Material

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
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
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
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
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
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 Vamos a medir los atributos del Los tomates son el tamaño y la
de los atributos del producto. software, por ejemplo, su forma correcta para el embalaje
fiabilidad en términos de tiempo para el supermercado. Los
medio entre fallos (MTBF), y tomates tienen un buen sabor y
suelte cuando alcanzan un color,
determinado nivel, por ejemplo,
MTBF de 12 horas.
La calidad es la aptitud para el Vamos a pedir a los usuarios si Los tomates son adecuados para
uso. La calidad puede tener pueden llevar a cabo sus tareas; si nuestra receta,
aspectos subjetivos y no sólo los están satisfechos de que puedan
aspectos cuantitativos. dar a conocer el software.
La calidad se basa en buenos Vamos a utilizar un proceso de Los tomates están orgánicamente,
procesos de fabricación, y la desarrollo de software los tomates no tienen manchas y
reunión de los requisitos reconocido. Sólo se crea. Liberar sin plagas,
definidos. Se mide mediante el software si hay menos de cinco dañar
pruebas, inspección y análisis defectos de alta prioridad en
de fallos y los errores. circulación una vez que las
pruebas previstas se han
completado.
Expectativa de relación calidad- Hemos encajadas en tiempo de la Los tomates tienen una buena
precio, Asequibilidad, y una prueba de dos semanas de vida útil. Los tomates son de
compensación basada en el valor permanecer en el presupuesto del valor económico o bien para
entre el tiempo, esfuerzo y proyecto. dinero,
aspectos económicos. Podemos
darnos el lujo de comprar este
software y esperar un retorno de
la inversión.
Sentimientos trascendentes, esto Nos gusta este software! Es Obtenemos nuestros tomates de
es acerca de los sentimientos de divertido y es la última cosa! una pequeña granja local y nos
un individuo o grupo de Entonces, ¿qué si tiene algunos llevamos tan bien con los
individuos hacia un producto o problemas? Queremos utilizar de productores,
un proveedor. 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.
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 Las pruebas pueden

presencia de defectos 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 Todo Testing (todas las
exhaustivas son imposible 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 Las pruebas se hacen de
son dependientes del manera diferente en
contexto 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, Encontrar y corregir
falacia 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
embargo, el detalle y la denominación de las actividades serán diferente para pruebas
estáticas. Discutiremos estática las pruebas en el Capítulo 3.
1.4.2 planificación y control de prueba
Durante la planificación de pruebas, nos aseguramos de que entendemos las metas y
objetivos de los clientes, los interesados y el proyecto, y los riesgos que la prueba es
pretende abordar. Esto nos dará lo que se llama a veces la misión de prueba o la asignación
de prueba. Sobre la base de este entendimiento, fijamos los objetivos y objetivos para los
propios ensayos, y derivan de un enfoque y un plan para las pruebas, donde se precisen las
actividades de prueba. Para ayudarnos podemos tener organización o programa de políticas
de prueba y una estrategia de prueba. Política de prueba da normas para las pruebas,
por ejemplo, 'Siempre revisan los documentos de diseño'; estrategia de prueba es el alto nivel
general enfoque, por ejemplo, "las pruebas del sistema se lleva a cabo por un equipo
independiente de informes al gestor de la calidad del programa. Será basado en el riesgo y
procede de una producto (calidad) Análisis del riesgo »(véase el capítulo 5). Si la política y
la estrategia son ya definidos que conducen nuestra planificación, pero si no nos debe pedir
que sean indicado y definido. La planificación de prueba tiene las siguientes tareas
principales, aproximación dado el fin, que nos ayudan a crear un plan de pruebas:
• Determinar el alcance y los riesgos e identificar los objetivos de la prueba: Considerar

qué software, componentes, sistemas u otros productos que están en posibilidades de
pruebas; el negocio, producto, proyecto y los riesgos técnicos que deben ser dirigido; y
si estamos probando principalmente para descubrir defectos, para mostrar que el
software cumple con los requisitos, para demostrar que el sistema es apto para el
propósito o para medir las cualidades y atributos de software.
• Determinar el enfoque de la prueba (técnicas, elementos de prueba, la cobertura, la
identificación de y la interfaz con los equipos que participan en la prueba, testware):
consideramos cómo vamos a llevar a cabo las pruebas, las técnicas a utilizar, lo que las
necesidades de pruebas y cuánto tiempo (es decir, qué grado de cobertura). Veremos que
necesita a involucrarse y cuando (esto podría incluir los desarrolladores, usuarios,
infraestructura, equipos); vamos a decidir lo que vamos a producir la mayor parte de las
pruebas (Por ejemplo testware tales como los procedimientos de prueba y los datos de
prueba). Esto se relaciona con los requisitos de la estrategia de prueba.
• Poner en práctica la política de prueba y / o la estrategia de prueba: hemos mencionado

que hay puede ser una política de organización o programa y la estrategia para la prueba. Si
esto es el caso, durante nuestra planificación que debe asegurarse de que lo que vamos a
hacer se adhiere a la política y la estrategia o que debe de haber acordado con las partes
interesadas, y documentado, una buena razón para apartarse de ella.
• Determinar los recursos de prueba requeridas (por ejemplo, personas, entorno de

prueba, PC): desde la planificación ya lo hemos hecho, ahora podemos entrar en
detalles; nosotros decidimos en nuestro equipo de maquillaje y también creamos todo el
hardware de apoyo y el software que necesitamos para el entorno de prueba.
• Tareas de análisis y diseño de pruebas Programación, ejecución de pruebas, ejecución
y evaluación: vamos a necesitar un horario de todas las tareas y actividades, por lo que
nosotros puede realizar un seguimiento de ellos y asegurarnos de que podemos completar la
prueba en el tiempo.
• Determinar los criterios de salida: tenemos que establecer criterios tales como los criterios
de cobertura (por ejemplo, el porcentaje de declaraciones en el software que debe ser
ejecutado durante la prueba) que le ayudará a realizar un seguimiento de si estamos
completando las actividades de prueba correctamente. Ellos nos mostrarán qué tareas y
controles hay que completar para un nivel particular de las pruebas antes de poder
decir que la prueba ha terminado.
La gestión de cualquier actividad no se detiene con la planificación de la

misma. Necesitamos que controlar y medir el progreso contra el plan. Por lo tanto, el
control de la prueba es un curso actividad. Necesitamos comparar el progreso real en
contra del progreso planificado, e informar al director del proyecto y del cliente sobre el
estado actual de las pruebas, incluyendo cualquier cambio o desviación del plan. Vamos a
tener que tomar medidas cuando sea necesario para cumplir con los objetivos del
proyecto. Tales acciones pueden implicar cambiar nuestro plan original, que sucede a
menudo. Cuando diferentes grupos realizar diferentes actividades de revisión y prueba
dentro del proyecto, la planificación y el control tiene que ocurrir dentro de cada uno
de esos grupos, sino también en todos los grupos para coordinar entre ellos, lo que
permite traspasos suaves entre cada etapa de pruebas. Planificación de las pruebas tiene en
cuenta la retroalimentación de monitoreo y las actividades de control que tienen lugar
durante todo el proyecto. Prueba de control tiene la las siguientes tareas principales:
• Medir y analizar los resultados de los exámenes y pruebas: Tenemos que saber cuántas
críticas y pruebas que hemos realizado. Tenemos que realizar un seguimiento de cuántos
pruebas han pasado y cuántos fallado, junto con el número, el tipo e importancia de los
defectos indicados.
• Seguir el progreso y criterios documento, cobertura de la prueba y de salida: Es
importante que se informa al equipo del proyecto la cantidad de pruebas se ha hecho, lo
que él Los resultados son, y qué conclusiones y evaluación de riesgos que hemos
tomado. Debemos hacer que el resultado de la prueba visible y útil para todo el equipo.
• Proporcionar información sobre las pruebas: Debemos esperar para hacer regular
informes excepcionales al jefe de proyecto, dirección de obra, los clientes y otros actores
clave para ayudarles a tomar decisiones informadas sobre estado del proyecto. También
debemos utilizar la información que tenemos para analizar las pruebas de sí mismo.
• Iniciar acciones correctivas: Por ejemplo, apretar los criterios de salida para los
defectos fijos, pedir más esfuerzo para ser puesto en la depuración o priorizar los
defectos de fijación bloqueadores de prueba.
• Tomar decisiones: Sobre la base de las medidas y la información recogida durante pruebas
y cualquier cambio en los riesgos de negocio y de proyecto o nuestra aumentado bajo pie de
riesgos técnicos y de productos, vamos a hacer decisiones o permitir que otros para tomar
decisiones: para continuar con las pruebas, para detener la prueba, para liberar el
software o para retenerlo para el trabajo posterior, por ejemplo.
1.4.3 Análisis de un ensayo y diseño

Análisis y diseño de la prueba es la actividad en la que los objetivos generales de ensayo se
transforman formado en las condiciones de prueba tangibles y diseños de prueba. Durante el
análisis de prueba y diseño, tomamos objetivos de las pruebas generales identificados durante
la planificación y construcción diseños de prueba y los procedimientos de prueba
(scripts). Vas a ver cómo hacer esto en el capítulo 4. Análisis y diseño de prueba tiene las
siguientes tareas principales, aproximadamente en el siguiente orden:
• Revisar la base de pruebas (tales como el análisis de riesgo del producto, requisitos,
arquitectura, especificaciones de diseño e interfaces), el examen de las especificaciones
para el software que estamos probando. Usamos la base de pruebas para ayudarnos a
construir nuestras pruebas. Podemos empezar a diseñar ciertos tipos de pruebas
(llamadas pruebas de recuadro negro) antes de que exista el código, ya que podemos
utilizar los documentos base de pruebas para entender lo que el sistema debe hacer una vez
construido. A medida que estudiamos la base de pruebas, que a menudo identificar las
lagunas y ambigüedades en las especificaciones, ya que estamos tratando de identificar con
precisión lo que sucede en cada punto del sistema, y esto también impide defectos que
aparecen en el código.
• Identificar las condiciones de ensayo basado en el análisis de los elementos de prueba,
sus especificaciones, y lo que sabemos acerca de su comportamiento y estructura. Esto
nos da una lista de lo que estamos interesados en la prueba. Si volvemos a nuestra forma
de conducir ejemplo, el examinador podría tener una lista de condiciones de prueba que
incluye 'comportamiento en los cruces "," uso de indicadores "," capacidad de maniobra del
coche, etc. En las pruebas, usamos las técnicas de prueba para ayudarnos a definir las
condiciones de prueba. De esto podemos empezar a identificar el tipo de datos de prueba
genérica que podría necesitar.
• Diseñar las pruebas (verá cómo hacer esto en el capítulo 4), utilizando técnicas de ayudar
a seleccionar las pruebas representativas que se refieren a aspectos particulares de la suave
Artículos de los cuales conllevan riesgos o que son de particular interés, en base a la prueba
condiciones y entrar en más detalles. Por ejemplo, el examinador podría mirar a una lista de
condiciones de prueba y decidir que necesitan uniones incluir uniones en T, cruce de caminos
y así sucesivamente. En las pruebas, vamos a definir la prueba de casos de prueba y
procedimientos.
• Evaluar la capacidad de prueba de los requisitos y del sistema. Los requisitos pueden
ser escritos de una manera que permite un tester para diseñar pruebas; por ejemplo, si el
rendimiento del software es importante, que debe especificarse en un comprobable
camino. Si los requisitos sólo dicen 'el software necesita para responder con rapidez
suficiente "que no es comprobable, ya que" lo suficientemente rápido "puede significar
diferentes cosas para diferentes personas. Uno de los requisitos más comprobable sería 'el
software tiene que responder dentro de 5 segundos con 20 personas se conectaron’. La
capacidad de prueba del sistema depende de aspectos tales como si es posible establecer
el sistema en un ambiente que coincide con el entorno operativo y si todas las formas en
que el sistema se puede configurar y utilizar puede ser entendido y probado. Por
ejemplo, si se prueba un sitio web, puede que no sea posible identificar y volver a crear
todas las configuraciones de hardware, sistema operativo, navegador, conexión,
cortafuegos y otros factores que el sitio web encuentra.
• Diseñar el entorno de configuración de prueba e identificar cualquier infraestructura

necesaria y herramientas. Esto incluye herramientas de prueba (véase el Capítulo 6) y
herramientas de apoyo tales como hojas de cálculo, procesadores de texto, herramientas de
planificación de proyectos y herramientas que no son de TI y el equipo - todo lo que necesita
para llevar a cabo nuestro trabajo.
1.4.4 Prueba de la aplicación y ejecución

Durante la implementación y ejecución de pruebas, tomamos las condiciones de prueba
y las convertirlos en los casos de prueba, mecanismos de prueba y configurar el entorno
de prueba. Esta significa que, después de haber reunido un alto nivel de diseño para nuestras
pruebas, que ahora empezamos a construirlas. Transformamos nuestras condiciones de
prueba en los casos de prueba y procedimientos, otros mecanismos de prueba
(testware), tales como secuencias de comandos para la automatización. También
tenemos que establecer un ambiente donde vamos a ejecutar las pruebas y construir
nuestros datos de prueba. La creación de ambiente y datos a menudo implica mucho
tiempo y esfuerzo, por lo que debe planificar y vigilar cuidadosamente este
trabajo. Prueba de la aplicación y la ejecución tienen la las siguientes tareas principales,
aproximadamente en el siguiente orden:
• Implementación:
- Desarrollar y dar prioridad a los casos de prueba, utilizando las técnicas que verá en
el capítulo 4, y crear datos de prueba para dichas pruebas. También vamos a escribir
instrucciones para llevar a cabo las pruebas de ensayo (procedimientos). Para el examinador
esto podría significar cambiar la condición de prueba a tomar la ruta hacia abajo Mayfield
Road hasta el cruce con Camino verde y pedir al conductor que gire a la izquierda en la
carretera y luego a la derecha en verde, camino, esperando que el controlador comprueba
espejos, señales y maniobras correctamente, sin dejar de ser conscientes de otros usuarios de
la carretera. "Es posible que tengamos para automatizar algunas pruebas utilizando la prueba
arneses y scripts de prueba automatizados. Vamos a hablar de la automatización más en el
capítulo 6.
- Crear conjuntos de pruebas de los casos de prueba para la eficiente ejecución de la

prueba. Una prueba Suite es una colección lógica de casos de prueba que, naturalmente,
trabajan juntos. Conjuntos de pruebas a menudo comparten datos y un conjunto de alto
nivel común de objetivos. También vamos a establecer un calendario de ejecución de la
prueba.
- Implementar y verificar el medio ambiente. Nos aseguramos de que el entorno de la

prueba se ha configurado correctamente, posiblemente, incluso la realización de pruebas
específicas en eso.
• Ejecución:
- Ejecutar los bancos de pruebas y casos de prueba individuales, siguiendo nuestra
prueba de procedimientos. Podríamos hacerlo manualmente o mediante el uso de
herramientas de ejecución de prueba, de acuerdo a la secuencia planificada.
- Registrar el resultado de la ejecución de la prueba y registrar las identidades y las

versiones del software bajo prueba, herramientas de prueba y testware. Hay que saber
exactamente ¿Qué pruebas que utilizamos contra qué versión del software; debemos
informar defectos en contra de las versiones específicas; y el registro de la
prueba mantenemos proporciona una pista de auditoría.
- Comparar los resultados reales (lo que pasó cuando nos encontramos con las pruebas)
con Resultados esperados (lo que anticipamos que ocurriría).
- Cuando existan diferencias entre los resultados reales y esperados, discrepancias
informe como incidentes. Se analizan para reunir más detalles sobre el defecto, reportan
información adicional sobre el problema, identificar las causas de los defectos, y diferenciar
entre problemas en el software y otros productos sometidos a prueba y cualquier defectos en
los datos de ensayos, en los documentos de prueba, o errores en la forma en que se ejecuta la
prueba. Nos gustaría registrar este último con el fin de mejorar la prueba en sí.
- Repetir las actividades de prueba, como resultado de las medidas adoptadas para cada
discrepancia. Nosotros debemos volver a ejecutar las pruebas que previamente había
fracasado con el fin de confirmar una solución (pruebas de confirmación o repetición de
pruebas). Ejecutamos pruebas y suites corregido si había defectos en nuestras
pruebas. Ejecutamos las prueba corregida de software de nuevo para asegurarse de que el
defecto fue corregido correctamente (prueba de confirmación) y que los programadores
no introducen defectos en las áreas inalteradas del software y que la fijación de un
defecto no descubrió otros defectos (regresión pruebas).
1.4.5 La evaluación de los criterios de salida y presentación de informes

La evaluación de los criterios de salida es la actividad en la ejecución de la prueba se evalúa
con respecto los objetivos definidos. Esto debe hacerse para cada nivel de la prueba, como
para cada uno de nosotros necesita saber si hemos hecho las pruebas suficientes. Sobre la
base de nuestra evaluación de riesgos, vamos a tener criterios establecidos contra el cual
mediremos "suficiente". Estos criterios varían para cada proyecto y se conocen como
criterios de salida. Ellos nos dicen si nos puede declarar una actividad determinada o
pruebas de nivel completo. Podemos tener una mezcla de criterios de media o de
terminación (que nos hablan de casos de prueba que deben estar incluido, por ejemplo,
"el examen de manejo debe incluir una parada de emergencia" o "el software prueba debe
incluir una medición de la respuesta '), los criterios de aceptación (que decirnos ¿Cómo
sabemos si el software se aprueba o no global, por ejemplo, "sólo pasan el conductor si han
completado la parada de emergencia de forma correcta »o« sólo pasar el software para la
liberación si cumple con los requisitos de la lista de prioridad 1') y la salida del proceso
(criterios que nos dicen si hemos completado todas las tareas que tenemos que hacer, por
ejemplo, "el examinador / tester no ha terminado hasta que se han escrito y presentado el
final del informe de la prueba '). Criterios de salida se deben establecer y evaluar para cada
nivel de prueba.
La evaluación de los criterios de salida tiene las siguientes tareas principales:
• Compruebe los registros de las pruebas en contra de los criterios de salida

especificados en la planificación de controles: Buscamos ver lo que evidencia que tenemos
para los que se han ejecutado y verificado las pruebas, y qué defectos se han planteado, fijo,
la confirmación de la prueba, o se encuentran fuera en pie.
• Evaluar si se necesitan más pruebas o si los criterios de salida deben ser cambiado: Es
posible que tenga que hacer más pruebas si no hemos realizado todas las pruebas que
Diseñamos, o si nos damos cuenta de que no hemos llegado a la cobertura de lo que
esperábamos, o si los riesgos se han incrementado para el proyecto. Es posible que tenga que
cambiar los criterios de salida para bajarlos, si los riesgos de negocio y de proyecto se elevan
en importancia y el producto o riesgos técnicos caen en importancia. Tenga en cuenta que
este No es fácil de hacer y debe ser acordado con las partes interesadas. La prueba de
gestionar herramientas e instrumentos de cobertura de prueba que vamos a discutir en el
capítulo 6 nos ayuda con esta evaluación.
• Escribir un informe resumen de la prueba para las partes interesadas: No es suficiente

que los testers conozcan el resultado de la prueba. Todas las partes interesadas deben saber
qué las pruebas se ha hecho y el resultado de la prueba, con el fin de hacer decisiones
informadas sobre el software.
1.4.6 actividades de cierre de prueba

Durante las actividades de cierre de prueba, recogemos los datos de las actividades de
prueba completados a consolidar la experiencia, incluyendo la comprobación y
presentación mecanismos de pruebas (testware) y análisis hechos y números. Es posible
que tengamos que hacer esto cuando se entrega el software. Nosotros también podríamos
cerrar las pruebas por otras razones, como cuando no hemos reunido la información
necesaria de las pruebas, cuando se canceló el proyecto, cuando un particular, se logra hito,
o cuando se realiza una liberación o actualización de mantenimiento.
Prueba actividades de cierre incluyen las siguientes tareas principales:

• Comprobar que los entregables, efectivamente entregada y asegurar que todos informes
de incidentes se han resuelto a través de la reparación de defectos o aplazamiento. Por los
diferidos, es decir, aquellos que permanecen abiertas, que pueden solicitar un cambio en una
versión futura. Documentamos la aceptación o el rechazo del sistema de software.
• Finalización y archivo testware, tales como scripts, el entorno de prueba, y cualquier

otras infraestructuras de ensayo, para su posterior reutilización. Es importante volver
a utilizar lo que podamos de testware; vamos a inevitable llevar a cabo las pruebas de
mantenimiento, y ahorra tiempo y esfuerzo si nuestra testware se puede sacar de una
biblioteca de pruebas existentes. También nos permite comparar los resultados de las pruebas
entre versiones de software.
• Entregar testware a la organización de mantenimiento que apoyará el software y

realizar correcciones de errores o cambios de mantenimiento, para su uso en aire
pruebas de confirmación y pruebas de regresión. Este grupo puede ser separado del grupo
personas que construyen y ponen a prueba el software; El mantenimiento testers son uno de
los clientes de los testers de desarrollo; van a utilizar la biblioteca de pruebas.
• Evaluar cómo fue la prueba y analizar las lecciones aprendidas para futuros
proyectos. Esto podría incluir mejoras en los procesos para el ciclo de vida de desarrollo de
software en su conjunto y también la mejora de la prueba procesos. Si usted refleja en la
figura 1.3 una vez más, podemos utilizar los resultados de las pruebas a fijar objetivos de
mejora de críticas y pruebas con el objetivo de reducir el número de defectos en el
uso. Podemos fijarnos en el número de incidentes los cuales eran los problemas de
prueba, con el objetivo de mejorar la forma en que diseñamos, ejecutar y comprobar
nuestras pruebas o la gestión de los entornos de prueba y datos. Esto nos ayuda a tomar
nuestras pruebas más madura y rentable para la organización. Esto está documentado en un
informe resumen de la prueba o podría ser parte de un informe general de evaluación del
proyecto.
1.5 LA PSICOLOGÍA DE PRUEBAS

1 Hay que recordar que el éxito de la prueba se ve influenciada por factores
psicológicos: (KL)
• Objetivos claros;
• Un equilibrio de auto-prueba y las pruebas independientes;
• El reconocimiento de la comunicación cortés y comentarios sobre defectos.
2 Contrasta la mentalidad de un tester y el de un desarrollador. (K2)

En esta sección, vamos a discutir los diversos factores psicológicos que influyen pruebas y
su éxito. Estos incluyen objetivos claros para las pruebas, las funciones y el equilibrio de la
auto-prueba y las pruebas independientes, clara, atenta comunicación y retroalimentación
sobre los defectos. También vamos a contrastar la mentalidad de un tester y de un
desarrollador.
Encontrará un solo término del programa de estudios en esta sección, las pruebas
independientes, y el término del glosario, la independencia.
1.5.1 Las pruebas independientes - que es un tester?

La mentalidad que desea utilizar durante la prueba y revisión es diferente de la que
utilizamos durante el análisis o en desarrollo. Con esto queremos decir que, si estamos
construyendo algo, que estamos trabajando positivamente para resolver problemas en el
diseño y a realizar un producto que cumpla con alguna necesidad. Sin embargo, cuando nos
prueba o revisa una producto, estamos buscando defectos en el producto y por lo tanto
son críticos de la misma.
Supongamos que se va a cocinar una comida para entrar en una competición para los
cocineros.
Se selecciona el menú, recoger los ingredientes, cocinar la comida, poner la mesa, y servir la
comida. Si quieres ganar, lo hace cada tarea, así como puedas. Suponer en cambio usted es
uno de los jueces que evalúan las comidas de competencia. Tú examinar todo críticamente,
incluyendo el menú, los ingredientes, los métodos usado, manteniendo a las asignaciones de
tiempo y presupuesto, la elección de los ingredientes, el elegancia de la mesa y de la porción,
y el aspecto y el sabor de la comida.
Para diferenciar entre los chefs de competencia, te alabamos todo buen aspecto de sus
actuaciones sino que también tenga en cuenta todos los fallos y errores Todos lo que el chef
hizo.
Lo mismo sucede con las pruebas de software: la construcción del software requiere una
mentalidad diferente de las pruebas del software.
No queremos decir que un tester no puede ser un programador, o que un programador
no puede ser un tester, aunque a menudo son funciones separadas. De hecho,
programadores son testers, que ponen a prueba los componentes que se construyen y la
integración de los componentes en el sistema. El buen chef será tan crítica como los jueces
de la competición de su propia obra, con el fin de prevenir y corregir errores y los defectos
antes de que nadie se fija en ellos. Así, con el derecho de pensar, programadores pueden
probar su propio código; de hecho, los programadores ponen a prueba su propio código y
encontrar muchos problemas, resolverlos antes de que nadie más vea el código. Negocio
análisis y de marketing personal debe revisar sus propios requisitos. Sistema arquitectos
deben revisar sus propios diseños. Sin embargo, todos sabemos que es difícil para
encontrar nuestros propios errores. Por lo tanto, los analistas de negocios, personal de
marketing, arquitectos y programadores a menudo dependen de otros para ayudar a
probar su trabajo. Esta otra persona podría ser un analista compañero, diseñador o
desarrollador. Una persona que va a utilizar el software puede ayudar a probar la misma. Los
analistas de negocio que trabajaron en los requisitos y diseño pueden realizar algunas
pruebas. Probando los especialistas, testers profesionales, están a menudo en cuestión. De
hecho, los exámenes pueden implicar una sucesión de personas cada carga un nivel diferente
de la prueba. Esto permite que una prueba independiente del sistema.
Pronto nos ocuparemos de los puntos en el ciclo de vida del software de desarrollo donde las
pruebas se llevan a cabo en el capítulo 2. Usted verá que hay que varias etapas de revisión y
las pruebas se llevan a cabo durante todo el ciclo de vida y estos pueden ser independientes
opiniones y pruebas. Temprano en el ciclo de vida, opiniones de requisitos y el diseño de
documentos por alguien que no sea el autor ayuda a encontrar defectos antes de la
codificación Inicial y nos ayuda a construir el software adecuado. Después de la
codificación, el software puede ser probado de forma independiente. Este grado
de independencia evita el sesgo autor y es a menudo más eficaz en la búsqueda de defectos
y fallas.
Varios niveles de independencia pueden ser identificados, mencionadas anteriormente, desde

el más bajo el nivel de independencia de la más alta:
• Pruebas por parte de la persona que escribió el artículo bajo prueba;

• Pruebas de otra persona en el mismo equipo, como otro programador;
• Pruebas realizadas por una persona de un grupo organizativo diferente, como por
ejemplo un equipo de pruebas independientes;
• Pruebas diseñadas por una persona de una organización o empresa diferente, como
las pruebas de contratación externa o la certificación por un organismo externo.
Debemos tener en cuenta, sin embargo, que la independencia no es necesariamente el factor

importante en buenas pruebas. Los desarrolladores que saben cómo poner a prueba y quién
son, como buenos cocineros, autocrítico, tienen la ventaja de la familiaridad y el orgullo de
trabajo que viene con verdadero profesionalismo. Tales promotores pueden gestionar
eficientemente encontrar muchos defectos en su propio código. Algunos métodos
desarrollo de software insisten en el diseño de pruebas antes de empezar a programar
y ejecutar estas pruebas de forma continua a medida que cambian el código. Este
enfoque promueve principios pruebas y detección de defectos temprana, lo que es
rentable. Recuerde, independientes pruebas puede llevarse a cabo en cualquier nivel de
la prueba y la elección de la independencia depende del riesgo en el contexto particular.
1.5.2 ¿Por qué a veces no seguir adelante con el resto de ¿el equipo?
Así como la independencia, la separación de la función del papel tester y el desarrollador
también se hace para ayudar a los esfuerzos de enfoque y para proporcionar los beneficios de
la formación y los recursos de pruebas profesionales. En muchas organizaciones, las
primeras etapas de las pruebas se llevan a cabo por los desarrolladores e integradores
y etapas posteriores independientemente, ya sea por un grupo de prueba especialista o
por los clientes.
Sin embargo, esta separación puede conducir a problemas, así como ventajas. La ventaja de
la independencia y el enfoque se puede perder si la relación entre los equipos se deteriora,
como veremos.
Cada organización y cada proyecto tendrán sus propias metas y objetivos.

Las diferentes partes interesadas, tales como los clientes, el equipo de desarrollo y el
gerente de la organización, tendrán diferentes puntos de vista sobre la calidad y tienen
sus propios objetivos. Debido a que las personas y los proyectos son impulsados por
objetivos, la parte interesada con las vistas más fuertes o la mayor influencia sobre un grupo
definirá, consciente o inconscientemente, lo que esos objetivos son. Gente tienden a alinear
sus planes con estos objetivos. Por ejemplo, dependiendo de la objetivo, un tester podría
centrarse ya sea en la búsqueda de defectos o en lo que confirma que software
funciona. Pero si uno de los interesados es menos influyente en el proyecto, pero más
influyente en la entrega, puede haber un conflicto de opiniones acerca de si el las
pruebas han cumplido sus objetivos. Un gerente puede desear la confirmación de que
el funciona el software y que es "suficientemente buena" si esto es visto como una manera
de entregar tan rápido como sea posible. Otro gerente puede querer la prueba de
encontrar, ya que muchos defectos como sea posible antes de que el software se publique,
que tendrá más tiempo para hacer y requerirá tiempo para la fijación, repetición de pruebas
y pruebas de regresión. Si no hay indique claramente los objetivos y criterios de salida para
las pruebas de la cual todas las partes interesadas Han convenido, los argumentos pueden
surgir, durante la prueba o después de la liberación, acerca si la prueba "suficiente" se ha
hecho.
Muchos de nosotros nos resulta un reto para realmente disfrutar de la crítica de nuestro
trabajo. Nosotros por lo general creemos que hemos hecho todo lo posible para producir
trabajo (documentos, código, pruebas, lo que sea) que es correcta y completa. Así que cuando
alguien identifica demás un defecto, un error que hemos hecho, que podría tomar esto
personalmente y obtener molesto con la otra persona, sobre todo si estamos bajo la presión
del tiempo. Esto es el caso de directivos, el personal, los testers y desarrolladores. Todos
cometemos errores y nos a veces se molesta, molesta o deprimida cuando alguien les
señala. Asi que, cuando como testers se corre una prueba que (desde nuestro punto de vista)
es una buena prueba de que se encuentra defectos y fallos en el software, tenemos que tener
cuidado en cómo reaccionamos. Estamos satisfecho, por supuesto, ya que hemos encontrado
un insecto bueno! Pero cómo será el requisito analista, diseñador, desarrollador, director del
proyecto y el cliente reaccionar? Las personas que construyen productos pueden
reaccionar a la defensiva y percibir esta reportados defecto como una crítica personal
contra el producto y contra el autor. El director del proyecto puede ser molesto con todo
el mundo para sostener el proyecto. Los el cliente puede perder la confianza en el producto
porque puede ver los defectos.
Dado que las pruebas puede ser visto como una actividad destructiva, tenemos que tener
cuidado de informar sobre los defectos y fallos del modo más objetivo y cortésmente
como sea posible. Si los demás son para ver nuestro trabajo como constructiva en la gestión
de riesgos de los productos, necesitamos tener cuidado cuando estamos revisando y cuando
estamos probando:
• Comunicar los resultados en el producto de una manera neutral, hecho-centrado y sin
criticar a la persona que lo creó. Por ejemplo, escribir objetiva y fáctica informes de
incidentes y resultados de la revisión.
- No regodearse - usted no es perfecto, ya sea!
- No se culpe - los errores son, probablemente, por el grupo en lugar de una individual.
- De forma constructiva, crítica y discute el defecto y cómo se va a registrarlo.
• Explicar que al saber de esto ahora podemos trabajar alrededor de él o fijarlo por lo
que el sistema entregado es mejor para el cliente.
- Di lo que te gustó y lo que funcionó, así como lo que no funcionó.
- Mostrar lo que el riesgo es sinceramente - no todo es de alta prioridad.
- No se limite a ver el lado pesimista - alabar, así como la crítica.
- mostrar lo que los riesgos han descubierto y los beneficios de la revisión o prueba.
• Comience con la colaboración en lugar de batallas. Recordar a todos el objetivo común
de los sistemas de mejor calidad.
- Ser educado y servicial, colaborar con sus colegas.
- Trate de entender cómo la otra persona se siente y por qué reaccionan como ellas hacen.
- Confirmar que la otra persona ha entendido lo que ha dicho y viceversa.
- Explicar cómo la prueba o examen ayuda al autor - lo que está en él para él o ella.
- Ofrecer el trabajo para ser revisado, también.
Es nuestro trabajo como revisor y tester para proporcionar a todos con clara, objetiva
información y para ello vamos caza de errores, minería y defectos fracaso
fabricación. Las personas que van a hacer buenos los colaboradores y los testers tienen el
deseo y la capacidad de encontrar problemas, y esto es cierto si la prueba es su trabajo
principal o parte de su papel como desarrollador. Estas personas acumulan la experiencia
de los que los errores es probable que se hizo, y se caracterizan por su curiosidad, ojo
crítico y atención al detalle. Sin embargo, a menos que también tienen buena habilidades
interpersonales y de comunicación, la cortesía, la comprensión de los demás y una
buena actitud hacia nuestros compañeros, colegas, clientes, directivos y el resto del
equipo, vamos a fracasar como testers porque nadie nos escuchará.
El líder del tester y la prueba necesitan buenas habilidades interpersonales para comunicarse
información objetiva acerca de los defectos, el progreso y los riesgos de una manera
constructiva [Sidra de pera]. Para el autor del software o el documento, la información puede
desertar ayudan a mejorar sus habilidades, pero sólo si ésta se realiza de una manera que les
ayuda.
Un libro que le puede resultar interesante en este contexto es Seis sombreros para pensar [de
Bono]. No se trata de la prueba sino que describe una forma de comunicación diferente
información: hechos; nuestras emociones; pensamientos pesimistas y optimistas; y la
creación Ideas Active. Al revisar o las pruebas, tenemos que comunicar hechos
objetivamente, pero los otros tipos de información son útiles también: "Esto sucedió; esto es
lo que sentía por ella; esto es lo que era bueno; esto es lo que podría salir mal; aquí es una así
podríamos resolver el problema". Como parte del suministro de la evaluación de riesgos, que
puede ayudar a los gerentes y clientes a tomar decisiones basadas en el riesgo en base a el
costo y el tiempo de impacto de un defecto. Si probamos y encontramos un defecto que
costaría $ A 15 000 para fijar y prueba de repetición de la prueba / de regresión, es que vale
la fijación? Si se causaría un impacto en el negocio de $50.000 en el entorno directo del
cliente puede desear que fijo. Si se tiene un potencial impacto en el negocio de $10.000 pero
cualquier solución es difícil de hacer y que pueden tener efectos negativos en otros lugares,
puede ser mejor no fijar. proporcionando el equipo con la información sobre el defecto en
términos que encuentran útil, puede ayudarles a tomar la decisión correcta acerca de arreglar
o no la fijación del problemas. Generalmente se dice que los defectos encontrados durante
las pruebas y se fijaron ahorrará tiempo y dinero en el futuro y reducir los riesgos, por
lo que necesitamos para demostrar que es el caso con el fin para la prueba que se valora.
Para ayudarle a pensar acerca de la psicología de las pruebas, no es un ejercicio en el final
del capítulo, después de las preguntas del examen la práctica.
Repaso Capítulo
Vamos a repasar lo que ha aprendido en este capítulo.
De la Sección 1.1, ahora debería ser capaz de explicar por qué es necesaria la prueba y apoyar
esa explicación con ejemplos y pruebas. Usted debe ser capaz para dar ejemplos de las
consecuencias negativas de un defecto de software o error de las personas, las empresas y el
medio ambiente. Usted debe ser capaz de contrastar un defecto con sus síntomas. Usted debe
ser capaz de discutir las formas en que prueba encaja en y es compatible con una mayor
calidad. Usted debe conocer los términos del glosario error, defecto, el fracaso, culpa,
error, calidad, riesgo, software, pruebas y pruebas exhaustivas.
De la Sección 1.2, usted debe ahora sabe lo que es la prueba. Usted debe ser capaz recordar
los objetivos comunes de la prueba. Usted debe ser capaz de describir cómo las pruebas
puede encontrar defectos, dar confianza y la información y prevenir defectos. Usted debe ser
capaz de explicar los principios básicos de la comprobación, resumidos en la sección
1.3. Usted debe saber los términos del glosario de código, depuración (debugging),
desarrollo de software, requisitos, revisión, realización de pruebas selectivas, caso de
prueba, ensayo y objetivo de la prueba.
De la Sección 1.4, usted debe reconocer ahora el proceso de prueba fundamental, como
además de ser consciente de algunas otras formas relacionadas para modelar el proceso de
prueba. Tú debe ser capaz de recordar las principales actividades de pruebas relacionadas
con la planificación y probar control, análisis y diseño, implementación y ejecución, la
evaluación de criterios de salida y presentación de informes, y el cierre de prueba. Usted
debe conocer los términos del glosario pruebas de confirmación, los criterios de salida,
incidente, pruebas de regresión, pruebas bases, condiciones de ensayo, cobertura de las
pruebas, datos de prueba, ejecución de la prueba, la prueba registro, plan de pruebas,
la estrategia de ensayo, el informe resumen de la prueba y testware.
Por último, desde la Sección 1.5, ahora debería ser capaz de explicar la psicología de las
pruebas y cómo las personas influyen en el éxito la prueba. Usted debe recordar la
importancia de objetivos claros, la combinación adecuada de autodiagnóstico e
independiente pruebas y cortés, respetuosa comunicación entre los testers y otros en el equipo
del proyecto, en especial sobre los defectos. Usted debe ser capaz de explicar y contrastar la
mentalidad de los testers y programadores y por qué estas diferencias pueden dar lugar a
conflictos. Usted debe saber el glosario término independencia.
PREGUNTAS examen de la muestra

Pregunta 1 Una empresa ha adquirido recientemente una aplicación off-the-shelf para
automatizar su proceso de pago de facturas. Ahora planean para ejecutar una prueba de
aceptación en contra del paquete antes de la ponerlo en producción. Cuál de los siguientes
es su razón más probable para la prueba?
a. Para fomentar la confianza en la aplicación.
b. Para detectar errores en la aplicación.
c. Para reunir pruebas para una demanda.
d. Para capacitar a los usuarios.
Pregunta 2 Según el Glosario ISTQB, la palabra 'bug' es sinónimo de cuál de las ¿siguientes
palabras?
a. Incidente
b. Defecto
c. Error
d. Fallo
Pregunta 3 Según el Glosario ISTQB, una riesgo se refiere a cuál de las siguientes?
a. La retroalimentación negativa al tester.
b. Las consecuencias negativas que se producirán.
c. Las consecuencias negativas que podrían ocurrir.
d. consecuencias negativas para el objeto de prueba.
Pregunta 4 La garantía de que comience la prueba de diseño durante la fase de definición de

los requisitos es importante para permitir, cuál de los siguientes objetivos de la prueba?
a. La prevención de defectos en el sistema.
c. Encontrar defectos a través de pruebas dinámicas.
d. Obtener la confianza en el sistema.
e. Terminar el proyecto a tiempo.
Pregunta 5 Un equipo de prueba encuentra constantemente entre 90% y 95% de los defectos
presentes en el sistema bajo prueba. Mientras que el director de pruebas entiende que esta es
una buena defecto de detección de porcentaje de su equipo de pruebas y la industria, senior
gestión y ejecutivos siguen siendo decepcionados en el grupo de prueba, diciendo que los del
área del equipo de prueba demasiados errores. Dado que los usuarios son generalmente
contento con el sistema y que los fracasos que se han producido por lo general han sido de
bajo impacto, ¿cuál de los siguientes principios de prueba es más propensos a ayudar al
director de pruebas explicar a éstos gerentes y ejecutivos por qué algunos defectos son
probable que se pierda?
a. Las pruebas exhaustivas no es posible
b. agrupación defecto
c. Paradoja del pesticida
d. La ausencia de errores-falacia
Pregunta 6 Según el Glosario ISTQB, es necesario realizar pruebas de regresión con qué
propósito?
a. Para verificar el éxito de las acciones correctivas.
b. Para evitar una tarea de ser considerada incorrectamente completa.
c. Para asegurarse de que no se han introducido defectos mediante una modificación.
d. Para motivar mejor prueba de la unidad por el programador.
Pregunta 7 ¿Cuál de los siguientes es más importante para promover y mantener una buena
relación entre los testers y desarrolladores?
a. La comprensión de lo que los gerentes sobre el valor pruebas.
b. Al explicar los resultados de pruebas de forma neutra.
c. La identificación de potenciales clientes soluciones temporales para loco.
e. La promoción de software de mejor calidad siempre posible.
Pregunta 8 ¿Cuál de las siguientes afirmaciones es la mejor evaluación de cómo se aplican

los principios de prueba en todo el ciclo de vida de la prueba?
a. principios de prueba sólo afectan a la preparación para pruebas.
b. principios de prueba sólo afectan actividades de ejecución de pruebas.
c. principios de prueba afectan a las actividades de prueba de los primeros tales como la
revisión.
d. principios de prueba afectan las actividades a lo largo del ciclo de vida de prueba.
EJERCICIO: PRUEBA DE PSICOLOGÍA

Leer el correo electrónico a continuación, y ver lo que encuentre pistas para ayudarle a
identificar problemas en el escenario descrito.
Categorizar las pistas / problemas como:

• Posibles personas, la psicología y la actitud problemas;
• Los problemas de otros problemas, por ejemplo, posible gestión de pruebas y el papel, los
posibles problemas del producto.
¡Hola!
Bueno, casi me causó pánico hoy porque pensé que había encontrado un mega
SHOWSTOPPER en el sistema de comercio que estamos probando. El director de pruebas y
otros se el examen de las bases de datos que participan por primera vez en el servidor y luego
en la puerta de entrada que alimenta los clientes, comprobando los registros de actualización
de procesos que corrieron durante la noche, así como comprobación de los datos pasados al
cliente. Finalmente encontré el problema. Había hecho clic mal, en un archivo .bat cuando
se ejecuta un cliente y había corrido hasta el entorno de cliente erróneo.
Para entonces, el director de pruebas estaba listo para decir unas pocas palabras en mi oído,
especialmente en lo que a la gente de desarrollo habían comenzado a involucrarse y tienen
cero tolerancias a los errores cometidos por los testers. El único que salvaba era que me
encontré con el error y no uno de los desarrolladores.
Era, objetivamente, un error interesante. Al iniciar sesión en el servidor de prueba ambientes,
los paneles muestran siempre el medio ambiente al que están conectado. En nuestro caso
tenemos dos entornos de prueba y llamados Systest14 Systest15 y mis pruebas se
establecieron en Systest15. Para ejecutar los clientes, tenemos que ejecutar archivos .bat, ya
sea para un cliente de 14 o 15. Yo había comenzado dos clientes, es decir dos participantes
en el intercambio, por lo que podrían hacer un poco de comercio entre ellos.
Parece que empecé el primer Aceptar cliente en el entorno de 15 pero cuando empecé la en
segundo lugar, que accidentalmente movido el ratón una fracción por lo que corrió el archivo
.bat 14 que está próxima a él en la lista de archivos del Explorador. Para empeorar las cosas,
las pantallas de los clientes no muestran el medio ambiente al que está unido.
Al principio me sentí un poco estúpido haber causado mucha actividad agitada y
desperdiciado. En reflexión pensé que si yo, como persona razonablemente competente,
puede cometer un error como esto entonces algo está mal. En el lado del servidor cuando
inicio sesión en una prueba medio ambiente, tengo que introducir el nombre del entorno y se
ha demostrado en todos los paneles.
En el lado del cliente, corro un entorno de prueba de cliente mediante la selección de un
archivo .bat de una lista de muchos y tienen que asegurarse de que haga clic en el archivo
correcto. No hay ni una pantalla ni capacidad de determinar el entorno de cliente en el que
estoy trabajando.
Así que voy a registrar esto como una alta prioridad, o la tiradora, el error - el cliente no
muestra el medio ambiente. En términos reales, esto significa que un usuario real podría ser
conectado con el sistema de producción y creo que está conectado a un sistema de prueba y
arruinar el comercio. Sé que esto ocurrió una vez en el sistema de negociación de acciones,
cuando una comerciante introduce una carga de transacciones de prueba en el sistema de
producción por error y caos causado.
Como una adición a esta historia, un par de días más tarde uno de los testers encontró lo que
parecía ser otro sensacional Mega. Él y el director de pruebas pasaron tres horas arrastrándose
por todo el sistema antes de descubrir el "error". Un nuevo filtro tenía ha agregado al software
de cliente para filtrar las transacciones que se muestran en los paneles por mercado
geográfico. Desconocido para ellos, se establece en un valor predeterminado del mercado
alemán, mientras que pensaban que estaban en el mercado del Reino Unido. En
consecuencia, a primera vista, se Aparecieron había problemas fundamentales con la red de
autobuses y de la transacción mensaje de radiodifusión sistemas. Aparte de la cuestión que
deberían haber sido informado de este cambio, se planteó un problema similar al que había
experimentado, el sistema cliente no muestra el mercado en el que está operando.
Bueno - Me voy para otro día feliz en el ¡oficina! Todo lo mejor SOLUCIÓN DE
EJERCICIO
La gente, los problemas de la psicología y la actitud incluyen, por ejemplo:

• Las malas relaciones entre el equipo de prueba y el director de pruebas, y los testers
y desarrolladores, por ejemplo, "Por entonces, el director de pruebas estaba listo para decir
unas pocas palabras en mi oído, especialmente en lo que al desarrollo la gente había
empezado a involucrarse y tienen cero tolerancia por los errores cometidos por los testers. Lo
único salvador fue que encontré el error y no uno de los desarrolladores".
• El uso de un lenguaje emotivo, comprensible en las circunstancias pero no es adecuado
para los problemas de información, por ejemplo, 'Bueno, casi me causó pánico hoy porque
pensé que había encontrado una sensacional en el Mega sistema de comercio que están
poniendo a prueba, 'y' Como una adición a esta historia, un par de días más tarde uno de los
testers encontrado lo que parecía ser otro mega-sensacional. "
• Desconfianza inicial superar mediante un reexamen del problema si una persona puede
cometer este error, los demás será. "Al principio me sentí un poco estúpido haber causado
mucha actividad agitada y desperdiciado. En la reflexión pensé que si yo, como persona
razonablemente competente, puede cometer un error como éste entonces algo está mal'.
• El uso de sarcasmo comprensible... 'Bueno - me voy para otro día feliz en la oficina! "
Otros problemas incluyen la gestión de pruebas y problemas de conducta, por ejemplo:
• Gestión de la configuración y el control de la liberación - Un nuevo filtro se habían
añadido al software de cliente de transacciones de filtro que aparecen en los paneles por
mercado geográfico ».
• Gestión de Configuración, relaciones, comunicaciones aparte de la cuestión de que
deberían estar informados de este cambio....'
• ¿Tiene el director de pruebas comprendía muy bien su papel? "Él y el director de
pruebas pasó tres horas de rastreo todo el sistema antes de descubrir el "error", "y" El director
de pruebas y otros se involucraron el examen de las bases de datos".
Hay algunos problemas de productos, aunque no hay problemas de funcionalidad o
técnicos. No todos los problemas nos encontramos con que los testers son de funcionalidad
o problemas técnicos. Hay algunos problemas que no son funcionales, Específicamente, la
usabilidad que indican que un usuario real podría ser molestados o peor por este problema:
• "Yo tenía mis-clic en un archivo .bat ...'
• 'En términos reales, esto significa que un usuario real podría estar conectado al sistema de
producción y cree que esta conectado a un sistema de prueba y arruinar el comercio. Sé que
esto sucedió una vez... cuando un comerciante entró una carga de transacciones de prueba en
el sistema de producción por error y el caos causado."
• "Se planteó un problema similar al que había experimentado el sistema cliente no muestra
el mercado en la que usted está negociando'.
• "No hay ni una exhibición ni la capacidad de determinar el entorno de cliente en el que
estoy trabajando." Y 'Para empeorar las cosas, las pantallas de los clientes no muestran el
entorno al que está conectado.
• "Desconocido para ellos, se establece en un valor predeterminado del mercado alemán,
mientras que pensaban que estaban en el mercado del Reino Unido. "
Tenga en cuenta que vamos a volver a este ejercicio al final del capítulo 5, donde nos
ocupamos de escribir un buen reporte de incidente.
CAPITULO 2 Prueba de todo el software ciclo vital
testing no es una actividad aislada. Tiene su lugar dentro de un ciclo de vida de
desarrollo de software modelo y por lo tanto el ciclo de vida aplicado determinará en gran
medida cómo se organiza la prueba.
Hay muchas formas diferentes de pruebas. Debido a varias disciplinas, a menudo con
diferentes intereses, están involucrados en el ciclo de vida de desarrollo, es importante
entender claramente y definir los diversos niveles y tipos de prueba. Este capítulo trata
sobre el software más comúnmente aplicado los modelos de desarrollo, los niveles de prueba
y tipos de prueba. El mantenimiento puede ser visto como una instancia específica de un
proceso de desarrollo. El mantenimiento de manera influye en el proceso de la prueba, los
niveles y tipos y cómo prueba puede ser organizado se describe en la última sección de este
capítulo.
T
2.1 MODELOS DE DESARROLLO DE SOFTWARE
1 Comprender la relación entre desarrollo, actividades de prueba y productos de
trabajo en el ciclo de vida de desarrollo y ejemplos dar basan en proyecto y las
características del producto y el contexto. (K2)
2 Reconocer el hecho de que los modelos de desarrollo de software deben adaptarse al
contexto de las características del proyecto y del producto. (KL)
3 razones Recall para diferentes niveles de prueba y características de la buena las
pruebas en cualquier modelo de ciclo de vida. (KL)
El proceso de desarrollo adoptado por un proyecto dependerá de los objetivos y metas

del proyecto. Existen numerosos ciclos de vida de desarrollo que se han desarrollado con el
fin de lograr diferentes requeridos objetivos. Estos ciclos de vida van desde metodologías
ligeras y rápidas, donde el tiempo a mercado es de la esencia, a través de metodologías
totalmente controlados y documentados en los que la calidad y la fiabilidad son factores
clave. Cada uno de estos métodos tiene su lugar en el software moderno el proceso de
desarrollo más adecuado de desarrollo y deben ser aplicadas a cada proyecto. Los
modelos especifican las diversas etapas del proceso y el orden en el que se llevan a cabo.
El modelo de ciclo de vida que se adopte para un proyecto tendrá un gran impacto en
la prueba que se realiza fuera. Las pruebas no existe en forma aislada; actividades de
prueba están muy relacionadas con las actividades de desarrollo de software. Se definirá
el qué, dónde y cuándo de nuestra prueba planificada, pruebas de regresión influencia y
determinará en gran medida el que las técnicas de ensayo para su uso. La prueba se organiza
y debe ajustarse al ciclo de vida de desarrollo o no será capaz de entregar su
beneficio. Si el tiempo de mercado es el factor clave, a continuación, la prueba debe ser
rápido y eficiente. Si un totalmente documentado ciclo de vida del software de desarrollo,
con una pista de auditoría de las pruebas, es se requiere, la prueba debe estar plenamente
documentado.
En cada ciclo de vida de desarrollo, una parte de la prueba se centra en pruebas de
verificación y otra parte se centra en pruebas de validación. La verificación se refiere
con la evaluación de un producto de trabajo, componente o sistema para determinar si
cumple con los requisitos establecidos. De hecho, la verificación se centra en la pregunta
"¿Es lo por entregar construido de acuerdo a la especificación? '. La validación se
refiere a la evaluación de un producto de trabajo, componente o sistema para
determinar si cumple con lo que el usuario necesita y sus requisitos. La validación se
centra en la pregunta "¿Es el entregable justo para el propósito, por ejemplo, tampoco
proporciona una solución para el problema? '.
2.1.1 V-modelo
Antes de discutir el modelo en V, vamos a ver el modelo que había antes de él.
El modelo de cascada fue uno de los primeros modelos, que se establecerá. Tiene una
línea de tiempo natural, donde las tareas se ejecutan de manera
secuencial. Comenzamos en el parte superior de la cascada con un estudio de viabilidad y el
flujo a través de los distintos las tareas del proyecto acabado con aplicación en el entorno
real. Diseño fluye a través en el desarrollo, que a su vez desemboca en construcción, y
finalmente en prueba. Las pruebas tiende a ocurrir hacia el final del ciclo de vida del
proyecto por lo defectos se detectan cerca de la fecha de implantación en vivo. Con este
modelo se tiene sido difícil conseguir la regeneración pasa hacia atrás hasta la cascada y hay
dificultades si nos necesitan para llevar a cabo numerosas iteraciones para una fase particular.
El V-modelo fue desarrollado para abordar algunos de los problemas experimentados

utilizando el enfoque de cascada tradicional. Los defectos que se encontraron fueron
demasiado tarde en el ciclo de la vida, como las pruebas no participó hasta el final del
proyecto.
Las pruebas también añaden tiempo de espera debido a su implicación tarde. El modelo V
orientado en que la prueba debe comenzar lo más temprano posible en la vida ciclo,
que, como hemos visto en el capítulo 1, es uno de los principios fundamental de pruebas
estructurado. También muestra que la prueba no es sólo una ejecución basada en la
actividad. Hay una variedad de actividades que deben ser realizadas antes del final de
la fase de codificación. Estas actividades de prueba deben llevarse a cabo
en paralelo con las actividades de desarrollo, y los testers tienen que trabajar con los
desarrolladores y analistas de negocios para que puedan realizar estas actividades y
tareas y producir un conjunto de entregables de prueba. Los productos de trabajo
producidos por los desarrolladores y analistas de negocios durante el desarrollo son la
base de pruebas en uno o más niveles. Al comenzar el diseño de las pruebas temprano,
los defectos son a menudo encontrados en los documentos básicos de prueba. Una buena
práctica es tener testers involucrados aún más temprano, durante la revisión de los
documentos básicos (borrador) de prueba.
El V-modelo es un modelo que ilustra cómo las actividades de prueba (verificación y

validación) se pueden integrar en cada fase del ciclo de vida. Dentro el modelo en V, las
pruebas de validación se lleva a cabo especialmente durante las primeras etapas, por
ejemplo, la revisión de los requisitos de los usuarios, y al final del ciclo de vida, por
ejemplo, durante las pruebas de aceptación del usuario.
Aunque existen variantes del modelo en V, un tipo común de usos V-modelo cuatro niveles
de prueba.
Los cuatro niveles de prueba utilizados, cada uno con sus propios objetivos, son:
• Pruebas de los componentes: busca defectos en y verifica el funcionamiento de
componentes de software (por ejemplo, módulos, programas, objetos, clases, etc.) que se
comprobable por separado;
• Pruebas de integración: las interfaces entre los componentes de las pruebas, las
interacciones con diferentes partes de un sistema tal como un sistema operativo, el sistema
de archivos y hardware o interfaces entre los sistemas;
• Pruebas del sistema: se ocupa del comportamiento de todo el sistema / producto como
definido por el alcance de un proyecto de desarrollo o producto. El objetivo principal de las
pruebas del sistema es la verificación respecto a los requisitos especificados;
• Pruebas de aceptación: las pruebas de validación en relación con las necesidades del
usuario, requisitos y procesos de negocio llevadas a cabo para determinar si se debe o no
aceptar el sistema.
Los diferentes niveles de la prueba se explican y analizan en detalle en la sección 2.2.

En la práctica, un modelo en V puede tener más o menos diferentes niveles de desarrollo
y pruebas, dependiendo del proyecto y el producto de software. Por ejemplo, puede haber
pruebas de integración de componentes después de componente sistema de pruebas y pruebas
de integración después de las pruebas del sistema. Los niveles de prueba pueden ser
combinados o reorganizado en función de la naturaleza del proyecto o de la
arquitectura del sistema. Para la integración de un off-the-shelf (COTS) de software del
producto en un sistema, un comprador puede realizar sólo integración de pruebas a nivel del
sistema (por ejemplo, la integración de la infraestructura y otros sistemas) y en una prueba
de fase de recepción, más tarde.
Tenga en cuenta que los tipos de productos de trabajo mencionadas en la figura 2.2 en el lado
izquierdo de la V-modelo son sólo un ejemplo. En la práctica vienen diferentes nombres. Las
referencias de los productos genéricos de trabajo incluyen la capacidad Maturity Model
Integration (CMMI) o los "procesos del ciclo de vida del software 'de ISO / IEC 12207. El
CMMI es un marco para la mejora de procesos para ambos ingeniería de sistemas e ingeniería
de software. Proporciona una guía sobre dónde enfocar y cómo, con el fin de aumentar el
nivel de madurez de los procesos [Chrissis et ah, 2004]. ISO / IEC 12207 es un estándar de
proceso del ciclo de vida del software integrado que se está convirtiendo rápidamente más
popular.
2.1.2 ciclos de vida iterativos

No todos los ciclos de vida son secuenciales. También hay iterativo o incremental de
vida ciclos en los que, en lugar de una gran línea de tiempo de desarrollo de principio a fin,
que pasar por una serie de fases del ciclo de vida más pequeños autónomos para el
mismo proyecto. Al igual que con el modelo en V, hay muchas variantes de la vida iterativo
ciclos.
Una característica común de los enfoques iterativos es que la entrega se divide en

incrementos o construye con cada incremento de añadir nuevas funcionalidades. El
inicial Valor mínimo contendrá la infraestructura necesaria para apoyar la
construcción inicial funcionalidad. El incremento producido por una iteración puede
ser probado en varios los niveles como parte de su desarrollo. Los incrementos
subsiguientes necesitarán pruebas para la nueva funcionalidad, pruebas de regresión de la
funcionalidad existente, e integración de las pruebas existentes y nuevas piezas. Las pruebas
de regresión es cada vez más importante en todas las iteraciones después de la
primera. Esto significa que más pruebas se requiere en cada fase de su posterior entrega que
debe tenerse en cuenta en el los planes del proyecto. Este ciclo de vida puede dar presencia
en el mercado temprano con funcionalidad crítica, puede ser más fácil de manejar
debido a la carga de trabajo se divide en partes más pequeñas piezas, y pueden reducir
la inversión inicial aunque puede costar más en el largo correr. Además presencia en el
mercado a principios significará pruebas de validación se lleva a cabo a cada incremento,
dando así respuesta temprana en el valor del negocio e idoneidad para el uso del producto.
Ejemplos de iterativos o modelos de desarrollo incrementales son prototipos, Desarrollo

rápido de aplicaciones (RAD), Rational Unified Process (RUP) y desarrollo ágil. Con el fin
de comprender mejor desarrollo iterativo Ment modelos y el papel cambiante de probar una
breve explicación de ambos RAD y se proporciona el desarrollo ágil.
Desarrollo rápido de aplicaciones

Desarrollo rápido de aplicaciones (RAD) es formalmente un desarrollo paralelo de funciones
y posterior integración.
Componentes / funciones se desarrollan en paralelo como si fueran mini proyectos, los
desarrollos son encajadas en tiempo, entregado, y después montarlo en una prototipo
de trabajo. Esto puede dar muy rápidamente al cliente algo para ver y utilizar y ofrecer
información relacionada con la entrega y sus requisitos.
El rápido cambio y el desarrollo del producto son posible al uso de esta metodología. Sin
embargo tendrá que ser desarrollado para el pliego de condiciones producto en algún
momento, y el proyecto tendrá que ser colocado bajo más controles formales antes de entrar
en producción.
Esta metodología permite temprana validación de los riesgos de la tecnología y una respuesta
rápida a las cambiantes del cliente requisitos.
Metodología de Desarrollo de Sistema Dinámico [DSDM] es un RAD refinado, proceso

que permite tener un control de la puesta en marcha con el fin de detener el proceso
cuando se salgan de control. Recuerde que todavía tiene que tener los elementos esenciales
de buenas prácticas de desarrollo en su lugar a fin de que estas metodologías a
trabajo. Tenemos que mantener una estricta gestión de la configuración de los rápidos
cambios que estamos haciendo en una serie de ciclos de desarrollo paralelo.
Desde la perspectiva de las pruebas que necesitamos para planificar esto con mucho cuidado
y actualización nuestros planes regularmente como las cosas van a cambiar muy rápidamente
(véase el capítulo 5 para más en los planes de prueba).
El proceso de desarrollo RAD estimula la regeneración de cliente activo. El cliente obtiene

una visibilidad temprana del producto, puede proporcionar información sobre el diseño y se
puede decidir, basándose en la funcionalidad existente, ya sea para proceder con el desarrollo,
lo que la funcionalidad para incluir en la próxima ciclo de entrega o incluso para detener el
proyecto si no está entregando la espera valor. Una solución centrada en el negocio temprano
en el mercado da un temprano retorno de la inversión (ROI) y puede proporcionar
información valiosa de la comercialización para el negocio. Validación con el proceso de
desarrollo RAD es así una la actividad temprana y mayor.
Desarrollo ágil
Extreme Programming (XP) es actualmente uno de los ágiles más conocida Los modelos del
ciclo de vida de desarrollo. (Véase [ágil] para las ideas detrás de este enfoque.)
La metodología pretende ser más humana de usar que los métodos de desarrollo del ambiente
tradicional. Algunas características de XP son:
• Promueve la generación de historias de negocios para definir la funcionalidad.
• Exige un cliente in situ de retroalimentación continua y para definir y llevar a cabo
las pruebas de aceptación funcional.
• Promueve la programación en parejas y la propiedad de código compartido entre
desarrolladores.
• Se establece que los scripts de prueba de componentes deberán ser escritos antes de
que el código es escritos y que esas pruebas deben ser automatizados.
• Afirma que la integración y las pruebas del código deberán ocurrir varias veces un
día.
• Afirma que se ha puesto en práctica la solución más sencilla para satisfacer hoy
problemas.
Con XP hay numerosas iteraciones de cada prueba que requiere. Desarrolladores XP para
escribir todos los casos de prueba que se les ocurra y automatizarlos. Cada vez que un
cambio se realiza en el código se prueba componente y luego integrado con el código
existente, que luego es totalmente integración a prueba utilizando el conjunto completo
de pruebas casos. Esto le da a la integración continua, por lo que entendemos que los
cambios son incorporados de forma continua en la compilación de software. Al mismo
tiempo, toda la prueba casos deben ejecutar al 100% lo que significa que todos los casos
de prueba que han sido identificado y automatizado se ejecutan y aprobar. XP no se
trata de hacer extrema actividades durante el proceso de desarrollo, se trata de hacer conocido
el valor añadido actividades de una manera extrema.
2.1.3 pruebas dentro de un modelo de ciclo de vida

En resumen, lo que se está utilizando modelo de ciclo de vida, hay varias características de
buena prueba:
• Para cada actividad de desarrollo hay una actividad pruebas correspondientes;
• Cada nivel de prueba tiene objetivos específicos de prueba a ese nivel;
• El análisis y diseño de pruebas para un nivel dado de ensayo deberían comenzar
durante la actividad de desarrollo correspondiente;
• Testers deben participar en la revisión de documentos tan pronto como borradores
están disponibles en el ciclo de desarrollo.
2.2 NIVELES DE PRUEBA

1 Comparación de los diferentes niveles de comprobación: principales objetivos, objetos
típicos de las pruebas, los objetivos típicos de las pruebas (por ejemplo, funcional o
estructural) y productos de trabajo relacionados, las personas que dan, los tipos de
defectos y fallas a ser identificado. (K2)
El V-modelo para la prueba se introdujo en la Sección 2.1. En esta sección se ve en más

detalle en los distintos niveles de prueba. Las características clave para cada nivel de prueba
se discuten y definen para ser capaz de separar más claramente las diversas pruebas los
niveles. Una comprensión profunda y la definición de los distintos niveles de la prueba se
identificar las áreas que faltan y evitar el solapamiento y la repetición. A veces podemos
desear introducir solapamiento deliberado para hacer frente a riesgos
específicos. Comprensión si queremos que se superpone y la eliminación de las brechas hará
que los niveles de ensayo más complementaria lo que conduce a la prueba más eficaz y
eficiente.
2.2.1 Pruebas de componentes
Pruebas de componentes, también conocido como unidad, módulo y programa de

pruebas, el objetivo es la búsquedas de defectos, y verifica el funcionamiento del
software (por ejemplo, módulos, programas, objetos, clases, etc.) que son comprobables por
separado.
Pruebas de componentes se puede realizar en aislamiento del resto del sistema de
dependencia en el contexto del ciclo de vida de desarrollo y el sistema. Lo más a
menudo stubs y drivers se usan para reemplazar el software que falta y simular la interfaz
entre los componentes de software de una manera simple. Un talón se llama desde el
componente de software a probar; un controlador llama a un componente a ensayar (ver
Figura 2.5).
Pruebas de componentes puede incluir pruebas de funcionalidad y no específica

características funcionales, tales como recursos en el comportamiento (por ejemplo,
pérdidas de memoria), per-rendimiento o la comprobación de la solidez, así como pruebas
estructurales (por ejemplo, la decisión cobertura). Los casos de prueba se derivan de los
productos de trabajo, tales como el software diseño o el modelo de datos.
Típicamente, la prueba de componentes se produce con el acceso al código siendo probado
y con el apoyo del entorno de desarrollo, tales como un marco de pruebas unitarias trabajar
o una herramienta de depuración, y en la práctica por lo general implica el programador que
escribió el código. A veces, dependiendo del nivel aplicable de riesgo, componente pruebas
se lleva a cabo por un programador diferente introduciendo de este modo independencia. Los
defectos se fijan típicamente tan pronto como se encuentran, sin registro oficial de los
incidentes que se encuentran.
Un enfoque en las pruebas de componentes, que se utiliza en la programación extrema
(XP), es para preparar y automatizar casos de prueba antes de la codificación. Esto se
llama una prueba de primera planteamiento o desarrollo basado en pruebas. Este enfoque
es muy iterativo y es basado en los ciclos de desarrollo de casos de prueba, a continuación,
la construcción y la integración de pequeños piezas de código, y la ejecución de las pruebas
de componentes hasta que pasan.
2.2.2 Las pruebas de integración
Pruebas de integración Pruebas de interfaces entre componentes, interacciones de

diferentes partes de un sistema tal como un sistema operativo, sistema de archivos y
hardware cerámica o interfaces entre sistemas. Tenga en cuenta que las pruebas de
integración deben ser diferenciadas de otras actividades de integración. Las pruebas de
integración son a menudo llevadas a cabo por el integrador, pero preferiblemente por un
tester de integración específica o equipo de pruebas.
Puede haber más de un nivel de pruebas de integración y que puede haber llevado a
cabo sobre los objetos de prueba de tamaño variable. Por ejemplo:
• Pruebas de integración de componentes pone a prueba la interacción entre el software
de componentes y se lleva a cabo después de la prueba de componentes;
• Pruebas de integración de sistemas a prueba las interacciones entre diferentes sistemas
y puede hacerse después de las pruebas del sistema. En este caso, el desarrollo de
Organización puede controlar sólo un lado de la interfaz, por lo que los cambios pueden ser
desestabilizador. Los procesos de negocio implementados como flujos de trabajo pueden
implicar una serie de sistemas que puede incluso funcionar en diferentes plataformas.
Cuanto mayor sea el alcance de la integración, más difícil se hace para aislar fracasos
a una interfaz específica, que puede conducir a un mayor riesgo. Esto lleva en diversos
enfoques para las pruebas de integración. Un extremo es que todos los componentes o
sistemas están integrados al mismo tiempo, después de lo cual todo lo que se pone a
prueba como un todo. Esto se llama 'big-bang' pruebas de integración. Pruebas de big-
bang tiene la ventaja de que todo esté terminado antes del comienzo de las pruebas de
integración. Ahí esta no hay necesidad de simular (aún sin terminar) partes. La principal
desventaja es que en general, es mucho tiempo y es difícil de encontrar la causa de los
fallos con este la integración tardía. Por lo tanto la integración del big-bang puede parecer
una buena idea en la planificación del proyecto, siendo optimista y esperando encontrar
ningún problema. Si uno piensa pruebas de integración encontrará defectos, es una buena
práctica considerar si el tiempo se salve por romper el proceso de pruebas de integración.
Otro extremo es que todos los programas están integrados uno a uno, y una prueba es llevado
a cabo después de cada paso (prueba incremental). Entre estos dos extremos, hay una gama
de variantes. El enfoque incremental tiene la ventaja de que los defectos se encuentran
al principio de un conjunto más pequeño cuando es relativamente fácil detectar la
causa. Una desventaja es que puede llevar mucho tiempo ya que los stabus y los drivers
tienen que ser desarrollado y utilizado en la prueba. Dentro de integración creciente se
debe ir probando una gama de posibilidades de existir, en parte, en función del sistema
arquitectura:
• De arriba hacia abajo: la prueba se lleva a cabo, de arriba a abajo, siguiendo el flujo
de control o estructura arquitectónica (por ejemplo, a partir de la interfaz gráfica de
usuario o en el menú principal). Componentes o sistemas son sustituidos por los talones
(stubs).
• De abajo hacia arriba: la prueba se lleva a cabo desde la parte inferior del mando a
fluir hacia arriba. Componentes o sistemas son sustituidos por los conductores(drivers).
• Funcional incrementales: la integración y las pruebas se lleva a cabo sobre la base de
las funciones o funcionalidades, como se documenta en la especificación funcional.
La secuencia de integración preferida y el número de pasos de integración requerida
dependerá de la ubicación en la arquitectura de las interfaces de alto riesgo.
La mejor opción es comenzar con la integración de las interfaces que se espera causa más
problemas. Hacer esto impide que los principales defectos en el extremo de la integración
fase de prueba. Con el fin de reducir el riesgo de descubrimiento defecto tarde,
integración debe normalmente ser incrementales en lugar de 'big-bang'. Lo ideal sería
que los testers deben entender la planificación de la arquitectura y la influencia de
integración. Si integración pruebas están previstas antes de construir componentes o
sistemas, pueden ser desarrollado en el orden requerido para las pruebas más eficiente.
En cada etapa de la integración, los testers se concentran únicamente en la integración en sí
mismo. Por ejemplo, si se están integrando el componente A con el componente B se
están interesados en probar la comunicación entre los componentes, no el funcionalidad
de cualquiera de ellos. Ambos enfoques funcionales y estructurales pueden estar usado. Las
pruebas de concreto características no funcionales (por ejemplo, el rendimiento) puede
también deben incluirse en las pruebas de integración. Las pruebas de integración se puede
llevar a cabo por los desarrolladores, pero se puede hacer por un equipo independiente de la
integración especialista testers, o por un grupo especializado de desarrolladores / integradores
incluyendo especialistas no-funcional.
2.2.3 Sistema de prueba
Las pruebas del sistema está relacionada con el comportamiento de todo el sistema /
producto como definido por el alcance de un proyecto de desarrollo o producto. Puede
incluir pruebas basado en los riesgos y / o especificación de requisitos, procesos de
negocio, casos de uso, u otras descripciones de alto nivel de comportamiento del sistema,
las interacciones con la operación del sistema, y los recursos del sistema. Las pruebas del
sistema es lo más a menudo en la prueba final nombre de desarrollo para verificar que el
sistema para ser entregado encuentra con la especificación y su finalidad pueden ser encontrar
tantos defectos como sea posible. Más a menudo se lleva a cabo por los testers especializados
que formen un dedicado, y, a veces un independiente, equipo de pruebas dentro del
desarrollo, que depende del gerente de desarrollo o el director del proyecto. En algunas
organizaciones las pruebas del sistema se lleva a cabo por una tercer equipo parte o por
los analistas de negocios. Una vez más el nivel necesario de independencia está en función
del nivel de riesgo aplicable y esto tendrá una alta influencia en las pruebas del sistema se
organiza manera.
Las pruebas del sistema debe investigar tanto funcionales y no funcionales

requisitos del sistema. Pruebas no funcionales típicas incluyen el rendimiento y
fiabilidad. Testers también pueden necesitar para hacer frente a incompleta o indocumentado
requisitos. Las pruebas del sistema de requisitos funcionales se inicia mediante el uso de
la (caja negro) técnicas basadas en las especificaciones apropiadas para el aspecto del
sistema a prueba. Por ejemplo, una tabla de decisión puede ser creada para
combinaciones de efectos que se describen en las reglas de negocio. Basado en la
estructura (caja blanca) técnicas también pueden utilizarse para evaluar la minuciosidad de
los elementos de prueba tales como la estructura de diálogo o menú de navegación página
web (véase el capítulo 4 para más información sobre la diversos tipos de la técnica).
Las pruebas del sistema requiere un entorno de prueba controlado con respecto a, entre
otras cosas, el control de las versiones de software, y la prueba testware datos (véase el
Capítulo 5 para más información sobre la gestión de configuración). Una prueba del sistema
es ejecutado por la organización de desarrollo en un (debidamente controlada) entorno
ambiente. El entorno de prueba debe corresponder a la diana o la producción final
entorno tanto como sea posible con el fin de minimizar el riesgo de medio ambiente- fallas
específicas no se encontraron por medio de pruebas.
2.2.4 Las pruebas de aceptación

Cuando la organización de desarrollo ha realizado su prueba del sistema y tiene la
correlación de todos o la mayoría de los defectos, el sistema será entregada al usuario o
cliente para. La prueba de aceptación
La prueba de aceptación debe responder a preguntas como:

"¿Puede ser puesto en libertad el sistema?", "¿Qué, si los hay, son la circulación (de
negocios) riesgos? ' y '¿Ha cumplido con sus obligaciones de desarrollo?'. Las pruebas
de aceptación es más a menudo la responsabilidad del usuario o cliente, aunque otras
partes interesadas pueden estar involucrados también. La ejecución de la prueba de
aceptación requiere una prueba ambiente que es para la mayoría de los aspectos,
representativa de la producción ambiental ( "como si la producción ').
El objetivo de las pruebas de aceptación es establecer la confianza en el sistema, parte

del sistema o características no funcionales específicos, por ejemplo la facilidad de uso,
del sistema. Las pruebas de aceptación más a menudo se centran en un tipo de
validación de las pruebas, por lo que estamos tratando de determinar si el sistema es
adecuado para el propósito.
Encontrar defectos no debe ser el foco principal de las pruebas de aceptación. A pesar
de esto evalúa la disposición del sistema para el despliegue y uso, no es necesariamente
el nivel final de la prueba. Por ejemplo, una prueba de integración de sistemas a gran escala
puede vendrá después de la aceptación de un sistema.
Las pruebas de aceptación pueden ocurrir en más de un solo nivel, por ejemplo:
• Un Comercial Off El producto de software (COTS) puede ser de aceptación probado
cuando se instala o integrado.
• Las pruebas de aceptación de la usabilidad de un componente puede hacerse durante
comprueba componente.
• Las pruebas de aceptación de una nueva mejora funcional puede venir antes las
pruebas del sistema.
Dentro de la prueba de aceptación para un sistema de negocio de apoyo, dos principal prueba
tipos se pueden distinguir; como resultado de su carácter especial, son generalmente
preparado y ejecutado por separado. La prueba de aceptación del usuario se centra
principalmente en la funcionalidad validando así la aptitud para el uso del sistema por
parte del usuario de negocios, mientras que la prueba de aceptación operativa (también
llamada la producción de prueba de aceptación) valida si el sistema se encuentra con el los
requisitos para el funcionamiento. La prueba de aceptación del usuario se realiza por
la los usuarios y los administradores de la aplicación. En cuanto a la planificación, la
aceptación de los usuarios prueba usualmente vincula estrechamente a la prueba del
sistema y, en muchos casos, ser organizada y se superpone en el tiempo. Si el sistema a
ser probado consiste en un número de subsistemas más o menos independientes, la prueba de
aceptación para una subsistema que cumple con los criterios de salida de la prueba del sistema
puede comenzar mientras otro subsistema puede estar todavía en la fase de prueba del
sistema. En la mayor organización, la administración del sistema llevará a cabo la prueba de
aceptación operativa poco antes de que el sistema se libera. La prueba de aceptación
operacional puede incluir la prueba de copia de seguridad / restauración, recuperación
de desastres, las tareas de mantenimiento y comprobación periódica de
vulnerabilidades de seguridad.
Otros tipos de pruebas de aceptación que existen son las pruebas de aceptación del
contrato y pruebas de aceptación del cumplimiento. Se realiza la prueba de aceptación
del contrato en contra de los criterios de aceptación de un contrato para la producción
de encargo desarrollado. La aceptación debe estar formalmente definida cuando se
acordó el contrato.
Se realizaron pruebas de aceptación cumplimiento o pruebas de aceptación regulación
en contra de las normas que se deben cumplir, como gubernamental, jurídica o las
normas de seguridad.
Si el sistema ha sido desarrollado para el mercado de masas, por ejemplo off comercial
software de la plataforma (COTS), luego las pruebas para usuarios individuales o clientes se
práctico o incluso posible en algunos casos. Feedback se necesitaba de potencial usuarios en
su mercado existente antes de que el producto de software es puesto out en venta
comercialmente. Muy a menudo este tipo de sistema se somete a dos etapas de aceptación
prueba. El primero se llama alfa de prueba. Esta prueba se lleva a cabo en el desarrollo
en el sitio de operaciones. Una sección transversal de los usuarios potenciales y los
miembros de la promotora de organización están invitados a utilizar el sistema. Los
desarrolladores observan los usuarios y en cuenta problemas. Las pruebas alfa también se
puede llevar a cabo por una prueba independiente equipo. Pruebas beta, o pruebas de
campo, envía el sistema a una sección transversal de los usuarios que instalarlo y utilizarlo
en condiciones de trabajo del mundo real. Los usuarios envían registros de incidentes
con el sistema de la organización de desarrollo, donde los defectos se reparan.
Tenga en cuenta que las organizaciones pueden utilizar otros términos, tales como la
recepción en fábrica verificación y conformidad de laboratorio de ensayo para los sistemas
que se ponen a prueba antes y después siendo trasladado a las instalaciones del cliente.
2.3 Tipos de pruebas: LOS OBJETIVOS DE LA VERIFICACIÓN
1 Compare cuatro tipos de prueba de software (funcionales, no funcionales, Estructural

y cambiar relacionados con) por ejemplo. (K2)
2 Reconocer que las pruebas funcionales y estructurales se producen en cualquier nivel
de prueba. (KL)
3 Identificación y descripción de los tipos de pruebas no funcionales basados en la no
Funcional requisitos. (K2)
4 Identificación y descripción de los tipos de pruebas basadas en el análisis de una
Software estructura o arquitectura del sistema. (K2)
5 Describir el propósito de las pruebas de confirmación y pruebas de regresión. (K2)
Los tipos de prueba se introducen como un medio para definir con claridad el objetivo
de un cierto nivel de prueba para un programa o proyecto. Tenemos que pensar diferente
tipos de pruebas, ya probar la funcionalidad del componente o sistema puede no ser suficiente
en cada nivel para cumplir con los objetivos generales de la prueba.
Enfoque de la prueba en un objetivo de la prueba específica y, por lo tanto, la selección
del tipo apropiado de prueba ayuda a preparar y comunicar decisiones en contra
objetivos de la prueba más fácil.
Un tipo de prueba se centra en un objetivo de la prueba particular, el cual podría ser la

prueba de una función que se lleva a cabo por el componente o sistema; una característica
de la calidad funcional, como la fiabilidad o la facilidad de uso; la estructura o la arquitectura
del componente o sistema; o relacionados con los cambios, es decir, reafirmante que los
defectos han sido corregidos (prueba de confirmación, o volver a la prueba) y en busca de
cambios no deseados (pruebas de regresión). En función de su objetividad, las pruebas se
organizarán de manera diferente. Por ejemplo, la prueba de componentes el objetivo de
rendimiento sería muy diferente a las pruebas de componentes dirigida a lograr la cobertura
decisión.
2.3.1 Pruebas de la función (pruebas funcionales)

La función de un sistema (o componente) es 'lo que hace'. Esto es típicamente se
describe en una especificación de requisitos, una especificación funcional, o en casos de
uso. Puede haber algunas funciones que se "supone" que debe proporcionarse que no están
documentados que son también parte de la necesidad de un sistema, aunque es difícil de
probar en contra de los requisitos de indocumentados e implícitos.
Las pruebas funcionales se basan en esas funciones, que se describe en los documentos
o entendido por los testers y se puede realizar en todos los niveles de la prueba (por
ejemplo, prueba de componentes pueden estar basados en una especificación de
componente).
Las pruebas funcionales considera el comportamiento especificado y es a menudo también
se refirió como las pruebas de caja negro. Esto no es del todo cierto, ya que las pruebas de
caja negro también incluye pruebas no funcionales (véase la Sección 2.3.2).
La función (o funciones) de pruebas pueden, en base a la norma ISO 9126, concentrarse
sobre la idoneidad, la interoperabilidad, la seguridad, precisión y
cumplimiento. Seguridad pruebas, por ejemplo, investiga las funciones (por ejemplo, un
firewall) en relación con detectores de amenazas, como virus, de los extraños maliciosos.
Las pruebas Funcionales pueden hacerse desde dos perspectivas: basada en requisitos
o basado en el proceso de negocio.
Pruebas basadas en requerimientos utiliza una especificación del requisito funcional
para el sistema como la base para el diseño de pruebas. Una buena manera de empezar es
utilizar la tabla de contenido de la especificación de requisitos como prueba inicial inventario
o lista de elementos para poner a prueba (o no para poner a prueba). También hay que dar
prioridad a las necesidades basadas en criterios de riesgo (si esto no se ha hecho ya en la
especificación) y usar esto para dar prioridad a las pruebas. Esto asegurará que el más
importante y las pruebas más importantes se incluyen en el esfuerzo de prueba.
Las pruebas basadas en procesos de negocio utiliza el conocimiento de los procesos de

negocio.
Los procesos de negocio se describen los escenarios involucrados en el negocio del día a
día uso del sistema. Por ejemplo, un sistema de personal y nómina puede tener un proceso
de negocio a lo largo de las líneas de: alguien se une a la compañía, él o ella es pagado en
una base regular, y él o ella finalmente sale de la empresa. Los casos de uso se originan de
desarrollo orientado a objetos, sino que son hoy en día muy popular en muchos ambientes
del desarrollo del ciclo de vida. También toman los procesos de negocio como punto de
partida, a pesar de que parten de tareas a realizar por los usuarios. Los casos de uso
son una base útil para casos de prueba desde una perspectiva de negocio.
Las técnicas utilizadas para las pruebas funcionales son a menudo basada en la
especificación, pero técnicas basadas en la experiencia también se pueden utilizar (véase el
capítulo 4 para más información sobre la prueba técnicas). Condiciones de prueba y casos
de prueba se derivan de la funcionalidad del componente o sistema. Como parte del
diseño de prueba, un modelo puede ser desarrollado, como un modelo de proceso, el
modelo de transición de estado o una especificación en lenguaje claro.
2.3.2 prueba de las características del producto de software (Pruebas no funcionales)

Un segundo objetivo de la prueba es la prueba de las características de calidad, o no
atributos funcionales del sistema (o componente o la integración del grupo). Aquí estamos
interesados en qué tan bien o algo rápido que se hace. Estamos probando algo que
necesitamos medir en una escala de medición, por ejemplo, tiempo para responder.
Ensayos no funcional, como las pruebas funcionales, se lleva a cabo en todos los niveles de
prueba.
No funcional de prueba incluye, pero no está limitado a, pruebas de rendimiento, de
carga las pruebas, las pruebas de estrés, pruebas de usabilidad, pruebas de
mantenimiento, pruebas de fiabilidad y la portabilidad de prueba. Es la prueba de "lo
bien" que funciona el sistema.
Muchos han tratado de captar la calidad del software en un conjunto de características y
relacionarlas con sub-características. En algunos de estos modelos algunas características
elementales siguen apareciendo, aunque su lugar en la jerarquía puede ser diferente. Los
Organización Internacional de Normalización (ISO) ha definido un conjunto de
características de calidad [ISO / IEC 9126, 2001]. Este conjunto refleja un paso importante
hacia el consenso en la industria de TI y de ese modo se aborda la noción general de la calidad
del software. La norma ISO 9126 define seis características de calidad y la subdivisión
de cada característica de calidad en un número de sub-características. Esta norma es
cada vez más y más reconocimiento en el la industria, lo que permite el desarrollo, prueba y
las partes interesadas para utilizar una terminología común para las características de calidad
y por lo tanto para no funcional pruebas.
Las características y sus sub-características son, respectivamente:
• Funcionalidad, que consta de cinco sub-características: idoneidad, exactitud, la
seguridad, la interoperabilidad y el cumplimiento; esta característica se ocupa de
funcional de pruebas tal como se describe en la Sección 2.3.1;
• Fiabilidad, que se define adicionalmente en la madurez sub-características (Robustez),
tolerancia a fallos, capacidad de recuperación y el cumplimiento;
• Facilidad de uso, que se divide en la comprensibilidad sub-características, facilidad de
aprendizaje, operabilidad, el atractivo y el cumplimiento;
• Eficiencia, que se divide en comportamiento en el tiempo (rendimiento), utilización de
recursos y el cumplimiento;
• Facilidad de mantenimiento, que se compone de cinco sub-características:
analizabilidad, mutabilidad, la estabilidad, la capacidad de prueba y el cumplimiento;
• Portabilidad, que también consta de cinco sub-características: capacidad de
adaptación, capacidad de instalación, la convivencia, la intercambiabilidad y
cumplimiento.
2.3.3 pruebas de software estructura / Arquitectura (prueba estructural)

El tercer objetivo de las pruebas es la estructura del sistema o componente. Si somos
hablar de la estructura de un sistema, podemos llamarla la arquitectura del sistema.
Pruebas estructurales se refiere a menudo como "caja blanca" o "caja de vidrio" porque
está interesados en lo que está sucediendo 'dentro de la caja'.
Pruebas estructurales se utiliza más a menudo como una forma de medir la minuciosidad
de las pruebas a través de la cobertura de un conjunto de elementos estructurales o
cobertura artículos. Puede ocurrir a cualquier nivel de la prueba, si bien es cierto que
tiende a ser principalmente aplicado en componente y la integración y, en general es
menos probable en más altos niveles de la prueba, a excepción de las pruebas de los procesos
empresariales. En la integración de componentes nivel que puede estar basada en la
arquitectura del sistema, tal como una jerarquía de llamada. Un sistema, integración de
sistema, vs base de pruebas, pruebas del sistema, integración de sistemas o aceptación podría
ser una modelo de negocio o estructura del menú.
A nivel de componentes, y en menor medida en la integración de componentes las pruebas,
hay una buena herramienta de apoyo para medir la cobertura de código. Cobertura
herramientas de medición evaluar el porcentaje de elementos ejecutables (por ejemplo,
declaración tos o los resultados de decisión) que han sido ejercitados (es decir, cubiertos) por
una Conjunto de pruebas. Si la cobertura no es 100%, entonces pruebas adicionales pueden
necesitar ser escrita y correr para cubrir aquellas partes que aún no han sido ejercidos. Esta
por supuesto depende de los criterios de salida. (Técnicas de cobertura se cubren en Capítulo
4.)
Las técnicas utilizadas para pruebas estructurales son técnicas basadas en la estructura,
también se hace referencia como técnicas de caja blanca. Modelos de flujo de control se
utilizan a menudo para apoyar las pruebas estructurales.
2.3.4 pruebas relacionados con los cambios (y confirmación de pruebas de regresión)

El objetivo final de la prueba es la prueba de los cambios. Esta categoría es ligeramente di-
rentes a los demás, porque si usted ha hecho un cambio en el software, que se han
cambiado la forma en que funciona, la forma en que se lleva a cabo (o ambas) y su
estructura. Sin embargo estamos buscando aquí en los tipos específicos de pruebas relativas
a cambios, a pesar de que incluya todos los otros tipos de pruebas.
Las pruebas de confirmación (repetición de pruebas)

Cuando una prueba falla y se determina que la causa del fracaso es un defecto del
software, se informó el defecto, y podemos esperar una nueva versión del software que
ha tenido el defecto fijo. En este caso tendremos que ejecutar la prueba de nuevo para
confirmar que el defecto de hecho se ha solucionado. Esto se conoce como la
confirmación prueba (también conocido como re-prueba).
Al hacer las pruebas de confirmación, es importante asegurarse de que la prueba es
ejecutado exactamente de la misma manera como lo fue la primera vez, usando las
mismas entradas, los datos y el medio ambiente. Si la prueba pasa ahora quiere decir
esto que el software ahora es correcta? Pues bien, ahora sabemos que al menos una parte
del software es corregir en el que el defecto fue. Pero esto no es suficiente. La corrección
puedo haber introducido o descubierto un defecto en el software diferente en otro
lugar. La manera de detectar a estos efectos secundarios inesperados 'de correcciones es
hacer pruebas de regresión.
Pruebas de regresión
Al igual que las pruebas de confirmación, pruebas de regresión implica que los casos de
prueba de ejecución han sido ejecutados antes. La diferencia es que, para la prueba de
regresión, los casos de prueba, probablemente, pasaron la última vez que fueron
ejecutados (compárese esto con los casos de prueba ejecutados en las pruebas de
confirmación - fallaron la última vez).
El término 'pruebas de regresión " es un término equivocado. Sería mejor si se llama

prueba "anti-regresión" porque estamos llevando a cabo pruebas con el intención de
verificar que el sistema no ha retrocedido (es decir, no lo hace ahora tienen más defectos
en ella como resultado de algún cambio). Más específicamente, el propósito de las pruebas
de regresión es verificar que las modificaciones en el software o el medio ambiente no
han causado efectos secundarios adversos no deseados y que el sistema todavía cumple
sus requisitos.
Es común que las organizaciones tienen por lo general lo que se denomina una prueba
de regresión suite o paquete de pruebas de regresión. Se trata de un conjunto de casos
de prueba que se utiliza específicamente para pruebas de regresión. Están diseñados
para ejercer colectivamente la mayoría de las funciones (ciertamente las más
importantes) en un sistema, pero no probar cualquiera en detalle. Es conveniente
contar con un conjunto de pruebas de regresión en cada nivel de la prueba (componente
las pruebas, las pruebas de integración, pruebas del sistema, etc.). Todos los casos de
prueba en una regresión se ejecutan un conjunto de pruebas cada vez que se produce
una nueva versión del software esto los hace candidatos ideales para
la automatización. Si el conjunto de pruebas de regresión es muy grande que sea más
apropiado para seleccionar un subconjunto para su ejecución.
Pruebas de regresión se ejecutan cada vez que cambia de software, ya sea como
consecuencia de correcciones o funcionalidad nueva o modificada. También es una buena
idea para ejecutarlos cuando algún aspecto de los cambios del entorno, por ejemplo, cuando
una nueva versión de un sistema de gestión de base de datos o se introduce una nueva versión
de un código fuente se utiliza compilador.
El mantenimiento de un conjunto de pruebas de regresión debe llevarse a cabo de modo

que evoluciona el tiempo de acuerdo con el software. A medida que se añade una nueva
funcionalidad a un sistema de nuevas pruebas de regresión deben ser añadidos o se cambia
la funcionalidad tan antigua o eliminan también lo debe de regresión pruebas pueden cambiar
o quitar. A medida que nuevas pruebas se añaden un conjunto de pruebas de regresión puede
llegar a ser muy grande. Si todas las pruebas tienen que ser ejecutado manualmente
puede que no sea posible ejecutar todas ellas cada vez que él se utiliza suite de
regresión. En este caso un subconjunto de los casos de prueba tiene que ser elegido.
Esta selección debe hacerse a la luz de los últimos cambios que se han hecho al software. A
veces, un conjunto de pruebas de regresión de las pruebas automatizadas pueden llegar a ser
tan grande que no siempre es posible ejecutar todas. Puede que sea posible y deseable
eliminar algunos casos de prueba a partir de una prueba de regresión grande suite por ejemplo
si son repetitivos (pruebas que ejercen la misma condiciones) o se pueden combinar (si
siempre se ejecutan en conjunto). Otro enfoque es la eliminación de los casos de prueba que
no han encontrado un defecto durante mucho tiempo (aunque este enfoque se debe utilizar
con cuidado!).
2.4 PRUEBAS MANTENIMIENTO

1 Comparación de las pruebas de mantenimiento (chequeo de un sistema operativo) a
pruebas una nueva aplicación con respecto a los tipos de prueba, disparadores de
pruebas y cantidad de pruebas. (K2)
2 Identificar las razones para las pruebas de mantenimiento (modificaciones, migración

y Jubilación). (K2)
3 Describir el papel de las pruebas de regresión y análisis de impacto en el

mantenimiento. (K2)
Una vez desplegado, el sistema es a menudo un servicio durante años o incluso

décadas. Durante esta vez el sistema y su entorno operacional a menudo se corrigen,
cambiado o extendida. Las pruebas que se ejecuta durante esta fase del ciclo de vida son
llamadas 'pruebas de mantenimiento'.
Tenga en cuenta que las pruebas de mantenimiento son diferente de las pruebas de
mantenimiento, que define lo fácil que es para mantener el sistema.
El proceso de desarrollo y prueba aplicables a los nuevos desarrollos no lo hace cambiar

fundamentalmente con fines de mantenimiento. Los mismos pasos del proceso de prueba se
aplicará y, dependiendo del tamaño y el riesgo de los cambios hechos, varios los niveles de
las pruebas se llevan a cabo: una prueba de componentes, una prueba de integración, un
sistema de prueba y una prueba de aceptación. Un proceso de prueba de mantenimiento
por lo general comienza con la recepción de una solicitud de cambio o un plan de
lanzamiento. El director de pruebas se utilizar esto como una base para producir un plan de
pruebas. Tras la recepción de la nueva o modificada especificaciones, los casos de prueba
correspondientes se especifican o adaptados. Tras la recepción del objeto de prueba, los
nuevos y modificados ensayos y las pruebas de regresión se ejecutan.
Al término de la prueba, se conserva una vez más la testware.
La comparación de las pruebas de mantenimiento para probar una nueva aplicación no es
más que una cuestión de una aproximación desde un ángulo diferente, que da lugar a una
serie de cambios de énfasis. Hay varias áreas donde la mayoría de las diferencias ocurrir, por
ejemplo con respecto a la base de pruebas. Una operación de "puesta a nivel» es con
frecuencia se requiere cuando se mantienen sistemas. Las especificaciones están menudo
'perdido', y un conjunto de testware relativa a las especificaciones simplemente No
existe. Bien puede ser posible llevar a cabo esta operación de puesta al día acción junto con
la prueba de una nueva versión de mantenimiento, lo que puede reducir la costó. Si no es
posible compilar las especificaciones de la cual los casos de prueba puede ser escrita,
incluyendo los resultados esperados, una base de prueba alternativo, por ejemplo, una
oráculo de pruebas, se debe buscar como solución de compromiso. Una búsqueda debe ser
realizada para la documentación que es más cercano a las especificaciones y los cuales
pueden ser gestionados por los desarrolladores, así como testers. En tales casos, es
aconsejable capaz de atraer la atención del cliente a la calidad de la prueba inferior que puede
ser alcanzado. Ser conscientes de los posibles problemas de "producción diaria '. En el peor
de los casos no se sabe lo que se está probando, muchos casos de prueba son ejecutado en el
mismo escenario y si se encuentra un incidente que a menudo es difícil de rastrear de nuevo
a el defecto real, ya que no trazabilidad para probar diseños y / o requisitos existe. Tenga en
cuenta que la reproducibilidad de las pruebas también es importante para las pruebas
de mantenimiento.
Un aspecto que, en muchos casos, difiere un poco del desarrollo situación es la organización
del ensayo. Nuevo desarrollo y su ensayo apropiado actividades se llevan a cabo por lo
general como parte de un proyecto, mientras que las pruebas de mantenimiento normalmente
se ejecutan como una actividad en la organización periódica. Como resultado, a menudo
existe cierta falta de recursos y la flexibilidad, y el proceso de prueba puede experimentar
una mayor competencia de otras actividades.
2.4.1 Análisis del impacto y pruebas de regresión

Por lo general, las pruebas de mantenimiento constarán de dos partes:
• Pruebas de los cambios
• Pruebas de regresión para mostrar que el resto del sistema no se ha visto afectada por los
trabajos de mantenimiento.
Además de las pruebas de lo que se ha cambiado, las pruebas de mantenimiento incluye
extensas pruebas de regresión para las partes del sistema que no han sido
cambiado. Una de las principales actividades e importante dentro de las pruebas de
mantenimiento es análisis de impacto. Durante el análisis del impacto, junto con las
partes interesadas, una decisión se hace sobre qué partes del sistema pueden verse
afectados involuntariamente y por lo tanto necesitan pruebas de regresión cuidado. El
análisis de riesgos ayudará a decidir dónde enfocar las pruebas de regresión es poco probable
que el equipo tendrá tiempo repetir todas las pruebas existentes.
Si las especificaciones de prueba desde el desarrollo inicial del sistema son cuidado, uno
puede ser capaz de volver a utilizarlos para las pruebas de regresión y de adaptarlos para
cambios en el sistema. Esto puede ser tan simple como cambiar los esperados resultados de
las pruebas existentes. A veces pueden necesitar ser construida pruebas adicionales.
Extensión o mejora del sistema pueden significar nuevas áreas han sido especificado y las
pruebas se elaborarán al igual que para el desarrollo. También es posible que las
actualizaciones son necesarias para un conjunto de pruebas automatizadas, que a menudo se
utiliza para apoyar las pruebas de regresión.
2.4.2 Los disparadores para las pruebas de mantenimiento

Como pruebas de mantenimiento indicado se realiza en un sistema operativo existente. Es
desencadenada por las modificaciones, la migración, o la jubilación del sistema.
Las modificaciones incluyen cambios de mejora planificadas (por ejemplo, base liberada),
correspondiente cambios correctivos y de emergencia, y los cambios en el medio
ambiente, tal como estaba previsto del sistema operativo o de bases de datos,
actualizaciones o parches para recién expuestas o descubrir vulnerabilidades del
sistema operativo. Pruebas de mantenimiento para la migración (por ejemplo, de una
plataforma a otra) debe incluir pruebas de funcionamiento del nuevo entorno, así como el
software modificado. Pruebas de mantenimiento para el retiro de un sistema puede
incluir pruebas de migración de datos o archivo, si Se requieren períodos de retención de
datos a largo.
Puesto que las modificaciones son más a menudo la parte principal de mantenimiento pruebas
la mayoría de las organizaciones, esto se discutirá en más detalle. Desde el punto de vista
de la prueba, hay dos tipos de modificaciones. Hay modificaciones en cuales se podrán
planificarse, y hay modificaciones correctivas ad-hoc, que no se puede planificar en
absoluto. Mantenimiento correctivo Ad-hoc se lleva a cabo cuando la búsqueda de
soluciones a los defectos no se puede retrasar. Procedimiento de prueba especial se
requiere en ese momento.
Modificaciones previstas
Los siguientes tipos de modificación prevista se pueden identificar:
• Modificaciones perfectivas (adaptación del software a los deseos del usuario, por
ejemplo, mediante el suministro de nuevas funciones o la mejora del rendimiento);
• Modificaciones de adaptación (adaptación de software a los cambios ambientales, tal
como nuevo hardware, nuevos sistemas de software o una nueva legislación);
• Modificaciones previstas correctivas (corrección de defectos diferible).
El método de prueba estándar estructurado es casi totalmente aplicable a planificada
modificaciones. En promedio, modificación prevista representa más del 90% de todos
trabajos de mantenimiento en los sistemas. [Pol y van Veenendaal]
Ad-hoc modificaciones correctivas
Ad-hoc modificaciones correctivas tienen que ver con los defectos que requieren una
inmediata solución, por ejemplo, una serie de producción que vuelca a altas horas de la
noche, una red que va hacia abajo con unos pocos cientos de usuarios en línea, un correo con
direcciones incorrectas.
Existen diferentes normas y procedimientos diferentes para la solución de problemas
de este tipo. Será imposible tomar los pasos necesarios para un enfoque estructurado de la
prueba. Sin embargo, una serie de actividades se llevan a cabo antes de un posible mal
funcionamiento, puede ser posible conseguir una situación en la que las pruebas sean fiables.
Ser ejecutado a pesar de las estaciones de pánico '' todo el año. En cierta medida, este
tipo de pruebas de mantenimiento es a menudo como los primeros auxilios (remendar)
y en una etapa posterior del proceso de prueba estándar Luego se sigue para establecer
una solución robusta, probarlo y establecer el nivel apropiado de documentación.
Un análisis de riesgos de los sistemas operativos se debe realizar con el fin de establecer
qué funciones o programas constituyen el mayor riesgo para la operación servicios en
caso de desastre. A continuación, se establece en el caso de la funciones en situación de
riesgo que (de prueba) acciones deben llevarse a cabo si un particular, la mala función se
produce. Existen varios tipos de mal funcionamiento pueden ser identificados y hay diversas
formas de responder a ellos para cada función en riesgo. Una posible reacción podría ser que
una función relevante en riesgo siempre debe ser probado, o que, bajo ciertas circunstancias,
la prueba podría ser realizada, en retrospectiva (el siguiente día, por ejemplo). Si se decide
que una función particular en riesgo debe siempre hacerse la prueba siempre que sea
pertinente, una serie de pruebas estándar, que podría ser ejecutada casi inmediatamente,
deben estar preparados para este fin. El estándar pruebas, obviamente, serían preparados y
mantenidos de acuerdo con la estructura enfoque de la prueba.
Incluso en el caso de modificaciones ad-hoc, es por lo tanto posible llevar una mejora de la
calidad mediante la adopción de un enfoque de la prueba específica. Es importante hacer un
análisis de riesgos completo del sistema y especificar un conjunto de pruebas estándar en
consecuencia.
Repaso Capítulo
De la Sección 2.1, que ahora debe entender la relación entre el desarrollo y las pruebas
dentro de un ciclo de vida de desarrollo, incluyendo las actividades de prueba y
productos de prueba (de trabajo). Debieras saber que el modelo de desarrollo a utilizar
debe encajar, o debe ser adaptada para encajar, las características del proyecto y del
producto. Debieras ser capaz de recordar las razones de los diferentes niveles de pruebas
y características de una buena prueba en cualquier modelo de ciclo de vida. Debieras
conocer los términos del glosario (comerciales) off-the-shelf software (COTS), el modelo
de desarrollo incremental, nivel de prueba, validación, verificación y V-modelo.
De la Sección 2.2, usted debe saber los niveles típicos de la prueba.

Usted debe ser capaz de comparar los diferentes niveles de pruebas con respecto a sus
principales objetivos, objetos típicos de la prueba, típico los objetivos de la prueba (por
ejemplo, funcional o estructural) y trabajos relacionados productos. También debe saber cual
las personas realizan la prueba actividades en los diferentes niveles de la prueba, los tipos de
defectos encontrados y fracasos para ser identificados. Usted debe conocer los términos del
glosario alfa las pruebas, las pruebas beta, pruebas de componentes, conductor,
funcional requisitos, la integración, las pruebas de integración, no funcional las
pruebas, la puesta a prueba de regulación de la aceptación (Pruebas de cumplimiento),
el ensayo, trozo, las pruebas del sistema robustez, basado en pruebas de desarrollo,
entorno de prueba y la aceptación de los usuarios pruebas.
De la Sección 2.3, usted debe saber los cuatro tipos principales de pruebas (Funcionales,
no funcionales, estructurales y cambiar-relacionados) y debe ser capaz de proporcionar
algunos ejemplos concretos para cada uno de estas. Usted debe entender que las pruebas
funcionales y estructurales ocurrir en cualquier nivel de la prueba y ser capaz de
explicar cómo se aplican en los diversos niveles de prueba. Usted debe ser capaz de
identificar y describir los tipos de pruebas no funcionales basados en no funcional
requisitos y características de calidad del producto. Por último, debe ser capaz de
explicar el propósito de las pruebas de confirmación (re- pruebas) y pruebas de
regresión en el contexto del cambio relacionado pruebas.
Usted debe saber los términos del glosario de pruebas de recuadro negro, la cobertura de
código, las pruebas de confirmación (re-prueba), funcionales las pruebas, las pruebas
de interoperabilidad, pruebas de carga, facilidad de mantenimiento pruebas, pruebas
de rendimiento, pruebas de portabilidad, la regresión las pruebas, las pruebas de
fiabilidad, las pruebas de seguridad, la especificación de base las pruebas, las pruebas
de estrés, pruebas estructurales, banco de pruebas, la facilidad de uso las pruebas y
la caja blanca de pruebas.
De la Sección 2.4, usted debe ser capaz de comparar el mantenimiento pruebas para
testar nuevas aplicaciones. Deberías ser capaz de identificar los factores desencadenantes
y las razones para las pruebas de mantenimiento, tales como modificaciones, la
migración y la jubilación. Por último, debe ser capaz de describir el papel de las pruebas de
regresión y análisis de impacto dentro de las pruebas de mantenimiento. Usted debe conocer
los términos del glosario análisis de impacto y pruebas de mantenimiento.

Pregunta 1 ¿Cuáles son las buenas prácticas para las pruebas dentro del ciclo de vida de
desarrollo?
a. análisis de la prueba y su diseño.
b. Diferentes niveles de prueba se definen con específica objetivos.
c. Testers comenzarán a involucrarse tan pronto como la codificación se realiza.
d. A y B anteriores.
Pregunta 2 ¿Qué opción describe mejor objetivos para los niveles de prueba con un modelo
de ciclo de vida?
a. Los objetivos deben ser genérico para cualquier prueba nivel.
b. Los objetivos son los mismos para cada nivel de prueba.
c. Los objetivos de un nivel de prueba no tienen que ser definido de antemano.
d. Cada nivel tiene objetivos específicos de ese nivel.
Pregunta 3 ¿Cuál de las siguientes es una prueba ¿tipo?

a. pruebas de componentes segundo. Prueba de funcion
b. Las pruebas del sistema
c. Test de aceptación
Pregunta 4 ¿Cuál de los siguientes es un no característica de la calidad funcional?

a. Factibilidad
b. usabilidad
c. Mantenimiento
d. Regresión
Pregunta 5 ¿Cuál de estos es una prueba funcional?

a. La medición de tiempo de respuesta en una línea de reserva sistema.
b. Comprobación del efecto de grandes volúmenes de tráfico en un sistema de centro de
llamadas.
c. Comprobación de la pantalla informa reservas on-line contenidos y la base de datos contra
el Información sobre la carta a los clientes.
d. Comprobar qué fácil es el sistema de usar.
Pregunta 6 ¿Cuál de los siguientes es un verdadero declaración en relación con el proceso de

fijación cambios de emergencia?
a. No hay tiempo para probar el cambio antes de que va en vivo, por lo que sólo los mejores
desarrolladores deben hacer este trabajo y no debe involucrar a los testers como ellos
ralentizar el proceso.
b. Sólo tiene que ejecutar la segunda prueba del defecto realidad fijo.
c. Siempre ejecutar una prueba de regresión completa de la totalidad del sistema en caso de
que otras partes del sistema tienen visto afectada de manera adversa.
d. Vuelva a probar la zona cambiada y luego usar riesgo evaluación para decidir sobre un
subconjunto razonable de toda la prueba de regresión para ejecutar en caso de otra partes del
sistema han sido adversamente afectado.
Pregunta 7 Una prueba de regresión:

a. Es sólo se ejecutan una vez.
b. Siempre será automatizado.
c. Revisará las áreas no modificadas del software para ver si se han visto afectadas.
d. Revisará las áreas modificadas del software para ver si han sido afectados.
Pregunta 8 Ensayos no funcional incluye:

a. Pruebas para ver donde el sistema no funciona correctamente.
b. Prueba de los atributos de calidad del sistema incluyendo la fiabilidad y facilidad de uso.
c. Obtener la aprobación del usuario para el sistema.
d. Prueba de una característica del sistema utilizando sólo el software requerido para esa
función.
Pregunta de prueba de 9 Beta es:
a. Realizado por los clientes en su propio sitio.
b. Realizado por los clientes en el sitio de desarrollo del software.
c. Realizado por un equipo de pruebas independiente.
d. Útil para probar el software desarrollado para una específico cliente o usuario.
CAPÍTULO TRES técnicas estáticas
técnicas de pruebas estáticas constituyen una forma eficaz de mejorar la calidad y la
productividad de software desarrollo. En este capítulo se describen las técnicas de
verificación estática, incluyendo opiniones y proporciona una visión general de la forma en
que se llevan a cabo. El objetivo fundamental de una prueba estática es mejorar la calidad
del software productos trabajo, ayudando a los ingenieros a reconocer y corregir sus
propios defectos temprano en el proceso de desarrollo de software. Si bien las técnicas
de pruebas estáticas no van a resolver todos los problemas, son enormemente
eficaces. técnicas estáticas pueden mejorar tanto la calidad como la productividad por
factores impresionantes.
Pruebas estáticas no es magia y no debe ser considerado como un reemplazo para la prueba
dinámica, pero todas las organizaciones deben considerar el uso de software de revisión en
todos los principales aspectos de su trabajo, incluyendo requisitos, diseño, implementación,
pruebas y mantenimiento. herramientas de análisis estático implementan controles
automáticos, por ejemplo en código.
S
3.1 COMENTARIOS Y EL PROCESO DE PRUEBA
1 Reconocer los productos de trabajo de software que pueden ser examinadas por las
diferentes técnicas estáticas. (KL)
2 Describir la importancia y el valor de considerar técnicas estáticas para la evaluación
de los productos de trabajo de software. (K2)
3 Explica la diferencia entre las técnicas estáticas y dinámicas. (K2)
En el capítulo 1, varias pruebas se presentaron términos. También prueba en sí se definió. La

última definición se repite aquí como medio para explicar los dos tipos principales de la
prueba.
La definición de la prueba describe los objetivos que se relacionan con la evaluación,
que revela los defectos y calidad. Como se indica en la definición dos enfoques pueden ser
utilizados para alcanzar estos objetivos, las pruebas estáticas y prueba dinámica.
Con los métodos de prueba dinámicos, el software se ejecuta utilizando un conjunto de

valores de entrada y su salida es entonces examinada y comparada con lo que se
espera. Durante la prueba estática, productos de trabajo de software se examinan
manualmente o con un conjunto de herramientas, pero no se ejecuta. Como
consecuencia, la prueba dinámica sólo se puede aplicar al código de software. Ejecución
dinámica se aplica como una técnica para detectar defectos y para determinar los atributos
de calidad del código. Esta opción de prueba es no aplicable para la mayoría de los productos
de trabajo de software. Entre la cuestión que surgen son: ¿Cómo podemos evaluar o
analizar un documento de requisitos, un documento de diseño, un plan de pruebas, o
un manual de usuario? ¿Cómo podemos efectivamente pre-examinar el código fuente
antes de la ejecución? Una técnica poderosa que puede ser usada es la prueba estática,
por ejemplo, una revisión. En principio, todos los productos de software pueden ser
probados usando técnicas de revisión.
Las pruebas dinámicas y pruebas estáticas son métodos complementarios, ya que
tienden a encontrar diferentes tipos de defectos de forma eficaz y eficiente. Tipos de
defectos que son más fáciles de encontrar durante las pruebas estáticas son:
desviaciones de las normas, falta requisitos, defectos de diseño, código no tienen
mantenimiento y especificaciones inconsistentes de la interfaz. Tenga en cuenta que, en
contraste con las pruebas dinámicas, pruebas estáticas encuentra defectos en lugar de
fracasos.
Además de encontrar defectos, los objetivos de las revisiones son a menudo también
informativos, comunicativos y educativos, por lo que los participantes aprenden sobre el
contenido de los productos de trabajo de software para ayudarles a entender el papel de su
propio trabajo y para planificar futuras etapas de desarrollo.
Los comentarios (revisones) a menudo representan los hitos del proyecto, y apoyan el
establecimiento de una línea base para un producto de software. El tipo y la cantidad
de defectos encontrados durante las revisiones también pueden ayudar a los testers a
centrar su prueba y seleccionar clases de pruebas efectivas. En algunos casos, los clientes
/ usuarios asisten a la reunión de revisión y proporcionan información al equipo de desarrollo,
por lo que las recomendaciones son también un medio de la comunicación / de usuario del
cliente.
Los estudios han demostrado que, como resultado de los exámenes, un aumento significativo
de la productividad y la calidad del producto se puede lograr [Gilb y Graham, 1993], [van
Veenendaal, 1999]. La reducción del número de defectos temprano en la vida del
producto ciclo también significa que menos tiempo tiene que ser gastado en pruebas y
mantenimiento. En resumen, el uso de pruebas estáticas, revisiones, sobre los productos
de trabajo de software tiene diversas ventajas:
• Dado que Las pruebas estáticas pueden comenzar temprano en el ciclo de la vida, la
detección temprana de defectos y su corrección, por ejemplo, una validación inicial de las
necesidades del usuario y no sólo tarde en el ciclo de vida durante las pruebas de aceptación.
• Mediante la detección de defectos en una etapa temprana, trabajo de repaso costes son
más a menudo relativamente bajo y por lo tanto relativamente barata mejora de la calidad de
producto software se pueden lograr.
• Desde la reanudación esfuerzo se reduce sustancialmente, la productividad de
desarrollo cifras probablemente aumentarán.
• La evaluación por un equipo tiene la ventaja adicional de que existe un intercambio de
información entre los participantes.
• Pruebas estáticas contribuyen a una mayor conciencia de los problemas de calidad.
En conclusión, las pruebas estáticas es un método muy adecuado para la mejora de la

calidad de los productos de trabajo de software. Esto se aplica principalmente a la
evaluación productos en sí, pero también es importante que la mejora de la calidad es no se
ha logrado una vez, pero tiene un carácter más estructural. La retroalimentación del
proceso de pruebas estáticas para el proceso de desarrollo permite proceso de mejora,
lo que permite evitar los errores similares que se realizan en el futuro.
PROCESO DE REVISIÓN 3.2

1 Recordemos las fases, funciones y responsabilidades de una típica revisión formal.
(KL)
2 Explicar las diferencias entre los diferentes tipos de revisión: Informal revisión,
revisión técnica, paso a paso y la inspección. (K2)
3 Explicar los factores para el desempeño exitoso de comentarios. (K2)
Opiniones varían desde muy informal al formal, (es decir, bien estructurado y regulado).
A pesar de que la inspección es quizás la opinión técnica más documentada y formal, desde
luego, no es el único. La formalidad de un proceso de revisión es relacionada con factores
como la madurez del proceso de desarrollo, legal o cualquiera de los requisitos
reglamentarios o la necesidad de una auditoría. En la práctica, la opinión informal es quizás
el tipo más común de revisión. Las opiniones son informales aplicado en varios momentos
durante las primeras etapas en el ciclo de vida de un documento.
Un equipo de dos personas puede llevar a cabo una revisión informal, como el autor puede
pedir a un colega para revisar un documento o código. En etapas posteriores estas opiniones
a menudo implican más personas y una reunión. Esto normalmente implica colegas del autor,
que tratan para encontrar defectos en el documento sometido a examen y discutir estos
defectos en una reunión de revisión. El objetivo es ayudar a los autores y al mejoramiento de
la calidad de la documento. Revisiones informales vienen en varios tamaños y formas,
pero todas tienen una característica en común que no están documentados.
3.2.1 Fases de una revisión formal

En contraste con revisiones informales, las revisiones formales siguen un proceso formal. Un
típico proceso de revisión formal consta de seis pasos principales:
1 Planificación
2 Kick-off
3 Preparación
4 Revisión reunión
5 re-trabajo
6 Seguimiento.
Planificación
El proceso de revisión para una revisión en particular comienza con una "solicitud de
revisión" por el autor al moderador (o líder de inspección). Un moderador a menudo se
asigna a hacerse cargo de la programación (fechas, hora, lugar y la invitación) de la
revisión. En un nivel de proyecto, la planificación del proyecto se necesita para que haya
tiempo para su revisión y la reelaboración de actividades, lo que proporciona a los
ingenieros tiempo para participar a fondo en las revisiones.
Para más formales, por ejemplo, inspecciones, el moderador siempre realiza un control de
entrada y define en esta etapa los criterios de salida formales. El control de entrada es
llevado a cabo para asegurar que el tiempo de los revisores no se desperdicia en un
documento que no está listo para su revisión. Un documento que contiene demasiados
errores obvios es claramente no está listo para entrar en un proceso de revisión formal e
incluso podría ser muy perjudicial para el proceso de revisión. Sería posiblemente de-motivar
tanto a los colaboradores y el autor. Además, la revisión no es más probable debido a los
numerosos defectos obvios y menores serán ocultar los defectos importantes.
Aunque cada vez son más los criterios de entrada se pueden aplicar, lo siguiente puede ser
considerado como el conjunto mínimo para llevar a cabo la inspección de entrada:
• Una breve comprobación de una muestra del producto por el moderador (o experto)
no lo hace revelar un gran número de defectos importantes. Por ejemplo, después de 30
minutos de comprobar, no más de 3 defectos principales se encuentran en una sola página o
menos de 10 defectos importantes en total en un conjunto de 5 páginas.
• El documento para ser revisado está disponible con los números de línea.
• El documento se sido limpiado por la ejecución de comprobaciones automáticas.
• Las referencias necesarias para la inspección son estables y disponibles.
• El autor del documento se prepara para unirse al equipo de revisión y se siente seguro con
la calidad del documento.
Si el documento pasa la comprobación de la entrada, el moderador y autor deciden qué

parte del documento va a revisión, debido a que la mente humana puede comprender
un conjunto limitado de páginas a la vez, el número no debe ser demasiado alto. El
número máximo de páginas depende, entre otras cosas, del objetivo, el tipo de examen y tipo
de documento y debe ser derivado de práctica experiencias dentro de la organización. Para
una revisión, el tamaño máximo es por lo general entre 10 y 20 páginas. En inspección
formal, solamente una o dos páginas pueden ser analizada en profundidad con el fin de
encontrar los defectos más graves que sean no es obvio.
Después de que el tamaño del documento se ha establecido y las páginas que se han
comprobado sido seleccionado, el moderador determina, en cooperación con el autor, la
composición del equipo de revisión. El equipo consiste normalmente entre cuatro y seis
participantes, incluyendo moderador y autor. Para mejorar la eficacia de la opinión, los
diferentes roles que se asignan a cada uno de los participantes. Estas funciones ayudan que
los revisores se centren en determinados tipos de defectos durante la
comprobación. Esto reduce la posibilidad de encontrar diferentes opiniones en los mismos
defectos. El moderador asigna los roles a los colaboradores.
La Figura 3.1 muestra los diferentes roles dentro de una revisión. Los roles representan
vistas del documento objeto de revisión.
Dentro de opiniones los siguientes enfoques pueden ser identificados:

• centrarse en los documentos de nivel superior, por ejemplo, el diseño no cumple con los
requisitos;
• enfoque en estándares, por ejemplo, la consistencia interna, la claridad, las convenciones
de nomenclatura, plantillas;
• centrarse en los documentos relacionados a un mismo nivel, por ejemplo, las interfaces
entre las funciones del software;
• centrarse en el uso, por ejemplo, para la capacidad de prueba o de mantenimiento.
El autor puede plantear funciones específicas adicionales y preguntas que tienen que estar
dirigidas. El moderador tiene la opción de cumplir también un papel, junto a la tarea de ser
un líder de opinión. Comprobación del documento mejora la capacidad del moderador
dirigir la reunión, ya que asegura una mejor comprensión. Además, mejora la eficiencia
revisión porque el moderador sustituye a un ingeniero que, de otra sabía que revisar el
documento y asistir a la reunión. Se recomienda que el moderador tomar el papel de
comprobar del cumplimiento de las normas, ya que esto tiende a ser un muy objetivo, que
conduce a una menor discusión de los defectos encontrados.
Patada inicial
Un paso opcional en un procedimiento de revisión es una reunión de lanzamiento. El
objetivo de este reunión es conseguir que todos estén en la misma longitud de onda en
relación con el documento sometidas a examen y comprometerse con el tiempo que se gasta
en la comprobación. También el Resultado del control de entrada y salida definido
criterios se discuten en caso de una mayor revisión formal. En general un saque de salida
es muy recomendable ya que existe un fuerte efecto positivo de una reunión de
lanzamiento de la motivación de los colaboradores y por lo tanto la eficacia del proceso de
revisión. En las instalaciones del cliente, tenemos hasta 70% de defectos encontrados por
página como resultado de la realización de un saque de salida, [van Veenendaal y van
der Zwan, 2000]
Durante la reunión de lanzamiento los revisores reciben una breve introducción en los
objetivos de la revisión y los documentos. Las relaciones entre el documento objeto de
examen y los demás documentos (fuentes) se explican, especialmente si el número de
documentos relacionados es alto.
Las asignaciones de funciones, porcentaje de control, las páginas que se comprobarán,

cambios en los procesos y otras posibles preguntas también se discuten en esta
reunión. Por supuesto la distribución del documento objeto de examen, los documentos de
origen y otra documentación relacionada, también se puede hacer durante el inicio del
encuentro.
Preparación
Los participantes trabajan individualmente en el documento que se examina, uso de los
documentos relacionados, procedimientos, reglas y listas de control. El individuo los
participantes a identificar los defectos, las preguntas y comentarios, de acuerdo con su
comprensión del documento y el papel. Todos los temas están grabados, preferiblemente
mediante un formulario de registro. Los errores ortográficos se registran en el documento
que se revisa, pero no se mencionó durante la reunión. El documento anotado será dado que
el autor al final de la sesión de registro. El uso de listas de control durante esta fase puede
hacer una revisión más eficaz y eficiente, por ejemplo, una lista específica de control basado
en perspectivas como usuario, mantenedor, tester u operaciones, o una lista de control para
problemas típicos de codificación.
Un factor crítico de éxito para una preparación exhaustiva es el número de páginas

comprobadas por hora. Esto se conoce como índice de comprobación. La tasa de
comprobación óptima es el resultado de una combinación de factores, incluyendo el tipo de
documento, su complejidad, el número de documentos relacionados y la experiencia del
revisor.
Por lo general, el porcentaje de control está en el intervalo de cinco a diez páginas por
hora, pero puede ser mucho menos de inspección formal, por ejemplo, una página por
hora. Durante preparación, los participantes no deben exceder este criterio. Mediante la
recopilación de datos y medir el proceso de revisión, los criterios específicos de la empresa
para el control de tasa y el tamaño del documento (ver la fase de planificación) se pueden
establecer, preferentemente específica a un tipo de documento.
Reunión de revisión
La reunión típicamente consta de los siguientes elementos (en parte en función del tipo
de examen): fase de registro, fase de discusión y la fase de decisión.
Durante la fase de registro de las cuestiones, por ejemplo, defectos, que han sido
identificados durante la preparación se mencionan página por página, revisor y por el
revisor se registran ya sea por el autor o por un escriba. Una persona separada para hacer la
extracción de madera (un escriba) es especialmente útil para este tipo de revisión formales
tales como una inspección. Para asegurar el progreso y la eficiencia, no se permite
ninguna discusión real durante la fase de registro. Si un problema necesita discusión, el
elemento se registra y procesa, en la fase de discusión. Una discusión detallada sobre si es o
no es un problema es un defecto no es muy significativo, ya que es mucho más eficiente que
simplemente iniciar sesión y proceder a la siguiente. Por otra parte, a pesar de la opinión del
equipo, un display defecto terco y se desecha bien puede llegar a ser una de verdad durante
la reanudación.
Cada defecto y su gravedad se van a registrar. El participante que identifique el defecto

propone la gravedad. Los grados de severidad pueden ser:
• Crítico: defectos causarán daños aguas abajo; el alcance y el impacto del defecto está más
allá del documento bajo inspección.
• Mayor, defectos podría causar un efecto aguas abajo (por ejemplo, un fallo en un diseño
puede como resultado generar un error en la aplicación).
• Menor, los defectos no son susceptibles de causar daños aguas abajo (por ejemplo, no
Cumplimiento con las normas y plantillas), Con el fin de mantener el valor añadido de las
opiniones, errores de ortografía no son parte de la clasificación de defecto. defectos de
ortografía se observan, por los participantes, en el documento sometido a examen y dado que
el autor al final de la reunión o podría ser tratado en un ejercicio de corrección de pruebas
por separado.
Durante la fase de registro la atención se centra en capturar la mayor cantidad posible

de defectos dentro de un período de tiempo determinado. Para asegurar esto, el
moderador intenta mantener una buena frecuencia de registro (número de defectos
registrados por minuta). En una buena y bien dirigida reunión de revisión formal, la
frecuencia de registro debe estar entre uno y dos defectos registrados por minuto.
Para una revisión más formal, los aspectos clasificados como temas de discusión serán
manipulados durante esta fase. Comentarios informales a menudo no tendrán que disponer
del registro de fase y comenzará inmediatamente con la discusión. El participante puede
participar en la discusión poniendo de relieve sus comentarios y razonamiento. Como
presidente de la reunión de la discusión, el moderador se encarga de problemas de las
personas. Por ejemplo, el moderador evita discusiones de conseguir demasiado personal,
reformula observaciones si es necesario y pide una pausa para enfriar abajo discusiones
calentados y / o participantes.
Revisores que no necesitan estar en la discusión puede salir, o mantenerse como un ejercicio
de aprendizaje. El moderador también se pasea esta parte de la reunión y garantiza que
todos los artículos tratados o bien tienen un resultado por el final de la reunión, o se
definen como un punto de acción si una discusión no se puede resolver durante la reunión. El
resultado de las discusiones se documenta para el futuro referencia.
Al final de la reunión, una decisión sobre el documento objeto de reseña puede ser hecha por
los participantes, en ocasiones formales sobre la base de criterios de salida. La mayor parte
de criterios de salida importantes es el número promedio de defectos críticos y / o
principales detectados por página (por ejemplo, no más de tres defectos críticos /
principales por página). Si el número de defectos detectados por página excede cierto nivel,
el documento debe ser revisado de nuevo, después de que haya sido modificada. Si el
documento cumple con los criterios de salida, el documento será revisado durante el
seguimiento por el moderador o uno o más participantes. Posteriormente, el documento
puede salir del proceso de revisión.
Si un proyecto se encuentra bajo presión, el moderador a veces se verá obligado a omitir

la salida del documento con defecto y se realizaran nuevas revisiones. Cuantificar la
configuración y acordar criterios del nivel de salida ayudan al moderador para tomar
decisiones firmes en todo el tiempo.
Además del número de defectos por página, otros criterios de salida se utilizan que miden
la rigurosidad del proceso de revisión, tales como asegurar que todas las páginas han sido
comprobadas a la velocidad adecuada. El número promedio de defectos por página sólo es
un indicador de la calidad válida si se cumplen estos criterios de proceso.
Rehacer
Sobre la base de los defectos detectados, el autor mejorará el documento que se revisó
paso a paso. No todos los defectos que se encuentra conduce a volver a trabajar. Es
responsabilidad del autor para juzgar si un defecto tiene que ser fijo. Si no se hace nada
sobre un tema por alguna razón, se debe informar al menos a indicar que el autor ha
examinado la cuestión.
Los cambios que se realizan en el documento deben ser fáciles de identificar y seguir. Por lo
tanto, el autor tiene que indicar dónde se realizan cambios (por ejemplo, El uso de ''
control de cambios en el software de procesamiento de textos).
Seguir
El moderador es responsable de asegurar que las acciones satisfactorias han sido
adoptadas en todos los defectos (registrada), sugerencias de mejora de procesos y
peticiones de cambio. Aunque el moderador comprueba para asegurarse de que el autor tiene
curso dado a todos los defectos conocidos, no es necesario que el moderador pase a
comprobar todas las correcciones en detalle. Si se decide que todos los participantes
comprueben el documento actualizado, el moderador se encarga de la distribución y recoge
las votaciones. Para los tipos más formales de los controles de revisión el moderador verifica
el cumplimiento a los criterios de salida.
Con el fin de controlar y optimizar el proceso de revisión, una serie de mediciones son
recogidos por el moderador en cada paso del proceso. Ejemplos de tales medidas
incluyen el número de defectos encontrados, el número de defectos encontrados por
página, el tiempo comprobando por página, el esfuerzo total de examen, etc. Es la
responsabilidad del moderador para asegurarse de que la información es correcta y se
almacenan durante futuros análisis.
3.2.2 Funciones y responsabilidades

Los participantes en cualquier tipo de revisión formal deben tener conocimientos
adecuados del proceso de revisión. La mejor y más eficiente, situación revisión se produce
cuando los participantes a obtener algún tipo de ventaja para su propio trabajo durante la
revisión. En el caso de una inspección o revisión técnica, los participantes deben haber
sido debidamente formados para ambos tipos de revisión han demostrado ser mucho
menos éxito con participantes sin formación. De hecho, esto se percibe como una revisión
de factor de éxito.
Las mejores revisones formales provienen de equipos bien organizados, guiados por
personal capacitado moderadores (o líderes de opinión). Dentro de un equipo de
revisión, cuatro tipos de participantes se pueden distinguir: moderador, autor, escriba
y revisor. Además, en la gestión tiene que desempeñar un papel en el proceso de revisión.
El moderador
El moderador (o líder de opinión) conduce el proceso de revisión. Él o ella determinar, en
cooperación con el autor, el tipo de revisión, el enfoque y la composición del equipo de
revisión. El moderador realiza la comprobación de la entrada y el seguimiento de la
repetición del trabajo, con el fin de controlar la calidad de la entrada y la salida del
proceso de revisión. El moderador también los horarios reuniones, difunde los
documentos antes de la reunión, los entrenadores de otro equipo miembros, marca el
ritmo del encuentro, las pistas posibles discusiones y almacena los datos que se recoge.
El autor
Como el autor del documento que se examina, el objetivo básico del autor debe ser
aprender tanto como sea posible en lo que respecta a la mejora de la calidad del
documento, sino también para mejorar su capacidad de escribir documentos futuros.
La tarea del autor es para iluminar zonas poco claras y comprender de los defectos
encontrados.
El escriba
Durante la reunión, el escriba (o grabadora) tiene que registrar cada defecto
mencionados y cualquier sugerencia para la mejora de procesos. En la práctica es a
menudo el autor que juega este papel, asegurándose de que el registro es legible y
comprensible. Si los autores registran sus propios defectos, o al menos toman sus propias
notas con sus propias palabras, se les ayuda a comprender mejor el registro durante el re-
trabajo.
Sin embargo, tener a alguien que no sea el autor tomar el papel del escriba (por ejemplo,
el moderador) puede tener ventajas significativas, ya que el autor se libera hasta pensar
en el documento en lugar de estar atado con una gran cantidad de escritura.
Los revisores
La tarea de los revisores (también llamadas juegos damas o inspectores) es comprobar
cualquier defectos en el material, sobre todo antes de la reunión. El nivel de rigurosidad
requerida depende del tipo de revisión. El nivel de conocimiento de dominio o experiencia
necesaria para los revisores también depende del tipo de revisión.
Los revisores deben ser elegidos para representar diferentes perspectivas y roles en el proceso
de revisión. Además del documento objeto de examen, los revisores reciben materiales de
revisión incluye documentos fuentes, normas, listas de control, etc. En general, un menor
número de fuentes y referencia los documentos proporcionados, más experiencia en el campo
con respecto al contenido del documento que se examina se necesita.
El gerente
El gerente está involucrado en las opiniones como él o ella decide sobre la ejecución de
revisiones, asigna tiempo en los programas del proyecto y determina si la revisión y los
objetivos del proceso se han cumplido. El gerente también se hará cargo de cualquier
revision solicitada por los participantes. Por supuesto, un administrador también puede ser
involucrados en la revisión en sí en función de sus antecedentes, la reproducción del papel
de un revisor si esto sería de gran ayuda.
3.2.3 Tipos de Revisión

Un solo documento puede ser objeto de más de una revisión. Si más de un tipo de examen
se utiliza, el orden puede variar. Por ejemplo, una revisión informal puede llevarse a cabo
antes de una revisión técnica, o la inspección se puede llevar en una especificación de
requisitos antes que una tutoría con los clientes. Es evidente que ninguno de los siguientes
tipos de revisión es el "ganador", pero los diferentes tipos sirven para diferentes
propósitos en diferentes etapas en el ciclo de vida de un documento.
Los principales tipos de examen, sus principales características y objetivos son comunes
descrito abajo.
Tutoría
Una tutoría se caracteriza porque el autor del documento examina este guiando a los
participantes a través del documento y de su proceso de pensamiento, para lograr un
entendimiento común y el intercambio de ideas. Esto es especialmente útil si la gente de
fuera de la disciplina de software está presente, que no están acostumbrados a, o no se puede
entender fácilmente documentos de desarrollo de software.
El contenido del documento se explica paso a paso por el autor, para alcanzar consenso sobre
los cambios o para reunir información.
Dentro de un paso a paso el autor hace la mayor parte de la preparación. Los participantes,
que son seleccionados a partir de diferentes departamentos, no se requiere hacer un estudio
detallado de los documentos con antelación. Debido a la forma en que la reunión se
estructura, un gran número de personas que pueden participar y esto mayor audiencia puede
traer un gran número de diversos puntos de vista con respecto al contenido del documento en
revisión, así como al servicio del propósito de la educación. Si el público representa una
amplia muestra de las habilidades y disciplinas, puede dar la seguridad de que no hay defectos
importantes se 'perdieron' en el tutorial. Una tutoría es especialmente útil para los
documentos de nivel superior, tales como especificaciones de requisitos y documentos
arquitectónicos.
Los objetivos específicos de un recorrido dependen de su papel en la creación del

documento. En general los siguientes objetivos pueden ser aplicables:
• Presentar el documento a las partes interesadas, tanto dentro como fuera de la disciplina
de software, con el fin de recopilar información sobre el tema que se documenta;
• Explicar (transferencia de conocimientos) y evaluar el contenido de la documentación;
• Establecer un entendimiento común del documento;
• Examinar y discutir la validez de las soluciones propuestas y la viabilidad de las
alternativas, establecer un consenso.
Las características clave de los recorridos son:

• La reunión está dirigida por los autores; menudo un escriba está presente.
• Escenarios y simulacros pueden ser utilizados para validar el contenido.
• preparación previa a la reunión separada para los colaboradores es opcional.
Revisión técnica
Una revisión técnica es una reunión de la discusión que se centra en el logro de con-
consenso sobre el contenido técnico de un documento. En comparación con inspecciones,
revisiones técnicas son menos formales y hay poco o ningún énfasis en la identificación de
defectos sobre la base de documentos de referencia y reglas, destinado lectores. Durante las
revisiones técnicas se han observado defectos por los expertos, que se centran en el
contenido del documento. Los expertos que se necesitan para una revisión técnica son,
por ejemplo, arquitectos, jefes de diseño y usuarios clave. En la práctica, las revisiones
técnicas varían de bastantes informales a muy formal.
Los objetivos de una revisión técnica son los siguientes:
• Evaluar el valor de los conceptos técnicos y alternativas en el producto y entorno del
proyecto;
• Establecer una coherencia en el uso y la representación de los conceptos técnicos;
• Asegurar, en una etapa temprana, que los conceptos técnicos se utilizan
correctamente;
• Informar a los participantes sobre el contenido técnico del documento.
Las características clave de una revisión técnica son:

• Es un proceso de detección de defectos documentado que implica compañeros y expertos
técnicos.
• Se realiza a menudo como una revisión por pares y sin gestión de partición.
• Lo ideal es que está dirigido por un moderador capacitado, pero posiblemente también por
un técnico experto.
• Una preparación separada se lleva a cabo durante el cual se examinó el producto y se
encuentran los defectos.
• Más características formales tales como el uso de listas de verificación y una lista de registro
o registro de emisión son opcionales.
Inspección
Inspección es el tipo más formal de revisión. El documento bajo inspección es redactada
y revisada a fondo por los revisores antes de la reunión, comparación del producto de
trabajo con sus fuentes y otros documentos de referencia, y usando reglas y listas de
control. En la reunión de la inspección son los defectos encontrados registrados y
cualquier discusión se pospone hasta la fase de discusión. Esto hace la inspección conocer
a una reunión muy eficiente.
La razón para llevar a cabo las inspecciones se puede explicar mediante el uso de concepto
de Weinberg de la ingeniería sin ego [Weinberg, 1971]. Weinberg se refiere a la tendencia
humana a la auto-justificar acciones. Ya que tienden a no ver la evidencia que entra en
conflicto con nuestras creencias fuertes, nuestra capacidad para encontrar errores en nuestro
propio trabajo se deteriora. Debido a esta tendencia, muchas organizaciones de ingeniería
tienen grupos de prueba independientes establecidas que se especializan en la búsqueda de
defectos. Similares principios han dado lugar a la introducción de las inspecciones y
revisiones en general.
Dependiendo de la organización y los objetivos de un proyecto, las inspecciones pueden

ser equilibradas para cumplir una serie de objetivos. Por ejemplo, si el tiempo de
comercialización es extremadamente importante, el énfasis en las inspecciones será la
eficiencia. En un mercado crítico para la seguridad, la atención se centrará en la efectividad.
Los objetivos generalmente aceptados de la inspección son los siguientes:

• Ayudar al autor a mejorar la calidad del documento objeto de la inspección;
• Eliminar los defectos de manera eficiente, lo más pronto posible;
• Mejorar la calidad de los productos, mediante la producción de documentos con un mayor
nivel de calidad;
• Crear un entendimiento común mediante el intercambio de información entre los
participantes de inspección;
• Formar a nuevos empleados en el proceso de desarrollo de la organización;
• Aprender de los defectos encontrados y mejorar los procesos con el fin de evitar que se
repiten defectos similares;
• Degustar unas pocas páginas o secciones de un documento más grande con el fin de medir
la típica calidad del documento, lo que mejora el trabajo de las personas en el futuro, y para
mejoras de proceso.
Las características clave de una inspección son:

• Por lo general se condujo por un moderador capacitado (desde luego no por el autor).
• Se utiliza papeles definidos durante el proceso.
• Se trata de pares para examinar el producto.
• Las reglas y listas de verificación se utilizan durante la fase de preparación.
• Una preparación separada se lleva a cabo durante el cual se examinó el producto y se
encuentran los defectos.
• Los defectos encontrados se documentan en una lista de registro o registro de tema.
• Un seguimiento oficial se lleva a cabo por el moderador aplicando criterios de salida.
• Opcionalmente, una etapa de análisis causal se introdujo para hacer frente a cuestiones de
mejora de procesos y aprender de los defectos encontrados.
• Las métricas son recogidos y analizados para optimizar el proceso.
3.2.4 Factores de éxito para las revisiones

La implementación de comentarios (formal) no es fácil ya que no hay una manera de
éxito y hay muchas maneras de fracasar. La siguiente lista contiene una serie de críticos
factores de éxito que mejoran las posibilidades de éxito en la aplicación de las revisiones.
Su objetivo es responder a la pregunta: "¿Cómo se inicia revisión (formal)? '.
Encontrar un "campeón"
Se necesita un campeón, que conducirá el proceso en un proyecto o un nivel de la
organización. Necesitan experiencia, entusiasmo y una mentalidad práctica con el fin
para guiar a los moderadores y participantes. La autoridad de este campeón debe ser
claro para toda la organización. apoyo a la gestión también es esencial para éxito. Ellos
deben, entre otras cosas, incorporar un tiempo adecuado para actividades de revisión de los
programas del proyecto.
Recoger las cosas que realmente cuentan

Seleccione los documentos de revisión que son más importantes en un proyecto.
La revisión de documentos altamente críticos, aguas arriba como los requisitos y la
arquitectura con toda seguridad, mostrara los beneficios del proceso de revisión para el
proyecto.
Estas horas de revisión invertidos tendrán un retorno claro y alto de la inversión.

Además, asegúrese de que cada revisión tiene un objetivo claro y el tipo correcto de
revisión se ha seleccionado para que coincide con el objetivo definido. No tratar de
opinión todo mediante inspección; adaptarse a la opinión sobre el riesgo asociado con el
documento ambiente. Algunos documentos sólo pueden justificar una revisión informal
y otros mediante inspección. Por supuesto, también es de suma importancia que personas
están involucradas.
Explícitamente planificar y realizar un seguimiento de las actividades de revisión

Para asegurar que las revisiones (criticas) se convierten en parte de las actividades del día a
día, las horas a ser gastado debe ser visible dentro de cada plan de proyecto. los ingenieros
implicados programan el tiempo de preparación y, muy importante, rehacen. El seguimiento
de estas horas será mejorar la planificación de la próxima revisión. Como se dijo
anteriormente, la gestión juega un papel importante en la planificación de las actividades
de revisión.
Capacitar a los participantes

Es importante que se imparta formación en técnicas de revisión, en especial técnicas
formales, tales como la inspección. De lo contrario es probable que el proceso de ser
obstaculizado por aquellos que no entienden el proceso y el razonamiento Detrás de
eso. entrenamiento especial se debe proporcionar a los moderadores para prepararlos
en su papel fundamental en el proceso de revisión.
Resolver los problemas de la gente

Los comentarios son sobre la evaluación del documento de alguien. Algunas de las
críticas tienden a obtener demasiado personal cuando no están bien gestionados por el
moderador. problemas de las personas y los aspectos psicológicos deben ser tratados por el
moderador y debe ser parte de la formación crítica, con lo que la opinión de una experiencia
positiva para el autor. Durante la revisión, los defectos deben ser bien recibidas y
expresarlos objetivamente.
Siga las reglas, pero que sea sencillo

Siga todas las reglas formales hasta que sepa por qué y cómo modificarlos, pero haga
el proceso tan formal como la cultura del proyecto o nivel de madurez permite.
No se convierta en demasiado teórica o demasiado detallada. Las listas de verificación
y los roles son eficaces para aumentar la eficacia de la identificación de defectos.
Mejorar continuamente procesos y herramientas

La mejora continua de los procesos y herramientas de apoyo (por ejemplo, listas de control),
en base a las ideas de los participantes, asegura la motivación de los ingenieros
involucrado. La motivación es la clave para un proceso de cambio con éxito. Debería
También hacer hincapié, además de encontrar defectos, en el aprendizaje y el proceso de
mejora.
los resultados del informe

Informe cuantifica los resultados y beneficios para todos los involucrados tan pronto
como sea posible, y discutir las consecuencias de los defectos si no se habían encontrado tan
temprano.
Los costos deben ser rastreados por supuesto, pero los beneficios, sobre todo cuando los
problemas no lo hacen ocurrir en el futuro, debe hacerse visible mediante la cuantificación
de los beneficios, así como los costos.
¡Solo hazlo!
El proceso es simple pero no fácil. Cada paso del proceso es claro, pero se necesita la
experiencia para ejecutar correctamente. Por lo tanto, tratar de conseguir que la gente con
experiencia para observar y ayudar en lo posible. Pero lo más importante, empezar a hacer
comentarios y comenzar a aprender de cada revisión.
3.3 Análisis estático por herramientas

1 Describir el objetivo del análisis estático y compararlo con pruebas dinámica. (K2)
2 Recordemos defectos típicos identificados por el análisis estático y compararlas con
las críticas y pruebas dinámicas. (KL)
3 Lista de beneficios típicos de los analistas estática. (KL)
4 Lista de código y diseño típicos defectos que pueden ser identificados por la estática
Las herramientas de análisis. (KL)
Hay mucho por hacer, revisiones de los productos de trabajo de software sin llegar a
ejecuta el sistema. Por ejemplo, vimos en el apartado anterior que podemos revisar
cuidadosamente los requisitos, diseños, códigos, planes de prueba y más, para encontrar
defectos y corregirlos antes de entregar un producto a un cliente. En esta sección, nos
centramos en un tipo diferente de pruebas estáticas, donde examinamos
cuidadosamente requisitos, diseños y código, por lo general con la asistencia automática
para desentrañar defectos adicionales antes del código real de ejecución. Por lo tanto, lo que
se llama El análisis estático es más que otra forma de prueba.
El análisis estático es un examen de los requisitos, el diseño y el código que difiere de la

prueba dinámica más tradicional en un número de maneras importantes:
• El análisis estático se realiza sobre los requisitos, el diseño o código sin llegar ejecutar el
artefacto software que está siendo examinada.
• El análisis estático se realiza idealmente antes de que los tipos de revisión formal se discute
en la Sección 3.2.
• Análisis estático no está relacionado con las propiedades dinámicas de los requisitos, el
diseño y el código, tales como cobertura de la prueba.
• El objetivo del análisis estático es encontrar defectos, pueden o no causar
fracasos. Como con las críticas, el análisis estático encuentra defectos en lugar de
fracasos.
Para el análisis estático hay muchas herramientas, y la mayoría de ellos se centran en

el código del software. herramientas de análisis estático suelen ser utilizados por los
desarrolladores antes, y A veces, durante, el diseño de componentes y pruebas de
integración y por diseñadores durante el modelado de software. Las herramientas
pueden mostrar atributos no sólo estructurales (métricas de código), tales como la
profundidad del número de anidación o ciclomática y verificación en contra de las
normas de codificación, sino también representaciones gráficas de control de flujo de
datos, las relaciones y el número de trayectorias distintas de una línea de código a
otro. Incluso el compilador puede considerarse una herramienta de análisis estático, ya que
construye una tabla de símbolos, señala el uso incorrecto y controles para no cumplimiento
de codificación de las convenciones del lenguaje (sintaxis).
Una de las razones para el uso de análisis estático (normas de codificación y similares)
está relacionada con las características de los lenguajes de programación propios.
Uno puede pensar que los lenguajes son seguros de usar, ya que al menos el comité de normas
sabe dónde están los problemas. Pero esto sería un error.
Agregando a los agujeros dejados por el proceso de normalización, los programadores

continuar para informar de las características del lenguaje, que aunque bien definido, dar
lugar a modos de fallo reconocible. A finales de la década de 1990, aproximadamente 700 de
estos problemas adicionales habían sido identificados en C estándar Ahora está claro la
existencia de tales modos de falla. Se puede demostrar que con frecuencia escapar del
escrutinio de la prueba dinámica convencional, terminando en comerciar el producto. Estos
problemas se pueden encontrar mediante el uso de herramientas de análisis estático de
detectarlos. ¡De hecho, muchos de los 700 modos de falla en C pueden ser detectados
informados de esta manera! En un programa típico de C, hay un promedio de
aproximadamente ocho faltas por cada 1.000 líneas de código fuente; que están
incrustados en el código liberado, a la espera de hacer que el código para fallar [Hatton,
1997].
La prueba dinámica simplemente no detectó estos. C no es el culpable aquí; esta el
ejercicio puede llevarse a cabo para otros lenguajes con ampliamente los mismos resultados.
Todos los lenguajes de programación tienen problemas y los programadores no pueden
asumir que están protegidos contra ellos. Y nada en el actual proceso internacional de
normalización de los lenguajes evitará que esto suceda en el futuro.
Las diversas características de herramientas de análisis estático se discuten a continuación,

con un enfoque especial hacia las herramientas de análisis de código estático, ya que estos
son los más comunes en la práctica del día a día. Tenga en cuenta que las herramientas de
análisis estático analizan código de software, así como salida generada como HTML y XML.
3.3.1 normas de codificación

Comprobación de la adherencia a los estándares de codificación es sin duda la más
conocida de todas las características. La primera acción a realizar es definir o adoptar
una codificación Standard. Por lo general, un estándar de codificación consiste en un
conjunto de reglas de programación (por ejemplo, 'Siempre revise los límites de un array
cuando se copia a la matriz'), nombrando convenciones (por ejemplo, "Las clases deben
comenzar con mayúscula) y especificaciones de diseño (por ejemplo, 'guion 4 espacios'). Se
recomienda que las normas existentes son adoptadas. La principal ventaja de esto es que se
ahorra una gran cantidad de esfuerzo. Una razón extra para adoptar este enfoque es que si se
toma un Standard de codificación conocida es probable que haya herramientas disponibles
que soportan este estándar de chequeo.
Incluso se puede poner al revés: la compra de un analizador de código estático y declarar
(una selección de) las reglas en él como su norma de codificación. sin tal herramienta, es
probable que falle la aplicación de un estándar de codificación en una organización.
Hay tres causas principales para esto: el número de reglas en un estándar de
codificación es por lo general tan grande que nadie puede recordar a todos ellos; algunas
normas contextuales que exigen una revisión de varios archivos son muy difíciles de
comprobar por los seres humanos; y si la gente pasa tiempo revisando los estándares de
codificación de las revisiones, que la voluntad distraerlos de otros defectos que de otro modo
podrían, por lo que procesar la revisión será menos eficaz.
3.3.2 métricas de código

Como se ha indicado, cuando se realizan análisis de código estático, por lo general la
información es calculada sobre los atributos estructurales del código, como frecuencia
de comentario, la profundidad de, el número de líneas de código, anidación ciclomática.
Esta información se puede calcular no sólo cuando el diseño y el código son creado, sino
también cuando se realizan cambios en un sistema, para ver si el diseño o código es cada vez
más grande, más complejo y más difícil de entender y mantener. Las mediciones también nos
ayudan a decidir entre varias alternativas de diseño, especialmente cuando el reajuste de las
porciones del código existente.
Hay muchos tipos diferentes de medidas estructurales, cada uno de los cuales nos dice algo
sobre el esfuerzo necesario para escribir el código en primer lugar, a entender el código al
hacer un cambio, o para probar el código utilizando herramientas o técnicas particulares.
programadores con experiencia saben que el 20% del código causan el 80% de los problemas
y el análisis de complejidad ayuda para encontrar este 20%, lo cual referirse de nuevo al
principio de la agrupación de defecto como se explica en el Capítulo 1.
Complejidad métrica identificar zonas de alto riesgo complejas.
La complejidad métrica ciclomática se basa en el número de decisiones en un

programa. Es importante testers, ya que proporciona una indicación de la cantidad de pruebas
(incluyendo comentarios) necesarias para evitar prácticamente defectos. En otras palabras,
las áreas de código identificadas como más complejo son candidatos para las revisiones
y pruebas dinámicas adicionales. Si bien hay muchas maneras de calcular la complejidad
ciclomática, la forma más fácil es para sumar el número de declaraciones de decisiones
binarias (por ejemplo, si, mientras que, por, etc.) y añadir 1 a eso. Una definición más formal
con respecto a las reglas de cálculo se proporciona en el glosario.
A continuación, se muestra un programa simple como un ejemplo:
El flujo de control generada por el programa se vería Figura 3.2.
El flujo de control muestra siete nodos (formas) y ocho bordes (líneas), utilizando así la
fórmula de la complejidad formal ciclomática es 8-7 + 2 = 3. En este caso no hay gráfico
llamada o subrutina.
Alternativamente, se puede calcular utilizando la complejidad ciclomática la regla de los
puntos de decisión. Puesto que hay dos puntos de decisión, las ciclomática complejidad es 2
+ 1 = 3.
3.3.3 estructura de Código

Hay muchos tipos diferentes de medidas estructurales, cada uno de los cuales nos dice
algo sobre el esfuerzo necesario para escribir el código en el primer lugar, comprender el
código a la hora de hacer un cambio, o para probar el código usando las herramientas
o técnicas particulares. A menudo se supone que un módulo grande requiere más tiempo
para especificar, diseño, código y prueba que uno más pequeño. Pero, de hecho, la estructura
del código juega un papel importante. Ahí Son varios los aspectos de la estructura del código
a tener en cuenta:
• Estructura de flujo de control;
• Estructura de flujo de datos;
• Estructura de datos.
La estructura de flujo de control se dirige a la secuencia en la que las instrucciones se
ejecutan. Este aspecto de la estructura refleja las iteraciones y bucles en el diseño de un
programa. Si sólo el tamaño de un programa se mide, no se proporciona información sobre
la frecuencia con que una instrucción se ejecuta y como se ejecuta. análisis de flujo de
control también se utiliza para identificar el código inalcanzable (muertos). De hecho,
muchos de las métricas de códigos se refieren a la estructura de flujo de control, por ejemplo,
número de anidada niveles de complejidad o ciclomática.
estructura de flujo de datos sigue la estela de un elemento de datos, ya que se accede y

se modifica por el código. Muchas veces, las operaciones aplicadas a los datos son más
compleja que las instrucciones que los desarrollan. Por lo tanto, el uso de flujo de datos
muestra cómo actúan los datos a medida que se transforman por el programa.
Los defectos pueden ser encontrados como referencia a una variable con un valor indefinido
y las variables que nunca se utilizan.
Estructura de datos se refiere a la organización de los datos en sí, independiente del

programa. Cuando los datos se organizan como una lista, cola, pila, u otra estructura bien
definida, los algoritmos para la creación, modificación o supresión de ellas hay más
probabilidades de estar bien definidos, también. Por lo tanto, la estructura de datos
proporciona una gran cantidad de información acerca de la dificultad de escribir
programas para manejar los datos y en el diseño de casos de prueba para demostrar la
corrección del programa. Es decir, a veces un programa es complejo, ya que tiene una
estructura de datos compleja, en lugar de causa de control complejo o flujo de datos.
Lo importante para el tester es ser consciente de que las medidas de análisis estático se
pueden utilizar como señales de alerta temprana de lo bien que el código sea cuando
esté terminado.
En resumen, el valor del análisis estático es especialmente para:

• Detección precoz de los defectos antes de probar la ejecución;
• Alerta temprana sobre aspectos sospechosos del código, diseño o los requisitos;
• Identificación de defectos que no se encuentran fácilmente en las pruebas dinámicas;
• Mejora de la capacidad de mantenimiento del código y el diseño ya que los ingenieros
trabajan de acuerdo a las normas y reglas documentados;
• Prevención de defectos, a condición de que los ingenieros están dispuestos a aprender
de su errores y mejora continua se practica.
Repaso Capítulo
De la Sección 3.1, usted debe ser capaz de explicar la importancia y ventaja de pruebas
estáticas. Usted debe saber la diferencia entre los ensayos estáticos y la prueba dinámica,
y también a entender el concepto de revisión (comentarios). Usted debería ser capaz de
reconocer los productos de trabajo de software que pueden ser examinadas por las
pruebas estática. Usted debe conocer los términos del glosario pruebas estáticas, pruebas
dinámicas y revisión.
De la Sección 3.2, usted debe entender la diferencia entre lo formal y revisiones

informales. Usted debe ser capaz de recordar las fases principales de una típica revisión
formal. Las principales funciones dentro de las revisiones y sus funciones deben ser claro
para usted. Usted debe conocer las diferencias entre los distintos tipos de revisión formal:
revisión técnica, paso a paso y la inspección. Por último, debe ser capaz de explicar los
factores para el desempeño exitoso de revisiones (comentarios). Debieras conocer los
términos del glosario criterios principales, los criterios de salida, formal opinión,
informal revisión, inspección, moderador, revisor, escriba, revisión técnica y paso a
paso.
De la Sección 3.3, usted debe entender el objetivo del análisis estático y ser capaz de
compararlo con pruebas estáticas y dinámicas. Deberías ser capaz de describir las
principales características de análisis estático y recordar defectos típicos que se
encuentra el uso de análisis estático. Por último, usted debe ser capaz de recordar los
beneficios de la utilización de análisis estático. Usted debe saber el glosario de
términos compilador, complejidad ciclo- matica, control de flujo, el flujo de datos y el
análisis estático.
Pregunta 1 ¿Cuál de los siguientes artefactos pueden ser examinados mediante el uso de
opinión técnicas?
a. código de software
b. Especificación de requisitos
c. El empleo de pruebas
d. Todo lo de arriba
Pregunta 2 ¿Qué afirmación acerca de la función de una herramienta de análisis estático es

cierto?
a. Proporciona información acerca de la calidad código sin ejecutarlo.
b. Cheques resultados esperados contra real resultados.
c. Puede detectar pérdidas de memoria.
d. Proporciona información acerca de lo que tiene el código de
y no se ha ejercido.
Pregunta 3 ¿Qué no es un tipo de ¿revisión?

a. Tutorial
b. Inspección
c. revisión informal
d. aprobación de la administración
Pregunta 4 ¿Qué afirmación acerca comentarios es de verdad?

a. Las inspecciones son dirigidas por un profesional capacitado moderador, mientras que las
revisiones técnicas no son necesariamente.
b. Revisiones técnicas están dirigidas por un líder entrenado, las inspecciones no son.
c. En un recorrido, el autor no lo hace asistir.
d. Los participantes de un recorrido siempre necesitan ser entrenados completamente.
Pregunta 5 ¿Cuál es la principal diferencia entre un tutorial y un ¿inspección?

a. Una inspección es dirigida por los autores, mientras que un paseo a través es dirigido por
un moderador capacitado.
b. Una inspección tiene un líder entrenado, mientras que un paseo a través no tiene un líder.
c. Los autores no están presentes durante inspecciones, mientras que son durante los
recorridos.
d. Un tutorial está dirigido por el autor, mientras que una inspección está dirigido por un
profesional capacitado moderador.
Pregunta 6 ¿Cuál de las siguientes características y tipos de revisión procesos van de la mano?
1. Dirigido por el autor
2. indocumentados
3. Sin la participación de gestión
4. Dirigido por un moderador o líder entrenado
5. Utiliza los criterios de entrada y salida
s. Inspección
t. Revisión técnica
u. revisión informal
v. Tutorial
a. s = 4, t = 3, u = 2 y 5, v = 1
segundo. s = 4 y 5, t = 3, u = 2, v = 1
do. s = 1 y 5, t = 3, u = 2, v = 4
re. s = 5, t = 4, u = 3, v = 1 y 2
Pregunta 7 ¿Cuál declaración sobre estática El análisis es verdad?

a. Con el análisis estático, los defectos pueden ser encontrado que son difícil de encontrar
con las pruebas dinámicas.
b. Compilando no es una forma de estática análisis.
c. Si se realiza correctamente, estático hace que el análisis redundante pruebas funcionales.
d. El análisis estático encuentra todas las faltas.
Pregunta 8 ¿Cuál de las siguientes declaraciones sobre el diseño de las primeras pruebas son
verdaderas y que son falsas?
1. Los defectos encontrados durante el diseño de la prueba temprana son más caros de
solucionar.
2. diseño de la prueba temprana puede encontrar defectos.
3. diseño de la prueba temprana puede causar cambios en los requisitos.
4. diseño de la prueba temprana requiere más esfuerzo.
a. 1 y 3 son ciertas. 2 y 4 son falsas.
b. 2 es verdadera. 1, 3 y 4 son falsas.
c. 2 y 3 son ciertas. 1 y 4 son falsas.
d. 2, 3 y 4 son verdaderas. 1 es falsa.
Pregunta 9 de análisis de código estático típicamente identifica todos menos uno de los
siguientes problemas. ¿Que es?
a. Código inalcanzable
b. las variables no declaradas
c. Los fallos en los requisitos
d. No hay suficientes comentarios
Técnicas de diseño de pruebas
Capítulo 3 cubierto pruebas estáticas, mirando a los documentos y el código y que no utiliza
el código. Este capítulo se centra en las pruebas dinámicas, donde el software que están
interesados en que se ejecute mediante la ejecución de pruebas en el código de ejecución.
4.1 Identificación de las condiciones de prueba y el diseño de casos de pruebas
1 Diferenciar entre una especificación de diseño de prueba, una especificación de casos

de prueba y un procedimiento de prueba. (KL)
2 Comparación de los términos de condiciones de prueba, casos de prueba y
procedimiento de prueba. (K2)
3 casos de prueba de escritura: (K3)
a) mostrando una clara trazabilidad de los requisitos; b) que contiene un
Resultado Esperado.
Traducir casos de prueba en un procedimiento de pruebas bien estructurado a un nivel

de detalle relevante para el conocimiento de los testers. (K3)
5 Escribir un programa de ejecución de prueba para un determinado conjunto de casos

de prueba, teniendo en cuenta priorización, y técnicos y lógicos dependencias. (K3)
4.1.1 Introducción
Antes de que realmente puede ejecutar una prueba, tenemos que saber lo que estamos
tratando de probar, las entradas, los resultados que debe ser producido por esas
entradas, y la forma en que realmente se preparan para ejecutar las pruebas.
En esta sección estamos ante tres cosas: las condiciones de prueba, casos de prueba y
procedimientos de prueba (o scripts) que se describen en las siguientes secciones. Cada
una se especifica en su propio documento, de acuerdo con la Documentación estándar de
Prueba [IEEE829].
Condiciones de la prueba se documentan en un diseño de la Norma de prueba. Vamos a ver

cómo elegir la prueba condiciones y dar prioridad a ellos.
Los casos de prueba se documentan en un caso de la Norma de prueba. Vamos a ver

cómo para escribir un buen caso de prueba, mostrando trazabilidad clara a la base de pruebas
(por ejemplo, la especificación de requisitos), así como a las condiciones de prueba.
Los procedimientos de prueba están documentados (como se puede esperar) en un
procedimiento de prueba Especifico (también conocido como un script de prueba o un
script de prueba manual). Vamos a ver la forma de traducir los casos de prueba en los
procedimientos de prueba relevantes para el conocimiento del testers, de la que se ejecuta
la prueba, y vamos a buscar la forma de producir un calendario de ejecución de pruebas,
usando el establecimiento de prioridades y técnica y lógica dependencias.
En esta sección, busque las definiciones de los términos del glosario: caso de prueba, caso
de prueba especifico, las condiciones de prueba, datos de prueba, procedimiento de
prueba especifico, escritura de la prueba y la trazabilidad.
4.1.2 La formalidad de la documentación de prueba
La prueba puede realizarse con diversos grados de formalidad. prueba muy formal tendría
una extensa documentación que está bien controlada, y se esperaría el detalle documentado
de las pruebas que incluyen la entrada exacta y específica y el resultado esperado de la
prueba. Muy informal prueba que no tiene documentación en absoluto, o sólo las notas
mantenidas por los testers individuales, pero todavía esperaría que el testers tiene en sus
mentes y señala una idea de lo que pretendían poner a prueba y lo que espera que el resultado
sea. La mayoría de la gente está probablemente en algún lugar ¡entre! El nivel adecuado de
formalidad para usted depende de su contexto:
una aplicación comercial crítica para la seguridad tiene necesidades muy diferentes que una
que solo se solicitud para ser utilizado por sólo unas pocas personas por un corto tiempo.
El nivel de formalidad también se ve influida por su organización, su cultura, las personas

que trabajan allí, el grado de madurez del proceso de desarrollo, el grado de madurez del
proceso de prueba, etc. La rigurosidad de la documentación de prueba puede También
dependerá de sus limitaciones de tiempo; bajo presión de tiempo excesivo, mantener una
buena documentación puede verse comprometida.
En este capítulo vamos a describir un estilo de documentación bastante formal. Si esto no es

apropiado para usted, es posible adoptar un enfoque menos formal, pero debe ser conscientes
de cómo aumentar la formalidad si es necesario.
4.1.3 Análisis de Prueba: Identificación de las condiciones de prueba

Análisis de la prueba es el proceso de observar algo que se puede utilizar para derivar
información de la prueba. Esta base de las pruebas se denomina la "base de pruebas
'. Podría ser un requisito del sistema, una especificación técnica, el propio código (por
estructural prueba), o un proceso de negocio. A veces las pruebas se pueden basar en el
conocimiento experimentado del usuario del sistema, que no puede ser documentado. La base
de pruebas incluye cualesquiera que sean las pruebas. Esto también se discutió en el Capítulo
1.
Desde una perspectiva de pruebas, nos fijamos en la base de pruebas con el fin de ver qué
podría ser probado, éstas son las condiciones de prueba. una condición de prueba es
simplemente algo que hemos podido probar. Si estamos buscando para medir la cobertura de
código decisiones (ramas), entonces la base de pruebas serían el propio código, y la lista
de la prueba de las condiciones serían los resultados de la decisión (verdaderos y falsos). Si
nosotros tenemos una especificación de requisitos, la tabla de contenido puede ser nuestra
lista inicial de condiciones de prueba.
Una buena manera de entender mejor los requisitos es tratar de definir las pruebas
para que cumplan con esos requisitos, como ha señalado [Hetzel, 1988].
Por ejemplo, si estamos probando un sistema de gestión de clientes y comercialización para
una empresa de telefonía móvil, podríamos tener condiciones de prueba que están
relacionados con una campaña de marketing, tales como la edad del cliente (pre-adolescente,
joven adulto, maduro), sexo, código postal o el código postal, y la preferencia de compra
(pago por uso o contrato). Una campaña de publicidad en particular podría ser dirigido a
clientes adolescentes varones en el medio oeste de los EE.UU. en pago por uso, por ejemplo.
expertos en pruebas utilizan diferentes nombres para representar la idea básica de "una lista
de cosas que podíamos probar '. Por ejemplo, Marick se refiere a los requisitos de prueba ''
como cosas que deben ser probadas. Aunque no se pretende dar a entender que todo debe ser
probado, se interpreta fácilmente de esta manera. [Marick, 1994] En contraste, Hutcheson
habla de la "objetos de la pruba 'como una lista de cosas que podrían ser probadas
[Hutcheson, 2003]; Craig habla sobre como amplias categorías 'objetivos' de prueba de cosas
para probar y '' inventarios de prueba como la lista actual de las cosas que necesitan ser
probado [Craig, 2002]. Estos autores se refieren a todo lo que el glosario ISTQB pide una
condición de prueba.
En la identificación de las condiciones de prueba, queremos 'lanzar la red' para identificar

tantos como podamos, y luego vamos a empezar a ser selectivo sobre cuáles llevar adelante
para desarrollar con más detalle y combinar en los casos de prueba. Podríamos llamarlos
'posibilidades' de prueba.
En el capítulo 1 se explicó que las pruebas de todo lo que se conoce como exhaustiva las
pruebas (que se define como el ejercicio de todas las combinaciones de insumos y las
condiciones previas) y hemos demostrado que este es un objetivo práctico. Por lo tanto, ya
que no puede ser probado todo, tenemos que seleccionar un subconjunto de todas las pruebas
posibles. En la práctica, el subconjunto que seleccione puede ser un subconjunto muy
pequeño y, sin embargo, tiene que tener una alta probabilidad de encontrar la mayor
parte de los defectos en un sistema. Necesitamos un proceso inteligente para guiar nuestra
selección; técnicas de prueba (es decir, diseño de pruebas técnicas) son tales procesos de
pensamiento.
Una técnica de prueba ayuda a seleccionar un buen conjunto de pruebas a partir del
número total de todas las pruebas posibles para un sistema dado. Diferentes técnicas
ofrecen diferentes maneras de mirar el software bajo prueba, posiblemente supuestos hechos
desafiantes sobre ello. Cada técnica proporciona un conjunto de reglas o directrices para
el testers a seguir en la identificación de las condiciones de prueba y casos de
prueba. Las técnicas se describen en detalle más adelante en este capítulo.
Las condiciones de pruebas que son elegidas dependerán de la estrategia de prueba o
enfoque detallado de las pruebas. Por ejemplo, podrían estar basados en el riesgo,
modelos del sistema, las posibles averías, los requisitos de cumplimiento, el
asesoramiento de expertos o heurística.
La palabra 'heurística' viene de la misma raíz griega como Eureka, lo que significa
'Encuentro'. Una heurística es una manera de dirigir su atención, una regla de sentido común
útil en la solución de un problema.
Condiciones de prueba deben ser capaces de vincularse de nuevo a sus fuentes en la prueba
Base, esto se llama trazabilidad.
La trazabilidad puede ser horizontal a través de toda la documentación de prueba para una
prueba del nivel de prueba determinado (por ejemplo, sistema, a partir de las condiciones de
prueba a través de casos de prueba para scripts de prueba) o vertical a través de las capas de
la documentación de desarrollo (por ejemplo, de los requisitos a los componentes).
¿Por qué es importante la trazabilidad? Considere estos ejemplos:
• Los requisitos para una función o característica dada han cambiado. Algunos de los
Ahora campos tienen diferentes rangos que se pueden introducir. ¿Qué pruebas fueron
mirando esos límites? Ahora necesitan ser cambiadas. ¿Cuántas pruebas en realidad será
afectado por este cambio en los requisitos? Estas preguntas se pueden responder fácilmente
si los requisitos se pueden rastrear fácilmente a las pruebas.
• Un conjunto de pruebas que ha corrido bien en el pasado ha empezado a tener serios
problemas. ¿Qué funcionalidad hacen estas pruebas en realidad ejercen? Trazabilidad entre
las pruebas y el requisito de que se están probando permite que las funciones o características
afectadas para identificar con mayor facilidad.
• Antes de la entrega de un nuevo lanzamiento, queremos saber si tenemos o no probado
todos los requisitos especificados en la especificación de requisitos. ¿Nosotros tenemos
la lista de las pruebas que han pasado, se puso a prueba todos los requisitos?
Después de haber identificado una lista de condiciones de prueba, es importante dar
prioridad a ellos, de modo que se identifican las condiciones de pruebas más importantes
(antes de una gran cantidad de tiempo es gastado en el diseño de casos de prueba basados en
ellos). ¡Es una buena idea para tratar de pensar del doble de las condiciones de prueba como
sea necesario a continuación, se puede tirar a la basura los menos los más importantes, y
usted tendrá un mejor conjunto de condiciones de prueba!
Tenga en cuenta que pasar algún tiempo adicional ahora, mientras que la identificación de
las condiciones de prueba, no toma mucho tiempo, ya que sólo enumerando las cosas que
podíamos probar. Esto es una buena inversión de nuestro tiempo ¡que no queremos pasar
tiempo implementar pobres pruebas!
Las condiciones de prueba se pueden identificar por los datos de prueba, así como para las
entradas de prueba y los resultados de las pruebas, por ejemplo, diferentes tipos de registro,
diferente distribución de tipos de registros dentro de un archivo o base de datos, diferentes
tamaños de los registros o campos de una grabar. Los datos de prueba deben ser diseñados
para representar los tipos más importantes de los datos, es decir, las condiciones de los
datos más importantes.
Condiciones de la prueba se documentan en el documento IEEE 829 llama una prueba
Especificaciones de Diseño, se muestra a continuación. (Este documento podría haber sido
llamado Condición de prueba Especificación, ya que los contenidos se hace referencia en la
norma son en realidad probar condiciones).
IEEE 829 STANDARD: ESPECIFICACIONES DEL MODELO DE DISEÑO DE

PRUEBA
Identificador de la prueba especificación de diseño Características para ser probados Enfoque
refinamientos Comprobación de las funciones de identificación pasa / falla criterios
4.1.4 Prueba de diseño: Especificación de casos de prueba

Condiciones de prueba pueden ser bastante vaga, que cubre toda una amplia gama de
posibilidades como vimos en nuestro ejemplo empresa de telefonía móvil (por ejemplo, un
adolescente en el mediano oeste), o una condición de prueba pueden ser más específicos (por
ejemplo, un cliente particular, masculino en pago por uso con menos de $ 10 de crédito). Sin
embargo, cuando llegamos a hacer un caso de prueba, estamos obligados a ser muy
específico; de hecho, ahora tenemos entradas específicas detalladas, no descripciones
generales (por ejemplo, Jim Green, de 17 años, la vida en Grand Rapids, Michigan, con el
crédito de $ 8,64, resultado esperado: añadir a Q4 campaña de marketing). Tenga en cuenta
que un caso de prueba cubre una serie de condiciones (Adolescente, varón, medio oeste
zona, pago por uso, y el crédito de menos de $ 10).
Para una condición de prueba de "un cliente existente ', la entrada de caso de prueba debe ser
'Jim Green', donde Jim Green ya existe en la base de datos del cliente, o parte de esta prueba
podría ser la creación de un registro de base de datos para Jim Green.
¡Un caso de prueba debe tener valores de entrada, por supuesto, pero sólo tener algunos
valores a la entrada del sistema no es una prueba! Si usted no sabe lo que el sistema de
apoyo plantea ver con las entradas, no se puede decir si la prueba es aprobada o no.
¿En caso de que estos casos de prueba detallados sean escritos? Pueden estar formalmente
documentados, como describiremos a continuación. Sin embargo, es posible probar sin
documentar un nivel de casos de prueba. Si das una aceptación del usuario experimentado
tester con un fuerte conocimiento de los negocios una lista de condiciones de prueba de
alto nivel, que probablemente podría hacer un buen trabajo de la prueba. Pero si usted
le dio la misma lista para un nuevo testers que no conocía el sistema en absoluto,
probablemente se perderá, por lo que se beneficiaría de tener casos de prueba más
detallados.
Los casos de prueba se pueden documentar como se describe en el estándar IEEE 829
estándar para Documentación de prueba. Tenga en cuenta que el contenido descrito en la
norma no todos lo hacen tienen que ser documentos físicos separados. Pero la lista de la
norma de lo que necesita pista de mantenerse es un buen punto de partida, incluso si las
condiciones de prueba y casos de prueba para una funcionalidad o característica dada
mantienen todas en un solo documento físico.
Uno de los aspectos más importantes de un instrumento es que se evalúa que el sistema
hace lo que se supone que debe hacer. Copeland dice 'En su esencia, la prueba es el
proceso de la comparación de "lo que es" con "lo que debería ser" '. [Copeland, 2003]
¡Si nos limitamos a algunas entradas y pensar ‘que fue muy divertido, supongo que el sistema
es probablemente correcto porque no se había estrellado “, ¡entonces esta es realmente una
prueba! Nosotros no lo creemos. han observado que el sistema hace lo que hace, esto no es
una prueba.
Boris Beizer refiere a esto como "la prueba para niños '[Beizer, 1990]. Puede que no sepamos
lo que es la respuesta correcta en detalle cada vez, y todavía puede obtener algún beneficio
de este enfoque a veces, pero no es realmente una prueba.
Con el fin de saber lo que el sistema debe hacer, tenemos que tener una fuente de
información sobre el comportamiento correcto del sistema, esto se llama un "oráculo" o
un oráculo de pruebas.
Esto no tiene nada que ver con las bases de datos o empresas que los fabrican. Viene de
el griego antiguo oráculo de Delfos, que supuestamente podía predecir el futuro con
infalible precisión. En realidad, sus respuestas eran tan vagas que la gente los interpretarse
en la forma que querían tal vez un poco como especificaciones de requisitos!
Una vez que un determinado valor de entrada ha sido elegido, el testers necesita
determinar qué resultado se espera de esa entrada y documentarla como parte del caso
de prueba.
Los resultados esperados incluyen información que aparece en una pantalla en respuesta a
una entrada, sino que también incluyen cambios en los datos y / o estados, y cualquier otra
consecuencia de la prueba (por ejemplo, una carta a imprimirse durante la noche).
¿Qué pasa si no tomamos una decisión en los resultados esperados antes de correr una
prueba? Podemos echar un vistazo a lo que produce el sistema y probablemente notará si algo
era absolutamente incorrecta. Sin embargo, probablemente no notar pequeñas diferencias en
cálculos o resultados que parecían mirar bien (es decir, son plausibles). De modo que lo haría
concluir que la prueba había pasado, cuando en realidad el software no ha dado el resultado
correcto. Las pequeñas diferencias en un cálculo pueden sumar a algo muy importante más
adelante, por ejemplo, si los resultados se multiplican por un factor grande.
Lo ideal sería que los resultados esperados se pueden predecir antes de que se ejecute
la prueba a continuación, su evaluación de si o no el software hizo lo correcto será más
objetiva.
Para algunas aplicaciones puede que no sea posible predecir o saber exactamente un resultado
esperado; que sólo podemos hacer un «control de razonabilidad '. En el caso de que tengamos
un "oráculo parcial" sabemos cuándo algo está muy mal, pero probablemente tendría que
aceptar algo que parecía razonable. Un ejemplo es cuando un sistema ha sido escrito para
calcular algo donde puede que no sea posible producir manualmente los resultados esperados
en un plazo de tiempo razonable porque los cálculos son tan complejos.
Además de los resultados esperados, en el caso de prueba también se especifica el entorno y
otras cosas que deben estar en su lugar antes que la prueba se puede ejecutar (la pre-
condiciones) y las cosas que deberían aplicarse cuando finalice la prueba (la pos-
condiciones).
IEEE 829 STANDARD:
CASO DE PRUEBA ESPECIFICACIONES MODELO
Identificador de la prueba especificación de Las especificaciones de salida
caso
Elementos de prueba necesidades ambientales
Las especificaciones de entrada requisitos de procedimiento especiales
dependencias Intercase
El caso de prueba también se debe decir por qué existe, es decir, el objetivo de la prueba
es o parte de las condiciones de prueba que se está ejercitando (trazabilidad). Los casos de
prueba pueden ahora ser priorizadas para que los casos de prueba más importantes se
ejecutan primero, y casos de prueba de baja prioridad se ejecutan después, o incluso no se
ejecutan en absoluto. Esto puede reflejar las prioridades ya establecidas para las condiciones
de prueba o la prioridad puede ser determinado por otros factores relacionados con los casos
de prueba específicos, tales como un valor de entrada, que ha demostrado ser problemático
en el pasado, el riesgo asociado con la prueba, o la secuencia más sensible de la ejecución de
las pruebas. Capítulo 5 da más detalles de la prueba basado en el riesgo.
Los casos de prueba deben ser detalladas por lo que podemos comprobar con exactitud los
resultados y sabemos que tenemos exactamente la respuesta adecuada del sistema. Si las
pruebas han de ser automatizadas, la herramienta de prueba tiene que saber exactamente qué
comparar con el sistema la salida.
4.1.5 Prueba de aplicación: Especificación de los procedimientos de prueba o secuencias

de comandos
El siguiente paso consiste en agrupar los casos de prueba de una manera sensata para la
ejecución de ellos y para especificar los pasos secuenciales que hay que hacer para ejecutar
la prueba. Por ejemplo, un conjunto de pruebas simples que cubren la amplitud del
sistema pueden formar una suite de regresión, o la totalidad de las pruebas que explorar
el funcionamiento de una funcionalidad o característica dada en profundidad pueden
ser agrupados para ser ejecutado juntos.
Puede ser necesario ejecutar en una secuencia particular algunos casos de prueba. Por
ejemplo, una prueba puede crear un nuevo registro de cliente, modificar dicho registro recién
creado y luego eliminarlo. Estas pruebas se deben ejecutar en el orden correcto, o no van a
probar lo que están destinados a probar.
El documento que describe los pasos a seguir en la ejecución de un conjunto de (pruebas y

especifica el orden ejecutable de las pruebas) se llama un procedimiento de prueba en el
estándar IEEE 829, y se suele denominar también como un script de prueba. Podría ser
llamado una secuencia de comandos de prueba manual para las pruebas que están destinadas
a ser ejecutadas manualmente en lugar de utilizar una herramienta de ejecución de la
prueba. escritura de la prueba también se utiliza para describir las instrucciones a una
herramienta de ejecución de la prueba. Una secuencia de comandos de automatización se
escribe en un lenguaje de programación que la herramienta puede interpretar. (Esto es un
automatizado procedimiento de prueba.) Véase el capítulo 6 para obtener más información
sobre éste y otros tipos de las herramientas de prueba.
Los procedimientos de prueba, o scripts de prueba, se forman entonces en una ejecución de

la prueba horario que especifica qué procedimientos se van a ejecutar en primer lugar, una
especie de guía. El plan de prueba diría cuando una secuencia de comandos dada se debe
ejecutar y por quién. El horario puede variar en función de los nuevos riesgos que afectan
a la percepción, la prioridad de una secuencia de comandos que se ocupa del riesgo, por
ejemplo. La lógica y las técnicas de dependencia entre las secuencias de comandos
también se tendrían en cuenta la hora de programar las secuencias de comandos. Por
ejemplo, una secuencia de comandos de regresión siempre puede ser la primera en ser
ejecutado cuando llega una nueva versión del software, como una prueba de humo o
prueba de cordura.
Volviendo a nuestro ejemplo de la cámara de marketing de la empresa de telefonía móvil,

que puede tener algunas pruebas para configurar los clientes de diferentes tipos en la base de
datos. Puede ser sensato para ejecutar la totalidad de la configuración de un grupo de pruebas
primero. Así que nuestro primer procedimiento de prueba implicaría la creación de un
número de clientes, incluyendo Jim Green, en la base de datos.
Procedimiento de la prueba DB15: Configuración de los clientes para la campaña de

marketing Y.
Paso 1: Abrir base de datos con el privilegio de escritura
Paso 2: Configuración de cliente Bob,maculino, de 62 años, Hudsonville, contrato
Paso 3: Configurar el cliente Jim Green masculino, 17, Grand Rapids, Pago por uso, $ 8.64
Etapa 4: ...
entonces podemos tener otro procedimiento de prueba que ver con la campaña de
marketing:
Procedimiento de la prueba MC03: Ofertas especiales para adolescentes bajo crédito
Paso 1: Obtener datos de la base de datos de Jim Green
Paso 2: Enviar mensaje de texto que ofrece el doble de crédito
Paso 3: Jim Green solicita crédito de $ 20, $ 40 acreditarán
Escribir el procedimiento de prueba es otra oportunidad para dar prioridad a las pruebas, a
asegurar que la mejor prueba se realiza en el tiempo disponible. Una buena regla de oro
es "encontrar las primeras cosas de miedo”. Sin embargo, la definición de lo que es 'miedo'
depende en el negocio, sistema o proyecto. Por ejemplo, ¿es peor para elevar Bob
límite de crédito Fundadores cuando él no es un buen riesgo de crédito (que no puede pagar
por el crédito que pidió) o negarse a aumentar su límite de crédito cuando él es un buen
crédito riesgo (que puede ir a otro lugar para su servicio de teléfono y perder la oportunidad
de una gran cantidad de ingresos a partir de él).
IEEE 829 STANDARD: ESPECIFICACIONES DEL MODELO DE

PROCEDIMIENTO DE PRUEBA
Prueba de identificador de especificación del procedimiento
Propósito
Requisitos especiales
pasos del procedimiento
4.2 CATEGORÍAS DE LAS TÉCNICAS DE DISEÑO DE PRUEBA

1 recordaremos que tantas razones basados en la especificación (caja negra) y
estructura basado en (caja blanca) son útiles para el diseño de pruebas de caja, y la lista
de las técnicas comunes para cada uno. (KL)
2 Explicar las características y diferencias basada en la especificación las pruebas, las
pruebas basadas en la estructura y las pruebas basadas en la experiencia. (K2)
En esta sección vamos a ver los diferentes tipos de técnicas de diseño de pruebas, cómo
Se utilizan y cómo se diferencian. Los tres tipos o categorías son distinguidos por su
fuente primaria: una especificación, la estructura del sistema o componente, o la
experiencia de una persona. Todas las categorías son útiles y los tres son
complementario.
En esta sección, busque las definiciones de los términos del glosario: prueba de recuadro
negro técnicas de diseño, basadas en la experiencia, las técnicas de diseño de pruebas
técnicas de diseño de pruebas basado en la especificación, prueba basada en la
estructura técnicas de diseño y técnicas de diseño de pruebas de caja blanca.
4.2.1 Introducción
Hay muchos tipos diferentes de técnicas de pruebas de software, cada uno con su propia
fortalezas y debilidades. Cada técnica individual es buena para encontrar tipos de
defectos particulares y relativamente pobres en la búsqueda de otros tipos. Por ejemplo,
una técnica que explora los límites superior e inferior de una gama única de entrada tiene
más probabilidades de encontrar defectos de contorno que los defectos asociados con la
combinación de entradas. Del mismo modo, las pruebas realizadas en las diferentes etapas
en el ciclo de vida de desarrollo de software van a encontrar diferentes tipos de defectos; es
la prueba de componentes más probabilidades de encontrar defectos lógicos de codificación
que no sean defectos de diseño del sistema.
Cada técnica de pruebas se encuentra en una de un número de categorías diferentes.
En términos generales hay dos categorías principales, estáticas y dinámicas. Técnica
estática se discuten en el Capítulo 3. Las técnicas dinámicas se subdividen en tres
categorías más: basada en la especificación (caja negra, también conocido como técnica
conductual), basado en la estructura (caja blanca o técnicas estructurales) y la basada
en la experiencia. Las técnicas basadas en la especificación incluyen tanto funcionales
como no técnicas funcionales (es decir, las características de calidad). Las técnicas cubiertas
en el plan de estudios se resumen en la Figura 4.1.
4.2.2 técnicas de pruebas estáticas

Como vimos en el capítulo 3, las técnicas de pruebas estáticas no ejecutan el código siendo
examinado y se utilizan generalmente antes de las pruebas que ejecutan el software.
Podrían ser llamados técnicas no ejecución. La mayoría de las técnicas de pruebas estáticas
se puede utilizar para "prueba" cualquier forma de documento que incluye código
fuente, diseño documento y modelos, especificaciones funcionales y especificaciones de
requisitos.
Sin embargo, el "análisis estático" es un tipo de herramienta compatible de pruebas estáticas
que se centra en las pruebas de lenguajes formales y por lo tanto a menudo se realiza para
probar estáticamente código fuente.
4.2.3 (Caja negra) técnicas de prueba basados en la especificación
La primera de las técnicas de pruebas dinámicas que vamos a ver es las técnicas de pruebas
basadas en la ESPECIFICACIÓN. Estos también son conocidos como "Caja negra" o
técnicas de prueba input / output, porque consideran que el software como una caja negra
con entradas y salidas, pero no tienen ningún conocimiento de cómo funciona el sistema o
componente se estructura dentro de la caja. En esencia, el testers está concentrando en lo
que hace el software, no cómo lo hace.
Nótese que la definición menciona tanto pruebas funcionales como no funcionales. Las
pruebas funcionales se ocupan de lo que hace el sistema, sus características o
funciones. pruebas no funcionales se ocupa de examinar qué tan bien el sistema hace
algo, en lugar de lo que hace. aspectos no funcionales (también conocido como las
características de calidad o atributos de calidad) incluyen el rendimiento, facilidad de uso,
portabilidad, facilidad de mantenimiento, etc. Las técnicas para poner a prueba estos aspectos
de procedimiento no-funcionales son menos formales que los de otra categoría como los
exámenes reales son más dependientes del tipo de sistema, lo que hace y los recursos
disponibles para las pruebas.
Pruebas no funcionales son parte del programa de estudios y también se trata en el capítulo
2. Existen técnicas para derivar las pruebas no funcionales [gilb, 1988], [Testing Normas],
pero que no estén recogidas en el nivel de infraestructura.
Categorización de las pruebas en caja blanca y caja negra se menciona en varios pruebas de
libros, incluyendo [Beizer, 1990] y [Copeland, 2003].
4.2.4 (caja blanca) técnicas de prueba basados en estructuras

técnicas de pruebas basadas en la estructura (que también son dinámicos y no estáticos)
utilizan la estructura interna del software para derivar casos de prueba. Son
comúnmente llamada técnicas 'caja blanca' ''caja de vidrio o (lo que implica que usted
puede ver en el sistema), ya que requieren el conocimiento de cómo se implementa el
software, que es, cómo funciona. Por ejemplo, una técnica estructural puede estar preocupado
con el ejercicio de bucles en el software. Los diferentes casos de prueba se pueden derivar de
ejercer el bucle una vez, dos veces, y muchas veces. Esto puede realizarse
independientemente de la funcionalidad del software.
4.2.5 técnicas de pruebas basadas en la experiencia

En las técnicas basadas en la experiencia, el conocimiento, las habilidades y los
antecedentes de las personas son el principal contribuyente a las condiciones de prueba
y casos de prueba. La experiencia de ambos técnicos y de negocio es importante, ya que
aportan diferentes perspectivas al análisis de la prueba y el proceso de diseño. Debido a la
experiencia previa con similares sistemas, pueden tener una visión de lo que podría ir mal, lo
que es muy útil para las pruebas.
4.2.6 Donde aplicar las diferentes categorías de técnicas

Las técnicas basadas en las especificaciones son apropiadas en todos los niveles de la
prueba (pruebas de componente a través de las pruebas de aceptación) cuando existan
especificaciones. Cuando sistema o pruebas de aceptación, la especificación de
requerimientos que realice o su especificación funcional puede constituir la base de las
pruebas. Al realizar pruebas de componente o integración, una especificación de documento
de diseño o de bajo nivel constituye la base de las pruebas.
Las técnicas basadas en estructura también se pueden utilizar en todos los niveles de la
prueba.
Los desarrolladores utilizan técnicas basadas en la estructura de las pruebas de componentes
y pruebas de integración, especialmente cuando existe un buen apoyo para la herramienta de
código de cobertura. Las técnicas basadas en estructura también se utilizan en el sistema y la
pruebas aceptación, pero las estructuras son diferentes. Por ejemplo, la cobertura de menú
opciones o transacciones comerciales importantes podrían ser el elemento estructural
en el sistema o pruebas de aceptación.
Técnicas basadas en las especificaciones y técnicas basadas en la experiencia se utilizan
para complementar las técnicas basadas en la estructura, y también se utilizan cuando
no hay especificación, o si la especificación es inadecuada o fuera de fecha. Este puede
ser el único tipo de técnica utilizada para sistemas de bajo riesgo, pero este enfoque puede
ser particularmente útil bajo extrema presión de tiempo, de hecho, este es uno de los factores
que conduce a la prueba exploratoria.
4.3 TECNICAS BASADAS EN ESPECIFICACIONES O EN CAJA NEGRA

1 casos de prueba de escritura a partir de modelos dados utilizando el software siguiente
para diseño de prueba técnicas. (K3)
a) partición de equivalencia;
b) análisis de valores límite;
c) tablas de decisión;
d) pruebas de transición de estado.
2 Entender el propósito principal de cada una de las cuatro técnicas, qué nivel y el tipo
de prueba podría utilizar la técnica, y cómo la cobertura puede ser mesurado. (K2)
3 Comprender el concepto de pruebas de casos de uso y sus beneficios. (K2)
En esta sección vamos a ver en detalle las cuatro tecnicas de pruebas basados en la
especificación técnicas de caja negra. Estas cuatro técnicas son K3, significa esto que tiene
que ser capaz de utilizar estas técnicas para el diseño de casos de prueba. Nosotros También
cubriremos brevemente (no a nivel K3) la técnica basada en la especificación de utilizar las
pruebas de caso. En la Sección 4.4, vamos a ver la estructura basada en K3 técnicas.
En esta sección, busque las definiciones de los términos del glosario: valores en la frontera
análisis, pruebas de la tabla de decisiones, la partición de equivalencia, estado de
pruebas de transición y las pruebas de caso de uso.
Las cuatro técnicas basadas en la especificación vamos a cubrir en detalle son:
• partición de equivalencia;
• análisis de valores límite;
• tablas de decisión;
• Prueba de transición de estado.
Tenga en cuenta que vamos a discutir los dos juntos por primera vez, ya que son muy
relacionado.
4.3.1 Equivalencia de partición y análisis de valores límite
Partición de equivalencia
Equivalencia de partición (EP) basada en la especificación de la técnica de caja negra. Se
puede aplicar en cualquier nivel de la prueba y es a menudo una buena técnica a utilizar
por primera vez. Es un enfoque de sentido común de la prueba, tanto es así que la mayoría
de los testers que la practican de manera informal a pesar de que no se den cuenta. Sin
embargo, mientras que es mejor utilizar la técnica de manera informal que no en todos, es
mucho mejor utilizar la técnica de una manera formal para alcanzar todos los beneficios que
puede ofrecer.
Esta técnica se puede encontrar en la mayoría de los libros de pruebas, incluido [Myers, 1979]
y [Copeland, 2003].
La idea detrás de la técnica consiste en dividir (es decir, a la Partición) un conjunto de
pruebas en grupos o conjuntos que se pueden considerar de las mismas condiciones (es decir,
el sistema de debe manejarlos de forma equivalente), por lo tanto "partición de equivalencia'.
Particiones de equivalencia también se conocen como clases de equivalencia, los dos
términos significan exactamente lo mismo.
La técnica particionamiento de equivalencia, requiere entonces que necesitamos pruebas para

sólo una condición de cada partición. Esto se debe a que estamos suponiendo que todas las
condiciones en una partición serán tratados de la misma manera por el software. Si una
condición en una partición funciona, asumimos que todas las condiciones en las partes van a
funcionar, y por lo tanto no tiene mucho sentido en la prueba de cualquiera de estos otros.
Por el contrario, si una de las condiciones en una partición no funciona, entonces se asume
que ninguna de las condiciones en que la partición va a funcionar así que de nuevo hay poco
sentido hacer análisis más en esa partición. Por supuesto, estos están simplificando que
pueden no ser siempre correcta, pero si las escribimos, por lo menos, da a la gente la
oportunidad de desafiar las suposiciones que hemos hecho y espero ayudar a identificar mejor
las particiones. Si tiene tiempo, es posible que desee probar más de un valor a partir de una
partición, especialmente si desea confirmar una selección de entradas de usuario típicos.
Por ejemplo, una cuenta de ahorros en un banco gana una tasa de interés diferente
dependiendo del saldo de la cuenta. Con el fin de probar el software que calcula los intereses
adeudados, podemos identificar los rangos de valores de equilibrio que ganan las diferentes
tasas de interés. Por ejemplo, si un equilibrio en el rango de $ 0 a $ 100 tiene una tasa de
interés del 3%, un saldo de más de $ 100 y hasta $ 1000 tiene una interfaz 5% tasa y saldos
de $ 1000 y por encima tienen una tasa de interés del 7%, tendríamos inicialmente que
identificar tres particiones de equivalencia válidos y no válidos como una partición mostrado
a continuación.
Tenga en cuenta que hemos identificado cuatro particiones aquí, a pesar de que la
especificación sólo menciona tres. Esto ilustra una tarea muy importante del testers no sólo
lo probamos lo que está en nuestra especificación, pero también pensamos en las cosas que
no se han especificado. En este caso se ha pensado en la situación en la que el equilibrio es
menor que cero. No hemos (todavía) identificó una partición no válida en la derecha, pero
esto también sería una buena cosa a tener en cuenta. Con el fin de identificar dónde la
partición termina el 7%, tendríamos que saber cuál es el saldo máximo de esta cuenta (que
puede no ser fácil de encontrar). En nuestro ejemplo, hemos dejado esto abierto por el
momento. Tenga en cuenta que la entrada no numérica es también una partición no válida
(Por ejemplo, la letra "a"), pero sólo se discuten las particiones numéricas por ahora.
Hemos hecho una suposición aquí sobre lo que es la diferencia más pequeña entre dos
valores. Hemos asumido dos cifras decimales, es decir, $ 100.00 pero podría haber asumido
cero decimales (es decir, $ 100) o más de dos decimales lugares (por ejemplo, $ 100,0000)
En cualquier caso, es una buena idea para indicar sus supuestos a continuación, otras personas
pueden verlos y le permiten saber si son correctas o no.
En el diseño de los casos de prueba de este software que se aseguraría de que las tres
particiones de equivalencia válidos son cada vez cubiertas, y también pondría a prueba la
partición no válida al menos una vez. Así, por ejemplo, podemos elegir calcular el interés
sobre los saldos Pu- $ 10.00 $ 50.00 $ 260.00 y $ 1,348.00. Si no teníamos identificado
específicamente estas particiones, es posible que al menos uno de ellos se podría haber
perdido a expensas de probar otras varias veces. Tenga en cuenta que también podríamos
aplicar la partición de equivalencia a las salidas también.
En este caso tenemos tres tipos de interés: 3%, 5% y 7%, más el error mensaje para la
partición no válida (o particiones). En este ejemplo, las salidas de particiones se alinean
exactamente con las particiones de entrada.
¿Cómo le podría probar esto sin pensar en las particiones? Un testers ingenuo (vamos a
llamar a él Robbie) podría haber pensado que un buen conjunto de pruebas se poner a prueba
todos los $ 50. Eso daría a las siguientes pruebas: $ 50.00 $ 100.00 $ 150.00, $ 200.00 $
250.00 ... decir hasta $ 800.00 (continuación Robbie habría conseguido cansado de él y pensó
que suficientes pruebas se han llevado a cabo). Pero mira lo que Robbie ha probado: ¡sólo
dos de cada cuatro particiones! Así que si el sistema no correspondiente a manejar un saldo
negativo o un saldo de $ 1000 o más, que no lo haría han encontrado que estos defectos por
lo que el enfoque ingenuo es menos eficaz a la equivalencia de particionamiento. ¡Al mismo
tiempo, Robbie tiene cuatro veces más pruebas (16 pruebas en comparación con nuestras
cuatro pruebas utilizando particiones de equivalencia), por lo que también es mucho menor
eficiente! Es por esto que decimos que el uso de técnicas como esta hace que las pruebas
tanto más eficaz y más eficiente.
Tenga en cuenta que cuando decimos que una partición es "no válida", no significa que
representa un valor que no puede ser introducida por un usuario o un valor que el usuario no
está planteado para entrar. Sólo significa que no es uno de los aportes esperados de este
campo particular. El software debe manejar correctamente los valores de la inválida
partición, al responder con un mensaje de error como "El balance debe ser al menos $ 0.00 '.
Tenga en cuenta también que la partición no válida puede no ser válido sólo en el contexto
de abono pagos de interés. Una cuenta que está sobregirada requerirá algún tipo de acción
diferente.
análisis de valores límite

Análisis de valores límite (BVA) se basa en las pruebas en los límites entre
particiones. Si alguna vez has hecho 'verificación de rango', que estaba probablemente se
está utilizando la técnica de análisis de valores límite, incluso si usted no era consciente de
ello. Tenga en cuenta que ambos tienen límites válidos (en las particiones válidas) y los
límites válidos (en las particiones no válidos).
A modo de ejemplo, considere una impresora que tiene una opción de entrada del número
de copias a realizar, de 1 a 99.
Para aplicar análisis de valores límite, tomaremos el mínimo y máximo (Límite) valores de
la partición válida (1 y 99 en este caso) junto con el primero o el último valor,
respectivamente, en cada una de las particiones no válidas adyacentes a la partición válida (0
y 100 en este caso). En este ejemplo tendríamos tres pruebas de equivalencia de partición
(uno de cada una de las tres particiones) y cuatro pruebas de contorno.
Considere el sistema bancario se describe en la sección sobre la equivalencia
particionamiento.
Debido a que los valores límite se definen como aquellos valores en el borde de una partición,
hemos identificado los siguientes valores límite: - $ 0.01 (un inválido valores en la frontera,
ya que está en el borde de una partición no válido), $ 0,00, $ 100.00 $ 100.01, $ 999.99 y $
1000.00 todos los valores límite válidos.
Así que mediante la aplicación de análisis de valores límite tendremos seis pruebas para la
frontera valores. Compara lo que nuestro modelo de prueba ingenua Robbie había hecho;
hizo realidad golpeó a uno de los valores límite ($ 100) a pesar de que era más por accidente
que el diseño. Así que además de las pruebas sólo la mitad de las particiones, Robbie sólo ha
probado uno sexta parte de los límites (por lo que será menos eficaz en la búsqueda de
cualquier frontera defectos). Si tenemos en cuenta todas nuestras pruebas, tanto para la
partición de equivalencia y el análisis de valores límite, las técnicas nos dan un total de nueve
pruebas, en comparación a los 16 que Robbie tenía, así que estamos siendo
considerablemente más eficiente, así como siendo tres veces más eficaces (prueba cuatro
particiones y seis obligadas, por lo que las condiciones de 10 en total en comparación con los
tres).
Tenga en cuenta que, en el ejemplo de los intereses bancarios, tenemos las particiones válidas
al lado de otras particiones válidas. Si nos vamos a considerar un límite válido para el interés
del 3% tasa, tenemos - $ 0,01, pero ¿qué pasa con el valor justo por encima de $ 100.00? El
valor de $ 100.01 no es un límite inválido; en realidad es un límite válido porque cae en una
partición válida. Así que la partición para 5%, por ejemplo, no tiene inválido los valores de
límites asociados con las particiones próximos a él.
Una buena manera de representar las particiones y los límites válidos y no válidos se
encuentra en una tabla como la Tabla 4.1:
TABLA 4.1 particiones de equivalencia y límites
Al mostrar los valores de la tabla, se puede observar que hay un máximo especificado para
la tasa de interés del 7%. Ahora nos gustaría saber cuál es el valor máximo es de un saldo de
cuenta, por lo que podemos probar ese límite.
Esto se llama una "frontera abierta", porque uno de los lados de la partición queda abierto,
es decir, no se define. Pero eso no quiere decir que podemos ignorarlo, debemos todavía
tratar de probarlo, pero ¿cómo? fronteras abiertas son más difíciles de probar, pero hay
maneras de abordarlas. ¡En realidad, la mejor solución al problema consiste en averiguar cuál
es el límite y debe especificarse como! Un método consiste en volver a la especificación de
ver si un máximo ha indicado en otro lugar para una cantidad de equilibrio. Si así, entonces
sabemos lo que nuestro valor límite es. Otro enfoque podría ser la de investigar otras áreas
conexas del sistema. Por ejemplo, el campo que sostiene la figura saldo de la cuenta puede
ser sólo seis cifras decimales más dos figuras. Esto daría un saldo de la cuenta máxima de $
999 999.99, así que podría usar eso como nuestro máximo valor límite. Si realmente no
podemos encontrar nada de lo que debe ser este límite, entonces es probable que utilizaremos
un enfoque intuitivo basado en la experiencia para investigar diversos valores grandes
tratando para hacer que falle.
Podríamos también tratar de averiguar sobre el límite inferior abierto - ¿cuál es el menor
saldo negativo? A pesar de que se han omitido esto desde nuestro ejemplo, de exponerlo en
la tabla muestra que se han omitido, así nos ayuda a ser más a fondo si queríamos ser.
En representación de las particiones y los límites de una tabla como ésta también hace que
sea más fácil para ver si está o no han probado cada uno (si ese es su objetivo).
La extensión de la partición de equivalencia y análisis de valores límite

Hasta aquí, mediante el uso de condiciones de PE y BVA que hemos identificado que podría
ser probadas, es decir, particiones y los valores límite. Las técnicas se utilizan para identificar
condiciones con prueba, lo que podría estar en un nivel bastante alto (por ejemplo, "cuenta
de bajo interés ') o en un nivel de detalle (por ejemplo, "valor de $ 100.00"). Hemos estado
buscando en la aplicación de estas técnicas a rangos de números. Sin embargo, también
podemos aplicar las técnicas a otras cosas.
Por ejemplo, si se reserva un vuelo, usted tiene una opción de Economía / autocar, entradas
Premium Economy, Business o Primera Clase. cada uno de estos es una partición de
equivalencia en su propio derecho y deben ser probados, pero no tiene sentido hablar de
límites para este tipo de partición, que es una colección de cosas válidos. La partición no
válida sería un intento de escribir cualquier otro tipo de clase de vuelo (por ejemplo,
«Personal»). Si este campo se implementa utilizando una lista desplegable, entonces no
debería ser posible escribir cualquier otra cosa, pero siendo una buena prueba para probar al
menos una vez en algún campo desplegable. Cuando se esté analizando, la base de prueba
(por ejemplo, una especificación de requisitos), la partición de equivalencia puede ayudar a
identificar dónde una lista desplegable sería apropiada.
Cuando se trata de identificar un defecto, puede probar con varios valores en una
partición.
Si esto se traduce en un comportamiento diferente en el que esperaba que fuera la misma, a
continuación, puede haber dos (o más) particiones en el que inicialmente se pensó que había
solo uno.
Podemos aplicar la partición de equivalencia y análisis de valores límite para todos los
niveles de prueba. Los ejemplos aquí estaban a un nivel bastante detallado, probablemente,
la mayor parte apropiada en las pruebas de componentes o en el ensayo detallado de una sola
pantalla.
A nivel del sistema, por ejemplo, podemos tener tres configuraciones básicas que nuestros
usuarios pueden elegir a la hora de establecer sus sistemas, con un número de opciones para
cada configuración. Las configuraciones básicas del sistema podrían ser administrador,
gerente y el enlace al cliente. Estos representan tres particiones de equivalencias que podrían
ser probados. Podríamos tener graves problemas si nos olvidamos de probar la configuración
para el administrador del sistema, por ejemplo.
También podemos aplicar la partición de equivalencia y análisis de valores límite más de una
vez para el mismo elemento de la especificación. Por ejemplo, si un sistema interno de
teléfono para una empresa con 200 teléfonos tiene los números de extensión de 3 dígitos 100-
699, podemos identificar los siguientes particiones y límites:
• Los dígitos (caracteres 0 a 9) con la partición no válida que no contienen dígitos
• número de dígitos, 3 (valores límite por lo que no válidas de 2 dígitos y 4 dígitos)
• rango de números de extensión, 100 a 699 (valores límite así que no válidas de 099y 700)
• extensiones que están en uso y las que no lo son (dos particiones válidas, no hay límites)
• los números de extensión menor a mayor y que están en uso también se podrían usar como
valores de límite
Un caso de prueba podría probar más de una de estas particiones / límites. Por ejemplo,
extensión 409, que está en uso pondría a prueba cuatro particiones válidas: dígitos, el número
de dígitos, el rango válido, y la partición 'en uso'. También pone a prueba los valores límite
para los dígitos, 0 y 9.
¿Cuántos casos de prueba qué tenemos que probar todas estas particiones y límites, tanto
válidos y no válidos? Necesitaríamos un no-dígitos, a 2 dígitos y número de 4 dígitos, los
valores de 99, 100, 699 y 700, una extensión que no está en utilizar, y, posiblemente, las
extensiones de menor a mayor y en uso. Se trata de diez u once años de casos de prueba el
número exacto dependerá de lo que se podría combinar en un solo caso de prueba.
Compare esto con el ejemplo número de un dígito en la Sección 1.1.6. Aquí nosotros
encontramos que teníamos 68 pruebas sólo para probar un campo de un dígito, si tuviéramos
que probarlo a fondo. En el particionado equivalencia y análisis de valores límite ayuda
identificar las pruebas que tienen más probabilidades de encontrar defectos, y para utilizar
menos casos de prueba para encontrarlos. Esto es porque el contenido de una partición es
representativo de todos de los valores posibles. En lugar de prueba de los diez dígitos
individuales, probamos uno de cada medio (por ejemplo, 4) y los dos bordes (0 y 9). En lugar
de probar todos los posibles caracteres no numérico, uno puede representar a todos ellos. Así
que tenemos cuatro pruebas (En lugar de 68) para un campo de un dígito.
Como hemos mencionado anteriormente, también podemos aplicar estas técnicas a la salida
particiones. Considere la siguiente extensión a nuestro ejemplo del tipo de interés bancario.
Supongamos que un cliente con más de una cuenta puede tener un extra de 1% interés en esta
cuenta si tienen al menos $ 1000 en él. Ahora tenemos dos posibles valores de salida (7% de
interés y un 8% de interés) para el mismo saldo de la cuenta, por lo que hemos identificado
otra condición de prueba (tasa de interés del 8%). (También han identificado la misma
condición de salida examinado con más clientes de una cuenta, que es una partición de tipos
de cliente.)
partición de equivalencia se puede aplicar a diferentes tipos de entrada también.
Nuestros ejemplos se han concentrado en las entradas que se escriben de un usuario (humana)
cuando se utiliza el sistema. Sin embargo, los sistemas reciben datos de entrada de otras
fuentes, así, como de otros sistemas por medio de alguna de las interfaces. Esta es también
un buen lugar para buscar las particiones (y los límites). Por ejemplo, el valor de un
parámetro de la interfaz puede caer en particiones de equivalencia válidos y no válidos. Este
tipo de defecto es a menudo difícil de encontrar en las pruebas una vez que las interfaces se
han unido entre sí, por lo que es particularmente útil para aplicar en las pruebas de integración
(ya sea integración de componentes o la integración del sistema).
análisis del valor límite puede ser aplicado a la totalidad de una cadena de caracteres (por
ejemplo, un nombre o dirección). El número de caracteres de la cadena, por ejemplo, entre 1
y 30 caracteres es la partición válida límite de 1 y 30. Los límites serían válidos 0 personajes
(nulo, simplemente pulse la tecla de retorno) y 31 caracteres. Ambas deberían producir un
mensaje de error.
Particiones también pueden identificarse para la creación de datos de prueba. Si hay
diferentes tipos de registro, será la prueba más representativa si se incluye un registro de
datos de cada tipo. El tamaño de un registro es también una partición con límites, así que
podría incluir registros máximos y mínimos de tamaño en la base de datos de prueba.
Si usted tiene algún conocimiento acerca de cómo el interior esté organizado físicamente,
puede ser capaz de identificar algunos límites ocultos. Por ejemplo, si un bloque de
almacenamiento de desbordamiento se utiliza cuando se introducen más de 255 caracteres en
un campo, las pruebas de contorno incluiría 255 y 256 caracteres en que campo. Esto puede
ser al borde de pruebas de caja blanca, ya que tenemos cierto conocimiento de cómo está
estructurado los datos, pero no importa cómo clasificamos las cosas, siempre como nuestra
prueba es eficaz en la búsqueda de defectos. No se colgó en una fina distinción acaba de
hacer lo que la prueba tiene sentido, sobre la base de lo que sabe. Un viejo proverbio chino
dice: "No importa si el gato es blanco o negro; todas lo que importa es que el gato cace
ratones".
Con el análisis de valores en la frontera, pensamos en la frontera como una línea divisoria
entre dos cosas. Por lo tanto, tenemos un valor a cada lado de la frontera (pero el límite en sí
no es un valor).
En cuanto a los valores de nuestro ejemplo impresora, 0 es inválida en una partición, 1

y 99 están en la partición válida y 100 está en la otra partición inválida. Entonces el
límite está entre los valores de 0 y 1, y entre los valores de 99 y 100. Hay una escuela de
pensamiento que considera un valor real como un valor límite. Por tradición, estos son los
valores de la partición válida (es decir, los valores especificado). Este enfoque requiere
entonces tres valores para todos los límites de dos, por lo que tendría 0,1 y 2 para el límite
izquierdo, y 98, 99 y 100 del límite derecha en este ejemplo. Los valores límite se dice que
son "en y, o bien lado de la frontera 'y el valor que es "en" generalmente se toma el límite
para estar en la partición válida.
Tenga en cuenta que Beizer habla acerca de las pruebas de dominio, una generalización
de particionamiento de equivalencia, con límites de tres valores. Se hace una distinción
entre las fronteras abiertas y cerradas, donde un contorno cerrado es aquel en el punto
se incluye en el dominio. Por lo que la convención es válida para la partición tener
límites cerrados. Usted puede saber que no lo hace tiene que saber esto para el
examen! British Standard 7925-2 estándar para Software de pruebas de componentes
también define un enfoque de tres valores en Boundary análisis de valor.
Entonces, ¿cuál es el mejor enfoque? Si se utiliza el enfoque de dos valores juntos con la
partición de equivalencia, que son igualmente eficaces y poco más eficiente que el enfoque
de tres valores. (No vamos a entrar en detalles aquí, pero esto se puede demostrar.) En este
libro vamos a utilizar el valor de dos enfoques. En el examen, es posible que tenga una
pregunta basada en cualquiera de los dos valores o el enfoque de tres valores, pero debe
quedar claro cuál es la correcta elección, en cualquier caso.
El diseño de casos de prueba

Una vez identificadas las condiciones que desea probar, en este caso mediante el uso de
Equivalencia de particionamiento y análisis de valores límite, el siguiente paso es
diseñar los casos de prueba. Las condiciones de prueba que pueden ser cubiertos en un solo
caso de prueba, Se necesitarán el menor número de casos de prueba con el fin de cubrir todas
las condiciones. Esto es por lo general el mejor enfoque para tomar las pruebas positivas y
para las pruebas que usted razonablemente confía que las va a pasar. Sin embargo, si no pasa
la prueba, entonces tenemos que averiguar por qué fallo, cuál de las condiciones de prueba
que manejada de forma incorrecta. Tenemos que conseguir un buen equilibrio entre cubrir
demasiados y pocas condiciones de prueba en nuestras pruebas.
Veamos cómo un caso de prueba puede cubrir una o más condiciones de
prueba. Utilizando el ejemplo saldo bancario, nuestra primera prueba podría ser de un
nuevo cliente con un saldo de $ 500. Esto cubriría un equilibrio en la partición desde $
100.01 a $ 999.99 y una partición de salida de una tasa de interés del 5%. También estaríamos
cubriendo otras particiones que aún no hemos explicado. por ejemplo, un cliente válido, un
nuevo cliente, un cliente con una sola cuenta, etc. Todas las particiones cubierto en esta
prueba son las particiones válidas.
Cuando llegamos a probar particiones no válidas, la opción más segura es, probablemente,
para tratar de cubrir sólo una condición de prueba válida por caso de prueba. Esto es porque
los programas pueden detener el procesamiento de entrada tan pronto como se encuentran
con el primer problema. Así que, si usted tiene un nombre no válido al cliente, dirección no
válida, y el equilibrio válido, se puede recibirá un mensaje de error que dice "entrada no
válida" y usted no sabe si la prueba ha detectado sólo una entrada válida o todos ellos. (¡Esto
también es la razón específica mensajes de error son mucho mejores que los generales!)
Sin embargo, si se sabe que se requiere el software bajo prueba para procesar toda
entrada, independientemente de su validez, entonces es razonable para continuar como
antes y diseño de casos de prueba que cubren la mayor cantidad de condiciones
inválidas de una sola vez como sea posible. Por ejemplo, si cada campo no válido en una
forma tiene algo de texto de color rojo por encima o por debajo del campo diciendo que este
campo no es válido y por qué, entonces usted sabe que cada campo está comprobado, por lo
que han probado todo el procesamiento de error en un caso de prueba. En cualquiera de los
casos, debe haber casos de prueba independientes que cubran condiciones válidos y no
válidos.
Para cubrir los casos de prueba límite, puede ser posible combinar la totalidad de los límites
válidos mínimos para un grupo de campos en un caso de prueba y también los valores
máximos de contorno. Los límites no válidos podrían ser probados juntos si la validación se
realiza en todos los campos; de lo contrario, deben ser probados por separado, Al igual que
con las particiones no válidos.
¿Por qué usar tanto la partición de equivalencia y análisis de valores límite?

Técnicamente, porque a cada límite de alguna partición, se hace un límite de análisis de valor
también y se ha colocado a prueba cada partición de equivalencia.
Sin embargo, este enfoque puede causar problemas si ese valor no fue sólo el valor límite
que falló o dejó toda la partición. También mediante la prueba límites que probablemente no
daría a los usuarios mucha confianza ya que estamos usando los valores extremos en lugar
de valores normales. Los límites pueden ser más difícil (y por lo tanto más costoso) para
establecer así.
Por ejemplo, en el ejemplo copias de impresora descrito anteriormente se identificaron los
siguientes valores límite:
Supongamos que prueba sólo los valores válidos de contorno 1 y 99 y nada entre ellos. Si
pasan ambas pruebas, esto parece indicar que todo el valor intermedio también debería
funcionar. Sin embargo, supongamos que una página se imprime correctamente, pero 99
páginas no. Ahora no sabemos si cualquier conjunto de más de una página funciona, por lo
que haríamos primero sería poner a prueba para decir 10 páginas, es decir, un valor de la
partición de equivalencia.
Le recomendamos que pruebe las particiones por separado de las fronteras esto significa la
elección de valores de partición no son valores límite.
Sin embargo, si se utiliza el método del valor límite de tres valores, a continuación, tendría
valores límite válidos de 1, 2, 98 y 99, así que tener una equivalencia separada del valor,
además de los dos valores límites adicionales no daría mucho beneficio adicional. Pero se
dio cuenta de que un valor de equivalencia, por ejemplo 10, sustituyendo tanto de los dos
valores límite adicionales (2 y 98). Esta es la razón por la partición equivalencia con el
análisis de valores límite de dos valores es más eficiente que el de tres valores análisis
de valores límite.
Qué particiones y los límites que decida ejercer (no es necesario para poner a prueba a
todos ellos), y para que usted decida poner a prueba en primer lugar, depende de su prueba
objetivos. Si su objetivo es el enfoque más a fondo, a continuación, siga el procedimiento
de las pruebas de las particiones válidas en primer lugar, a continuación, las particiones
no válidas, entonces válida los límites y las fronteras finalmente no válidos. Sin embargo,
si usted es menor de tiempo presión y no puede evaluar todo (¿y quién no lo es?),
entonces la prueba objetiva le ayudará a decidir qué vamos a probar. Si necesitas una
confianza de los usuarios de operaciones típicas con un número mínimo de pruebas, que
pueden hacer para válidar sólo peticiones. Si desea encontrar el mayor número posible de
defectos tan pronto como sea posible, es posible comenzar con los valores límite, válidas y
no válidas. si quieres la confianza de que el sistema se encargará de malas entradas
correctamente, puede hacerlo particiones principalmente no válidas y los límites. Su
experiencia previa de los tipos de defectos encontrados puede ayudar a encontrar
defectos similares; por ejemplo, si hay típicamente un número de defectos de contorno,
entonces empezaría por las pruebas límites.
particionamiento equivalencia y análisis de valores límite se describen en la mayor parte de
libros de pruebas, incluyendo [Myers, 1979] y [Copeland, 2003]. Ejemplos de tipos de clases
de equivalencia a tener en cuenta se dan en [Kaner et al., 1993] particionamiento
equivalencia y análisis de valores límite se describen en BS7925-2, incluyendo el diseño de
pruebas y medición de la cobertura.
4.3.2 prueba de tablas de Decisión

¿Por qué utilizar las tablas de decisión?
Las técnicas de partición de equivalencia y análisis de valores límite se aplica a
situaciones o entradas específicas. Sin embargo, si diferentes combinaciones de entradas
resultan en diferentes acciones adoptadas, esto puede ser más difícil de mostrar utilizando el
particionado equivalencia y análisis de valores límite, que tienden a estar más centrado en la
interfaz de usuario. Las otras dos técnicas basadas en la especificación, tablas de decisión
y las pruebas de transición de estado se centran más en los negocios la lógica de negocio
o reglas.
Una tabla de decisión es una buena manera de tratar con combinaciones de cosas (por
ejemplo, entradas). Esta técnica a veces también se conoce como una tabla 'causa-efecto'.
La razón de esto es que no es una técnica de diagramas lógica asociada llamada 'causa-efecto
gráfica' que a veces se utiliza para ayudar a la deriva tabla de decisión (Myers describe esto
como una red lógica combinatoria [Myers, 1979]). Sin embargo, la mayoría de las personas
les resulta más útil sólo para usar la tabla descrita en [Copeland, 2003].
Si comienza a utilizar las tablas de decisión para explorar cuáles son las reglas de
negocio que debe ser probadas, es posible que los analistas y desarrolladores encuentren
las tablas muy útil y quieran empezar a usarlos también. Anime a esto, como lo hará
hacer su trabajo más fácil en el futuro. Las tablas de decisión proporcionan una forma
sistemática de indicando las reglas de negocio complejas, que es útil para los
desarrolladores, así como para testers. Las tablas de decisión se pueden utilizar en el
diseño de pruebas o se utilizan en las especificaciones, ya que ayudan a los testers a
explorar los efectos de las combinaciones de diferentes entradas y otros estados de software
que deben poner en práctica reglas de negocio correctamente. Ayudar a los desarrolladores
hacer un mejor trabajo también puede conducir a una mejor relación con ellos.
Pruebas de combinaciones puede ser un reto, ya que el número de combinaciones a
menudo puede ser enorme. Probar todas las combinaciones puede ser poco práctico, si no
imposible. Tenemos que estar satisfecho con las pruebas de sólo un pequeño
subconjunto de combinaciones, pero tomar la decisión de qué combinaciones para
probar y cuáles dejar fuera eso no es trivial. Si usted no tiene una forma sistemática de la
selección de combinaciones, un subconjunto arbitrario será utilizada y esto puede resultar en
una prueba ineficaz.
Las tablas de decisión ayudan a la selección sistemática de casos de prueba eficaz y
puede tener el efecto secundario beneficioso de encontrar problemas y ambigüedades
en la especificación. Es una técnica que funciona bien en conjunto con la equivalencia
particion. La combinación de condiciones explorado puede ser combinaciones de
particiones de equivalencia.
Además de las tablas de decisión, hay otras técnicas que tienen que ver con probando
combinaciones de cosas: las pruebas por parejas y matrices ortogonales. Estas se describen
en [Copeland, 2003]. Otra fuente de técnicas es [Pol et al., 2001]. Las tablas de decisión y de
causa-efecto gráfica se describen en [BS7925-2], incluyendo el diseño de pruebas y la
medición de la cobertura.
Utilizando las tablas de decisión para el diseño de la prueba

La primera tarea es identificar una función o subsistema adecuado que tiene un
comportamiento que reacciona de acuerdo con una combinación de entradas o
eventos. El comportamiento de interés no debe ser demasiado extensa (es decir, no debe
contener demasiadas entradas) De otra manera el número de combinaciones se convertirá
engorroso y difícil de gestionar. Es mejor tratar con un gran número de condiciones
dividiéndolos en subconjuntos y hacer frente a los subconjuntos de una en una.
Una vez que haya identificado los aspectos que deben ser combinados, a continuación,
poner ellos en una tabla con todas las combinaciones de verdadero y falso para cada
una de los aspectos. Tomemos un ejemplo de una solicitud de préstamo, donde se puede
introducir el importe de la cuota mensual o el número de años que desea tomar para pagarlo
(el término del préstamo). Si introduce tanto, el sistema hará un compromiso entre los dos si
entran en conflicto. Las dos condiciones son la cantidad del préstamo y el término, por lo que
los ponemos en una tabla (ver Tabla 4.2).
A continuación, vamos a identificar todas las combinaciones de verdadero y falso (véase

la tabla 4.3). Con dos condiciones, cada uno de los cuales puede ser verdadera o falsa,
tendremos cuatro combinaciones (dos a la potencia del número de cosas que pueden
combinar). Nota que, si tenemos tres cosas para combinar, tendremos ocho combinaciones,
con cuatro cosas, hay 16, etc. Es por esto que es bueno para hacer frente a pequeños grupos
de combinaciones a la vez. Con el fin de realizar un seguimiento de cuáles son las
combinaciones que tenemos, alternará verdadero y falso en la fila inferior, poner dos Trues
y luego dos Falses en la fila encima de la fila inferior, etc., por lo que la fila superior tendrá
todas Trues y luego todos los Falses (y este principio se aplica a todas las tablas).
El siguiente paso (al menos para este ejemplo) es identificar el resultado correcto para cada
combinación (ver Tabla 4.4). En este ejemplo, podemos entrar en una o ambas los dos
campos. Cada combinación se refiere a veces como una regla.
En este punto, podemos darnos cuenta de que no habíamos pensado en lo que sucede si el
cliente no entra nada en ninguno de los dos campos. La tabla ha puesto de relieve una
combinación que no fue mencionado en la especificación para este ejemplo. Podríamos
suponer que esta combinación debe dar lugar a un mensaje de error, por lo que tenemos que
añadir otra acción (véase el cuadro 4.5). este alto ilumina la fuerza de esta técnica para
descubrir omisiones y ambigüedades en presupuesto. No es inusual para algunas
combinaciones para ser omitidas de presupuesto; Por lo tanto, esto también es una técnica
valiosa para utilizar al revisar una base de pruebas selectivas.
Supongamos que cambiamos nuestro ejemplo un poco, por lo que no se permite que el cliente
introducir ambos de pago y plazo. Ahora nuestra tabla va a cambiar, porque hay También
debe ser un mensaje de error si se introducen, por lo que se verá como la tabla 4.6.
Usted puede notar ahora que sólo hay un "Sí" en cada columna, es decir, nuestras acciones
son mutuamente excluyentes una sola acción se produce para cada combinación de
condiciones. Podríamos representar esto de una manera diferente haciendo una lista de las
acciones en la celda de una fila, como se muestra en la Tabla 4.7. Tenga en cuenta que si más
de una acción los resultados de cualquiera de las combinaciones, entonces sería mejor para
mostrar como filas separadas en lugar de combinarlos en una fila.
El paso final de esta técnica es escribir casos de prueba para ejercer cada uno de los
cuatro reglas en nuestra la tabla.
En este ejemplo empezamos mediante la identificación de las condiciones de entrada y
luego identificar los resultados. Sin embargo, en la práctica podría funcionar al revés,
podemos ver que hay una serie de resultados diferentes, y tienen que trabajar atrás para
entender qué combinación de condiciones de entrada en realidad conducir los resultados. La
técnica funciona igual de bien lo hace de esta manera, y bien puede ser un enfoque iterativo
a medida que descubre más sobre las reglas que impulsan el sistema.
Tarjeta de crédito ejemplo práctico

Veamos otro ejemplo. Si usted es un cliente nuevo que abre una tarjeta de crédito
cuenta, usted obtendrá un descuento del 15% en todas sus compras hoy. Si usted es un
cliente existente y que mantenga una tarjeta de fidelización, se obtiene un descuento del
10%. Si tienen un cupón, se puede obtener un 20% de descuento en la actualidad (pero no se
puede utilizar con la "nuevo cliente descuento). Se añaden cantidades de descuento, si
procede. Esto se muestra en la Tabla 4.8.
TABLA 4.8 Tabla de decisiones, por ejemplo, tarjeta de crédito

En la Tabla 4.8, las condiciones y las acciones se enumeran en la columna de la izquierda.
Todas las demás columnas de la tabla de decisión representan cada regla separada, una para
cada combinación de condiciones. Podemos optar por probar cada descartar / combinación y
si hay sólo unos pocos lo cual suele ser el caso.
Sin embargo, si el número de reglas / combinaciones es grande, es más probable que
probarlas mediante la selección de un subconjunto rica para la prueba.
Tenga en cuenta que hemos puesto X para el descuento por dos de las columnas (Reglas 1 y
2) esto significa que esta combinación no debería ocurrir. No se puede ser a la vez una
nuevo cliente y ya titular de una tarjeta de fidelidad! Debe haber un error mensaje que indica
esto, pero incluso si no sabemos cuál debería ser ese mensaje, se será aun así obtener una
buena prueba.
Hemos hecho una suposición en la Regla 3. Desde el cupón tiene un mayor descuento que el
nuevo descuento al cliente, suponemos que el cliente elegir 20% en lugar de 15%. No
podemos añadirlos, ya que el cupón no puede ser utilizado con el descuento 'nuevo
cliente'. La acción del 20% es una suposición por nuestra parte, y debemos comprobar que
este supuesto (y cualquiera otra suposición que hacemos) es correcta, pidiendo a la persona
que escribió la especificación o los usuarios.
Por regla 5, sin embargo, podemos añadir los descuentos, ya que tanto el cupón y el descuento
de la tarjeta de fidelización debe aplicarse (al menos esa es nuestra hipótesis).
Reglas 4, 6 y 7 tienen un solo tipo de descuento y el Artículo 8 no tiene descuento.
por lo que 0%.
Si estamos aplicando esta técnica a fondo, tendríamos una prueba para cada columna o regla
de nuestra tabla de decisiones. La ventaja de hacer esto es que podemos probar una
combinación de cosas que de otro modo quizás no hemos probado y que podría encontrar un
defecto.
Sin embargo, si tenemos una gran cantidad de combinaciones, puede que no sea posible o
razonable para probar todas las combinaciones. Si estamos con limitaciones de tiempo, es
posible que no tenemos tiempo para probar todas las combinaciones. No asuma que todas las
combinaciones deben ser probados; es mejor priorizar y probar las combinaciones más
importantes. Tener la tabla completa nos permite ver qué combinaciones decidimos
probar y que no para poner a prueba esta vez.
También puede haber muchas acciones diferentes como resultado de las combinaciones
de condiciones. En el ejemplo anterior que acabamos de tener una: el descuento este
aplicado. La tabla de decisión muestra las acciones que se aplican a cada combinación
de condiciones.
En el ejemplo anterior todas las condiciones son binarias, es decir, tienen sólo dos
posibles valores: Verdadero o Falso (o, si lo prefiere Sí o No). A menudo es el caso que las
condiciones son más complejos, que tienen potencialmente muchos valores posibles.
Cuando este es el caso es probable que sea muy grande el número de combinaciones, por lo
las combinaciones sólo pueden ser muestreados en lugar de ejercer todos ellos.
4.3.3 Pruebas de transición Estado

Pruebas de transición de estados se utiliza cuando algún aspecto del sistema se describe en
lo que se llama una "máquina de estados finitos”. Esto significa simplemente que el
sistema puede estar en un número (finito) de estados diferentes, y las transiciones de un
estado a otro están determinados por las reglas de la "máquina". Este es el modelo
sobre el que se basan el sistema y las pruebas. Cualquier sistema en el que se obtiene
una salida diferente para la misma entrada, dependiendo de lo que ha ocurrido antes,
es un sistema de estados finitos. Un sistema de estados finitos se muestra a menudo como
un diagrama de estados (Véase la Figura 4.2).
Por ejemplo, si solicita retirar $ 100 de un cajero automático, es posible haber dado
efectivo. Más adelante puede hacer exactamente la misma petición, pero se negó el dinero
(porque su saldo es insuficiente). Esta negativa se debe al estado de su cuenta bancaria ha
pasado de tener fondos suficientes para cubrir la retirada de tener fondos insuficientes. La
operación que causó su cuenta para cambiar su estado era probablemente la retirada
anterior. Un diagrama de estado puede representar un modelo desde el punto de vista
del sistema, la cuenta o el cliente.
Otro ejemplo es un procesador de textos. Si un documento está abierto, usted puede
cerrarlo. Si no hay ningún documento abierto, luego 'Cerrar' no está disponible. Después de
elegir "Cerrar" una vez, no se puede elegir de nuevo para el mismo documento a menos que
abrir dicho documento. Así, un documento tiene dos estados: abierta y cerrada.
Un modelo de transición de estado tiene cuatro partes básicas:

• los estados que el software puede ocupar (abierto / cerrado o financiado / insuficiente
fondos);
• las transiciones de un estado a otro (no se permiten todas las transiciones);
• los eventos que causan una transición (el cierre de un archivo o la retirada de dinero);
• se dan las acciones que resultan de una (un mensaje de error de transición o su dinero en
efectivo).
Tenga en cuenta que, en cualquier estado dado, un evento puede causar una sola acción, pero
el mismo evento de un estado diferente, puede causar una acción diferente y un estado final
diferentes.
Vamos a ver por primera vez en los casos de prueba que ejecutan las transiciones de estado
válidos.
La figura 4.2 muestra un ejemplo de introducir un número de identificación personal (PIN)
a una cuenta bancaria. Los estados se muestran como círculos, las transiciones como
líneas con flechas y los eventos como el texto cercano a las transiciones. (Nosotros no
hemos demostrado la acción explícitamente en este diagrama, pero serían un mensaje al
cliente diciendo cosas tales como "Por favor, introduzca su PIN '.)
El diagrama de estados muestra siete estados, pero sólo cuatro eventos posibles (tarjeta
insertado, Entrar PIN, PIN y el PIN OK no OK). No hemos especificado todas las posibles
transiciones, aquí hay también serían un tiempo de espera de "esperar a que el PIN ' y desde
los tres intentos que volver al estado inicial después de la hora habían transcurrido y,
probablemente expulsar la tarjeta. También habría una transición del estado "volver la tarjeta
de nuevo al estado de inicio. No hemos especificado todos los posibles eventos o bien no
sería una opción "cancelar" de "esperar a que el PIN '
y desde los tres intentos, lo que también se remontan al estado de inicio y expulsar la
tarjeta. El estado de cuenta de acceso 'sería el comienzo de otro diagrama de estado que
muestra las transacciones válidas que pueden ser asumidas en la cuenta.
Sin embargo, este diagrama de estado, a pesar de que es incompleta, todavía nos da
información sobre cual diseñar, algunas pruebas útiles y para explicar la transición de técnica
de estado.
Al derivar casos de prueba, podemos empezar con un escenario típico. A primera vista el
caso de prueba en este caso sería la situación normal, donde se introduce el PIN correcto
la primera vez. Para ser más profundo, es posible que queremos estar seguros de que
cubrimos todos los estados (es decir, al menos una prueba pasa por cada estado) o que puede
querer cubrir cada transición. Una segunda prueba (para visitar todos los estados) sería la de
introducir una PIN incorrecto cada vez, para que el sistema se come la tarjeta. Todavía no
hemos probado cada transición todavía. Con el fin de hacer eso, nos gustaría una prueba
donde el PIN era incorrecta la primera vez, pero está bien la segunda vez, y otra prueba donde
el PIN era correcta en el tercer intento. Estas pruebas son probablemente menos importantes
que los primeros dos.
Tenga en cuenta que una transición no tiene que cambiar a un estado diferente (aunque todas
las transiciones que se muestran arriba que ir a un estado diferente). Lo que podría haber una
transición de la 'cuenta de acceso, que simplemente se remonta a' cuenta de acceso 'para una
acción como "equilibrio solicitud'.
Las condiciones de prueba se pueden derivar de la gráfica del estado de varias maneras. Cada
Estado puede señalar como una condición de prueba, al igual que cada transición. En el
inicio, pueda que no tenga que ser capaz de identificar la cobertura de un conjunto de pruebas
en términos de transiciones.
Yendo más allá del nivel esperado en el inicio, también podemos considerar transición
pares y triples y así sucesivamente. La cobertura de todas las transiciones individuales
es también conocida como la cobertura 0-interruptor, la cobertura de pares de
transición es la cobertura l-switch, la cobertura de triples de transición es la cobertura
de 2 controles, etc. Derivación de casos de prueba a partir del modelo de transición de
estados es un enfoque de caja negra. La medición de la cantidad que han probado (cubierta)
se está acercando a un punto de vista de caja blanca. Sin embargo, el estado pruebas de
transición es considerada como una técnica de caja negra.
Una de las ventajas de la técnica de transición de estados es que el modelo puede ser tan
detallada o tan abstracto como usted necesita que sea. Cuando una parte del sistema es
más importante (es decir, requiere más pruebas) una mayor profundidad de detalle puede ser
modelado. Cuando el sistema es menos importante (requiere menos pruebas), el modelo
puede utilizar un solo estado para significar lo que sería de otra manera una serie de diferentes
estados.
Las pruebas para las transiciones no válidas

Derivación de pruebas sólo a partir de un diagrama de estados (también conocido como un
diagrama de estado) es muy bueno para ver las transiciones válidas, pero es posible que no
vea fácilmente las pruebas negativas, donde tratamos de generar transiciones no válidas. Con
el fin de ver el número total de combinaciones de estados y transiciones, válidas y no válidas,
es útil una tabla de estado.
La tabla de estado se enumeran todos los estados en un lado de la tabla y todos los
eventos que provocan transiciones a lo largo de la parte superior (o viceversa). Cada
celda representa entonces un par el estado evento. El contenido de cada celda indica que
el estado del sistema se moverá, cuando el evento correspondiente se produce mientras que
en el estado asociado.
Esto incluirá los posibles eventos erróneos, acontecimientos que no se espera que
sucederán en ciertos estados. Estas son las condiciones de pruebas negativas.
La Tabla 4.9 muestra los estados en la primera columna y las posibles entradas de toda la fila
superior. Así, por ejemplo, si el sistema está en el estado 1, la inserción de una tarjeta
que lleve al Estado 2. Si estamos en el estado 2, y se introduce un PIN válido, vamos al
Estado el 6 de acceder a la cuenta. En el estado 2 si introduce un número incorrecto,
vamos a 3. Estado han puesto un guion en las celdas que deberían ser imposible, es
decir, representan no válido transiciones de ese estado.
Hemos puesto un signo de interrogación de dos celdas, en donde entramos ya sea válida o
una PIN no válido cuando estamos accediendo a la cuenta. Tal vez el sistema tomará nuestro
número PIN como la cantidad de dinero en efectivo a retirar ¡Podría ser una buena prueba!
La mayoría de las otras celdas no válidos sería físicamente imposible en este ejemplo.
pruebas no válidas (negativos) intentarán generar transiciones no válidas, las transiciones que
no debería ser posible (pero a menudo tomar buenas pruebas cuando resulta que son posible).
Una descripción más extensa de las máquinas de estado se encuentra en [Marick,
1994]. pruebas de transición de estados también se describe en [Craig, 2002], [Copeland,
2003], [Beizer, 1990] y [Broekman, 2003]. Transición de estado las pruebas se describen en
BS7925-2, incluyendo pruebas de diseño y cobertura medidas.
4.3.4 Pruebas de caso de uso

Las pruebas de casos de uso es una técnica que nos ayuda a identificar casos de prueba que
ejercitan el sistema entero de transacción por transacción de principio a fin. Son descrito por
Ivar Jacobson en su libro Object-Oriented Software Engineering: A Caso de uso enfoque
impulsado [Jacobson, 1992].
Un caso de uso es una descripción del uso particular del sistema por un actor (o usuario
del sistema). Cada caso de uso describe las interacciones del actor ha el sistema con el fin de
lograr una tarea específica (o, al menos, producir algo de valor para el usuario). Los actores
son por lo general las personas, pero también puede ser otros sistemas. Los casos de uso son
una secuencia de pasos que describen las interacciones entre el actor y el sistema.
Los casos de uso se definen en términos del actor, no del sistema, describiendo lo que el
actor hace y lo que el actor ve, más que lo que el sistema espera de entradas y lo que los
sistemas arrojan en la salida. A menudo utilizan el lenguaje y los términos del negocio
en lugar de términos técnicos, especialmente cuando el actor es un usuario del
negocio. Ellos sirven como base para el desarrollo de casos de prueba sobre todo en el
sistema y pruebas de niveles de aceptación.
Los casos de uso pueden descubrir defectos de integración, es decir, los defectos causados
por la interacción incorrecta entre los diferentes componentes. Utilizado de esta manera, el
actor puede ser algo que las interfaces del sistema, como a un enlace de comunicación o
subsistema.
Los casos de uso describen el proceso que fluye a través de un sistema basado en su mayor
parte uso probable. Esto hace que los casos de prueba derivados de los casos de uso
particularmente sean buenos para encontrar defectos en el uso real del sistema (es decir,
los defectos que los usuarios es más probable que venir a través de la primera vez que utiliza
el sistema). Cada caso de uso por lo general tiene una corriente principal (o lo más
probable) y, a veces escenario adicional ramas alternativas (que abarcan, por ejemplo, casos
especiales o condición excepcional). Cada caso de uso debe especificar alguna condición
previa que deben cumplirse para utilizar el caso para trabajar. Los casos de uso
también deben especificar condiciones posteriores que son observables. Los resultados y
una descripción del estado final del sistema después del caso de uso tiene ha ejecutado con
éxito.
El ejemplo de PIN que se utilizó para la prueba de transición de estado también podría ser
definida en términos de casos de uso, como se muestra en la Figura 4.3. Mostramos un
escenario de éxito y las extensiones (que representan las formas en que el escenario podría
dejar de ser un éxito).
Para las pruebas de casos de uso, tendríamos una prueba de la hipótesis de éxito y una tesis
para cada extensión. En este ejemplo, podemos dar la extensión 4b una prioridad más alta
de 4a desde un punto de vista de la seguridad.
Requisitos del sistema también se pueden especificar como un conjunto de casos de
uso. Este enfoque puede hacer que sea más fácil para involucrar a los usuarios en la
recopilación de requisitos y el proceso de definición.
4.4 ESTRUCTURA BASADA EN TÉCNICAS DE CAJA BLANCA

1 Describir el concepto y la importancia de la cobertura de código. (K2)
2 Explicar los conceptos de la declaración y la cobertura de decisión y bajo destacan
que estos conceptos se pueden utilizar también en otros niveles de prueba componente
(por ejemplo, en los procesos de negocio a nivel de sistema). (K2)
3 escritura DE casos de prueba de flujos de control dados utilizando el siguiente diseño
de la prueba técnicas: (K3)
a) declaración cobertura;
b) la cobertura de decisión.
4 Evaluar declaración y cobertura de decisión para la integridad. (K3)
En esta sección vamos a analizar en detalle el concepto de cobertura y cómo se puede utilizar
para medir algunos aspectos de la rigurosidad de las pruebas. Con el fin de ver cómo en
realidad funciona la cobertura, vamos a utilizar algunos ejemplos a nivel de código (aunque
la cobertura también se aplica a otros niveles, como los procedimientos de negocio). En
particular, vamos a mostrar cómo medir la cobertura de los estados y decisiones, y los casos
de prueba de cómo escribir para extender la cobertura si no es 100%. Los mismos principios
se aplican a la cobertura del sistema, elementos de cobertura de nivel, por ejemplo, elementos
de menú.
En esta sección, busque las definiciones de los términos del glosario:

la cobertura de código, la cobertura de decisión, la cobertura de sentencias, las pruebas,
las pruebas basadas en estructura estructural y pruebas de caja blanca
4.4.1 El uso de técnicas basadas en la estructura para medir la cobertura y pruebas de

diseño
técnicas basadas en la estructura sirven para dos propósitos: Medición de cobertura de
la prueba y el diseño de casos de prueba estructural. A menudo se utilizan primero para
evaluar la cantidad de pruebas realizadas por pruebas derivados de técnicas basadas en la
especificación, es decir, para evaluar la cobertura. Ellos a continuación, se utilizan para
diseñar pruebas adicionales con el objetivo de aumentar la cobertura de la prueba.
Técnicas de diseño de pruebas basadas en la estructura

son una buena manera de generar casos de prueba adicionales que son diferentes de
pruebas existentes. Ellos pueden ayudar a asegurar una mayor amplitud de la prueba, en el
sentido que los casos de prueba que permitan alcanzar el 100% de cobertura en cualquier
medida serán el ejercicio de todas las partes del software desde el punto de vista de los
elementos que se están cubiertos.
¿Qué es la cobertura de la prueba?

medidas de cobertura de las pruebas de alguna manera específica la cantidad de las pruebas
realizadas por un conjunto de pruebas (derivado de alguna otra manera, por ejemplo,
utilizando técnicas basadas en la especificación). Siempre que sea posible contar las cosas y
puede decir si o no cada una de esas cosas ha sido probada por alguna prueba, entonces
podemos medir la cobertura. La medida básica de cobertura es
¿dónde está el elemento de cobertura lo que hemos podido contar y ver si una prueba ha
ejercido o utilizado este concepto.
Hay peligro en el uso de una medida de cobertura. Una cobertura del 100% no significa
100% probado! técnicas de cobertura miden sólo una dimensión de una multi-
dimensión. Dos casos de prueba diferentes pueden alcanzar exactamente la misma cobertura,
pero los datos de entrada de uno se puede encontrar un error que los datos de entrada de la
otra no.
Uno de los inconvenientes de la medición de cobertura de código es que mide la cobertura
de lo que ha sido escrito, es decir, el propio código; no se puede decir nada sobre el software
que no se ha escrito. Si una función no ha aplicado, técnicas de prueba basados en la
especificación revelará esto. Si una función era omitida de la especificación, a continuación,
las técnicas basadas en la experiencia pueden encontrarlo.
Pero las técnicas basadas en la estructura sólo pueden mirar a una estructura que ya
está ahí.
Tipos de cobertura
Cobertura de la prueba se puede medir en base a los diferentes números de elementos
estructurales en un sistema o componente. La cobertura se puede medir en el nivel de
pruebas de componente, el nivel de pruebas de integración, el nivel de sistema o pruebas
de aceptación.
Por ejemplo, en el sistema o nivel de aceptación, los elementos de cobertura pueden ser
requisitos, opciones de menús, pantallas, o las transacciones comerciales típicas. otra
cobertura medidas incluyen cosas tales como elementos estructurales de base de datos
(registros, campos y sub-campos) y archivos. Es digno de la comprobación de las nuevas
herramientas, como la herramienta de prueba mercado se desarrolla con bastante rapidez.
En el nivel de integración, podríamos medir la cobertura de interfaces o específica las
interacciones que han sido probados. La cobertura de llamadas del módulo, objeto o llamadas
procedimiento también se pueden medir (y con el apoyo de herramientas en cierta medida).
Podemos medir la cobertura para cada una de las técnicas basadas en la especificación como
bien:
• EP: porcentaje de particiones de equivalencia ejercidas (podríamos medir válido y la
cobertura de partición no válida por separado si esto tiene sentido);
• BVA: porcentaje de límites ejercidas (también podríamos separar válido y límites válidos
si hubiéramos deseado);
• Las tablas de decisión: porcentaje de reglas de negocio o columnas de tabla de decisiones
probado;
• Prueba de transición de estados: hay una serie de posibles medidas de cobertura:
- Porcentaje de estados visitados
- Porcentaje de transiciones (válidos) ejercidas (esto se conoce como Chow de 0- la cobertura
del interruptor)
- Porcentaje de pares de transiciones válidas ejercidas ('transición' o pares la cobertura 1-
interruptor de Chow) y la serie más larga de transiciones, como transición triples, cuádruples,
etc.
- Porcentaje de transiciones no válidas ejercido (de la tabla de estado)
Las medidas de cobertura de las técnicas basadas en la especificación se aplicarían a

cualquier prueba nivel de la técnica se ha utilizado (por ejemplo, sistema o componente
nivel).
Cuando la cobertura es discutida por los analistas de negocios, testers de sistemas o
usuarios, lo más probable se refiere al porcentaje de requisitos que han sido probados por un
conjunto de pruebas. Esto se puede medir mediante una herramienta como un requisito
gestión de herramientas o una herramienta de gestión de pruebas.
Sin embargo, cuando la cobertura es discutida por los programadores, lo más probable
es que se refiere a la cobertura de código, donde los elementos estructurales se pueden
identificar usando una herramienta, ya que no es un buen apoyo de herramientas para
medir la cobertura de código. Nosotros declaración de la cubierta y la cobertura de decisión
en breve.
Las declaraciones y los resultados de decisión son dos estructuras que se pueden medir en el
código y hay una buena herramienta de apoyo para estas medidas de cobertura. Cobertura de
código se hace normalmente en los componentes y pruebas de integración de componentes
sí que se hace en absoluto. Si alguien dice tener cobertura de código logrado, es importante
para establecer exactamente qué elementos del código han sido cubiertas, como la
declaración la cobertura (a menudo lo que se entiende) es significativamente más débil que
la cobertura de decisión o algunas de las otras medidas de cobertura de código.
Cómo medir la cobertura

A efectos prácticos, la medición de la cobertura es algo que requiere soporte de una
herramienta. Sin embargo, el conocimiento de los pasos que toma típicamente para medir
la cobertura es útil en la comprensión de los méritos relativos de cada técnica. Nuestro
ejemplo se supone una herramienta de medida de cobertura intrusivo que altera el código
mediante la inserción de instrumentación:
1 Decidir sobre el elemento estructural a utilizar, es decir, los elementos de cobertura sean
contados.
2 Cuenta los elementos estructurales o elementos.
3 Instrumento código.
4 Ejecute las pruebas para las cuales se requiere la medición de cobertura.
5 El uso de la salida de la instrumentación, determina el porcentaje de elementos o artículos
ejercidos.
Instrumentación de código (paso 3) implica la inserción de código junto a cada estructura de

elemento con el fin de registrar el momento en que el elemento estructural ha sido
ejercido. La determinación de la medida de cobertura real (paso 5) es entonces una cuestión
del análisis de la información registrada.
la medida de cobertura de código se hace mejor con el uso de herramientas (como se describe
en Capítulo 6) y hay un número de tales herramientas en el mercado. Estas herramientas
pueden ayudar a aumentar la calidad y la productividad de las pruebas. Aumentan la
calidad de asegurar que los aspectos más estructurales sean probados, así hay defectos en los
caminos estructurales se pueden encontrar. Ellos aumentan la productividad y la eficiencia,
poniendo de relieve pruebas que pueden ser redundantes, es decir, pruebas de la misma
estructura que las otras pruebas (Aunque esto no es necesariamente una mala cosa, ya que
podemos encontrar una prueba de defectos la misma estructura con datos diferente).
En común con todas las técnicas de pruebas basadas en la estructura, técnicas de
cobertura de código son los más utilizados en las zonas de código de software donde es
necesario pruebas más completas. código crítico con la seguridad; código que es vital
para el funcionamiento correcto de una sistema y piezas complejas de código son todos
ejemplos basado en técnicas estructura son particularmente digno de la aplicación. Por
ejemplo, DO178-B [RTCA] requiere cobertura estructural para ciertos tipos de sistema para
ser utilizada por el militares. técnicas de cobertura estructurales se deben utilizar siempre,
además de técnicas de pruebas basadas en la experiencia, más que como una basada en
especificación y alternativa a ellos.
Diseño de casos de prueba basados en la estructura

Si usted está apuntando para un nivel dado de cobertura (digamos 95%), pero no lo ha
alcanzado su objetivo (por ejemplo, sólo tiene el 87% hasta el momento), entonces casos
adicionales de prueba pueden ser diseñados con el objetivo de ejercer una parte o la
totalidad de la estructura a elementos donde aún no llegaron. Este es el diseño de la
prueba basada en la estructura. Estas nuevas pruebas se ejecutan a continuación, a
través del código instrumentado y una nueva medida de cobertura se calcula. Esto se
repite hasta que la cobertura requerida se logra a medida (¡o hasta que decida que su objetivo
era demasiado ambicioso!). Lo ideal sería que todas las pruebas deben correr de nuevo en el
instrumentado código.
Vamos a ver algunos ejemplos de la cobertura basada en la estructura y diseño de la prueba
para la declaración y la toma de pruebas a continuación.
4.4.2 Declaración de la cobertura y de pruebas de requisitos

Declaración cobertura se calcula por:
Los estudios y la experiencia en la industria han indicado que lo que se considera
bastante completa en una prueba de caja negra en realidad puede alcanzar sólo el 60%
y el 75% la cobertura de sentencias. Típica prueba ad hoc es probable que sea alrededor
del 30% esto deja el 70% de las declaraciones no probadas.
Diferentes herramientas de cobertura pueden trabajar de manera ligeramente

diferente, por lo que pueden dar diferentes cifras de cobertura para el mismo conjunto
de pruebas en el mismo código, aunque con una cobertura del 100% deben ser el mismo.
Vamos a ilustrar los principios de la cobertura de código. Con el fin de simplificar nuestro
ejemplos, utilizaremos un pseudo-código básico esto no es ningún lenguaje de programación
específico, pero debe ser legible y comprensible para usted, incluso si no han hecho ninguna
programación usted mismo.
Por ejemplo, considere el ejemplo de código 4.1.
Para lograr el 100% de cobertura de la declaración de este segmento de código sólo un caso
de prueba se requiere, uno que asegura que la variable A contiene un valor que es mayor que
el valor de la variable B, por ejemplo, A = 12 y B = 10. Obsérvese que aquí estamos haciendo
pruebas estructurales de diseño en primer lugar, ya que estamos eligiendo nuestros valores
de entrada con el fin de garantizar la cobertura de sentencias.
Veamos un ejemplo en el que medimos la cobertura en primer lugar. Con el fin de simplificar
el ejemplo, vamos a considerar cada línea como un comunicado. (Diferentes herramientas y
métodos pueden contar cosas diferentes como las declaraciones, pero el principio básico es
sin embargo el mismo que se cuentan.) Una declaración puede ser en una sola línea, o pueden
extenderse a varias líneas. Una línea puede contener más de una sentencia, sólo una
declaración, o sólo una parte de un comunicado. Algunos estados pueden contener otros
estados dentro de ellos. En el ejemplo de código 4.2, tenemos dos declaraciones de lectura,
una instrucción de asignación, y luego una instrucción IF en tres líneas, pero el SI declaración
contiene otra declaración (impresión) como parte de ella.
Aunque no es del todo correcta, hemos numerado cada línea y consideraremos cada línea
como un comunicado. (Algunas herramientas pueden agrupar instrucciones que siempre
serían ejecutados juntos en un bloque básico que se considera como una sola instrucción.)
Sin embargo, nos limitaremos a usar líneas numeradas para ilustrar los principios de la
cobertura de los estados (líneas). Vamos a analizar la cobertura de un conjunto de pruebas en
nuestro programa de seis declaraciones:
¿Cuál lineas hemos cubierto?
• En la prueba1_1, el valor de C será de 8, por lo que cubrirá las declaraciones sobre las líneas
1 a 4 y la línea 6.
• En la prueba 1_2, el valor de C será de 50, por lo que vamos a cubrir exactamente el mismo
estado como prueba 1_1.
• En la prueba 1_3, el valor de C será de 49 años, así que de nuevo vamos a cubrir el mismo
estado.
Puesto que hemos cubierto cinco de los seis estados, tenemos la declaración 83%
cobertura (con tres pruebas). Lo que prueba qué necesitamos con el fin de cubrir
declaración 5, la afirmación de que no hemos ejercido todavía Que tal este:
Prueba 1_4: A = 20, B = 25
Esta vez el valor de C es 70, por lo que se imprimirá 'grande C y vamos a tener ejercido
los seis de los estados, por lo que ahora la cobertura de sentencias = 100%. Nos dasmos
cuenta que medimos cobertura primero, y luego diseñado una prueba para cubrir la
declaración que todavía no habíamos cubierto.
Tenga en cuenta que la prueba 1_4 por sí solo es más efectividad (hacia nuestro objetivo de
100% de cobertura de declaración) que las tres primeras pruebas juntos. Sólo tomando
Prueba 1_4 en más eficiente que el conjunto de cuatro pruebas, ya que a utilizado sólo una
prueba en lugar de cuatro. Al ser más eficaz y más eficiente es la marca de una buena técnica
de prueba.
4.4.3 Cobertura de decisión y pruebas de decisión

Una decisión es una instrucción IF, una declaración de control de bucle (por ejemplo, do-
while o Repeat-until), o una instrucción CASE, donde hay dos o más posibles salidas o
resultados de la declaración. Con una instrucción IF, la salida puede o bien ser verdadera o
falsa, en función del valor de la condición lógica que SI viene después. Con una sentencia de
control de bucle, el resultado es o bien para llevar a cabo el código dentro del bucle o no de
nuevo una salida Verdadero o Falso. la cobertura de decisión se calcula por:
Lo que se siente como pruebas funcionales razonablemente exhaustiva puede lograr

solamente 40% al 60% de cobertura de decisión, prueba típica ad hoc puede cubrir sólo el
20% de las decisiones, dejando el 80% de los posibles resultados no probados. Incluso si las
pruebas parecen bastante completas a partir de una funcional o especificación basada en
punto de vista, es posible que sólo cubría dos tercios o tres cuartos de las decisiones. la
cobertura de decisión es más fuerte que la cobertura de sentencias. Se reanudará la
cobertura de sentencias 'esto significa que el 100% de cobertura de decisión siempre
garantiza la cobertura de sentencias 100%. Cualquier medida de la cobertura más fuerte
puede requerir más casos de prueba para lograr una cobertura del 100%. Por ejemplo,
considere ejemplo de código 4.1 nuevo.
Vimos anteriormente que se requería ese caso, sólo una prueba para lograr el 100%
declaración la cobertura ambiente. Sin embargo, la cobertura de decisión requiere cada
decisión que ha tenido tanto un resultado verdadero y falso. Por lo tanto, para lograr una
cobertura del 100% de decisión, un segundo caso de prueba es necesario que A es menor o
igual a B. Esta voluntad Asegurar que la declaración de decisiones 'SI A> B' tiene un
resultado falso. Así que una prueba es suficiente para la cobertura de declaración 100%, pero
se necesitan dos pruebas para 100% la cobertura de decisión. Tenga en cuenta que la
cobertura de decisión 100% garantiza el 100% declaración de cobertura, pero no al revés!
Vamos a suponer que ya tenemos la siguiente prueba, lo que nos da el 100% la cobertura de
sentencias por ejemplo de código 4.3.
PRUEBA 2
Prueba 2_1: A = 20, B = 15
¿Qué resultados de la decisión que hemos ejercido con nuestra prueba? El valor de C es -10,
Por lo que la condición de 'C <0' es cierto, por lo que se imprimirá 'C negativo' y tenemos
ejercido el resultado de que la declaración verdadera decisión. Pero no hemos ejercido el
resultado de la decisión de False. ¿Qué otra prueba de qué tenemos que ejercer el resultado
falso y para lograr una cobertura del 100% de decisión? Antes de responder a esta pregunta,
vamos a echar un vistazo a otra forma de representar este código. A veces, la estructura de
toma es más fácil ver en un flujo de control diagrama (véase la Figura 4.4).
La línea punteada muestra donde 2_1 prueba ha ido y muestra claramente que, sin embargo,
no han tenido un examen que toma la salida falsa de la instrucción IF.
Vamos a modificar nuestra prueba existente establecido mediante la adición de otra prueba:
PRUEBAS DE 2
Prueba 2_1: A = 20, B = 15
Prueba 2_2: A = 10, B = 2
Esto se refiere ahora tanto de los resultados de la decisión, True (con prueba 2_1) y Falso
(con prueba 2_2). Si tuviéramos que dibujar el camino tomado por la prueba 2_2, sería una
línea recta desde la declaración de lectura abajo de la salida falsa ya través de la endif. Tenga
en cuenta que podría haber elegido otros números para lograr ya sea los resultados de
verdadero o falso.
4.4.4 Otras técnicas basadas en la estructura

Hay otras técnicas basadas en la estructura que se pueden utilizar para lograr la prueba
a diferentes grados de rigurosidad. Algunas técnicas son más fuertes (requieren más
pruebas para lograr una cobertura del 100% y, por tanto, tienen una mayor probabilidad de
la detección de defectos) y otros son más débiles.
Por ejemplo, la cobertura de rama está estrechamente relacionado con la cobertura de
decisiones y en el 100% de cobertura dan exactamente los mismos resultados. medidas
de cobertura de decisión la cobertura de los saltos condicionales; cobertura de
sucursales mide la cobertura de ambas ramas condicionales e incondicionales. El Plan
de estudios utiliza cobertura de decisión, ya que es la fuente de las ramas. Algunas
herramientas de medida de cobertura pueden hablar acerca de la cobertura de la rama cuando
en realidad quieren decir algo sobre cobertura decisión.
Otras medidas de código de cobertura de flujo de control incluyen la secuencia de código
lineal y saltos (LCSAJ) de la cobertura, la cobertura de la condición, la cobertura de
condición múltiple (También conocido como la cobertura de condición combinación) y la
determinación condición cobertura (también conocida como la cobertura de decisión
condición múltiple o modificado de la cobertura de decisión condición, MCDC). Esta técnica
requiere la cobertura de todas condiciones que pueden afectar o determinar el resultado de la
decisión.
Otro popular, pero a menudo mal entendida, medida de código de cobertura es el camino
cobertura. A veces cualquier técnica basada en la estructura se denomina "prueba de ruta'
[Patton, 2001]. Sin embargo, en sentido estricto, para cualquier código que contiene un bucle,
cobertura de caminos es imposible ya que un camino que recorre el bucle tres veces es
diferente de la ruta que viaja alrededor del mismo bucle cuatro veces. Esto es cierto incluso
si el resto de los caminos son idénticos. Así que si es posible viajar ronda el bucle un número
ilimitado de veces, entonces hay un número ilimitado de caminos a través de ese trozo de
código. Por esta razón, es más correcto hablar de 'Una cobertura independiente segmento de
trazado ", aunque el término" cobertura de ruta más corta se utiliza con frecuencia.
se describen las medidas basadas en la estructura y técnicas de diseño de pruebas
relacionados en [BS7925-2]. Las técnicas basadas en estructura también se discuten en
[Copeland.2003] y [Myers, 1979]. Una buena descripción de la teoría de grafos detrás de
estructura pruebas se puede encontrar en [Jorgensen, 1995] y [Hetzel, 1988] también muestra
un enfoque estructural. [Pol et al, 2001] describe un enfoque basado en la estructura llamado
una prueba de algoritmo.
4.5 Técnicas basadas en la experiencia

1 motivos de visita para la escritura de casos de prueba basados en la intuición,
experiencia y conocimiento acerca de defectos comunes. (KL)
2 Comparación de las técnicas basadas en la experiencia con las pruebas basadas en la
especificación técnicas. (K2)
En esta sección vamos a ver dos técnicas basadas en la experiencia, por qué y cuándo son
útiles, y cómo encajan con las técnicas basadas en la especificación.
Si bien es cierto que la prueba debe ser rigurosa, completa y sistemática, esto no es todo
lo que hay de la prueba. Hay un papel definitivo para las técnicas no sistemática, es decir,
sobre la base de pruebas de conocimiento, la experiencia, la imaginación y la intuición de
una persona. La razón es que algunos defectos son difíciles de encontrar usando enfoques
sistemáticos, por lo que un buen ' cazador bug - errores ' pueden ser muy creativos en la
búsqueda de aquellos defectos difícil de alcanzar.
En esta sección, busque las definiciones de los términos del glosario: adivinar el error
y pruebas exploratorias.
4.5.1 Adivinar error

Error adivinar es una técnica que siempre se debe utilizar como un complemento de
otras técnicas más formales. El éxito de error adivinar en mucho depende de la habilidad
del testers, como buenos testers saben dónde los defectos son más probabilidades que
estén. Algunas personas parecen ser naturalmente bueno en las pruebas y los demás son
buenos testers porque tienen mucha experiencia, ya sea como un testers o trabajan con un
sistema en particular y por lo tanto son capaces de establecer claramente sus debilidades.
Esta es la razón para un enfoque de error de adivinar, que se utiliza después de las técnicas
más formales tienen ha aplicado en cierta medida, puede ser muy eficaz. En el uso más
formal de técnicas, el testers es probable que obtenga una mejor comprensión del
sistema, lo que hace y cómo funciona. Con esta mejor comprensión, es probable que sea
mejor en formas de adivinanzas en el que el sistema no funcione correctamente.
No hay reglas para adivinar error. El testers analiza situaciones en las que el software
no puede ser capaz de hacer frente. Las condiciones típicas a tratar de incluir la división
por cero, de entrada, en blanco (o no), archivos vacíos y el tipo equivocado de datos (por
ejemplo, caracteres alfabéticos, donde se requiere numérico). Si alguien alguna vez dice de
un sistema o el entorno en el cual se va a operar "que nunca podría suceda', que podría ser
una buena idea para probar esa condición, ya que tales supuestos sobre lo que va y no va a
ocurrir en el entorno real son a menudo la causa de fallos. Un enfoque estructurado a la
técnica de error de adivinar es enumerar posibles defectos o fallos y diseñar pruebas
que tratan de producirlos. Estas listas de defectos y el fracaso pueden ser construido en
base a la propia experiencia del testers o de otras personas, defectos e insuficiencia de
datos disponibles, y desde el conocimiento común acerca de por qué falla el software.
4.5.2 El testing exploratorio

Pruebas exploratorias es un enfoque práctico en el que están involucrados los testers,
un mínimo de planificación y ejecución de prueba máxima. La planificación consiste en
la creación de un documento de prueba, una breve declaración del alcance de un corto (1 a 2
hora) encajadas en tiempo esfuerzo de la prueba, los objetivos y los posibles enfoques para
ser utilizado.
Las actividades de diseño y ejecución de pruebas se realizan en paralelo típicamente sin
documentar formalmente las condiciones de prueba, casos de prueba o scripts de
prueba.
Esto no quiere decir que no se utilizarán otras técnicas, pruebas formales.
Por ejemplo, el testers puede decidir utilizar análisis de valores límite, pero pensará a través
de y probar los valores límite más importantes sin que necesariamente escribirlos. Algunas
notas serán escritos durante las pruebas exploratorias, por lo que un informe se puede
producir después.
El registro de datos se lleva a cabo como la ejecución de pruebas, la documentación es el
aspectos clave de lo que se evalúa, los defectos encontrados y cualquier pensamiento acerca
de la posible ulteriores pruebas. Un aspecto clave de la prueba exploratoria es el
aprendizaje: el aprendizaje por el testers acerca el software, su uso, sus puntos fuertes
y sus puntos débiles. Como su nombre lo indica, pruebas exploratorias se trata de
explorar, encontrar información sobre el software, lo que hace, lo que no hace, qué
funciona y qué no funciona. El testers está constantemente tomando decisiones sobre lo
siguiente que debe probar y dónde pasar el tiempo (limitado).
Este es un enfoque que es más útil cuando no hay mala especificación y cuando el tiempo es
muy limitado. También puede servir para complementar otras pruebas más formales,
ayudando a establecer una mayor confianza en el software. De esta manera, la prueba de
exploración se puede utilizar como un control sobre el proceso de prueba formal ayudando a
asegurar que los defectos más graves se han encontrado. pruebas exploratorias se describe en
[Kaner, 2002] y [Copeland, 2003] Otras maneras de probar en forma exploratoria ( 'ataques')
se describen b \ [Whittaker, 2002].
4.6 ELECCIÓN DE UNA PRUEBA TÉCNICA

1 Enumerar los factores que influyen en la selección de la técnica de diseño de prueba
apropiado para un tipo particular de problema, tales como el tipo de sistema, el riesgo,
el cliente requisitos, modelos de uso modelado de caso, los requisitos modelos o
conocimientos tester. (K2)
En esta última sección vamos a ver los factores que intervienen en la decisión acerca de las
técnicas que se utilizan para cuándo.
¿Qué técnica es la mejor? ¡Esta es la pregunta equivocada! Cada técnica es buena para
ciertas cosas, y no tan bueno para otras cosas. Por ejemplo, uno de los beneficios de las
técnicas basadas en la estructura es que se pueden encontrar “cosas” en el código que
no debería estar ahí, como 'caballos de Troya' u otro código malicioso. Sin embargo, si
hay partes de la especificación que faltan en el código, sólo las técnicas basadas en la
especificación las encontrarán, las técnicas basadas en la estructura sólo pueden probar lo
que hay. Si hay cosas faltantes de la memoria descriptiva y a partir del código, entonces sólo
experiencia-técnicas basadas las encontrarían. Cada técnica individual está dirigido a
determinados tipos de defectos también. Por ejemplo, las pruebas de transición de estado
es poco probable encontrar defectos de contorno.
La elección de qué técnicas de prueba usar depende de una serie de factores, incluyendo el
tipo de sistema, las normas reglamentarias, el cliente o requisito contractual, nivel de riesgo,
tipo de riesgo, objetivo de la prueba, la documentación disponible, el conocimiento de los
testers, el tiempo y el presupuesto, el ciclo de vida de desarrollo, caso de uso modelos y la
experiencia previa de los tipos de defectos encontrados.
Algunas técnicas son más aplicables a determinadas situaciones y niveles de prueba:
otros son aplicables a todos los niveles de prueba.
En este capítulo se ha cubierto el software más popular y de uso común técnicas de
prueba. Hay muchos otros que quedan fuera del alcance de la Plan de estudios que este libro
se basa en. Con tantas técnicas de prueba para elegir desde cómo son los testers para decidir
cuáles usar.
Tal vez lo más importante a entender es que la mejor prueba técnica es que no hay una
de prueba única. Debido a que cada técnica de prueba es buena en la búsqueda de una clase
específica de defecto, mediante una sola técnica ayudará a asegurar que muchos (tal vez la
mayoría, pero no todos) se encuentran defectos de esa clase particular.
¡Por desgracia, también puede ayudar a asegurar que muchos defectos de otras clases están
perdidos! Usando una variedad de técnicas, por tanto, ayudará a asegurar que una variedad
de defectos se encuentran, lo que resulta en las pruebas más eficaz.
Entonces, ¿cómo podemos elegir las técnicas de prueba más adecuados para usar? Las
decisiones se basan en una serie de factores, tanto internos como externos.
Los factores internos que influyen en la decisión sobre qué técnica a utilizar son:
• Los modelos usados: Dado que las técnicas de pruebas se basan en modelos, los modelos
disponible (es decir, desarrollar y utilizar durante la especificación, diseño e implementación
del sistema) dependerán en cierta medida que controlan las pruebas técnicas se pueden
utilizar. Por ejemplo, si la especificación contiene un estado Diagrama de transición, las
pruebas de transición de estado sería una buena técnica para utilizar.
• Conocimiento testers experimento: ¿Cuántos testers conocen el sistema y sobre Técnicas
de prueba influirán claramente su elección de las pruebas técnicas? Este conocimiento en sí
mismo puede ser influenciado por su experiencia en prueba y del sistema bajo prueba.
• Defectos probables: El conocimiento de los defectos que serán muy útiles en la elección
de técnicas de prueba (ya que cada técnica es buena en la búsqueda de un particular, tipo de
defecto). Este conocimiento puede ser adquirida a través de la experiencia probar una versión
anterior del sistema y los niveles anteriores de la prueba en la versión actual.
• Objetivo de la prueba: Si el objetivo de la prueba es simplemente para ganar la confianza
de que el software hace las tareas operativas típicas a continuación, utilizar los casos sería un
enfoque posible. Si el objetivo es que las pruebas muy completo y luego más técnicas
rigurosas y detalladas (incluyendo técnicas basadas en la estructura) debe ser elegido.
• Documentación Sea o no documentado (por ejemplo, unas exigencias especificación)
existe y si es o no es hasta la fecha afectará a la elección de las técnicas de prueba. El
contenido y el estilo de la documentación también influirán en la elección de las técnicas (por
ejemplo, si las tablas de decisión o grafos de estado se han utilizado a continuación las
técnicas de prueba asociados deben ser usado).
• Modelo de ciclo de vida: Un modelo de ciclo de vida secuencial se presta a la utilización
de más técnicas formales, mientras que un modelo de ciclo de vida iterativo puede ser más
adecuado para el uso de un enfoque de pruebas exploratorias.
Los factores externos que influyen en la decisión sobre qué técnica a utilizar son:
• Riesgo Cuanto mayor es el riesgo (por ejemplo, los sistemas críticos de seguridad), mayor
es la necesidad para las pruebas formales y más a fondo. El riesgo comercial puede ser
influenciado por problemas de calidad (por lo que la prueba más completa sería apropiada)
o por cuestiones de tiempo hasta el comercial (pruebas de manera exploratoria sería una
elección apropiada).
• El cliente y los requisitos contractuales: A veces los contratos especifican las técnicas
particulares de prueba a utilizar (más comúnmente declaración o rama cobertura).
• Tipo de sistema: El tipo de sistema (por ejemplo, incrustado, gráfico, financiero, etc.)
influirá en la elección de las técnicas. Por ejemplo, una aplicación financiera que implica
muchos cálculos se beneficiaría de análisis de valores límite.
• Los requisitos reglamentarios Algunas industrias tienen normas reglamentarias o
directrices que rigen las técnicas de pruebas utilizados. Por ejemplo, la industria de aviación
requiere el uso de partición de equivalencia, el valor límite de Análisis y la transición de
estado de prueba para sistemas de alta integridad, junto con el Estado de la decisión o la
cobertura de decisión condición modificado en función del nivel de integridad del software
requerido.
• El tiempo y el presupuesto: En última instancia la cantidad de tiempo no está disponible
siempre afectar la elección de las técnicas de prueba. Cuando se dispone de más tiempo que
podamos darnos el lujo de seleccionar más técnicas y cuando el tiempo está muy limitado
estaremos limitados a lo que sabemos que tienen una buena oportunidad de ayudarnos a
encontrar sólo los defectos más importantes.
Repaso Capítulo
De la Sección 4.1, ahora debería ser capaz de diferenciar entre una condición de prueba,
un caso de prueba y un procedimiento de prueba y saben que están documentados en una
especificación de diseño de la prueba, una especificación de casos de prueba y un
procedimiento de ensayo respectivamente. Usted debe ser capaz de escribir casos de prueba
que incluyen los resultados esperados y que muestran una clara trazabilidad para la
realización de pruebas selectivas (por ejemplo, requisitos). Usted debe ser capaz de traducir
en casos de prueba un procedimiento de prueba en el nivel apropiado de detalle para tester y
usted debería ser capaz de escribir un programa de ejecución de la prueba para un
determinado conjunto de casos de prueba que tenga en cuenta las prioridades como, así como
las dependencias técnicas y lógicas. Usted debe saber el glosario de términos casos de
prueba, especificación de caso de prueba, las condiciones de ensayo, datos de prueba,
procedimiento de ensayo de escritura de la prueba, y trazabilidad.
Desde el punto 4.2 (o categorías de técnicas de diseño de pruebas), se debe ser capaz de dar
razones por las cuales tanto la especificación de base (caja negra) y basado en la estructura
(caja blanca) enfoques son útiles, y la lista de las técnicas comunes para cada uno de estos
enfoques. Tú debe ser capaz de explicar las características y diferencias entre basada
especificación, basado en la estructura y la experiencia de base técnicas. Usted debe saber
los términos del glosario de prueba de caja negra técnicas de diseño, basadas en la
experiencia, las técnicas de diseño de pruebas técnicas de diseño de pruebas basado en
la especificación, prueba basada en la estructura técnicas de diseño y técnicas de diseño
de pruebas de caja blanca.
De la Sección 4.3, usted debe ser capaz de escribir casos de prueba a partir modelos de
software determinado, utilizando la partición de equivalencia, límite análisis del valor, tablas
de decisión y diagramas de transición de estados. Debes entender el objetivo principal de
cada uno de estas cuatro técnicas, qué nivel y tipo de pruebas podrían utilizar cada técnica y
cómo se puede medir la cobertura para cada uno de ellos. También debes entender el
concepto y los beneficios de casos de uso pruebas. Usted debe saber el glosario de
términos de valor de frontera análisis, pruebas de la tabla de decisiones, la partición de
equivalencia, estatal pruebas de transición y las pruebas de caso de uso.
De la Sección 4.4, usted debe ser capaz de describir el concepto y importancia de cobertura
de código. Usted debe ser capaz de explicar los conceptos de la cobertura de sentencias y
decisiones y entienden que estos conceptos también se pueden usar a niveles de prueba
distintos de las pruebas de componentes (como los procedimientos de negocios en la prueba
del sistema nivel). Usted debe ser capaz de escribir casos de prueba de control dado flujos
utilizando pruebas de requisitos y pruebas de decisiones, y que debiera ser capaz de evaluar
la cobertura de declaración y la decisión de lo completo. Usted debe saber el glosario
términos de cobertura de código, la cobertura de decisión, la cobertura de sentencias,
pruebas estructurales, Las pruebas basadas en la estructura y pruebas de caja blanca.
De la Sección 4.5, usted debe ser capaz de recordar las razones para escribir casos de prueba
basados en la intuición, experiencia y conocimiento acerca de defectos comunes y usted
debería ser capaz de comparar las técnicas basadas en la experiencia con los basados en la
especificación técnicas. Usted debe saber el glosario de términos de error de adivinanzas
y pruebas exploratorias.
De la Sección 4.6, usted debe ser capaz de enumerar los factores que influir en la selección
de la técnica de diseño de prueba apropiado para un tipo particular de problema, tales como
el tipo de sistema, el riesgo, los requisitos del cliente, modelos para el modelado de casos de
uso, modelos de requisitos o conocimientos prueba.

Pregunta 1 ¿En qué documento se describe en el estándar IEEE 829 ¿Quieres que encontrará
las instrucciones para los pasos a seguir para hacerse un análisis que incluye la configuración,
la explotación forestal, medio ambiente y la medición?
a. Plan de prueba
b. especificación de diseño de la prueba
c. especificación de caso de prueba
d. procedimiento de ensayo
Pregunta 2 Con un tester de gran experiencia con un buen conocimiento de los negocios, que
se acercan a la definición de procedimientos de ensayo sería eficaz y más eficiente para un
proyecto en el marco de tiempo severo ¿presión?
a. Un esquema de alto nivel de las condiciones de ensayo y
pasos generales a tomar.
b. Cada paso en el ensayo explicado en detalle.
c. Un esquema de alto nivel de las condiciones de ensayo con
Los pasos a seguir discuten en detalle con otra tester experimentado.
d. La documentación detallada de todos los casos de prueba y un registro cuidadoso de cada
paso que se da en la prueba.
Pregunta 3 Ponga los casos de prueba que implementan la siguiendo las condiciones de
prueba en el mejor orden para el prueba cronograma de ejecución, para una prueba que está
comprobando modificaciones de los clientes en una base de datos.
1 Imprimir modificado registro del cliente.
2 Cambio de dirección de cliente: número de casa y
nombre de la calle.
3 capturar e imprimir el mensaje de error en pantalla.
4 Cambio de dirección de cliente: código postal.
5 Confirmar cliente existente está en la base de datos
la apertura de ese registro.
6 Cierre el registro del cliente y cerrar el
base de datos.
7 Trate de añadir un nuevo cliente sin detalles en absoluto.
a. 5,4, 2,1, 3, 7, 6
b. 4,2,5,1,6,7,3
c. 5,4,2,1,7,3,6
d. 5,1, 2, 3,4, 7, 6
Pregunta 4 ¿Por qué son ambos basados en la especificación y la estructura basada en técnicas
de prueba útil?
a. Ellos encuentran diferentes tipos de defectos.
b. El uso de técnicas más es siempre mejor.
c. Ambos encuentran los mismos tipos de defectos.
d. Debido a las especificaciones tienden a ser no estructurada.
Pregunta 5 ¿Qué es una característica clave de técnicas de pruebas basadas en la estructura?

a. Se utilizan principalmente para evaluar la estructura de una especificación.
b. Se utilizan tanto para medir la cobertura y para
pruebas de diseño para aumentar la cobertura.
c. Se basan en los conocimientos y la experiencia de
el tester.
d. Utilizan un modelo formal o informal de la
software o componente.
Pregunta 6 ¿Cuál de las siguientes sería una ejemplo de las pruebas de toma de mesa para
una financiera aplicación en el nivel del sistema de prueba?
a. Una tabla que contiene las reglas para las combinaciones de
entradas a dos campos en una pantalla.
b. Una tabla que contiene las reglas para las interfaces entre
componentes.
c. Una tabla que contiene reglas para la hipoteca
aplicaciones.
d. Una tabla que contiene las reglas para el ajedrez.
Pregunta 7 ¿Cuál de las siguientes podría ser una medida de la cobertura para las pruebas de
transición de estado?
V se han alcanzado todos los estados.
W El tiempo de respuesta para cada transacción es
adecuado.
X Cada transición se ha ejercido.
Y Todos los límites se han ejercido.
secuencias específicas
Z de transiciones han sido ejercido.
a. X, YandZ
b. V, X, Y y Z
c. W, Xandy
d. V, X y Z
Pregunta 8 Las tarifas postales para cartas 'ligeros' son 25p hasta L0G, 35p hasta 50 g, más
un extra por cada l0p 25g adicional hasta l00g.
¿Qué entradas de prueba (en gramos) serían seleccionados
utilizando el particionado de equivalencia?
a. 8,42,82,102
b. 4,15, 65, 92159
c. 10,50,75,100
d. 5,20, 40, 60, 80
Pregunta 9 ¿Cuál de los siguientes podría ser utilizado para evaluar la cobertura alcanzada
para ESPECIFICACIÓN base (caja negra) técnicas de prueba?
los resultados
V Decisión resultados de ejercicios
W Particiones ejercidas
X Ejercicios límites
Y ejercicios transiciones de estado
Z ejercicios declaraciones
a. V, W, Yor Z
b. W, XorY
c. V, XorZ
d. W, X, Y o Z
Pregunta 10 ¿Cuál de los siguientes estructura- técnica de diseño de la prueba basada sería
más probabilidades de ser aplicado a?
1 Los límites entre la tasa de interés de la hipoteca alzacuello.
2 Una transición no válida entre dos diferentes atrasos ^ estados.
3 El flujo de procesos de negocio para la hipoteca aprobación.
4 El flujo de control del programa para calcular reembolsos.
a. 2, 3 y 4
b. 2 y 4
c. 3 y 4
d. 1, 2 y 3
Pregunta 11 Uso de pruebas caso es útil para cuál de ¿el seguimiento?

P Diseño de pruebas de aceptación con los usuarios o clientes.
Q Asegurarse de que el negocio de la corriente principal procesos son probados.

R encontrar defectos en la interacción entre componentes.
S Identificación de los valores máximos y mínimos para cada campo de entrada. La
identificación de la T porcentaje de declaraciones ejercido por una series de pruebas.
a. P, Q y R
b. Q, S y T
c. P, Q y S
d. R, S y T
Pregunta 12 ¿Cuál de las siguientes afirmaciones sobre la relación entre la cobertura de

sentencias y la cobertura de decisión es correcta?
a. la cobertura de la decisión 100% se logra si la declaración la cobertura es mayor que 90%.
b. la cobertura de declaración de 100% se consigue si la decisión la cobertura es mayor que
90%.
c. la cobertura de la decisión 100% significa siempre el 100% la cobertura de sentencias.
d. la cobertura de sentencias 100% significa siempre el 100% la cobertura de decisión.
Pregunta 13 Si usted está volando con una economía billete, hay una posibilidad de que usted
puede conseguir actualizado a la clase de negocios, sobre todo si se tiene una tarjeta de oro
en el programa de viajero frecuente de la aerolínea. Si usted no posee una tarjeta de oro, hay
una posibilidad que usted conseguirá 'golpeado' fuera de la línea aérea si esto está lleno y te
registras tarde. Esto se muestra en la Figura 4.5.
Tenga en cuenta que cada caja (es decir, declaración) ha sido numerado.
Tres pruebas han llevado a cabo:
Prueba 1: titular de la tarjeta de oro que se ve actualizado a clase de negocios
Prueba 2: titular de la tarjeta no de oro que se queda en la economía
Prueba 3: Una persona que recibe un golpe desde el vuelo
¿Cuál es la cobertura de sentencias de estas tres pruebas?
a. 60%
b. 70%
c. 80%
d. 90%
Pregunta 14 ¿Por qué están adivinando error y pruebas exploratorias bueno hacer?
a. Pueden encontrar defectos perdidas por ESPECIFICACIÓN con base y las técnicas
basadas en la estructura.
b. No requieren ningún tipo de formación para ser tan eficaz como técnicas formales.
c. Se pueden utilizar más eficazmente cuando hay buenas especificaciones.
d. Se asegurarán de que todo el código o sistema se probado.
Pregunta 15 ¿Cómo funcionan las técnicas basadas en la experiencia diferir de las técnicas
basadas en la especificación?
a. Dependen de la comprensión del tester de la forma en que el sistema está estructurado en
lugar de en una
registro documentado de lo que el sistema debe hacer.
b. Ellos dependen de tener testers de más edad en lugar de testers más jóvenes.
c. Dependen de un registro documentado de lo el sistema debe hacer en lugar de en una
punto de vista personal del individuo.
d. Dependen de vista personal de un individuo
en lugar de en un registro documentado de lo que el sistema debe hacer.
Pregunta 16 Al elegir qué técnica utilizar en una situación dada, que deben tomarse factores
¿en cuenta?
U experiencia previa de tipos de defectos encontrados en esto o sistemas similares
V el conocimiento existente de los testers
W normas reglamentarias que se aplican
X el tipo de herramienta de ejecución de la prueba que se utilizará
Y la documentación disponible
Z experiencia previa en el desarrollo
idioma
a. V, W, Y y Z
b. U, V, W y Y
c. U, X y Y
d. V, W e Y
Pregunta 17 Teniendo en cuenta el diagrama de estados de la figura 4.6, que es el caso de

prueba serie mínima de validez Las transiciones a cubrir todos los estados?
a. SS-S1-S2-S4-S1-S3-ES
b. SS-S1-S2-S3-S4-ES
c. SS-S1-S2-S4-S1-S3-S4-S1-S3-ES
d. SS-S1-S4-S2-S1-S3-ES
Ejercicios: TÉCNICAS DE DISEÑO DE PRUEBA

Ejercicios basados en las técnicas reguladas en este capítulo se dan en esta sección. Las
soluciones son trabajadas dada en la siguiente sección.
el ejercicio de equivalencia Partición / Límite Análisis de Valor
Escenario: Si se toma el tren antes de las 9:30 de la mañana o por la tarde después de las
4:00 pm hasta las 19:30 ( 'hora punta'), que debe pagar la tarifa completa. Un billete protector
está disponible para los trenes entre las 9:30 am y las 4:00 pm, y después de las 7:30.
¿Cuáles son las particiones y los valores límite para poner a prueba los horarios de los trenes
para los tipos de entradas? ¿Cuáles son válidos particiones y que son particiones no
válida? ¿Cuáles son los valores límite? (Una tabla puede ser útil para organice sus particiones
y límites.) Derivar casos de prueba para las particiones y los límites.
¿Hay alguna pregunta que tenga sobre este 'requisito'? Está claro algo? ejercicio tabla de
decisión
Escenario: Si mantiene un '' mayores de 60 años tarjeta de ferrocarril, se obtiene un
descuento del 34% en cualquier compra de entradas. Si usted es viajar con un niño (menor
de 16), se puede obtener un descuento del 50% en cualquier billete si usted tiene una tarjeta
de ferrocarril de la familia, de otro modo se obtiene un descuento del 10%. Que sólo puede
contener un tipo de tarjeta de ferrocarril.
Producir una tabla de decisión que muestra todas las combinaciones de tipos de tarifas y
descuentos resultante y derivar casos de prueba a partir de la tabla de decisiones.
el ejercicio de transición de estados
Escenario: Una cesta de compras sitio web comienza como vacía. Como se seleccionan las
compras, que se añaden a la cesta de la compra. Los elementos también se pueden eliminar
de la cesta de la compra. Cuando el cliente decide visita, un resumen de los artículos de la
canasta y el costo total se muestran, para el cliente que decir si esto está bien o no. Si el
contenido y los precios están bien, luego de salir de la pantalla de resumen y de ir a el sistema
de pago. De lo contrario, vaya de nuevo a compras (para que pueda eliminar elementos si lo
desea).
a. Producir un diagrama de estado que muestra los diferentes estados y transiciones. Definir
una prueba, en términos de la secuencia de estados, para cubrir todas las transiciones.
segundo. Producir una tabla de estados. Dé un ejemplo de ensayo para una transición válida.
Declaración y pruebas decisión ejercicio
Escenario: Una máquina expendedora dispensa cualquiera de bebidas calientes o frías. Si

elige una bebida caliente (por ejemplo, té o café), se le preguntará si desea la leche (y añade
la leche si es necesario), y luego se le pregunta si desea azúcar (y agrega el azúcar
si se requiere), luego de su bebida se dispensa.
a. Dibuje un diagrama de flujo de control para este ejemplo. (Pista: consideran a la selección
del tipo de bebida como una declaración.)
segundo. Dadas las pruebas siguientes, ¿cuál es la cobertura de sentencias logra? ¿Cuál es la
cobertura de decisión conseguido?
Prueba 1: Bebida fría
Prueba 2: Bebida caliente con leche y azúcar
do. ¿Qué pruebas adicionales serían necesarios para lograr una cobertura del 100%
comunicado? ¿Qué pruebas adicionales que sería necesario para lograr una cobertura del
100% de decisión?
SOLUCIONES DE EJERCICIO
ejercicio EP / BVA
Lo primero que debe hacer es establecer exactamente cuáles son los límites entre la tarifa
completa y tarifa ahorro.
Vamos a poner estos en una tabla para organizar nuestros pensamientos:
Hemos asumido que los valores límite son: las 9:29 am, 9:30 am, a las 4:00 de la tarde, 16:01,
7:30 y 07:31 p.m. Al establecer exactamente lo que pensamos que se entiende por la
especificación, podemos destacar algunas ambigüedades o, al menos, plantear algunas
preguntas - este es uno de los beneficios de utilizar la técnica de! Por ejemplo:
"¿Cuándo comienza la hora punta de la mañana? ¿A la medianoche? A las 11:30 pm del día
anterior? En el momento de el primer tren del día? Si es así, ¿cuándo es el primer tren? ¿5:00
de la mañana?'
Esta es una omisión más importante de la especificación. Podríamos hacer una suposición
acerca de cuándo se inicia, pero sería mejor para averiguar lo que es correcto.
• Si un tren se debe dejar exactamente a las 4:00 pm es un boleto protector sigue siendo
válido?
• ¿Qué pasa si un tren se debe dejar antes de las 4:00 pm, pero se retrasa hasta después de
16:00? Es un boleto protector todavía ¿válido? (Es decir, si la hora de salida real es diferente
a la hora de salida programada)
Nuestra tabla anterior nos ha ayudado a ver dónde están las particiones. Todas las particiones
de la tabla anterior son las particiones válidas. Puede ser que una partición no válida sería un
tiempo que ningún tren estaba en marcha, por ejemplo, antes 5:00 am, pero nuestra
especificación no mencionó que! Sin embargo, sería bueno mostrar esta posibilidad también.
Podríamos ser un poco más formal haciendo una lista de todas las particiones y los límites
válidos y no válidos en una mesa, ya que se describe en la Sección 4.3.1, pero en este caso
que en realidad no añadir mucho, ya que todas las particiones son válidos.
Estos son los casos de prueba podemos extraer de este ejemplo:
Tenga en cuenta que los casos de prueba 1, 4, 7 y 10 se basan en valores de partición de
equivalencia; los casos 2, 3, 5, prueba 6, 8 y 9 se basan en los valores de límite. También
puede haber otra información sobre los casos de prueba, como condición previa ciones, que
no hemos mostrados aquí.
ejercicio tabla de decisión

Los tipos de tarifas mencionadas incluyen una tarjeta de ferrocarril de los 60 más ', una tarjeta
de ferrocarril de la familia, y si están viajando con un niño o no. Con tres condiciones o
causas, tenemos ocho columnas en nuestra mesa de decisión siguiente.
Cuando llegamos a llenar los efectos, podemos encontrar esto un poco más difícil. Para las
dos primeras reglas, por ejemplo, ¿cuál debe ser la salida? Es una X debido a la celebración
de más de una tarjeta de carril no debe ser posible? La especificación no dice qué pasa si
alguien nos depara más de una tarjeta, es decir, No se ha especificado la salida, así que quizás
hay que poner un signo de interrogación en esta columna. Por supuesto si alguien hace
sostener dos tarjetas de carril, que probablemente no admitir esto, y tal vez iban a reclamar
el 50% de descuento con su tarjeta de ferrocarril de la familia si están viajando con un niño,
así que quizás deberían poner el 50% para la Regla 1 y 34% para la Regla 2 en esta
columna. Nuestra notación muestra que no sabemos lo que el esperado resultado debe ser por
estas reglas!
Esto pone de relieve el hecho de que nuestro lenguaje natural (Inglés) especificación no es
muy clara en cuanto a lo que el efectos en realidad debería ser. Una de las ventajas de esta
técnica es que obliga a una mayor claridad. Si las respuestas son deletreado hacia fuera en
una tabla de decisión, entonces está claro cuál es el efecto debe ser. Cuando diferentes
personas vienen con diferentes respuestas para las salidas, entonces usted tiene una
especificación de claro!
La palabra 'en otro caso' en la especificación es ambigua. Significa "lo contrario" significa
que siempre podemos encontrar en por lo menos un descuento del 10% o significa que si
viaja con un niño y un sobre de la tarjeta 60, pero no una familia la tarjeta se obtiene el 10%
y el 34%? Dependiendo de lo supuesto de que realice por el significado de "lo contrario", se
obtendrá una fila última diferente en su tabla de decisiones.
Tenga en cuenta que el efecto o la salida es la misma (34%) tanto para los artículos 3 y 4.
Esto significa que nuestra tercera causa (Sea o no un niño también está viajando) en realidad
no tiene influencia en la salida. Estas columnas podrían por lo tanto, ser combinado con 'no
me importa' como entrada para la tercera causa. Este «racionalización» de la mesa significa
que tendremos un menor número de columnas y, por tanto, un menor número de casos de
prueba. La reducción en los casos de prueba se basa en la suposición de que estamos haciendo
sobre el factor de tener ningún efecto en el resultado, por lo que una más completa enfoque
sería incluir cada columna de la tabla.
Aquí hay una tabla racionalizado, donde hemos mostrado nuestras suposiciones acerca de los
dos primeros resultados y nos También se han combinado los artículos 6 y 8, ya que tener
una tarjeta de ferrocarril de la familia no tiene ningún efecto si no está Travel- ing con un
niño.
Estos son los casos de prueba que nosotros sacamos de esta tabla. (Si no racionalizar la tabla,
a continuación, se quiere tiene ocho casos de prueba en lugar de seis.) Tenga en cuenta que
no necesariamente probar cada columna, pero la mesa le permite tomar una decisión sobre
qué combinaciones para poner a prueba y cuáles no para poner a prueba esta vez.
Tenga en cuenta que es posible que hayamos planteado algunas cuestiones adicionales
cuando diseñamos los casos de prueba. Por ejemplo, hace el descuento para una tarjeta de
ferrocarril sólo se aplican a los viajeros o para alguien que viaja con ellos? Aquí tenemos
supone que se aplica a todos los viajeros de ferrocarril de la tarjeta de la familia, pero al
pasajero individual solamente para el mayores de 60 años tarjeta de ferrocarril.
el ejercicio de transición de estados
El diagrama de estados se muestra en la Figura 4.7. El estado inicial (SI) es cuando la cesta
de la compra está vacía. Cuando Se añade un elemento a la cesta, se pasa al estado (S2),
donde hay posibles compras. Algo adicional artículos añadidos a la cesta de no cambiar el
estado (sólo el número total de lo que se compra). Los productos que pueden ser eliminado,
lo que no cambia el estado a menos que el total de elementos ordenados va de 1 a 0. En este
caso, volvemos a la cesta vacía (SI). Cuando queremos hacer la salida, nos vamos al estado
de sumario (S3) para aprobación. Si la lista y los precios son aprobados, vamos al pago
(S4); si no, volvemos al estado de compras (Posiblemente para eliminar algunos elementos
para reducir el precio total que tenemos que pagar). Hay cuatro estados y siete transiciones.
Tenga en cuenta que SI es nuestro Estado de inicio para este ejemplo y S4 es el estado final
- esto significa que no estamos con- trate con cualquier evento que sucede una vez que
lleguemos al estado S4.
Aquí está una prueba para cubrir todas las transiciones. Tenga en cuenta que el estado final
de una etapa o evento es el estado de inicio de el siguiente evento, por lo que estos pasos se
debe hacer en esta secuencia.
Aunque nuestro ejemplo no está interesado en lo que sucede a partir de Estado 4, habría otros
eventos y acciones una vez que entramos en el proceso de pago que podría ser mostrado por
otro diagrama de estado (por ejemplo, comprobar validez dad de la tarjeta de crédito, deduzca
la cantidad, correo electrónico un recibo, etc.).
La tabla de estado correspondiente es:
Todas las cajas que contienen las transiciones - son válidos en este ejemplo. pruebas
negativas ejemplo sería incluir:
• intento de añadir un artículo a partir del estado de resumen y el coste (S3)
• tratar de eliminar un elemento de la cesta vacía de compras (SI)
• tratar de entrar en 'Aceptar', mientras que en el estado de compras (S2).
Declaración y pruebas decisión ejercicio
El diagrama de flujo de control se muestra en la Figura 4.8. Tenga en cuenta que dibujar un
diagrama de control ilustra aquí que la prueba estructural también se puede aplicar a la
estructura de los procesos generales, no sólo a la computadora algoritmos. Los diagramas de
flujo son generalmente fáciles de entender que el texto cuando se está tratando de describir
la resultados de las decisiones tomadas en los acontecimientos posteriores.
En la Figura 4.9, podemos ver la ruta que las pruebas 1 y 2 han tomado a través de nuestro
grafo de control de flujo.
Prueba 1 ha ido hacia abajo de la parte izquierda para seleccionar una bebida fría. Prueba 2
se ha ido a la derecha en cada oportunidad, añadiendo la leche y el azúcar a una bebida
caliente.
Cada declaración (representado por una caja en el diagrama) ha sido cubierto por nuestros
dos pruebas, por lo que tener una cobertura del 100% comunicado.
No hemos tomado el no haya salida ya sea de la leche? ' o "azúcar? ' decisiones, por lo que
hay dos decisiones Los resultados que no hemos probado todavía. Hicimos prueba tanto de
los resultados de la 'caliente o frío? decisión, por lo que hemos cubierto cuatro de los seis
resultados de la decisión. la cobertura de decisión es 4/6 o 67% con los dos pruebas.
No se requieren pruebas adicionales para lograr la cobertura de sentencias, como ya tenemos
una cobertura del 100% de Las declaraciones.
Se necesita un ensayo adicional para lograr una cobertura del 100% de decisión:
Prueba 3: Bebida caliente, sin leche, sin azúcar Este examen abarcará tanto resultado de la
decisión del "no" de la leche y el azúcar decisiones, por lo que lo hará ahora tienen cobertura
de decisión 100%.
CAPÍTULO CINCO
Gestión de Pruebas
La prueba es una actividad compleja. La prueba es a menudo un sub-proyecto distinto dentro
del software más grande desarrollo, mantenimiento, o proyecto de integración. Las pruebas
usualmente representan una sustancial porción del presupuesto total del proyecto. Por
lo tanto, debemos entender cómo debemos gestionar las pruebas que hacemos.
Este capítulo trata sobre los temas esenciales para la gestión de pruebas en seis secciones. La
primera se refiere a la forma de organizar los testers y las pruebas. El segundo se refiere
a la estimación, la planificación y la estrategia del esfuerzo de la prueba. Los terceros
direcciones de prueba monitoreo del progreso, informes de pruebas y control de
prueba. El cuarto explica la gestión de configuración y su relación con las pruebas. El
quinto cubre el tema central de riesgo y cómo las pruebas afectan y es afectada por
riesgos de los productos y de proyectos. La sexta y última sección se analiza la gestión
de incidentes, ambos defectos de los productos y otros eventos que requieren una mayor
investigación.
5.1 ORGANIZACIÓN PRUEBA

1 Reconocer la importancia de las pruebas independientes. (KL)
2 Enumerar las ventajas y los inconvenientes de las pruebas independientes dentro de
una organización. (K2)
3 Reconocer los diferentes miembros del equipo para ser considerado para la creación
de un equipo de pruebas. (KL)
4 Recordemos las tareas de los líderes y los testers de prueba típicos. (KL)
En esta sección, vamos a hablar de la organización de un esfuerzo de la prueba dentro de un

proyecto. Vamos a ver el valor de pruebas independientes, y discutir los beneficios y riesgos
potenciales asociados con las pruebas independientes. Nosotros examinaremos los diversos
tipos de diferentes miembros del equipo de prueba de lo que se quiere en un equipo de
prueba. Y bueno familiarizarnos con las tareas típicas realizadas por los líderes de la prueba
y los testers.
A medida que avanzamos a través de esta sección, mantener los ojos abiertos para los
términos del glosario
tester, el líder de la prueba y director de pruebas.
5.1.1 Las pruebas independientes e integradas

En el capítulo 1 hablamos de pruebas independiente desde la perspectiva psicológica del
individuo tester. En este capítulo, vamos a ver en la organización e implicaciones para la
gestión de la independencia.
Los enfoques para la organización de un equipo de pruebas varían, así como los lugares
en la organización, estructura donde el equipo de prueba se ajusta. La prueba es una
evaluación de calidad, y ya que la evaluación no siempre es positiva, muchas
organizaciones se esfuerzan por crear un clima organizacional donde los testers pueden
ofrecer una independencia, objetiva a la evaluación de la calidad.
Cuando se piensa en la forma independiente del equipo de pruebas es, reconocer que
independencia no es un bien / o estado, sino un proceso continuo. En un extremo de lo
continuo se encuentra la falta de independencia, donde el programador realiza pruebas
dentro del equipo de programación.
Avanzando hacia la independencia, se encuentra un tester o grupo de testers integrado
al equipo de trabajo junto a los programadores, e informan al gerente de desarrollo. Es
posible encontrar un equipo de testers que están independientes y fuera del equipo de
desarrollo, pero la presentación de informes de gestión de proyectos.
Cerca del otro extremo de la escala estaría completa independencia. Podría haber un equipo
de prueba separado en la organización en un punto igual al equipo de desarrollo o
proyecto. Usted puede encontrar especialistas en el negocio de dominio (por ejemplo, los
usuarios del sistema), especialistas en la tecnología (por ejemplo, expertos de bases de
datos), y especialistas en las pruebas (tales como testers de seguridad, certificación testers,
o expertos de automatización de pruebas) en un equipo de prueba separado, como parte de
un equipo de pruebas más grande e independiente o como parte de un contrato, el equipo de
prueba externalizado. Vamos examinar los beneficios y riesgos potenciales de la
independencia, a partir del beneficio.
Organización independiente a menudo puede ver más, y otros defectos diferentes que
un tester de trabajo dentro de un equipo de programación o un tester que es de
profesión un programador. Mientras que los analistas de negocios, personal de marketing,
diseñadores y programadores traen sus propias suposiciones sobre la especificación y
ejecución del programa bajo prueba, organización independiente aportan un conjunto
diferente de hipótesis a las pruebas y a los comentarios, que a menudo ayuda a exponer los
defectos ocultos y los problemas relacionados con la manera de pensar del grupo, como
hemos comentado en Capítulo 3. Un tester independiente trae una actitud escéptica,
sensación de pesimismo en los profesionales, si hay alguna duda sobre la conducta observada,
se debe preguntar: ¿Esto es un defecto?
A nivel de equipo, un equipo de pruebas independiente que informa a una persona mayor o
gerente puede disfrutar de (una vez que se lo han ganado) más credibilidad en la organización
que un supervisor de la prueba o el tester que forma parte del equipo de programación. un
tester independinete que reporta a la alta dirección puede reportar sus resultados con
honestidad y sin preocuparse por las represalias que pudieran derivarse de señalar los
problemas de compañeros de trabajo o, peor aún, el trabajo del gerente. Un equipo de
pruebas independiente a menudo tiene un presupuesto separado, lo que ayuda a
garantizar la inversion adecuado del dinero que es dedicado a la formación del tester,
herramientas de prueba, equipos de prueba, y así sucesivamente. En algunas
organizaciones, los testers en un equipo de prueba independiente puede resultar más fácil de
tener una carrera que conduce en más puestos de alto rango en las pruebas.
Equipos de pruebas independientes no están exentos de riesgos. Es posible que los
testers y el equipo de pruebas estén aislados. Esto puede tomar la forma de aislamiento
interpersonal a partir de los programadores, los diseñadores y el equipo del proyecto
en sí, o puede tomar la forma de aislamiento de la visión más amplia de la calidad y la
objetividad de negocios (por ejemplo, el enfoque obsesivo sobre los defectos, a menudo
acompañado de una negativa a aceptar priorización de los defectos de negocio). Esto
conduce a problemas de comunicación, sentimientos de alineación y la antipatía, la falta
de identificación con apoyo para los objetivos del proyecto, festivales culpa espontáneas
y puñaladas por la espalda político.
Incluso los equipos de pruebas bien integrados pueden sufrir problemas. Otros grupos de
interés del proyecto titulares podrían llegar a ver al equipo de pruebas independiente con o
sin razón como un cuello de botella y una fuente de retraso. Algunos programadores deponen
de sus responsabilidades de calidad, diciendo, 'Bueno, tenemos este equipo de pruebas ahora,
para ¿Por qué necesito hacer pruebas unitarias a mi código?
Debido al deseo de los beneficios de un equipo de pruebas independientes, las empresas los
establecen a veces, sólo para separarlos de nuevo más tarde. ¿Por qué suele ocurrir eso? Una
causa común es el hecho de que el director de pruebas de eficacia gestiona los riesgos de la
independencia enumerados anteriormente. Algunos equipos de prueba sucumben a la
tentación de adoptar una actitud de "no se puede hacer", sabiendo que el proyecto debe
plegarse a sus necesidades y ser flexible cada lado a fin de permitir el éxito del
proyecto. Algunos Testers llegan a actuar como líderes de procesos o como auditores sin
un mandato de gestión y el apoyo adecuados.
El resentimiento y la presión aumenta, hasta que por fin la organización decide que el equipo
de pruebas independiente causa más problemas de los que resuelve. Es especialmente
importante para que los evaluadores y gestores de prueba entiendan a la misión que sirven y
las razones por las que la organización quiere una prueba independiente del equipo. A
menudo, todo el equipo de prueba debe darse cuenta de que, son parte del equipo de
proyecto independientes, que existen para proporcionar un servicio al equipo de
proyecto.
No hay un solo enfoque correcto para la organización de pruebas. Para cada proyecto,
debe tener en cuenta si va a utilizar un equipo de pruebas independiente, basado en el
proyecto, el dominio de aplicación, y los niveles de riesgo, entre otros factores. A medida
que el tamaño, la complejidad y la criticidad del proyecto aumenta, es importante tener
independencia en los niveles posteriores de las pruebas (como prueba de integración,
prueba del sistema y la prueba de aceptación), aunque algunas pruebas a menudo es
mejor que se hagan por otras personas, tales como directores de proyectos, gerentes de
calidad, desarrolladores, expertos en negocios y de dominio o infraestructura o expertos
en operaciones de TI.
5.1.2 Trabajando como un líder de la prueba

Hemos visto que la ubicación de un equipo de pruebas dentro de una organización del
proyecto puede variar ampliamente. Del mismo modo hay una amplia variación en los
roles que juega la gente dentro del equipo de prueba. Algunas de estas funciones se producen
con frecuencia, algunos con poca frecuencia. Dos roles que se encuentran dentro de
muchos equipos de prueba son los del tester y el líder tester, aunque las mismas personas
pueden desempeñar ambos papeles en varios puntos durante el proyecto. Vamos a echar un
vistazo a los trabajos realizados en estos papeles, a partir de la prueba líder.
Los líderes de prueba tienden a estar involucrados en la planificación, el seguimiento y
control de las actividades de prueba y las tareas se discuten en la Sección 1.5 en la prueba
fundamental proceso. Al inicio del proyecto, los líderes de la prueba, en colaboración
con otras partes interesadas, diseñar los objetivos de la prueba, las políticas de la
organización de la prueba (si no ya en el lugar), las estrategias de prueba y planes de
pruebas. Se estiman las pruebas que hay hacer y negocian con la dirección para
adquirir los recursos necesarios.
Reconocen cuando la automatización de pruebas es adecuada y, si lo es, planean el
esfuerzo, seleccionar las herramientas, y garantizar la formación del equipo. Pueden
consultar con otros grupos, por ejemplo, los programadores para ayudarles con sus
pruebas. Conducen, orientan y supervisan el análisis, diseño, implementación y ejecución de
los casos de prueba, procedimientos de prueba. Aseguran configuración adecuada la gestión
del testware producido y la trazabilidad de las pruebas para la prueba base.
A medida que se acerca la ejecución de pruebas, se aseguran de que el entorno de prueba este
en su lugar antes de la ejecución de pruebas y administrado durante la ejecución de la
prueba. Ellos programan las pruebas para la ejecución y luego monitorean, meden, controlan
e informan sobre el progreso de la prueba, el estado de la calidad del producto y los resultados
de las pruebas, adaptar el plan de pruebas y compensando como sea necesario para adaptarse
a la evolución de condiciones. Durante la ejecución de prueba y medida que el proyecto vaya
remitiendo, las que escriben resúmenes de estado de la prueba.
A veces los líderes de prueba tienen diferentes títulos, como director de pruebas o
coordinador de prueba. Por otra parte, el papel supervisor de la prueba puede terminar
asignado a un director del proyecto, un gerente de desarrollo o un gerente de control de
calidad.
(En cuanto a las dos primeras personas en esta lista, advirtiendo campanas sobre la
independencia debería estar sonando en tu cabeza ahora, además de los pensamientos acerca
de cómo podemos asegurar que tales testers no obtienen el conocimiento y la perspectiva
necesaria para administrar la prueba.) El que está jugando el papel, esperan que les permite
planificar, monitorizar y controlar el trabajo de prueba.
5.1.3 Trabajando como un tester

Al igual que con los líderes de la prueba, los proyectos deben incluir los testers, en primer
lugar, a pesar de que es a menudo el caso de que el proyecto no necesita un complemento
completo de los testers hasta que el período de ejecución de la prueba. En las fases de
planificación y preparación de la prueba, los testers deben revisar y contribuir a los planes de
prueba, así como al análisis, la revisión y la evaluación de los requisitos y especificaciones
de diseño. Pueden ser involucrado en, o incluso ser las primeras personas que
identifican condiciones de prueba y creación de diseños de prueba, casos de prueba,
especificaciones del procedimiento de prueba y datos de prueba, y pueden ayudar a
automatizar las pruebas. A menudo establecen el ambiente de prueba o ayudan a la
administración del sistema y la gestión del personal.
Cuando comienza la ejecución de pruebas, el número de testers aumenta a menudo, a partir

del trabajo necesario para aplicar las pruebas en el entorno de prueba. (Pueden jugar
un papel en todos los niveles de la prueba, incluso aquellos que no están bajo el control
directo de la prueba grupo; por ejemplo, se podría aplicar pruebas unitarias que fueron
diseñados por los programadores.) Los testers ejecutan y registran las pruebas, evalúan los
resultados y el documento con problemas encontrados. Siguen de cerca la prueba y el entorno
de prueba, a menudo el uso de herramientas para esta tarea, ya menudo recopilar las métricas
de rendimiento. En todo el ciclo de vida de las pruebas, que revise el trabajo del otro,
incluyendo prueba de especificaciones, informes de defectos y resultados de pruebas.
5.1.4 Definición de la necesidad de habilidades del personal de pruebas
Hacer pruebas correctamente requiere más que definir las posiciones correctas y
número de personas para estos cargos. Los buenos equipos de prueba tienen la
combinación adecuada de habilidades basadas en las tareas y actividades que se debe llevar
a cabo, y las personas fuera del equipo de pruebas que están a cargo de las tareas de prueba
necesitan los conocimientos adecuados, también.
Las personas que participan en las pruebas necesitan cualificaciones profesionales y
sociales básicas tales como leer y escribir, capacidad para preparar y entregar por
escrito y verbal informes, la capacidad de comunicarse de manera efectiva, y así
sucesivamente. Ir más allá que, cuando pensamos en las habilidades que necesitan testers,
tres áreas principales vienen a mente:
• Aplicación de dominio o de negocios: Un tester debe entender el comportamiento, el
problema del sistema que va a resolver, el proceso que va a automatizar y etc., con el fin de
detectar el comportamiento inadecuado durante las pruebas y reconocer “Como deben
trabajar las funciones y características”.
• Tecnología: Un tester debe ser consciente de los problemas, limitaciones y capacidades
de la tecnología de aplicación escogida, con el fin de localizar los problemas con eficacia y
eficientemente y reconocer la 'probabilidad de falla' y funciones características.
• Pruebas: Un tester debe conocer los temas de prueba analizados en este libro y temas sobre
la prueba a menudo más avanzados con el fin de llevar a cabo eficaz y eficiente las tareas de
prueba asignadas.
Las habilidades específicas en cada área y el nivel de habilidad requerido varían según
el proyecto, organización, aplicación, y los riesgos involucrados.
El conjunto de tareas y actividades de prueba son muchas y variadas, y también lo son las
habilidades requeridas, por lo que a menudo se ven la especialización de habilidades y
separación de roles. Por ejemplo, debido al conocimiento especial requerido en las áreas de
las pruebas, la tecnología y los negocios de dominio, respectivamente, los expertos del
instrumento de medida pueden manejar la automatización de las pruebas de regresión, los
programadores pueden realizar pruebas de componente, pruebas de integración y de los
usuarios y de integración y los operadores pueden estar involucrados en prueba de
aceptación.
Hemos defendido durante mucho tiempo la prueba generalizada, la participación de las
personas en todo el equipo del proyecto en la realización de tareas de prueba. Cerremos este
sección, sin embargo, en una nota de advertencia. Las compañías de software y del sistema
(Por ejemplo, los productores de software empaquetado y productos de consumo)
típicamente sobrestiman el conocimiento de tecnologías necesarias para ser un eficaz
tester. Las empresas que utilizan la tecnología de la información (por ejemplo, bancos y
compañías de seguros) normalmente sobreestiman el conocimiento del dominio de negocio
necesario.
Todos los tipos de proyectos tienden a subestimar el conocimiento de pruebas

necesario. Hemos visto un proyecto fracasar en parte porque personas sin los
conocimientos y habilidades apropiadas, evalúan componentes críticos, más tarde esto
condujo al descubrimiento de desastrosos problemas fundamentales de
arquitectura. La mayoría de los proyectos pueden beneficiarse de la participación de
los testers profesionales, como las pruebas de aficionados por lo general solo se No es
suficiente.
5.2 Planes de Pruebas, Estimaciones y Estrategias

1 Reconocer los diferentes niveles y objetivos de la planificación de pruebas. (KL)
2 Resumir el propósito y el contenido del plan de prueba, prueba característica de
diseño y procedimiento de prueba de acuerdo con los documentos [IEEE 829]. (K2)
3 Recordemos factores típicos que influyen en el esfuerzo relacionado con
pruebas. (KL)
4 diferenciar entre dos enfoques conceptualmente diferentes: el enfoque basado en la
métrica y el enfoque basado en el experto. (K2)
5 Diferenciar entre el tema de la planificación de prueba para un proyecto, para los
niveles de prueba individuales (por ejemplo, prueba del sistema) u objetivos específicos
de prueba (por ejemplo, usabilidad prueba), y para la ejecución de la prueba. (K2)
6 Lista de las tareas de preparación y ejecución de pruebas que necesitan
planificación. (KL)
7 Reconocer y justificar los criterios de salida adecuadas para la prueba específica los
niveles y grupos de casos de prueba (por ejemplo, para las pruebas de integración,
aceptación prueba o las pruebas de usabilidad). (K2)
En esta sección, vamos a hablar de un trío de temas complicados de prueba: planes,

presupuestos y estrategias. Los planes, estimaciones y estrategias dependerán de un
número de factores, incluyendo el nivel, objetivos y objetivos de la prueba que estamos
a punto de realizar. Escribir un plan, preparar una estimación y seleccionar estrategias de
prueba tienden a ocurrir simultáneamente e idealmente durante el período de planificación
para el proyecto en general, aunque debemos estar dispuestos a revisarlas y obtener más
información para el avance del proyecto.
Veamos de cerca cómo preparar un plan de pruebas, el examen cuestiones relacionadas con
la planificación de un proyecto, para un nivel de prueba o fase, para un tipo específico de
prueba y de ejecución de la prueba. Examinaremos factores típicos que influyen en el
esfuerzo relacionados con las pruebas, y ven dos enfoques diferentes de la estimación:
métricas de base y basado en un experto. Discutiremos la selección de estrategias de
prueba y las formas de establecer criterios de salida adecuadas para la prueba. Además,
vamos a ver diferentes tareas relacionadas con la preparación y ejecución de pruebas que
requieren la planificación.
Al leer, mantener los ojos abiertos para el glosario de términos de criterios entrada, los
criterios de salida, prueba exploratoria, el enfoque de la prueba, el nivel de prueba, plan
de pruebas, procedimiento de prueba y la estrategia de prueba.
5.2.1 El propósito y el contenido de los planes de prueba

Mientras que las personas tienden a tener diferentes definiciones de lo que sucede en una
plan de pruebas, para nosotros un plan de pruebas es el plan del proyecto a realizar para
el trabajo de pruebas. No es una especificación de diseño de la prueba, una colección
de casos de prueba o un conjunto de procedimientos de prueba; de hecho, la mayor parte
de nuestros planes de prueba, No abordan ese nivel de detalle.
¿Por qué escribimos planes de prueba? Tenemos tres razones principales.
En primer lugar, escribir un plan de pruebas guía nuestro pensamiento. Encontramos
que, si puede explicar algo con palabras, lo entendemos. Si no es así, hay una buena
probabilidad de que no.
Escribir un plan de pruebas nos obliga a hacer frente a los retos que nos esperan y
enfoca nuestro pensamiento sobre temas importantes. En el capítulo 2 de Fred Brooks
brillante y libro esencial en la gestión de la ingeniería de software, El mes laboral mítico,
explica la importancia de la estimación y planificación cuidadosa para los ensayos lo
siguiente:
Si no se permite suficiente tiempo para la prueba del sistema, en particular, es
particularmente desastrosa. Dado que el retraso se produce al final del horario, nadie es
consciente de lo previsto hasta casi el problema fecha de entrega [y] retraso en este punto
tiene inusualmente severas repercusiones financieras. El proyecto está dotado de personal,
y el coste por día es el máximo [como son los costos de oportunidad asociados]. Es por lo
tanto, muy importante para que haya suficiente tiempo de prueba en el sistema de
calendario original.
[Brooks, 1995]
Encontramos que el uso de una plantilla al escribir los planes de prueba nos ayuda a
recordar los retos importantes. Puede utilizar la plantilla del plan de prueba IEEE 829 se
muestra en este capítulo, utilizar de otra persona plantilla o crear su propia plantilla con el
tiempo.
El proceso de planificación de prueba y el plan en sí sirven como vehículos para la
comunicación con otros miembros del equipo del proyecto, testers, compañeros,
directivos y otras partes interesadas. Esta comunicación permite que el plan de pruebas
pueda influir en el equipo del proyecto y también en el plan de pruebas, especialmente en las
áreas de las políticas y las motivaciones de pruebas de toda la organización; Prueba de
alcance, objetividad y áreas críticas a la prueba; proyecto y del producto riesgos,
consideración de recursos y limitaciones; y la capacidad de prueba del elemento bajo prueba.
Esto se puede hacer a través de la comunicación de circulación de uno o dos planes de pruebas
corrientes de aire y a través de las reuniones de revisión. un proyecto de tales incluirá muchos
notas tales como los siguientes:
[Por determinar: Jennifer: Por favor dígame cuál es el plan para la liberación de la prueba
elementos en el laboratorio de pruebas para cada ciclo de ejecución de la prueba del sistema]
[de Dave por favor me deja saber qué versión de la herramienta de prueba se utilizará para
las pruebas de regresión de los incrementos anteriores.]
Como documentar las respuestas a estas preguntas, el plan de pruebas se convierte en un
registro de las discusiones previas y acuerdos entre los testers y el resto del equipo del
proyecto.
El plan de pruebas también nos ayuda a gestionar el cambio. Durante las primeras fases
del proyecto, podemos reunir más información, revisamos nuestros planes. Como el proyecto
evoluciona y las situaciones cambian, nos adaptamos a estos planes. planes de pruebas
escritos nos dan una línea de base para medir dichas revisiones o cambios. Además, la
actualización del plan en los principales hitos de la prueba ayuda a mantener alineado con el
proyecto necesariamente. Mientras ejecutamos las pruebas, hacemos los ajustes finales
en nuestros planes en base a resultados. Puede que no tenga el tiempo o la energía para
actualizar sus planes de prueba cada vez que se produce una variación, ya que algunos
proyectos pueden ser muy dinámico. en el capítulo 6 [Negro, 2001], se describe un método
sencillo para documentar las variaciones respecto el plan de prueba que se puede
implementar utilizando una base de datos u hoja de cálculo. Usted puede incluir estos
registros de cambio en una actualización periódica del plan de pruebas, como parte de
un informe de estado prueba, o como parte de un resumen de la prueba al final de su
proyecto.
Hemos encontrado que es mejor escribir varios planes de prueba en algunas
situaciones. Por ejemplo, cuando logramos la integración al sistema de niveles de
prueba, los dos períodos de ejecución de pruebas ocurrirán en diferentes momentos y tienen
diferentes objetivos. Para algunos proyectos de sistemas, un plan de pruebas de hardware y
software de un plan de prueba abordará diferentes técnicas y herramientas, así como los
diferentes públicos.
Sin embargo, ya que puede haber superposición entre estos planes de prueba, una prueba del
plan maestro que se dirige a los elementos comunes puede reducir la cantidad redundante de
documentación.
Plantilla Standard IEEE 829 del plan de pruebas
identificador de plan de pruebas entregables de prueba

Introducción Tareas de prueba
Elementos de prueba ]Necesidades ambientales
Características para ser probadas Responsabilidades
Características no a probar Las necesidades de personal y de formación
Enfoque Programar
Elemento pasa / no pasa criterios Riesgos y Contingencias
Criterios de suspensión y reanudación Aprobaciones
5.2.2 ¿Qué hacer con su cerebro, mientras las pruebas se planifican?

Escribir un buen plan de pruebas es más fácil que escribir una novela, pero ambas tareas
requieren un enfoque organizado y el pensamiento cuidadoso. De hecho, un plan de prueba
debe ser bueno, breve y centrado, a diferencia de algunas novelas, algunos podrían
argumentar que es más difícil para escribir un buen plan de pruebas. Veamos algunas de las
tareas de planificación que debemos llevar a cabo.
A un alto nivel, es necesario considerar el propósito servido por el trabajo de prueba.

En términos de las necesidades globales de la organización, este propósito se denomina
variablemente como la misión del equipo de prueba o la política de pruebas de la
organización. En términos del proyecto específico, la comprensión del propósito de la
prueba significa conocer las respuestas a preguntas tales como:
• ¿Cuál es su alcance y lo que está fuera del alcance de esta prueba de esfuerzo?
• ¿Cuáles son los objetivos de la prueba?
• ¿Cuáles son los riesgos importantes de los proyectos y productos? (Más información sobre
los riesgos de Sección 5.5).
• ¿Las restricciones afectan las pruebas (por ejemplo, limitaciones presupuestarias, plazos
duros, etc.)?
• que es lo más importante para este producto y el proyecto?
• ¿Qué aspectos del producto son más (o menos) comprobable?
• ¿Cuál debería ser el calendario general de ejecución de pruebas y cómo deberíamos
decidir el orden en el que se ejecutan pruebas específicas? (Producto y la planificación
riesgos, discutido más adelante en este capítulo, influirán en las respuestas a estas preguntas).
A continuación, debe seleccionar las estrategias que sean adecuadas a los fines de
prueba (más en el tema de la selección de estrategias en unas pocas páginas). Además, es
necesario decidir cómo dividir el trabajo de pruebas en varios niveles, como se discutió
en el capítulo 2 (por ejemplo, componentes, integración, sistema y aceptación). Si ya se ha
tomado esa decisión, es necesario decidir cómo adaptarse mejor al trabajo de pruebas en el
nivel en el que es responsable de la prueba trabajo realizado en los otros niveles de la
prueba. Durante el análisis y diseño de pruebas, usted querrá reducir las brechas y la
superposición entre los niveles y durante la ejecución de pruebas, tendrá que coordinar
entre los niveles. Estos detalles se ocupan de la coordinación entre el plan maestro de
pruebas y los diferentes niveles se tratan a menudo.
Además de la integración y coordinación entre los niveles de prueba, usted debe tener
también un plan para integrar y coordinar todo el trabajo de pruebas a hacerse con el resto
del proyecto. Por ejemplo, ¿qué elementos deben ser adquiridos para la prueba?
¿Están en curso los problemas de suministro, como con las cuentas de imitación (es decir,
simula billetes de banco) para una aplicación financiera, como un cajero
automático? ¿Cuándo el programador realiza la obra completa en el sistema bajo
prueba? ¿Qué operaciones de apoyo es requerida para el entorno de prueba? ¿Qué tipo de
información debe ser entregado para el equipo de mantenimiento al final de la prueba?
Descendiendo en los detalles, lo que hace que un plan sea un plan en lugar de una declaración
larga de una lista de buenas ideas o una colección de sugerencias es que el autor es quién
especifica que se hará en ella, cómo y cuándo (por lo menos es la idea general). Se necesitan
recursos para llevar a cabo el trabajo. Estos son a menudo decisiones difíciles que requieren
una cuidadosa consideración y la construcción de un consenso con todo el equipo de trabajo,
incluso con el director del proyecto.
Todo el proceso de prueba desde la planificación hasta el cierre produce información,

algunas de las cuales se tendrán que documentar. ¿Con qué precisión debe el testers
escribir los casos de prueba, diseños y procedimientos? ¿Cuánto se le deja a juicio del tester
durante la ejecución de la prueba, y cuáles son los problemas de reproducibilidad asociados
con esta decisión? ¿Qué tipos de plantillas pueden utilizar los testers para los diversos
documentos que van a producir? ¿De qué manera esos documentos se relacionan entre sí? Si
tiene intención de utilizar herramientas para tareas como la prueba de diseño y ejecución,
como se discute en el capítulo 6, que necesita para entender esas herramientas de captura de
información mientras se trabaja en el plan.
Algunos saben qué información deberá reunirse en forma de datos en bruto y luego
destilar. ¿Qué métricas va a utilizar para supervisar, controlar y gestionar las pruebas ¿Cuál
de esas métricas va a utilizar para y que otras métricas? informar de sus resultados Vamos a
ver más de cerca las posibles respuestas a estas preguntas en la Sección 5.3, pero un buen
plan de pruebas de dar respuestas al principio del proyecto.
Por último, se mueve hacia atrás hasta un nivel más alto, pensar en lo que sería verdad sobre
el proyecto cuando el proyecto estaba listo para comenzar a ejecutar las pruebas. ¿Qué sería
verdad sobre el proyecto cuando el proyecto estaba listo para hacer la prueba de
ejecución? ¿En qué momento se puede empezar con seguridad un nivel de prueba o fase
particular, conjunto de pruebas o destino de la prueba? ¿Cuándo se puede acabar? Los
factores a considerar en tales decisiones son a menudo llamados "criterios de entrada»
y «criterios de salida. ' Para tales criterios, factores típicos son:
• Adquisición y suministro: la disponibilidad de personal, herramientas, sistemas y otros
materiales necesarios.
• Los elementos de prueba: el estado en que los elementos a probar deben estar al poner en
marcha y al terminar la prueba.
• Defectos: el número conocido de estar presente, la tasa de entrada, predecir el número que
permanecerán, y el número total resuelto.
• Pruebas: el número de ejecución, pasada, con error, bloqueado, saltos, y así sucesivamente.
• Cobertura: las partes de la base de pruebas, el código de software o ambos que han sido
probado y cuáles no.
• Calidad: el estado de las características de calidad importantes para el sistema.
• Dinero: el costo de encontrar un defecto en el nivel actual de las pruebas, en
comparación con el costo de encontrarlo en el siguiente nivel de la prueba (o de producción).
• Riesgo: los resultados no deseados que podrían resultar de envío demasiado pronto
(Tales como defectos o áreas no probados latente) o demasiado tarde (tal como pérdida de
mercado compartir).
Al escribir los criterios de salida, tratamos de recordar que el éxito del proyecto es un
equilibrio de las consideraciones de calidad, presupuesto, agenda y consideraciones o
características. Esto es aún más importante a la hora de aplicar los criterios de salida
al final del proyecto.
5.2.3 Estimación de las pruebas de lo que implicará y lo que costará

El trabajo de pruebas a realizar a menudo puede ser visto como un subproyecto dentro del
proyecto más grande. Por lo tanto, podemos adaptar las técnicas fundamentales de la
estimación para la prueba. Nosotros podríamos comenzar con una estructura de trabajo
de desintegración que identifica las etapas, actividades y tareas.
Comenzando en el nivel más alto, podemos descomponer un proyecto en fases de pruebas
mediante el proceso de prueba fundamental identificado en el Plan de estudios ISTQB:
planificación y control; análisis y diseño; implementación y ejecución; Evaluar criterios
de salida y presentación de informes; y el cierre de prueba. Dentro de cada fase se
identifican las actividades y dentro de cada actividad identificamos tareas y quizás
subtareas. Debemos identificar actividades y tareas, que trabajan tanto hacia delante
como hacia atrás. Cuando decimos que trabajamos hacia adelante, queremos decir que
comenzamos con las actividades de planificación y luego movemos hacia adelante en el
paso a paso de tiempo, preguntando: ¿Ahora qué viene? '
Trabajando hacia atrás significa que tenemos en cuenta los riesgos que se identificaron
durante análisis de riesgos (del que hablaremos en la sección 5.5). Para aquellos riesgos
que se tiene la intención de abordar a través de pruebas, se pregunta, ¿Qué actividades
y tareas se requieren en cada etapa para llevar a cabo esta prueba? Veamos un ejemplo
de cómo usted puede trabajar hacia atrás.
Supongamos que usted ha identificado el rendimiento (performance) como un área
importante de riesgo para su producto. Por lo tanto, las pruebas de rendimiento es una
actividad en la fase de ejecución de la prueba. Ahora estimas las tareas involucradas con la
ejecución de una prueba de rendimiento, cuánto tiempo llevarán esas tareas y el número de
veces que se necesita para ejecutar la pruebas.
Ahora, esas pruebas no acaban de aparecer de la nada: alguien tenía que desarrollarlas. Por
lo tanto, el desarrollo de pruebas de rendimiento implica actividades de análisis de la prueba,
el diseño e implementación. Ahora podrá valorar las tareas implicadas en el desarrollo de una
prueba de rendimiento, tales como la escritura de guiones de prueba y la creación de datos
de prueba, persona.
Por lo general, las pruebas de rendimiento se deben ejecutar en un entorno de prueba especial
que está diseñado para parecerse al entorno de producción o de campo, por lo menos en
aquellas formas que podrían afectar el tiempo de respuesta y la utilización de recursos y
desempeño, las pruebas necesitan herramientas especiales para generar carga y comprobar la
respuesta. Por lo tanto, pruebas de desempeño en ambientes de adquisición y la configuración
es una actividad en la fase de prueba de implementación. Ahora podrá valorar las tareas
involucradas en la adquisición y calcular un ambienta para este tipo de prueba, tales como la
simulación de rendimiento en el entorno de producción para buscar posibles cuellos de
botella, para obtener el hardware, software, herramientas y la configuración de hardware,
software y herramientas.
No todo el mundo sabe cómo usar las herramientas de pruebas de rendimiento o pruebas de
diseño de alto rendimiento. Por lo tanto, pruebas de rendimiento de formación o dotación de
personal es una actividad en la fase de planificación de las pruebas. Dependiendo del enfoque
que desea tomar, ahora estimar el tiempo necesario para identificar y contratar a un
profesional de pruebas de rendimiento o para formar una o más personas en su organización
para hacer el trabajo.
Por último, en muchos casos, un plan detallado de las pruebas se ha escrito para las
pruebas de rendimiento, debido a sus diferencias con respecto a otros tipos de
pruebas. Por lo tanto, la planificación de pruebas de rendimiento es una actividad en la fase
de planificación de las pruebas. Ahora estimar el tiempo requerido para realizar el borrador,
revisar y finalizar un plan de pruebas de rendimiento.
Cuando va a crear su estructura de trabajo y se descompone (sub-tareas), recuerde que usted

querrá usarlo tanto para la estimación (al principio) el seguimiento y de control (como el
proyecto sigue). Para asegurar la precisión de la estimación y un control preciso, asegúrese
de que subdividir el trabajo finamente. Esto significa que las tareas deben ser de corta
duración, de uno a tres días. Si ellas están mucho más tiempo dicen dos semanas entonces se
corre el riesgo de que las sub-tareas largas y complejo se 'escondan o solapen' dentro de la
tarea más grande, sólo para ser descubierto más adelante. Esto puede dar lugar a sorpresas
desagradables durante el proyecto.
5.2.4 Las técnicas de estimación
Hay dos técnicas para la estimación cubiertos por la Fundación ISTQB Silaba. Uno
consiste en consultar a las personas que van a hacer el trabajo y otra perssonas con
experiencia en las tareas a realizar. La otra consiste en el análisis de métricas de
proyectos anteriores y de datos de la industria.
Veamos cada uno de ellos.
Pidiendo a los Expertos contribuyentes implicados en el trabajo y con experiencia,
seleccionar miembros del personal para desarrollar una estructura de trabajo en subtrabajo
para el proyecto. Una vez hecho esto, se trabaja en conjunto para comprender, cada tarea, el
esfuerzo, duración, dependencias y recursos requisitos. La idea es hacer uso de la sabiduría
colectiva del equipo para crear su estimación de prueba. El uso de una herramienta como
Microsoft Project o una pizarra blanca y notas adhesivas, usted y el equipo pueden entonces
predecir las pruebas finales actualizadas y los principales hitos. Esta técnica es a menudo
llamada estimación 'de abajo hacia arriba' porque se inicia en el nivel más bajo de la
estructura jerarquía de trabajo, se desintegra en tareas y define la duración, esfuerzo,
dependencias y recursos para cada tarea y se suman a través de todas la Tareas.
Análisis de métricas pueden ser tan simples o sofisticados como usted lo quiera. el
enfoque más simple es preguntar, "¿Cuántos testers son los que normalmente tenemos
por desarrollador en un proyecto? Un enfoque algo más fiable implica la clasificación
del proyecto en términos de tamaño (pequeño, mediano o grande) y la complejidad
(simple, moderado o complejo) y luego ver, en promedio, los proyectos en cuánto al
tiempo, el tamaño y la complejidad de combinación han tenido características similares
en el pasado. Otro enfoque simple y fiable es mirar el esfuerzo promedio por caso de prueba
en proyectos anteriores similares y utilizar el número estimado de casos de prueba para
estimar el esfuerzo total. enfoques sofisticados implican la construcción de modelos
matemática en una hoja de cálculo para que se parezcan a los promedios históricos o de la
industria para determinados parámetros clave, número de pruebas realizadas por el tester por
día, número de defectos encontrados por tester por día, etc. y después de conectar esos
parámetros para predecir duración y esfuerzo para tareas o actividades clave en su
proyecto. La relación del tester y el desarrollador es un ejemplo de una técnica de estimación
de arriba hacia abajo, en la que toda estimación se deriva a nivel de proyecto, mientras que
la técnica paramétrica es de abajo hacia arriba, por lo menos cuando se utiliza para estimar
las tareas o actividades individuales.
Preferimos empezar haciendo uso de la sabiduría del equipo para crear el desglose de
la estructura de trabajo y una estimación detallada de abajo hacia arriba. A
continuación, aplicamos modelos y reglas generales para comprobar y ajustar la
estimación de abajo hacia arriba y de arriba hacia abajo con el uso de historias
pasadas. Este enfoque tiende a crear una estimación que es a la vez más exacta y más
defendible que cualquiera de las técnicas por sí mismo.
Incluso la mejor estimación se debe negociar con la dirección. sesiones de negociación

exhiben increíbles variedades, dependiendo de las personas involucradas. Sin embargo,
hay algunas posiciones de negociación clásicas. No es raro que el líder de la prueba o gerente
trate de vender al equipo de gestión el valor añadido por la prueba o para alertar a la gestión
de los problemas potenciales que resultarían de no realizar pruebas suficientes. No es inusual
para una gestión que debe buscar formas inteligentes para acelerar el calendario o para
presionar por una cobertura equivalente en menos tiempo o con menos recursos. En
medio de estas posiciones, usted y sus colegas pueden llegar a comprometerse, si las partes
están dispuestas. Nuestra experiencia ha sido exitosa en negociaciones sobre las estimaciones
en donde la atención se centra en ganar y perder menos y más acerca de averiguar la mejor
manera de equilibrar las presiones de la competencia en los ámbitos de la calidad,
programación, presupuesto.
5.2.5 Factores que afectan el esfuerzo de la prueba

La prueba es una tarea compleja en muchos proyectos y una variedad de factores que
pueden influir en él. Al crear planes de prueba y la estimación del esfuerzo de prueba y
horarios, debe mantener estos factores en mente o sus planes y estimaciones lo
engañaran al comienzo del proyecto y traicionar en medio o al final del mismo. Las
estrategias de prueba o enfoques que usted escoge tendrán una influencia importante
en las pruebas de esfuerzo. Este factor es tan influyente que vamos a volver a ella en la
Sección 5.2.6. En esta sección, vamos a ver los factores relacionados con el producto, el
proceso y los resultados de las pruebas.
Factores de productos comienzan con la presencia de documentación suficiente del

proyecto por lo que los testers puede averiguar lo que el sistema es, cómo se supone que
funciona
y qué comportamiento correcto aparece. En otras palabras, información adecuada de
alta calidad sobre la base de pruebas nos ayudará a hacer un mejor trabajo, más
eficiente para la definición de las pruebas.
La importancia de las características de calidad no funcionales como la usabilidad,

fiabilidad, seguridad, rendimiento, y así sucesivamente también influye en el esfuerzo
de prueba. Estos objetivos de la prueba pueden ser costoso y consume mucho tiempo.
La complejidad es otro factor importante del producto o proyecto. Ejemplos de

consideraciones de complejidad incluyen:
• La dificultad de comprender y manejar correctamente el problema del sistema, está

siendo construido para resolver (por ejemplo, la aviónica (Aplicación de la electrónica a la
aviación) y el software de exploración de petróleo);
• El uso de tecnologías innovadoras, especialmente los de largo o corto historial probado
• La necesidad de configuraciones de prueba complicadas y quizás varias, especialmente
cuando éstas dependen de la llegada oportuna de software escasos, hardware y otros
suministros;
• La prevalencia de las normas de seguridad muy estrictas, estrictamente reglamentadas u
otros procesos reglamentos;
• La distribución geográfica del equipo, sobre todo si los cruces del equipo zonas horarias
(como muchos de los esfuerzos de externalización a hacer).
Mientras que la buena documentación del proyecto es un factor positivo, también es cierto
que tener que presentar la documentación detallada, como prueba meticulosamente
especificada, da lugar a retrasos. Durante la ejecución de pruebas, tener que mantener tan
detallada la documentación requiere mucho esfuerzo, como lo hace el trabajo con datos de
prueba frágil debe ser mantenido o restaurado con frecuencia durante la prueba. Finalmente,
el aumento del tamaño del producto conduce a aumentos en el tamaño del proyecto y el
equipo del proyecto aumenta, aumenta la dificultad de predecir y gestionar el proyecto. Esto
conduce a la desproporcionada tasa de colapso de grandes proyectos.
Factores de proceso incluyen en la disponibilidad de herramientas de prueba, especialmente

los que reducen el esfuerzo asociado con la ejecución de la prueba, que está en la ruta crítica
para lanzamiento. En cuanto al desarrollo, herramientas de depuración y la depuración
dedicada al entorno (a diferencia de la depuración en el entorno de prueba) también reduce
el tiempo requerido para completar la prueba.
El ciclo de la vida mismo es un factor influyente en el proceso, como el modelo V tiende a

ser más frágil en la cara de cambio de última hora mientras que los modelos incrementales
tienden a tener alta costes de las pruebas de regresión. la madurez del proceso, incluyendo la
madurez del proceso de prueba, están entre los factores, especialmente la implicación de que
los procesos maduros implican manejar cuidadosamente cambios en el medio y al final del
proyecto, que reduce el coste de ejecución de pruebas.
La presión del tiempo es otro factor a considerar. La presión no debe ser una excusa
para tomar riesgos innecesarios. Sin embargo, es una razón para hacer una cuidadosa,
consideración de decisiones, planificar y volver a planificar de manera inteligente
durante todo el proceso, que es otra característica de los procesos maduros.
Las personas ejecutan el proceso, y los factores son tan importantes o más importante
que cualquier otra. De hecho, incluso cuando muchas cosas preocupantes son
verdaderas sobre un proyecto, un excelente equipo a menudo puede hacer que sucedan
cosas buenas en el proyecto y en las pruebas. Se incluyen las habilidades de las personas
en el equipo en su conjunto, y la alineación de esas habilidades con el proyecto
necesariamente. Desde un proyecto, en un equipo de trabajo, las relaciones sólidas, la
ejecución fiable de compromisos acordados y responsabilidades son determinantes para
trabajar juntos hacia un objetivo común. Esto es especialmente importante para
pruebas, donde gran parte de lo que probamos, el uso y lo que se genera proviene del
grupo mismo, o va a la gente fuera del grupo de prueba. Debido a la importancia de
relaciones de confianza y la larga curva de aprendizaje que participan tiene en software
y la ingeniería de sistemas, también es un importante factor humano, para la estabilidad
del equipo de proyecto.
La cantidad total de esfuerzo de la prueba durante la ejecución de la misma son importantes

para los resultados de la prueba. La entrega de software de buena calidad en el comienzo de
la ejecución de la prueba y rápidas soluciones sólidas a anomalías, evita retrasos en el proceso
de ejecución de la prueba. Un defecto, una vez identificados, no debería tener que ir a través
de múltiples ciclos de corrección / retest / re-abierta, al menos no si la estimación inicial se
va a celebrar ya.
Usted probablemente ha notado que a partir de esta lista se incluyeron una serie de factores
fuera del alcance y control del supervisor de la prueba o el administrador. De hecho, los
eventos que ocurrirán antes o después de la prueba puede traer estos factores. Por esta
razón, los testers, en especialmente los líderes o gerentes de prueba, estén en sintonía
con el contexto general en el que operan. Algunos de estos factores resultan ser riesgos
específicos para las pruebas del proyecto, y deben abordarse en el plan de pruebas.
Los riesgos del proyecto se analizan con más detalle en la Sección 5.5.
5.2.6 Prueba de enfoques o estrategias

La elección de los métodos de prueba o estrategias son un poderoso factor en el éxito
del esfuerzo de la prueba y la precisión de los planes de pruebas y estimaciones. Este
factor está bajo el control de los testers y líderes de prueba. Por supuesto, también tiene
opciones significa que se pueden cometer errores, por lo que vamos a hablar de cómo escoger
la estrategia de prueba correcta en un minuto. En primer lugar, sin embargo, veamos los
principales tipos de estrategias de prueba que se encuentran comúnmente.
• Analítica: Por ejemplo, la estrategia basada en el riesgo implica la realización de un

análisis de riesgo utilizando documentos del proyectos y aportes de las mismas, a
continuación, la planificación, la estimación, el diseño, y dar prioridad a las pruebas
basadas en el riesgo. (Hablaremos más sobre el análisis de riesgo más adelante en este
capítulo). Otra estrategia es la prueba analítica La estrategia basada en los requisitos,
donde un análisis de la especificación de requisitos constituye la base para la
planificación, el diseño y la estimación de las pruebas.
estrategias de pruebas analíticas tienen en común el uso de algunas técnicas formales o
informales, por lo general durante las fases de diseño y requisitos del proyecto.
• Basado en Modelos: Por ejemplo, se puede construir modelos matemáticos para la

carga y la respuesta de los servidores de comercio electrónico, y la prueba basada en ese
modelo. Si el comportamiento del sistema bajo prueba se ajusta a la predicha por el
modelo, el sistema se considera que está funcionando. estrategias de prueba basados en
modelos tienen en común la creación o selección de un cierto modelo formal o informal para
el sistema de comportamientos crítico, por lo general durante las fases de diseño y requisitos
del proyecto.
• Metódica: Por ejemplo, usted podría tener una lista de comprobación que usted ha
puesto A punto durante los años que sugieren las principales áreas de las pruebas que
se ejecuten o se podría seguir un estándar de la industria para la calidad del software,
tales como ISO 9126, para su esquema de las principales áreas de prueba. A continuación,
metódicamente diseñar, implementar y ejecutar las pruebas siguiendo este
esquema. estrategias de pruebas metódicas tienen en común la adhesión a un enfoque
planificado previamente, sistematizado que se
ha desarrollado internamente, montado a partir de varios conceptos desarrollados in-casa y
recogido desde el exterior, o adaptado significativamente de las ideas del exterior y puede
tener un punto de participación para la prueba temprana o tardía.
• Proceso compatible con estándar: Por ejemplo, es posible adoptar el IEEE 829
estándar para su prueba, el uso de libros tales como [Craig, 2002] o [Drabick, 2004] para
llenar los vacíos metodológicos. Alternativamente, es posible adoptar una de las
metodologías ágiles como la programación extrema. Procesamiento compatible con el
estándar, las estrategias compatibles tienen en común la dependencia sobre un enfoque de las
pruebas desarrollados externamente, a menudo con poca o ninguna personalización y puede
tener un punto de participación para la prueba temprana o tardía.
• Dinámico: Por ejemplo, puede crear un conjunto de pruebas con una línea guía que se
centrara en la adaptación rápida o debilidades conocidas en el software. Estrategias
dinámicas, tales como pruebas exploratorias, tienen en común que se concentran en la
búsqueda de la mayor cantidad posible de defectos durante la ejecución de la prueba y
adaptarlas a la realidad del sistema bajo prueba, ya que es cuando se entrega, y típicamente
enfatizar las últimas etapas de la prueba. Véase, por ejemplo, el enfoque basado en ataques
en el de [Whittaker, 2002] y [Whittaker, 2003] y la aproximación exploratoria de [Kaner et
al., 2002].
• Consultivo o Dirigida: Por ejemplo, es posible pedir a los usuarios o desarrolladores del
sistema que le diga lo que debe probar o incluso confiar en ellos para hacer las pruebas. las
estrategias de consulta o dirigidos tienen en común la dependencia de un grupo de no-testers
para guiar o llevar a cabo el esfuerzo de prueba y por lo general hacer hincapié en las últimas
etapas de la prueba simplemente debido a la falta de reconocimiento del valor de las primeras
pruebas.
• Regresión con Aversión: Por ejemplo, usted puede tratar de automatizar todas las pruebas
de la funcionalidad del sistema de modo que, cada vez que cambie algo, puede volver a
ejecutar todas las pruebas para asegurar que nada se ha roto. en técnicas de regresión
con aversión tienen un conjunto común de procedimientos generalmente automatizado
que les permiten detectar defectos de regresión. Una estrategia de regresión de aversión
puede implicar la automatización de pruebas funcionales antes de la liberación de la función,
en cuyo caso se requieren pruebas tempranas, pero a veces la prueba se centra casi
exclusivamente en las pruebas de las funciones que ya han sido liberadas, que es en cierto
sentido una forma de liberación posterior a la participación de la prueba.
Algunas de estas estrategias son más preventivas, otras más reactivas. Por ejemplo, las
estrategias de prueba analítica implican el análisis inicial de la base de pruebas, y
tienden a identificar los problemas en la base de pruebas antes de la ejecución de la
prueba. Esto permite la eliminación de los defectos temprano y barato. Esa es una
fortaleza de los enfoques preventivos.
las estrategias de las pruebas dinámicas que se centran en el período de ejecución de la

prueba. tales estrategias permitir la localización de defectos y clusters de defectos que
podrían haber sido difícil anticipar hasta que tenga el sistema real en frente de usted. Esa es
una fuerza de enfoques reactivos.
En lugar de ver la estrategia de elección, especialmente las estrategias preventivas o reactivas,

ya sea como una / o situación, vamos a dejar entrar en el secreto peor guardado de la prueba
(y muchas otras disciplinas): No hay una mejor manera. Te sugerimos que adopte cualquier
enfoque de prueba, tienen más sentido en una situación particular, y no dude en pedir prestado
y mezclar.
¿Cómo sabes qué estrategias utilizar para recoger o mezclar y obtener las mejores
posibilidades de éxito? Hay muchos factores a considerar, pero destaquemos algunas
de las lo más importante:
• Riesgos: La prueba es sobre la gestión de riesgos, por lo que debe tener en cuenta los
riesgos y el nivel de riesgo. Para una aplicación bien establecida que está evolucionando
lentamente, la regresión es un riesgo importante, por lo que las estrategias de regresión con
aversión tienen sentido. Para una nueva aplicación, un análisis de riesgos puede revelar
diferentes riesgos si tienes que elegir una basada en el riesgo de estrategia analítica.
• Habilidades: Las estrategias no sólo deben ser elegidos, sino que también deben ser
ejecutadas. Así que, usted tiene que considerar qué habilidades poseen sus testers y la
falta. Una estrategia estándar compatible es una opción inteligente cuando falta el
tiempo y habilidades en su equipo para crear su propio enfoque.
• Objetivos: Las pruebas deben satisfacer las necesidades de los interesados para tener
éxito. Si el objetivo es encontrar el mayor número posible de defectos con una cantidad
mínima de tiempo y esfuerzo invertido. Por ejemplo, en una típica prueba independiente, una
estrategia dinámica tiene sentido.
• Regulaciones: A veces hay que satisfacer no sólo las partes interesadas, sino también
los reguladores. En este caso, puede ser necesario diseñar una estrategia metódica de
pruebas que satisface estos reguladores que se han cumplido todos los requisitos.
• Producto: Algunos productos tales como sistemas de armas y contrato de desarrollo

software tienden a tener requisitos bien especificados. Esto conduce a la sinergia con
unos requisitos basados en la estrategia analítica.
• Negocios: consideraciones comerciales y la continuidad del negocio son a menudo

importantes. Si usted puede utilizar un sistema heredado como un modelo para un
nuevo sistema, puede utilizar una estrategia basada en el modelo.
Ya hemos mencionado que un buen equipo a veces puede triunfar sobre una situación
donde los materiales, factores del proceso y retraso iban en contra de su éxito. Sin
embargo, la ejecución con un muy buen equipo talentoso, de una estrategia imprudente
es el equivalente de ir muy rápido por una carretera en la dirección equivocada. Por lo
tanto, debe tomar decisiones inteligentes en términos de estrategias de prueba. Por otra
parte, debe elegir las estrategias de prueba con un ojo hacia los factores mencionados
anteriormente, el cronograma, presupuesto, limitaciones del proyecto y las realidades
de la organización y su política.
5.3 PROGRESO, SUPERVISION Y CONTROL DE LA PRUEBA

1 Recordemos métricas comunes que se utilizan para la preparación de la prueba de
monitoreo y ejecución. (KL)
2 Conocer e interpretar las métricas de prueba para la presentación de informes de
prueba y control de prueba (Por ejemplo, los defectos encontrados y se fijaron, pruebas
que pasaron y la que no).
(K2)
3 Resumir el propósito y el contenido del resumen de la prueba documento de informe
de acuerdo con [IEEE 829]. (K2)
En esta sección, vamos a revisar las técnicas y las métricas que se utilizan comúnmente
para el seguimiento de la preparación y ejecución de pruebas. Nos centraremos
especialmente en el uso y la interpretación de dichas métricas de prueba para la
presentación de informes, el control y análisis del esfuerzo de la prueba, incluyendo las
basadas en defectos y los basados en los datos de prueba.
También vamos a ver opciones para informar sobre el estado de prueba utilizando dichas
métricas y otra información.
A medida que lea, recuerde que debe velar por el glosario de términos densidad de defectos,
insuficiencia tasa, control de prueba, cobertura de la prueba, monitorización de las
pruebas y el informe de prueba.
5.3.1 Seguimiento de la evolución de las actividades de prueba
Después de haber desarrollado nuestros planes, se definen nuestras estrategias y

enfoques de prueba y estimamos el trabajo a realizar, ahora tenemos que seguir nuestro
trabajo de pruebas que realizamos hacia fuera. Supervisión de Prueba puede servir a
varios propósitos durante el proyecto, incluyendo el seguimiento:
• Dar al equipo de pruebas la retroalimentación de las pruebas, de cómo va el trabajo de

pruebas, las oportunidades que permite, para orientar y mejorar las pruebas y el proyecto.
• Proporcionar al equipo de proyecto la visibilidad de los resultados de las pruebas.
• Medir el estado de los elementos de prueba, la cobertura de prueba y comparar los
elementos de la prueba frente a los criterios de salida para determinar si el trabajo de
la prueba se realiza correctamente.
• Recopilar datos para su uso en la estimación de los esfuerzos de las pruebas futuras.
Especialmente para proyectos pequeños, el líder de prueba o una persona delegada pueden
reunir pruebas para llevar un seguimiento del progreso y control de la prueba con información
de forma manual utilizando documentos, hojas de cálculo y bases de datos simples. Cuando
se trabaja con grandes equipos, proyectos y distribuido los esfuerzos de prueba a largo
plazo, nos encontramos con que la eficacia y la coherencia de los datos colectivos es
ayudada por el uso de herramientas automatizadas (véase el Capítulo 6).
Una manera de reunir información del progreso de la prueba es utilizar el registro de

la prueba IEEE 829 modelo. Si bien gran parte de la información relacionada con los
eventos de registro puede ser capturados en un documento, preferimos para capturar la
información de la prueba por prueba en hojas de cálculo (véase la Figura 5.1).
LOG plantilla de prueba IEEE 829 STANDARD
Identificador de registro de la prueba Entradas de actividad y de eventos

(]Ejecución, descripción, resultados del
procedimiento, información del ambiente,
eventos anómalos, Identificadores de
informe de incidente)
Descripción (piezas que se prueben,
ambiente en el que la prueba es
llevado a cabo)
En la Figura 5.1, las columnas A y B muestran el ID de prueba y el caso de prueba o conjunto

de pruebas nombre. El estado del caso de prueba se muestra en la columna C ( 'Warn' indica
una prueba que dio lugar a una falla menor). Columna D muestra la configuración de
prueba, donde los códigos de A, B y C corresponden a probar entornos descrito en detalle
en el plan de pruebas. Las columnas E y F muestran el número de identificación de defectos
(o error) (de la base de datos de seguimiento de defecto) y el número de prioridad de riesgo
del defecto (Desde el 1, el peor de los casos, al 25, al menos riesgoso). Columna G muestra
las iniciales del tester que corrió la prueba. Columnas H y L los datos de captura para cada
prueba relacionada con fechas, el esfuerzo y la duración (en horas). Tenemos planeado para
las métricas y el esfuerzo real y fechas completado la cual nos permitiría resumir el progreso
en relación con el calendario y el presupuesto previsto. Esta hoja de cálculo también puede
ser un resumen en términos del porcentaje de pruebas que han sido corridas y el
porcentaje de pruebas que han pasado y han fallado.
Figura 5.1 podría mostrar una instantánea del progreso de la prueba durante la ejecución de
la prueba por periodo, o tal vez incluso al cierre de la prueba si se considera aceptable para
saltar algunas de las pruebas. Durante el análisis, diseño e implementación de las pruebas,
una hoja de cálculo así mostraría el estado de las pruebas en función de su estado de
desarrollo.
Además del estado de casos de prueba, también es común para monitorear el progreso
de prueba durante el período de ejecución de la prueba observando el número de
defectos encontrados y fijo. Figura 5.2 muestra un gráfico que traza el número total de
defectos abierto y cerrado en el transcurso de la ejecución de la prueba hasta el
momento.
También muestra el período de prueba de la fecha de finalización prevista y el número
previsto de defectos que se encontrarán. Idealmente, como el proyecto se acerca al final
planeado fecha, el número total de defectos abiertos se instalará en el número previsto
y el número total de defectos corregidos convergerá con el número total abrió. Estos dos
resultados nos dicen que hemos encontrado bastantes defectos para sentir cómoda que hemos
terminado la prueba, que no tenemos ninguna razón para pensar que muchos más defectos
están al acecho en el producto, y que todos los defectos conocidos han sido resuelto.
Gráficas tales como la Figura 5.2 también se pueden utilizar para mostrar las tasas de
fracaso o defecto densidad. Cuando la fiabilidad es una preocupación fundamental,
podríamos estar más preocupados por la frecuencia con la que se observan fallas que
con el número de defectos que están provocando los fracasos. En las organizaciones que
están buscando producir ultra-fiabilidad de software, se puede trazar el número de defectos
sin resolver normalizados por el tamaño del producto, ya sea en miles de líneas de código
fuente (KSLOC), en función puntos (FP) o alguna otra métrica de tamaño del
código. Una vez que el número de defectos resueltos cae por debajo de un umbral
predefinido, por ejemplo, tres por millones de líneas de código a continuación, el
producto puede considerarse que cumplen con los criterios de salida densidad de
defecto.
Medir el progreso de prueba basado en los defectos encontrados y fijo es común y útil
si se usa con cuidado.
La métrica del avance de las pruebas a partir de los defectos detectados es frecuente y
útil. Se debe evitar la utilización únicamente de esa métrica ya que es posible una
manipulación deliberadamente incorrecta por parte de otros actores intervinientes en el
ciclo de vida de los defectos.
Dicho esto, el progreso de técnicas de pruebas de monitoreo varían considerablemente

de las preferencias de los testers y las partes interesadas, las necesidades y objetivos del
proyecto, los requisitos reglamentarios, las limitaciones de tiempo y de dinero y otros
factores.
Además de los tipos de información que se muestran en el registro de la prueba IEEE 829
Plantilla, figuras 5.1 y Figura 5.2, otros sistemas de medición comunes para el progreso
de prueba monitoreo incluye:
• El grado de terminación de la preparación entorno de prueba;

• La extensión de la cobertura de la prueba consiguió, comparada con los requisitos, riesgos,
código, configuraciones u otras áreas de interés;
• El estado de la prueba (incluyendo el análisis, diseño e implementación) en comparación
con diversos hitos de prueba;
• La economía de la prueba, tales como los costes y beneficios de la prueba continua
ejecución en términos de encontrar el siguiente defecto o ejecutar la siguiente prueba.
Como técnica de monitorización complementaria, es posible evaluar el nivel subjetivo de

confianza que los testers tienen con los elementos de la prueba. Sin embargo, evite tomar
decisiones importantes basadas en evaluaciones subjetivas solo, con la impresión de la gente
ya que tienen una forma de ser inexacta y coloreado por el sesgo.
5.3.2 Informes de estado de la prueba

monitoreo de progreso de la prueba se trata de la recopilación de los datos de prueba
detallado; prueba de estado de la presentación de informes, se trata de comunicar con
eficacia nuestros hallazgos a otros titulares del proyecto interesados. Al igual que con el
control del progreso de prueba, en la práctica existe una gran variabilidad en como las
personas informan el estado de pruebas, con las variaciones impulsadas por las preferencias
de los testers y las partes interesadas, las necesidades y objetivos del proyecto, requisitos
reglamentarios, limitaciones de tiempo y dinero y las limitaciones de las herramientas
disponible para la presentación de informes. A menudo, las variaciones o resúmenes de las
métricas utilizada para el control del progreso de prueba, tal como muestra la Figura 5.1 y
Figura 5.2, se utilizan para informes de estado de prueba, también. Independientemente
de las métricas específicas, gráficas e informes utilizado, informes de estado de prueba
ayudan a los participantes del proyecto a comprender los resultados de un período de
prueba, especialmente en lo que se refiere a los objetivos fundamentales del proyecto y
si (o cuando) los criterios de salida estaban satisfechos.
Además de notificar a los interesados del proyecto sobre los resultados de la prueba, la
presentación de informes de estado de la prueba es a menudo sobre esclarecedor e influir en
ellos. Se trata de analizar la información y las métricas disponibles para apoyar las
conclusiones, condiciones, y las decisiones sobre cómo orientar el proyecto hacia adelante o
tomar otro comportamiento. Por ejemplo, podríamos estimar el número de defectos que
quedan por descubrir, presentar los costos y beneficios de retrasar la fecha de lanzamiento
para permitir más pruebas, evaluar los riesgos de los productos y de los proyectos restantes
y ofrecer un dictamen sobre la confianza de las partes interesadas en la calidad del sistema
bajo prueba.
Usted debe pensar en los informes de estado de prueba durante la planificación de las pruebas
y períodos de preparación, ya que a menudo se necesitan para recopilar métricas específicas
durante y al final de un período de prueba para generar los informes de estado de prueba de
una manera efectiva y eficiente. Los datos específicos que querrá reunir dependerá de sus
informes específicos, pero las consideraciones comunes incluyen los siguientes:
• ¿Cómo va a evaluar la adecuación de los objetivos de la prueba para un nivel de prueba

dado y si se lograron los objetivos?
• ¿Cómo va a evaluar la adecuación del enfoque de prueba adoptado y si se apoya el logro de
los objetivos de prueba del proyecto?
• ¿Cómo va a evaluar la eficacia de la prueba con respecto a estos objetivos y enfoques?
Por ejemplo, si usted está haciendo la prueba basada en el riesgo, un objetivo principal de la
prueba es someter los riesgos importantes de los productos, en la medida adecuada de la
prueba. Mesa 5.1 muestra un ejemplo de un gráfico que permitiría informar de la cobertura
de la prueba y los defectos no resueltos contra las principales áreas de riesgo producto que
identificó en el análisis de riesgos. Si usted está haciendo las pruebas basadas en
requisitos, usted podría medir la cobertura en términos de requisitos o áreas
funcionales en lugar de riesgos.
En algunos proyectos, el equipo de pruebas debe crear un informe de resumen de la

prueba. Tal informe, creada ya sea en un hito clave o al final de un nivel de prueba, describe
los resultados de un determinado nivel o fase de la prueba. La prueba estándar IEEE 829
Resumen plantilla de informe proporciona una guía útil para lo que sucede en tales un
informe. Además de incluir el tipo de gráficos y tablas que se muestran anteriormente, es
posible discutir los eventos importantes (especialmente problemáticas) que se produjeron
Durante las pruebas, los objetivos de la prueba y si lo fueron, la prueba estrategia utilizada y
lo bien que funcionó, y la eficacia global del esfuerzo de la prueba.
PRUEBA DE INFORME RESUMEN PLANTILLA: IEEE 829 STANDARD
Prueba identificador informe resumido Evaluación

Resumen Resumen de las actividades
varianzas aprobaciones
evaluación integral Resumen de Resultados
5.3.3 Prueba de control

Los proyectos no siempre se desarrollan según lo previsto. De hecho, toda obra humana
más complicado que un día de campo familiar es probable que varíe de plan. Los riesgos se
vuelven ocurrencias. necesidades de los interesados evolucionan. El mundo que nos
rodea cambia. Cuando planes y la realidad divergen, debemos actuar para llevar el
proyecto de nuevo bajo control.
En algunos casos, los resultados de prueba en sí son detrás de la divergencia; para ejemplo,
supongamos que la calidad de los elementos de las pruebas resulta inaceptablemente mala y
retrasa el Progreso de la prueba. En otros casos, la prueba se ve afectada por eventos de
afuera; para ejemplo, las pruebas pueden ser retrasada cuando los elementos de prueba llegan
tarde o la prueba medio ambiente no está disponible. Control de prueba se trata de orientar
las acciones correctivas para tratar de lograr el mejor resultado posible para el proyecto.
Las acciones correctivas específicas dependen, por supuesto, de lo que estamos tratando de
controlar. Considere los siguientes ejemplos hipotéticos:
• Una parte del software bajo prueba será entregado tarde, después de la prueba prevista
fecha de inicio. Las condiciones del mercado dictan que no podemos cambiar la fecha de
liberación. Prueba de control podría implicar modificar las prioridades de las pruebas por lo
que comencemos las pruebas en contra de lo que está disponible ahora.
• Por razones de coste, pruebas de rendimiento se ejecuta normalmente en las noches de la
semana fuera del horario de la producción de ambiente. Debido a la alta demanda imprevista
de sus productos, la compañía ha adoptado temporalmente un turno de tarde que mantiene el
entorno de producción en uso 18 horas al día, cinco días a la semana. Prueba de control podría
implicar la reprogramación pruebas de rendimiento para el fin de semana.
Aunque estos ejemplos muestran las acciones de control que afectan las pruebas, el
equipo del proyecto también podría tener que tomar otras acciones que afectan a los
demás en el proyecto. Por ejemplo, supongamos que la fecha de terminación de la
prueba está en riesgo debido a un elevado número de reparaciones de defectos que
hacen fallar la prueba de confirmación en el entorno de prueba. En este caso, el control
de prueba podría implicar que los programadores requieren hacer las correcciones
para volver a probar a fondo las correcciones antes de registrarse en el código
repositorio para su inclusión en una compilación de prueba.
5.4 GESTIÓN DE LA CONFIGURACIÓN

1 resumen cómo soportes de gestión de configuración pruebas. (K2)
En esta breve sección, vamos a ver cómo la gestión de configuración se refiere a las pruebas
y apoya. Usted se encontrará con el glosario términos de gestión de configuración y control
de versiones.
Gestión de la configuración es un tema que a menudo confunde a los nuevos practicantes,
pero, si alguna vez tiene la mala suerte de trabajar como tester en un proyecto donde se
manipula esta actividad crítica mal, Nunca se le olvide lo importante que es. En pocas
palabras, la gestión de la configuración es, en parte, sobre determinar claramente los
elementos que componen el software o sistema. Estos elementos incluyen código fuente,
scripts de prueba, el software de terceros, hardware, datos, desarrollo y documentación
de prueba. gestión de la configuración también trata de asegurar que estos elementos se
utilizan cuidadosamente, a fondo y con atención a lo largo de todo el proyecto y ciclo de
vida del producto.
Gestión de la configuración tiene una serie de importantes implicaciones para la prueba. Por
un lado, permite a los testers gestionar sus testware y resultados de pruebas utilizando la
misma configuración de mecanismos de gestión, como si fueran tan valioso como el código
fuente y la documentación para el sistema en sí.
Por otro lado, la gestión de la configuración apoya la construcción del proceso, que es
esencial para la entrega de una liberación de prueba en el entorno de prueba. El simple envío
de archivos Zip por correo electrónico no será suficiente, porque hay demasiadas
oportunidades para este tipo de archivos a contaminarse con contenidos no deseados o para
albergar sobrante Las versiones anteriores de elementos. Sobre todo, en las últimas fases de
la prueba, es fundamental contar con una manera sólida y fiable de entrega de elementos de
prueba que funcionan y son la versión correcta.
Por último, pero no menos importante, la administración de configuración nos permite

mapear lo que se está probando a los archivos y componentes subyacentes que lo
componen. Esto es absolutamente crítico. Por ejemplo, cuando nos informa defectos,
tenemos que informar sobre ellos contra algo, lo que la versión controló. Si no está claro lo
que encontramos en el defecto, los programadores tendrán un tiempo muy difícil de encontrar
el defecto para fijarlo. Para el tipo de informes de prueba se discutió anteriormente para tener
cualquier sentido, hay que ser capaz de rastrear los resultados de la prueba de nuevo a lo que
probamos exactamente.
Idealmente, cuando se los somete a una prueba organizada, bajo control de versiones de
liberación de un repositorio de código fuente gestionados cambio, es acompañado por un
elemento de transmisión de prueba, informes o notas.
[IEEE 829] proporciona una guía útil para lo que sucede en tal informe. Notas de la
versión no son siempre tan formal y no siempre contienen toda la información que se muestra.
Mientras que nuestra descripción fue breve, gestión de la configuración es un tema que es
tan compleja como la gestión de medio ambiente. Así que, planificación avanzada es
fundamental para hacer este trabajo. Durante la planificación del proyecto y tal vez como
parte de su propio plan de pruebas hay que asegurarse de los procedimientos y herramientas
de administración de configuraciones seleccionado. A medida que avanza el proyecto, el
proceso de configuración debe implementar mecanismos e interfaces claves en el
resto del proceso de desarrollo, esto debe ser documentado. Prueba en tiempo de ejecución,
esto permitirá que usted y el resto del equipo del proyecto tengan sorpresas desagradables,
como las pruebas del software equivocado, construyendo instalable inadecuados y
comunicando defectos irreproducibles contra versiones de código que no existen más que en
la prueba ambiente.
LA PLANTILLA IEEE 829 STANDARD: TEST DE ELEMENTOS DE INFORME

DE TRANSMISIÓN
identificador de informe de transmisión elementos de transmisión
Ubicación
Estado
Aprobaciones
5.5 RIESGO Y PRUEBA

1 Describe un riesgo como un posible problema que amenazaría el logro de los objetivos
del proyecto una o más de las partes interesadas. (K2)
2 Recuerde que los riesgos son determinados por la probabilidad (de pasando) e
impacto (daño resultante si sucede). (KL)
3 Distinguir entre los riesgos del proyecto y del producto. (K2)
4 Reconocer riesgos típicos en productos y proyectos. (KL)
5 Describir, mediante ejemplos, cómo el análisis del riesgo y la administración del riesgo
pueden ser utilizados para la planificación de pruebas. (K2)
Esta sección trata sobre un tema que creemos que es fundamental para las pruebas: el
riesgo. Miremos de cerca los riesgos, los posibles problemas que podrían poner en peligro
los objetivos de los interesados en el proyecto. Vamos a discutir la forma de determinar el
nivel de riesgo utilizando la probabilidad y el impacto. Veremos que existen riesgos
relacionados con el producto y los riesgos relacionada con el proyecto, y mirar a los
riesgos típicos en ambas categorías. Finalmente, y más importante vamos a ver varias
maneras de como el análisis de riesgos y gestión de riesgos puede ayudar a trazar un curso
para la prueba sólida a medida que lea esta sección, asegúrese de asistir con atención los
términos del glosario riesgo del producto, el riesgo del proyecto, los riesgos y las pruebas
basadas en el riesgo.
5.5.1 Riesgos y niveles de riesgo

Riesgo Es una palabra que todos usamos vagamente, pero ¿qué es el riesgo? En pocas
palabras, es la posibilidad de un resultado negativo o indeseable. En el futuro, un riesgo
tiene alguna probabilidad entre 0% y 100%; es una posibilidad, no una certeza. En el
pasado, Sin embargo, ya sea que el riesgo se ha materializado y convertido en un resultado,
problema o no lo ha hecho; la probabilidad de un riesgo en el pasado es o bien 0% o 100%.
La probabilidad de un riesgo de convertirse en un resultado es uno de los factores a

considerar cuando se piensa en el nivel de riesgo asociado a la posible consecuencia
negativa. Lo más probable es que el resultado es, peor es el riesgo. Sin embargo, la
probabilidad no es la única consideración.
Por ejemplo, la mayoría de la gente tiende a atrapar un resfriado en el curso de su vive, por
lo general más de una vez. El individuo típico sano no sufre graves consecuencias. Por lo
tanto, el nivel general de riesgo asociado con los resfriados es baja para esta persona. Pero el
riesgo de un resfriado para una persona mayor con dificultades para respirar sería muy
alto. Las consecuencias potenciales o impacto son una consideración importante que afecta
el nivel de riesgo, también.
Recordemos que en el capítulo 1 hemos discutido cómo en el contexto del sistema, y

especialmente el riesgo asociado a las fallas, las pruebas de influencias. A continuación,
vamos a entrar en más detalles sobre el concepto de riesgos, cómo influyen en las pruebas, y
específicas maneras de gestionar el riesgo.
Podemos clasificar los riesgos en los riesgos del proyecto (factores relacionados con la
forma en que el trabajo es llevado a cabo, es decir, el proyecto de prueba) y riesgos de los
productos (factores relativos a lo que es producido por el trabajo, es decir, lo que estamos
probando). Vamos a ver el producto corre el riesgo de primera.
5.5.2 Riesgos del Producto

Se puede pensar en un riesgo del producto como la posibilidad de que el sistema o
software podría dejar de satisfacer algunas necesidades del cliente, usuario o grupos de
interés. (Algunos autores se refieren a los "riesgos de los productos 'como' riesgos de
calidad ', ya que son los riesgos para la calidad del producto.) Software insatisfactorio
podría omitir algunas funciones claves que los clientes especifican, los usuarios
requieren o los grupos de interés les habían prometido. software insatisfactorio podría
ser poco fiable y con frecuencia no comportarse normalmente. Software insatisfactorio
puede fallar en formas que causan daños financieros u otros daños a un usuario o de la
compañía donde el usuario trabaja. software insatisfactorio podría tener problemas
relacionados con una característica de calidad especial, que podría no ser la
funcionalidad, sino más bien la seguridad, fiabilidad, facilidad de uso, mantenimiento
o el rendimiento.
Las pruebas basadas en riesgo es la idea de que podemos organizar nuestros esfuerzos de
pruebas en una manera que reduce el nivel de riesgo del producto del sistema. Pruebas
basadas en riesgo se realizan para priorizar y hacer hincapié en las pruebas adecuadas
durante la ejecución de la prueba, pero es algo más que eso. Las pruebas basadas en el
riesgo comienzan temprano en el proyecto, la identificación de riesgos para la calidad
del sistema y el uso del conocimiento de los riesgos para orientar la planificación de
pruebas, especificación, preparación y ejecución. Las pruebas basadas en el riesgo
consisten en la mitigación de proporcionar oportunidades para reducir la probabilidad de
defectos, especialmente los defectos de alto impacto y la contingencia, pruebas para
identificar soluciones alternativas para que los defectos que quedan más allá de nuestro
alcance sean menos dolorosos.
Las pruebas basadas en riesgo también implican la medición de lo bien que estamos
haciendo la búsqueda y la eliminación de defectos en las zonas críticas, como se muestra
en la Tabla 5.1. La prueba basada en el riesgo También puede implicar el uso de análisis de
riesgos para identificar oportunidades proactivas para eliminar o prevenir los defectos a
través de actividades no son para ayudarnos a seleccionar qué prueba de actividades vamos
realizar.
Organizaciones de pruebas maduras utilizan pruebas para reducir el riesgo asociado

con la entrega del software a un nivel aceptable [Beizer, 1990], [Hetzel, 1988]. A
mediados de la década del 1990, una serie de testers, incluidos nosotros, comenzamos a
explorar diferentes técnicas para la prueba basada en el riesgo. Al hacerlo, se adaptó bien el
concepto de riesgo de gestión a las pruebas de software. La aplicación y evaluación de riesgo
en las técnicas de gestión se discuten en [Negro, 2001] y [Negro, 2004]. Por dos puntos de
vista alternativos, véase el capítulo 11 de la [Pol et al., 2002] y en el Capítulo 2 de [Craig,
2002]. El origen del concepto de prueba basado en el riesgo se puede encontrar en Capítulo
1 de [Beizer, 1990] y en el Capítulo 2 de [Hetzel, 1988].
Las pruebas basadas en el riesgo comienzan con el análisis de riesgos del producto. Una
de las técnicas para el análisis del riesgo es una lectura atenta de la especificación de
requisitos, especificaciones de diseño, documentación del usuario y otros artículos. Otra
técnica es una lluvia de ideas con muchos de los interesados en el proyecto. Otra es una
secuencia de sesiones de uno-a-uno o con grupos pequeños de expertos en negocios y
tecnología en la empresa.
Algunas personas utilizan todas estas técnicas cuando pueden. Para nosotros, un equipo
basado en enfoque que involucra a los actores clave y expertos es preferible a un enfoque
puramente basado en documento de base, como el enfoque de equipo se basan en el
conocimiento, la sabiduría y la visión de todo el equipo para determinar qué vamos a probar
y cuánto.
Mientras que usted podría realizar el análisis de riesgos con la pregunta "¿Qué tenemos que
preocuparnos ¿acerca de?' por lo general se requiere una mayor estructura de evitar las cosas
que faltan. Una manera de disponer que la estructura es la búsqueda de riesgos específicos
en determinadas categorías de riesgo particulares del producto. Se podría considerar los
riesgos en las áreas de funcionalidad, localización, facilidad de uso, fiabilidad,
rendimiento y compatibilidad. Alternativamente, puede hacer utilizar las características de
calidad y sub-características de la norma ISO 9126 (introducido en el capítulo 1), ya que
cada sub-característica que importa está sujeta a riesgos que el sistema podría tener
problemas en esa área. Es posible que tenga una lista de riesgos típicos o pasados que deben
ser considerados. También puede ser que desee revisar las pruebas que fallaron y los errores
que haya encontrado en una revisión anterior de un producto similar. Estas listas y reflexiones
sirven para refrescar la memoria, lo que obligó a pensar acerca de los riesgos de tipos
particulares, así como ayudar a estructurar la documentación de los riesgos de los productos.
Cuando hablamos de riesgos específicos, nos referimos a un tipo particular de defecto

o falla que pudiera ocurrir. Por ejemplo, si estuviera probando la utilidad de la calculadora
que se incluye con Microsoft Windows, es posible identificar 'cálculo incorrecto 'como un
riesgo específico dentro de la categoría de funcionalidad. Sin embargo, esto es demasiado
ancho. Considere además incorrecta. Se trata de una especie de alto impacto de defecto, como
todos los que usan la calculadora lo verá. Es poco probable, ya que la adición no es un
algoritmo complejo. Esto contrasta con un cálculo incorrecto de seno. Esto es un tipo de bajo
impacto de defecto, ya que pocas personas utilizan la función seno en la calculadora de
Windows. Es más probable que tenga un defecto, sin embargo, las funciones sinusoidales
son difíciles de calcular.
Después de identificar los elementos de riesgo, usted y, en su caso, las partes interesadas,
debe revisar la lista para asignar la probabilidad de problemas y el impacto de
problemas asociados con cada uno. Hay muchas maneras de hacer esto asignación de
probabilidad e impacto. Usted puede hacer esto con todas las partes interesadas En
seguida. Puede hacer que los hombres de negocios que determinan el impacto y la técnica las
personas a determinar la probabilidad, y luego se funden las determinaciones. De cualquier
manera, la razón para la identificación de riesgos primero y después la evaluación de su nivel,
de riesgos con respecto a la otra.
Las escalas utilizadas para la probabilidad y el impacto varían. Algunas personas utilizan la
escala alta, media y baja. Algunos utilizan una escala de 1-10. El problema con una escala de
1 a 10 es que a menudo es difícil diferenciar una 2 de un 3 o un 7 de un 8, a menos que las
diferencias entre cada calificación están claramente definidas. Una escala de cinco puntos
(muy alto, alto, medio, bajo y muy bajo) tiende a funcionar bien.
Dados dos clasificaciones de niveles de riesgo, probabilidad e impacto, tenemos un
problema, sin embargo: Necesitamos una única calificación de riesgo, agregado para guiar
nuestras pruebas de esfuerzo. Al igual que con las escalas de calificación, las prácticas
varían. Un enfoque consiste en convertir cada clasificación de riesgo en un número y
luego agregar o multiplicar los números de calcular un número de prioridad de
riesgo. Por ejemplo, suponga un riesgo particular tiene una alta probabilidad y un
impacto medio. El número de prioridad de riesgo sería entonces 6 (2 veces 3).
Armado con un número de prioridad de riesgo, ahora podemos decidir sobre los
diferentes riesgos opciones de mitigación disponibles para nosotros. ¿Usamos el
entrenamiento formal para los programadores o analistas, se basan en el entrenamiento
cruzado y críticas o asumen que saben lo suficiente? ¿Hacer llevamos a cabo extensas
pruebas, prueba superficial o ninguna prueba en absoluto? ¿Deberíamos garantizar la
cobertura de las pruebas unitarias y pruebas del sistema de este riesgo? Estas opciones y más
están disponibles para nosotros.
A medida que transcurre este proceso, asegúrese de capturar la información clave en
un documento. No somos aficionados a la documentación excesiva, pero esta cantidad
de información simplemente no se puede manejar en su cabeza. Se recomienda una ligera
tabla como la que se muestra en la Tabla 5.2; por lo general capturar esto en una hoja de
cálculo.
Vamos a terminar esta sección con dos consejos rápidos sobre el análisis de riesgo del
producto. Primero, recuerde tener en cuenta tanto la probabilidad e impacto. Si bien
puede hacer que se sienta como un héroe a encontrar un montón de defectos, las pruebas
también se tratan de la construcción de la confianza en clave funciones. Necesitamos
poner a prueba las cosas que probablemente no se rompen, pero sería catastrófico si lo
hicieron.
En segundo lugar, los análisis de riesgo, especialmente los primeros, son conjeturas
adecuadas. Hacer asegurarse de que siga hacia arriba y vuelve a visitar el análisis de
riesgos en los hitos clave del proyecto.
Por ejemplo, si usted está siguiendo un modelo en V, es posible realizar el primer análisis
durante la fase de requisitos, a continuación, examinar y revisar que al final de las fases de
diseño e implementación, así como antes de iniciar prueba de unidad, prueba de integración,
y la prueba del sistema. También le recomendamos revisar el análisis de riesgo durante
la prueba. Usted puede encontrar que han descubierto nuevos riesgos o encontraron
que algunos riesgos no eran tan arriesgados como se pensaba y el aumento de su
confianza en el análisis de riesgos.
5.5.3 Riesgos del proyecto

Acabamos de discutir el uso de pruebas para gestionar los riesgos para la calidad del
producto.
Sin embargo, la prueba es una actividad igual que el resto del proyecto y por lo tanto
está sujeta a los riesgos que ponen en peligro el proyecto. Para hacer frente a los riesgos
de los proyectos que se aplican a las pruebas, podemos utilizar los mismos conceptos que
aplicamos a identificar, priorizar y la gestión de riesgos de los productos.
Recordando que un riesgo es la posibilidad de un resultado negativo, los riesgos del
proyecto afectan a la prueba, Existen riesgos directos tales como la demora en la entrega
de elementos de prueba al equipo de pruebas o problemas de disponibilidad con el
entorno de prueba. Ahí son también riesgos indirectos, tales como retrasos excesivos en
la reparación de los defectos que se encuentran en prueba o problemas con la obtención
de apoyo para la administración profesional del sistema el entorno de prueba.
Por supuesto, estos no son más que cuatro ejemplos de los riesgos del proyecto; muchos otros
pueden aplicar a su esfuerzo de pruebas. Para descubrir estos riesgos, hágase y hacemos a
otros participantes en el proyecto y las partes interesadas algunas preguntas, ¿lo que podría
ir mal en el proyecto de retrasar o invalidar el plan de pruebas, la estrategia de prueba
y la estimación de prueba? ¿Qué son inaceptables los resultados de las pruebas o en las
pruebas? ¿Cuáles son las probabilidades y el impacto de cada uno de estos riesgos? ' Se puede
ver que este proceso es mucho al igual que el proceso de análisis de riesgos de los
productos. Listas de control y ejemplos pueden ayudarle a identificar los riesgos del proyecto
de prueba [Black, 2004].
Para cualquier riesgo, producto o proyecto, tiene cuatro opciones típicas:
• Mitigar: Tomar medidas con antelación para reducir la probabilidad (y posiblemente el

impacto) del riesgo.
• Contingencia: Tener un plan en marcha para reducir el impacto debería tener el riesgo
convertido en un resultado.
• Transferencia: Convencer a algún otro miembro del equipo de proyecto o de las partes
interesadas para reducir la probabilidad o aceptar el impacto del riesgo.
• Ignorar: No hacer nada acerca del riesgo, que es por lo general sólo una opción inteligente
cuando hay poco que se puede hacer o cuando la probabilidad y el impacto son bajo.
Hay otra opción típica de gestión de riesgos, la compra de seguros, que no suele ser usado
por proyecto o en productos de proyectos de software, aunque no es desconocido.
Aquí hay algunos riesgos típicos, junto con algunas opciones para la gestión de los
mismos.
• Logística o problemas de calidad del producto que bloquean las pruebas: Estos pueden
ser mitigados mediante una planificación cuidadosa, buena clasificación y gestión de
defectos, y diseño de una prueba robusta.
• Los elementos de prueba que no se instalará en el entorno de prueba: Estos pueden ser
mitigados a través del humo (o aceptación) pruebas antes de iniciar las fases de prueba o
como parte de un nightly build (construcción nocturna) o la integración continua. Tener un
proceso definido de desinstalación, es un buen plan de contingencia.
• El cambio excesivo en el producto que invalida los resultados de pruebas o requiere

actualizaciones para poner a prueba los casos, resultados esperados y ambientes: Estos
pueden ser mitigado través de buenos procesos de control de cambios, el diseño de pruebas
robusta y ligera documentación de prueba de peso. Cuando se producen incidentes graves, la
transferencia del riesgo por la progresividad de gestión a menudo está en orden.
• Entornos de pruebas insuficientes o poco realistas que dan resultados engañosos: Una
opción es la transferencia de los riesgos para la gestión, explicando los límites de Los
resultados que fueron obtenidos en entornos limitados. Mitigación, a veces completa el
alivio, se puede lograr por medio de pruebas de externalización tales como el rendimiento
pruebas que son particularmente sensibles a los entornos de prueba apropiados.
Aquí hay algunos riesgos adicionales a tener en cuenta y tal vez para gestionar:
• Cuestiones de organización tales como la escasez de personas, habilidades o entrenamiento,

problemas con la comunicación y responder a probar los resultados, mala expectativa de lo
que puede lograr la prueba y la complejidad del equipo de proyecto u organización.
• Proveer cuestiones tales como problemas con las plataformas de hardware o subyacentes,
las no consideraciones de problemas de pruebas en el contrato o no ajustar correctamente las
respuestas a los problemas que puedan surgir.
• Los problemas técnicos relacionados con la ambigua, contradictoria o sin prioridades de

requisitos, un número excesivamente grande de los requisitos dados, otra las limitaciones del
proyecto, la complejidad y los problemas de alta calidad con el diseño del sistema, el código
o las pruebas.
Puede haber otros riesgos que se aplican a su proyecto y no todos los proyectos son
sujetos a los mismos riesgos. Véase el Capítulo 2 de [Negro, 2001], los capítulos 6 y 7 de
la [Negro, 2004] y en el Capítulo 3 de [Craig, 2002] para una discusión sobre la gestión
los riesgos del proyecto durante la prueba y en el plan de pruebas.
Por último, no se olvide de que los elementos de prueba también pueden tener riesgos
asociados con ellos.
Por ejemplo, hay un riesgo de que el plan de prueba omitirá pruebas para un área
funcional o que los casos de prueba no ejercen las áreas críticas del sistema.
5.5.4 Atar todo junto para la gestión de riesgos

Podemos hacer frente a los riesgos relacionados con las pruebas, al proyecto y el producto
mediante la aplicación de algunas, técnicas de gestión de riesgos estructuradas sencillas. El
primer paso es evaluar o analizar los riesgos al comienzo del proyecto. Al igual que un
gran océano, proyectos, especialcialmente grandes proyectos, requieren el manejo de la
dirección mucho antes que el iceberg este a la vista. Por utilizando un modelo de plan de
prueba como la plantilla IEEE 829 se ha mostrado anteriormente, se puede recordar que
debe considerar y gestionar los riesgos durante la fase de planificación.
Vale la pena repetir aquí que los análisis de riesgo tempranos son conjeturas. Algunas de esas
conjeturas suelen estar equivocadas. Asegúrese de que va a volver a evaluar y ajustar sus
riesgos a intervalos regulares en el proyecto y hacer correcciones apropiadas al curso de la
prueba o el propio proyecto.
Algunas personas tienen problemas comunes cuando las organizaciones adoptan primero
pruebas basadas en riesgos, es una tendencia a ser excesivamente alarmado por algunos de
los riesgos una vez que están articulados con claridad. No se debe confundir con la
probabilidad de impacto o viceversa.
Debe administrar los riesgos de manera apropiada, basada en probabilidad y el

impacto. Triage (Método para clasificar la urgencia de la atención) los riesgos mediante la
comprensión de qué parte de su esfuerzo general se pueden gastar para tratar con ellos.
Es muy importante mantener un sentido de perspectiva, un enfoque en el punto del

ejercicio. Al igual que con la vida, el objetivo de la prueba basado en el riesgo no debe ser
no puede prácticamente ser un proyecto libre de riesgo. Lo que podemos lograr con La
prueba basado en el riesgo es la unión de las pruebas con las mejores prácticas en la
gestión de riesgos a lograr un resultado del proyecto que equilibra los riesgos con la
calidad, características, presupuesto y programar (schedule).
5.6 GESTIÓN DE INCIDENTES

1 Reconocer el contenido del informe [IEEE 829] incidente. (KL)
2 Escribir un informe de incidente que cubre la observación de una falla durante
pruebas. (K3)
Vamos a ver este capítulo sobre gestión de pruebas con un tema importante:
¿Cómo podemos documentar y gestionar las incidencias que se produzcan durante la
ejecución de pruebas? Vamos a ver lo que los temas que debemos cubrir cuando los
incidentes de informes y defectos. Al final de esta sección, usted estará listo para escribir un
informe a fondo de incidente.
Mantenga sus ojos abiertos para el único término del programa de estudios en esta
sección, incidente de registro de datos (incident logging).
5.6.1 ¿Cuáles son los informes de incidentes y cómo puedo escribir bien ¿Cuáles?
Cuando se ejecuta una prueba, es posible observar que los resultados reales son diferentes a
los resultados esperados. Esto no es algo malo uno de los principales objetivos de las
pruebas es encontrar problemas. Diferentes organizaciones tienen diferentes nombres para
describir este tipo de situaciones.
Comúnmente, se llaman incidentes, errores, defectos, problemas o cuestiones.
Para ser precisos, a veces hacer una distinción entre incidentes, en una mano y defectos o
errores en el otra. Un incidente es cualquier situación en la que el sistema exhibe un
comportamiento cuestionable, pero a menudo nos referimos a un incidente como un
defecto únicamente cuando la causa es algún problema en el tema (Item) que estamos
probando.
Otras causas de los incidentes incluyen una mala configuración o el fracaso del
ambiente prueba, datos de prueba corruptos, malas pruebas, resultados esperados no
válidos y errores probados. (Sin embargo, en algunos casos, la política es clasificar como
un defecto de cualquier incidencia que surge a partir de un diseño de la prueba, el entorno de
prueba o cualquier otra cosa, que está bajo la administración de configuración formal.)
Hablamos de incidentes que indiquen la posibilidad de que un comportamiento
cuestionable no es necesariamente un defecto verdadero. Nosotros registrar estos
incidentes para que tengamos un registro de lo que hemos observado y podemos seguir el
incidente y realizar un seguimiento de lo que se hace para corregirlo.
Si bien es más común encontrar el registro de incidentes o notificación de defectos

procesos y herramientas en uso durante las fases de prueba formales, independientes, también
puede registro, informe, seguimiento y gestión de incidencias encontradas durante el
desarrollo y revisiones. De hecho, esta es una buena idea, ya que le da información útil sobre
la medida en que los principios y es más económica las actividades de detección y
eliminación de defectos.
Por supuesto, también necesitamos alguna forma de presentación de informes, el seguimiento

y la gestión de incidentes que se producen en el campo o después de la implementación del
sistema. Mientras que muchos de estos incidentes se producen por fallas humanas o algún
otro comportamiento no relacionada con un defecto, un porcentaje de defectos escapan del
control de calidad y pruebas de actividades. El porcentaje de detección de defectos, lo que
se compara campo de defectos con la prueba de los defectos, es una medida importante de la
eficacia del proceso de prueba.
He aquí un ejemplo de una fórmula DDP que se aplicaría para el cálculo de DDP para el
último nivel de la prueba antes de su liberación en el campo:
Es más común encontrar defectos notificados en contra del código o el sistema sí mismo. Sin
embargo, también hemos visto casos en que se describen los defectos en contra de requisitos
y especificaciones de diseño, guías del usuario y del operador y pruebas.
A menudo, ayuda a la eficacia y eficiencia de la presentación de informes, el seguimiento y

la gestión de defectos cuando la herramienta de seguimiento de defecto proporciona una
capacidad de variar algunas de las informaciones capturadas en función de lo que se informó
en contra del defecto.
En algunos proyectos, se encuentran un gran número de defectos. Incluso en el más

pequeño proyectos en los que se encuentran 100 o menos defectos, se puede perder
fácilmente un seguimiento de ellos a menos que tenga un proceso para la presentación
de informes, clasificación, asignación y gestión de defectos del descubrimiento a la
resolución final.
Un informe de incidente contiene una descripción de la mala conducta que era

observada y la clasificación de la mala conducta. Al igual que con cualquier
comunicación escrita, que ayuda a tener objetivos claros en mente al escribir. Un
objetivo común para tales informes es proporcionar a los programadores,
administradores y otros con detallada información sobre el comportamiento observado
y el defecto. Otra es la de apoyar el análisis de las tendencias de agregar defectos a los datos,
ya sea para comprender más sobre un conjunto particular de problemas o pruebas o para la
comprensión y la presentación de informes en el nivel global de la calidad del sistema. Por
último, informes de defectos, cuando se analizaron a través de un proyecto e incluso a través
de proyectos, dar información que puede conducir al desarrollo y mejoras en los procesos de
prueba.
Al escribir un incidente, que ayuda a tener los lectores en mente, también. Los programadores
necesitan la información de la memoria para encontrar y corregir los defectos antes de que
ocurre, sin embargo, previo a que esto suceda, los líderes deberán analizar y priorizar los
defectos con el fin de asignar eficientemente los recursos disponibles. Debido a que
algunos defectos pueden ser diferidos, tal vez para fijarse más tarde o quizás, en última
instancia, a no ser fijo en todos debemos incluir soluciones temporales y otros datos útiles
para el servicio de asistencia o soporte de equipos técnicos. Por último, los testers a menudo
necesitan saber lo que sus colegas están encontrando, que puedan ver un comportamiento
similar en otro lugar y evitar tratar de ejecutar las pruebas que serán bloqueados.
Un buen informe de incidente es un documento técnico. Además de ser claro para sus
objetivos y la audiencia, cualquier buen informe surge de un enfoque cuidadoso para
investigar y escribir el informe. Tenemos algunas reglas básicas que pueden ayudar a escribir
un buen informe de incidente.
En primer lugar, utilizar un enfoque cuidadoso, atento a la ejecución de las

pruebas. Nunca se sabe cuándo se va a encontrar un problema. Si usted está golpeando el
teclado mientras charla con los compañeros de oficina o soñando con una película que acaba
de ver, es posible que no se dé cuenta de comportamientos extraños. Incluso si usted ve el
incidente, ¿cuánto es lo que realmente sabe sobre él? ¿Qué se puede escribir en un
informe de incidente? síntomas intermitentes o esporádicos son un hecho de la vida para
algunos defectos y es siempre desalentador tener un informe de incidente rebotando como
'irreproducible '. Por lo tanto, es una buena idea tratar de reproducir los síntomas cuando
los vea esta puede ser una buena regla de oro. Si tiene un defecto con síntomas
intermitente, todavía tendríamos que informar que seguirían, pero nos gustaría asegurarnos
de incluir tanta información como sea posible, especialmente el número de veces que
intentamos reproducir y las veces que de hecho ocurrió.
También debe tratar de aislar el defecto mediante cambios cuidadosamente elegidos a los
pasos utilizados para reproducirlo. Al aislar el defecto, usted ayuda a guiar el programador a
la parte problemática del sistema. También aumenta su propio conocimiento de cómo
funciona el sistema y cómo se produce un error.
Algunos casos de prueba se centran en las condiciones de frontera, lo que puede hacer
que parezca que un defecto no es probable que suceda con frecuencia en la
práctica. Hemos encontrado que es una buena idea para buscar condiciones más
generalizadas que causen esa falla de ocurrir, en lugar de simplemente confiar en el caso de
prueba. Esto ayuda a prevenir el duplicado de informe de incidente, 'Ningún usuario real va
a hacer esto otra vez. " También reduce el número de informes duplicados que quedan
archivados.
Como a menudo hay una gran cantidad de pruebas pasando con el sistema durante un período
de prueba, hay un montón de otros resultados de las pruebas disponibles. Comparación de un
problema observado contra otros resultados de la prueba y los defectos conocidos que se
encuentran es una buena manera de encontrar y documentar la información adicional que el
programador es muy probable que encuentre útil. Por ejemplo, es posible comprobar si hay
síntomas similares observados con otros defectos, los mismos síntomas observados con
defectos que se fijaron en las anteriores versiones o resultados similares (o diferentes)
observada en las pruebas que cubren partes similares del sistema.
Muchos lectores de informes de incidentes, especialmente los gerentes, serán necesarios para
comprender y soportar la prioridad y la gravedad del defecto. Por lo tanto, el impacto del
problema en los usuarios, clientes y otras partes interesadas es importante. La mayoría de
seguimiento de defectos de sistemas tienen un campo de título o resumen y ese campo deben
mencionar el impacto, también.
Elección de las palabras, sin duda importa en los informes de incidentes. Usted debería
ser claro y sin ambigüedades. También debe ser neutral, centrado e imparcial, teniendo
en cuenta los problemas interpersonales relacionados con las pruebas discutido en Capítulo
1 y al principio de este capítulo. Por último, mantener el informe conciso ayuda a
mantener la atención de la gente y evita el problema de la pérdida de ellos en detalles.
Como última regla de oro para los informes de incidentes, se recomienda que utilice una
proceso de revisión de todos los informes presentados. Funciona si usted tiene la opinión
tester en la revisión de informes y hemos permitido también que los testers, al menos los
experimentados revisen los informes de otros testers. Los comentarios son técnicas probadas
de garantía de calidad e informes de incidentes son importantes entregables del proyecto.
5.6.2 Lo que va en un informe de incidente?

Un informe de incidente describe una situación, comportamiento o evento que ocurrió
durante las pruebas que requiere más investigación. En muchos casos, un incidente
consta de un informe de una o dos pantallas, llenas de información recogida por un defecto
herramienta de seguimiento y se almacena en una base de datos.
Como se mencionó anteriormente, a menudo se documenta la información narrativa como

un resumen, los pasos para reproducir, las etapas de aislamiento juzgados y el impacto del
problema. Estos campos deben mencionar las entradas dadas y salidas observadas, la
discrepancia o la varianza de las expectativas, las diferentes formas en que podría y no podía
hacer que se repite el problema y el impacto. La información que un tester proporcionaría
incluye la fecha y hora de la falla, la fase del proyecto, el fracaso fue encontrado en el
caso de prueba que produjo el incidente, las referencias a las especificaciones u otros
documentos que proporcionan información sobre el comportamiento correcto, el
nombre del tester (y tal vez el revisor), el entorno de prueba y cualquier información
adicional acerca de la configuración del software, sistema o medio ambiente. A veces
los testers clasifican el ámbito de aplicación, la gravedad y la prioridad del defecto,
aunque a veces los gerentes o un comité de realizan ese papel para el triaje del error.
A medida que el incidente se soluciona, los administradores pueden asignar un nivel de
prioridad al informe. El tablero de control de cambios o error, el comité de triaje podría
documentar los riesgos, costos, oportunidades y beneficios asociados a la fijación o que no
se fija el defecto. El programador, al fijar el defecto, puede capturar la causa raíz, la fase de
introducción y la fase de extracción.
Después de que el defecto haya sido resuelto, administradores, programadores u otras

personas pueden hacer conclusiones y recomendaciones. A lo largo del ciclo de vida del
informe del incidente, desde el descubrimiento de la resolución, el sistema de seguimiento
de defectos debe permitir que cada persona que trabaja en el informe de incidente pueda
entrar en el estado e información de la historia.
IEEE 829 STANDARD: PRUEBA DE PLANTILLA DE INFORME DE

INCIDENTE
Prueba identificador de notificación de incidentes
Resumen
Descripción incidente (entradas, resultados esperados, los resultados reales, anomalías,
fecha y hora, paso del procedimiento, ambiente, los intentos de repetición,
testers y observadores)
Impacto
5.6.3 ¿Qué ocurre con los informes de incidentes después de que les presenta?
Como mencionamos anteriormente, los informes de incidentes se gestionan a través de un
ciclo de vida desde el descubrimiento hasta la resolución. El ciclo de vida de notificación
de incidentes se muestra a menudo como una Diagrama de transición de estado (véase la
Figura 5.3). Mientras que el sistema de seguimiento de defectos puede utilizar un ciclo de
vida diferente, vamos a tomar éste como un ejemplo para ilustrar cómo un ciclo de vida de
notificación de incidentes podría funcionar.
En el ciclo de vida de notificación de incidentes se muestra en la Figura 5.3, todos los

informes de incidentes se mueven a través de una serie de estados claramente identificados
después de haber sido informado. Algunos de estas transiciones de estado se producen
cuando un miembro del equipo del proyecto se completa alguna tarea asignada en relación
con el cierre de un informe de incidente. Algunos de estas transición de estado se producen
cuando el equipo del proyecto decide no reparar un defecto durante este proyecto, que lleva
al aplazamiento del informe del incidente. Algunas de estas transiciones de Estado se
producen cuando un informe de incidente está mal escrito o describe el comportamiento que
en realidad es correcta, lo que lleva al rechazo de ese informe.
Vamos a centrarnos en el camino tomado por los informes de incidentes que finalmente son
corregidos.
Después de que se informó de un incidente, un tester o un gerente de pruebas revisa el
informe.
Si tiene éxito en el examen, el informe del incidente se convierte en abierto, por lo que ahora
el equipo de proyecto debe decidir si o no para reparar el defecto. Si el defecto puede ser
reparado, se le asigna un programador para repararlo.
Una vez que el programador cree que las reparaciones se han completado, el informe de
incidente se devuelve al tester para las pruebas de confirmación. Si la prueba de confirmación
falla, el informe de incidente se vuelve a abrir y volver a asignar. Una vez que el tester
confirma un buen estado, el informe de incidente está cerrado. No queda más trabajo por
hacer.
En cualquier estado que no sea rechazado, diferido o cerrado, es necesario seguir trabajando
sobre el incidente antes del final de este proyecto. En tal estado, el informe de incidente tiene
un propietario identificado claramente. El propietario es responsable de la transición del
incidente en un estado posterior permitido. Las flechas en el diagrama de demostración
muestran las transiciones permitidas.
En un estado rechazado, diferido o cerrado, el informe del incidente no será asignado a un

propietario. Sin embargo, ciertos acontecimientos del mundo real pueden causar un
incidente, informar al cambiar de estado, incluso si no hay trabajo activo está ocurriendo en
el informe del incidente.
Los ejemplos incluyen la recurrencia de una falla asociado con un informe de incidente
cerrado, y el descubrimiento de una falla de más gravedad asociada con un reporte diferido
de incidente.
Lo ideal sería que sólo el propietario puede pasar el informe del incidente de los actuales
estado a otro estado y lo ideal es que el propietario sólo puede hacer la transición del
incidente, informar a un estado próximo permitido. La mayoría de los sistemas de soporte de
seguimiento de defectos hacen cumplir el ciclo de vida y las reglas del ciclo de vida. Los
buenos sistemas de seguimiento de defectos permiten personalizar el conjunto de estados, los
propietarios, y las transiciones permitido coincidir con los flujos de trabajo reales. Y,
mientras que un buen sistema de seguimiento de defectos es útil, el flujo de trabajo defecto
real debe ser supervisado y apoyado por proyectos y gestión de la empresa.
Repaso Capítulo
De la Sección 5.1, ahora debería ser capaz de explicar las ideas básicas de la organización
de las pruebas. Usted debe saber porque las pruebas independientes son importantes,
sino también ser capaz de analizar los beneficios potenciales y los problemas asociados
con los equipos de pruebas independientes. deben reconocer los tipos de personas y
habilidades necesarias en un equipo de prueba y recordar las tareas que un tester y un
líder de la prueba llevaran a cabo.
Usted debe saber el glosario de términos tester, el líder de la prueba y gerente de prueba.
De la Sección 5.2, ahora debería comprender los fundamentos de planificación de las
pruebas y la estimación. debe saber las razones de la elaboración de planes de prueba y
ser capaz de explicar cómo se relacionan con los planes de prueba de proyectos, niveles
o fases de prueba, los de objetivos de prueba y ejecución pruebas. debe saber qué partes
del proceso de prueba requieren especial atención en la planificación de las
pruebas. Usted debe ser capaz de explicar la justificación detrás de varios criterios de
entrada y salida que podrían relacionarse a los proyectos, niveles o fases de prueba y
los objetivos de la prueba. debe ser capaz de distinguir el propósito y el contenido de los
planes de prueba de la prueba de diseño de especificaciones, casos de prueba y
procedimientos de prueba, y conocer la IEEE 829 esbozo de un plan de pruebas. Usted
debe conocer los factores que afectar el esfuerzo involucrado en las pruebas, incluyendo
especialmente estrategias (enfoques) de la prueba y cómo afectan a las pruebas. Usted
debería ser capaz de explicar cómo se utilizan métricas, la experiencia y la negociación de
estimar. Usted debe conocer los términos del glosario criterios de entrada, salida criterios,
pruebas exploratorias, enfoque de la prueba, la prueba de nivel, planes de prueba,
prueba procedimiento y estrategia de prueba.
De la Sección 5.3, usted debe ser capaz de explicar los fundamentos del seguimiento y
control de progreso de las pruebas. Usted debe saber las métricas comunes que son
tomadas, guardadas y usadas para el monitoreo, así como formas de presentar estas
métricas. Usted debe ser capaz de analizar, interpretar y explicar las métricas de prueba
que pueden ser útiles para el informe del estado de las pruebas y para tomar decisiones
acerca de cómo controlar el progreso de prueba.
Usted debe ser capaz de explicar un informe provisional de situación típica y conocer el
informe resumen de la prueba IEEE 829 y el registro de la prueba. Usted debe saber los
términos del glosario densidad de defectos, tasa de fallos, control de prueba, prueba
cobertura, monitorización de las pruebas y el informe de prueba.
De la Sección 5.4, ahora debería comprender los fundamentos de la configuración de la

gestión que se refieren a la prueba. Usted debería ser capaz de resumir la ayuda que
proporciona la gestión de la configuración de la prueba para hacer nuestro trabajo
mejor. Usted debe conocer los términos del glosario gestión de la configuración y el
control de versiones.
De la Sección 5.5, ahora debería ser capaz de explicar cómo el riesgo y las pruebas se
relacionan. Usted debe saber que el riesgo es un potencial efecto negativo o indeseable y
que la mayor parte de los riesgos que interesan se refieren a la consecución de los
objetivos del proyecto. deben saber sobre probabilidad y el impacto de los factores que
determinan la importancia de un riesgo. Usted debe ser capaz de comparar y contrastar
los riesgos para el producto (y su calidad) y los riesgos para el proyecto en sí y saber los
riesgos típicos para el producto y el proyecto. Debieras ser capaz de describir cómo
utilizar el análisis de riesgos y gestión de riesgos para pruebas y planificación de las
pruebas. Usted debe conocer los términos del glosario riesgo del producto, el riesgo del
proyecto, los riesgos y las pruebas basadas en el riesgo.
De la Sección 5.6, usted debe entender ahora el registro de incidentes y ser capaz de
utilizar la gestión de incidencias en sus proyectos. debe conocer el contenido de un
informe de incidente de acuerdo con la estándar IEEE 829. Usted debe ser capaz de
escribir con alta calidad informe basado en los resultados de pruebas y gestionar dicho
informe a través de su vida ciclo. Usted debe saber el término del glosario registro de
incidentes.

Pregunta 1 ¿Por qué son importantes las pruebas independientes?
a. Las pruebas independientes es generalmente más barato que las pruebas de su propio
trabajo.
b. Las pruebas independientes es más eficaz en la búsqueda defectos.
c. testers independientes deben determinar la procesos y metodologías utilizadas.
d. testers independientes son desapasionados acerca si el proyecto tiene éxito o no
Pregunta 2 ¿Cuál de las siguientes es una de las tareas típicas de un líder de prueba?
a. Desarrollar los requisitos del sistema, diseño especificaciones y modelos de uso.
b. Manejar todas las funciones de automatización de pruebas.
c. Mantener pruebas y cobertura de las pruebas ocultas a programadores.
d. Reunir y presentar las métricas de progreso de la prueba.
Pregunta 3 ¿Según el Glosario ISTQB, ¿Qué queremos decir cuando llamamos a alguien
gerente de prueba?
a. Un director de pruebas gestiona una colección de prueba líderes.
b. Un director de pruebas es el líder de un equipo de prueba o equipos.
c. Un director de pruebas se le paga más de un líder de la prueba.
d. Un gerente prueba de informes a un líder de la prueba.
Pregunta 4 ¿Cuál es la principal diferencia entre el plan de pruebas, la especificación de

diseño de la prueba, y del procedimiento de ensayo?
a. El plan de ensayo describe uno o más niveles de las pruebas, las especificaciones de diseño
de la prueba identifican casos de prueba de nivel alto y una prueba especificación del
procedimiento se describen las acciones de la ejecución de una prueba.
b. El plan de pruebas es para los administradores, el diseño de la prueba especificación es
para los programadores y la prueba especificación del procedimiento es para los testers que
se encuentran la automatización de pruebas.
c. El plan de pruebas es la menos profunda, la prueba especificación del procedimiento es el
más completo y la especificación de diseño de la prueba está a medio camino entre los dos.
d. El plan de pruebas se terminó en el primer tercio de la proyecto, la especificación de diseño
de la prueba se acaba en el tercio medio del proyecto y la prueba especificación del
procedimiento se acaba en la última tercio del proyecto.
Pregunta 5 ¿Cuál de los siguientes factores es una influencia en la prueba de esfuerzo

involucrado en la mayor parte proyectos?
a. La separación geográfica de tester y programadores.
b. La salida del director de pruebas durante el proyecto.
c. La calidad de la información utilizada para desarrollar los exámenes.
d. enfermedad inesperada a largo plazo por un miembro del equipo del proyecto.
Pregunta 6 El Plan de Estudios de la Fundación ISTQB establece un proceso de prueba

fundamental en la prueba la planificación se produce al principio del proyecto, mientras que
la prueba ejecución se produce al final. ¿Cuál de los siguientes elementos del plan de pruebas,
mientras que se especifique durante la prueba Planificación, se evalúa durante la ejecución
de la prueba?
a. tareas de prueba
b. necesidades ambientales
c. Criterio de salida
d. entrenamiento del equipo de prueba
Pregunta 7 Tenga en cuenta los siguientes criterios de salidaque puede ser encontrado en un
plan de pruebas:
I No se conocen los defectos de los clientes crítico.
II Todas las interfaces entre los componentes probados.
III 100% de cobertura de código de todas las unidades.
IV especifica todos los requisitos satisfechos.
V funcionalidad del sistema coincide con el sistema legado para todas las reglas de negocio.
¿Cuál de las siguientes afirmaciones es verdadera acerca si estos criterios de salida

pertenecen a una aceptación ¿Plan de prueba?
a. Todas las declaraciones pertenecen en un plan de pruebas de aceptación.
b. Sólo comunicado que pertenece a una prueba de aceptación plan.
c. Sólo los números I, II y V pertenezco en un plan de pruebas de aceptación.
d. Sólo los números I, IV, V y pertenecen a un plan de pruebas de aceptación.
Pregunta 8 ¿Según el Glosario ISTQB, lo que es un nivel de prueba?

a. Un grupo de actividades de prueba que se organizan juntos.
b. Uno o más especificación de diseño de la prueba documentos.
c. Un tipo de prueba.
d. Una certificación ISTQB.
Pregunta 9 ¿Cuál de las siguientes mediciones haría será más útil para vigilar durante la
ejecución de la prueba?
a. Porcentaje de casos de prueba escrita.
b. Número de entornos de prueba que queden por configurado.
c. Número de defectos encontrados y fijos.
d. Porcentaje de requisitos para los que tiene una prueba ha escrito.
Pregunta 10 Durante la ejecución de pruebas, la prueba gerente describe la siguiente situación

al equipo de proyecto: '90% de los casos de prueba se han ejecutado. 20% de los casos de
prueba han identificado los defectos. 127 Se han encontrado defectos. 112 defectos han sido
fijo y han superado las pruebas de confirmación. Del restante 15 defectos, gestión de
proyectos tiene decidieron que no necesitan ser fijado antes de lanzamiento.' ¿Cuál de los
siguientes es la interpretación más razonable de este informe provisional de situación?
a. Los restantes 15 defectos deben ser de confirmación probado antes de su liberación.

b. El 10% restante de los casos de prueba se debe ejecutar antes de su liberación.
c. Ahora el sistema está listo para el lanzamiento sin más pruebas o esfuerzo de desarrollo.
d. Los programadores deben centrar su atención en la fijación de los defectos restantes
conocido antes de su liberación.
Pregunta 11 En un informe resumen de la prueba, el supervisor de la prueba del proyecto

hace la siguiente declaración, 'El subsistema de procesamiento de pagos no acepta los pagos
de los titulares de tarjetas American Express, que se considera una característica
imprescindible para este trabajo lanzamiento.' Esta declaración es probable que se encuentre
en ¿cuál de las siguientes secciones?
a. Evaluación
b. Resumen de las actividades
c. varianzas
d. Descripción incidente
Pregunta 12 Durante un período inicial de prueba ejecución, un defecto se encuentra, resuelto

y confirmado como resuelto de una comprobación, pero se ve de nuevo más tarde durante la
ejecución de la prueba posterior. ¿Cuál de los siguientes es un aspecto relacionados con las
pruebas de gestión de la configuración que es más probable que se han venido abajo?
a. trazabilidad
b. prueba de confirmación
c. Control de la configuración
d. gestión de documentación de prueba
Pregunta 13 Usted está trabajando como tester en un proyecto para desarrollar un sistema de
punto de venta para supermercados y otros puntos de venta similares. ¿Cuál de los siguientes
es un riesgo del producto con respecto a dicha ¿proyecto?
a. La llegada de un producto competidor más fiable en el mercado.
b. Entrega de una versión de prueba incompleta a la primera ciclo de prueba del sistema.
c. Un excesivamente alto número de soluciones a anomalías fallan durante la re-prueba.
d. Si no se acepta tarjetas de crédito permitidas.
Pregunta 14 Una reunión de análisis de riesgo del producto es que tuvo lugar durante el
período de planificación del proyecto. ¿Cuál de la siguiente determina el nivel de riesgo?
a. Dificultad de la solución de problemas relacionados con el código
b. El daño que podría causar al usuario
c. El precio por el que se vende el software
d. El personal técnico de la reunión
La pregunta 15 que está escribiendo un plan de pruebas utilizando la IEEE 829 plantilla y
actualmente están completando la sección de riesgos y contingencias. ¿De los cuales lo que
sigue es más probable que se enumeran como un riesgo del proyecto?
a. enfermedad inesperada de un miembro clave del equipo
b. el tiempo de proceso de transacciones excesivamente lento
c. corrupción de los datos en virtud de congestión de la red
d. El fracaso para tratar un caso clave de uso
Pregunta 16 Usted y los interesados en el proyecto elaborar una lista de los riesgos de
producto y los riesgos del proyecto durante la etapa de planificación de un proyecto. Qué
más debe hacer con esas listas de riesgos durante la prueba ¿planificación?
a. Determinar el alcance de las pruebas requeridas para el riesgo de los productos y la

mitigación y contingencia acciones necesarias para los riesgos del proyecto.
b. Obtener los recursos necesarios para cubrir completamente cada riesgo del producto con
pruebas y transferencia la responsabilidad del proyecto corre el riesgo de que el proyecto
gerente.
c. Ejecutar pruebas suficientes para los riesgos de los productos, basado en la probabilidad y
el impacto de cada riesgo del producto y ejecutar acciones de mitigación para todos los
riesgos del proyecto.
d. No se requiere ninguna acción adicional de gestión de riesgos en la etapa de planificación
de las pruebas.
Pregunta 17 Según el Glosario ISTQB, una riesgo del producto se relaciona con cuál de las
siguientes?
a. El control del proyecto de prueba
b. El objeto de prueba
c. Un elemento de una sola prueba
d. Un posible resultado negativo
Pregunta 18 En un informe de incidente, el tester hace la siguiente declaración, En este punto,

me esperar recibir un mensaje de error que explica la rechazo a esta entrada inválida y me
pide que introduzca una entrada válida. En cambio, el sistema acepta la entrada, muestra un
reloj de arena de entre uno y cinco segundos y, finalmente, termina de forma anormal,
dando el mensaje, "inesperado tipo de datos: 15.
Haga clic para continuar. "" Esta declaración es probable que sea encontrado en cuál de las
siguientes secciones de IEEE 829 informe de incidente estándar?
a. Resumen
b. Impacto
c. Tema pase / no pasa criterios
d. Descripción incidente
Pregunta 19 Según el Glosario ISTQB, ¿qué es lo que llamamos un documento que describe
cualquier evento que ocurrió durante la prueba que requiere investigación más a fondo?
a. Un informe de error
b. Un informe de defectos
c. Un informe de incidente
d. Un informe resumen de la prueba
La pregunta 20 se realizó un análisis de riesgo del producto durante la etapa de planificación

del proceso de prueba.
Durante la fase de ejecución del proceso de prueba, el director de pruebas dirige los testers
para clasificar cada informe de defectos por el riesgo de un producto conocido que se refiere
a (O al "otro"). Una vez a la semana, el director de pruebas se ejecuta un informe que muestra
el porcentaje de defectos en relación con cada producto riesgo conocido y desconocido
riesgos. ¿Cuál es una posible utilización de dicho informe?
a. Para identificar nuevos riesgos para la calidad del sistema.

b. Para localizar las agrupaciones de defectos en los subsistemas de productos.
c. Para comprobar la cobertura de riesgos por medio de pruebas.
d. Para medir pruebas exploratorias.
EJERCICIO: INFORME DE INCIDENTES

Remitirse a la dirección de correo utilizado como un ejercicio en el Capítulo 1. Utilice la
plantilla de incidentes para transformar esa e- enviar por correo en un defecto informe bien
escrito. Asegúrese de tomar en cuenta y resolver algunos de los problemas con la dirección
de correo. Siéntase libre de utilizar su imaginación para crear los detalles adicionales que
pueda necesitar para una buen informe de defectos.
SOLUCIÓN DE EJERCICIO
Este es un posible defecto informe derivado de la dirección de correo. Tenga en cuenta que
se ha evitado la repetición y lenguaje emotivo. Nos hemos asegurado de incluir suficientes
pruebas y los pasos para reproducir el problema.
Descripción breve Los entornos de cliente no están claramente identificados en pantalla para
el usuario y el método de iniciar sesión en un entorno de cliente permite a los entornos de
prueba y producción deben confundirse. Esto significa que si ustedes mis-clic en un archivo
.bat cuando se ejecuta el cliente, puede abrir el cliente equivocado y no se dan cuenta.
Evaluación de impacto
Prioridad baja a mediana
Muy alta severidad
(No detener procedimiento de prueba)
(Podría afectar los negocios de los usuarios)
Descripción detallada Los entornos de cliente no están claramente identificados en pantalla
para el usuario y el método de iniciar sesión en un entorno de cliente permite a los entornos
de prueba y producción deben confundirse. Esto significa que si ustedes mis-clic en un
archivo .bat cuando se ejecuta el cliente, puede abrir el cliente equivocado y no se dan cuenta.
Este es un problema que se resuelve si haría la prueba realiza dentro de las áreas de desarrollo
y el sistema de ensayo más eficiente y también es importante para la comunidad de usuarios.
Este problema surgirá para los usuarios de dos maneras:
• Llevan a cabo UAT en sus propias máquinas y por lo tanto los datos de prueba, así como
los clientes en vivo están disponibles en sus listas y pueden mal seleccione el cliente, ya sea
en la realización de las pruebas (y sin querer probar en el sistema vivo) o puede mis-
seleccionar el sistema de prueba cuando el comercio (creo que han negociado cuando no
tienen o plantear cuestiones de mesa de ayuda si creen que sea un problema del sistema).
• Llevan a cabo el trabajo en diferentes países / mercados y necesitan saber que están
operando en.
Las medidas tomadas por el tester:

•Tenemos dos entornos de prueba llamados Systest14 y Systesti 5 y mis pruebas se
establecieron en systest 15.
•Para ejecutar los clientes, tenemos que ejecutar un archivo .bat, ya sea para un cliente de 14
o 15.
•Yo había comenzado dos clientes, es decir, dos participantes en el intercambio, por lo que
podía hacer algo de comercio entre ellos.
•Parece que empecé el primer cliente en el entorno de 15, pero cuando empecé la segunda
me ha movido accidentalmente el ratón una fracción por lo que corrió el archivo .bat 14 que
está junto a él en la lista de archivos del Explorador.
Las pantallas de los clientes no muestran el entorno al que está conectado y por lo que trataron
de proceder con las pruebas que había planeado y no podía conseguir los resultados que yo
esperaba. Después de algunas investigaciones me di cuenta de que había cometido un error
en la prueba de puesta a punto seleccionando el cliente equivocado. ¿Qué hizo que mi error
y podría prevenirse? mientras que en el diario de navegación en el lado del servidor en un
entorno de prueba, el nombre del entorno se deben escribir en y se demuestra en todo el
paneles, el inicio de sesión para el lado del cliente se realiza mediante la selección de un
archivo .bat de una lista de todos los archivos con nombres similares. Ahí no es ni una
pantalla ni la capacidad de determinar el entorno de cliente en el que se está trabajando.
Un problema relacionado (TP1034 / 2) se ha aumentado con respecto al país por defecto /

mercado, que no se muestra en pantalla y puede ser mal seleccionados. Proporcionar una
pantalla de inicio de sesión para el cliente y que muestra el cliente seleccionado en la pantalla
prevendría estos dos errores de usuario.
Aunque esto no es un problema funcionalidad y es causada por un error de usuario, que es

un error fácil de hacer y podría tener un gran impacto. En términos de la vida real que
significa un usuario real podría estar conectado al sistema de producción y creo que él o ella
está conectado a un sistema de prueba y así hacer que las operaciones irregulares o
ilegales. Esto ha sucedido una vez en el sistema de producción de negociación de acciones,
cuando un operador introduce una carga de transacciones de prueba en la producción del
sistema por error y causado problemas considerables (véase el informe de incidente en vivo
A1204 / 23b). Necesitamos, por tanto, prevenir que esto ocurra en este sistema.
Impacto en las pruebas Pasaron 15 horas-hombre para investigar y comprender la causa
raíz.
La evidencia adjunta
• Las capturas de pantalla de los entornos de servidor y cliente 14 y 15
• Las capturas de pantalla de entornos reales equivalentes
• Las capturas de pantalla del problema de elección país
• estadísticas de tiempo de recuperación para este problema, el problema / defecto mercado
del país y el problema de la equidad del sistema referido a.
CAPÍTULO SEIS
Herramienta de apoyo para las pruebas
ou puede desear que tenías una herramienta mágica que automatizar todos
la prueba para usted. Si es así, usted se sentirá decepcionado. Sin embargo, hay una
número de herramientas muy útiles que pueden aportar beneficios significativos. En este
capítulo
veremos que hay un apoyo de herramientas para muchos aspectos diferentes de software
pruebas. Veremos que el éxito con las herramientas no está garantizada, incluso si una
herramienta apropiada se adquiere - también hay riesgos en el uso de herramientas. Existen
algunas consideraciones especiales que se mencionan en el programa de estudios para ciertos
tipos de
Herramienta: herramientas de ejecución de pruebas, herramientas de pruebas de rendimiento,
herramientas de análisis estático y
herramientas de gestión de pruebas.
Y
6.1 Tipos de herramienta de prueba
1 clasificar los diferentes tipos de herramientas de prueba de acuerdo con la prueba
activi proceso
lazos. (K2)
2 Reconocer las herramientas que pueden ayudar a los desarrolladores en sus pruebas.
(KL)
En esta sección, vamos a describir los diferentes tipos de herramientas en términos de su
general
funcionalidad, en vez de entrar en muchos detalles. La razón de esto es que, en
en general, los tipos de herramienta será bastante estable durante un período más largo, a
pesar de que
habrá nuevos proveedores en el mercado, herramientas nuevas y mejoradas, e incluso la
nueva
tipos de herramienta en los próximos años.
No mencionaremos las herramientas comerciales en este capítulo. Si lo hemos hecho, este
libro
dataría muy rápidamente! proveedores de herramientas son adquiridos por otros proveedores,
el cambio
sus nombres, y cambiar los nombres de las herramientas con bastante frecuencia, por lo que
no
mencionar los nombres de herramientas o vendedores.
6.1.1 Prueba de clasificación de herramientas
Las herramientas se agrupan por las actividades de ensayo o áreas que son compatibles con
una
Conjunto de herramientas, por ejemplo, herramientas que apoyan las actividades de gestión,
herramientas para
apoyar las pruebas estáticas, etc.
No hay necesariamente un uno-a-uno entre un tipo de herramienta
se describe aquí y una herramienta ofrecido por un proveedor o un instrumento comercial
abierto
página 170
herramienta de código. Algunas herramientas realizan una función muy específica y limitada
(a veces
llama una "solución puntual '), pero muchas de las herramientas comerciales destinadas a
ayudar
un número de diferentes funciones (suites de herramientas o familias de herramientas). Por
ejemplo, una
herramienta "de gestión de pruebas 'puede proporcionar apoyo para la gestión de las pruebas
(el progreso
monitoreo), gestión de la configuración de testware, gestión de incidencias,
y la gestión de requisitos y trazabilidad; otra herramienta puede proporcionar tanto
medición de la cobertura y el apoyo diseño de la prueba.
Hay algunas cosas que la gente puede hacer mucho mejor o más fácil que un com-
computadora puede hacer. Por ejemplo, cuando ves a un amigo en un lugar inesperado, di
en un aeropuerto, se puede reconocer de inmediato su rostro. Este es un ejemplo de
reconocimiento de patrones que las personas son muy buenos, pero no es fácil escribir soft-
cerámica que puede reconocer una cara.
Hay otras cosas que las computadoras pueden hacer mucho mejor o más rápido
que la gente puede hacer. Por ejemplo, se puede añadir hasta 20 números de tres dígitos
¿con rapidez? Esto no es fácil para la mayoría de la gente a hacer, por lo que es probable que
hagan
algunos errores, incluso si los números están escritos. Una computadora hace esto
con precisión y muy rápidamente. Como otro ejemplo, si se pide a la gente a hacer
exactamente la misma tarea una y otra vez, pronto se aburren y luego empezar
cometiendo errores.
El punto es que es una buena idea utilizar las computadoras para hacer cosas que ordenadores
ERS son realmente buenos y que las personas no son muy buenos. Así soporte de la
herramienta es
muy útil para tareas repetitivas - el equipo no se aburre y podrá
repetir exactamente lo que se hizo antes. Debido a que la herramienta sea rápido, esto puede
hacer esas actividades mucho más eficiente y más fiable. Las herramientas también pueden
hacer cosas que pueden saturar una persona, tales como comparar el contenido de una
archivo de datos de gran tamaño o la simulación de cómo se comportaría el sistema.
Una herramienta que mide algún aspecto de software puede tener lateral inesperada
efectos sobre dicho software. Por ejemplo, una herramienta que mide los tiempos por falta
de
ensayos de funcionamiento (rendimiento) necesita interactuar estrechamente con la
software con el fin de medirlo. Una herramienta de rendimiento va a establecer una hora de
inicio y
un tiempo de parada para una transacción dada con el fin de medir el tiempo de respuesta,
para
ejemplo. Pero el acto de tomar esa medida, es decir, el tiempo en el almacenamiento
esos dos puntos, en realidad podría hacer que toda la operación tardará un poco
más de lo que haría si la herramienta no estaba midiendo el tiempo de respuesta. De
Por supuesto, el tiempo extra es muy pequeño, pero todavía está allí. Este efecto se llama
el "efecto de sondeo '.
Otro ejemplo del efecto de la sonda se produce con las herramientas de cobertura. A fin de
que
medir la cobertura, la herramienta debe identificar primero todos los elementos estructurales
que
podrían ser ejercido para ver si una prueba ejerce o no. Esto se conoce como 'instrumento
Menting el código '. Las pruebas se ejecutan a continuación, a través del código de
instrumentos de medida
que la herramienta puede decirle (a través de la instrumentación) si es o no un hecho
sucursal (por ejemplo) se ha ejercido. Pero el código instrumentado no es el
mismo que el código de bienes - que también incluye el código de instrumentación. En teoría,
el
código es el mismo, pero en la práctica, no lo es. Debido a que las herramientas de trabajo
diferentes de cobertura
de manera ligeramente diferente, es posible obtener una medida de la cobertura ligeramente
diferente en
el mismo programa, debido al efecto de la sonda. Por ejemplo herramientas diferentes pueden
contar sucursales en diferentes formas, por lo que el porcentaje de cobertura sería com-
comparación con un número total de diferentes ramas. El tiempo de respuesta del instrumento
mentado código también puede ser significativamente peor que el código sin
instrumentación. (También hay herramientas de cobertura no intrusivos que observan la
página 171
bloques de memoria que contienen el código objeto para obtener una medida aproximada
sin instrumentación, por ejemplo, para el software embebido.)
Un ejemplo adicional del efecto de la sonda es cuando una herramienta de depuración se
utiliza para
tratar de encontrar un defecto particular. Si se ejecuta el código con el depurador, a
continuación, el error
desaparece; sólo reaparece cuando el depurador está apagada (con lo cual
es mucho más difícil de encontrar). Estos son a veces conocidos como '' Heizenbugs
(Después de principio de incertidumbre de Heizenberg).
En las descripciones de las herramientas a continuación, indicaremos las herramientas que
son
más probabilidades de ser utilizado por los desarrolladores durante las pruebas de
componentes y el componente
pruebas de integración. Por ejemplo herramientas de medición de cobertura son más a
menudo
utilizados en las pruebas de componentes, sino que se utilizan con más frecuencia las
herramientas de pruebas de rendimiento
en las pruebas del sistema, las pruebas de integración de sistemas y pruebas de aceptación.
Tenga en cuenta que para el examen Foundation Certificate, sólo es necesario reconocer
los diferentes tipos de herramientas y lo que hacen; que no es necesario una comprensión
detallada
pie de ellos (o no saben cómo usarlos).
6.1.2 Herramienta de apoyo para la gestión de las pruebas y exámenes
¿Qué significa "gestión de pruebas '? Podría ser 'la gestión de pruebas "o
que podría ser 'la gestión del proceso de prueba'. Las herramientas de esta amplia categoría
proporcionar soporte para uno o ambos de estos. La gestión de la prueba se aplica
sobre la totalidad del ciclo de vida del software de desarrollo, por lo que una gestión de
pruebas
herramienta podría estar entre los primeros en ser utilizado en un proyecto. Una herramienta
de gestión de pruebas
También puede gestionar las pruebas, que comenzaría al principio del proyecto y lo haría
a continuación, seguir utilizándose durante todo el proyecto y también después de que el
sistema tenía
sido puesto en libertad. En la práctica, las herramientas de gestión de pruebas suelen ser
utilizados por especialización
ist testers o gerentes de las pruebas a nivel de prueba del sistema o aceptación.
herramientas de gestión de pruebas
Las características proporcionadas por las herramientas de gestión de prueba incluyen los
enumerados a continuación.
Algunas herramientas proporcionarán todas estas características; otros pueden proporcionar
una o más
de las características, sin embargo este tipo de herramientas todavía serían clasificadas como
de gestión de pruebas
herramientas.
Rasgos o características de las herramientas de gestión de pruebas incluyen soporte para:
• Gestión de pruebas (por ejemplo, hacer el seguimiento de los datos asociados a un
determinado conjunto
de pruebas, sabiendo qué pruebas necesitan para funcionar en un entorno común, número de
de pruebas previstas, por escrito, correr, pasado o no);
• programación de pruebas para ser ejecutado (manualmente o mediante una herramienta de
ejecución de la prueba);
• La gestión de las actividades de prueba (tiempo de permanencia en el diseño de pruebas,
ejecución de la prueba,
si estamos en la fecha prevista o en el presupuesto);
• interfaces con otras herramientas, tales como:
- Herramientas de ejecución de pruebas (herramientas de prueba de funcionamiento);
- Herramientas de gestión de incidentes;
- Herramientas de gestión de requisitos;
- Herramientas de gestión de configuración;
• trazabilidad de las pruebas, resultados de pruebas y defectos en los requisitos o de otras
fuentes;
• resultados de las pruebas de registro (tenga en cuenta que la herramienta de gestión de
pruebas no se ejecuta pruebas,
página 172
pero podría resumir los resultados de herramientas de ejecución de pruebas de que la prueba
de manejo
interfaces de las herramientas con Ment);
• la preparación de los informes de progreso basados en métricas (análisis cuantitativo), tales
como:
- Las pruebas se ejecutan y se pasan las pruebas;
- incidentes plantearon, defectos fijos y excepcional.
Esta información se puede utilizar para controlar el proceso de prueba y decidir qué
las acciones a tomar (control de prueba), como se describe en el capítulo 5. La herramienta
también da
información sobre el componente o sistema que está siendo probada (el objeto de
prueba). Prueba
herramientas de gestión ayudan a reunir, organizar y comunicar información
acerca de las pruebas en un proyecto.
herramientas de gestión de requisitos
Son herramientas de gestión de requisitos herramientas realmente poniendo a
prueba? Algunas personas pueden decir
no lo son, sino que proporcionan algunas de las características que son muy útiles para las
pruebas.
Dado que las pruebas se basan en los requisitos, mejor será la calidad de la exigencia
mentos, más fácil será para escribir pruebas de ellos. También es importante estar
capaz de rastrear las pruebas a los requisitos y exigencias de pruebas, como vimos en el
Capitulo 2.
Algunas herramientas de gestión de requisitos son capaces de encontrar defectos en el
requisito
mentos, por ejemplo mediante la comprobación de palabras ambiguas o prohibidas, tales
como
'Poder', 'y / o', 'según sea necesario "o" (por decidir)'.
Funciones o características de las herramientas de gestión de requisitos incluyen
apoyo para:
• almacenar declaraciones de requisitos;
• almacenar información sobre los atributos de los requisitos;
• verificación de la coherencia de los requisitos;
• identificar indefinido, desaparecidos o 'que se define más adelante' requisitos;
• fijación de las prioridades para los propósitos de prueba;
• trazabilidad de los requisitos a los ensayos y pruebas de los requisitos, funciones o
caracteristicas;
• trazabilidad a través de niveles de requisitos;
• interfaz para probar las herramientas de gestión;
• La cobertura de las necesidades por un conjunto de pruebas (a veces).
herramientas de gestión de incidentes
Este tipo de herramienta también se conoce como una herramienta de seguimiento de
defectos, a-gestión de defectos
herramienta, una herramienta de seguimiento de bugs o una herramienta de gestión de
errores. Sin embargo, 'incidente Hombre-
herramienta de gestión ' , porque no es probablemente un mejor nombre para él todas las
cosas
rastreado en realidad son defectos o errores; incidentes también pueden ser problemas
percibidos,
anomalías (que no son necesariamente defectos) o las solicitudes de mejora. También lo que
Normalmente se registra es la información sobre el error (no el defecto) que era
generados durante la prueba - información sobre el defecto que causó que el fracaso
vendría a la luz cuando alguien (por ejemplo, un desarrollador) comienza a investigar la
fracaso.
Los informes de incidentes pasan por una serie de etapas, desde la identificación inicial
y el registro de los datos, mediante el análisis, clasificación, asignación para
página 173
la fijación, fijo, re-probado y cerrada, tal como se describe en el capítulo 5. gestión de
incidentes
Ment herramientas hacen que sea mucho más fácil hacer un seguimiento de los incidentes en
el tiempo.
Funciones o características de las herramientas de gestión de incidentes incluyen soporte
para:
• almacenar información sobre los atributos de incidentes (por ejemplo, la gravedad);
• almacenar los archivos adjuntos (por ejemplo, una captura de pantalla);
• dar prioridad a los incidentes;
• la asignación de acciones a personas (fix, prueba de confirmación, etc.);
• Estado (por ejemplo, abierta, rechazado, duplicar, diferido, listo para la prueba de
confirmación,
cerrado);
• Información sobre las estadísticas sobre incidentes / métricas (por ejemplo, tiempo medio
abierta,
número de incidentes con cada estado, el número total recaudado, abierta o
cerrado).
funcionalidad de la herramienta de gestión de incidencias se puede incluir en una prueba
comercial
herramientas administrativas.
herramientas de gestión de configuración
Un ejemplo: Un grupo de prueba comenzó a probar el software, esperando encontrar la
habitual
bastante alto número de problemas. Pero para su sorpresa, el software parecía estar
mucho mejor de lo habitual este tiempo - se encontraron muy pocos defectos. Antes de que
CEL
ebrated la gran calidad de esta versión, que acaba de hacer una comprobación adicional para
ver si tenían la versión correcta y descubrieron que en realidad estaban probando
la versión de dos meses anteriores (que había sido depurado) con las pruebas
para que la versión anterior. Era bueno saber que esto todavía estaba bien, pero
no fueron en realidad probando lo que pensaban que estaban probando o lo que deberían
han estado probando.
Herramientas de gestión de configuración no son estrictamente probando herramientas o
bien, pero
buena gestión de la configuración es crucial para el ensayo controlado, como era
descrito en el capítulo 5. Necesitamos saber exactamente qué es lo que estamos apoyo
planteado para probar, como la versión exacta de todas las cosas que pertenecen a una
sistema. Es posible llevar a cabo actividades de gestión de configuración sin
el uso de herramientas, pero las herramientas hacen la vida mucho más fácil, sobre todo en
el complejo
ambientes.
Testware necesita estar bajo la gestión de la configuración y la misma herramienta
puede ser capaz de ser utilizado para testware así como para elementos de software. también
testware
tiene diferentes versiones y se cambia con el tiempo. Es importante para ejecutar el
versión correcta de las pruebas, así, como nuestro ejemplo anterior muestra.
Funciones o características de las herramientas de gestión de configuración incluyen
apoyo para:
• almacenar información acerca de las versiones y la obra del software y testware;
• trazabilidad entre el software y testware y diferentes versiones o variantes;
• Hacer un seguimiento de las versiones de las cuales pertenecen a cada configuraciones (por
ejemplo oper
Ating sistemas, las bibliotecas, los navegadores);
• construir y liberar la gestión;
• baselining (por ejemplo, todos los elementos de configuración que componen una versión
específica);
• Control de acceso (registro de salida).
página 174
6.1.3 Herramienta de apoyo para pruebas estáticas
Las herramientas descritas en esta sección apoyan las actividades de ensayo descritos en
Capítulo 3.
herramientas de apoyo a proceso de revisión
El valor de los diferentes tipos de revisión se discutió en el capítulo 3. Para una muy
revisión informal, donde una persona se ve en el documento de otra y da unos cuantos
comentarios al respecto, una herramienta como ésta sólo podría ponerse en el camino. Sin
embargo, cuando
el proceso de revisión es más formal, cuando muchas personas están involucradas, o cuando
el
personas involucradas están en diferentes ubicaciones geográficas, entonces el apoyo de
herramientas
se convierte en mucho más beneficioso.
Es posible hacer un seguimiento de toda la información para un proceso de revisión
el uso de hojas de cálculo y documentos de texto, sino una herramienta de revisión que está
diseñado
con el propósito es más probable que hacer un mejor trabajo. Por ejemplo, una cosa
que deben ser controlados para cada revisión es que los revisores no tienen
pasado el documento demasiado rápido, es decir, que la tasa de cheques (número de
páginas controladas por hora) fue similar a la recomendada para los que la revisión
ciclo. Una herramienta de apoyo a proceso de revisión podría calcular automáticamente la
la comprobación de tipos y la bandera excepciones. Las herramientas de apoyo a proceso de
revisión puede
normalmente ser adaptado para el proceso de revisión en particular o tipo de revisión
Siendo hecho.
Rasgos o características de las herramientas de apoyo proceso de revisión incluyen soporte
para:
• una referencia común para el proceso de revisión o procesos para su uso en diferentes
situaciones;
• almacenar y clasificar los comentarios de revisión;
• comunicar a los comentarios de personas relevantes;
• coordinar las revisiones en línea;
• Hacer un seguimiento de los comentarios, incluyendo defectos encontrados, y
proporcionando estadísti
cal información acerca de ellos;
• proporcionar la trazabilidad entre los comentarios, documentos revisados y relacionados
documentos;
• un repositorio de reglas, procedimientos y listas de control para ser utilizado en los
exámenes, así
como criterios de entrada y salida;
• supervisar el estado de la crítica (pasado, fue aprobada con correcciones, requiere re-
revisión);
• recopilación de métricas e informar sobre los factores clave.
herramientas de análisis estático (D)
El '(D)' después de esto (y otros tipos de herramienta) indica que estas herramientas son más
propensos a ser utilizado por los desarrolladores. El análisis estático de herramientas se
discutió en
Capítulo 3. En esta sección se da un resumen de lo que hacen las herramientas.
Herramientas de análisis estático son utilizados normalmente por los desarrolladores como
parte del desarrollo
ción y el proceso de pruebas de componentes. El aspecto clave es que el código (u otro
artefacto) no se ejecuta o se ejecuta. Por supuesto, la propia herramienta se ejecuta, pero el
código fuente que nos interesa es la de datos de entrada a la herramienta.
página 175
herramientas de análisis estático son una extensión de la tecnología de compilación - de
hecho algunos
compiladores ofrecen funciones de análisis estático. Vale la pena comprobar lo que está
disponible
de compiladores existentes o entornos de desarrollo antes de mirar a propósito
persiguiendo una herramienta de análisis estático más sofisticado.
El análisis estático también se puede llevar a cabo en otras cosas que el código de software,
por
ejemplo, el análisis estático de requisitos o el análisis estático de los sitios web (por
ejemplo, para evaluar el uso adecuado de etiquetas de accesibilidad o el siguiente de HTML
normas).
herramientas de análisis estático de código puede ayudar a los desarrolladores a entender la
estructura
tura del código, y también se puede utilizar para hacer cumplir las normas de
codificación. Mira la sección
6.2.3 consideraciones especiales en la introducción de herramientas de análisis estático en
una
organización.
Funciones o características de las herramientas de análisis estático incluyen soporte para:
• calcular métricas tales como la complejidad ciclomática o niveles de anidamiento (que
puede
ayuda a identificar dónde más pruebas puede ser necesaria debido al aumento del riesgo);
• hacer cumplir las normas de codificación;
• analizar las estructuras y dependencias;
• ayuda en la comprensión de código;
• identificar anomalías o defectos en el código (como se describe en el capítulo 3).
Las herramientas de modelado (D)
Las herramientas de modelado ayudan a validar modelos del sistema o software. Por
ejemplo
una herramienta puede comprobar la consistencia de los objetos de datos en una base de datos
y se puede encontrar inconsistente
tencias y defectos. Estos pueden ser difíciles de recoger en las pruebas - es posible que tenga
probado con un elemento de datos y no se dan cuenta de que en otra parte de la base de datos
existe información contradictoria en relación con ese tema. Las herramientas de modelado
también puede
comprobar los modelos de estado o modelos de objetos.
Las herramientas de modelado suelen ser utilizados por los desarrolladores y pueden ayudar
en el diseño de
El software.
Una gran ventaja de las dos herramientas de modelado y herramientas de análisis estático es
que se pueden utilizar antes de las pruebas dinámicas se pueden ejecutar. Esto permite que
cualquier
defectos que estas herramientas pueden encontrar para ser identificados tan pronto como sea
posible, cuando se
es más fácil y más barato para solucionarlos. También hay un menor número de defectos de
izquierda a propagar
puerta en etapas posteriores, por lo que el desarrollo puede acelerarse y hay menos
rehacer. (Por supuesto, esto es difícil de demostrar, ya que estos defectos no están allí
¡ahora!)
Tenga en cuenta que "las herramientas de pruebas basadas en modelos 'son en realidad
herramientas que generan prueba
insumos o casos de prueba a partir de la información almacenada sobre un modelo en
particular (por ejemplo, una
diagrama de estado), por lo que se clasifican como herramientas de diseño del ensayo (véase
la Sección 6.1.4).
Rasgos o características de las herramientas de modelado incluyen soporte para:
• la identificación de inconsistencias y defectos dentro del modelo;
• ayudar a identificar y priorizar las áreas del modelo para las pruebas;
• la predicción de la respuesta del sistema y el comportamiento bajo diversas situaciones,
tales como
nivel de carga;
• facilitar la comprensión de las funciones del sistema e identificar las condiciones de prueba
utilizando una
lenguaje de modelado como UML.
página 176
6.1.4 Herramienta de apoyo para la especificación de las pruebas
Las herramientas descritas en esta sección apoyan las actividades de ensayo descritos en
Capítulo 4.
herramientas de diseño de la prueba
Herramientas de diseño de pruebas ayudan a construir casos de prueba, o al menos las
entradas de prueba (que es parte
de un caso de prueba). Si un oráculo automatizado está disponible, a continuación, la
herramienta también puede con-
struct el resultado esperado, lo que en realidad puede generar casos de prueba (en lugar de
sólo
entradas de prueba).
Por ejemplo, si los requisitos se mantienen en una gestión de requisitos o
herramienta de gestión de pruebas, o en un Computer Aided Software Engineering (CASE)
herramienta utilizada por los desarrolladores, entonces es posible identificar los campos de
entrada, incluyendo
el rango de valores válidos. Esta información de la distancia se puede usar para identificar
obligados-
los valores y las particiones de equivalencia aria. Si se almacena el rango válido, la
herramienta puede
distinguir entre los valores que deben ser aceptadas y los que deben ge-
eRate un mensaje de error. Si se almacenan los mensajes de error, entonces el esperado
resultado se puede comprobar en detalle. Si el resultado esperado de la entrada de un válido
valor se conoce, a continuación, que resultado esperado también se puede incluir en el caso
de prueba
construido por la herramienta de diseño de la prueba.
Otro tipo de herramienta de diseño de la prueba es aquella que ayuda a seleccionar las
combinaciones de
posibles factores que deben utilizarse en las pruebas, para asegurar que todos los pares de
combinaciones de
sistema operativo y el navegador se prueban, por ejemplo. Algunas de estas herramientas
puede
utilizar matrices ortogonales. Ver [Copeland, 2003] para una descripción de estos
combinación
técnicas nación.
Tenga en cuenta que la herramienta de diseño de la prueba puede tener sólo un oráculo parcial
- es decir,
conozca qué entrada los valores han de ser aceptados y rechazados, pero puede
No conocer el mensaje de error exacto o cálculo resultante de la esperada
resultado de la prueba. Así, la herramienta de diseño de la prueba puede ayudarnos a empezar
a trabajar con
diseño de la prueba e identificará todos los campos, pero no va a hacer todo el trabajo
de diseño de prueba para nosotros - no habrá más la verificación de que pueden necesitar
estar
hecho.
Otro tipo de herramienta de diseño de la prueba a veces se llama un "raspador de pantalla ',
una
plantilla estructurada o un marco de ensayo. La herramienta se parece a una ventana de la
interfaz gráfica de usuario e identifica todos los botones, las listas y de entrada
campos, y pueden establecer una prueba para cada cosa que encuentre. Esto significa que
se hace clic en cada botón, por ejemplo, y se seleccionará a cada cuadro de lista.
Este es un buen comienzo para un conjunto exhaustivo de pruebas y puede rápida y
fácilmente
identificar los botones que no funcionan. Sin embargo, a menos que la herramienta tiene
acceso a una
Oracle, puede no saber lo que realmente debería ocurrir como resultado de la
clic de botón.
Sin embargo, otro tipo de herramienta de diseño de la prueba puede ser combinado con una
herramienta de cobertura. Si
una herramienta de cobertura ha identificado que se ramifica han sido cubiertas por un
conjunto de
pruebas existente, por ejemplo, también puede identificar la ruta que necesita ser tomada en
Para cubrir las ramas no probados. Al identificar cuál de las decisiones anteriores
sión los resultados tienen que ser verdadera o falsa, la herramienta se puede calcular un valor
de entrada
que hará que la ejecución de tomar un camino en particular con el fin de aumentar la
cobertura.
Aquí la prueba está siendo diseñado desde el propio código. En este caso la presencia de
un oráculo es menos probable, por lo que sólo puede ser las entradas de prueba que se
construyen por
la herramienta de diseño de la prueba.
página 177
Rasgos o características de las herramientas de diseño de prueba incluyen soporte para:
• valores de entrada la prueba de generación a partir de:
- requisitos;
- Modelos de diseño (estado, datos u objeto);
- Código;
- las interfaces gráficas de usuario;
- condiciones de prueba;
• Los resultados de generación de esperar, si un oráculo está disponible para la herramienta.
El beneficio de este tipo de herramientas es que se puede identificar fácilmente y rápidamente
el
pruebas (o entradas de prueba) que va a ejercer todos los elementos, por ejemplo, campos de
entrada, botones,
ramas. Esto ayuda a la prueba para ser más a fondo (si es un objetivo de
¡la prueba!)
Entonces podemos tener el problema de tener demasiadas pruebas y la necesidad de encontrar
una
forma de identificar las pruebas más importantes para correr. La tala de un inmanejable
Número capaces de pruebas se puede hacer mediante el análisis de riesgos (véase el capítulo
5). El uso de un com-
técnica de combinación tales como matrices ortogonales también pueden ayudar.
herramientas de preparación de datos de prueba
La creación de datos de prueba puede ser un esfuerzo significativo, especialmente si una
extensa
Se necesita rango o el volumen de los datos para las pruebas. herramientas de preparación
de datos de prueba
ayudar en esta área. Pueden ser utilizados por los desarrolladores, pero también se pueden
usar
durante el sistema o pruebas de aceptación. Son particularmente útiles para la persona
rendimiento y pruebas de fiabilidad, donde una gran cantidad de datos es realista
necesario.
herramientas de preparación de datos de prueba permiten que los datos a ser seleccionados a
partir de una de datos existente
base o creado, generado, manipulado y editado para su uso en pruebas. El más
herramientas sofisticadas que pueden hacer frente a una serie de archivos y formatos de base
de datos.
Rasgos o características de las herramientas de preparación de datos de prueba incluyen el
apoyo a:
• Extraer selección de registros de datos a partir de archivos o bases de datos;
• registros de datos 'masaje' para que sean anónimos o no poder ser identificados
con personas reales (para protección de datos);
• permitir a los registros para ser ordenados o dispuestos en un orden diferente;
• generar nuevos registros con los datos pertinentes pseudo-aleatorios o datos creados
de acuerdo con algunas directrices, por ejemplo, un perfil operativo;
• construir un gran número de registros similares a partir de una plantilla, para dar un gran
un conjunto de registros para las pruebas de volumen, por ejemplo.
6.1.5 Herramienta de apoyo para la ejecución de la prueba y la explotación forestal
herramientas de ejecución de pruebas
Cuando la gente piensa en una "herramienta de prueba ', por lo general es una herramienta
de ejecución de la prueba que se
tener en cuenta, una herramienta que puede ejecutar las pruebas. Este tipo de herramienta
también se refiere como una
'Herramienta de prueba de marcha ». La mayoría de las herramientas de este tipo ofrecen una
manera de empezar capturando
o grabar las pruebas manuales; de ahí que también se conocen como herramientas 'de
captura / reproducción',
'/ reproducción de captura' 'herramientas o herramientas de grabación / reproducción'. La
analogía es con la grabación de una
programa de televisión, y reproducción del mismo. Sin embargo, las pruebas no son algo
página 178
que se reproduce sólo por otras personas a ver las pruebas de interactuar con el sistema,
que puede reaccionar de forma ligeramente diferente cuando se repiten las pruebas. Por lo
tanto cAP-
Tured pruebas no son adecuados si se desea alcanzar el éxito a largo plazo con una prueba
herramienta de ejecución, como se describe en la Sección 6.2.3.
herramientas de ejecución de pruebas utilizan un lenguaje de script para manejar la
herramienta. el scripting
idioma es realmente un lenguaje de programación. Por lo que cualquier tester que desea
utilizar una
herramienta de ejecución de la prueba directamente tendrá que utilizar conocimientos de
programación para crear y
modificar los scripts. La ventaja de secuencias de comandos programable es que las pruebas
pueden
repetir las acciones (en bucles) para diferentes valores de los datos (es decir, las entradas de
prueba), que pueden tomar
diferentes rutas dependiendo del resultado de una prueba (por ejemplo, si no pasa la prueba,
van a una
un conjunto diferente de las pruebas) y pueden ser llamados desde otros scripts que dan
algunos
estructura para el conjunto de pruebas.
Cuando las personas se encuentran con una herramienta de ejecución de la prueba, tienden a
utilizarlo para
"Captura / reproducción ', que suena muy bien cuando se escucha por primera vez al
respecto. los
La teoría es que mientras se ejecutan las pruebas manuales, sólo tiene que encender el
'Capturar', como una grabadora de vídeo para un programa de televisión. Sin embargo, la
teoría
se rompe cuando intenta reproducir las pruebas capturados - este enfoque no hace
escalar para un gran número de pruebas. La razón principal de esto es que un capturaron
guión es muy difícil de mantener porque:
• Está estrechamente ligado al flujo y la interfaz presentada por la interfaz gráfica de usuario.
• Se puede depender de las circunstancias, el estado y el contexto del sistema en el momento
el guión fue grabado. Por ejemplo, una secuencia de comandos capturará un nuevo orden
número asignado por el sistema cuando se graba una prueba. Cuando la prueba es
reproduce, el sistema asignará un número de orden diferente y rechazar sub
solicitudes subsiguientes que contienen el número de pedido previamente capturada.
• La información de contacto de prueba es "no modificable ', es decir, que está incrustado en
el indi
UAL guión para cada prueba.
Cualquiera de estas cosas pueden ser superados mediante la modificación de las secuencias
de comandos, pero luego
ya no son sólo grabar y reproducir! Si se necesita más tiempo para actualizar una
prueba capturado de lo que se necesitaría para ejecutar la misma prueba de nuevo de forma
manual, las secuencias de comandos
tienden a ser abandonado y se convierte en la herramienta 'estantería-ware'.
Hay mejores maneras de utilizar las herramientas de ejecución de pruebas para hacer que
funcionen bien y
realmente ofrecer los beneficios de correr sin supervisión de pruebas automatizadas. Existen
al menos cinco niveles de secuencias de comandos y también diferentes técnicas de
comparación. Datos-
scripting impulsado es un avance con respecto a las secuencias de comandos capturados pero
los scripts basado en palabras clave
dar significativamente más beneficios. [Fewster y Graham, 1999], [Buwalda et al.,
2001]. [Mosley y Posey, 2002] describen el "control sincronizado impulsado por los datos
pruebas'. Ver también la sección 6.2.3.
Hay muchas maneras diferentes de utilizar una herramienta de ejecución de la prueba y las
herramientas
ellos continúan para obtener nuevas características útiles. Por ejemplo, una prueba de eje-
cution herramienta puede ayudar a identificar los campos de entrada que formarán las
entradas de prueba y
puede construir una tabla que es el primer paso hacia el scripting basado en datos.
A pesar de que se conocen comúnmente como herramientas de prueba, que son en realidad
los más utilizados para las pruebas de regresión (para que pudieran ser referidos como
"regresión
herramientas de prueba "en lugar de" herramientas de ensayo »). Una herramienta de
ejecución de la prueba se ejecuta con mayor frecuencia
pruebas que ya se ha ejecutado antes. Uno de los beneficios más significativos de
el uso de este tipo de herramientas es que cada vez que se cambia un sistema existente (por
ejemplo, para
una solución defecto o una mejora), todos de las pruebas que se ejecutan antes podría
página 179
potencialmente ser ejecutado de nuevo, para asegurarse de que los cambios no han alterado
el
sistema existente mediante la introducción o revelar un defecto.
Funciones o características de las herramientas de ejecución de pruebas incluyen soporte
para:
• captura (grabación) entradas de prueba mientras que las pruebas se ejecutan de forma
manual;
• almacenar un resultado esperado en forma de una pantalla o un objeto de comparar con,
la próxima vez que se ejecute la prueba;
• ejecución de pruebas de secuencias de comandos y archivos de datos almacenados,
opcionalmente, se accede por la
la escritura (si impulsado por los datos o se utiliza secuencias de comandos basado en
palabras clave);
• Comparación dinámica (mientras se ejecuta la prueba) de las pantallas, elementos, enlaces,
controles, objetos y valores;
• capacidad para iniciar la comparación posterior a la ejecución;
• Los resultados de registro de las pruebas realizadas (pasa / falla, las diferencias entre lo
esperado y
resultados actuales);
• enmascaramiento o de filtrado de subconjuntos de reales y los resultados esperados, por
ejemplo,
excluyendo la fecha actual pantalla visualizada y el tiempo que no es de interés
para una prueba en particular;
• la medición de los tiempos de pruebas;
• sincronización de las entradas con la aplicación que se está probando, por ejemplo, esperar
hasta que la apli
cación está listo para aceptar la siguiente entrada, o insertar un retardo fijo para representar
velocidad de interacción humana;
• envío de resumen de los resultados de una herramienta de gestión de pruebas.
Mazo de prueba / Grupo de instrumentos de prueba de marco (D)
Estos dos tipos de herramienta se agrupan juntos ya que son variantes de la
tipo de apoyo que necesitan los desarrolladores al probar componentes individuales o
de unidades de software. Un instrumento de prueba proporciona talones y los
conductores, que son pequeñas
programas que interactúan con el software bajo prueba (por ejemplo, para las pruebas de
media
ware y software embebido). Véase el Capítulo 2 para obtener más detalles de cómo estos son
utilizado en las pruebas de integración. Algunas herramientas de marco de prueba de
unidad proporcionan apoyo
para el software orientado a objetos, otros por otros paradigmas de desarrollo. Unidad
marcos de ensayo se pueden utilizar en el desarrollo ágil para automatizar pruebas en
paralelismo
lel con el desarrollo. Ambos tipos de herramientas permiten a los desarrolladores para probar,
identificar
y localizar los defectos. El marco o los talones y los controladores proporcionan ninguna
información que necesita el software que se está probando (por ejemplo, una entrada que
haría
han venido de un usuario) y también recibir cualquier información enviada por el software
(Por ejemplo, un valor que se muestra en una pantalla). Talones también pueden ser referidos
como
'' objetos simulados.
arneses de prueba o controladores se pueden desarrollar en el local para los sistemas
particulares.
Asesoramiento sobre el diseño de los pilotos de pruebas se puede encontrar en [Hoffman y
Strooper, 1995].
Hay un gran número de herramientas 'xUnit' para la programación de diferentes len-
guas, por ejemplo JUnit para Java, NUnit para aplicaciones .Net, etc. Hay tanto
herramientas comerciales y también de código abierto (es decir, libres) herramientas. marco
de pruebas unitarias
herramientas son muy similares a probar herramientas de ejecución, ya que incluyen
instalaciones como
La capacidad de almacenar los casos de prueba y monitorear si las pruebas de aprobación o
no, por ejemplo.
La diferencia principal es que no hay ninguna instalación de captura / reproducción y tienden
para ser utilizado en un nivel inferior, es decir, para el componente o pruebas de integración
de componentes,
en lugar de para el sistema o pruebas de aceptación.
página 180
Rasgos o características de los arneses de prueba y herramientas de marco de pruebas
unitarias
incluir el apoyo a:
• el suministro de insumos para el software que está siendo probado;
• Salidas de recepción generadas por el software están probando;
• la ejecución de una serie de pruebas en el marco o usar el instrumento de prueba;
• La grabación de pasa / no pasa resultados de cada prueba (herramientas de marco);
• Pruebas de almacenamiento de herramientas (marco);
• Soporte para la depuración (herramientas de marco);
• Medición de la cobertura en el nivel de código (herramientas de marco).
comparadores de prueba
¿Es realmente una prueba de si poner algunos elementos de entrada en algún tipo de software,
pero nunca mirar hacia
ver si el software produce el resultado correcto? La esencia de la prueba es
para comprobar si el software produce el resultado correcto, y para hacer eso,
debe comparar lo que el software produce a lo que debería producir. Una prueba
comparador ayuda a automatizar aspectos de esa comparación.
Hay dos formas en las que los resultados reales de la prueba se puede comparar con el
Resultados esperados para el examen. comparación dinámica es donde la comparación es
hecho de forma dinámica, es decir, mientras se ejecuta la prueba. La otra forma es posterior
a la ejecución
comparación ción, donde se realiza la comparación después de la prueba ha terminado
la ejecución y el software que se está probando ya no está en funcionamiento.
herramientas de ejecución de pruebas incluyen la capacidad de realizar la comparación
dinámica
mientras que la herramienta se ejecuta una prueba. Este tipo de comparación es buena para
comparar
la redacción de un mensaje de error que aparece en una pantalla con la redacción correcta
para ese mensaje de error. comparación dinámico es útil cuando un resultado real hace
no coincide con el resultado esperado en el medio de una prueba - la herramienta se puede
programar
tomar alguna acción de recuperación en este momento o ir a un conjunto diferente de las
pruebas.
la comparación posterior a la ejecución por lo general se realiza mejor mediante una
herramienta independiente (es decir, no
la herramienta de ejecución de la prueba). Este es el tipo de herramienta que entendemos por
una prueba comparativa
tor o prueba de comparación de herramienta y es típicamente una herramienta de 'stand-
alone'. Operante
sistemas normalmente tienen herramientas de comparación de archivos disponibles que
pueden ser utilizados para
la comparación posterior a la ejecución y, a menudo una herramienta de comparación se
desarrollarán in-
casa para la comparación de un determinado tipo de archivo o prueba de resultado.
comparación post-ejecución es el mejor para la comparación de un gran volumen de datos,
por
ejemplo la comparación de los contenidos de un archivo completo con el contenido esperado
de
dicho archivo o en la comparación de un gran conjunto de registros de una base de datos con
la esperada
contenido de dichos registros. Por ejemplo, comparando el resultado de un funcionamiento
por lotes (por ejemplo,
procesamiento de transacciones en línea durante la noche del día) es probablemente
imposible
prescindir de soporte de la herramienta.
Si una comparación es dinámica o posterior a la ejecución, el comparador de prueba
tiene que saber lo que el resultado es correcto. Esto puede ser almacenado como parte de la
prueba
caso en sí mismo o puede ser calculada utilizando un oráculo de prueba. Véase el Capítulo 4
para información
ción sobre oráculos de prueba.
Rasgos o características de los comparadores de prueba incluyen soporte para:
• Comparación dinámica de eventos transitorios que se producen durante la ejecución de la
prueba;
• comparación posterior a la ejecución de los datos almacenados, por ejemplo, en archivos o
bases de datos;
• enmascaramiento o filtrado de subconjuntos de los resultados reales y esperados.
página 181
herramientas de medición de la cobertura (D)
Como bien has probado? Herramientas de cobertura pueden ayudar a responder a esta
pregunta.
Una herramienta de cobertura identifica en primer lugar los elementos o elementos de
cobertura que pueden ser
contó, y donde la herramienta se puede identificar cuando una prueba de que ha ejercido la
cobertura
elemento de edad. A nivel de las pruebas de componentes, los elementos de cobertura podrían
ser líneas de código
o instrucciones de código o los resultados de decisiones (por ejemplo, la salida Verdadero o
Falso de un SI
declaración). En el nivel de integración de componentes, el elemento de cobertura puede ser
una llamada a
una función o módulo. Aunque la cobertura se puede medir en el sistema o aceptación
ANCE niveles de prueba, por ejemplo, cuando el elemento de cobertura pueden ser una
declaración requisito
ción, no hay muchos (si lo hay) herramientas comerciales a este nivel; hay más
herramienta de apoyo a nivel de las pruebas de componentes o en cierta medida al
componente de inte-
gración nivel.
El proceso de identificación de los elementos de cobertura a nivel de prueba de componentes
es
llamado "instrumentar el código ', tal como se describe en el capítulo 4. Un conjunto de
pruebas se
a continuación, ejecute a través del código instrumentado, usando ya sea automáticamente
una prueba de eje-
cution herramienta o manualmente. La herramienta de cobertura a continuación, cuenta el
número de cobertura
Los artículos que han sido ejecutadas por el banco de pruebas, e informa del porcentaje de
elementos de cobertura que se han ejercido, y también puede identificar los elementos que
todavía no se han ejercido (es decir, aún no probado). Las pruebas adicionales pueden ser
ejecutadas
para aumentar la cobertura (la herramienta de informes de cobertura acumulada de todas las
pruebas se ejecutan
hasta aquí).
Las herramientas más sofisticadas de cobertura pueden proporcionar apoyo para ayudar a
iden-
tificar las entradas de prueba que ejercerá las rutas que incluyen, que aún no ejercidas
elementos de cobertura (o enlace a una herramienta de diseño de prueba para identificar la
no ejercidas
artículos). Por ejemplo, si no todos los resultados de las decisiones se han ejercido, el
herramienta de cobertura puede identificar el resultado particular de decisiones (por ejemplo,
una salida falsa
a partir de una instrucción IF) que ninguna prueba ha tenido hasta ahora, y puede entonces
también ser capaz
para calcular la entrada de prueba requerida para forzar la ejecución de tomar esa decisión
resultado.
Rasgos o características de las herramientas de medición de cobertura incluyen soporte
para:
• Identificación de los elementos de cobertura (instrumentar el código);
• calcular el porcentaje de elementos de cobertura que se ejerce por un conjunto de
pruebas; '
• Los elementos de cobertura de los informes que no se han ejercido hasta el momento;
• la identificación de entradas de prueba para ejercer artículos que aún no cubiertas
(herramienta de diseño de la prueba
funcionalidad);
• Talones de generadores y conductores (si es parte de un marco de prueba de unidad).
Tenga en cuenta que las herramientas de cobertura sólo miden la cobertura de los elementos
que
se pueden identificar. El hecho de que las pruebas han logrado declaración de 100% cobertura
la edad, esto no significa que su software ha sido probado 100%!
herramientas de seguridad
Hay una serie de herramientas que se protejan los sistemas de ataque externo, por
ejemplo cortafuegos, que son importantes para cualquier sistema.
Herramientas de pruebas de seguridad se pueden utilizar para probar la seguridad al
tratar de entrar en una
sistema, si está o no está protegido por una herramienta de seguridad. Los ataques pueden
centrarse
página 182
en la red, el software de soporte, el código de la aplicación o el subyacente
base de datos.
Funciones o características de las herramientas de pruebas de seguridad incluyen soporte
para:
• la identificación de los virus;
• detección de intrusiones, tales como ataques de denegación de servicio;
• simular diferentes tipos de ataques externos;
• el sondeo de puertos abiertos u otros puntos externamente visibles de ataque;
• identificar las debilidades en los archivos de contraseñas y contraseñas;
• controles de seguridad durante el funcionamiento, por ejemplo, para comprobar la
integridad de los archivos, y
detección de intrusos, por ejemplo, comprobación de los resultados de los ataques de prueba.
6.1.6 Herramienta de apoyo para el funcionamiento y la supervisión
Las herramientas descritas en esta prueba el apoyo sección que se pueden llevar a cabo en
una
sistema cuando está en funcionamiento, es decir, mientras se está ejecutando. Esto puede ser
durante la prueba
o podría ser después de un sistema se libera en el modo Live.
Las herramientas de análisis dinámico (D)
Las herramientas de análisis dinámicos son "dinámico", ya que requieren que el código
sea
corriendo. Son "análisis" en lugar de herramientas de 'prueba' porque analizan lo
que está pasando "entre bastidores", mientras que el software está en ejecución (ya sea siendo
ejecutado con casos de prueba o de ser utilizado en la operación).
Una analogía con un coche puede ser útil en este caso. Si usted va a mirar un coche para
comprar,
podría sentarse en ella para ver si es cómodo y ver lo que suenan las puertas hacen - esto
sería el análisis estático porque el coche no está siendo impulsada. Si se toma una prueba de
conducción,
entonces sería comprobar que el coche lleva a cabo como se esperaba (por ejemplo, gira a la
derecha cuando se
girar el volante hacia la derecha de la rueda) - esto sería una prueba. Mientras que el coche
está en marcha,
si se va a comprobar el nivel de aceite o el líquido de frenos, esto sería lisis dinámico
sis - que sólo se puede hacer mientras el motor está en marcha, pero no es un caso de prueba.
Cuando el tiempo de respuesta de su PC se ralentiza y más lento con el tiempo, pero es mucho
mejoró después de volver a arrancar, esto también puede deberse a una "pérdida de memoria",
donde
los programas no liberan correctamente bloques de memoria de nuevo a la operación
sistema. Finalmente, el sistema funcionará sin memoria por completo y se detendrá. Re-
restaura el arranque de toda la memoria que se había perdido, por lo que el rendimiento de la
sistema se ha restaurado a su estado normal.
Rasgos o características de las herramientas de análisis dinámicos incluyen soporte para:
• la detección de fugas de memoria;
• la identificación de puntero errores aritméticos tales como punteros nulos;
• la identificación de dependencias de tiempo.
Estas herramientas normalmente serían utilizados por los desarrolladores en la prueba de
componentes y
las pruebas de integración de componentes, por ejemplo, al probar el middleware, cuando las
pruebas
de seguridad o en la búsqueda de defectos de robustez.
Otra forma de análisis dinámico para sitios web es comprobar si cada enlace
¿Se comunica efectivamente a otra cosa (este tipo de herramienta puede ser llamado un "Web
araña'). La herramienta no sabe si se ha vinculado a la página correcta, pero al
menos se puede encontrar enlaces muertos, que pueden ser útiles.
página 183
El rendimiento de pruebas, pruebas de carga y herramientas de pruebas de estrés
Actuación-
herramientas de prueba tienen que ver con las pruebas a nivel de sistema para ver si es o
no
el sistema hará frente a un gran volumen de uso. A prueba de carga '' cheques que
el sistema puede hacer frente a su número esperado de transacciones. Un "volumen"
prueba comprueba que el sistema puede hacer frente a una gran cantidad de datos, por
ejemplo, muchos
campos de un registro, muchos registros en un archivo, etc. Una prueba de "estrés" es uno
que va
más allá del uso normal esperado del sistema (para ver lo que sucedería
fuera de sus expectativas de diseño), con respecto a la carga o el volumen.
En las pruebas de rendimiento, muchas entradas de prueba pueden ser enviados en el software
o
sistema en el que los resultados individuales no puedan ser controlados con detalle. El
propósito
de la prueba es medir características, como los tiempos de respuesta, rendimiento o
el tiempo medio entre fallos (para las pruebas de fiabilidad).
Con el fin de evaluar el rendimiento, la herramienta tiene que generar algún tipo de
la actividad en el sistema, y esto se puede hacer de diferentes maneras. En una muy simple
nivelar la misma transacción podría repetirse muchas veces, pero esto no es realis-
tic. Hay muchos niveles de realismo que se podrían establecer, en función de la herramienta,
tales como diferentes perfiles de usuario, diferentes tipos de actividades, retrasos y
temporización
otros parámetros. Adecuadamente la replicación de los entornos de usuario final o usuario
perfiles suele ser clave para obtener resultados realistas.
El análisis de la salida de una herramienta de pruebas de rendimiento no es siempre
sencillo y que requiere tiempo y experiencia. Si el rendimiento es
no hasta el nivel que se espera, a continuación, algunos análisis debe realizarse
para ver dónde está el problema y saber qué se puede hacer para mejorar la
actuación.
Rasgos o características de las herramientas de pruebas de rendimiento incluyen soporte
para:
• la generación de una carga en el sistema a ensayar;
• la medición de la temporización de las operaciones específicas como la carga en el sistema
de
varía;
• la medición de tiempos medios de respuesta;
• la producción de gráficos o tablas de respuestas en el tiempo.
Las herramientas de monitoreo
Las herramientas de monitoreo se utilizan para el seguimiento continuo del estado del
sistema
en uso, con el fin de tener la advertencia más temprana de problemas y para mejorar el
servicio.
Hay herramientas de monitoreo para servidores, redes, bases de datos, seguridad, desempeño
Ance, sitio web y el uso de Internet y aplicaciones.
Rasgos o características de las herramientas de supervisión incluyen soporte para:
• la identificación de problemas y el envío de un mensaje de alerta al administrador (por
ejemplo,
administrador de red);
• Inicio de sesión en tiempo real e información histórica;
• encontrar los valores óptimos;
• controlar el número de usuarios en una red;
• El tráfico de red de monitoreo (ya sea en tiempo real o que cubre una longitud dada de
momento de la operación con el análisis realizado después).
página 184
6.1.7 Herramienta de apoyo para las áreas específicas de la aplicación (KL)
En este capítulo, hemos descrito las herramientas de acuerdo a su funcionalidad en general
clasificaciones. También hay otras especializaciones de herramientas dentro de estas cla-
clasifi-. Por ejemplo, hay herramientas de pruebas de rendimiento basados en la web, así
como herramientas de pruebas de rendimiento para los sistemas de back-office. Hay análisis
estático
herramientas para las plataformas de desarrollo y lenguajes de programación específicos,
desde
cada lenguaje de programación y cada plataforma tiene características distintas.
Hay herramientas de análisis dinámicos que se centran en temas de seguridad, así como
Las herramientas de análisis dinámicos para sistemas embebidos.
juegos de herramientas comerciales podrán agruparse para áreas de aplicación específicas,
tales como
o sistemas integrados basados en web.
6.1.8 Herramienta de apoyo utilizando otras herramientas
Las herramientas descritas en este capítulo no son las únicas herramientas que un aparato
puede hacer
uso de. Normalmente, no puede pensar en un procesador de textos o una hoja de cálculo
como una
herramienta de prueba, pero a menudo se utilizan para almacenar los diseños de prueba,
scripts de prueba o datos de prueba.
Testers pueden también utilizar SQL para configurar y consultar bases de datos que contiene
los datos de prueba.
Las herramientas utilizadas por los desarrolladores cuando la depuración, para ayudar a
localizar defectos y comprobar
sus correcciones, también están probando herramientas.
Los desarrolladores utilizan herramientas de depuración al identificar y corregir
defectos. los
herramientas de depuración les permiten ejecutar pruebas individuales y localizados para
asegurar que
se han identificado correctamente la causa de un defecto y para confirmar que su
cambiar el código de hecho va a corregir el defecto.
Es una buena idea para buscar en cualquier tipo de herramienta a su disposición formas que
podría
ser utilizado para ayudar a apoyar cualquiera de las actividades de prueba. Por ejemplo, los
testers pueden utilizar
scripts de Perl para ayudar a comparar los resultados de las pruebas.
6.2 uso efectivo de herramientas: POTENCIAL
Beneficios y riesgos
1 un resumen de los beneficios y riesgos potenciales de la prueba
la automatización y la herramienta
apoyo para la prueba. (K2)
2 Reconocer que las herramientas de ejecución de pruebas pueden tener diferentes
scripting tecnología
técnicas, incluyendo impulsado por los datos y basado en palabras clave. (KL)
La razón de la adquisición de herramientas para apoyar la prueba es para obtener beneficios,
mediante el uso de una
programa de software para hacer ciertas tareas que son mejor realizadas por un equipo de
por una persona.
Indicaciones para la introducción de herramientas en una organización se puede encontrar en
la web arti-
culos, revistas y libros, tales como [Dustin et al., 1999], [Siteur, 2005] y
[Fewster y Graham, 1999].
página 185
6.2.1 Los beneficios potenciales de la utilización de herramientas
Hay muchos beneficios que se pueden obtener mediante el uso de herramientas para apoyar
la prueba,
cualquiera que sea el tipo específico de herramienta. Los beneficios incluyen:
• Reducción del trabajo repetitivo;
• una mayor coherencia y capacidad de repetición;
• evaluación objetiva;
• facilidad de acceso a la información sobre las pruebas o ensayos.
El trabajo repetitivo es tedioso que hacer manualmente. La gente se aburre y
cometer errores al hacer la misma tarea una y otra vez. Ejemplos de este
tipo de trabajo repetitivo incluyen la ejecución de pruebas de regresión, entrando en la misma
datos de prueba una y otra vez (ambos de los cuales se pueden hacer por una ejecución de la
prueba
la herramienta), la comprobación contra los estándares de codificación (que puede ser
realizado por un análi- estático
herramienta sis) o la creación de una base de datos de ensayo específico (que puede ser
realizado por un datos de prueba
y herramientas).
La gente tiende a hacer la misma tarea de una manera ligeramente diferente, incluso cuando
piensan que están repitiendo algo exactamente. Una herramienta será exactamente reproducir
lo
lo hizo antes, por lo que cada vez que se ejecuta el resultado es consistente. Ejemplos de
dónde
este aspecto es beneficioso incluir la comprobación para confirmar la exactitud de una
solución de
un defecto (que puede ser realizado por una herramienta de herramienta de depuración o
ejecución de la prueba), Enterprise
ING entradas de prueba (que se pueden hacer con una herramienta de ejecución de la prueba)
y de generación
pruebas de requisitos (que se pueden hacer con una herramienta de diseño de la prueba o,
posiblemente,
una herramienta de gestión de requisitos).
Si una persona calcula un valor a partir de los informes de incidentes o de software, que
puede
sin querer omitir algo, o sus propios prejuicios subjetivos pueden conducirlos
para interpretar esos datos de forma incorrecta. Utilizando una herramienta significa que el
sesgo es subjetiva
retiró y la evaluación es más repetible y calculado de forma coherente.
Los ejemplos incluyen la evaluación de la complejidad ciclomática o niveles de imbricación
de una
componente (que puede ser realizado por una herramienta de análisis estático), la cobertura
(cobertura
herramienta de medición), el comportamiento del sistema (herramientas de monitoreo) y las
estadísticas de incidentes
(Herramienta de gestión de pruebas).
Tener gran cantidad de datos no significa que la información se comunica.
La información presentada visualmente es mucho más fácil para la mente humana para tomar
en
e interpretar. Por ejemplo, una tabla o gráfica es una mejor manera de mostrar información
ción de una larga lista de números - esta es la razón por tablas y gráficos de cálculo en
sábanas son tan útiles. herramientas especiales dan estas funciones directamente para la
información que procesan. Los ejemplos incluyen estadísticas y gráficos sobre la prueba
el progreso (ejecución de la prueba o de la herramienta de gestión de pruebas), las tasas de
incidencia (incidente
herramienta de gestión o administración de pruebas) y rendimiento (performance
herramienta de prueba).
Además de estos beneficios generales, cada tipo de herramienta tiene beneficios específicos
en relación con el aspecto de las pruebas que soporta la herramienta particular. estos
beneficios
son normalmente un lugar destacado en la información disponible para la venta
tipo de herramienta. Vale la pena investigar una serie de diferentes herramientas para
conseguir un general
Habida cuenta de los beneficios.
página 186
6.2.2 Los riesgos de usar herramientas
Aunque hay ventajas significativas que se pueden alcanzar utilizando herramientas para
las actividades de prueba de apoyo, hay muchas organizaciones que no han alcanzado
los beneficios que esperaban.
La simple compra de una herramienta no es garantía de beneficios que alcanzan, al igual que
la compra
membresía en un gimnasio no garantiza que usted estará más en forma. Cada tipo de
herramienta requiere una inversión de tiempo y esfuerzo para lograr el potencial
beneficios.
Hay muchos riesgos que están presentes cuando el apoyo de herramientas para la prueba es
intro-
producida y utilizada, sea cual sea el tipo específico de herramienta. Los riesgos incluyen:
• expectativas poco realistas de la herramienta;
• subestimar el tiempo, costo y esfuerzo para la introducción inicial de una
herramienta;
• subestimar el tiempo y el esfuerzo necesarios para lograr significativa y en contra
conti- se beneficia de la herramienta;
• subestimar el esfuerzo necesario para mantener los activos de prueba generados por
la herramienta;
• exceso de confianza en la herramienta.
Las expectativas poco realistas pueden ser uno de los mayores riesgos para el éxito con
herramientas. Las herramientas son solamente software y todos sabemos que hay muchos
problemas
con cualquier tipo de software! Es importante tener claros los objetivos para lo que el
herramienta se puede hacer y que esos objetivos son realistas.
La introducción de algo nuevo en una organización rara vez es sencillo.
Después de haber comprado un instrumento, tendrá que pasar de la apertura de la caja para
tener
un número de personas que son capaces de utilizar la herramienta de una manera que traerá
beneficios.
Habrá problemas técnicos que superar, pero también habrá resistencia
de otras personas - tanto deben ser abordados con el fin de tener éxito en la introducción
ing una herramienta.
Piense en la última vez que hiciste algo nuevo por primera vez
(Aprender a conducir, andar en bicicleta, esquiar). Sus primeros intentos fueron poco
probable que sea
muy bueno, pero con más experiencia que llegó a ser mucho mejor. Usando una prueba
herramienta por primera vez no va a ser su mejor uso de la herramienta, ya sea. Toma tiempo
para desarrollar formas de utilización de la herramienta con el fin de lograr lo que es posible.
Afortunadamente, hay algunos atajos (por ejemplo, libros y artículos sobre la lectura
Otras experiencias y aprender de ellos de la gente). Véase también la sección 6.3 para
más detalles sobre la introducción de una herramienta en una organización.
una planificación insuficiente para el mantenimiento de los activos que la herramienta pro-
duce es un fuerte contribuyente a las herramientas que terminan como "plataforma-ware ', a
lo largo de
con los riesgos anteriormente mencionados. Aunque particularmente relevante para la prueba
de eje-
herramientas cution, la planificación de mantenimiento es también un factor con otros tipos
de
herramienta.
Las herramientas no son definitivamente la magia! Ellos pueden hacer muy bien lo que han
sido
diseñados para hacer (por lo menos una herramienta de buena calidad puede), pero no pueden
hacerlo todo.
Una herramienta sin duda puede ayudar, pero no sustituir a la inteligencia necesaria para
saber la mejor manera de usarlo, y cómo evaluar los usos actuales y futuras de la herramienta.
Por ejemplo, una herramienta de ejecución de la prueba no reemplaza la necesidad de una
buena prueba
diseño y no debe ser utilizado para todas las pruebas - algunas pruebas son aún mejores
página 187
ejecutado manualmente. Una prueba que toma un tiempo muy largo para automatizar y no lo
hará
ejecutarse muy a menudo es mejor hacer manualmente.
Esta lista de riesgos no es exhaustiva. Otros dos factores importantes son:
• la habilidad necesaria para crear buenas pruebas;
• la habilidad necesaria para utilizar las herramientas bien, dependiendo del tipo de
herramienta.
Las habilidades de un tester no son las mismas que las habilidades del usuario de la
herramienta. El tester
se concentra en lo que debe ser probado, ¿cuáles deberían ser los casos de prueba y cómo
para dar prioridad a la prueba. El usuario de la herramienta se concentra en la mejor manera
de conseguir la herramienta
para hacer su trabajo con eficacia y cómo dar el aumento de los beneficios del uso de la
herramienta.
6.2.3 Consideraciones especiales para algunos tipos de herramientas
herramientas de ejecución de pruebas
A '/ herramienta de reproducción de captura "es un término engañoso, aunque es de uso
común.
Captura / reproducción es un modo de utilizar una herramienta de ejecución de la prueba y
probablemente el
peor manera de usarlo!
Con el fin de saber lo que pone a prueba a ejecutar y cómo ejecutar ellos, la ejecución de
pruebas
la herramienta debe tener alguna forma de saber qué hacer - este es el guión de la
herramienta. Pero puesto que la herramienta es único software, el guión debe ser exacta y
inequívoca al ordenador (que no tiene sentido común). Esto significa que
el guión se convierte en un programa, escrito en un lenguaje de programación. el Script
idioma ing puede ser específica para una herramienta particular, o puede ser una más general
idioma. Los lenguajes de script no se utilizan solo por las herramientas de ejecución de
pruebas, pero la
scripts utilizados por la herramienta se almacenan electrónicamente a ser ejecutado cuando
las pruebas son
ejecutado bajo el control de la herramienta.
Existen herramientas que pueden generar secuencias de comandos mediante la identificación
de lo que está en la pantalla
en lugar de mediante la captura de una prueba manual, pero todavía generar secuencias de
comandos para ser utilizado
en la ejecución; ellos no están libres de la escritura.
Hay diferentes niveles de secuencias de comandos. Cinco se describen en [Fewster y
Graham, 1999]:
• guiones lineales (que podrían ser creadas manualmente o se capturan mediante el registro
de una
prueba manual);
• guías estructuradas (mediante selección y estructuras de programación de iteración);
• guiones compartidos (donde una secuencia de comandos puede ser llamado por otros
sistemas de escritura por lo que puede ser re-utilizados
- Guiones compartidos también requieren una biblioteca de scripts de configuración formal
en virtud del hombre
gestión);
• guiones basados en datos (cuando los datos de prueba está en un archivo o una hoja de
cálculo para ser leídos por
una secuencia de comandos de control);
• secuencias de comandos basado en palabras clave (donde se almacena toda la
información acerca de la prueba
en un archivo o una hoja de cálculo, con una serie de secuencias de comandos de control que
poner en práctica el
pruebas que se describen en el archivo).
La captura de una prueba manual parece ser una buena idea para empezar, sobre todo si
actualmente se está ejecutando pruebas manualmente de todos modos. Pero una prueba
capturado (a lineal
guión) no es una buena solución, por una serie de razones, incluyendo:
• La secuencia de comandos no sabe cuál es el resultado esperado es hasta que se programa
en -
que sólo almacena entradas que se han registrado, no se ponen a prueba los casos.
página 188
• Un pequeño cambio en el software puede invalidar docenas o cientos de guiones.
• El guión grabado sólo puede hacer frente a exactamente las mismas condiciones que cuando
que fue grabado. Los acontecimientos inesperados (por ejemplo, un archivo que ya existe)
no serán
interpretado correctamente por la herramienta.
Sin embargo, hay algunos momentos en los que la captura de entradas de prueba (es decir
grabación
ing una prueba manual) es útil. Por ejemplo, si usted está haciendo exploratoria
prueba o si va a ejecutar pruebas sin guión con negocios con experiencia
usuarios, que pueden ser muy útiles simplemente para registrar todo lo que se hace, como
una
pista de auditoría. Esto sirve como una forma de documentación de lo que se probó
(Aunque el análisis puede que no sea fácil). Esta pista de auditoría también puede ser muy
útil si se produce un fallo que no puede ser reproducido fácilmente - la grabación
de la falla específica se puede jugar a la promotora para ver exactamente lo
secuencia de la causa del problema.
entradas de prueba capturados pueden ser útiles en el corto plazo, donde el contexto
permanece válido. Sólo que no espere para jugar de nuevo como pruebas de regresión
(cuando el
contexto de la prueba puede ser diferente). pruebas capturados pueden ser aceptables para
unos pocos
docena de pruebas, donde el esfuerzo para actualizarlos cuando no son los cambios de
software
muy grande. No hay que esperar un enfoque lineal-scripting para escalar a cientos o
miles de pruebas.
Así que la captura de pruebas tiene un lugar, pero no es un lugar grande en términos de
automatizar la ejecución de pruebas.
secuencias de comandos por datos permiten que los datos, es decir, las entradas de prueba y
espera fuera
viene, para ser almacenados por separado de la secuencia de comandos. Esto tiene la ventaja
de que una
tester que no sabe cómo utilizar un lenguaje de script puede rellenar un archivo o
hoja de cálculo con los datos de una prueba específica. Esto es particularmente útil cuando
hay un gran número de valores de datos que necesitan ser probados utilizando la misma
script de control.
secuencias de comandos basado en palabras clave incluyen no sólo datos, sino también las
palabras clave en los datos
presentar u hoja de cálculo. Esto permite un tester (que no es un programador de script) a
diseñar una gran variedad de pruebas (no sólo los datos de prueba de entrada a cambio de las
misma prueba, al igual que en los scripts basados en datos). El tester necesita saber qué
palabras clave
están disponibles en la actualidad para usar (por alguien haber escrito un guión para él) y
los datos que la palabra clave se esperaba, pero el tester puede entonces escribir pruebas, no
sólo
datos de prueba. El tester también puede solicitar palabras clave adicionales para ser añadido
a la
disponible programado que conjunto de scripts según sea necesario. Las palabras clave
pueden hacer frente a tanto
entradas de prueba y los resultados esperados.
Por supuesto, alguien todavía tiene que ser capaz de utilizar la herramienta directamente y
ser
capaz de programar en un lenguaje de secuencias de comandos de la herramienta con el fin
de escribir y
depurar los guiones que utilizarán las tablas de datos o tablas de palabras clave. Una pequeña
número de especialistas en automatización puede admitir un mayor número de testers,
que luego no tienen que aprender a ser programadores de secuencias de comandos (a menos
que quieran
a).
Los archivos de datos (data-driven o basado en palabras clave) incluyen los resultados
esperados
para las pruebas. Los resultados reales de cada ensayo también necesitan ser almacenados,
por lo
menos hasta que se comparan con los resultados esperados y las diferencias son
iniciado sesión.
Más información sobre el procesamiento de datos impulsado y guiado por palabra clave se
puede encontrar
en [Fewster y Graham, 1999].
página 189
herramientas de pruebas de rendimiento
Las pruebas de rendimiento se está convirtiendo en una disciplina especializada de su
propia. Con
las pruebas funcionales, los tipos de defectos que nosotros estamos buscando la funcionalidad
son -
¿El sistema o componente producir el resultado correcto para entradas dadas? En
pruebas de rendimiento, que normalmente no están preocupados por lo tanto con funcionales
corrección, pero con características de calidad no funcionales. Cuando se utiliza una persona
herramienta de prueba de rendimiento que estamos buscando en el proceso de las
transacciones, el grado
de la precisión de un cálculo dado, los recursos informáticos que se utilizan para una
dado el nivel de transacciones, el tiempo necesario para determinadas operaciones o la
número de usuarios que pueden utilizar el sistema a la vez.
Con el fin de obtener lo mejor de una herramienta de pruebas de rendimiento, es importante
entender lo que la herramienta se puede y no puede hacer por usted. Aunque esto es cierto
para
otros tipos de herramienta así, hay problemas particulares con el rendimiento de pruebas
herramientas, incluyendo:
• el diseño de la carga a ser generado por la herramienta (por ejemplo, entrada aleatoria o
de acuerdo a los perfiles de usuario);
• aspectos temporales (por ejemplo, la inserción de delaysto marca la entrada del usuario
simulado más realista);
• la duración de la prueba y qué hacer si una prueba se detiene prematuramente;
• la reducción a la ubicación de un cuello de botella;
• exactamente qué aspectos de medir (por ejemplo, nivel de interacción del usuario o de
servidor);
• la forma de presentar la información recopilada.
herramientas de análisis estático
herramientas de análisis estático son muy útiles para los desarrolladores, ya que pueden
identificar el potencial
problemas en el código antes de ejecutar el código y también pueden ayudar a comprobar
que el código se escribe en las normas de codificación.
Cuando se introduce primero una herramienta de análisis estático, no puede haber algunos
problemas.
Por ejemplo, si la herramienta comprueba el estándar de codificación actual frente a código
escrito
Hace varios años, puede haber una serie de cosas que se encuentran en el código antiguo que
no cumplen con el nuevo estándar de codificación ahora en su lugar. Si el código de edad, ha
sido
trabajando bien durante años, probablemente no es una buena idea para cambiarlo sólo para
satisfacer
el nuevo estándar de codificación (a menos que los cambios son necesarios por alguna otra
razón).
Existe el riesgo de que los cambios para cumplir con la nueva norma puede tener inadvertida
efectos secundarios que pueden no ser arrastrados por las pruebas de regresión.
herramientas de análisis estático pueden generar un gran número de mensajes, por ejemplo
encontrando la misma cosa cada pocas líneas. Esto puede ser bastante molesto, especial-
todo si las cosas que se encuentran, no se consideran importantes ahora, por ejemplo
advertencia
Ings en lugar de defectos potenciales.
El objetivo de la herramienta de análisis estático es producir código que será más fácil de
mantener en el futuro, por lo que sería una buena idea para poner en práctica más alta Stan-
nor- sobre nuevo código que todavía está siendo probado, antes de que se libera en el uso,
sino para
permitir que el código más antiguo pueda comprobarse de forma menos estricta. Todavía hay
un riesgo de que el
cambios para ajustarse a la nueva norma introducirá un lateral inesperada
efecto, pero hay una probabilidad mucho mayor de que se encontró en las pruebas y
no hay tiempo para arreglarlo antes de que el sistema se libera.
Un filtro en la salida de. la herramienta de análisis estático podría eliminar algunas de las
mensajes menos importantes y que los mensajes más importantes más probabilidades de
hacerse notar y fijo.
página 190
herramientas de gestión de pruebas
herramientas de gestión de pruebas pueden proporcionar una gran cantidad de información
útil, pero la información
CIÓN como los producidos por la herramienta no puede estar en la forma que será más eficaz
dentro de su propio contexto. Un cierto trabajo adicional puede ser necesaria para producir
interfaces con otras herramientas o una hoja de cálculo con el fin de asegurar que la
información
ción se comunica de la manera más eficaz.
Un informe producido por una herramienta de gestión de prueba (ya sea directa o
indirectamente
a través de otra herramienta u hoja de cálculo) puede ser un informe muy útil en el
momento, pero puede no ser útil en tres o seis meses. Es importante
monitorear la información producida para asegurar que es el más relevante ahora.
Es importante disponer de un procedimiento de ensayo definido antes de gestión de pruebas
se introducen herramientas. Si el proceso de prueba está funcionando bien manualmente, a
continuación, una
herramienta de gestión de pruebas puede ayudar a apoyar el proceso y hacerlo más
eficiente. Si usted adopta una herramienta de gestión de prueba cuando sus propias pruebas
procesos son inmaduros, una opción es seguir las normas y
procesos que son asumidos por la forma en que la herramienta funciona. Esto puede ser útil;
pero no es necesario seguir los procesos específicos del proveedor. El mejor
enfoque es definir sus propios procesos, teniendo en cuenta la herramienta
va a utilizar, y luego adaptar la herramienta para proporcionar el mayor beneficio para su
organización.
6.3 La introducción de una herramienta en AN
ORGANIZACIÓN
1 Estado de los principios fundamentales de la introducción de una herramienta en una
organización.
(KL)
2 Estado de los objetivos de una prueba de concepto o fase para el pilotaje
evalua herramienta
ción. (KL)
3 Reconocer que otros factores, además de simplemente la adquisición de una
herramienta son
necesario
para una buena sujeción de la herramienta. (KL)
6.3.1 Principios fundamentales
El lugar para empezar a la hora de introducir una herramienta en una organización no es con
el
herramienta - es con la organización. Para que una herramienta para proporcionar un
beneficio, debe
coincidir con una necesidad dentro de la organización, y resolver esa necesidad en una forma
que es a la vez
efectivo y eficiente. La herramienta debe ayudar a construir sobre las fortalezas de la
organización y dirección de sus debilidades. La organización tiene que estar lista
para los cambios que vendrán con la nueva herramienta. Si las prácticas actuales de prueba
No son buenos y la organización no está maduro, entonces es generalmente más rentable
efectivo para mejorar las prácticas de prueba en lugar de tratar de encontrar herramientas
para apoyar
las malas prácticas. La automatización de caos apenas da el caos más rápido!
página 191
Por supuesto, a veces podemos mejorar nuestros propios procesos en paralelo con
la introducción de un instrumento de apoyo a esas prácticas y que puede recoger un poco de
buena
ideas para la mejora de las formas en que las herramientas de trabajo. Sin embargo, tenga en
cuenta
que la herramienta no debe tomar la iniciativa, sino que debe proporcionar el apoyo a lo que
su
organización define.
Los siguientes factores son importantes en la selección de una herramienta:
• evaluación de la madurez de la organización (por ejemplo, preparación para el cambio);
• identificación de las áreas de la organización, donde el apoyo de herramientas se
ayudar a mejorar los procesos de prueba;
• evaluación de las herramientas contra requisitos claros y criterios objetivos;
• prueba de concepto para ver si el producto funciona como se desee y se encuentra con el
requisitos y objetivos definidos por ella;
• Evaluación del proveedor (formación, apoyo y otros aspectos comerciales) o
la red de apoyo de código abierto;
• la identificación y planificación de implementación interna (incluyendo entrenamiento y
tutoría para los nuevos en el uso de la herramienta).
6.3.2 Proyecto piloto
Una de las maneras de hacer una prueba de concepto es tener un proyecto piloto como la
primera
Lo hace con una nueva herramienta. Esto utilizará la herramienta en serio, pero en una escala
pequeña,
con tiempo suficiente para explorar diferentes formas de utilizar la herramienta. objetivos
se debe establecer para el piloto con el fin de evaluar si es o no el concepto es
probada, es decir, que la herramienta puede lograr lo que se necesita dentro de la orga- actual
nizacional contexto.
Un proyecto piloto de la herramienta debe esperar encontrarse con problemas - que deberían
ser
resuelto en formas que pueden ser utilizados por todo el mundo más adelante. El proyecto
piloto debería
experimentar con diferentes formas de utilizar la herramienta. Por ejemplo, los ajustes
diferentes
para una herramienta de análisis estático, diferentes informes de una herramienta de gestión
de pruebas, diferencia
técnicas de scripting y la comparación ENT durante una herramienta de ejecución de la
prueba o diferentes
los perfiles de carga para una herramienta de pruebas de rendimiento.
Los objetivos de un proyecto piloto para una nueva herramienta son:
• Para obtener más información acerca de la herramienta (más detalle, más profundidad);
• para ver cómo la herramienta encajaría con los procesos existentes o documentación, cómo
los que tendría que cambiar para trabajar bien con la herramienta y el uso de la
herramienta para optimizar los procesos existentes;
• decidir sobre las formas estándar de la utilización de la herramienta que funcione para todos
los potenciales
los usuarios (por ejemplo, las convenciones de nombres, creación de bibliotecas, que define
la modularidad,
donde se almacenarán los diferentes elementos, y la forma en que la propia herramienta serán
mantenido);
• evaluar el proyecto piloto respecto a sus objetivos (tienen los beneficios de estado
logrado a un costo razonable?).
página 192
6.3.3 Factores de éxito
El éxito no está garantizado o automática en la aplicación de una herramienta de prueba, pero
muchas organizaciones han tenido éxito. Éstos son algunos de los factores que tienen
contribuido al éxito:
• incremental de puesta en marcha (después de que el piloto) con el resto de la organización;
• la adaptación y mejora de los procesos, testware y artefactos de herramientas para obtener
el mejor
encajar y el equilibrio entre ellos y el uso de la herramienta;
• proporcionar una formación adecuada, orientación y tutoría de nuevos usuarios;
• definición y comunicación de directrices para el uso de la herramienta, en base a lo
que se ha aprendido en el piloto;
• la implementación de un mecanismo de mejora continua como herramienta de uso para
untar
a través de más de la organización;
• supervisión de la utilización de la herramienta y los beneficios alcanzados y la adaptación
de la
el uso de la herramienta para tener en cuenta lo que se aprende.
Más información y consejos sobre la selección y herramientas de aplicación pueden ser
encontrado en [Fewster y Graham, 1999] y [Dustin et al., 1999].
página 193
Repaso Capítulo
De la Sección 6.1, ahora debería ser capaz de clasificar los diferentes tipos de pruebas
herramientas de acuerdo con las actividades del proceso de pruebas que apoyan. También
deberías
reconocer las herramientas que pueden ayudar a los desarrolladores en sus pruebas (mostrado
por '' (D)
abajo). Además de la lista de abajo, hay que reconocer que existen herramientas
que prestan apoyo a áreas específicas de aplicación y que las herramientas de uso general
también puede
se utilizará para apoyar la prueba. Las herramientas que ahora debe reconocer son:
Las herramientas que soportan la gestión de las pruebas y exámenes:
- Herramienta de gestión de pruebas;
- requisitos de la herramienta de gestión;
- Herramienta de gestión de incidencias;
- Herramienta de gestión de la configuración.
Herramientas que soportan pruebas estáticas:
- Herramienta de revisión de soporte de procesos;
- Herramienta de análisis estático (D);
- Herramienta de modelado (D).
Herramientas que soportan la especificación de prueba:
- Herramienta de diseño de la prueba;
- Herramienta de preparación de los datos de prueba.
Herramientas que apoyan la ejecución de pruebas y registro:
- Herramienta de ejecución de la prueba;
- Instrumento de prueba y un marco de prueba de la unidad de herramienta (D);
- Comparador de ensayo;
- Herramienta de medición de cobertura (D);
- Herramienta de seguridad.
Las herramientas que apoyan el desempeño y monitoreo:
- Herramienta de análisis dinámico;
- Rendimiento en las pruebas, la carga de prueba y herramienta de pruebas de tensión;
- Herramienta de monitorización.
Además de las herramientas mencionadas, usted debe conocer los términos del glosario
herramienta de depuración, conductor, efecto de sondeo y el trozo.
De la Sección 6.2, usted debe ser capaz de resumir los beneficios potenciales
y riesgos potenciales de soporte de herramientas para las pruebas en general. Usted debe
reconocer
que algunas herramientas tienen consideraciones especiales, incluyendo herramientas de
ejecución de prueba, per-
herramientas, herramientas de análisis estático y herramientas de gestión prueba de
rendimiento de pruebas de. Tú
debe conocer los términos del glosario de la prueba, la prueba de palabras clave
impulsada por datos y
lenguaje de script y reconocer estos como asociado con herramientas de ejecución de
prueba.
De la Sección 6.3, usted debe ser capaz de establecer los principios básicos de introducción
ing una herramienta en una organización (por ejemplo, la evaluación de madurez de la
organización, clara
requisitos y criterios objetivos, la prueba de concepto, evaluación de proveedores,
orientación y tutoría). Usted debe ser capaz de indicar los objetivos de una prueba-de-
concepto o fase de pilotaje para la evaluación de herramientas (por ejemplo, aprenden acerca
de la herramienta, evaluar ajuste
con las prácticas actuales, decidir sobre las normas, evaluar los beneficios). Debe reco-
nocer que la simple adquisición de una herramienta no es el único factor en el logro de una
buena herramienta
página 194
apoyo; hay muchos otros factores que son importantes para el éxito (por ejemplo incremental
mental de puesta en marcha, los procesos de adaptación, capacitación y entrenamiento, el uso
de la definición
directrices, obtener experiencia y seguimiento de los beneficios). No hay finición específica
defini- para esta sección.
página 195
Pregunta 1 ¿Qué herramientas ayudan a apoyar estática
¿pruebas?
a. herramientas de análisis estático y herramientas de ejecución de pruebas.
segundo. proceso de revisión de los instrumentos de apoyo, análisis estático
herramientas e instrumentos de medición de cobertura.
do. Dinámica herramientas de análisis y herramientas de modelado.
re. proceso de revisión de los instrumentos de apoyo, análisis estático
herramientas y herramientas de modelado.
Pregunta 2 ¿Qué actividades de prueba son apoyados por
arnés de prueba o marco de pruebas unitarias herramientas?
a. Gestión de pruebas y control.
segundo. especificación de las pruebas y el diseño.
do. Ejecución de la prueba y la explotación forestal.
re. Rendimiento y la supervisión.
Pregunta 3 ¿Cuáles son los beneficios potenciales de la
el uso de herramientas en general para apoyar las pruebas?
a. Mayor calidad de código, reducción en el número
de testers necesarios, mejores objetivos para las pruebas.
segundo. Mayor repetibilidad de las pruebas, la reducción de
trabajo repetitivo, la evaluación objetiva.
do. Una mayor capacidad de respuesta de los usuarios, la reducción de
las pruebas se ejecutan, los objetivos no es necesario.
re. Mayor calidad del código, reducción de papeleo,
menos objeciones a las pruebas.
Pregunta 4 ¿Qué es un riesgo potencial en el uso de herramientas
para soportar las pruebas?
a. Las expectativas poco realistas, esperando la herramienta que se puede hacer
demasiado.
segundo. la confianza suficiente sobre la herramienta, es decir, dejar de hacer
las pruebas manuales cuando una herramienta de ejecución de la prueba tiene
ha comprado.
do. La herramienta puede detectar defectos que no están allí.
re. La herramienta se repetirá exactamente lo mismo que lo hizo
la vez anterior.
Pregunta 5 ¿Cuál de las siguientes son avanzados
técnicas de scripting para herramientas de ejecución de pruebas?
a. Impulsado por los datos y basado en palabras clave
segundo. Basada en datos y la captura impulsada
do. Captura de guiado y de ojo de cerradura impulsada
re. Reproducción impulsado y guiado por palabra clave
Pregunta 6 ¿Cuál de los siguientes no sería
realizado como parte de la selección de una herramienta para una organización?
a. Evaluar la madurez de la organización, los puntos fuertes y
debilidades.
segundo. Estirar la herramienta a tantos usuarios como sea posible
dentro de la organización.
do. Evaluar las características de la herramienta contra la clara
requisitos y criterios objetivos.
re. Identificar los requisitos internos para los entrenamientos y
tutoría en el uso de la herramienta.
Pregunta 7 ¿Cuál de los siguientes es un objetivo para una
prueba de concepto o fase piloto para la evaluación de herramientas?
a. Decidir qué herramienta para adquirir.
segundo. Decidir sobre los objetivos y requisitos principales
para este tipo de herramienta.
do. Evaluar el vendedor herramienta incluida la formación,
apoyo y aspectos comerciales.
re. Decidir sobre los procedimientos estándar para el uso, manejo,
almacenar y mantener la herramienta y la prueba
bienes.
página 196
examen de prueba
En el examen real, usted tendrá 60 minutos para trabajar a través de 40 preguntas
aproximadamente la misma mezcla de dificultad y distribución Syllabus como se muestra en
la siguiente
examen de prueba. Después de haber tomado este examen de prueba, verifique sus respuestas
con la respuesta
llave.
Pregunta 1 ¿Qué es una clave
característica de la especificación basada en
técnicas de prueba?
a. Las pruebas se derivan de información sobre
cómo se construye el software.
segundo. Las pruebas se derivan de modelos (formal o
informal) que especifican el problema de ser
resuelto por
el software o sus componentes.
do. Las pruebas se derivan en base al
habilidades y
experiencia del tester.
re. Las pruebas se derivan de la extensión de la
cobertura
de los elementos estructurales del sistema o
componentes.
Pregunta 2 Un conjunto de pruebas exhaustivas haría
incluir:
a. Todas las combinaciones de valores de entrada
y las condiciones previas.
segundo. Todas las combinaciones de valores de entrada y
valores de salida.
do. Todos los pares de valor de entrada y
condiciones previas.
re. Todos los estados y las transiciones de estado.
Pregunta 3 ¿Qué afirmación acerca de las pruebas
¿es verdad?
a. La prueba se inicia tan pronto como sea posible en el
vida
ciclo.
segundo. La prueba se inició después de que el código está escrito
así que eso
tenemos un sistema con el que trabajar.
do. Las pruebas se hacen más económicamente en el
final de
el ciclo de vida.
re. Testing sólo puede ser realizado por un
prueba independiente
equipo.
Pregunta 4 Para un procedimiento de prueba que es
comprobar modificaciones de los clientes en una
base de datos, el cual dos pasos siguientes serían
la prioridad más baja si no tuvimos tiempo de
ejecutar todos los pasos?
1 Abrir la base de datos existente y confirmar
cliente
estado civil 2 Cambio de cliente a partir de
soltero a casado
nombre de la calle 3 Cambio de cliente a partir de
Parques Camino a Park Road
límite de crédito 4 Cambio de cliente a partir de 500
a 750
5 Vuelva a colocar el primer nombre del cliente
exactamente de la
mismo nombre de pila
6 Cierre el registro del cliente y cerca
el
base de datos
a. Las pruebas 1 y 4
segundo. Las pruebas 2 y 3
do. Las pruebas 5 y 6
re. Las pruebas 3 y 5
Pregunta 5 Tenga en cuenta la siguiente lista de
ya sea del producto o proyecto riesgos:
I Un cálculo incorrecto de las tasas
podría
shortchange la organización.
II Un vendedor puede fallar para entregar una
componente del sistema a tiempo.
IIIA defecto podría permitir a los hackers
obtener privilegios administrativos.
brecha de habilidades IVA podría ocurrir en un nuevo
tecnología utilizada en el sistema.
VA proceso de priorización de defectos podría
sobrecargar el equipo de desarrollo.
¿Cuál de las siguientes afirmaciones es verdadera?
a. I es principalmente un riesgo del producto y II, III, IV
yV
son sobre todo los riesgos del proyecto.
segundo. II y V son los principales riesgos de los productos y que,
III y
V son los principales riesgos del proyecto.
do. I y III son principalmente riesgos de los productos, mientras
II, IV
y V son los principales riesgos del proyecto.
re. Enfermo y V son los principales riesgos de los productos,
mientras que I, II
y IV son los principales riesgos del proyecto.
página 197
Pregunta 6 Considere las siguientes afirmaciones
acerca de las pruebas de regresión:
Me Pueden automatizarse de manera útil si están bien
diseñado.
II Ellos son los mismos que los ensayos de confirmación (re-tests).
IIIThey son una forma de reducir el riesgo de un cambio
tener un efecto adverso en otras partes del sistema.
IVThey solamente son efectivos si automatizado.
¿Qué par de afirmaciones es verdadera?
a. I y II
segundo. I y III
do. II y III
re. II y IV
Pregunta 7 ¿Cuál de las siguientes podría ser utilizado para
evaluar la cobertura alcanzada para la estructura a base de
(caja blanca) técnicas de prueba?
los resultados V decisión que se ejerce
Particiones W ejercidas
Los límites X ejercidas
Y Condiciones o varias condiciones de ejercerse
Declaraciones Z ejercidas
a. V, Wory
segundo. WXorY
do. V, YorZ
re. W, XorZ
Pregunta 8 de la opinión de la parte siguiente de una
reporte de incidente.
1 coloco cualquier artículo en la cesta de la compra.
2 Pongo toda otra (diferente) itemin la cesta de la compra.
3 elimino el primer elemento de la cesta de la compra, pero
dejar el segundo elemento de la compra.
4 hago clic en el botón <Pedido>.
5 Yo esperaba que el sistema muestre el primer pago y envío
pantalla. En su lugar, nos muestra un mensaje de error emergente,
'No hay artículos en el carrito. Haga clic en <Ok> para
seguir comprando.'
6 hago clic en <Ok>.
7 espero que el sistema para volver a la ventana principal
que me permitirá continuar con la adición y eliminación
artículos de la cesta. En lugar de ello, el navegador
termina.
8 El fracaso se describe en los pasos 5 y 7 se produjo en
cada uno de tres intentos para llevar a cabo los pasos 1,2,3,4
y 6.
Asumir que ninguna otra información narrativa es
incluida en el informe. Cuál de los siguientes
aspectos importantes de un informe de incidente es buena
falta de este informe de incidente?
a. Los pasos para reproducir el fallo.
segundo. El resumen.
do. La comprobación de la intermitencia.
re. El uso de un tono de objetivo.
Pregunta 9 ¿Cuál de los siguientes son los beneficios y
los cuales son los riesgos de usar herramientas para apoyar las pruebas?
1 La excesiva dependencia de la herramienta
2 Una mayor coherencia y repetibilidad
3 La evaluación objetiva
4 Las expectativas poco realistas
5 La subestimación del esfuerzo necesario para mantener
los activos de prueba generados por la herramienta
6 La facilidad de acceso a la información sobre los ensayos o pruebas
7 El trabajo repetitivo se reduce
a. Beneficios: 3,4,6 y 7. Riesgos: 1,2 y 5
segundo. Beneficios: 1,2,3 y 7, Riesgos: 4,5 y 6
do. Beneficios: 2,3,6 y 7. Riesgos: 1,4 y 5
re. Beneficios: 2,3,5 y 6. Riesgos: 1,4 y 7
Pregunta 10 ¿Cuál de los siguientes anima
pruebas objetivas?
a. prueba de la unidad
segundo. Las pruebas del sistema
do. Las pruebas independientes
re. Pruebas destructivas
Pregunta 11 De las siguientes afirmaciones acerca
opiniones de especificaciones, que afirmación es cierta?
a. Los comentarios no son generalmente rentables como el
reuniones consumen mucho tiempo y requieren
preparación y seguimiento.
segundo. Thereisnoneed toprepare Foror followuponreviews.
do. Los comentarios deben ser controladas por el autor.
re. Los comentarios son una prueba estática temprana eficaz en el coste
sistema.
página 198
Pregunta 12 Considere la siguiente lista de
las actividades del proceso de prueba:
Análisis y diseño I
las actividades de cierre de prueba II
IIIEvaluating criterios de salida y
la presentación de informes
IVPlanning y control
V Aplicación y ejecución
¿Cuál de los siguientes lugares en estos
su secuencia lógica?
a. I, II, III, IV y V
segundo. IV, I, V, III y II.
do. IV, I, V, II y III.
re. I, IV, V HI y II.
Pregunta 13 objetivos de prueba pueden variar entre
proyectos y por lo tanto debe ser declarado en la prueba
plan. ¿Cuál de las siguientes pruebas
objetivos pueden entrar en conflicto con el buen
mentalidad tester?
a. Demostrar que el sistema funciona, antes de
envíalo.
segundo. Encontrar el mayor número posible de defectos.
do. Reducir el nivel general de riesgo del producto.
re. Prevenir los defectos hasta principios de
participación.
Pregunta 14 actividades de prueba que son
con el apoyo de herramientas de preparación de los datos de prueba?
a. gestión y control de prueba
segundo. especificación de las pruebas y el diseño
do. Ejecución de la prueba y la explotación forestal
re. Rendimiento y monitorización
Pregunta 15 Si usted está volando con una
billete de economía, hay una posibilidad de que
usted puede conseguir ascendieron a la clase ejecutiva,
especialmente si usted tiene una tarjeta de oro en el
programa de viajero frecuente de la aerolínea. Si tu
no estén en posesión de una tarjeta de oro, hay una posibilidad
que usted conseguirá 'golpeado' fuera de la línea aérea si esto
está lleno y te registras tarde. Esto se muestra
en la Figura 7.1. Tenga en cuenta que cada caja (es decir,
declaración) ha sido numerada.
Tres ensayos ya han llevado a cabo:
Prueba 1: titular de la tarjeta de oro que se ve mejorada
a
clase de negocios
Prueba 2: titular de la tarjeta no de oro que se aloja en
economía
Prueba 3: Una persona que recibe un golpe desde el
vuelo
¿Qué pruebas adicionales serían necesarios para
lograr una cobertura de decisión 100%?
a. Un titular de la tarjeta de oro que se queda en la economía
y una
titular de la tarjeta no de oro que se ve mejorada
a
clase de negocios.
segundo. Un titular de la tarjeta de oro y una tarjeta que no sea de oro
poseedor
que se actualizan tanto a la clase ejecutiva.
do. Un titular de la tarjeta de oro y una tarjeta que no sea de oro
poseedor
que tanto se quedan en clase económica.
re. Un titular de la tarjeta de oro que se actualiza a
negocio
clase y un soporte de la tarjeta ni oro que
estancias en
clase de economia.
Pregunta 16 Considere los siguientes tipos
de herramientas:
Gestión de pruebas V
herramientas
W herramientas de análisis estático
X herramientas de modelado
Las herramientas de análisis dinámico Y.
herramientas de pruebas de rendimiento Z
Cuál de los siguientes de estas herramientas es la mayor
susceptibles de ser utilizados por los desarrolladores?
a. W, Xandy
segundo. VYandZ
do. V, WandZ
re. X, YandZ
página 199
Pregunta 17 ¿Qué es una condición de la prueba?
a. Una entrada, el resultado esperado,
condición previa y
postcondition
segundo. Los pasos a seguir para obtener el sistema a una
punto dado
do. Algo que puede ser probado
re. Un estado específico del software, por ejemplo,
antes de una prueba
se puede ejecutar
Pregunta 18 ¿Cuál de las siguientes es la
más importante diferencia entre el metrics-
y enfoque basado en el enfoque basado en experto
para poner a prueba la estimación de?
a. El enfoque basado en la métrica es más
preciso
que el enfoque basado en el experto.
segundo. Los usos de aproximación basada en métricas
cálculos
a partir de datos históricos mientras que el experto-
basado
enfoque se basa en la sabiduría del equipo.
do. El enfoque basado en la métrica se puede utilizar
para verificar
una estimación creado usando el experto-
basado
enfoque, pero no viceversa.
re. El enfoque basado en el experto lleva más tiempo
que la
basada en métricas de enfoque.
Pregunta 19 Si la temperatura cae
por debajo de los 18 grados, la calefacción se desconecta
en. Cuando la temperatura alcanza 21
grados, la calefacción se desconecta. Qué
se establece el mínimo de los valores de entrada de prueba para
cubrir todas las particiones de equivalencia válidos?
a. 15,19 y 25 grados
segundo. 17,18,20 y 21 grados
do. 18,20 y 22 grados
re. 16 y 26 grados
Pregunta 20 ¿Cuál de estos
declaraciones acerca de las pruebas funcionales es
¿cierto?
a. Ensayos estructurales es más importante
que
pruebas funcionales, ya que aborda la
código.
segundo. Las pruebas funcionales es útil en todo el
vida
ciclo y se puede aplicar por el negocio
analistas,
testers, desarrolladores y usuarios.
do. Las pruebas funcionales es más poderoso que
pruebas estáticas
ya que en realidad ejecuta el sistema y ver lo
que sucede.
re. La inspección es una forma de pruebas funcionales.
Pregunta 21 ¿Cuál es el propósito de
pruebas de confirmación?
a.
Para confirmar la confianza de los usuarios que
el sistema
responda a sus necesidades de negocio.
segundo. Para confirmar que un defecto se ha solucionado
correctamente.
do. Para confirmar que no hay cambios inesperados
Ha estado
introducido o no cubierto, como resultado de
cambios
hecho.
re. Para confirmar que la lógica detallada de una
componente
se ajusta a su especificación.
Pregunta 22 factores de éxito que son
necesaria para una buena soporte de la herramienta dentro de una
¿organización?
a. La adquisición de la mejor herramienta y la garantía
que todos
testers utilizan.
segundo. procesos de adaptación para encajar con el uso de
la herramienta
y monitorear el uso de herramientas y beneficios.
do. El establecimiento de objetivos ambiciosos para la herramienta
beneficios y
plazos agresivos para lograrlos.
re. La adopción de prácticas de otros exitosos
organizaciones y asegurar que formas iniciales
de
el uso de la herramienta se mantienen.
Pregunta 23 ¿Cuál de los siguientes mejor
describe las pruebas de integración?
a. Pruebas realizadas para exponer fallos en
el
interfaces y en la interacción
Entre
componentes integrados.
segundo. Pruebas para verificar que un componente está listo
para
integración.
do. Pruebas para verificar que el entorno de prueba
puede ser
integrado con el producto.
re. Integración de las pruebas de software automatizado
suites con
el producto.
página 200
Pregunta 24 De acuerdo con el ISTQB
Glosario, depuración:
a. Es parte del proceso de prueba fundamental.
segundo. Incluye la reparación de la causa de una
fracaso.
do. Consiste en añadir intencionadamente conocida
defectos.
re. Sigue los pasos de un procedimiento de prueba.
Pregunta 25 ¿Cuál de las siguientes podría
ser una causa de un defecto en la financiera
software en el que un tipo de interés incorrectos
¿es calculado?
a. La insuficiencia de fondos estaban disponibles para
pagar la tasa de interés calculada.
segundo. cálculos insuficientes de compuesto
interesar
fueron incluidos.
do. Una formación insuficiente se le dio a la
desarrolladores
en relación con el cálculo del interés compuesto
reglas.
re. calculadoras inexactas se utilizaron para
calcula el
Resultados previstos.
Pregunta 26 Supongamos tarifas postales para 'luz
letras 'son:
$ 0,25 hasta el 10
gramos; $ 0.35 hasta
50 gramos; $ 0.45 hasta
a 75 gramos; $ 0.55
hasta 100 gramos.
¿Qué entradas (en gramos) de prueba sería
seleccionados mediante análisis de valores límite?
a. 0,9,19,49,50,74,75, 99,100
segundo. 10,50,75,100,250,1000
do. 0,1,10,11,50,51,75,76,100,101
re. 25,26,35,36,45,46,55,56
Pregunta 27 Considere la siguiente decisión
mesa.
Teniendo en cuenta esta tabla de decisión, lo que se espera que la
como resultado de los siguientes casos de prueba?
TCI: A 26 años de edad, por negocios, pero con
violaciónes o accidentes en su forma de conducir
grabar
TC2: Un turista de 62 años de edad con una limpia
registro de conductor
a. TCI: No suministre coche; TC2: vehículo de suministro
con
de pagar prima.
segundo. TCI: vehículo de suministro de pago de prima;
TC2:
coche de alimentación sin necesidad de pagar prima.
do. TCI: No suministre coche; TC2: vehículo de suministro
con ningún
de pagar prima.
re. TCI: vehículo de suministro de pago de prima;
TC2:
No suministrar coche.
Pregunta 28 ¿Cuál es la prueba exploratoria?
a. El proceso de anticipar o adivinar
dónde
se pueden producir defectos.
segundo. Un enfoque sistemático para identificar
específico
clases equivalentes de entrada.
do. La prueba llevada a cabo por un fletado
ingeniero.
re. diseño de la prueba concurrente, ejecución de la prueba,
prueba
la tala y el aprendizaje.
Pregunta 29 ¿Qué significa si un conjunto de
pruebas ha alcanzado una cobertura del 90% afirmación?
a. 9 de cada 10 tienen resultados de la decisión
estado
ejercido por este conjunto de pruebas.
segundo. 9 de cada 10 estados se han ejercido
por esto
conjunto de pruebas.
do. 9 de cada 10 pruebas han llevado a cabo en este
conjunto de
software.
re. 9 de cada 10 declaraciones acerca de los requisitos
el
software son correctos.
Pregunta 30 Un plan de prueba está escrito
específicamente para describir un nivel de pruebas
donde el objetivo principal es el establecimiento
página 201
confianza en el sistema. De los cuales
Lo que sigue es un nombre probable de este
¿documento?
IIICheck un elemento de prueba para detectar defectos introducidos por una
cambio
IVRecord e informe del estado de cambios para poner a prueba
artículos
a. plan de pruebas maestro
segundo. plan de pruebas del sistema
V Confirmar que cambia a un elemento de prueba fijado un defecto
¿Cuál de las siguientes afirmaciones es verdadera?
do. plan de pruebas de aceptación
re. Plan de proyecto
a. Sólo I es una tarea de gestión de configuración.
segundo. Todas son tareas de gestión de configuración.
Pregunta 31 Requisito 24.3. UN
'Asistente de franqueo' calculará la cantidad
de franqueo insuficiente para las letras y los pequeños
paquetes de hasta 1 kilogramo de peso. los
entradas son: el tipo de elemento (carta, libro o
otro paquete) y el peso en gramos.
Cuál de las siguientes ajustarse a la
contenido que debe tener un caso de prueba?
do. I, II y III son las tareas de gestión de configuración.
re. I, II y IV son las tareas de gestión de configuración.
Pregunta 35 Considere la siguiente transición de estado
diagrama.
a. Prueba de los tres tipos de artículo al poste
y tres pesos diferentes [Req 24.3]
segundo. Prueba 1: letra, 10grams, franqueo € 0,25. Prueba 2:
libro, de 500 gramos, el franqueo € 1,00. Prueba 3: paquete,
999 gramos, franqueo € 2,53 [Req 24.3]
do. Prueba 1: carta, 10 gramos a Bélgica. Prueba 2: libro
500 gramos a EE.UU.. Prueba 3: paquete, 999 gramos hasta
Sudáfrica [Req 24.3]
thisdiagram dado, que casebelowcovers de prueba
cada transición válida?
a. SS-S1-S2-S4-S1-S3-ES
re. Prueba 1: 10grams letra, Bélgica, gastos de envío € 0,25.
Prueba 2: Paquetes de 999 gramos a Sudáfrica,
gastos de envío € 2,53
segundo. SS-S1-S2-S3-S4-S3-S4-ES
do. SS-S1-S2-S4-S1-S3-S4-S1-S3-ES
re. SS-S1-S4-S2-S1-S3-ES
Pregunta 32 ¿Cuál es la mejor descripción de estática
¿análisis?
Pregunta 36 Un plan de prueba incluye lo siguiente
cláusulas entre los criterios de salida:
a. El análisis de los programas de proceso por lotes
segundo. La revisión de los planes de prueba
• La prueba del sistema continuará hasta que todos significativos
riesgos de los productos han sido cubiertos en la medida
se especifica en el documento de análisis de riesgo del producto.
do. El análisis de código de programa u otro software
artefactos
• La prueba del sistema deberá continuar hasta que no hay defectos deber-fix
permanecerá en contra de cualquier producto significativa los riesgos especí
especifican en el documento de análisis de riesgo del producto.
re. El uso de las pruebas de recuadro negro
Pregunta ejecución de la prueba 33 del sistema en un proyecto es
planeado durante ocho semanas. Después de una semana de la prueba, una
tester sugiere que el objetivo de la prueba se indica en el
plan de pruebas de "encontrar el mayor número posible de defectos
durante la prueba del sistema "podría estar más estrechamente conocido por
redirigir el esfuerzo de la prueba según la cual la prueba
¿principio?
Durante la ejecución de pruebas, el equipo de prueba detecta 430 debe-
corregir los defectos antes de su liberación y todos los defectos debe-fix son
resuelto. Después de la liberación, los clientes encuentran 212 nuevo
defectos, no se detectaron ninguno de los cuales durante la prueba.
Esto significa que sólo 67% de los defectos importantes
fueron encontrados antes de la liberación, un porcentaje que es
muy por debajo del promedio en su industria. Se le pide que
encontrar la causa de la gran cantidad de terreno
fracasos. Tenga en cuenta la siguiente lista de explicaciones:
a. Imposibilidad de pruebas exhaustivas.
segundo. Importancia de las primeras pruebas.
do. La ausencia de errores falacia.
Yo No todas las pruebas previstas para la significativa
fueron ejecutados riesgos de los productos.
re. agrupación defecto.
II La organización tiene expectativas poco realistas de
el porcentaje de defectos que las pruebas se pueden encontrar.
Pregunta 34 Tenga en cuenta las siguientes actividades que
podría estar relacionado con la gestión de configuración:
-tema de control de versiones IIIA ha dado lugar a la liberación
de una versión del software que se utilizó durante
las primeras pruebas.
Yo identificar y documentar las características de una prueba
ítem
Control II cambia a las características de una prueba
ítem
página 202
IVThe análisis de riesgos del producto no pudo
identificar todos los riesgos importantes de una
punto de vista del cliente.
V El análisis de riesgos producto no era
actualizado durante el proyecto como nueva
la información estuviera disponible.
¿Cuál de las siguientes afirmaciones indicar
los cuales son posibles explicaciones de la raíz
causa?
a. II, III y IV son posibles explicaciones,
pero yo y
V no son posibles.
segundo. Los cinco son posibles explicaciones.
do. I, IV y V son posibles explicaciones, pero
II y
III no son posibles.
re. Ill, IV y V son posibles explicaciones,
pero yo y
II no son posibles.
Pregunta 37 ¿Cuál es el más importante
factor para el buen desarrollo de
críticas?
a. Un escriba separada durante el registro
reunión
segundo. participantes capacitados y líderes de opinión
do. La disponibilidad de herramientas para apoyar la
revisión
proceso
re. Un plan de prueba revisado
Pregunta 38 Considere el siguiente
declaraciones acerca de las pruebas de mantenimiento:
Me Requiere tanto de re-test y pruebas de regresión
y
puede requerir nuevas pruebas adicionales.
II Se está haciendo pruebas para demostrar lo fácil que será
mantener
el sistema.
Iiiit es difícil alcance y, por tanto, las necesidades
cuidadoso
riesgos y análisis de impacto.
IVIT no tiene por qué hacerse en caso de emergencia
corrección de errores. ¿Cuál de las afirmaciones son
¿cierto?
a. I y III
b. I y IV
c. II y III
d. II y IV
Pregunta 39 ¿Qué dos ESPECIFICACIÓN
técnicas de ensayo basadas están más estrechamente
¿relacionados entre sí?
a. Las tablas de decisión y de transición de estados
pruebas
segundo. partición de equivalencia y el estado
transición
pruebas
do. Las tablas de decisión y valores en la frontera
análisis
re. Equivalencia de partición y
análisis de valores límite
Pregunta 40 ¿Cuál de los siguientes es
Una ventaja de las pruebas independientes?
a. testers independientes no tienen que gastar
hora
la comunicación con el equipo del proyecto.
segundo. Los programadores pueden dejar de preocuparse
la calidad
de su trabajo y enfoque en la producción
más código.
do. Los otros en un proyecto pueden presionar al
testers independientes para acelerar las pruebas
en el
al final del programa.
re. testers independientes veces cuestionan
el
supuestos detrás de los requisitos,
y diseños
implementaciones.
página 203
RESPUESTAS A MUESTREAN preguntas del examen
Esta sección contiene las respuestas y los objetivos de aprendizaje de la muestra
preguntas en cada capítulo y para el papel maqueta completa en el Capítulo 7.
Si nota cualquiera de las preguntas mal o si no estuvieras seguro de la respuesta,
entonces el objetivo de aprendizaje le indica qué parte del programa de estudios para volver
a en
Para ayudar a entender por qué la respuesta correcta es la correcta. el aprendizaje
ing objetivos se enumeran al principio de cada sección. Por ejemplo, si tienes
Pregunta 4 en el capítulo 1 equivocada, y luego ir a la Sección 1.2 y leyó el primer aprendizaje
ing objetivo. A continuación, vuelva a leer la parte del capítulo que se ocupa de ese tema.
página 204
página 205
página 206

Material

Cargado por

Copyright:

Formatos disponibles

Material

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Material

Cargado por

Copyright:

Formatos disponibles

1 Fundamentos de la prueba 1

1.1 ¿Por qué está probando necesario? 1

2 Pruebas de todo el ciclo de vida del software 35

4 Técnicas de diseño de la prueba 77

Apoyo 6 Herramienta para la prueba 169

1.1 ¿Por qué está probando NECESARIO?

Prueba Principio - La prueba es dependiente del contexto

1.1.3 Las causas de los defectos de software

Sí importan nuestros errores?

Cuando surgen defectos?

Podemos ver que el requisito 1 se implementa correctamente, comprendimos la el

Los defectos introducidos en el requisito 3 son más difíciles de tratar; construimos

Se introdujeron los defectos en el requisito 4 durante la definición de los requisitos; el

Encontrará pruebas para la economía de la información y las pruebas de control de calidad

1.1.4 Papel de las pruebas en el desarrollo de software, mantenimiento y operaciones

1.1.5 Pruebas y calidad

¿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

Si el análisis se limita al software, lo podría hacer en estos y decir,

1.1.6 ¿Cuánta prueba es suficiente?

En cambio, necesitamos un enfoque de prueba que proporciona la cantidad correcta de las

1.2 Qué es la prueba?

• La prueba ha conocido metas - evaluar si el conductor es suficientemente seguro le

1.2.2 Definición de las pruebas de software

Prueba y prueba de conducción 1.2.3 Software comparó

• Planificación y preparación - Tanto el examinador y el tester necesitan un plan de la acción

• Evaluación - El examinador y el tester debe hacer un objetivo evaluación, registrar el

De la misma manera, si nos embarcamos en la prueba de un sistema de software sin un plan

1.2.4 Cuando podemos cumplir con nuestros objetivos de la prueba?

Principio de pruebas - Las primeras pruebas

La fijación de los defectos no siempre puede ser el objetivo de la prueba o el resultado

Principio de pruebas - agrupación de defectos

1.2.5 Centrándose en defectos puede ayudar a planificar nuestras pruebas

1.2.6 Los grupos de defectos cambian con el tiempo

Principio de pruebas - paradoja de Pesticidas

1.2.7 Depuración elimina defectos

1.2.8 ¿Es el defecto del software libre?

Encontrar y corregir defectos no ayuda si el sistema integrado se puede utilizar y no

1.3 PRINCIPIOS DE PRUEBA

1 Explicar los principios fundamentales en las pruebas. (K2)

Principio 1 Las pruebas muestran Las pruebas pueden

1.4 FUNDAMENTAL proceso de prueba

1 Recordemos las actividades fundamentales de la prueba desde la planificación hasta

Estas actividades son lógicamente ordenadas, pero en un proyecto en particular, puede

• Determinar el alcance y los riesgos e identificar los objetivos de la prueba: Considerar

• Poner en práctica la política de prueba y / o la estrategia de prueba: hemos mencionado

• Determinar los recursos de prueba requeridas (por ejemplo, personas, entorno de

La gestión de cualquier actividad no se detiene con la planificación de la

1.4.3 Análisis de un ensayo y diseño

• Diseñar el entorno de configuración de prueba e identificar cualquier infraestructura

1.4.4 Prueba de la aplicación y ejecución

- Crear conjuntos de pruebas de los casos de prueba para la eficiente ejecución de la

- Implementar y verificar el medio ambiente. Nos aseguramos de que el entorno de la

- Registrar el resultado de la ejecución de la prueba y registrar las identidades y las

1.4.5 La evaluación de los criterios de salida y presentación de informes

La evaluación de los criterios de salida tiene las siguientes tareas principales:

• Compruebe los registros de las pruebas en contra de los criterios de salida

• Escribir un informe resumen de la prueba para las partes interesadas: No es suficiente

1.4.6 actividades de cierre de prueba

Prueba actividades de cierre incluyen las siguientes tareas principales: