Etapas de pruebas de pruebas en varios modelos de desarrollo. ¿Por qué son necesarias las pruebas? Preparándose para la prueba

Prueba de servicios web

Mayoría mejor manera evaluar si probamos bien el producto; analizar los defectos no detectados. Aquellos que nuestros usuarios, implementadores y empresas han encontrado. Puedes evaluar muchas cosas a partir de ellos: qué no hemos comprobado lo suficiente, a qué áreas del producto se debe prestar más atención. más atención, cuál es el porcentaje general de omisiones y cuál es la dinámica de sus cambios. Con esta métrica (quizás la más común en las pruebas), todo está bien, pero... Cuando lanzamos el producto y nos enteramos de los errores omitidos, puede que ya sea demasiado tarde: apareció un artículo enojado sobre nosotros en Habré, los competidores están Las críticas se difunden rápidamente, hemos perdido la confianza de los clientes en nosotros, la dirección está insatisfecha.

Para evitar que esto suceda, normalmente intentamos evaluar la calidad de las pruebas con antelación, antes del lanzamiento: ¿qué tan bien y en profundidad probamos el producto? ¿Qué áreas faltan atención, dónde están los principales riesgos, cuál es el progreso? Y para responder a todas estas preguntas, evaluamos la cobertura de las pruebas.

¿Por qué evaluar?

Cualquier métrica de evaluación es una pérdida de tiempo. En este momento, puede realizar pruebas, crear errores y preparar pruebas automáticas. ¿Qué tipo de beneficio mágico obtenemos de las métricas de cobertura de pruebas para sacrificar el tiempo de prueba?

1. Encontrar tus áreas débiles. Naturalmente, ¿necesitamos esto? no sólo para llorar, sino para saber dónde se necesitan mejoras. Cual áreas funcionales¿No está cubierto por las pruebas? ¿Qué no hemos comprobado? ¿Dónde están los mayores riesgos de perder errores?
2. Rara vez obtenemos el 100% según los resultados de nuestra evaluación de cobertura. ¿Qué mejorar? ¿A dónde ir? ¿Cuál es el porcentaje ahora? ¿Cómo podemos aumentarlo con cualquier tarea? ¿Qué tan rápido podemos llegar a 100? Todas estas preguntas aportan transparencia y claridad a nuestro proceso., y las respuestas las proporciona la evaluación de cobertura.
3. Foco de atención. Digamos que nuestro producto tiene alrededor de 50 áreas funcionales diferentes. resulta nueva versión, y comenzamos a probar 1 de ellos, y encontramos errores tipográficos allí, botones que se han movido un par de píxeles y otras pequeñas cosas... Y ahora el tiempo de prueba terminó, y esta funcionalidad se prueba en detalle... ¿Y los otros 50? La evaluación de cobertura nos permite priorizar tareas en función de las realidades y plazos actuales.

¿Cómo evaluar?

Antes de implementar cualquier métrica, es importante decidir cómo la utilizará. Comience respondiendo exactamente esta pregunta; lo más probable es que comprenda de inmediato cuál es la mejor manera de calcularla. Y en este artículo solo compartiré algunos ejemplos y mi experiencia sobre cómo se puede hacer esto. No para copiar soluciones a ciegas, sino para que su imaginación se base en esta experiencia y piense en una solución que sea ideal para usted.

Evaluamos la cobertura de requisitos mediante pruebas.

Digamos que tiene analistas en su equipo y no pierden el tiempo. horas de trabajo. Según los resultados de su trabajo, se crearon requisitos en RMS (Sistema de gestión de requisitos): HP QC, MS TFS, IBM Doors, Jira (con complementos adicionales), etc. Ingresan requisitos en este sistema que cumplen con los requisitos (perdón por la tautología). Estos requisitos son atómicos, trazables, específicos... En general, condiciones ideales para pruebas. ¿Qué podemos hacer en este caso? Cuando utilice un enfoque escrito, vincule los requisitos y las pruebas. Realizamos pruebas en el mismo sistema, establecemos una conexión entre requisitos y pruebas y en cualquier momento podemos ver un informe sobre qué requisitos tienen pruebas, cuáles no, cuándo se aprobaron estas pruebas y con qué resultado.
Obtenemos un mapa de cobertura, cubrimos todos los requisitos no cubiertos, todos quedan contentos y satisfechos, no se nos escapa ningún error...

Bien, volvamos del cielo a la tierra. Lo más probable es que no tenga requisitos detallados, no sean atómicos, algunos de los requisitos se hayan perdido por completo y no tenga tiempo para documentar cada prueba, o al menos cada dos pruebas. Puede desesperarse y llorar, o puede admitir que las pruebas son un proceso compensatorio, y cuanto peor están las cosas con el análisis y el desarrollo del proyecto, más debemos esforzarnos y compensar los problemas de otros participantes en el proceso. Veamos los problemas por separado.

Problema: los requisitos no son atómicos.

Los analistas también a veces cometen errores mentales y, por lo general, esto está plagado de problemas en todo el proyecto. Por ejemplo, estás desarrollando editor de texto, y es posible que tenga dos requisitos en su sistema (entre otros): "el formato html debe ser compatible" y "al abrir un archivo de un formato no compatible, debería aparecer una ventana emergente con una pregunta". ¿Cuántas pruebas se requieren para cheque básico 1er requisito? ¿Y para el 2do? ¡¡¡La diferencia en las respuestas probablemente sea cien veces mayor!!! No podemos decir que si hay al menos 1 prueba para el primer requisito, esto sea suficiente, pero para el segundo, lo más probable es que lo sea.

¡Por tanto, la presencia de una prueba de requisitos no nos garantiza nada en absoluto! ¿Qué significan nuestras estadísticas de cobertura en este caso? ¡Casi nada! ¡Tendremos que decidir!

1. En este caso, se puede eliminar el cálculo automático de la cobertura de requisitos mediante pruebas; todavía no conlleva ninguna carga semántica.
2. Para cada requisito, empezando por el de mayor prioridad, preparamos pruebas. A la hora de prepararnos analizamos qué pruebas requerirá este requisito, ¿cuántas serán suficientes? Llevamos a cabo un análisis de prueba completo y no lo descartamos "hay una prueba, bueno, está bien".
3. Dependiendo del sistema utilizado, exportamos/subimos pruebas bajo demanda y... ¡probamos estas pruebas! ¿Hay suficientes? Lo ideal, por supuesto, es que dichas pruebas se realicen con un analista y desarrollador de esta funcionalidad. Imprime las pruebas, encierra a tus compañeros en una sala de reuniones y no los dejes ir hasta que digan “sí, estas pruebas son suficientes” (esto sólo sucede con un acuerdo escrito, cuando estas palabras se dicen para cerrar, incluso sin analizando las pruebas Durante una discusión oral, sus colegas lanzarán críticas, pruebas perdidas, requisitos incomprendidos, etc. (esto no siempre es agradable, ¡pero es muy útil para las pruebas!)
4. Después de finalizar las pruebas según sea necesario y acordar su integridad, a este requisito se le puede asignar el estado "cubierto por pruebas" en el sistema. Esta información significará mucho más que “aquí hay al menos 1 prueba”.

Por supuesto, un proceso de aprobación de este tipo requiere muchos recursos y tiempo, especialmente al principio, antes de adquirir práctica. Por lo tanto, lleve a cabo únicamente los requisitos de alta prioridad y nuevas mejoras. Con el tiempo, irás ajustando los requisitos restantes y ¡todos estarán contentos! Pero... ¿y si no hay ningún requisito?

Problema: no hay ningún requisito.

Están ausentes del proyecto, se discuten oralmente, cada uno hace lo que quiere/puede y como entiende. Lo probamos de la misma manera. Como resultado, tenemos una gran cantidad de problemas no solo en las pruebas y el desarrollo, sino también en la implementación inicialmente incorrecta de funciones: ¡queríamos algo completamente diferente! Aquí puedo recomendar la opción "definir y documentar los requisitos usted mismo", e incluso utilicé esta estrategia un par de veces en mi práctica, pero en el 99% de los casos no existen tales recursos en el equipo de pruebas, así que tomemos un poco más de tiempo. ruta que requiere menos recursos:

1. Crea una lista de características. ¡Sami! En forma de signo de Google, en formato PBI en TFS: elija cualquiera, siempre que no lo haga formato de texto. ¡Todavía necesitamos recopilar estados! Agregamos todas las áreas funcionales del producto a esta lista e intentamos elegir una. nivel general descomposición (puede escribir objetos de software, scripts de usuario, módulos, páginas web, métodos API o formularios de pantalla...), ¡pero no todo esto a la vez! UN formato de descomposición, más fácil y visual para ti, te permitirá no perderte cosas importantes.
2. Estamos de acuerdo en la INTEGRIDAD de esta lista con analistas, desarrolladores, empresas, dentro de nuestro equipo... ¡Intenta hacer todo lo posible para no perder partes importantes del producto! La profundidad del análisis depende de usted. En mi práctica, solo había unos pocos productos para los cuales creamos más de 100 páginas en la tabla, y eran productos gigantes. En la mayoría de los casos, entre 30 y 50 líneas son un resultado que se puede lograr con un procesamiento cuidadoso posterior. En un equipo pequeño sin analistas de pruebas dedicados numero mayor Los elementos de la lista de características serán demasiado difíciles de mantener.
3. Después de eso, pasamos por prioridades y procesamos cada línea de la lista de características como en la sección de requisitos descrita anteriormente. Escribimos pruebas, discutimos, acordamos la suficiencia. Marcamos los estados para qué característica hay suficientes pruebas. Recibimos estados, avances y ampliación de pruebas a través de la comunicación con el equipo. ¡Todos están felices!

Pero... ¿Qué pasa si los requisitos se mantienen, pero no en un formato rastreable?

Problema: los requisitos no son rastreables.

Hay una gran cantidad de documentación sobre el proyecto, los analistas escriben a una velocidad de 400 caracteres por minuto, tienes especificaciones, especificaciones técnicas, instrucciones, certificados (la mayoría de las veces esto sucede a petición del cliente), y todo esto actúa. como requisitos, y todo ha estado en el proyecto durante mucho tiempo. ¿No sabe dónde buscar qué información?
Repetimos el apartado anterior, ¡ayudando a todo el equipo a organizarse!

1. Creamos una lista de características (ver arriba), pero sin descripción detallada requisitos.
2. Para cada característica, recopilamos enlaces a especificaciones técnicas, especificaciones, instrucciones y otros documentos.
3. Nos guiamos por prioridades, preparamos pruebas, acordamos su integridad. Todo es igual, solo que al combinar todos los documentos en una sola tabla aumentamos la facilidad de acceso a ellos, los estados transparentes y la coherencia de las pruebas. Al final, ¡todo va genial con nosotros y todos contentos!

Pero... No por mucho tiempo... Parece que durante la semana pasada, los analistas han actualizado 4 especificaciones diferentes según las solicitudes de los clientes!!!

Problema: los requisitos cambian todo el tiempo.

Por supuesto, sería bueno probar algún tipo de sistema fijo, pero nuestros productos suelen estar vivos. El cliente pidió algo, algo cambió en la legislación externa a nuestro producto, y en algún lugar los analistas encontraron un error en el análisis del año pasado... ¡Las exigencias viven sus propias vidas! ¿Qué hacer?

1. Supongamos que ya ha recopilado enlaces a especificaciones técnicas y especificaciones en forma de tabla de lista de características, PBI, requisitos, notas Wiki, etc. Digamos que ya tiene pruebas para estos requisitos. ¡Y ahora el requisito está cambiando! Esto podría significar un cambio en RMS, una tarea en TMS (Sistema de gestión de tareas) o una carta por correo. En cualquier caso, esto lleva a la misma consecuencia: ¡tus pruebas son irrelevantes! O puede que no sean relevantes. Esto significa que requieren actualización (cobertura de prueba versión antigua el producto de alguna manera realmente no cuenta, ¿verdad?)
2. En la lista de características, en RMS, en TMS (Sistema de gestión de pruebas – testrails, sitechco, etc.), las pruebas deben marcarse necesaria e inmediatamente como irrelevantes. En HP QC o MS TFS esto se puede hacer automáticamente al actualizar requisitos, pero en una placa de Google o wiki tendrás que ingresarlo manualmente. Pero deberías darte cuenta de inmediato: ¡las pruebas son irrelevantes! Esto significa que nos enfrentamos a una ruta iterativa completa: actualizar, volver a ejecutar el análisis de prueba, reescribir las pruebas, acordar los cambios y solo después de eso marcar la característica/requisito nuevamente como "cubierto por pruebas".

En este caso, obtenemos todos los beneficios de la evaluación de cobertura de pruebas, ¡y en dinámica! ¡¡¡Todos están felices!!! Pero…
Pero ha pasado tanto tiempo trabajando en los requisitos que ahora no tiene suficiente tiempo para realizar pruebas o documentar las pruebas. En mi opinión (¡y aquí hay lugar para una disputa religiosa!) los requisitos más importante que las pruebas¡Y es mejor así! Al menos están bien, todo el equipo lo sabe y los desarrolladores están haciendo exactamente lo que se necesita. ¡PERO NO QUEDA TIEMPO PARA DOCUMENTAR LAS PRUEBAS!

Problema: no hay suficiente tiempo para documentar las pruebas.

De hecho, el origen de este problema puede ser no sólo la falta de tiempo, sino también tu elección muy consciente de no documentarlos (no nos gustan, evitamos el efecto de un pesticida, el producto cambia con demasiada frecuencia, etc.) .). ¿Pero cómo evaluar la cobertura de la prueba en este caso?

1. Aún necesitará los requisitos, ya sea como requisitos completos o como una lista de características, por lo que algunas de las secciones descritas anteriormente, dependiendo del trabajo de los analistas en el proyecto, seguirán siendo necesarias. ¿Tienes los requisitos/lista de características?
2. Describimos y acordamos verbalmente brevemente la estrategia de prueba, ¡sin documentar pruebas específicas! Esta estrategia puede especificarse en una columna de una tabla, en una página wiki o en un requisito del RMS, y nuevamente debe acordarse. Como parte de esta estrategia, los controles se realizarán de forma diferente, pero usted sabrá: cuándo último tiempo¿Probado y usando qué estrategia? ¡Y esto, ya ves, tampoco está mal! Y todos serán felices.

Pero… ¿Qué otro “pero”? ¿¿¿Cual???

¡Digamos que lo solucionaremos todo y que los productos de calidad nos acompañen!

Plan de curso:

1.
Modelo de prueba y cómo trabajar con la estructura.
2.
Cómo crear cheques
1.
2.
Técnicas de diseño de pruebas (caja negra)
Descripción general de las técnicas de caja blanca
3.
Trabajar con coherencia
4.
Formulación de controles
5.
Priorización
6.
Siguiendo el proceso de documentación de prueba.

Auditoría: lo que se comprobó

1.
Integridad de la cobertura (según sea necesario)
2.
Coherencia (duplicados, requisitos contradictorios)
3.
Estructura (dividida en partes y en kits de prueba cómo te golpean por los cheques)
4.
Contenido de los controles (redacción, comprensible para todos los participantes del proyecto)
5.
Diseño (errores administrativos, apariencia cuidada)
6.
Recubrimiento (Humo/MAT/AT)
7.
Cumplimiento del proceso (proceso de trabajar con la documentación de prueba)

Errores para todo tipo de documentación.
Alfabetismo
60
10,4
Cubriendo todas las funciones
cheques
42
9,4
Desglose de funciones
6,4
Apariencia
6,2
estilo único
2,1
Métodos de documento
2,1
Métodos de resultados
2
55
38
14
20
17
% de todos los proyectos
% de todos los errores

Errores de encuesta de prueba, casos de prueba
Saltarse cheques
12,6
Esperado
resultado
Duplicados
estilo único
Controversias
Prioridad
70
47
6
38
3,5
25
2,4
25
1,6
1,4
19
% de todos los proyectos
% de todos los errores

modelo de prueba

- Este estructura lógica, describiendo la funcionalidad
comportamiento del sistema y/o del usuario, según el cual
Se generan casos de prueba. Construyendo un modelo de prueba
comienza con la construcción de la estructura, y luego se aprueba
la estructura está llena de casos de prueba/verificaciones.
c) Dmitri Tishchenko. Blog de A1QA, 2014

Cobertura de inspección

1) Deseos del cliente actual en especificaciones\requisitos\diseños
2) Acuerdos sobre el proyecto.
3) Disponibilidad controles necesarios para cada función:
Técnicas de diseño de pruebas:
◦
◦
◦
◦
Pruebas de partición equivalente
Prueba de valores límite
Prueba por pares
Pruebas de transición estatal

Partición de equivalencia

TECNOLOGÍA DE CLASES EQUIVALENTES

*para simplificar el ejemplo, tomemos un precio constante

1) Divida los parámetros de entrada en clases.

Parámetro
Clase 1
Clase 2
Versión del producto
Estándar
De primera calidad
<0
0 <= количество < 100
Cantidad
Clase 3
>= 100
*Voice of Reason: para la "Versión del producto", debe probar TODOS los valores de la clase de valor válida.
Por ejemplo, para el campo Pago (valores: tarjeta, efectivo, transferencia), es lógico probar TODAS las opciones por separado

2) 1 clase == 1 cheque

Versión del producto
Caso 1
Estándar
Caso 2
De primera calidad
Cantidad

2) 1 clase == 1 cheque

Versión del producto
Caso 1
Estándar
Caso 2
De primera calidad
Cantidad
Caso 3
-1
Caso 4
16
Caso 5
125

3) Cheque negativo solo para 1ra clase en el caso

Versión del producto
Cantidad
Resultado
Caso 1
Estándar
50
Positivo
Caso 2
De primera calidad
50
Positivo
Caso 3
Estándar
-1
Negativo
Caso 4
Estándar
16
Positivo
Caso 5
Estándar
125
Negativo

4) Reconsiderar los controles positivos

Versión del producto
Cantidad
Resultado
Caso 1
Estándar
50
Positivo
Caso 2
De primera calidad
50
Positivo
Caso 3
Estándar
-1
Negativo
Caso 4
Estándar
16
Positivo
Caso 5
Estándar
125
Negativo

5) sumas

Versión del producto
Cantidad
Resultado
Caso 1
De primera calidad
50
Positivo
Caso 2
Estándar
-1
Negativo
Caso 3
Estándar
16
Positivo
Caso 4
De primera calidad
125
Negativo

Más clases...

Parámetro
Clase 1
Clase 2
Versión del producto
Estándar
De primera calidad
<0
0 <= Кол-во < 100
Fraccionario
Entero
Números
No números
Cantidad
Clase 3
> 100
Vacío

Versión del producto
Cantidad
Resultado
Caso 1
Estándar
50
Positivo
Caso 2
De primera calidad
10
Positivo
Caso 3
De primera calidad
-1
Negativo
Caso 4
Estándar
16
Positivo
Caso 5
De primera calidad
150
Negativo
Caso 6
De primera calidad
19,45
Negativo
Caso 7
De primera calidad
%¡Número!
Negativo
Caso 8
Estándar
-
Negativo

Versión del producto
Cantidad
Resultado
Caso 1
Estándar
50
Positivo
Caso 2
De primera calidad
10
Positivo
Caso 3
De primera calidad
-1
Negativo
Caso 4
Estándar
16
Positivo
Caso 5
De primera calidad
150
Negativo
Caso 6
De primera calidad
19.45
Negativo
Caso 7
De primera calidad
%¡Número!
Negativo
Caso 8
Estándar
-
Negativo

~30% de casos positivos

Versión del producto
Cantidad
Resultado
Caso 1
Estándar
50
Positivo
Caso 2
De primera calidad
10
Positivo
Caso 3
De primera calidad
-1
Negativo
Caso 4
De primera calidad
150
Negativo
Caso 5
De primera calidad
19.45
Negativo
Caso 6
De primera calidad
%¡Número!
Negativo
Caso 7
Estándar
-
Negativo

Función
Parámetro de entrada
Beneficiario
Enviar
Sujeto
Cuerpo
Archivos
Adjuntar
Archivos
Dar formato al texto
Borrar
Vacío
Clase 1
Clase 2
Dirección existente Dirección inexistente
Talla 0
0 < Размер <= Limit
Contiene símbolos @
._-+
Símbolos distintos de @ . _ - +
Formato
No formatear
Talla 0
0 < Размер <= Limit
Contiene personajes
excepto “∞₽₾₾©¥£μ®” Símbolos ∞₽₾₾©¥£μ®
Talla 0
0 < Размер <= Limit
Formato
Sin formato
No
Uno
Talla 0
0 < Размер <= Limit
Apoyado
No compatible
No hay texto seleccionado
elegir
Texto
formateo
Hacer clic
Clase 3
Tamaño > Límite
Tamaño > Límite
Tamaño > Límite
Muchos
Tamaño > Límite
formateado
º texto

№
1
2
Beneficiario
existe
0 < Размер <= Limit
Sujeto
0 < Размер <= Limit
Contiene personajes
excepto “∞₽₾₾©¥£μ®”
3 Contiene símbolos @. _ 0< Размер <= Limit
-+
4 formato
0 < Размер <= Limit
5 Dirección inexistente 0< Размер <= Limit
6 Talla 0
Contiene personajes
excepto “∞₽₾₾©¥£μ®”
7 Tamaño > Límite
Contiene personajes
excepto “∞₽₾₾©¥£μ®”
8 Sin formato
0 < Размер <= Limit
9 0 < Размер <= Limit
Talla 0
10 0 < Размер <= Limit
Tamaño > Límite
11 0 < Размер <= Limit
Contiene personajes
“∞₽₾₾©¥£µ®”
12 hay
0 < Размер <= Limit
0 < Размер <= Limit
Formato
No
Uno
Esperado
resultado
Enviado
Enviado
0 < Размер <= Limit
Tres
Enviado
0 < Размер <= Limit
0 < Размер <= Limit
Formato
Tres
No
Uno
Enviado
No entregado
No enviado
Formato
Uno
No enviado
0 < Размер <= Limit
Formato
0 < Размер <= Limit
0 < Размер <= Limit
No
Uno
Tres
Tres
No enviado
No enviado
No enviado
No enviado
Tamaño > Límite
No
No enviado
Cuerpo
Archivos

#
Aporte
Resultado
Vacío
Cancelar eliminación
Texto no seleccionado\no seleccionar
formateo
Carta eliminada
La carta no ha sido eliminada.
Texto
Formato aplicado
4
Texto enriquecido
Nuevo formato aplicado
5
Tamaño y formato disponibles
valores
Archivo adjunto
No especificar archivo
Archivo no adjunto
Especificar un archivo de un tamaño no válido
(mín.< или >máximo)
Archivo no adjunto
Especificar archivo no compatible
Archivo no adjunto
1
Función
Eliminación
2
3
6
7
8
Formato
Adjunto
archivo
El sistema no aplica formato.

Valores límite

TÉCNICA DEL VALOR LÍMITE

Tarea: crear casos de prueba para el plan de evacuación

Tarea: crear casos de prueba para el plan de evacuación

0
Prueba básica
Para calmar los nervios
Prueba negativa
99

99
0
0
99

Encontrar todos los pares (ver gráfico)
En matemáticas, este es el producto cartesiano:
Plan_de_evacuación x Evaluación_de_riesgos = ((a,b) | a ∈ Plan_de_evacuación, b ∈ Evaluación_de_riesgos)
Plan_de_evacuación x Evaluación_de_riesgos =
{ (-1,-1),
(-1,0), (-1,1),
(-1,50),
(-1,98), (-1,99), (-1,100),
(0,-1),
(0,0),
(0,1),
(0,50),
(0,98),
(0,99),
(0,100),
(1,-1),
(1,0),
(1,1),
(1,50),
(1,98),
(1,99),
(1,100),
(50,-1), (50,0), (50,1), (50,50),
(50,98), (50,99), (50,100),
(98,-1), (98,0), (98,1), (98,50),
(98,98), (98,99), (98,100),
(99,-1), (99,0), (99,1),
(99,50), (99,98), (99,99),
(99,100),
(100,-1), (100,0), (100,1), (100,50), (100,98), (100,99), (100,100),
}
7x7 = 49 cheques

Plan_evacuación = (-1, 0, 1, 50, 98, 99, 100)
Evaluación_Riesgo = (-1, 0, 1, 50, 98, 99, 100)
EP_Type = (Estándar, Premium)
RA_Type = (Estándar, Premium)
Número de casos = 7 * 7 * 2 * 2 = 196

Pruebas por pares

TÉCNICA PARA PRUEBA DE TODOS LOS PARES

Tarea

Almacenamiento de datos (5): PostgreSQL, Oracle, MySQL, JSON, XML
Sistema operativo (4): Windows 7, 8, 10, OS X 10
RAM (3): 1024 MB, 4096 MB, 8192 MB
Disco duro (2): SCSI, IDE
Búsqueda completa = 5 * 4 * 3 * 2 = 120 opciones

Ideas

1. Pruebe pares de valores, no búsquedas exhaustivas
2. Prueba empírica de eficacia
3. Opciones de técnica masiva de todos los pares/ortogonal

Trabajando con ortogonales
matrices

1
2
3
4
5
Datos
PostgreSQL
Oráculo
mysql
JSON
XML
SO
ventana 7
ventana 8
ventanas 10
OS X 10
RAM
1 024 megas
4 096 megas
8 192 megas
disco duro
SCSI
IDE

Trabajando con ortogonales
matrices
1. Comprenda qué y cuántos parámetros de entrada:
1
2
3
4
5
Datos
PostgreSQL
Oráculo
mysql
JSON
XML
SO
ventana 7
ventana 8
ventanas 10
OS X 10
RAM
1 024 megas
4 096 megas
8 192 megas
disco duro
SCSI
IDE

Trabajando con ortogonales
matrices
1. Comprenda qué y cuántos parámetros de entrada:
Almacenamiento de datos
SO
RAM
disco duro
Columna 5
Columna 6
1
1
1
1
1
1
1
2
2
2
2
2
1
3
3
3
3
3
1
4
4
4
4
4
1
5
5
5
5
5
2
1
2
3
4
5
2
2
3
4
5
1
1
2
3
4
5
2
3
4
5
1
2
Datos
PostgreSQL
Oráculo
mysql
JSON
XML
2
4
5
1
2
3
SO
ventana 7
ventana 8
ventanas 10
OS X 10
2
5
1
2
3
4
3
1
3
5
2
4
RAM
1 024 megas
4 096 megas
8 192 megas
3
2
4
1
3
5
disco duro
SCSI
IDE
3
3
5
2
4
1
3
4
1
3
5
2
3
5
2
4
1
3
4
1
4
2
5
3
4
2
5
3
1
4
4
3
1
4
2
5
4
4
2
5
3
1
4
5
3
1
4
2
5
1
5
4
3
2
5
2
1
5
4
3
5
3
2
1
5
4
5
4
3
2
1
5
5
5
4
3
2
1
2. Seleccione una matriz ortogonal adecuada: L25(56 ^6)

Trabajando con ortogonales
matrices
1. Comprenda qué y cuántos parámetros de entrada:
1
2
3
4
5
Datos
PostgreSQL
Oráculo
mysql
JSON
XML
SO
ventana 7
ventana 8
ventanas 10
OS X 10
RAM
1 024 megas
4 096 megas
8 192 megas
disco duro
SCSI
IDE
2. Seleccione una matriz ortogonal adecuada:
3. Construyendo una matriz ortogonal
4. Eliminar COLUMNAS innecesarias
L25(56^6)
Almacenamiento de datos
SO
RAM
disco duro
1
1
1
1
1
2
2
2
1
3
3
3
1
4
4
4
1
5
5
5
2
1
2
3
2
2
3
4
2
3
4
5
2
4
5
1
2
5
1
2
3
1
3
5
3
2
4
1
3
3
5
2
3
4
1
3
3
5
2
4
4
1
4
2
4
2
5
3
4
3
1
4
4
4
2
5
4
5
3
1
5
1
5
4
5
2
1
5
5
3
2
1
5
4
3
2
5
5
4
3

Trabajando con ortogonales
matrices
1. Comprenda qué y cuántos parámetros de entrada:
Almacenamiento de datos
SO
RAM
disco duro
1
PostgreSQL
ventana 7
1 024 megas
SCSI
2
PostgreSQL
ventana 8
4 096 megas
IDE
3
PostgreSQL
ventanas 10
8 192 megas
SCSI
4
PostgreSQL
OS X 10
1 024 megas
SCSI
5
PostgreSQL
ventanas 10
1 024 megas
SCSI
6
Oráculo
ventana 7
4 096 megas
SCSI
7
Oráculo
ventana 8
8 192 megas
SCSI
1
2
3
4
5
8
Oráculo
ventanas 10
1 024 megas
SCSI
Datos
PostgreSQL
Oráculo
mysql
JSON
XML
9
Oráculo
OS X 10
1 024 megas
SCSI
SO
ventana 7
ventana 8
ventanas 10
OS X 10
10
Oráculo
ventanas 10
1 024 megas
IDE
11
mysql
ventana 7
8 192 megas
SCSI
RAM
1 024 megas
4 096 megas
8 192 megas
12
mysql
ventana 8
1 024 megas
SCSI
disco duro
SCSI
IDE
13
mysql
ventanas 10
4 096 megas
IDE
14
mysql
OS X 10
1 024 megas
SCSI
15
mysql
OS X 10
4 096 megas
SCSI
16
JSON
ventana 7
4 096 megas
IDE
17
JSON
ventana 8
4 096 megas
SCSI
18
JSON
ventanas 10
1 024 megas
SCSI
19
JSON
OS X 10
4 096 megas
SCSI
20
JSON
OS X 10
8 192 megas
SCSI
21
XML
ventana 7
4 096 megas
SCSI
22
XML
ventana 8
1 024 megas
SCSI
23
XML
ventanas 10
4 096 megas
SCSI
24
XML
OS X 10
8 192 megas
IDE
25
XML
ventanas 10
4 096 megas
SCSI
2. Seleccione una matriz ortogonal adecuada: L25(56 ^6)
3. Construyendo una matriz ortogonal
4. Eliminar COLUMNAS innecesarias
5. Ingrese los valores de los parámetros de entrada.
6. Complete los espacios en blanco + verifique la relevancia de los pares

PICTO
Almacenamiento de datos
SO
RAM
disco duro
1
JSON
OSX_10
4096MB
SCSI
2
Oráculo
windows7
1024MB
IDE
3
mysql
windows10
8192MB
IDE
4
Oráculo
windows8
8192MB
SCSI
5
JSON
windows8
1024MB
IDE
6
JSON
windows7
8192MB
SCSI
7
Oráculo
windows10
1024MB
SCSI
8
XML
windows7
4096MB
IDE
9
mysql
OSX_10
1024MB
SCSI
10
JSON
windows10
4096MB
SCSI
11
XML
windows10
8192MB
SCSI
12
PostgreSQL
windows8
4096MB
SCSI
13
mysql
windows7
4096MB
SCSI
14
XML
windows8
1024MB
IDE
15
PostgreSQL
windows7
1024MB
IDE
16
XML
OSX_10
8192MB
IDE
17
PostgreSQL
windows10
8192MB
SCSI
18
mysql
windows8
4096MB
IDE
19
PostgreSQL
OSX_10
8192MB
IDE
20
Oráculo
OSX_10
4096MB
SCSI

105*16*2*4*5*2 = 134 400

1
2
3
4
5
…
105
Sujeto
árabe
Historia del Arte
Biología
Negocio
Estudios
Química
…
EAL
Nivel escolar (16)
Elemental
Medio
Alto
Toda la escuela
Alto/Medio
…
Probabilidad
Definido
Tentativo
Empleo
Tipo
Lleno
Parte
Sustituto
Temporario
Duración del contrato
1
2
3
4
Carta de presentación

El capítulo introduce el concepto de calidad, describe el proceso de prueba y analiza cómo la calidad y las pruebas se relacionan con diversos procesos de fabricación. Se presenta la visión tradicional de las pruebas como un mecanismo para evaluar la calidad de un producto, y también describe cómo las pruebas ayudan a fortalecer y fortalecer la arquitectura en las primeras etapas del ciclo de desarrollo.

Objetivo

El propósito de las pruebas es evaluar la calidad del producto. Esto significa no sólo evaluar el producto final, sino también evaluar la arquitectura desde las primeras etapas del proceso hasta la entrega final del producto a los clientes. incluye lo siguiente.

Comprobación de las interacciones de los componentes

Comprobación de la correcta integración de los componentes.

Comprobar la exactitud de la implementación de todos los requisitos.

Identificar los defectos y tomar las medidas necesarias para eliminarlos antes
implementación de software

Calidad

Uso estándar del término calidad incluye muchas cosas: por regla general, esta palabra denota la ausencia de defectos y (¡lo que es mucho más importante!) el cumplimiento del objetivo previsto; Con el concepto de calidad asociamos lo que necesitamos de un producto. Un producto (o un componente del mismo) puede no ser defectuoso, pero si no hace lo que necesitamos, es tan inútil como un producto defectuoso. El objetivo principal de las pruebas es evaluar la calidad del producto final, así como evaluar la calidad de los componentes que lo componen y la arquitectura que determina la forma de esos componentes. Esto es para garantizar que el producto sea

Capítulo 12. G67

cumple o supera ciertos requisitos (evaluados según medidas y criterios de aceptación).

La calidad de un producto no puede evaluarse plenamente por sí sola; El software es desarrollado por una organización mediante un proceso, por lo que la mala calidad puede deberse a un proceso deficiente o a un proceso difícil de seguir. Como consecuencia, la evaluación de la calidad a menudo considera no sólo la calidad del producto en sí, sino también factores organizativos y la calidad del proceso.

¿Quién es responsable de la calidad del producto?

Todos los miembros del equipo del proyecto son responsables de producir un producto de calidad. Si la calidad no estaba inicialmente integrada en el producto, entonces ya no se puede “agregar más adelante” realizando algunas acciones activas para garantizar la calidad.

La tarea de probar no es garantizar calidad y evaluar al mismo tiempo que brinda retroalimentación para resolver problemas de calidad a un costo y tiempo razonables. El trabajo del evaluador es evaluar la calidad y proporcionar comentarios, y el trabajo del equipo del proyecto es crear artefactos que cumplan con los requisitos y parámetros de calidad.

Pruebas en un ciclo de vida iterativo

Las pruebas no son una actividad separada ni una fase de un proyecto en la que se realiza una evaluación de la calidad. Si los desarrolladores necesitan retroalimentación oportuna sobre cuestiones de calidad del producto, entonces se deben realizar pruebas a lo largo de todo el ciclo de vida: se puede probar la funcionalidad de los primeros prototipos; estabilidad, cobertura y rendimiento de la arquitectura (siempre se pueden corregir malas decisiones); Además, puede probar el producto final y evaluar su preparación para transferirlo a manos de los clientes. Existe una opinión común de que las pruebas son la verificación final del desempeño global; Sin embargo, esta situación pierde el principal beneficio de las pruebas: la oportunidad de brindar retroalimentación mientras todavía hay tiempo (y recursos) para tomar las medidas necesarias.

Clasificación de pruebas

Para evaluar la calidad de un producto se requieren varios tipos de pruebas. Las siguientes características se pueden utilizar para clasificar las pruebas.

Parámetro de calidad probado -¿Qué parámetro de calidad se está probando?

Fase de prueba- Punto del ciclo de vida en el que se realiza.
pruebas

Tipo de prueba- una tarea específica de una prueba individual, generalmente asociada con una
parámetro de calidad

Parámetros de calidad

Existen patrones que permiten identificar problemas relacionados con la calidad (por regla general, casi todos los sistemas tienen el mismo tipo de problemas). En consecuencia, se debe evaluar lo siguiente para cada producto.

Fiabilidad

El software "resiste" la aparición de errores durante la ejecución: no hay fallos, congelaciones, pérdidas de memoria, etc.

Funcionalidad

El software implementa los casos de uso requeridos o tiene el comportamiento esperado.

yo productividad

El software y el sistema funcionan, responden rápidamente a eventos predeterminados y continúan funcionando de manera aceptable en condiciones operativas del mundo real (por ejemplo, carga pesada, períodos prolongados de operación, etc.). Las pruebas de rendimiento se centran en proporcionar la funcionalidad requerida y al mismo tiempo satisfacer los requisitos no funcionales del sistema.

Cada uno de los parámetros de calidad especificados requiere que se realicen una o más pruebas en una o más etapas de prueba. Además, existen otros parámetros de calidad cuya valoración puede ser más subjetiva: facilidad de uso, ampliabilidad, flexibilidad, etc. En cada oportunidad se debe realizar una evaluación cualitativa de estos parámetros de calidad.

Etapas de prueba

Las pruebas no deben considerarse una actividad separada realizada completamente a la vez. Las pruebas se llevan a cabo en diferentes etapas del desarrollo del software y tienen como objetivo verificar varios objetos (objetivos de prueba). Las etapas de las pruebas progresan desde probar pequeños elementos del sistema, como componentes (pruebas unitarias), hasta las pruebas. pruebas de sistemas completos (pruebas de sistemas). Enumeremos las etapas de prueba existentes y sus tareas.

Pruebas unitarias

Se prueban los elementos mínimos del sistema. El tiempo de prueba suele coincidir con el tiempo de implementación de los elementos.

Pruebas integrales

Se prueban unidades integradas (o componentes o subsistemas).

Pruebas del sistema

Se prueban las aplicaciones y sistemas completos (que constan de una o más aplicaciones).

Pruebas de aceptación

La aplicación (o sistema) completada es probada por los usuarios finales (o representantes de los usuarios finales). Propósito de la prueba: determinar la preparación para la implementación del producto.

Cabe recordar que en diferentes momentos del ciclo de vida, las etapas de prueba se llevan a cabo con diferentes énfasis. El prototipo inicial, utilizado en la fase de investigación para evaluar la viabilidad de la visión del producto, estará sujeto a varias pruebas de aceptación. El prototipo arquitectónico desarrollado durante la fase de refinamiento del plan estará sujeto a pruebas integrales y del sistema diseñadas para verificar la integridad arquitectónica y el rendimiento de los elementos arquitectónicos clave, aunque en este momento gran parte del código del sistema está en forma de programas sustitutos. Las etapas de prueba no son "fases" predefinidas que se ejecutan secuencialmente más cerca de fin proyecto; por el contrario, en un ciclo de vida iterativo, las pruebas comienzan temprano y ocurren con frecuencia.

tipos de pruebas

Hay muchos tipos de pruebas, cada una de las cuales se centra en un objetivo de prueba específico y prueba solo un aspecto de la calidad del software. Debido a que las pruebas ocurren durante todo el ciclo de vida, el software bajo prueba puede ser una sola pieza de código, una unidad integral o una aplicación (o sistema) completa. Nombramos los tipos de pruebas más comunes.

Prueba de certificación

Compara el desempeño de un objetivo de prueba y algún objeto estándar, como el software existente, o evalúa el desempeño de acuerdo con algún sistema de medidas.

Prueba de configuración

Comprueba el funcionamiento aceptable del objetivo de prueba bajo varias configuraciones (software o hardware).

Pruebas funcionales

Se comprueba el funcionamiento del objeto de prueba objetivo en general, es decir adecuada implementación de los precedentes requeridos.

Pruebas de instalación

Verifica que el destino de prueba esté instalado correctamente y que se pueda instalar correctamente en diferentes configuraciones o en diferentes condiciones (por ejemplo, espacio en disco insuficiente).

Pruebas de integridad

Se verifica la confiabilidad del objeto de prueba objetivo, su estabilidad y resistencia a errores durante la ejecución.

prueba de carga

Verifica que el rendimiento del objetivo de prueba sea aceptable en una variedad de condiciones operativas (incluido un número variable de usuarios, transacciones, etc.) con una configuración fija.

Pruebas de rendimiento

Verifica el rendimiento aceptable del objetivo de prueba en varias configuraciones mientras mantiene características operativas constantes.

Pruebas en modo difícil

Verifica el rendimiento aceptable del objetivo de prueba en condiciones críticas o de emergencia, como recursos limitados o una cantidad extremadamente grande de usuarios.

Pruebas de regresión

La prueba de regresión es una técnica de prueba en la que las pruebas realizadas previamente se vuelven a ejecutar en una nueva versión del objeto de destino. El objetivo de este tipo de prueba es garantizar que la calidad del objeto de destino no se deteriore (regrese) cuando se agreguen nuevas características a ese objeto. Las pruebas de regresión son necesarias para

Máxima detección temprana de defectos;

Comprobar que los cambios de código no introducen nuevos defectos o
restaurar los viejos.

Las pruebas de regresión pueden implicar ejecutar cualquier tipo de prueba una y otra vez. Normalmente, dichas pruebas se realizan en cada iteración y consisten en volver a ejecutar pruebas realizadas en iteraciones anteriores.

Modelo de prueba

Modelo de prueba- es una representación de lo que se probará y cómo se realizarán las pruebas. Este modelo es una representación de los modelos de diseño e implementación, que describe las pruebas reales y los parámetros objetivo relacionados con las pruebas. El modelo de prueba incluye un conjunto de tareas de control, procedimientos de prueba, escenarios de prueba y resultados de prueba esperados, así como una descripción de su relación.

Echemos un vistazo más de cerca a los componentes del modelo de prueba.

Tareas de control

Un conjunto de datos de prueba, condiciones de ejecución de pruebas y resultados esperados desarrollados para una tarea de prueba específica. Las tareas de control pueden determinarse a partir de precedentes, documentación de diseño o código de programa. La tarea de control se puede implementar utilizando uno o más métodos de prueba.

Métodos de prueba

Un conjunto de instrucciones detalladas para configurar y realizar tareas de control y evaluar los resultados obtenidos. Con un método de prueba se pueden implementar una o varias tareas de control. También se puede utilizar una metodología de prueba para implementar solo una parte de una tarea de prueba, como un flujo de caso de uso alternativo.

Escenarios de prueba

Instrucciones que automatizan la implementación de parte o la totalidad de un procedimiento de prueba (o procedimientos de prueba).

Clases de prueba y componentes.

Clases y componentes que implementan proyectos de prueba, incluidos controladores y programas sustitutos.

Interacciones de prueba

Las interacciones se representan en forma de diagrama de interacción o diagrama de secuencia y reflejan el flujo de mensajes ordenado en el tiempo entre los componentes de la prueba y el objetivo de la prueba que ocurre durante la prueba.

Notas

Información de texto que describe restricciones o información adicional utilizada en el modelo de prueba. Se pueden adjuntar notas a cualquier elemento del modelo de prueba.

Los principales elementos del modelo de prueba y sus relaciones se muestran en la Fig. 12.1.

Arroz. 12.1. Tareas de prueba, métodos de prueba y escenarios de prueba para un cajero automático.

Artistas y artefactos

Dos actores principales están involucrados en el proceso de prueba.

Desarrollador de pruebas responsable de planificar, desarrollar, implementar pruebas y
evaluación de pruebas. Sus responsabilidades incluyen la creación de un plan y modelo de prueba.
desarrollo, implementación de métodos de prueba y evaluación de la cobertura y resultados de las pruebas.
Tatuajes y pruebas de efectividad.

Ensayador Responsable de realizar pruebas del sistema. en su obligacion
incluye configurar y ejecutar pruebas, evaluar el rendimiento de las pruebas,
recuperación de errores, evaluación de resultados de pruebas y registro
defectos identificados.

Si se necesita un código específico para respaldar las pruebas (por ejemplo, se deben desarrollar controladores o programas sustitutos), entonces el proceso también debe involucrar a un desarrollador y diseñador en roles similares a los definidos en los Capítulos 10 y 11.

Los actores y artefactos del proceso de prueba se presentan en la Fig. 12.2. Veamos los artefactos clave de este proceso.

plan de prueba, que contiene información sobre las metas y objetivos de las pruebas.
El plan de prueba determina qué estrategias se utilizarán y cuáles
Se requieren recursos para realizar las pruebas.

Modelo de prueba descrito anteriormente.

Resultados de la prueba y datos recopilados durante la ejecución de la prueba.

Modelo de carga de trabajo para pruebas de desempeño; define
variables y sus valores utilizados en diversas operaciones
pruebas para modelar o simular las características de elementos externos.
intérpretes, funciones realizadas por los usuarios finales, volumen
estas funciones y la carga creada por estas funciones.

defectos, obtenidos como resultado de "pruebas fallidas" son uno de
tipos de solicitudes de cambio (consulte el Capítulo 13).

Además de los artefactos enumerados, se deben crear los siguientes artefactos al desarrollar soporte de software para una prueba.

Paquetes de prueba y clases.

Subsistemas y componentes de prueba.

La evaluación de la prueba final se utiliza como parte de la evaluación de la iteración del proyecto y de la evaluación periódica del estado (consulte el Capítulo 7, “Flujo de trabajo de gestión de proyectos”).

Proceso

Un proceso de prueba típico, sus elementos principales y las dependencias entre ellos se muestran en la Fig. 12.3.

Preparándose para la prueba

El propósito de este elemento de flujo de trabajo es definir y describir las pruebas que se realizarán. Para ello, se crea un plan de prueba que contiene requisitos y estrategias de prueba. Se puede desarrollar un plan de prueba único que describa todos los tipos de pruebas a realizar, o se puede crear un plan separado para cada tipo de prueba. La preparación de las pruebas se lleva a cabo de tal manera que las actividades de prueba sean mensurables y manejables.

Desarrollo de pruebas

El propósito de este elemento de flujo de trabajo es definir, describir y crear el modelo de prueba y sus artefactos asociados. Se crea un proyecto de prueba para garantizar que el software utilizado para las pruebas esté organizado adecuadamente y cumpla con los requisitos especificados. Durante este elemento del flujo de trabajo, el diseñador de pruebas analiza el objetivo de la prueba, desarrolla un modelo de prueba y (en el caso de pruebas de rendimiento) un modelo de carga de trabajo. El diseño de pruebas transforma los casos de uso en tareas de aceptación y control del sistema, que luego guían el diseño de los elementos de software que realizan las pruebas.

Implementación de prueba

El propósito de este elemento de proceso es implementar los procedimientos de prueba definidos en la sección Preparándose para la prueba. Los métodos de prueba se crean, por regla general, en un entorno de automatización de pruebas o en un entorno de programación. El artefacto resultante es una versión electrónica del procedimiento de prueba, denominada script de prueba.

Si se necesita un código específico para respaldar o realizar pruebas (por ejemplo, se deben desarrollar herramientas de prueba, controladores o programas sustitutos), entonces el desarrollador, diseñador y desarrollador de pruebas participan en el trabajo de su creación.

Ejecución de pruebas en la etapa de pruebas integrales.

El propósito de este elemento de flujo de trabajo es garantizar que los componentes del sistema se combinen correctamente y garantizar que la combinación se comporte correctamente. El integrador del sistema es responsable de compilar y combinar el sistema en bloques funcionales crecientes. Para cada uno de estos bloques, se prueban las funciones agregadas, se realizan pruebas de regresión y se recuperan los resultados de las pruebas.

Durante una iteración, se realizan pruebas integrales varias veces hasta que todo el sistema se integra exitosamente (determinado por el objetivo de la iteración).

Ejecución de pruebas durante la fase de prueba del sistema.

El objetivo de este elemento del proceso tecnológico es asegurar el correcto funcionamiento de todo el sistema. El integrador de sistemas compila e integra sistemas en unidades funcionales cada vez mayores. Cada elemento agregado

debe pasar pruebas de funcionalidad; además, se ejecutan todas las pruebas realizadas previamente a cada diseño (pruebas de regresión).

Durante una sola iteración, las pruebas del sistema se realizan varias veces hasta que todo el sistema se integra exitosamente (determinado por el objetivo de la iteración) y se cumplen los criterios de éxito de la prueba o de finalización del sistema.

Evaluación de prueba

El propósito de este elemento del proceso tecnológico es desarrollar y evaluar medidas de prueba cuantitativas que permitan determinar la calidad del objeto de prueba objetivo y el proceso de prueba. Esto se logra revisando y evaluando los resultados de las pruebas, identificando y registrando solicitudes de cambio y calculando medidas de prueba clave.

Apoyo instrumental

Debido a que las pruebas son un esfuerzo iterativo realizado a lo largo del ciclo de desarrollo, se necesita soporte de herramientas para garantizar que las pruebas comiencen temprano y se realicen con frecuencia; Las pruebas manuales no son lo suficientemente eficientes y no permiten evaluar exhaustivamente el software que se está desarrollando. Este último punto es especialmente cierto para las pruebas de rendimiento y carga, donde se debe simular la carga de trabajo y recopilar una cantidad significativa de datos.

Rational Software Corporation ofrece las siguientes herramientas para respaldar la automatización de pruebas y el proceso de prueba en general.

TestStudio es un conjunto de herramientas que soportan la ejecución de
realizar pruebas y evaluar los resultados de las mismas. Las herramientas TestStudio permiten
probador para crear scripts de prueba con interfaz gráfica
la cara del usuario. Estos escenarios se centran en tales parámetros.
cualidades como confiabilidad, función y rendimiento. Incluido en el conjunto
TestStudio incluye las siguientes herramientas.

Robot admite la ejecución de pruebas, lo que permite a los evaluadores crear y reproducir scripts de prueba con una interfaz gráfica de usuario y comparar los resultados obtenidos y los resultados esperados.

LogViewer captura los resultados de las pruebas y proporciona un informe para evaluar el rendimiento de las pruebas.

TestManager admite la planificación, el diseño y la evaluación de pruebas, le permite determinar la cobertura de las pruebas y genera informes de estado de las pruebas.

TestFactory admite pruebas de confiabilidad generando y ejecutando automáticamente scripts de prueba. Además, esta herramienta informa mediante programación la cobertura de las pruebas.

PerformanceStudio ejecuta scripts de prueba de usuario virtual
cuerpo, utilizando pruebas de rendimiento y algunas funciones
pruebas onales.

DevelopmentStudio admite el flujo de trabajo de prueba y
Incluye las siguientes herramientas.

Rational Purify para aislar errores de tiempo de ejecución difíciles de encontrar.

Rational PureCoverage* para identificar áreas de código que no superan las pruebas y realizar análisis de cobertura de código.

Rational Quantify* para identificar fragmentos de código que limitan el rendimiento.

Además, Rational Unified Process ofrece mentores de herramientas para la mayoría de estas herramientas.

Reanudar

Las pruebas le permiten evaluar la calidad del producto fabricado.

Las pruebas son un proceso iterativo que se realiza en todas las fases de la vida.
ciclo largo; te permite organizarte temprano contrarrestar comunicación sobre temas de calidad
va, utilizado para mejorar el producto durante su desarrollo y construcción.
nia. Las pruebas no sólo deben realizarse al final del ciclo de vida
(aceptar o rechazar el producto final); debe ser inseparable
una parte integral del mecanismo de retroalimentación constante.

Todos son responsables de la calidad. La calidad no puede ser introducida por el organismo de pruebas.
ción. Las pruebas tienen como único objetivo evaluar la calidad y organizar
retroalimentación oportuna para mejorar la calidad del sistema.

Ofrece un mecanismo de retroalimentación,
permitiendo medir la calidad e identificar los defectos. Pruebas realizadas
tiene lugar en las primeras etapas del proyecto: comienza con pruebas de planificación y algunas
segunda evaluación (a veces llevada a cabo incluso en la fase de investigación) y continuación
crece a medida que avanza el proyecto.

Anotación: Conceptos básicos de prueba. Fases y etapas de las pruebas. Tipos de pruebas. Desarrollo basado en pruebas

Introducción

Las pruebas son uno de los métodos más establecidos. seguro de calidad desarrollo de software.

Desde un punto de vista técnico En términos de pruebas, las pruebas consisten en ejecutar una aplicación sobre un determinado conjunto de datos fuente y comparar los resultados obtenidos con los previamente conocidos (de referencia) para establecer la conformidad de varias propiedades y características de la aplicación con las propiedades ordenadas. Como una de las fases principales del proceso de desarrollo de productos de software (diseño de aplicaciones - desarrollo de código - pruebas), las pruebas se caracterizan por una contribución bastante grande a la intensidad laboral total del desarrollo de productos. Una estimación ampliamente conocida de la distribución de la intensidad laboral entre las fases de creación de un producto de software es: 40% -20% -40%.

Desde un punto de vista matemático La prueba puede considerarse como la interpretación de una determinada fórmula y la prueba de su verdad en ciertos conjuntos. De hecho, un programa se puede representar como una fórmula f = f1* f2* f3*... * fn, donde f1, f 2, ... fn son operadores del lenguaje de programación y su superposición es un programa.

La veracidad de dicha fórmula se puede comprobar mediante un enfoque formal, es decir, las fórmulas y enunciados requeridos (teoremas) se derivan de las fórmulas axiomáticas originales utilizando procedimientos formales (reglas de inferencia). La ventaja del enfoque formal es que evita acceder a un rango infinito de valores y opera sólo con un conjunto finito de símbolos en cada paso de la prueba. Sin embargo, a menudo la construcción de un sistema formal y la formalización del programa en sí son procesos muy complejos. Un enfoque alternativo para justificar la verdad es la interpretación.

El enfoque interpretativo se utiliza cuando se sustituyen constantes en fórmulas y luego se interpretan las fórmulas como declaraciones significativas en los elementos de conjuntos de valores específicos. La veracidad de las fórmulas interpretadas se verifica en conjuntos finitos de valores posibles. La complejidad del enfoque es que a menudo el número de combinaciones de valores es muy grande y las combinaciones en sí constan de una gran cantidad de valores, lo que significa que procesar todas las combinaciones requerirá recursos importantes. Existen varios métodos para reducir el número de combinaciones que deben considerarse. Principal problema de prueba- determinar la suficiencia de un conjunto de pruebas para la veracidad de la conclusión sobre la exactitud de la implementación del programa, así como encontrar un conjunto de pruebas que tengan esta propiedad.

Pruebas estáticas El uso de métodos de análisis formal, sin ejecutar el programa bajo prueba, identifica construcciones incorrectas o relaciones incorrectas entre los objetos del programa (errores de tareas formales) utilizando herramientas especiales de monitoreo de código: CodeChecker.

Pruebas dinámicas(prueba en sí) identifica errores solo en un programa en ejecución utilizando herramientas especiales automatización de pruebas- Testbed o banco de pruebas.

Conceptos básicos de las pruebas

Clases de criterios de prueba

Criterios estructurales utilizar información sobre la estructura del programa (los llamados criterios del "cuadro blanco"), lo que presupone el conocimiento del texto fuente del programa o la especificación del programa en forma de un gráfico de control de flujo. Criterios estructurales se basan en los elementos principales del gráfico de control: operadores, ramas y rutas.

• Condición del criterio de prueba del comando (criterio C0): un conjunto de pruebas en total debe garantizar que cada comando se pase al menos una vez.
• La condición del criterio de prueba de rama (criterio C1) es que el conjunto de pruebas en conjunto debe garantizar que cada rama se pase al menos una vez.
• Condición del criterio para probar rutas (criterio C2): un conjunto de pruebas en total debe garantizar que cada ruta se pase al menos 1 vez.

Criterios funcionales se formulan en la descripción de los requisitos para el producto de software (los llamados criterios de "caja negra"). Proporcionan, en primer lugar, control sobre el grado de cumplimiento de los requisitos del cliente en el producto de software. Dado que los requisitos están formulados para el producto en su conjunto, reflejan la interacción de la aplicación bajo prueba con el medio ambiente. El problema de las pruebas funcionales es, ante todo, la intensidad del trabajo; El hecho es que los documentos que registran los requisitos de un producto de software son, por regla general, bastante voluminosos, sin embargo, la verificación correspondiente debe ser exhaustiva.

Se distinguen los siguientes tipos especiales: criterios funcionales:

• elementos de especificación de prueba;
• probar clases de datos de entrada;
• prueba de reglas: un conjunto de pruebas juntas debe garantizar la verificación de cada regla si los valores de entrada y salida se describen mediante un conjunto de reglas de alguna gramática;
• probar clases de salida;
• Pruebas de funcionamiento;
• Criterios combinados para programas y especificaciones. Criterios de prueba estocástica formulado en términos

comprobar la presencia de propiedades específicas en la aplicación bajo prueba, mediante la prueba de una determinada hipótesis estadística. Se utiliza cuando se prueban sistemas de software complejos, cuando un conjunto de pruebas deterministas (X, Y) tiene un poder enorme.

Criterios de mutación se centran en comprobar las propiedades de un producto de software basándose en el enfoque de Monte Carlo.

El método de prueba de mutaciones consiste en introducir mutaciones (pequeños errores) en el programa desarrollado P, es decir crear artificialmente programas mutantes P1, P2... . Luego, el programa P y sus mutantes se prueban en el mismo conjunto de pruebas (X, Y).

Si se confirma la exactitud del programa P en el conjunto (X, Y) y, además, se identifican todos los errores introducidos en los programas mutantes, entonces el conjunto de prueba (X, Y) corresponde al criterio de mutación y el programa bajo prueba se declara correcto. Si algunos mutantes no revelaron todas las mutaciones, entonces se debe ampliar el conjunto de pruebas (X, Y) y continuar con las pruebas.

Fases de prueba

Al realizar pruebas, suele haber tres fases: prueba unitaria, de integración y del sistema.

Pruebas unitarias- Se trata de probar un programa a nivel de módulos, funciones o clases individuales. El propósito de las pruebas unitarias es identificar errores localizados en el módulo al implementar algoritmos, así como determinar el grado de preparación del sistema para pasar al siguiente nivel de desarrollo y prueba. Las pruebas unitarias se llevan a cabo según el principio de "caja blanca", es decir, se basan en el conocimiento de la estructura interna del programa y, a menudo, incluyen ciertos métodos de análisis de cobertura de código.

Pruebas de integración está probando una parte de un sistema que consta de dos o más módulos. La tarea principal de las pruebas de integración es buscar defectos asociados con errores en la implementación e interpretación de la interacción de la interfaz entre módulos. La principal diferencia entre las pruebas unitarias y de integración son los objetivos, es decir, los tipos de defectos detectados, que, a su vez, determinan la estrategia para seleccionar los datos de entrada y los métodos de análisis.

Pruebas del sistema es cualitativamente diferente de los niveles de integración y modulares. Considera el sistema bajo prueba en su conjunto y opera a nivel de interfaces de usuario. Principal tarea de prueba del sistema consiste en identificar defectos asociados con el funcionamiento del sistema en su conjunto, como el uso incorrecto de los recursos del sistema, combinaciones no deseadas de datos a nivel de usuario, incompatibilidad con el medio ambiente, escenarios de uso no deseados, funcionalidad faltante o incorrecta, inconvenientes en el uso y similares.

Las pruebas del sistema se llevan a cabo en todo el proyecto utilizando el método de la "caja negra". La estructura del programa no importa; sólo las entradas y salidas visibles para el usuario están disponibles para prueba. Los códigos y la documentación del usuario están sujetos a pruebas.

Además, destacan prueba de regresión- un ciclo de prueba que se lleva a cabo cuando se realizan cambios durante la fase de prueba del sistema o de mantenimiento del producto. El principal problema de las pruebas de regresión es la elección entre total y parcial. volver a probar y reposición de kits de prueba. Con parcial volver a probar Sólo se monitorean aquellas partes del proyecto que están asociadas con componentes modificados.

Etapas de prueba

Cada fase de prueba incluye los siguientes pasos:

1. Establecer metas(requisitos de prueba), incluyendo la siguiente especificación: qué partes del sistema se probarán, qué aspectos de su funcionamiento se seleccionarán para verificación, cuál es la calidad deseada, etc.
2. Planificación: crear un cronograma (cronograma) para desarrollar pruebas para cada subsistema probado; evaluación de los recursos humanos, de software y de hardware necesarios; Desarrollo del cronograma del ciclo de pruebas. Es importante tener en cuenta que el cronograma de pruebas debe ser coherente con el cronograma de desarrollo del sistema que se está creando.
3. Desarrollo de pruebas(código de prueba para el sistema bajo prueba).
4. Ejecución de pruebas: implementación de ciclos de prueba.
5. Análisis de resultados.

ciclo de prueba Es un ciclo de ejecución de pruebas que incluye las fases 4 y 5 del proceso de prueba. El ciclo de prueba consiste en ejecutar las pruebas desarrolladas en alguna sección del sistema definida de forma única (estado del código del sistema que se está desarrollando). Normalmente, esta porción del sistema se llama construir.

plan de prueba- se trata de un documento, o un conjunto de documentos, que contiene recursos de prueba, una lista de funciones y subsistemas que se van a probar, estrategia de prueba, programar ciclos de prueba, fijar la configuración de la prueba (composición y parámetros específicos del entorno de hardware y software), definir una lista de métricas de prueba que deben recopilarse y analizarse durante el ciclo de prueba (por ejemplo, métricas que evalúan el grado de cobertura de un conjunto de requisitos mediante pruebas).

Las pruebas se desarrollan en base a especificaciones, tanto de forma manual como mediante herramientas automatizadas. Además del código en sí, el concepto de “prueba” incluye su descripción general y una descripción detallada de los pasos realizados en esta prueba.

Para evaluar la calidad de las pruebas, se utilizan varias métricas relacionadas con la cantidad de defectos encontrados, la cobertura del código, los requisitos funcionales y una variedad de escenarios.

Toda la información sobre los defectos detectados durante las pruebas (tipo, condiciones de detección, motivo, condiciones de corrección, tiempo dedicado a la corrección) se ingresan en la base de datos de defectos.

La información sobre el plan de prueba, las pruebas y los defectos se utiliza al final de cada ciclo de prueba para generar informe de prueba y ajustar el sistema de prueba para la siguiente iteración.

tipos de pruebas

El plan de prueba identifica y documenta varios tipos de pruebas.

Los tipos de pruebas por tipo de subsistema o producto son los siguientes:

1. Prueba de la funcionalidad principal, cuando se prueba el propio sistema, que es el principal producto fabricado.
2. Las pruebas de instalación incluyen pruebas de los scripts de instalación iniciales del sistema, scripts de reinstalación (sobre una copia existente), pruebas de desinstalación, pruebas de instalación en presencia de errores en el paquete instalado, en el entorno o en el script, etc.
3. La prueba de la documentación del usuario incluye verificar la integridad y claridad de la descripción de las reglas y características de uso del producto, la presencia de una descripción de todos los escenarios y funcionalidades, la sintaxis y gramática del idioma, la funcionalidad de ejemplos, etc.

Tipos de pruebas basadas en el método de selección de valores de entrada:

1. Pruebas funcionales, que comprueban:
   • cubrir requisitos funcionales;
   • Cobertura de casos de uso.
2. Pruebas de estrés, que prueban condiciones extremas de uso del producto.
3. Prueba de límites.
4. Pruebas de rendimiento.
5. Pruebas de cumplimiento de normas.
6. Pruebas de compatibilidad con otros sistemas de software y hardware.
7. Ensayos de trabajo con el medio ambiente.
8. Trabajo de prueba en una plataforma específica.

Desarrollo basado en pruebas

Consideremos un enfoque de prueba ligeramente diferente al anterior. Test Driven Development (TDD) es un proceso de desarrollo de software que implica escribir y automatizar pruebas unitarias antes de que se escriban las clases o módulos correspondientes. Esto garantiza que todas las responsabilidades de cualquier pieza de software estén definidas incluso antes de codificarlas.

TDD especifica el siguiente orden de pasos de programación:

• Rojo: escribe una pequeña prueba que no funciona y tal vez ni siquiera se compila.
• Verde: haga que la prueba se ejecute lo más rápido posible, sin preocuparse por la corrección del diseño y la limpieza del código. Escriba el código suficiente para que la prueba funcione.
• Refactorización: elimine cualquier duplicación del código que escriba.
• Una vez que los desarrolladores dominan TDD, descubren que escriben muchas más pruebas que antes y avanzan en pequeños pasos que antes podrían haber parecido inútiles.

Una vez que el programador ha realizado una prueba y puede estar seguro de que esa parte de la funcionalidad está cubierta, realiza una segunda ejecución de prueba, luego una tercera, luego una cuarta, etc. Cuanto más complejo sea el problema al que se enfrenta el programador, menor será el área de prueba. funcionalidad que debe cubrir cada prueba. El resultado es una cobertura del código del 100% con pruebas unitarias, lo que, por regla general, no se puede lograr con el enfoque clásico de pruebas.

Definitivamente hay problemas que no pueden (al menos por el momento) resolverse únicamente con pruebas. En particular, TDD no permite la demostración mecánica de la idoneidad del código desarrollado en las áreas de seguridad de datos e interacción entre procesos. Por supuesto, la seguridad se basa en un código que debe estar libre de defectos, pero también se basa en la participación humana en los procedimientos de protección de datos. Los sutiles problemas que surgen en el área de comunicación entre procesos no se pueden reproducir con certeza simplemente ejecutando algún código.

Resultados

Cuanto más activamente se desarrollan otros nuevos sistemas de información A medida que las arquitecturas se vuelven más complejas y se desarrollan nuevas tecnologías, el proceso de prueba se vuelve más importante. Cada vez están surgiendo más aplicaciones móviles y basadas en la web. Probar estos sistemas es mucho más difícil que los programas de un solo usuario para PC domésticos. Este tipo de sistemas requieren algoritmos de automatización de pruebas eficientes. Además, es relevante la tarea de comprobar la seguridad de los sistemas de información en todas sus manifestaciones. La industria de los videojuegos también necesita nuevos enfoques para las pruebas.

Las pruebas acompañan casi todo el proceso de desarrollo, incluidas las primeras etapas. Aún se necesitan mejoras en la tecnología para probar especificaciones y requisitos. La tarea actual es desarrollar pruebas que prueben el proceso de desarrollo, los requisitos comerciales y los objetivos de toda la organización. Estamos hablando de desarrollar pruebas más efectivas que cubran una amplia variedad de características del sistema de información.

Además, se continúa la investigación en el campo de las pruebas enfocadas a un modelo de desarrollo específico (cascada, espiral) o un paradigma de programación específico. Por ejemplo, se proponen pruebas basadas en agentes para probar sistemas orientados a componentes. Para probar subprogramas de Java activos, se propone utilizar redes neuronales. Para probar los agentes que existen en la web (robots, arañas), se propone utilizar sistemas basados ​​en el conocimiento.

Así, a pesar de la gran seguridad del proceso de prueba y de la completa automatización de muchas de sus etapas, todavía quedan muchas áreas de investigación y trabajo práctico.

El enfoque tradicional para las pruebas automatizadas se parece a esto: un redactor de pruebas estudia el sistema bajo prueba y luego escribe manualmente cada script individual para probar el sistema bajo prueba. Alguien podría escribir aquí la orgullosa palabra “hecho a mano”, pero yo lo llamo “paja”. Esto se debe a que, por lo general, este enfoque para crear y escribir pruebas presenta dos problemas:

• La "paradoja de los pesticidas" descrita por Boris Beizer en 1990. Consiste en el hecho de que las pruebas son cada vez menos efectivas para detectar errores, ya que los errores para los que se escribieron estas pruebas ya han sido encontrados y corregidos. Si esto no sucede, entonces surgen serias dudas sobre el código escrito y los procesos de trabajo.
• Las pruebas son estáticas y difíciles de cambiar, mientras que el sistema bajo prueba tiende a evolucionar constantemente, adquirir nuevas funcionalidades y cambiar el comportamiento de los antiguos. Y las pruebas deben cambiarse cada vez que una funcionalidad cambia la apariencia del programa o su comportamiento. Y a medida que crece la complejidad de actualizar las pruebas, se vuelve cada vez más difícil justificar los enormes costos de mantener las pruebas.

Las pruebas basadas en modelos ignoran casi por completo estos problemas, ya que las pruebas se crean automáticamente a partir del modelo exacto de la aplicación. Esto simplifica enormemente tanto el soporte de los existentes como la generación de nuevos tests sumamente útiles y flexibles.

¿Qué es un modelo?

Un modelo es una descripción del sistema bajo prueba. Una especificación formal funcionará bien. El modelo debería ser mucho más simple que el sistema que se describe y de alguna manera ayudarnos a comprender y predecir el comportamiento del producto que se está probando.

Normalmente, se utiliza como modelo un gráfico de estados o algún tipo de máquina de estados finitos. Al mismo tiempo, el gráfico de estado se ha utilizado en las pruebas durante la tercera década para representar el software bajo prueba y el diseño de la prueba. Puedes leer más sobre esta técnica de diseño de pruebas. . O mejor aún, en una gran cantidad de libros sobre pruebas que se han publicado durante los últimos 25 años.

En resumen, se puede describir de la siguiente manera: el software bajo prueba comienza a funcionar en algún estado (“la página principal está abierta”), acepta algunas entradas del usuario (“mira fotos de gatitos”) y, dependiendo de esta entrada, se mueve a un nuevo estado (“ha aparecido un álbum con fotografías de gatitos”). Usamos modelos todo el tiempo para comprender el comportamiento del software con el que estamos trabajando (“Hmm... si estoy aquí y hago esto Este entonces estaré fuera allá"). Sí, en general, se puede considerar que todas las pruebas mueven el probador a través de varios estados del sistema y verifican que estos movimientos ocurren correctamente (lo que significa "correctamente" es un tema aparte, por lo que lo omitiremos por ahora) .

¿Qué son las pruebas basadas en modelos?

Es una idea bastante antigua utilizar modelos descritos formalmente para hacer que las pruebas de software sean más baratas y sencillas. Las pruebas basadas en modelos en sí mismas son una técnica de prueba "avanzada" a través de una "caja negra". Tiene una serie de ventajas respecto a los métodos tradicionales:

• Puedes comenzar a ensamblar el modelo incluso antes de que aparezcan las primeras líneas de código.
• El modelado implica un trabajo exhaustivo en la especificación y arquitectura del software que se está desarrollando, lo que, por regla general, permite deshacerse de problemas fundamentales y discrepancias triviales en las primeras etapas.
• El modelo contendrá información que se puede reutilizar para futuras necesidades de prueba, incluso si la especificación cambia.
• El modelo es mucho más fácil de mantener que un gran conjunto de pruebas dispares.

Y lo más importante, los modelos descritos formalmente en combinación con los rudimentos de la teoría de grafos ayudan a generar cientos de pruebas de manera fácil y sin esfuerzo.

Un fanático de Agile con ojos de águila podría exclamar "¡oye! ¡tenemos BDD y cubre los primeros tres puntos y también es una especificación!" Responderé "nada de eso; sus ejemplos se convertirán en una especificación normal sólo cuando el rey Shaka Zulu pueda considerarse una especificación para toda la humanidad".

Ahora dejemos de lado el debate y veamos cómo usar la teoría de grafos para extraer del modelo lo que necesitas para las pruebas.

Un breve programa educativo sobre teoría de grafos.

La teoría de grafos se originó en 1736 en la antigua ciudad prusiana de Köningsberg. La ciudad se encontraba en dos orillas del río y al mismo tiempo ocupaba un par de islas en medio de este mismo río. Los habitantes de esta ciudad, por ociosidad, intentaron descubrir cómo visitar los siete puentes sin cruzar uno dos veces. Lo decidimos en la práctica, durante los paseos y, en teoría, durante las reuniones en la cocina. Durante mucho tiempo nadie pudo probar ni refutar la posibilidad de la existencia de esta ruta, hasta que llegó el aburrido Euler y arruinó las vacaciones de la gente del pueblo.

A Euler se le ocurrió la idea de representar cada terreno como un vértice de un gráfico y los puentes como bordes del gráfico.

Y de repente quedó claro que la ruta requerida no existía. Y todo porque todos los vértices tienen un número impar de aristas. Después de todo, si la parte superior tiene un número par de bordes, entonces cada vez que un ciudadano ambulante ingresa a este terreno, puede salir de allí por un nuevo puente. Por lo tanto, resulta que no podrás caminar por todos los puentes sin cruzar un puente dos veces.

Desde entonces, un grafo en el que todos los vértices tienen un número par de aristas se llama “Gráfico Euleriano”. Y el recorrido completo de este grafo lleva el orgulloso nombre de “camino euleriano”.

Y después los habitantes de Koeningsberg tuvieron que buscarse otras diversiones. Sólo un matemático chino, Mei-Ku Kuan, siguió engañándose con estos puentes. Y le molestó la siguiente pregunta:

Si es imposible construir una ruta para que cada puente se cruce exactamente una vez, entonces ¿cuál es el número mínimo de cruces de puente adicionales que se deben realizar para completar el desvío?

Y esto ya es muy similar al problema que enfrentan los carteros. Digamos que cada vértice es un buzón donde hay que dejar letras. Y es que, digamos, nuestro cartero debe tirar cartas en cada casilla sin realizar movimientos innecesarios.

Kuan propuso considerar volver a cruzar un puente como agregar otro borde al gráfico. Agregar aristas debería dar como resultado que todos los vértices del gráfico tengan un número par de aristas. Este procedimiento suele denominarse "eulerianización" del grafo. Y después de "eulerianizar" el gráfico, podemos construir una ruta de Euler a lo largo de él.

Y en honor a Kuan, este problema se llamó "el problema del cartero chino".

Unos años más tarde, todavía había aburridos que se interesaban por lo que sucedería si fuera posible caminar a lo largo de los bordes del gráfico en una sola dirección. Este es exactamente el problema que surge, similar al dolor de cabeza de un taxista en Nueva York al construir una ruta por calles de sentido único.

Aquí presentamos otro término: dígrafo. O un gráfico dirigido. Este es un gráfico cuyos bordes solo se pueden cruzar en una dirección específica. Los bordes dirigidos también se denominan "arcos".

Y si en el caso del Camino de Euler o del Problema del Cartero Chino operamos con arcos tocando los vértices, aquí también hay que tener en cuenta la dirección del movimiento. Y requerimos la proporción de "eulerianización" de dicho gráfico para que el número de arcos que entran en un vértice sea igual al número de arcos que salen. Y contando cada arco entrante como “+1” y arco saliente como “-1” podemos calcular la “polaridad” de cada vértice del dígrafo. Por ejemplo, un vértice con dos arcos entrantes y uno saliente tiene la polaridad “2 - 1 = 1”.

Para Eulerizar un dígrafo, necesitamos dibujar arcos entre los vértices positivos y negativos. Necesitamos esta "igualación" del número de arcos entrantes y salientes por la misma razón por la que logramos un número par de aristas en un gráfico no dirigido: cualquier visitante de un vértice del gráfico debería poder salir de él.

¿Qué tienen que ver las pruebas con esto?

Supongamos que el evaluador tiene un modelo del comportamiento del sistema bajo prueba. Supongamos también que este modelo parece un dígrafo, donde los vértices representan el estado del sistema y los arcos son acciones que el evaluador puede realizar para cambiar el estado del sistema.

Lo primero que querrá hacer un evaluador es realizar todas las acciones posibles con el sistema bajo prueba. Pero, ¿cómo podemos hacer esto de manera efectiva? Entonces, a un probador experto se le ocurre un enigma sobre un taxista de Nueva York, que está ligeramente disfrazado. Y como ya tenemos un modelo del sistema bajo prueba en forma de gráfico, solo necesitamos aplicarle un algoritmo transversal adecuado, que se puede generar automáticamente.

Por otro lado, realizar todas las acciones posibles es bueno, pero incluso el administrador de pruebas más estrecho de miras comprende que se trata de una "cobertura estatal" banal en términos de pruebas de código sin formato. Pero los multiplicadores tienen una propiedad desagradable: por regla general, tienen muchos estados "siguientes" para cada vértice. ¿Qué debemos hacer si queremos probar todas las combinaciones posibles de acciones? Las soluciones a problemas como el problema del cartero chino no son adecuadas porque solo garantizan visitar cada arco, pero no visitar todas las combinaciones posibles de arcos.

Este enfoque se utilizó activamente para probar máquinas de estados finitos. Además, este requisito se desprende naturalmente de la técnica de diseño de pruebas combinatorias denominada "todos los pares".

Un tal De Bruijn propuso una solución. El algoritmo se parece a esto:

• Dibujamos un gráfico en el lateral, donde cada borde del gráfico original es un vértice.
• Donde en el gráfico original el arco "1" ingresa al vértice del cual sale el arco "2", dibujamos un arco en el gráfico recién creado desde el vértice "1" al vértice "2".
• Eulerizemos el gráfico resultante.
• Dibujemos un camino de Euler en este gráfico.

En principio, no puede molestarse y simplemente hacer un recorrido aleatorio del gráfico. Lo que es digno de mención es que esta estrategia es bastante resistente a la “paradoja de los pesticidas”. Por otro lado, cualquier aplicación más o menos compleja tiene un gráfico de estados bastante extenso, al que se puede dedicar mucho tiempo antes de obtener al menos algo de cobertura con un "paseo aleatorio".

Más adelante escribiré sobre por qué se agregan aquí las cadenas de Markov y cómo generalmente se resuelve la paralelización de tales pruebas. Por ahora, resumamos brevemente.

Total

Los modelos son una excelente manera de representar y pensar en la aplicación bajo prueba, pero también nos brindan una manera bastante simple de actualizar las pruebas y mantenernos al día con una aplicación en constante evolución.

Podemos considerar las pruebas de aplicaciones como atravesar un gráfico creado en función del modelo de aplicación. A su vez, la Teoría de Grafos proporciona herramientas suficientes para utilizar información sobre el comportamiento del sistema descrito en el modelo para generar nuevas pruebas brillantes.

Y, dado que la Teoría de Grafos nos permite trabajar directamente con el modelo:

• Se pueden generar nuevos recorridos automáticamente cuando cambia el modelo.
• Nuestras pruebas pueden cambiar fácil y naturalmente dentro del mismo modelo.
• Diferentes algoritmos transversales pueden satisfacer diferentes necesidades de prueba.
• Los algoritmos de derivación resultantes se pueden reutilizar fácilmente en un entorno completamente nuevo.