Tipos de pruebas de software
Examen de la unidad
Las pruebas unitarias se realizan en una función individual, clase o módulo de forma independiente que probar un software completamente de trabajo. Usando un marco para pruebas unitarias, el programador puede crear casos de prueba con entrada y salida esperada. Al tener cientos, miles o decenas de miles de casos de prueba unitaria para un proyecto de software grande asegura que todas las unidades individuales funcionen como se esperaba mientras continúa cambiando el código. Al cambiar una unidad que tiene casos de prueba, los casos de prueba para ese módulo deben estudiarse y determinar si se necesitan nuevos casos de prueba, la salida ha cambiado o los casos de prueba actuales se pueden eliminar como ya no es relevante. Crear un gran volumen de pruebas unitarias es la forma más fácil de lograr una alta cobertura de casos de prueba para una base de código de software, pero no se asegurará de que el producto final funcione como un sistema como se esperaba.
Prueba funcional
Las pruebas funcionales son la forma más común de pruebas. Cuando las personas se refieren a las pruebas de software sin muchos detalles, a menudo significan pruebas funcionales. Las pruebas funcionales verificarán las funciones principales del trabajo de software como se esperaba. Se podría escribir un plan de prueba para describir todos los casos de prueba funcional que se probará, que corresponden a las principales características y capacidades del software. Las pruebas de funcionalidad primaria serán "camino feliz " Pruebas, que no intenta romper el software ni usarlo en ningún escenario desafiante. Este debería ser el mínimo absoluto de las pruebas para cualquier proyecto de software.
Pruebas de integración
Después de la prueba unitaria y las pruebas funcionales, puede haber varios módulos o todo el sistema que aún no se ha probado en su conjunto. O puede haber componentes que son en gran medida independientes pero que ocasionalmente se usan juntos. En cualquier momento, los componentes o módulos se prueban de forma independiente, pero no como un sistema completo, se deben realizar pruebas de integración para validar la función de componentes como un sistema de trabajo de acuerdo con los requisitos y expectativas del usuario.
Pruebas de estrés
Piense en las pruebas de estrés como si estuviera probando un transbordador espacial o avión. ¿Qué significa poner su software o sistema en "estrés"?? El estrés no es más que una carga intensa de un tipo específico que es más probable que rompa su sistema. Esto podría ser similar a la "prueba de carga" en el sentido de colocar su sistema en alta concurrencia con muchos usuarios que acceden al sistema. Pero estresar un sistema también podría suceder en otros vectores. Por ejemplo, ejecutar firmware en un componente de hardware cuando el hardware ha tenido un deterioro físico y está operando en modo degradado. El estrés es exclusivo de todo tipo de software, y los sistemas y el diseño de las pruebas de estrés deben tener en cuenta lo que las causas naturales o antinaturales tienen más probabilidades de enfatizar su software o sistema.
Prueba de carga
Las pruebas de carga son un tipo específico de pruebas de estrés, como se discutió anteriormente, por lo que se automatizan grandes cantidades de conexiones y accesos de usuario concurrentes para generar la simulación del efecto de una gran cantidad de usuarios auténticos que acceden a su sistema de software al mismo tiempo. El objetivo es averiguar cuántos usuarios pueden acceder a su sistema al mismo tiempo sin que su sistema de software se rompa. Si su sistema puede manejar fácilmente el tráfico normal de 10,000 usuarios, qué sucederá si su sitio web o software se vuelve viral y obtiene 1 millón de usuarios? ¿Esto será inesperado? "CARGA" Romper su sitio web o sistema? Las pruebas de carga simularán esto, por lo que se siente cómodo con el aumento futuro de los usuarios porque sabe que su sistema puede manejar el aumento de la carga.
Pruebas de rendimiento
Las personas pueden sentirse completamente frustradas y desesperadas cuando el software no cumple con sus requisitos de rendimiento. El rendimiento, en general, significa qué tan rápido se pueden completar las funciones importantes. Cuanto más complejas y dinámicas las funciones estén disponibles en un sistema, más importante y no obvio será probar su rendimiento, tomemos un ejemplo básico, Windows o un sistema operativo Linux. Un sistema operativo es un producto de software altamente complejo, y hacer pruebas de rendimiento en su sistema podría implicar la velocidad y el momento de las funciones como el arranque, instalar una aplicación, buscar un archivo, ejecutar cálculos en una GPU y/o cualquier otro de los millones de acciones que se pueden realizar. Se debe tener cuidado al seleccionar los casos de prueba de rendimiento, para garantizar las características de rendimiento importantes y propensas a mal funcionamiento de.
Prueba de escalabilidad
Las pruebas en su computadora portátil son buenas, pero no lo suficientemente buena cuando está construyendo una red social, un sistema de correo electrónico o un software de supercomputadora. Cuando su software está destinado a implementarse en 1000 servidores, todos funcionan al unísono, entonces las pruebas que realiza localmente en un sistema no descubrirá los errores que ocurren cuando el software se implementa "a escala" en cientos de miles de instancias. En realidad, sus pruebas probablemente nunca podrán ejecutarse a escala completa antes de liberar a la producción porque sería demasiado costosa y no práctica construir un sistema de prueba con 1000 servidores que cuestan millones de dólares. Por lo tanto, las pruebas de escalabilidad se realizan en múltiples servidores, pero generalmente no el número total de servidores de producción para tratar de descubrir algunos de los defectos que se pueden encontrar, ya que sus sistemas se usan en una infraestructura más grande.
Prueba de análisis estático
El análisis estático se realiza una prueba que se realiza inspeccionando el código de software sin ejecutarlo realmente. Para hacer un análisis estático, en general, usaría una herramienta, hay muchas, una herramienta famosa es la cobertura. El análisis estático es fácil de ejecutar antes de lanzar su software y puede encontrar muchos problemas de calidad en su código que se pueden solucionar antes de liberar. Errores de memoria, errores de manejo de tipo de datos, desferencias de puntero nulo, variables no inicializadas y se pueden encontrar muchos más defectos. Lenguajes como C y C ++ se benefician enormemente del análisis estático porque los idiomas proporcionan una gran libertad para los programadores a cambio de una gran potencia, pero esto también puede crear grandes errores y errores que se pueden encontrar utilizando pruebas de análisis estático.
Prueba de inyección de fallas
Algunas condiciones de error son muy difíciles de simular o activar, por lo tanto, el software puede diseñarse para inyectar artificialmente un problema o falla en el sistema sin que el defecto ocurra naturalmente. El propósito de las pruebas de inyección de fallas es ver cómo el software maneja estas fallas inesperadas. ¿Responde con gracia a la situación, se bloquea o produce resultados problemáticos inesperados e impredecibles?? Por ejemplo, supongamos que tenemos un sistema bancario, y hay un módulo para transferir fondos internamente de la cuenta A a la cuenta B. Sin embargo, esta operación de transferencia solo se llama después de que el sistema ya haya verificado que estas cuentas existían antes de llamar a la operación de transferencia. Aunque asumimos que ambas cuentas existen, la operación de transferencia tiene un caso de falla en el que no existe una cuenta de objetivo o fuente, y que puede lanzar un error. Porque en circunstancias normales nunca recibimos este error debido a la prueba previa de las entradas, por lo que para verificar el comportamiento del sistema cuando la transferencia falla debido a una cuenta inexistente, inyectamos un error falso en el sistema que devuelve una cuenta inexistente Para una transferencia y prueba cómo responde el resto del sistema en ese caso. Es muy importante que el código de inyección de fallas solo esté disponible en escenarios de prueba y no se libere a la producción, donde podría crear estragos.
Prueba de exceso de memoria
Al usar idiomas como C o C ++, el programador tiene una gran responsabilidad de abordar directamente la memoria, y esto puede causar errores fatales en el software si se cometen errores. Por ejemplo, si un puntero es nulo y se desactiva, el software se bloqueará. Si la memoria se asigna a un objeto y luego se copia una cadena sobre el espacio de memoria del objeto, hacer referencia al objeto puede causar un bloqueo incorrecto o incluso un comportamiento incorrecto no especificado. Por lo tanto, es fundamental usar una herramienta para tratar de atrapar errores de acceso a la memoria en un software que utiliza idiomas como C o C ++, lo que podría tener estos posibles problemas. Las herramientas que pueden hacer este tipo de prueba incluyen Valgrind de código abierto o herramientas patentadas como PurifyPlus. Estas herramientas pueden ahorrar el día en que no está claro por qué el software se está bloqueando o se portan mal y apunta directamente a la ubicación en el código que tiene el error. Impresionante, correcto?
Prueba de casos de límite
Es fácil cometer errores en la codificación cuando se encuentra en lo que se llama un límite. Por ejemplo, una máquina cajera automatizada bancaria dice que puede retirar un máximo de $ 300. Entonces, imagine que el codificador escribió el siguiente código naturalmente al construir este requisito:
If (amt < 300)
startwithdrawl ()
demás
error ("Puede retirar %s", amt);
¿Puedes detectar el error?? El usuario que intenta retirar $ 300 recibirá un error porque no es inferior a $ 300. Este es un error. Por lo tanto, la prueba de límite se realiza naturalmente. Los límites de los requisitos luego aseguran que en ambos lados del límite y el límite, el software funcione correctamente.
Prueba de fuzz
La generación de alta velocidad de entrada al software puede producir tantas combinaciones de entrada posibles, incluso si esas combinaciones de entrada son sin sentido y nunca serían suministradas por un usuario real. Este tipo de prueba de fuzz puede encontrar errores y vulnerabilidades de seguridad que no se encuentran a través de otros medios debido al alto volumen de entradas y escenarios probados rápidamente sin la generación de casos de prueba manual.
Prueba exploratoria
Cierra los ojos y visualiza lo que significa la palabra "explorar". Está observando y sondeando un sistema para averiguar cómo funciona realmente. Imagine que recibe una nueva silla de escritorio en pedido por correo, y tiene 28 piezas, todas en bolsas de plástico separadas sin instrucciones. Debe explorar su nueva llegada para descubrir cómo funciona y cómo se junta. Con este espíritu, puedes convertirte en un probador exploratorio. No tendrá un plan de prueba bien definido de casos de prueba. Explorará y investigará su software en busca de cosas que le hagan decir la maravillosa palabra: “Interesante!". Al aprender, sondea más y encuentre formas de romper el software que los diseñadores nunca pensaron, y luego entregar un informe que detalla numerosos supuestos, fallas y riesgos malos en el software. Obtenga más información sobre esto en el libro llamado Explore It.
Pruebas de penetración
En el mundo de la seguridad del software, las pruebas de penetración son uno de los principales medios de prueba. Todos los sistemas, ya sean biológicos, físicos o software, tienen fronteras y límites. Estos límites están destinados a permitir solo mensajes, personas o componentes específicos para ingresar al sistema. Más concretamente, consideremos un sistema bancario en línea que utiliza la autenticación del usuario para ingresar al sitio. Si el sitio puede ser pirateado y ingresado en el backend sin una autenticación adecuada, que sería una penetración, que debe protegerse contra. El objetivo de las pruebas de penetración es utilizar técnicas conocidas y experimentales para evitar el límite de seguridad normal de un sistema o sitio web de software. Las pruebas de penetración a menudo implican verificar todos los puertos que están escuchando e intentando ingresar a un sistema a través de un puerto abierto. Otras técnicas comunes incluyen inyección SQL o agrietamiento de contraseña.
Pruebas de regresión
Después de tener un software de trabajo que se implementa en el campo, es fundamental evitar que la introducción de errores en la funcionalidad que ya estaba funcionando. El propósito del desarrollo de software es aumentar la capacidad de su producto, introducir errores o hacer que la antigua funcionalidad deje de funcionar, lo que se llama regresión. La regresión es un error o defecto que se introdujo cuando anteriormente la capacidad funcionaba como se esperaba. Nada puede arruinar la reputación de su software o marca más rápido que introducir errores de regresión en su software y hacer que los usuarios reales encuentren estos errores después de una versión.
Los casos de prueba de regresión y los planes de prueba deben construirse alrededor de la funcionalidad central que debe continuar trabajando para garantizar que los usuarios tengan una buena experiencia con su aplicación. Todas las funciones centrales de su software que los usuarios esperan trabajar de cierta manera deben tener un caso de prueba de regresión que se pueda ejecutar para evitar que la funcionalidad se rompa en una nueva versión. Esto podría ser de 50 a 50,000 casos de prueba que cubren la funcionalidad central de su software o aplicación.
Prueba de bisección del código fuente
Se introdujo un error en el software, pero no es obvio qué versión del lanzamiento introdujo el nuevo error. Imagine que había 50 confirmaciones de software desde la última vez que el software funcionaba sin el error, hasta ahora cuando ..
Prueba de localización
Imagine una aplicación meteorológica que muestra el clima actual y proyectado en su ubicación, así como una descripción de las condiciones climáticas. La primera parte de las pruebas de localización es garantizar que el lenguaje correcto, el alfabeto y los caracteres se muestren correctamente, dependiendo de la geolocación del usuario. La aplicación en el Reino Unido debe mostrarse en inglés con caracteres latinos; La misma aplicación en China debe mostrarse en caracteres chinos en el idioma chino. Pruebas de localización más elaboradas realizadas, la gama más amplia de personas de diferentes geolocaciones interactuará con la aplicación.
Prueba de accesibilidad
Algunos de los ciudadanos en nuestra comunidad tienen discapacidades y, por lo tanto, pueden tener problemas para usar el software que se está creando, por lo que se realizan pruebas de accesibilidad para garantizar que las poblaciones con discapacidades aún puedan acceder a la funcionalidad del sistema. Por ejemplo, si suponemos que el 1% de la población es de color ciego, y nuestra interfaz de software supone que los usuarios pueden distinguir entre rojo y verde, pero esas personas con ciegas de color no pueden notar la diferencia. Por lo tanto, una interfaz bien sofocada tendrá señales adicionales más allá del color para indicar significado. Otros escenarios además de las pruebas de ceguera en color también se incluirían en las pruebas de accesibilidad de software, como ceguera visual completa, sordera y muchos otros escenarios. Se debe acceder a un buen producto de software en un porcentaje máximo de usuarios potenciales.
Prueba de actualización
Aplicaciones simples en un teléfono, sistemas operativos como Ubuntu, Windows o Linux Mint, y software que ejecuta submarinos nucleares necesitan actualizaciones frecuentes. El proceso de la actualización en sí podría introducir errores y defectos que no existirían en una instalación nueva porque el estado del entorno era diferente y el proceso de introducir el nuevo software en la parte superior de los viejos podría haber introducido errores. Tomemos un ejemplo simple, tenemos una computadora portátil ejecutando Ubuntu 18.04, y queremos actualizar a Ubuntu 20.04. Este es un proceso diferente para instalar el sistema operativo que limpiar directamente el disco duro e instalar Ubuntu 20.04. Por lo tanto, después de instalar el software o cualquiera de sus funciones derivadas, es posible que no funcione al 100% como se esperaba o lo mismo que cuando el software estaba recién instalado. Por lo tanto, primero debemos considerar probar la actualización en sí en muchos casos y escenarios diferentes para garantizar que la actualización funcione hasta la finalización. Y luego, también debemos considerar probar la actualización real del sistema para garantizar que el software se establezca y funcione como se esperaba. No repetiríamos todos los casos de prueba de un sistema recién instalado, lo que sería una pérdida de tiempo, pero pensaremos cuidadosamente con nuestro conocimiento del sistema de lo que podría romper durante una actualización y agregar estratégicamente casos de prueba para esas funciones.
Prueba de caja negra y caja blanca
Black Box y White Box son metodologías de prueba menos específicas y más tipos de categorizaciones de pruebas. Esencialmente, las pruebas de caja negra, que supone que el probador no sabe nada sobre el funcionamiento interno del software y crea un plan de prueba y casos de prueba que solo miran el sistema desde el exterior para verificar su función. Las pruebas de caja blanca son realizadas por arquitectos de software que comprenden el funcionamiento interno de un sistema de software y diseñan los casos con conocimiento de lo que podría, debería, debería y es probable que se rompa. Es probable que las pruebas de caja en blanco y negro encuentren diferentes tipos de defectos.
Blogs y artículos sobre pruebas de software
Las pruebas de software son un campo dinámico y muchas publicaciones y artículos interesantes que actualizan a la comunidad sobre el pensamiento de última generación en las pruebas de software. Todos podemos beneficiarnos de este conocimiento. Aquí hay una muestra de artículos interesantes de diferentes fuentes de blog que es posible que desee seguir:
- 7 consejos a seguir antes de la prueba sin requisitos; http: // www.Dirección de pruebas.com/
- 60 mejores herramientas de prueba de automatización: la guía de la lista definitiva; https: // testguild.com/
- Herramientas de prueba de base de datos de código abierto; https: // www.SoftWaretestingmagazine.com/
- La cobertura de prueba unitaria al 100 por ciento no es suficiente; https: // www.Stickyminds.com/
- Pruebas escamosas en Google y cómo las mitigamos; https: // prueba.googleblog.com/
- ¿Qué son las pruebas de regresión?? ; https: // prueba.IO/Blog/
- 5 Pasos de prueba de software clave Cada ingeniero debe realizar; https: // techbeacon.com/
Productos para pruebas de software
La mayoría de las valiosas tareas de pruebas se pueden automatizar, por lo que no debería sorprendernos que usar herramientas y productos para realizar las innumerables tareas de garantía de calidad del software sea una buena idea. A continuación enumeramos algunas herramientas de software importantes y altamente valiosas para las pruebas de software que puede explorar y ver si pueden ayudar.
Junit
Para probar el software basado en Java, JUNIT proporciona un conjunto de pruebas integral para las pruebas de unidad y funcionales del código que es amigable con el entorno Java.
Selenio
Para probar aplicaciones web, Selenium proporciona la capacidad de automatizar las interacciones con los navegadores web, incluidas las pruebas de compatibilidad con el navegador cruzado. Esta es una infraestructura de prueba Premier para la automatización de pruebas web.
Pepino
Un marco de prueba basado en el comportamiento permite a los usuarios comerciales, gerentes de productos y desarrolladores explicar la funcionalidad esperada en el lenguaje natural y luego definir ese comportamiento en los casos de prueba. Esto hace casos de prueba más legibles y un mapeo claro a la funcionalidad del usuario esperado.
Purificar
Encuentre las filtraciones de memoria y las corrupciones de memoria en el tiempo de ejecución ejecutando su software con la instrumentación Purify Plus integrada que rastree su uso de memoria y señala errores en su código que no son fáciles de encontrar sin instrumentación.
Valgrind
Herramientas de código abierto que ejecutarán su software y le permitirán interactuar con él mientras señala un informe de error de errores de codificación, como fugas de memoria y corrupciones. No es necesario recompilar o agregar instrumentación al proceso de compilación, ya que Valgrind tiene la inteligencia para comprender dinámicamente su código de máquina e inyectar instrumentación sin problemas para encontrar errores de codificación y ayudarlo a mejorar su código.
Cobertura
Herramienta de análisis estático que encontrará errores de codificación en su software incluso antes de compilar y ejecutar su código. La cobertura puede encontrar vulnerabilidades de seguridad, violaciones de las convenciones de codificación, así como errores y defectos que su compilador no encontrará. Se puede encontrar código muerto, variables no inicializadas y miles de otros tipos de defectos. Es vital limpiar su código con análisis estático antes de liberarlo a la producción.
Jímero
Un marco de código abierto para pruebas de rendimiento orientadas a desarrolladores basados en Java, de ahí la J en el nombre. La prueba del sitio web es uno de los principales casos de uso para JMeter, además de las pruebas de rendimiento de bases de datos, sistemas de correo y muchas otras aplicaciones basadas en servidores.
Metasploit
Para las pruebas de seguridad y penetración, MetaSploit es un marco genérico con miles de características y capacidades. Use la consola de interacción para acceder a los exploits precodificados e intente verificar la seguridad de su aplicación.
Investigación académica sobre pruebas de software
- Grupo de Investigación de Pruebas de la Universidad de Sheffield
- Laboratorio de verificación y validación de software de la Universidad de Kentucky
- Grupo de investigación de pruebas de software de la Universidad Estatal de Dakota del Norte
- Sistema Prueba de laboratorio inteligente; Universidad Técnica Checa Praga
- NASA: Jon McBride Software Testing and Research (JSTAR)
- Universidad McMaster; Laboratorio de investigación de calidad de software
- Universidad de Tech de Ontario; Laboratorio de investigación de calidad de software
- La Universidad de Texas @ Dallas; Stqa
Conclusión
El papel del software en la sociedad continúa creciendo, y al mismo tiempo, el software del mundo se vuelve más complejo. Para que el mundo funcione, debemos tener métodos y estrategias para probar y validar el software que creamos realizando las funciones que pretende realizar. Para cada sistema de software complejo, debe existir una estrategia de prueba y un plan de prueba para continuar validando la funcionalidad del software a medida que continúan mejorando y proporcionan su función.