2010-06-01 13 views

Respuesta

14

Pregunta extraña: la prueba unitaria se supone que es automática, por lo tanto repetible y fácil de ejecutar. Para muchos (incluido yo) "prueba de unidad manual" es una contradicción en los términos.

Las pruebas manuales pueden ser útiles en los casos en que no se pueden realizar pruebas automatizadas. Estos generalmente no están en el nivel de prueba de la unidad, pero son más altos, p. pruebas de integración, GUI, estrés, etc.

Con pruebas unitarias, está probando pequeñas partes de su código (típicamente métodos/clases individuales) a la vez. Las pruebas están escritas en código, por lo que pueden (casi siempre) ejecutarse automáticamente mediante un marco de prueba de unidades.

Actualización: ahora que le da un contexto más concreta a su pregunta, es más fácil dar una respuesta concreta :-)

Estoy convencido de que decir que las pruebas unitarias automatizadas casi siempre hay que pagar por sí mismos muchas veces durante la vida de un proyecto SW. Configurarlos es más costoso que las pruebas manuales, pero cuanto más los ejecute, más tiempo ahorrará, y más retroalimentación obtendrá sobre dónde se rompe el código con los nuevos cambios.

Cubrir el código heredado con pruebas unitarias definitivamente no es fácil, pero si el producto es valioso para su empresa y se espera que continúe durante años, sigue siendo un esfuerzo digno. Sobre todo porque en la vida real, un sistema de producción tiende a sobrevivir a su vida esperada.

Un aspecto es que "intenta verificar todas las rutas de código que hemos escrito" - con pruebas automatizadas de unidades combinadas con una herramienta de cobertura de código, puede ver automágicamente - a menudo dentro de su IDE, si la herramienta de cobertura es bien integrado: qué rutas de código no están cubiertas por las últimas pruebas unitarias.

Recomiendo Working Effectively with Legacy Code - contiene una gran cantidad de valiosos conocimientos sobre cómo escribir pruebas unitarias para código legado enmarañado y mal escrito.

+3

+1 Las pruebas unitarias son automáticas por definición. –

+0

Sí claro, En nuestro caso, tenemos una aplicación grande donde utilizaremos UT automatizada. Actualmente preparamos nuestros datos de prueba mauaaly e intentamos verificar todas las rutas de código que hemos escrito. Para eso, necesitamos hacer un análisis de comparación, ya sea que la automatización nos ayude a largo plazo o no. – Debajyoti

+0

Entonces, si hago esto manualmente, entonces estoy perdiendo el tiempo. Puedo hacer esto fácilmente mediante alguna herramienta UT como VS test o Pex. – Debajyoti

1

Creo que la única respuesta real a su pregunta es , no importa, porque tiene que tener ambos.

Las pruebas unitarias automatizadas permitirán a los desarrolladores codificar las pruebas que validan automáticamente el código de acuerdo con su comprensión de las especificaciones. Como están automatizados, se pueden ejecutar una y otra vez con poca o ninguna variación cada vez. Por definición, estas pruebas unitarias sabrán cómo funciona el software, bajo la cubierta, y como tal puede considerarse como prueba de caja blanca - las pruebas son conscientes de algunos, si no todos, del código subyacente.

Las pruebas manuales, por otro lado, revelarán problemas desde el punto de vista de los usuarios. Tendrá la capacidad de descubrir qué errores pueden encontrar las entidades que no están familiarizadas con el código y la estructura subyacentes, así como también si hay problemas con respecto a la usabilidad de su programa. Esto se considera prueba de caja negra.

+0

Gracias Jon. Esto me ayudara mucho. – Debajyoti

4

"Prueba de unidad manual" es prácticamente imposible. Las pruebas unitarias se definen como pruebas de pequeñas unidades de código de forma aislada. Realmente no puedes hacer eso manualmente.

Ahora, si usted está hablando de pruebas de integración, eso es un asunto diferente:

pruebas de integración manual Pro:

  • probadores son más baratos que los desarrolladores
  • probadores pueden ajustar de forma inteligente la pruebas de los cambios en la aplicación: no son tan frágiles inherentemente como las pruebas automatizadas
  • Los probadores pueden detectar errores que una prueba automatizada podría pasar por alto (como missi) ng o valores incorrectos que no se han probado explícitamente, o problemas de diseño)
  • No requiere software de prueba adicional que puede ser costoso y/o requiere mucho tiempo para aprender
  • Siempre posible; no hay requisitos técnicos que debe cumplir
  • Puede simplemente comenzar; los costos iniciales para hacer una prueba única son mucho menores que para configurar e implementar una prueba automatizada.

de Con las pruebas de integración manual:

  • usted tiene que pagar un ser humano cada vez que los haces. A la larga, eso es muy, muy caro.
  • La prueba de regresión completa después de las correcciones de errores es básicamente imposible (demasiado costosa).
  • Esto significa que tiene que ser muy conservador con los cambios al final del ciclo de desarrollo y los grandes cambios en general. Sin refactorización constante: mejor vivir con código incorrecto que riesgos de efectos secundarios catastróficos.
  • Tienes que planificar con mucho cuidado cuando harás las pruebas para obtener la máxima relación calidad-precio. Hasta cierto punto, tendrá que ajustar sus prácticas de desarrollo para reflejar eso.

Con todo, lo mejor es tener ambos pruebas de integración manuales y automatizados; a veces se pueden complementar mutuamente, ya que algunas cosas pueden, de hecho, ser más fáciles de probar de forma automática, mientras que otras no se pueden automatizar en absoluto.

Cuestiones relacionadas