¿Qué es la automatización de pruebas de software?

Prólogo del traductor: Probablemente a fines de 2008, tuve un intercambio con un ingeniero que había trabajado casi toda la vida en Sun (cuando Sun estaba a punto de ser adquirido, él estaba muy bajo), explicó a Sun en detalle. La arquitectura de prueba interna, que menciona el desarrollo propio de Sun de un gran número de herramientas de prueba automatizadas a lo largo de las décadas, tengo una pregunta: ¿la prueba automatizada no es un concepto que ha surgido en los últimos años? ¿Cuál es el estado y el rol de las pruebas automatizadas? ¿Pueden las pruebas automatizadas resolver los problemas que enfrentan las pruebas? En los últimos años, mi comprensión de las pruebas ha mejorado, y acabo de ver el artículo de James Bach "¿Qué es la automatización de las pruebas?" ", Soy similar a su punto de vista, traducido para que todos lo vean, bienvenido a discutir.

La automatización de la prueba es cualquier prueba que es asistida por herramientas. Esta prueba se realiza el primer día de la industria de la computación. Y nunca ha habido un historial de "la automatización de pruebas reemplaza el trabajo de los ingenieros de pruebas"; esto sucede a menos que ignore por completo el trabajo real de los evaluadores.

Por la misma razón, los detectores automáticos del espacio nunca se han utilizado para "reemplazar el trabajo de los científicos espaciales", solo han ampliado el alcance de la exploración de los científicos. La prueba automatizada también significa ampliar el alcance de la exploración del probador.

La automatización de pruebas simplemente no es nueva (en el círculo de consentimiento — — traductor Orz), el concepto de ingenieros de pruebas independientes es más nuevo que eso. Hace mucho tiempo, hacia fines de la década de 1940, los ingenieros de pruebas independientes no aparecían en absoluto. El desarrollador prueba el programa él mismo. En la década de 1960, los documentos sobre pruebas (como los de la conferencia IFIPS) trataban sobre cómo los desarrolladores probaban sus propios programas. Los dos conceptos de prueba y depuración tampoco se distinguen. A medida que los sistemas de software crecen en tamaño, el concepto de pruebas independientes se ha puesto de moda. En Chapel Hill, 1972, se llevó a cabo la primera reunión sobre pruebas de software, que llevó al inicio de las pruebas de software como una tecnología independiente del desarrollo.

Pero en esta reunión, creo que cometieron un error. Es que tienen muchas expectativas y entusiasmo para la automatización de pruebas. Esta expectativa no se logró con éxito al final, pero no debido a la falta de práctica, sino debido a la falta de una buena comprensión.

No entienden, pero también muchos programadores contemporáneos (no creo que muchos programadores entiendan — — traductor) no entienden: buenas pruebas de software, naturales, inevitables Es un tipo de actividad humana, inevitable, no accidental. La prueba es una actividad social, una actividad psicológica. Cuanto más complejo es el software, mayor es el rol de las personas en el uso e identificación de problemas de software. Pero la conferencia de Chapel Hill fue ocupada por personas capacitadas como programadores e ingenieros electrónicos que carecían del conocimiento de cómo pensar.

(¿Quién es este tipo de persona que piensa? Jerry Weinberg. Su tesis doctoral de 1965 sobre resolución de problemas es increíble. Él escribió psicología de programación de computadoras en 1970, incluida una Una serie de artículos sobre pruebas de software en la década de 1960. En su libro de 1961, Software Development Foundation, dedicó un capítulo a analizar las pruebas de software. Desafortunadamente, Jerry no asistió a la conferencia de Chapel Hill, pero sí asistió a la conferencia CAST en Toronto.

El concepto de evaluadores independientes capacitados es más nuevo que el concepto de pruebas automatizadas, pero en comparación con la automatización de pruebas, el concepto no es lo suficientemente aceptable, porque la capacitación de los evaluadores es realmente muy mala.
(Nuestro servicio doméstico no es un — — traductor)

Así que algunas personas entienden que las pruebas son una técnica simple, la prueba es para asegurarse de que la llamada a la API no haga que el programa funcione como una bestia no controlada. No se donde ir Esta idea sigue ahí, me refiero a Microsoft. Mi esposa tiene que dejarme ayudarla a localizar el problema del software de Microsoft Office. Me dijeron que Microsoft Office, un software que todavía está inflado, fue escrito por desarrolladores que no han estudiado sistemáticamente las pruebas de software, con el apoyo de esas "herramientas de prueba automatizadas".
(Afortunadamente, mi colega, Michael Bolton — ¿mdash; este amigo está cantando bien? Traductor Orz — — recientemente abrió una clase de prueba en Microsoft, así que, tal vez, hay esperanza)

Pruebas La automatización no reproduce el pensamiento creativo de los ingenieros de pruebas que conciben pruebas, controlan pruebas, modifican pruebas, observan y evalúan productos. La automatización de pruebas no puede hacer esas pruebas de alta calidad. Por lo tanto, la automatización de pruebas nunca tuvo la intención de: automatizar los servicios proporcionados por esos ingenieros de pruebas.

En una palabra, la automatización de prueba significa usar herramientas de prueba. La automatización de pruebas es un concepto antiguo, y el concepto de un ingeniero de pruebas independiente es más nuevo que esto. La industria aún no ha probado (excepto en un ámbito interno pequeño) los evaluadores de capacitación en sistemas, solo nombraron la posición de "Ingeniero de pruebas" o "Ingeniero de pruebas de desarrollo", y algunos de ellos no están familiarizados con Se les arrojan herramientas de prueba y luego se les hace ilusión que puedan trabajar duro. Luchando

(También, soy programador. Utilizo mi computadora Apple II para programar, que es anterior a lo que escuché acerca de los ensambladores. A principios de la década de 1990, dirigí el proyecto Borland C ++. El grupo de prueba Borland Turbo Debugger — — Debugger es una herramienta de depuración para desarrolladores, lo que indica que James conoce bien el trabajo del desarrollador. Traductor Antes de eso, lideré el equipo de desarrollo de herramientas de prueba en Apple. Pruebas de personal, pruebas automatizadas basadas en GUI, pruebas automatizadas no basadas en GUI, he hecho estas cosas.

Estas experiencias incluso me han traído algunos problemas nuevos, cuando me enfrento a la nueva generación Los probadores "mdash" se refieren a probadores independientes, traductores y mdash entrenados y mdash; y desarrolladores que no han utilizado las llamadas herramientas de prueba automatizadas, soy un poco impaciente)

Traductor: James Bach significa que debe ser la vida de un ingeniero de pruebas independiente, no a la inversa. ¿Se puede resolver hoy el problema resuelto mediante pruebas automatizadas hace 50 años? Bienvenido a la discusión.