tipos tecnicas software sistema seguridad pruebas niveles negra integracion funcionales ejemplos caja testing tdd scrum

testing - tecnicas - The Agile Way: ¿Pruebas de integración frente a pruebas funcionales o ambas?



tecnicas de pruebas de software (10)

Deberías hacer todos ellos porque la unidad, la integración y las pruebas funcionales sirven para diferentes propósitos.
Me parece que un punto importante es que la prueba de escritura es muy importante y TDD no es suficiente, el BDD (desarrollo impulsado por el comportamiento) ofrece un buen enfoque ...

Trabajo en una oficina que hace Agile desde hace un tiempo. Utilizamos Scrum para la gestión de proyectos y combinamos las prácticas de ingeniería de XP. Funciona bien y constantemente estamos aprendiendo lecciones y refinando nuestro proceso.

Me gustaría informarle acerca de nuestras prácticas habituales para realizar pruebas y obtener comentarios sobre cómo podría mejorarse esto:

TDD: Primera línea de defensa Somos bastante religiosos sobre las pruebas unitarias y diría que nuestros desarrolladores también tienen la experiencia suficiente para escribir pruebas exhaustivas y aislar siempre el SUT con burlas.

Pruebas de integración Para nuestro uso, las pruebas de integración son básicamente las mismas que las pruebas unitarias simplemente sin usar los simulacros. Esto tiende a detectar algunos problemas que pasaron por las pruebas unitarias. Estas pruebas tienden a ser difíciles de leer, ya que generalmente implican mucho o trabajan en las secciones before_each y after_each del marco de especificaciones, ya que el sistema debe alcanzar a menudo un cierto estado para que las pruebas sean significativas.

Pruebas funcionales Usualmente hacemos esto de una manera estructurada, pero manual. Hemos jugado con Selenium y Windmill, que son geniales, pero para nosotros al menos todavía no están completos.

Me gustaría escuchar cómo alguien más está haciendo cosas. ¿Crees que si las pruebas de integración o las pruebas funcionales se llevan a cabo lo suficientemente bien, el otro puede descartarse?

Diría (y esto es solo una cuestión de opinión) que sus pruebas funcionales son sus verdaderas pruebas. Es decir, esas pruebas que realmente simulan el uso real de su aplicación. Por esta razón, nunca te deshagas de ellos, pase lo que pase.

Parece que tienes un sistema decente funcionando. Consérvelo todo si no tienes nada que perder.

En mi cliente actual, realmente no nos separamos entre pruebas unitarias y pruebas de integración. Las entidades comerciales son tan dependientes de la capa de datos subyacente (utilizando un marco ORM propio) que, en efecto, tenemos pocas o verdaderas pruebas unitarias.

El servidor de compilación está configurado con integración continua (CI) en Team Build y para evitar que se atasque demasiado con pruebas lentas (el conjunto de pruebas completo tarda más de una hora en ejecutarse en el servidor) hemos separado las pruebas en "lento" pruebas que se ejecutan dos veces al día y pruebas "rápidas" que se ejecutan como parte de una integración continua. Al establecer un atributo en el método de prueba, el servidor de compilación puede distinguir entre los dos.

En general, las pruebas "lentas" son aquellas que necesitan acceso a datos, uso de servicios web o similares. Estas se considerarían pruebas de integración o pruebas funcionales por convención común. Algunos ejemplos son: pruebas CRUD, pruebas de reglas de validación comercial que necesitan un conjunto de objetos para trabajar, etc.

Las pruebas "rápidas" son más parecidas a las pruebas unitarias, donde puede aislar razonablemente el estado y el comportamiento de un solo objeto para la prueba.

Considero que cualquier prueba que se ejecute en décimas de segundo o menos es "rápida". Cualquier otra cosa es lenta y probablemente no debería ejecutarse como parte de CI.

Estoy de acuerdo en que no debes preocuparte demasiado por el "sabor" de la prueba que usas como parte del desarrollo (expresando los criterios de aceptación, ya que las pruebas son la excepción, por supuesto). El desarrollador individual debe usar su criterio para decidir qué tipo de pruebas se adaptan mejor a su código. Insistir en pruebas unitarias para una entidad comercial podría no revelar las fallas de una prueba CRUD, y así sucesivamente ...

Hemos experimentado que un conjunto sólido de pruebas de selenio realmente resume lo que el cliente espera de la calidad realmente bien. Así que, en esencia, hemos tenido esta discusión: si escribir pruebas de selenio fuera tan fácil como escribir pruebas unitarias, deberíamos centrarnos menos en las pruebas unitarias.

Y si hay un error en alguna parte que no tiene ninguna consecuencia en la aplicación, ¿a quién le importa realmente? Pero siempre están los problemas que rodean las complejidades de la vida real; ¿Estás seguro de que tus pruebas funcionales están capturando los escenarios correctos? Puede haber complejidades subyacentes causadas por otros sistemas que no son directamente visibles en el comportamiento de la aplicación.

En realidad, escribir pruebas de selenio (usando un lenguaje de programación apropiado, no selenese) se vuelve realmente simple y divertido una vez que exploras los problemas iniciales. Pero aún no estamos dispuestos a renunciar a nuestras pruebas unitarias ...

La unidad, la integración y las pruebas funcionales, aunque ejercen el mismo código, lo están atacando desde diferentes perspectivas. Son esas perspectivas las que marcan la diferencia, si dejaras caer un tipo de prueba entonces algo podría funcionar desde ese ángulo.

Además, las pruebas unitarias no se tratan realmente de probar tu código, especialmente si estás practicando TDD. El proceso de TDD te ayuda a diseñar mejor tu código , solo obtienes la ventaja adicional de un conjunto de pruebas al final.

No ha mencionado si tiene un servidor de integración continua ejecutándose. Recomiendo encarecidamente configurar uno ( Hudson es fácil de configurar). Entonces puede hacer que su integración y pruebas funcionales corran contra cada check in del código.

Las pruebas unitarias, las pruebas de integración y las pruebas funcionales sirven para diferentes propósitos. No debe descartar uno solo porque los demás se ejecutan con un alto nivel de confiabilidad.

Mi empresa realiza pruebas funcionales pero no unidades o pruebas de integración. Estoy tratando de alentarlos a adoptarlos, los veo como un mejor diseño y una indicación más rápida de que todo está bien. ¿Necesita pruebas unitarias si realiza pruebas funcionales?

Tiendo a no separar varios sabores de prueba en TDD. Para mí, TDD es desarrollo basado en pruebas, no desarrollo basado en pruebas unitarias. Entonces mi práctica de TDD combina pruebas unitarias, pruebas de integración, pruebas funcionales y de aceptación. Esto hace que algunos componentes sean cubiertos por ciertos tipos de pruebas y que otros componentes sean cubiertos por otros tipos de pruebas de una manera muy pragmática.

Hice una question sobre la relevancia de esta práctica y la respuesta corta fue que, en la práctica, la separación se realiza entre las pruebas rápidas / simples que se ejecutan automáticamente en cada compilación y las pruebas lentas / complejas que se ejecutan con menos frecuencia.

Yo comparo las pruebas unitarias como asegurarse de que las palabras en un párrafo estén escritas correctamente. Las pruebas funcionales son como asegurarse de que el párrafo tenga sentido y fluya dentro del documento en el que se encuentra.