Métodos básicos de prueba de productos de software. Terminología asociada a las pruebas unitarias. Técnicas de resolución de problemas para pruebas de software

Pruebas es un método de investigación que permite identificar el nivel de conocimientos, destrezas, habilidades y otros rasgos de personalidad, así como su cumplimiento de ciertos estándares mediante el análisis de la forma en que el sujeto realiza una serie de tareas especiales. Estas tareas suelen denominarse pruebas. Una prueba es una tarea estandarizada o tareas relacionadas de manera especial que permiten al investigador diagnosticar el grado de expresión de la propiedad en estudio en el sujeto, sus características psicológicas, así como su actitud hacia determinados objetos. Como resultado de las pruebas, generalmente se obtiene una determinada característica cuantitativa que muestra el grado de gravedad del rasgo en estudio en un individuo. Debe estar correlacionado con los estándares establecidos para esta categoría de materias.

Esto significa que con la ayuda de pruebas es posible determinar el nivel actual de desarrollo de una determinada propiedad en el objeto de estudio y compararlo con el estándar o con el desarrollo de esta cualidad en el sujeto en un período anterior.

Existen ciertas reglas para realizar pruebas e interpretar los resultados obtenidos. Estas reglas están bastante claramente desarrolladas y las principales tienen el siguiente significado:

1) informar al sujeto sobre los propósitos de la prueba;

2) familiarizar al sujeto con las instrucciones para realizar las tareas de prueba y lograr la confianza del investigador de que las instrucciones se entendieron correctamente;

3) garantizar una situación en la que los sujetos puedan realizar tareas con calma e independencia; mantener una actitud neutral hacia los examinados, evitando sugerencias y ayuda;

4) el cumplimiento por parte del investigador de las instrucciones metodológicas para el procesamiento de los datos obtenidos y la interpretación de los resultados que acompañan a cada prueba o tarea correspondiente;

5) prevenir la difusión de información psicodiagnóstica obtenida como resultado de las pruebas, asegurando su confidencialidad;

6) familiarizar al sujeto con los resultados de la prueba, proporcionándole a él o al responsable la información relevante, teniendo en cuenta el principio "¡No hacer daño!"; en este caso, surge la necesidad de resolver una serie de problemas éticos y morales;

7) acumulación por parte del investigador de información obtenida por otros métodos y técnicas de investigación, su correlación entre sí y determinación de la coherencia entre ellos; enriqueciendo su experiencia con la prueba y el conocimiento sobre las características de su aplicación.

También existen varios tipos de pruebas, cada una de las cuales va acompañada de los procedimientos de prueba correspondientes.

Prueba de aptitud permiten identificar y medir el nivel de desarrollo de determinadas funciones mentales y procesos cognitivos. Estas pruebas se asocian con mayor frecuencia con el diagnóstico de la esfera cognitiva del individuo, las características del pensamiento y, por lo general, también se denominan intelectuales.

Estos incluyen, por ejemplo, la prueba de Raven, la prueba de Amthauer, las subpruebas correspondientes de la prueba de Wechsler, etc., así como las pruebas de tareas de generalización, clasificación y muchas otras pruebas de carácter investigativo.

Pruebas de rendimiento se centran en identificar el nivel de desarrollo de conocimientos, habilidades y capacidades específicas, tanto como una medida del éxito en la implementación como una medida de la preparación para realizar alguna actividad. Todos los casos de exámenes de prueba pueden servir como ejemplos. En la práctica se suelen utilizar “baterías” de pruebas de rendimiento.

Pruebas de personalidad tienen como objetivo identificar los rasgos de personalidad de los sujetos. Son numerosos y variados: hay cuestionarios de estados y composición emocional del individuo (por ejemplo, tests de ansiedad), cuestionarios de motivación para la actividad y preferencias, determinaciones de rasgos de personalidad y relaciones.

Existe un grupo de pruebas llamadas proyectivas, que nos permiten identificar actitudes, necesidades e impulsos inconscientes, ansiedades y un estado de miedo.

El uso de pruebas siempre está asociado a medir la manifestación de una u otra propiedad psicológica y evaluar el nivel de su desarrollo o formación. Por tanto, la calidad de la prueba es importante. La calidad de una prueba se caracteriza por los criterios de su precisión, es decir Fiabilidad y Validez.

La confiabilidad de una prueba está determinada por qué tan estables son los resultados obtenidos y qué tan independientes son de factores aleatorios. Por supuesto, estamos hablando de comparar los testimonios de los mismos sujetos. Esto significa que una prueba confiable debe tener puntajes consistentes en múltiples pruebas y puede estar seguro de que la prueba detecta lo mismo.

propiedad. Se utilizan varios métodos para comprobar la fiabilidad de las pruebas.

Una forma es la repetición de pruebas que acabamos de mencionar: si los resultados de la primera prueba y de las repetidas después de un cierto tiempo muestran la presencia de un nivel suficiente de correlación, esto indicará la confiabilidad de la prueba. El segundo método implica el uso de otra forma equivalente de prueba y la presencia de una alta correlación entre ellas. También es posible utilizar un tercer método para evaluar la confiabilidad, cuando la prueba permite dividirla en dos partes y una.

y se examina al mismo grupo de sujetos utilizando ambas partes de la prueba. La confiabilidad de una prueba muestra con qué precisión se miden los parámetros psicológicos y qué tan alta puede ser la confianza del investigador en los resultados obtenidos.

La validez de la prueba responde a la pregunta de qué revela exactamente la prueba y qué tan adecuada es para identificar lo que se pretende hacer. Por ejemplo, las pruebas de capacidad a menudo revelan algo diferente: formación, la presencia de experiencia relevante o, por el contrario, la falta de ella. En este caso, la prueba no cumple con los requisitos de validez.

En psicodiagnóstico existen diferentes tipos de validez. En el caso más simple, la validez de una prueba suele determinarse comparando los indicadores obtenidos como resultado de la prueba con valoraciones de expertos sobre la presencia de esta propiedad en los sujetos (validez actual o validez “simultánea”), así como analizando datos obtenidos como resultado de la observación de los sujetos en diversas situaciones de la vida y el trabajo, y sus logros en el campo correspondiente.

La cuestión de la validez de una prueba también se puede resolver comparando sus datos con indicadores obtenidos mediante una técnica asociada a una técnica determinada, cuya validez se considera establecida.

Estudio de productos de actividad. es un método de investigación que permite estudiar indirectamente la formación de conocimientos y habilidades, intereses y habilidades de una persona a partir del análisis de los productos de sus actividades. La peculiaridad de este método es que el investigador no entra en contacto con la persona misma, sino que se ocupa de los productos de sus actividades o pensamientos anteriores sobre lo que

Los cambios se produjeron en el propio sujeto en el proceso y como resultado de su inclusión en un determinado sistema de interacciones y relaciones.

Existen varias metodologías para las pruebas dinámicas de software. Dependiendo de si el evaluador tiene acceso al código fuente del programa, se distinguen los siguientes métodos de prueba:

• Método de caja negra
• Método de caja blanca
• Método de caja gris

Método de caja negra.

El término "caja negra" fue mencionado por primera vez por el psiquiatra W. R. Ashby en su libro "Introducción a la cibernética" en 1959. Escribió que el método de la caja negra permite estudiar el comportamiento de un sistema haciendo abstracción de su estructura interna.

En el ámbito de las pruebas, el método de la caja negra es una técnica de prueba que se basa en trabajar con las interfaces externas del software, sin conocimiento del funcionamiento interno del sistema.

Este método se llama "Caja Negra", porque en este método el software bajo prueba le parece al evaluador una caja negra, dentro de la cual ocurren algunos procesos, pero el evaluador no sabe absolutamente nada sobre ellos. Esta técnica le permite detectar errores en las siguientes categorías:

• · Errores de interfaz.
• · Funciones faltantes o implementadas incorrectamente.
• · Rendimiento insuficiente del sistema o errores de comportamiento.
• · Estructuras de datos incorrectas o mala organización del acceso a bases de datos externas.

Por lo tanto, dado que el evaluador no tiene idea de las partes internas y la estructura del sistema, necesita concentrarse en lo que hace el programa, en lugar de cómo lo hace.

Método de caja blanca.

Como sugiere el nombre, este método de prueba es lo opuesto al método de caja negra. Este método de prueba se basa en el análisis de la estructura interna del sistema.

Es decir, en este caso, el evaluador conoce todos los aspectos de la implementación del software bajo prueba. Este método le permite probar no solo la exactitud de la respuesta de un programa a una entrada específica (como en el caso de una caja negra), sino también el funcionamiento correcto de módulos y funciones individuales, basándose en el conocimiento del código que procesará esto. aporte. El conocimiento de las características de implementación del programa bajo prueba es un requisito obligatorio para que el evaluador pueda utilizar esta técnica con éxito. Las pruebas de caja blanca le permiten profundizar en las partes internas del software, más allá de sus interfaces externas.

Método de la caja gris.

Este método de prueba del sistema implica una combinación de enfoques de Caja Blanca y Caja Negra. Por tanto, el evaluador sólo conoce parcialmente la estructura interna del programa. Por ejemplo, se supone que hay acceso a la estructura interna del software para desarrollar los casos de prueba más efectivos, mientras que las pruebas en sí se llevarán a cabo utilizando un método de caja negra. O los evaluadores pueden seguir el método de la caja negra en todo, pero para asegurarse de que los algoritmos individuales funcionen correctamente, pueden mirar la información en los registros o analizar los registros del programa en una base de datos.

Tarde o temprano, muchas organizaciones que utilizan tal o cual software se ven en la necesidad de organizar un proceso de prueba. Por lo general, hay varias razones, o se trata de una startup que requiere inmediatamente probar su software, o la gerencia comienza a comprender que, además de las pruebas comerciales, el mantenimiento, el desarrollo y todos los demás que pueden participar en la empresa, hay especialistas en pruebas profesionales. todavía se necesita quién releve a todas las demás personas, sin tener un conocimiento normal de las pruebas. Y es a partir de este momento que a menudo comienza el tradicional nombramiento de uno de los empleados actuales para el puesto de jefe del departamento de pruebas, tradicional en nuestro trabajo. Como, aquí tienes un campo, siémbralo... No importa lo que hagas, pero el departamento debe existir y debe dar resultados. Por supuesto, no siempre todo es tan malo; alguien todavía está buscando especialistas en pruebas competentes para este puesto, pero aun así todavía no existe un proceso de prueba en esta etapa y es necesario crearlo.

Y muy a menudo, muchos gerentes comienzan a crear un proceso de prueba no de manera sistemática, sino selectiva. Pero al mismo tiempo, si organizamos el proceso de prueba simplemente seleccionando las mejores prácticas, sin tener un enfoque sistemático, entonces dicho proceso no traerá resultados positivos ni en un mes ni en un año.

Creo que mucha gente sabe que si el proceso de prueba no se organiza correctamente desde el principio, será extremadamente difícil cambiarlo más adelante. Por lo tanto, ¿es necesario determinar cómo organizar adecuadamente el proceso de prueba?

¿Por dónde empezar a organizar el proceso de prueba?

Identifico 11 criterios principales al organizar el proceso de prueba:

1. Objetivos y alcance de las pruebas.
2. Equipo
3. Control
4. Comunicación e interacción
5. Metodología de prueba
6. Documentación del proceso
7. Gestión de riesgos
8. Medición de procesos
9. Herramientas
10. Entornos de prueba
11. La mejora de procesos

Es el cumplimiento de todos estos criterios lo que permite que el proceso de prueba se desarrolle de manera uniforme, lo que en poco tiempo le permite alcanzar un nivel en el que el proceso de prueba traerá resultados positivos.

Por lo tanto, cualquier gerente que se enfrente a la tarea de organizar el proceso de prueba debe plantearse las siguientes preguntas:

• ¿Por qué necesitamos pruebas?
• ¿Qué tenemos que hacer pruebas?
• ¿Qué procesos es necesario formalizar o crear?
• ¿Cómo y qué debemos probar?

Sólo después de recibir respuestas a estas preguntas podremos comenzar a avanzar hacia las normas.

Destaco los siguientes estándares que realmente necesitas estudiar antes de comenzar a construir un proceso:

• ISO 29119
• IEEE 829\1008
• TPI Next&TMap
• ISTQB

Naturalmente, es imposible utilizar plenamente las prácticas establecidas en las normas. Cualquier estándar debe personalizarse para satisfacer las necesidades de su proceso de prueba específico, porque la implementación irreflexiva de prácticas estándar puede tener consecuencias adversas porque su proceso de prueba no cumplirá con los requisitos comerciales.

¡Cualquier proceso de TI siempre debe satisfacer las necesidades comerciales!

Analizaremos los principales criterios para construir un proceso de prueba.

Objetivos y alcance de las pruebas.

El propósito de las pruebas es detectar defectos, verificar que el software cumpla con los requisitos establecidos y proporcionar comentarios sobre los defectos a todas las partes interesadas.

Este es un objetivo estándar del proceso de prueba, pero también puede haber objetivos determinados por las necesidades comerciales de la organización. Por ejemplo, es típico de los bancos que varios requisitos del Banco Central se implementen de manera oportuna, por lo que, además del objetivo general de realizar pruebas, también se agrega la ejecución oportuna de pruebas con la calidad requerida para tareas críticas.

Hablando del área de pruebas, debemos entender perfectamente qué es exactamente lo que tenemos que probar. Estos pueden ser sistemas, componentes, procesos de negocio. Para entender esto, sólo necesitas responder dos preguntas:

• ¿Qué se debe probar?
• ¿Qué probaremos?

A menudo, lo que hay que probar y lo que probaremos pueden diferir mucho. Depende de las capacidades de su proceso de prueba. “Lo que se necesita” a menudo lo dictan las empresas y la gerencia, por lo que un buen gerente siempre debe comprender “lo que se necesita” para probar. Como dice el refrán: "Si persigues dos liebres, no atraparás ninguna", así está aquí. Siempre es mejor probar cualitativamente lo que realmente puedes probar con tu equipo que tomar todo lo que pide la empresa y no hacer nada a tiempo, e incluso pasar por alto defectos críticos.

equipo y gestion

El equipo es el componente más importante del proceso de prueba. Sin un equipo, tú, como líder, no harás nada. A menudo existen varios enfoques para formar un equipo:

Herramientas e infraestructura

¿Qué es el proceso de prueba sin herramientas? Esto resulta ser trabajo manual por el bien del trabajo manual :) Creo que muchos de ustedes han oído hablar a menudo de escribir casos de prueba en documentos de Word, de crear gráficos y diagramas en Excel. Pero, ¿por qué desperdiciar esfuerzos si el mercado nos ofrece productos de gestión de pruebas ya preparados, como HP ALM, MS TFS, TestRail, TestLink, JIRA Zephyr y muchos otros?
Por lo tanto, si ha comenzado a organizar el proceso de prueba, haga que este proceso sea conveniente y efectivo. Escriba casos de prueba en formas convenientes de productos terminados, integre herramientas con un sistema de gestión de tareas, personalícelos, etc.

Al abordar la elección de una herramienta, siempre se debe comprender:

• ¿Qué tareas planeas realizar?
• ¿Cuál es su presupuesto para herramientas?

Una vez recibidas las respuestas a estas preguntas, podrá determinar las herramientas de prueba que le resulten más convenientes y tal vez desarrollar las suyas propias.

Además de las herramientas de gestión de pruebas, las herramientas de prueba también incluyen:

• Sistema de gestión de defectos y tareas (se puede incluir en el sistema de gestión de pruebas)
• Herramientas auxiliares (para capturas de pantalla, tomar registros, trabajar con bases de datos, SOUP UI para XML, etc.)
• Herramientas de automatización (, Selenium, etc.)
• Sistemas de gestión del conocimiento (en motor wiki)

Ahora hablemos de infraestructura. En el contexto actual de mi historia, me refiero a entornos de prueba.

En casi cualquier organización, especialmente si la organización es grande y no desarrolla aplicaciones móviles para el mercado de juegos, necesitará uno o más entornos de prueba para realizar las pruebas. La capacidad y el volumen de integración del sistema en entornos de prueba pueden variar según el volumen de pruebas.

Como estándar, identifico los siguientes tipos de entornos de prueba:

• Entorno de desarrollo (¿se puede clasificar como entorno de prueba?, pero aún así)
• Entorno de prueba del sistema (se pueden implementar uno o más sistemas, componentes, no requiere mucha energía)
• Entorno de integración (un entorno de integración completo para probar la funcionalidad de los procesos comerciales de un extremo a otro)
• Medio ambiente (el requisito principal es que la potencia corresponda al circuito de combate)
• Entorno ProdLike/PreProd (entorno para depurar una compilación probada ya preparada y realizar pruebas de instalación)

La capacidad de organizar una cantidad tan grande de entornos de prueba le permite realizar trabajos de prueba superponiéndolos uno encima del otro, aumentando así la cantidad de cambios (lanzamientos, sprints) que pueden ocurrir en paralelo, pero en diferentes etapas de la prueba.

La mejora de procesos

Muy a menudo digo la frase "Cualquier proceso, pase lo que pase, siempre debe mejorarse constantemente", a lo que muy a menudo escucho "Bueno, nuestro proceso ya funciona bien".

Pero eso no es cierto. Por qué debemos mejorar constantemente el proceso de prueba:

1. Los objetivos de las pruebas no pueden ser los mismos; cambian constantemente según las necesidades del negocio, que dicta el mercado.

2. El sector de TI está en constante evolución. Están surgiendo nuevas tecnologías y enfoques que siempre nos permiten mejorar el proceso de prueba.

Como dicen, ¡no hay límites para la perfección!

Bueno, cómo mejorar es el ciclo estándar de Demming.

Planificado - Realizado - Analizado - Ajustado

Bueno, en conclusión, diré que el correcto permite crear en el menor tiempo posible un proceso de prueba verdaderamente efectivo que resuelva las metas y objetivos planteados para el mismo.

Introducción

Los métodos de prueba de software actuales no nos permiten identificar de manera inequívoca y completa todos los defectos y establecer el funcionamiento correcto del programa analizado, por lo que todos los métodos de prueba existentes operan en el marco de un proceso de verificación formal del software que se está investigando o desarrollando.

Este proceso de verificación formal, o verificación, puede acreditar que no existen defectos en cuanto al método utilizado. (Es decir, no hay forma de establecer o garantizar con precisión la ausencia de defectos en un producto de software, teniendo en cuenta el factor humano presente en todas las etapas. ciclo de vida del software).

Existen muchos enfoques para resolver el problema de las pruebas y verificación de software, pero las pruebas efectivas de productos de software complejos son un proceso altamente creativo que no se reduce a seguir o crear procedimientos estrictos y precisos.

Las pruebas estáticas también incluyen pruebas. requisitos , especificaciones , documentación.

Pruebas de regresión

Después de realizar cambios en la siguiente versión del programa, las pruebas de regresión confirman que los cambios realizados no afectaron el rendimiento del resto de funciones de la aplicación. Las pruebas de regresión se pueden realizar manualmente o utilizando automatización de pruebas.

Guiones de prueba

Los evaluadores utilizan scripts de prueba en diferentes niveles: tanto en pruebas unitarias como en pruebas de integración y sistemas. Los scripts de prueba generalmente se escriben para probar componentes que tienen más probabilidades de fallar o donde un error no encontrado a tiempo podría resultar costoso.

Pruebas de caja blanca y caja negra

En la terminología de los profesionales de pruebas, las frases "pruebas de caja blanca" y "pruebas de caja negra" se refieren a si el desarrollador de la prueba tiene acceso al código fuente del software bajo prueba, o si las pruebas se realizan a través de una interfaz de usuario o programación de aplicaciones. interfaz proporcionada por la unidad bajo prueba.

En prueba de caja negra, el probador tiene acceso al software sólo a través del mismo interfaces, como cliente o usuario, o a través de interfaces externas que permiten que otra computadora u otro proceso se conecte al sistema para realizar pruebas. Por ejemplo, un módulo de prueba puede presionar virtualmente teclas o botones del mouse en el programa bajo prueba usando un mecanismo de comunicación de proceso, con la confianza de que todo va correctamente y que estos eventos producen la misma respuesta que las pulsaciones de teclas y botones del mouse reales. Generalmente, prueba de caja negra llevado a cabo utilizando especificaciones u otros documentos que describen los requisitos del sistema. Como regla general, en este tipo de pruebas criterio de cobertura consiste en cubrir la estructura de los datos de entrada, requisitos de cobertura y cobertura del modelo (en pruebas basadas en modelos).

En las pruebas de caja gris, el desarrollador de la prueba tiene acceso al código fuente, pero cuando se ejecutan las pruebas directamente, generalmente no se requiere acceso al código.

Mientras que las pruebas "alfa" y "beta" se refieren a las etapas previas al lanzamiento de un producto (y también, implícitamente, al tamaño de la comunidad de pruebas y las limitaciones de los métodos de prueba), las pruebas de caja blanca y de caja negra se refieren a las formas en que en el que el evaluador logra el objetivo.

Las pruebas beta en general se limitan a las pruebas de caja negra (aunque una parte permanente de los evaluadores generalmente continúan con las pruebas de caja blanca en paralelo con las pruebas beta). Por lo tanto, el término "prueba beta" puede indicar el estado del programa (más cerca de su lanzamiento que "alfa"), o puede indicar algún grupo de evaluadores y el proceso realizado por ese grupo. Por lo tanto, un evaluador puede continuar trabajando en pruebas de caja blanca aunque el software ya esté "en fase beta", pero en este caso no forma parte de la "prueba beta" (grupo/proceso).

Cobertura de código

La cobertura del código es, en esencia, pruebas de caja blanca. El software bajo prueba se construye con configuraciones o bibliotecas especiales y/o se ejecuta en un entorno especial, como resultado de lo cual, para cada función del programa utilizada (ejecutada), se determina la ubicación de esta función en el código fuente. Este proceso permite a los desarrolladores y especialistas en control de calidad identificar partes del sistema que, durante el funcionamiento normal, rara vez o nunca se utilizan (como el código de manejo de errores, etc.). Esto permite a los evaluadores concentrarse en probar los modos más importantes.

Los evaluadores pueden utilizar los resultados de las pruebas de cobertura de código para desarrollar pruebas o datos de prueba que extiendan la cobertura del código a características importantes.

Normalmente, las herramientas y bibliotecas utilizadas para obtener cobertura de código requieren costos significativos de rendimiento y/o memoria que son inaceptables para el funcionamiento normal del software. Por tanto, sólo pueden utilizarse en condiciones de laboratorio.

Citas

• "Las pruebas de programas se pueden utilizar para demostrar la presencia de errores, pero nunca mostrarán su ausencia". - Dijkstra, 1970

ver también

• Seguimiento semántico hacia atrás- un método universal para probar cualquier artefacto de diseño

Notas

Literatura

• Glenford Myers, Tom Badgett, Corey Sandler El arte de las pruebas de software, tercera edición. - M.: “Dialéctica”, 2012. - 272 p. - ISBN 978-5-8459-1796-6
• Lisa Crispin, Janet Gregory Pruebas ágiles: una guía práctica para evaluadores y equipos ágiles. - M.: “Williams”, 2010. - 464 p. - (Serie firmada de Addison-Wesley). - 1000 ejemplares. - ISBN 978-5-8459-1625-9
• Kaner Khem, Folk Jack, Nguyen Yong Kek Pruebas de software. Conceptos fundamentales de la gestión de aplicaciones empresariales. - Kiev: DiaSoft, 2001. - 544 p. - ISBN 9667393879
• Culbertson Robert, Brown Chris, Cobb Gary Pruebas rápidas. - M.: “Williams”, 2002. - 374 p. - ISBN 5-8459-0336-X
• Sinitsyn S. V., Nalyutin N. Yu. Verificación de software. - M.: BINOM, 2008. - 368 p. - ISBN 978-5-94774-825-3
• Béizer B. Pruebas de caja negra. Tecnologías para pruebas funcionales de software y sistemas. - San Petersburgo. : Pedro, 2004. - 320 p. - ISBN 5-94723-698-2

Enlaces

• Portal de especialistas en pruebas de software y control de calidad (ruso)
• Portal sobre pruebas de software automatizadas (ruso)
• Calidad del software (ruso)