<100% Cobertura de prueba: mejores prácticas en la selección de áreas de prueba

Question

Supongamos que está trabajando en un proyecto y el presupuesto de tiempo/dinero no permite una cobertura del 100% de todos los códigos/rutas.

De esto se deduce que es necesario probar algunos subconjuntos críticos de su código. Claramente, se puede usar un enfoque de "control de tripas" para probar el sistema, donde la intuición y el análisis manual pueden producir algún tipo de cobertura de prueba que será "aceptable".

Sin embargo, supongo que existen mejores prácticas/enfoques/procesos que identifican elementos críticos hasta cierto umbral y le permiten enfocar sus elementos de prueba en esos bloques.

Por ejemplo, un proceso popular para identificar fallas en la fabricación es Modo de falla y análisis de efectos. Estoy buscando un proceso (s) para identificar bloques de prueba críticos en el software.

Answer 1

La cobertura del código del 100% no es un objetivo deseable. Ver this blog por algunas razones.

Mi mejor práctica es derivar casos de prueba de casos de uso. Cree una trazabilidad concreta (utilizo una herramienta UML pero también una hoja de cálculo) entre los casos de uso que se supone que su sistema debe implementar y los casos de prueba que prueban que funciona.

Identifique explícitamente los casos de uso más críticos. Ahora mira los casos de prueba que rastrean. ¿Tiene muchos casos de prueba para los casos de uso crítico? ¿Cubren todos los aspectos del caso de uso? ¿Cubren los casos negativos y de excepción?

He encontrado que es la mejor fórmula (y el mejor uso del tiempo del equipo) para garantizar una buena cobertura.

EDIT:

simple, ejemplo artificioso de por qué el 100% de cobertura de código no garantiza que la prueba del 100% de los casos. Say CriticalProcess() se supone que llama a AppendFile() para anexar texto, pero en su lugar llama a WriteFile() para sobrescribir el texto.

[UnitTest] 
Cover100Percent() 
{ 
    CriticalProcess(true, false); 
    Assert(FileContents("TestFile.txt") == "A is true"); 

    CriticalProcess(false, true); 
    Assert(FileContents("TestFile.txt") == "B is true"); 

    // You could leave out this test, have 100% code coverage, and not know 
    // the app is broken. 
    CriticalProcess(true, true); 
    Assert(FileContents("TestFile.txt") == "A is trueB is true"); 
} 

void CriticalProcess(bool a, bool b) 
{ 
    if (a) 
    { 
     WriteFile("TestFile.txt", "A is true"); 
    } 

    if (b) 
    { 
     WriteFile("TestFile.txt", "B is true"); 
    } 
} 

Answer 2

A menos que esté haciendo un desarrollo completamente nuevo usando TDD, es poco probable que obtenga (o desee) una cobertura de prueba del 100%. La cobertura del código es más una guía, algo para preguntar "¿qué no he probado?"

Es posible que desee consultar otras métricas, como cyclomatic complexity. Encuentre las áreas complejas de su código y pruébelo (luego refactorice para simplificar).

Answer 3

Depende completamente del tipo de software que esté desarrollando. Si se puede acceder de forma remota, la prueba de seguridad debe ser la prioridad más alta. En el caso de las aplicaciones web, existen pruebas automatizadas, como Sitewatch o Wapiti, que se pueden utilizar. También hay herramientas para ayudar a generar pruebas unitarias para SOAP.

Answer 4

Hay 3 componentes principales que debe tener en cuenta:

• características importantes - debe saber lo que es más crítico. Pregúntate a ti mismo "¿Qué tan atornillado sería yo (o mi cliente) si hay un error en este componente/fragmento de código?". Su cliente probablemente podría ayudarlo a determinar este tipo de prioridades. Las cosas que tratan directamente con el dinero tienden a seguir en este caso
• funciones de uso frecuente - Los casos de uso más comunes deben estar lo más libres de errores posible.A nadie le importa si hay un error en una parte del sistema que nadie usa
• características más complejas - Los desarrolladores generalmente tienen una buena idea de qué partes del código son más propensas a contener errores. Debes prestar especial atención a esos.

Si usted tiene esta información, entonces probablemente no será difícil elegir cómo distribuir los recursos de prueba.

Answer 5

Falso sentido de seguridad: Siempre debe tener en cuenta que la cobertura de las pruebas puede llevar a una falsa sensación de seguridad. Un gran artículo sobre este hecho se puede encontrar en the disco blog. Dicho esto, confiar en la información de los indicadores "verdes" le permite pasar por alto las rutas no probadas.

buen indicador para caminos no probados: Por otra parte faltante cobertura de la prueba la mayoría de veces que se muestran en rojo siempre es un gran indicador de caminos que no están cubiertos. Puede verificar estos primero porque son fáciles de detectar y le permiten evaluar si desea agregar cobertura de prueba aquí o no.

Enfoque centrado en el código para identificar elementos críticos: Existe un gran soporte de herramientas disponible para ayudarlo a encontrar el desorden y posibles errores en su código. Es posible que desee echar un vistazo a IntelliJ IDE y sus funciones de análisis de código o, por ejemplo, en Findbugs, Checkstyle y PMD. Una gran herramienta que combina estas herramientas de análisis estático de código que está disponible de forma gratuita es Sonar.

Aproximación centrada en la característica para identificar elementos críticos: Evalúe su software y desglose en características. Hágase preguntas como: "¿Qué características son las más importantes y debería ser más confiable ¿Dónde tenemos que cuidar de la exactitud de los resultados Cuando se trata de un error o fallo sea más destructivo para el software???"

Answer 6

Tal vez el mejor indicio de que un módulo está cubierto insuficientemente es informes de fallos en contra de ella. Cualquier módulo que edite una y otra vez debe estar bien cubierto. Pero la complejidad ciclomática se correlaciona bastante bien con la frecuencia de errores, también - y se puede medir ese antes los errores aparecen!

Answer 7

Si usted tiene una base de código legado, un buen lugar para comenzar es:

• Añadir una prueba de unidad por cada error que encontrar y corregir. La unidad de prueba debe reproducir el error, entonces corregir el código, y el uso de la prueba de la unidad para verificar que se fija, y después para asegurarse de que en el futuro no se rompe de nuevo por cualquier razón.

• Siempre que sea posible, agregue pruebas a los principales componentes de alto nivel para que muchas fallas de bajo nivel causen una falla en la prueba unitaria (por ejemplo, en lugar de probar cada rutina de acceso de la base de datos de forma independiente, agregue una prueba 100 usuarios, elimina 50 de ellos, verifica el resultado, y las gotas de la base de datos. no verá fácilmente donde el fracaso es (que tendrá que depuración de averiguar por qué fracasó) pero al menos sabes que vas realice una prueba que ejercite el sistema general de la base de datos y le avisará rápidamente si algo importante falla en esa área del código. Una vez que cubra las áreas de mayor nivel, puede preocuparse por profundizar.

• Ad d unidad de pruebas para su nuevo código, o cuando modifica cualquier código.

Con el tiempo, esto en sí mismo lo ayudará a aumentar la cobertura en los lugares más importantes.

(Tenga en cuenta que si su código base está funcionando código que ha estado funcionando durante años, entonces la mayoría de las veces no "necesita" pruebas unitarias para probar que funciona. Si solo agrega pruebas unitarias a todo , por supuesto, con el tiempo a medida que crece su cobertura, puede comenzar a detectar regresiones a partir de esas pruebas, y encontrará errores a través del proceso de agregar pruebas unitarias para las pruebas anteriores. código no probado, pero si lo que sudar tinta a través de la adición de código ciegamente pruebas de unidad para todo, obtendrá un muy pobre costo por insecto-fija ratio)

Answer 8

a todo el comprobador de cobertura del 90%:

El problema al hacerlo, el código del 10% difícil de probar es también el código no trivial que contiene el 90% del error. Esta es la conclusión que obtuve empíricamente después de muchos años de TDD.

Y después de todo esto es una conclusión bastante directa. Este 10% de código difícil de probar, es difícil de probar porque refleja un problema de negocios engañoso o un defecto de diseño complicado o ambos. Estas razones exactas que a menudo conducen a un código defectuoso.

Pero también:

• 100% código cubierto que disminuye con el tiempo a menos de 100% cubierto menudo señala un fallo, o al menos un defecto.
• Código 100% cubierto que se usa junto con contratos, es el arma definitiva para llevar a vivir cerca del código libre de errores. Code Contracts and Automated Testing are pretty much the same thing
• Cuando se descubre un error en el código cubierto al 100%, es más fácil de arreglar. Dado que el código responsable del error ya está cubierto por las pruebas, no debería ser difícil escribir nuevas pruebas para cubrir la corrección de errores.