SOFTWARE TEST CASE
En el ciclo de desarrollo y publicación de software, las pruebas y la verificación funcional desempeñan un papel decisivo:
es el momento en que se comprueba cada función frente a los requisitos de negocio.
Data-Ware verifica sus propias aplicaciones y las de sus clientes, preparando planes de prueba estructurados
y, cuando es posible, automatizándolos para garantizar calidad y fiabilidad antes del release.
PRUEBAS
Tipos. Casos.
Los pasos de prueba pueden dividirse en dos grandes macroáreas: pruebas de unidades individuales o funciones integradas y pruebas.
Pruebas de unidades y funciones individuales
En esta fase, el proyecto se realiza como un conjunto de programas (módulos) en el lenguaje de programación elegido.
Las pruebas unitarias se utilizan para verificar que cada módulo cumple las especificaciones requeridas.
Las funciones de seguridad implicadas en esta fase son:
• Análisis y pruebas de código - Antes de emitir nuevas partes de código de desarrollo, se realizan pruebas para identificar
buffer overflow, sql code injection, etc ...
• Métricas y post mortem - hacer seguimiento de los problemas de seguridad identificados durante las pruebas.
Para cada vulnerabilidad, se debe registrar en una base de datos de bugs.
La base de datos de bugs también contendrá todas las vulnerabilidades de seguridad aún no resueltas.
Pruebas integradas
En esta fase, se integran las unidades individuales y se ejecutan las pruebas completas del sistema para asegurarse de que se cumplen las especificaciones.
Las pruebas de seguridad implicadas en esta fase pueden identificarse en cinco macro actividades:
1. Network Mapping
2. Análisis de vulnerabilidades mediante herramientas automáticas
3. Penetration Testing
4. Password Cracking
5. Log auditing
Test case. Condiciones.
Un test case es un conjunto de condiciones mediante las cuales el tester determina si la aplicación cumple los requisitos o no.
Se define por tres entidades:
- elementos de entrada
- ruta
- resultado (elementos de salida)
Normalmente, cada aplicación debería tener un conjunto de test cases para todos los escenarios de aplicación que puedan ocurrir, incluidos los errores.
En caso de pruebas de rendimiento, no es necesario utilizar todos los test cases de la aplicación, ya que no se trata de la funcionalidad de la aplicación,
sino de su resistencia.
Entonces tendremos que seleccionar test cases que tengan un uso significativo (al menos superior al 5%), y aquellos donde el consumo de recursos sea mayor.
Por ejemplo, si tenemos una aplicación web, podríamos omitir la parte administrativa o de personalización del usuario para probar funciones más
comunes, como login / logout, búsqueda en el catálogo, pago, gestión del carrito, etc.
Para cada test case asociaremos un peso (uso), que servirá para definir la carga de trabajo durante las sesiones de prueba.
