De Wikipedia, la enciclopedia libre
Saltar a navegación Saltar a búsqueda
Este artículo trata sobre el término en ingeniería de software. Para conocer el término legal, consulte Caso de prueba (ley) . Para otros usos, consulte Caso de prueba (desambiguación) .

En ingeniería de software, un caso de prueba es una especificación de las entradas, las condiciones de ejecución, el procedimiento de prueba y los resultados esperados que definen una sola prueba que se ejecutará para lograr un objetivo de prueba de software en particular , como ejecutar una ruta de programa en particular o verificar cumplimiento de un requisito específico. [1] Los casos de prueba subyacen a las pruebas que son metódicas en lugar de fortuitas. Se puede construir una batería de casos de prueba para producir la cobertura deseada del software que se está probando. Los casos de prueba definidos formalmente permiten que las mismas pruebas se ejecuten repetidamente contra versiones sucesivas del software, lo que permite pruebas de regresión efectivas y consistentes . [2]

Casos de prueba formales [ editar ]

Para probar completamente que se cumplen todos los requisitos de una aplicación, debe haber al menos dos casos de prueba para cada requisito: una prueba positiva y una prueba negativa. [3] Si un requisito tiene subrequisitos, cada subrequisito debe tener al menos dos casos de prueba. El seguimiento del vínculo entre el requisito y la prueba se realiza con frecuencia mediante una matriz de trazabilidad . Los casos de prueba escritos deben incluir una descripción de la funcionalidad que se probará y la preparación requerida para garantizar que la prueba se pueda realizar.

Un caso de prueba formal por escrito se caracteriza por una entrada conocida y por una salida esperada, que se resuelve antes de que se ejecute la prueba. [4] La entrada conocida debe probar una condición previa y la salida esperada debe probar una condición posterior .

Casos de prueba informales [ editar ]

Para aplicaciones o sistemas sin requisitos formales, se pueden escribir casos de prueba basados ​​en el funcionamiento normal aceptado de programas de una clase similar. En algunas escuelas de pruebas, los casos de prueba no se escriben en absoluto, pero las actividades y los resultados se informan después de que se hayan ejecutado las pruebas.

En las pruebas de escenarios , se utilizan historias hipotéticas para ayudar al evaluador a pensar en un problema o sistema complejo. Por lo general, estos escenarios no están escritos en detalle. Pueden ser tan simples como un diagrama para un entorno de prueba o pueden ser una descripción escrita en prosa. La prueba de escenario ideal es una historia motivadora, creíble, compleja y fácil de evaluar. Por lo general, son diferentes de los casos de prueba en que los casos de prueba son pasos únicos, mientras que los escenarios cubren varios pasos de la clave. [5] [6]

Formato de caso de prueba escrito típico [ editar ]

Un caso de prueba suele ser un solo paso, u ocasionalmente una secuencia de pasos, para probar el comportamiento / funcionalidad correctos, características de una aplicación. Por lo general, se da un resultado esperado o un resultado esperado. [7]

Información adicional que puede incluirse: [8]

  • ID de caso de prueba : este campo identifica de forma única un caso de prueba.
  • Caso de prueba Descripción / Resumen : este campo describe el objetivo del caso de prueba.
  • Pasos de prueba : en este campo, se mencionan los pasos exactos para realizar el caso de prueba.
  • Requisitos previos : este campo especifica las condiciones o los pasos que se deben seguir antes de ejecutar los pasos de prueba.
  • Profundidad
  • Categoría de prueba
  • Autor: nombre del probador.
  • Automatización: si este caso de prueba está automatizado o no.
  • contraseña errónea
  • Observaciones

Los casos de prueba más grandes también pueden contener estados o pasos de requisitos previos y descripciones. [8]

Un caso de prueba escrito también debe contener un lugar para el resultado real.

Estos pasos se pueden almacenar en un documento de procesador de texto, hoja de cálculo, base de datos u otro repositorio común.

En un sistema de base de datos, también puede ver los resultados de pruebas anteriores y quién generó los resultados y la configuración del sistema utilizada para generar esos resultados. Estos resultados pasados ​​generalmente se almacenarían en una tabla separada.

Los conjuntos de pruebas a menudo también contienen [9]

  • Resumen de la prueba
  • Configuración

Además de una descripción de la funcionalidad que se va a probar y la preparación necesaria para garantizar que la prueba se pueda realizar, la parte que lleva más tiempo en el caso de prueba es crear las pruebas y modificarlas cuando cambia el sistema.

En circunstancias especiales, podría ser necesario ejecutar la prueba, producir resultados y luego un equipo de expertos evaluaría si los resultados pueden considerarse aprobados. Esto sucede a menudo en la determinación del número de rendimiento de nuevos productos. La primera prueba se toma como línea de base para los ciclos posteriores de prueba y lanzamiento del producto.

Las pruebas de aceptación , que utilizan una variación de un caso de prueba escrito, suelen ser realizadas por un grupo de usuarios finales o clientes del sistema para garantizar que el sistema desarrollado cumple los requisitos especificados o el contrato. [10] [11] Las pruebas de aceptación del usuario se diferencian por la inclusión de la ruta feliz o los casos de prueba positivos con la exclusión casi completa de los casos de prueba negativos. [12]

Ver también [ editar ]

Referencias [ editar ]

  1. ^ Ingeniería de sistemas y software - Vocabulario . Iso / Iec / IEEE 24765: 2010 (E) . 2010-12-01. págs. 1–418. doi : 10.1109 / IEEESTD.2010.5733835 . ISBN 978-0-7381-6205-8.
  2. ^ Kaner, Cem (mayo de 2003). "¿Qué es un buen caso de prueba?" (PDF) . ESTRELLA Este : 2.
  3. ^ "Escribir reglas de prueba para verificar los requisitos de las partes interesadas" . StickyMinds .
  4. ^ Beizer, Boris (22 de mayo de 1995). Prueba de caja negra . Nueva York: Wiley. pag. 3 . ISBN 9780471120940.
  5. ^ "Introducción a las pruebas de escenarios" (PDF) . Cem Kaner . Consultado el 7 de mayo de 2009 .
  6. ^ Crispin, Lisa; Gregory, Janet (2009). Pruebas ágiles: una guía práctica para probadores y equipos ágiles . Addison-Wesley . págs.  192 –5. ISBN 978-81-317-3068-3.
  7. ^ https://www.softwaretestingstandard.org/part3.php ISO / IEC / IEEE 29119-4: 2019 , "Parte 4: Técnicas de prueba"
  8. ↑ a b Liu, Juan (2014). "Estudios de los procesos de prueba de software basados ​​en GUI" . 2014 Conferencia Internacional sobre Informática, Red : 113–121. doi : 10.1109 / CSCI.2014.104 . ISBN 9781605951676. S2CID  15204091 . Consultado el 22 de octubre de 2019 .
  9. ^ Kaner, Cem; Falk, Jack; Nguyen, Hung Q. (1993). Pruebas de software informático (2ª ed.). Boston: Thomson Computer Press. pag. 123–4 . ISBN 1-85032-847-1.
  10. ^ Goethem, Brian Hambling, Pauline van (2013). Prueba de aceptación del usuario: una guía paso a paso . BCS Learning & Development Limited. ISBN 9781780171678.
  11. ^ Black, Rex (agosto de 2009). Gestión del proceso de prueba: herramientas y técnicas prácticas para la gestión de pruebas de hardware y software . Hoboken, Nueva Jersey: Wiley. ISBN 978-0-470-40415-7.
  12. ^ Cimperman, Rob (2006). Definición de UAT: una guía para las pruebas prácticas de aceptación del usuario . Educación Pearson. pp. Capítulo 2. ISBN 9780132702621.

Enlaces externos [ editar ]

  • Redacción de casos de prueba de seguridad de software: integración de casos de prueba de seguridad en su plan de prueba por Robert Auger
  • Ingeniería de casos de prueba de software por Ajay Bhagwat