Wikibrief

Pruebas de software

Editar artículo

Desarrollo de software
Actividades centrales Actividades principales
Paradigmas y modelos
Metodologías y marcos
Disciplinas de apoyo
Practicas
Instrumentos
Estándares y cuerpos de conocimiento
Glosarios
Contornos
  • v
  • t
  • mi

La prueba de software es una investigación realizada para proporcionar a las partes interesadas información sobre la calidad del producto o servicio de software que se está probando. Las pruebas de software también pueden proporcionar una vista objetiva e independiente del software para permitir que la empresa aprecie y comprenda los riesgos de la implementación del software. Las técnicas de prueba incluyen el proceso de ejecutar un programa o aplicación con la intención de encontrar fallas y verificar que el producto de software sea apto para su uso.

Las pruebas de software implican la ejecución de un componente de software o un componente del sistema para evaluar una o más propiedades de interés. En general, estas propiedades indican hasta qué punto el componente o sistema sometido a prueba:

  • cumple con los requisitos que guiaron su diseño y desarrollo,
  • responde correctamente a todo tipo de entradas,
  • realiza sus funciones en un plazo aceptable,
  • es suficientemente utilizable,
  • se puede instalar y ejecutar en los entornos previstos
  • logra el resultado general que desean sus grupos de interés.

Como el número de pruebas posibles incluso para componentes de software simples es prácticamente infinito, todas las pruebas de software utilizan alguna estrategia para seleccionar las pruebas que son factibles para el tiempo y los recursos disponibles. Como resultado, las pruebas de software típicamente, pero no exclusivamente, intentan ejecutar un programa o aplicación con la intención de encontrar fallas debido a fallas de software. El trabajo de prueba es un proceso iterativo, ya que cuando se soluciona una falla, puede iluminar otras fallas debido a fallas más profundas, o incluso puede crear nuevas fallas.

Las pruebas de software pueden proporcionar información objetiva e independiente sobre la calidad del software y el riesgo de que falle a los usuarios o patrocinadores.

Las pruebas de software se pueden realizar tan pronto como exista el software ejecutable (incluso si está parcialmente completo). El enfoque general del desarrollo de software a menudo determina cuándo y cómo se realizan las pruebas. Por ejemplo, en un proceso por fases, la mayoría de las pruebas se realizan después de que se hayan definido los requisitos del sistema y luego se hayan implementado en programas comprobables. Por el contrario, con un enfoque ágil, los requisitos, la programación y las pruebas a menudo se realizan al mismo tiempo.

Contenido
  • 1 Resumen
    • 1.1 Fallos y fallos
    • 1.2 Combinaciones de entrada y condiciones previas
    • 1.3 Economía
    • 1.4 Roles
  • 2 Historia
  • 3 Enfoque de prueba
    • 3.1 Pruebas estáticas, dinámicas y pasivas
    • 3.2 Enfoque exploratorio
    • 3.3 El enfoque de "caja"
      • 3.3.1 Prueba de caja blanca
      • 3.3.2 Prueba de caja negra
        • 3.3.2.1 Prueba visual
      • 3.3.3 Prueba de caja gris
  • 4 niveles de prueba
    • 4.1 Prueba unitaria
    • 4.2 Prueba de integración
    • 4.3 Prueba del sistema
    • 4.4 Prueba de aceptación
  • 5 tipos de pruebas, técnicas y tácticas
    • 5.1 Prueba de instalación
    • 5.2 Prueba de compatibilidad
    • 5.3 Pruebas de humo y cordura
    • 5.4 Prueba de regresión
    • 5.5 Prueba de aceptación
    • 5.6 Prueba alfa
    • 5.7 Prueba Beta
    • 5.8 Pruebas funcionales y no funcionales
    • 5.9 Prueba continua
    • 5.10 Ensayos destructivos
    • 5.11 Prueba de rendimiento del software
    • 5.12 Pruebas de usabilidad
    • 5.13 Prueba de accesibilidad
    • 5.14 Prueba de seguridad
    • 5.15 Internacionalización y localización
    • 5.16 Pruebas de desarrollo
    • 5.17 Prueba A / B
    • 5.18 Prueba concurrente
    • 5.19 Prueba de conformidad o prueba de tipo
    • 5.20 Prueba de comparación de salida
    • 5.21 Pruebas de propiedad
    • 5.22 Prueba de VCR
  • 6 Proceso de prueba
    • 6.1 Modelo de desarrollo de cascada tradicional
    • 6.2 Modelo de desarrollo ágil o XP
    • 6.3 Un ciclo de prueba de muestra
  • 7 Pruebas automatizadas
    • 7.1 Herramientas de prueba
    • 7.2 Capturar y reproducir
  • 8 Medición en pruebas de software
    • 8.1 Jerarquía de la dificultad de las pruebas
  • 9 Prueba de artefactos
  • 10 certificaciones
  • 11 Controversia
  • 12 Procesos relacionados
    • 12.1 Verificación y validación del software
    • 12.2 Aseguramiento de la calidad del software
  • 13 Véase también
  • 14 referencias
  • 15 Lecturas adicionales
  • 16 Enlaces externos

Visión general

Aunque las pruebas de software pueden determinar la corrección del software bajo el supuesto de algunas hipótesis específicas (consulte la jerarquía de dificultad de las pruebas a continuación), las pruebas no pueden identificar todas las fallas dentro del software. En cambio, proporciona una crítica o comparación que compara el estado y el comportamiento del producto con los oráculos de prueba, principios o mecanismos mediante los cuales alguien podría reconocer un problema. Estos oráculos pueden incluir (pero no se limitan a) especificaciones, contratos, productos comparables, versiones anteriores del mismo producto, inferencias sobre el propósito previsto o esperado, expectativas del usuario o cliente, estándares relevantes, leyes aplicables u otros criterios.

El propósito principal de las pruebas es detectar fallas de software para que los defectos se puedan descubrir y corregir. Las pruebas no pueden establecer que un producto funcione correctamente en todas las condiciones, sino solo que no funciona correctamente en condiciones específicas. El alcance de las pruebas de software puede incluir el examen del código, así como la ejecución de ese código en varios entornos y condiciones, así como el examen de los aspectos del código: ¿hace lo que se supone que debe hacer y hace lo que debe hacer? En la cultura actual del desarrollo de software, una organización de pruebas puede estar separada del equipo de desarrollo. Hay varios roles para los miembros del equipo de prueba. La información derivada de las pruebas de software se puede utilizar para corregir el proceso mediante el cual se desarrolla el software.

Cada producto de software tiene un público objetivo. Por ejemplo, la audiencia del software de videojuegos es completamente diferente del software bancario. Por lo tanto, cuando una organización desarrolla o invierte en un producto de software, puede evaluar si el producto de software será aceptable para sus usuarios finales, su público objetivo, sus compradores y otras partes interesadas. Las pruebas de software ayudan a realizar esta evaluación.

Fallos y fallos

Las fallas de software ocurren a través del siguiente proceso: Un programador comete un error (error), que resulta en una falla (defecto, error) en el código fuente del software. Si se ejecuta esta falla, en ciertas situaciones el sistema producirá resultados incorrectos, causando una falla.

No todas las fallas resultarán necesariamente en fallas. Por ejemplo, las fallas en el código muerto nunca resultarán en fallas. Una falla que no reveló fallas puede resultar en una falla cuando se cambia el entorno. Ejemplos de estos cambios en el entorno incluyen el software que se ejecuta en una nueva plataforma de hardware de computadora, alteraciones en los datos de origen o la interacción con software diferente. Una sola falla puede resultar en una amplia gama de síntomas de falla.

No todas las fallas de software se deben a errores de codificación. Una fuente común de defectos costosos son los vacíos de requisitos, es decir, requisitos no reconocidos que resultan en errores de omisión por parte del diseñador del programa. Las brechas de requisitos a menudo pueden ser requisitos no funcionales como la capacidad de prueba, la escalabilidad, el mantenimiento, el rendimiento y la seguridad.

Combinaciones de entrada y condiciones previas

Un problema fundamental con las pruebas de software es que las pruebas bajo todas las combinaciones de entradas y condiciones previas (estado inicial) no son factibles, incluso con un producto simple. Esto significa que la cantidad de fallas en un producto de software puede ser muy grande y los defectos que ocurren con poca frecuencia son difíciles de encontrar en las pruebas y la depuración. Más significativamente, las dimensiones no funcionales de la calidad (cómo se supone que es frente a lo que se supone que debe hacer) - usabilidad, escalabilidad, rendimiento, compatibilidad y confiabilidad - pueden ser altamente subjetivas; algo que constituye un valor suficiente para una persona puede resultar intolerable para otra.

Los desarrolladores de software no pueden probar todo, pero pueden utilizar el diseño de prueba combinatoria para identificar la cantidad mínima de pruebas necesarias para obtener la cobertura que desean. El diseño de prueba combinatoria permite a los usuarios obtener una mayor cobertura de prueba con menos pruebas. Ya sea que busquen velocidad o profundidad de prueba, pueden usar métodos de diseño de prueba combinatorios para construir una variación estructurada en sus casos de prueba.

Ciencias económicas

Un estudio realizado por NIST en 2002 informa que los errores de software le cuestan a la economía estadounidense $ 59.5 mil millones al año. Más de un tercio de este costo podría evitarse si se realizaran mejores pruebas de software.

La subcontratación de pruebas de software debido a los costos es muy común, siendo China, Filipinas e India los destinos preferidos.

Roles

Las pruebas de software pueden ser realizadas por probadores de software dedicados; hasta la década de 1980, el término "probador de software" se usó generalmente, pero más tarde también se consideró una profesión separada. En cuanto a los plazos y los diferentes objetivos en las pruebas de software, se han establecido diferentes roles, como director de pruebas, análisis de plomo, analista de prueba, diseñador de prueba, probador, desarrollador de la automatización, y administrador de la prueba. Las pruebas de software también pueden ser realizadas por probadores de software no dedicados.

Historia

Glenford J. Myers introdujo inicialmente la separación de la depuración de las pruebas en 1979. Aunque su atención estaba en las pruebas de rotura ("Un caso de prueba exitoso es aquel que detecta un error aún no descubierto"), ilustró el deseo de la ingeniería de software. comunidad para separar las actividades de desarrollo fundamentales, como la depuración, de las de verificación.

Enfoque de prueba

Pruebas estáticas, dinámicas y pasivas

Hay muchos enfoques disponibles en las pruebas de software. Las revisiones, recorridos o inspecciones se denominan pruebas estáticas, mientras que la ejecución de código programado con un conjunto determinado de casos de prueba se denomina prueba dinámica.

Las pruebas estáticas a menudo son implícitas, como la corrección de pruebas, además, cuando las herramientas de programación / editores de texto verifican la estructura del código fuente o los compiladores (precompiladores) verifican la sintaxis y el flujo de datos como análisis de programa estático. Las pruebas dinámicas tienen lugar cuando se ejecuta el programa. Las pruebas dinámicas pueden comenzar antes de que el programa esté completo al 100% para probar secciones particulares de código y se apliquen a funciones o módulos discretos. Las técnicas típicas para estos son el uso de códigos auxiliares / controladores o la ejecución desde un entorno de depuración.

Las pruebas estáticas implican verificación, mientras que las pruebas dinámicas también implican validación.

La prueba pasiva significa verificar el comportamiento del sistema sin ninguna interacción con el producto de software. A diferencia de las pruebas activas, los probadores no proporcionan ningún dato de prueba, pero miran los registros y trazas del sistema. Buscan patrones y comportamientos específicos para tomar algún tipo de decisiones. Esto está relacionado con la verificación del tiempo de ejecución sin conexión y el análisis de registros.

Enfoque exploratorio

Las pruebas exploratorias son un enfoque para las pruebas de software que se describe de manera concisa como aprendizaje simultáneo, diseño de pruebas y ejecución de pruebas. Cem Kaner, quien acuñó el término en 1984, define las pruebas exploratorias como "un estilo de pruebas de software que enfatiza la libertad personal y la responsabilidad del evaluador individual para optimizar continuamente la calidad de su trabajo al tratar el aprendizaje relacionado con las pruebas, el diseño de pruebas, ejecución de pruebas e interpretación de resultados de pruebas como actividades de apoyo mutuo que se ejecutan en paralelo a lo largo del proyecto ".

El enfoque de "caja"

Los métodos de prueba de software se dividen tradicionalmente en pruebas de caja blanca y negra. Estos dos enfoques se utilizan para describir el punto de vista que el evaluador adopta al diseñar casos de prueba. También se puede aplicar un enfoque híbrido llamado prueba de caja gris a la metodología de prueba de software. Con el concepto de prueba de caja gris, que desarrolla pruebas a partir de elementos de diseño específicos, ganando importancia, esta "distinción arbitraria" entre pruebas de caja blanca y negra se ha desvanecido un poco.

Prueba de caja blanca

Artículo principal: Prueba de caja blanca Diagrama de prueba de caja blanca Diagrama de prueba de caja blanca

La prueba de caja blanca (también conocida como prueba de caja transparente, prueba de caja de vidrio, prueba de caja transparente y prueba estructural) verifica las estructuras internas o el funcionamiento de un programa, en contraposición a la funcionalidad expuesta al usuario final. En las pruebas de caja blanca, se utiliza una perspectiva interna del sistema (el código fuente), así como habilidades de programación, para diseñar casos de prueba. El probador elige entradas para ejercitar rutas a través del código y determinar las salidas apropiadas. Esto es análogo a probar nodos en un circuito, por ejemplo, pruebas en circuito (ICT).

Si bien las pruebas de caja blanca se pueden aplicar a los niveles de unidad, integración y sistema del proceso de prueba de software, generalmente se realiza a nivel de unidad. Puede probar rutas dentro de una unidad, rutas entre unidades durante la integración y entre subsistemas durante una prueba a nivel de sistema. Aunque este método de diseño de prueba puede descubrir muchos errores o problemas, es posible que no detecte partes no implementadas de la especificación o requisitos faltantes.

Las técnicas utilizadas en las pruebas de caja blanca incluyen:

  • Prueba de API : prueba de la aplicación utilizando API públicas y privadas (interfaces de programación de aplicaciones)
  • Cobertura de código : creación de pruebas para satisfacer algunos criterios de cobertura de código (por ejemplo, el diseñador de pruebas puede crear pruebas para hacer que todas las declaraciones del programa se ejecuten al menos una vez)
  • Métodos de inyección de fallas : introducción intencional de fallas para medir la eficacia de las estrategias de prueba.
  • Métodos de prueba de mutaciones
  • Métodos de prueba estáticos

Las herramientas de cobertura de código pueden evaluar la integridad de un conjunto de pruebas que se creó con cualquier método, incluidas las pruebas de caja negra. Esto permite al equipo de software examinar partes de un sistema que rara vez se prueban y garantiza que se hayan probado los puntos de función más importantes. La cobertura del código como métrica de software se puede informar como un porcentaje para:

  • Cobertura de funciones, que informa sobre las funciones ejecutadas
  • Cobertura de la declaración, que informa sobre la cantidad de líneas ejecutadas para completar la prueba
  • Cobertura de decisiones, que informa sobre si se han ejecutado tanto la rama Verdadero como la rama Falsa de una prueba determinada

La cobertura del 100% de la declaración garantiza que todas las rutas de código o ramas (en términos de flujo de control ) se ejecuten al menos una vez. Esto es útil para garantizar la funcionalidad correcta, pero no es suficiente, ya que el mismo código puede procesar diferentes entradas de forma correcta o incorrecta. Las funciones y métodos pseudoprobados son aquellos que están cubiertos pero no especificados (es posible eliminar su cuerpo sin romper ningún caso de prueba).

Prueba de caja negra

Artículo principal: Prueba de caja negra Diagrama de caja negra

Las pruebas de caja negra (también conocidas como pruebas funcionales) tratan el software como una "caja negra", examinando la funcionalidad sin ningún conocimiento de implementación interna, sin ver el código fuente. Los evaluadores solo saben lo que se supone que debe hacer el software, no cómo lo hace. Métodos de prueba de recuadro negro incluyen: partición de equivalencia, análisis de valor límite, todos los pares de pruebas, tablas de transición de estado, tabla de decisión pruebas, las pruebas de pelusa, pruebas basadas en modelos, caso de uso de pruebas, pruebas exploratorias, y pruebas basadas en la especificación.

Las pruebas basadas en especificaciones tienen como objetivo probar la funcionalidad del software de acuerdo con los requisitos aplicables. Este nivel de prueba generalmente requiere que se proporcionen casos de prueba completos al probador, quien luego puede simplemente verificar que para una entrada determinada, el valor de salida (o comportamiento), "es" o "no es" el mismo que el valor esperado. especificado en el caso de prueba. Los casos de prueba se basan en especificaciones y requisitos, es decir, lo que se supone que debe hacer la aplicación. Utiliza descripciones externas del software, incluidas especificaciones, requisitos y diseños para derivar casos de prueba. Estas pruebas pueden ser funcionales o no funcionales, aunque normalmente son funcionales.

Las pruebas basadas en especificaciones pueden ser necesarias para asegurar la funcionalidad correcta, pero no son suficientes para protegerse contra situaciones complejas o de alto riesgo.

Una ventaja de la técnica de la caja negra es que no se requieren conocimientos de programación. Independientemente de los sesgos que puedan haber tenido los programadores, es probable que el evaluador tenga un conjunto diferente y pueda enfatizar diferentes áreas de funcionalidad. Por otro lado, se ha dicho que las pruebas de caja negra son "como caminar en un laberinto oscuro sin una linterna". Debido a que no examinan el código fuente, hay situaciones en las que un evaluador escribe muchos casos de prueba para verificar algo que podría haber sido probado por un solo caso de prueba o deja algunas partes del programa sin probar.

Este método de prueba se puede aplicar a todos los niveles de prueba de software: unidad, integración, sistema y aceptación. Por lo general, comprende la mayoría, si no todas, las pruebas en niveles superiores, pero también puede dominar las pruebas unitarias.

Prueba de interfaz de componentes

Las pruebas de interfaz de componentes son una variación de las pruebas de caja negra, con el enfoque en los valores de los datos más allá de las acciones relacionadas de un componente del subsistema. La práctica de las pruebas de interfaz de componentes se puede utilizar para verificar el manejo de los datos pasados ​​entre varias unidades o componentes del subsistema, más allá de las pruebas de integración total entre esas unidades. Los datos que se pasan se pueden considerar como "paquetes de mensajes" y el rango o los tipos de datos se pueden verificar, para los datos generados a partir de una unidad, y probar su validez antes de pasar a otra unidad. Una opción para las pruebas de interfaz es mantener un archivo de registro separado de los elementos de datos que se pasan, a menudo con una marca de tiempo registrada para permitir el análisis de miles de casos de datos pasados ​​entre unidades durante días o semanas. Las pruebas pueden incluir verificar el manejo de algunos valores de datos extremos mientras que otras variables de interfaz se pasan como valores normales. Los valores de datos inusuales en una interfaz pueden ayudar a explicar un rendimiento inesperado en la siguiente unidad.

Pruebas visuales

El objetivo de las pruebas visuales es proporcionar a los desarrolladores la capacidad de examinar lo que estaba sucediendo en el punto de falla del software al presentar los datos de tal manera que el desarrollador pueda encontrar fácilmente la información que necesita, y la información se exprese con claridad..

En el centro de las pruebas visuales está la idea de que mostrarle a alguien un problema (o una falla en la prueba), en lugar de solo describirlo, aumenta en gran medida la claridad y la comprensión. Las pruebas visuales, por lo tanto, requieren la grabación de todo el proceso de prueba, capturando todo lo que ocurre en el sistema de prueba en formato de video. Los videos de salida se complementan con la entrada del probador en tiempo real a través de la cámara web de imagen en imagen y los comentarios de audio de los micrófonos.

Las pruebas visuales ofrecen una serie de ventajas. La calidad de la comunicación aumenta drásticamente porque los evaluadores pueden mostrar el problema (y los eventos que lo conducen) al desarrollador en lugar de solo describirlo y la necesidad de replicar las fallas de prueba dejará de existir en muchos casos. El desarrollador tendrá todas las pruebas que necesite de una prueba fallida y, en cambio, podrá centrarse en la causa de la falla y cómo se debe solucionar.

Las pruebas ad hoc y las pruebas exploratorias son metodologías importantes para verificar la integridad del software, ya que requieren menos tiempo de preparación para su implementación, mientras que los errores importantes se pueden encontrar rápidamente. En las pruebas ad hoc, donde las pruebas se llevan a cabo de forma improvisada e improvisada, la capacidad de los probadores para basar las pruebas en métodos documentados y luego improvisar variaciones de esas pruebas puede resultar en un examen más riguroso de las correcciones de defectos. Sin embargo, a menos que se mantenga una documentación estricta de los procedimientos, uno de los límites de las pruebas ad hoc es la falta de repetibilidad.

Más información: prueba de la interfaz gráfica de usuario

Prueba de caja gris

Artículo principal: Prueba de caja gris

Las pruebas de caja gris (ortografía estadounidense: prueba de caja gris) implica tener conocimiento de las estructuras y algoritmos de datos internos con el fin de diseñar pruebas mientras se ejecutan esas pruebas a nivel de usuario o de caja negra. El evaluador a menudo tendrá acceso tanto al "código fuente como al binario ejecutable". Las pruebas de caja gris también pueden incluir ingeniería inversa (usando análisis de código dinámico) para determinar, por ejemplo, valores límite o mensajes de error. La manipulación de datos de entrada y el formateo de la salida no califican como caja gris, ya que la entrada y la salida están claramente fuera de la "caja negra" que llamamos el sistema bajo prueba. Esta distinción es particularmente importante cuando se realizan pruebas de integración entre dos módulos de código escritos por dos desarrolladores diferentes, donde solo se exponen las interfaces para la prueba.

Al conocer los conceptos subyacentes de cómo funciona el software, el evaluador toma decisiones de prueba mejor informadas mientras prueba el software desde el exterior. Por lo general, a un probador de caja gris se le permitirá configurar un entorno de prueba aislado con actividades como sembrar una base de datos. El evaluador puede observar el estado del producto que se está probando después de realizar ciertas acciones, como ejecutar declaraciones SQL en la base de datos y luego ejecutar consultas para asegurarse de que se hayan reflejado los cambios esperados. Las pruebas de caja gris implementan escenarios de prueba inteligentes, basados ​​en información limitada. Esto se aplicará particularmente al manejo de tipos de datos, manejo de excepciones, etc.

Niveles de prueba

En términos generales, existen al menos tres niveles de prueba: prueba unitaria, prueba de integración y prueba del sistema. Sin embargo, los desarrolladores pueden incluir un cuarto nivel, pruebas de aceptación. Esto puede ser en forma de pruebas de aceptación operativa o simples pruebas de usuario final (beta), pruebas para garantizar que el software cumpla con las expectativas funcionales. Según el programa de estudios de nivel básico de pruebas certificadas por ISTQB, los niveles de prueba incluyen esos cuatro niveles, y el cuarto nivel se denomina prueba de aceptación. Las pruebas se agrupan con frecuencia en uno de estos niveles según el lugar en el que se agregan en el proceso de desarrollo de software o según el nivel de especificidad de la prueba.

Examen de la unidad

Artículo principal: Prueba unitaria

Las pruebas unitarias se refieren a las pruebas que verifican la funcionalidad de una sección específica de código, generalmente a nivel de función. En un entorno orientado a objetos, esto suele ser a nivel de clase, y las pruebas unitarias mínimas incluyen los constructores y destructores.

Este tipo de pruebas generalmente las escriben los desarrolladores mientras trabajan en el código (estilo caja blanca), para garantizar que la función específica esté funcionando como se esperaba. Una función puede tener varias pruebas para detectar casos de esquina u otras ramas en el código. Las pruebas unitarias por sí solas no pueden verificar la funcionalidad de una pieza de software, sino que se utilizan para garantizar que los componentes básicos del software funcionen de forma independiente entre sí.

Las pruebas unitarias son un proceso de desarrollo de software que implica una aplicación sincronizada de un amplio espectro de estrategias de prevención y detección de defectos para reducir los riesgos, el tiempo y los costos del desarrollo de software. Lo realiza el desarrollador o ingeniero de software durante la fase de construcción del ciclo de vida del desarrollo de software. Las pruebas unitarias tienen como objetivo eliminar los errores de construcción antes de que el código se promueva a pruebas adicionales; esta estrategia tiene como objetivo aumentar la calidad del software resultante, así como la eficiencia del proceso de desarrollo general.

En función de las expectativas de la organización para el desarrollo de software, las pruebas unitarias podría incluir el análisis estático de código, análisis de flujo de datos, análisis de métricas, las revisiones de código de pares, la cobertura de código análisis y otras prácticas de pruebas de software.

Pruebas de integración

Artículo principal: Pruebas de integración

La prueba de integración es cualquier tipo de prueba de software que busca verificar las interfaces entre los componentes con un diseño de software. Los componentes de software pueden integrarse de forma iterativa o todos juntos ("big bang"). Normalmente, lo primero se considera una mejor práctica, ya que permite localizar y solucionar los problemas de la interfaz de forma más rápida.

Las pruebas de integración funcionan para exponer defectos en las interfaces y la interacción entre componentes integrados (módulos). Se integran y prueban grupos progresivamente más grandes de componentes de software probados correspondientes a elementos del diseño arquitectónico hasta que el software funciona como un sistema.

Las pruebas de integración generalmente involucran una gran cantidad de código y producen trazas que son más grandes que las producidas por las pruebas unitarias. Esto tiene un impacto en la facilidad de localizar la falla cuando falla una prueba de integración. Para superar este problema, se ha propuesto cortar automáticamente las pruebas grandes en piezas más pequeñas para mejorar la localización de fallas.

Prueba del sistema

Artículo principal: Prueba del sistema

La prueba del sistema prueba un sistema completamente integrado para verificar que el sistema cumple con sus requisitos. Por ejemplo, una prueba del sistema puede implicar probar una interfaz de inicio de sesión, luego crear y editar una entrada, además de enviar o imprimir los resultados, seguido del procesamiento resumido o la eliminación (o archivo) de las entradas y luego cerrar la sesión.

Test de aceptación

Artículo principal: Prueba de aceptación

Por lo general, este nivel de pruebas de aceptación incluye los siguientes cuatro tipos:

  • Pruebas de aceptación del usuario
  • Prueba de aceptación operativa
  • Pruebas de aceptación contractual y reglamentaria
  • Pruebas alfa y beta

Las pruebas de aceptación del usuario y las pruebas alfa y beta se describen en la siguiente sección de tipos de prueba.

La aceptación operativa se utiliza para llevar a cabo la preparación operativa (prelanzamiento) de un producto, servicio o sistema como parte de un sistema de gestión de la calidad. OAT es un tipo común de prueba de software no funcional, que se utiliza principalmente en proyectos de desarrollo y mantenimiento de software. Este tipo de prueba se centra en la preparación operativa del sistema para ser compatible o para convertirse en parte del entorno de producción. Por lo tanto, también se conoce como prueba de preparación operativa (ORT) o prueba de preparación y garantía de operaciones (ORamp;A). Las pruebas funcionales dentro de OAT se limitan a aquellas pruebas que se requieren para verificar los aspectos no funcionales del sistema.

Además, las pruebas de software deben garantizar que la portabilidad del sistema, además de funcionar como se espera, no dañe ni corrompe parcialmente su entorno operativo ni provoque que otros procesos dentro de ese entorno dejen de funcionar.

Las pruebas de aceptación contractual se realizan en base a los criterios de aceptación del contrato definidos durante el acuerdo del contrato, mientras que las pruebas de aceptación regulatorias se realizan en base a las regulaciones relevantes para el producto de software. Ambas pruebas pueden ser realizadas por usuarios o probadores independientes. Las pruebas de aceptación de regulaciones a veces involucran a las agencias reguladoras que auditan los resultados de las pruebas.

Tipos de pruebas, técnicas y tácticas

Diferentes etiquetas y formas de agrupar las pruebas pueden ser tipos de prueba, tácticas o técnicas de prueba de software.

TestingCup - Campeonato polaco de pruebas de software, Katowice, mayo de 2016

Prueba de instalación

Artículo principal: Prueba de instalación

La mayoría de los sistemas de software tienen procedimientos de instalación que son necesarios antes de que puedan usarse para su propósito principal. La prueba de estos procedimientos para lograr un sistema de software instalado que pueda utilizarse se conoce como prueba de instalación.

Pruebas de compatibilidad

Artículo principal: pruebas de compatibilidad

Una causa común de falla del software (real o percibida) es la falta de compatibilidad con otro software de aplicación, sistemas operativos (o versiones de sistemas operativos, antiguos o nuevos) o entornos de destino que difieren mucho del original (como un terminal o La aplicación GUI destinada a ejecutarse en el escritorio ahora debe convertirse en una aplicación web, que debe procesarse en un navegador web ). Por ejemplo, en el caso de una falta de compatibilidad con versiones anteriores, esto puede ocurrir porque los programadores desarrollan y prueban software solo en la última versión del entorno de destino, que no todos los usuarios pueden estar ejecutando. Esto da como resultado la consecuencia no deseada de que es posible que el último trabajo no funcione en versiones anteriores del entorno de destino o en hardware más antiguo que las versiones anteriores del entorno de destino eran capaces de usar. A veces, estos problemas se pueden solucionar mediante la abstracción proactiva de la funcionalidad del sistema operativo en un módulo de programa o biblioteca separados.

Pruebas de humo y cordura

Artículo principal: Prueba de humo (software)

Las pruebas de cordura determinan si es razonable continuar con más pruebas.

Las pruebas de humo consisten en intentos mínimos de operar el software, diseñados para determinar si hay algún problema básico que impida que funcione. Estas pruebas se pueden utilizar como prueba de verificación de construcción.

Pruebas de regresión

Artículo principal: prueba de regresión

Las pruebas de regresión se centran en encontrar defectos después de que se ha producido un cambio de código importante. Específicamente, busca descubrir regresiones de software, como características degradadas o perdidas, incluidos errores antiguos que han regresado. Estas regresiones se producen siempre que la funcionalidad del software que antes funcionaba correctamente deja de funcionar como se esperaba. Por lo general, las regresiones ocurren como una consecuencia involuntaria de cambios en el programa, cuando la parte recién desarrollada del software choca con el código existente previamente. Las pruebas de regresión suelen ser el esfuerzo de prueba más grande en el desarrollo de software comercial, debido a la verificación de numerosos detalles en funciones de software anteriores, e incluso se puede desarrollar software nuevo mientras se utilizan algunos casos de prueba antiguos para probar partes del nuevo diseño para garantizar que la funcionalidad anterior aún sea compatible..

Los métodos comunes de prueba de regresión incluyen volver a ejecutar conjuntos anteriores de casos de prueba y verificar si han vuelto a surgir fallas previamente solucionadas. La profundidad de las pruebas depende de la fase del proceso de lanzamiento y del riesgo de las funciones añadidas. Pueden ser completos, para cambios agregados tarde en el lanzamiento o considerados riesgosos, o ser muy superficiales, que consisten en pruebas positivas en cada característica, si los cambios son al principio del lanzamiento o se consideran de bajo riesgo. En las pruebas de regresión, es importante tener afirmaciones sólidas sobre el comportamiento existente. Para ello, es posible generar y agregar nuevas aserciones en casos de prueba existentes, esto se conoce como amplificación de prueba automática.

Test de aceptación

Artículo principal: Prueba de aceptación

Las pruebas de aceptación pueden significar una de dos cosas:

  1. Una prueba de humo se utiliza como prueba de aceptación de la construcción antes de realizar más pruebas, por ejemplo, antes de la integración o regresión.
  2. Las pruebas de aceptación realizadas por el cliente, a menudo en su entorno de laboratorio en su propio hardware, se conocen como pruebas de aceptación del usuario (UAT). Las pruebas de aceptación se pueden realizar como parte del proceso de transferencia entre dos fases de desarrollo.

Prueba alfa

Las pruebas alfa son pruebas operativas simuladas o reales realizadas por usuarios / clientes potenciales o un equipo de prueba independiente en el sitio de los desarrolladores. Las pruebas alfa se emplean a menudo para el software estándar como una forma de prueba de aceptación interna antes de que el software pase a la prueba beta.

Prueba beta

Consulte también: Software_release_life_cycle § Beta

Las pruebas beta vienen después de las pruebas alfa y pueden considerarse una forma de prueba de aceptación de usuarios externos. Las versiones del software, conocidas como versiones beta, se lanzan a una audiencia limitada fuera del equipo de programación conocido como beta testers. El software se distribuye a grupos de personas para que las pruebas adicionales puedan garantizar que el producto tenga pocas fallas o errores. Las versiones beta se pueden poner a disposición del público abierto para aumentar el campo de comentarios a un número máximo de usuarios futuros y ofrecer valor antes, durante un período de tiempo prolongado o incluso indefinido ( beta perpetua ).

Pruebas funcionales vs no funcionales

Las pruebas funcionales se refieren a actividades que verifican una acción o función específica del código. Por lo general, se encuentran en la documentación de requisitos del código, aunque algunas metodologías de desarrollo funcionan a partir de casos de uso o historias de usuarios. Las pruebas funcionales tienden a responder a la pregunta de "¿puede el usuario hacer esto?" O "¿funciona esta característica en particular?".

Las pruebas no funcionales se refieren a aspectos del software que pueden no estar relacionados con una función específica o una acción del usuario, como la escalabilidad u otro rendimiento, el comportamiento bajo ciertas restricciones o la seguridad. Las pruebas determinarán el punto de ruptura, el punto en el que los extremos de escalabilidad o rendimiento conducen a una ejecución inestable. Los requisitos no funcionales tienden a ser aquellos que reflejan la calidad del producto, particularmente en el contexto de la perspectiva de idoneidad de sus usuarios.

Prueba continua

Artículo principal: prueba continua

Las pruebas continuas son el proceso de ejecución de pruebas automatizadas como parte del proceso de entrega de software para obtener comentarios inmediatos sobre los riesgos comerciales asociados con un candidato de lanzamiento de software. Las pruebas continuas incluyen la validación tanto de los requisitos funcionales como de los no funcionales ; el alcance de las pruebas se extiende desde la validación de los requisitos ascendentes o las historias de los usuarios hasta la evaluación de los requisitos del sistema asociados con los objetivos comerciales generales.

Pruebas destructivas

Artículo principal: Ensayos destructivos

Las pruebas destructivas intentan hacer que falle el software o un subsistema. Verifica que el software funcione correctamente incluso cuando recibe entradas no válidas o inesperadas, estableciendo así la solidez de las rutinas de validación de entrada y gestión de errores. La inyección de fallas de software, en forma de fuzzing, es un ejemplo de prueba de fallas. Varias herramientas comerciales de prueba no funcionales están vinculadas desde la página de inyección de fallas de software ; También existen numerosas herramientas de software libre y de código abierto disponibles que realizan pruebas destructivas.

Más información: manejo de excepciones y pruebas de recuperación

Prueba de rendimiento del software

Artículo principal: pruebas de rendimiento del software

Las pruebas de rendimiento generalmente se ejecutan para determinar cómo se desempeña un sistema o subsistema en términos de capacidad de respuesta y estabilidad bajo una carga de trabajo particular. También puede servir para investigar, medir, validar o verificar otros atributos de calidad del sistema, como escalabilidad, confiabilidad y uso de recursos.

Las pruebas de carga se refieren principalmente a probar que el sistema puede continuar funcionando bajo una carga específica, ya sean grandes cantidades de datos o una gran cantidad de usuarios. Esto se conoce generalmente como escalabilidad de software. La actividad de prueba de carga relacionada cuando se realiza como una actividad no funcional a menudo se denomina prueba de resistencia. La prueba de volumen es una forma de probar las funciones del software incluso cuando ciertos componentes (por ejemplo, un archivo o una base de datos) aumentan radicalmente de tamaño. Las pruebas de estrés son una forma de probar la confiabilidad bajo cargas de trabajo inesperadas o poco frecuentes. Las pruebas de estabilidad (a menudo denominadas pruebas de carga o resistencia) verifican si el software puede funcionar bien de forma continua en un período aceptable o por encima de él.

Hay poco acuerdo sobre cuáles son los objetivos específicos de las pruebas de rendimiento. Los términos prueba de carga, prueba de rendimiento, prueba de escalabilidad y prueba de volumen, a menudo se usan indistintamente.

Los sistemas de software en tiempo real tienen estrictas restricciones de tiempo. Para probar si se cumplen las restricciones de tiempo, se utilizan pruebas en tiempo real.

Pruebas de usabilidad

Las pruebas de usabilidad son para verificar si la interfaz de usuario es fácil de usar y comprender. Se ocupa principalmente del uso de la aplicación. Este no es un tipo de prueba que pueda automatizarse; Se necesitan usuarios humanos reales, supervisados ​​por diseñadores de UI expertos.

Pruebas de accesibilidad

Las pruebas de accesibilidad pueden incluir el cumplimiento de estándares como:

Pruebas de seguridad

Las pruebas de seguridad son esenciales para el software que procesa datos confidenciales para evitar la intrusión de piratas informáticos en el sistema.

La Organización Internacional de Normalización (ISO) define esto como un "tipo de prueba realizada para evaluar el grado en que un elemento de prueba, y los datos e información asociados, están protegidos para que personas o sistemas no autorizados no puedan usarlos, leerlos o modificarlos, y a las personas o sistemas autorizados no se les niega el acceso a ellos ".

Internacionalización y localización

Las pruebas de internacionalización y localización validan que el software se puede utilizar con diferentes idiomas y regiones geográficas. El proceso de pseudolocalización se utiliza para probar la capacidad de una aplicación para traducirse a otro idioma y facilitar la identificación de cuándo el proceso de localización puede introducir nuevos errores en el producto.

Las pruebas de globalización verifican que el software está adaptado para una nueva cultura (como diferentes monedas o zonas horarias).

También se debe probar la traducción real a los lenguajes humanos. Los posibles fallos de localización y globalización incluyen:

  • El software a menudo se localiza traduciendo una lista de cadenas fuera de contexto, y el traductor puede elegir la traducción incorrecta para una cadena fuente ambigua.
  • La terminología técnica puede volverse inconsistente si el proyecto es traducido por varias personas sin la debida coordinación o si el traductor es imprudente.
  • Las traducciones literalmente palabra por palabra pueden parecer inapropiadas, artificiales o demasiado técnicas en el idioma de destino.
  • Los mensajes no traducidos en el idioma original pueden dejarse codificados en el código fuente.
  • Algunos mensajes pueden crearse automáticamente en tiempo de ejecución y la cadena resultante puede ser gramatical, funcionalmente incorrecta, engañosa o confusa.
  • El software puede utilizar un método abreviado de teclado que no tiene ninguna función en la distribución del teclado del idioma de origen, pero se utiliza para escribir caracteres en la distribución del idioma de destino.
  • El software puede carecer de soporte para la codificación de caracteres del idioma de destino.
  • Las fuentes y los tamaños de fuente que son apropiados en el idioma de origen pueden ser inapropiados en el idioma de destino; por ejemplo, los caracteres CJK pueden volverse ilegibles si la fuente es demasiado pequeña.
  • Una cadena en el idioma de destino puede ser más larga de lo que puede manejar el software. Esto puede hacer que la cadena sea parcialmente invisible para el usuario o hacer que el software se bloquee o no funcione correctamente.
  • El software puede carecer del soporte adecuado para leer o escribir texto bidireccional.
  • El software puede mostrar imágenes con texto no localizado.
  • Los sistemas operativos localizados pueden tener archivos de configuración del sistema y variables de entorno con nombres diferentes y diferentes formatos para la fecha y la moneda.

Pruebas de desarrollo

Artículo principal: pruebas de desarrollo

Las pruebas de desarrollo son un proceso de desarrollo de software que implica la aplicación sincronizada de un amplio espectro de estrategias de prevención y detección de defectos para reducir los riesgos, el tiempo y los costos del desarrollo de software. Lo realiza el desarrollador o ingeniero de software durante la fase de construcción del ciclo de vida del desarrollo de software. Las pruebas de desarrollo tienen como objetivo eliminar los errores de construcción antes de que el código se promueva a otras pruebas; esta estrategia tiene como objetivo aumentar la calidad del software resultante, así como la eficiencia del proceso de desarrollo general.

Dependiendo de las expectativas de la organización para el desarrollo de software, las pruebas de desarrollo pueden incluir análisis de código estático, análisis de flujo de datos, análisis de métricas, revisiones de código de pares, pruebas unitarias, análisis de cobertura de código, trazabilidad y otras prácticas de prueba de software.

Pruebas A / B

Artículo principal: pruebas A / B

Las pruebas A / B son un método para ejecutar un experimento controlado para determinar si un cambio propuesto es más efectivo que el enfoque actual. Los clientes se dirigen a una versión actual (control) de una función oa una versión modificada (tratamiento) y se recopilan datos para determinar qué versión es mejor para lograr el resultado deseado.

Prueba concurrente

Artículo principal: Pruebas concurrentes

Las pruebas concurrentes o de simultaneidad evalúan el comportamiento y el rendimiento del software y los sistemas que utilizan la computación concurrente, generalmente en condiciones normales de uso. Los problemas típicos que expone este tipo de pruebas son los puntos muertos, las condiciones de carrera y los problemas con el manejo de memoria / recursos compartidos.

Pruebas de conformidad o pruebas de tipo

Artículo principal: pruebas de conformidad

En las pruebas de software, las pruebas de conformidad verifican que un producto funcione de acuerdo con sus estándares especificados. Los compiladores, por ejemplo, se someten a pruebas exhaustivas para determinar si cumplen con el estándar reconocido para ese idioma.

Prueba de comparación de salida

La creación de una salida esperada de visualización, ya sea como comparación de datos de texto o capturas de pantalla de la interfaz de usuario, a veces se denomina prueba de instantáneas o prueba Golden Master, a diferencia de muchas otras formas de prueba, esto no puede detectar fallas automáticamente y, en cambio, requiere que un humano evalúe la salida en busca de inconsistencias..

Pruebas de propiedad

La prueba de propiedad es una técnica de prueba en la que, en lugar de afirmar que entradas específicas producen salidas esperadas específicas, el practicante genera aleatoriamente muchas entradas, ejecuta el programa en todas ellas y afirma la verdad de alguna "propiedad" que debería ser cierta para cada par. de entrada y salida. Por ejemplo, cada entrada a una función de ordenación debe tener la misma longitud que su salida. Cada resultado de una función de ordenación debe ser una lista que aumenta monótonamente.

Las bibliotecas de pruebas de propiedades permiten al usuario controlar la estrategia mediante la cual se construyen las entradas aleatorias, para garantizar la cobertura de casos degenerados o entradas con patrones específicos que se necesitan para ejercitar completamente los aspectos de la implementación bajo prueba.

Las pruebas de propiedades también se conocen a veces como "pruebas generativas" o "pruebas QuickCheck", ya que fueron introducidas y popularizadas por la biblioteca de Haskell " QuickCheck ".

Prueba de VCR

La prueba de VCR, también conocida como "prueba de reproducción" o prueba de "grabación / reproducción", es una técnica de prueba para aumentar la confiabilidad y la velocidad de las pruebas de regresión que involucran un componente que es lento o poco confiable para comunicarse, a menudo una API de terceros. fuera del control del probador. Implica realizar una grabación ("casete") de las interacciones del sistema con el componente externo y luego reproducir las interacciones grabadas como un sustituto de la comunicación con el sistema externo en ejecuciones posteriores de la prueba.

La técnica fue popularizada en el desarrollo web por la biblioteca Ruby vcr.

Proceso de prueba

Modelo de desarrollo de cascada tradicional

Una práctica común en el desarrollo en cascada es que las pruebas las realiza un grupo independiente de probadores. Esto puede suceder:

  • después de que se desarrolle la funcionalidad, pero antes de que se envíe al cliente. Esta práctica a menudo da como resultado que la fase de prueba se utilice como un búfer del proyecto para compensar los retrasos del proyecto, comprometiendo así el tiempo dedicado a las pruebas.
  • en el mismo momento se inicia el proyecto de desarrollo, como un proceso continuo hasta que finaliza el proyecto.

Sin embargo, incluso en el modelo de desarrollo en cascada, las pruebas unitarias a menudo las realiza el equipo de desarrollo de software, incluso cuando un equipo independiente realiza más pruebas.

Más información: Integración del modelo de madurez de capacidad y modelo de cascada

Modelo de desarrollo ágil o XP

Por el contrario, algunas disciplinas de software emergentes, como la programación extrema y el movimiento de desarrollo de software ágil, se adhieren a un modelo de " desarrollo de software basado en pruebas ". En este proceso, las pruebas unitarias son escritas primero por los ingenieros de software (a menudo con programación por pares en la metodología de programación extrema). Se espera que las pruebas fallen inicialmente. Después de cada prueba fallida, se escribe solo el código suficiente para aprobarla. Esto significa que los conjuntos de pruebas se actualizan continuamente a medida que se descubren nuevas condiciones de falla y casos extremos, y se integran con cualquier prueba de regresión que se desarrolle. Las pruebas unitarias se mantienen junto con el resto del código fuente del software y, en general, se integran en el proceso de compilación (con las pruebas inherentemente interactivas relegadas a un proceso de aceptación de compilación parcialmente manual).

Los objetivos finales de este proceso de prueba son respaldar la integración continua y reducir las tasas de defectos.

Esta metodología aumenta el esfuerzo de prueba realizado por el desarrollo, antes de llegar a cualquier equipo de prueba formal. En algunos otros modelos de desarrollo, la mayor parte de la ejecución de la prueba se produce después de que se han definido los requisitos y se ha completado el proceso de codificación.

Un ciclo de prueba de muestra

Aunque existen variaciones entre organizaciones, existe un ciclo típico de prueba. El siguiente ejemplo es común entre las organizaciones que emplean el modelo de desarrollo Waterfall. Las mismas prácticas se encuentran comúnmente en otros modelos de desarrollo, pero pueden no ser tan claras o explícitas.

  • Análisis de requisitos : las pruebas deben comenzar en la fase de requisitos del ciclo de vida del desarrollo de software. Durante la fase de diseño, los probadores trabajan para determinar qué aspectos de un diseño son probables y con qué parámetros funcionan esas pruebas.
  • Planificación de pruebas: estrategia de pruebas, plan de pruebas, creación de bancos de pruebas. Dado que se llevarán a cabo muchas actividades durante las pruebas, se necesita un plan.
  • Desarrollo de pruebas: procedimientos de prueba, escenarios de prueba, casos de prueba, conjuntos de datos de prueba, scripts de prueba para usar en software de prueba.
  • Ejecución de la prueba: los probadores ejecutan el software en función de los planes y los documentos de prueba y, a continuación, informan al equipo de desarrollo de los errores encontrados. Esta parte puede resultar compleja cuando se realizan pruebas con falta de conocimientos de programación.
  • Informes de prueba: una vez que se completan las pruebas, los evaluadores generan métricas y hacen informes finales sobre su esfuerzo de prueba y si el software probado está listo para su lanzamiento o no.
  • Análisis del resultado de la prueba: o Análisis de Defectos, lo realiza el equipo de desarrollo generalmente junto con el cliente, para decidir qué defectos deben asignarse, repararse, rechazarse (es decir, si el software se encuentra funcionando correctamente) o aplazarse para ser tratados más tarde.
  • Nueva prueba de defectos: una vez que el equipo de desarrollo se ha ocupado de un defecto, el equipo de pruebas vuelve a probarlo.
  • Prueba de regresión : es común tener un pequeño programa de prueba construido a partir de un subconjunto de pruebas, para cada integración de software nuevo, modificado o fijo, con el fin de garantizar que la última entrega no haya arruinado nada y que el producto de software como un todo sigue funcionando correctamente.
  • Cierre de la prueba: una vez que la prueba cumple con los criterios de salida, las actividades como la captura de los productos clave, las lecciones aprendidas, los resultados, los registros y los documentos relacionados con el proyecto se archivan y se utilizan como referencia para proyectos futuros.

Pruebas automatizadas

Artículo principal: Automatización de pruebas

Muchos grupos de programación confían cada vez más en las pruebas automatizadas, especialmente los grupos que utilizan el desarrollo basado en pruebas. Hay muchos marcos para escribir pruebas, y el software de integración continua ejecutará las pruebas automáticamente cada vez que el código se ingrese en un sistema de control de versiones.

Si bien la automatización no puede reproducir todo lo que un humano puede hacer (y todas las formas en que piensa en hacerlo), puede ser muy útil para las pruebas de regresión. Sin embargo, requiere un conjunto de pruebas bien desarrollado de scripts de prueba para que sea realmente útil.

Herramientas de prueba

Las pruebas de programas y la detección de fallas pueden ser de gran ayuda mediante las herramientas de prueba y los depuradores. Las herramientas de prueba / depuración incluyen características como:

Algunas de estas características pueden incorporarse en una sola herramienta compuesta o en un entorno de desarrollo integrado (IDE).

Capturar y reproducir

La captura y reproducción consiste en recopilar escenarios de uso de un extremo a otro mientras se interactúa con una aplicación y convertir estos escenarios en casos de prueba. Las posibles aplicaciones de captura y reproducción incluyen la generación de pruebas de regresión. La herramienta SCARPE captura de forma selectiva un subconjunto de la aplicación en estudio a medida que se ejecuta. JRapture captura la secuencia de interacciones entre un programa Java en ejecución y los componentes del sistema host, como archivos o eventos en las interfaces gráficas de usuario. Luego, estas secuencias se pueden reproducir para realizar pruebas basadas en observaciones. Saieva y col. proponen generar pruebas ad-hoc que reproduzcan los rastros de ejecución del usuario registrados para probar los parches candidatos en busca de errores de seguridad críticos. Pankti recopila perfiles de objetos en producción para generar pruebas unitarias diferenciales enfocadas. Esta herramienta mejora la captura y reproducción con la generación sistemática de oráculos de prueba derivados.

Medición en pruebas de software

Artículo principal: Calidad del software

Las medidas de calidad incluyen temas como corrección, integridad, seguridad y requisitos ISO / IEC 9126 como capacidad, confiabilidad, eficiencia, portabilidad, mantenibilidad, compatibilidad y usabilidad.

Hay una serie de métricas de software de uso frecuente, o medidas, que se utilizan para ayudar a determinar el estado del software o la idoneidad de las pruebas.

Jerarquía de la dificultad de las pruebas

En función del número de casos de prueba necesarios para construir un conjunto de pruebas completo en cada contexto (es decir, un conjunto de pruebas tal que, si se aplica a la implementación bajo prueba, recopilamos suficiente información para determinar con precisión si el sistema es correcto o incorrecto según alguna especificación), se ha propuesto una jerarquía de dificultad de prueba. Incluye las siguientes clases de testabilidad :

  • Clase I: existe un conjunto de pruebas completo finito.
  • Clase II: cualquier tasa de distinción parcial (es decir, cualquier capacidad incompleta para distinguir sistemas correctos de sistemas incorrectos) se puede alcanzar con una serie de pruebas finita.
  • Clase III: existe un conjunto de pruebas completo contable.
  • Clase IV: existe una suite de pruebas completa.
  • Clase V: todos los casos.

Se ha demostrado que cada clase está estrictamente incluida en la siguiente. Por ejemplo, probar cuando asumimos que el comportamiento de la implementación bajo prueba puede ser denotado por una máquina determinista de estados finitos para algunos conjuntos finitos conocidos de entradas y salidas y con un número conocido de estados pertenece a la Clase I (y todas las clases subsecuentes). Sin embargo, si no se conoce el número de estados, solo pertenece a todas las clases desde la Clase II en adelante. Si la implementación bajo prueba debe ser una máquina determinista de estados finitos que no cumple con la especificación para una sola traza (y sus continuaciones), y se desconoce su número de estados, entonces solo pertenece a las clases de la Clase III en adelante. Probar máquinas temporales donde las transiciones se activan si las entradas se producen dentro de un intervalo acotado real solo pertenece a clases desde la Clase IV en adelante, mientras que probar muchos sistemas no deterministas solo pertenece a la Clase V (pero no a todos, y algunos incluso pertenecen a la Clase I). La inclusión en la Clase I no requiere la simplicidad del modelo de cálculo asumido, ya que algunos casos de prueba que involucran implementaciones escritas en cualquier lenguaje de programación y las implementaciones de prueba definidas como máquinas que dependen de magnitudes continuas, han demostrado estar en la Clase I.Otros elaborados los casos, como el marco de prueba de Matthew Hennessy bajo la semántica de must, y las máquinas temporales con tiempos de espera racionales, pertenecen a la Clase II.

Prueba de artefactos

Un proceso de prueba de software puede producir varios artefactos. Los artefactos reales producidos son un factor del modelo de desarrollo de software utilizado, las necesidades de las partes interesadas y de la organización.

Plan de prueba
Un plan de prueba es un documento que detalla el enfoque que se tomará para las actividades de prueba previstas. El plan puede incluir aspectos tales como objetivos, alcance, procesos y procedimientos, requisitos de personal y planes de contingencia. El plan de prueba puede venir en forma de un plan único que incluye todos los tipos de prueba (como un plan de prueba de aceptación o del sistema) y consideraciones de planificación, o puede emitirse como un plan de prueba maestro que proporciona una descripción general de más de una prueba detallada. plan (un plan de un plan). Un plan de prueba puede ser, en algunos casos, parte de una amplia " estrategia de prueba " que documenta los enfoques generales de prueba, que puede ser en sí mismo un plan de prueba maestro o incluso un artefacto separado.
Matriz de trazabilidad
Una matriz de trazabilidad es una tabla que correlaciona los requisitos o los documentos de diseño con los documentos de prueba. Se utiliza para cambiar las pruebas cuando se modifican los documentos de origen relacionados, para seleccionar casos de prueba para su ejecución al planificar las pruebas de regresión considerando la cobertura de requisitos.
Caso de prueba
Un caso de prueba normalmente consta de un identificador único, referencias de requisitos de una especificación de diseño, condiciones previas, eventos, una serie de pasos (también conocidos como acciones) a seguir, entrada, salida, resultado esperado y el resultado real. Definido clínicamente, un caso de prueba es una entrada y un resultado esperado. Esto puede ser tan conciso como "para la condición x, el resultado derivado es y", aunque normalmente los casos de prueba describen con más detalle el escenario de entrada y los resultados que se pueden esperar. Ocasionalmente, puede ser una serie de pasos (pero a menudo los pasos están contenidos en un procedimiento de prueba separado que se puede ejecutar en múltiples casos de prueba, como una cuestión de economía) pero con un resultado esperado o un resultado esperado. Los campos opcionales son un ID de caso de prueba, un paso de prueba o un número de orden de ejecución, los requisitos relacionados, la profundidad, la categoría de la prueba, el autor y las casillas de verificación para determinar si la prueba es automatizada y se ha automatizado. Los casos de prueba más grandes también pueden contener estados o pasos de requisitos previos y descripciones. Un caso de prueba 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 otros repositorios comunes. En un sistema de base de datos, también puede ver los resultados de pruebas anteriores, quién generó los resultados y qué configuración del sistema se utilizó para generar esos resultados. Estos resultados pasados ​​generalmente se almacenarían en una tabla separada.
Secuencia de comandos de prueba
Un script de prueba es un procedimiento o código de programación que replica las acciones del usuario. Inicialmente, el término se derivó del producto del trabajo creado por herramientas de prueba de regresión automatizadas. Un caso de prueba será una línea de base para crear scripts de prueba usando una herramienta o un programa.
Banco de pruebas
El término más común para una colección de casos de prueba es un conjunto de pruebas. El conjunto de pruebas a menudo también contiene instrucciones u objetivos más detallados para cada colección de casos de prueba. Definitivamente contiene una sección donde el probador identifica la configuración del sistema utilizada durante la prueba. Un grupo de casos de prueba también puede contener estados o pasos de requisitos previos y descripciones de las siguientes pruebas.
Dispositivo de prueba o datos de prueba
En la mayoría de los casos, se utilizan varios conjuntos de valores o datos para probar la misma funcionalidad de una característica en particular. Todos los valores de prueba y los componentes ambientales cambiables se recopilan en archivos separados y se almacenan como datos de prueba. También es útil proporcionar estos datos al cliente y con el producto o proyecto. Existen técnicas para generar datos de prueba.
Arnés de prueba
El software, las herramientas, las muestras de entrada y salida de datos y las configuraciones se denominan colectivamente arnés de prueba.
Prueba de funcionamiento
Un informe de los resultados de ejecutar un caso de prueba o un conjunto de pruebas.

Certificaciones

Más información: Certificación § En pruebas de software

Existen varios programas de certificación para respaldar las aspiraciones profesionales de los probadores de software y los especialistas en garantía de calidad. Tenga en cuenta que algunos profesionales argumentan que el campo de las pruebas no está listo para la certificación, como se menciona en la sección de controversias.

Controversia

Algunas de las principales controversias sobre las pruebas de software incluyen:

Ágil vs.tradicional
¿Deberían los probadores aprender a trabajar en condiciones de incertidumbre y cambio constante o deberían apuntar a la "madurez" del proceso ? El movimiento de pruebas ágiles ha recibido una popularidad creciente desde 2006 principalmente en los círculos comerciales, mientras que los proveedores de software gubernamentales y militares utilizan esta metodología, pero también los modelos tradicionales de última prueba (por ejemplo, en el modelo Waterfall ).
Pruebas manuales frente a pruebas automatizadas
Algunos escritores creen que la automatización de pruebas es tan cara en relación con su valor que debería utilizarse con moderación. Entonces, la automatización de la prueba puede considerarse como una forma de capturar e implementar los requisitos. Como regla general, cuanto mayor sea el sistema y mayor la complejidad, mayor será el ROI en la automatización de pruebas. Además, la inversión en herramientas y experiencia se puede amortizar en varios proyectos con el nivel adecuado de intercambio de conocimientos dentro de una organización.
¿Se justifica la existencia del estándar de pruebas de software ISO 29119 ?
Se ha formado una oposición significativa entre las filas de la escuela de pruebas de software basada en el contexto sobre el estándar ISO 29119. Las asociaciones profesionales de pruebas, como la Sociedad Internacional de Pruebas de Software, han intentado que se retire el estándar.
Algunos profesionales declaran que el campo de prueba no está listo para la certificación.
Ninguna certificación que se ofrece ahora requiere que el solicitante demuestre su capacidad para probar software. Ninguna certificación se basa en un cuerpo de conocimientos ampliamente aceptado. La certificación en sí misma no puede medir la productividad, habilidad o conocimiento práctico de un individuo, y no puede garantizar su competencia o profesionalismo como evaluador.
Estudios utilizados para mostrar el costo relativo de reparar defectos.
Hay puntos de vista opuestos sobre la aplicabilidad de los estudios utilizados para mostrar el costo relativo de corregir defectos en función de su introducción y detección. Por ejemplo:

Se cree comúnmente que cuanto antes se encuentra un defecto, más barato es repararlo. La siguiente tabla muestra el costo de reparar el defecto según la etapa en la que se encontró. Por ejemplo, si un problema en los requisitos se encuentra solo después del lanzamiento, entonces costaría entre 10 y 100 veces más solucionarlo que si ya se hubiera detectado en la revisión de requisitos. Con el advenimiento de las prácticas modernas de implementación continua y los servicios basados ​​en la nube, el costo de la reimplementación y el mantenimiento puede disminuir con el tiempo.

Costo de arreglar un defecto Tiempo detectado
Requisitos Arquitectura Construcción Prueba del sistema Posteriores a la liberación
Hora introducida Requisitos 1 × 3 × 5–10 × 10 × 10-100 ×
Arquitectura - 1 × 10 × 15 × 25-100 ×
Construcción - - 1 × 10 × 10-25 ×

Los datos de los que se extrapola esta tabla son escasos. Laurent Bossavit dice en su análisis:

La curva de "proyectos más pequeños" resulta ser de sólo dos equipos de estudiantes de primer año, un tamaño de muestra tan pequeño que extrapolar a "proyectos más pequeños en general" es totalmente indefendible. El estudio de GTE no explica sus datos, aparte de decir que provienen de dos proyectos, uno grande y otro pequeño. El documento citado para el proyecto "Safeguard" de Bell Labs niega específicamente haber recopilado los datos detallados que sugieren los puntos de datos de Boehm. El estudio de IBM (el artículo de Fagan) contiene afirmaciones que parecen contradecir el gráfico de Boehm y ningún resultado numérico que se corresponda claramente con sus puntos de datos.

Boehm ni siquiera cita un artículo para los datos de TRW, excepto cuando escribió para "Making Software" en 2010, y allí citó el artículo original de 1976. Existe un gran estudio realizado en TRW en el momento adecuado para que Boehm lo cite, pero ese documento no contiene el tipo de datos que respaldarían las afirmaciones de Boehm.

Procesos relacionados

Verificación y validación de software

Artículos principales: Verificación y validación (software) y Control de calidad del software

Las pruebas de software se utilizan en asociación con la verificación y validación :

  • Verificación: ¿Hemos construido el software correctamente? (es decir, implementa los requisitos).
  • Validación: ¿Hemos creado el software adecuado? (es decir, los entregables satisfacen al cliente).

Los términos verificación y validación se usan comúnmente de manera intercambiable en la industria; También es común ver estos dos términos definidos con definiciones contradictorias. De acuerdo con el Glosario estándar de terminología de ingeniería de software de IEEE :

La verificación es el proceso de evaluar un sistema o componente para determinar si los productos de una determinada fase de desarrollo satisfacen las condiciones impuestas al inicio de esa fase.
La validación es el proceso de evaluar un sistema o componente durante o al final del proceso de desarrollo para determinar si satisface los requisitos especificados.

Y, según la norma ISO 9000:

La verificación es la confirmación mediante examen y mediante la provisión de evidencia objetiva de que se han cumplido los requisitos especificados.
La validación es la confirmación mediante examen y mediante la provisión de evidencia objetiva de que se han cumplido los requisitos para un uso o aplicación específicos previstos.

La contradicción se debe al uso de los conceptos de requisitos y requisitos especificados, pero con significados diferentes.

En el caso de los estándares IEEE, los requisitos especificados, mencionados en la definición de validación, son el conjunto de problemas, necesidades y deseos de las partes interesadas que el software debe resolver y satisfacer. Dichos requisitos están documentados en una Especificación de requisitos de software (SRS). Y los productos mencionados en la definición de verificación son los artefactos de salida de cada fase del proceso de desarrollo de software. Estos productos son, de hecho, especificaciones tales como Especificación de diseño arquitectónico, Especificación de diseño detallado, etc. El SRS también es una especificación, pero no se puede verificar (al menos no en el sentido utilizado aquí, más sobre este tema a continuación).

Pero, para la ISO 9000, los requisitos especificados son el conjunto de especificaciones, como se mencionó anteriormente, que deben verificarse. Una especificación, como se explicó anteriormente, es el producto de una fase del proceso de desarrollo de software que recibe otra especificación como entrada. Una especificación se verifica con éxito cuando implementa correctamente su especificación de entrada. Todas las especificaciones se pueden verificar excepto el SRS porque es el primero (aunque se puede validar). Ejemplos: La Especificación de Diseño debe implementar el SRS; y los artefactos de la fase de Construcción deben implementar la Especificación de Diseño.

Entonces, cuando estas palabras se definen en términos comunes, la aparente contradicción desaparece.

Tanto el SRS como el software deben estar validados. El SRS se puede validar estáticamente consultando con las partes interesadas. Sin embargo, ejecutar alguna implementación parcial del software o un prototipo de cualquier tipo (pruebas dinámicas) y obtener una retroalimentación positiva de ellos, puede aumentar aún más la certeza de que el SRS está correctamente formulado. Por otro lado, el software, como producto final y en ejecución (no sus artefactos y documentos, incluido el código fuente) debe validarse dinámicamente con las partes interesadas ejecutando el software y haciendo que lo prueben.

Algunos podrían argumentar que, para SRS, la entrada son las palabras de las partes interesadas y, por lo tanto, la validación de SRS es lo mismo que la verificación de SRS. Pensar de esta manera no es aconsejable ya que solo genera más confusión. Es mejor pensar en la verificación como un proceso que involucra un documento de entrada formal y técnico.

Aseguramiento de la calidad del software

Las pruebas de software pueden considerarse parte de un proceso de aseguramiento de la calidad del software (SQA). En SQA, los especialistas en procesos de software y los auditores se preocupan por el proceso de desarrollo de software y no solo por los artefactos como la documentación, el código y los sistemas. Examinan y cambian el proceso de ingeniería del software en sí para reducir el número de fallas que terminan en el software entregado: la denominada tasa de defectos. Lo que constituye una tasa de defectos aceptable depende de la naturaleza del software; un videojuego de simulador de vuelo tendría una tolerancia a defectos mucho mayor que el software para un avión real. Aunque existen vínculos estrechos con SQA, los departamentos de pruebas a menudo existen de forma independiente y es posible que no exista una función de SQA en algunas empresas.

La prueba de software es una actividad para investigar el software que se está probando con el fin de proporcionar información relacionada con la calidad a las partes interesadas. Por el contrario, QA ( garantía de calidad ) es la implementación de políticas y procedimientos destinados a evitar que los defectos lleguen a los clientes.

Ver también

Referencias

Otras lecturas

enlaces externos

Contactos: mail@wikibrief.org
El contenido está disponible bajo la licencia CC BY-SA 3.0 (a menos que se indique lo contrario).