Blog de probadores aburridos: escenarios de prueba negativos. Imagen de prueba para pensamiento negativo y positivo Dio un resultado positivo a los productos probados

Al probar producto de software usó una gran cantidad varios tipos pruebas La clasificación más amplia y detallada fue propuesta por el autor del libro “Pruebas Punto Com” Roman Savin. Combinó los tipos de pruebas por motivos tales como el objeto, el sujeto de la prueba, el nivel, la positividad de la prueba y el grado de automatización de la prueba. La clasificación se ha complementado con base en fuentes como el libro Software Testing de Sam Kaner y el recurso de prueba en línea Pro Testing - Software Testing.

Según el objeto de la prueba

· Pruebas funcionales. Las pruebas funcionales son uno de los tipos de pruebas más utilizados en la actualidad. La tarea de tales pruebas es establecer cuánto el software desarrollado (SW) corresponde a los requisitos del cliente en términos de funcionalidad. En otras palabras, la realización de pruebas funcionales le permite comprobar la capacidad sistema de informacion resolver problemas de los usuarios.
· Pruebas no funcionales. Le permite verificar el cumplimiento de las propiedades del software con los requisitos no funcionales establecidos. Por lo tanto, las pruebas no funcionales son las pruebas de todas las propiedades del programa que no están relacionadas con la funcionalidad del sistema. Tales propiedades se pueden presentar características en términos de parámetros tales como:
- Fiabilidad (la capacidad del sistema para responder a situaciones imprevistas).
- Rendimiento (la capacidad del sistema para trabajar bajo cargas pesadas).
- Conveniencia (búsqueda de la experiencia del usuario con la aplicación).
- Escalabilidad (la capacidad de escalar la aplicación tanto vertical como horizontalmente).
- Seguridad (investigación de la posibilidad de interrupción de la aplicación y robo de datos del usuario por parte de intrusos).
- Portabilidad (la capacidad de transferir la aplicación a un conjunto específico de plataformas)

Y muchas otras cualidades.

Pruebas interfaz de usuario. Esto está probando la corrección de la visualización de los elementos de la interfaz de usuario en varios dispositivos, la corrección de su respuesta ante la comisión de diversas acciones por parte del usuario, y una valoración de cómo se espera que se comporte el programa en su conjunto. Estas pruebas permiten evaluar la eficacia con la que el usuario podrá trabajar con la aplicación y cómo apariencia aplicación corresponde a los documentos aprobados creados por los diseñadores. Al probar la interfaz de usuario, la tarea principal del probador es identificar fallas visuales y estructurales en la interfaz gráfica de la aplicación, verificar la posibilidad y facilidad de navegación en la aplicación y la corrección del procesamiento de la entrada de la aplicación desde el teclado, el mouse y otros dispositivos de entrada. La prueba de la interfaz de usuario es necesaria para garantizar que la interfaz cumpla con los requisitos y estándares aprobados, y para garantizar que el usuario pueda trabajar con interfaz gráfica de usuario aplicaciones
· Pruebas de usabilidad. Este es un método de prueba que le permite evaluar el grado de usabilidad de la aplicación, la velocidad de aprendizaje del usuario cuando trabaja con el programa y también cómo los usuarios del producto desarrollado lo encuentran comprensible y atractivo en el contexto de condiciones dadas. Dichas pruebas son necesarias para garantizar la experiencia de usuario más positiva al trabajar con la aplicación.
· Pruebas de seguridad. Le permite identificar las principales vulnerabilidades del software en relación con varios ataques de intrusos. Sistemas informáticos muy a menudo son objeto de ciberataques para interrumpir la operatividad del sistema de información o robar datos confidenciales. Las pruebas de seguridad brindan la oportunidad de analizar la respuesta real y la efectividad de los mecanismos de defensa utilizados en el sistema en caso de un intento de intrusión. Durante las pruebas de seguridad, el probador intenta realizar las mismas acciones que realizaría un cracker real. Cuando un probador intenta hackear el sistema, se puede usar cualquier medio: ataques al sistema usando utilidades especiales; intentos de aprender nombres de usuario y contraseñas utilizando medios externos; Ataques DDOS; generación intencional de errores para detectar la posibilidad de penetración en el sistema en el proceso de su recuperación; explotar vulnerabilidades conocidas del sistema sin parches.
· Pruebas de instalación. Este término significa probar la corrección de la instalación (instalación) de un determinado producto de software. Dichas pruebas generalmente se realizan en entornos creados artificialmente para determinar el grado de preparación del software para la operación. Las principales razones para realizar tales pruebas están relacionadas con la necesidad de verificar el correcto comportamiento del producto de software durante la implementación o actualización automática. Asegurarse de que el software se instala correctamente y es estable es un factor muy importante en la creación de un producto de software, ya que permite a los usuarios comenzar a utilizar el producto más rápido y con menos esfuerzo, al tiempo que garantiza que el producto se comporte correctamente en todos los entornos de software probados.
· Pruebas de configuración. Las pruebas de configuración están diseñadas para evaluar el rendimiento del software en varias configuraciones del sistema. Dependiendo del tipo de producto de software que se esté probando, las pruebas de configuración pueden tener diferentes objetivos. Por lo general, se trata de determinar la configuración de hardware óptima que proporcione suficientes parámetros de rendimiento para que funcione el software o de verificar una configuración de hardware específica (o una plataforma que incluya, además del hardware, el software de terceros necesario para que el programa funcione) para la compatibilidad con el producto que se está probando. Si estamos hablando sobre cliente-servidor software, la prueba de configuración se lleva a cabo por separado para el servidor y por separado para el cliente. Por lo general, cuando se prueba la compatibilidad de un servidor con una determinada configuración, la tarea es encontrar la configuración óptima, ya que la estabilidad y el rendimiento del servidor son importantes. Mientras que al probar un cliente, por el contrario, intentan identificar fallas de software en cualquier configuración y, si es posible, eliminarlas.
· Pruebas de confiabilidad y recuperación después de fallas (stress testing). Este tipo de prueba a menudo se realiza para software que funciona con datos valiosos del usuario, cuya continuidad de operación y velocidad de recuperación de fallas son críticas para el usuario. Las pruebas de falla y recuperación prueban la capacidad del programa para recuperarse rápida y exitosamente de fallas de hardware, interrupciones de la red o errores críticos en el software mismo. Esto permite evaluar las posibles consecuencias de un fallo y el tiempo necesario para el posterior restablecimiento del sistema. Sobre la base de los datos obtenidos durante las pruebas, se puede evaluar la fiabilidad del sistema en su conjunto y, en caso de un rendimiento insatisfactorio, se pueden tomar las medidas adecuadas para mejorar los sistemas de recuperación.
Pruebas de localización. Las pruebas de localización permiten averiguar qué tan bien se adapta el producto a la población de ciertos países y cómo se corresponde con sus características culturales. Por lo general, se consideran los matices culturales y lingüísticos, a saber, la traducción de la interfaz de usuario, la documentación relacionada y los archivos a un idioma determinado, y también se prueba la corrección de los formatos de monedas, números, horas y números de teléfono.
· Pruebas de estrés. La prueba de carga le permite identificar la cantidad máxima de tareas del mismo tipo que el programa puede realizar en paralelo. El objetivo más popular de las pruebas de carga en el contexto de las aplicaciones cliente-servidor es estimar el número máximo de usuarios que pueden usar simultáneamente los servicios de la aplicación.
· Ensayos de estabilidad. Las pruebas de estabilidad verifican el rendimiento de la aplicación durante el uso a largo plazo con cargas medias. Dependiendo del tipo de aplicación, se forman ciertos requisitos para la duración de su funcionamiento ininterrumpido. Las pruebas de estabilidad buscan identificar problemas de la aplicación, como fugas de memoria, picos de carga severos y otros factores que pueden impedir que la aplicación funcione durante un período prolongado.
· Ensayos volumétricos. La tarea de las pruebas de volumen es identificar la reacción de la aplicación y evaluar el posible deterioro en el funcionamiento del software con un aumento significativo en la cantidad de datos en la base de datos de la aplicación. Por lo general, esta prueba incluye:
- Medición del tiempo de ejecución de operaciones relacionadas con la obtención o cambio de datos de la base de datos ante una determinada intensidad de solicitudes.
- Identificación de la dependencia del incremento en el tiempo de las operaciones sobre la cantidad de datos en la base de datos.
- Determinar el número máximo de usuarios que pueden trabajar simultáneamente con la aplicación sin retrasos apreciables de la base de datos.
Pruebas de escalabilidad. Este es un tipo de prueba de software diseñado para probar la capacidad de un producto para aumentar (a veces disminuir) el alcance de ciertas características no funcionales. Algunos tipos de aplicaciones necesitan escalar fácilmente y, por supuesto, seguir siendo funcionales y soportar una determinada carga de usuarios.

Pruebas relacionadas con cambios

Sanity es uno de los tipos de pruebas, cuyo objetivo es probar el desempeño de una función o módulo en particular de acuerdo con los requisitos técnicos declarados por el cliente. Las pruebas sanitarias se utilizan con bastante frecuencia cuando se comprueba alguna parte de un programa o aplicación cuando se realizan ciertos cambios debido a factores ambientales. Este tipo la prueba generalmente se realiza manualmente.
· La prueba de humo es un ciclo corto de pruebas, cuyo propósito es confirmar el hecho de que la aplicación que se está instalando se inicia y realiza las funciones después de que se haya creado el código nuevo o editado. Al finalizar las pruebas de los segmentos más importantes de la aplicación, se proporciona información objetiva sobre la presencia o ausencia de defectos en el funcionamiento de los segmentos probados. Con base en los resultados de las pruebas de humo, se toma la decisión de enviar la solicitud para su revisión o si debe someterse a más pruebas completas.
· Pruebas de regresión: pruebas destinadas a encontrar errores en áreas ya probadas. Las pruebas de regresión verifican el producto en busca de errores que podrían resultar de agregar una nueva sección del programa o corregir otros errores. El propósito de este tipo de prueba es asegurarse de que la actualización de la compilación o la corrección de errores no generen nuevos errores.

Por nivel de prueba

· Pruebas unitarias (Unit tests). Consiste en comprobar cada módulo individual (elemento original del sistema) mediante la ejecución de pruebas automatizadas en un entorno artificial. Las implementaciones de tales pruebas a menudo usan varios stubs y controladores para imitar el funcionamiento de un sistema real. Las pruebas unitarias automatizadas son la primera oportunidad de ejecutar y probar el código fuente. La creación de pruebas unitarias para todos los módulos del sistema le permite identificar muy rápidamente los errores en el código que pueden aparecer durante el desarrollo.
· Pruebas de integración. Esta es una prueba de los módulos individuales del sistema para una correcta interacción. El objetivo principal de las pruebas de integración es encontrar defectos e identificar comportamientos incorrectos asociados con errores en la interpretación o implementación de la interacción entre módulos.
· Pruebas del sistema. Esta es una prueba del programa como un todo, dicha prueba verifica el cumplimiento del programa con los requisitos establecidos.
· Test de aceptación. Esta es una prueba exhaustiva que determina el nivel real de preparación del sistema para que lo utilicen los usuarios finales. Las pruebas se llevan a cabo sobre la base de un conjunto de escenarios de prueba que cubren las principales operaciones comerciales del sistema.

Por ejecución de código

· Pruebas estáticas. Esta es la identificación de artefactos que aparecen durante el desarrollo de un producto de software mediante el análisis de archivos fuente, como documentación o código de programa. Dicha prueba se lleva a cabo sin ejecutar directamente el código, la calidad de los archivos fuente y su cumplimiento de los requisitos se evalúan manualmente o utilizando herramientas auxiliares. Las pruebas estáticas deben realizarse antes que las pruebas dinámicas, por lo que los errores encontrados durante las pruebas estáticas son menos costosos. desde el punto de vista código fuente, las pruebas estáticas se expresan en revisión de código. Por lo general, una revisión de código archivos individuales se realiza después de cada cambio de estos archivos por parte del programador, la revisión en sí puede ser realizada tanto por otro programador como por el desarrollador principal o por un empleado individual involucrado en la revisión del código. El uso de pruebas estáticas permite mantener la calidad del software en todas las etapas de desarrollo y reduce el tiempo de desarrollo del producto.
· Pruebas dinámicas. A diferencia de las pruebas estáticas, este tipo de pruebas implica ejecutar el código fuente de la aplicación. Por lo tanto, las pruebas dinámicas contienen muchos otros tipos de pruebas que ya se han descrito anteriormente. Las pruebas dinámicas le permiten identificar errores en el comportamiento del programa mediante el análisis de los resultados de su ejecución. Resulta que casi todos los tipos de pruebas existentes corresponden a la clase de pruebas dinámicas.

Por tema de prueba

· Pruebas alfa. Esta prueba es para la mayoría primeras versiones software de computadora (o dispositivo de hardware). Las pruebas alfa casi siempre las realizan los propios desarrolladores de software. Durante las pruebas alfa, los desarrolladores de aplicaciones encuentran y corrigen errores y problemas en el programa. Por lo general, durante las pruebas Alpha hay una imitación del trabajo con el programa por parte de los desarrolladores a tiempo completo, con menos frecuencia hay un trabajo real tanto de usuarios potenciales como de clientes con el producto. Por regla general, las pruebas alfa se llevan a cabo en la etapa más temprana del desarrollo del software, sin embargo, en casos individuales puede aplicarse a un producto terminado o casi terminado, por ejemplo, como prueba de aceptación.
· Pruebas beta. Probando un producto aún en desarrollo. En la prueba beta, este producto está disponible para un número limitado de usuarios con el fin de investigar e informar problemas emergentes que experimentan los usuarios. Dicha prueba es necesaria para encontrar errores que los desarrolladores podrían haber pasado por alto. Por lo general, las pruebas beta se realizan en dos fases: pruebas beta cerradas y pruebas beta abiertas. Una prueba beta cerrada está probando en un círculo estrictamente limitado de usuarios seleccionados. Dichos usuarios pueden ser desarrolladores familiares o sus colegas que no están directamente relacionados con el desarrollo del producto probado. La prueba beta abierta consiste en crear y alojar acceso abierto beta pública. EN este caso Cualquier usuario puede ser un probador beta. Comentario de tales probadores beta se lleva a cabo con la ayuda de revisiones en el sitio y los sistemas de análisis y registro de acciones de los usuarios integrados en el programa, estos sistemas son necesarios para analizar el comportamiento de los usuarios y detectar dificultades y errores que encuentran.

Según la positividad del escenario

· Pruebas positivas. Las pruebas de escenario positivo prueban la capacidad de un programa para realizar su funcionalidad prevista. Como regla general, para tales pruebas, se desarrollan escenarios de prueba, durante los cuales, en condiciones normales de funcionamiento del software, no debería haber ninguna dificultad.
· Pruebas negativas. Las pruebas de software negativas ocurren en escenarios que corresponden a un comportamiento anormal del programa. Estas pruebas comprueban la corrección del programa en situaciones de emergencia. Esto le permite asegurarse de que el programa genera los mensajes de error correctos, no daña los datos del usuario y se comporta correctamente en general en situaciones en las que no se pretende el comportamiento normal del producto. El objetivo principal de las pruebas negativas es probar la estabilidad del sistema ante diversas influencias, la capacidad de validar correctamente los datos de entrada y manejar las excepciones que surgen tanto en los propios algoritmos de software como en la lógica comercial.

Por grado de automatización

· Prueba manual. La prueba manual se lleva a cabo sin el uso de herramientas adicionales. herramientas de software, te permite probar un programa o sitio web simulando las acciones del usuario. En este modelo, el probador actúa como usuario, siguiendo ciertos escenarios, mientras analiza la salida del programa y su comportamiento en general.
· Pruebas automatizadas. Dichas pruebas permiten, mediante el uso de software adicional para automatizar las pruebas, acelerar significativamente el proceso de prueba. Dicho software adicional le permite controlar y administrar la ejecución de las pruebas y comparar los resultados esperados y reales del programa. Más detalles serán discutidos más adelante.

El artículo ha sido revisado teniendo en cuenta las críticas y recomendaciones recibidas en el foro.

Con este artículo, me gustaría describir mi comprensión de las pruebas de software: el proceso no es trivial, como siempre pensé, y, ni siquiera podía imaginar, muy interesante.

Siempre me ha interesado lo que son las pruebas de software. ¿Por qué contratar a alguien para probar un producto de software si el propio desarrollador puede dedicar un par de horas a una tarea de tan baja prioridad? Y finalmente, ¿por qué probar en absoluto? Después de todo, los programadores son tipos inteligentes: escriben correctamente. Pero

No todo es tan simple como me parecía.

Habiendo pasado de programadores a probadores, sin tener suficiente teoría en mi seno, traté durante mucho tiempo de "romper" el producto de software, dando datos de entrada deliberadamente incorrectos a la entrada. Y, curiosamente, se rompió. Se creó un mensaje de error y el día siguiente se consideró bien vivido.

Más tarde, comencé a enfrentar el hecho de que, sin importar cuántas pruebas realices, aún surgen errores. Al no tener idea de qué y cómo se debe dar "como entrada" a la aplicación bajo prueba, el proceso de prueba parecía interminable. Como resultado - un círculo vicioso, en el que los plazos incumplidos para las pruebas, enojado PM y desarrolladores cansados de "tonterías".

Y solo mucho más tarde, destaqué para mí una secuencia clara de acciones que se deben realizar para probar el software:

Estudiar la especificación. Esta etapa es la más importante y también se denomina diseño y/o análisis de requisitos. A veces se usa el nombre de "prueba de especificación", un poco más adelante entenderemos por qué es "prueba". Aquí debe leer detenidamente la documentación (especificaciones) de la aplicación.
Prueba de humo. En esta etapa, es necesario verificar si el sistema funciona (funciona correctamente, "jura" correctamente si no se procesa correctamente, etc.). Esto se hace para comprender si la aplicación es adecuada para realizar más pruebas o si no funciona en absoluto (no funciona correctamente).
Pruebas "positivas". En esta tercera etapa, debe verificar el resultado de la aplicación cuando recibe los datos de entrada "correctos".
Pruebas "negativas". Esta es la cuarta y última etapa de las pruebas iniciales. Aquí debe ver cómo se comporta la aplicación, recibiendo datos "incorrectos" como entrada. Esto se hace para determinar cómo se comporta la aplicación en tal caso. Si dicha opción se describe en la especificación y debe describirse, compare el resultado esperado con el resultado obtenido.

Entonces, consideremos todo en orden.

Especificación, requisitos, SRS.

¿Cómo determinar cuándo y cómo debe funcionar la aplicación en sí, cuándo y cómo debe "romperse" (es decir, cómo debe reaccionar el sistema o su módulo ante datos no válidos o comportamiento incorrecto del usuario)? ¿Cuál debe ser el resultado de un procesamiento correcto, bajo qué condiciones y datos de entrada debe tener lugar un procesamiento correcto? ¿Cuál debe ser el resultado de un procesamiento incorrecto de la solicitud bajo prueba, en qué condiciones debe tener lugar?

Todas estas preguntas se responden en la documentación de la aplicación bajo prueba. En cualquier caso, él, la respuesta, debe estar allí, de lo contrario la documentación no está completa, lo que equivale a un error en la documentación. Quiero hacer una reserva de que ya en esta etapa pueden ocurrir los primeros defectos: un defecto en la especificación (en los requisitos) tiene la misma importancia para el sistema (y a veces más alto por prioridad!) defecto. También vale la pena mencionar que la prueba de requisitos es un tipo de prueba tan completo, al que se le presta poca atención inmerecidamente. Los principales indicadores de la prueba exitosa de los requisitos es el logro de los criterios de completitud (probabilidad) y consistencia de los requisitos.

La documentación le permite comprender por sí mismo los pasos principales para verificar la aplicación, dónde y cómo debería funcionar la aplicación, dónde se "rompe". Y, no menos importante, Cómo romper. Qué "decir" en caso de un procesamiento exitoso, qué mensajes de error pueden/deben aparecer durante el procesamiento.

Habiendo entendido toda la "sabiduría" de los requisitos para la aplicación y las características de la implementación de estos requisitos por parte del desarrollador, puede comenzar a probar el resultado final.

Proceso de prueba

Este proceso se puede describir mediante los siguientes pasos:

Verifique cómo funciona la aplicación cuando recibe datos "correctos" como entrada (para saber "qué es bueno y qué es malo" leemos la documentación);
Si todo funciona y funciona correctamente (es decir, exactamente como se describe en la especificación), el siguiente paso es verificar los valores límite (es decir, dónde comienzan y terminan los datos "correctos");
Verificación del funcionamiento de la aplicación al ingresar datos que no están incluidos en el rango de valores válidos (nuevamente, consulte la especificación).

Los párrafos primero y segundo describen un proceso llamado prueba "positiva". Las pruebas "positivas" son pruebas en datos o escenarios que corresponden al comportamiento normal (regular, esperado) del sistema bajo prueba.

El tercer punto describe el proceso opuesto al proceso "positivo" - prueba "negativa". Se trata de probar datos o escenarios que corresponden a un comportamiento anormal del sistema bajo prueba: varios mensajes de error, excepciones, estados "más allá", etc.

Sin embargo, las pruebas "positivas" y "negativas" deben ir precedidas de pruebas de "humo".

El Diccionario de información da una definición bastante clara del término "prueba de humo":

una forma rudimentaria de probar un producto de software después de cambiar su configuración o después de cambiarlo (el producto de software) en sí mismo. Durante el proceso de prueba de humo, el probador verifica el software para detectar la presencia de "humo", es decir, buscando cualquier errores críticos programas;
la primera ejecución de un programa después de romperlo o "construirlo".

Prioridades en las pruebas

¿Por qué las pruebas "positivas" se consideran un orden de magnitud más importante que las pruebas "negativas"?

Supongamos que el sistema no es demasiado resistente a las entradas "malas". ¿Esto da miedo? A menudo no demasiado. Los usuarios tarde o temprano aprenderán a eludir las "trampas", no realizarán acciones "peligrosas" o "no autorizadas", el servicio apoyo técnico pronto recordará qué problemas suelen tener los usuarios y dará consejos como “en ningún caso dejes este campo en blanco, de lo contrario…”.

Pero, todo esto no sucederá en absoluto si el sistema no cumple con su objetivo principal, si los usuarios (clientes) no pueden resolver sus problemas comerciales, si hacen todo bien, ingresan buenos datos, pero no obtienen resultados. Y no hay nada que aconsejarlos en esta situación. Y se van...

Esta es la razón por la que las pruebas "positivas" son mucho, mucho más importantes que las pruebas "negativas".

Sin embargo, esto no significa que se puedan descuidar las pruebas "negativas", porque. No en todas las etapas del ciclo de vida del software, las prioridades de los valores permanecen sin cambios.

Resumen

Ahora, después de haber dado los primeros pasos exitosos para probar la aplicación y haber recibido un resultado positivo, puede pensar en formas más sofisticadas de probar la aplicación, como dicen: "Más, más". Todo depende de la profundidad del nivel de prueba requerido, el deseo y la capacidad de probar la aplicación. Naturalmente, las cuatro etapas descritas anteriormente no cubren el ciclo completo de prueba de la aplicación, pero son obligatorias para la prueba inicial.

Nosotros (no es un secreto) estamos muy preocupados por la calidad de nuestros productos y observamos con temor el colapso del sistema. Esto justifica la existencia de probadores en el mundo. Nos hace sentir como héroes: ¡el gran Tester vino y salvó a sus usuarios de terribles errores críticos!

Y nuestros evaluadores nunca se olvidan de las pruebas negativas, aunque no todos los progresistas están contentos con eso. Pero tales controles no son un capricho de los "probadores malvados", son causados por la necesidad de cerrar vulnerabilidades y protegerse de piratas informáticos y bots, ataques Dos / DDos que ingresan al sistema.

Por supuesto, ¿cuál es la vocación de los especialistas en pruebas? Necesidad de encontrar problemas. Problemas en los que la mayoría de las veces nadie tiene tiempo para pensar, no quiere verlos y tratarlos. Y si no solo se comprueba el correcto funcionamiento del sistema, sino también su comportamiento anómalo, entonces se suma tensión en el equipo.

Verá, los programadores escriben software apuntando al resultado, al lanzamiento planificado, ¡vuelan en las alas de la inspiración! Y luego viene la etapa de verificación y numerosas correcciones y ediciones del código "ideal". Y eso es todo, escóndete en todas las direcciones, el sistema está siendo probado.

Para no molestar a nadie, algunos especialistas pueden posponer las pruebas negativas para más tarde o ignorarlas por completo (¡horror!) En aras de reducir el tiempo y el presupuesto. Bueno, ¿para qué comprobar si el programa ni siquiera hace lo que debería, verdad? No.

Pruebas positivas y negativas

Pero primero lo primero. Al probar software con casos de prueba, hay dos conjuntos de controles: positivo y negativo. Y el segundo suele ser más que el primero.

prueba positiva- esta es una verificación del sistema para el cumplimiento de su comportamiento normal (regular, esperado), de acuerdo con los TOR y. Es decir, aquí analizamos si el software hace lo que se espera de él, si la implementación cumple con los requisitos modernos, si se admiten las pautas de la interfaz de usuario, etc.

A prueba negativa- Esto está probando el sistema en busca de un comportamiento anormal. Analizamos si el software es resistente a la entrada de datos incorrectos, cómo se manejan las excepciones, qué información se muestra en los mensajes de error, si es posible interrumpir el funcionamiento del producto y/o afectar el rendimiento de la solución, etc. .

Ya hemos dicho que algunos expertos dejan las pruebas negativas para más tarde o se olvidan de ellas, que es casi lo mismo. Ya sabes, lo que se pospone para más tarde casi siempre queda sin cumplir.

Por lo tanto, en nuestra opinión,

Por lo general, las pruebas negativas y positivas no necesitan separarse ni distribuirse en el tiempo.

Porque, ¿podemos decir que un sistema está funcionando como debería si probamos su respuesta solo a las entradas correctas?

prueba positivo-negativo

Al probar, oh, cuán importantes son la intuición, el sentimiento y los instintos de caza, llámalo como quieras. Y aquí se sienta nuestro ingeniero, revisa el formulario de registro, por ejemplo.

Verifica todo de acuerdo con las especificaciones técnicas y los escenarios de prueba, observa cómo se procesan los datos, que el usuario debe ingresar en los campos (no el hecho de que ingresará, por cierto) y aquí está: ¡insight! Le parece que si ingresa algo de "% adynadyn />" en este campo de inicio de sesión, y no texto sin formato, definitivamente algo sucederá. Algo oscuro y sombrío mal.

¿Y qué? Debe decirse a sí mismo: “No. Ahora tengo que hacer pruebas positivas y nada más. Aquí tengo uno negativo programado para la próxima semana, luego llegará el momento de %adynadyn />. Tal vez"?

Consideramos que este enfoque de las pruebas negativas es ineficaz, y he aquí por qué:

Si realiza pruebas positivas y negativas por separado, será más largo. Al menos porque serán dos iteraciones de prueba.
Los probadores y codificadores viven con fechas límite. Y si el tiempo es estrictamente limitado, posponer las pruebas negativas para más adelante aumenta el riesgo de que se olvide por completo. Después de todo, cuanto más se acerque al momento X, más rápido pasará el tiempo, antes deberá completar las tareas, corregir defectos, aplicar los requisitos comerciales finales (que pueden cambiar) y terminar un montón de otras cosas. Fecha límite: ¡hace calor!
¡La separación de las pruebas negativas y positivas, en nuestra opinión, es simplemente contraria a la naturaleza del probador! Después de todo, su tarea principal es verificar el sistema para todo. acciones posibles usuario final. Y la mayoría de las personas son ilógicas y pueden hacer una variedad de cosas indecentes con el software;)

Nosotros, como probadores, estamos muy preocupados si el sistema contiene errores en los cheques de la categoría negativa. Y sobre todo si las consecuencias de tales errores son críticas para todo el sistema. Pero no tenemos miedo de denunciarlos. Especialmente con un truco bajo la manga: tenemos probadores femeninas en nuestro equipo. ¿Y quién puede defender obstinadamente la “idealidad” del código cuando destrozan el desempeño del proyecto con suaves voces hasta hacerlos añicos? Es lo mismo.

Entonces, ¿qué conclusiones podemos sacar?

¡No se olvide de las pruebas negativas, combínelas con las positivas, reúna especialistas experimentados en un equipo e intente cambiar la tarea de informar sobre los hombros de las niñas! Todo menos el último es 100% recomendable, y tu jefe de proyecto se encargará de ello.

Y, por supuesto, asegúrese de revisar su producto, no piense que los programadores escribirán inmediatamente un código limpio y hermoso: ¡todavía no puede prescindir de los errores! Sin mencionar las numerosas vulnerabilidades, que se confirman con los datos personales y confidenciales que se filtran regularmente en la red.

¿Por qué la gente hace pruebas psicológicas? Naturalmente, cada uno tiene sus propios motivos. Alguien quiere entenderse a sí mismo y "entender lo que soy". Alguien está ansioso por confirmar la opinión predominante sobre su carácter. Alguien simplemente mata el tiempo libre y se divierte. Pero todos, aunque a menudo sin darse cuenta, es decir, puramente, quieren escuchar algo bueno sobre ellos mismos. ¿Para qué? Sí, y eso levanta el ánimo. La prueba que le ofrecemos para pasar tiene el único propósito: traer una gota de positivo a su estado actual. De hecho, esto no es una prueba en absoluto, sino algo así como una predicción positiva. ¡Y ellos, como saben, muy a menudo se hacen realidad!

06.10.2018 16947 +67

¿Quieres saber cómo otras personas perciben tu nombre? Gratis Servicio en línea El análisis fonosemántico le permite descubrir cómo se percibe una palabra en particular a nivel subconsciente. Con él, puede, por ejemplo, elegir un nombre para un niño o un nombre para una empresa.
¡Descubre cómo te sentirás en un mes! Ahora mismo en nuestro sitio puedes calcular tus biorritmos absolutamente gratis. Según los resultados del cálculo, recibirá recomendaciones personales y un cronograma para cambiar los biorritmos para el próximo mes.
Pruebas psicológicas populares Una gran cantidad de pruebas psicológicas populares para todos los gustos. Para hombres, para mujeres, esotéricos, profesionales... ¡Y todo esto online, gratis y sin registro!

Muy preocupado por la calidad de los productos. Esto explica la disponibilidad mundial de probadores de software. Al proporcionar, estas personas aseguran su calidad.

Muchos probadores nunca se olvidarán de las pruebas negativas, aunque no todos los programadores están contentos con esto. Dicho control es necesario para proteger contra piratas informáticos, bots, ataques Dos/DDos.

¿Cuál es la vocación de los probadores? Deben encontrar problemas que no son visibles para los demás. No se demore con las pruebas negativas o estará poniendo el sistema en peligro.

Pruebas positivas y negativas

Empecemos desde el principio. Hay 2 tipos de control cuando se incluyen casos de prueba en las pruebas: positivo y negativo. Este último tiene la ventaja.

prueba positiva es el proceso de verificar el comportamiento correcto de acuerdo con las especificaciones y la documentación. Se realizan pruebas positivas para garantizar que el sistema haga exactamente lo que se espera.

Pruebas negativas es el proceso de verificar el comportamiento incorrecto. A través de tales pruebas, podemos saber que el sistema hará frente a situaciones imprevistas.

prueba positivo-negativo

Para realizar pruebas de software, debe tener intuición o instinto de caza. Un probador es una persona versátil que puede realizar tanto análisis de negocios como pruebas.

Los evaluadores verifican si el proceso se está ejecutando correctamente: si se cumplen los requisitos técnicos y los escenarios de prueba. Ejecutar pruebas positivas y negativas por separado llevará más tiempo que realizarlas todas al mismo tiempo. Esto se debe a que hay dos iteraciones de prueba.

Después de todo, cuanto más se acerque a la hora X, más rápido pasará el tiempo y antes necesitará completar tareas, corregir defectos, aplicar requisitos comerciales (que pueden variar) y hacer más. ¡La fecha límite es el momento más caluroso!

¡Separar las pruebas positivas y negativas es simplemente contrario a la naturaleza del probador! Su tarea es verificar el sistema para todas las acciones posibles del usuario final.

Los humanos son básicamente ilógicos y pueden causar problemas en el software. Las pruebas negativas ayudarán a evitar problemas.

Materiales temáticos: