Software de prueba de sentido común

La historia del desarrollo y uso del software nos ha dejado muchas lecciones aprendidas de las enormes pérdidas financieras y materiales causadas por defectos del software. Estas lecciones nos han obligado a los ingenieros de pruebas a tomar detecciones sólidas para detectar defectos ocultos de software no detectados.

El objetivo final del software de producción es satisfacer las necesidades del cliente. Utilizamos los requisitos del cliente como criterio para evaluar la calidad del software. Creemos que el significado específico de Software Bug incluye los siguientes factores:

• El software no cumple con la funcionalidad y el rendimiento requeridos por los clientes;

• El software excede los requisitos del cliente;

• El software tiene errores que no pueden ser tolerados por los clientes;

• Software El uso no cumple con los hábitos y el entorno de trabajo del cliente.

Teniendo en cuenta el diseño y otros factores, también podemos pensar que los defectos del software también pueden incluir un diseño de software que no cumpla con las especificaciones, no logrando las mejores condiciones (fondos, alcance, etc.). Desafortunadamente, muchos de nosotros estamos más inclinados a pensar que los defectos del software son problemas de tiempo de ejecución, y que las pruebas del software se limitan después de que se envíe el programa.

En el entorno doméstico actual, casi no podemos ver las especificaciones completas y precisas de la demanda de los clientes, y las necesidades de nuestros clientes cambian de vez en cuando. Es imposible realizar pruebas perfectas. Por lo tanto, como excelente probador, la búsqueda de la perfección de la calidad del software es ciertamente nuestro objetivo, pero para aclarar la brecha entre la realidad y el ideal de las pruebas de software, aprenda a elegir y ceda en las pruebas de software, no hay daño en las pruebas de software. .

Los siguientes son algunos de los sentidos comunes de las pruebas de software. La comprensión y la aplicación de estos sentidos comunes nos ayudarán a comprender mejor la escala de las pruebas de software cuando se realizan pruebas de software.

• La prueba está incompleta (la prueba no está completa)

Obviamente, debido a que los requisitos del software son incompletos, la combinación de rutas lógicas del software, una gran cantidad de datos de entrada y la diversidad de resultados Otros factores, incluso un programa extremadamente simple, para agotar todas las rutas lógicas, todos los datos de entrada y verificar todos los resultados son una cosa muy difícil. Tomemos un ejemplo simple, como encontrar el mayor divisor común de dos enteros. Su información de entrada es dos enteros positivos. Pero si probamos el número de todo el campo entero positivo, desde la infinitud de su número, podemos probar que dicha prueba no funcionará en la vida real, incluso si podemos agotar el programa algún día, me temo Nosotros, nuestros hijos y nietos hemos sido viejos por mucho tiempo. Por esta razón, como prueba de software, generalmente usamos el análisis de valor de límite y clase equivalente para realizar la prueba de software real. Encontrar el conjunto de casos de uso mínimo se convierte en una forma necesaria para optimizar la complejidad de la prueba.

• Las pruebas son inmunes (inmunidad a defectos de software)

Los defectos de los programas son tan terribles como la "inmunidad" de los virus, y cuantas más pruebas utilice el evaluador, más inmunes serán. Cuanto más fuerte es, más difícil es encontrar más defectos de software. Podemos llegar a esta conclusión a partir de la teoría de la probabilidad matemática. Suponiendo que hay 500 defectos de software en un programa de 50000 líneas y que los errores de software están distribuidos uniformemente, se puede encontrar un defecto de software cada 100 líneas. Suponemos que el probador pasa algún tiempo buscando defectos de software en X horas /100 líneas. Según este cálculo, cuando el software tiene 500 defectos, se necesitan X horas para encontrar un defecto del software. Cuando solo hay 5 errores en el software, necesitamos 100X horas para cada defecto del software. La práctica ha demostrado que el proceso de prueba real es más exigente que los supuestos anteriores, por lo que debemos reemplazar diferentes métodos de prueba y datos de prueba. Este ejemplo también muestra que un solo método en las pruebas de software no puede abordar de manera eficiente y completa todos los defectos del software, por lo que las pruebas de software se deben probar de tantas maneras como sea posible.

• Las pruebas son "concepto genérico" (prueba completa)

Siempre me he opuesto a las pruebas de software solo después de que se complete el programa. Si la fase posterior a la fase de programación se denomina simplemente prueba de software, aumentará el efecto de amplificación de los defectos en la fase de demanda y la fase de diseño. Esto es muy perjudicial para la calidad del software. Los defectos en la demanda y los defectos de diseño también son defectos del software, recordando que "los defectos del software tienen fertilidad". Las pruebas de software deben abarcar todo el proceso de desarrollo de software. La verificación de requisitos (autoprueba) y la verificación de diseño (autoprueba) también se pueden contar como una de las pruebas de software (recomendada como: prueba de demanda y prueba de diseño). Las pruebas de software deben ser un concepto genérico que cubra todo el ciclo de vida del software para garantizar que se prohíba cada fase del ciclo. Al mismo tiempo, la prueba en sí misma debe tener un tercero para evaluar (auditoría del sistema de información y supervisión de ingeniería de software), es decir, la prueba en sí también debe probarse para garantizar la confiabilidad y eficiencia de la prueba en sí. De lo contrario, no es correcto y es difícil servir a las personas.

También es necesario señalar que la prueba de software es una condición necesaria y no suficiente para mejorar la calidad de los productos de software. La prueba de software es el medio más directo y rápido para mejorar la calidad del producto, pero de ninguna manera es un medio fundamental.

• 80-20 Principios

El 80% de los defectos del software a menudo viven en el 20% del espacio del software. Este principio nos dice que si desea que las pruebas de software sean efectivas, recuerde visitar sus múltiples "ubicaciones" de alto riesgo. Existe una probabilidad mucho mayor de encontrar defectos de software allí. Este principio es de gran importancia para los evaluadores de software para mejorar la eficiencia de las pruebas y la tasa de descubrimiento de defectos. Los probadores inteligentes encontrarán rápidamente más defectos basados ​​en este principio, mientras que los probadores estúpidos siguen buscando sin rumbo.

80-20 Otro aspecto del principio es que podemos encontrar y evitar el 80% de los defectos del software en el análisis del sistema, el diseño del sistema, la etapa de implementación del sistema y el trabajo de prueba. Después de eso, las pruebas del sistema pueden ayudar Identificamos el 80% de los defectos restantes, y el último 5% de los defectos del software solo se pueden revelar después de que el sistema se haya entregado para un amplio rango de uso a largo plazo. Debido a que las pruebas de software solo pueden garantizar la detección de tantos defectos de software como sea posible, no hay garantía de que se detecten todos los defectos de software.

Los principios de 80-20 también se pueden reflejar en los aspectos de automatización de las pruebas de software. Se ha comprobado que el 80% de los defectos de software se pueden descubrir mediante pruebas manuales y el 20% de los defectos de software se pueden detectar mediante pruebas automatizadas. Debido al cruce entre los dos, todavía hay alrededor del 5% de los defectos del software que deben ser descubiertos y corregidos de otras maneras.

• Pruebas de beneficios

¿Por qué implementamos pruebas de software para mejorar la calidad y la eficiencia del proyecto y, en última instancia, para mejorar la eficacia general del proyecto? Por esta razón, podemos descubrir fácilmente el grado que debemos dominar en la implementación de pruebas de software. Las pruebas de software deben encontrar un equilibrio entre los costos de prueba de software y los beneficios de calidad del software. Este punto de equilibrio es el grado que debemos seguir al implementar las pruebas de software. Las actividades unilaterales inevitablemente dañarán el valor y la importancia de las pruebas de software. En general, en las pruebas de software, deberíamos tratar de mantener las pruebas de software simples, no complicar en exceso las pruebas de software, en palabras del físico Einstein: Manténgalo simple pero no demasiado simple.

• La inevitabilidad de los defectos

En las pruebas de software, no todos los defectos del software pueden solucionarse debido a una correlación incorrecta. Aunque algunos defectos de software pueden repararse, inevitablemente introduciremos nuevos defectos de software durante el proceso de reparación. Muchos defectos de software son contradictorios, y la desaparición de una contradicción conducirá inevitablemente a otra contradicción. Por ejemplo, cuando resolvemos las deficiencias de la generalidad, a menudo traemos defectos en la eficiencia de ejecución. Además, en el proceso de reparación de defectos, a menudo sufrimos limitaciones de tiempo y costos, por lo que no podemos reparar de manera efectiva y completa todos los defectos de software. Por lo tanto, evaluar la importancia de los defectos de software, el alcance de la influencia, elegir una solución de compromiso o considerar los defectos de software por factores que no son de software (como mejorar el rendimiento del hardware) es un hecho que debemos enfrentar frente a los defectos de software.

• Las pruebas de software deben tener los resultados esperados

Las pruebas sin resultados esperados no son razonables. Los defectos de software se derivan de comparaciones. Esto es así como no hay un estándar para medir. Si no sabemos o no podemos estar seguros de los resultados esperados, no podemos entender la exactitud de la prueba. Es fácil para las personas sentirse como una persona ciega. Muchos evaluadores a menudo juzgan la aparición de defectos de software por sus propios sentimientos. El resultado es a menudo juzgado por cosas plausibles como resultados correctos, por lo que a menudo se produce una detección errónea.

• El significado de las pruebas de software - Análisis post mortem

¿El propósito de las pruebas de software es simplemente encontrar defectos tan simples? Si es "sí", puedo garantizar que se producirán defectos de software similares en la próxima prueba de software del nuevo proyecto. El viejo dicho dice: "La gente que no conoce la historia repetirá inevitablemente los mismos errores". Sin un análisis cuidadoso de los resultados de las pruebas de software, no podemos entender las causas y las contramedidas de los defectos. Como resultado, tenemos que gastar una gran cantidad de mano de obra y recursos para encontrar defectos de software nuevamente. Desafortunadamente, la mayoría de los equipos de prueba no son conscientes de esto en este momento, y hay una falta de análisis de resultados de prueba en el informe de prueba.

Conclusión:

Las pruebas de software son un proceso que requiere "conciencia". Como evaluador, está tranquilo y se mantiene en la escala, y responde fundamentalmente a las pruebas de software con una comprensión correcta. Espero que este artículo Es útil para los lectores entender las pruebas de software.