Este artículo analiza un conjunto de tácticas útiles en las pruebas de software . Está pensado como una lista completa de enfoques tácticos para el aseguramiento de la calidad del software (más ampliamente conocido coloquialmente como aseguramiento de la 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, "desarrollador) pruebas").
Prueba de instalación
Una prueba de instalación asegura que el sistema esté instalado correctamente y que funcione con el hardware real del cliente.
El enfoque de la caja
Los métodos de prueba de software se dividen tradicionalmente en pruebas de caja blanca y negra. Estos dos enfoques se utilizan para describir el punto de vista que adopta un ingeniero de pruebas al diseñar casos de prueba.
Prueba de caja blanca
La prueba de caja blanca (también conocida como prueba de caja transparente, prueba de caja de vidrio, prueba de caja transparente y prueba estructural, al ver el código fuente) prueba las estructuras internas o el funcionamiento de un programa, a diferencia de 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 probador elige entradas para ejercitar rutas a través del código y determinar las salidas apropiadas. Esto es análogo a probar nodos en un circuito, por ejemplo , pruebas en circuito (ICT).
Si bien las pruebas de caja blanca se pueden aplicar a los niveles de unidad , integración y sistema del proceso de prueba de software, generalmente se realiza a nivel de unidad. Puede probar rutas dentro de una unidad, rutas entre unidades durante la integración y entre subsistemas durante una prueba a nivel de sistema. Aunque este método de diseño de prueba puede descubrir muchos errores o problemas, es posible que no detecte partes no implementadas de la especificación o requisitos faltantes.
Las técnicas utilizadas en las pruebas de caja blanca incluyen:
- Prueba de API : prueba de la aplicación utilizando API públicas y privadas (interfaces de programación de aplicaciones)
- Cobertura de código : creación de pruebas para satisfacer algunos criterios de cobertura de código (por ejemplo, el diseñador de pruebas puede crear pruebas para hacer que todas las declaraciones del programa se ejecuten al menos una vez)
- Métodos de inyección de fallas : introducción intencional de fallas para medir la eficacia de las estrategias de prueba.
- Métodos de prueba de mutaciones
- Métodos de prueba estáticos
Las herramientas de cobertura de código pueden evaluar la integridad de un conjunto de pruebas que se creó con cualquier método, incluidas las pruebas de caja negra. Esto permite al equipo de software examinar partes de un sistema que rara vez se prueban y garantiza que se hayan probado los puntos de función más importantes . [1] La cobertura del código como métrica de software se puede informar como un porcentaje para:
- Cobertura de funciones , que informa sobre las funciones ejecutadas
- Cobertura de la declaración , que informa sobre la cantidad de líneas ejecutadas para completar la prueba
- Cobertura de decisiones , que informa sobre si se han ejecutado tanto la rama Verdadero como la rama Falsa de una prueba determinada
La cobertura del 100% de la declaración asegura que todas las rutas de código o ramas (en términos de flujo de control ) se ejecuten al menos una vez. Esto es útil para garantizar la funcionalidad correcta, pero no es suficiente, ya que el mismo código puede procesar diferentes entradas de forma correcta o incorrecta.
Prueba de caja negra
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 saben lo que se supone que debe hacer el software, no cómo lo hace. [2] métodos de prueba Negro-box incluyen: partición de equivalencia , análisis de valor límite , todos los pares de pruebas , tablas de transición de estado , tabla de decisión pruebas, las pruebas de pelusa , pruebas basadas en modelos , caso de uso de prueba, la prueba exploratoria y pruebas basadas en la especificación.
Las pruebas basadas en especificaciones tienen como objetivo probar la funcionalidad del software de acuerdo con los requisitos aplicables. [3] Este nivel de prueba generalmente requiere que se proporcionen casos de prueba completos al evaluador, quien luego puede simplemente verificar que para una entrada determinada, el valor de salida (o comportamiento), "es" o "no es" el mismo que el valor esperado especificado en el caso de prueba. Los casos de prueba se basan en especificaciones y requisitos, es decir, lo que se supone que debe hacer la aplicación. Utiliza descripciones externas del software, incluidas especificaciones, requisitos y diseños para derivar casos de prueba. Estas pruebas pueden ser funcionales o no funcionales , aunque normalmente son funcionales.
Las pruebas basadas en especificaciones pueden ser necesarias para asegurar la funcionalidad correcta, pero no son suficientes para protegerse contra situaciones complejas o de alto riesgo. [4]
Una ventaja de la técnica de la caja negra es que no se requieren conocimientos de programación. Independientemente de los sesgos que puedan haber tenido los programadores, es probable que el probador tenga un conjunto diferente y pueda enfatizar diferentes áreas de funcionalidad. Por otro lado, se ha dicho que las pruebas de caja negra son "como caminar en un laberinto oscuro sin una linterna". [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 haber sido probado por un solo caso de prueba, o deja algunas partes del programa sin probar.
Este método de prueba se puede aplicar a todos los niveles de prueba de software: unidad , integración , sistema y aceptación . Por lo general, comprende la mayoría, si no todas, las pruebas en niveles superiores, pero también puede dominar las pruebas unitarias.
Pruebas visuales
El objetivo de las pruebas visuales es proporcionar a los desarrolladores la capacidad de examinar lo que estaba sucediendo en el punto de falla del software al presentar los datos de tal manera que el desarrollador pueda encontrar fácilmente la información que necesita y que 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 una falla en la prueba), en lugar de solo describirlo, aumenta en gran medida 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 del probador en tiempo real a través de una cámara web de imagen en una 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 probadores pueden mostrar el problema (y los eventos que lo conducen) al desarrollador en lugar de simplemente describirlo y la necesidad de replicar las fallas de prueba dejará de existir en muchos casos. El desarrollador tendrá todas las pruebas que necesite de una prueba fallida y, en cambio, podrá centrarse en la causa de la falla y en cómo se debe solucionar.
Las pruebas visuales son particularmente adecuadas para entornos que implementan métodos ágiles en su desarrollo de software, ya que los métodos ágiles requieren una mayor comunicación entre probadores y desarrolladores y colaboración dentro de equipos pequeños. [ cita requerida ]
Las pruebas ad hoc y las pruebas exploratorias son metodologías importantes para verificar la integridad del software, ya que requieren menos tiempo de preparación para su implementación, mientras que los errores importantes se pueden encontrar rápidamente. En las pruebas ad hoc, donde las pruebas se llevan a cabo de forma improvisada e improvisada, la capacidad de una herramienta de prueba para registrar visualmente todo lo que ocurre en un sistema se vuelve muy importante para documentar los pasos tomados para descubrir el error. [ aclaración necesaria ] [ cita necesaria ]
Las pruebas visuales están ganando reconocimiento en la aceptación del cliente y las pruebas de usabilidad , porque la prueba puede ser utilizada por muchas personas involucradas en el proceso de desarrollo. [ cita requerida ] Para el cliente, es fácil proporcionar informes detallados de errores 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 falla de software para los desarrolladores.
Prueba de caja gris
Las pruebas de caja gris (ortografía estadounidense: prueba de caja gris) implica tener conocimiento de las estructuras y algoritmos de datos internos con el fin de diseñar pruebas, mientras se ejecutan esas pruebas a nivel de usuario o de caja negra. No se requiere que el probador tenga acceso completo al código fuente del software. [2] La manipulación de datos de entrada y el formateo de la salida no califican como 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 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, califican como caja gris, ya que el usuario normalmente no podría cambiar el repositorio de datos en las operaciones normales de producción. [ 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 el exterior. Por lo general, a un probador de caja gris se le permitirá configurar un entorno de prueba aislado con actividades como sembrar una base de datos . El evaluador puede observar el estado del producto que se está probando después de realizar ciertas acciones, como ejecutar declaraciones SQL en la base de datos y luego ejecutar consultas para asegurarse de que se hayan reflejado los cambios esperados. Las pruebas de caja gris implementan escenarios de prueba inteligentes, basados en información limitada. Esto se aplicará particularmente al manejo de tipos de datos, manejo de excepciones , etc. [8]
Pruebas automatizadas
Muchos grupos de programación confían cada vez más en las pruebas automatizadas , especialmente los grupos que utilizan el desarrollo basado en pruebas . Hay muchos marcos para escribir pruebas, y el software de integración continua ejecutará las pruebas automáticamente cada vez que se ingrese el código en un sistema de control de versiones.
Si bien la automatización no puede reproducir todo lo que un humano puede hacer (y todas las formas en que piensa en hacerlo), puede ser muy útil para las pruebas de regresión. Sin embargo, requiere un conjunto de pruebas bien desarrollado de scripts de prueba para que sea realmente útil.
Herramientas de prueba automatizadas
Las pruebas de programas y la detección de fallas pueden ser de gran ayuda mediante las herramientas de prueba y los depuradores . Las herramientas de prueba / depuración incluyen características como:
- Monitores de programa, que permiten el monitoreo total o parcial del código del programa, incluyendo:
- Simulador de conjunto de instrucciones , que permite un monitoreo completo del nivel de instrucción y facilidades de rastreo.
- Hipervisor , que permite un control completo de la ejecución del código del programa, que incluye: -
- Animación del programa , que permite la ejecución paso a paso y el punto de interrupción condicional a nivel de fuente o en código de máquina
- Informes de cobertura de código
- Volcado formateado o depuración simbólica , herramientas que permiten la inspección de las variables del programa en caso de error o en puntos seleccionados
- Las herramientas de prueba de GUI (interfaz gráfica de usuario) funcionales automatizadas se utilizan para repetir las pruebas a nivel del sistema a través de la GUI
- Puntos de referencia , que permiten realizar comparaciones de rendimiento en tiempo de ejecución
- Análisis de rendimiento (o herramientas de creación de perfiles) que pueden ayudar a resaltar los puntos calientes y el uso de recursos.
Algunas de estas características pueden incorporarse en una sola herramienta compuesta o en un entorno de desarrollo integrado (IDE).
Abstracción de capas de aplicación aplicadas a pruebas automatizadas
En general, hay cuatro niveles reconocidos de pruebas: pruebas unitarias, pruebas de integración, pruebas de interfaz de componentes y pruebas del sistema. Con frecuencia, las pruebas se agrupan 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 según lo definido por la guía SWEBOK son las pruebas unitarias, de integración y del 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]
Hay dos niveles diferentes de pruebas desde la perspectiva de los clientes: pruebas de bajo nivel (LLT) y pruebas de alto nivel (HLT). LLT es un grupo de pruebas para componentes de diferentes niveles de aplicaciones o productos de software. HLT es un grupo de pruebas para toda la aplicación o producto de software. [ cita requerida ]
Examen de la unidad
Las pruebas unitarias se refieren a las pruebas que verifican la funcionalidad de una sección específica de código, generalmente a nivel de función. En un entorno orientado a objetos , esto suele ser a nivel de clase, y las pruebas unitarias mínimas incluyen los constructores y destructores. [10]
Este tipo de pruebas generalmente las escriben los desarrolladores mientras trabajan en el código (estilo de caja blanca), para garantizar que la función específica esté funcionando como se esperaba. Una función puede tener varias pruebas para detectar casos de esquina u otras ramas en el código. Las pruebas unitarias por sí solas no pueden verificar la funcionalidad de una pieza de software, sino que se utilizan para garantizar que los componentes básicos del software funcionen de forma independiente entre sí.
Las pruebas unitarias son un proceso de desarrollo de software que implica la aplicación sincronizada de un amplio espectro de estrategias de prevención y detección de defectos para reducir los riesgos, el tiempo y los costos del desarrollo de software. Lo realiza el desarrollador o ingeniero de software durante la fase de construcción del ciclo de vida del desarrollo de software. En lugar de reemplazar los enfoques tradicionales de control de calidad, los aumenta. Las pruebas unitarias tienen como objetivo eliminar los errores de construcción antes de que el código se promueva a QA; esta estrategia tiene como objetivo aumentar la calidad del software resultante, así como la eficiencia del desarrollo general y el proceso de control de calidad.
En función de las expectativas de la organización para el desarrollo de software, las pruebas unitarias podría incluir el análisis estático de código , análisis de flujo de datos , análisis de métricas, las revisiones de código de pares, la cobertura de código análisis y otras verificación de software prácticas.
Pruebas de integración
La prueba de integración es cualquier tipo de prueba de software que busca verificar las interfaces entre los componentes con un diseño de software. Los componentes de software pueden integrarse de forma iterativa o todos juntos ("big bang"). Normalmente, lo primero se considera una mejor práctica, ya que permite localizar y solucionar los problemas de la interfaz de forma más rápida.
Las pruebas de integración funcionan para exponer defectos en las interfaces y la interacción entre componentes integrados (módulos). Se integran y prueban grupos progresivamente más grandes de componentes de software probados correspondientes a elementos del diseño arquitectónico hasta que el software funciona como un sistema. [11]
Prueba de interfaz de componentes
La práctica de las pruebas de interfaz de componentes se puede utilizar para verificar el manejo de los datos pasados entre varias unidades o componentes del subsistema, más allá de las pruebas de integración total entre esas unidades. [12] [13] Los datos que se pasan se pueden considerar como "paquetes de mensajes" y el rango o los tipos de datos se pueden verificar, para los datos generados a partir de una unidad, y probar su validez antes de pasar a otra unidad. Una opción para las pruebas de interfaz es mantener un archivo de registro separado de los elementos de datos que se pasan, a menudo con una marca de tiempo registrada para permitir el análisis de miles de casos de datos pasados entre unidades durante días o semanas. Las pruebas pueden incluir verificar el manejo de algunos valores de datos extremos mientras que otras variables de interfaz se pasan como valores normales. [12] Los valores de datos inusuales en una interfaz pueden ayudar a explicar un 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 los datos más allá de las acciones relacionadas de un componente del subsistema.
Prueba del sistema
La prueba del sistema prueba un sistema completamente integrado para verificar que el sistema cumple con sus requisitos. [14] Por ejemplo, una prueba del sistema puede implicar probar una interfaz de inicio de sesión, luego crear y editar una entrada, además de enviar o imprimir los resultados, seguido de un procesamiento resumido o la eliminación (o archivo) de las entradas y luego cerrar la sesión.
Prueba de aceptación operativa
La aceptación operativa se utiliza para llevar a cabo la preparación operativa (prelanzamiento) de un producto, servicio o sistema como parte de un sistema de gestión de la calidad . OAT es un tipo común de prueba de software no funcional, que se utiliza principalmente en proyectos de desarrollo y mantenimiento de software . Este tipo de prueba se centra en la preparación operativa del sistema para ser compatible y / o para convertirse en parte del entorno de producción. Por lo tanto, también se conoce como prueba de preparación operativa (ORT) o prueba de preparación y garantía de operaciones (OR&A). Las pruebas funcionales dentro de OAT se limitan a aquellas pruebas que se requieren para verificar los aspectos no funcionales del sistema.
Además, las pruebas de software deben garantizar que la portabilidad del sistema, además de funcionar como se espera, no dañe ni corrompe parcialmente su entorno operativo ni provoque que otros procesos dentro de ese entorno dejen de funcionar. [15]
Pruebas de compatibilidad
Una causa común de falla del software (real o percibida) es la falta de compatibilidad con otro software de aplicación , sistemas operativos (o versiones de sistemas operativos , antiguos o nuevos) o entornos de destino que difieren mucho del original (como un terminal o La aplicación GUI destinada a ejecutarse en el escritorio ahora se requiere que se convierta en una aplicación web , que debe procesarse en un navegador web ). Por ejemplo, en el caso de una falta de compatibilidad con versiones anteriores , esto puede ocurrir porque los programadores desarrollan y prueban software solo en la última versión del entorno de destino, que no todos los usuarios pueden estar ejecutando. Esto da como resultado la consecuencia no deseada de que es posible que el último trabajo no funcione en versiones anteriores del entorno de destino o en hardware más antiguo que las versiones anteriores del entorno de destino podían usar. A veces, estos problemas se pueden solucionar mediante la abstracción proactiva de la funcionalidad del sistema operativo en un módulo de programa o biblioteca separados .
Pruebas de humo y cordura
Las pruebas de cordura determinan si es razonable continuar con más pruebas.
Las pruebas de humo consisten en intentos mínimos de operar el software, diseñados para determinar si hay algún problema básico que impida que funcione. Estas pruebas se pueden utilizar como prueba de verificación de construcción .
Pruebas de regresión
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, busca descubrir regresiones de software , como características degradadas o perdidas, incluidos errores antiguos que han regresado. Estas regresiones se producen cuando la funcionalidad del software que anteriormente funcionaba correctamente deja de funcionar como se esperaba. Por lo general, las regresiones ocurren como una consecuencia involuntaria de cambios en el programa, cuando la parte recién desarrollada del software choca con el código previamente existente. Los métodos comunes de prueba de regresión incluyen volver a ejecutar conjuntos anteriores de casos de prueba y verificar si han vuelto a surgir fallas previamente solucionadas. La profundidad de las pruebas depende de la fase del proceso de lanzamiento y del riesgo de las funciones añadidas. Pueden ser completos, para cambios agregados tarde en el lanzamiento o considerados riesgosos, o ser muy superficiales, que consisten en pruebas positivas en cada característica, si los cambios son al principio del lanzamiento o se consideran de bajo riesgo. Las pruebas de regresión suelen ser el esfuerzo de prueba más grande en el desarrollo de software comercial, [16] debido a la verificación de numerosos detalles en funciones de software anteriores, e incluso se puede desarrollar software nuevo mientras se utilizan algunos casos de prueba antiguos para probar partes del nuevo diseño para garantizar la funcionalidad anterior. todavía es compatible.
Test de aceptación
Las pruebas de aceptación pueden significar una de dos cosas:
- Una prueba de humo se utiliza como prueba de aceptación antes de introducir una nueva construcción en el proceso de prueba principal, es decir, antes de la integración o regresión .
- Las pruebas de aceptación realizadas por el cliente, a menudo en su entorno de laboratorio en su propio hardware, se conocen como pruebas de aceptación del usuario (UAT). Las pruebas de aceptación se pueden realizar como parte del proceso de transferencia entre dos fases de desarrollo. [ cita requerida ]
Prueba alfa
Las pruebas alfa son pruebas operativas simuladas o reales realizadas por usuarios / clientes potenciales o un equipo de prueba independiente en el sitio de los desarrolladores. Las pruebas alfa se emplean a menudo para software estándar como una forma de prueba de aceptación interna, antes de que el software pase a la prueba beta. [17]
Prueba beta
Las pruebas beta vienen después de las pruebas alfa y pueden considerarse una forma de prueba de aceptación de usuarios externos . Las versiones del software, conocidas como versiones beta , se lanzan a una audiencia limitada fuera del equipo de programación conocido como beta testers. El software se distribuye a grupos de personas para que las pruebas adicionales puedan garantizar que el producto tenga pocas fallas o errores . Las versiones beta se pueden poner a disposición del público abierto para aumentar el campo de comentarios a un número máximo de usuarios futuros y ofrecer valor antes, durante un período de tiempo prolongado o incluso indefinido ( beta perpetua ). [ cita requerida ]
Pruebas funcionales vs no funcionales
Las pruebas funcionales se refieren a actividades que verifican una acción o función específica del código. Por lo general, se encuentran en la documentación de requisitos del código, aunque algunas metodologías de desarrollo funcionan a partir de casos de uso o historias de usuarios. Las pruebas funcionales tienden a responder a la pregunta de "¿puede el usuario hacer esto?" O "¿funciona esta característica en particular?".
Las pruebas no funcionales se refieren a aspectos del software que pueden no estar relacionados con una función específica o una acción del usuario, como la escalabilidad u otro rendimiento , el comportamiento bajo ciertas restricciones o la seguridad . Las pruebas determinarán el punto de ruptura, el punto en el que los extremos de escalabilidad o rendimiento conducen a una ejecución inestable. Los requisitos no funcionales tienden a ser aquellos que reflejan la calidad del producto, particularmente en el contexto de la perspectiva de idoneidad de sus usuarios.
Prueba continua
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 de requisitos funcionales y no funcionales ; el alcance de las pruebas se extiende desde la validación de los requisitos ascendentes o las historias de los usuarios hasta la evaluación de los requisitos del sistema asociados con los objetivos comerciales generales. [20] [21] [22]
Pruebas destructivas
Las pruebas destructivas intentan hacer que falle el software o un subsistema. Verifica que el software funcione correctamente incluso cuando recibe entradas no válidas o inesperadas, estableciendo así la solidez de las rutinas de validación de entrada y gestión de errores. [ 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 funcionales están vinculadas desde la página de inyección de fallas de software ; También existen numerosas herramientas de software libre y de código abierto disponibles que realizan pruebas destructivas.
Prueba de rendimiento del software
Las pruebas de rendimiento generalmente se ejecutan para determinar cómo se desempeña un sistema o subsistema en términos de capacidad de respuesta y estabilidad bajo una carga de trabajo particular. También puede servir para investigar, medir, validar o verificar otros atributos de calidad del sistema, como escalabilidad, confiabilidad y uso de recursos.
Las pruebas de carga se refieren principalmente a probar que el sistema puede continuar funcionando bajo una carga específica, ya sean grandes cantidades de datos o una gran cantidad de usuarios . Esto se conoce generalmente como escalabilidad de software. La actividad de prueba de carga relacionada, cuando se realiza como una actividad no funcional, a menudo se denomina prueba de resistencia . La prueba de volumen es una forma de probar las funciones del software incluso cuando ciertos componentes (por ejemplo, un archivo o una base de datos) aumentan radicalmente de tamaño. Las pruebas de estrés son una forma de probar la confiabilidad bajo cargas de trabajo inesperadas o poco frecuentes. Las pruebas de estabilidad (a menudo denominadas pruebas de carga o resistencia) verifican si el software puede funcionar bien de forma continua en un período aceptable o por encima de él.
Hay poco acuerdo sobre cuáles son los objetivos específicos de las pruebas de rendimiento. Los términos prueba de carga, prueba de rendimiento, prueba de escalabilidad y prueba de volumen, a menudo se usan indistintamente.
Los sistemas de software en tiempo real tienen estrictas restricciones de tiempo. Para probar si se cumplen las restricciones de tiempo, se utilizan pruebas en tiempo real .
Pruebas de usabilidad
Las pruebas de usabilidad son para verificar si la interfaz de usuario es fácil de usar y comprender. Se ocupa principalmente del uso de la aplicación.
Pruebas de accesibilidad
Las pruebas de accesibilidad pueden incluir el cumplimiento de estándares como:
- Ley de Estadounidenses con Discapacidades de 1990
- Sección 508 Enmienda a la Ley de Rehabilitación de 1973
- Iniciativa de Accesibilidad Web (WAI) del Consorcio World Wide Web (W3C)
Pruebas de seguridad
Las pruebas de seguridad son esenciales para el software que procesa datos confidenciales para evitar la intrusión de piratas informáticos en el sistema .
La Organización Internacional de Normalización (ISO) define esto como un "tipo de prueba realizada para evaluar el grado en que un elemento de prueba, y los datos e información asociados, están protegidos para que personas o sistemas no autorizados no puedan usarlos, leerlos o modificarlos, y a las personas o sistemas autorizados no se les niega el acceso a ellos ". [23]
Pruebas de internacionalización y localización
La capacidad general del software para internacionalizarse y localizarse se puede probar automáticamente sin traducción real, mediante el uso de pseudolocalización . Verificará que la aplicación aún funciona, incluso después de que se haya traducido a un nuevo idioma o se haya adaptado a una nueva cultura (como diferentes monedas o zonas horarias). [24]
También se debe probar la traducción real a los lenguajes humanos. Los posibles errores de localización incluyen:
- El software a menudo se localiza traduciendo una lista de cadenas fuera de contexto, y el traductor puede elegir la traducción incorrecta para una cadena fuente ambigua.
- La terminología técnica puede volverse inconsistente si el proyecto es traducido por varias personas sin la debida coordinación o si el traductor es imprudente.
- Las traducciones literalmente palabra por palabra pueden parecer inapropiadas, artificiales o demasiado técnicas en el idioma de destino.
- Los mensajes no traducidos en el idioma original pueden dejarse codificados en el código fuente.
- Algunos mensajes pueden crearse automáticamente en tiempo de ejecución y la cadena resultante puede ser gramatical, funcionalmente incorrecta, engañosa o confusa.
- El software puede utilizar un método abreviado de teclado que no tiene ninguna función en la distribución del teclado del idioma de origen , pero se utiliza para escribir caracteres en la distribución del idioma de destino.
- El software puede carecer de soporte para la codificación de caracteres del idioma de destino.
- Las fuentes y los tamaños de fuente que son apropiados en el idioma de origen pueden ser inapropiados en el idioma de destino; por ejemplo, los caracteres CJK pueden volverse ilegibles si la fuente es demasiado pequeña.
- Una cadena en el idioma de destino puede ser más larga de lo que puede manejar el software. Esto puede hacer que la cadena sea parcialmente invisible para el usuario o hacer que el software se bloquee o no funcione correctamente.
- El software puede carecer del soporte adecuado para leer o escribir texto bidireccional .
- El software puede mostrar imágenes con texto no localizado.
- Los sistemas operativos localizados pueden tener archivos de configuración del sistema y variables de entorno con nombres diferentes y diferentes formatos para la fecha y la moneda .
Pruebas de desarrollo
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 de desarrollo de software. Lo realiza el desarrollador o ingeniero de software durante la fase de construcción del ciclo de vida del desarrollo de software. En lugar de reemplazar los enfoques tradicionales de control de calidad, los aumenta. Las pruebas de desarrollo tienen como objetivo eliminar los errores de construcción antes de que el código se promueva a control de calidad; esta estrategia tiene como objetivo aumentar la calidad del software resultante, así como la eficiencia del desarrollo general y el proceso de 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 de pares, pruebas unitarias, análisis de cobertura de código, trazabilidad y otras prácticas de verificación de software.
Pruebas A / B
Las pruebas A / B son básicamente una comparación de dos salidas, generalmente cuando solo ha cambiado una variable: ejecutar una prueba, cambiar una cosa, ejecutar la prueba nuevamente, comparar los resultados. Esto es más útil en situaciones más pequeñas, pero muy útil para ajustar cualquier programa. Con proyectos más complejos, se pueden realizar pruebas multivariantes.
Prueba concurrente
En las pruebas simultáneas, la atención se centra en el rendimiento mientras se ejecuta continuamente con una entrada normal y en condiciones operativas normales, a diferencia de las pruebas de estrés o las pruebas de fuzz. Las pérdidas de memoria, así como las fallas básicas, son más fáciles de encontrar con este método.
Pruebas de conformidad o pruebas de tipo
En las pruebas de software, las pruebas de conformidad verifican que un producto funcione de acuerdo con sus estándares especificados. Los compiladores, por ejemplo, se someten a pruebas exhaustivas para determinar si cumplen con el estándar reconocido para ese idioma.
Referencias
- ^ Introducción , Análisis de cobertura de código, Steve Cornett [ ¿fuente no confiable? ]
- ↑ a b Patton, Ron (26 de julio de 2005). Pruebas de software (2ª ed.). Sams Publishing. ISBN 978-0672327988.[ página necesaria ]
- ^ Laycock, GT (1993). "La teoría y la práctica de las pruebas de software basadas en especificaciones" . Departamento de Ciencias de la Computación, Universidad de Sheffield, Reino Unido. Archivado desde el original ( PostScript ) el 14 de febrero de 2007 . Consultado el 13 de febrero de 2008 . Cite journal requiere
|journal=
( ayuda ) - ^ Bach, James (junio de 1999). "Pruebas basadas en riesgos y requisitos" (PDF) . Computadora . 32 (6): 113-114 . Consultado el 19 de agosto de 2008 .
- ^ Savenkov, Roman (2008). Cómo convertirse en un tester de software . Consultoría Roman Savenkov. pag. 159. ISBN 978-0-615-23372-7.
- ^ "Pruebas visuales de software - Universidad Tecnológica de Helsinki" (PDF) . Consultado el 13 de enero de 2012 .
- ^ "Artículo sobre pruebas visuales en Test Magazine" . Testmagazine.co.uk. Archivado desde el original el 24 de julio de 2012 . Consultado el 13 de enero de 2012 .
- ^ "Herramientas de prueba SOA para técnicas de prueba SOA de caja negra, blanca y gris" . Crosschecknet.com . Consultado el 10 de diciembre de 2012 .
- ^ a b "Guía SWEBOK - Capítulo 5" . Computer.org . Consultado el 13 de enero de 2012 .
- ^ Carpeta, Robert V. (1999). Prueba de sistemas orientados a objetos: objetos, patrones y herramientas . Addison-Wesley Professional. pag. 45 . ISBN 0-201-80938-9.
- ^ Beizer, Boris (1990). Técnicas de prueba de software (Segunda ed.). Nueva York: Van Nostrand Reinhold. págs. 21, 430. ISBN 0-442-20672-0.
- ^ a b Clapp, Judith A. (1995). Control de calidad de software, análisis de errores y pruebas . pag. 313. ISBN 0815513631.
- ^ a b Mathur, Aditya P. (2008). Fundamentos de las pruebas de software . Universidad de Purdue. pag. 18. ISBN 978-8131716601.
- ^ IEEE (1990). Diccionario informático estándar IEEE: una compilación de glosarios informáticos estándar IEEE . Nueva York: IEEE. ISBN 1-55937-079-3.
- ^ Documento técnico: Aceptación operativa: una aplicación del estándar de pruebas de software ISO 29119. Mayo de 2015 Anthony Woods, Capgemini
- ^ Paul Ammann; Jeff Offutt (2008). Introducción a las pruebas de software . pag. 215 de 322 páginas.
- ^ van Veenendaal, Erik. "Glosario estándar de términos utilizados en pruebas de software" . Consultado el 4 de enero de 2013 .
- ^ Parte de la canalización: por qué las pruebas continuas son esenciales , por Adam Auerbach, TechWell Insights agosto de 2015
- ^ La relación entre el riesgo y las pruebas continuas: una entrevista con Wayne Ariola , por Cameron Philipp-Edmonds, Stickyminds, diciembre de 2015
- ^ DevOps: ¿Está enviando errores a los clientes más rápido ?, Por Wayne Ariola y Cynthia Dunlop, PNSQC, octubre de 2015
- ^ DevOps y QA: ¿Cuál es el costo real de la calidad? , por Ericka Chickowski, DevOps.com, junio de 2015
- ^ Desplazar a la izquierda y poner la calidad en primer lugar , por Adam Auerbach, TechWell Insights octubre de 2014
- ^ ISO / IEC / IEEE 29119-1: 2013 - Ingeniería de software y sistemas - Pruebas de software - Parte 1 - Conceptos y definiciones; Sección 4.38
- ^ "Globalización paso a paso: el enfoque mundial de las pruebas. Microsoft Developer Network" . Msdn.microsoft.com . Consultado el 13 de enero de 2012 .
enlaces externos
- Herramientas y productos de prueba de software en Curlie