Hispanopedia Wiki
Articulo de referencia

Caso de prueba (software)

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 defi...

Hispanopedia WikiContenido en espanolLectura gratuita

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 única prueba que se ejecutará para lograr un objetivo particular de prueba de software , como probar una ruta de programa específica o verificar el cumplimiento de un requisito específico. [ 1 ] Los casos de prueba son la base de las pruebas metódicas en lugar de las aleatorias. Se puede crear un conjunto de casos de prueba para producir la cobertura deseada del software que se está probando. Los casos de prueba definidos formalmente permiten ejecutar las mismas pruebas repetidamente en versiones sucesivas del software, lo que permite realizar pruebas de regresión efectivas y consistentes . [ 2 ]

Casos de prueba formales

Para comprobar 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 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 frecuentemente mediante una matriz de trazabilidad . Los casos de prueba escritos deben incluir una descripción de la funcionalidad que se va a probar y la preparación necesaria para garantizar que la prueba se pueda realizar.

Un caso de prueba escrito formal se caracteriza por una entrada conocida y una salida esperada, que se determina antes de ejecutar la prueba. [ 4 ] La entrada conocida debe probar una precondición y la salida esperada debe probar una postcondición .

Casos de prueba informales

Para aplicaciones o sistemas sin requisitos formales, los casos de prueba pueden escribirse basándose en el funcionamiento normal aceptado de programas de una clase similar. En algunas metodologías de pruebas, no se escriben casos de prueba, sino que se informan las actividades y los resultados una vez ejecutadas las pruebas.

En las pruebas de escenarios , se utilizan historias hipotéticas para ayudar al evaluador a comprender un problema o sistema complejo. Estos escenarios generalmente no se describen con detalle. Pueden ser tan simples como un diagrama de un entorno de prueba o una descripción escrita en prosa. El escenario ideal es una historia motivadora, creíble, compleja y fácil de evaluar. Suelen diferenciarse de los casos de prueba en que estos últimos constan de pasos individuales, mientras que los escenarios abarcan varios pasos clave. [ 5 ] [ 6 ]

Formato típico de caso de prueba escrito

Un caso de prueba generalmente contiene un solo paso o una secuencia de pasos para probar el comportamiento, la funcionalidad y las características correctas de una aplicación. Normalmente se proporciona un resultado esperado.

Información adicional que puede incluirse: [ 7 ]

  • ID del caso de prueba : un identificador único para el caso de prueba.
  • Descripción/resumen : El objetivo del caso de prueba.
  • Pasos de la prueba : Los pasos exactos a seguir.
  • Resultado esperado : El resultado esperado y cómo determinar si se ha logrado.
  • Resultado real
  • Requisitos previos : Condiciones que deben existir o preparación necesaria antes de la ejecución de la prueba.
  • Categoría de prueba
  • Autor - nombre del evaluador.
  • Automatización : si este caso de prueba está automatizado o no y, en caso afirmativo, cómo.
  • Aprobado/suspenso
  • Observaciones

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

Un caso de prueba escrito también debe incluir un espacio para el resultado real.

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

En un sistema de base de datos, también es posible consultar los resultados de pruebas anteriores, quién los generó y la configuración del sistema utilizada. Estos resultados suelen almacenarse en una tabla aparte.

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

  • Resumen de la prueba
  • Configuración

Además de la 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 más tiempo consume en el caso de prueba es la creación de las pruebas y su modificación cuando el sistema cambia.

En circunstancias especiales, podría ser necesario realizar la prueba, obtener los resultados y, posteriormente, un equipo de expertos evaluar si estos son satisfactorios. Esto suele ocurrir al determinar el rendimiento de nuevos productos. La primera prueba se toma como referencia para las pruebas posteriores y los ciclos de 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 cumpla con los requisitos especificados o el contrato. [ 9 ] [ 10 ] Las pruebas de aceptación del usuario se diferencian por la inclusión de casos de prueba positivos o de ruta feliz , excluyendo casi por completo los casos de prueba negativos. [ 11 ]

Véase también

Referencias

  1. ↑ Ingeniería de sistemas y software - Vocabulario . ISO/IEC/IEEE 24765:2010(E). 1 de diciembre de 2010. 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) . STAR East : 2.
  3. ↑ "Redacción de reglas de prueba para verificar los requisitos de las partes interesadas" . StickyMinds .
  4. ↑ Beizer, Boris (22 de mayo de 1995). Black Box Testing . Nueva York: Wiley. pág . 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 evaluadores y equipos ágiles . Addison-Wesley . págs. 192-195 . ISBN  978-81-317-3068-3.
  7. 1 2 Liu, Juan (2014). "Equilibrio del proceso de toma de decisiones en el mercado financiero" . Conferencia Internacional de 2014 sobre Ciencia Computacional e Inteligencia Computacional . pp. 113–121 . doi : 10.1109/CSCI.2014.104 . ISBN  9781605951676. S2CID 15204091 . Consultado el 22-10-2019 . 
  8. ↑ Kaner, Cem; Falk, Jack; Nguyen, Hung Q. (1993). Pruebas de software informático (2.ª ed.). Boston: Thomson Computer Press. págs. 123-124 . ISBN   1-85032-847-1.
  9. ↑ Hambling, Brian; van Goethem, Pauline (2013). Pruebas de aceptación del usuario: una guía paso a paso . BCS Learning & Development Limited. ISBN 9781780171678.
  10. ↑ Black, Rex (agosto de 2009). Managing the Testing Process: Practical Tools and Techniques for Managing Hardware and Software Testing . Hoboken, NJ: Wiley. ISBN 978-0-470-40415-7.
  11. ↑ Cimperman, Rob (2006). UAT Defined: A Guide to Practical User Acceptance Testing . Pearson Education. pp. Capítulo 2. ISBN  9780132702621.
  • Ingeniería de casos de prueba de software por Ajay Bhagwat