¿Qué métodos de prueba usa para desarrollar sitios web?

Question

Hay una gran cantidad de métodos de prueba por ahí decir blackbox, graybox, unit, functional, etc. regression

Obviamente, un proyecto no puede asumir todos los métodos de prueba. Así que hice esta pregunta para tener una idea de qué métodos de prueba usar y por qué debería usarlos. Puede responder en el siguiente formato:

Método de prueba - lo que lo utilizan en

por ejemplo,

1. Unidad de Pruebas - Yo lo uso para ... (bla, bla)
2. pruebas de regresión - Yo lo uso para ... (bla, bla)

me pidieron para participar en TDD y, por supuesto, tuve que investigar los métodos de prueba. Pero hay una plétora de ellos y no sé qué usar (porque todos suenan útiles).

Answer 1

1. Unit Testing es utilizado por los desarrolladores para garantizar que el código de unidad que escribió sea el correcto. Por lo general, se trata de pruebas de caja blanca y de cierto nivel de pruebas de caja negra.

2. Pruebas de Regresión es una prueba funcional utilizada por los probadores para garantizar que los nuevos cambios en el sistema no ha roto ninguna de las funcionalidades existentes

3. Las pruebas funcionales se Pruebas realizadas en un sistema completo e integrado para evaluar el cumplimiento del sistema con sus requisitos especificados. Las pruebas de funcionalidad entran dentro del alcance de las pruebas de caja negra, y como tal, no requieren conocimiento del diseño interno del código o la lógica

.

Estos Test-driven development y Feature Driven Development artículos wiki serán de gran ayuda para usted.

para TDD es necesario seguir siguiente proceso:

1. función de documento (o caso de uso) que es necesario implementar o mejorar en su aplicación que Actualmente no existe.
2. Conjunto de escritura de prueba funcional casos que pueden garantizar la función anterior de (desde el paso 1) funciona. Es posible que necesite escribir varios casos de prueba para la característica anterior para probar todos los posibles flujos de trabajo de .
3. Escribir código para implementar la función anterior (desde el paso 1).
4. Pruebe este código utilizando los casos de prueba que había escrito antes (en el paso 2). La prueba real
   puede ser manual, pero recomendaría crear pruebas automáticas si es posible.
5. Si pasan todos los casos de prueba, es bueno que vaya. De lo contrario, debe actualizar el código (vuelva al paso 3) para que la prueba pase.

TDD es garantizar que los casos de prueba funcionales que se escribieron antes de codificar deberían funcionar y no importa cómo se implementó el código.

Answer 2

No hay "correcto" o "incorrecto" en las pruebas. Las pruebas son un arte y lo que debe elegir y qué tan bien funciona para usted depende mucho de un proyecto a otro y de su experiencia.

Pero como experto profesional en pruebas mi sugerencia es que tenga una combinación saludable de pruebas automáticas y manuales.

(Los ejemplos siguientes son en PHP, pero se puede encontrar fácilmente los ejemplos correctos para lo que cada vez Langauge/marco que está utilizando)

de prueba automatizada de

• pruebas unitarias
  Uso PHPUnit para probar tus clases, funciones e interacción entre ellos.
  http://phpunit.sourceforge.net/

• de prueba automatizada funcional
  Si es posible se debe automatizar muchas de las pruebas funcionales. Algunos trabajos de marcos tienen pruebas funcionales integradas. De lo contrario, debe usar una herramienta para ello. Si está desarrollando sitios web/aplicaciones, es posible que desee consultar Selenium.
  http://www.webinade.com/web-development/functional-testing-in-php-using-selenium-ide

• integración continua
  Uso CI para asegurarse de que todas sus pruebas automatizadas se ejecuten cada vez que alguien en su equipo hace un commit al proyecto.
  http://martinfowler.com/articles/continuousIntegration.html

pruebas manuales
Por mucho que me encanta de prueba automatizada que es, en mi humilde opinión, no es un sustituto de las pruebas manuales. La razón principal es que un sistema automatizado solo puede hacer lo que se le dice y solo verificar lo que se le ha informado para ver si pasa o no. Un humano puede usar su inteligencia para encontrar fallas y plantear preguntas que aparecen mientras prueba otra cosa.

• pruebas exploratorias
  ET es una manera muy bajo costo y eficaz para encontrar defectos en un proyecto. Aprovecha la inteligencia de un ser humano y le enseña más sobre el proyecto a los probadores/desarrolladores que cualquier otra técnica de prueba que conozco. Realizar una sesión de ET orientada a cada función desplegada en el entorno de prueba no solo es una forma efectiva de encontrar problemas rápidamente, sino también una buena forma de aprender y divertirse.
  http://www.satisfice.com/articles/et-article.pdf

Esta respuesta es (casi) idéntico al que le di a otra pregunta. Echa un vistazo a esa pregunta ya que tenía otras buenas respuestas que podrían ayudarte. How can we decide which testing method can be used?

Answer 3

por lo general hace las cosas siguientes: consistencia

• Página en caso de varias páginas web orzuelos.
• Prueba de las conexiones de la base de datos.
• Probando las funcionalidades que pueden verse afectadas por el cambio que acabo de hacer.
• Pruebo funciones con entrada de muestra para asegurarme de que funcionen bien (especialmente aquellas que son similares a algoritmos).
• En algunos casos, implemento funciones que codifican la mayoría de las configuraciones de manera muy simple, luego implemento las configuraciones más tarde, probando después de implementar cada configuración.

La mayoría de estos se aplican a las aplicaciones, también.

Answer 4

Antes de ir a la respuesta, me gustaría aclarar el concepto de prueba sobre múltiples métodos.

Hay seis tipos de pruebas principales que cubren la mayoría de los métodos de prueba.

1. Negro Box Testing Testing
2. caja blanca que las pruebas
3. Caja Gris
4. pruebas funcionales
5. pruebas de integración
6. pruebas de usabilidad

Casi todos los métodos de prueba se encuentra debajo de estos tipos , también puedes usar algún método de prueba en múltiples tipos como puede usar las pruebas de humo en el cuadro negro o en el cuadro blanco sobre la base de los recursos disponibles para evaluar.

Para probar un sitio web completamente, debe usar al menos los siguientes métodos de prueba en función de los recursos disponibles para la prueba. Estos son al menos métodos que deberían usarse para probar un sitio web, pero puede haber algunos métodos más sobre la base de la naturaleza del sitio web.

1. Prueba Requisito
2. Prueba Smock
3. Prueba del Sistema
4. Pruebas de Integración
5. Regresión Pruebas Pruebas
6. Seguridad
7. Pruebas de rendimiento de carga &
8. probar la distribución

Al menos debe utilizar todos los métodos de prueba anteriores (8) para probar un sitio web sin importar qué tipo de prueba esté enfocando. Puede automatizar su prueba en algunas áreas y puede hacerlo manualmente, todo depende de la disponibilidad de los recursos.

No existe una regla específica para seguir cualquier tipo de prueba o método. Como usted sabe, "Testing Is An ART" (Prueba es un arte), entonces el arte no tiene reglas ni límites. Depende totalmente de ti Lo que utilizas para probar y cómo .......

Espero que tengas la respuesta a la pregunta.

Answer 5

Selenium es muy bueno para probar sitios web.

Answer 6

La respuesta depende del marco web utilizado (si existe). Django, por ejemplo, tiene funciones de prueba incorporadas.

Para PHP (o pruebas web funcionales), SimpleTest es bastante bueno y bueno ... simple. Es compatible con Prueba de unidad (solo PHP) y Prueba web. Las pruebas se pueden ejecutar en el IDE (Eclipse) o en el navegador (es decir, en su servidor).

Answer 7

Las otras respuestas publicadas hasta el momento se centran en la unidad/funcional/rendimiento/etc. prueba, y todos son razonables.

Sin embargo, una de las preguntas clave que debe formular es "¿qué tan efectivas son mis pruebas?".

Esto a menudo se responde con pruebas de cobertura herramientas, que determinan qué partes de su aplicación se vuelven ejercitadas por un conjunto de pruebas. La herramienta de cobertura de prueba ideal le permite probar su aplicación por cualquier método que pueda imaginar (incluidas todas las respuestas estándar anteriores) y luego informará qué parte y qué porcentaje de su código se ejerció. Lo más importante, le dirá qué código no hizo ejercicio. Luego puede inspeccionar ese código y decidir si se justifican más pruebas o si no le importa. Si el código no probado tiene que ver con "manejo de error completo del disco" y cree que los discos de 1TB son comunes, puede decidir ignorarlos. Si el código no probado es la lógica de validación de entrada que conduce a las consultas SQL, puede decidir que debe probar esa lógica para asegurarse de que no se produzcan ataques de inyección SQL.

Qué herramientas de cobertura de prueba le permiten tomar una decisión racional que haya probado adecuadamente, utilizando datos sobre qué partes de su código se han ejercido. Entonces, independientemente de cómo realice la prueba, las mejores prácticas indican que también debe hacer un análisis de cobertura de prueba.

Las herramientas de cobertura de prueba se pueden obtener de una variedad de fuentes. SD proporciona a family of test coverage tools que maneja C, C++, Java, C#, PHP y COBOL, todos los cuales se usan para respaldar las pruebas de sitios web de varias maneras.