¿Podemos suponer al probar el software que un usuario no realizaría acciones tan tontas en el software?

Por ejemplo: al realizar pruebas funcionales de un formulario en una aplicación web, probaremos los campos ingresando diferentes tipos de valores de entrada aleatorios.

En general, nosotros, como usuarios de la aplicación web, no ingresamos valores aleatorios en los campos.

Entonces, ¿de qué sirve incorporar todos esos casos de prueba que pueden o no conducir a errores, cuando la probabilidad de que aparezcan este tipo de problemas en la producción es mucho menor?

Nota: El ejemplo anterior es solo un caso de muestra; tales problemas pueden ocurrir en cualquier tipo de característica / módulo.

Estoy haciendo esta pregunta solo para saber si hay prácticas estándar a seguir o si depende totalmente del producto, dominio y todos los demás factores.

Es posible que no ingrese valores aleatorios en los campos de una aplicación web, pero ciertamente hay personas que hacen exactamente eso.

Algunas personas ingresan al azar por accidente y otras lo hacen intencionalmente tratando de romper la aplicación. En ambos casos, no desea que la aplicación se bloquee o muestre otro comportamiento no deseado.
Para el primer tipo de usuario, no desea eso porque les da una mala experiencia y podría rechazarlos.
Para el segundo tipo de usuario, generalmente no tienen intenciones honorables y no desea permitirles tener acceso a información a la que no deberían poder acceder o permitirles denegar a los usuarios genuinos el acceso a sus servicios.

La práctica estándar para las pruebas es verificar no solo que el caso de buen tiempo funciona, sino también que se exploran casos extremos inusuales para encontrar posibles problemas y tener la confianza de que los atacantes no pueden acceder fácilmente a su sistema. Si su aplicación ya se bloquea con una entrada aleatoria, no desea saber qué puede hacer un atacante con una entrada especialmente diseñada.

Nunca asumas nada

No puede asumir que ningún usuario no hará algo "tonto" con su software por accidente o a propósito. Los usuarios pueden presionar accidentalmente el botón equivocado, el gato puede caminar sobre el teclado, el sistema puede funcionar mal, su computadora puede ser secuestrada por software malicioso, etc.

Además, el propio usuario puede ser malicioso, buscando intencionalmente formas de romper su software con la esperanza de que pueda encontrar una manera de explotarlo en su beneficio. Incluso si encuentran un error que no pueden explotar, cualquier cosa que encuentren puede estimularlos a sondear su sistema en busca de algo que puedan atacar, sabiendo que faltan sus procedimientos de control de calidad.

En lo que respecta a las pruebas, es útil protegerse contra entradas aleatorias, sin embargo, elegir entradas de prueba completamente al azar (es decir, sin una consideración particular hacia ningún caso de uso o casos extremos) es inútil. El propósito de las pruebas es validar su solución contra los requisitos y expectativas de su empleador / clientes / usuarios; Esto significa que debe centrarse en apuntar a todos los casos límite y condiciones de contorno, así como a los casos 'degenerados' que no se ajustan al flujo de trabajo esperado del usuario.

Por supuesto, puede ejecutar pruebas que revelen errores que luego decida que no vale la pena corregir; Esto puede deberse a todo tipo de razones: el error puede ser demasiado costoso de corregir en relación con su impacto en el usuario, o puede descubrir errores en funciones que nadie usa, o el error puede estar tan bien establecido en el sistema que algunos los usuarios lo están tratando como una característica.

Alternativamente, puede estar escribiendo un software a medida que tiene una audiencia muy limitada de usuarios 'expertos' donde no hay ningún beneficio comercial de pasar tiempo reparando errores, porque esos usuarios son capaces de hacer su trabajo con software defectuoso (por ejemplo, una herramienta de diagnóstico utilizado por el equipo interno de TI no genera ningún ingreso, por lo que si se bloquea ocasionalmente, es probable que nadie quiera pagar por el tiempo requerido para solucionarlo; simplemente le dirán al equipo de TI que viva con los errores) .

Sin embargo, solo puede tomar estas decisiones si conoce estos errores. Por ejemplo, un usuario puede ingresar una entrada maliciosa que borra toda la base de datos; si no se ha protegido y probado explícitamente para este escenario, entonces no hay forma de que pueda estar seguro de si esto puede suceder o no. El riesgo de dejar errores no descubiertos en el sistema significa que potencialmente te estás exponiendo a problemas reales si uno de esos errores se revela en el mundo real y tiene un gran impacto en tus usuarios.

Entonces, si bien la decisión sobre si corregir los errores puede requerir algún aporte del propietario del software (por lo general, quien paga su salario), la decisión sobre la prueba de errores y los casos para los que se debe realizar una prueba es una preocupación de ingeniería que debe ser factorizado en las estimaciones y la planificación del proyecto, donde el objetivo debe ser algo tan cercano a la cobertura total como sea razonablemente posible dadas las limitaciones de tiempo / dinero / recursos.

Hay varios factores a tener en cuenta. Para ilustrar esos puntos, usaré un ejemplo de un campo en el que un usuario debe ingresar un porcentaje en el contexto de una cuota definida para una tarea específica en términos de cuánto espacio en disco podría usar la tarea. 0% significa que la tarea no podría escribir nada en el disco; 100% significa que la tarea podría llenar todo el espacio en disco. Los valores intermedios significan lo que significan.

Como desarrollador, probablemente esté considerando que los valores aceptables son [0, 1, 2, 3, ⋯ 99, 100], y todo lo demás es una tontería. Veamos por qué los usuarios aún podrían estar ingresando esos valores "tontos".

Errores tipográficos

%^

El usuario estaba ingresando el valor 56, pero presionó por error Shiftal ingresarlos (por ejemplo, porque en el teclado francés, debe presionar Shiftpara ingresar dígitos, y el usuario estaba cambiando constantemente entre un teclado francés y un QWERTY).

De la misma manera, puede obtener un número, con algo después o antes, o en el medio:

56q

Aquí, el usuario probablemente estaba ingresando los dígitos, seguido de una pestaña para pasar al siguiente campo. En lugar de presionar   ⇆  , el usuario presionó la tecla vecina.

Malentendidos y malas interpretaciones

Una entrada vacía es probablemente la más habitual. El usuario imaginó que el campo era opcional o no sabía qué poner en este campo.

56.5

El usuario pensó que los valores de coma flotante eran aceptables. O el usuario está equivocado, y la aplicación debe explicar cortésmente por qué solo se aceptan valores enteros, o si los requisitos iniciales eran incorrectos, y tiene sentido permitir que los usuarios ingresen valores de punto flotante.

none

El usuario no entendió que cuando se le preguntó por el espacio que la tarea podría ocupar, la aplicación esperaba un número. Esto podría indicar una interfaz de usuario deficiente. Por ejemplo, preguntar al usuario "¿Cuánto espacio en disco debería ocupar la tarea?" Invita a este tipo de entrada, mientras que un campo con un signo de porcentaje a continuación recibiría menos de ese tipo de entrada, porque "none%" no genera mucho sentido

150

El usuario no entendió lo que significa el porcentaje en este caso. Tal vez el usuario quería decir que la tarea puede tomar el 150% del espacio utilizado actualmente, por lo que si en un disco de 2 TB se usan 100 GB, la tarea podría usar 150 GB. Una vez más, una mejor interfaz de usuario podría ayudar. Por ejemplo, en lugar de tener un campo de entrada simple con un signo de porcentaje adjunto, se podría tener esto:

[____] % of disk space (2 TB)

Cuando el usuario comienza a escribir, cambiaría el texto sobre la marcha para convertirse en esto:

[5___] % of disk space (102.4 GB of 2 TB)

Representaciones

Los números grandes o los números con coma flotante se pueden representar de manera diferente. Por ejemplo, un número 1234.56 podría escribirse así: 1,234.56. Dependiendo de la cultura, la representación de texto del mismo número sería diferente. En francés, el mismo número se escribe así: 1 234,56. Mira, una coma donde no esperarías una, y un espacio.

Esperar siempre un formato específico usando un entorno local específico lo metería en problemas tarde o temprano, porque los usuarios de diferentes países tendrían diferentes hábitos de escribir números, fechas y horas, etc.

Humanos contra computadoras

Twenty-four

Los humanos comunes no piensan de la misma manera que las computadoras. "Veinticuatro" es un número real, independientemente de lo que le diga una PC.

Aunque (1) la mayoría de los sistemas no manejan en absoluto este tipo de entrada y (2) casi todos los usuarios no imaginarían ingresar un número escrito en letras completas, no significa que dicha entrada sea tonta. En About Face 3 , Alan Cooper señala que no manejar tales entradas es indicativo de la incapacidad de las computadoras para adaptarse a los humanos, e idealmente, la interfaz debería ser capaz de manejar esas entradas correctamente.

Lo único que tengo que agregar al libro de Alan Cooper es que, en muchos casos, los números se escriben en dígitos por error . El hecho de que las computadoras esperen que sus usuarios cometan errores (y no tolerarán a un usuario que escribe correctamente) es molesto.

Unicode

5𝟨

Unicode se reserva sus propias sorpresas: los personajes que podrían tener el mismo aspecto no son los mismos. ¿No convencido? Copie y pegue "5𝟨" === "56"en las herramientas de desarrollador de su navegador y presione Enter.

La razón por la que esas cadenas no son iguales es que el carácter Unicode 𝟨no es el mismo que el carácter 6. Esto crearía una situación en la que llamaría un cliente enojado, diciéndole que su aplicación no funciona, proporcionando una captura de pantalla de una entrada que parece legítima, y ​​su aplicación alegando que la entrada no es válida.

¿Por qué alguien ingresaría un carácter Unicode que se parece a un dígito? Si bien no esperaría que un usuario ingresara uno involuntariamente, una copia-pegar de una fuente diferente podría causar eso, y tuve un caso en el que el usuario realmente hizo esa copia-pegar de una cadena que contenía un carácter Unicode que no aparecer en la pantalla.

Conclusión

Esos son los casos que obtiene para un campo de entrada de número elemental. Te dejaría imaginar lo que puedes manejar para formularios más complejos, como una fecha o una dirección.

Mi respuesta se centra en lo que usted llamó "tonto" de entrada. La prueba no se trata de verificar los caminos felices; también se trata de verificar que su aplicación no se dañe cuando un usuario malintencionado ingrese intencionalmente cosas extrañas, tratando de romperla. Esto significa que cuando solicita un porcentaje, también tiene que probar qué sucede cuando el usuario responde con una cadena que contiene 1,000,000 de caracteres, o un número negativo, o una mesa auxiliar .

Aquí hay muchas buenas respuestas que describen por qué esto es importante, pero no muchos consejos sobre cómo proteger de manera sensata su aplicación. La "práctica estándar" es utilizar una validación de entrada robusta, tanto en el cliente como en el servidor. La entrada no sensible es fácil de defender; simplemente rechazas todo lo que no tiene sentido en ese contexto específico. Por ejemplo, un número de seguro social consiste únicamente en guiones y dígitos; puede rechazar con seguridad cualquier otra cosa que el usuario escriba en un campo de número de seguro social.

Hay dos tipos de pruebas que deben realizarse en cada aplicación que escriba, y cada una tiene diferentes propósitos. Las pruebas que realiza en su propia aplicación son pruebas positivas; Su propósito es demostrar que el programa funciona. La prueba de lo que los probadores también hacen en su aplicación es una prueba negativa; Su propósito es demostrar que su programa no funciona. ¿Por qué necesitas esto? Porque no eres la mejor persona para probar tu propio software. Después de todo, escribiste la cosa, así que obviamente ya funciona, ¿verdad?

Cuando escriba la validación de entrada, empleará pruebas positivas para demostrar que su validación funciona. Los probadores usarán entradas aleatorias para intentar demostrar que no funciona. Tenga en cuenta que el espacio del problema para las entradas aleatorias es esencialmente ilimitado; su objetivo no es probar cada permutación posible, sino limitar el espacio del problema rechazando entradas no válidas.

También tenga en cuenta que el usuario final no es el único que proporciona información a su programa. Cada clase que escribe tiene su propia API y sus propias restricciones sobre lo que se considera entrada válida, por lo que la validación robusta (es decir, "contratos de código") también es importante para sus clases. La idea es fortalecer su software para que el comportamiento inesperado sea raro o inexistente en la mayor medida posible.

Finalmente, el flujo de trabajo es importante. He visto caer aplicaciones, no porque el usuario haya ingresado algo no sensitivo, sino porque hicieron cosas en la aplicación en un orden inesperado. Su aplicación debe ser consciente de esta posibilidad y manejar flujos de trabajo inesperados con gracia o requerir que el usuario realice operaciones en el orden especificado.

Por lo general, los valores 'aleatorios' no son aleatorios. Estás intentando capturar casos extremos, el "desconocido desconocido".

Digamos, por ejemplo, que el carácter # bloqueará su aplicación. No lo sabe de antemano y sería imposible escribir casos de prueba para cada entrada posible. Pero podemos escribir una prueba "¬!"£$%^&*()_+-=[]{};'#:@~,./<>?|\"y ver si se rompe

Una vez escribí un programa, que probé en vivo en un laboratorio con 60 estudiantes. Estaba parado detrás de las 60 pantallas de la computadora y los vi usarlo. La cantidad de cosas ridículas que hicieron fue espeluznante. Estaba empapado en sudor viendo su "creatividad". Hicieron mucho más de lo que cualquier individuo puede fantasear en toda la vida. Por supuesto, uno de ellos lo rompió.

Después de eso sigo un enfoque: if "a very specific use case" do, else show error

Si tengo varios casos de uso, los defino estrictamente y encadeno los anteriores.

Lo que está describiendo es Fuzzing o Fuzz Testing : arroje entradas aleatorias e inválidas a un sistema y vea qué sucede. No haces esto porque esperas que lo haga un usuario. Lo hace para exponer sus propias suposiciones y prejuicios para estresar los bordes de su sistema para ver qué sucede.

La entrada de prueba normal escrita por un humano con vendrá con suposiciones y sesgos. Estos sesgos pueden ser ciertas clases de errores que nunca se encuentran a través de las pruebas.

Por ejemplo, si la mayor parte de su entrada está en el rango Unicode seguro para ASCII, no se ejercitarán los supuestos sobre la codificación de caracteres en el código. O tal vez siempre está por debajo de un cierto tamaño, por lo que no se golpea un campo o búfer de tamaño fijo. O tal vez hay caracteres especiales que se interpretan de manera sorprendente exponiendo que la entrada del usuario se alimenta a un shell o se utiliza para generar consultas de manera insegura. O tal vez hay demasiadas pruebas de "camino feliz" y no hay suficientes intentos de ejercer el manejo de errores.

Fuzzing no tiene tales preconcepciones sobre la entrada. Ejercerá brutalmente su sistema con cualquier combinación posible de entrada "válida". Unicode, ASCII, grande, pequeño y muchos errores. Su sistema debe responder con gracia a todos ellos. Nunca debería estrellarse. El usuario siempre debe recibir algún tipo de mensaje sensato sobre lo que salió mal y cómo solucionarlo. No es Garbage In / Garbage Out, es Garbage In / Error Out .

Si bien uno podría descartar las explosiones resultantes porque "ningún usuario real hará eso", eso no entiende el punto del ejercicio. Fuzzing es una forma económica de eliminar sus prejuicios sobre posibles entradas. Es una forma barata de arrojar todas las cosas raras que los usuarios intentarán hacer en su sistema. Como ingeniero, su trabajo es garantizar que su sistema falle con gracia.

Además, la "entrada" difusa no solo se trata de usuarios. Podría representar el resultado de una consulta API a un servicio de terceros, ¿qué pasa si eso comienza a enviar resultados desordenados? ¿Cómo maneja su sistema eso? Un sistema adecuado debería alertar a un administrador de que un componente ha fallado. Un sistema inadecuado rechazará silenciosamente la consulta incorrecta o, peor aún, la aceptará como buena información.

Finalmente, algunos usuarios son maliciosos. Si no prueba fuzzmente su sistema, alguien más lo hará. Sondearán los bordes de su sistema en busca de errores comunes e intentarán usarlos como agujeros de seguridad. Las pruebas fuzz pueden simular esto, hasta cierto punto, y puede lidiar con los posibles agujeros de seguridad descubiertos antes de que se conviertan en un problema.

Si su objetivo es crear un producto de calidad, pruebe todos los tipos posibles de entrada que un usuario podrá enviar físicamente. De lo contrario, solo está esperando el día en que alguien envíe ese tipo de entrada que no consideró necesario probar.

Durante una gran demostración de un nuevo software de subasta electrónica en una autoridad local donde trabajé, mi gerente decidió (admitiendo con cierta travesura) que sentía la necesidad de ver qué pasaba si presentaba una oferta de subasta con un valor negativo. Para mi verdadera sorpresa, el software de la subasta permitió que esta oferta sin sentido y todo el proceso de subasta se detuviera. El tipo de subasta que se está demostrando nunca debería haber permitido la presentación de importes negativos.

Algunos de los integrantes del gran grupo de oficiales de adquisiciones y finanzas reunidos se molestaron con mi gerente por presentar un valor sin sentido. Pero otros, incluido yo mismo, estaban molestos con los desarrolladores de software por no probar y rechazar un tipo tan obvio de entrada inválida. Solo puedo imaginar lo débil que debe haber sido el software al desviar otros tipos de entrada no válida (intentos de inyección de código, caracteres exóticos no representables en la tabla de la base de datos, etc.).

Si fuera por mí, habría devuelto el software y lo consideraría inadecuado para su propósito. La diferencia entre un producto de software débil y uno fuerte es el nivel de prueba al que ha sido sometido.

Por ejemplo: al realizar pruebas funcionales de un formulario en una aplicación web, probaremos los campos ingresando diferentes tipos de valores de entrada aleatorios.

Si. Este es un tipo de prueba, pero no es una prueba funcional . Esto es lo que se llama prueba de esfuerzo . Es el acto de aplicar presión a un sistema para ver si puede manejarlo.

Entonces, ¿de qué sirve incorporar todos esos casos de prueba que pueden o no conducir a errores, cuando la probabilidad de que aparezcan este tipo de problemas en la producción es mucho menor?

Cuando esté estrés pruebas de software que está tratando de descubrir los límites de lo límites del software son.

Las pruebas son exhaustivas por naturaleza. Donde necesita descubrir límites de uso, puntos de ruptura, verificar todas las ramas lógicas o ver cómo las fallas parciales afectan a todo el sistema.

Puede pasar todas sus pruebas funcionales, pero aún así fallar las pruebas de estrés .

Estoy haciendo esta pregunta solo para saber si hay prácticas estándar a seguir o si depende totalmente del producto, dominio y todos los demás factores.

Sí, esta es una práctica estándar.

La prueba del software consiste en hacer una pregunta sobre el comportamiento esperado , y cuando pasan todas las pruebas, esto comunica que el software funciona según lo previsto. Esta es la razón por la cual las pruebas son buenas condiciones previas para implementar actualizaciones.

La prueba de esfuerzo no proporciona indicadores específicos claros de aprobación o falla Los resultados son más informativos. Le indica qué puede manejar su sistema y usted toma decisiones a partir de esa información.

Puede definir objetivos específicos para las pruebas de resistencia que deben aprobarse para continuar con la siguiente etapa del desarrollo. Estos pueden incluirse como parte de su proceso de garantía de calidad, pero los cambios en el entorno pueden cambiar los resultados de una prueba de esfuerzo. Entonces, las personas realizan pruebas de estrés en diferentes momentos para ver cómo el sistema maneja las condiciones cambiantes.

Lo que quiero decir es que no puede simplemente ejecutar pruebas de estrés cada vez que implementa una nueva versión de su software, y asumir que esto significa que todo pasará las pruebas de estrés más adelante.