Phenquestions
Examen de la unidad
La prueba unitaria es la prueba realizada en una función, clase o módulo individual independientemente de la prueba de un software completamente funcional. 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 de unidades para un gran proyecto de software, se garantiza que todas las unidades individuales funcionen como se espera a medida que 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 pueden eliminarse porque ya no son relevantes. 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 garantizará que el producto final funcione como un sistema como se esperaba.
Pruebas funcionales
La prueba funcional es la forma más común de prueba. Cuando las personas se refieren a las pruebas de software sin muchos detalles, a menudo se refieren a pruebas funcionales. Las pruebas funcionales comprobarán que las funciones principales del software funcionan como se esperaba. Se podría escribir un plan de prueba para describir todos los casos de prueba funcional que se probarán, lo que corresponde a las principales características y capacidades del software. La prueba de funcionalidad principal será "camino feliz " pruebas, que no intenta romper el software o usarlo en escenarios desafiantes. Este debe ser el mínimo absoluto de pruebas para cualquier proyecto de software.
Pruebas de integración
Después de la prueba unitaria y la prueba funcional, puede haber varios módulos o todo el sistema que aún no se haya probado en su totalidad. O puede haber componentes que son en gran medida independientes pero que ocasionalmente se usan juntos. Cada vez que 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 que los componentes funcionen juntos 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 un 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 las "pruebas de carga" en el sentido de poner su sistema en alta concurrencia con muchos usuarios que acceden al sistema. Pero estresar un sistema también podría ocurrir en otros vectores. Por ejemplo, ejecutar firmware en un componente de hardware cuando el hardware se ha deteriorado físicamente y está funcionando en modo degradado. El estrés es exclusivo de todos los tipos de software, y los sistemas y el diseño de las pruebas de estrés deben tener en cuenta qué causas naturales o no naturales tienen más probabilidades de estresar su software o sistema.
Prueba de carga
La prueba de carga es un tipo específico de prueba de estrés, como se mencionó anteriormente, en el que se automatizan un gran número de conexiones y accesos de usuarios simultáneos para generar la simulación del efecto de un gran número 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?? Será esto inesperado "CARGA" romper su sitio web o sistema? Las pruebas de carga simularán esto, por lo que se sentirá cómodo con el futuro aumento de usuarios porque sabe que su sistema puede manejar el aumento de carga.
Pruebas de rendimiento
Las personas pueden frustrarse y desesperarse por completo cuando el software no cumple con sus requisitos de rendimiento. El rendimiento, en general, significa la rapidez con la que se pueden completar las funciones importantes. Cuanto más complejas y dinámicas están disponibles las funciones en un sistema, más importante y no obvio se vuelve probar su rendimiento, tomemos un ejemplo básico, sistema operativo Windows o Linux. Un sistema operativo es un producto de software muy complejo y realizar pruebas de rendimiento en su sistema podría implicar la velocidad y el tiempo de funciones como el arranque, la instalación de una aplicación, la búsqueda de un archivo, la ejecución de cálculos en una GPU y / o cualquier otro los millones de acciones que se pueden realizar. Se debe tener cuidado al seleccionar los casos de prueba de rendimiento, para garantizar que las características de rendimiento importantes y que probablemente no funcionen correctamente se prueben.
Prueba de escalabilidad
Probar en su computadora portátil es bueno, pero no lo suficientemente bueno 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 funcionando al unísono, las pruebas que realice localmente en un sistema no descubrirán los errores que ocurren cuando el software se implementa "a escala" en cientos de miles de instancias. En realidad, es probable que sus pruebas nunca puedan ejecutarse a escala completa antes de lanzarse a producción porque sería demasiado costoso y no práctico construir un sistema de prueba con 1000 servidores que cuestan millones de dólares. Por lo tanto, las pruebas de escalabilidad se realizan en varios servidores, pero generalmente no en la cantidad total de servidores de producción para intentar descubrir algunos de los defectos que se pueden encontrar cuando sus sistemas se utilizan en una infraestructura más grande.
Prueba de análisis estático
El análisis estático es una prueba que se realiza inspeccionando el código del software sin ejecutarlo realmente. Para hacer análisis estático, generalmente, usaría una herramienta, hay muchas, una herramienta famosa es Coverity. 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 pueden solucionarse antes de su lanzamiento. Se pueden encontrar errores de memoria, errores de manejo de tipos de datos, desreferencias de puntero nulo, variables no inicializadas y muchos más defectos. Los lenguajes como C y C ++ se benefician enormemente del análisis estático porque los lenguajes brindan una gran libertad a 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 la prueba 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, digamos 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 una cuenta de origen o de destino no existe, y que puede arrojar un error. Porque en circunstancias normales nunca obtenemos este error debido a las pruebas previas 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 pruebe 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 publique en producción, donde podría causar estragos.
Prueba de desbordamiento de memoria
Cuando se utilizan lenguajes como C o C ++, el programador tiene la 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 desreferenciado, el software fallará. Si se asigna memoria a un objeto y luego se copia una cadena en el espacio de memoria del objeto, hacer referencia al objeto puede causar un bloqueo o incluso un comportamiento incorrecto no especificado. Por lo tanto, es fundamental utilizar una herramienta para intentar detectar errores de acceso a la memoria en software que utiliza lenguajes como C o C ++, que podrían tener estos problemas potenciales. Las herramientas que pueden realizar este tipo de pruebas incluyen Open Source Valgrind o herramientas propietarias como PurifyPlus. Estas herramientas pueden salvar el día cuando no está claro por qué el software falla o se comporta mal y apuntan directamente a la ubicación en el código que tiene el error. Impresionante, cierto?
Prueba de caso límite
Es fácil cometer errores en la codificación cuando se encuentra en lo que se llama un límite. Por ejemplo, un cajero automático de un banco dice que puede retirar un máximo de $ 300. Entonces, imagine que el codificador escribió el siguiente código de forma natural al crear este requisito:
Si (amt < 300)startWithdrawl ()
demás
error ("Puede retirar% s", amt);
¿Puedes detectar el error?? El usuario que intente retirar $ 300 recibirá un error porque no es menos de $ 300. Esto es un error. Por lo tanto, las pruebas de límites se realizan de forma natural. Los límites de los requisitos garantizan que en ambos lados del límite y del límite, el software esté funcionando correctamente.
Prueba de fuzz
La generación de entrada de alta velocidad al software puede producir tantas combinaciones de entrada posibles, incluso si esas combinaciones de entrada son una tontería total 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 manual de casos de prueba.
Prueba exploratoria
Cierra los ojos y visualiza lo que significa la palabra "Explorar". Está observando y probando un sistema para descubrir cómo funciona realmente. Imagine que recibe una nueva silla de escritorio en un pedido por correo, y tiene 28 piezas, todas en bolsas de plástico separadas sin instrucciones. Debes explorar tu recién llegado para descubrir cómo funciona y cómo se arma. Con este espíritu, puede convertirse en un probador exploratorio. No tendrá un plan de prueba bien definido de casos de prueba. Explorará y probará su software en busca de cosas que le hagan decir la palabra maravillosa: “INTERESANTE!". Al aprender, investiga más y encuentra formas de romper el software en las que los diseñadores nunca pensaron, y luego entrega un informe que detalla numerosas suposiciones erróneas, fallas y riesgos en el software. Obtenga más información sobre esto en el libro titulado 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 de software, tienen fronteras y límites. Estos límites están destinados a permitir que solo mensajes, personas o componentes específicos ingresen al sistema. Más concretamente, consideremos un sistema bancario en línea que utiliza autenticación de usuario para ingresar al sitio. Si el sitio puede ser pirateado e ingresado en el backend sin la autenticación adecuada, eso 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 eludir el límite de seguridad normal de un sistema de software o sitio web. Las pruebas de penetración a menudo implican verificar todos los puertos que están escuchando e intentar ingresar a un sistema a través de un puerto abierto. Otras técnicas comunes incluyen la inyección de SQL o el descifrado de contraseñas.
Pruebas de regresión
Una vez que tenga un software en funcionamiento que se implemente en el campo, es fundamental evitar 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 funcionalidad antigua deje de funcionar, lo que se denomina 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 un lanzamiento.
Los casos de prueba de regresión y los planes de prueba deben construirse en torno a la funcionalidad principal que debe seguir funcionando para garantizar que los usuarios tengan una buena experiencia con su aplicación. Todas las funciones principales de su software que los usuarios esperan que funcionen 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 entre 50 y 50,000 casos de prueba que cubren la funcionalidad principal de su software o aplicación.
Prueba de bisección de código fuente
Se introdujo un error en el software, pero no es obvio qué versión de la versión introdujo el nuevo error. Imagine que hubo 50 confirmaciones de software desde la última vez que se sabe que el software funcionó sin el error, hasta ahora cuando ..
Prueba de localización
Imagine una aplicación meteorológica que muestre el tiempo actual y proyectado en su ubicación, así como una descripción de las condiciones meteorológicas. La primera parte de las pruebas de localización es garantizar que el idioma, el alfabeto y los caracteres correctos se muestren correctamente, según la ubicación geográfica 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 geolocalizaciones interactuará con la aplicación.
Pruebas de accesibilidad
Algunos de los ciudadanos de 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 asumimos que el 1% de la población es daltónica, y nuestra interfaz de software asume que los usuarios pueden distinguir entre rojo y verde, pero esas personas daltónicas NO PUEDEN notar la diferencia. Por lo tanto, una interfaz bien de software tendrá señales adicionales más allá del color para indicar el significado. Otros escenarios además de las pruebas de daltonismo también se incluirían en las pruebas de accesibilidad del software, como ceguera visual total, sordera y muchos otros escenarios. Un buen producto de software debe ser accesible para un porcentaje máximo de usuarios potenciales.
Prueba de actualización
Las aplicaciones simples en un teléfono, los sistemas operativos como Ubuntu, Windows o Linux Mint, y el software que ejecuta submarinos nucleares necesitan actualizaciones frecuentes. El proceso de actualización en sí mismo 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 introducción del nuevo software además del antiguo podría haber introducido errores. Tomemos un ejemplo simple, tenemos una computadora portátil que ejecuta 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 esté funcionando al 100% como se esperaba o igual que cuando el software se instaló recientemente. Por lo tanto, primero debemos considerar probar la actualización en muchos casos y escenarios diferentes para asegurarnos de que la actualización funcione hasta su finalización. Y luego, también debemos considerar probar la actualización posterior del sistema real para asegurarnos de que el software se instaló y funciona 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 detenidamente con nuestro conocimiento del sistema lo que PODRÍA romper durante una actualización y agregaremos estratégicamente casos de prueba para esas funciones.
Prueba de caja negra y caja blanca
La caja negra y la caja blanca son metodologías de prueba menos específicas y más categorías de pruebas. Esencialmente, pruebas de caja negra, que asumen que el probador no sabe nada sobre el funcionamiento interno del software y crea un plan de prueba y casos de prueba que solo observan el sistema desde el exterior para verificar su función. Las pruebas de caja blanca las realizan 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 blanca y negra encuentren diferentes tipos de defectos.
Blogs y artículos sobre pruebas de software
Las pruebas de software son un campo dinámico y hay muchas publicaciones y artículos interesantes que actualizan a la comunidad sobre el pensamiento más moderno sobre las pruebas de software. Todos podemos beneficiarnos de este conocimiento. Aquí hay una muestra de artículos interesantes de diferentes fuentes de blogs que quizás desee seguir:
- 7 consejos a seguir antes de realizar pruebas sin requisitos; http: // www.revistas de prueba.com /
- 60 mejores herramientas de prueba de automatización: la guía de lista definitiva; https: // testguild.com /
- Herramientas de prueba de bases de datos de código abierto; https: // www.revista de software.com /
- La cobertura de prueba unitaria del 100 por ciento no es suficiente; https: // www.mentes pegajosas.com /
- Pruebas inestables en Google y cómo las mitigamos; https: // prueba.googleblog.com /
- ¿Qué es la prueba de regresión?? ; https: // prueba.io / blog /
- 27 mejores extensiones de Chrome para desarrolladores en 2020; https: // www.lambdatest.com /
- 5 pasos clave de prueba de software que todo ingeniero debe realizar; https: // techbeacon.com /
Productos para pruebas de software
La mayoría de las tareas de prueba valiosas se pueden automatizar, por lo que no debería sorprender que el uso de herramientas y productos para realizar las innumerables tareas de control de calidad del software sea una buena idea. A continuación, enumeraremos algunas herramientas de software importantes y de gran valor para las pruebas de software que puede explorar y ver si pueden ayudar.
JUnit
Para probar software basado en Java, JUnit proporciona un conjunto de pruebas completo para pruebas unitarias y funcionales del código que es amigable con el entorno de Java.
Selenio
Para probar aplicaciones web, Selenium ofrece la capacidad de automatizar las interacciones con los navegadores web, incluidas las pruebas de compatibilidad entre navegadores. Esta es una infraestructura de prueba de primer nivel para la automatización de pruebas web.
Pepino
Un marco de prueba basado en el comportamiento permite a los usuarios comerciales, gerentes de producto y desarrolladores explicar la funcionalidad esperada en lenguaje natural y luego definir ese comportamiento en casos de prueba. Esto hace que los casos de prueba sean más legibles y una asignación clara a la funcionalidad esperada del usuario.
Purificar
Encuentre fugas de memoria y daños en la memoria en tiempo de ejecución ejecutando su software con la instrumentación Purify Plus incorporada que rastrea 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ñalan un informe de errores de codificación, como fugas de memoria y corrupciones. No es necesario volver a compilar o agregar instrumentación al proceso de compilación, ya que Valgrind tiene la inteligencia para comprender dinámicamente el código de su máquina e inyectar instrumentación sin problemas para encontrar errores de codificación y ayudarlo a mejorar su código.
Coverity
Herramienta de análisis estático que encontrará errores de codificación en su software incluso antes de que compile y ejecute su código. Coverity puede encontrar vulnerabilidades de seguridad, violaciones de las convenciones de codificación, así como errores y defectos que su compilador no encontrará. Se pueden encontrar códigos muertos, variables no inicializadas y miles de otros tipos de defectos. Es vital limpiar su código con análisis estático antes de lanzarlo a producción.
JMeter
Un marco de código abierto para pruebas de rendimiento orientado a desarrolladores basados en Java, de ahí la J en el nombre. Las pruebas de sitios web son uno de los principales casos de uso de JMeter, además de las pruebas de rendimiento de bases de datos, sistemas de correo y muchas otras aplicaciones basadas en servidores.
Metasploit
Para pruebas de seguridad y penetración, Metasploit es un marco genérico con miles de características y capacidades. Utilice la consola de interacción para acceder a 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 validación y verificación de software de la Universidad de Kentucky
- Grupo de investigación de pruebas de software de la Universidad Estatal de Dakota del Norte
- Laboratorio inteligente de pruebas de sistemas; Universidad Técnica Checa de Praga
- NASA: Pruebas e investigación de software de Jon McBride (JSTAR)
- Universidad McMaster; Laboratorio de Investigación de Calidad de Software
- Universidad Tecnológica de Ontario; Laboratorio de investigación de calidad de software
- La Universidad de Texas en Dallas; STQA
Conclusión
El papel del software en la sociedad sigue 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 al realizar las funciones que está destinado a realizar. Para cada sistema de software complejo, se debe implementar una estrategia de prueba y un plan de prueba para continuar validando la funcionalidad del software a medida que continúan mejorando y proporcionando su función.
