FUNDAMENTOS DEL SOFTWARE PRUEBAS CERTIFICACIÓN ISTQB Dorothy Graham
Erik van Veenendaal Isabel Evans
Rex Negro CONTENIDO
Agradecimientos viii Prefacio ix
1 Fundamentos de la prueba 1
1.1 ¿Por qué está probando necesario? 1 1.2 ¿Cuál es la prueba? 11
1.3 Principios de prueba 18
1.4 proceso de prueba Fundamental 20 1.5 La psicología de la prueba 26 Revisión del capítulo 31
Examen de muestra cuestiona 32 Ejercicio: Prueba de la psicología 33 Solución de ejercicios 34
2 Pruebas de todo el ciclo de vida del software 35 2.1 modelos de desarrollo de software 35
2.2 Los niveles de prueba 41
2.3 Tipos de pruebas: los objetivos de la prueba 46 2.4 Mantenimiento de la prueba 50
Revisión del capítulo 54
Examen de muestra cuestiona 55 3 técnicas estáticas 57
3.1 Los comentarios y el proceso de prueba 57 3.2 Proceso de revisión 59
3.3 Análisis estático con herramientas 69 Revisión del capítulo 74
Examen de muestra cuestiona 75 4 Técnicas de diseño de la prueba 77
4.1 Identificación de las condiciones de prueba y el diseño de casos de prueba 77 4.2 Categorías de las técnicas de diseño de pruebas 84
4.3 Técnicas basada en la especificación o caja negra 87 4.4 Técnicas basadas en la estructura o de caja blanca 105 4.5 Técnicas basadas en la experiencia 112
4.6 Selección de las técnicas de prueba 114 Repaso del capítulo 117
Examen de muestra cuestiona 118
Ejercicios: técnicas de diseño de pruebas 121 Soluciones de ejercicio 122
5 Gestión de pruebas 127 5.1 Prueba de organización 127
5.2 Prueba de planes, estimaciones y estrategias 132 5.3 Prueba de control del progreso y el control 142 5.4 Gestión de la configuración 148
5.5 Riesgos y pruebas 149 5.6 Gestión de incidencias 155 Repaso del capítulo 161
Examen de muestra cuestiona 162 Ejercicio: Incidente informe 165 Ejercicio solución 166
Apoyo 6 Herramienta para la prueba 169 6.1 Tipos de herramienta de prueba 169
6.2 El uso efectivo de herramientas: beneficios y riesgos potenciales 184 6.3 La introducción de una herramienta en una organización 190
Repaso del capítulo 193
Examen de muestra cuestiona 195 7 Fundación ISTQB examen 197 Preparación para el examen 197 Tomar el examen 199
201 examen de prueba Glosario 209
Las respuestas a las preguntas del examen 227 muestrean referencias 231
237 autores 239 empresas CAPÍTULO 1
Fundamentos de la prueba
En este capítulo, se le dará a conocer los fundamentos de la prueba: ¿por qué es necesario realizar exámenes; sus limitaciones, los objetivos y el propósito; los principios detrás de la prueba; el proceso que sigue testers; y algunos de los psicológica factores que los evaluadores deben tener en cuenta en su trabajo. Al leer este capítulo se abordan obtener una comprensión de los fundamentos de la prueba y ser capaz de describir esos fundamentos.
1.1 ¿Por qué está probando NECESARIO?
1 Describe, con ejemplos, el modo en que un defecto en el software puede causar dañar a una persona, al medio ambiente o a una empresa. (K2)
2 Distinguir entre la causa de un defecto y sus efectos. (K2)
3 Dar razones por las cuales es necesario realizar pruebas a través de ejemplos. (K2) 4 Describir por qué la prueba es parte de la garantía de calidad y dar ejemplos de cómo las pruebas contribuye a una mayor calidad. (K2)
5 Recordemos los términos "error", "defecto", "culpa", "fracaso" y la corres 'error' ding términos y 'bug'. (KL)
6 Explicar los principios fundamentales en las pruebas. (K2) 1.1.1 Introducción
En esta sección, vamos a poner en marcha el libro con una discusión sobre las pruebas de por qué asuntos. Vamos a describir e ilustrar cómo los defectos o errores de software pueden causar problemas para las personas, el medio ambiente o una empresa. Dibujaremos importante distinciones entre los defectos, sus causas y sus efectos. Vamos a explicar por qué es necesario realizar pruebas para encontrar estos defectos, cómo las pruebas promueven la calidad, y cómo pruebas encaja en la garantía de calidad. En esta sección, también vamos a introducir algunos principios fundamentales de la prueba.
A medida que avanzamos a través de esta sección, para ver los términos del programa de estudios de errores, defectos, errores, fracaso, culpa, error, la calidad, el riesgo, el software, los ensayos y pruebas exhaustivas.
Usted encontrará estos términos definidos en el glosario.
Usted puede preguntar "¿cuál es la prueba? y vamos a ver más de cerca la definición de las pruebas en la Sección 1.2. Por el momento, vamos a adoptar una sencilla cada día- el uso de la vida: "cuando estamos probando algo que se comprueba si está bien '.
Vamos a tener que redefinir que cuando definimos las pruebas de software más adelante. Vamos a empezar por considerar por qué es necesario realizar exámenes. La prueba es necesaria porque todos cometemos errores. Algunos de esos errores no son importantes, pero algunos de ellos son caros o peligroso. Tenemos que comprobar todo y cualquier cosa que producimos porque las cosas siempre pueden salir mal - los seres humanos cometen errores todo el tiempo - es lo que nosotros ¡Haz lo mejor!.
Debido a que debemos asumir nuestro trabajo contiene errores, todos tenemos que comprobar nuestro propio trabajo. Sin embargo, algunos errores provienen de malas suposiciones y puntos ciegos, por lo que podrían hacer los mismos errores cuando comprobamos nuestro propio trabajo, ya que hecho cuando lo hicimos. Así que es posible que no note los defectos en lo que hemos hecho. Lo ideal sería conseguir a alguien más para comprobar nuestro trabajo - otra persona es más probabilidades de detectar los defectos.
En este libro, vamos a explorar las implicaciones de estos dos párrafos simples una y otra vez. Qué importa si hay errores en lo que hacemos?. Lo hace importa si no encontramos algunos de esos defectos?. Sabemos que en la vida ordinaria, algunos de nuestros errores no importan, y algunos son muy importantes. Es lo mismo con sistemas de software. Necesitamos saber si es probable que cause un error en particular problemas. Para ayudarnos a pensar en esto, debemos tener en cuenta el contexto en el que utilizamos diferentes sistemas de software.
Prueba Principio - La prueba es dependiente del contexto
La prueba se realiza de forma diferente en diferentes contextos. Por ejemplo, el software de seguridad crítico es probado de manera diferente a partir de un sitio de comercio electrónico. En estos días, casi todo el mundo es consciente de los sistemas de software. Nos encontramos con ellas en nuestros hogares, en el trabajo, en las compras, y en comunicación de masas sistemas. Cada vez más, son parte de nuestras vidas. Utilizamos el software dia
a día, en aplicaciones comerciales cotidianas como la banca y en los productos de consumo, tales como automóviles y lavadoras. Sin embargo, la mayoría de la gente ha tenido una experiencia con software que no funciona como se esperaba: un error en una factura, un retraso cuando se espera una tarjeta de crédito para procesar y un sitio web que no se ha cargado correctamente son ejemplos comunes de los problemas que pueden ocurrir debido a problemas de software.
No todos los sistemas de software tienen el mismo nivel de riesgo y no todos los problemas suelen tener el mismo impacto cuando se producen. Un riesgo es algo que no ha sucedido todavía y puede que nunca llegue a suceder; es un problema potencial. Estamos preocupados sobre estos problemas potenciales, ya que, si uno de ellos ocurre, tendremos un impacto negativo. Cuando hablamos de riesgos, debemos tener en cuenta qué tan probable es que el problema se produce, y el impacto en caso de que suceda. Por ejemplo, siempre cruzamos la carretera, hay un cierto riesgo de que vamos a ser heridos por un coche. La probabilidad campana depende de factores tales como la cantidad de tráfico en la carretera es, si existe es un lugar seguro cruzar, lo bien que podemos ver, y qué tan rápido podemos cruzar. El impacto depende de qué tan rápido se va el coche, si estamos usando protector engranaje, nuestra edad y nuestra salud. El riesgo de una persona en particular se puede resolver y por lo tanto la mejor estrategia de carretera de cruce. Algunos de los problemas que nos encontramos al utilizar el software son bastante trivial, pero otros pueden ser costosos y perjudiciales, con la pérdida de dinero, tiempo o negocio reputación, e incluso pueden causar lesiones o la muerte. Por ejemplo, supongamos que una interfaz de usuario tiene defectos tipográficos. ¿Importa esto? Puede ser trivial, pero podría tener un efecto significativo, según el sitio web y el defecto:
• Si mi sitio web personal árbol genealógico tiene soltera de mi abuela materna nombre mal escrito, mi madre se molesta y tengo que aguantar a algunos las burlas de la familia, pero se puede arreglar con facilidad y sólo la familia verlo (probablemente).
• Si la página web de la compañía tiene algunas faltas de ortografía en el texto, los clientes potenciales pueden ser puestos fuera de la empresa, ya que parece poco profesional.
• Si un programa de software calcula mal cantidades aplicación de plaguicidas, el efecto podría ser muy significativa: supongamos que un punto decimal se coloca erróneamente por lo que la tasa de aplicación es 10 veces demasiado grande. Los usos agricultores o jardinero más plaguicidas de los necesarios, lo que eleva sus costos, tiene medioambiental impactos sobre la fauna y agua y tiene impacto en la salud y la seguridad del agricultor, jardinero, la familia y la fuerza de trabajo, ganado y animales domésticos. Puede También será la consiguiente pérdida de confianza en los negocios y para la empresa y posibles costos legales y multas por causa de los problemas ambientales y de salud.
1.1.3 Las causas de los defectos de software
¿Por qué es que los sistemas de software a veces no funcionan correctamente? Lo sabemos la gente comete errores - somos falibles.
Si alguien comete un error o un error en el uso del software, esto puede conducir directamente a un problema, el software se utiliza incorrectamente y así no se comporta tal y como esperábamos. Sin embargo, las personas al diseñar y construir el software, puede cometer errores durante el diseño y la construcción. Estos errores significan que hay fallas
en el software en sí. Estos son los llamados defectos o, a veces errores o fallos. Recuerde que el software no es sólo el código; comprobar la definición de software.
Cuando el código de software se ha construido, se ejecuta y luego cualquier defecto hace que el sistema dejará de hacer lo que se debe hacer (o hacer algo que no debería), causando un fallo. No todos los defectos dan lugar a fallos; algunas permanecen en estado latente en el código y es posible que nunca les aviso.
Sí importan nuestros errores?
Vamos a pensar en las consecuencias de los errores. Estamos de acuerdo en que cualquier ser humano siendo, los programadores y testers incluidos, puede cometer un error. Estos errores pueden producir defectos en el código de software o sistema, o en un documento. Si un defecto en código se ejecuta, el sistema puede experimentar un fracaso. Por lo que los errores que cometemos cuestión que en parte debido a que tienen consecuencias para los productos de los que somos responsable.
Nuestros errores son también importantes porque los sistemas y proyectos de software son complicados. Muchos de los productos intermedios y finales se construyen durante un proyecto, y la gente es casi seguro que cometer errores y errores en todas las actividades de la construir. Algunos de éstos se encuentran y se retira por los autores de la obra, pero es difícil para las personas a encontrar sus propios errores, mientras que la construcción de un producto.
Los defectos en software, sistemas o documentos pueden resultar en fallos, pero no todos defectos causan fallos. Podríamos argumentar que si un error no conduce a un defecto o un defecto no conduce a un fallo, entonces no es de alguna importancia que ni siquiera saben que hemos hecho un error.
Nuestra falibilidad se agrava cuando nos falta experiencia, no tienen el derecho información, entienden mal, o si no tenemos cuidado, cansado o bajo la presión del tiempo.
Todos estos factores afectan nuestra capacidad para tomar decisiones sensatas ya sea nuestro cerebro no tienen la información o no puede procesar la suficiente rapidez.
Además, somos más propensos a cometer errores cuando se trata de desconcertantes problemas técnicos o de negocio, procesos de negocio complejos, código o infraestructura las tecnologías cambiantes, o muchas interacciones del sistema. Esto es porque nuestro cerebro sólo puede tratar con una cantidad razonable de complejidad o el cambio cuando se le preguntó que lidiar con más nuestros cerebros no puede procesar la información que tener correctamente.
No es sólo los defectos dan lugar al fracaso. Las fallas también pueden ser causados por condiciones ambientales, así: por ejemplo, una ráfaga de radiación, un fuerte campo magnético, campos electrónicos, o la contaminación podrían causar fallos en el hardware o firmware. Esos defectos pueden prevenir o modificar la ejecución de un programa. Las fallas también pueden surgir debido a un error humano en la interacción con el software, tal vez se introduce un valor de entrada incorrecta o una salida siendo mal interpretada.
Por último, los fallos también pueden ser causados por alguien deliberadamente tratando de causar un fallo en un sistema, daño malicioso.
Cuando pensamos en lo que podría salir mal, tenemos que considerar los defectos y fallas que surgen de:
• Errores en la especificación, diseño e implementación del software y sistema; • Errores en el uso del sistema;
• Condiciones ambientales; • Daño intencional;
• Posibles consecuencias de los errores anteriores, daño intencional, defectos y fracasos. Cuando surgen defectos?
En la figura 1.1 podemos ver cómo pueden surgir defectos en cuatro requisitos para un producto.
Podemos ver que el requisito 1 se implementa correctamente, comprendimos la el requisito de cliente, diseñado correctamente para cumplir con este requisito, construido correlación para satisfacer el diseño, y así entregar ese requisito con los atributos correctos funcionalmente, se hace lo que se supone que debe hacer y también tiene los atributos no funcionales, lo que es lo suficientemente rápido, fácil de entender y así sucesivamente.
Con los demás requisitos, se han cometido errores en diferentes etapas.
Requisito 2 es bien hasta que se codifica el software, cuando hacemos algunos errores e introducir defectos. Probablemente, estos son fácilmente detectado y corregido durante las pruebas, ya que podemos ver el producto no cumple con las características de diseño. Los defectos introducidos en el requisito 3 son más difíciles de tratar; construimos exactamente lo que nos dijeron que por desgracia, pero el diseñador hecho algunos errores tarde por lo que hay defectos en el diseño. A menos que comprobamos en contra de la exigencia de la definición, no se dará cuenta de los defectos durante la prueba. Cuando hacemos aviso que será difícil de solucionar porque serán necesarios cambios en el diseño.
Se introdujeron los defectos en el requisito 4 durante la definición de los requisitos; el producto ha sido diseñado y construido para satisfacer esa defectuosa definición de requerimientos. Si probamos el producto cumple con sus requisitos y diseño, que va a pasar sus pruebas, pero puede ser rechazado por el usuario o cliente. Defectos reportado por el cliente en la prueba de aceptación o uso directo puede ser muy costoso.
Desafortunadamente, los requisitos y defectos de diseño no son raros; las evaluaciones de miles de proyectos han demostrado que los defectos introducidos durante los requerimientos y el diseño constituyen cerca de la mitad del número total de defectos [Jones].
¿Cuál es el costo de los defectos?
Además de considerar el impacto de los fallos derivados de defectos que no hemos encontrado, debemos tener en cuenta el impacto de cuando nos encontramos con esos defectos. El costo de encontrar y corregir defectos se eleva considerablemente en todo el ciclo de vida; pensar en el viejo proverbio Inglés "una puntada a tiempo ahorra nueve '. Esto significa que si usted repara un desgarro en el manguito de ahora, si bien es pequeña, es fácil de reparar, pero si lo deja, se irá a peor y necesitan más puntos de sutura para repararlo. Si relacionamos los escenarios mencionados anteriormente a la figura 1.2, vemos que, si se comete un error y el consiguiente defecto se detecta en los requisitos en la etapa de especificación, entonces es relativamente barato para encontrar y corregir. La observación del aumento de los costes de eliminación de defectos en el software se remonta a [Boehm]. Explicas
Encontrará pruebas para la economía de la información y las pruebas de control de calidad en [], [Gilb Negro 2001] o [Negro 2004]. La especificación puede estar correctamente y re-emiten. Del mismo modo,
Si se comete un error y el consiguiente defecto detectado en el diseño en la fase de diseño, entonces el diseño puede ser corregido y reeditado con un costo relativamente bajo. Lo mismo se aplica para la construcción. Sin embargo, un defecto se introduce en la especificación de requisitos y no es detectado hasta que las pruebas de aceptación o incluso una vez que el sistema ha estado en práctica entonces serán mucho más caros de solucionar. Esto se debe a re-trabajo ser necesario en la especificación y diseño antes se pueden realizar cambios en construcción; debido a un defecto en los requisitos y puede propagarse por varios lugares en el diseño y el código; y porque todo el trabajo realizado pruebas a tendrá que ser repetido con el fin de alcanzar el nivel de confianza en el que el punto software que se requiere.
Es muy a menudo el caso de que los defectos detectados en una etapa muy tardía, dependiendo de la gravedad que sean, no son corregidos debido a que el costo de hacerlo es demasiado costoso. Además, si el software se entrega y cumple las especificaciones acordadas, que a veces todavía no será aceptada si la especificación estaba mal. El equipo de proyecto puede haber entregado exactamente lo que se les pidió entregar, pero no es lo que los usuarios querían. Esto puede llevar a los usuarios a ser infeliz con el sistema que se entregará finalmente. En algunos casos, cuando el defecto es demasiado grave, el sistema puede tener que ser desinstalados por completo.
1.1.4 Papel de las pruebas en el desarrollo de software, mantenimiento y operaciones Hemos visto que los errores humanos pueden causar un defecto o falla para ser introducido en cualquier etapa en el ciclo de vida del software de desarrollo y, dependiendo de la consecuencias del error, los resultados pueden ser triviales o catastrófica. Riguroso es necesario realizar pruebas durante el desarrollo y mantenimiento para identificar defectos, para reducir las fallas en el ambiente operacional y aumentar la calidad del sistema operativo. Esto incluye buscar lugares en la interfaz de usuario donde un usuario podría cometer un error en la entrada de datos o en la interpretación de la salida, y en busca de posibles puntos débiles para intencional y maliciosa ataque. Encargado de realizar la ayuda a avanzar hacia una mejor calidad de los productos y servicio, pero eso es sólo uno de los métodos de verificación y validación aplicados a productos. Los procesos también se
comprueban, por ejemplo mediante una auditoría. Una variedad de métodos se pueden utilizar para comprobar el trabajo, algunos de los cuales son realizados por el autor del trabajo y unos por otros para obtener una visión independiente.
También es posible que sea necesario para llevar a cabo las pruebas de software para satisfacer contractual o requisitos legales, o las normas específicas de la industria. Estas normas pueden especificar qué tipo de técnicas que debemos utilizar, o el porcentaje de código de software que deben ejercerse. Puede ser una sorpresa saber que no siempre probaremos a todos el código; eso sería demasiado caro en comparación con el riesgo que estamos tratando acuerdo. Sin embargo como es de esperar mayor es el riesgo asociado a la industria tratar de usar el software, lo más probable es que va a existir un estándar para la prueba.
Las industrias de aviónica, motor, médicos y farmacéuticos tienen todas las normas que cubre la prueba de software. Por ejemplo, la Federal de Aviación de los Estados Unidos Estándar DO-178B de la administración [RTCA / DO-178B] tiene requisitos para cobertura de la prueba.
1.1.5 Pruebas y calidad
Las pruebas nos ayuda a medir la calidad de software en términos de la cantidad de los defectos encontrados, las pruebas se ejecutan, y el sistema cubierto por las pruebas. Podemos hacer esto tanto para los atributos funcionales del software (por ejemplo, la impresión de un informe correctamente) y de los requisitos de software no funcionales y características (por ejemplo, la impresión de un informe con la suficiente rapidez). Características no funcionales están cubiertos en el Capítulo 2. La prueba puede dar confianza en la calidad del software de si encuentra pocos o ningún defecto, siempre estamos felices de que la prueba es suficientemente rigurosa. Por supuesto, una prueba pobre puede descubrir algunos defectos y nos dejan con una falsa sensación de seguridad. Una prueba bien diseñada va a descubrir defectos si presentes y por lo tanto, si pasa una prueba de este tipo, con razón, vamos a tener más confianza en el software y poder afirmar que el nivel general de riesgo de la utilización del sistema se ha reducido. Cuando las pruebas no encuentran defectos, la calidad del software sistema aumenta cuando se fijan esos defectos, siempre que las correcciones se llevan a cabo correctamente.
¿Qué es la calidad?
Proyectos tienen como objetivo ofrecer software de especificación. Para el proyecto entregar lo que necesita el cliente requiere una especificación correcta. Además, el sistema entregado debe cumplir con la especificación. Esto se conoce como validación ('es esta la especificación correcta?') y verificación ('es el sistema correcto al valor especificado? '). Por supuesto, además de querer que el sistema de software adecuado construido correctamente, el cliente quiere que el proyecto sea dentro del presupuesto y la escala de tiempo definida, este debe llegar cuando lo necesitan y no cuesta demasiado. La definición del glosario ISTQB abarca no sólo los requisitos especificados, sino también las necesidades y expectativas de los clientes y usuarios. Es importante que el proyecto equipo, los clientes y otras partes interesadas del proyecto establecen y acuerdan expectativas. Tenemos que entender lo que los clientes entienden por calidad y cuáles
son sus expectativas. Lo que nosotros como desarrolladores de software y testers debemos ver como la calidad, que el software cumple con su especificación definida, es técnicamente excelente y tiene algunos errores en ella, no puede proporcionar una solución de calidad para nuestra Customs client. Por otra parte, si nuestros clientes a encontrar que han gastado más dinero que querían o que el software no ayuda a llevar a cabo sus tareas, no será impresionado por la excelencia técnica de la solución. Si el cliente quiere un coche barato para una "gestión sobre 'y tiene un pequeño presupuesto, entonces un costoso coche deportivo o un tanque militar no son soluciones de calidad, por muy bien que construyen.
Para comparar las diferentes expectativas de la gente, El cuadro 1.1 resume y explica los puntos de vista y expectativas de calidad usando la 'producción y compra de los tomates 'como una analogía de' la producción y compra de software'. Usted verá como usted mirar a través de la mesa que el enfoque de la prueba sería muy diferente dependiendo de qué punto de vista estamos a favor de [Trienekens], [Evans].
Además de comprender lo que la calidad se siente y se parece a los clientes, usuarios y otras partes interesadas, que ayuda a tener algunos atributos de calidad de medir la calidad en contra, sobre todo para ayudar a la primera, basada en el producto, punto de vista en la mesa. Estos atributos o características pueden servir como un marco o listas de comprobación para las áreas a tener en cuenta la cobertura. Una de ese conjunto de atributos de calidad puede
Tabla 1.1 Puntos de vista de las expectativas y la calidad
Punto de vista Software tomates
La calidad se mide en términos de los atributos del producto.
Vamos a medir los atributos del software, por ejemplo, su fiabilidad en términos de tiempo
medio entre fallos (MTBF), y suelte cuando alcanzan un determinado nivel, por ejemplo,
MTBF de 12 horas.
Los tomates son el tamaño y la forma correcta para el embalaje
para el supermercado. Los tomates tienen un buen sabor y
color,
La calidad es la aptitud para el uso. La calidad puede tener aspectos subjetivos y no sólo los
aspectos cuantitativos.
Vamos a pedir a los usuarios si pueden llevar a cabo sus tareas; si
están satisfechos de que puedan dar a conocer el software.
Los tomates son adecuados para nuestra receta,
La calidad se basa en buenos procesos de fabricación, y la
reunión de los requisitos definidos. Se mide mediante pruebas, inspección y análisis
de fallos y los errores.
Vamos a utilizar un proceso de desarrollo de software reconocido. Sólo se crea. Liberar el software si hay menos de cinco
defectos de alta prioridad en circulación una vez que las
pruebas previstas se han completado.
Los tomates están orgánicamente, los tomates no tienen manchas y
sin plagas, dañar
Expectativa de relación calidad-precio, Asequibilidad, y una compensación basada en el valor
entre el tiempo, esfuerzo y aspectos económicos. Podemos
darnos el lujo de comprar este software y esperar un retorno de
la inversión.
Hemos encajadas en tiempo de la prueba de dos semanas de permanecer en el presupuesto del
proyecto.
Los tomates tienen una buena vida útil. Los tomates son de valor económico o bien para
Sentimientos trascendentes, esto es acerca de los sentimientos de
un individuo o grupo de individuos hacia un producto o
un proveedor.
Nos gusta este software! Es divertido y es la última cosa! Entonces, ¿qué si tiene algunos problemas? Queremos utilizar de todos modos... Nos gusta trabajar con este equipo de software. Por lo tanto, hubo algunos problemas que ellos lo solucionaron muy
rápido confiamos en ellos.
Obtenemos nuestros tomates de una pequeña granja local y nos
llevamos tan bien con los productores,
Se encuentran en la norma ISO 9126. Esta jerarquía de características y sub características de calidad se discute en el Capítulo 2.
¿Qué es el análisis de causa raíz?
Cuando detectamos fallos, podríamos tratar de rastrear de nuevo a su causa raíz, la verdadera razón de que ocurrieron. Hay varias maneras de llevar a cabo la raíz, análisis de la causa, a menudo con un grupo de lluvia de ideas y discutirlas, por lo que puede ver diferentes técnicas en diferentes organizaciones. Si usted es interesados en el uso de análisis de causa raíz en su trabajo, encontrará técnicas simples se describe en [Evans], [TQMI] y [Robson]. Por ejemplo, supongamos que una organización tiene un problema con la impresión en varias ocasiones en su defecto. Algunos de mantenimiento de TI popular se reúnen para examinar el problema y empiezan por toda la lluvia de ideas posibles causas de los fracasos. A continuación, se agrupan en categorías que tienen elegido, y ver si hay causas subyacentes o profundas comunes. Algunos de las causas obvias que descubren podrían ser: • La impresora se queda sin suministros (tinta o papel).
• Software del controlador de la impresora falla.
• Sala de la impresora está demasiado caliente para la impresora y se apodera de arriba. Estas son las causas inmediatas. Si nos fijamos en uno de ellos, 'impresora se queda sin suministros (tinta o papel) ', puede ocurrir debido a:
• Nadie es responsable de comprobar los niveles de papel y de tinta en la impresora; posible causa fundamental: ningún proceso para comprobar los niveles de tinta de impresora / papel antes de utilizar.
• Algunos miembros del personal no sabe cómo cambiar los cartuchos de tinta; posible causa de la raíz: personal no capacitado o dado instrucciones en el cuidado de las impresoras. • No hay suministro de cartuchos de repuesto o papel; posible causa de la raíz: hay un proceso de control de existencias y pedidos.
Si el análisis se limita al software, lo podría hacer en estos y decir,
"No se trata de problemas de software, por lo que no nos conciernen! ' Así que, como software testers podríamos limitarnos a informar del fallo de controlador de impresora. Sin embargo, nuestra competencia como testers puede estar más allá del software; podríamos tener que remitir a mirar todo un sistema que incluye hardware y firmware. Además, incluso si nuestra competencia es el software, es posible que desee considerar la forma de software que pueda ayudar a las personas a prevenir o resolver problemas; podemos mirar más allá de este punto de vista. El software podría proporcionar una interfaz de usuario que ayuda al usuario anticipar cuando papel o la tinta se está agotando. Se podría proporcionar instrucciones paso a paso para ayudan a los usuarios cambiar los cartuchos o reponer papel. Se podría proporcionar un alto aviso de la temperatura de manera que el medio
ambiente puede ser controlado. Como testers, nos No queremos sólo de pensar e informar sobre los defectos, pero, con el resto del proyecto equipo, pensar en cualquier posibles causas de fallos.
Utilizamos las pruebas para ayudarnos a encontrar fallos y los errores (potenciales) en el software desarrollo, mantenimiento y operaciones. Hacemos esto para ayudar a reducir el riesgo de los fallos que se producen en un entorno operativo, en otras palabras, una vez que el sistema está siendo utilizado y contribuir a la calidad del sistema de software.
Sin embargo, al mismo tiempo tenemos que pensar e informar sobre una amplia variedad de defectos y los fracasos, no todos se arreglen. Programadores y otros pueden corregir defectos antes de divulgar el sistema para su uso operativo, pero puede ser más sensato evitar el fracaso. La fijación de un defecto tiene alguna posibilidad de introducir otro defecto o de ser hecho incorrecta o incompleta. Esto es especialmente cierto si estamos arreglando un defecto bajo presión. Por esta razón, los proyectos tendrán una visión a veces que aplazará la fijación de un fallo. Esto no significa que el tester que ha encontrado los problemas ha perdido el tiempo. Es útil saber que hay un problema, y nos puede ayudar a los usuarios del sistema sólo funcionan alrededor y lo evitan.
Cuanto más rigurosa nuestras pruebas, más defectos encontraremos. Pero se verá en Los capítulos 3 y 4, cuando nos fijamos en las técnicas para la prueba, que la prueba rigurosa no significa necesariamente más pruebas; lo que queremos hacer es la prueba de que se encuentra defectos una pequeña cantidad de bien colocado, pruebas selectivas podrían ser más riguroso que un gran número de pruebas de mal centrados.
Vimos anteriormente que una de las estrategias para hacer frente a los errores, fallos y los errores se para tratar de evitar que ellos, y nos fijamos en la identificación de las causas de los defectos y fracasos. Cuando empezamos un nuevo proyecto, vale la pena aprender de los problemas encontrados en proyectos anteriores o en el software de producción. Comprensión las causas raíz de los defectos es un aspecto importante de las actividades de aseguramiento de la calidad, y prueba contribuye al ayudarnos a identificar defectos tan pronto como sea posible antes de que el software está en uso. Como testers, también estamos interesados en el estudio de los defectos encontrados en otros proyectos, por lo que podemos mejorar nuestros procesos. Proceso mejoras deberían evitar los defectos recurrentes y, como consecuencia, mejorar la calidad de los sistemas futuros. Las organizaciones deben considerar la prueba como parte de una estrategia de control de calidad más grande, que incluye otras actividades (por ejemplo, normas de desarrollo, entrenamiento y análisis de causa raíz).
1.1.6 ¿Cuánta prueba es suficiente?
Principio de pruebas - Las pruebas exhaustivas no es posible
Prueba de todo (todas las combinaciones de insumos y las condiciones previas) no es factible a excepción de casos triviales. En lugar de pruebas exhaustivas, utilizamos los riesgos y prioridades para enfocar los esfuerzos de prueba.
Hemos visto que las pruebas nos ayudan a encontrar defectos y mejorar la calidad del software. Cómo muchas pruebas debemos hacer? Tenemos una opción: Prueba de todo, nada
prueba o probar algunos de los programas. Ahora, su respuesta inmediata para que así puede ser de por ejemplo, "Todo debe ser probado '. No queremos utilizar el software que no ha sido completamente probado, ¿verdad? Esto implica que hay que ejercitar todos los aspectos de un sistema de software durante la prueba. Lo que tenemos que considerar es si nos debe, o incluso puede, probar por completo.
Veamos la cantidad de pruebas que tendríamos que hacer para ser capaz de probar agotamiento. ¿Cuántas pruebas se necesita hacer para probar por completo una de un dígito ¿campo numérico? La pregunta inmediata es: "¿Qué quiere decir con la prueba por completo?
Hay 10 posibles valores numéricos válidos, pero así como los valores válidos nosotros necesitará asegurarse de que todos los valores válidos son rechazados. Hay 26 mayúsculas Los caracteres alfabéticos, 26 minúsculas, por lo menos 6 caracteres especiales y signos de puntuación como así como un valor en blanco. Por lo que habría por lo menos 68 pruebas de este ejemplo de un campo de un dígito.
Este problema solo empeora a medida que nos fijamos en los ejemplos más realistas. En práctica Tice, los sistemas tienen más de un campo de entrada con ser los campos de la variación tamaños. Estas pruebas serían junto a otros como la ejecución de las pruebas de diferencia Sección 2 ¿Cuál es la prueba? 11 ambientes ENT. Si tomamos un ejemplo en una pantalla cuenta con 15 campos de entrada, cada uno con 5 valores posibles, a continuación, para poner a prueba la totalidad del valor de entrada válida combinaciones que se necesita 30 517 578 125 (515) Las pruebas! Es poco probable que el proyecto escalas de tiempo se permita esta cantidad de pruebas.
Prueba de nuestro campo de un dígito con valores de 2, 3 y 4 hace que nuestras pruebas más Thor- ough, pero no nos da más información que si acabábamos probado con el valor 3. Las presiones sobre un proyecto incluyen el tiempo y el presupuesto, así como la presión de ofrecer una solución técnica que satisfaga las necesidades de los clientes. Clientes y jefes de proyecto tendrá que pasar una cantidad de pruebas que proporciona un retorno de la inversión para ellos. Este retorno de la inversión incluye prevenibles fallos después de la liberación que son costosos. Probando por completo - incluso si eso es lo que los clientes y gestores de proyectos piden no es más que lo que pueden permitirse.
En cambio, necesitamos un enfoque de prueba que proporciona la cantidad correcta de las pruebas para este proyecto, estos clientes (y otras partes interesadas) y este software. Nosotros hacer esto mediante la alineación de las pruebas que hacemos con los riesgos para los clientes, los grupos de interés titulares, el proyecto y el software. La evaluación y gestión del riesgo es una de las la mayoría de las actividades importantes en cualquier proyecto, y es una actividad clave y la razón de pruebas. Decidir la cantidad de pruebas es suficiente debe tener en cuenta el nivel de riesgo, incluidos los riesgos técnicos y comerciales relacionados con el producto y el proyecto restricciones tales como el tiempo y el presupuesto.
Llevamos a cabo una evaluación de riesgos para decidir la cantidad de pruebas que hacer. Podemos entonces variar el esfuerzo de pruebas basado en el nivel de riesgo en diferentes áreas.
Además, las pruebas deben proporcionar suficiente información para las partes interesadas para tomar decisiones informadas acerca de la versión del software o del sistema estamos probando, para el siguiente paso de desarrollo o entrega a los clientes. El esfuerzo puesto en la garantía de calidad y actividades de prueba tiene que ser tai lored a los riesgos y los costos asociados con el proyecto. Debido a la límites en el presupuesto, el tiempo, y en las pruebas que necesitamos para decidir la forma en que se centrar nuestra prueba, basado en los riesgos. Pronto nos ocuparemos de la evaluación de riesgos en Capítulo 5.
1.2 Qué es la prueba?
Objetivos de aprendizaje del programa de estudios para 1.2 ¿Cuál es la prueba? 1 Recordemos los objetivos comunes de la prueba. (KL)
2 Describir el propósito de las pruebas en el desarrollo de software, mantenimiento y las operaciones como un medio para encontrar defectos, proporcionan la confianza y la información y prevenir los defectos. (K2)
En esta sección, vamos a revisar los objetivos comunes de la prueba. Vamos a explicar cómo las pruebas nos ayudan a encontrar defectos, dar confianza a la información, y prevenir los defectos. También introduciremos otros principios fundamentales de pruebas.
A medida que lea esta sección, se encontrará con los términos de código, depuración, desarrollo de software, requisitos, revisión, base de pruebas, casos de prueba, la prueba y objetivo de la prueba.
1.2.1 La prueba de conducción - una analogía para las pruebas de software
Hemos pasado algún tiempo describiendo por qué tenemos que probar, pero no hemos discutido lo que es prueba. ¿Qué entendemos por la palabra de pruebas? Utilizamos las palabras prueba y prueba en la vida cotidiana y anterior nos dijo que las pruebas podrían ser descritas como 'Comprobar el software está bien'. Eso no es una definición suficientemente detallada para ayudar a entender las pruebas de software. Vamos a usar una analogía para ayudarnos: los exámenes de conducción. En una prueba de conducción, el examinador evalúa críticamente la conducción del candidato, señalando cada error, grande o pequeña, hecha por el conductor bajo prueba. El examinador toma el conductor a través de una ruta que pone a prueba muchas actividades de conducción posibles, tales como cruces de carreteras de diferentes tipos, de control y maniobra del vehículo, capacidad para detenerse de manera segura en caso de emergencia, y la conciencia de la carretera, otros usuarios de la carretera y peligros. Algunas de las actividades deben ser probadas. Por ejemplo, en el Reino Unido, una Comprobación de la parada de emergencia siempre se lleva a cabo, con el examinador que simula al momento de emergencia por golpear el tablero de instrumentos momento en el que el conductor debe detener el coche de forma rápida, segura y sin pérdida de control. Al final de la prueba, el examinador hace un juicio sobre el comportamiento del conductor. Tiene el controlador superando la prueba o no? El examinador basa la sentencia sobre el número y gravedad de los fallos detectados, y también si el conductor ha podido satisfacer las necesidades de conducción. Un fallo grave solo es suficiente para quebrar la totalidad prueba, pero un pequeño número de fallos menores aún podrían implicar que se superó la prueba. Muchas fallas menores reducirían la confianza del examinador en la calidad de la conducción hasta el punto en que el conductor no puede pasar. El formato de la prueba de conducción y de la conducta del examinador es dignas de consideración:
• La prueba es planificado y preparado. Antes de la prueba, el examinador ha planeado una serie de rutas que cubren las actividades motrices clave para permitir una evaluación
exhaustiva de la actuación del conductor. Los conductores menores de prueba hacen no saben qué ruta se les pedirá a tomar con antelación, aunque conocer los requisitos de la prueba. • La prueba ha conocido metas - evaluar si el conductor es suficientemente seguro le permitirá conducir por sí mismos sin un instructor, sin poner en peligro a sí mismos u otros. Existen claras apto / no apto criterios, basado en el número y la gravedad de las faltas, pero con la confianza de que el examinador en el conducción también se tiene en cuenta. • La prueba se lleva a cabo por lo tanto, para demostrar que los requerimientos los satisface el conductor para la conducción y para demostrar que están en condiciones de conducir. El examinador busca fallas en la conducción. El tiempo para la prueba es limitado, por lo que no es una prueba completa de las capacidades del conductor, pero es representativa, y permite que el examinador para tomar una decisión basada en el riesgo sobre el controlador. Todos los conductores están probados de forma equivalente y el examinador es neutral y objetivo. El examinador registrará observaciones objetivas que permiten una evaluación del riesgo de ser hecho sobre la conducción. En base a esto, se le dará al conductor una formar lo que le permite solicitar una licencia de conducir. Un conductor que no voluntad obtener un informe con una lista de fallos y áreas a mejorar antes de volver a tomar la prueba.
• Además de la observación de que el conductor efectivamente el volante, el examinador le preguntará preguntas o el conductor tomarán un examen escrito para comprobar su escasa pie de las normas de circulación, señales de tráfico, y qué hacer en varios situaciones de tráfico.
1.2.2 Definición de las pruebas de software
Con esa analogía en mente, veamos la definición de software ISTQB Pruebas.
Vamos a romper la definición en partes; la definición tiene alguna clave frases para recordar. La definición comienza con una descripción de la prueba como una proceso y, a continuación se enumeran algunos objetivos del proceso de prueba. En primer lugar, vamos a ver probando como un proceso:
• Proceso - La prueba es un proceso más que una sola actividad - hay una serie de las actividades en cuestión.
• Todas las actividades del ciclo de vida - Capítulo 2 se analizan las pruebas como un proceso que se lleva colocar a lo largo del desarrollo de software de ciclo de vida. Vimos anteriormente que cuanto más tarde en el ciclo de la vida nos encontramos con errores, es más caro que son arreglar. Si podemos encontrar y corregir defectos en los requisitos de los requisitos etapa, que debe tener sentido comercial. Vamos a construir el software adecuado, correctamente y en un menor costo total. Por lo tanto, el proceso de pensamiento de diseño, pruebas temprano en el ciclo de vida puede ayudar a prevenir defectos de ser introducido en el código. A veces nos referimos a esto como "la verificación de la prueba base a través del diseño de la prueba '. La base de pruebas incluye documentos tales como el requisitos y especificaciones de diseño. Vas a ver cómo hacer esto en Capítulo 4.
• Tanto estática y dinámica - Veremos en el capítulo 3 que, además de pruebas en las que el código de software es ejecutado para demostrar los resultados de las pruebas se ejecutan (A menudo llamado pruebas dinámicas) también podemos probar y encontrar defectos sin ejecutar código. Esto se llama prueba estática. Esta prueba incluye la revisión de documentos (incluyendo el código fuente) y el análisis estático. Esta es una útil y manera rentable de las pruebas.
• Planificación - Las actividades se llevan a cabo antes y después de la ejecución de la prueba. Necesitamos que administrar la prueba; por ejemplo, tenemos la intención de lo que queremos hacer; controlamos la actividades de prueba; nos informe sobre el progreso de prueba y el estado del software bajo prueba; y finalizamos o cerca de ensayos cuando se completa una fase. Capítulo 5 se refiere a estas actividades de gestión de prueba.
• Preparación - Tenemos que elegir lo que prueba que vamos a hacer, mediante la selección con la prueba las condiciones y el diseño de casos de prueba. Capítulo 4 cubre las actividades de diseño de prueba.
• Evaluación - Así como la ejecución de las pruebas, debemos comprobar los resultados y evaluar el software bajo prueba y los criterios de finalización, que nos ayudan a decidirnos si hemos terminado las pruebas y si el producto de software ha superado las pruebas.
• Los productos de software y productos de trabajo relacionados - Hacemos no sólo el código de prueba. Probamos los requisitos y especificaciones de diseño, y nos ponen a prueba los documentos relacionados tales como la operación, el usuario y material de formación. Pruebas estáticas y dinámicas son ambos necesarios para cubrir la gama de productos que necesitamos para poner a prueba.
La segunda parte de la definición cubre algunos de los objetivos de la prueba - las razones por las que lo hacemos:
• Determinar que los productos de software satisfacen los requisitos especificados: Algunos de las pruebas que hacemos se centra en el control de los productos con las especificaciones de para el producto; por ejemplo, se revisa el diseño para ver si cumple requerimientos, y entonces podríamos ejecutar el código para comprobar que cumple con el diseño.
Si el producto cumple con su especificación, podemos proporcionar esa información a ayudar a los usuarios juzgan la calidad del producto y decidir si es Listo para usar.
• Demostrar que (los productos de software) son aptos para el propósito: Esta cifra es ligeramente diferente con el punto anterior; después de todos los requisitos especificados podrían ser incorrecta o incompleta. 'Es adecuado al fin' analiza si el software hace suficiente para ayudar a los usuarios para llevar a cabo sus tareas; nos fijamos en si la suave cerámica hace lo que el usuario podría esperar razonablemente. Por ejemplo, podríamos mira que podrían comprar o utilizar el software, y comprobar que se hace lo que esperan; esto nos podría llevar a añadir un comentario del compañero de comercialización de nuestras pruebas estáticas, para comprobar que las expectativas del software están correctamente conjunto. Una manera de juzgar la calidad de un producto es por su estado de forma es por su propósito.
• Detección de defectos: Lo más a menudo pensamos en las pruebas de software como medio de la detección de fallos o defectos que, en uso operativo causarán fallas. Hallazgo los defectos nos ayuda a comprender los riesgos asociados con poner el software en uso operativo, y la fijación de los defectos mejora la calidad de los productos. Sin embargo, la identificación de defectos tiene otra ventaja. Con causa raíz análisis, sino que también ayudan a mejorar los procesos de desarrollo y hacer un menor número de errores en el trabajo futuro.
Esta es una definición adecuada de las pruebas para cualquier nivel de pruebas, a partir de componente de pruebas a través de las pruebas de aceptación, siempre que recordemos que
tomar los diversos objetivos de estos diferentes niveles de pruebas en cuenta. (En Capítulo 2 explicaremos los diferentes niveles de la prueba, sus objetivos, y cómo encajan en el ciclo de vida de desarrollo de software.).
Podemos ver claramente ahora por qué la percepción común de pruebas (que sólo consiste en la ejecución de pruebas, es decir, la ejecución del software) no es completa. Este es uno de las actividades de prueba, pero no todos los del proceso de prueba.
Prueba y prueba de conducción 1.2.3 Software comparó
Podemos ver que la prueba de software es muy parecido a una prueba de conducción de muchas maneras, aunque por supuesto no es una analogía perfecta! El examinador se convierte el tester de software. El conductor que se examina se convierte en el sistema o software bajo prueba, y verá a medida que avanzamos a través de este libro que el mismo enfoque sostiene ampliamente.
• Planificación y preparación - Tanto el examinador y el tester necesitan un plan de la acción y la necesidad de prepararse para la prueba, que no es exhaustiva, pero es representativa y permite tomar decisiones basadas en el riesgo sobre el resultado.
• estático y dinámico - Tanto dinámico (conducir el coche o la ejecución de la suave Ware) y estáticas (preguntas al conductor o una revisión del software) son pruebas útil.
• Evaluación - El examinador y el tester debe hacer un objetivo evaluación, registrar el resultado de la prueba y reportar observaciones objetivas sobre la prueba.
• Determinar que cumplan los requisitos especificados – El examinador y tester tanto verificación según las necesidades para llevar a cabo tareas particulares exitosamente. • Demostrar que son aptos para el propósito - El examinador y el tester no son la evaluación de la perfección, sino para cumplir suficiente los atributos necesarios para pasar la prueba. • Detección de defectos - El examinador y el tester de tanto buscar y registro fallos.
Vamos a pensar un poco más acerca de la planificación. Porque el tiempo es limitado, con el fin de realizar un recorrido representativo que lo haría proporcionar una suficientemente buena prueba, ambos testers de software y examinadores deciden de antemano la ruta que tomarán.
No es posible llevar a cabo la prueba de conducción y tomar decisiones sobre dónde pedir al conductor que vaya al lado en el calor del momento.
Si el examinador hizo eso, podrían quedarse sin tiempo y tienen que volver al centro de pruebas sin haber observado todas las maniobras necesarias. El conductor todavía va a querer un pase / informe de fallo.
De la misma manera, si nos embarcamos en la prueba de un sistema de software sin un plan de acción, que son muy propensos a quedarse sin tiempo antes de saber si hemos hecho lo suficiente la prueba. Ya veremos que los buenos testers siempre tienen un plan de acción. En algunos casos, utilizamos un esquema de peso ligero que proporciona los objetivos y generales dirección de la prueba, permitiendo que los testers para variar la prueba durante ejecución. En otros casos, se utiliza guiones detallados que muestran los pasos en la ruta de prueba y documentar exactamente lo que el tester debe esperar que
suceda ya que cada paso. Cualquiera sea el enfoque del tester de toma, habrá un plan de acción. Del mismo modo, tal como El examinador hace un registro y reporte, un buen tester defectos de documentos objetivamente encontraron y el resultado de la prueba.
Por lo tanto, existen actividades de prueba antes y después de la ejecución de la prueba, y nos explicar esas actividades en este libro. Como tester o el director de pruebas, usted estará involucrado en la planificación y control de la prueba, la elección de las condiciones de prueba, el diseño de casos de prueba en base a las pruebas condiciones, la ejecución de ellos y comprobación de resultados, que evalúan si las pruebas suficientes que se ha hecho mediante el examen de finalización (O salida) criterios, al informar sobre el proceso de prueba y el sistema bajo finalización de la prueba, y la presentación de pruebas (o resumen) informa.
1.2.4 Cuando podemos cumplir con nuestros objetivos de la prueba? Principio de pruebas - Las primeras pruebas
Las actividades de prueba deben comenzar tan pronto como sea posible en el software o el sistema de vida de desarrollo ciclo y debe centrarse en objetivos definidos.
Podemos utilizar tanto las pruebas dinámicas y pruebas estáticas como medio para el logro de similares objetivos de la prueba. Ambos proporcionan información a mejorar tanto el sistema a ser probado, el desarrollo y los procesos de prueba. Hemos mencionado anteriormente que la prueba puede tener diferentes metas y objetivos, que a menudo incluyen:
• encontrar defectos;
• ganando confianza y proporcionar información sobre el nivel de la calidad; • La prevención de defectos.
Muchos tipos de revisión y pruebas actividades se llevan a cabo en diferentes etapas del ciclo de vida, como veremos en el capítulo 2. Estos tienen diferentes objetivos. Temprano las pruebas, tales como actividades de diseño y revisión de la prueba temprana encuentran defectos desde el principio cuando son baratos para encontrar y corregir. Una vez que el código está escrito, programadores y testers a menudo corren un conjunto de pruebas para que puedan identificar y corregir los defectos de El software. En este 'pruebas de desarrollo "(que incluye los componentes, integración y las pruebas del sistema), el principal objetivo pueden ser para causar el mayor número de fracasos posible, de manera que se identifican los defectos en el software y se pueden fijar.
Después de que las pruebas, los usuarios del software pueden llevar a cabo la aceptación las pruebas para confirmar que el sistema funciona como se espera y para ganar confianza que ha cumplido con los requisitos.
La fijación de los defectos no siempre puede ser el objetivo de la prueba o el resultado deseada. A veces simplemente queremos recabar información y medir el software. Esto puede tomar la forma de medidas de atributos tales como el tiempo promedio entre fallos para evaluar la fiabilidad, o una evaluación de la densidad de defectos en el software para evaluar y comprender el riesgo de soltarlo.
Cuando el mantenimiento del software mediante la mejora o corregir errores, estamos cambiando software que ya se está utilizando. En ese caso, un objetivo de las pruebas puede ser para asegurarse de que no hemos cometido errores y defectos introducidos cuando ha cambiado el software. Esto se llama la prueba de regresión pruebas para garantizar nada ha cambiado que no debería haber cambiado.
Podemos continuar para probar el sistema una vez que está en uso operacional. En este caso, el objetivo principal puede ser evaluar las características del sistema, como la fiabilidad o disponibilidad.
Principio de pruebas - agrupación de defectos
Un pequeño número de módulos contiene la mayor parte de los defectos descubiertos durante el pre-lanzamiento las pruebas o mostrar la mayoría de los fracasos operacionales.
1.2.5 Centrándose en defectos puede ayudar a planificar nuestras pruebas
Un análisis de defectos y fracasos con el fin de mejorar los procesos nos permite mejorar nuestras pruebas y nuestros requerimientos, diseño y desarrollo procesos. Un fenómeno que han observado muchos testers es que los defectos tienden a agruparse. Esto puede suceder debido a que un área del código es especialmente complejo y difícil, o porque el cambio de software y otros productos tiende que causa defectos de reacción en cadena. Testers suelen usar esta información cuando hacer su evaluación de riesgos para la planificación de las pruebas, y se centrará en conocida "puntos calientes".
Un objetivo principal de opiniones y otras pruebas estáticas es llevar a cabo la prueba como pronto sea posible, encontrar y corregir los defectos de forma más barata y la prevención defectos que aparezcan en las etapas posteriores de este proyecto. Estas actividades nos ayudan averiguar acerca de los defectos anteriormente e identificar posibles grupos. Además, un importante resultado de todas las pruebas es la información que ayuda a la evaluación de riesgos; estas opiniones contribuirán a la planificación de las pruebas ejecutadas más tarde en el ciclo de vida del software de desarrollo. También podemos llevar a cabo la raíz Análisis de la causa para evitar defectos y fallos se presente de nuevo y tal vez para identificar la causa de los clusters y agrupaciones potenciales futuras.
1.2.6 Los grupos de defectos cambian con el tiempo Principio de pruebas - paradoja de Pesticidas
Si las mismas pruebas se repiten una y otra vez, con el tiempo el mismo conjunto de casos de prueba se ya no se encuentra ninguna nuevos errores. Para superar esta "paradoja del pesticida ', los casos de prueba deben ser examinados y revisados con regularidad, y necesitan ser escritas para ejercer pruebas nuevas a diferentes partes del software o sistema para encontrar potencialmente más defectos.
Con el tiempo, a medida que mejoramos nuestro ciclo de vida de desarrollo de software de todo y los primeros estudios de estática, que bien puede encontrar que los niveles de los ensayos dinámicos que se encuentran menos defectos. Una iniciativa típica de mejora de ensayo inicialmente se encuentra más defectos como las pruebas de mejora y, a continuación, como la prevención de defectos entra en acción, vemos los números defecto de goteo, como
se muestra en la Figura 1.3. La primera parte de la mejora nos permite reducir los fallos en el funcionamiento; después, la mejora nos hace más eficientes y eficaces en la producción del software con menos defectos en el mismo.
Como los "puntos calientes" para los insectos se limpiaron tenemos que mover nuestro enfoque en otras partes donde, a la siguiente serie de riesgos. Con el tiempo, nuestro enfoque puede cambiar de la búsqueda errores de codificación, al mirar a los requisitos y documentos de diseño de los defectos, y a la búsqueda de mejoras en los procesos de manera que se previene defectos en el producto. Con referencia a la Figura 1.3, por la publicación de 9 y 10, esperaríamos que la coste total y el esfuerzo asociado con reseñas y ensayos es mucho menor que en comunicados de 4 o 7.
1.2.7 Depuración elimina defectos
Cuando una prueba encuentra un defecto que debe ser fijo, un programador tiene que hacer algún trabajo para localizar el defecto en el código y hacer la corrección. En este proceso, llamado debuging, un programador examinará el código de la causa inmediata del problema, repare el código y comprueba que el código se ejecuta ahora como se esperaba. El arreglo está a menudo entonces prueba por separado (por ejemplo, mediante un tester independiente) para confirmar la solución. Tenga en cuenta que las pruebas y la depuración son actividades diferentes. Desarrolladores pueden probar sus propias correcciones, en cuyo caso el ciclo muy ajustado de la identificación de fallos, depuración y repetición del examen es a menudo referido libremente como la depuración. Sin embargo, a menudo siguiendo el ciclo de depuración del código fijo se prueba de forma independiente tanto para volver a probar la corrección de sí mismo y de aplicar las pruebas de regresión a los alrededores software sin cambios.
1.2.8 ¿Es el defecto del software libre?
Principio de pruebas - Las pruebas muestran presencia de defectos
Las pruebas pueden demostrar que los defectos están presentes, pero no puede demostrar que no hay defectos.
Testing reduce la probabilidad de defectos sin descubrir que quedan en el software, pero, incluso sino se encuentran defectos, no es una prueba de la corrección.
Este principio se deriva de la teoría del proceso de experimentación científica y ha sido adoptado por los testers; verá la idea en muchos libros de ensayo.
Si bien no se espera para leer la teoría científica [Popper] la analogía utilizado en la ciencia es útil; Sin embargo muchos cisnes blancos que vemos, no podemos decir 'Todo cisnes son blancos ». Sin embargo, tan pronto como vemos un cisne negro que podemos decir 'No todos los cisnes son blancos ». De la misma manera, sin embargo, muchas pruebas que se ejecutan sin la búsqueda de un error, no hemos mostrado 'No hay errores'. Tan pronto como nos encontramos con un error, hemos demostrado 'Este código no está libre de errores'.
1.2.9 Si no encontramos defectos ¿Eso significa que los usuarios aceptaran el software? Principio de pruebas - Ausencia de errores falacia.
Encontrar y corregir defectos no ayuda si el sistema integrado se puede utilizar y no cumple las necesidades y expectativas de los usuarios.
Hay otro principio importante debemos tener en cuenta; los clientes de cerámica, las personas y organizaciones que compran y lo utilizan para ayudar en su día a tareas del día, no están interesados en los defectos o número de defectos, salvo cuando están directamente afectados por la inestabilidad del software. Las personas que utilizan, cerámica están más interesados en el software de apoyo en la realización de tareas Eficiente y efectivamente. El software debe satisfacer sus necesidades. Es por esta razón por la que los requisitos y defectos de diseño que hemos discutido son tan importante, y por qué las revisiones e inspecciones (véase el Capítulo 3) son un ejemplo fundamental parte mental de toda la actividad de prueba. 1.3 PRINCIPIOS DE PRUEBA
1 Explicar los principios fundamentales en las pruebas. (K2)
En las secciones 1.1 y 1.2, hemos introducido una serie de pruebas y principios breves explicaciones. Estos se enumeran en la Tabla 1.2, para que lo lea más para recordar mismo acerca de ellos. Estos principios se han sugerido en los últimos 40 años y ofrecen directrices generales comunes para todas las pruebas.
TABLA 1.2 principios de prueba
Principio 1 Las pruebas muestran presencia de defectos
Las pruebas pueden demostrar que los defectos
están presentes, pero no puede demostrar que no hay
defectos. Testing reduce la probabilidad de defectos sin
descubrir que quedan en el software, pero, incluso si no
se detectan deficiencias, no es una prueba de la
corrección.
Principio 2 Las pruebas
exhaustivas son imposible
Todo Testing (todas las combinaciones de insumos y las condiciones previas) no es viable a excepción de los casos triviales. En lugar de exhaustivas pruebas,
utilizamos los riesgos y prioridades para centrar los esfuerzos de prueba.
Principio 3 Las primeras pruebas Las actividades de prueba deben comenzar tan pronto
como sea posible en el software o sistema el desarrollo del ciclo de vida
y debe ser centrado en objetivos definidos. Principio 4 Agrupación defecto Un pequeño número de
módulos contienen la mayor parte de los defectos descubiertos durante la pre- liberar, las pruebas mostran
la mayor parte fallas operacionales. Principio 5 Paradoja de Pesticidas Si las mismas pruebas se
repiten una y otra vez, con el mismo conjunto de
prueba, casos ya no encuentra ningún nuevo
error. A superar esta "paradoja del pesticida ', la
prueba casos necesitan ser revisados con regularidad y nuevas y diferentes pruebas necesitan para ser escrito,
para ejercer diferentes partes del software o sistema para encontrar
potencialmente más defectos.
Principio 6 Las pruebas
son dependientes del contexto
Las pruebas se hacen de manera diferente en diferentes contextos. Por ejemplo, la seguridad crítica
software se prueba de manera diferente a partir de
un sitio de comercio electrónico.
Principio 7 Ausencia de errores,
falacia
Encontrar y corregir defectos no ayuda si el sistema integrado se puede utilizar y no lo hace
satisfacer las necesidades y expectativas de los usuarios. 1.4 FUNDAMENTAL proceso de prueba
1 Recordemos las actividades fundamentales de la prueba desde la planificación hasta actividades de cierre de la prueba y las tareas principales de cada prueba actividad. (KL)
1.4.1 Introducción
En esta sección, vamos a describir el proceso de la prueba fundamental y actividades. Estos comienzan con la planificación de controles y continúan hasta el cierre a prueba.
Para cada parte del proceso de prueba, vamos a discutir las principales tareas de cada prueba actividad.
En esta sección, también se encontrará con los términos del glosario de pruebas de confirmación, criterios de salida, incidentes, pruebas de regresión, base de pruebas, la prueba condición, cobertura de las pruebas, datos de prueba, ejecución de la prueba, registro de la prueba, la prueba plan, la estrategia de prueba, el informe de resumen de la prueba y testware.
Como hemos visto, aunque las pruebas de ejecución son importante, también necesitamos una plan de acción y un informe sobre el resultado de las pruebas. Los planes del proyecto y de prueba deben incluir el tiempo que se gasta en la planificación de las pruebas, el diseño de casos de prueba, la preparación para la ejecución y la evaluación del estado. La idea de una prueba fundamental proceso para todos los niveles de la prueba se ha desarrollado a lo largo de los años. Sea cual sea el nivel de las pruebas, vemos el mismo tipo de actividades principales que suceden, aunque hay puede ser una cantidad diferente de formalidad en los diferentes niveles, por ejemplo, pruebas de componentes pueden ser llevadas a cabo de manera menos formal de las pruebas del sistema en la mayoría organizaciones con un proceso de prueba menos documentado. La decisión sobre el nivel de formalidad de los procesos dependerá del sistema y el software contexto y el nivel de riesgo asociado con el software. Así podemos dividir las actividades en el proceso de prueba fundamental en los siguientes pasos básicos:
• Planificación y control; • Análisis y diseño;
• Implementación y ejecución;
• Evaluación de los criterios de salida y presentación de informes; • Las actividades de cierre de prueba.
Estas actividades son lógicamente ordenadas, pero en un proyecto en particular, puede solaparse, simultáneamente e incluso repetirse. Este proceso es especialmente, utilizado para la prueba dinámica, pero las principales partidas del proceso se puede aplicar a críticas también. Por ejemplo, tenemos que planificar y prepararse para una revisión, llevar a cabo las opiniones y evaluar los resultados de las críticas. Para algunas críticas, como las inspecciones, tendremos criterios de salida y pasará a través de las actividades de cierre. Sin
