Pruebas exploratorias del software
James Whittaker es administrador de desarrollo de asociar en Bing, Microsoft. Es director anterior de ingeniería en Google que era responsable de probar Chrome, mapas, y las aplicaciones web de Google. James es uno de los nombres más conocidos de probar el mundo encima y ha creado varios bestsellers en la prueba de software. También hospeda un popular blog de MSDN.
Julio de 2012
Este tema es un fragmento del libro La prueba de software de Exploratory: Sugerencias, trucos, explica y técnicas de resolver diseño de pruebas.
Se aplica a
Administración del ciclo de vida de la aplicación, Visual Studio, TFS
Objetivos de pruebas exploratorias
Prueba exploratoria – plan como se prueba
Pruebas exploratorias para los equipos ágiles
Pruebas exploratorias puede coexistir con la prueba con guiones planeada
Exploraciones basadas escenario
Explica exploratorios de pruebas
En pruebas exploratorias, los evaluadores pueden interactuar con la aplicación de la manera siguiente y utilizan la información que la aplicación proporciona reaccionar, cambie el curso, y normalmente exploran la funcionalidad de la aplicación sin restricciones. Puede parecer ad hoc a algunas, pero en manos de un evaluador exploratorio experto y experimentado, esta técnica puede probar eficaz. Los promotores mantengan que pruebas exploratorias permite que los plenos poderes de cerebro humano surtan efecto en encontrar los errores y funcionalidad el comprobar sin restricciones preconcebidas.
El inconveniente de pruebas exploratorias es ese riesgo de los evaluadores que pierde mucho tiempo en vaga alrededor de una aplicación que busca elementos a la prueba y que las intenta encontrar errores. La falta de preparación, de estructura, y guía puede conducir a muchas horas improductivas y a volver a examinar la misma funcionalidad repetidamente. Uno ver fácilmente que la prueba completamente ad hoc no es claramente la mejor manera de ir alrededor a probar. Los evaluadores que ven sobre las entradas, los entornos de software, y las otras cosas que se pueden modificar durante un paso de prueba estarán más bien instrumentados explorar la aplicación con el propósito y la intención. Este conocimiento los ayudará a probar mejor y más elegante y a maximizar las posibilidades de detectar defectos serios de diseño e implementación.
Objetivos de pruebas exploratorias
To gain an understanding of how an application works, what its interface looks like, and what functionality it implements: Such un objetivo es adoptado a menudo por los evaluadores nuevos a un proyecto o los que desean identificar puntos de entrada de la prueba, identifican desafíos de prueba concretos, y escriba planes de pruebas. Este también es el objetivo utilizado por los evaluadores experimentados cuando exploran una aplicación para entender qué profundidad sus necesidades de pruebas y buscar nueva funcionalidad inexplorada.
La idea de To force the software to exhibit its capabilities: The es crear software para trabajar completa y establézcalo como preguntas difíciles que pasarlo con sus pasos. Esto puede o no puede encontrar errores, pero proporcionará siempre probar que el software realiza la función que se diseñó y que cumple sus requisitos.
To find bugs: Exploring los bordes de la aplicación y de alcanzar puntos suaves posibles es una especializados de pruebas exploratorias. El objetivo es útil, en lugar de sin objetivo, vaya identificar funcionalidad no comprobada e históricamente con errores. Los evaluadores exploratorios no deben tropezar simplemente a través de los errores, debe colocar en ellos con el propósito y la intención.
Prueba exploratoria – plan como se prueba
Pruebas de software es complicado por una sobrecarga de las posibilidades de la variación de entradas y las rutas de acceso del código para establecer, los datos almacenados, y el entorno operativo. De hecho, si uno elija para solucionar esta variación antes de alguna prueba escribiendo planes o por un enfoque exploratorio que permite la planeación y la prueba que se intercalarán, es una tarea imposible. Independientemente de cómo lo hace en última instancia pruebas, simplemente es demasiado compleja haga completamente.
Sin embargo, las técnicas exploratorias tienen la ventaja que se aconseja a los evaluadores a planear mientras prueban y utilizar la información recopilada durante la prueba para afectar a la prueba real de la manera en que se realiza. Esto es una ventaja clave sobre los plan- primeros métodos. Imagine que al intentar predecir el ganador de Super Bowl o de Premier League antes de que comience de estación. Esto es difícil de hacer para ver cómo los equipos están jugando, cómo administran la competencia, y si los protagonistas pueden impedir lesión. La información proveniente en como estación revela contiene la clave para predecir el resultado con cualquier cantidad de exactitud. Lo mismo sucede del software, y pruebas exploratorias abraza esto intentando planear, probar, y planear en pequeños incrementos en curso dirigidos por conocimiento completo de todos últimos e información actual sobre cómo el software realiza y pistas que produce durante la prueba.
Pruebas exploratorias para los equipos ágiles
Pruebas exploratorias adapta sobre todo al desarrollo de aplicaciones Web moderno mediante métodos ágiles. Los ciclos de desarrollo son short, dejando poco tiempo para escribir y el mantenimiento formales del script. Las características se desarrollan a menudo rápidamente, por lo que la minimizar de artefactos dependientes (como casos de prueba pre- preparados) es un atributo deseable. ¿Si el caso de prueba tiene una buena oportunidad de convertirse inútiles, por qué escríbala en primer lugar? ¿No es el valor personalmente hacia arriba para ocupar más casos de prueba que mantienen de tiempo que realmente haciendo pruebas?
(Para obtener ejemplos de las herramientas ágiles para pruebas exploratorias en Visual Studio y TFS, vea Pruebas exploratorias mediante Microsoft Test Manager, Pruebas de aplicaciones de la Tienda Windows que se ejecutan en un dispositivo que usa la ventana de pruebas exploratorias, y Ejecutar pruebas en Microsoft Test Manager.)
Pruebas exploratorias puede coexistir con la prueba con guiones planeada
No es necesario ver pruebas exploratorias como alternativa estricta a la prueba manual script- basada en. De hecho, los dos pueden coexistir muy de bienvenida. Tener scripts formales puede proporcionar una estructura a la exploración del cuadro, y los métodos exploratorios pueden agregar un elemento de la variación en los scripts que pueden amplificar su eficacia. La mejor manera que he encontrado para combinar las dos técnicas es iniciar con scripts formales y usar las técnicas exploratorias de insertar la variación en ellas. De esta manera, un script puede finalizar hacia arriba traducir en cualquier número de casos de prueba exploratorios reales.
La prueba script- basada tradicional suele implicar un punto de inicio de casos de usuario o los escenarios de un extremo a otro documentadas que esperamos que los usuarios finales realizan. Estos escenarios pueden proceder de investigación de usuario, los datos de las versiones anteriores de la aplicación, etc., y se utilizan como scripts para probar el software. El elemento agregado de pruebas exploratorias a la prueba tradicional de escenario amplia el ámbito de script para insertar la variación, investigación, y las rutas opcionales del usuario.
Exploraciones basadas escenario
En el escenario de ejemplo- basada cubrirá los casos en que la prueba simple de escenario no imita y más exactamente a los usuarios reales, que se pierden a menudo del escenario principal: Con todo el producto permite muchas posibles variaciones. Debemos no solo esperar que obtienen utilizado, generalmente es probar que funcionarán.
La idea detrás de pruebas exploratorias escenario de ejemplo- basada es utilizar escenarios existentes mucho cuando los exploradores reales utilizan un mapa para dirigirse a través de desert u otro terreno desconocido. Los escenarios, como mapas, son guía general sobre qué hacer durante la prueba, las entradas seleccionar, y que no son absolutos las rutas de acceso del código recorrer, pero ellas. Los mapas pueden describir la ubicación de destino pero proporcionar varias maneras de obtener allí. Igualmente, se anima el evaluador exploratorio se proporciona rutas alternativas e incluso que considere una gran variedad de posibles rutas al ejecutar un escenario. De hecho, que es el propósito exacto de este formulario de prueba exploratoria: para probar la funcionalidad descrita por el escenario, agregando tanta variación posible. Nuestro “mapa” no está diseñada para identificar la ruta de acceso más corta, se ha pensado encontrar muchas rutas. Cuanto más que se pueden probar, mejor; esto conduce a más confianza que el software realizará el escenario robusto cuando está en manos de los usuarios que pueden y se desviarán de las expectativas.
Un escenario útil hará normalmente uno o más de los siguientes:
Espera un caso de usuario
Describe un requisito
Muestra cómo funciona una característica
Muestra un escenario de integración
Describe la configuración y la instalación
Describe las precauciones y cosas que pueden salir mal
Los evaluadores exploratorios deben trabajar completa para asegurarse de que recopilan tantas escenarios posible de todas estas categorías. Es entonces la tarea seguir los escenarios e insertar la variación como consultamos el ajuste. Es cómo elegimos para insertar esta variación que cree esta tarea exploratorias de la naturaleza y que es el asunto se gira a continuación.
(Para obtener un ejemplo de cómo utilizar pruebas exploratorias con las herramientas de agile en Visual Studio y TFS, vea Cómo: Iniciar una sesión de pruebas exploratorias en Microsoft Test Manager.)
Explica exploratorios de pruebas
Supongamos que está visitando a grandes ciudad como Londres, Inglaterra, por el primer momento. Es un lugar grande, No disponible, confuso para los nuevos turistas, con las partes de cosas a ver y hace. De hecho, incluso el más completo, la mayoría de turista Tiempo- libre tendría una dificultad de consulta a todo una ciudad como Londres tiene que proporcionar. Lo mismo se pueden indicar de los evaluadores bien instrumentados que intentan explorar el software complejo; toda la financiación en el mundo no garantizará integridad.
Las ventajas de turismo de una combinación de estructura y de libertad, y hacerlo pruebas exploratorias. Hay muchas metáforas que transcurren que nos ayudarán a agregar la estructura a nuestra exploración y a empezar con las aplicaciones más rápidamente y con más detalles que el estilo libre que prueba solamente. Muchos de estos recorridos cabidos en una estrategia más grande de la prueba y pueden incluso combinar con la prueba escenario de ejemplo- basada tradicional que determinará exactamente cómo se organiza el recorrido.
Cualquier comentario planeación de pruebas necesita iniciar con la descomposición de software en partes más pequeñas que sean más manejables. Pero las características de pruebas pueden impedir que el buscar de errores que se producen cuando las características interactúan entre sí. Afortunadamente, la metáfora turística insiste en ninguna tal descomposición. En su lugar, sugiere la descomposición basada en try en lugar de en cualquier estructura inherente de la aplicación en pruebas. Como un turista que se amplíe a sus vacaciones al intentar ver tanto como sea posible en tan a short al período de tiempo posible, por lo que el evaluador también organizará los recorridos. Un turista real seleccione una combinación de indicaciones para ver y sitios a visitar, y un evaluador también elegirá para mezclar y las características del software con el intenta hacer algo concreto. Este intento requiere a menudo cualquier número de características y funciones de la aplicación que se combinarán de maneras que no serían si funcionamos bajo el modelo estricto de la prueba de características.
El recorrido de la guía turística
Las guías turísticas para los turistas identifican los mejores hoteles, las empresas de mejor, y las atracciones superior, sin entrar demasiado detalle o sobrecargar un turista con demasiadas opciones. El artefacto análoga para pruebas exploratorias es el manual del usuario, si el imprimirse o implementada como ayuda en línea (en este caso, a menudo denomino esto el recorrido de F1 para denotar el acceso directo a la mayoría de los sistemas de ayuda). Para este recorrido, seguiremos el consejo de manuales de usuario como hojas de ruta (traveler) cuidadosas, nunca desviándose de su jefe.
El recorrido de Money
Cada ubicación que codicia a turistas debe tener algunas buenas razones de ellas para proceder. Para Las Vegas, son los casinos y la curva spline, y para Egipto es las pirámides. Para los evaluadores exploratorios que presentan las características de moneda conduce directamente al personal de ventas. Las personas de ventas pasa mucho tiempo que da demostraciones de aplicaciones y es una fuente de información fantástica para el recorrido de Money. Para ejecutar el recorrido, simplemente la ejecución a través de demostraciones personalmente y buscar problemas. Mientras el código de producto se modifica para las correcciones de errores y las nuevas características, puede que se interrumpe y se demo no sólo hayan encontrado un gran error, pero ha guardado el personal de ventas de alguna en lugar vergüenza seria.
El recorrido de la señal
Como chico que crecía en los campos, los prados, y el bosque de Kentucky, aprendí utilizar un compás observando a mi anterior hermano. El proceso es simple. Utilice el compás para buscar una señal (un árbol, una roca, una cara del acantilado, etc.) en la dirección que desea ir, cree la forma a esa señal, y después busque el siguiente, etc., etc. Mientras las indicaciones estuvieran todas en la misma dirección, puede obtenerse mediante una revisión del bosque denso de Kentucky.
El recorrido de Landmark para evaluadores exploratorios es similar en que elegiremos señales y se comprobarán la misma lupulización señalado mediante software a través de un bosque. Elija un conjunto de pasos, decida sobre pedir para ellos, y después explorar la aplicación que va de la señal a la señal hasta que haya que visitan todos en la lista. Supervise que señala se han utilizado y crea un mapa de cobertura señalado para seguir el progreso.
El recorrido intelectual
Era una vez en una excursión de Londres donde la guía era un caballero en los años 50 que demandó al principio haber vivido en Londres toda su duración. Un turista compañero sucedió ser un escolar que estaba bien informado en historial inglés y hace sistemáticamente preguntas difíciles de guía. No significaba se voltea, sino que se curioso, que combinados con su conocimiento realiza encima de ser una combinación peligrosa… por lo menos a la guía. Cuando se aplica a pruebas exploratorias, este recorrido adquiere el enfoque de hacer preguntas difíciles de software. ¿Cómo creamos que el software funciona tan completa como sea posible? ¿Qué características se estirarán sus límites? ¿Qué las entradas y los datos lo harán para realizar el procesamiento? ¿Qué entradas pueden confundir las rutinas de comprobación de errores? ¿Qué entradas y datos internos esfuerzo su capacidad para generar resultados concreto?
Fedex viaja
Fedex es un icono en el entorno de la paquete- entrega. Recogen los paquetes, desplácelos alrededor de los diferentes centros de distribución, y los envía a su destino final. Para este recorrido, en lugar de los paquetes mueven alrededor de planeta a través del sistema de Fedex, piense en los datos que recorren de software. Durante este recorrido, un evaluador debe concentrarse en estos datos. Intente para identificar las entradas están almacenados y “sígalas” alrededor de software. Por ejemplo, ¿cuando se escribe una dirección en un sitio de compras, dónde hace obtiene mostrado? ¿Qué características se utilizan? Si se utiliza como dirección de facturación, asegúrese de que la práctica que característica. Si se utiliza como dirección de envío, asegúrese de que el uso de característica. Si se puede actualizar, actualícela. ¿Obtiene nunca formulario o purgado procesa o? Intente encontrar cada característica que toque datos para, así como Federal Express controla los paquetes, implicarle en cada fase del ciclo de vida de los datos.
El recorrido del recolector de elementos no utilizados
Los que obtienen la recolección de curbside conocen a residentes y a policía de las vecindades mejor que incluso porque van calle por la calle, contienen por home, haga familiarizados con cada topetón en la ruta. Sin embargo, porque tienen prisa, no permanecen en un lugar mucho tiempo. Para el software, esto es como una comprobación de punto metódica. Podemos decidir la comprobación de punto la interfaz donde vamos pantalla la pantalla, el diálogo por el diálogo (que favorece, como el recolector de elementos no utilizados, la ruta de acceso más corta), y no deteniendo para probar en detalle, sólo comprobar las cosas obvias (quizás como el recorrido de Supermodel). Podríamos utilizar este recorrido para ir característica por la característica, el módulo por módulo, o cualquier otra señal que tenga sentido para la aplicación concreta.
El recorrido de la Malo- entorno
Cada ciudad digno de visitar tiene vecindades no válidos y áreas que un turista está bien asesorado evitar. El software también tiene erróneo que vecindad- esas secciones de código rellenaron por los errores. Claramente, no sabemos con antelación las características probablemente representar vecindades no válidos. Pero cuando detecte y se notifican los errores, podemos conectar ciertas características con números de errores y podemos seguir donde los errores se producen en el producto. Porque los errores suelen juntarse, la nueva visita de las secciones con errores de producto es un recorrido digno de tomar. De hecho, una vez que una sección con errores de código se identifica, se recomienda para tomar el recorrido de un recolector de elementos no utilizados a través de las características siguientes para comprobar que las correcciones no introdujeron ninguna nueva errores.
El recorrido de museo
Los museos que muestran antigüedades son un favorito de turistas. Las antigüedades dentro de una base de código que merecen la misma clase de atención de evaluadores. En este caso, las antigüedades de software es código heredado. Más antiguos archivos de código que sufren la revisión o que se colocan en un nuevo entorno suelen ser averiados susceptible. Con haber salido largo y de los desarrolladores originales a menudo muy, el código heredado es difícil de modificar, difícil ver y, evade red de desarrolladores (quién de pruebas unitarias normalmente escribir esas pruebas solo para el nuevo código). Durante este recorrido, los evaluadores deben identificar un anterior código y artefactos ejecutables y comprobar que reciben una parte justa de atención de pruebas.
El recorrido posterior de callejón
En el ojo de varias personas, un buen recorrido es uno en el que se visita lugares populares. El cambio de estos recorridos sería uno en el que se visitó lugares que nadie más era probable ir. En términos exploratorios de pruebas, éstos son las características menos probable que se van a utilizar y las que son mínima atractivas a los usuarios. Si la organización sigue el uso de características, este recorrido se ordenará probar los que está en la parte inferior de la lista. Si la organización sigue cobertura de código, este recorrido le implora para encontrar maneras de probar el código siguen que se cubrirá.
El recorrido de toda la noche
También conocido como el recorrido de ir de discotecas, esto es para esa personas que mantenga out hacia atrás y alcanza los clubs nocturnos. La clave aquí es toda la noche. Los evaluadores exploratorios en el recorrido de toda la noche mantendrá la ejecución de la aplicación sin cerrarlo. Los archivos y no próximo abierto ellos. A menudo, ni siquiera molestan el guardar de ellos para evitar cualquier posible que restablece el efecto en el que aparezca el momento de guardar. Conectarse a recursos remotos y nunca desconectan. Mientras todos estos recursos están en uso constante, pueden incluso ejecutar pruebas mediante otros recorridos para conservar el funcionamiento del software y mover datos sobre. Si hacen esto bastante tiempo, pueden encontrar errores que otros evaluadores no encontrarán porque se deniega el software que el reinicio limpio que aparece cuando se reinicia.
El recorrido de top model
Para este recorrido, le deseo pensar superficie. Todo lo que lo hace, no va más allá de epidérmico. Este recorrido no es de función o sustancia; es busca alrededor y las primeras impresión. Durante el recorrido de top model, el foco no está en funcionalidad o interacción real. Sólo en la interfaz. Toma el recorrido y observe los elementos de la interfaz. ¿Parecen buenas? ¿Presentar correctamente, y es el rendimiento ofrecen? ¿Al realizar cambios, haga GUI actualizado correctamente? ¿Tan correctamente o hay los artefactos feas dejadas en la pantalla? ¿Si el software utiliza el color en una manera de mostrar algún significado, esto se hace sistemáticamente? ¿GUI paneles internamente coherentes con los botones y los controles donde se espera que sean? ¿La interfaz infringe convenciones o normas?
El recorrido de teleadicto
Siempre hay una persona en un recorrido de grupo que simplemente no participa. Se coloca en la reproducción con sus brazos doblados. Ha agujereado, unenergetic, y crea una maravilla exactamente por lo que molestó el pagar el recorrido en primer lugar. Un recorrido de Coach Potato significa realizar el trabajo en poco real posible. Esto significa que todos los valores predeterminados (valores previamente rellenadas por la aplicación), y campos de entrada esconde, rellenando como pocos datos de formulario como sea posible, nunca haciendo clic en un anuncio, paginar a través de muestra sin hacer clic en los botones o escribir ningún dato, etc. Si hay cualquier opción a ir un método en la aplicación u otra, la patatas car toma siempre la ruta de menos resistencia.
El recorrido obsesivo
Los evaluadores de OCD entrarán en la misma entrada repetidamente. Vaya a la misma acción repetidamente. Repetirán, reharán, copiará, pegarán, se prestados, y después harán todos que más. Principalmente, el nombre del juego es repetición. Pedir un elemento en un sitio de ventas y después pídalo de nuevo para comprobar si aplica un descuento múltiple de la compra. Escriba algunos datos en una pantalla, vuelva inmediatamente para especificarla en de nuevo. Estas son acciones que no hacen los desarrolladores a menudo los casos de error del programa para. Puede dar rienda suelta a estrago significativo.
Los desarrolladores están pensar en un usuario que realicen acciones en un orden concreto y mediante software con el propósito. Aunque los usuarios incurren en errores y tienen que retroceder, y no reconoce a menudo qué ruta específica tenía el desarrollador en la perspectiva para ellos, y tienen sus propios. Esto puede producir un esquema de uso título cuidadosamente por los desarrolladores para bajar por el borde de carretera rápidamente.
La prueba es compleja, pero el uso eficaz de técnicas exploratorias puede ayudar doméstico que la complejidad y contribuye a la producción de software de alta calidad.
Vea también
Otros recursos
Cómo: Iniciar una sesión de pruebas exploratorias en Microsoft Test Manager
Cómo: Crear un nuevo caso de prueba manual desde una sesión de pruebas exploratorias