stringtranslate.com

Pruebas de software

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

La prueba de software es el acto de verificar si el software satisface las expectativas.

Las pruebas de software pueden proporcionar información objetiva e independiente sobre la calidad del software y el riesgo de que falle para un usuario o patrocinador. [1]

Las pruebas de software pueden determinar la corrección del software para escenarios específicos , pero no pueden determinar la corrección para todos los escenarios. [2] [3] No puede encontrar todos los errores .

Basándose en los criterios de medición de la exactitud de un oráculo , las pruebas de software emplean principios y mecanismos que podrían reconocer un problema. Algunos ejemplos de oráculos son: especificaciones , contratos , [4] productos comparables, versiones anteriores del mismo producto, inferencias sobre el propósito previsto o esperado, expectativas del usuario o del cliente, estándares relevantes y leyes aplicables.

Las pruebas de software suelen ser dinámicas por naturaleza: se ejecuta el software para verificar que el resultado real coincida con lo esperado. También pueden ser estáticas por naturaleza: se revisa el código y su documentación asociada .

Las pruebas de software se utilizan a menudo para responder a la pregunta: ¿El software hace lo que se supone que debe hacer y lo que necesita hacer?

La información obtenida a partir de las pruebas de software se puede utilizar para mejorar el proceso de desarrollo del software. [5] : 41–43 

Las pruebas de software deben seguir un enfoque de "pirámide" en el que la mayoría de las pruebas deben ser pruebas unitarias , seguidas de pruebas de integración y, finalmente, las pruebas de extremo a extremo (e2e) deben tener la proporción más baja. [6] [7] [8]

Ciencias económicas

Un estudio realizado por el NIST en 2002 reveló que los errores de software le cuestan a la economía estadounidense 59.500 millones de dólares al año. Más de un tercio de este costo podría evitarse si se realizaran mejores pruebas de software. [9] [ dudosodiscutir ]

La subcontratación de pruebas de software debido a los costos es muy común, y China, Filipinas e India son los destinos preferidos. [ cita requerida ]

Historia

Glenford J. Myers introdujo inicialmente la separación entre la depuración y las pruebas en 1979. [10] Aunque su atención se centraba en las pruebas de fallas ("Un caso de prueba exitoso es aquel que detecta un error aún no descubierto". [10] : 16  ), ilustró el deseo de la comunidad de ingeniería de software de separar las actividades fundamentales de desarrollo, como la depuración, de las de verificación.

Objetivos

Las pruebas de software generalmente están orientadas a objetivos.

Encontrar errores

Las pruebas de software generalmente incluyen el manejo de errores de software: un defecto en el código que causa un resultado no deseado. [11] : 31  Los errores generalmente ralentizan el progreso de las pruebas e involucran la asistencia del programador para depurarlos y corregirlos.

No todos los defectos provocan un fallo. Por ejemplo, un defecto en un código inactivo no se considerará un fallo.

Un defecto que no causa una falla en un momento dado puede volver a ocurrir debido a cambios ambientales. Algunos ejemplos de cambios ambientales incluyen el uso de un nuevo hardware informático , cambios en los datos e interacción con un software diferente. [12]

Un solo defecto puede provocar múltiples síntomas de falla.

Garantizar que se cumplan los requisitos

Las pruebas de software pueden implicar una brecha de requisitos: la omisión de un requisito en el diseño. [5] : 426  Las brechas de requisitos a menudo pueden ser requisitos no funcionales, como capacidad de prueba , escalabilidad , capacidad de mantenimiento , rendimiento y seguridad .

Cobertura del código

Una limitación fundamental de las pruebas de software es que no es posible realizar pruebas bajo todas las combinaciones de entradas y precondiciones (estado inicial), ni siquiera con un producto simple. [3] : 17–18  [13] Los defectos que se manifiestan en condiciones inusuales son difíciles de encontrar en las pruebas. Además, las dimensiones no funcionales de la calidad (cómo se supone que debe ser versus lo que se supone que debe hacer ) – usabilidad , escalabilidad , rendimiento , compatibilidad y confiabilidad – pueden ser subjetivas; algo que constituye un valor suficiente para una persona puede no serlo para otra.

Aunque no es posible realizar pruebas para cada entrada posible, es posible realizar pruebas mediante la combinación de métodos para maximizar la cobertura y minimizar las pruebas. [14]

Categorización

Las pruebas se pueden clasificar de muchas maneras. [15]

Pruebas automatizadas

En las pruebas de software, la automatización de pruebas es el uso de software independiente del software que se está probando para controlar la ejecución de las pruebas y la comparación de los resultados reales con los resultados previstos. [16] La automatización de pruebas puede automatizar algunas tareas repetitivas pero necesarias en un proceso de prueba formalizado ya implementado, o realizar pruebas adicionales que serían difíciles de hacer manualmente. La automatización de pruebas es fundamental para la entrega continua y las pruebas continuas . [17]

Niveles

Las pruebas de software se pueden clasificar en niveles según qué parte del sistema de software es el foco de una prueba. [18] [19] [20] [21]

Pruebas unitarias

Las pruebas unitarias , también conocidas como pruebas de componentes o módulos, son una forma de prueba de software mediante la cual se prueba un código fuente aislado para validar el comportamiento esperado. [22]

Pruebas de integración

Las pruebas de integración , también llamadas integración y pruebas, abreviadas I&T, son una forma de prueba de software en la que se prueban varias partes de un sistema de software como un grupo.

Prueba del sistema

Las pruebas del sistema , también conocidas como pruebas de extremo a extremo (E2E), son pruebas que se realizan en un sistema de software completo .

Pruebas estáticas, dinámicas y pasivas

Existen muchos enfoques para las pruebas de software. Las revisiones , los recorridos o las 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 pruebas dinámicas . [23] [24]

Las pruebas estáticas suelen ser implícitas, como la corrección de pruebas, además de 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 estático del programa . Las pruebas dinámicas tienen lugar cuando se ejecuta el programa en sí. Las pruebas dinámicas pueden comenzar antes de que el programa esté 100% completo para probar secciones particulares del código y se aplican a funciones o módulos discretos. [23] [24] Las técnicas típicas para esto son el uso de stubs /drivers o la ejecución desde un entorno de depuración . [24]

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

Las pruebas pasivas implican verificar el comportamiento del sistema sin ninguna interacción con el producto de software. A diferencia de las pruebas activas, los evaluadores no proporcionan ningún dato de prueba, sino que observan los registros y rastros del sistema. Extraen patrones y comportamientos específicos para tomar algún tipo de decisión. [25] Esto está relacionado con la verificación en tiempo de ejecución sin conexión y el análisis de registros .

Exploratorio

Las pruebas exploratorias son un enfoque de las pruebas de software que se describe de forma concisa como aprendizaje simultáneo, diseño de pruebas y ejecución de pruebas. Cem Kaner , quien acuñó el término en 1984, [26] define las pruebas exploratorias como "un estilo de pruebas de software que enfatiza la libertad y la responsabilidad personal del evaluador individual para optimizar continuamente la calidad de su trabajo al tratar el aprendizaje relacionado con las pruebas, el diseño de pruebas, la ejecución de pruebas y la interpretación de los resultados de las pruebas como actividades que se apoyan mutuamente y que se ejecutan en paralelo durante todo el proyecto". [27]

Pruebas preestablecidas vs. pruebas adaptativas

El tipo de estrategia de pruebas a realizar depende de si las pruebas que se aplicarán a la IUT deben decidirse antes de que comience a ejecutarse el plan de pruebas (pruebas preestablecidas [28] ) o si cada entrada que se aplicará a la IUT puede depender dinámicamente de las salidas obtenidas durante la aplicación de las pruebas anteriores (pruebas adaptativas [29] [30] ).

Caja negra y blanca

Las pruebas de software a menudo se pueden dividir en caja blanca y caja negra. Estos dos enfoques se utilizan para describir el punto de vista que adopta el evaluador al diseñar casos de prueba. Un enfoque híbrido llamado caja gris incluye aspectos de ambas cajas y también se puede aplicar a la metodología de pruebas de software. [31] [32]

Prueba de caja blanca

Diagrama de prueba de caja blanca
Diagrama de prueba de caja blanca

Las pruebas de caja blanca (también conocidas como pruebas de caja transparente, pruebas de caja de vidrio, pruebas de caja transparente y pruebas estructurales) verifican 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 evaluador elige entradas para ejercitar rutas a través del código y determina las salidas apropiadas. [31] [32] 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 en los niveles de unidad , integración y sistema del proceso de prueba de software, generalmente se realizan en el nivel de unidad. [33] 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 pruebas 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: [32] [34]

Las herramientas de cobertura de código pueden evaluar la integridad de un conjunto de pruebas creado 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. [35] La cobertura de código como métrica de software se puede informar como un porcentaje para: [31] [35] [36]

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

La cobertura del 100 % de las declaraciones garantiza que todas las rutas o ramas del código (en términos de flujo de control ) se ejecuten al menos una vez. Esto es útil para garantizar una funcionalidad correcta, pero no es suficiente, ya que el mismo código puede procesar diferentes entradas de manera correcta o incorrecta. [37]

Prueba de caja negra

Diagrama de caja negra

Las pruebas de caja negra (también conocidas como pruebas funcionales) describen el diseño de casos de prueba sin conocimiento de la implementación, sin leer el código fuente. Los evaluadores solo saben lo que se supone que debe hacer el software, no cómo lo hace. [38] Los métodos de prueba de caja negra incluyen: partición de equivalencia , análisis de valores límite , pruebas de todos los pares , tablas de transición de estados , pruebas de tabla de decisión , pruebas difusas , pruebas basadas en modelos , pruebas de casos de uso , pruebas exploratorias y pruebas basadas en especificaciones. [31] [32] [36]

Las pruebas basadas en especificaciones tienen como objetivo probar la funcionalidad del software de acuerdo con los requisitos aplicables. [39] Este nivel de pruebas generalmente requiere que se proporcionen casos de prueba exhaustivos al evaluador, quien luego puede simplemente verificar que para una entrada dada, el valor de salida (o comportamiento), ya sea "es" o "no es" el mismo que el valor esperado especificado en el caso de prueba. Los casos de prueba se construyen en torno a 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 generalmente funcionales. Las pruebas basadas en especificaciones pueden ser necesarias para asegurar la funcionalidad correcta, pero son insuficientes para protegerse contra situaciones complejas o de alto riesgo. [40]

Las pruebas de caja negra se pueden utilizar en cualquier nivel de prueba, aunque normalmente no a nivel de unidad. [33]

Prueba de interfaz de componentes

Las pruebas de interfaz de componentes son una variación de las pruebas de caja negra , con el foco en los valores de los datos más allá de las acciones relacionadas de un componente del subsistema. [41] La práctica de las pruebas de interfaz de componentes se puede utilizar para verificar el manejo de los datos que pasan entre varias unidades o componentes del subsistema, más allá de las pruebas de integración completa entre esas unidades. [42] [43] Los datos que se pasan pueden considerarse como "paquetes de mensajes" y se puede verificar el rango o los tipos de datos, para los datos generados desde una unidad, y probar su validez antes de pasarlos 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 la verificación del manejo de algunos valores de datos extremos mientras que otras variables de interfaz se pasan como valores normales. [42] Los valores de datos inusuales en una interfaz pueden ayudar a explicar el rendimiento inesperado en la siguiente unidad.

Prueba visual

El objetivo de las pruebas visuales es proporcionar a los desarrolladores la capacidad de examinar lo que estaba sucediendo en el momento de la falla del software presentando los datos de tal manera que el desarrollador pueda encontrar fácilmente la información que necesita y la información se exprese claramente. [44] [45]

En el centro de las pruebas visuales está la idea de que mostrarle a alguien un problema (o un fallo de prueba), en lugar de simplemente describirlo, aumenta enormemente la claridad y la comprensión. Por lo tanto, las pruebas visuales requieren la grabación de todo el proceso de prueba, es decir, capturar todo lo que ocurre en el sistema de prueba en formato de video. Los videos de salida se complementan con la entrada en tiempo real del evaluador a través de una cámara web con imagen en imagen y comentarios de audio de 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 provocaron) al desarrollador en lugar de simplemente describirlo y, en muchos casos, ya no será necesario replicar los errores de las pruebas. El desarrollador tendrá todas las pruebas que necesite de un error de prueba y podrá centrarse en la causa del fallo y en cómo solucionarlo.

Las pruebas ad hoc y exploratorias son metodologías importantes para verificar la integridad del software, porque requieren menos tiempo de preparación para su implementación, mientras que los errores importantes se pueden encontrar rápidamente. [46] En las pruebas ad hoc, donde las pruebas se realizan de manera improvisada, la capacidad del o los evaluadores de basar las pruebas en métodos documentados y luego improvisar variaciones de esas pruebas puede dar como resultado un examen más riguroso de las correcciones de defectos. [46] 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. [46]

Prueba de caja gris

Las pruebas de caja gris (en inglés, gray-box testing) implican el uso de los conocimientos sobre las estructuras de datos internas y los algoritmos con el fin de diseñar pruebas mientras se ejecutan esas pruebas en el nivel de usuario o de caja negra. El evaluador a menudo tendrá acceso tanto al "código fuente como al binario ejecutable". [47] Las pruebas de caja gris también pueden incluir ingeniería inversa (utilizando análisis de código dinámico) para determinar, por ejemplo, valores límite o mensajes de error. [47] La ​​manipulación de los datos de entrada y el formateo de la salida no se califican como pruebas de 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 las interfaces están expuestas 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 afuera. Por lo general, a un evaluador de caja gris se le permitirá configurar un entorno de prueba aislado con actividades como la inicialización de una base de datos . El evaluador puede observar el estado del producto que se está probando después de realizar ciertas acciones, como ejecutar sentencias SQL contra 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. [48]

Con el concepto de pruebas de caja gris, esta "distinción arbitraria" entre pruebas de caja negra y pruebas de caja blanca se ha desvanecido un poco. [33]

Prueba de instalación

La mayoría de los sistemas de software tienen procedimientos de instalación que son necesarios antes de que puedan utilizarse 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 . [49] : 139  Estos procedimientos pueden implicar actualizaciones totales o parciales y procesos de instalación/desinstalación.

  • Un usuario debe seleccionar una variedad de opciones.
  • Los archivos y bibliotecas dependientes deben asignarse, cargarse o ubicarse.
  • Deben estar presentes configuraciones de hardware válidas.
  • Los sistemas de software pueden necesitar conectividad para conectarse a otros sistemas de software. [49] : 145 

Prueba de compatibilidad

Una causa común de falla de software (real o percibida) es la falta de compatibilidad con otro software de aplicación , sistemas operativos (o versiones de sistemas operativos , antiguas o nuevas) o entornos de destino que difieren en gran medida del original (como una aplicación de terminal o GUI destinada a ejecutarse en el escritorio que ahora se requiere que se convierta en una aplicación web , que debe mostrarse 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 puede que no todos los usuarios estén ejecutando. Esto da como resultado la consecuencia no deseada de que el último trabajo puede no funcionar 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 abstrayendo de manera proactiva la funcionalidad del sistema operativo en un módulo o biblioteca de programa independiente .

Pruebas de humo y de cordura

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 existen problemas básicos que impidan su funcionamiento. Estas pruebas se pueden utilizar como prueba de verificación de la compilación .

Prueba de regresión

Las pruebas de regresión se centran en encontrar defectos después de que se haya producido un cambio importante en el código. Específicamente, buscan descubrir regresiones de software , como características degradadas o perdidas, incluidos errores antiguos que han regresado. Tales regresiones ocurren siempre que la funcionalidad del software que anteriormente funcionaba correctamente, deja de funcionar como se esperaba. Por lo general, las regresiones ocurren como una consecuencia no deseada de los cambios del programa, cuando la parte recién desarrollada del software colisiona con el código previamente existente. Las pruebas de regresión suelen ser el mayor esfuerzo de prueba en el desarrollo de software comercial, [50] debido a la verificación de numerosos detalles en las características del software anterior, 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 se admita.

Los métodos habituales de pruebas de regresión incluyen volver a ejecutar conjuntos de casos de prueba anteriores y comprobar si han vuelto a aparecer los fallos corregidos anteriormente. La profundidad de las pruebas depende de la fase del proceso de lanzamiento y del riesgo de las características añadidas. Pueden ser completas, en el caso de los cambios añadidos en una fase avanzada del lanzamiento o que se consideren arriesgados, o muy superficiales, consistentes en pruebas positivas de cada característica, si los cambios se realizan en una fase temprana del lanzamiento o se consideran de bajo riesgo.

Prueba de aceptación

Las pruebas de aceptación son pruebas a nivel de sistema para garantizar que el software cumpla con las expectativas del cliente. [51] [52] [53] [54]

Las pruebas de aceptación pueden realizarse como parte del proceso de transferencia entre dos fases de desarrollo. [ cita requerida ]

Las pruebas se agrupan frecuentemente en estos niveles según dónde se realizan en el proceso de desarrollo de software o según el nivel de especificidad de la prueba. [54]

A veces, la UAT la realiza el cliente, en su entorno y en su propio hardware.

La OAT 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 calidad . La 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 que se va a respaldar o que se va a convertir 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 (OR&A). Las pruebas funcionales dentro de la 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 o corrompa parcialmente su entorno operativo ni provoque que otros procesos dentro de ese entorno dejen de funcionar. [55]

Las pruebas de aceptación contractual se realizan en función de los criterios de aceptación del contrato definidos durante el acuerdo del contrato, mientras que las pruebas de aceptación regulatorias se realizan en función de las regulaciones pertinentes al producto de software. Ambas pruebas pueden ser realizadas por usuarios o evaluadores independientes. Las pruebas de aceptación regulatorias a veces implican que las agencias regulatorias auditen los resultados de las pruebas. [54]

Prueba alfa

Las pruebas alfa son pruebas operativas simuladas o reales que realizan usuarios/clientes potenciales o un equipo de pruebas independiente en las instalaciones de los desarrolladores. Las pruebas alfa se emplean a menudo para software comercial como una forma de prueba de aceptación interna antes de que el software pase a la fase de prueba beta. [56]

Prueba beta

Las pruebas beta se realizan 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, conocida como probadores beta. El software se lanza a grupos de personas para que las pruebas posteriores 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 retroalimentación a un número máximo de futuros usuarios y para entregar valor antes, durante un período de tiempo extendido o incluso indefinido ( beta perpetua ). [57]

Pruebas funcionales y 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 usuario. Las pruebas funcionales tienden a responder a la pregunta "¿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

Las pruebas continuas son el proceso de ejecutar pruebas automatizadas como parte del proceso de entrega de software para obtener retroalimentación inmediata sobre los riesgos comerciales asociados con un candidato a lanzamiento de software. [58] [59] 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 de abajo hacia arriba o las historias de usuario hasta la evaluación de los requisitos del sistema asociados con los objetivos comerciales generales. [60] [61]

Pruebas destructivas

Las pruebas destructivas intentan provocar que el software o un subsistema falle. Verifican 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 entradas y gestión de errores. [ cita requerida ] La inyección de fallas de software , en forma de fuzzing , es un ejemplo de prueba de fallas. Varias herramientas comerciales de prueba no funcional están vinculadas desde la página de inyección de fallas de software ; también hay numerosas herramientas de software libre y de código abierto disponibles que realizan pruebas destructivas.

Pruebas de rendimiento de software

Las pruebas de rendimiento se realizan generalmente para determinar el rendimiento de un sistema o subsistema en términos de capacidad de respuesta y estabilidad bajo una carga de trabajo particular. También pueden servir para investigar, medir, validar o verificar otros atributos de calidad del sistema, como la escalabilidad, la confiabilidad y el uso de recursos.

Las pruebas de carga se ocupan principalmente de probar que el sistema puede seguir funcionando bajo una carga específica, ya sea grandes cantidades de datos o una gran cantidad de usuarios . Esto generalmente se conoce como escalabilidad del software . La actividad de prueba de carga relacionada, cuando se realiza como una actividad no funcional, a menudo se conoce como prueba de resistencia . Las pruebas de volumen son 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 manera continua durante un período aceptable o por encima de él.

Existe poco consenso sobre cuáles son los objetivos específicos de las pruebas de rendimiento. Los términos pruebas de carga, pruebas de rendimiento, pruebas de escalabilidad y pruebas de volumen suelen usarse indistintamente.

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

Pruebas de usabilidad

Las pruebas de usabilidad sirven para comprobar si la interfaz de usuario es fácil de usar y comprender. Se centran principalmente en el uso de la aplicación. No se trata de un tipo de prueba que se pueda automatizar; se necesitan usuarios humanos reales supervisados ​​por diseñadores de interfaz de usuario expertos .

Pruebas de accesibilidad

Las pruebas de accesibilidad se realizan para garantizar que el software sea accesible para personas con discapacidades. Algunas de las pruebas de accesibilidad web más comunes son:

Normas comunes de cumplimiento

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 el que un elemento de prueba, y los datos e información asociados, están protegidos de modo que personas o sistemas no autorizados no puedan usarlos, leerlos o modificarlos, y a las personas o sistemas autorizados no se les niegue el acceso a ellos". [62]

Internacionalización y localización

Las pruebas de internacionalización y localización validan que el software se puede utilizar en 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 errores en el producto.

Las pruebas de globalización verifican que el software esté adaptado a una nueva cultura, como diferentes monedas o zonas horarias. [63]

También es necesario probar la traducción real a los idiomas humanos. Entre los posibles errores de localización y globalización se incluyen los siguientes:

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 con el fin de reducir los riesgos, el tiempo y los costos del desarrollo de software. Las 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 promocione para 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 por pares, pruebas unitarias, análisis de cobertura de código, trazabilidad y otras prácticas de pruebas de software.

Prueba A/B

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

Pruebas concurrentes

Las pruebas concurrentes o de concurrencia evalúan el comportamiento y el rendimiento del software y los sistemas que utilizan computación concurrente , generalmente en condiciones de uso normales. Los problemas típicos que este tipo de pruebas expondrá son bloqueos, condiciones de carrera y problemas con el manejo de recursos/memoria compartida.

Prueba de conformidad o prueba de tipo

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

Prueba de comparación de salida

La creación de una pantalla con el resultado esperado, ya sea como comparación de datos de texto o capturas de pantalla de la interfaz de usuario, [3] : 195  a veces se denomina prueba de instantáneas o prueba maestra dorada; a diferencia de muchas otras formas de prueba, esta no puede detectar fallas automáticamente y, en cambio, requiere que un humano evalúe el resultado en busca de inconsistencias.

Prueba de propiedad

La prueba de propiedades es una técnica de prueba en la que, en lugar de afirmar que determinadas entradas producen determinadas salidas esperadas, el profesional genera aleatoriamente muchas entradas, ejecuta el programa en todas ellas y afirma la veracidad de alguna "propiedad" que debería ser cierta para cada par de entrada y salida. Por ejemplo, cada salida de una función de serialización debería ser aceptada por la función de deserialización correspondiente, y cada salida de una función de ordenación debería ser una lista monótonamente creciente que contenga exactamente los mismos elementos que su entrada.

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 que presentan patrones específicos que son necesarios para ejercitar completamente 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 Haskell QuickCheck . [64]

Prueba metamórfica

Las pruebas metamórficas (MT) son una técnica de pruebas de software basada en propiedades que puede ser un enfoque eficaz para abordar el problema del oráculo de pruebas y el problema de generación de casos de prueba. El problema del oráculo de pruebas es la dificultad de determinar los resultados esperados de los casos de prueba seleccionados o de determinar si los resultados reales coinciden con los resultados esperados.

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 con el que la comunicación es lenta o poco confiable, a menudo una API de terceros fuera del control del evaluador. Implica hacer 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 se popularizó en el desarrollo web gracias a la biblioteca Ruby vcr.

Trabajo en equipo

Roles

En una organización, los evaluadores pueden estar en un equipo separado del resto del equipo de desarrollo de software o pueden estar integrados en un equipo. Las pruebas de software también pueden ser realizadas por evaluadores de software no especializados.

En la década de 1980, el término probador de software comenzó a usarse para designar una profesión separada.

Los roles y títulos notables en pruebas de software incluyen: [65] gerente de pruebas , líder de pruebas , analista de pruebas , diseñador de pruebas , probador , desarrollador de automatización y administrador de pruebas . [66]

Procesos

Las organizaciones que desarrollan software realizan pruebas de manera diferente, pero existen patrones comunes. [2]

Desarrollo en cascada

En el desarrollo en cascada , las pruebas se realizan generalmente después de que se completa el código, pero antes de que el producto se envíe al cliente. [67] Esta práctica a menudo da como resultado que la fase de prueba se use como un amortiguador del proyecto para compensar los retrasos del proyecto, comprometiendo así el tiempo dedicado a las pruebas. [10] : 145–146 

Algunos sostienen que el proceso en cascada permite que las pruebas comiencen cuando se inicia el proyecto de desarrollo y que sean un proceso continuo hasta que el proyecto finalice. [68]

Desarrollo ágil

El desarrollo de software ágil generalmente implica realizar pruebas mientras se escribe el código y organizar equipos con programadores y evaluadores y con miembros del equipo que realizan tanto la programación como las pruebas.

Una práctica ágil, el desarrollo de software basado en pruebas (TDD), es una forma de realizar pruebas unitarias en las que se realizan pruebas a nivel de unidad mientras se escribe el código del producto. [69] El código de prueba se actualiza a medida que se agregan nuevas características y se descubren condiciones de falla (se corrigen errores). Por lo general, el código de prueba unitaria se mantiene con el código del proyecto, se integra en el proceso de compilación y se ejecuta en cada compilación y como parte de las pruebas de regresión. Los objetivos de esta integración continua son respaldar el desarrollo y reducir los defectos. [70] [69]

Incluso en organizaciones que separan los equipos por funciones de programación y prueba, muchas veces hacen que los programadores realicen pruebas unitarias . [71]

Proceso de muestra

El ejemplo que se muestra a continuación es común para el desarrollo en cascada. Las mismas actividades se encuentran comúnmente en otros modelos de desarrollo, pero podrían describirse de manera diferente.

Calidad

Verificación y validación de software

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

Los términos verificación y validación se utilizan comúnmente de manera intercambiable en la industria; también es común ver estos dos términos definidos con definiciones contradictorias. Según el Glosario estándar IEEE de terminología de ingeniería de software : [11] : 80–81 

La verificación es el proceso de evaluar un sistema o componente para determinar si los productos de una fase de desarrollo determinada 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 aportando pruebas objetivas de que se han cumplido requisitos específicos.
La validación es la confirmación mediante examen y mediante la aportación de pruebas objetivas 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 las normas 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 se documentan 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 como la Especificación de Diseño Arquitectónico, la Especificación de Diseño Detallado, etc. La SRS también es una especificación, pero no se puede verificar (al menos no en el sentido que se le da aquí, más sobre este tema a continuación).

Pero, para la ISO 9000, los requisitos especificados son el conjunto de especificaciones, como se acaba de mencionar, que deben ser verificadas. 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 la SRS porque es la primera (aunque se puede validar). Ejemplos: La Especificación de Diseño debe implementar la SRS; y, los artefactos de la fase de Construcción deben implementar la Especificación de Diseño.

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

Tanto el SRS como el software deben ser validados. El SRS puede ser validado estáticamente consultando a las partes interesadas. Sin embargo, ejecutar una implementación parcial del software o un prototipo de cualquier tipo (prueba dinámica) y obtener 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 funcionamiento (no sus artefactos y documentos, incluido el código fuente) debe ser validado dinámicamente con las partes interesadas ejecutando el software y pidiéndoles que lo prueben.

Algunos podrían argumentar que, en el caso de los sistemas de información estadística, el insumo son las palabras de las partes interesadas y, por lo tanto, la validación de los sistemas de información estadística es lo mismo que la verificación de los sistemas de información estadística. 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 implica un documento de insumo formal y técnico.

Garantía de calidad del software

En algunas organizaciones, las pruebas de software forman parte de un proceso de aseguramiento de la calidad del software (SQA, por sus siglas en inglés). [3] : 347  En SQA, los especialistas en procesos de software y los auditores se ocupan del proceso de desarrollo de software, más que solo de los artefactos como la documentación, el código y los sistemas. Examinan y modifican el proceso de ingeniería de software en sí para reducir la cantidad de fallas que terminan en el software entregado: la llamada tasa de defectos. Lo que constituye una tasa de defectos aceptable depende de la naturaleza del software; un videojuego de simulación de vuelo tendría una tolerancia a los 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 puede que no exista una función de SQA en algunas empresas. [ cita requerida ]

La prueba de software es una actividad que se realiza 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, el control de calidad (QA ) es la implementación de políticas y procedimientos destinados a evitar que los defectos lleguen a los clientes.

Medidas

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 o medidas de software que se utilizan con frecuencia para ayudar a determinar el estado del software o la idoneidad de las pruebas.

Artefactos

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

Plan de prueba

Un plan de pruebas es un documento que detalla el enfoque que se adoptará para las actividades de prueba previstas. El plan puede incluir aspectos como objetivos, alcance, procesos y procedimientos, requisitos de personal y planes de contingencia. [51] El plan de pruebas puede presentarse en forma de un único plan que incluya todos los tipos de pruebas (como un plan de pruebas de aceptación o de sistema) y consideraciones de planificación, o puede emitirse como un plan de pruebas maestro que proporcione una descripción general de más de un plan de pruebas detallado (un plan de un plan). [51] Un plan de pruebas puede ser, en algunos casos, parte de una amplia " estrategia de pruebas " que documenta los enfoques generales de las pruebas, que puede ser en sí misma un plan de pruebas maestro o incluso un artefacto separado.

Matriz de trazabilidad

En el desarrollo de software , una matriz de trazabilidad (TM) [73] : 244  es un documento, generalmente en forma de tabla, que se utiliza para ayudar a determinar la integridad de una relación al correlacionar dos documentos de referencia cualesquiera mediante una comparación de relación de muchos a muchos. [73] : 3–22  A menudo se utiliza con requisitos de alto nivel (estos a menudo consisten en requisitos de marketing) y requisitos detallados del producto con las partes correspondientes del diseño de alto nivel , el diseño detallado, el plan de prueba y los casos de prueba .

Caso de prueba

Un caso de prueba normalmente consta de un identificador único, referencias de requisitos de una especificación de diseño, precondiciones, eventos, una serie de pasos (también conocidos como acciones) a seguir, entrada, salida, resultado esperado y el resultado real. Clínicamente definido, un caso de prueba es una entrada y un resultado esperado. [74] Esto puede ser tan conciso como "para la condición x, su resultado derivado es y", aunque normalmente los casos de prueba describen con más detalle el escenario de entrada y qué resultados podrían esperarse. Ocasionalmente puede ser una serie de pasos (pero a menudo los pasos están contenidos en un procedimiento de prueba separado que puede ejercerse contra múltiples casos de prueba, como una cuestión de economía) pero con un resultado esperado o resultado esperado. Los campos opcionales son un ID de caso de prueba, paso de prueba o número de orden de ejecución, requisito(s) relacionado(s), profundidad, categoría de prueba, autor y casillas de verificación para si la prueba es automatizable y ha sido automatizada. Los casos de prueba más grandes también pueden contener estados o pasos de prerrequisitos 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, una hoja de cálculo, una base de datos u otros repositorios comunes. En un sistema de base de datos, también es posible 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 anteriores normalmente se almacenan en una tabla separada.

Guión 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 automatizada. Un caso de prueba será una línea base para crear scripts de prueba utilizando una herramienta o un programa.

Conjunto de pruebas

En el desarrollo de software , una suite de pruebas , menos comúnmente conocida como suite de validación, es una colección de casos de prueba que se pretende utilizar para probar un programa de software para demostrar que tiene un conjunto específico de comportamientos. [75] Una suite de pruebas a menudo contiene instrucciones detalladas u objetivos para cada colección de casos de prueba e información sobre la configuración del sistema que se utilizará durante la prueba. Un grupo de casos de prueba también puede contener estados o pasos de prerrequisitos y descripciones de las siguientes pruebas.

Accesorio 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 modificables se recopilan en archivos separados y se almacenan como datos de prueba. También resulta útil proporcionar estos datos al cliente y junto con el producto o un 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 pruebas" .

Prueba de funcionamiento

Una ejecución de prueba es una colección de casos de prueba o conjuntos de pruebas que el usuario ejecuta y compara los resultados esperados con los reales. Una vez finalizada, se puede generar un informe de todas las pruebas ejecutadas.

Certificaciones

Existen varios programas de certificación para respaldar las aspiraciones profesionales de los evaluadores de software y los especialistas en control de calidad. Algunos profesionales sostienen que el campo de las pruebas no está listo para la certificación, como se mencionó en la sección de controversias.

Controversia

Algunas de las principales controversias en materia de pruebas de software incluyen:

Ágil vs. tradicional
¿Los testers deberían 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 ganado popularidad desde principios de los años 2000, principalmente en círculos comerciales [76] [77], mientras que los proveedores de software gubernamentales y militares [78] utilizan esta metodología, pero también los modelos tradicionales de prueba final (por ejemplo, en el modelo Waterfall ). [ cita requerida ]
Pruebas manuales vs. pruebas automatizadas
Algunos autores creen que la automatización de pruebas es tan cara en relación con su valor que debería utilizarse con moderación. [79] La automatización de pruebas puede considerarse entonces como una forma de capturar e implementar los requisitos. Como regla general, cuanto mayor sea el sistema y mayor la complejidad, mayor será el retorno de la inversión en la automatización de pruebas. Además, la inversión en herramientas y experiencia puede amortizarse en varios proyectos con el nivel adecuado de intercambio de conocimientos dentro de una organización.
¿Está justificada la existencia de la norma ISO 29119 de pruebas de software?
Se ha formado una oposición significativa en las filas de la escuela de pruebas de software basada en el contexto con respecto a la norma ISO 29119. Las asociaciones de pruebas profesionales, como la Sociedad Internacional de Pruebas de Software, han intentado que se retire la norma. [80] [81]
Algunos profesionales declaran que el campo de pruebas no está listo para la certificación
[82] Actualmente, ninguna certificación que se ofrece exige que el solicitante demuestre su capacidad para probar software. Ninguna certificación se basa en un conjunto de conocimientos ampliamente aceptado. La certificación en sí no puede medir la productividad de un individuo, su habilidad o su conocimiento práctico, y no puede garantizar su competencia o profesionalismo como evaluador. [83]
Estudios utilizados para mostrar el gasto relativo de reparar defectos
Existen opiniones encontradas sobre la aplicabilidad de los estudios utilizados para mostrar el costo relativo de la reparación de defectos en función de su introducción y detección. Por ejemplo:

Se cree comúnmente que cuanto antes se encuentre un defecto, más barato será solucionarlo. La siguiente tabla muestra el costo de solucionar el defecto dependiendo de la etapa en la que se encontró. [84] Por ejemplo, si un problema en los requisitos se encuentra recién después de la publicación, entonces costaría entre 10 y 100 veces más solucionarlo que si ya se hubiera encontrado en la revisión de requisitos. Con la llegada 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.

Los datos a partir de los cuales se extrapola esta tabla son escasos. Laurent Bossavit afirma 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 la extrapolación a "proyectos más pequeños en general" es totalmente indefendible. El estudio de GTE no explica sus datos, más allá de decir que provienen de dos proyectos, uno grande y otro pequeño. El artículo citado para el proyecto "Safeguard" de Bell Labs niega específicamente haber recopilado los datos de grano fino 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 corresponda claramente a sus puntos de datos.

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

Véase también

Referencias

  1. ^ Kaner, Cem (17 de noviembre de 2006). Pruebas exploratorias (PDF) . Conferencia anual mundial sobre pruebas de software del Quality Assurance Institute. Orlando, FL . Consultado el 22 de noviembre de 2014 .
  2. ^ ab Pan, Jiantao (primavera de 1999). "Software Testing" (trabajo de curso). Carnegie Mellon University . Consultado el 21 de noviembre de 2017 .
  3. ^ abcd Kaner, Cem ; Falk, Jack; Nguyen, Hung Quoc (1999). Prueba de software informático (2.ª ed.). Nueva York: John Wiley and Sons. ISBN 978-0-471-35846-6.
  4. ^ Leitner, Andreas; Ciupa, Ilinca; Oriol, Manuel; Meyer, Bertrand ; Fiva, Arno (septiembre de 2007). Contract Driven Development = Test Driven Development – ​​Writing Test Cases (PDF) . ESEC/FSE'07: European Software Engineering Conference and the ACM SIGSOFT Symposium on the Foundations of Software Engineering 2007. Dubrovnik, Croacia . Consultado el 8 de diciembre de 2017 .
  5. ^ ab Kolawa, Adam; Huizinga, Dorota (2007). Prevención automatizada de defectos: mejores prácticas en la gestión de software. Wiley-IEEE Computer Society Press. ISBN 978-0-470-04212-0.
  6. ^ Cohn, Mike (2009). Cómo tener éxito con Agile: desarrollo de software con Scrum . Addison-Wesley Professional. ISBN 978-0321579362.
  7. ^ Molina, Alessandro (2021). Creación de software basado en pruebas con Python: escriba conjuntos de pruebas que se adapten a las necesidades y la complejidad de sus aplicaciones utilizando Python y PyTest . Packt Publishing. ISBN 978-1838642655.
  8. ^ Fernandes da Costa, Lucas (2021). Pruebas de aplicaciones JavaScript . Manning. ISBN 978-1617297915.
  9. ^ "Los impactos económicos de una infraestructura inadecuada para las pruebas de software" (PDF) . Instituto Nacional de Normas y Tecnología . Mayo de 2002 . Consultado el 19 de diciembre de 2017 .
  10. ^ abc Myers, Glenford J. (1979). El arte de las pruebas de software. John Wiley and Sons. ISBN 978-0-471-04328-7.
  11. ^ ab Glosario estándar IEEE de terminología de ingeniería de software , IEEE, 1990, doi : 10.1109/IEEESTD.1990.101064, ISBN 978-1-55937-067-7
  12. ^ "Programa de estudios de nivel básico para probadores certificados". International Software Testing Qualifications Board . 31 de marzo de 2011. Sección 1.1.2. Archivado desde el original (pdf) el 28 de octubre de 2017. Consultado el 15 de diciembre de 2017 .
  13. ^ "Programa de estudios de nivel básico para probadores certificados" (PDF) . International Software Testing Qualifications Board . 1 de julio de 2005. Principio 2, Sección 1.3. Archivado desde el original (PDF) el 17 de diciembre de 2008 . Consultado el 15 de diciembre de 2017 .
  14. ^ Ramler, Rudolf; Kopetzky, Theodorich; Platz, Wolfgang (17 de abril de 2012). Diseño de pruebas combinatorias en el conjunto de pruebas TOSCA: lecciones aprendidas e implicaciones prácticas . Quinta Conferencia Internacional sobre Pruebas y Validación de Software (ICST) del IEEE. Montreal, QC, Canadá. doi :10.1109/ICST.2012.142.
  15. ^ Kaner, Cem; Bach, James; Pettichord, Bret (2001). Lecciones aprendidas en pruebas de software: un enfoque basado en el contexto . Wiley. págs. 31–43. ISBN 978-0-471-08112-8.
  16. ^ Kolawa, Adam; Huizinga, Dorota (2007). Prevención automatizada de defectos: mejores prácticas en la gestión de software . Wiley-IEEE Computer Society Press. pág. 74. ISBN 978-0-470-04212-0.
  17. ^ O'Connor, Rory V.; Akkaya, Mariye Umay; Kemaneci, Kerem; Yilmaz, Murat; Poth, Alexander; Messnarz, Richard (15 de octubre de 2015). Mejora de procesos de sistemas, software y servicios: 22.ª conferencia europea, EuroSPI 2015, Ankara, Turquía, 30 de septiembre - 2 de octubre de 2015. Actas. Springer. ISBN. 978-3-319-24647-5.
  18. ^ Bourque, Pierre; Fairley, Richard E., eds. (2014). "Capítulo 5". Guía del conjunto de conocimientos de ingeniería de software . 3.0. IEEE Computer Society. ISBN 978-0-7695-5166-1. Recuperado el 2 de enero de 2018 .
  19. ^ Bourque, P.; Fairley, RD, eds. (2014). "Capítulo 4: Pruebas de software" (PDF) . SWEBOK v3.0: Guía del conjunto de conocimientos de ingeniería de software . IEEE. págs. 4–1–4–17. ISBN 978-0-7695-5166-1. Archivado desde el original (PDF) el 19 de junio de 2018 . Consultado el 13 de julio de 2018 .
  20. ^ Dooley, J. (2011). Desarrollo de software y práctica profesional. APress. págs. 193-4. ISBN 978-1-4302-3801-0.
  21. ^ Wiegers, K. (2013). Creación de una cultura de ingeniería de software. Addison-Wesley. págs. 211-2. ISBN 978-0-13-348929-3.
  22. ^ Kolawa, Adam; Huizinga, Dorota (2007). Prevención automatizada de defectos: mejores prácticas en la gestión de software . Wiley-IEEE Computer Society Press. pág. 75. ISBN 978-0-470-04212-0.
  23. ^ ab Graham, D.; Van Veenendaal, E.; Evans, I. (2008). Fundamentos de las pruebas de software. Aprendizaje Cengage. págs. 57–58. ISBN 978-1-84480-989-9.
  24. ^ abcd Oberkampf, WL; Roy, CJ (2010). Verificación y validación en computación científica. Cambridge University Press. págs. 154-155. ISBN 978-1-139-49176-1.
  25. ^ Lee, D.; Netravali, AN; Sabnani, KK; Sugla, B.; John, A. (1997). "Pruebas pasivas y aplicaciones para la gestión de redes". Actas de la Conferencia internacional sobre protocolos de red de 1997. IEEE Comput. Soc. págs. 113–122. doi :10.1109/icnp.1997.643699. ISBN 978-0-8186-8061-8.S2CID 42596126  .
  26. ^ Cem Kaner, "Un tutorial sobre pruebas exploratorias Archivado el 12 de junio de 2013 en Wayback Machine ", pág. 2
  27. ^ Cem Kaner, Un tutorial sobre pruebas exploratorias Archivado el 12 de junio de 2013 en Wayback Machine , pág. 36.
  28. ^ Lee, D.; Yannakakis, M. (1996). "Principios y métodos de prueba de máquinas de estados finitos: un estudio". Actas del IEEE . 84 (8): 1090–1123. doi :10.1109/5.533956.
  29. ^ Petrenko, A.; Yevtushenko, N. (2011). "Pruebas adaptativas de implementaciones deterministas especificadas por FSM no deterministas". En Testing Software and Systems: 23rd IFIP WG 6.1 International Conference, ICTSS 2011, París, Francia, 7-10 de noviembre. Lecture Notes in Computer Science. Vol. 7019. Springer Berlin Heidelberg. págs. 162–178. doi :10.1007/978-3-642-24580-0_12. ISBN 978-3-642-24579-4.
  30. ^ Petrenko, A.; Yevtushenko, N. (2014). "Pruebas adaptativas de sistemas no deterministas con FSM". En 2014, 15.° Simposio internacional IEEE sobre ingeniería de sistemas de alta seguridad. IEEE. págs. 224–228. doi :10.1109/HASE.2014.39. ISBN. 978-1-4799-3466-9.
  31. ^ abcd Limaye, MG (2009). Pruebas de software. Tata McGraw-Hill Education. págs. 108-11. ISBN 978-0-07-013990-9.
  32. ^ abcd Saleh, KA (2009). Ingeniería de software. Publicación J. Ross. págs. 224–41. ISBN 978-1-932159-94-3.
  33. ^ abc Ammann, P.; Offutt, J. (2016). Introducción a las pruebas de software. Cambridge University Press. pág. 26. ISBN 978-1-316-77312-3.
  34. ^ Everatt, GD; McLeod Jr., R. (2007). "Capítulo 7: Pruebas funcionales". Pruebas de software: pruebas a lo largo de todo el ciclo de vida del desarrollo de software . John Wiley & Sons. págs. 99–121. ISBN 978-0-470-14634-7.
  35. ^ ab Cornett, Steve (c. 1996). "Análisis de cobertura de código". Tecnología de pruebas Bullseye. Introducción . Consultado el 21 de noviembre de 2017 .
  36. ^ ab Black, R. (2011). Pruebas de software pragmáticas: cómo convertirse en un profesional de pruebas eficaz y eficiente. John Wiley & Sons. págs. 44–6. ISBN 978-1-118-07938-6.
  37. ^ Como ejemplo simple, la función C consta de una sola declaración. Todas las pruebas contra una especificación tendrán éxito, excepto si se elige esta opción.int f(int x){return x*x-6*x+8;}f(x)>=0x=3
  38. ^ Patton, Ron (2005). Pruebas de software (2.ª edición). Indianápolis: Sams Publishing. ISBN 978-0-672-32798-8.
  39. ^ Laycock, Gilbert T. (1993). The Theory and Practice of Specification Based Software Testing (PDF) (tesis de disertación). Departamento de Ciencias de la Computación, Universidad de Sheffield . Consultado el 2 de enero de 2018 .
  40. ^ Bach, James (junio de 1999). «Pruebas basadas en riesgos y requisitos» (PDF) . Computer . 32 (6): 113–114 . Consultado el 19 de agosto de 2008 .
  41. ^ Mathur, AP (2011). Fundamentos de las pruebas de software. Pearson Education India. pág. 63. ISBN 978-81-317-5908-0.
  42. ^ ab Clapp, Judith A. (1995). Control de calidad de software, análisis de errores y pruebas. William Andrew. pág. 313. ISBN 978-0-8155-1363-6. Recuperado el 5 de enero de 2018 .
  43. ^ Mathur, Aditya P. (2007). Fundamentos de las pruebas de software. Pearson Education India. pág. 18. ISBN 978-81-317-1660-1.
  44. ^ Lönnberg, Jan (7 de octubre de 2003). Pruebas visuales de software (PDF) (tesis de maestría). Universidad Tecnológica de Helsinki . Consultado el 13 de enero de 2012 .
  45. ^ Chima, Raspal. «Pruebas visuales». Revista TEST . Archivado desde el original el 24 de julio de 2012. Consultado el 13 de enero de 2012 .
  46. ^ abc Lewis, WE (2016). Pruebas de software y mejora continua de la calidad (3.ª ed.). CRC Press. pp. 68–73. ISBN 978-1-4398-3436-7.
  47. ^ ab Ransome, J.; Misra, A. (2013). Seguridad del software básico: seguridad en la fuente. CRC Press. págs. 140-143. ISBN 978-1-4665-6095-6.
  48. ^ "Herramientas de prueba SOA para cajas negras, blancas y grises" (informe técnico). Crosscheck Networks. Archivado desde el original el 1 de octubre de 2018. Consultado el 10 de diciembre de 2012 .
  49. ^ ab Myers, G. (2004). Sandler, C.; Badgett, T.; Thomas, M. (eds.). El arte de las pruebas de software (2.ª ed.). Wiley. ISBN 9780471469124.
  50. ^ Ammann, Paul; Offutt, Jeff (28 de enero de 2008). Introducción a las pruebas de software. Cambridge University Press . p. 215. ISBN 978-0-521-88038-1. Recuperado el 29 de noviembre de 2017 .
  51. ^ abc Lewis, WE (2016). Pruebas de software y mejora continua de la calidad (3.ª ed.). CRC Press. pp. 92–6. ISBN 978-1-4398-3436-7.
  52. ^ Machado, P.; Vincenzi, A.; Maldonado, JC (2010). "Capítulo 1: Pruebas de software: una descripción general". En Borba, P.; Cavalcanti, A.; Sampaio, A.; Woodcook, J. (eds.). Técnicas de prueba en ingeniería de software . Springer Science & Business Media. págs. 13–14. ISBN 978-3-642-14334-2.
  53. ^ Clapp, JA; Stanten, SF; Peng, WW; et al. (1995). Control de calidad de software, análisis de errores y pruebas. Nova Data Corporation. pág. 254. ISBN 978-0-8155-1363-6.
  54. ^ abc "ISTQB CTFL Syllabus 2018" (PDF) . ISTQB - International Software Testing Qualifications Board . Archivado (PDF) del original el 24 de marzo de 2022 . Consultado el 11 de abril de 2022 .
  55. ^ Woods, Anthony J. (5 de junio de 2015). "Operational Acceptance – an application of the ISO 29119 Software Testing standard" (Libro blanco). Capgemini Australia . Consultado el 9 de enero de 2018 .
  56. ^ "Glosario estándar de términos utilizados en pruebas de software" (PDF) . Versión 3.1. International Software Testing Qualifications Board . Consultado el 9 de enero de 2018 .
  57. ^ O'Reilly, Tim (30 de septiembre de 2005). "What is Web 2.0" (¿Qué es la Web 2.0?). O'Reilly Media. Sección 4. Fin del ciclo de lanzamiento de software . Consultado el 11 de enero de 2018 .
  58. ^ Auerbach, Adam (3 de agosto de 2015). "Parte del proceso: por qué las pruebas continuas son esenciales". TechWell Insights . TechWell Corp . Consultado el 12 de enero de 2018 .
  59. ^ Philipp-Edmonds, Cameron (5 de diciembre de 2014). "La relación entre el riesgo y las pruebas continuas: una entrevista con Wayne Ariola". Stickyminds . Consultado el 16 de enero de 2018 .
  60. ^ Ariola, Wayne; Dunlop, Cynthia (octubre de 2015). DevOps: ¿Está enviando errores a los clientes más rápido? (PDF) . Conferencia de calidad de software del Pacífico Noroeste . Consultado el 16 de enero de 2018 .
  61. ^ Auerbach, Adam (2 de octubre de 2014). "Shift Left and Put Quality First" (Desplazarse a la izquierda y priorizar la calidad). TechWell Insights . TechWell Corp . Consultado el 16 de enero de 2018 .
  62. ^ "Sección 4.38". ISO/IEC/IEEE 29119-1:2013 – Ingeniería de software y sistemas – Pruebas de software – Parte 1 – Conceptos y definiciones. Organización Internacional de Normalización . Consultado el 17 de enero de 2018 .
  63. ^ "Globalización paso a paso: el enfoque de pruebas preparado para el mundo. Microsoft Developer Network". Microsoft Developer Network. Archivado desde el original el 23 de junio de 2012. Consultado el 13 de enero de 2012 .
  64. ^ Claessen, Koen; Hughes, John (2000). "QuickCheck". Actas de la quinta conferencia internacional ACM SIGPLAN sobre programación funcional . Icfp '00. págs. 268–279. doi :10.1145/351240.351266. ISBN 978-1-58113-202-1.S2CID5668071  .​
  65. ^ Gelperin, David ; Hetzel, Bill (1 de junio de 1988). "El crecimiento de las pruebas de software". Comunicaciones de la ACM . 31 (6): 687–695. doi : 10.1145/62959.62965 . S2CID  14731341.
  66. ^ Gregory, Janet; Crispin, Lisa (2014). Más pruebas ágiles . Addison-Wesley Professional. págs. 23–39. ISBN 978-0-13-374956-4.
  67. ^ "Ciclo de vida de las pruebas de software". etestinghub . Fase de prueba en las pruebas de software . Consultado el 13 de enero de 2012 .
  68. ^ Dustin, Elfriede (2002). Pruebas de software eficaces. Addison-Wesley Professional. pág. 3. ISBN 978-0-201-79429-8.
  69. ^ ab "¿Qué es el desarrollo impulsado por pruebas (TDD)?". Agile Alliance . 5 de diciembre de 2015. Consultado el 17 de marzo de 2018 .
  70. ^ "Desarrollo basado en pruebas e integración continua para aplicaciones móviles". Microsoft Developer Network . 14 de enero de 2009 . Consultado el 17 de marzo de 2018 .
  71. ^ Brown, Chris; Cobb, Gary; Culbertson, Robert (12 de abril de 2002). Introducción a las pruebas rápidas de software.
  72. ^ Tran, Eushiuan (1999). "Verificación/Validación/Certificación" (trabajo de curso). Universidad Carnegie Mellon . Consultado el 13 de agosto de 2008 .
  73. ^ ab Gotel, Orlena; Cleland-Huang, Jane ; Hayes, Jane Huffman; Zisman, Andrea; Egyed, Alexander; Grünbacher, Paul; Dekhtyar, Alex; Antoniol, Giuliano; Maletic, Jonathan (1 de enero de 2012). Cleland-Huang, Jane; Gotel, Orlena; Zisman, Andrea (eds.). Trazabilidad de software y sistemas . Springer Londres. doi :10.1007/978-1-4471-2239-5_1. ISBN 9781447122388.
  74. ^ IEEE (1998). Estándar IEEE para documentación de pruebas de software . Nueva York: IEEE. ISBN 978-0-7381-1443-9.
  75. ^ Pinto, Leandro Sales; Sinha, Saurabh; Orso, Alessandro (11 de noviembre de 2012). "Entender los mitos y realidades de la evolución de los conjuntos de pruebas". Actas del 20.º Simposio internacional sobre los fundamentos de la ingeniería de software de la ACM SIGSOFT . Association for Computing Machinery. págs. 1–11. doi :10.1145/2393596.2393634. ISBN . 9781450316149.S2CID 9072512  .
  76. ^ Strom, David (1 de julio de 2009). "Todos somos parte de la historia". Software Test & Performance Collaborative. Archivado desde el original el 31 de agosto de 2009.
  77. ^ Griffiths, M. (2005). "Enseñando gestión de proyectos ágiles al PMI". Conferencia de Desarrollo Ágil (ADC'05) . ieee.org. pp. 318–322. doi :10.1109/ADC.2005.45. ISBN 978-0-7695-2487-0. Número de identificación del sujeto  30322339.
  78. ^ Willison, John S. (abril de 2004). "Desarrollo ágil de software para una fuerza ágil". CrossTalk (abril de 2004). STSC. Archivado desde el original el 29 de octubre de 2005.
  79. ^ Un ejemplo es Mark Fewster, Dorothy Graham: Software Test Automation. Addison Wesley, 1999, ISBN 978-0-201-33140-0
  80. ^ "stop29119". commonsensetesting.org . Archivado desde el original el 2 de octubre de 2014.
  81. ^ Paul Krill (22 de agosto de 2014). "Los evaluadores de software se oponen a la propuesta de normas ISO 29119". InfoWorld .
  82. ^ Kaner, Cem (2001). "Propuesta de subvención de la NSF para 'sentar las bases para mejoras significativas en la calidad de los cursos académicos y comerciales en pruebas de software'" (PDF) . Archivado desde el original (PDF) el 27 de noviembre de 2009. Consultado el 13 de octubre de 2006 .
  83. ^ Kaner, Cem (2003). Medición de la eficacia de los evaluadores de software (PDF) . STAR East. Archivado desde el original (PDF) el 26 de marzo de 2010. Consultado el 18 de enero de 2018 .
  84. ^ McConnell, Steve (2004). Código completo (2.ª edición). Microsoft Press. pág. 29. ISBN 978-0-7356-1967-8.
  85. ^ Bossavit, Laurent (20 de noviembre de 2013). "El costo de los defectos: una historia ilustrada". Los duendes de la ingeniería de software: cómo el folclore se convierte en realidad y qué hacer al respecto . leanpub.

Lectura adicional

Enlaces externos