En este artículo se analiza un conjunto de tácticas útiles en las pruebas de software . Se pretende que sea una lista completa de enfoques tácticos para el control de calidad del software (conocido más comúnmente como control de calidad (tradicionalmente llamado por el acrónimo "QA")) y la aplicación general del método de prueba (generalmente llamado simplemente "prueba" o, a veces, "prueba de desarrollador").
Una prueba de instalación garantiza que el sistema esté instalado correctamente y funcione en el hardware real del cliente.
Los métodos de prueba de software se dividen tradicionalmente en pruebas de caja blanca y de caja negra. Estos dos enfoques se utilizan para describir el punto de vista que adopta un ingeniero de pruebas al diseñar casos de prueba.
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, mediante la observación del código fuente) prueban 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, así como habilidades de programación, para diseñar casos de prueba. El evaluador elige entradas para practicar 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 en los niveles de unidad , integración y sistema del proceso de prueba de software, generalmente se realizan en el nivel de unidad. Pueden probar rutas dentro de una unidad, rutas entre unidades durante la integración y entre subsistemas durante una prueba a nivel de sistema. Si bien 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:
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. [1] [ ¿ Fuente poco confiable? ] La cobertura de código como métrica de software se puede informar como un porcentaje para:
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 distintas entradas de manera correcta o incorrecta.
Las pruebas de caja negra tratan el software como una "caja negra", examinando la funcionalidad sin ningún conocimiento de la implementación interna, sin ver el código fuente. Los evaluadores solo son conscientes de lo que se supone que debe hacer el software, no de cómo lo hace. [2] Los métodos de prueba de caja negra incluyen: partición de equivalencia , análisis de valores límite , prueba de todos los pares , tablas de transición de estados , prueba de tabla de decisiones , prueba de fuzz , prueba basada en modelos , prueba de casos de uso , prueba exploratoria y prueba basada en especificaciones.
Las pruebas basadas en especificaciones tienen como objetivo probar la funcionalidad del software de acuerdo con los requisitos aplicables. [3] 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), "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 garantizar una funcionalidad correcta, pero son insuficientes para protegerse contra situaciones complejas o de alto riesgo. [4]
Una ventaja de la técnica de caja negra es que no se requieren conocimientos de programación. Independientemente de los sesgos que puedan tener 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 un paseo por un laberinto oscuro sin una linterna". [5] 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 haberse probado con 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 pruebas de software: unitario , de integración , de sistema y de aceptación . Por lo general, comprende la mayoría de las pruebas, si no todas, de los niveles superiores, pero también puede dominar las pruebas unitarias.
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 con claridad. [6] [7]
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, capturando 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 probador 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 visuales son particularmente adecuadas para entornos que implementan métodos ágiles en el desarrollo de software, ya que los métodos ágiles requieren una mayor comunicación entre evaluadores y desarrolladores y colaboración dentro de equipos pequeños. [ cita requerida ]
Las pruebas ad hoc y exploratorias son metodologías importantes para verificar la integridad del software, ya que requieren menos tiempo de preparación para su implementación y, al mismo tiempo, los errores importantes se pueden encontrar rápidamente. En las pruebas ad hoc, donde las pruebas se realizan de manera improvisada, la capacidad de una herramienta de prueba para registrar visualmente todo lo que ocurre en un sistema se vuelve muy importante para documentar los pasos que se tomaron para descubrir el error. [ aclaración necesaria ] [ cita necesaria ]
Las pruebas visuales están ganando reconocimiento en la aceptación del cliente y en las pruebas de usabilidad , porque la prueba puede ser utilizada por muchas personas involucradas en el proceso de desarrollo. [ cita requerida ] Para el cliente, resulta fácil proporcionar informes de errores detallados y comentarios, y para los usuarios del programa, las pruebas visuales pueden registrar las acciones del usuario en la pantalla, así como su voz e imagen, para proporcionar una imagen completa en el momento de la falla del software para los desarrolladores.
Las pruebas de caja gris (en inglés, gray-box testing) implican tener conocimiento de las estructuras de datos internas y los algoritmos con el fin de diseñar pruebas, mientras se ejecutan esas pruebas a nivel de usuario o de caja negra. No se requiere que el evaluador tenga acceso total al código fuente del software. [2] La manipulación de los datos de entrada y el formateo de la salida no se califican como pruebas de caja gris, porque 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.
Sin embargo, las pruebas que requieren modificar un repositorio de datos de back-end, como una base de datos o un archivo de registro, sí califican como pruebas de caja gris, ya que el usuario normalmente no podría cambiar el repositorio de datos en operaciones de producción normales. [ cita requerida ] Las pruebas de caja gris también pueden incluir ingeniería inversa para determinar, por ejemplo, valores límite o mensajes de error.
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. [8]
Muchos grupos de programación recurren cada vez más a las pruebas automatizadas , especialmente los grupos que utilizan el desarrollo basado en pruebas . Existen muchos marcos en los que se pueden escribir pruebas, y el software de integración continua ejecutará pruebas automáticamente cada vez que se introduzca código en un sistema de control de versiones .
Si bien la automatización no puede reproducir todo lo que un ser humano puede hacer (y todas las formas en que piensa 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.
Las herramientas de prueba y depuradores pueden ayudar significativamente a la detección de fallas y pruebas de programas . Las herramientas de prueba y depuración incluyen características como:
Algunas de estas características pueden incorporarse en una única herramienta compuesta o en un entorno de desarrollo integrado (IDE).
En general, se reconocen cuatro niveles de pruebas: pruebas unitarias, pruebas de integración, pruebas de interfaz de componentes y pruebas de sistema. Las pruebas se agrupan con frecuencia 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. Los principales niveles durante el proceso de desarrollo, tal como se define en la guía SWEBOK, son las pruebas unitarias, de integración y de sistema, que se distinguen por el objetivo de la prueba sin implicar un modelo de proceso específico. [9] Otros niveles de prueba se clasifican según el objetivo de la prueba. [9]
Existen dos niveles diferentes de pruebas desde la perspectiva de los clientes: pruebas de bajo nivel (LLT) y pruebas de alto nivel (HLT). Las LLT son un grupo de pruebas para componentes de diferentes niveles de una aplicación o producto de software. Las HLT son un grupo de pruebas para toda la aplicación o producto de software. [ cita requerida ]
Las pruebas unitarias se refieren a 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. [10]
Este tipo de pruebas suelen ser escritas por los desarrolladores mientras trabajan en el código (estilo caja blanca), para garantizar que la función específica funcione como se espera. Una función puede tener múltiples pruebas, para detectar casos extremos u otras ramificaciones en el código. Las pruebas unitarias por sí solas no pueden verificar la funcionalidad de un 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 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. En lugar de reemplazar los enfoques tradicionales de control de calidad, los amplía. Las pruebas unitarias tienen como objetivo eliminar los errores de construcción antes de que el código pase a control de calidad; esta estrategia tiene como objetivo aumentar la calidad del software resultante, así como la eficiencia del proceso general de desarrollo y control de calidad.
Dependiendo de las expectativas de la organización para el desarrollo de software, las pruebas unitarias 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, análisis de cobertura de código y otras prácticas de verificación de software .
Las pruebas de integración son cualquier tipo de prueba de software que busca verificar las interfaces entre componentes frente a un diseño de software. Los componentes de software pueden integrarse de forma iterativa o todos juntos ("big bang"). Normalmente, la primera opción se considera una mejor práctica, ya que permite localizar y solucionar problemas de interfaz más rápidamente.
Las pruebas de integración sirven para exponer defectos en las interfaces y la interacción entre los componentes integrados (módulos). Se van integrando y probando grupos cada vez más grandes de componentes de software probados, correspondientes a elementos del diseño arquitectónico, hasta que el software funciona como un sistema. [11]
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. [12] [13] 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. [12] Los valores de datos inusuales en una interfaz pueden ayudar a explicar el rendimiento inesperado en la siguiente unidad. Las pruebas de interfaz de componentes son una variación de las pruebas de caja negra , [13] con el enfoque en los valores de datos más allá de las acciones relacionadas de un componente del subsistema.
Las pruebas del sistema prueban un sistema completamente integrado para verificar que el sistema cumple con sus requisitos. [14] Por ejemplo, una prueba del sistema podría implicar probar una interfaz de inicio de sesión, luego crear y editar una entrada, además de enviar o imprimir resultados, seguido del procesamiento resumido o la eliminación (o archivo) de las entradas y luego cerrar la sesión.
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 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 y/o a formar 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. [15]
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 .
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 .
Las pruebas de regresión se centran en encontrar defectos después de que se haya producido un cambio importante en el código. En concreto, buscan descubrir regresiones de software , como características degradadas o perdidas, incluidos errores antiguos que han vuelto a aparecer. Estas regresiones se producen siempre que la funcionalidad del software que antes funcionaba correctamente deja de hacerlo como estaba previsto. Normalmente, las regresiones se producen como consecuencia no intencionada de los cambios en el programa, cuando la parte del software recién desarrollada choca con el código que ya existía. 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 al final del lanzamiento o considerados arriesgados, o muy superficiales, consistentes en pruebas positivas de cada característica, si los cambios se producen al principio del lanzamiento o se consideran de bajo riesgo. Las pruebas de regresión suelen ser el mayor esfuerzo de prueba en el desarrollo de software comercial, [16] debido a la verificación de numerosos detalles en las características 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.
Las pruebas de aceptación pueden significar una de dos cosas:
Las pruebas alfa son pruebas operativas simuladas o reales que realizan usuarios o clientes potenciales o un equipo de pruebas independiente en las instalaciones de los desarrolladores. Las pruebas alfa suelen emplearse para software comercial como una forma de prueba de aceptación interna, antes de que el software pase a la fase de prueba beta. [17]
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 comentarios 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 ). [ cita requerida ]
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.
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. [18] [19] 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. [20] [21] [22]
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.
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 .
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.
Las pruebas de accesibilidad pueden incluir el cumplimiento de estándares como:
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) lo define 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". [23]
La capacidad general de un software para ser internacionalizado y localizado se puede probar automáticamente sin una traducción real, mediante el uso de pseudolocalización . Esto verificará que la aplicación aún funciona, incluso después de haber sido traducida a un nuevo idioma o adaptada a una nueva cultura (como diferentes monedas o zonas horarias). [24]
También es necesario probar la traducción real a los idiomas humanos. Entre los posibles errores de localización se incluyen los siguientes:
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. Las lleva a cabo el desarrollador o el ingeniero de software durante la fase de construcción del ciclo de vida del desarrollo de software. En lugar de reemplazar los enfoques tradicionales de control de calidad, los amplía. Las pruebas de desarrollo tienen como objetivo eliminar los errores de construcción antes de que el código pase a control de calidad; esta estrategia tiene como objetivo aumentar la calidad del software resultante, así como la eficiencia del proceso general de desarrollo y control de calidad.
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 verificación de software.
Las pruebas A/B son básicamente una comparación de dos resultados, generalmente cuando solo ha cambiado una variable: se ejecuta una prueba, se cambia una cosa, se vuelve a ejecutar la prueba y se comparan los resultados. Esto es más útil en situaciones de menor escala, pero muy útil para ajustar cualquier programa. En proyectos más complejos, se pueden realizar pruebas multivariantes.
En las pruebas concurrentes, el enfoque se centra en el rendimiento mientras se ejecuta de forma continua con una entrada normal y en condiciones operativas normales, a diferencia de las pruebas de estrés o pruebas de fuzz. Las fugas de memoria, así como los fallos básicos, son más fáciles de detectar con este método.
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.
{{cite journal}}: Requiere citar revista |journal=( ayuda )