Y continuamos con los métodos o modelos o formas para testear o para probar nuestras contramedidas o
hacer un assessment en general en este caso un poquito más enfocado en software.
Primero como temas más básicos tenemos los testeos a las pruebas dinámicas y estáticas de software otra
vez como tal.
Las pruebas estáticas Bargas valga la redundancia en su nombre testean el código de forma pasiva o estática.
En este caso significa que el código no está corriendo verdad.
Esto podría incluir revisión de código es decir ver el código y decir aquí falta una variable un punto
y coma.
Aquí hay muchos y saqué muchos loops en muchos ciclos que podrían afectar al performance.
Podríamos ver la sintaxis si está bien hecha etcétera etcétera.
Del análisis estático hay herramientas para hacerlo porque obviamente hacerlo manual puede ser un poco
difícil y nos podríamos saltar muchos problemas o muchas cosas que realmente estaban malas con el simple
hecho de verlo y hacerlo de forma manual entonces tenemos muchas herramientas para para ayudarnos con
esto.
En pocas palabras las pruebas o los test de forma estática en el código.
Luego tenemos los textos las pruebas de forma dinámica.
Esto significa que el código se está ejecutando.
Entonces de esta forma podríamos tener chequeos de seguridad de performance por ejemplo cuánta memoria
se está consumiendo si de repente por ahí el garbage collector está haciendo su trabajo en procesos
que ya no se están utilizando.
De repente hay alguna variable que no las aniquilamos bien o chequeamos los famosos Boundary checks
o los chequeos de límite verdad? de alguna variable.
Por ejemplo tenemos un login un formulario login y password pero se nos olvidó chequear el tamaño del
password que se podía utilizar y esto nos podría llevar a ser vulnerables a un ataque de buffer overflow
por ejemplo y esto lo hace otra vez con el código corriendo es decir de forma dinámica.
También obviamente tenemos herramientas para facilitar este tipo de pruebas para que no sea de forma
manual ni mucho menos.
Luego tenemos las transacciones sintéticas esto es básicamente simular actividades de la aplicación
por ejemplo loteos transacciones etcétera etcétera para ver el proforma verdad.
A esto comúnmente se le conoce como por estrés pero realmente el nombre que se la da o el nombre que
se ha adoptado últimamente es transacciones sintácticas sintéticas o monitoreos sintéticos como tal
pero este es el punto ver cuál es el cuál es el límite de transacciones por ejemplo si yo quisiera ver
cuántos usuarios puedo tener conectados al mismo tiempo o cuántos usuarios.
Por ejemplo si yo estoy testeando alguna aplicación para la banca cuántos usuarios pueden hacer una
transacción o un retiro de mi aplicación.
Por ejemplo tenemos también los niveles de testeo o de pruebas de software que por ejemplo tenemos las
pruebas unitarias.
Esto es básicamente una prueba de bajo nivel de los componentes del software.
Por ejemplo como funciones procedimientos objetos etcétera etcétera.
Luego tenemos las pruebas de instalación.
Esto básicamente es para ver que también se lleva el software con las demás herramientas por ejemplo
de repente hay un antivirus que no le gusta el software de repente y el software es algo para monitoreo
de usuarios de actividades en una computadora.
Entonces de repente por ahí el antivirus lo detecta como un virus y no puede dar su máximo potencial
si así lo quieren ver.
Luego tenemos los testeados de integración es decir que también se va a llevar en este caso con otras
herramientas que son necesarias para el funcionamiento por ejemplo de repente mi aplicación lo único
que hace es multiplicar sumar números o alguna calculadora pero yo necesito adaptarme hacia otro software
que ya está corriendo que es el que se encarga de hacer la reportería.
Es un ejemplo esto tendría que ver que también se lleva con la base de datos que está corriendo etcétera
etcétera.
Luego tenemos las pruebas de regresión es decir si vamos a tener a vamos a aplicar upgrades o modificaciones
o parches sobre alguna aplicación que esté corriendo.
Es decir si nosotros ya sacamos la versión 2.0 3.0 va a seguir dando la misma funcionalidad a los usuarios
que están utilizando la aplicación 1.0 o la versión base o va a quebrar alguna funcionalidad de repente
y metimos ahí algún algoritmo de inscripción nuevo que no se va a llevar bien con el sistema obsoleto
o viejito que teníamos antes o con una versión anterior y eso puede quebrar alguna funcionalidad dentro
del sistema del usuario.
Luego tenemos las pruebas de aceptación que valga la redundancia en el nombre otra vez es cuando el
cliente dice Bueno sí acepto esto y esto puede ser desde funcionalidades de negocio es decir sí si me
gusta cómo se hacen las transacciones hasta funcionalidades de seguridad por ejemplo Orda bueno de repente
y el cliente había pedido agregar dos factores de autenticación recuérdense algo que soy algo que tengo
algo que sé y Dónde estoy.
Podría ser.
De repente el cliente había pedido eso y nosotros no lo agregamos entonces esto podría ser algo que
podríamos tener ahí con las pruebas de aceptación.
Por último pasamos a una técnica muy conocida que realmente no hay una traducción al español literal
de lo que significa pero sea más fácil.
Y es básicamente un estilo de prueba tipo caja negra es decir yo le meto información random a la aplicación
para ver cómo se comporta la otra vez.
Esto nos sirve por ejemplo para Floqq.
De repente yo le meto mil caracteres al campo de password para ver si realmente los acepta.
También podría decir bueno yo lo voy a meter en una fecha 30 de febrero de algún año que no existe vamos
a ver cómo se comporta la herramienta elemento cero dividido menos 1 o 1 dividido menos 1 2 0.
Cualquier cualquier tipo de input que pueda tener de repente yo le meto caracteres marchar a una a un
campo sólo numérico para ver cómo se comporta la aplicación recuérdense los errores que pueda traer
alguna aplicación pueden revelar también información confidencial de cómo cómo funciona la aplicación
por debajo de la escena digámoslo así por debajo de la de todo el show que tenemos ahí el hacia el cliente.
Podríamos revelar tal vez la versión de la base de datos podríamos revelar la versión de cualquier versión
o cualquier software que se esté corriendo Android de cines como le conocen los estadounidenses o las
personas de habla inglés.
Podríamos revelar también información que realmente no tendría que haberse digamos revelado hacia el
público entonces ahí tendríamos un gran problema con eso.
Entonces este es en pocas palabras fácil verdad y que incluye casos de uso como el Jews cais o el caso
del mal uso otra vez meter información con por ejemplo un númerica en un campo que sólo recibe caracteres
o meter caracteres en un campo solo reciben números.
Meter el 30 de febrero de algún año 73 es el mismo que hizo caso de mal uso digamos así y obviamente
tenemos el interfaz detesten es decir ver que realmente de repente yo me lo veía como un usuario de
bajos privilegios que realmente no podía dar clic en algunas pestañas o que realmente los botones estén
habilitados deshabilitados etcétera etcétera.
Y bueno en pocas palabras esos son los tipos de testeo que tenemos ojo para el software.
Y ojo también que no son los únicos y también como siempre como siempre he dicho a través del curso
no es que esto sea lo único que vaya a existir como pruebas hay mucho más pero estos son los más básicos
o los más utilizados.
Y bueno eso es todo amigos.
Pero les ha gustado y nos vemos muy pronto.