FUNDAMENTOS DEL SOFTWARE PRUEBAS CERTIFICACIN ISTQB

Dorothy Graham
Erik van Veenendaal
Isabel Evans
Rex Negro

CONTENIDO
Agradecimientos viii Prefacio ix

1 Fundamentos de la prueba 1
1.1 Por qu est probando necesario? 1
1.2 Cul es la prueba? 11
1.3 Principios de prueba 18
1.4 proceso de prueba Fundamental 20
1.5 La psicologa de la prueba 26
Revisin del captulo 31
Examen de muestra cuestiona 32
Ejercicio: Prueba de la psicologa 33
Solucin 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
Revisin del captulo 54
Examen de muestra cuestiona 55

3 tcnicas estticas 57
3.1 Los comentarios y el proceso de prueba 57
3.2 Proceso de revisin 59
3.3 Anlisis esttico con herramientas 69
Revisin del captulo 74
Examen de muestra cuestiona 75

4 Tcnicas de diseo de la prueba 77

4.1 Identificacin de las condiciones de prueba y el diseo de casos de prueba 77
4.2 Categoras de las tcnicas de diseo de pruebas 84
4.3 Tcnicas basada en la especificacin o caja negra 87
4.4 Tcnicas basadas en la estructura o de caja blanca 105
4.5 Tcnicas basadas en la experiencia 112
4.6 Seleccin de las tcnicas de prueba 114
Repaso del captulo 117
Examen de muestra cuestiona 118
Ejercicios: tcnicas de diseo de pruebas 121
Soluciones de ejercicio 122
5 Gestin de pruebas 127
5.1 Prueba de organizacin 127
5.2 Prueba de planes, estimaciones y estrategias 132
5.3 Prueba de control del progreso y el control 142
5.4 Gestin de la configuracin 148
5.5 Riesgos y pruebas 149
5.6 Gestin de incidencias 155
Repaso del captulo 161
Examen de muestra cuestiona 162
Ejercicio: Incidente informe 165
Ejercicio solucin 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 introduccin de una herramienta en una organizacin 190
Repaso del captulo 193
Examen de muestra cuestiona 195
7 Fundacin ISTQB examen 197
Preparacin 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

CAPTULO 1

Fundamentos de la prueba
En este captulo, se le dar a conocer los fundamentos de la prueba: por qu es necesario
realizar exmenes; sus limitaciones, los objetivos y el propsito; los principios detrs de la
prueba; el proceso que sigue testers; y algunos de los psicolgica factores que los evaluadores
deben tener en cuenta en su trabajo. Al leer este captulo se abordan obtener una comprensin
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 daar
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 travs de ejemplos. (K2)
4 Describir por qu la prueba es parte de la garanta de calidad y dar ejemplos de cmo
las pruebas contribuye a una mayor calidad. (K2)
5 Recordemos los trminos "error", "defecto", "culpa", "fracaso" y la corres
'error' ding trminos y 'bug'. (KL)
6 Explicar los principios fundamentales en las pruebas. (K2)
1.1.1 Introduccin
En esta seccin, vamos a poner en marcha el libro con una discusin sobre las pruebas de por
qu asuntos. Vamos a describir e ilustrar cmo 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, cmo las pruebas
promueven la calidad, y cmo pruebas encaja en la garanta de calidad. En esta seccin,
tambin vamos a introducir algunos principios fundamentales de la prueba.

A medida que avanzamos a travs de esta seccin, para ver los trminos 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 trminos definidos en el glosario.

Usted puede preguntar "cul es la prueba? y vamos a ver ms de cerca la definicin de las
pruebas en la Seccin 1.2. Por el momento, vamos a adoptar una sencilla cada da- 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 ms
adelante. Vamos a empezar por considerar por qu es necesario realizar exmenes. 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 podran 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 sera conseguir a alguien ms para comprobar nuestro
trabajo - otra persona es ms probabilidades de detectar los defectos.

En este libro, vamos a explorar las implicaciones de estos dos prrafos 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 crtico es probado de manera diferente a partir de un sitio de comercio
electrnico. En estos das, 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 comunicacin
de masas sistemas. Cada vez ms, son parte de nuestras vidas. Utilizamos el software dia
a da, en aplicaciones comerciales cotidianas como la banca y en los productos de
consumo, tales como automviles y lavadoras. Sin embargo, la mayora 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 crdito 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 todava 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 trfico en la carretera es, si existe es un lugar seguro cruzar, lo bien que podemos ver, y
qu tan rpido podemos cruzar. El impacto depende de qu tan rpido 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 prdida de dinero, tiempo o
negocio reputacin, e incluso pueden causar lesiones o la muerte. Por ejemplo,
supongamos que una interfaz de usuario tiene defectos tipogrficos. Importa esto? Puede
ser trivial, pero podra tener un efecto significativo, segn el sitio web y el defecto:
Si mi sitio web personal rbol genealgico 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 slo la familia verlo (probablemente).
Si la pgina web de la compaa tiene algunas faltas de ortografa 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 aplicacin de plaguicidas, el efecto
podra ser muy significativa: supongamos que un punto decimal se coloca errneamente por
lo que la tasa de aplicacin es 10 veces demasiado grande. Los usos agricultores o jardinero
ms 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 domsticos. Puede Tambin ser la
consiguiente prdida 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 esperbamos. Sin embargo, las personas al disear y construir el software, puede
cometer errores durante el diseo y la construccin. 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 slo el cdigo; comprobar la definicin de software.
Cuando el cdigo 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
debera), causando un fallo. No todos los defectos dan lugar a fallos; algunas permanecen
en estado latente en el cdigo 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 cdigo de software o sistema, o en un documento. Si un
defecto en cdigo se ejecuta, el sistema puede experimentar un fracaso. Por lo que los errores
que cometemos cuestin que en parte debido a que tienen consecuencias para los productos
de los que somos responsable.

Nuestros errores son tambin 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
difcil para las personas a encontrar sus propios errores, mientras que la construccin de un
producto.
Los defectos en software, sistemas o documentos pueden resultar en fallos, pero no todos
defectos causan fallos. Podramos 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 informacin,
entienden mal, o si no tenemos cuidado, cansado o bajo la presin del tiempo.
Todos estos factores afectan nuestra capacidad para tomar decisiones sensatas ya sea nuestro
cerebro no tienen la informacin o no puede procesar la suficiente rapidez.
Adems, somos ms propensos a cometer errores cuando se trata de desconcertantes
problemas tcnicos o de negocio, procesos de negocio complejos, cdigo o infraestructura
las tecnologas cambiantes, o muchas interacciones del sistema. Esto es porque nuestro
cerebro slo puede tratar con una cantidad razonable de complejidad o el cambio cuando se
le pregunt que lidiar con ms nuestros cerebros no puede procesar la informacin que tener
correctamente.
No es slo los defectos dan lugar al fracaso. Las fallas tambin pueden ser causados por
condiciones ambientales, as: por ejemplo, una rfaga de radiacin, un fuerte campo
magntico, campos electrnicos, o la contaminacin podran causar fallos en el hardware
o firmware. Esos defectos pueden prevenir o modificar la ejecucin de un programa.
Las fallas tambin pueden surgir debido a un error humano en la interaccin con el
software, tal vez se introduce un valor de entrada incorrecta o una salida siendo mal
interpretada.
Por ltimo, los fallos tambin pueden ser causados por alguien deliberadamente tratando de
causar un fallo en un sistema, dao malicioso.
Cuando pensamos en lo que podra salir mal, tenemos que considerar los defectos y
fallas que surgen de:
 Errores en la especificacin, diseo e implementacin del software y sistema;
Errores en el uso del sistema;
Condiciones ambientales;
Dao intencional;
Posibles consecuencias de los errores anteriores, dao intencional, defectos y fracasos.

Cuando surgen defectos?

En la figura 1.1 podemos ver cmo pueden surgir defectos en cuatro requisitos para un
producto.

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

requisito de cliente, diseado correctamente para cumplir con este requisito, construido
correlacin para satisfacer el diseo, y as entregar ese requisito con los atributos
correctos funcionalmente, se hace lo que se supone que debe hacer y tambin tiene los
atributos no funcionales, lo que es lo suficientemente rpido, fcil de entender y as
sucesivamente.
Con los dems 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 fcilmente detectado y corregido durante
las pruebas, ya que podemos ver el producto no cumple con las caractersticas de diseo.

Los defectos introducidos en el requisito 3 son ms difciles de tratar; construimos

exactamente lo que nos dijeron que por desgracia, pero el diseador hecho algunos errores
tarde por lo que hay defectos en el diseo. A menos que comprobamos en contra de la
exigencia de la definicin, no se dar cuenta de los defectos durante la prueba. Cuando
hacemos aviso que ser difcil de solucionar porque sern necesarios cambios en el
diseo.

Se introdujeron los defectos en el requisito 4 durante la definicin de los requisitos; el

producto ha sido diseado y construido para satisfacer esa defectuosa definicin de
requerimientos. Si probamos el producto cumple con sus requisitos y diseo, que va a pasar
sus pruebas, pero puede ser rechazado por el usuario o cliente. Defectos reportado por el
cliente en la prueba de aceptacin o uso directo puede ser muy costoso.
Desafortunadamente, los requisitos y defectos de diseo no son raros; las evaluaciones de
miles de proyectos han demostrado que los defectos introducidos durante los
requerimientos y el diseo constituyen cerca de la mitad del nmero total de defectos
[Jones].
Cul es el costo de los defectos?
Adems 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 Ingls "una puntada a tiempo ahorra nueve
'. Esto significa que si usted repara un desgarro en el manguito de ahora, si bien es pequea,
es fcil de reparar, pero si lo deja, se ir a peor y necesitan ms 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 especificacin, entonces es relativamente barato para encontrar y corregir. La
observacin del aumento de los costes de eliminacin de defectos en el software se remonta
a [Boehm]. Explicas

Encontrar pruebas para la economa de la informacin y las pruebas de control de calidad

en [], [Gilb Negro 2001] o [Negro 2004]. La especificacin puede estar correctamente y re-
emiten. Del mismo modo,
Si se comete un error y el consiguiente defecto detectado en el diseo en la fase de diseo,
entonces el diseo puede ser corregido y reeditado con un costo relativamente bajo. Lo
mismo se aplica para la construccin. Sin embargo, un defecto se introduce en la
especificacin de requisitos y no es detectado hasta que las pruebas de aceptacin o
incluso una vez que el sistema ha estado en prctica entonces sern mucho ms caros
de solucionar. Esto se debe a re-trabajo ser necesario en la especificacin y diseo antes se
pueden realizar cambios en construccin; debido a un defecto en los requisitos y puede
propagarse por varios lugares en el diseo y el cdigo; 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 tarda,
dependiendo de la gravedad que sean, no son corregidos debido a que el costo de hacerlo
es demasiado costoso. Adems, si el software se entrega y cumple las especificaciones
acordadas, que a veces todava no ser aceptada si la especificacin estaba mal. El equipo
de proyecto puede haber entregado exactamente lo que se les pidi entregar, pero no es
lo que los usuarios queran. 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 catastrfica. 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
podra cometer un error en la entrada de datos o en la interpretacin de la salida, y en busca
de posibles puntos dbiles para intencional y maliciosa ataque. Encargado de realizar la
ayuda a avanzar hacia una mejor calidad de los productos y servicio, pero eso es slo uno de
los mtodos de verificacin y validacin aplicados a productos. Los procesos tambin se
comprueban, por ejemplo mediante una auditora. Una variedad de mtodos 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 visin independiente.

Tambin es posible que sea necesario para llevar a cabo las pruebas de software para
satisfacer contractual o requisitos legales, o las normas especficas de la industria. Estas
normas pueden especificar qu tipo de tcnicas que debemos utilizar, o el porcentaje de
cdigo de software que deben ejercerse. Puede ser una sorpresa saber que no siempre
probaremos a todos el cdigo; eso sera demasiado caro en comparacin 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 ms probable es que va a existir un estndar
para la prueba.

Las industrias de avinica, motor, mdicos y farmacuticos tienen todas las normas que
cubre la prueba de software. Por ejemplo, la Federal de Aviacin de los Estados Unidos
Estndar DO-178B de la administracin [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 trminos 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 impresin de un informe correctamente) y de los requisitos de software no
funcionales y caractersticas (por ejemplo, la impresin de un informe con la suficiente
rapidez). Caractersticas no funcionales estn cubiertos en el Captulo 2. La prueba puede dar
confianza en la calidad del software de si encuentra pocos o ningn 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 sensacin de seguridad. Una prueba
bien diseada va a descubrir defectos si presentes y por lo tanto, si pasa una prueba de
este tipo, con razn, vamos a tener ms confianza en el software y poder afirmar que el
nivel general de riesgo de la utilizacin 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 especificacin. Para el proyecto
entregar lo que necesita el cliente requiere una especificacin correcta. Adems, el
sistema entregado debe cumplir con la especificacin. Esto se conoce como validacin
('es esta la especificacin correcta?') y verificacin ('es el sistema correcto al valor
especificado? '). Por supuesto, adems 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 definicin del glosario ISTQB abarca no slo los requisitos especificados, sino tambin
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 cules
son sus expectativas. Lo que nosotros como desarrolladores de software y testers debemos
ver como la calidad, que el software cumple con su especificacin definida, es tcnicamente
excelente y tiene algunos errores en ella, no puede proporcionar una solucin de calidad para
nuestra Customs client. Por otra parte, si nuestros clientes a encontrar que han gastado ms
dinero que queran o que el software no ayuda a llevar a cabo sus tareas, no ser impresionado
por la excelencia tcnica de la solucin. Si el cliente quiere un coche barato para una "gestin
sobre 'y tiene un pequeo 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 'produccin y compra de los tomates
'como una analoga de' la produccin y compra de software'. Usted ver como usted mirar a
travs de la mesa que el enfoque de la prueba sera muy diferente dependiendo de qu
punto de vista estamos a favor de [Trienekens], [Evans].

Adems 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 caractersticas pueden servir como un marco o listas de comprobacin
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 trminos Vamos a medir los atributos del Los tomates son el tamao y la
de los atributos del producto. software, por ejemplo, su forma correcta para el embalaje
fiabilidad en trminos 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 slo los estn 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 estn orgnicamente,
procesos de fabricacin, y la desarrollo de software los tomates no tienen manchas y
reunin de los requisitos reconocido. Slo se crea. Liberar sin plagas,
definidos. Se mide mediante el software si hay menos de cinco daar
pruebas, inspeccin y anlisis defectos de alta prioridad en
de fallos y los errores. circulacin una vez que las
pruebas previstas se han
completado.
Expectativa de relacin 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
compensacin basada en el valor permanecer en el presupuesto del valor econmico o bien para
entre el tiempo, esfuerzo y proyecto. dinero,
aspectos econmicos. Podemos
darnos el lujo de comprar este
software y esperar un retorno de
la inversin.
 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 pequea 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
rpido confiamos en ellos.
Se encuentran en la norma ISO 9126. Esta jerarqua de caractersticas y sub caractersticas
de calidad se discute en el Captulo 2.

Qu es el anlisis de causa raz?

Cuando detectamos fallos, podramos tratar de rastrear de nuevo a su causa raz, la

verdadera razn de que ocurrieron. Hay varias maneras de llevar a cabo la raz, anlisis
de la causa, a menudo con un grupo de lluvia de ideas y discutirlas, por lo que puede ver
diferentes tcnicas en diferentes organizaciones. Si usted es interesados en el uso de anlisis
de causa raz en su trabajo, encontrar tcnicas simples se describe en [Evans], [TQMI] y
[Robson]. Por ejemplo, supongamos que una organizacin tiene un problema con la
impresin en varias ocasiones en su defecto. Algunos de mantenimiento de TI popular se
renen para examinar el problema y empiezan por toda la lluvia de ideas posibles causas de
los fracasos. A continuacin, se agrupan en categoras que tienen elegido, y ver si hay causas
subyacentes o profundas comunes. Algunos de las causas obvias que descubren podran 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: ningn proceso para comprobar los niveles de tinta de impresora / papel
antes de utilizar.
Algunos miembros del personal no sabe cmo cambiar los cartuchos de tinta; posible causa
de la raz: 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 raz: hay un proceso
de control de existencias y pedidos.

Si el anlisis se limita al software, lo podra hacer en estos y decir,

"No se trata de problemas de software, por lo que no nos conciernen! ' As que, como
software testers podramos limitarnos a informar del fallo de controlador de impresora.
Sin embargo, nuestra competencia como testers puede estar ms all del software; podramos
tener que remitir a mirar todo un sistema que incluye hardware y firmware. Adems, 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 ms all de
este punto de vista. El software podra proporcionar una interfaz de usuario que ayuda al
usuario anticipar cuando papel o la tinta se est agotando. Se podra proporcionar
instrucciones paso a paso para ayudan a los usuarios cambiar los cartuchos o reponer
papel. Se podra proporcionar un alto aviso de la temperatura de manera que el medio
ambiente puede ser controlado. Como testers, nos No queremos slo 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 ms sensato
evitar el fracaso. La fijacin 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 presin. Por esta razn, los proyectos tendrn una visin a veces
que aplazar la fijacin 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 slo funcionan alrededor y lo evitan.

Cuanto ms rigurosa nuestras pruebas, ms defectos encontraremos. Pero se ver en

Los captulos 3 y 4, cuando nos fijamos en las tcnicas para la prueba, que la prueba rigurosa
no significa necesariamente ms pruebas; lo que queremos hacer es la prueba de que se
encuentra defectos una pequea cantidad de bien colocado, pruebas selectivas podran ser
ms riguroso que un gran nmero 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 identificacin 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
produccin. Comprensin las causas raz 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,
tambin estamos interesados en el estudio de los defectos encontrados en otros proyectos,
por lo que podemos mejorar nuestros procesos. Proceso mejoras deberan 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 ms grande, que incluye otras actividades (por ejemplo, normas de desarrollo,
entrenamiento y anlisis de causa raz).

1.1.6 Cunta 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 excepcin 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. Cmo muchas pruebas debemos hacer? Tenemos una opcin: 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 tendramos que hacer para ser capaz de probar
agotamiento. Cuntas pruebas se necesita hacer para probar por completo una de un dgito
campo numrico? La pregunta inmediata es: "Qu quiere decir con la prueba por
completo?
Hay 10 posibles valores numricos vlidos, pero as como los valores vlidos nosotros
necesitar asegurarse de que todos los valores vlidos son rechazados. Hay 26 maysculas
Los caracteres alfabticos, 26 minsculas, por lo menos 6 caracteres especiales y signos de
puntuacin como as como un valor en blanco. Por lo que habra por lo menos 68 pruebas de
este ejemplo de un campo de un dgito.

Este problema solo empeora a medida que nos fijamos en los ejemplos ms realistas. En
prctica Tice, los sistemas tienen ms de un campo de entrada con ser los campos de la
variacin tamaos. Estas pruebas seran junto a otros como la ejecucin de las pruebas de
diferencia Seccin 2 Cul 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 continuacin,
para poner a prueba la totalidad del valor de entrada vlida 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 dgito con valores de 2, 3 y 4 hace que nuestras pruebas ms
Thor- ough, pero no nos da ms informacin que si acabbamos probado con el valor 3.
Las presiones sobre un proyecto incluyen el tiempo y el presupuesto, as como la presin de
ofrecer una solucin tcnica 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 inversin
para ellos. Este retorno de la inversin incluye prevenibles fallos despus de la liberacin que
son costosos. Probando por completo - incluso si eso es lo que los clientes y gestores de
proyectos piden no es ms 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 alineacin de las pruebas que hacemos con los
riesgos para los clientes, los grupos de inters titulares, el proyecto y el software. La
evaluacin y gestin del riesgo es una de las la mayora de las actividades importantes en
cualquier proyecto, y es una actividad clave y la razn de pruebas. Decidir la cantidad de
pruebas es suficiente debe tener en cuenta el nivel de riesgo, incluidos los riesgos tcnicos y
comerciales relacionados con el producto y el proyecto restricciones tales como el tiempo y
el presupuesto.

Llevamos a cabo una evaluacin 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.
Adems, las pruebas deben proporcionar suficiente informacin para las partes interesadas
para tomar decisiones informadas acerca de la versin del software o del sistema estamos
probando, para el siguiente paso de desarrollo o entrega a los clientes. El esfuerzo puesto en
la garanta de calidad y actividades de prueba tiene que ser tai lored a los riesgos y los costos
asociados con el proyecto. Debido a la lmites 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 evaluacin de riesgos en Captulo 5.

1.2 Qu es la prueba?
Objetivos de aprendizaje del programa de estudios para 1.2 Cul es la prueba?
1 Recordemos los objetivos comunes de la prueba. (KL)
2 Describir el propsito de las pruebas en el desarrollo de software, mantenimiento y
las operaciones como un medio para encontrar defectos, proporcionan la confianza y la
informacin y prevenir los defectos. (K2)

En esta seccin, vamos a revisar los objetivos comunes de la prueba. Vamos a explicar cmo
las pruebas nos ayudan a encontrar defectos, dar confianza a la informacin, y prevenir
los defectos. Tambin introduciremos otros principios fundamentales de pruebas.
A medida que lea esta seccin, se encontrar con los trminos de cdigo, depuracin,
desarrollo de software, requisitos, revisin, base de pruebas, casos de prueba, la prueba
y objetivo de la prueba.
1.2.1 La prueba de conduccin - una analoga para las pruebas de software
Hemos pasado algn 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 podran ser
descritas como 'Comprobar el software est bien'. Eso no es una definicin suficientemente
detallada para ayudar a entender las pruebas de software. Vamos a usar una analoga para
ayudarnos: los exmenes de conduccin. En una prueba de conduccin, el examinador evala
crticamente la conduccin del candidato, sealando cada error, grande o pequea, hecha por
el conductor bajo prueba. El examinador toma el conductor a travs de una ruta que pone a
prueba muchas actividades de conduccin posibles, tales como cruces de carreteras de
diferentes tipos, de control y maniobra del vehculo, 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
Comprobacin 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 rpida, segura y sin prdida 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 nmero y
gravedad de los fallos detectados, y tambin si el conductor ha podido satisfacer las
necesidades de conduccin. Un fallo grave solo es suficiente para quebrar la totalidad prueba,
pero un pequeo nmero de fallos menores an podran implicar que se super la prueba.
Muchas fallas menores reduciran la confianza del examinador en la calidad de la conduccin
hasta el punto en que el conductor no puede pasar. El formato de la prueba de conduccin y
de la conducta del examinador es dignas de consideracin:
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 evaluacin
exhaustiva de la actuacin del conductor. Los conductores menores de prueba hacen no saben
qu ruta se les pedir a tomar con antelacin, 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 nmero y la gravedad de las faltas,
pero con la confianza de que el examinador en el conduccin tambin se tiene en cuenta.
La prueba se lleva a cabo por lo tanto, para demostrar que los requerimientos los satisface
el conductor para la conduccin y para demostrar que estn en condiciones de conducir. El
examinador busca fallas en la conduccin. 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 decisin basada en el riesgo sobre el controlador. Todos
los conductores estn probados de forma equivalente y el examinador es neutral y objetivo. El
examinador registrar observaciones objetivas que permiten una evaluacin del riesgo de ser
hecho sobre la conduccin. 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.
Adems de la observacin de que el conductor efectivamente el volante, el examinador le
preguntar preguntas o el conductor tomarn un examen escrito para comprobar su escasa
pie de las normas de circulacin, seales de trfico, y qu hacer en varios situaciones de
trfico.

1.2.2 Definicin de las pruebas de software

Con esa analoga en mente, veamos la definicin de software ISTQB
Pruebas.
Vamos a romper la definicin en partes; la definicin tiene alguna clave frases para
recordar. La definicin comienza con una descripcin de la prueba como una proceso y,
a continuacin se enumeran algunos objetivos del proceso de prueba. En primer lugar,
vamos a ver probando como un proceso:
Proceso - La prueba es un proceso ms que una sola actividad - hay una serie de las
actividades en cuestin.
Todas las actividades del ciclo de vida - Captulo 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 ms tarde en el ciclo de la vida nos encontramos con errores, es
ms 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 diseo,
pruebas temprano en el ciclo de vida puede ayudar a prevenir defectos de ser
introducido en el cdigo. A veces nos referimos a esto como "la verificacin de la prueba
base a travs del diseo de la prueba '. La base de pruebas incluye documentos tales como
el requisitos y especificaciones de diseo. Vas a ver cmo hacer esto en Captulo 4.
Tanto esttica y dinmica - Veremos en el captulo 3 que, adems de pruebas en las que el
cdigo de software es ejecutado para demostrar los resultados de las pruebas se ejecutan (A
menudo llamado pruebas dinmicas) tambin podemos probar y encontrar defectos sin
ejecutar cdigo. Esto se llama prueba esttica. Esta prueba incluye la revisin de
documentos (incluyendo el cdigo fuente) y el anlisis esttico. Esta es una til y manera
rentable de las pruebas.
 Planificacin - Las actividades se llevan a cabo antes y despus de la ejecucin de la
prueba. Necesitamos que administrar la prueba; por ejemplo, tenemos la intencin 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. Captulo 5 se refiere a estas actividades de gestin de prueba.

Preparacin - Tenemos que elegir lo que prueba que vamos a hacer, mediante la
seleccin con la prueba las condiciones y el diseo de casos de prueba. Captulo 4 cubre las
actividades de diseo de prueba.
Evaluacin - As como la ejecucin de las pruebas, debemos comprobar los resultados y
evaluar el software bajo prueba y los criterios de finalizacin, 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 slo el
cdigo de prueba. Probamos los requisitos y especificaciones de diseo, y nos ponen a
prueba los documentos relacionados tales como la operacin, el usuario y material de
formacin. Pruebas estticas y dinmicas son ambos necesarios para cubrir la gama de
productos que necesitamos para poner a prueba.
La segunda parte de la definicin 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 diseo para ver si cumple
requerimientos, y entonces podramos ejecutar el cdigo para comprobar que cumple con el
diseo.
Si el producto cumple con su especificacin, podemos proporcionar esa informacin 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 propsito: Esta cifra es
ligeramente diferente con el punto anterior; despus de todos los requisitos especificados
podran 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 cermica hace lo que el usuario podra esperar razonablemente. Por ejemplo,
podramos mira que podran comprar o utilizar el software, y comprobar que se hace lo que
esperan; esto nos podra llevar a aadir un comentario del compaero de comercializacin de
nuestras pruebas estticas, para comprobar que las expectativas del software estn
correctamente conjunto. Una manera de juzgar la calidad de un producto es por su estado de
forma es por su propsito.
Deteccin de defectos: Lo ms a menudo pensamos en las pruebas de software como medio
de la deteccin de fallos o defectos que, en uso operativo causarn fallas. Hallazgo los
defectos nos ayuda a comprender los riesgos asociados con poner el software en uso
operativo, y la fijacin de los defectos mejora la calidad de los productos. Sin embargo,
la identificacin de defectos tiene otra ventaja. Con causa raz anlisis, sino que tambin
ayudan a mejorar los procesos de desarrollo y hacer un menor nmero de errores en el
trabajo futuro.
Esta es una definicin adecuada de las pruebas para cualquier nivel de pruebas, a partir de
componente de pruebas a travs de las pruebas de aceptacin, siempre que recordemos que
tomar los diversos objetivos de estos diferentes niveles de pruebas en cuenta. (En Captulo 2
explicaremos los diferentes niveles de la prueba, sus objetivos, y cmo encajan en el ciclo de
vida de desarrollo de software.).
Podemos ver claramente ahora por qu la percepcin comn de pruebas (que slo consiste
en la ejecucin de pruebas, es decir, la ejecucin 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 conduccin 1.2.3 Software compar

Podemos ver que la prueba de software es muy parecido a una prueba de conduccin de
muchas maneras, aunque por supuesto no es una analoga 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 travs de este libro que el mismo
enfoque sostiene ampliamente.

Planificacin y preparacin - Tanto el examinador y el tester necesitan un plan de la accin

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.
esttico y dinmico - Tanto dinmico (conducir el coche o la ejecucin de la suave Ware)
y estticas (preguntas al conductor o una revisin del software) son pruebas til.

Evaluacin - El examinador y el tester debe hacer un objetivo evaluacin, registrar el

resultado de la prueba y reportar observaciones objetivas sobre la prueba.
Determinar que cumplan los requisitos especificados El examinador y tester tanto
verificacin segn las necesidades para llevar a cabo tareas particulares exitosamente.
Demostrar que son aptos para el propsito - El examinador y el tester no son la evaluacin
de la perfeccin, sino para cumplir suficiente los atributos necesarios para pasar la prueba.
Deteccin de defectos - El examinador y el tester de tanto buscar y registro fallos.
Vamos a pensar un poco ms acerca de la planificacin. Porque el tiempo es limitado, con el
fin de realizar un recorrido representativo que lo hara proporcionar una suficientemente
buena prueba, ambos testers de software y examinadores deciden de antemano la ruta que
tomarn.

No es posible llevar a cabo la prueba de conduccin y tomar decisiones sobre dnde pedir al
conductor que vaya al lado en el calor del momento.
Si el examinador hizo eso, podran quedarse sin tiempo y tienen que volver al centro de
pruebas sin haber observado todas las maniobras necesarias. El conductor todava 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 accin, 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
accin. En algunos casos, utilizamos un esquema de peso ligero que proporciona los
objetivos y generales direccin de la prueba, permitiendo que los testers para variar la
prueba durante ejecucin. 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
accin. 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 despus de la ejecucin de la prueba,
y nos explicar esas actividades en este libro. Como tester o el director de pruebas, usted
estar involucrado en la planificacin y control de la prueba, la eleccin de las
condiciones de prueba, el diseo de casos de prueba en base a las pruebas condiciones,
la ejecucin de ellos y comprobacin de resultados, que evalan si las pruebas suficientes
que se ha hecho mediante el examen de finalizacin (O salida) criterios, al informar sobre el
proceso de prueba y el sistema bajo finalizacin de la prueba, y la presentacin 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 dinmicas y pruebas estticas como medio para el
logro de similares objetivos de la prueba. Ambos proporcionan informacin 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 informacin sobre el nivel de la calidad;
La prevencin de defectos.

Muchos tipos de revisin y pruebas actividades se llevan a cabo en diferentes etapas del
ciclo de vida, como veremos en el captulo 2. Estos tienen diferentes objetivos. Temprano
las pruebas, tales como actividades de diseo y revisin de la prueba temprana
encuentran defectos desde el principio cuando son baratos para encontrar y
corregir. Una vez que el cdigo 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, integracin y las
pruebas del sistema), el principal objetivo pueden ser para causar el mayor nmero de
fracasos posible, de manera que se identifican los defectos en el software y se pueden
fijar.
Despus de que las pruebas, los usuarios del software pueden llevar a cabo la aceptacin las
pruebas para confirmar que el sistema funciona como se espera y para ganar confianza que
ha cumplido con los requisitos.

La fijacin de los defectos no siempre puede ser el objetivo de la prueba o el resultado

deseada. A veces simplemente queremos recabar informacin 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 evaluacin 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 regresin pruebas para
garantizar nada ha cambiado que no debera 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 caractersticas del sistema, como la fiabilidad o
disponibilidad.

Principio de pruebas - agrupacin de defectos

Un pequeo nmero de mdulos contiene la mayor parte de los defectos descubiertos durante
el pre-lanzamiento las pruebas o mostrar la mayora de los fracasos operacionales.

1.2.5 Centrndose en defectos puede ayudar a planificar nuestras pruebas

Un anlisis de defectos y fracasos con el fin de mejorar los procesos nos permite mejorar
nuestras pruebas y nuestros requerimientos, diseo y desarrollo procesos. Un fenmeno
que han observado muchos testers es que los defectos tienden a agruparse. Esto puede
suceder debido a que un rea del cdigo es especialmente complejo y difcil, o porque el
cambio de software y otros productos tiende que causa defectos de reaccin en
cadena. Testers suelen usar esta informacin cuando hacer su evaluacin de riesgos para la
planificacin de las pruebas, y se centrar en conocida "puntos calientes".

Un objetivo principal de opiniones y otras pruebas estticas es llevar a cabo la prueba como
pronto sea posible, encontrar y corregir los defectos de forma ms barata y la prevencin
defectos que aparezcan en las etapas posteriores de este proyecto. Estas actividades nos
ayudan averiguar acerca de los defectos anteriormente e identificar posibles grupos. Adems,
un importante resultado de todas las pruebas es la informacin que ayuda a la
evaluacin de riesgos; estas opiniones contribuirn a la planificacin de las pruebas
ejecutadas ms tarde en el ciclo de vida del software de desarrollo. Tambin podemos llevar
a cabo la raz Anlisis 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 ms defectos.
Con el tiempo, a medida que mejoramos nuestro ciclo de vida de desarrollo de software de
todo y los primeros estudios de esttica, que bien puede encontrar que los niveles de los
ensayos dinmicos que se encuentran menos defectos. Una iniciativa tpica de mejora de
ensayo inicialmente se encuentra ms defectos como las pruebas de mejora y, a continuacin,
como la prevencin de defectos entra en accin, vemos los nmeros 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; despus, la mejora nos hace ms eficientes y eficaces en la
produccin 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 bsqueda errores de codificacin, al mirar a los requisitos y documentos
de diseo de los defectos, y a la bsqueda de mejoras en los procesos de manera que se
previene defectos en el producto. Con referencia a la Figura 1.3, por la publicacin de 9 y
10, esperaramos que la coste total y el esfuerzo asociado con reseas y ensayos es mucho
menor que en comunicados de 4 o 7.

1.2.7 Depuracin elimina defectos

Cuando una prueba encuentra un defecto que debe ser fijo, un programador tiene que
hacer algn trabajo para localizar el defecto en el cdigo y hacer la correccin. En este
proceso, llamado debuging, un programador examinar el cdigo de la causa inmediata del
problema, repare el cdigo y comprueba que el cdigo se ejecuta ahora como se esperaba.
El arreglo est a menudo entonces prueba por separado (por ejemplo, mediante un tester
independiente) para confirmar la solucin. Tenga en cuenta que las pruebas y la depuracin
son actividades diferentes. Desarrolladores pueden probar sus propias correcciones, en
cuyo caso el ciclo muy ajustado de la identificacin de fallos, depuracin y repeticin del
examen es a menudo referido libremente como la depuracin. Sin embargo, a menudo
siguiendo el ciclo de depuracin del cdigo fijo se prueba de forma independiente tanto para
volver a probar la correccin de s mismo y de aplicar las pruebas de regresin 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 estn 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 correccin.
Este principio se deriva de la teora del proceso de experimentacin cientfica y ha sido
adoptado por los testers; ver la idea en muchos libros de ensayo.
Si bien no se espera para leer la teora cientfica [Popper] la analoga 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 bsqueda de un error, no hemos mostrado 'No hay errores'. Tan pronto como nos
encontramos con un error, hemos demostrado 'Este cdigo 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 cermica, las personas
y organizaciones que compran y lo utilizan para ayudar en su da a tareas del da, no estn
interesados en los defectos o nmero de defectos, salvo cuando estn directamente afectados
por la inestabilidad del software. Las personas que utilizan, cermica estn ms interesados
en el software de apoyo en la realizacin de tareas Eficiente y efectivamente. El software
debe satisfacer sus necesidades. Es por esta razn por la que los requisitos y defectos de
diseo que hemos discutido son tan importante, y por qu las revisiones e inspecciones (vase
el Captulo 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 ms para recordar mismo
acerca de ellos. Estos principios se han sugerido en los ltimos 40 aos 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
estn 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
correccin.
Principio 2 Las pruebas Todo Testing (todas las
exhaustivas son imposible combinaciones de insumos y
las condiciones previas) no
es viable a excepcin 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 Agrupacin defecto Un pequeo nmero de
mdulos 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 ningn 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 ms
defectos.
Principio 6 Las pruebas Las pruebas se hacen de
son dependientes del manera diferente en
contexto diferentes contextos. Por
ejemplo, la seguridad crtica
software se prueba de
manera diferente a partir de
un sitio de comercio
electrnico.
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 planificacin hasta

actividades de cierre de la prueba y las tareas principales de cada prueba
actividad. (KL)

1.4.1 Introduccin
En esta seccin, vamos a describir el proceso de la prueba fundamental y
actividades. Estos comienzan con la planificacin de controles y continan hasta el
cierre a prueba.
Para cada parte del proceso de prueba, vamos a discutir las principales tareas de cada prueba
actividad.
En esta seccin, tambin se encontrar con los trminos del glosario de pruebas de
confirmacin, criterios de salida, incidentes, pruebas de regresin, base de pruebas, la
prueba condicin, cobertura de las pruebas, datos de prueba, ejecucin 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 ejecucin son importante, tambin necesitamos
una plan de accin 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 planificacin de las
pruebas, el diseo de casos de prueba, la preparacin para la ejecucin y la evaluacin
del estado. La idea de una prueba fundamental proceso para todos los niveles de la prueba
se ha desarrollado a lo largo de los aos. 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 mayora
organizaciones con un proceso de prueba menos documentado. La decisin 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 bsicos:
Planificacin y control;
Anlisis y diseo;
Implementacin y ejecucin;
Evaluacin de los criterios de salida y presentacin de informes;
Las actividades de cierre de prueba.

Estas actividades son lgicamente ordenadas, pero en un proyecto en particular, puede

solaparse, simultneamente e incluso repetirse. Este proceso es especialmente, utilizado
para la prueba dinmica, pero las principales partidas del proceso se puede aplicar a crticas
tambin. Por ejemplo, tenemos que planificar y prepararse para una revisin, llevar a cabo
las opiniones y evaluar los resultados de las crticas. Para algunas crticas, como las
inspecciones, tendremos criterios de salida y pasar a travs de las actividades de cierre. Sin
embargo, el detalle y la denominacin de las actividades sern diferente para pruebas
estticas. Discutiremos esttica las pruebas en el Captulo 3.
1.4.2 planificacin y control de prueba
Durante la planificacin 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 misin de prueba o la asignacin
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 organizacin o programa de polticas
de prueba y una estrategia de prueba. Poltica de prueba da normas para las pruebas,
por ejemplo, 'Siempre revisan los documentos de diseo'; 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) Anlisis del riesgo (vase el captulo 5). Si la poltica y
la estrategia son ya definidos que conducen nuestra planificacin, pero si no nos debe pedir
que sean indicado y definido. La planificacin de prueba tiene las siguientes tareas
principales, aproximacin 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 estn en posibilidades de
pruebas; el negocio, producto, proyecto y los riesgos tcnicos 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
propsito o para medir las cualidades y atributos de software.
Determinar el enfoque de la prueba (tcnicas, elementos de prueba, la cobertura, la
identificacin de y la interfaz con los equipos que participan en la prueba, testware):
consideramos cmo vamos a llevar a cabo las pruebas, las tcnicas a utilizar, lo que las
necesidades de pruebas y cunto tiempo (es decir, qu grado de cobertura). Veremos que
necesita a involucrarse y cuando (esto podra 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 prctica la poltica de prueba y / o la estrategia de prueba: hemos mencionado

que hay puede ser una poltica de organizacin o programa y la estrategia para la prueba. Si
esto es el caso, durante nuestra planificacin que debe asegurarse de que lo que vamos a
hacer se adhiere a la poltica y la estrategia o que debe de haber acordado con las partes
interesadas, y documentado, una buena razn para apartarse de ella.

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

prueba, PC): desde la planificacin ya lo hemos hecho, ahora podemos entrar en
detalles; nosotros decidimos en nuestro equipo de maquillaje y tambin creamos todo el
hardware de apoyo y el software que necesitamos para el entorno de prueba.
Tareas de anlisis y diseo de pruebas Programacin, ejecucin de pruebas, ejecucin
y evaluacin: 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 mostrarn qu tareas y
controles hay que completar para un nivel particular de las pruebas antes de poder
decir que la prueba ha terminado.

La gestin de cualquier actividad no se detiene con la planificacin 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 desviacin 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 revisin y prueba
dentro del proyecto, la planificacin y el control tiene que ocurrir dentro de cada uno
de esos grupos, sino tambin en todos los grupos para coordinar entre ellos, lo que
permite traspasos suaves entre cada etapa de pruebas. Planificacin de las pruebas tiene en
cuenta la retroalimentacin 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 exmenes y pruebas: Tenemos que saber cuntas
crticas y pruebas que hemos realizado. Tenemos que realizar un seguimiento de cuntos
pruebas han pasado y cuntos fallado, junto con el nmero, 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 evaluacin de riesgos que hemos
tomado. Debemos hacer que el resultado de la prueba visible y til para todo el equipo.

Proporcionar informacin sobre las pruebas: Debemos esperar para hacer regular
informes excepcionales al jefe de proyecto, direccin de obra, los clientes y otros actores
clave para ayudarles a tomar decisiones informadas sobre estado del proyecto. Tambin
debemos utilizar la informacin que tenemos para analizar las pruebas de s mismo.

Iniciar acciones correctivas: Por ejemplo, apretar los criterios de salida para los
defectos fijos, pedir ms esfuerzo para ser puesto en la depuracin o priorizar los
defectos de fijacin bloqueadores de prueba.
Tomar decisiones: Sobre la base de las medidas y la informacin recogida durante pruebas
y cualquier cambio en los riesgos de negocio y de proyecto o nuestra aumentado bajo pie de
riesgos tcnicos 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 Anlisis de un ensayo y diseo

Anlisis y diseo de la prueba es la actividad en la que los objetivos generales de ensayo se
transforman formado en las condiciones de prueba tangibles y diseos de prueba. Durante el
anlisis de prueba y diseo, tomamos objetivos de las pruebas generales identificados durante
la planificacin y construccin diseos de prueba y los procedimientos de prueba
(scripts). Vas a ver cmo hacer esto en el captulo 4. Anlisis y diseo de prueba tiene las
siguientes tareas principales, aproximadamente en el siguiente orden:

Revisar la base de pruebas (tales como el anlisis de riesgo del producto, requisitos,
arquitectura, especificaciones de diseo 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 disear ciertos tipos de pruebas
(llamadas pruebas de recuadro negro) antes de que exista el cdigo, 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 ambigedades en las especificaciones, ya que estamos tratando de identificar con
precisin lo que sucede en cada punto del sistema, y esto tambin impide defectos que
aparecen en el cdigo.
Identificar las condiciones de ensayo basado en el anlisis 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 podra 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 tcnicas de prueba para ayudarnos a definir las
condiciones de prueba. De esto podemos empezar a identificar el tipo de datos de prueba
genrica que podra necesitar.
Disear las pruebas (ver cmo hacer esto en el captulo 4), utilizando tcnicas de ayudar
a seleccionar las pruebas representativas que se refieren a aspectos particulares de la suave
Artculos de los cuales conllevan riesgos o que son de particular inters, en base a la prueba
condiciones y entrar en ms detalles. Por ejemplo, el examinador podra 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 disear pruebas; por ejemplo, si el
rendimiento del software es importante, que debe especificarse en un comprobable
camino. Si los requisitos slo dicen 'el software necesita para responder con rapidez
suficiente "que no es comprobable, ya que" lo suficientemente rpido "puede significar
diferentes cosas para diferentes personas. Uno de los requisitos ms comprobable sera '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, conexin,
cortafuegos y otros factores que el sitio web encuentra.

Disear el entorno de configuracin de prueba e identificar cualquier infraestructura

necesaria y herramientas. Esto incluye herramientas de prueba (vase el Captulo 6) y
herramientas de apoyo tales como hojas de clculo, procesadores de texto, herramientas de
planificacin 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 aplicacin y ejecucin

Durante la implementacin y ejecucin 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, despus de haber reunido un alto nivel de diseo 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 automatizacin. Tambin
tenemos que establecer un ambiente donde vamos a ejecutar las pruebas y construir
nuestros datos de prueba. La creacin de ambiente y datos a menudo implica mucho
tiempo y esfuerzo, por lo que debe planificar y vigilar cuidadosamente este
trabajo. Prueba de la aplicacin y la ejecucin tienen la las siguientes tareas principales,
aproximadamente en el siguiente orden:

Implementacin:
- Desarrollar y dar prioridad a los casos de prueba, utilizando las tcnicas que ver en
el captulo 4, y crear datos de prueba para dichas pruebas. Tambin vamos a escribir
instrucciones para llevar a cabo las pruebas de ensayo (procedimientos). Para el examinador
esto podra significar cambiar la condicin 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, seales 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 automatizacin ms en el
captulo 6.

- Crear conjuntos de pruebas de los casos de prueba para la eficiente ejecucin de la

prueba. Una prueba Suite es una coleccin lgica de casos de prueba que, naturalmente,
trabajan juntos. Conjuntos de pruebas a menudo comparten datos y un conjunto de alto
nivel comn de objetivos. Tambin vamos a establecer un calendario de ejecucin 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 realizacin de pruebas
especficas en eso.

Ejecucin:
- Ejecutar los bancos de pruebas y casos de prueba individuales, siguiendo nuestra
prueba de procedimientos. Podramos hacerlo manualmente o mediante el uso de
herramientas de ejecucin de prueba, de acuerdo a la secuencia planificada.

- Registrar el resultado de la ejecucin 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 versin del software; debemos
informar defectos en contra de las versiones especficas; y el registro de la
prueba mantenemos proporciona una pista de auditora.
- Comparar los resultados reales (lo que pas cuando nos encontramos con las pruebas)
con Resultados esperados (lo que anticipamos que ocurrira).
- Cuando existan diferencias entre los resultados reales y esperados, discrepancias
informe como incidentes. Se analizan para reunir ms detalles sobre el defecto, reportan
informacin 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 gustara 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 haba
fracasado con el fin de confirmar una solucin (pruebas de confirmacin o repeticin de
pruebas). Ejecutamos pruebas y suites corregido si haba defectos en nuestras
pruebas. Ejecutamos las prueba corregida de software de nuevo para asegurarse de que el
defecto fue corregido correctamente (prueba de confirmacin) y que los programadores
no introducen defectos en las reas inalteradas del software y que la fijacin de un
defecto no descubri otros defectos (regresin pruebas).

1.4.5 La evaluacin de los criterios de salida y presentacin de informes

La evaluacin de los criterios de salida es la actividad en la ejecucin de la prueba se evala
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 evaluacin de riesgos, vamos a tener criterios establecidos contra el cual
mediremos "suficiente". Estos criterios varan 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
terminacin (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 medicin de la respuesta '), los criterios de aceptacin (que decirnos Cmo
sabemos si el software se aprueba o no global, por ejemplo, "slo pasan el conductor si han
completado la parada de emergencia de forma correcta o slo pasar el software para la
liberacin 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 evaluacin 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 planificacin 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 confirmacin de la prueba, o se encuentran fuera en pie.
Evaluar si se necesitan ms pruebas o si los criterios de salida deben ser cambiado: Es
posible que tenga que hacer ms pruebas si no hemos realizado todas las pruebas que
Diseamos, o si nos damos cuenta de que no hemos llegado a la cobertura de lo que
esperbamos, 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 tcnicos caen en importancia. Tenga en cuenta que
este No es fcil 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
captulo 6 nos ayuda con esta evaluacin.

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 comprobacin y
presentacin mecanismos de pruebas (testware) y anlisis hechos y nmeros. Es posible
que tengamos que hacer esto cuando se entrega el software. Nosotros tambin podramos
cerrar las pruebas por otras razones, como cuando no hemos reunido la informacin
necesaria de las pruebas, cuando se cancel el proyecto, cuando un particular, se logra hito,
o cuando se realiza una liberacin o actualizacin 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 travs de la reparacin de defectos o aplazamiento. Por los
diferidos, es decir, aquellos que permanecen abiertas, que pueden solicitar un cambio en una
versin futura. Documentamos la aceptacin o el rechazo del sistema de software.

Finalizacin y archivo testware, tales como scripts, el entorno de prueba, y cualquier

otras infraestructuras de ensayo, para su posterior reutilizacin. 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. Tambin nos permite comparar los resultados de las pruebas
entre versiones de software.

Entregar testware a la organizacin de mantenimiento que apoyar el software y

realizar correcciones de errores o cambios de mantenimiento, para su uso en aire
pruebas de confirmacin y pruebas de regresin. 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 cmo fue la prueba y analizar las lecciones aprendidas para futuros
proyectos. Esto podra incluir mejoras en los procesos para el ciclo de vida de desarrollo de
software en su conjunto y tambin la mejora de la prueba procesos. Si usted refleja en la
figura 1.3 una vez ms, podemos utilizar los resultados de las pruebas a fijar objetivos de
mejora de crticas y pruebas con el objetivo de reducir el nmero de defectos en el
uso. Podemos fijarnos en el nmero de incidentes los cuales eran los problemas de
prueba, con el objetivo de mejorar la forma en que diseamos, ejecutar y comprobar
nuestras pruebas o la gestin de los entornos de prueba y datos. Esto nos ayuda a tomar
nuestras pruebas ms madura y rentable para la organizacin. Esto est documentado en un
informe resumen de la prueba o podra ser parte de un informe general de evaluacin del
proyecto.

1.5 LA PSICOLOGA DE PRUEBAS

1 Hay que recordar que el xito de la prueba se ve influenciada por factores
psicolgicos: (KL)
Objetivos claros;
Un equilibrio de auto-prueba y las pruebas independientes;
El reconocimiento de la comunicacin corts y comentarios sobre defectos.

2 Contrasta la mentalidad de un tester y el de un desarrollador. (K2)

En esta seccin, vamos a discutir los diversos factores psicolgicos 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 comunicacin y retroalimentacin
sobre los defectos. Tambin vamos a contrastar la mentalidad de un tester y de un
desarrollador.
Encontrar un solo trmino del programa de estudios en esta seccin, las pruebas
independientes, y el trmino del glosario, la independencia.

1.5.1 Las pruebas independientes - que es un tester?

La mentalidad que desea utilizar durante la prueba y revisin es diferente de la que
utilizamos durante el anlisis o en desarrollo. Con esto queremos decir que, si estamos
construyendo algo, que estamos trabajando positivamente para resolver problemas en el
diseo 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 crticos de la misma.
Supongamos que se va a cocinar una comida para entrar en una competicin 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 evalan las comidas de competencia. T examinar todo crticamente,
incluyendo el men, los ingredientes, los mtodos usado, manteniendo a las asignaciones de
tiempo y presupuesto, la eleccin de los ingredientes, el elegancia de la mesa y de la porcin,
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 tambin tenga en cuenta todos los fallos y errores Todos lo que el chef
hizo.
Lo mismo sucede con las pruebas de software: la construccin 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
integracin de los componentes en el sistema. El buen chef ser tan crtica como los jueces
de la competicin 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 cdigo; de hecho, los programadores ponen a prueba su propio cdigo y
encontrar muchos problemas, resolverlos antes de que nadie ms vea el cdigo. Negocio
anlisis y de marketing personal debe revisar sus propios requisitos. Sistema arquitectos
deben revisar sus propios diseos. Sin embargo, todos sabemos que es difcil 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 podra ser un analista compaero, diseador 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 diseo pueden realizar algunas
pruebas. Probando los especialistas, testers profesionales, estn a menudo en cuestin. De
hecho, los exmenes pueden implicar una sucesin 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 captulo 2. Usted ver que hay que varias etapas de revisin 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 diseo de
documentos por alguien que no sea el autor ayuda a encontrar defectos antes de la
codificacin Inicial y nos ayuda a construir el software adecuado. Despus de la
codificacin, el software puede ser probado de forma independiente. Este grado
de independencia evita el sesgo autor y es a menudo ms eficaz en la bsqueda de defectos
y fallas.

Varios niveles de independencia pueden ser identificados, mencionadas anteriormente, desde

el ms bajo el nivel de independencia de la ms alta:

Pruebas por parte de la persona que escribi el artculo 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 diseadas por una persona de una organizacin o empresa diferente, como
las pruebas de contratacin externa o la certificacin 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 cmo poner a prueba y quin
son, como buenos cocineros, autocrtico, 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 cdigo. Algunos mtodos
desarrollo de software insisten en el diseo de pruebas antes de empezar a programar
y ejecutar estas pruebas de forma continua a medida que cambian el cdigo. Este
enfoque promueve principios pruebas y deteccin de defectos temprana, lo que es
rentable. Recuerde, independientes pruebas puede llevarse a cabo en cualquier nivel de
la prueba y la eleccin 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 separacin de la funcin del papel tester y el desarrollador
tambin se hace para ayudar a los esfuerzos de enfoque y para proporcionar los beneficios de
la formacin 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 separacin puede conducir a problemas, as como ventajas. La ventaja de
la independencia y el enfoque se puede perder si la relacin entre los equipos se deteriora,
como veremos.

Cada organizacin y cada proyecto tendrn sus propias metas y objetivos.

Las diferentes partes interesadas, tales como los clientes, el equipo de desarrollo y el
gerente de la organizacin, tendrn 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 ms 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 podra
centrarse ya sea en la bsqueda de defectos o en lo que confirma que software
funciona. Pero si uno de los interesados es menos influyente en el proyecto, pero ms
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 confirmacin de que
el funciona el software y que es "suficientemente buena" si esto es visto como una manera
de entregar tan rpido 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 ms tiempo para hacer y requerir tiempo para la fijacin, repeticin de pruebas
y pruebas de regresin. 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 despus de la liberacin, acerca si la prueba "suficiente" se ha
hecho.
Muchos de nosotros nos resulta un reto para realmente disfrutar de la crtica de nuestro
trabajo. Nosotros por lo general creemos que hemos hecho todo lo posible para producir
trabajo (documentos, cdigo, pruebas, lo que sea) que es correcta y completa. As que cuando
alguien identifica dems un defecto, un error que hemos hecho, que podra tomar esto
personalmente y obtener molesto con la otra persona, sobre todo si estamos bajo la presin
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
seala. 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 cmo reaccionamos. Estamos satisfecho, por supuesto, ya que hemos encontrado
un insecto bueno! Pero cmo ser el requisito analista, diseador, 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 crtica 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 ms objetivo y cortsmente
como sea posible. Si los dems son para ver nuestro trabajo como constructiva en la gestin
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 fctica informes de
incidentes y resultados de la revisin.
- 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, crtica y discute el defecto y cmo 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 crtica.
- mostrar lo que los riesgos han descubierto y los beneficios de la revisin o prueba.
Comience con la colaboracin en lugar de batallas. Recordar a todos el objetivo comn
de los sistemas de mejor calidad.
- Ser educado y servicial, colaborar con sus colegas.
- Trate de entender cmo 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 cmo la prueba o examen ayuda al autor - lo que est en l para l o ella.
- Ofrecer el trabajo para ser revisado, tambin.

Es nuestro trabajo como revisor y tester para proporcionar a todos con clara, objetiva
informacin y para ello vamos caza de errores, minera y defectos fracaso
fabricacin. 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
crtico y atencin al detalle. Sin embargo, a menos que tambin tienen buena habilidades
interpersonales y de comunicacin, la cortesa, la comprensin de los dems y una
buena actitud hacia nuestros compaeros, colegas, clientes, directivos y el resto del
equipo, vamos a fracasar como testers porque nadie nos escuchar.

El lder del tester y la prueba necesitan buenas habilidades interpersonales para comunicarse
informacin 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 informacin puede
desertar ayudan a mejorar sus habilidades, pero slo 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 comunicacin diferente
informacin: hechos; nuestras emociones; pensamientos pesimistas y optimistas; y la
creacin Ideas Active. Al revisar o las pruebas, tenemos que comunicar hechos
objetivamente, pero los otros tipos de informacin son tiles tambin: "Esto sucedi; esto es
lo que senta por ella; esto es lo que era bueno; esto es lo que podra salir mal; aqu es una as
podramos resolver el problema". Como parte del suministro de la evaluacin 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
costara $ A 15 000 para fijar y prueba de repeticin de la prueba / de regresin, es que vale
la fijacin? Si se causara 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 solucin es difcil de hacer y que pueden tener efectos negativos en otros lugares,
puede ser mejor no fijar. proporcionando el equipo con la informacin sobre el defecto en
trminos que encuentran til, puede ayudarles a tomar la decisin correcta acerca de arreglar
o no la fijacin 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 psicologa de las pruebas, no es un ejercicio en el final
del captulo, despus de las preguntas del examen la prctica.

Repaso Captulo
Vamos a repasar lo que ha aprendido en este captulo.

De la Seccin 1.1, ahora debera ser capaz de explicar por qu es necesaria la prueba y apoyar
esa explicacin 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 sntomas. Usted debe
ser capaz de discutir las formas en que prueba encaja en y es compatible con una mayor
calidad. Usted debe conocer los trminos del glosario error, defecto, el fracaso, culpa,
error, calidad, riesgo, software, pruebas y pruebas exhaustivas.

De la Seccin 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 cmo las pruebas
puede encontrar defectos, dar confianza y la informacin y prevenir defectos. Usted debe ser
capaz de explicar los principios bsicos de la comprobacin, resumidos en la seccin
1.3. Usted debe saber los trminos del glosario de cdigo, depuracin (debugging),
desarrollo de software, requisitos, revisin, realizacin de pruebas selectivas, caso de
prueba, ensayo y objetivo de la prueba.

De la Seccin 1.4, usted debe reconocer ahora el proceso de prueba fundamental, como
adems 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 planificacin y probar control, anlisis y diseo, implementacin y ejecucin, la
evaluacin de criterios de salida y presentacin de informes, y el cierre de prueba. Usted
debe conocer los trminos del glosario pruebas de confirmacin, los criterios de salida,
incidente, pruebas de regresin, pruebas bases, condiciones de ensayo, cobertura de las
pruebas, datos de prueba, ejecucin 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 Seccin 1.5, ahora debera ser capaz de explicar la psicologa de las
pruebas y cmo las personas influyen en el xito la prueba. Usted debe recordar la
importancia de objetivos claros, la combinacin adecuada de autodiagnstico e
independiente pruebas y corts, respetuosa comunicacin 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 trmino independencia.

PREGUNTAS examen de la muestra

Pregunta 1 Una empresa ha adquirido recientemente una aplicacin off-the-shelf para
automatizar su proceso de pago de facturas. Ahora planean para ejecutar una prueba de
aceptacin en contra del paquete antes de la ponerlo en produccin. Cul de los siguientes
es su razn ms probable para la prueba?
a. Para fomentar la confianza en la aplicacin.
b. Para detectar errores en la aplicacin.
c. Para reunir pruebas para una demanda.
d. Para capacitar a los usuarios.

Pregunta 2 Segn el Glosario ISTQB, la palabra 'bug' es sinnimo de cul de las siguientes
palabras?
a. Incidente
b. Defecto
c. Error
d. Fallo

Pregunta 3 Segn el Glosario ISTQB, una riesgo se refiere a cul de las siguientes?
a. La retroalimentacin negativa al tester.
b. Las consecuencias negativas que se producirn.
c. Las consecuencias negativas que podran ocurrir.
d. consecuencias negativas para el objeto de prueba.

Pregunta 4 La garanta de que comience la prueba de diseo durante la fase de definicin de

los requisitos es importante para permitir, cul de los siguientes objetivos de la prueba?
a. La prevencin de defectos en el sistema.
c. Encontrar defectos a travs de pruebas dinmicas.
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 deteccin de porcentaje de su equipo de pruebas y la industria, senior
gestin 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, cul de los siguientes principios de prueba es ms 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. agrupacin defecto
c. Paradoja del pesticida
d. La ausencia de errores-falacia

Pregunta 6 Segn el Glosario ISTQB, es necesario realizar pruebas de regresin con qu

propsito?
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 modificacin.
d. Para motivar mejor prueba de la unidad por el programador.

Pregunta 7 Cul de los siguientes es ms importante para promover y mantener una buena
relacin entre los testers y desarrolladores?
a. La comprensin de lo que los gerentes sobre el valor pruebas.
b. Al explicar los resultados de pruebas de forma neutra.
c. La identificacin de potenciales clientes soluciones temporales para loco.
e. La promocin de software de mejor calidad siempre posible.

Pregunta 8 Cul de las siguientes afirmaciones es la mejor evaluacin de cmo se aplican

los principios de prueba en todo el ciclo de vida de la prueba?
a. principios de prueba slo afectan a la preparacin para pruebas.
b. principios de prueba slo afectan actividades de ejecucin de pruebas.
c. principios de prueba afectan a las actividades de prueba de los primeros tales como la
revisin.
d. principios de prueba afectan las actividades a lo largo del ciclo de vida de prueba.

EJERCICIO: PRUEBA DE PSICOLOGA

Leer el correo electrnico a continuacin, y ver lo que encuentre pistas para ayudarle a
identificar problemas en el escenario descrito.

Categorizar las pistas / problemas como:

Posibles personas, la psicologa y la actitud problemas;
Los problemas de otros problemas, por ejemplo, posible gestin de pruebas y el papel, los
posibles problemas del producto.

Hola!
Bueno, casi me caus pnico hoy porque pens que haba 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 actualizacin
de procesos que corrieron durante la noche, as como comprobacin de los datos pasados al
cliente. Finalmente encontr el problema. Haba hecho clic mal, en un archivo .bat cuando
se ejecuta un cliente y haba corrido hasta el entorno de cliente errneo.
Para entonces, el director de pruebas estaba listo para decir unas pocas palabras en mi odo,
especialmente en lo que a la gente de desarrollo haban 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 sesin en el servidor de prueba ambientes,
los paneles muestran siempre el medio ambiente al que estn 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 haba comenzado dos clientes, es decir dos participantes
en el intercambio, por lo que podran 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 ratn una fraccin por lo que corri el archivo
.bat 14 que est prxima 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 estpido haber causado mucha actividad agitada y
desperdiciado. En reflexin 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 sesin 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 seleccin 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 trminos reales, esto significa que un usuario real podra ser
conectado con el sistema de produccin y creo que est conectado a un sistema de prueba y
arruinar el comercio. S que esto ocurri una vez en el sistema de negociacin de acciones,
cuando una comerciante introduce una carga de transacciones de prueba en el sistema de
produccin por error y caos causado.
Como una adicin a esta historia, un par de das ms tarde uno de los testers encontr lo que
pareca ser otro sensacional Mega. l y el director de pruebas pasaron tres horas arrastrndose
por todo el sistema antes de descubrir el "error". Un nuevo filtro tena ha agregado al software
de cliente para filtrar las transacciones que se muestran en los paneles por mercado
geogrfico. Desconocido para ellos, se establece en un valor predeterminado del mercado
alemn, mientras que pensaban que estaban en el mercado del Reino Unido. En
consecuencia, a primera vista, se Aparecieron haba problemas fundamentales con la red de
autobuses y de la transaccin mensaje de radiodifusin sistemas. Aparte de la cuestin que
deberan haber sido informado de este cambio, se plante un problema similar al que haba
experimentado, el sistema cliente no muestra el mercado en el que est operando.
Bueno - Me voy para otro da feliz en el oficina! Todo lo mejor SOLUCIN DE
EJERCICIO

La gente, los problemas de la psicologa 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 odo, especialmente en lo que al desarrollo la gente haba
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 informacin, por ejemplo, 'Bueno, casi me caus pnico hoy porque
pens que haba encontrado una sensacional en el Mega sistema de comercio que estn
poniendo a prueba, 'y' Como una adicin a esta historia, un par de das ms tarde uno de los
testers encontrado lo que pareca ser otro mega-sensacional. "
Desconfianza inicial superar mediante un reexamen del problema si una persona puede
cometer este error, los dems ser. "Al principio me sent un poco estpido haber causado
mucha actividad agitada y desperdiciado. En la reflexin 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 da feliz en la oficina! "
Otros problemas incluyen la gestin de pruebas y problemas de conducta, por ejemplo:
Gestin de la configuracin y el control de la liberacin - Un nuevo filtro se haban
aadido al software de cliente de transacciones de filtro que aparecen en los paneles por
mercado geogrfico .
Gestin de Configuracin, relaciones, comunicaciones aparte de la cuestin de que
deberan estar informados de este cambio....'
Tiene el director de pruebas comprenda 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
tcnicos. No todos los problemas nos encontramos con que los testers son de funcionalidad
o problemas tcnicos. Hay algunos problemas que no son funcionales, Especficamente, la
usabilidad que indican que un usuario real podra ser molestados o peor por este problema:
"Yo tena mis-clic en un archivo .bat ...'
'En trminos reales, esto significa que un usuario real podra estar conectado al sistema de
produccin 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 produccin por error y el caos causado."
"Se plante un problema similar al que haba experimentado el sistema cliente no muestra
el mercado en la que usted est negociando'.
"No hay ni una exhibicin 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 alemn,
mientras que pensaban que estaban en el mercado del Reino Unido. "
Tenga en cuenta que vamos a volver a este ejercicio al final del captulo 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 cmo se organiza la prueba.
Hay muchas formas diferentes de pruebas. Debido a varias disciplinas, a menudo con
diferentes intereses, estn involucrados en el ciclo de vida de desarrollo, es importante
entender claramente y definir los diversos niveles y tipos de prueba. Este captulo trata
sobre el software ms comnmente aplicado los modelos de desarrollo, los niveles de prueba
y tipos de prueba. El mantenimiento puede ser visto como una instancia especfica de un
proceso de desarrollo. El mantenimiento de manera influye en el proceso de la prueba, los
niveles y tipos y cmo prueba puede ser organizado se describe en la ltima seccin de este
captulo.
T
2.1 MODELOS DE DESARROLLO DE SOFTWARE
1 Comprender la relacin entre desarrollo, actividades de prueba y productos de
trabajo en el ciclo de vida de desarrollo y ejemplos dar basan en proyecto y las
caractersticas del producto y el contexto. (K2)
2 Reconocer el hecho de que los modelos de desarrollo de software deben adaptarse al
contexto de las caractersticas del proyecto y del producto. (KL)
3 razones Recall para diferentes niveles de prueba y caractersticas 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 metodologas
ligeras y rpidas, donde el tiempo a mercado es de la esencia, a travs de metodologas
totalmente controlados y documentados en los que la calidad y la fiabilidad son factores
clave. Cada uno de estos mtodos tiene su lugar en el software moderno el proceso de
desarrollo ms 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 estn muy relacionadas con las actividades de desarrollo de software. Se definir
el qu, dnde y cundo de nuestra prueba planificada, pruebas de regresin influencia y
determinar en gran medida el que las tcnicas 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 continuacin, la prueba debe ser
rpido y eficiente. Si un totalmente documentado ciclo de vida del software de desarrollo,
con una pista de auditora 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
verificacin y otra parte se centra en pruebas de validacin. La verificacin se refiere
con la evaluacin de un producto de trabajo, componente o sistema para determinar si
cumple con los requisitos establecidos. De hecho, la verificacin se centra en la pregunta
"Es lo por entregar construido de acuerdo a la especificacin? '. La validacin se
refiere a la evaluacin de un producto de trabajo, componente o sistema para
determinar si cumple con lo que el usuario necesita y sus requisitos. La validacin se
centra en la pregunta "Es el entregable justo para el propsito, por ejemplo, tampoco
proporciona una solucin para el problema? '.

2.1.1 V-modelo
Antes de discutir el modelo en V, vamos a ver el modelo que haba antes de l.
El modelo de cascada fue uno de los primeros modelos, que se establecer. Tiene una
lnea 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 travs de los distintos las tareas del proyecto acabado con aplicacin en el entorno
real. Diseo fluye a travs en el desarrollo, que a su vez desemboca en construccin, 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 implantacin en vivo. Con este
modelo se tiene sido difcil conseguir la regeneracin pasa hacia atrs 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 tambin aaden tiempo de espera debido a su implicacin tarde. El modelo V
orientado en que la prueba debe comenzar lo ms temprano posible en la vida ciclo,
que, como hemos visto en el captulo 1, es uno de los principios fundamental de pruebas
estructurado. Tambin muestra que la prueba no es slo una ejecucin basada en la
actividad. Hay una variedad de actividades que deben ser realizadas antes del final de
la fase de codificacin. 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 ms niveles. Al comenzar el diseo de las pruebas temprano,
los defectos son a menudo encontrados en los documentos bsicos de prueba. Una buena
prctica es tener testers involucrados an ms temprano, durante la revisin de los
documentos bsicos (borrador) de prueba.

El V-modelo es un modelo que ilustra cmo las actividades de prueba (verificacin y

validacin) se pueden integrar en cada fase del ciclo de vida. Dentro el modelo en V, las
pruebas de validacin se lleva a cabo especialmente durante las primeras etapas, por
ejemplo, la revisin de los requisitos de los usuarios, y al final del ciclo de vida, por
ejemplo, durante las pruebas de aceptacin del usuario.

Aunque existen variantes del modelo en V, un tipo comn 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, mdulos, programas, objetos, clases, etc.) que se
comprobable por separado;
Pruebas de integracin: 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 verificacin respecto a los requisitos especificados;
Pruebas de aceptacin: las pruebas de validacin en relacin 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 seccin 2.2.

En la prctica, un modelo en V puede tener ms o menos diferentes niveles de desarrollo
y pruebas, dependiendo del proyecto y el producto de software. Por ejemplo, puede haber
pruebas de integracin de componentes despus de componente sistema de pruebas y pruebas
de integracin despus de las pruebas del sistema. Los niveles de prueba pueden ser
combinados o reorganizado en funcin de la naturaleza del proyecto o de la
arquitectura del sistema. Para la integracin de un off-the-shelf (COTS) de software del
producto en un sistema, un comprador puede realizar slo integracin de pruebas a nivel del
sistema (por ejemplo, la integracin de la infraestructura y otros sistemas) y en una prueba
de fase de recepcin, ms 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 slo un ejemplo. En la prctica vienen diferentes nombres. Las
referencias de los productos genricos 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 ingeniera de sistemas e ingeniera
de software. Proporciona una gua sobre dnde enfocar y cmo, con el fin de aumentar el
nivel de madurez de los procesos [Chrissis et ah, 2004]. ISO / IEC 12207 es un estndar de
proceso del ciclo de vida del software integrado que se est convirtiendo rpidamente ms
popular.

2.1.2 ciclos de vida iterativos

No todos los ciclos de vida son secuenciales. Tambin hay iterativo o incremental de
vida ciclos en los que, en lugar de una gran lnea de tiempo de desarrollo de principio a fin,
que pasar por una serie de fases del ciclo de vida ms pequeos autnomos para el
mismo proyecto. Al igual que con el modelo en V, hay muchas variantes de la vida iterativo
ciclos.

Una caracterstica comn de los enfoques iterativos es que la entrega se divide en

incrementos o construye con cada incremento de aadir nuevas funcionalidades. El
inicial Valor mnimo contendr la infraestructura necesaria para apoyar la
construccin inicial funcionalidad. El incremento producido por una iteracin puede
ser probado en varios los niveles como parte de su desarrollo. Los incrementos
subsiguientes necesitarn pruebas para la nueva funcionalidad, pruebas de regresin de la
funcionalidad existente, e integracin de las pruebas existentes y nuevas piezas. Las pruebas
de regresin es cada vez ms importante en todas las iteraciones despus de la
primera. Esto significa que ms 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 crtica, puede ser ms fcil de manejar
debido a la carga de trabajo se divide en partes ms pequeas piezas, y pueden reducir
la inversin inicial aunque puede costar ms en el largo correr. Adems presencia en el
mercado a principios significar pruebas de validacin 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

rpido 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 explicacin de ambos RAD y se proporciona el desarrollo gil.

Desarrollo rpido de aplicaciones

Desarrollo rpido de aplicaciones (RAD) es formalmente un desarrollo paralelo de funciones
y posterior integracin.
Componentes / funciones se desarrollan en paralelo como si fueran mini proyectos, los
desarrollos son encajadas en tiempo, entregado, y despus montarlo en una prototipo
de trabajo. Esto puede dar muy rpidamente al cliente algo para ver y utilizar y ofrecer
informacin relacionada con la entrega y sus requisitos.

El rpido cambio y el desarrollo del producto son posible al uso de esta metodologa. Sin
embargo tendr que ser desarrollado para el pliego de condiciones producto en algn
momento, y el proyecto tendr que ser colocado bajo ms controles formales antes de entrar
en produccin.

Esta metodologa permite temprana validacin de los riesgos de la tecnologa y una respuesta
rpida a las cambiantes del cliente requisitos.

Metodologa de Desarrollo de Sistema Dinmico [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 todava tiene que tener los elementos esenciales
de buenas prcticas de desarrollo en su lugar a fin de que estas metodologas a
trabajo. Tenemos que mantener una estricta gestin de la configuracin de los rpidos
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 actualizacin nuestros planes regularmente como las cosas van a cambiar muy rpidamente
(vase el captulo 5 para ms en los planes de prueba).

El proceso de desarrollo RAD estimula la regeneracin de cliente activo. El cliente obtiene

una visibilidad temprana del producto, puede proporcionar informacin sobre el diseo y se
puede decidir, basndose en la funcionalidad existente, ya sea para proceder con el desarrollo,
lo que la funcionalidad para incluir en la prxima ciclo de entrega o incluso para detener el
proyecto si no est entregando la espera valor. Una solucin centrada en el negocio temprano
en el mercado da un temprano retorno de la inversin (ROI) y puede proporcionar
informacin valiosa de la comercializacin para el negocio. Validacin 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 ms conocida Los modelos del
ciclo de vida de desarrollo. (Vase [gil] para las ideas detrs de este enfoque.)

La metodologa pretende ser ms humana de usar que los mtodos de desarrollo del ambiente
tradicional. Algunas caractersticas de XP son:
Promueve la generacin de historias de negocios para definir la funcionalidad.
Exige un cliente in situ de retroalimentacin continua y para definir y llevar a cabo
las pruebas de aceptacin funcional.
Promueve la programacin en parejas y la propiedad de cdigo compartido entre
desarrolladores.
Se establece que los scripts de prueba de componentes debern ser escritos antes de
que el cdigo es escritos y que esas pruebas deben ser automatizados.
Afirma que la integracin y las pruebas del cdigo debern ocurrir varias veces un
da.
Afirma que se ha puesto en prctica la solucin ms 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 cdigo se prueba componente y luego integrado con el cdigo
existente, que luego es totalmente integracin a prueba utilizando el conjunto completo
de pruebas casos. Esto le da a la integracin continua, por lo que entendemos que los
cambios son incorporados de forma continua en la compilacin 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 aadido 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 caractersticas de
buena prueba:
Para cada actividad de desarrollo hay una actividad pruebas correspondientes;
Cada nivel de prueba tiene objetivos especficos de prueba a ese nivel;
 El anlisis y diseo de pruebas para un nivel dado de ensayo deberan comenzar
durante la actividad de desarrollo correspondiente;
Testers deben participar en la revisin de documentos tan pronto como borradores
estn disponibles en el ciclo de desarrollo.

2.2 NIVELES DE PRUEBA

1 Comparacin de los diferentes niveles de comprobacin: principales objetivos, objetos
tpicos de las pruebas, los objetivos tpicos 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 Seccin 2.1. En esta seccin se ve en ms

detalle en los distintos niveles de prueba. Las caractersticas clave para cada nivel de prueba
se discuten y definen para ser capaz de separar ms claramente las diversas pruebas los
niveles. Una comprensin profunda y la definicin de los distintos niveles de la prueba se
identificar las reas que faltan y evitar el solapamiento y la repeticin. A veces podemos
desear introducir solapamiento deliberado para hacer frente a riesgos
especficos. Comprensin si queremos que se superpone y la eliminacin de las brechas har
que los niveles de ensayo ms complementaria lo que conduce a la prueba ms eficaz y
eficiente.

2.2.1 Pruebas de componentes

Pruebas de componentes, tambin conocido como unidad, mdulo y programa de

pruebas, el objetivo es la bsquedas de defectos, y verifica el funcionamiento del
software (por ejemplo, mdulos, 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 ms 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 taln 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 especfica

caractersticas funcionales, tales como recursos en el comportamiento (por ejemplo,
prdidas de memoria), per-rendimiento o la comprobacin de la solidez, as como pruebas
estructurales (por ejemplo, la decisin cobertura). Los casos de prueba se derivan de los
productos de trabajo, tales como el software diseo o el modelo de datos.
Tpicamente, la prueba de componentes se produce con el acceso al cdigo siendo probado
y con el apoyo del entorno de desarrollo, tales como un marco de pruebas unitarias trabajar
o una herramienta de depuracin, y en la prctica por lo general implica el programador que
escribi el cdigo. 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 tpicamente 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 programacin extrema
(XP), es para preparar y automatizar casos de prueba antes de la codificacin. 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 continuacin,
la construccin y la integracin de pequeos piezas de cdigo, y la ejecucin de las pruebas
de componentes hasta que pasan.

2.2.2 Las pruebas de integracin

Pruebas de integracin Pruebas de interfaces entre componentes, interacciones de

diferentes partes de un sistema tal como un sistema operativo, sistema de archivos y
hardware cermica o interfaces entre sistemas. Tenga en cuenta que las pruebas de
integracin deben ser diferenciadas de otras actividades de integracin. Las pruebas de
integracin son a menudo llevadas a cabo por el integrador, pero preferiblemente por un
tester de integracin especfica o equipo de pruebas.

Puede haber ms de un nivel de pruebas de integracin y que puede haber llevado a

cabo sobre los objetos de prueba de tamao variable. Por ejemplo:
Pruebas de integracin de componentes pone a prueba la interaccin entre el software
de componentes y se lleva a cabo despus de la prueba de componentes;
Pruebas de integracin de sistemas a prueba las interacciones entre diferentes sistemas
y puede hacerse despus de las pruebas del sistema. En este caso, el desarrollo de
Organizacin puede controlar slo 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 integracin, ms difcil se hace para aislar fracasos
a una interfaz especfica, que puede conducir a un mayor riesgo. Esto lleva en diversos
enfoques para las pruebas de integracin. Un extremo es que todos los componentes o
sistemas estn integrados al mismo tiempo, despus de lo cual todo lo que se pone a
prueba como un todo. Esto se llama 'big-bang' pruebas de integracin. Pruebas de big-
bang tiene la ventaja de que todo est terminado antes del comienzo de las pruebas de
integracin. Ah esta no hay necesidad de simular (an sin terminar) partes. La principal
desventaja es que en general, es mucho tiempo y es difcil de encontrar la causa de los
fallos con este la integracin tarda. Por lo tanto la integracin del big-bang puede parecer
una buena idea en la planificacin del proyecto, siendo optimista y esperando encontrar
ningn problema. Si uno piensa pruebas de integracin encontrar defectos, es una buena
prctica considerar si el tiempo se salve por romper el proceso de pruebas de integracin.
Otro extremo es que todos los programas estn integrados uno a uno, y una prueba es llevado
a cabo despus 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 ms pequeo cuando es relativamente fcil 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 integracin creciente se
debe ir probando una gama de posibilidades de existir, en parte, en funcin del sistema
arquitectura:

De arriba hacia abajo: la prueba se lleva a cabo, de arriba a abajo, siguiendo el flujo
de control o estructura arquitectnica (por ejemplo, a partir de la interfaz grfica 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 integracin y las pruebas se lleva a cabo sobre la base de
las funciones o funcionalidades, como se documenta en la especificacin funcional.
La secuencia de integracin preferida y el nmero de pasos de integracin requerida
depender de la ubicacin en la arquitectura de las interfaces de alto riesgo.

La mejor opcin es comenzar con la integracin de las interfaces que se espera causa ms
problemas. Hacer esto impide que los principales defectos en el extremo de la integracin
fase de prueba. Con el fin de reducir el riesgo de descubrimiento defecto tarde,
integracin debe normalmente ser incrementales en lugar de 'big-bang'. Lo ideal sera
que los testers deben entender la planificacin de la arquitectura y la influencia de
integracin. Si integracin pruebas estn previstas antes de construir componentes o
sistemas, pueden ser desarrollado en el orden requerido para las pruebas ms eficiente.
En cada etapa de la integracin, los testers se concentran nicamente en la integracin en s
mismo. Por ejemplo, si se estn integrando el componente A con el componente B se
estn interesados en probar la comunicacin entre los componentes, no el funcionalidad
de cualquiera de ellos. Ambos enfoques funcionales y estructurales pueden estar usado. Las
pruebas de concreto caractersticas no funcionales (por ejemplo, el rendimiento) puede
tambin deben incluirse en las pruebas de integracin. Las pruebas de integracin se puede
llevar a cabo por los desarrolladores, pero se puede hacer por un equipo independiente de la
integracin 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 especificacin de requisitos, procesos de
negocio, casos de uso, u otras descripciones de alto nivel de comportamiento del sistema,
las interacciones con la operacin del sistema, y los recursos del sistema. Las pruebas del
sistema es lo ms a menudo en la prueba final nombre de desarrollo para verificar que el
sistema para ser entregado encuentra con la especificacin y su finalidad pueden ser encontrar
tantos defectos como sea posible. Ms 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 ms el nivel necesario de independencia est en funcin
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 tpicas incluyen el rendimiento y
fiabilidad. Testers tambin 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) tcnicas basadas en las especificaciones apropiadas para el aspecto del
sistema a prueba. Por ejemplo, una tabla de decisin puede ser creada para
combinaciones de efectos que se describen en las reglas de negocio. Basado en la
estructura (caja blanca) tcnicas tambin pueden utilizarse para evaluar la minuciosidad de
los elementos de prueba tales como la estructura de dilogo o men de navegacin pgina
web (vase el captulo 4 para ms informacin sobre la diversos tipos de la tcnica).

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 (vase el
Captulo 5 para ms informacin sobre la gestin de configuracin). Una prueba del sistema
es ejecutado por la organizacin de desarrollo en un (debidamente controlada) entorno
ambiente. El entorno de prueba debe corresponder a la diana o la produccin final
entorno tanto como sea posible con el fin de minimizar el riesgo de medio ambiente- fallas
especficas no se encontraron por medio de pruebas.

2.2.4 Las pruebas de aceptacin

Cuando la organizacin de desarrollo ha realizado su prueba del sistema y tiene la
correlacin de todos o la mayora de los defectos, el sistema ser entregada al usuario o
cliente para. La prueba de aceptacin

La prueba de aceptacin debe responder a preguntas como:

"Puede ser puesto en libertad el sistema?", "Qu, si los hay, son la circulacin (de
negocios) riesgos? ' y 'Ha cumplido con sus obligaciones de desarrollo?'. Las pruebas
de aceptacin es ms a menudo la responsabilidad del usuario o cliente, aunque otras
partes interesadas pueden estar involucrados tambin. La ejecucin de la prueba de
aceptacin requiere una prueba ambiente que es para la mayora de los aspectos,
representativa de la produccin ambiental ( "como si la produccin ').

El objetivo de las pruebas de aceptacin es establecer la confianza en el sistema, parte

del sistema o caractersticas no funcionales especficos, por ejemplo la facilidad de uso,
del sistema. Las pruebas de aceptacin ms a menudo se centran en un tipo de
validacin de las pruebas, por lo que estamos tratando de determinar si el sistema es
adecuado para el propsito.
Encontrar defectos no debe ser el foco principal de las pruebas de aceptacin. A pesar
de esto evala la disposicin del sistema para el despliegue y uso, no es necesariamente
el nivel final de la prueba. Por ejemplo, una prueba de integracin de sistemas a gran escala
puede vendr despus de la aceptacin de un sistema.
Las pruebas de aceptacin pueden ocurrir en ms de un solo nivel, por ejemplo:
 Un Comercial Off El producto de software (COTS) puede ser de aceptacin probado
cuando se instala o integrado.
Las pruebas de aceptacin de la usabilidad de un componente puede hacerse durante
comprueba componente.
Las pruebas de aceptacin de una nueva mejora funcional puede venir antes las
pruebas del sistema.

Dentro de la prueba de aceptacin para un sistema de negocio de apoyo, dos principal prueba
tipos se pueden distinguir; como resultado de su carcter especial, son generalmente
preparado y ejecutado por separado. La prueba de aceptacin 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 aceptacin operativa (tambin
llamada la produccin de prueba de aceptacin) valida si el sistema se encuentra con el los
requisitos para el funcionamiento. La prueba de aceptacin del usuario se realiza por
la los usuarios y los administradores de la aplicacin. En cuanto a la planificacin, la
aceptacin 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 nmero de subsistemas ms o menos independientes, la prueba de
aceptacin para una subsistema que cumple con los criterios de salida de la prueba del sistema
puede comenzar mientras otro subsistema puede estar todava en la fase de prueba del
sistema. En la mayor organizacin, la administracin del sistema llevar a cabo la prueba de
aceptacin operativa poco antes de que el sistema se libera. La prueba de aceptacin
operacional puede incluir la prueba de copia de seguridad / restauracin, recuperacin
de desastres, las tareas de mantenimiento y comprobacin peridica de
vulnerabilidades de seguridad.

Otros tipos de pruebas de aceptacin que existen son las pruebas de aceptacin del
contrato y pruebas de aceptacin del cumplimiento. Se realiza la prueba de aceptacin
del contrato en contra de los criterios de aceptacin de un contrato para la produccin
de encargo desarrollado. La aceptacin debe estar formalmente definida cuando se
acord el contrato.
Se realizaron pruebas de aceptacin cumplimiento o pruebas de aceptacin regulacin
en contra de las normas que se deben cumplir, como gubernamental, jurdica 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
prctico 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 aceptacin
prueba. El primero se llama alfa de prueba. Esta prueba se lleva a cabo en el desarrollo
en el sitio de operaciones. Una seccin transversal de los usuarios potenciales y los
miembros de la promotora de organizacin estn invitados a utilizar el sistema. Los
desarrolladores observan los usuarios y en cuenta problemas. Las pruebas alfa tambin se
puede llevar a cabo por una prueba independiente equipo. Pruebas beta, o pruebas de
campo, enva el sistema a una seccin transversal de los usuarios que instalarlo y utilizarlo
en condiciones de trabajo del mundo real. Los usuarios envan registros de incidentes
con el sistema de la organizacin de desarrollo, donde los defectos se reparan.
Tenga en cuenta que las organizaciones pueden utilizar otros trminos, tales como la
recepcin en fbrica verificacin y conformidad de laboratorio de ensayo para los sistemas
que se ponen a prueba antes y despus siendo trasladado a las instalaciones del cliente.

2.3 Tipos de pruebas: LOS OBJETIVOS DE LA VERIFICACIN

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 Identificacin y descripcin de los tipos de pruebas no funcionales basados en la no
Funcional requisitos. (K2)
4 Identificacin y descripcin de los tipos de pruebas basadas en el anlisis de una
Software estructura o arquitectura del sistema. (K2)
5 Describir el propsito de las pruebas de confirmacin y pruebas de regresin. (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 especfica y, por lo tanto, la seleccin
del tipo apropiado de prueba ayuda a preparar y comunicar decisiones en contra
objetivos de la prueba ms fcil.

Un tipo de prueba se centra en un objetivo de la prueba particular, el cual podra ser la

prueba de una funcin que se lleva a cabo por el componente o sistema; una caracterstica
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 confirmacin, o volver a la prueba) y en busca de
cambios no deseados (pruebas de regresin). En funcin de su objetividad, las pruebas se
organizarn de manera diferente. Por ejemplo, la prueba de componentes el objetivo de
rendimiento sera muy diferente a las pruebas de componentes dirigida a lograr la cobertura
decisin.

2.3.1 Pruebas de la funcin (pruebas funcionales)

La funcin de un sistema (o componente) es 'lo que hace'. Esto es tpicamente se
describe en una especificacin de requisitos, una especificacin funcional, o en casos de
uso. Puede haber algunas funciones que se "supone" que debe proporcionarse que no estn
documentados que son tambin parte de la necesidad de un sistema, aunque es difcil de
probar en contra de los requisitos de indocumentados e implcitos.
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 especificacin de
componente).
Las pruebas funcionales considera el comportamiento especificado y es a menudo tambin
se refiri como las pruebas de caja negro. Esto no es del todo cierto, ya que las pruebas de
caja negro tambin incluye pruebas no funcionales (vase la Seccin 2.3.2).
La funcin (o funciones) de pruebas pueden, en base a la norma ISO 9126, concentrarse
sobre la idoneidad, la interoperabilidad, la seguridad, precisin y
cumplimiento. Seguridad pruebas, por ejemplo, investiga las funciones (por ejemplo, un
firewall) en relacin con detectores de amenazas, como virus, de los extraos 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 especificacin del requisito funcional
para el sistema como la base para el diseo de pruebas. Una buena manera de empezar es
utilizar la tabla de contenido de la especificacin de requisitos como prueba inicial inventario
o lista de elementos para poner a prueba (o no para poner a prueba). Tambin hay que dar
prioridad a las necesidades basadas en criterios de riesgo (si esto no se ha hecho ya en la
especificacin) y usar esto para dar prioridad a las pruebas. Esto asegurar que el ms
importante y las pruebas ms 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 da a
da uso del sistema. Por ejemplo, un sistema de personal y nmina puede tener un proceso
de negocio a lo largo de las lneas de: alguien se une a la compaa, 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 da muy popular en muchos ambientes
del desarrollo del ciclo de vida. Tambin 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 tcnicas utilizadas para las pruebas funcionales son a menudo basada en la
especificacin, pero tcnicas basadas en la experiencia tambin se pueden utilizar (vase el
captulo 4 para ms informacin sobre la prueba tcnicas). Condiciones de prueba y casos
de prueba se derivan de la funcionalidad del componente o sistema. Como parte del
diseo de prueba, un modelo puede ser desarrollado, como un modelo de proceso, el
modelo de transicin de estado o una especificacin en lenguaje claro.

2.3.2 prueba de las caractersticas del producto de software (Pruebas no funcionales)

Un segundo objetivo de la prueba es la prueba de las caractersticas de calidad, o no
atributos funcionales del sistema (o componente o la integracin del grupo). Aqu estamos
interesados en qu tan bien o algo rpido que se hace. Estamos probando algo que
necesitamos medir en una escala de medicin, 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 estrs, 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 caractersticas y
relacionarlas con sub-caractersticas. En algunos de estos modelos algunas caractersticas
elementales siguen apareciendo, aunque su lugar en la jerarqua puede ser diferente. Los
Organizacin Internacional de Normalizacin (ISO) ha definido un conjunto de
caractersticas 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 nocin general de la calidad
del software. La norma ISO 9126 define seis caractersticas de calidad y la subdivisin
de cada caracterstica de calidad en un nmero de sub-caractersticas. Esta norma es
cada vez ms y ms reconocimiento en el la industria, lo que permite el desarrollo, prueba y
las partes interesadas para utilizar una terminologa comn para las caractersticas de calidad
y por lo tanto para no funcional pruebas.
Las caractersticas y sus sub-caractersticas son, respectivamente:
Funcionalidad, que consta de cinco sub-caractersticas: idoneidad, exactitud, la
seguridad, la interoperabilidad y el cumplimiento; esta caracterstica se ocupa de
funcional de pruebas tal como se describe en la Seccin 2.3.1;
Fiabilidad, que se define adicionalmente en la madurez sub-caractersticas (Robustez),
tolerancia a fallos, capacidad de recuperacin y el cumplimiento;
Facilidad de uso, que se divide en la comprensibilidad sub-caractersticas, facilidad de
aprendizaje, operabilidad, el atractivo y el cumplimiento;
Eficiencia, que se divide en comportamiento en el tiempo (rendimiento), utilizacin de
recursos y el cumplimiento;
Facilidad de mantenimiento, que se compone de cinco sub-caractersticas:
analizabilidad, mutabilidad, la estabilidad, la capacidad de prueba y el cumplimiento;
Portabilidad, que tambin consta de cinco sub-caractersticas: capacidad de
adaptacin, capacidad de instalacin, 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 ms a menudo como una forma de medir la minuciosidad

de las pruebas a travs de la cobertura de un conjunto de elementos estructurales o
cobertura artculos. Puede ocurrir a cualquier nivel de la prueba, si bien es cierto que
tiende a ser principalmente aplicado en componente y la integracin y, en general es
menos probable en ms altos niveles de la prueba, a excepcin de las pruebas de los procesos
empresariales. En la integracin de componentes nivel que puede estar basada en la
arquitectura del sistema, tal como una jerarqua de llamada. Un sistema, integracin de
sistema, vs base de pruebas, pruebas del sistema, integracin de sistemas o aceptacin podra
ser una modelo de negocio o estructura del men.
A nivel de componentes, y en menor medida en la integracin de componentes las pruebas,
hay una buena herramienta de apoyo para medir la cobertura de cdigo. Cobertura
herramientas de medicin evaluar el porcentaje de elementos ejecutables (por ejemplo,
declaracin tos o los resultados de decisin) 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 an no han sido ejercidos. Esta
por supuesto depende de los criterios de salida. (Tcnicas de cobertura se cubren en Captulo
4.)
Las tcnicas utilizadas para pruebas estructurales son tcnicas basadas en la estructura,
tambin se hace referencia como tcnicas 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 confirmacin de pruebas de regresin)

El objetivo final de la prueba es la prueba de los cambios. Esta categora es ligeramente di-
rentes a los dems, 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 especficos de pruebas relativas
a cambios, a pesar de que incluya todos los otros tipos de pruebas.

Las pruebas de confirmacin (repeticin 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 versin 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
confirmacin prueba (tambin conocido como re-prueba).
Al hacer las pruebas de confirmacin, 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 correccin
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 regresin.

Pruebas de regresin
Al igual que las pruebas de confirmacin, pruebas de regresin implica que los casos de
prueba de ejecucin han sido ejecutados antes. La diferencia es que, para la prueba de
regresin, los casos de prueba, probablemente, pasaron la ltima vez que fueron
ejecutados (comprese esto con los casos de prueba ejecutados en las pruebas de
confirmacin - fallaron la ltima vez).

El trmino 'pruebas de regresin " es un trmino equivocado. Sera mejor si se llama

prueba "anti-regresin" porque estamos llevando a cabo pruebas con el intencin de
verificar que el sistema no ha retrocedido (es decir, no lo hace ahora tienen ms defectos
en ella como resultado de algn cambio). Ms especficamente, el propsito de las pruebas
de regresin es verificar que las modificaciones en el software o el medio ambiente no
han causado efectos secundarios adversos no deseados y que el sistema todava cumple
sus requisitos.
Es comn que las organizaciones tienen por lo general lo que se denomina una prueba
de regresin suite o paquete de pruebas de regresin. Se trata de un conjunto de casos
de prueba que se utiliza especficamente para pruebas de regresin. Estn diseados
para ejercer colectivamente la mayora de las funciones (ciertamente las ms
importantes) en un sistema, pero no probar cualquiera en detalle. Es conveniente
contar con un conjunto de pruebas de regresin en cada nivel de la prueba (componente
las pruebas, las pruebas de integracin, pruebas del sistema, etc.). Todos los casos de
prueba en una regresin se ejecutan un conjunto de pruebas cada vez que se produce
una nueva versin del software esto los hace candidatos ideales para
la automatizacin. Si el conjunto de pruebas de regresin es muy grande que sea ms
apropiado para seleccionar un subconjunto para su ejecucin.

Pruebas de regresin se ejecutan cada vez que cambia de software, ya sea como
consecuencia de correcciones o funcionalidad nueva o modificada. Tambin es una buena
idea para ejecutarlos cuando algn aspecto de los cambios del entorno, por ejemplo, cuando
una nueva versin de un sistema de gestin de base de datos o se introduce una nueva versin
de un cdigo fuente se utiliza compilador.

El mantenimiento de un conjunto de pruebas de regresin debe llevarse a cabo de modo

que evoluciona el tiempo de acuerdo con el software. A medida que se aade una nueva
funcionalidad a un sistema de nuevas pruebas de regresin deben ser aadidos o se cambia
la funcionalidad tan antigua o eliminan tambin lo debe de regresin pruebas pueden cambiar
o quitar. A medida que nuevas pruebas se aaden un conjunto de pruebas de regresin 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
regresin. En este caso un subconjunto de los casos de prueba tiene que ser elegido.

Esta seleccin debe hacerse a la luz de los ltimos cambios que se han hecho al software. A
veces, un conjunto de pruebas de regresin 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 regresin 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 eliminacin 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 Comparacin de las pruebas de mantenimiento (chequeo de un sistema operativo) a
pruebas una nueva aplicacin 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, migracin

y Jubilacin). (K2)

3 Describir el papel de las pruebas de regresin y anlisis de impacto en el

mantenimiento. (K2)

Una vez desplegado, el sistema es a menudo un servicio durante aos o incluso

dcadas. 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 fcil 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 tamao y el riesgo de los cambios hechos, varios los niveles de
las pruebas se llevan a cabo: una prueba de componentes, una prueba de integracin, un
sistema de prueba y una prueba de aceptacin. Un proceso de prueba de mantenimiento
por lo general comienza con la recepcin 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 recepcin de la nueva o modificada especificaciones, los casos de prueba
correspondientes se especifican o adaptados. Tras la recepcin del objeto de prueba, los
nuevos y modificados ensayos y las pruebas de regresin se ejecutan.
Al trmino de la prueba, se conserva una vez ms la testware.
La comparacin de las pruebas de mantenimiento para probar una nueva aplicacin no es
ms que una cuestin de una aproximacin desde un ngulo diferente, que da lugar a una
serie de cambios de nfasis. Hay varias reas donde la mayora de las diferencias ocurrir, por
ejemplo con respecto a la base de pruebas. Una operacin de "puesta a nivel es con
frecuencia se requiere cuando se mantienen sistemas. Las especificaciones estn menudo
'perdido', y un conjunto de testware relativa a las especificaciones simplemente No
existe. Bien puede ser posible llevar a cabo esta operacin de puesta al da accin junto con
la prueba de una nueva versin 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
orculo de pruebas, se debe buscar como solucin de compromiso. Una bsqueda debe ser
realizada para la documentacin que es ms 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 atencin del cliente a la calidad de la prueba inferior que puede
ser alcanzado. Ser conscientes de los posibles problemas de "produccin 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 difcil de rastrear de nuevo
a el defecto real, ya que no trazabilidad para probar diseos y / o requisitos existe. Tenga en
cuenta que la reproducibilidad de las pruebas tambin es importante para las pruebas
de mantenimiento.
Un aspecto que, en muchos casos, difiere un poco del desarrollo situacin es la organizacin
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 organizacin peridica. 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 Anlisis del impacto y pruebas de regresin

Por lo general, las pruebas de mantenimiento constarn de dos partes:
Pruebas de los cambios
Pruebas de regresin para mostrar que el resto del sistema no se ha visto afectada por los
trabajos de mantenimiento.
Adems de las pruebas de lo que se ha cambiado, las pruebas de mantenimiento incluye
extensas pruebas de regresin para las partes del sistema que no han sido
cambiado. Una de las principales actividades e importante dentro de las pruebas de
mantenimiento es anlisis de impacto. Durante el anlisis del impacto, junto con las
partes interesadas, una decisin se hace sobre qu partes del sistema pueden verse
afectados involuntariamente y por lo tanto necesitan pruebas de regresin cuidado. El
anlisis de riesgos ayudar a decidir dnde enfocar las pruebas de regresin 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 regresin 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.
Extensin o mejora del sistema pueden significar nuevas reas han sido especificado y las
pruebas se elaborarn al igual que para el desarrollo. Tambin es posible que las
actualizaciones son necesarias para un conjunto de pruebas automatizadas, que a menudo se
utiliza para apoyar las pruebas de regresin.

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 migracin, o la jubilacin 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 recin expuestas o descubrir vulnerabilidades del
sistema operativo. Pruebas de mantenimiento para la migracin (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 migracin de datos o archivo, si Se requieren perodos de retencin de
datos a largo.
Puesto que las modificaciones son ms a menudo la parte principal de mantenimiento pruebas
la mayora de las organizaciones, esto se discutir en ms detalle. Desde el punto de vista
de la prueba, hay dos tipos de modificaciones. Hay modificaciones en cuales se podrn
planificarse, y hay modificaciones correctivas ad-hoc, que no se puede planificar en
absoluto. Mantenimiento correctivo Ad-hoc se lleva a cabo cuando la bsqueda de
soluciones a los defectos no se puede retrasar. Procedimiento de prueba especial se
requiere en ese momento.

Modificaciones previstas
Los siguientes tipos de modificacin prevista se pueden identificar:
Modificaciones perfectivas (adaptacin del software a los deseos del usuario, por
ejemplo, mediante el suministro de nuevas funciones o la mejora del rendimiento);
Modificaciones de adaptacin (adaptacin de software a los cambios ambientales, tal
como nuevo hardware, nuevos sistemas de software o una nueva legislacin);
Modificaciones previstas correctivas (correccin de defectos diferible).
El mtodo de prueba estndar estructurado es casi totalmente aplicable a planificada
modificaciones. En promedio, modificacin prevista representa ms 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 solucin, por ejemplo, una serie de produccin que vuelca a altas horas de la
noche, una red que va hacia abajo con unos pocos cientos de usuarios en lnea, un correo con
direcciones incorrectas.
Existen diferentes normas y procedimientos diferentes para la solucin 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 situacin en la que las pruebas sean fiables.

Ser ejecutado a pesar de las estaciones de pnico '' todo el ao. 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 estndar Luego se sigue para establecer
una solucin robusta, probarlo y establecer el nivel apropiado de documentacin.

Un anlisis de riesgos de los sistemas operativos se debe realizar con el fin de establecer
qu funciones o programas constituyen el mayor riesgo para la operacin servicios en
caso de desastre. A continuacin, se establece en el caso de la funciones en situacin de
riesgo que (de prueba) acciones deben llevarse a cabo si un particular, la mala funcin se
produce. Existen varios tipos de mal funcionamiento pueden ser identificados y hay diversas
formas de responder a ellos para cada funcin en riesgo. Una posible reaccin podra ser que
una funcin relevante en riesgo siempre debe ser probado, o que, bajo ciertas circunstancias,
la prueba podra ser realizada, en retrospectiva (el siguiente da, por ejemplo). Si se decide
que una funcin particular en riesgo debe siempre hacerse la prueba siempre que sea
pertinente, una serie de pruebas estndar, que podra ser ejecutada casi inmediatamente,
deben estar preparados para este fin. El estndar pruebas, obviamente, seran 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 adopcin de un enfoque de la prueba especfica. Es importante hacer un
anlisis de riesgos completo del sistema y especificar un conjunto de pruebas estndar en
consecuencia.

Repaso Captulo
Vamos a repasar lo que ha aprendido en este captulo.
De la Seccin 2.1, que ahora debe entender la relacin 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 caractersticas del proyecto y del
producto. Debieras ser capaz de recordar las razones de los diferentes niveles de pruebas
y caractersticas de una buena prueba en cualquier modelo de ciclo de vida. Debieras
conocer los trminos del glosario (comerciales) off-the-shelf software (COTS), el modelo
de desarrollo incremental, nivel de prueba, validacin, verificacin y V-modelo.

De la Seccin 2.2, usted debe saber los niveles tpicos de la prueba.

Usted debe ser capaz de comparar los diferentes niveles de pruebas con respecto a sus
principales objetivos, objetos tpicos de la prueba, tpico los objetivos de la prueba (por
ejemplo, funcional o estructural) y trabajos relacionados productos. Tambin 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 trminos del
glosario alfa las pruebas, las pruebas beta, pruebas de componentes, conductor,
funcional requisitos, la integracin, las pruebas de integracin, no funcional las
pruebas, la puesta a prueba de regulacin de la aceptacin (Pruebas de cumplimiento),
el ensayo, trozo, las pruebas del sistema robustez, basado en pruebas de desarrollo,
entorno de prueba y la aceptacin de los usuarios pruebas.

De la Seccin 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 cmo 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 caractersticas de calidad del producto. Por ltimo, debe ser capaz de
explicar el propsito de las pruebas de confirmacin (re- pruebas) y pruebas de
regresin en el contexto del cambio relacionado pruebas.

Usted debe saber los trminos del glosario de pruebas de recuadro negro, la cobertura de
cdigo, las pruebas de confirmacin (re-prueba), funcionales las pruebas, las pruebas
de interoperabilidad, pruebas de carga, facilidad de mantenimiento pruebas, pruebas
de rendimiento, pruebas de portabilidad, la regresin las pruebas, las pruebas de
fiabilidad, las pruebas de seguridad, la especificacin de base las pruebas, las pruebas
de estrs, pruebas estructurales, banco de pruebas, la facilidad de uso las pruebas y
la caja blanca de pruebas.

De la Seccin 2.4, usted debe ser capaz de comparar el mantenimiento pruebas para
testar nuevas aplicaciones. Deberas ser capaz de identificar los factores desencadenantes
y las razones para las pruebas de mantenimiento, tales como modificaciones, la
migracin y la jubilacin. Por ltimo, debe ser capaz de describir el papel de las pruebas de
regresin y anlisis de impacto dentro de las pruebas de mantenimiento. Usted debe conocer
los trminos del glosario anlisis de impacto y pruebas de mantenimiento.

PREGUNTAS examen de la muestra

Pregunta 1 Cules son las buenas prcticas para las pruebas dentro del ciclo de vida de
desarrollo?
a. anlisis de la prueba y su diseo.
b. Diferentes niveles de prueba se definen con especfica objetivos.
c. Testers comenzarn a involucrarse tan pronto como la codificacin se realiza.
d. A y B anteriores.

Pregunta 2 Qu opcin describe mejor objetivos para los niveles de prueba con un modelo
de ciclo de vida?
a. Los objetivos deben ser genrico 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 especficos de ese nivel.

Pregunta 3 Cul de las siguientes es una prueba tipo?

a. pruebas de componentes segundo. Prueba de funcion
b. Las pruebas del sistema
c. Test de aceptacin

Pregunta 4 Cul de los siguientes es un no caracterstica de la calidad funcional?

a. Factibilidad
b. usabilidad
c. Mantenimiento
d. Regresin

Pregunta 5 Cul de estos es una prueba funcional?

a. La medicin de tiempo de respuesta en una lnea de reserva sistema.
b. Comprobacin del efecto de grandes volmenes de trfico en un sistema de centro de
llamadas.
c. Comprobacin de la pantalla informa reservas on-line contenidos y la base de datos contra
el Informacin sobre la carta a los clientes.
d. Comprobar qu fcil es el sistema de usar.

Pregunta 6 Cul de los siguientes es un verdadero declaracin en relacin con el proceso de

fijacin cambios de emergencia?
a. No hay tiempo para probar el cambio antes de que va en vivo, por lo que slo los mejores
desarrolladores deben hacer este trabajo y no debe involucrar a los testers como ellos
ralentizar el proceso.
b. Slo tiene que ejecutar la segunda prueba del defecto realidad fijo.
c. Siempre ejecutar una prueba de regresin 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 evaluacin para decidir sobre un
subconjunto razonable de toda la prueba de regresin para ejecutar en caso de otra partes del
sistema han sido adversamente afectado.

Pregunta 7 Una prueba de regresin:

a. Es slo 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 aprobacin del usuario para el sistema.
d. Prueba de una caracterstica del sistema utilizando slo el software requerido para esa
funcin.
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 especfico cliente o usuario.
 CAPTULO TRES tcnicas estticas
tcnicas de pruebas estticas constituyen una forma eficaz de mejorar la calidad y la
productividad de software desarrollo. En este captulo se describen las tcnicas de
verificacin esttica, incluyendo opiniones y proporciona una visin general de la forma en
que se llevan a cabo. El objetivo fundamental de una prueba esttica 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 tcnicas
de pruebas estticas no van a resolver todos los problemas, son enormemente
eficaces. tcnicas estticas pueden mejorar tanto la calidad como la productividad por
factores impresionantes.
Pruebas estticas no es magia y no debe ser considerado como un reemplazo para la prueba
dinmica, pero todas las organizaciones deben considerar el uso de software de revisin en
todos los principales aspectos de su trabajo, incluyendo requisitos, diseo, implementacin,
pruebas y mantenimiento. herramientas de anlisis esttico implementan controles
automticos, por ejemplo en cdigo.
S

3.1 COMENTARIOS Y EL PROCESO DE PRUEBA

1 Reconocer los productos de trabajo de software que pueden ser examinadas por las
diferentes tcnicas estticas. (KL)
2 Describir la importancia y el valor de considerar tcnicas estticas para la evaluacin
de los productos de trabajo de software. (K2)
3 Explica la diferencia entre las tcnicas estticas y dinmicas. (K2)

En el captulo 1, varias pruebas se presentaron trminos. Tambin prueba en s se defini. La

ltima definicin se repite aqu como medio para explicar los dos tipos principales de la
prueba.
La definicin de la prueba describe los objetivos que se relacionan con la evaluacin,
que revela los defectos y calidad. Como se indica en la definicin dos enfoques pueden ser
utilizados para alcanzar estos objetivos, las pruebas estticas y prueba dinmica.

Con los mtodos de prueba dinmicos, 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 esttica, productos de trabajo de software se examinan
manualmente o con un conjunto de herramientas, pero no se ejecuta. Como
consecuencia, la prueba dinmica slo se puede aplicar al cdigo de software. Ejecucin
dinmica se aplica como una tcnica para detectar defectos y para determinar los atributos
de calidad del cdigo. Esta opcin de prueba es no aplicable para la mayora de los productos
de trabajo de software. Entre la cuestin que surgen son: Cmo podemos evaluar o
analizar un documento de requisitos, un documento de diseo, un plan de pruebas, o
un manual de usuario? Cmo podemos efectivamente pre-examinar el cdigo fuente
antes de la ejecucin? Una tcnica poderosa que puede ser usada es la prueba esttica,
por ejemplo, una revisin. En principio, todos los productos de software pueden ser
probados usando tcnicas de revisin.
Las pruebas dinmicas y pruebas estticas son mtodos complementarios, ya que
tienden a encontrar diferentes tipos de defectos de forma eficaz y eficiente. Tipos de
defectos que son ms fciles de encontrar durante las pruebas estticas son:
desviaciones de las normas, falta requisitos, defectos de diseo, cdigo no tienen
mantenimiento y especificaciones inconsistentes de la interfaz. Tenga en cuenta que, en
contraste con las pruebas dinmicas, pruebas estticas encuentra defectos en lugar de
fracasos.
Adems de encontrar defectos, los objetivos de las revisiones son a menudo tambin
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 lnea base para un producto de software. El tipo y la cantidad
de defectos encontrados durante las revisiones tambin pueden ayudar a los testers a
centrar su prueba y seleccionar clases de pruebas efectivas. En algunos casos, los clientes
/ usuarios asisten a la reunin de revisin y proporcionan informacin al equipo de desarrollo,
por lo que las recomendaciones son tambin un medio de la comunicacin / de usuario del
cliente.

Los estudios han demostrado que, como resultado de los exmenes, un aumento significativo
de la productividad y la calidad del producto se puede lograr [Gilb y Graham, 1993], [van
Veenendaal, 1999]. La reduccin del nmero de defectos temprano en la vida del
producto ciclo tambin significa que menos tiempo tiene que ser gastado en pruebas y
mantenimiento. En resumen, el uso de pruebas estticas, revisiones, sobre los productos
de trabajo de software tiene diversas ventajas:

Dado que Las pruebas estticas pueden comenzar temprano en el ciclo de la vida, la
deteccin temprana de defectos y su correccin, por ejemplo, una validacin inicial de las
necesidades del usuario y no slo tarde en el ciclo de vida durante las pruebas de aceptacin.
Mediante la deteccin de defectos en una etapa temprana, trabajo de repaso costes son
ms a menudo relativamente bajo y por lo tanto relativamente barata mejora de la calidad de
producto software se pueden lograr.
Desde la reanudacin esfuerzo se reduce sustancialmente, la productividad de
desarrollo cifras probablemente aumentarn.
La evaluacin por un equipo tiene la ventaja adicional de que existe un intercambio de
informacin entre los participantes.
Pruebas estticas contribuyen a una mayor conciencia de los problemas de calidad.

En conclusin, las pruebas estticas es un mtodo muy adecuado para la mejora de la

calidad de los productos de trabajo de software. Esto se aplica principalmente a la
evaluacin productos en s, pero tambin es importante que la mejora de la calidad es no se
ha logrado una vez, pero tiene un carcter ms estructural. La retroalimentacin del
proceso de pruebas estticas para el proceso de desarrollo permite proceso de mejora,
lo que permite evitar los errores similares que se realizan en el futuro.

PROCESO DE REVISIN 3.2

1 Recordemos las fases, funciones y responsabilidades de una tpica revisin formal.
(KL)
2 Explicar las diferencias entre los diferentes tipos de revisin: Informal revisin,
revisin tcnica, paso a paso y la inspeccin. (K2)
3 Explicar los factores para el desempeo exitoso de comentarios. (K2)

Opiniones varan desde muy informal al formal, (es decir, bien estructurado y regulado).

A pesar de que la inspeccin es quizs la opinin tcnica ms documentada y formal, desde

luego, no es el nico. La formalidad de un proceso de revisin es relacionada con factores
como la madurez del proceso de desarrollo, legal o cualquiera de los requisitos
reglamentarios o la necesidad de una auditora. En la prctica, la opinin informal es quizs
el tipo ms comn de revisin. 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 revisin informal, como el autor puede
pedir a un colega para revisar un documento o cdigo. En etapas posteriores estas opiniones
a menudo implican ms personas y una reunin. Esto normalmente implica colegas del autor,
que tratan para encontrar defectos en el documento sometido a examen y discutir estos
defectos en una reunin de revisin. El objetivo es ayudar a los autores y al mejoramiento de
la calidad de la documento. Revisiones informales vienen en varios tamaos y formas,
pero todas tienen una caracterstica en comn que no estn documentados.

3.2.1 Fases de una revisin formal

En contraste con revisiones informales, las revisiones formales siguen un proceso formal. Un
tpico proceso de revisin formal consta de seis pasos principales:
1 Planificacin
2 Kick-off
3 Preparacin
4 Revisin reunin
5 re-trabajo
6 Seguimiento.

Planificacin
El proceso de revisin para una revisin en particular comienza con una "solicitud de
revisin" por el autor al moderador (o lder de inspeccin). Un moderador a menudo se
asigna a hacerse cargo de la programacin (fechas, hora, lugar y la invitacin) de la
revisin. En un nivel de proyecto, la planificacin del proyecto se necesita para que haya
tiempo para su revisin y la reelaboracin de actividades, lo que proporciona a los
ingenieros tiempo para participar a fondo en las revisiones.

Para ms 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 revisin. Un documento que contiene demasiados
errores obvios es claramente no est listo para entrar en un proceso de revisin formal e
incluso podra ser muy perjudicial para el proceso de revisin. Sera posiblemente de-motivar
tanto a los colaboradores y el autor. Adems, la revisin no es ms probable debido a los
numerosos defectos obvios y menores sern ocultar los defectos importantes.
Aunque cada vez son ms los criterios de entrada se pueden aplicar, lo siguiente puede ser
considerado como el conjunto mnimo para llevar a cabo la inspeccin de entrada:
Una breve comprobacin de una muestra del producto por el moderador (o experto)
no lo hace revelar un gran nmero de defectos importantes. Por ejemplo, despus de 30
minutos de comprobar, no ms de 3 defectos principales se encuentran en una sola pgina o
menos de 10 defectos importantes en total en un conjunto de 5 pginas.
El documento para ser revisado est disponible con los nmeros de lnea.
El documento se sido limpiado por la ejecucin de comprobaciones automticas.
Las referencias necesarias para la inspeccin son estables y disponibles.
El autor del documento se prepara para unirse al equipo de revisin y se siente seguro con
la calidad del documento.

Si el documento pasa la comprobacin de la entrada, el moderador y autor deciden qu

parte del documento va a revisin, debido a que la mente humana puede comprender
un conjunto limitado de pginas a la vez, el nmero no debe ser demasiado alto. El
nmero mximo de pginas depende, entre otras cosas, del objetivo, el tipo de examen y tipo
de documento y debe ser derivado de prctica experiencias dentro de la organizacin. Para
una revisin, el tamao mximo es por lo general entre 10 y 20 pginas. En inspeccin
formal, solamente una o dos pginas pueden ser analizada en profundidad con el fin de
encontrar los defectos ms graves que sean no es obvio.

Despus de que el tamao del documento se ha establecido y las pginas que se han
comprobado sido seleccionado, el moderador determina, en cooperacin con el autor, la
composicin del equipo de revisin. El equipo consiste normalmente entre cuatro y seis
participantes, incluyendo moderador y autor. Para mejorar la eficacia de la opinin, 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
comprobacin. 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 revisin. Los roles representan
vistas del documento objeto de revisin.

Dentro de opiniones los siguientes enfoques pueden ser identificados:

centrarse en los documentos de nivel superior, por ejemplo, el diseo no cumple con los
requisitos;
enfoque en estndares, 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 especficas adicionales y preguntas que tienen que estar
dirigidas. El moderador tiene la opcin de cumplir tambin un papel, junto a la tarea de ser
un lder de opinin. Comprobacin del documento mejora la capacidad del moderador
dirigir la reunin, ya que asegura una mejor comprensin. Adems, mejora la eficiencia
revisin porque el moderador sustituye a un ingeniero que, de otra saba que revisar el
documento y asistir a la reunin. 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 discusin de los defectos encontrados.

Patada inicial
Un paso opcional en un procedimiento de revisin es una reunin de lanzamiento. El
objetivo de este reunin es conseguir que todos estn en la misma longitud de onda en
relacin con el documento sometidas a examen y comprometerse con el tiempo que se gasta
en la comprobacin. Tambin el Resultado del control de entrada y salida definido
criterios se discuten en caso de una mayor revisin formal. En general un saque de salida
es muy recomendable ya que existe un fuerte efecto positivo de una reunin de
lanzamiento de la motivacin de los colaboradores y por lo tanto la eficacia del proceso de
revisin. En las instalaciones del cliente, tenemos hasta 70% de defectos encontrados por
pgina como resultado de la realizacin de un saque de salida, [van Veenendaal y van
der Zwan, 2000]

Durante la reunin de lanzamiento los revisores reciben una breve introduccin en los
objetivos de la revisin y los documentos. Las relaciones entre el documento objeto de
examen y los dems documentos (fuentes) se explican, especialmente si el nmero de
documentos relacionados es alto.

Las asignaciones de funciones, porcentaje de control, las pginas que se comprobarn,

cambios en los procesos y otras posibles preguntas tambin se discuten en esta
reunin. Por supuesto la distribucin del documento objeto de examen, los documentos de
origen y otra documentacin relacionada, tambin se puede hacer durante el inicio del
encuentro.

Preparacin
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
comprensin del documento y el papel. Todos los temas estn grabados, preferiblemente
mediante un formulario de registro. Los errores ortogrficos se registran en el documento
que se revisa, pero no se mencion durante la reunin. El documento anotado ser dado que
el autor al final de la sesin de registro. El uso de listas de control durante esta fase puede
hacer una revisin ms eficaz y eficiente, por ejemplo, una lista especfica de control basado
en perspectivas como usuario, mantenedor, tester u operaciones, o una lista de control para
problemas tpicos de codificacin.

Un factor crtico de xito para una preparacin exhaustiva es el nmero de pginas

comprobadas por hora. Esto se conoce como ndice de comprobacin. La tasa de
comprobacin ptima es el resultado de una combinacin de factores, incluyendo el tipo de
documento, su complejidad, el nmero de documentos relacionados y la experiencia del
revisor.

Por lo general, el porcentaje de control est en el intervalo de cinco a diez pginas por
hora, pero puede ser mucho menos de inspeccin formal, por ejemplo, una pgina por
hora. Durante preparacin, los participantes no deben exceder este criterio. Mediante la
recopilacin de datos y medir el proceso de revisin, los criterios especficos de la empresa
para el control de tasa y el tamao del documento (ver la fase de planificacin) se pueden
establecer, preferentemente especfica a un tipo de documento.

Reunin de revisin
La reunin tpicamente consta de los siguientes elementos (en parte en funcin del tipo
de examen): fase de registro, fase de discusin y la fase de decisin.

Durante la fase de registro de las cuestiones, por ejemplo, defectos, que han sido
identificados durante la preparacin se mencionan pgina por pgina, revisor y por el
revisor se registran ya sea por el autor o por un escriba. Una persona separada para hacer la
extraccin de madera (un escriba) es especialmente til para este tipo de revisin formales
tales como una inspeccin. Para asegurar el progreso y la eficiencia, no se permite
ninguna discusin real durante la fase de registro. Si un problema necesita discusin, el
elemento se registra y procesa, en la fase de discusin. Una discusin detallada sobre si es o
no es un problema es un defecto no es muy significativo, ya que es mucho ms eficiente que
simplemente iniciar sesin y proceder a la siguiente. Por otra parte, a pesar de la opinin del
equipo, un display defecto terco y se desecha bien puede llegar a ser una de verdad durante
la reanudacin.

Cada defecto y su gravedad se van a registrar. El participante que identifique el defecto

propone la gravedad. Los grados de severidad pueden ser:
Crtico: defectos causarn daos aguas abajo; el alcance y el impacto del defecto est ms
all del documento bajo inspeccin.
Mayor, defectos podra causar un efecto aguas abajo (por ejemplo, un fallo en un diseo
puede como resultado generar un error en la aplicacin).
 Menor, los defectos no son susceptibles de causar daos aguas abajo (por ejemplo, no
Cumplimiento con las normas y plantillas), Con el fin de mantener el valor aadido de las
opiniones, errores de ortografa no son parte de la clasificacin de defecto. defectos de
ortografa se observan, por los participantes, en el documento sometido a examen y dado que
el autor al final de la reunin o podra ser tratado en un ejercicio de correccin de pruebas
por separado.

Durante la fase de registro la atencin se centra en capturar la mayor cantidad posible

de defectos dentro de un perodo de tiempo determinado. Para asegurar esto, el
moderador intenta mantener una buena frecuencia de registro (nmero de defectos
registrados por minuta). En una buena y bien dirigida reunin de revisin formal, la
frecuencia de registro debe estar entre uno y dos defectos registrados por minuto.

Para una revisin ms formal, los aspectos clasificados como temas de discusin sern
manipulados durante esta fase. Comentarios informales a menudo no tendrn que disponer
del registro de fase y comenzar inmediatamente con la discusin. El participante puede
participar en la discusin poniendo de relieve sus comentarios y razonamiento. Como
presidente de la reunin de la discusin, 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 discusin puede salir, o mantenerse como un ejercicio
de aprendizaje. El moderador tambin se pasea esta parte de la reunin y garantiza que
todos los artculos tratados o bien tienen un resultado por el final de la reunin, o se
definen como un punto de accin si una discusin no se puede resolver durante la reunin. El
resultado de las discusiones se documenta para el futuro referencia.

Al final de la reunin, una decisin sobre el documento objeto de resea 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 nmero promedio de defectos crticos y / o
principales detectados por pgina (por ejemplo, no ms de tres defectos crticos /
principales por pgina). Si el nmero de defectos detectados por pgina excede cierto nivel,
el documento debe ser revisado de nuevo, despus 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 ms participantes. Posteriormente, el documento
puede salir del proceso de revisin.

Si un proyecto se encuentra bajo presin, el moderador a veces se ver obligado a omitir

la salida del documento con defecto y se realizaran nuevas revisiones. Cuantificar la
configuracin y acordar criterios del nivel de salida ayudan al moderador para tomar
decisiones firmes en todo el tiempo.

Adems del nmero de defectos por pgina, otros criterios de salida se utilizan que miden
la rigurosidad del proceso de revisin, tales como asegurar que todas las pginas han sido
comprobadas a la velocidad adecuada. El nmero promedio de defectos por pgina slo es
un indicador de la calidad vlida 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 razn, se debe informar al menos a indicar que el autor ha
examinado la cuestin.
Los cambios que se realizan en el documento deben ser fciles de identificar y seguir. Por lo
tanto, el autor tiene que indicar dnde 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 distribucin y recoge
las votaciones. Para los tipos ms formales de los controles de revisin el moderador verifica
el cumplimiento a los criterios de salida.

Con el fin de controlar y optimizar el proceso de revisin, una serie de mediciones son
recogidos por el moderador en cada paso del proceso. Ejemplos de tales medidas
incluyen el nmero de defectos encontrados, el nmero de defectos encontrados por
pgina, el tiempo comprobando por pgina, el esfuerzo total de examen, etc. Es la
responsabilidad del moderador para asegurarse de que la informacin es correcta y se
almacenan durante futuros anlisis.

3.2.2 Funciones y responsabilidades

Los participantes en cualquier tipo de revisin formal deben tener conocimientos
adecuados del proceso de revisin. La mejor y ms eficiente, situacin revisin se produce
cuando los participantes a obtener algn tipo de ventaja para su propio trabajo durante la
revisin. En el caso de una inspeccin o revisin tcnica, los participantes deben haber
sido debidamente formados para ambos tipos de revisin han demostrado ser mucho
menos xito con participantes sin formacin. De hecho, esto se percibe como una revisin
de factor de xito.
Las mejores revisones formales provienen de equipos bien organizados, guiados por
personal capacitado moderadores (o lderes de opinin). Dentro de un equipo de
revisin, cuatro tipos de participantes se pueden distinguir: moderador, autor, escriba
y revisor. Adems, en la gestin tiene que desempear un papel en el proceso de revisin.

El moderador
El moderador (o lder de opinin) conduce el proceso de revisin. l o ella determinar, en
cooperacin con el autor, el tipo de revisin, el enfoque y la composicin del equipo de
revisin. El moderador realiza la comprobacin de la entrada y el seguimiento de la
repeticin del trabajo, con el fin de controlar la calidad de la entrada y la salida del
proceso de revisin. El moderador tambin los horarios reuniones, difunde los
documentos antes de la reunin, 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 bsico del autor debe ser
aprender tanto como sea posible en lo que respecta a la mejora de la calidad del
documento, sino tambin 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 reunin, el escriba (o grabadora) tiene que registrar cada defecto
mencionados y cualquier sugerencia para la mejora de procesos. En la prctica es a
menudo el autor que juega este papel, asegurndose 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 (tambin llamadas juegos damas o inspectores) es comprobar
cualquier defectos en el material, sobre todo antes de la reunin. El nivel de rigurosidad
requerida depende del tipo de revisin. El nivel de conocimiento de dominio o experiencia
necesaria para los revisores tambin depende del tipo de revisin.

Los revisores deben ser elegidos para representar diferentes perspectivas y roles en el proceso
de revisin. Adems del documento objeto de examen, los revisores reciben materiales de
revisin incluye documentos fuentes, normas, listas de control, etc. En general, un menor
nmero de fuentes y referencia los documentos proporcionados, ms 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 ejecucin de
revisiones, asigna tiempo en los programas del proyecto y determina si la revisin y los
objetivos del proceso se han cumplido. El gerente tambin se har cargo de cualquier
revision solicitada por los participantes. Por supuesto, un administrador tambin puede ser
involucrados en la revisin en s en funcin de sus antecedentes, la reproduccin del papel
de un revisor si esto sera de gran ayuda.

3.2.3 Tipos de Revisin

Un solo documento puede ser objeto de ms de una revisin. Si ms de un tipo de examen
se utiliza, el orden puede variar. Por ejemplo, una revisin informal puede llevarse a cabo
antes de una revisin tcnica, o la inspeccin se puede llevar en una especificacin de
requisitos antes que una tutora con los clientes. Es evidente que ninguno de los siguientes
tipos de revisin es el "ganador", pero los diferentes tipos sirven para diferentes
propsitos en diferentes etapas en el ciclo de vida de un documento.
Los principales tipos de examen, sus principales caractersticas y objetivos son comunes
descrito abajo.

Tutora
Una tutora se caracteriza porque el autor del documento examina este guiando a los
participantes a travs del documento y de su proceso de pensamiento, para lograr un
entendimiento comn y el intercambio de ideas. Esto es especialmente til si la gente de
fuera de la disciplina de software est presente, que no estn acostumbrados a, o no se puede
entender fcilmente 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 informacin.

Dentro de un paso a paso el autor hace la mayor parte de la preparacin. Los participantes,
que son seleccionados a partir de diferentes departamentos, no se requiere hacer un estudio
detallado de los documentos con antelacin. Debido a la forma en que la reunin se
estructura, un gran nmero de personas que pueden participar y esto mayor audiencia puede
traer un gran nmero de diversos puntos de vista con respecto al contenido del documento en
revisin, as como al servicio del propsito de la educacin. Si el pblico 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 tutora es especialmente til para los
documentos de nivel superior, tales como especificaciones de requisitos y documentos
arquitectnicos.

Los objetivos especficos de un recorrido dependen de su papel en la creacin 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 informacin sobre el tema que se documenta;
Explicar (transferencia de conocimientos) y evaluar el contenido de la documentacin;
Establecer un entendimiento comn del documento;
Examinar y discutir la validez de las soluciones propuestas y la viabilidad de las
alternativas, establecer un consenso.

Las caractersticas clave de los recorridos son:

La reunin est dirigida por los autores; menudo un escriba est presente.
Escenarios y simulacros pueden ser utilizados para validar el contenido.
preparacin previa a la reunin separada para los colaboradores es opcional.

Revisin tcnica
Una revisin tcnica es una reunin de la discusin que se centra en el logro de con-
consenso sobre el contenido tcnico de un documento. En comparacin con inspecciones,
revisiones tcnicas son menos formales y hay poco o ningn nfasis en la identificacin de
defectos sobre la base de documentos de referencia y reglas, destinado lectores. Durante las
revisiones tcnicas se han observado defectos por los expertos, que se centran en el
contenido del documento. Los expertos que se necesitan para una revisin tcnica son,
por ejemplo, arquitectos, jefes de diseo y usuarios clave. En la prctica, las revisiones
tcnicas varan de bastantes informales a muy formal.
Los objetivos de una revisin tcnica son los siguientes:
Evaluar el valor de los conceptos tcnicos y alternativas en el producto y entorno del
proyecto;
Establecer una coherencia en el uso y la representacin de los conceptos tcnicos;
Asegurar, en una etapa temprana, que los conceptos tcnicos se utilizan
correctamente;
Informar a los participantes sobre el contenido tcnico del documento.

Las caractersticas clave de una revisin tcnica son:

Es un proceso de deteccin de defectos documentado que implica compaeros y expertos
tcnicos.
Se realiza a menudo como una revisin por pares y sin gestin de particin.
Lo ideal es que est dirigido por un moderador capacitado, pero posiblemente tambin por
un tcnico experto.
Una preparacin separada se lleva a cabo durante el cual se examin el producto y se
encuentran los defectos.
Ms caractersticas formales tales como el uso de listas de verificacin y una lista de registro
o registro de emisin son opcionales.

Inspeccin
Inspeccin es el tipo ms formal de revisin. El documento bajo inspeccin es redactada
y revisada a fondo por los revisores antes de la reunin, comparacin del producto de
trabajo con sus fuentes y otros documentos de referencia, y usando reglas y listas de
control. En la reunin de la inspeccin son los defectos encontrados registrados y
cualquier discusin se pospone hasta la fase de discusin. Esto hace la inspeccin conocer
a una reunin muy eficiente.

La razn para llevar a cabo las inspecciones se puede explicar mediante el uso de concepto
de Weinberg de la ingeniera 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 ingeniera
tienen grupos de prueba independientes establecidas que se especializan en la bsqueda de
defectos. Similares principios han dado lugar a la introduccin de las inspecciones y
revisiones en general.

Dependiendo de la organizacin y los objetivos de un proyecto, las inspecciones pueden

ser equilibradas para cumplir una serie de objetivos. Por ejemplo, si el tiempo de
comercializacin es extremadamente importante, el nfasis en las inspecciones ser la
eficiencia. En un mercado crtico para la seguridad, la atencin se centrar en la efectividad.

Los objetivos generalmente aceptados de la inspeccin son los siguientes:

Ayudar al autor a mejorar la calidad del documento objeto de la inspeccin;
 Eliminar los defectos de manera eficiente, lo ms pronto posible;
Mejorar la calidad de los productos, mediante la produccin de documentos con un mayor
nivel de calidad;
Crear un entendimiento comn mediante el intercambio de informacin entre los
participantes de inspeccin;
Formar a nuevos empleados en el proceso de desarrollo de la organizacin;
Aprender de los defectos encontrados y mejorar los procesos con el fin de evitar que se
repiten defectos similares;
Degustar unas pocas pginas o secciones de un documento ms grande con el fin de medir
la tpica calidad del documento, lo que mejora el trabajo de las personas en el futuro, y para
mejoras de proceso.

Las caractersticas clave de una inspeccin 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 verificacin se utilizan durante la fase de preparacin.
Una preparacin 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 anlisis causal se introdujo para hacer frente a cuestiones de
mejora de procesos y aprender de los defectos encontrados.
Las mtricas son recogidos y analizados para optimizar el proceso.

3.2.4 Factores de xito para las revisiones

La implementacin de comentarios (formal) no es fcil ya que no hay una manera de
xito y hay muchas maneras de fracasar. La siguiente lista contiene una serie de crticos
factores de xito que mejoran las posibilidades de xito en la aplicacin de las revisiones.

Su objetivo es responder a la pregunta: "Cmo se inicia revisin (formal)? '.

Encontrar un "campen"
Se necesita un campen, que conducir el proceso en un proyecto o un nivel de la
organizacin. Necesitan experiencia, entusiasmo y una mentalidad prctica con el fin
para guiar a los moderadores y participantes. La autoridad de este campen debe ser
claro para toda la organizacin. apoyo a la gestin tambin es esencial para xito. Ellos
deben, entre otras cosas, incorporar un tiempo adecuado para actividades de revisin de los
programas del proyecto.

Recoger las cosas que realmente cuentan

Seleccione los documentos de revisin que son ms importantes en un proyecto.
La revisin de documentos altamente crticos, aguas arriba como los requisitos y la
arquitectura con toda seguridad, mostrara los beneficios del proceso de revisin para el
proyecto.

Estas horas de revisin invertidos tendrn un retorno claro y alto de la inversin.

Adems, asegrese de que cada revisin tiene un objetivo claro y el tipo correcto de
revisin se ha seleccionado para que coincide con el objetivo definido. No tratar de
opinin todo mediante inspeccin; adaptarse a la opinin sobre el riesgo asociado con el
documento ambiente. Algunos documentos slo pueden justificar una revisin informal
y otros mediante inspeccin. Por supuesto, tambin es de suma importancia que personas
estn involucradas.

Explcitamente planificar y realizar un seguimiento de las actividades de revisin

Para asegurar que las revisiones (criticas) se convierten en parte de las actividades del da a
da, las horas a ser gastado debe ser visible dentro de cada plan de proyecto. los ingenieros
implicados programan el tiempo de preparacin y, muy importante, rehacen. El seguimiento
de estas horas ser mejorar la planificacin de la prxima revisin. Como se dijo
anteriormente, la gestin juega un papel importante en la planificacin de las actividades
de revisin.

Capacitar a los participantes

Es importante que se imparta formacin en tcnicas de revisin, en especial tcnicas
formales, tales como la inspeccin. De lo contrario es probable que el proceso de ser
obstaculizado por aquellos que no entienden el proceso y el razonamiento Detrs de
eso. entrenamiento especial se debe proporcionar a los moderadores para prepararlos
en su papel fundamental en el proceso de revisin.

Resolver los problemas de la gente

Los comentarios son sobre la evaluacin del documento de alguien. Algunas de las
crticas tienden a obtener demasiado personal cuando no estn bien gestionados por el
moderador. problemas de las personas y los aspectos psicolgicos deben ser tratados por el
moderador y debe ser parte de la formacin crtica, con lo que la opinin de una experiencia
positiva para el autor. Durante la revisin, 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 cmo modificarlos, pero haga
el proceso tan formal como la cultura del proyecto o nivel de madurez permite.
No se convierta en demasiado terica o demasiado detallada. Las listas de verificacin
y los roles son eficaces para aumentar la eficacia de la identificacin 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 motivacin de los ingenieros
involucrado. La motivacin es la clave para un proceso de cambio con xito. Debera
Tambin hacer hincapi, adems 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 haban 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 cuantificacin
de los beneficios, as como los costos.

Solo hazlo!
El proceso es simple pero no fcil. 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 ms importante, empezar a hacer
comentarios y comenzar a aprender de cada revisin.

3.3 Anlisis esttico por herramientas

1 Describir el objetivo del anlisis esttico y compararlo con pruebas dinmica. (K2)
2 Recordemos defectos tpicos identificados por el anlisis esttico y compararlas con
las crticas y pruebas dinmicas. (KL)
3 Lista de beneficios tpicos de los analistas esttica. (KL)
4 Lista de cdigo y diseo tpicos defectos que pueden ser identificados por la esttica
Las herramientas de anlisis. (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, diseos, cdigos, planes de prueba y ms, para encontrar
defectos y corregirlos antes de entregar un producto a un cliente. En esta seccin, nos
centramos en un tipo diferente de pruebas estticas, donde examinamos
cuidadosamente requisitos, diseos y cdigo, por lo general con la asistencia automtica
para desentraar defectos adicionales antes del cdigo real de ejecucin. Por lo tanto, lo que
se llama El anlisis esttico es ms que otra forma de prueba.

El anlisis esttico es un examen de los requisitos, el diseo y el cdigo que difiere de la

prueba dinmica ms tradicional en un nmero de maneras importantes:

El anlisis esttico se realiza sobre los requisitos, el diseo o cdigo sin llegar ejecutar el
artefacto software que est siendo examinada.
El anlisis esttico se realiza idealmente antes de que los tipos de revisin formal se discute
en la Seccin 3.2.
Anlisis esttico no est relacionado con las propiedades dinmicas de los requisitos, el
diseo y el cdigo, tales como cobertura de la prueba.
El objetivo del anlisis esttico es encontrar defectos, pueden o no causar
fracasos. Como con las crticas, el anlisis esttico encuentra defectos en lugar de
fracasos.

Para el anlisis esttico hay muchas herramientas, y la mayora de ellos se centran en

el cdigo del software. herramientas de anlisis esttico suelen ser utilizados por los
desarrolladores antes, y A veces, durante, el diseo de componentes y pruebas de
integracin y por diseadores durante el modelado de software. Las herramientas
pueden mostrar atributos no slo estructurales (mtricas de cdigo), tales como la
profundidad del nmero de anidacin o ciclomtica y verificacin en contra de las
normas de codificacin, sino tambin representaciones grficas de control de flujo de
datos, las relaciones y el nmero de trayectorias distintas de una lnea de cdigo a
otro. Incluso el compilador puede considerarse una herramienta de anlisis esttico, ya que
construye una tabla de smbolos, seala el uso incorrecto y controles para no cumplimiento
de codificacin de las convenciones del lenguaje (sintaxis).

Una de las razones para el uso de anlisis esttico (normas de codificacin y similares)
est relacionada con las caractersticas de los lenguajes de programacin propios.
Uno puede pensar que los lenguajes son seguros de usar, ya que al menos el comit de normas
sabe dnde estn los problemas. Pero esto sera un error.

Agregando a los agujeros dejados por el proceso de normalizacin, los programadores

continuar para informar de las caractersticas del lenguaje, que aunque bien definido, dar
lugar a modos de fallo reconocible. A finales de la dcada de 1990, aproximadamente 700 de
estos problemas adicionales haban sido identificados en C estndar Ahora est claro la
existencia de tales modos de falla. Se puede demostrar que con frecuencia escapar del
escrutinio de la prueba dinmica convencional, terminando en comerciar el producto. Estos
problemas se pueden encontrar mediante el uso de herramientas de anlisis esttico de
detectarlos. De hecho, muchos de los 700 modos de falla en C pueden ser detectados
informados de esta manera! En un programa tpico de C, hay un promedio de
aproximadamente ocho faltas por cada 1.000 lneas de cdigo fuente; que estn
incrustados en el cdigo liberado, a la espera de hacer que el cdigo para fallar [Hatton,
1997].
La prueba dinmica 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 programacin tienen problemas y los programadores no pueden
asumir que estn protegidos contra ellos. Y nada en el actual proceso internacional de
normalizacin de los lenguajes evitar que esto suceda en el futuro.

Las diversas caractersticas de herramientas de anlisis esttico se discuten a continuacin,

con un enfoque especial hacia las herramientas de anlisis de cdigo esttico, ya que estos
son los ms comunes en la prctica del da a da. Tenga en cuenta que las herramientas de
anlisis esttico analizan cdigo de software, as como salida generada como HTML y XML.

3.3.1 normas de codificacin

Comprobacin de la adherencia a los estndares de codificacin es sin duda la ms
conocida de todas las caractersticas. La primera accin a realizar es definir o adoptar
una codificacin Standard. Por lo general, un estndar de codificacin consiste en un
conjunto de reglas de programacin (por ejemplo, 'Siempre revise los lmites de un array
cuando se copia a la matriz'), nombrando convenciones (por ejemplo, "Las clases deben
comenzar con mayscula) y especificaciones de diseo (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 razn extra para adoptar este enfoque es que si se
toma un Standard de codificacin conocida es probable que haya herramientas disponibles
que soportan este estndar de chequeo.
Incluso se puede poner al revs: la compra de un analizador de cdigo esttico y declarar
(una seleccin de) las reglas en l como su norma de codificacin. sin tal herramienta, es
probable que falle la aplicacin de un estndar de codificacin en una organizacin.
Hay tres causas principales para esto: el nmero de reglas en un estndar de
codificacin es por lo general tan grande que nadie puede recordar a todos ellos; algunas
normas contextuales que exigen una revisin de varios archivos son muy difciles de
comprobar por los seres humanos; y si la gente pasa tiempo revisando los estndares de
codificacin de las revisiones, que la voluntad distraerlos de otros defectos que de otro modo
podran, por lo que procesar la revisin ser menos eficaz.

3.3.2 mtricas de cdigo

Como se ha indicado, cuando se realizan anlisis de cdigo esttico, por lo general la
informacin es calculada sobre los atributos estructurales del cdigo, como frecuencia
de comentario, la profundidad de, el nmero de lneas de cdigo, anidacin ciclomtica.

Esta informacin se puede calcular no slo cuando el diseo y el cdigo son creado, sino
tambin cuando se realizan cambios en un sistema, para ver si el diseo o cdigo es cada vez
ms grande, ms complejo y ms difcil de entender y mantener. Las mediciones tambin nos
ayudan a decidir entre varias alternativas de diseo, especialmente cuando el reajuste de las
porciones del cdigo existente.

Hay muchos tipos diferentes de medidas estructurales, cada uno de los cuales nos dice algo
sobre el esfuerzo necesario para escribir el cdigo en primer lugar, a entender el cdigo al
hacer un cambio, o para probar el cdigo utilizando herramientas o tcnicas particulares.

programadores con experiencia saben que el 20% del cdigo causan el 80% de los problemas
y el anlisis de complejidad ayuda para encontrar este 20%, lo cual referirse de nuevo al
principio de la agrupacin de defecto como se explica en el Captulo 1.
Complejidad mtrica identificar zonas de alto riesgo complejas.

La complejidad mtrica ciclomtica se basa en el nmero de decisiones en un

programa. Es importante testers, ya que proporciona una indicacin de la cantidad de pruebas
(incluyendo comentarios) necesarias para evitar prcticamente defectos. En otras palabras,
las reas de cdigo identificadas como ms complejo son candidatos para las revisiones
y pruebas dinmicas adicionales. Si bien hay muchas maneras de calcular la complejidad
ciclomtica, la forma ms fcil es para sumar el nmero de declaraciones de decisiones
binarias (por ejemplo, si, mientras que, por, etc.) y aadir 1 a eso. Una definicin ms formal
con respecto a las reglas de clculo se proporciona en el glosario.
A continuacin, se muestra un programa simple como un ejemplo:
El flujo de control generada por el programa se vera Figura 3.2.
El flujo de control muestra siete nodos (formas) y ocho bordes (lneas), utilizando as la
frmula de la complejidad formal ciclomtica es 8-7 + 2 = 3. En este caso no hay grfico
llamada o subrutina.
Alternativamente, se puede calcular utilizando la complejidad ciclomtica la regla de los
puntos de decisin. Puesto que hay dos puntos de decisin, las ciclomtica complejidad es 2
+ 1 = 3.

3.3.3 estructura de Cdigo

Hay muchos tipos diferentes de medidas estructurales, cada uno de los cuales nos dice
algo sobre el esfuerzo necesario para escribir el cdigo en el primer lugar, comprender el
cdigo a la hora de hacer un cambio, o para probar el cdigo usando las herramientas
o tcnicas particulares. A menudo se supone que un mdulo grande requiere ms tiempo
para especificar, diseo, cdigo y prueba que uno ms pequeo. Pero, de hecho, la estructura
del cdigo juega un papel importante. Ah Son varios los aspectos de la estructura del cdigo
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 diseo de un
programa. Si slo el tamao de un programa se mide, no se proporciona informacin sobre
la frecuencia con que una instruccin se ejecuta y como se ejecuta. anlisis de flujo de
control tambin se utiliza para identificar el cdigo inalcanzable (muertos). De hecho,
muchos de las mtricas de cdigos se refieren a la estructura de flujo de control, por ejemplo,
nmero de anidada niveles de complejidad o ciclomtica.

estructura de flujo de datos sigue la estela de un elemento de datos, ya que se accede y

se modifica por el cdigo. Muchas veces, las operaciones aplicadas a los datos son ms
compleja que las instrucciones que los desarrollan. Por lo tanto, el uso de flujo de datos
muestra cmo actan 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 organizacin 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 creacin, modificacin o supresin de ellas hay ms
probabilidades de estar bien definidos, tambin. Por lo tanto, la estructura de datos
proporciona una gran cantidad de informacin acerca de la dificultad de escribir
programas para manejar los datos y en el diseo de casos de prueba para demostrar la
correccin 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 anlisis esttico se
pueden utilizar como seales de alerta temprana de lo bien que el cdigo sea cuando
est terminado.

En resumen, el valor del anlisis esttico es especialmente para:

Deteccin precoz de los defectos antes de probar la ejecucin;
Alerta temprana sobre aspectos sospechosos del cdigo, diseo o los requisitos;
Identificacin de defectos que no se encuentran fcilmente en las pruebas dinmicas;
Mejora de la capacidad de mantenimiento del cdigo y el diseo ya que los ingenieros
trabajan de acuerdo a las normas y reglas documentados;
Prevencin de defectos, a condicin de que los ingenieros estn dispuestos a aprender
de su errores y mejora continua se practica.

Repaso Captulo
Vamos a repasar lo que ha aprendido en este captulo.

De la Seccin 3.1, usted debe ser capaz de explicar la importancia y ventaja de pruebas
estticas. Usted debe saber la diferencia entre los ensayos estticos y la prueba dinmica,
y tambin a entender el concepto de revisin (comentarios). Usted debera ser capaz de
reconocer los productos de trabajo de software que pueden ser examinadas por las
pruebas esttica. Usted debe conocer los trminos del glosario pruebas estticas, pruebas
dinmicas y revisin.

De la Seccin 3.2, usted debe entender la diferencia entre lo formal y revisiones

informales. Usted debe ser capaz de recordar las fases principales de una tpica revisin
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 revisin formal:
revisin tcnica, paso a paso y la inspeccin. Por ltimo, debe ser capaz de explicar los
factores para el desempeo exitoso de revisiones (comentarios). Debieras conocer los
trminos del glosario criterios principales, los criterios de salida, formal opinin,
informal revisin, inspeccin, moderador, revisor, escriba, revisin tcnica y paso a
paso.

De la Seccin 3.3, usted debe entender el objetivo del anlisis esttico y ser capaz de
compararlo con pruebas estticas y dinmicas. Deberas ser capaz de describir las
principales caractersticas de anlisis esttico y recordar defectos tpicos que se
encuentra el uso de anlisis esttico. Por ltimo, usted debe ser capaz de recordar los
beneficios de la utilizacin de anlisis esttico. Usted debe saber el glosario de
trminos compilador, complejidad ciclo- matica, control de flujo, el flujo de datos y el
anlisis esttico.
PREGUNTAS examen de la muestra
Pregunta 1 Cul de los siguientes artefactos pueden ser examinados mediante el uso de
opinin tcnicas?
a. cdigo de software
b. Especificacin de requisitos
c. El empleo de pruebas
d. Todo lo de arriba

Pregunta 2 Qu afirmacin acerca de la funcin de una herramienta de anlisis esttico es

cierto?
a. Proporciona informacin acerca de la calidad cdigo sin ejecutarlo.
b. Cheques resultados esperados contra real resultados.
c. Puede detectar prdidas de memoria.
d. Proporciona informacin acerca de lo que tiene el cdigo de
y no se ha ejercido.

Pregunta 3 Qu no es un tipo de revisin?

a. Tutorial
b. Inspeccin
c. revisin informal
d. aprobacin de la administracin

Pregunta 4 Qu afirmacin acerca comentarios es de verdad?

a. Las inspecciones son dirigidas por un profesional capacitado moderador, mientras que las
revisiones tcnicas no son necesariamente.
b. Revisiones tcnicas estn dirigidas por un lder 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 Cul es la principal diferencia entre un tutorial y un inspeccin?

a. Una inspeccin es dirigida por los autores, mientras que un paseo a travs es dirigido por
un moderador capacitado.
b. Una inspeccin tiene un lder entrenado, mientras que un paseo a travs no tiene un lder.
c. Los autores no estn presentes durante inspecciones, mientras que son durante los
recorridos.
d. Un tutorial est dirigido por el autor, mientras que una inspeccin est dirigido por un
profesional capacitado moderador.

Pregunta 6 Cul de las siguientes caractersticas y tipos de revisin procesos van de la mano?
1. Dirigido por el autor
2. indocumentados
3. Sin la participacin de gestin
4. Dirigido por un moderador o lder entrenado
5. Utiliza los criterios de entrada y salida
s. Inspeccin
t. Revisin tcnica
u. revisin 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 Cul declaracin sobre esttica El anlisis es verdad?

a. Con el anlisis esttico, los defectos pueden ser encontrado que son difcil de encontrar
con las pruebas dinmicas.
b. Compilando no es una forma de esttica anlisis.
c. Si se realiza correctamente, esttico hace que el anlisis redundante pruebas funcionales.
d. El anlisis esttico encuentra todas las faltas.

Pregunta 8 Cul de las siguientes declaraciones sobre el diseo de las primeras pruebas son
verdaderas y que son falsas?
1. Los defectos encontrados durante el diseo de la prueba temprana son ms caros de
solucionar.
2. diseo de la prueba temprana puede encontrar defectos.
3. diseo de la prueba temprana puede causar cambios en los requisitos.
4. diseo de la prueba temprana requiere ms 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 anlisis de cdigo esttico tpicamente identifica todos menos uno de los
siguientes problemas. Que es?
a. Cdigo inalcanzable
b. las variables no declaradas
c. Los fallos en los requisitos
d. No hay suficientes comentarios
 Tcnicas de diseo de pruebas

Captulo 3 cubierto pruebas estticas, mirando a los documentos y el cdigo y que no utiliza
el cdigo. Este captulo se centra en las pruebas dinmicas, donde el software que estn
interesados en que se ejecute mediante la ejecucin de pruebas en el cdigo de ejecucin.

4.1 Identificacin de las condiciones de prueba y el diseo de casos de pruebas

1 Diferenciar entre una especificacin de diseo de prueba, una especificacin de casos

de prueba y un procedimiento de prueba. (KL)
2 Comparacin de los trminos 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 ejecucin de prueba para un determinado conjunto de casos

de prueba, teniendo en cuenta priorizacin, y tcnicos y lgicos dependencias. (K3)

4.1.1 Introduccin
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 seccin 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 Documentacin estndar de
Prueba [IEEE829].

Condiciones de la prueba se documentan en un diseo de la Norma de prueba. Vamos a ver

cmo 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

cmo para escribir un buen caso de prueba, mostrando trazabilidad clara a la base de pruebas
(por ejemplo, la especificacin de requisitos), as como a las condiciones de prueba.
Los procedimientos de prueba estn documentados (como se puede esperar) en un
procedimiento de prueba Especifico (tambin 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 ejecucin de pruebas,
usando el establecimiento de prioridades y tcnica y lgica dependencias.

En esta seccin, busque las definiciones de los trminos 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 documentacin de prueba
La prueba puede realizarse con diversos grados de formalidad. prueba muy formal tendra
una extensa documentacin que est bien controlada, y se esperara el detalle documentado
de las pruebas que incluyen la entrada exacta y especfica y el resultado esperado de la
prueba. Muy informal prueba que no tiene documentacin en absoluto, o slo las notas
mantenidas por los testers individuales, pero todava esperara que el testers tiene en sus
mentes y seala una idea de lo que pretendan poner a prueba y lo que espera que el resultado
sea. La mayora de la gente est probablemente en algn lugar entre! El nivel adecuado de
formalidad para usted depende de su contexto:
una aplicacin comercial crtica para la seguridad tiene necesidades muy diferentes que una
que solo se solicitud para ser utilizado por slo unas pocas personas por un corto tiempo.

El nivel de formalidad tambin se ve influida por su organizacin, 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 documentacin de prueba puede Tambin
depender de sus limitaciones de tiempo; bajo presin de tiempo excesivo, mantener una
buena documentacin puede verse comprometida.

En este captulo vamos a describir un estilo de documentacin bastante formal. Si esto no es

apropiado para usted, es posible adoptar un enfoque menos formal, pero debe ser conscientes
de cmo aumentar la formalidad si es necesario.

4.1.3 Anlisis de Prueba: Identificacin de las condiciones de prueba

Anlisis de la prueba es el proceso de observar algo que se puede utilizar para derivar
informacin de la prueba. Esta base de las pruebas se denomina la "base de pruebas
'. Podra ser un requisito del sistema, una especificacin tcnica, el propio cdigo (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 tambin se discuti en el Captulo
1.
Desde una perspectiva de pruebas, nos fijamos en la base de pruebas con el fin de ver qu
podra ser probado, stas son las condiciones de prueba. una condicin de prueba es
simplemente algo que hemos podido probar. Si estamos buscando para medir la cobertura de
cdigo decisiones (ramas), entonces la base de pruebas seran el propio cdigo, y la lista
de la prueba de las condiciones seran los resultados de la decisin (verdaderos y falsos). Si
nosotros tenemos una especificacin 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 sealado [Hetzel, 1988].
Por ejemplo, si estamos probando un sistema de gestin de clientes y comercializacin para
una empresa de telefona mvil, podramos tener condiciones de prueba que estn
relacionados con una campaa de marketing, tales como la edad del cliente (pre-adolescente,
joven adulto, maduro), sexo, cdigo postal o el cdigo postal, y la preferencia de compra
(pago por uso o contrato). Una campaa de publicidad en particular podra 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 bsica de "una lista
de cosas que podamos 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 fcilmente de esta manera. [Marick, 1994] En contraste, Hutcheson
habla de la "objetos de la pruba 'como una lista de cosas que podran ser probadas
[Hutcheson, 2003]; Craig habla sobre como amplias categoras '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
condicin de prueba.

En la identificacin de las condiciones de prueba, queremos 'lanzar la red' para identificar

tantos como podamos, y luego vamos a empezar a ser selectivo sobre cules llevar adelante
para desarrollar con ms detalle y combinar en los casos de prueba. Podramos llamarlos
'posibilidades' de prueba.

En el captulo 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 prctico. Por lo tanto, ya
que no puede ser probado todo, tenemos que seleccionar un subconjunto de todas las pruebas
posibles. En la prctica, el subconjunto que seleccione puede ser un subconjunto muy
pequeo 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
seleccin; tcnicas de prueba (es decir, diseo de pruebas tcnicas) son tales procesos de
pensamiento.

Una tcnica de prueba ayuda a seleccionar un buen conjunto de pruebas a partir del
nmero total de todas las pruebas posibles para un sistema dado. Diferentes tcnicas
ofrecen diferentes maneras de mirar el software bajo prueba, posiblemente supuestos hechos
desafiantes sobre ello. Cada tcnica proporciona un conjunto de reglas o directrices para
el testers a seguir en la identificacin de las condiciones de prueba y casos de
prueba. Las tcnicas se describen en detalle ms adelante en este captulo.
Las condiciones de pruebas que son elegidas dependern de la estrategia de prueba o
enfoque detallado de las pruebas. Por ejemplo, podran estar basados en el riesgo,
modelos del sistema, las posibles averas, los requisitos de cumplimiento, el
asesoramiento de expertos o heurstica.

La palabra 'heurstica' viene de la misma raz griega como Eureka, lo que significa
'Encuentro'. Una heurstica es una manera de dirigir su atencin, una regla de sentido comn
til en la solucin 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 travs de toda la documentacin de prueba para una
prueba del nivel de prueba determinado (por ejemplo, sistema, a partir de las condiciones de
prueba a travs de casos de prueba para scripts de prueba) o vertical a travs de las capas de
la documentacin de desarrollo (por ejemplo, de los requisitos a los componentes).
Por qu es importante la trazabilidad? Considere estos ejemplos:
Los requisitos para una funcin o caracterstica dada han cambiado. Algunos de los
Ahora campos tienen diferentes rangos que se pueden introducir. Qu pruebas fueron
mirando esos lmites? Ahora necesitan ser cambiadas. Cuntas pruebas en realidad ser
afectado por este cambio en los requisitos? Estas preguntas se pueden responder fcilmente
si los requisitos se pueden rastrear fcilmente 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 estn probando permite que las funciones o caractersticas
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 especificacin de requisitos. Nosotros tenemos
la lista de las pruebas que han pasado, se puso a prueba todos los requisitos?
Despus de haber identificado una lista de condiciones de prueba, es importante dar
prioridad a ellos, de modo que se identifican las condiciones de pruebas ms importantes
(antes de una gran cantidad de tiempo es gastado en el diseo 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 continuacin, se puede tirar a la basura los menos los ms importantes, y
usted tendr un mejor conjunto de condiciones de prueba!
Tenga en cuenta que pasar algn tiempo adicional ahora, mientras que la identificacin de
las condiciones de prueba, no toma mucho tiempo, ya que slo enumerando las cosas que
podamos probar. Esto es una buena inversin 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 distribucin de tipos de registros dentro de un archivo o base de datos, diferentes
tamaos de los registros o campos de una grabar. Los datos de prueba deben ser diseados
para representar los tipos ms importantes de los datos, es decir, las condiciones de los
datos ms importantes.
Condiciones de la prueba se documentan en el documento IEEE 829 llama una prueba
Especificaciones de Diseo, se muestra a continuacin. (Este documento podra haber sido
llamado Condicin de prueba Especificacin, ya que los contenidos se hace referencia en la
norma son en realidad probar condiciones).

IEEE 829 STANDARD: ESPECIFICACIONES DEL MODELO DE DISEO DE

PRUEBA
Identificador de la prueba especificacin de diseo Caractersticas para ser probados Enfoque
refinamientos Comprobacin de las funciones de identificacin pasa / falla criterios

4.1.4 Prueba de diseo: Especificacin 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 telefona mvil (por ejemplo, un
adolescente en el mediano oeste), o una condicin de prueba pueden ser ms especficos (por
ejemplo, un cliente particular, masculino en pago por uso con menos de $ 10 de crdito). Sin
embargo, cuando llegamos a hacer un caso de prueba, estamos obligados a ser muy
especfico; de hecho, ahora tenemos entradas especficas detalladas, no descripciones
generales (por ejemplo, Jim Green, de 17 aos, la vida en Grand Rapids, Michigan, con el
crdito de $ 8,64, resultado esperado: aadir a Q4 campaa de marketing). Tenga en cuenta
que un caso de prueba cubre una serie de condiciones (Adolescente, varn, medio oeste
zona, pago por uso, y el crdito de menos de $ 10).
Para una condicin 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
podra ser la creacin de un registro de base de datos para Jim Green.
Un caso de prueba debe tener valores de entrada, por supuesto, pero slo 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 continuacin. Sin embargo, es posible probar sin
documentar un nivel de casos de prueba. Si das una aceptacin del usuario experimentado
tester con un fuerte conocimiento de los negocios una lista de condiciones de prueba de
alto nivel, que probablemente podra hacer un buen trabajo de la prueba. Pero si usted
le dio la misma lista para un nuevo testers que no conoca el sistema en absoluto,
probablemente se perder, por lo que se beneficiara de tener casos de prueba ms
detallados.
Los casos de prueba se pueden documentar como se describe en el estndar IEEE 829
estndar para Documentacin de prueba. Tenga en cuenta que el contenido descrito en la
norma no todos lo hacen tienen que ser documentos fsicos 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 caracterstica dada
mantienen todas en un solo documento fsico.
Uno de los aspectos ms importantes de un instrumento es que se evala que el sistema
hace lo que se supone que debe hacer. Copeland dice 'En su esencia, la prueba es el
proceso de la comparacin de "lo que es" con "lo que debera 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 haba 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 nios '[Beizer, 1990]. Puede que no sepamos
lo que es la respuesta correcta en detalle cada vez, y todava puede obtener algn 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
informacin sobre el comportamiento correcto del sistema, esto se llama un "orculo" o
un orculo de pruebas.
Esto no tiene nada que ver con las bases de datos o empresas que los fabrican. Viene de
el griego antiguo orculo de Delfos, que supuestamente poda predecir el futuro con
infalible precisin. En realidad, sus respuestas eran tan vagas que la gente los interpretarse
en la forma que queran 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 informacin que aparece en una pantalla en respuesta a
una entrada, sino que tambin 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 decisin 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 pequeas diferencias en
clculos o resultados que parecan mirar bien (es decir, son plausibles). De modo que lo hara
concluir que la prueba haba pasado, cuando en realidad el software no ha dado el resultado
correcto. Las pequeas diferencias en un clculo pueden sumar a algo muy importante ms
adelante, por ejemplo, si los resultados se multiplican por un factor grande.
Lo ideal sera que los resultados esperados se pueden predecir antes de que se ejecute
la prueba a continuacin, su evaluacin de si o no el software hizo lo correcto ser ms
objetiva.
Para algunas aplicaciones puede que no sea posible predecir o saber exactamente un resultado
esperado; que slo podemos hacer un control de razonabilidad '. En el caso de que tengamos
un "orculo parcial" sabemos cundo algo est muy mal, pero probablemente tendra que
aceptar algo que pareca 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 clculos son tan complejos.
Adems de los resultados esperados, en el caso de prueba tambin 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 deberan aplicarse cuando finalice la prueba (la pos-
condiciones).
IEEE 829 STANDARD:
CASO DE PRUEBA ESPECIFICACIONES MODELO
Identificador de la prueba especificacin 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 tambin 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 ms importantes se
ejecutan primero, y casos de prueba de baja prioridad se ejecutan despus, 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 especficos, tales como un valor de entrada, que ha demostrado ser problemtico
en el pasado, el riesgo asociado con la prueba, o la secuencia ms sensible de la ejecucin de
las pruebas. Captulo 5 da ms 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 aplicacin: Especificacin 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
ejecucin 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 regresin, o la totalidad de las pruebas que explorar
el funcionamiento de una funcionalidad o caracterstica 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 recin
creado y luego eliminarlo. Estas pruebas se deben ejecutar en el orden correcto, o no van a
probar lo que estn destinados a probar.

El documento que describe los pasos a seguir en la ejecucin de un conjunto de (pruebas y

especifica el orden ejecutable de las pruebas) se llama un procedimiento de prueba en el
estndar IEEE 829, y se suele denominar tambin como un script de prueba. Podra ser
llamado una secuencia de comandos de prueba manual para las pruebas que estn destinadas
a ser ejecutadas manualmente en lugar de utilizar una herramienta de ejecucin de la
prueba. escritura de la prueba tambin se utiliza para describir las instrucciones a una
herramienta de ejecucin de la prueba. Una secuencia de comandos de automatizacin se
escribe en un lenguaje de programacin que la herramienta puede interpretar. (Esto es un
automatizado procedimiento de prueba.) Vase el captulo 6 para obtener ms informacin
sobre ste y otros tipos de las herramientas de prueba.

Los procedimientos de prueba, o scripts de prueba, se forman entonces en una ejecucin de

la prueba horario que especifica qu procedimientos se van a ejecutar en primer lugar, una
especie de gua. El plan de prueba dira cuando una secuencia de comandos dada se debe
ejecutar y por quin. El horario puede variar en funcin de los nuevos riesgos que afectan
a la percepcin, la prioridad de una secuencia de comandos que se ocupa del riesgo, por
ejemplo. La lgica y las tcnicas de dependencia entre las secuencias de comandos
tambin se tendran en cuenta la hora de programar las secuencias de comandos. Por
ejemplo, una secuencia de comandos de regresin siempre puede ser la primera en ser
ejecutado cuando llega una nueva versin del software, como una prueba de humo o
prueba de cordura.

Volviendo a nuestro ejemplo de la cmara de marketing de la empresa de telefona mvil,

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 configuracin de un grupo de pruebas
primero. As que nuestro primer procedimiento de prueba implicara la creacin de un
nmero de clientes, incluyendo Jim Green, en la base de datos.

Procedimiento de la prueba DB15: Configuracin de los clientes para la campaa de

marketing Y.
Paso 1: Abrir base de datos con el privilegio de escritura
Paso 2: Configuracin de cliente Bob,maculino, de 62 aos, 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 campaa de
marketing:
Procedimiento de la prueba MC03: Ofertas especiales para adolescentes bajo crdito
Paso 1: Obtener datos de la base de datos de Jim Green
Paso 2: Enviar mensaje de texto que ofrece el doble de crdito
Paso 3: Jim Green solicita crdito de $ 20, $ 40 acreditarn

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 definicin de lo que es 'miedo'
depende en el negocio, sistema o proyecto. Por ejemplo, es peor para elevar Bob
lmite de crdito Fundadores cuando l no es un buen riesgo de crdito (que no puede pagar
por el crdito que pidi) o negarse a aumentar su lmite de crdito cuando l es un buen
crdito riesgo (que puede ir a otro lugar para su servicio de telfono 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 especificacin del procedimiento
Propsito
Requisitos especiales
pasos del procedimiento

4.2 CATEGORAS DE LAS TCNICAS DE DISEO DE PRUEBA

1 recordaremos que tantas razones basados en la especificacin (caja negra) y
estructura basado en (caja blanca) son tiles para el diseo de pruebas de caja, y la lista
de las tcnicas comunes para cada uno. (KL)
2 Explicar las caractersticas y diferencias basada en la especificacin las pruebas, las
pruebas basadas en la estructura y las pruebas basadas en la experiencia. (K2)

En esta seccin vamos a ver los diferentes tipos de tcnicas de diseo de pruebas, cmo
Se utilizan y cmo se diferencian. Los tres tipos o categoras son distinguidos por su
fuente primaria: una especificacin, la estructura del sistema o componente, o la
experiencia de una persona. Todas las categoras son tiles y los tres son
complementario.
En esta seccin, busque las definiciones de los trminos del glosario: prueba de recuadro
negro tcnicas de diseo, basadas en la experiencia, las tcnicas de diseo de pruebas
tcnicas de diseo de pruebas basado en la especificacin, prueba basada en la
estructura tcnicas de diseo y tcnicas de diseo de pruebas de caja blanca.

4.2.1 Introduccin
Hay muchos tipos diferentes de tcnicas de pruebas de software, cada uno con su propia
fortalezas y debilidades. Cada tcnica individual es buena para encontrar tipos de
defectos particulares y relativamente pobres en la bsqueda de otros tipos. Por ejemplo,
una tcnica que explora los lmites superior e inferior de una gama nica de entrada tiene
ms probabilidades de encontrar defectos de contorno que los defectos asociados con la
combinacin 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 ms probabilidades de encontrar defectos lgicos de codificacin
que no sean defectos de diseo del sistema.
Cada tcnica de pruebas se encuentra en una de un nmero de categoras diferentes.
En trminos generales hay dos categoras principales, estticas y dinmicas. Tcnica
esttica se discuten en el Captulo 3. Las tcnicas dinmicas se subdividen en tres
categoras ms: basada en la especificacin (caja negra, tambin conocido como tcnica
conductual), basado en la estructura (caja blanca o tcnicas estructurales) y la basada
en la experiencia. Las tcnicas basadas en la especificacin incluyen tanto funcionales
como no tcnicas funcionales (es decir, las caractersticas de calidad). Las tcnicas cubiertas
en el plan de estudios se resumen en la Figura 4.1.

4.2.2 tcnicas de pruebas estticas

Como vimos en el captulo 3, las tcnicas de pruebas estticas no ejecutan el cdigo siendo
examinado y se utilizan generalmente antes de las pruebas que ejecutan el software.
Podran ser llamados tcnicas no ejecucin. La mayora de las tcnicas de pruebas estticas
se puede utilizar para "prueba" cualquier forma de documento que incluye cdigo
fuente, diseo documento y modelos, especificaciones funcionales y especificaciones de
requisitos.
Sin embargo, el "anlisis esttico" es un tipo de herramienta compatible de pruebas estticas
que se centra en las pruebas de lenguajes formales y por lo tanto a menudo se realiza para
probar estticamente cdigo fuente.
4.2.3 (Caja negra) tcnicas de prueba basados en la especificacin
La primera de las tcnicas de pruebas dinmicas que vamos a ver es las tcnicas de pruebas
basadas en la ESPECIFICACIN. Estos tambin son conocidos como "Caja negra" o
tcnicas de prueba input / output, porque consideran que el software como una caja negra
con entradas y salidas, pero no tienen ningn conocimiento de cmo funciona el sistema o
componente se estructura dentro de la caja. En esencia, el testers est concentrando en lo
que hace el software, no cmo lo hace.
Ntese que la definicin menciona tanto pruebas funcionales como no funcionales. Las
pruebas funcionales se ocupan de lo que hace el sistema, sus caractersticas 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 (tambin conocido como las
caractersticas de calidad o atributos de calidad) incluyen el rendimiento, facilidad de uso,
portabilidad, facilidad de mantenimiento, etc. Las tcnicas para poner a prueba estos aspectos
de procedimiento no-funcionales son menos formales que los de otra categora como los
exmenes reales son ms 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 tambin se trata en el captulo
2. Existen tcnicas para derivar las pruebas no funcionales [gilb, 1988], [Testing Normas],
pero que no estn recogidas en el nivel de infraestructura.
Categorizacin 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) tcnicas de prueba basados en estructuras

tcnicas de pruebas basadas en la estructura (que tambin son dinmicos y no estticos)
utilizan la estructura interna del software para derivar casos de prueba. Son
comnmente llamada tcnicas 'caja blanca' ''caja de vidrio o (lo que implica que usted
puede ver en el sistema), ya que requieren el conocimiento de cmo se implementa el
software, que es, cmo funciona. Por ejemplo, una tcnica 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 tcnicas de pruebas basadas en la experiencia

En las tcnicas 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 tcnicos y de negocio es importante, ya que
aportan diferentes perspectivas al anlisis de la prueba y el proceso de diseo. Debido a la
experiencia previa con similares sistemas, pueden tener una visin de lo que podra ir mal, lo
que es muy til para las pruebas.

4.2.6 Donde aplicar las diferentes categoras de tcnicas

Las tcnicas basadas en las especificaciones son apropiadas en todos los niveles de la
prueba (pruebas de componente a travs de las pruebas de aceptacin) cuando existan
especificaciones. Cuando sistema o pruebas de aceptacin, la especificacin de
requerimientos que realice o su especificacin funcional puede constituir la base de las
pruebas. Al realizar pruebas de componente o integracin, una especificacin de documento
de diseo o de bajo nivel constituye la base de las pruebas.
Las tcnicas basadas en estructura tambin se pueden utilizar en todos los niveles de la
prueba.
Los desarrolladores utilizan tcnicas basadas en la estructura de las pruebas de componentes
y pruebas de integracin, especialmente cuando existe un buen apoyo para la herramienta de
cdigo de cobertura. Las tcnicas basadas en estructura tambin se utilizan en el sistema y la
pruebas aceptacin, pero las estructuras son diferentes. Por ejemplo, la cobertura de men
opciones o transacciones comerciales importantes podran ser el elemento estructural
en el sistema o pruebas de aceptacin.
Tcnicas basadas en las especificaciones y tcnicas basadas en la experiencia se utilizan
para complementar las tcnicas basadas en la estructura, y tambin se utilizan cuando
no hay especificacin, o si la especificacin es inadecuada o fuera de fecha. Este puede
ser el nico tipo de tcnica utilizada para sistemas de bajo riesgo, pero este enfoque puede
ser particularmente til bajo extrema presin 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 diseo de prueba tcnicas. (K3)
a) particin de equivalencia;
b) anlisis de valores lmite;
c) tablas de decisin;
d) pruebas de transicin de estado.

2 Entender el propsito principal de cada una de las cuatro tcnicas, qu nivel y el tipo
de prueba podra utilizar la tcnica, y cmo la cobertura puede ser mesurado. (K2)

3 Comprender el concepto de pruebas de casos de uso y sus beneficios. (K2)

En esta seccin vamos a ver en detalle las cuatro tecnicas de pruebas basados en la
especificacin tcnicas de caja negra. Estas cuatro tcnicas son K3, significa esto que tiene
que ser capaz de utilizar estas tcnicas para el diseo de casos de prueba. Nosotros Tambin
cubriremos brevemente (no a nivel K3) la tcnica basada en la especificacin de utilizar las
pruebas de caso. En la Seccin 4.4, vamos a ver la estructura basada en K3 tcnicas.
En esta seccin, busque las definiciones de los trminos del glosario: valores en la frontera
anlisis, pruebas de la tabla de decisiones, la particin de equivalencia, estado de
pruebas de transicin y las pruebas de caso de uso.
Las cuatro tcnicas basadas en la especificacin vamos a cubrir en detalle son:
particin de equivalencia;
anlisis de valores lmite;
tablas de decisin;
Prueba de transicin 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 particin y anlisis de valores lmite
Particin de equivalencia
Equivalencia de particin (EP) basada en la especificacin de la tcnica de caja negra. Se
puede aplicar en cualquier nivel de la prueba y es a menudo una buena tcnica a utilizar
por primera vez. Es un enfoque de sentido comn de la prueba, tanto es as que la mayora
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 tcnica de manera informal que no en todos, es
mucho mejor utilizar la tcnica de una manera formal para alcanzar todos los beneficios que
puede ofrecer.
Esta tcnica se puede encontrar en la mayora de los libros de pruebas, incluido [Myers, 1979]
y [Copeland, 2003].
La idea detrs de la tcnica consiste en dividir (es decir, a la Particin) 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 "particin de equivalencia'.
Particiones de equivalencia tambin se conocen como clases de equivalencia, los dos
trminos significan exactamente lo mismo.

La tcnica particionamiento de equivalencia, requiere entonces que necesitamos pruebas para

slo una condicin de cada particin. Esto se debe a que estamos suponiendo que todas las
condiciones en una particin sern tratados de la misma manera por el software. Si una
condicin en una particin 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 particin no funciona, entonces se asume
que ninguna de las condiciones en que la particin va a funcionar as que de nuevo hay poco
sentido hacer anlisis ms en esa particin. Por supuesto, estos estn 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 ms de un valor a partir de una
particin, especialmente si desea confirmar una seleccin de entradas de usuario tpicos.
Por ejemplo, una cuenta de ahorros en un banco gana una tasa de inters 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 inters. Por ejemplo, si un equilibrio en el rango de $ 0 a $ 100 tiene una tasa de
inters del 3%, un saldo de ms de $ 100 y hasta $ 1000 tiene una interfaz 5% tasa y saldos
de $ 1000 y por encima tienen una tasa de inters del 7%, tendramos inicialmente que
identificar tres particiones de equivalencia vlidos y no vlidos como una particin mostrado
a continuacin.

Tenga en cuenta que hemos identificado cuatro particiones aqu, a pesar de que la
especificacin slo menciona tres. Esto ilustra una tarea muy importante del testers no slo
lo probamos lo que est en nuestra especificacin, pero tambin pensamos en las cosas que
no se han especificado. En este caso se ha pensado en la situacin en la que el equilibrio es
menor que cero. No hemos (todava) identific una particin no vlida en la derecha, pero
esto tambin sera una buena cosa a tener en cuenta. Con el fin de identificar dnde la
particin termina el 7%, tendramos que saber cul es el saldo mximo de esta cuenta (que
puede no ser fcil de encontrar). En nuestro ejemplo, hemos dejado esto abierto por el
momento. Tenga en cuenta que la entrada no numrica es tambin una particin no vlida
(Por ejemplo, la letra "a"), pero slo se discuten las particiones numricas por ahora.
Hemos hecho una suposicin aqu sobre lo que es la diferencia ms pequea entre dos
valores. Hemos asumido dos cifras decimales, es decir, $ 100.00 pero podra haber asumido
cero decimales (es decir, $ 100) o ms de dos decimales lugares (por ejemplo, $ 100,0000)
En cualquier caso, es una buena idea para indicar sus supuestos a continuacin, otras personas
pueden verlos y le permiten saber si son correctas o no.

En el diseo de los casos de prueba de este software que se asegurara de que las tres
particiones de equivalencia vlidos son cada vez cubiertas, y tambin pondra a prueba la
particin no vlida al menos una vez. As, por ejemplo, podemos elegir calcular el inters
sobre los saldos Pu- $ 10.00 $ 50.00 $ 260.00 y $ 1,348.00. Si no tenamos identificado
especficamente estas particiones, es posible que al menos uno de ellos se podra haber
perdido a expensas de probar otras varias veces. Tenga en cuenta que tambin podramos
aplicar la particin de equivalencia a las salidas tambin.
En este caso tenemos tres tipos de inters: 3%, 5% y 7%, ms el error mensaje para la
particin no vlida (o particiones). En este ejemplo, las salidas de particiones se alinean
exactamente con las particiones de entrada.
Cmo le podra probar esto sin pensar en las particiones? Un testers ingenuo (vamos a
llamar a l Robbie) podra haber pensado que un buen conjunto de pruebas se poner a prueba
todos los $ 50. Eso dara a las siguientes pruebas: $ 50.00 $ 100.00 $ 150.00, $ 200.00 $
250.00 ... decir hasta $ 800.00 (continuacin Robbie habra conseguido cansado de l y pens
que suficientes pruebas se han llevado a cabo). Pero mira lo que Robbie ha probado: slo
dos de cada cuatro particiones! As que si el sistema no correspondiente a manejar un saldo
negativo o un saldo de $ 1000 o ms, que no lo hara 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 ms pruebas (16 pruebas en comparacin con nuestras
cuatro pruebas utilizando particiones de equivalencia), por lo que tambin es mucho menor
eficiente! Es por esto que decimos que el uso de tcnicas como esta hace que las pruebas
tanto ms eficaz y ms eficiente.
Tenga en cuenta que cuando decimos que una particin es "no vlida", 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. Slo significa que no es uno de los aportes esperados de este
campo particular. El software debe manejar correctamente los valores de la invlida
particin, al responder con un mensaje de error como "El balance debe ser al menos $ 0.00 '.
Tenga en cuenta tambin que la particin no vlida puede no ser vlido slo en el contexto
de abono pagos de inters. Una cuenta que est sobregirada requerir algn tipo de accin
diferente.

anlisis de valores lmite

Anlisis de valores lmite (BVA) se basa en las pruebas en los lmites entre
particiones. Si alguna vez has hecho 'verificacin de rango', que estaba probablemente se
est utilizando la tcnica de anlisis de valores lmite, incluso si usted no era consciente de
ello. Tenga en cuenta que ambos tienen lmites vlidos (en las particiones vlidas) y los
lmites vlidos (en las particiones no vlidos).
A modo de ejemplo, considere una impresora que tiene una opcin de entrada del nmero
de copias a realizar, de 1 a 99.

Para aplicar anlisis de valores lmite, tomaremos el mnimo y mximo (Lmite) valores de
la particin vlida (1 y 99 en este caso) junto con el primero o el ltimo valor,
respectivamente, en cada una de las particiones no vlidas adyacentes a la particin vlida (0
y 100 en este caso). En este ejemplo tendramos tres pruebas de equivalencia de particin
(uno de cada una de las tres particiones) y cuatro pruebas de contorno.
Considere el sistema bancario se describe en la seccin sobre la equivalencia
particionamiento.

Debido a que los valores lmite se definen como aquellos valores en el borde de una particin,
hemos identificado los siguientes valores lmite: - $ 0.01 (un invlido valores en la frontera,
ya que est en el borde de una particin no vlido), $ 0,00, $ 100.00 $ 100.01, $ 999.99 y $
1000.00 todos los valores lmite vlidos.

As que mediante la aplicacin de anlisis de valores lmite tendremos seis pruebas para la
frontera valores. Compara lo que nuestro modelo de prueba ingenua Robbie haba hecho;
hizo realidad golpe a uno de los valores lmite ($ 100) a pesar de que era ms por accidente
que el diseo. As que adems de las pruebas slo la mitad de las particiones, Robbie slo ha
probado uno sexta parte de los lmites (por lo que ser menos eficaz en la bsqueda de
cualquier frontera defectos). Si tenemos en cuenta todas nuestras pruebas, tanto para la
particin de equivalencia y el anlisis de valores lmite, las tcnicas nos dan un total de nueve
pruebas, en comparacin a los 16 que Robbie tena, as que estamos siendo
considerablemente ms eficiente, as como siendo tres veces ms eficaces (prueba cuatro
particiones y seis obligadas, por lo que las condiciones de 10 en total en comparacin con los
tres).
Tenga en cuenta que, en el ejemplo de los intereses bancarios, tenemos las particiones vlidas
al lado de otras particiones vlidas. Si nos vamos a considerar un lmite vlido para el inters
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 lmite invlido; en realidad es un lmite vlido porque cae en una
particin vlida. As que la particin para 5%, por ejemplo, no tiene invlido los valores de
lmites asociados con las particiones prximos a l.
Una buena manera de representar las particiones y los lmites vlidos y no vlidos se
encuentra en una tabla como la Tabla 4.1:
TABLA 4.1 particiones de equivalencia y lmites
Al mostrar los valores de la tabla, se puede observar que hay un mximo especificado para
la tasa de inters del 7%. Ahora nos gustara saber cul es el valor mximo es de un saldo de
cuenta, por lo que podemos probar ese lmite.
Esto se llama una "frontera abierta", porque uno de los lados de la particin queda abierto,
es decir, no se define. Pero eso no quiere decir que podemos ignorarlo, debemos todava
tratar de probarlo, pero cmo? fronteras abiertas son ms difciles de probar, pero hay
maneras de abordarlas. En realidad, la mejor solucin al problema consiste en averiguar cul
es el lmite y debe especificarse como! Un mtodo consiste en volver a la especificacin de
ver si un mximo ha indicado en otro lugar para una cantidad de equilibrio. Si as, entonces
sabemos lo que nuestro valor lmite es. Otro enfoque podra ser la de investigar otras reas
conexas del sistema. Por ejemplo, el campo que sostiene la figura saldo de la cuenta puede
ser slo seis cifras decimales ms dos figuras. Esto dara un saldo de la cuenta mxima de $
999 999.99, as que podra usar eso como nuestro mximo valor lmite. Si realmente no
podemos encontrar nada de lo que debe ser este lmite, entonces es probable que utilizaremos
un enfoque intuitivo basado en la experiencia para investigar diversos valores grandes
tratando para hacer que falle.

Podramos tambin tratar de averiguar sobre el lmite inferior abierto - cul 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 ms a fondo si queramos ser.
En representacin de las particiones y los lmites de una tabla como sta tambin hace que
sea ms fcil para ver si est o no han probado cada uno (si ese es su objetivo).

La extensin de la particin de equivalencia y anlisis de valores lmite

Hasta aqu, mediante el uso de condiciones de PE y BVA que hemos identificado que podra
ser probadas, es decir, particiones y los valores lmite. Las tcnicas se utilizan para identificar
condiciones con prueba, lo que podra estar en un nivel bastante alto (por ejemplo, "cuenta
de bajo inters ') o en un nivel de detalle (por ejemplo, "valor de $ 100.00"). Hemos estado
buscando en la aplicacin de estas tcnicas a rangos de nmeros. Sin embargo, tambin
podemos aplicar las tcnicas a otras cosas.
Por ejemplo, si se reserva un vuelo, usted tiene una opcin de Economa / autocar, entradas
Premium Economy, Business o Primera Clase. cada uno de estos es una particin de
equivalencia en su propio derecho y deben ser probados, pero no tiene sentido hablar de
lmites para este tipo de particin, que es una coleccin de cosas vlidos. La particin no
vlida sera 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
debera ser posible escribir cualquier otra cosa, pero siendo una buena prueba para probar al
menos una vez en algn campo desplegable. Cuando se est analizando, la base de prueba
(por ejemplo, una especificacin de requisitos), la particin de equivalencia puede ayudar a
identificar dnde una lista desplegable sera apropiada.
Cuando se trata de identificar un defecto, puede probar con varios valores en una
particin.
Si esto se traduce en un comportamiento diferente en el que esperaba que fuera la misma, a
continuacin, puede haber dos (o ms) particiones en el que inicialmente se pens que haba
solo uno.
Podemos aplicar la particin de equivalencia y anlisis de valores lmite 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 bsicas que nuestros
usuarios pueden elegir a la hora de establecer sus sistemas, con un nmero de opciones para
cada configuracin. Las configuraciones bsicas del sistema podran ser administrador,
gerente y el enlace al cliente. Estos representan tres particiones de equivalencias que podran
ser probados. Podramos tener graves problemas si nos olvidamos de probar la configuracin
para el administrador del sistema, por ejemplo.
Tambin podemos aplicar la particin de equivalencia y anlisis de valores lmite ms de una
vez para el mismo elemento de la especificacin. Por ejemplo, si un sistema interno de
telfono para una empresa con 200 telfonos tiene los nmeros de extensin de 3 dgitos 100-
699, podemos identificar los siguientes particiones y lmites:
Los dgitos (caracteres 0 a 9) con la particin no vlida que no contienen dgitos
nmero de dgitos, 3 (valores lmite por lo que no vlidas de 2 dgitos y 4 dgitos)
rango de nmeros de extensin, 100 a 699 (valores lmite as que no vlidas de 099y 700)
extensiones que estn en uso y las que no lo son (dos particiones vlidas, no hay lmites)
los nmeros de extensin menor a mayor y que estn en uso tambin se podran usar como
valores de lmite

Un caso de prueba podra probar ms de una de estas particiones / lmites. Por ejemplo,
extensin 409, que est en uso pondra a prueba cuatro particiones vlidas: dgitos, el nmero
de dgitos, el rango vlido, y la particin 'en uso'. Tambin pone a prueba los valores lmite
para los dgitos, 0 y 9.
Cuntos casos de prueba qu tenemos que probar todas estas particiones y lmites, tanto
vlidos y no vlidos? Necesitaramos un no-dgitos, a 2 dgitos y nmero de 4 dgitos, los
valores de 99, 100, 699 y 700, una extensin que no est en utilizar, y, posiblemente, las
extensiones de menor a mayor y en uso. Se trata de diez u once aos de casos de prueba el
nmero exacto depender de lo que se podra combinar en un solo caso de prueba.
Compare esto con el ejemplo nmero de un dgito en la Seccin 1.1.6. Aqu nosotros
encontramos que tenamos 68 pruebas slo para probar un campo de un dgito, si tuviramos
que probarlo a fondo. En el particionado equivalencia y anlisis de valores lmite ayuda
identificar las pruebas que tienen ms probabilidades de encontrar defectos, y para utilizar
menos casos de prueba para encontrarlos. Esto es porque el contenido de una particin es
representativo de todos de los valores posibles. En lugar de prueba de los diez dgitos
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 numrico, uno puede representar a todos ellos. As
que tenemos cuatro pruebas (En lugar de 68) para un campo de un dgito.
Como hemos mencionado anteriormente, tambin podemos aplicar estas tcnicas a la salida
particiones. Considere la siguiente extensin a nuestro ejemplo del tipo de inters bancario.
Supongamos que un cliente con ms de una cuenta puede tener un extra de 1% inters en esta
cuenta si tienen al menos $ 1000 en l. Ahora tenemos dos posibles valores de salida (7% de
inters y un 8% de inters) para el mismo saldo de la cuenta, por lo que hemos identificado
otra condicin de prueba (tasa de inters del 8%). (Tambin han identificado la misma
condicin de salida examinado con ms clientes de una cuenta, que es una particin de tipos
de cliente.)
particin de equivalencia se puede aplicar a diferentes tipos de entrada tambin.
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 tambin
un buen lugar para buscar las particiones (y los lmites). Por ejemplo, el valor de un
parmetro de la interfaz puede caer en particiones de equivalencia vlidos y no vlidos. Este
tipo de defecto es a menudo difcil 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 integracin
(ya sea integracin de componentes o la integracin del sistema).
anlisis del valor lmite puede ser aplicado a la totalidad de una cadena de caracteres (por
ejemplo, un nombre o direccin). El nmero de caracteres de la cadena, por ejemplo, entre 1
y 30 caracteres es la particin vlida lmite de 1 y 30. Los lmites seran vlidos 0 personajes
(nulo, simplemente pulse la tecla de retorno) y 31 caracteres. Ambas deberan producir un
mensaje de error.
Particiones tambin pueden identificarse para la creacin de datos de prueba. Si hay
diferentes tipos de registro, ser la prueba ms representativa si se incluye un registro de
datos de cada tipo. El tamao de un registro es tambin una particin con lmites, as que
podra incluir registros mximos y mnimos de tamao en la base de datos de prueba.
Si usted tiene algn conocimiento acerca de cmo el interior est organizado fsicamente,
puede ser capaz de identificar algunos lmites ocultos. Por ejemplo, si un bloque de
almacenamiento de desbordamiento se utiliza cuando se introducen ms de 255 caracteres en
un campo, las pruebas de contorno incluira 255 y 256 caracteres en que campo. Esto puede
ser al borde de pruebas de caja blanca, ya que tenemos cierto conocimiento de cmo est
estructurado los datos, pero no importa cmo clasificamos las cosas, siempre como nuestra
prueba es eficaz en la bsqueda de defectos. No se colg en una fina distincin 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 anlisis de valores en la frontera, pensamos en la frontera como una lnea divisoria
entre dos cosas. Por lo tanto, tenemos un valor a cada lado de la frontera (pero el lmite en s
no es un valor).

En cuanto a los valores de nuestro ejemplo impresora, 0 es invlida en una particin, 1

y 99 estn en la particin vlida y 100 est en la otra particin invlida. Entonces el
lmite 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 lmite. Por tradicin, estos son los
valores de la particin vlida (es decir, los valores especificado). Este enfoque requiere
entonces tres valores para todos los lmites de dos, por lo que tendra 0,1 y 2 para el lmite
izquierdo, y 98, 99 y 100 del lmite derecha en este ejemplo. Los valores lmite se dice que
son "en y, o bien lado de la frontera 'y el valor que es "en" generalmente se toma el lmite
para estar en la particin vlida.
Tenga en cuenta que Beizer habla acerca de las pruebas de dominio, una generalizacin
de particionamiento de equivalencia, con lmites de tres valores. Se hace una distincin
entre las fronteras abiertas y cerradas, donde un contorno cerrado es aquel en el punto
se incluye en el dominio. Por lo que la convencin es vlida para la particin tener
lmites cerrados. Usted puede saber que no lo hace tiene que saber esto para el
examen! British Standard 7925-2 estndar para Software de pruebas de componentes
tambin define un enfoque de tres valores en Boundary anlisis de valor.

Entonces, cul es el mejor enfoque? Si se utiliza el enfoque de dos valores juntos con la
particin de equivalencia, que son igualmente eficaces y poco ms 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 cul es la correcta eleccin, en cualquier caso.

El diseo de casos de prueba

Una vez identificadas las condiciones que desea probar, en este caso mediante el uso de
Equivalencia de particionamiento y anlisis de valores lmite, el siguiente paso es
disear los casos de prueba. Las condiciones de prueba que pueden ser cubiertos en un solo
caso de prueba, Se necesitarn el menor nmero 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 confa que las va a pasar. Sin embargo, si no pasa
la prueba, entonces tenemos que averiguar por qu fallo, cul 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 cmo un caso de prueba puede cubrir una o ms condiciones de
prueba. Utilizando el ejemplo saldo bancario, nuestra primera prueba podra ser de un
nuevo cliente con un saldo de $ 500. Esto cubrira un equilibrio en la particin desde $
100.01 a $ 999.99 y una particin de salida de una tasa de inters del 5%. Tambin estaramos
cubriendo otras particiones que an no hemos explicado. por ejemplo, un cliente vlido, un
nuevo cliente, un cliente con una sola cuenta, etc. Todas las particiones cubierto en esta
prueba son las particiones vlidas.
Cuando llegamos a probar particiones no vlidas, la opcin ms segura es, probablemente,
para tratar de cubrir slo una condicin de prueba vlida 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 vlido al cliente, direccin no
vlida, y el equilibrio vlido, se puede recibir un mensaje de error que dice "entrada no
vlida" y usted no sabe si la prueba ha detectado slo una entrada vlida o todos ellos. (Esto
tambin es la razn especfica 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 diseo de casos de prueba que cubren la mayor cantidad de condiciones
invlidas de una sola vez como sea posible. Por ejemplo, si cada campo no vlido en una
forma tiene algo de texto de color rojo por encima o por debajo del campo diciendo que este
campo no es vlido 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 vlidos y no
vlidos.

Para cubrir los casos de prueba lmite, puede ser posible combinar la totalidad de los lmites
vlidos mnimos para un grupo de campos en un caso de prueba y tambin los valores
mximos de contorno. Los lmites no vlidos podran ser probados juntos si la validacin se
realiza en todos los campos; de lo contrario, deben ser probados por separado, Al igual que
con las particiones no vlidos.

Por qu usar tanto la particin de equivalencia y anlisis de valores lmite?

Tcnicamente, porque a cada lmite de alguna particin, se hace un lmite de anlisis de valor
tambin y se ha colocado a prueba cada particin de equivalencia.
Sin embargo, este enfoque puede causar problemas si ese valor no fue slo el valor lmite
que fall o dej toda la particin. Tambin mediante la prueba lmites que probablemente no
dara a los usuarios mucha confianza ya que estamos usando los valores extremos en lugar
de valores normales. Los lmites pueden ser ms difcil (y por lo tanto ms costoso) para
establecer as.
Por ejemplo, en el ejemplo copias de impresora descrito anteriormente se identificaron los
siguientes valores lmite:

Supongamos que prueba slo los valores vlidos de contorno 1 y 99 y nada entre ellos. Si
pasan ambas pruebas, esto parece indicar que todo el valor intermedio tambin debera
funcionar. Sin embargo, supongamos que una pgina se imprime correctamente, pero 99
pginas no. Ahora no sabemos si cualquier conjunto de ms de una pgina funciona, por lo
que haramos primero sera poner a prueba para decir 10 pginas, es decir, un valor de la
particin de equivalencia.
Le recomendamos que pruebe las particiones por separado de las fronteras esto significa la
eleccin de valores de particin no son valores lmite.
Sin embargo, si se utiliza el mtodo del valor lmite de tres valores, a continuacin, tendra
valores lmite vlidos de 1, 2, 98 y 99, as que tener una equivalencia separada del valor,
adems de los dos valores lmites adicionales no dara mucho beneficio adicional. Pero se
dio cuenta de que un valor de equivalencia, por ejemplo 10, sustituyendo tanto de los dos
valores lmite adicionales (2 y 98). Esta es la razn por la particin equivalencia con el
anlisis de valores lmite de dos valores es ms eficiente que el de tres valores anlisis
de valores lmite.
Qu particiones y los lmites 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 ms a fondo, a continuacin, siga el procedimiento
de las pruebas de las particiones vlidas en primer lugar, a continuacin, las particiones
no vlidas, entonces vlida los lmites y las fronteras finalmente no vlidos. Sin embargo,
si usted es menor de tiempo presin y no puede evaluar todo (y quin no lo es?),
entonces la prueba objetiva le ayudar a decidir qu vamos a probar. Si necesitas una
confianza de los usuarios de operaciones tpicas con un nmero mnimo de pruebas, que
pueden hacer para vlidar slo peticiones. Si desea encontrar el mayor nmero posible de
defectos tan pronto como sea posible, es posible comenzar con los valores lmite, vlidas y
no vlidas. si quieres la confianza de que el sistema se encargar de malas entradas
correctamente, puede hacerlo particiones principalmente no vlidas y los lmites. Su
experiencia previa de los tipos de defectos encontrados puede ayudar a encontrar
defectos similares; por ejemplo, si hay tpicamente un nmero de defectos de contorno,
entonces empezara por las pruebas lmites.
particionamiento equivalencia y anlisis de valores lmite 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 anlisis de valores lmite se describen en BS7925-2, incluyendo el diseo de
pruebas y medicin de la cobertura.

4.3.2 prueba de tablas de Decisin

Por qu utilizar las tablas de decisin?
Las tcnicas de particin de equivalencia y anlisis de valores lmite se aplica a
situaciones o entradas especficas. Sin embargo, si diferentes combinaciones de entradas
resultan en diferentes acciones adoptadas, esto puede ser ms difcil de mostrar utilizando el
particionado equivalencia y anlisis de valores lmite, que tienden a estar ms centrado en la
interfaz de usuario. Las otras dos tcnicas basadas en la especificacin, tablas de decisin
y las pruebas de transicin de estado se centran ms en los negocios la lgica de negocio
o reglas.
Una tabla de decisin es una buena manera de tratar con combinaciones de cosas (por
ejemplo, entradas). Esta tcnica a veces tambin se conoce como una tabla 'causa-efecto'.
La razn de esto es que no es una tcnica de diagramas lgica asociada llamada 'causa-efecto
grfica' que a veces se utiliza para ayudar a la deriva tabla de decisin (Myers describe esto
como una red lgica combinatoria [Myers, 1979]). Sin embargo, la mayora de las personas
les resulta ms til slo para usar la tabla descrita en [Copeland, 2003].
Si comienza a utilizar las tablas de decisin para explorar cules 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 tambin. Anime a esto, como lo har
hacer su trabajo ms fcil en el futuro. Las tablas de decisin proporcionan una forma
sistemtica de indicando las reglas de negocio complejas, que es til para los
desarrolladores, as como para testers. Las tablas de decisin se pueden utilizar en el
diseo 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 prctica reglas de negocio correctamente. Ayudar a los desarrolladores
hacer un mejor trabajo tambin puede conducir a una mejor relacin con ellos.
Pruebas de combinaciones puede ser un reto, ya que el nmero de combinaciones a
menudo puede ser enorme. Probar todas las combinaciones puede ser poco prctico, si no
imposible. Tenemos que estar satisfecho con las pruebas de slo un pequeo
subconjunto de combinaciones, pero tomar la decisin de qu combinaciones para
probar y cules dejar fuera eso no es trivial. Si usted no tiene una forma sistemtica de la
seleccin de combinaciones, un subconjunto arbitrario ser utilizada y esto puede resultar en
una prueba ineficaz.
Las tablas de decisin ayudan a la seleccin sistemtica de casos de prueba eficaz y
puede tener el efecto secundario beneficioso de encontrar problemas y ambigedades
en la especificacin. Es una tcnica que funciona bien en conjunto con la equivalencia
particion. La combinacin de condiciones explorado puede ser combinaciones de
particiones de equivalencia.
Adems de las tablas de decisin, hay otras tcnicas 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 tcnicas es [Pol et al., 2001]. Las tablas de decisin y de
causa-efecto grfica se describen en [BS7925-2], incluyendo el diseo de pruebas y la
medicin de la cobertura.

Utilizando las tablas de decisin para el diseo de la prueba

La primera tarea es identificar una funcin o subsistema adecuado que tiene un
comportamiento que reacciona de acuerdo con una combinacin de entradas o
eventos. El comportamiento de inters no debe ser demasiado extensa (es decir, no debe
contener demasiadas entradas) De otra manera el nmero de combinaciones se convertir
engorroso y difcil de gestionar. Es mejor tratar con un gran nmero de condiciones
dividindolos en subconjuntos y hacer frente a los subconjuntos de una en una.
Una vez que haya identificado los aspectos que deben ser combinados, a continuacin,
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 prstamo, donde se puede
introducir el importe de la cuota mensual o el nmero de aos que desea tomar para pagarlo
(el trmino del prstamo). Si introduce tanto, el sistema har un compromiso entre los dos si
entran en conflicto. Las dos condiciones son la cantidad del prstamo y el trmino, por lo que
los ponemos en una tabla (ver Tabla 4.2).

A continuacin, vamos a identificar todas las combinaciones de verdadero y falso (vase

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 nmero 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 pequeos grupos
de combinaciones a la vez. Con el fin de realizar un seguimiento de cules 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
combinacin (ver Tabla 4.4). En este ejemplo, podemos entrar en una o ambas los dos
campos. Cada combinacin se refiere a veces como una regla.

En este punto, podemos darnos cuenta de que no habamos pensado en lo que sucede si el
cliente no entra nada en ninguno de los dos campos. La tabla ha puesto de relieve una
combinacin que no fue mencionado en la especificacin para este ejemplo. Podramos
suponer que esta combinacin debe dar lugar a un mensaje de error, por lo que tenemos que
aadir otra accin (vase el cuadro 4.5). este alto ilumina la fuerza de esta tcnica para
descubrir omisiones y ambigedades en presupuesto. No es inusual para algunas
combinaciones para ser omitidas de presupuesto; Por lo tanto, esto tambin es una tcnica
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 Tambin
debe ser un mensaje de error si se introducen, por lo que se ver como la tabla 4.6.
Usted puede notar ahora que slo hay un "S" en cada columna, es decir, nuestras acciones
son mutuamente excluyentes una sola accin se produce para cada combinacin de
condiciones. Podramos 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 ms
de una accin los resultados de cualquiera de las combinaciones, entonces sera mejor para
mostrar como filas separadas en lugar de combinarlos en una fila.

El paso final de esta tcnica es escribir casos de prueba para ejercer cada uno de los
cuatro reglas en nuestra la tabla.
En este ejemplo empezamos mediante la identificacin de las condiciones de entrada y
luego identificar los resultados. Sin embargo, en la prctica podra funcionar al revs,
podemos ver que hay una serie de resultados diferentes, y tienen que trabajar atrs para
entender qu combinacin de condiciones de entrada en realidad conducir los resultados. La
tcnica funciona igual de bien lo hace de esta manera, y bien puede ser un enfoque iterativo
a medida que descubre ms sobre las reglas que impulsan el sistema.

Tarjeta de crdito ejemplo prctico

Veamos otro ejemplo. Si usted es un cliente nuevo que abre una tarjeta de crdito
cuenta, usted obtendr un descuento del 15% en todas sus compras hoy. Si usted es un
cliente existente y que mantenga una tarjeta de fidelizacin, se obtiene un descuento del
10%. Si tienen un cupn, se puede obtener un 20% de descuento en la actualidad (pero no se
puede utilizar con la "nuevo cliente descuento). Se aaden cantidades de descuento, si
procede. Esto se muestra en la Tabla 4.8.

TABLA 4.8 Tabla de decisiones, por ejemplo, tarjeta de crdito

En la Tabla 4.8, las condiciones y las acciones se enumeran en la columna de la izquierda.
Todas las dems columnas de la tabla de decisin representan cada regla separada, una para
cada combinacin de condiciones. Podemos optar por probar cada descartar / combinacin y
si hay slo unos pocos lo cual suele ser el caso.
Sin embargo, si el nmero de reglas / combinaciones es grande, es ms probable que
probarlas mediante la seleccin 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 combinacin no debera 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 cul debera ser ese mensaje, se ser aun as obtener una
buena prueba.
Hemos hecho una suposicin en la Regla 3. Desde el cupn tiene un mayor descuento que el
nuevo descuento al cliente, suponemos que el cliente elegir 20% en lugar de 15%. No
podemos aadirlos, ya que el cupn no puede ser utilizado con el descuento 'nuevo
cliente'. La accin del 20% es una suposicin por nuestra parte, y debemos comprobar que
este supuesto (y cualquiera otra suposicin que hacemos) es correcta, pidiendo a la persona
que escribi la especificacin o los usuarios.
Por regla 5, sin embargo, podemos aadir los descuentos, ya que tanto el cupn y el descuento
de la tarjeta de fidelizacin debe aplicarse (al menos esa es nuestra hiptesis).
Reglas 4, 6 y 7 tienen un solo tipo de descuento y el Artculo 8 no tiene descuento.
por lo que 0%.
Si estamos aplicando esta tcnica a fondo, tendramos una prueba para cada columna o regla
de nuestra tabla de decisiones. La ventaja de hacer esto es que podemos probar una
combinacin de cosas que de otro modo quizs no hemos probado y que podra 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 ms
importantes. Tener la tabla completa nos permite ver qu combinaciones decidimos
probar y que no para poner a prueba esta vez.
Tambin 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 decisin muestra las acciones que se aplican a cada combinacin
de condiciones.
En el ejemplo anterior todas las condiciones son binarias, es decir, tienen slo dos
posibles valores: Verdadero o Falso (o, si lo prefiere S o No). A menudo es el caso que las
condiciones son ms complejos, que tienen potencialmente muchos valores posibles.
Cuando este es el caso es probable que sea muy grande el nmero de combinaciones, por lo
las combinaciones slo pueden ser muestreados en lugar de ejercer todos ellos.

4.3.3 Pruebas de transicin Estado

Pruebas de transicin de estados se utiliza cuando algn aspecto del sistema se describe en
lo que se llama una "mquina de estados finitos. Esto significa simplemente que el
sistema puede estar en un nmero (finito) de estados diferentes, y las transiciones de un
estado a otro estn determinados por las reglas de la "mquina". 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 (Vase la Figura 4.2).
Por ejemplo, si solicita retirar $ 100 de un cajero automtico, es posible haber dado
efectivo. Ms adelante puede hacer exactamente la misma peticin, 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
operacin 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 ningn documento abierto, luego 'Cerrar' no est disponible. Despus 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 transicin de estado tiene cuatro partes bsicas:

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 transicin (el cierre de un archivo o la retirada de dinero);
se dan las acciones que resultan de una (un mensaje de error de transicin o su dinero en
efectivo).

Tenga en cuenta que, en cualquier estado dado, un evento puede causar una sola accin, pero
el mismo evento de un estado diferente, puede causar una accin diferente y un estado final
diferentes.
Vamos a ver por primera vez en los casos de prueba que ejecutan las transiciones de estado
vlidos.
La figura 4.2 muestra un ejemplo de introducir un nmero de identificacin personal (PIN)
a una cuenta bancaria. Los estados se muestran como crculos, las transiciones como
lneas con flechas y los eventos como el texto cercano a las transiciones. (Nosotros no
hemos demostrado la accin explcitamente en este diagrama, pero seran un mensaje al
cliente diciendo cosas tales como "Por favor, introduzca su PIN '.)

El diagrama de estados muestra siete estados, pero slo cuatro eventos posibles (tarjeta
insertado, Entrar PIN, PIN y el PIN OK no OK). No hemos especificado todas las posibles
transiciones, aqu hay tambin seran un tiempo de espera de "esperar a que el PIN ' y desde
los tres intentos que volver al estado inicial despus de la hora haban transcurrido y,
probablemente expulsar la tarjeta. Tambin habra una transicin del estado "volver la tarjeta
de nuevo al estado de inicio. No hemos especificado todos los posibles eventos o bien no
sera una opcin "cancelar" de "esperar a que el PIN '

y desde los tres intentos, lo que tambin se remontan al estado de inicio y expulsar la
tarjeta. El estado de cuenta de acceso 'sera el comienzo de otro diagrama de estado que
muestra las transacciones vlidas que pueden ser asumidas en la cuenta.
Sin embargo, este diagrama de estado, a pesar de que es incompleta, todava nos da
informacin sobre cual disear, algunas pruebas tiles y para explicar la transicin de tcnica
de estado.
Al derivar casos de prueba, podemos empezar con un escenario tpico. A primera vista el
caso de prueba en este caso sera la situacin normal, donde se introduce el PIN correcto
la primera vez. Para ser ms 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 transicin. Una segunda prueba (para visitar todos los estados) sera la de
introducir una PIN incorrecto cada vez, para que el sistema se come la tarjeta. Todava no
hemos probado cada transicin todava. Con el fin de hacer eso, nos gustara 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 transicin no tiene que cambiar a un estado diferente (aunque todas
las transiciones que se muestran arriba que ir a un estado diferente). Lo que podra haber una
transicin de la 'cuenta de acceso, que simplemente se remonta a' cuenta de acceso 'para una
accin como "equilibrio solicitud'.
Las condiciones de prueba se pueden derivar de la grfica del estado de varias maneras. Cada
Estado puede sealar como una condicin de prueba, al igual que cada transicin. En el
inicio, pueda que no tenga que ser capaz de identificar la cobertura de un conjunto de pruebas
en trminos de transiciones.
Yendo ms all del nivel esperado en el inicio, tambin podemos considerar transicin
pares y triples y as sucesivamente. La cobertura de todas las transiciones individuales
es tambin conocida como la cobertura 0-interruptor, la cobertura de pares de
transicin es la cobertura l-switch, la cobertura de triples de transicin es la cobertura
de 2 controles, etc. Derivacin de casos de prueba a partir del modelo de transicin de
estados es un enfoque de caja negra. La medicin de la cantidad que han probado (cubierta)
se est acercando a un punto de vista de caja blanca. Sin embargo, el estado pruebas de
transicin es considerada como una tcnica de caja negra.
Una de las ventajas de la tcnica de transicin de estados es que el modelo puede ser tan
detallada o tan abstracto como usted necesita que sea. Cuando una parte del sistema es
ms importante (es decir, requiere ms 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 sera de otra manera una serie de diferentes
estados.

Las pruebas para las transiciones no vlidas

Derivacin de pruebas slo a partir de un diagrama de estados (tambin conocido como un
diagrama de estado) es muy bueno para ver las transiciones vlidas, pero es posible que no
vea fcilmente las pruebas negativas, donde tratamos de generar transiciones no vlidas. Con
el fin de ver el nmero total de combinaciones de estados y transiciones, vlidas y no vlidas,
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 errneos, acontecimientos que no se espera que
sucedern 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 insercin de una tarjeta
que lleve al Estado 2. Si estamos en el estado 2, y se introduce un PIN vlido, vamos al
Estado el 6 de acceder a la cuenta. En el estado 2 si introduce un nmero incorrecto,
vamos a 3. Estado han puesto un guion en las celdas que deberan ser imposible, es
decir, representan no vlido transiciones de ese estado.
Hemos puesto un signo de interrogacin de dos celdas, en donde entramos ya sea vlida o
una PIN no vlido cuando estamos accediendo a la cuenta. Tal vez el sistema tomar nuestro
nmero PIN como la cantidad de dinero en efectivo a retirar Podra ser una buena prueba!
La mayora de las otras celdas no vlidos sera fsicamente imposible en este ejemplo.
pruebas no vlidas (negativos) intentarn generar transiciones no vlidas, las transiciones que
no debera ser posible (pero a menudo tomar buenas pruebas cuando resulta que son posible).
Una descripcin ms extensa de las mquinas de estado se encuentra en [Marick,
1994]. pruebas de transicin de estados tambin se describe en [Craig, 2002], [Copeland,
2003], [Beizer, 1990] y [Broekman, 2003]. Transicin de estado las pruebas se describen en
BS7925-2, incluyendo pruebas de diseo y cobertura medidas.

4.3.4 Pruebas de caso de uso

Las pruebas de casos de uso es una tcnica que nos ayuda a identificar casos de prueba que
ejercitan el sistema entero de transaccin por transaccin 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 descripcin 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 especfica (o, al menos, producir algo de valor para el usuario). Los actores
son por lo general las personas, pero tambin 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 trminos del actor, no del sistema, describiendo lo que el
actor hace y lo que el actor ve, ms que lo que el sistema espera de entradas y lo que los
sistemas arrojan en la salida. A menudo utilizan el lenguaje y los trminos del negocio
en lugar de trminos tcnicos, 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 aceptacin.
Los casos de uso pueden descubrir defectos de integracin, es decir, los defectos causados
por la interaccin incorrecta entre los diferentes componentes. Utilizado de esta manera, el
actor puede ser algo que las interfaces del sistema, como a un enlace de comunicacin o
subsistema.
Los casos de uso describen el proceso que fluye a travs 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 ms probable que venir a travs de la primera vez que utiliza
el sistema). Cada caso de uso por lo general tiene una corriente principal (o lo ms
probable) y, a veces escenario adicional ramas alternativas (que abarcan, por ejemplo, casos
especiales o condicin excepcional). Cada caso de uso debe especificar alguna condicin
previa que deben cumplirse para utilizar el caso para trabajar. Los casos de uso
tambin deben especificar condiciones posteriores que son observables. Los resultados y
una descripcin del estado final del sistema despus del caso de uso tiene ha ejecutado con
xito.
El ejemplo de PIN que se utiliz para la prueba de transicin de estado tambin podra ser
definida en trminos 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 podra
dejar de ser un xito).
Para las pruebas de casos de uso, tendramos una prueba de la hiptesis de xito y una tesis
para cada extensin. En este ejemplo, podemos dar la extensin 4b una prioridad ms alta
de 4a desde un punto de vista de la seguridad.
Requisitos del sistema tambin se pueden especificar como un conjunto de casos de
uso. Este enfoque puede hacer que sea ms fcil para involucrar a los usuarios en la
recopilacin de requisitos y el proceso de definicin.

4.4 ESTRUCTURA BASADA EN TCNICAS DE CAJA BLANCA

1 Describir el concepto y la importancia de la cobertura de cdigo. (K2)
2 Explicar los conceptos de la declaracin y la cobertura de decisin y bajo destacan
que estos conceptos se pueden utilizar tambin 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 diseo
de la prueba tcnicas: (K3)
a) declaracin cobertura;
b) la cobertura de decisin.
4 Evaluar declaracin y cobertura de decisin para la integridad. (K3)

En esta seccin vamos a analizar en detalle el concepto de cobertura y cmo se puede utilizar
para medir algunos aspectos de la rigurosidad de las pruebas. Con el fin de ver cmo en
realidad funciona la cobertura, vamos a utilizar algunos ejemplos a nivel de cdigo (aunque
la cobertura tambin se aplica a otros niveles, como los procedimientos de negocio). En
particular, vamos a mostrar cmo medir la cobertura de los estados y decisiones, y los casos
de prueba de cmo 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 seccin, busque las definiciones de los trminos del glosario:

la cobertura de cdigo, la cobertura de decisin, la cobertura de sentencias, las pruebas,
las pruebas basadas en estructura estructural y pruebas de caja blanca

4.4.1 El uso de tcnicas basadas en la estructura para medir la cobertura y pruebas de

diseo
tcnicas basadas en la estructura sirven para dos propsitos: Medicin de cobertura de
la prueba y el diseo de casos de prueba estructural. A menudo se utilizan primero para
evaluar la cantidad de pruebas realizadas por pruebas derivados de tcnicas basadas en la
especificacin, es decir, para evaluar la cobertura. Ellos a continuacin, se utilizan para
disear pruebas adicionales con el objetivo de aumentar la cobertura de la prueba.

Tcnicas de diseo 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 sern el ejercicio de todas las partes del software desde el punto de vista de los
elementos que se estn cubiertos.

Qu es la cobertura de la prueba?
medidas de cobertura de las pruebas de alguna manera especfica la cantidad de las pruebas
realizadas por un conjunto de pruebas (derivado de alguna otra manera, por ejemplo,
utilizando tcnicas basadas en la especificacin). 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 bsica de cobertura es

dnde 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! tcnicas de cobertura miden slo una dimensin de una multi-
dimensin. 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 medicin de cobertura de cdigo es que mide la cobertura
de lo que ha sido escrito, es decir, el propio cdigo; no se puede decir nada sobre el software
que no se ha escrito. Si una funcin no ha aplicado, tcnicas de prueba basados en la
especificacin revelar esto. Si una funcin era omitida de la especificacin, a continuacin,
las tcnicas basadas en la experiencia pueden encontrarlo.
Pero las tcnicas basadas en la estructura slo pueden mirar a una estructura que ya
est ah.

Tipos de cobertura
Cobertura de la prueba se puede medir en base a los diferentes nmeros 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 integracin, el nivel de sistema o pruebas
de aceptacin.
Por ejemplo, en el sistema o nivel de aceptacin, los elementos de cobertura pueden ser
requisitos, opciones de mens, pantallas, o las transacciones comerciales tpicas. otra
cobertura medidas incluyen cosas tales como elementos estructurales de base de datos
(registros, campos y sub-campos) y archivos. Es digno de la comprobacin de las nuevas
herramientas, como la herramienta de prueba mercado se desarrolla con bastante rapidez.
En el nivel de integracin, podramos medir la cobertura de interfaces o especfica las
interacciones que han sido probados. La cobertura de llamadas del mdulo, objeto o llamadas
procedimiento tambin se pueden medir (y con el apoyo de herramientas en cierta medida).
Podemos medir la cobertura para cada una de las tcnicas basadas en la especificacin como
bien:
EP: porcentaje de particiones de equivalencia ejercidas (podramos medir vlido y la
cobertura de particin no vlida por separado si esto tiene sentido);
BVA: porcentaje de lmites ejercidas (tambin podramos separar vlido y lmites vlidos
si hubiramos deseado);
Las tablas de decisin: porcentaje de reglas de negocio o columnas de tabla de decisiones
probado;
Prueba de transicin de estados: hay una serie de posibles medidas de cobertura:
- Porcentaje de estados visitados
- Porcentaje de transiciones (vlidos) ejercidas (esto se conoce como Chow de 0- la cobertura
del interruptor)
- Porcentaje de pares de transiciones vlidas ejercidas ('transicin' o pares la cobertura 1-
interruptor de Chow) y la serie ms larga de transiciones, como transicin triples, cudruples,
etc.
- Porcentaje de transiciones no vlidas ejercido (de la tabla de estado)

Las medidas de cobertura de las tcnicas basadas en la especificacin se aplicaran a

cualquier prueba nivel de la tcnica 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 ms 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
gestin de herramientas o una herramienta de gestin de pruebas.

Sin embargo, cuando la cobertura es discutida por los programadores, lo ms probable

es que se refiere a la cobertura de cdigo, donde los elementos estructurales se pueden
identificar usando una herramienta, ya que no es un buen apoyo de herramientas para
medir la cobertura de cdigo. Nosotros declaracin de la cubierta y la cobertura de decisin
en breve.
Las declaraciones y los resultados de decisin son dos estructuras que se pueden medir en el
cdigo y hay una buena herramienta de apoyo para estas medidas de cobertura. Cobertura de
cdigo se hace normalmente en los componentes y pruebas de integracin de componentes
s que se hace en absoluto. Si alguien dice tener cobertura de cdigo logrado, es importante
para establecer exactamente qu elementos del cdigo han sido cubiertas, como la
declaracin la cobertura (a menudo lo que se entiende) es significativamente ms dbil que
la cobertura de decisin o algunas de las otras medidas de cobertura de cdigo.

Cmo medir la cobertura

A efectos prcticos, la medicin de la cobertura es algo que requiere soporte de una
herramienta. Sin embargo, el conocimiento de los pasos que toma tpicamente para medir
la cobertura es til en la comprensin de los mritos relativos de cada tcnica. Nuestro
ejemplo se supone una herramienta de medida de cobertura intrusivo que altera el cdigo
mediante la insercin de instrumentacin:
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 cdigo.
4 Ejecute las pruebas para las cuales se requiere la medicin de cobertura.
5 El uso de la salida de la instrumentacin, determina el porcentaje de elementos o artculos
ejercidos.

Instrumentacin de cdigo (paso 3) implica la insercin de cdigo junto a cada estructura de

elemento con el fin de registrar el momento en que el elemento estructural ha sido
ejercido. La determinacin de la medida de cobertura real (paso 5) es entonces una cuestin
del anlisis de la informacin registrada.
la medida de cobertura de cdigo se hace mejor con el uso de herramientas (como se describe
en Captulo 6) y hay un nmero 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 ms 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 comn con todas las tcnicas de pruebas basadas en la estructura, tcnicas de
cobertura de cdigo son los ms utilizados en las zonas de cdigo de software donde es
necesario pruebas ms completas. cdigo crtico con la seguridad; cdigo que es vital
para el funcionamiento correcto de una sistema y piezas complejas de cdigo son todos
ejemplos basado en tcnicas estructura son particularmente digno de la aplicacin. Por
ejemplo, DO178-B [RTCA] requiere cobertura estructural para ciertos tipos de sistema para
ser utilizada por el militares. tcnicas de cobertura estructurales se deben utilizar siempre,
adems de tcnicas de pruebas basadas en la experiencia, ms que como una basada en
especificacin y alternativa a ellos.

Diseo 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, slo tiene el 87% hasta el momento), entonces casos
adicionales de prueba pueden ser diseados con el objetivo de ejercer una parte o la
totalidad de la estructura a elementos donde an no llegaron. Este es el diseo de la
prueba basada en la estructura. Estas nuevas pruebas se ejecutan a continuacin, a
travs del cdigo 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 sera que todas las pruebas deben correr de nuevo en el
instrumentado cdigo.
Vamos a ver algunos ejemplos de la cobertura basada en la estructura y diseo de la prueba
para la declaracin y la toma de pruebas a continuacin.

4.4.2 Declaracin de la cobertura y de pruebas de requisitos

Declaracin 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 slo el 60%
y el 75% la cobertura de sentencias. Tpica 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 cdigo, aunque con una cobertura del 100% deben ser el mismo.
Vamos a ilustrar los principios de la cobertura de cdigo. Con el fin de simplificar nuestro
ejemplos, utilizaremos un pseudo-cdigo bsico esto no es ningn lenguaje de programacin
especfico, pero debe ser legible y comprensible para usted, incluso si no han hecho ninguna
programacin usted mismo.
Por ejemplo, considere el ejemplo de cdigo 4.1.

Para lograr el 100% de cobertura de la declaracin de este segmento de cdigo slo 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. Obsrvese que aqu estamos haciendo
pruebas estructurales de diseo 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 lnea como un comunicado. (Diferentes herramientas y
mtodos pueden contar cosas diferentes como las declaraciones, pero el principio bsico es
sin embargo el mismo que se cuentan.) Una declaracin puede ser en una sola lnea, o pueden
extenderse a varias lneas. Una lnea puede contener ms de una sentencia, slo una
declaracin, o slo una parte de un comunicado. Algunos estados pueden contener otros
estados dentro de ellos. En el ejemplo de cdigo 4.2, tenemos dos declaraciones de lectura,
una instruccin de asignacin, y luego una instruccin IF en tres lneas, pero el SI declaracin
contiene otra declaracin (impresin) como parte de ella.

Aunque no es del todo correcta, hemos numerado cada lnea y consideraremos cada lnea
como un comunicado. (Algunas herramientas pueden agrupar instrucciones que siempre
seran ejecutados juntos en un bloque bsico que se considera como una sola instruccin.)
Sin embargo, nos limitaremos a usar lneas numeradas para ilustrar los principios de la
cobertura de los estados (lneas). Vamos a analizar la cobertura de un conjunto de pruebas en
nuestro programa de seis declaraciones:
Cul lineas hemos cubierto?
En la prueba1_1, el valor de C ser de 8, por lo que cubrir las declaraciones sobre las lneas
1 a 4 y la lnea 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 aos, as que de nuevo vamos a cubrir el mismo
estado.
Puesto que hemos cubierto cinco de los seis estados, tenemos la declaracin 83%
cobertura (con tres pruebas). Lo que prueba qu necesitamos con el fin de cubrir
declaracin 5, la afirmacin de que no hemos ejercido todava 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 diseado una prueba para cubrir la
declaracin que todava no habamos cubierto.
Tenga en cuenta que la prueba 1_4 por s solo es ms efectividad (hacia nuestro objetivo de
100% de cobertura de declaracin) que las tres primeras pruebas juntos. Slo tomando
Prueba 1_4 en ms eficiente que el conjunto de cuatro pruebas, ya que a utilizado slo una
prueba en lugar de cuatro. Al ser ms eficaz y ms eficiente es la marca de una buena tcnica
de prueba.

4.4.3 Cobertura de decisin y pruebas de decisin

Una decisin es una instruccin IF, una declaracin de control de bucle (por ejemplo, do-
while o Repeat-until), o una instruccin CASE, donde hay dos o ms posibles salidas o
resultados de la declaracin. Con una instruccin IF, la salida puede o bien ser verdadera o
falsa, en funcin del valor de la condicin lgica que SI viene despus. Con una sentencia de
control de bucle, el resultado es o bien para llevar a cabo el cdigo dentro del bucle o no de
nuevo una salida Verdadero o Falso. la cobertura de decisin se calcula por:

Lo que se siente como pruebas funcionales razonablemente exhaustiva puede lograr

solamente 40% al 60% de cobertura de decisin, prueba tpica ad hoc puede cubrir slo 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 especificacin basada en
punto de vista, es posible que slo cubra dos tercios o tres cuartos de las decisiones. la
cobertura de decisin es ms fuerte que la cobertura de sentencias. Se reanudar la
cobertura de sentencias 'esto significa que el 100% de cobertura de decisin siempre
garantiza la cobertura de sentencias 100%. Cualquier medida de la cobertura ms fuerte
puede requerir ms casos de prueba para lograr una cobertura del 100%. Por ejemplo,
considere ejemplo de cdigo 4.1 nuevo.
Vimos anteriormente que se requera ese caso, slo una prueba para lograr el 100%
declaracin la cobertura ambiente. Sin embargo, la cobertura de decisin requiere cada
decisin que ha tenido tanto un resultado verdadero y falso. Por lo tanto, para lograr una
cobertura del 100% de decisin, un segundo caso de prueba es necesario que A es menor o
igual a B. Esta voluntad Asegurar que la declaracin de decisiones 'SI A> B' tiene un
resultado falso. As que una prueba es suficiente para la cobertura de declaracin 100%, pero
se necesitan dos pruebas para 100% la cobertura de decisin. Tenga en cuenta que la
cobertura de decisin 100% garantiza el 100% declaracin de cobertura, pero no al revs!

Vamos a suponer que ya tenemos la siguiente prueba, lo que nos da el 100% la cobertura de
sentencias por ejemplo de cdigo 4.3.
PRUEBA 2
Prueba 2_1: A = 20, B = 15

Qu resultados de la decisin que hemos ejercido con nuestra prueba? El valor de C es -10,
Por lo que la condicin de 'C <0' es cierto, por lo que se imprimir 'C negativo' y tenemos
ejercido el resultado de que la declaracin verdadera decisin. Pero no hemos ejercido el
resultado de la decisin de False. Qu otra prueba de qu tenemos que ejercer el resultado
falso y para lograr una cobertura del 100% de decisin? Antes de responder a esta pregunta,
vamos a echar un vistazo a otra forma de representar este cdigo. A veces, la estructura de
toma es ms fcil ver en un flujo de control diagrama (vase la Figura 4.4).
La lnea 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 instruccin IF.
Vamos a modificar nuestra prueba existente establecido mediante la adicin 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 decisin, True (con prueba 2_1) y Falso
(con prueba 2_2). Si tuviramos que dibujar el camino tomado por la prueba 2_2, sera una
lnea recta desde la declaracin de lectura abajo de la salida falsa ya travs de la endif. Tenga
en cuenta que podra haber elegido otros nmeros para lograr ya sea los resultados de
verdadero o falso.

4.4.4 Otras tcnicas basadas en la estructura

Hay otras tcnicas basadas en la estructura que se pueden utilizar para lograr la prueba
a diferentes grados de rigurosidad. Algunas tcnicas son ms fuertes (requieren ms
pruebas para lograr una cobertura del 100% y, por tanto, tienen una mayor probabilidad de
la deteccin de defectos) y otros son ms dbiles.
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 decisin 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 decisin, 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 decisin.
Otras medidas de cdigo de cobertura de flujo de control incluyen la secuencia de cdigo
lineal y saltos (LCSAJ) de la cobertura, la cobertura de la condicin, la cobertura de
condicin mltiple (Tambin conocido como la cobertura de condicin combinacin) y la
determinacin condicin cobertura (tambin conocida como la cobertura de decisin
condicin mltiple o modificado de la cobertura de decisin condicin, MCDC). Esta tcnica
requiere la cobertura de todas condiciones que pueden afectar o determinar el resultado de la
decisin.

Otro popular, pero a menudo mal entendida, medida de cdigo de cobertura es el camino
cobertura. A veces cualquier tcnica basada en la estructura se denomina "prueba de ruta'
[Patton, 2001]. Sin embargo, en sentido estricto, para cualquier cdigo 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 idnticos. As que si es posible viajar ronda el bucle un nmero
ilimitado de veces, entonces hay un nmero ilimitado de caminos a travs de ese trozo de
cdigo. Por esta razn, es ms correcto hablar de 'Una cobertura independiente segmento de
trazado ", aunque el trmino" cobertura de ruta ms corta se utiliza con frecuencia.
se describen las medidas basadas en la estructura y tcnicas de diseo de pruebas
relacionados en [BS7925-2]. Las tcnicas basadas en estructura tambin se discuten en
[Copeland.2003] y [Myers, 1979]. Una buena descripcin de la teora de grafos detrs de
estructura pruebas se puede encontrar en [Jorgensen, 1995] y [Hetzel, 1988] tambin muestra
un enfoque estructural. [Pol et al, 2001] describe un enfoque basado en la estructura llamado
una prueba de algoritmo.

4.5 Tcnicas basadas en la experiencia

1 motivos de visita para la escritura de casos de prueba basados en la intuicin,
experiencia y conocimiento acerca de defectos comunes. (KL)
2 Comparacin de las tcnicas basadas en la experiencia con las pruebas basadas en la
especificacin tcnicas. (K2)

En esta seccin vamos a ver dos tcnicas basadas en la experiencia, por qu y cundo son
tiles, y cmo encajan con las tcnicas basadas en la especificacin.
Si bien es cierto que la prueba debe ser rigurosa, completa y sistemtica, esto no es todo
lo que hay de la prueba. Hay un papel definitivo para las tcnicas no sistemtica, es decir,
sobre la base de pruebas de conocimiento, la experiencia, la imaginacin y la intuicin de
una persona. La razn es que algunos defectos son difciles de encontrar usando enfoques
sistemticos, por lo que un buen ' cazador bug - errores ' pueden ser muy creativos en la
bsqueda de aquellos defectos difcil de alcanzar.

En esta seccin, busque las definiciones de los trminos del glosario: adivinar el error
y pruebas exploratorias.

4.5.1 Adivinar error

Error adivinar es una tcnica que siempre se debe utilizar como un complemento de
otras tcnicas ms formales. El xito de error adivinar en mucho depende de la habilidad
del testers, como buenos testers saben dnde los defectos son ms probabilidades que
estn. Algunas personas parecen ser naturalmente bueno en las pruebas y los dems 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 razn para un enfoque de error de adivinar, que se utiliza despus de las tcnicas
ms formales tienen ha aplicado en cierta medida, puede ser muy eficaz. En el uso ms
formal de tcnicas, el testers es probable que obtenga una mejor comprensin del
sistema, lo que hace y cmo funciona. Con esta mejor comprensin, 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 tpicas a tratar de incluir la divisin
por cero, de entrada, en blanco (o no), archivos vacos y el tipo equivocado de datos (por
ejemplo, caracteres alfabticos, donde se requiere numrico). Si alguien alguna vez dice de
un sistema o el entorno en el cual se va a operar "que nunca podra suceda', que podra ser
una buena idea para probar esa condicin, 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
tcnica de error de adivinar es enumerar posibles defectos o fallos y disear 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 comn acerca de por qu falla el software.

4.5.2 El testing exploratorio

Pruebas exploratorias es un enfoque prctico en el que estn involucrados los testers,
un mnimo de planificacin y ejecucin de prueba mxima. La planificacin consiste en
la creacin de un documento de prueba, una breve declaracin 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 diseo y ejecucin de pruebas se realizan en paralelo tpicamente sin
documentar formalmente las condiciones de prueba, casos de prueba o scripts de
prueba.
Esto no quiere decir que no se utilizarn otras tcnicas, pruebas formales.
Por ejemplo, el testers puede decidir utilizar anlisis de valores lmite, pero pensar a travs
de y probar los valores lmite ms importantes sin que necesariamente escribirlos. Algunas
notas sern escritos durante las pruebas exploratorias, por lo que un informe se puede
producir despus.
El registro de datos se lleva a cabo como la ejecucin de pruebas, la documentacin es el
aspectos clave de lo que se evala, 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 dbiles. Como su nombre lo indica, pruebas exploratorias se trata de
explorar, encontrar informacin 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 dnde pasar el tiempo (limitado).

Este es un enfoque que es ms til cuando no hay mala especificacin y cuando el tiempo es
muy limitado. Tambin puede servir para complementar otras pruebas ms formales,
ayudando a establecer una mayor confianza en el software. De esta manera, la prueba de
exploracin se puede utilizar como un control sobre el proceso de prueba formal ayudando a
asegurar que los defectos ms 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 ELECCIN DE UNA PRUEBA TCNICA

1 Enumerar los factores que influyen en la seleccin de la tcnica de diseo 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 seccin vamos a ver los factores que intervienen en la decisin acerca de las
tcnicas que se utilizan para cundo.

Qu tcnica es la mejor? Esta es la pregunta equivocada! Cada tcnica es buena para

ciertas cosas, y no tan bueno para otras cosas. Por ejemplo, uno de los beneficios de las
tcnicas basadas en la estructura es que se pueden encontrar cosas en el cdigo que
no debera estar ah, como 'caballos de Troya' u otro cdigo malicioso. Sin embargo, si
hay partes de la especificacin que faltan en el cdigo, slo las tcnicas basadas en la
especificacin las encontrarn, las tcnicas basadas en la estructura slo pueden probar lo
que hay. Si hay cosas faltantes de la memoria descriptiva y a partir del cdigo, entonces slo
experiencia-tcnicas basadas las encontraran. Cada tcnica individual est dirigido a
determinados tipos de defectos tambin. Por ejemplo, las pruebas de transicin de estado
es poco probable encontrar defectos de contorno.
La eleccin de qu tcnicas 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 documentacin 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 tcnicas son ms aplicables a determinadas situaciones y niveles de prueba:
otros son aplicables a todos los niveles de prueba.
En este captulo se ha cubierto el software ms popular y de uso comn tcnicas de
prueba. Hay muchos otros que quedan fuera del alcance de la Plan de estudios que este libro
se basa en. Con tantas tcnicas de prueba para elegir desde cmo son los testers para decidir
cules usar.
Tal vez lo ms importante a entender es que la mejor prueba tcnica es que no hay una
de prueba nica. Debido a que cada tcnica de prueba es buena en la bsqueda de una clase
especfica de defecto, mediante una sola tcnica ayudar a asegurar que muchos (tal vez la
mayora, pero no todos) se encuentran defectos de esa clase particular.

Por desgracia, tambin puede ayudar a asegurar que muchos defectos de otras clases estn
perdidos! Usando una variedad de tcnicas, por tanto, ayudar a asegurar que una variedad
de defectos se encuentran, lo que resulta en las pruebas ms eficaz.
Entonces, cmo podemos elegir las tcnicas de prueba ms adecuados para usar? Las
decisiones se basan en una serie de factores, tanto internos como externos.

Los factores internos que influyen en la decisin sobre qu tcnica a utilizar son:
Los modelos usados: Dado que las tcnicas de pruebas se basan en modelos, los modelos
disponible (es decir, desarrollar y utilizar durante la especificacin, diseo e implementacin
del sistema) dependern en cierta medida que controlan las pruebas tcnicas se pueden
utilizar. Por ejemplo, si la especificacin contiene un estado Diagrama de transicin, las
pruebas de transicin de estado sera una buena tcnica para utilizar.
Conocimiento testers experimento: Cuntos testers conocen el sistema y sobre Tcnicas
de prueba influirn claramente su eleccin de las pruebas tcnicas? 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 sern muy tiles en la eleccin
de tcnicas de prueba (ya que cada tcnica es buena en la bsqueda de un particular, tipo de
defecto). Este conocimiento puede ser adquirida a travs de la experiencia probar una versin
anterior del sistema y los niveles anteriores de la prueba en la versin 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 tpicas a continuacin, utilizar los casos sera un
enfoque posible. Si el objetivo es que las pruebas muy completo y luego ms tcnicas
rigurosas y detalladas (incluyendo tcnicas basadas en la estructura) debe ser elegido.
Documentacin Sea o no documentado (por ejemplo, unas exigencias especificacin)
existe y si es o no es hasta la fecha afectar a la eleccin de las tcnicas de prueba. El
contenido y el estilo de la documentacin tambin influirn en la eleccin de las tcnicas (por
ejemplo, si las tablas de decisin o grafos de estado se han utilizado a continuacin las
tcnicas de prueba asociados deben ser usado).
Modelo de ciclo de vida: Un modelo de ciclo de vida secuencial se presta a la utilizacin
de ms tcnicas formales, mientras que un modelo de ciclo de vida iterativo puede ser ms
adecuado para el uso de un enfoque de pruebas exploratorias.

Los factores externos que influyen en la decisin sobre qu tcnica a utilizar son:
Riesgo Cuanto mayor es el riesgo (por ejemplo, los sistemas crticos de seguridad), mayor
es la necesidad para las pruebas formales y ms a fondo. El riesgo comercial puede ser
influenciado por problemas de calidad (por lo que la prueba ms completa sera apropiada)
o por cuestiones de tiempo hasta el comercial (pruebas de manera exploratoria sera una
eleccin apropiada).
El cliente y los requisitos contractuales: A veces los contratos especifican las tcnicas
particulares de prueba a utilizar (ms comnmente declaracin o rama cobertura).
 Tipo de sistema: El tipo de sistema (por ejemplo, incrustado, grfico, financiero, etc.)
influir en la eleccin de las tcnicas. Por ejemplo, una aplicacin financiera que implica
muchos clculos se beneficiara de anlisis de valores lmite.
Los requisitos reglamentarios Algunas industrias tienen normas reglamentarias o
directrices que rigen las tcnicas de pruebas utilizados. Por ejemplo, la industria de aviacin
requiere el uso de particin de equivalencia, el valor lmite de Anlisis y la transicin de
estado de prueba para sistemas de alta integridad, junto con el Estado de la decisin o la
cobertura de decisin condicin modificado en funcin 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 eleccin de las tcnicas de prueba. Cuando se dispone de ms tiempo que
podamos darnos el lujo de seleccionar ms tcnicas y cuando el tiempo est muy limitado
estaremos limitados a lo que sabemos que tienen una buena oportunidad de ayudarnos a
encontrar slo los defectos ms importantes.

Repaso Captulo
Vamos a repasar lo que ha aprendido en este captulo.

De la Seccin 4.1, ahora debera ser capaz de diferenciar entre una condicin de prueba,
un caso de prueba y un procedimiento de prueba y saben que estn documentados en una
especificacin de diseo de la prueba, una especificacin 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
realizacin 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 debera ser capaz de escribir un programa de ejecucin de la prueba para un
determinado conjunto de casos de prueba que tenga en cuenta las prioridades como, as como
las dependencias tcnicas y lgicas. Usted debe saber el glosario de trminos casos de
prueba, especificacin 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 categoras de tcnicas de diseo de pruebas), se debe ser capaz de dar
razones por las cuales tanto la especificacin de base (caja negra) y basado en la estructura
(caja blanca) enfoques son tiles, y la lista de las tcnicas comunes para cada uno de estos
enfoques. T debe ser capaz de explicar las caractersticas y diferencias entre basada
especificacin, basado en la estructura y la experiencia de base tcnicas. Usted debe saber
los trminos del glosario de prueba de caja negra tcnicas de diseo, basadas en la
experiencia, las tcnicas de diseo de pruebas tcnicas de diseo de pruebas basado en
la especificacin, prueba basada en la estructura tcnicas de diseo y tcnicas de diseo
de pruebas de caja blanca.

De la Seccin 4.3, usted debe ser capaz de escribir casos de prueba a partir modelos de
software determinado, utilizando la particin de equivalencia, lmite anlisis del valor, tablas
de decisin y diagramas de transicin de estados. Debes entender el objetivo principal de
cada uno de estas cuatro tcnicas, qu nivel y tipo de pruebas podran utilizar cada tcnica y
cmo se puede medir la cobertura para cada uno de ellos. Tambin debes entender el
concepto y los beneficios de casos de uso pruebas. Usted debe saber el glosario de
trminos de valor de frontera anlisis, pruebas de la tabla de decisiones, la particin de
equivalencia, estatal pruebas de transicin y las pruebas de caso de uso.

De la Seccin 4.4, usted debe ser capaz de describir el concepto y importancia de cobertura
de cdigo. Usted debe ser capaz de explicar los conceptos de la cobertura de sentencias y
decisiones y entienden que estos conceptos tambin 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 declaracin y la decisin de lo completo. Usted debe saber el glosario
trminos de cobertura de cdigo, la cobertura de decisin, la cobertura de sentencias,
pruebas estructurales, Las pruebas basadas en la estructura y pruebas de caja blanca.
De la Seccin 4.5, usted debe ser capaz de recordar las razones para escribir casos de prueba
basados en la intuicin, experiencia y conocimiento acerca de defectos comunes y usted
debera ser capaz de comparar las tcnicas basadas en la experiencia con los basados en la
especificacin tcnicas. Usted debe saber el glosario de trminos de error de adivinanzas
y pruebas exploratorias.
De la Seccin 4.6, usted debe ser capaz de enumerar los factores que influir en la seleccin
de la tcnica de diseo 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.

PREGUNTAS examen de la muestra

Pregunta 1 En qu documento se describe en el estndar IEEE 829 Quieres que encontrar
las instrucciones para los pasos a seguir para hacerse un anlisis que incluye la configuracin,
la explotacin forestal, medio ambiente y la medicin?
a. Plan de prueba
b. especificacin de diseo de la prueba
c. especificacin 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 definicin de procedimientos de ensayo sera eficaz y ms eficiente para un
proyecto en el marco de tiempo severo presin?
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 documentacin 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 ejecucin, para una prueba que est
comprobando modificaciones de los clientes en una base de datos.
1 Imprimir modificado registro del cliente.
2 Cambio de direccin de cliente: nmero de casa y
nombre de la calle.
3 capturar e imprimir el mensaje de error en pantalla.
4 Cambio de direccin de cliente: cdigo 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 aadir 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 especificacin y la estructura basada en tcnicas

de prueba til?
a. Ellos encuentran diferentes tipos de defectos.
b. El uso de tcnicas ms 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 caracterstica clave de tcnicas de pruebas basadas en la estructura?

a. Se utilizan principalmente para evaluar la estructura de una especificacin.
b. Se utilizan tanto para medir la cobertura y para
pruebas de diseo 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 Cul de las siguientes sera una ejemplo de las pruebas de toma de mesa para
una financiera aplicacin 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 Cul de las siguientes podra ser una medida de la cobertura para las pruebas de
transicin de estado?
V se han alcanzado todos los estados.
W El tiempo de respuesta para cada transaccin es
adecuado.
X Cada transicin se ha ejercido.
Y Todos los lmites se han ejercido.
secuencias especficas
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, ms
un extra por cada l0p 25g adicional hasta l00g.
Qu entradas de prueba (en gramos) seran 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 Cul de los siguientes podra ser utilizado para evaluar la cobertura alcanzada
para ESPECIFICACIN base (caja negra) tcnicas de prueba?
los resultados
V Decisin resultados de ejercicios
W Particiones ejercidas
X Ejercicios lmites
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 Cul de los siguientes estructura- tcnica de diseo de la prueba basada sera
ms probabilidades de ser aplicado a?
1 Los lmites entre la tasa de inters de la hipoteca alzacuello.
2 Una transicin no vlida entre dos diferentes atrasos ^ estados.
3 El flujo de procesos de negocio para la hipoteca aprobacin.
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 cul de el seguimiento?

P Diseo de pruebas de aceptacin con los usuarios o clientes.

Q Asegurarse de que el negocio de la corriente principal procesos son probados.

R encontrar defectos en la interaccin entre componentes.
S Identificacin de los valores mximos y mnimos para cada campo de entrada. La
identificacin 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 Cul de las siguientes afirmaciones sobre la relacin entre la cobertura de

sentencias y la cobertura de decisin es correcta?
a. la cobertura de la decisin 100% se logra si la declaracin la cobertura es mayor que 90%.
b. la cobertura de declaracin de 100% se consigue si la decisin la cobertura es mayor que
90%.
c. la cobertura de la decisin 100% significa siempre el 100% la cobertura de sentencias.
d. la cobertura de sentencias 100% significa siempre el 100% la cobertura de decisin.

Pregunta 13 Si usted est volando con una economa 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 aerolnea. Si usted no posee una tarjeta de oro, hay
una posibilidad que usted conseguir 'golpeado' fuera de la lnea area si esto est lleno y te
registras tarde. Esto se muestra en la Figura 4.5.
Tenga en cuenta que cada caja (es decir, declaracin) 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 economa
Prueba 3: Una persona que recibe un golpe desde el vuelo
Cul es la cobertura de sentencias de estas tres pruebas?
a. 60%
b. 70%
c. 80%
d. 90%

Pregunta 14 Por qu estn adivinando error y pruebas exploratorias bueno hacer?

a. Pueden encontrar defectos perdidas por ESPECIFICACIN con base y las tcnicas
basadas en la estructura.
b. No requieren ningn tipo de formacin para ser tan eficaz como tcnicas formales.
c. Se pueden utilizar ms eficazmente cuando hay buenas especificaciones.
d. Se asegurarn de que todo el cdigo o sistema se probado.
Pregunta 15 Cmo funcionan las tcnicas basadas en la experiencia diferir de las tcnicas
basadas en la especificacin?
a. Dependen de la comprensin 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 ms edad en lugar de testers ms jvenes.
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 tcnica utilizar en una situacin 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 ejecucin de la prueba que se utilizar
Y la documentacin 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 mnima 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: TCNICAS DE DISEO DE PRUEBA

Ejercicios basados en las tcnicas reguladas en este captulo se dan en esta seccin. Las
soluciones son trabajadas dada en la siguiente seccin.
el ejercicio de equivalencia Particin / Lmite Anlisis de Valor
Escenario: Si se toma el tren antes de las 9:30 de la maana o por la tarde despus 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 despus de las 7:30.
Cules son las particiones y los valores lmite para poner a prueba los horarios de los trenes
para los tipos de entradas? Cules son vlidos particiones y que son particiones no
vlida? Cules son los valores lmite? (Una tabla puede ser til para organice sus particiones
y lmites.) Derivar casos de prueba para las particiones y los lmites.
Hay alguna pregunta que tenga sobre este 'requisito'? Est claro algo? ejercicio tabla de
decisin
Escenario: Si mantiene un '' mayores de 60 aos tarjeta de ferrocarril, se obtiene un
descuento del 34% en cualquier compra de entradas. Si usted es viajar con un nio (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 slo puede
contener un tipo de tarjeta de ferrocarril.
Producir una tabla de decisin 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 transicin de estados
Escenario: Una cesta de compras sitio web comienza como vaca. Como se seleccionan las
compras, que se aaden a la cesta de la compra. Los elementos tambin se pueden eliminar
de la cesta de la compra. Cuando el cliente decide visita, un resumen de los artculos 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 estn 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 trminos de la secuencia de estados, para cubrir todas las transiciones.
segundo. Producir una tabla de estados. D un ejemplo de ensayo para una transicin vlida.
Declaracin y pruebas decisin ejercicio

Escenario: Una mquina expendedora dispensa cualquiera de bebidas calientes o fras. Si

elige una bebida caliente (por ejemplo, t o caf), se le preguntar si desea la leche (y aade
la leche si es necesario), y luego se le pregunta si desea azcar (y agrega el azcar
si se requiere), luego de su bebida se dispensa.
a. Dibuje un diagrama de flujo de control para este ejemplo. (Pista: consideran a la seleccin
del tipo de bebida como una declaracin.)
segundo. Dadas las pruebas siguientes, cul es la cobertura de sentencias logra? Cul es la
cobertura de decisin conseguido?
Prueba 1: Bebida fra
Prueba 2: Bebida caliente con leche y azcar
do. Qu pruebas adicionales seran necesarios para lograr una cobertura del 100%
comunicado? Qu pruebas adicionales que sera necesario para lograr una cobertura del
100% de decisin?

SOLUCIONES DE EJERCICIO
ejercicio EP / BVA
Lo primero que debe hacer es establecer exactamente cules son los lmites entre la tarifa
completa y tarifa ahorro.
Vamos a poner estos en una tabla para organizar nuestros pensamientos:
Hemos asumido que los valores lmite 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
especificacin, podemos destacar algunas ambigedades o, al menos, plantear algunas
preguntas - este es uno de los beneficios de utilizar la tcnica de! Por ejemplo:
"Cundo comienza la hora punta de la maana? A la medianoche? A las 11:30 pm del da
anterior? En el momento de el primer tren del da? Si es as, cundo es el primer tren? 5:00
de la maana?'
Esta es una omisin ms importante de la especificacin. Podramos hacer una suposicin
acerca de cundo se inicia, pero sera 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
vlido?
Qu pasa si un tren se debe dejar antes de las 4:00 pm, pero se retrasa hasta despus de
16:00? Es un boleto protector todava vlido? (Es decir, si la hora de salida real es diferente
a la hora de salida programada)
Nuestra tabla anterior nos ha ayudado a ver dnde estn las particiones. Todas las particiones
de la tabla anterior son las particiones vlidas. Puede ser que una particin no vlida sera un
tiempo que ningn tren estaba en marcha, por ejemplo, antes 5:00 am, pero nuestra
especificacin no mencion que! Sin embargo, sera bueno mostrar esta posibilidad tambin.
Podramos ser un poco ms formal haciendo una lista de todas las particiones y los lmites
vlidos y no vlidos en una mesa, ya que se describe en la Seccin 4.3.1, pero en este caso
que en realidad no aadir mucho, ya que todas las particiones son vlidos.
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 particin de
equivalencia; los casos 2, 3, 5, prueba 6, 8 y 9 se basan en los valores de lmite. Tambin
puede haber otra informacin sobre los casos de prueba, como condicin previa ciones, que
no hemos mostrados aqu.

ejercicio tabla de decisin

Los tipos de tarifas mencionadas incluyen una tarjeta de ferrocarril de los 60 ms ', una tarjeta
de ferrocarril de la familia, y si estn viajando con un nio o no. Con tres condiciones o
causas, tenemos ocho columnas en nuestra mesa de decisin siguiente.
Cuando llegamos a llenar los efectos, podemos encontrar esto un poco ms difcil. Para las
dos primeras reglas, por ejemplo, cul debe ser la salida? Es una X debido a la celebracin
de ms de una tarjeta de carril no debe ser posi- ble? La especificacin no dice qu pasa si
alguien nos depara ms de una tarjeta, es decir, No se ha especificado la salida, as que quizs
hay que poner un signo de interrogacin 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 estn viajando con un nio,
as que quizs deberan poner el 50% para la Regla 1 y 34% para la Regla 2 en esta
columna. Nuestra notacin 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 (Ingls) especificacin no es
muy clara en cuanto a lo que el efectos en realidad debera ser. Una de las ventajas de esta
tcnica es que obliga a una mayor claridad. Si las respuestas son deletreado hacia fuera en
una tabla de decisin, entonces est claro cul es el efecto debe ser. Cuando diferentes
personas vienen con diferentes respuestas para las salidas, entonces usted tiene una
especificacin de claro!
La palabra 'en otro caso' en la especificacin 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 nio 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 artculos 3 y 4.
Esto significa que nuestra tercera causa (Sea o no un nio tambin est viajando) en realidad
no tiene influencia en la salida. Estas columnas podran por lo tanto, ser combinado con 'no
me importa' como entrada para la tercera causa. Este racionalizacin de la mesa significa
que tendremos un menor nmero de columnas y, por tanto, un menor nmero de casos de
prueba. La reduccin en los casos de prueba se basa en la suposicin de que estamos haciendo
sobre el factor de tener ningn efecto en el resultado, por lo que una ms completa enfoque
sera incluir cada columna de la tabla.
Aqu hay una tabla racionalizado, donde hemos mostrado nuestras suposiciones acerca de los
dos primeros resultados y nos Tambin se han combinado los artculos 6 y 8, ya que tener
una tarjeta de ferrocarril de la familia no tiene ningn efecto si no est Travel- ing con un
nio.
Estos son los casos de prueba que nosotros sacamos de esta tabla. (Si no racionalizar la tabla,
a continuacin, 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 decisin sobre
qu combinaciones para poner a prueba y cules no para poner a prueba esta vez.
Tenga en cuenta que es posible que hayamos planteado algunas cuestiones adicionales
cuando diseamos los casos de prueba. Por ejemplo, hace el descuento para una tarjeta de
ferrocarril slo 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 aos tarjeta de ferrocarril.
el ejercicio de transicin 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 vaca. Cuando Se aade un elemento a la cesta, se pasa al estado (S2),
donde hay posibles compras. Algo adicional artculos aadidos a la cesta de no cambiar el
estado (slo el nmero 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 vaca (SI). Cuando queremos hacer la salida, nos vamos al estado
de sumario (S3) para aprobacin. 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, habra otros
eventos y acciones una vez que entramos en el proceso de pago que podra ser mostrado por
otro diagrama de estado (por ejemplo, comprobar validez dad de la tarjeta de crdito, deduzca
la cantidad, correo electrnico un recibo, etc.).
La tabla de estado correspondiente es:
Todas las cajas que contienen las transiciones - son vlidos en este ejemplo. pruebas
negativas ejemplo sera incluir:
 intento de aadir un artculo a partir del estado de resumen y el coste (S3)
tratar de eliminar un elemento de la cesta vaca de compras (SI)
tratar de entrar en 'Aceptar', mientras que en el estado de compras (S2).
Declaracin y pruebas decisin 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 tambin se puede aplicar a la
estructura de los procesos generales, no slo a la computadora algoritmos. Los diagramas de
flujo son generalmente fciles 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 travs de nuestro
grafo de control de flujo.
Prueba 1 ha ido hacia abajo de la parte izquierda para seleccionar una bebida fra. Prueba 2
se ha ido a la derecha en cada oportunidad, aadiendo la leche y el azcar a una bebida
caliente.
Cada declaracin (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 "azcar? ' decisiones, por lo que
hay dos decisiones Los resultados que no hemos probado todava. Hicimos prueba tanto de
los resultados de la 'caliente o fro? decisin, por lo que hemos cubierto cuatro de los seis
resultados de la decisin. la cobertura de decisin 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 decisin:
Prueba 3: Bebida caliente, sin leche, sin azcar Este examen abarcar tanto resultado de la
decisin del "no" de la leche y el azcar decisiones, por lo que lo har ahora tienen cobertura
de decisin 100%.
CAPTULO CINCO
Gestin de Pruebas
La prueba es una actividad compleja. La prueba es a menudo un sub-proyecto distinto dentro
del software ms grande desarrollo, mantenimiento, o proyecto de integracin. Las pruebas
usualmente representan una sustancial porcin del presupuesto total del proyecto. Por
lo tanto, debemos entender cmo debemos gestionar las pruebas que hacemos.

Este captulo trata sobre los temas esenciales para la gestin 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 estimacin, la planificacin 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 gestin de configuracin y su relacin con las pruebas. El
quinto cubre el tema central de riesgo y cmo las pruebas afectan y es afectada por
riesgos de los productos y de proyectos. La sexta y ltima seccin se analiza la gestin
de incidentes, ambos defectos de los productos y otros eventos que requieren una mayor
investigacin.

5.1 ORGANIZACIN PRUEBA

1 Reconocer la importancia de las pruebas independientes. (KL)
2 Enumerar las ventajas y los inconvenientes de las pruebas independientes dentro de
una organizacin. (K2)
3 Reconocer los diferentes miembros del equipo para ser considerado para la creacin
de un equipo de pruebas. (KL)
4 Recordemos las tareas de los lderes y los testers de prueba tpicos. (KL)

En esta seccin, vamos a hablar de la organizacin 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 tpicas realizadas por los lderes de la prueba
y los testers.
A medida que avanzamos a travs de esta seccin, mantener los ojos abiertos para los
trminos del glosario
tester, el lder de la prueba y director de pruebas.

5.1.1 Las pruebas independientes e integradas

En el captulo 1 hablamos de pruebas independiente desde la perspectiva psicolgica del
individuo tester. En este captulo, vamos a ver en la organizacin e implicaciones para la
gestin de la independencia.
Los enfoques para la organizacin de un equipo de pruebas varan, as como los lugares
en la organizacin, estructura donde el equipo de prueba se ajusta. La prueba es una
evaluacin de calidad, y ya que la evaluacin no siempre es positiva, muchas
organizaciones se esfuerzan por crear un clima organizacional donde los testers pueden
ofrecer una independencia, objetiva a la evaluacin 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 programacin.
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 estn independientes y fuera del equipo de
desarrollo, pero la presentacin de informes de gestin de proyectos.
Cerca del otro extremo de la escala estara completa independencia. Podra haber un equipo
de prueba separado en la organizacin 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 tecnologa (por ejemplo, expertos de bases de
datos), y especialistas en las pruebas (tales como testers de seguridad, certificacin testers,
o expertos de automatizacin de pruebas) en un equipo de prueba separado, como parte de
un equipo de pruebas ms 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.
Organizacin independiente a menudo puede ver ms, y otros defectos diferentes que
un tester de trabajo dentro de un equipo de programacin o un tester que es de
profesin un programador. Mientras que los analistas de negocios, personal de marketing,
diseadores y programadores traen sus propias suposiciones sobre la especificacin y
ejecucin del programa bajo prueba, organizacin independiente aportan un conjunto
diferente de hiptesis 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 Captulo 3. Un tester independiente trae una actitud escptica,
sensacin 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) ms credibilidad en la organizacin
que un supervisor de la prueba o el tester que forma parte del equipo de programacin. un
tester independinete que reporta a la alta direccin puede reportar sus resultados con
honestidad y sin preocuparse por las represalias que pudieran derivarse de sealar los
problemas de compaeros de trabajo o, peor an, 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 formacin del tester,
herramientas de prueba, equipos de prueba, y as sucesivamente. En algunas
organizaciones, los testers en un equipo de prueba independiente puede resultar ms fcil de
tener una carrera que conduce en ms puestos de alto rango en las pruebas.
Equipos de pruebas independientes no estn exentos de riesgos. Es posible que los
testers y el equipo de pruebas estn aislados. Esto puede tomar la forma de aislamiento
interpersonal a partir de los programadores, los diseadores y el equipo del proyecto
en s, o puede tomar la forma de aislamiento de la visin ms amplia de la calidad y la
objetividad de negocios (por ejemplo, el enfoque obsesivo sobre los defectos, a menudo
acompaado de una negativa a aceptar priorizacin de los defectos de negocio). Esto
conduce a problemas de comunicacin, sentimientos de alineacin y la antipata, la falta
de identificacin con apoyo para los objetivos del proyecto, festivales culpa espontneas
y pualadas por la espalda poltico.
Incluso los equipos de pruebas bien integrados pueden sufrir problemas. Otros grupos de
inters del proyecto titulares podran llegar a ver al equipo de pruebas independiente con o
sin razn 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 cdigo?

Debido al deseo de los beneficios de un equipo de pruebas independientes, las empresas los
establecen a veces, slo para separarlos de nuevo ms tarde. Por qu suele ocurrir eso? Una
causa comn 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
tentacin 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 lderes de procesos o como auditores sin
un mandato de gestin y el apoyo adecuados.
El resentimiento y la presin aumenta, hasta que por fin la organizacin decide que el equipo
de pruebas independiente causa ms problemas de los que resuelve. Es especialmente
importante para que los evaluadores y gestores de prueba entiendan a la misin que sirven y
las razones por las que la organizacin 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 organizacin 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 aplicacin, y los niveles de riesgo, entre otros factores. A medida
que el tamao, la complejidad y la criticidad del proyecto aumenta, es importante tener
independencia en los niveles posteriores de las pruebas (como prueba de integracin,
prueba del sistema y la prueba de aceptacin), 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 lder de la prueba

Hemos visto que la ubicacin de un equipo de pruebas dentro de una organizacin del
proyecto puede variar ampliamente. Del mismo modo hay una amplia variacin 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 lder tester, aunque las mismas personas
pueden desempear 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 lder.
Los lderes de prueba tienden a estar involucrados en la planificacin, el seguimiento y
control de las actividades de prueba y las tareas se discuten en la Seccin 1.5 en la prueba
fundamental proceso. Al inicio del proyecto, los lderes de la prueba, en colaboracin
con otras partes interesadas, disear los objetivos de la prueba, las polticas de la
organizacin 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 direccin para
adquirir los recursos necesarios.
Reconocen cuando la automatizacin de pruebas es adecuada y, si lo es, planean el
esfuerzo, seleccionar las herramientas, y garantizar la formacin del equipo. Pueden
consultar con otros grupos, por ejemplo, los programadores para ayudarles con sus
pruebas. Conducen, orientan y supervisan el anlisis, diseo, implementacin y ejecucin de
los casos de prueba, procedimientos de prueba. Aseguran configuracin adecuada la gestin
del testware producido y la trazabilidad de las pruebas para la prueba base.

A medida que se acerca la ejecucin de pruebas, se aseguran de que el entorno de prueba este
en su lugar antes de la ejecucin de pruebas y administrado durante la ejecucin de la
prueba. Ellos programan las pruebas para la ejecucin 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 evolucin de condiciones. Durante la ejecucin de prueba y medida que el proyecto vaya
remitiendo, las que escriben resmenes de estado de la prueba.

A veces los lderes de prueba tienen diferentes ttulos, 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 debera estar sonando en tu cabeza ahora, adems de los pensamientos acerca
de cmo 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 lderes 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 perodo de ejecucin de la prueba. En las fases de
planificacin y preparacin de la prueba, los testers deben revisar y contribuir a los planes de
prueba, as como al anlisis, la revisin y la evaluacin de los requisitos y especificaciones
de diseo. Pueden ser involucrado en, o incluso ser las primeras personas que
identifican condiciones de prueba y creacin de diseos 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
administracin del sistema y la gestin del personal.

Cuando comienza la ejecucin de pruebas, el nmero 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 estn bajo el control
directo de la prueba grupo; por ejemplo, se podra aplicar pruebas unitarias que fueron
diseados por los programadores.) Los testers ejecutan y registran las pruebas, evalan 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 mtricas
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 Definicin de la necesidad de habilidades del personal de pruebas
Hacer pruebas correctamente requiere ms que definir las posiciones correctas y
nmero de personas para estos cargos. Los buenos equipos de prueba tienen la
combinacin adecuada de habilidades basadas en las tareas y actividades que se debe llevar
a cabo, y las personas fuera del equipo de pruebas que estn a cargo de las tareas de prueba
necesitan los conocimientos adecuados, tambin.
Las personas que participan en las pruebas necesitan cualificaciones profesionales y
sociales bsicas 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 ms all que, cuando pensamos en las habilidades que necesitan testers,
tres reas principales vienen a mente:
Aplicacin 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 caractersticas.
Tecnologa: Un tester debe ser consciente de los problemas, limitaciones y capacidades
de la tecnologa de aplicacin escogida, con el fin de localizar los problemas con eficacia y
eficientemente y reconocer la 'probabilidad de falla' y funciones caractersticas.
Pruebas: Un tester debe conocer los temas de prueba analizados en este libro y temas sobre
la prueba a menudo ms avanzados con el fin de llevar a cabo eficaz y eficiente las tareas de
prueba asignadas.

Las habilidades especficas en cada rea y el nivel de habilidad requerido varan segn
el proyecto, organizacin, aplicacin, y los riesgos involucrados.

El conjunto de tareas y actividades de prueba son muchas y variadas, y tambin lo son las
habilidades requeridas, por lo que a menudo se ven la especializacin de habilidades y
separacin de roles. Por ejemplo, debido al conocimiento especial requerido en las reas de
las pruebas, la tecnologa y los negocios de dominio, respectivamente, los expertos del
instrumento de medida pueden manejar la automatizacin de las pruebas de regresin, los
programadores pueden realizar pruebas de componente, pruebas de integracin y de los
usuarios y de integracin y los operadores pueden estar involucrados en prueba de
aceptacin.
Hemos defendido durante mucho tiempo la prueba generalizada, la participacin de las
personas en todo el equipo del proyecto en la realizacin de tareas de prueba. Cerremos este
seccin, sin embargo, en una nota de advertencia. Las compaas de software y del sistema
(Por ejemplo, los productores de software empaquetado y productos de consumo)
tpicamente sobrestiman el conocimiento de tecnologas necesarias para ser un eficaz
tester. Las empresas que utilizan la tecnologa de la informacin (por ejemplo, bancos y
compaas 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, evalan componentes crticos, ms tarde esto
condujo al descubrimiento de desastrosos problemas fundamentales de
arquitectura. La mayora de los proyectos pueden beneficiarse de la participacin 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 planificacin de pruebas. (KL)
2 Resumir el propsito y el contenido del plan de prueba, prueba caracterstica de
diseo y procedimiento de prueba de acuerdo con los documentos [IEEE 829]. (K2)
3 Recordemos factores tpicos que influyen en el esfuerzo relacionado con
pruebas. (KL)
4 diferenciar entre dos enfoques conceptualmente diferentes: el enfoque basado en la
mtrica y el enfoque basado en el experto. (K2)
5 Diferenciar entre el tema de la planificacin de prueba para un proyecto, para los
niveles de prueba individuales (por ejemplo, prueba del sistema) u objetivos especficos
de prueba (por ejemplo, usabilidad prueba), y para la ejecucin de la prueba. (K2)
6 Lista de las tareas de preparacin y ejecucin de pruebas que necesitan
planificacin. (KL)
7 Reconocer y justificar los criterios de salida adecuadas para la prueba especfica los
niveles y grupos de casos de prueba (por ejemplo, para las pruebas de integracin,
aceptacin prueba o las pruebas de usabilidad). (K2)

En esta seccin, vamos a hablar de un tro de temas complicados de prueba: planes,

presupuestos y estrategias. Los planes, estimaciones y estrategias dependern de un
nmero de factores, incluyendo el nivel, objetivos y objetivos de la prueba que estamos
a punto de realizar. Escribir un plan, preparar una estimacin y seleccionar estrategias de
prueba tienden a ocurrir simultneamente e idealmente durante el perodo de planificacin
para el proyecto en general, aunque debemos estar dispuestos a revisarlas y obtener ms
informacin para el avance del proyecto.

Veamos de cerca cmo preparar un plan de pruebas, el examen cuestiones relacionadas con
la planificacin de un proyecto, para un nivel de prueba o fase, para un tipo especfico de
prueba y de ejecucin de la prueba. Examinaremos factores tpicos que influyen en el
esfuerzo relacionados con las pruebas, y ven dos enfoques diferentes de la estimacin:
mtricas de base y basado en un experto. Discutiremos la seleccin de estrategias de
prueba y las formas de establecer criterios de salida adecuadas para la prueba. Adems,
vamos a ver diferentes tareas relacionadas con la preparacin y ejecucin de pruebas que
requieren la planificacin.

Al leer, mantener los ojos abiertos para el glosario de trminos 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 propsito 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 especificacin de diseo de la prueba, una coleccin
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 gua 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 captulo 2 de Fred Brooks
brillante y libro esencial en la gestin de la ingeniera de software, El mes laboral mtico,
explica la importancia de la estimacin y planificacin 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 da es el mximo [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 captulo, utilizar de otra persona plantilla o crear su propia plantilla con el
tiempo.
El proceso de planificacin de prueba y el plan en s sirven como vehculos para la
comunicacin con otros miembros del equipo del proyecto, testers, compaeros,
directivos y otras partes interesadas. Esta comunicacin permite que el plan de pruebas
pueda influir en el equipo del proyecto y tambin en el plan de pruebas, especialmente en las
reas de las polticas y las motivaciones de pruebas de toda la organizacin; Prueba de
alcance, objetividad y reas crticas a la prueba; proyecto y del producto riesgos,
consideracin de recursos y limitaciones; y la capacidad de prueba del elemento bajo prueba.
Esto se puede hacer a travs de la comunicacin de circulacin de uno o dos planes de pruebas
corrientes de aire y a travs de las reuniones de revisin. un proyecto de tales incluir muchos
notas tales como los siguientes:
[Por determinar: Jennifer: Por favor dgame cul es el plan para la liberacin de la prueba
elementos en el laboratorio de pruebas para cada ciclo de ejecucin de la prueba del sistema]
[de Dave por favor me deja saber qu versin de la herramienta de prueba se utilizar para
las pruebas de regresin 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 tambin nos ayuda a gestionar el cambio. Durante las primeras fases
del proyecto, podemos reunir ms informacin, revisamos nuestros planes. Como el proyecto
evoluciona y las situaciones cambian, nos adaptamos a estos planes. planes de pruebas
escritos nos dan una lnea de base para medir dichas revisiones o cambios. Adems, la
actualizacin 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 energa para
actualizar sus planes de prueba cada vez que se produce una variacin, ya que algunos
proyectos pueden ser muy dinmico. en el captulo 6 [Negro, 2001], se describe un mtodo
sencillo para documentar las variaciones respecto el plan de prueba que se puede
implementar utilizando una base de datos u hoja de clculo. Usted puede incluir estos
registros de cambio en una actualizacin peridica 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 integracin al sistema de niveles de
prueba, los dos perodos de ejecucin de pruebas ocurrirn 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 tcnicas y herramientas, as como los
diferentes pblicos.
Sin embargo, ya que puede haber superposicin entre estos planes de prueba, una prueba del
plan maestro que se dirige a los elementos comunes puede reducir la cantidad redundante de
documentacin.

Plantilla Standard IEEE 829 del plan de pruebas

identificador de plan de pruebas entregables de prueba

Introduccin Tareas de prueba
Elementos de prueba ]Necesidades ambientales
Caractersticas para ser probadas Responsabilidades
Caractersticas no a probar Las necesidades de personal y de formacin
Enfoque Programar
Elemento pasa / no pasa criterios Riesgos y Contingencias
Criterios de suspensin y reanudacin Aprobaciones

5.2.2 Qu hacer con su cerebro, mientras las pruebas se planifican?

Escribir un buen plan de pruebas es ms fcil 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 podran
argumentar que es ms difcil para escribir un buen plan de pruebas. Veamos algunas de las
tareas de planificacin que debemos llevar a cabo.

A un alto nivel, es necesario considerar el propsito servido por el trabajo de prueba.

En trminos de las necesidades globales de la organizacin, este propsito se denomina
variablemente como la misin del equipo de prueba o la poltica de pruebas de la
organizacin. En trminos del proyecto especfico, la comprensin del propsito de la
prueba significa conocer las respuestas a preguntas tales como:

Cul es su alcance y lo que est fuera del alcance de esta prueba de esfuerzo?
Cules son los objetivos de la prueba?
Cules son los riesgos importantes de los proyectos y productos? (Ms informacin sobre
los riesgos de Seccin 5.5).
 Las restricciones afectan las pruebas (por ejemplo, limitaciones presupuestarias, plazos
duros, etc.)?
que es lo ms importante para este producto y el proyecto?
Qu aspectos del producto son ms (o menos) comprobable?
Cul debera ser el calendario general de ejecucin de pruebas y cmo deberamos
decidir el orden en el que se ejecutan pruebas especficas? (Producto y la planificacin
riesgos, discutido ms adelante en este captulo, influirn en las respuestas a estas preguntas).

A continuacin, debe seleccionar las estrategias que sean adecuadas a los fines de
prueba (ms en el tema de la seleccin de estrategias en unas pocas pginas). Adems, es
necesario decidir cmo dividir el trabajo de pruebas en varios niveles, como se discuti
en el captulo 2 (por ejemplo, componentes, integracin, sistema y aceptacin). Si ya se ha
tomado esa decisin, es necesario decidir cmo 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 anlisis y diseo de pruebas, usted querr reducir las brechas y la
superposicin entre los niveles y durante la ejecucin de pruebas, tendr que coordinar
entre los niveles. Estos detalles se ocupan de la coordinacin entre el plan maestro de
pruebas y los diferentes niveles se tratan a menudo.

Adems de la integracin y coordinacin entre los niveles de prueba, usted debe tener
tambin 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?

Estn en curso los problemas de suministro, como con las cuentas de imitacin (es decir,
simula billetes de banco) para una aplicacin financiera, como un cajero
automtico? Cundo 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
informacin 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 declaracin
larga de una lista de buenas ideas o una coleccin de sugerencias es que el autor es quin
especifica que se har en ella, cmo y cundo (por lo menos es la idea general). Se necesitan
recursos para llevar a cabo el trabajo. Estos son a menudo decisiones difciles que requieren
una cuidadosa consideracin y la construccin de un consenso con todo el equipo de trabajo,
incluso con el director del proyecto.

Todo el proceso de prueba desde la planificacin hasta el cierre produce informacin,

algunas de las cuales se tendrn que documentar. Con qu precisin debe el testers
escribir los casos de prueba, diseos y procedimientos? Cunto se le deja a juicio del tester
durante la ejecucin de la prueba, y cules son los problemas de reproducibilidad asociados
con esta decisin? 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 intencin de utilizar herramientas para tareas como la prueba de diseo y ejecucin,
como se discute en el captulo 6, que necesita para entender esas herramientas de captura de
informacin mientras se trabaja en el plan.
Algunos saben qu informacin deber reunirse en forma de datos en bruto y luego
destilar. Qu mtricas va a utilizar para supervisar, controlar y gestionar las pruebas Cul
de esas mtricas va a utilizar para y que otras mtricas? informar de sus resultados Vamos a
ver ms de cerca las posibles respuestas a estas preguntas en la Seccin 5.3, pero un buen
plan de pruebas de dar respuestas al principio del proyecto.

Por ltimo, se mueve hacia atrs hasta un nivel ms alto, pensar en lo que sera verdad sobre
el proyecto cuando el proyecto estaba listo para comenzar a ejecutar las pruebas. Qu sera
verdad sobre el proyecto cuando el proyecto estaba listo para hacer la prueba de
ejecucin? En qu momento se puede empezar con seguridad un nivel de prueba o fase
particular, conjunto de pruebas o destino de la prueba? Cundo 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 tpicos son:
Adquisicin 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 nmero conocido de estar presente, la tasa de entrada, predecir el nmero que
permanecern, y el nmero total resuelto.
Pruebas: el nmero de ejecucin, pasada, con error, bloqueado, saltos, y as sucesivamente.
Cobertura: las partes de la base de pruebas, el cdigo de software o ambos que han sido
probado y cules no.
Calidad: el estado de las caractersticas de calidad importantes para el sistema.
Dinero: el costo de encontrar un defecto en el nivel actual de las pruebas, en
comparacin con el costo de encontrarlo en el siguiente nivel de la prueba (o de produccin).
Riesgo: los resultados no deseados que podran resultar de envo demasiado pronto
(Tales como defectos o reas no probados latente) o demasiado tarde (tal como prdida 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
caractersticas. Esto es an ms importante a la hora de aplicar los criterios de salida
al final del proyecto.

5.2.3 Estimacin 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 ms grande. Por lo tanto, podemos adaptar las tcnicas fundamentales de la
estimacin para la prueba. Nosotros podramos comenzar con una estructura de trabajo
de desintegracin que identifica las etapas, actividades y tareas.
Comenzando en el nivel ms alto, podemos descomponer un proyecto en fases de pruebas
mediante el proceso de prueba fundamental identificado en el Plan de estudios ISTQB:
planificacin y control; anlisis y diseo; implementacin y ejecucin; Evaluar criterios
de salida y presentacin de informes; y el cierre de prueba. Dentro de cada fase se
identifican las actividades y dentro de cada actividad identificamos tareas y quizs
subtareas. Debemos identificar actividades y tareas, que trabajan tanto hacia delante
como hacia atrs. Cuando decimos que trabajamos hacia adelante, queremos decir que
comenzamos con las actividades de planificacin y luego movemos hacia adelante en el
paso a paso de tiempo, preguntando: Ahora qu viene? '
Trabajando hacia atrs significa que tenemos en cuenta los riesgos que se identificaron
durante anlisis de riesgos (del que hablaremos en la seccin 5.5). Para aquellos riesgos
que se tiene la intencin de abordar a travs de pruebas, se pregunta, Qu actividades
y tareas se requieren en cada etapa para llevar a cabo esta prueba? Veamos un ejemplo
de cmo usted puede trabajar hacia atrs.
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 ejecucin de la prueba. Ahora estimas las tareas involucradas con la
ejecucin de una prueba de rendimiento, cunto tiempo llevarn esas tareas y el nmero de
veces que se necesita para ejecutar la pruebas.
Ahora, esas pruebas no acaban de aparecer de la nada: alguien tena que desarrollarlas. Por
lo tanto, el desarrollo de pruebas de rendimiento implica actividades de anlisis de la prueba,
el diseo e implementacin. Ahora podr valorar las tareas implicadas en el desarrollo de una
prueba de rendimiento, tales como la escritura de guiones de prueba y la creacin de datos
de prueba, persona.
Por lo general, las pruebas de rendimiento se deben ejecutar en un entorno de prueba especial
que est diseado para parecerse al entorno de produccin o de campo, por lo menos en
aquellas formas que podran afectar el tiempo de respuesta y la utilizacin de recursos y
desempeo, las pruebas necesitan herramientas especiales para generar carga y comprobar la
respuesta. Por lo tanto, pruebas de desempeo en ambientes de adquisicin y la configuracin
es una actividad en la fase de prueba de implementacin. Ahora podr valorar las tareas
involucradas en la adquisicin y calcular un ambienta para este tipo de prueba, tales como la
simulacin de rendimiento en el entorno de produccin para buscar posibles cuellos de
botella, para obtener el hardware, software, herramientas y la configuracin de hardware,
software y herramientas.

No todo el mundo sabe cmo usar las herramientas de pruebas de rendimiento o pruebas de
diseo de alto rendimiento. Por lo tanto, pruebas de rendimiento de formacin o dotacin de
personal es una actividad en la fase de planificacin 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 ms personas en su organizacin
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 planificacin de pruebas de rendimiento es una actividad en la fase
de planificacin 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 estimacin (al principio) el seguimiento y de control (como el
proyecto sigue). Para asegurar la precisin de la estimacin y un control preciso, asegrese
de que subdividir el trabajo finamente. Esto significa que las tareas deben ser de corta
duracin, de uno a tres das. Si ellas estn mucho ms 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 ms grande, slo para ser descubierto ms adelante. Esto puede dar lugar a sorpresas
desagradables durante el proyecto.
5.2.4 Las tcnicas de estimacin
Hay dos tcnicas para la estimacin cubiertos por la Fundacin 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 anlisis de mtricas 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, duracin, dependencias y recursos requisitos. La idea es hacer uso de la sabidura
colectiva del equipo para crear su estimacin 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 tcnica es a menudo
llamada estimacin 'de abajo hacia arriba' porque se inicia en el nivel ms bajo de la
estructura jerarqua de trabajo, se desintegra en tareas y define la duracin, esfuerzo,
dependencias y recursos para cada tarea y se suman a travs de todas la Tareas.

Anlisis de mtricas pueden ser tan simples o sofisticados como usted lo quiera. el
enfoque ms simple es preguntar, "Cuntos testers son los que normalmente tenemos
por desarrollador en un proyecto? Un enfoque algo ms fiable implica la clasificacin
del proyecto en trminos de tamao (pequeo, mediano o grande) y la complejidad
(simple, moderado o complejo) y luego ver, en promedio, los proyectos en cunto al
tiempo, el tamao y la complejidad de combinacin han tenido caractersticas 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 nmero estimado de casos de prueba para
estimar el esfuerzo total. enfoques sofisticados implican la construccin de modelos
matemtica en una hoja de clculo para que se parezcan a los promedios histricos o de la
industria para determinados parmetros clave, nmero de pruebas realizadas por el tester por
da, nmero de defectos encontrados por tester por da, etc. y despus de conectar esos
parmetros para predecir duracin y esfuerzo para tareas o actividades clave en su
proyecto. La relacin del tester y el desarrollador es un ejemplo de una tcnica de estimacin
de arriba hacia abajo, en la que toda estimacin se deriva a nivel de proyecto, mientras que
la tcnica paramtrica es de abajo hacia arriba, por lo menos cuando se utiliza para estimar
las tareas o actividades individuales.

Preferimos empezar haciendo uso de la sabidura del equipo para crear el desglose de
la estructura de trabajo y una estimacin detallada de abajo hacia arriba. A
continuacin, aplicamos modelos y reglas generales para comprobar y ajustar la
estimacin de abajo hacia arriba y de arriba hacia abajo con el uso de historias
pasadas. Este enfoque tiende a crear una estimacin que es a la vez ms exacta y ms
defendible que cualquiera de las tcnicas por s mismo.

Incluso la mejor estimacin se debe negociar con la direccin. sesiones de negociacin

exhiben increbles variedades, dependiendo de las personas involucradas. Sin embargo,
hay algunas posiciones de negociacin clsicas. No es raro que el lder de la prueba o gerente
trate de vender al equipo de gestin el valor aadido por la prueba o para alertar a la gestin
de los problemas potenciales que resultaran de no realizar pruebas suficientes. No es inusual
para una gestin 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
estn dispuestas. Nuestra experiencia ha sido exitosa en negociaciones sobre las estimaciones
en donde la atencin se centra en ganar y perder menos y ms acerca de averiguar la mejor
manera de equilibrar las presiones de la competencia en los mbitos de la calidad,
programacin, 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 estimacin del esfuerzo de prueba y
horarios, debe mantener estos factores en mente o sus planes y estimaciones lo
engaaran al comienzo del proyecto y traicionar en medio o al final del mismo. Las
estrategias de prueba o enfoques que usted escoge tendrn una influencia importante
en las pruebas de esfuerzo. Este factor es tan influyente que vamos a volver a ella en la
Seccin 5.2.6. En esta seccin, 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 documentacin suficiente del

proyecto por lo que los testers puede averiguar lo que el sistema es, cmo se supone que
funciona
y qu comportamiento correcto aparece. En otras palabras, informacin adecuada de
alta calidad sobre la base de pruebas nos ayudar a hacer un mejor trabajo, ms
eficiente para la definicin de las pruebas.

La importancia de las caractersticas de calidad no funcionales como la usabilidad,

fiabilidad, seguridad, rendimiento, y as sucesivamente tambin 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 avinica (Aplicacin de la electrnica a la
aviacin) y el software de exploracin de petrleo);
El uso de tecnologas innovadoras, especialmente los de largo o corto historial probado
La necesidad de configuraciones de prueba complicadas y quizs 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 distribucin geogrfica del equipo, sobre todo si los cruces del equipo zonas horarias
(como muchos de los esfuerzos de externalizacin a hacer).
Mientras que la buena documentacin del proyecto es un factor positivo, tambin es cierto
que tener que presentar la documentacin detallada, como prueba meticulosamente
especificada, da lugar a retrasos. Durante la ejecucin de pruebas, tener que mantener tan
detallada la documentacin requiere mucho esfuerzo, como lo hace el trabajo con datos de
prueba frgil debe ser mantenido o restaurado con frecuencia durante la prueba. Finalmente,
el aumento del tamao del producto conduce a aumentos en el tamao 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 ejecucin de la prueba, que est en la ruta crtica
para lanzamiento. En cuanto al desarrollo, herramientas de depuracin y la depuracin
dedicada al entorno (a diferencia de la depuracin en el entorno de prueba) tambin 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 ms frgil en la cara de cambio de ltima hora mientras que los modelos incrementales
tienden a tener alta costes de las pruebas de regresin. la madurez del proceso, incluyendo la
madurez del proceso de prueba, estn entre los factores, especialmente la implicacin de que
los procesos maduros implican manejar cuidadosamente cambios en el medio y al final del
proyecto, que reduce el coste de ejecucin de pruebas.

La presin del tiempo es otro factor a considerar. La presin no debe ser una excusa
para tomar riesgos innecesarios. Sin embargo, es una razn para hacer una cuidadosa,
consideracin de decisiones, planificar y volver a planificar de manera inteligente
durante todo el proceso, que es otra caracterstica de los procesos maduros.

Las personas ejecutan el proceso, y los factores son tan importantes o ms 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 alineacin de esas habilidades con el proyecto
necesariamente. Desde un proyecto, en un equipo de trabajo, las relaciones slidas, la
ejecucin fiable de compromisos acordados y responsabilidades son determinantes para
trabajar juntos hacia un objetivo comn. 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 ingeniera de sistemas, tambin es un importante factor humano, para la estabilidad
del equipo de proyecto.

La cantidad total de esfuerzo de la prueba durante la ejecucin de la misma son importantes

para los resultados de la prueba. La entrega de software de buena calidad en el comienzo de
la ejecucin de la prueba y rpidas soluciones slidas a anomalas, evita retrasos en el proceso
de ejecucin de la prueba. Un defecto, una vez identificados, no debera tener que ir a travs
de mltiples ciclos de correccin / retest / re-abierta, al menos no si la estimacin 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 ocurrirn antes o despus de la prueba puede traer estos factores. Por esta
razn, los testers, en especialmente los lderes o gerentes de prueba, estn en sintona
con el contexto general en el que operan. Algunos de estos factores resultan ser riesgos
especficos para las pruebas del proyecto, y deben abordarse en el plan de pruebas.

Los riesgos del proyecto se analizan con ms detalle en la Seccin 5.5.

5.2.6 Prueba de enfoques o estrategias

La eleccin de los mtodos de prueba o estrategias son un poderoso factor en el xito
del esfuerzo de la prueba y la precisin de los planes de pruebas y estimaciones. Este
factor est bajo el control de los testers y lderes de prueba. Por supuesto, tambin tiene
opciones significa que se pueden cometer errores, por lo que vamos a hablar de cmo 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 comnmente.

Analtica: Por ejemplo, la estrategia basada en el riesgo implica la realizacin de un

anlisis de riesgo utilizando documentos del proyectos y aportes de las mismas, a
continuacin, la planificacin, la estimacin, el diseo, y dar prioridad a las pruebas
basadas en el riesgo. (Hablaremos ms sobre el anlisis de riesgo ms adelante en este
captulo). Otra estrategia es la prueba analtica La estrategia basada en los requisitos,
donde un anlisis de la especificacin de requisitos constituye la base para la
planificacin, el diseo y la estimacin de las pruebas.
estrategias de pruebas analticas tienen en comn el uso de algunas tcnicas formales o
informales, por lo general durante las fases de diseo y requisitos del proyecto.

Basado en Modelos: Por ejemplo, se puede construir modelos matemticos para la

carga y la respuesta de los servidores de comercio electrnico, 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 comn la creacin o seleccin de un cierto modelo formal o informal para
el sistema de comportamientos crtico, por lo general durante las fases de diseo y requisitos
del proyecto.

Metdica: Por ejemplo, usted podra tener una lista de comprobacin que usted ha
puesto A punto durante los aos que sugieren las principales reas de las pruebas que
se ejecuten o se podra seguir un estndar de la industria para la calidad del software,
tales como ISO 9126, para su esquema de las principales reas de prueba. A continuacin,
metdicamente disear, implementar y ejecutar las pruebas siguiendo este
esquema. estrategias de pruebas metdicas tienen en comn la adhesin 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 participacin para la prueba temprana o tarda.
 Proceso compatible con estndar: Por ejemplo, es posible adoptar el IEEE 829
estndar para su prueba, el uso de libros tales como [Craig, 2002] o [Drabick, 2004] para
llenar los vacos metodolgicos. Alternativamente, es posible adoptar una de las
metodologas giles como la programacin extrema. Procesamiento compatible con el
estndar, las estrategias compatibles tienen en comn la dependencia sobre un enfoque de las
pruebas desarrollados externamente, a menudo con poca o ninguna personalizacin y puede
tener un punto de participacin para la prueba temprana o tarda.

Dinmico: Por ejemplo, puede crear un conjunto de pruebas con una lnea gua que se
centrara en la adaptacin rpida o debilidades conocidas en el software. Estrategias
dinmicas, tales como pruebas exploratorias, tienen en comn que se concentran en la
bsqueda de la mayor cantidad posible de defectos durante la ejecucin de la prueba y
adaptarlas a la realidad del sistema bajo prueba, ya que es cuando se entrega, y tpicamente
enfatizar las ltimas etapas de la prueba. Vase, por ejemplo, el enfoque basado en ataques
en el de [Whittaker, 2002] y [Whittaker, 2003] y la aproximacin 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 comn 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.

Regresin con Aversin: 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 tcnicas de regresin
con aversin tienen un conjunto comn de procedimientos generalmente automatizado
que les permiten detectar defectos de regresin. Una estrategia de regresin de aversin
puede implicar la automatizacin de pruebas funcionales antes de la liberacin de la funcin,
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 liberacin posterior a la participacin de la prueba.

Algunas de estas estrategias son ms preventivas, otras ms reactivas. Por ejemplo, las
estrategias de prueba analtica implican el anlisis inicial de la base de pruebas, y
tienden a identificar los problemas en la base de pruebas antes de la ejecucin de la
prueba. Esto permite la eliminacin de los defectos temprano y barato. Esa es una
fortaleza de los enfoques preventivos.

las estrategias de las pruebas dinmicas que se centran en el perodo de ejecucin de la

prueba. tales estrategias permitir la localizacin de defectos y clusters de defectos que
podran haber sido difcil 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 eleccin, especialmente las estrategias preventivas o reactivas,

ya sea como una / o situacin, 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 ms sentido en una situacin particular, y no dude en pedir prestado
y mezclar.
Cmo 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 ms importante:

Riesgos: La prueba es sobre la gestin de riesgos, por lo que debe tener en cuenta los
riesgos y el nivel de riesgo. Para una aplicacin bien establecida que est evolucionando
lentamente, la regresin es un riesgo importante, por lo que las estrategias de regresin con
aversin tienen sentido. Para una nueva aplicacin, un anlisis de riesgos puede revelar
diferentes riesgos si tienes que elegir una basada en el riesgo de estrategia analtica.

Habilidades: Las estrategias no slo deben ser elegidos, sino que tambin deben ser
ejecutadas. As que, usted tiene que considerar qu habilidades poseen sus testers y la
falta. Una estrategia estndar compatible es una opcin 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 nmero posible de defectos con una cantidad
mnima de tiempo y esfuerzo invertido. Por ejemplo, en una tpica prueba independiente, una
estrategia dinmica tiene sentido.

Regulaciones: A veces hay que satisfacer no slo las partes interesadas, sino tambin
los reguladores. En este caso, puede ser necesario disear una estrategia metdica 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 analtica.

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 situacin
donde los materiales, factores del proceso y retraso iban en contra de su xito. Sin
embargo, la ejecucin con un muy buen equipo talentoso, de una estrategia imprudente
es el equivalente de ir muy rpido por una carretera en la direccin equivocada. Por lo
tanto, debe tomar decisiones inteligentes en trminos 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 organizacin y su poltica.

5.3 PROGRESO, SUPERVISION Y CONTROL DE LA PRUEBA

1 Recordemos mtricas comunes que se utilizan para la preparacin de la prueba de
monitoreo y ejecucin. (KL)
2 Conocer e interpretar las mtricas de prueba para la presentacin 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 propsito y el contenido del resumen de la prueba documento de informe
de acuerdo con [IEEE 829]. (K2)

En esta seccin, vamos a revisar las tcnicas y las mtricas que se utilizan comnmente
para el seguimiento de la preparacin y ejecucin de pruebas. Nos centraremos
especialmente en el uso y la interpretacin de dichas mtricas de prueba para la
presentacin de informes, el control y anlisis del esfuerzo de la prueba, incluyendo las
basadas en defectos y los basados en los datos de prueba.
Tambin vamos a ver opciones para informar sobre el estado de prueba utilizando dichas
mtricas y otra informacin.
A medida que lea, recuerde que debe velar por el glosario de trminos densidad de defectos,
insuficiencia tasa, control de prueba, cobertura de la prueba, monitorizacin de las
pruebas y el informe de prueba.

5.3.1 Seguimiento de la evolucin de las actividades de prueba

Despus 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. Supervisin de Prueba puede servir a
varios propsitos durante el proyecto, incluyendo el seguimiento:

Dar al equipo de pruebas la retroalimentacin de las pruebas, de cmo 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 estimacin de los esfuerzos de las pruebas futuras.

Especialmente para proyectos pequeos, el lder de prueba o una persona delegada pueden
reunir pruebas para llevar un seguimiento del progreso y control de la prueba con informacin
de forma manual utilizando documentos, hojas de clculo 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 (vase el Captulo 6).

Una manera de reunir informacin del progreso de la prueba es utilizar el registro de

la prueba IEEE 829 modelo. Si bien gran parte de la informacin relacionada con los
eventos de registro puede ser capturados en un documento, preferimos para capturar la
informacin de la prueba por prueba en hojas de clculo (vase la Figura 5.1).
 LOG plantilla de prueba IEEE 829 STANDARD

Identificador de registro de la prueba Entradas de actividad y de eventos

(]Ejecucin, descripcin, resultados del
procedimiento, informacin del ambiente,
eventos anmalos, Identificadores de
informe de incidente)
Descripcin (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 configuracin de
prueba, donde los cdigos de A, B y C corresponden a probar entornos descrito en detalle
en el plan de pruebas. Las columnas E y F muestran el nmero de identificacin de defectos
(o error) (de la base de datos de seguimiento de defecto) y el nmero 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 duracin (en horas). Tenemos planeado para
las mtricas y el esfuerzo real y fechas completado la cual nos permitira resumir el progreso
en relacin con el calendario y el presupuesto previsto. Esta hoja de clculo tambin puede
ser un resumen en trminos del porcentaje de pruebas que han sido corridas y el
porcentaje de pruebas que han pasado y han fallado.

Figura 5.1 podra mostrar una instantnea del progreso de la prueba durante la ejecucin 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 anlisis, diseo e implementacin de las pruebas,
una hoja de clculo as mostrara el estado de las pruebas en funcin de su estado de
desarrollo.
Adems del estado de casos de prueba, tambin es comn para monitorear el progreso
de prueba durante el perodo de ejecucin de la prueba observando el nmero de
defectos encontrados y fijo. Figura 5.2 muestra un grfico que traza el nmero total de
defectos abierto y cerrado en el transcurso de la ejecucin de la prueba hasta el
momento.
Tambin muestra el perodo de prueba de la fecha de finalizacin prevista y el nmero
previsto de defectos que se encontrarn. Idealmente, como el proyecto se acerca al final
planeado fecha, el nmero total de defectos abiertos se instalar en el nmero previsto
y el nmero total de defectos corregidos converger con el nmero total abri. Estos dos
resultados nos dicen que hemos encontrado bastantes defectos para sentir cmoda que hemos
terminado la prueba, que no tenemos ninguna razn para pensar que muchos ms defectos
estn al acecho en el producto, y que todos los defectos conocidos han sido resuelto.
Grficas tales como la Figura 5.2 tambin se pueden utilizar para mostrar las tasas de
fracaso o defecto densidad. Cuando la fiabilidad es una preocupacin fundamental,
podramos estar ms preocupados por la frecuencia con la que se observan fallas que
con el nmero de defectos que estn provocando los fracasos. En las organizaciones que
estn buscando producir ultra-fiabilidad de software, se puede trazar el nmero de defectos
sin resolver normalizados por el tamao del producto, ya sea en miles de lneas de cdigo
fuente (KSLOC), en funcin puntos (FP) o alguna otra mtrica de tamao del
cdigo. Una vez que el nmero de defectos resueltos cae por debajo de un umbral
predefinido, por ejemplo, tres por millones de lneas de cdigo a continuacin, 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 comn y til
si se usa con cuidado.
La mtrica del avance de las pruebas a partir de los defectos detectados es frecuente y
til. Se debe evitar la utilizacin nicamente de esa mtrica ya que es posible una
manipulacin deliberadamente incorrecta por parte de otros actores intervinientes en el
ciclo de vida de los defectos.

Dicho esto, el progreso de tcnicas de pruebas de monitoreo varan 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.
Adems de los tipos de informacin que se muestran en el registro de la prueba IEEE 829
Plantilla, figuras 5.1 y Figura 5.2, otros sistemas de medicin comunes para el progreso
de prueba monitoreo incluye:

El grado de terminacin de la preparacin entorno de prueba;

La extensin de la cobertura de la prueba consigui, comparada con los requisitos, riesgos,
cdigo, configuraciones u otras reas de inters;
El estado de la prueba (incluyendo el anlisis, diseo e implementacin) en comparacin
con diversos hitos de prueba;
La economa de la prueba, tales como los costes y beneficios de la prueba continua
ejecucin en trminos de encontrar el siguiente defecto o ejecutar la siguiente prueba.

Como tcnica de monitorizacin 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 impresin 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 recopilacin de los datos de prueba
detallado; prueba de estado de la presentacin 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 prctica 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 presentacin de informes. A menudo, las variaciones o resmenes de las
mtricas 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, tambin. Independientemente
de las mtricas especficas, grficas e informes utilizado, informes de estado de prueba
ayudan a los participantes del proyecto a comprender los resultados de un perodo de
prueba, especialmente en lo que se refiere a los objetivos fundamentales del proyecto y
si (o cuando) los criterios de salida estaban satisfechos.

Adems de notificar a los interesados del proyecto sobre los resultados de la prueba, la
presentacin de informes de estado de la prueba es a menudo sobre esclarecedor e influir en
ellos. Se trata de analizar la informacin y las mtricas disponibles para apoyar las
conclusiones, condiciones, y las decisiones sobre cmo orientar el proyecto hacia adelante o
tomar otro comportamiento. Por ejemplo, podramos estimar el nmero de defectos que
quedan por descubrir, presentar los costos y beneficios de retrasar la fecha de lanzamiento
para permitir ms 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 planificacin de las pruebas
y perodos de preparacin, ya que a menudo se necesitan para recopilar mtricas especficas
durante y al final de un perodo de prueba para generar los informes de estado de prueba de
una manera efectiva y eficiente. Los datos especficos que querr reunir depender de sus
informes especficos, pero las consideraciones comunes incluyen los siguientes:

Cmo va a evaluar la adecuacin de los objetivos de la prueba para un nivel de prueba

dado y si se lograron los objetivos?
Cmo va a evaluar la adecuacin del enfoque de prueba adoptado y si se apoya el logro de
los objetivos de prueba del proyecto?
Cmo 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 grfico que permitira informar de la cobertura
de la prueba y los defectos no resueltos contra las principales reas de riesgo producto que
identific en el anlisis de riesgos. Si usted est haciendo las pruebas basadas en
requisitos, usted podra medir la cobertura en trminos 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 estndar IEEE 829
Resumen plantilla de informe proporciona una gua til para lo que sucede en tales un
informe. Adems de incluir el tipo de grficos y tablas que se muestran anteriormente, es
posible discutir los eventos importantes (especialmente problemticas) 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 Evaluacin

Resumen Resumen de las actividades
varianzas aprobaciones
evaluacin integral Resumen de Resultados

5.3.3 Prueba de control

Los proyectos no siempre se desarrollan segn lo previsto. De hecho, toda obra humana
ms complicado que un da de campo familiar es probable que vare 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 detrs 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 especficas dependen, por supuesto, de lo que estamos tratando de
controlar. Considere los siguientes ejemplos hipotticos:

Una parte del software bajo prueba ser entregado tarde, despus de la prueba prevista
fecha de inicio. Las condiciones del mercado dictan que no podemos cambiar la fecha de
liberacin. Prueba de control podra 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 produccin de ambiente. Debido a la alta demanda imprevista
de sus productos, la compaa ha adoptado temporalmente un turno de tarde que mantiene el
entorno de produccin en uso 18 horas al da, cinco das a la semana. Prueba de control podra
implicar la reprogramacin pruebas de rendimiento para el fin de semana.

Aunque estos ejemplos muestran las acciones de control que afectan las pruebas, el
equipo del proyecto tambin podra tener que tomar otras acciones que afectan a los
dems en el proyecto. Por ejemplo, supongamos que la fecha de terminacin de la
prueba est en riesgo debido a un elevado nmero de reparaciones de defectos que
hacen fallar la prueba de confirmacin en el entorno de prueba. En este caso, el control
de prueba podra implicar que los programadores requieren hacer las correcciones
para volver a probar a fondo las correcciones antes de registrarse en el cdigo
repositorio para su inclusin en una compilacin de prueba.

5.4 GESTIN DE LA CONFIGURACIN

1 resumen cmo soportes de gestin de configuracin pruebas. (K2)
En esta breve seccin, vamos a ver cmo la gestin de configuracin se refiere a las pruebas
y apoya. Usted se encontrar con el glosario trminos de gestin de configuracin y control
de versiones.
Gestin de la configuracin 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 crtica mal, Nunca se le olvide lo importante que es. En pocas
palabras, la gestin de la configuracin es, en parte, sobre determinar claramente los
elementos que componen el software o sistema. Estos elementos incluyen cdigo fuente,
scripts de prueba, el software de terceros, hardware, datos, desarrollo y documentacin
de prueba. gestin de la configuracin tambin trata de asegurar que estos elementos se
utilizan cuidadosamente, a fondo y con atencin a lo largo de todo el proyecto y ciclo de
vida del producto.
Gestin de la configuracin 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 configuracin de mecanismos de gestin, como si fueran tan valioso como el cdigo
fuente y la documentacin para el sistema en s.

Por otro lado, la gestin de la configuracin apoya la construccin del proceso, que es
esencial para la entrega de una liberacin de prueba en el entorno de prueba. El simple envo
de archivos Zip por correo electrnico 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 slida y fiable de entrega de elementos de
prueba que funcionan y son la versin correcta.

Por ltimo, pero no menos importante, la administracin de configuracin nos permite

mapear lo que se est probando a los archivos y componentes subyacentes que lo
componen. Esto es absolutamente crtico. Por ejemplo, cuando nos informa defectos,
tenemos que informar sobre ellos contra algo, lo que la versin control. Si no est claro lo
que encontramos en el defecto, los programadores tendrn un tiempo muy difcil 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
liberacin de un repositorio de cdigo fuente gestionados cambio, es acompaado por un
elemento de transmisin de prueba, informes o notas.

[IEEE 829] proporciona una gua til para lo que sucede en tal informe. Notas de la
versin no son siempre tan formal y no siempre contienen toda la informacin que se muestra.
Mientras que nuestra descripcin fue breve, gestin de la configuracin es un tema que es
tan compleja como la gestin de medio ambiente. As que, planificacin avanzada es
fundamental para hacer este trabajo. Durante la planificacin del proyecto y tal vez como
parte de su propio plan de pruebas hay que asegurarse de los procedimientos y herramientas
de administracin de configuraciones seleccionado. A medida que avanza el proyecto, el
proceso de configuracin debe implementar mecanismos e interfaces claves en el
resto del proceso de desarrollo, esto debe ser documentado. Prueba en tiempo de ejecucin,
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 cdigo que no existen ms que en
la prueba ambiente.

LA PLANTILLA IEEE 829 STANDARD: TEST DE ELEMENTOS DE INFORME

DE TRANSMISIN
identificador de informe de transmisin elementos de transmisin
Ubicacin
Estado
Aprobaciones

5.5 RIESGO Y PRUEBA

1 Describe un riesgo como un posible problema que amenazara el logro de los objetivos
del proyecto una o ms de las partes interesadas. (K2)
2 Recuerde que los riesgos son determinados por la probabilidad (de pasando) e
impacto (dao resultante si sucede). (KL)
3 Distinguir entre los riesgos del proyecto y del producto. (K2)
4 Reconocer riesgos tpicos en productos y proyectos. (KL)
5 Describir, mediante ejemplos, cmo el anlisis del riesgo y la administracin del riesgo
pueden ser utilizados para la planificacin de pruebas. (K2)
Esta seccin trata sobre un tema que creemos que es fundamental para las pruebas: el
riesgo. Miremos de cerca los riesgos, los posibles problemas que podran 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 tpicos en ambas categoras. Finalmente, y ms importante vamos a ver varias
maneras de como el anlisis de riesgos y gestin de riesgos puede ayudar a trazar un curso
para la prueba slida a medida que lea esta seccin, asegrese de asistir con atencin los
trminos 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 ms probable es que el resultado es, peor es el riesgo. Sin embargo, la
probabilidad no es la nica consideracin.

Por ejemplo, la mayora de la gente tiende a atrapar un resfriado en el curso de su vive, por
lo general ms de una vez. El individuo tpico 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 sera muy
alto. Las consecuencias potenciales o impacto son una consideracin importante que afecta
el nivel de riesgo, tambin.

Recordemos que en el captulo 1 hemos discutido cmo en el contexto del sistema, y

especialmente el riesgo asociado a las fallas, las pruebas de influencias. A continuacin,
vamos a entrar en ms detalles sobre el concepto de riesgos, cmo influyen en las pruebas, y
especficas 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 podra dejar de satisfacer algunas necesidades del cliente, usuario o grupos de
inters. (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
podra omitir algunas funciones claves que los clientes especifican, los usuarios
requieren o los grupos de inters les haban prometido. software insatisfactorio podra
ser poco fiable y con frecuencia no comportarse normalmente. Software insatisfactorio
puede fallar en formas que causan daos financieros u otros daos a un usuario o de la
compaa donde el usuario trabaja. software insatisfactorio podra tener problemas
relacionados con una caracterstica de calidad especial, que podra no ser la
funcionalidad, sino ms 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 ejecucin de la prueba, pero es algo ms que eso. Las pruebas basadas en el
riesgo comienzan temprano en el proyecto, la identificacin de riesgos para la calidad
del sistema y el uso del conocimiento de los riesgos para orientar la planificacin de
pruebas, especificacin, preparacin y ejecucin. Las pruebas basadas en el riesgo
consisten en la mitigacin 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 ms all de nuestro
alcance sean menos dolorosos.

Las pruebas basadas en riesgo tambin implican la medicin de lo bien que estamos
haciendo la bsqueda y la eliminacin de defectos en las zonas crticas, como se muestra
en la Tabla 5.1. La prueba basada en el riesgo Tambin puede implicar el uso de anlisis de
riesgos para identificar oportunidades proactivas para eliminar o prevenir los defectos a
travs 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 dcada del 1990, una serie de testers, incluidos nosotros, comenzamos a
explorar diferentes tcnicas para la prueba basada en el riesgo. Al hacerlo, se adapt bien el
concepto de riesgo de gestin a las pruebas de software. La aplicacin y evaluacin de riesgo
en las tcnicas de gestin se discuten en [Negro, 2001] y [Negro, 2004]. Por dos puntos de
vista alternativos, vase el captulo 11 de la [Pol et al., 2002] y en el Captulo 2 de [Craig,
2002]. El origen del concepto de prueba basado en el riesgo se puede encontrar en Captulo
1 de [Beizer, 1990] y en el Captulo 2 de [Hetzel, 1988].
Las pruebas basadas en el riesgo comienzan con el anlisis de riesgos del producto. Una
de las tcnicas para el anlisis del riesgo es una lectura atenta de la especificacin de
requisitos, especificaciones de diseo, documentacin del usuario y otros artculos. Otra
tcnica 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 pequeos de expertos en negocios y
tecnologa en la empresa.
Algunas personas utilizan todas estas tcnicas 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 sabidura y la visin de todo el equipo para determinar qu vamos a probar
y cunto.
Mientras que usted podra realizar el anlisis 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 bsqueda de riesgos especficos
en determinadas categoras de riesgo particulares del producto. Se podra considerar los
riesgos en las reas de funcionalidad, localizacin, facilidad de uso, fiabilidad,
rendimiento y compatibilidad. Alternativamente, puede hacer utilizar las caractersticas de
calidad y sub-caractersticas de la norma ISO 9126 (introducido en el captulo 1), ya que
cada sub-caracterstica que importa est sujeta a riesgos que el sistema podra tener
problemas en esa rea. Es posible que tenga una lista de riesgos tpicos o pasados que deben
ser considerados. Tambin puede ser que desee revisar las pruebas que fallaron y los errores
que haya encontrado en una revisin 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 documentacin de los riesgos de los productos.

Cuando hablamos de riesgos especficos, 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 'clculo incorrecto 'como un
riesgo especfico dentro de la categora de funcionalidad. Sin embargo, esto es demasiado
ancho. Considere adems 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 adicin no es un
algoritmo complejo. Esto contrasta con un clculo incorrecto de seno. Esto es un tipo de bajo
impacto de defecto, ya que pocas personas utilizan la funcin seno en la calculadora de
Windows. Es ms probable que tenga un defecto, sin embargo, las funciones sinusoidales
son difciles de calcular.

Despus 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 asignacin 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 tcnica las
personas a determinar la probabilidad, y luego se funden las determinaciones. De cualquier
manera, la razn para la identificacin de riesgos primero y despus la evaluacin de su nivel,
de riesgos con respecto a la otra.

Las escalas utilizadas para la probabilidad y el impacto varan. 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 difcil diferenciar una 2 de un 3 o un 7 de un 8, a menos que las
diferencias entre cada calificacin estn 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 calificacin de riesgo, agregado para guiar
nuestras pruebas de esfuerzo. Al igual que con las escalas de calificacin, las prcticas
varan. Un enfoque consiste en convertir cada clasificacin de riesgo en un nmero y
luego agregar o multiplicar los nmeros de calcular un nmero de prioridad de
riesgo. Por ejemplo, suponga un riesgo particular tiene una alta probabilidad y un
impacto medio. El nmero de prioridad de riesgo sera entonces 6 (2 veces 3).
Armado con un nmero de prioridad de riesgo, ahora podemos decidir sobre los
diferentes riesgos opciones de mitigacin disponibles para nosotros. Usamos el
entrenamiento formal para los programadores o analistas, se basan en el entrenamiento
cruzado y crticas o asumen que saben lo suficiente? Hacer llevamos a cabo extensas
pruebas, prueba superficial o ninguna prueba en absoluto? Deberamos garantizar la
cobertura de las pruebas unitarias y pruebas del sistema de este riesgo? Estas opciones y ms
estn disponibles para nosotros.
A medida que transcurre este proceso, asegrese de capturar la informacin clave en
un documento. No somos aficionados a la documentacin excesiva, pero esta cantidad
de informacin 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
clculo.
Vamos a terminar esta seccin con dos consejos rpidos sobre el anlisis de riesgo del
producto. Primero, recuerde tener en cuenta tanto la probabilidad e impacto. Si bien
puede hacer que se sienta como un hroe a encontrar un montn de defectos, las pruebas
tambin se tratan de la construccin de la confianza en clave funciones. Necesitamos
poner a prueba las cosas que probablemente no se rompen, pero sera catastrfico si lo
hicieron.

En segundo lugar, los anlisis de riesgo, especialmente los primeros, son conjeturas
adecuadas. Hacer asegurarse de que siga hacia arriba y vuelve a visitar el anlisis de
riesgos en los hitos clave del proyecto.
Por ejemplo, si usted est siguiendo un modelo en V, es posible realizar el primer anlisis
durante la fase de requisitos, a continuacin, examinar y revisar que al final de las fases de
diseo e implementacin, as como antes de iniciar prueba de unidad, prueba de integracin,
y la prueba del sistema. Tambin le recomendamos revisar el anlisis 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 anlisis 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 gestin 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 tambin riesgos indirectos, tales como retrasos excesivos en
la reparacin de los defectos que se encuentran en prueba o problemas con la obtencin
de apoyo para la administracin profesional del sistema el entorno de prueba.

Por supuesto, estos no son ms que cuatro ejemplos de los riesgos del proyecto; muchos otros
pueden aplicar a su esfuerzo de pruebas. Para descubrir estos riesgos, hgase y hacemos a
otros participantes en el proyecto y las partes interesadas algunas preguntas, lo que podra
ir mal en el proyecto de retrasar o invalidar el plan de pruebas, la estrategia de prueba
y la estimacin de prueba? Qu son inaceptables los resultados de las pruebas o en las
pruebas? Cules 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 anlisis 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 tpicas:

Mitigar: Tomar medidas con antelacin para reducir la probabilidad (y posiblemente el

impacto) del riesgo.

Contingencia: Tener un plan en marcha para reducir el impacto debera tener el riesgo
convertido en un resultado.

Transferencia: Convencer a algn 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 slo una opcin inteligente
cuando hay poco que se puede hacer o cuando la probabilidad y el impacto son bajo.

Hay otra opcin tpica de gestin 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 tpicos, junto con algunas opciones para la gestin de los
mismos.

Logstica o problemas de calidad del producto que bloquean las pruebas: Estos pueden
ser mitigados mediante una planificacin cuidadosa, buena clasificacin y gestin de
defectos, y diseo de una prueba robusta.

Los elementos de prueba que no se instalar en el entorno de prueba: Estos pueden ser
mitigados a travs del humo (o aceptacin) pruebas antes de iniciar las fases de prueba o
como parte de un nightly build (construccin nocturna) o la integracin continua. Tener un
proceso definido de desinstalacin, 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 travs de buenos procesos de control de cambios, el diseo de pruebas
robusta y ligera documentacin de prueba de peso. Cuando se producen incidentes graves, la
transferencia del riesgo por la progresividad de gestin a menudo est en orden.

Entornos de pruebas insuficientes o poco realistas que dan resultados engaosos: Una
opcin es la transferencia de los riesgos para la gestin, explicando los lmites de Los
resultados que fueron obtenidos en entornos limitados. Mitigacin, a veces completa el
alivio, se puede lograr por medio de pruebas de externalizacin 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 organizacin tales como la escasez de personas, habilidades o entrenamiento,

problemas con la comunicacin y responder a probar los resultados, mala expectativa de lo
que puede lograr la prueba y la complejidad del equipo de proyecto u organizacin.

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 tcnicos relacionados con la ambigua, contradictoria o sin prioridades de

requisitos, un nmero excesivamente grande de los requisitos dados, otra las limitaciones del
proyecto, la complejidad y los problemas de alta calidad con el diseo del sistema, el cdigo
o las pruebas.

Puede haber otros riesgos que se aplican a su proyecto y no todos los proyectos son
sujetos a los mismos riesgos. Vase el Captulo 2 de [Negro, 2001], los captulos 6 y 7 de
la [Negro, 2004] y en el Captulo 3 de [Craig, 2002] para una discusin sobre la gestin
los riesgos del proyecto durante la prueba y en el plan de pruebas.
Por ltimo, no se olvide de que los elementos de prueba tambin 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 crticas del sistema.

5.5.4 Atar todo junto para la gestin de riesgos

Podemos hacer frente a los riesgos relacionados con las pruebas, al proyecto y el producto
mediante la aplicacin de algunas, tcnicas de gestin de riesgos estructuradas sencillas. El
primer paso es evaluar o analizar los riesgos al comienzo del proyecto. Al igual que un
gran ocano, proyectos, especialcialmente grandes proyectos, requieren el manejo de la
direccin 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 planificacin.

Vale la pena repetir aqu que los anlisis de riesgo tempranos son conjeturas. Algunas de esas
conjeturas suelen estar equivocadas. Asegrese 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 estn 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 (Mtodo para clasificar la urgencia de la atencin) los riesgos mediante la
comprensin 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 prcticamente ser un proyecto libre de riesgo. Lo que podemos lograr con La
prueba basado en el riesgo es la unin de las pruebas con las mejores prcticas en la
gestin de riesgos a lograr un resultado del proyecto que equilibra los riesgos con la
calidad, caractersticas, presupuesto y programar (schedule).

5.6 GESTIN DE INCIDENTES

1 Reconocer el contenido del informe [IEEE 829] incidente. (KL)
2 Escribir un informe de incidente que cubre la observacin de una falla durante
pruebas. (K3)
Vamos a ver este captulo sobre gestin de pruebas con un tema importante:
Cmo podemos documentar y gestionar las incidencias que se produzcan durante la
ejecucin de pruebas? Vamos a ver lo que los temas que debemos cubrir cuando los
incidentes de informes y defectos. Al final de esta seccin, usted estar listo para escribir un
informe a fondo de incidente.

Mantenga sus ojos abiertos para el nico trmino del programa de estudios en esta
seccin, incidente de registro de datos (incident logging).

5.6.1 Cules son los informes de incidentes y cmo puedo escribir bien Cules?
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.
Comnmente, se llaman incidentes, errores, defectos, problemas o cuestiones.

Para ser precisos, a veces hacer una distincin entre incidentes, en una mano y defectos o
errores en el otra. Un incidente es cualquier situacin 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 algn problema en el tema (Item) que estamos
probando.

Otras causas de los incidentes incluyen una mala configuracin o el fracaso del
ambiente prueba, datos de prueba corruptos, malas pruebas, resultados esperados no
vlidos y errores probados. (Sin embargo, en algunos casos, la poltica es clasificar como
un defecto de cualquier incidencia que surge a partir de un diseo de la prueba, el entorno de
prueba o cualquier otra cosa, que est bajo la administracin de configuracin 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 ms comn encontrar el registro de incidentes o notificacin de defectos

procesos y herramientas en uso durante las fases de prueba formales, independientes, tambin
puede registro, informe, seguimiento y gestin de incidencias encontradas durante el
desarrollo y revisiones. De hecho, esta es una buena idea, ya que le da informacin til sobre
la medida en que los principios y es ms econmica las actividades de deteccin y
eliminacin de defectos.

Por supuesto, tambin necesitamos alguna forma de presentacin de informes, el seguimiento

y la gestin de incidentes que se producen en el campo o despus de la implementacin del
sistema. Mientras que muchos de estos incidentes se producen por fallas humanas o algn
otro comportamiento no relacionada con un defecto, un porcentaje de defectos escapan del
control de calidad y pruebas de actividades. El porcentaje de deteccin 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 frmula DDP que se aplicara para el clculo de DDP para el
ltimo nivel de la prueba antes de su liberacin en el campo:

Es ms comn encontrar defectos notificados en contra del cdigo o el sistema s mismo. Sin
embargo, tambin hemos visto casos en que se describen los defectos en contra de requisitos
y especificaciones de diseo, guas del usuario y del operador y pruebas.

A menudo, ayuda a la eficacia y eficiencia de la presentacin de informes, el seguimiento y

la gestin de defectos cuando la herramienta de seguimiento de defecto proporciona una
capacidad de variar algunas de las informaciones capturadas en funcin de lo que se inform
en contra del defecto.

En algunos proyectos, se encuentran un gran nmero de defectos. Incluso en el ms

pequeo proyectos en los que se encuentran 100 o menos defectos, se puede perder
fcilmente un seguimiento de ellos a menos que tenga un proceso para la presentacin
de informes, clasificacin, asignacin y gestin de defectos del descubrimiento a la
resolucin final.

Un informe de incidente contiene una descripcin de la mala conducta que era

observada y la clasificacin de la mala conducta. Al igual que con cualquier
comunicacin escrita, que ayuda a tener objetivos claros en mente al escribir. Un
objetivo comn para tales informes es proporcionar a los programadores,
administradores y otros con detallada informacin sobre el comportamiento observado
y el defecto. Otra es la de apoyar el anlisis de las tendencias de agregar defectos a los datos,
ya sea para comprender ms sobre un conjunto particular de problemas o pruebas o para la
comprensin y la presentacin de informes en el nivel global de la calidad del sistema. Por
ltimo, informes de defectos, cuando se analizaron a travs de un proyecto e incluso a travs
de proyectos, dar informacin que puede conducir al desarrollo y mejoras en los procesos de
prueba.

Al escribir un incidente, que ayuda a tener los lectores en mente, tambin. Los programadores
necesitan la informacin de la memoria para encontrar y corregir los defectos antes de que
ocurre, sin embargo, previo a que esto suceda, los lderes debern 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 ms tarde o quizs, 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 tcnicos. Por ltimo, los testers a menudo
necesitan saber lo que sus colegas estn encontrando, que puedan ver un comportamiento
similar en otro lugar y evitar tratar de ejecutar las pruebas que sern bloqueados.

Un buen informe de incidente es un documento tcnico. Adems 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 bsicas que pueden ayudar a escribir
un buen informe de incidente.

En primer lugar, utilizar un enfoque cuidadoso, atento a la ejecucin de las

pruebas. Nunca se sabe cundo se va a encontrar un problema. Si usted est golpeando el
teclado mientras charla con los compaeros de oficina o soando con una pelcula que acaba
de ver, es posible que no se d cuenta de comportamientos extraos. Incluso si usted ve el
incidente, cunto es lo que realmente sabe sobre l? Qu se puede escribir en un
informe de incidente? sntomas intermitentes o espordicos 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 sntomas cuando
los vea esta puede ser una buena regla de oro. Si tiene un defecto con sntomas
intermitente, todava tendramos que informar que seguiran, pero nos gustara asegurarnos
de incluir tanta informacin como sea posible, especialmente el nmero de veces que
intentamos reproducir y las veces que de hecho ocurri.

Tambin 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 problemtica del sistema. Tambin aumenta su propio conocimiento de cmo
funciona el sistema y cmo 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
prctica. Hemos encontrado que es una buena idea para buscar condiciones ms
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, 'Ningn usuario real va
a hacer esto otra vez. " Tambin reduce el nmero de informes duplicados que quedan
archivados.

Como a menudo hay una gran cantidad de pruebas pasando con el sistema durante un perodo
de prueba, hay un montn de otros resultados de las pruebas disponibles. Comparacin 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 informacin adicional que el
programador es muy probable que encuentre til. Por ejemplo, es posible comprobar si hay
sntomas similares observados con otros defectos, los mismos sntomas 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, sern 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 mayora de
seguimiento de defectos de sistemas tienen un campo de ttulo o resumen y ese campo deben
mencionar el impacto, tambin.

Eleccin de las palabras, sin duda importa en los informes de incidentes. Usted debera
ser claro y sin ambigedades. Tambin debe ser neutral, centrado e imparcial, teniendo
en cuenta los problemas interpersonales relacionados con las pruebas discutido en Captulo
1 y al principio de este captulo. Por ltimo, mantener el informe conciso ayuda a
mantener la atencin de la gente y evita el problema de la prdida de ellos en detalles.
Como ltima regla de oro para los informes de incidentes, se recomienda que utilice una
proceso de revisin de todos los informes presentados. Funciona si usted tiene la opinin
tester en la revisin de informes y hemos permitido tambin que los testers, al menos los
experimentados revisen los informes de otros testers. Los comentarios son tcnicas probadas
de garanta 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 situacin, comportamiento o evento que ocurri
durante las pruebas que requiere ms investigacin. En muchos casos, un incidente
consta de un informe de una o dos pantallas, llenas de informacin recogida por un defecto
herramienta de seguimiento y se almacena en una base de datos.

Como se mencion anteriormente, a menudo se documenta la informacin 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 podra y no poda
hacer que se repite el problema y el impacto. La informacin que un tester proporcionara
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 informacin sobre el comportamiento correcto, el
nombre del tester (y tal vez el revisor), el entorno de prueba y cualquier informacin
adicional acerca de la configuracin del software, sistema o medio ambiente. A veces
los testers clasifican el mbito de aplicacin, 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 podra
documentar los riesgos, costos, oportunidades y beneficios asociados a la fijacin o que no
se fija el defecto. El programador, al fijar el defecto, puede capturar la causa raz, la fase de
introduccin y la fase de extraccin.

Despus 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 resolucin, el sistema de seguimiento
de defectos debe permitir que cada persona que trabaja en el informe de incidente pueda
entrar en el estado e informacin de la historia.

IEEE 829 STANDARD: PRUEBA DE PLANTILLA DE INFORME DE

INCIDENTE
Prueba identificador de notificacin de incidentes
Resumen
Descripcin incidente (entradas, resultados esperados, los resultados reales, anomalas,
fecha y hora, paso del procedimiento, ambiente, los intentos de repeticin,
testers y observadores)
Impacto

5.6.3 Qu ocurre con los informes de incidentes despus de que les presenta?
Como mencionamos anteriormente, los informes de incidentes se gestionan a travs de un
ciclo de vida desde el descubrimiento hasta la resolucin. El ciclo de vida de notificacin
de incidentes se muestra a menudo como una Diagrama de transicin de estado (vase 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 cmo un ciclo de vida de
notificacin de incidentes podra funcionar.

En el ciclo de vida de notificacin de incidentes se muestra en la Figura 5.3, todos los

informes de incidentes se mueven a travs de una serie de estados claramente identificados
despus 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 relacin
con el cierre de un informe de incidente. Algunos de estas transicin 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.
Despus 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 confirmacin. Si la prueba de confirmacin
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 ms 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 transicin del
incidente en un estado posterior permitido. Las flechas en el diagrama de demostracin
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 ms gravedad asociada con un reporte diferido
de incidente.

Lo ideal sera que slo el propietario puede pasar el informe del incidente de los actuales
estado a otro estado y lo ideal es que el propietario slo puede hacer la transicin del
incidente, informar a un estado prximo permitido. La mayora 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 gestin de la empresa.
Repaso Captulo
Vamos a repasar lo que ha aprendido en este captulo.
De la Seccin 5.1, ahora debera ser capaz de explicar las ideas bsicas de la organizacin
de las pruebas. Usted debe saber porque las pruebas independientes son importantes,
sino tambin 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
lder de la prueba llevaran a cabo.
Usted debe saber el glosario de trminos tester, el lder de la prueba y gerente de prueba.
De la Seccin 5.2, ahora debera comprender los fundamentos de planificacin de las
pruebas y la estimacin. debe saber las razones de la elaboracin de planes de prueba y
ser capaz de explicar cmo se relacionan con los planes de prueba de proyectos, niveles
o fases de prueba, los de objetivos de prueba y ejecucin pruebas. debe saber qu partes
del proceso de prueba requieren especial atencin en la planificacin de las
pruebas. Usted debe ser capaz de explicar la justificacin detrs de varios criterios de
entrada y salida que podran relacionarse a los proyectos, niveles o fases de prueba y
los objetivos de la prueba. debe ser capaz de distinguir el propsito y el contenido de los
planes de prueba de la prueba de diseo 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 cmo afectan a las pruebas. Usted
debera ser capaz de explicar cmo se utilizan mtricas, la experiencia y la negociacin de
estimar. Usted debe conocer los trminos 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 Seccin 5.3, usted debe ser capaz de explicar los fundamentos del seguimiento y
control de progreso de las pruebas. Usted debe saber las mtricas comunes que son
tomadas, guardadas y usadas para el monitoreo, as como formas de presentar estas
mtricas. Usted debe ser capaz de analizar, interpretar y explicar las mtricas de prueba
que pueden ser tiles para el informe del estado de las pruebas y para tomar decisiones
acerca de cmo controlar el progreso de prueba.

Usted debe ser capaz de explicar un informe provisional de situacin tpica y conocer el
informe resumen de la prueba IEEE 829 y el registro de la prueba. Usted debe saber los
trminos del glosario densidad de defectos, tasa de fallos, control de prueba, prueba
cobertura, monitorizacin de las pruebas y el informe de prueba.

De la Seccin 5.4, ahora debera comprender los fundamentos de la configuracin de la

gestin que se refieren a la prueba. Usted debera ser capaz de resumir la ayuda que
proporciona la gestin de la configuracin de la prueba para hacer nuestro trabajo
mejor. Usted debe conocer los trminos del glosario gestin de la configuracin y el
control de versiones.

De la Seccin 5.5, ahora debera ser capaz de explicar cmo 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 consecucin 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 tpicos para el producto y el proyecto. Debieras ser capaz de describir cmo
utilizar el anlisis de riesgos y gestin de riesgos para pruebas y planificacin de las
pruebas. Usted debe conocer los trminos del glosario riesgo del producto, el riesgo del
proyecto, los riesgos y las pruebas basadas en el riesgo.

De la Seccin 5.6, usted debe entender ahora el registro de incidentes y ser capaz de
utilizar la gestin de incidencias en sus proyectos. debe conocer el contenido de un
informe de incidente de acuerdo con la estndar IEEE 829. Usted debe ser capaz de
escribir con alta calidad informe basado en los resultados de pruebas y gestionar dicho
informe a travs de su vida ciclo. Usted debe saber el trmino del glosario registro de
incidentes.

PREGUNTAS examen de la muestra

Pregunta 1 Por qu son importantes las pruebas independientes?
a. Las pruebas independientes es generalmente ms barato que las pruebas de su propio
trabajo.
b. Las pruebas independientes es ms eficaz en la bsqueda defectos.
c. testers independientes deben determinar la procesos y metodologas utilizadas.
d. testers independientes son desapasionados acerca si el proyecto tiene xito o no

Pregunta 2 Cul de las siguientes es una de las tareas tpicas de un lder de prueba?
a. Desarrollar los requisitos del sistema, diseo especificaciones y modelos de uso.
b. Manejar todas las funciones de automatizacin de pruebas.
c. Mantener pruebas y cobertura de las pruebas ocultas a programadores.
d. Reunir y presentar las mtricas de progreso de la prueba.

Pregunta 3 Segn el Glosario ISTQB, Qu queremos decir cuando llamamos a alguien

gerente de prueba?
a. Un director de pruebas gestiona una coleccin de prueba lderes.
b. Un director de pruebas es el lder de un equipo de prueba o equipos.
c. Un director de pruebas se le paga ms de un lder de la prueba.
d. Un gerente prueba de informes a un lder de la prueba.

Pregunta 4 Cul es la principal diferencia entre el plan de pruebas, la especificacin de

diseo de la prueba, y del procedimiento de ensayo?
a. El plan de ensayo describe uno o ms niveles de las pruebas, las especificaciones de diseo
de la prueba identifican casos de prueba de nivel alto y una prueba especificacin del
procedimiento se describen las acciones de la ejecucin de una prueba.
b. El plan de pruebas es para los administradores, el diseo de la prueba especificacin es
para los programadores y la prueba especificacin del procedimiento es para los testers que
se encuentran la automatizacin de pruebas.
c. El plan de pruebas es la menos profunda, la prueba especificacin del procedimiento es el
ms completo y la especificacin de diseo 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 especificacin de diseo
de la prueba se acaba en el tercio medio del proyecto y la prueba especificacin del
procedimiento se acaba en la ltima tercio del proyecto.

Pregunta 5 Cul de los siguientes factores es una influencia en la prueba de esfuerzo

involucrado en la mayor parte proyectos?
a. La separacin geogrfica de tester y programadores.
b. La salida del director de pruebas durante el proyecto.
c. La calidad de la informacin utilizada para desarrollar los exmenes.
d. enfermedad inesperada a largo plazo por un miembro del equipo del proyecto.

Pregunta 6 El Plan de Estudios de la Fundacin ISTQB establece un proceso de prueba

fundamental en la prueba la planificacin se produce al principio del proyecto, mientras que
la prueba ejecucin se produce al final. Cul de los siguientes elementos del plan de pruebas,
mientras que se especifique durante la prueba Planificacin, se evala durante la ejecucin
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 crtico.
II Todas las interfaces entre los componentes probados.
III 100% de cobertura de cdigo 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.

Cul de las siguientes afirmaciones es verdadera acerca si estos criterios de salida

pertenecen a una aceptacin Plan de prueba?
a. Todas las declaraciones pertenecen en un plan de pruebas de aceptacin.
b. Slo comunicado que pertenece a una prueba de aceptacin plan.
c. Slo los nmeros I, II y V pertenezco en un plan de pruebas de aceptacin.
d. Slo los nmeros I, IV, V y pertenecen a un plan de pruebas de aceptacin.

Pregunta 8 Segn el Glosario ISTQB, lo que es un nivel de prueba?

a. Un grupo de actividades de prueba que se organizan juntos.
b. Uno o ms especificacin de diseo de la prueba documentos.
c. Un tipo de prueba.
d. Una certificacin ISTQB.

Pregunta 9 Cul de las siguientes mediciones hara ser ms til para vigilar durante la
ejecucin de la prueba?
a. Porcentaje de casos de prueba escrita.
b. Nmero de entornos de prueba que queden por configurado.
c. Nmero de defectos encontrados y fijos.
d. Porcentaje de requisitos para los que tiene una prueba ha escrito.

Pregunta 10 Durante la ejecucin de pruebas, la prueba gerente describe la siguiente situacin

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 confirmacin. Del restante 15 defectos, gestin de
proyectos tiene decidieron que no necesitan ser fijado antes de lanzamiento.' Cul de los
siguientes es la interpretacin ms razonable de este informe provisional de situacin?

a. Los restantes 15 defectos deben ser de confirmacin probado antes de su liberacin.

b. El 10% restante de los casos de prueba se debe ejecutar antes de su liberacin.
c. Ahora el sistema est listo para el lanzamiento sin ms pruebas o esfuerzo de desarrollo.
d. Los programadores deben centrar su atencin en la fijacin de los defectos restantes
conocido antes de su liberacin.

Pregunta 11 En un informe resumen de la prueba, el supervisor de la prueba del proyecto

hace la siguiente declaracin, 'El subsistema de procesamiento de pagos no acepta los pagos
de los titulares de tarjetas American Express, que se considera una caracterstica
imprescindible para este trabajo lanzamiento.' Esta declaracin es probable que se encuentre
en cul de las siguientes secciones?
a. Evaluacin
b. Resumen de las actividades
c. varianzas
d. Descripcin incidente

Pregunta 12 Durante un perodo inicial de prueba ejecucin, un defecto se encuentra, resuelto

y confirmado como resuelto de una comprobacin, pero se ve de nuevo ms tarde durante la
ejecucin de la prueba posterior. Cul de los siguientes es un aspecto relacionados con las
pruebas de gestin de la configuracin que es ms probable que se han venido abajo?

a. trazabilidad
b. prueba de confirmacin
c. Control de la configuracin
d. gestin de documentacin 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. Cul de los siguientes
es un riesgo del producto con respecto a dicha proyecto?
a. La llegada de un producto competidor ms fiable en el mercado.
b. Entrega de una versin de prueba incompleta a la primera ciclo de prueba del sistema.
c. Un excesivamente alto nmero de soluciones a anomalas fallan durante la re-prueba.
d. Si no se acepta tarjetas de crdito permitidas.

Pregunta 14 Una reunin de anlisis de riesgo del producto es que tuvo lugar durante el
perodo de planificacin del proyecto. Cul de la siguiente determina el nivel de riesgo?
a. Dificultad de la solucin de problemas relacionados con el cdigo
b. El dao que podra causar al usuario
c. El precio por el que se vende el software
d. El personal tcnico de la reunin

La pregunta 15 que est escribiendo un plan de pruebas utilizando la IEEE 829 plantilla y
actualmente estn completando la seccin de riesgos y contingencias. De los cuales lo que
sigue es ms 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. corrupcin de los datos en virtud de congestin 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 planificacin de un proyecto. Qu
ms debe hacer con esas listas de riesgos durante la prueba planificacin?

a. Determinar el alcance de las pruebas requeridas para el riesgo de los productos y la

mitigacin 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 mitigacin para todos los
riesgos del proyecto.
d. No se requiere ninguna accin adicional de gestin de riesgos en la etapa de planificacin
de las pruebas.

Pregunta 17 Segn el Glosario ISTQB, una riesgo del producto se relaciona con cul 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 declaracin, En este punto,

me esperar recibir un mensaje de error que explica la rechazo a esta entrada invlida y me
pide que introduzca una entrada vlida. 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 declaracin es probable que sea encontrado en cul de las
siguientes secciones de IEEE 829 informe de incidente estndar?
a. Resumen
b. Impacto
c. Tema pase / no pasa criterios
d. Descripcin incidente
Pregunta 19 Segn el Glosario ISTQB, qu es lo que llamamos un documento que describe
cualquier evento que ocurri durante la prueba que requiere investigacin ms 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 anlisis de riesgo del producto durante la etapa de planificacin

del proceso de prueba.
Durante la fase de ejecucin 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 relacin con cada producto riesgo conocido y desconocido
riesgos. Cul es una posible utilizacin 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 direccin de correo utilizado como un ejercicio en el Captulo 1. Utilice la
plantilla de incidentes para transformar esa e- enviar por correo en un defecto informe bien
escrito. Asegrese de tomar en cuenta y resolver algunos de los problemas con la direccin
de correo. Sintase libre de utilizar su imaginacin para crear los detalles adicionales que
pueda necesitar para una buen informe de defectos.
SOLUCIN DE EJERCICIO
Este es un posible defecto informe derivado de la direccin de correo. Tenga en cuenta que
se ha evitado la repeticin y lenguaje emotivo. Nos hemos asegurado de incluir suficientes
pruebas y los pasos para reproducir el problema.
Descripcin breve Los entornos de cliente no estn claramente identificados en pantalla para
el usuario y el mtodo de iniciar sesin en un entorno de cliente permite a los entornos de
prueba y produccin 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.
Evaluacin de impacto
Prioridad baja a mediana
Muy alta severidad
(No detener procedimiento de prueba)
(Podra afectar los negocios de los usuarios)
Descripcin detallada Los entornos de cliente no estn claramente identificados en pantalla
para el usuario y el mtodo de iniciar sesin en un entorno de cliente permite a los entornos
de prueba y produccin 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 hara la prueba realiza dentro de las reas de desarrollo
y el sistema de ensayo ms eficiente y tambin es importante para la comunidad de usuarios.
Este problema surgir para los usuarios de dos maneras:
Llevan a cabo UAT en sus propias mquinas y por lo tanto los datos de prueba, as como
los clientes en vivo estn disponibles en sus listas y pueden mal seleccione el cliente, ya sea
en la realizacin 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 pases / mercados y necesitan saber que estn
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 haba comenzado dos clientes, es decir, dos participantes en el intercambio, por lo que
poda 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 ratn una fraccin 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 haba planeado y no poda conseguir los resultados que yo
esperaba. Despus de algunas investigaciones me di cuenta de que haba cometido un error
en la prueba de puesta a punto seleccionando el cliente equivocado. Qu hizo que mi error
y podra prevenirse? mientras que en el diario de navegacin 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 sesin para el lado del cliente se realiza mediante la seleccin 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 pas por defecto /

mercado, que no se muestra en pantalla y puede ser mal seleccionados. Proporcionar una
pantalla de inicio de sesin para el cliente y que muestra el cliente seleccionado en la pantalla
prevendra estos dos errores de usuario.

Aunque esto no es un problema funcionalidad y es causada por un error de usuario, que es

un error fcil de hacer y podra tener un gran impacto. En trminos de la vida real que
significa un usuario real podra estar conectado al sistema de produccin 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 produccin de negociacin de acciones,
cuando un operador introduce una carga de transacciones de prueba en la produccin del
sistema por error y causado problemas considerables (vase 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
raz.
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 eleccin pas
estadsticas de tiempo de recuperacin para este problema, el problema / defecto mercado
del pas y el problema de la equidad del sistema referido a.
CAPTULO SEIS
Herramienta de apoyo para las pruebas
ou puede desear que tenas una herramienta mgica que automatizar todos
la prueba para usted. Si es as, usted se sentir decepcionado. Sin embargo, hay una
nmero de herramientas muy tiles que pueden aportar beneficios significativos. En este
captulo
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 - tambin 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 ejecucin de pruebas, herramientas de pruebas de rendimiento,
herramientas de anlisis esttico y
herramientas de gestin 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 seccin, vamos a describir los diferentes tipos de herramientas en trminos de su
general
funcionalidad, en vez de entrar en muchos detalles. La razn de esto es que, en
en general, los tipos de herramienta ser bastante estable durante un perodo ms largo, a
pesar de que
habr nuevos proveedores en el mercado, herramientas nuevas y mejoradas, e incluso la
nueva
tipos de herramienta en los prximos aos.
No mencionaremos las herramientas comerciales en este captulo. Si lo hemos hecho, este
libro
datara muy rpidamente! 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 clasificacin 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 gestin,
herramientas para
apoyar las pruebas estticas, 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
 pgina 170
herramienta de cdigo. Algunas herramientas realizan una funcin muy especfica y limitada
(a veces
llama una "solucin puntual '), pero muchas de las herramientas comerciales destinadas a
ayudar
un nmero de diferentes funciones (suites de herramientas o familias de herramientas). Por
ejemplo, una
herramienta "de gestin de pruebas 'puede proporcionar apoyo para la gestin de las pruebas
(el progreso
monitoreo), gestin de la configuracin de testware, gestin de incidencias,
y la gestin de requisitos y trazabilidad; otra herramienta puede proporcionar tanto
medicin de la cobertura y el apoyo diseo de la prueba.
Hay algunas cosas que la gente puede hacer mucho mejor o ms fcil 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 fcil escribir soft-
cermica que puede reconocer una cara.
Hay otras cosas que las computadoras pueden hacer mucho mejor o ms rpido
que la gente puede hacer. Por ejemplo, se puede aadir hasta 20 nmeros de tres dgitos
con rapidez? Esto no es fcil para la mayora de la gente a hacer, por lo que es probable que
hagan
algunos errores, incluso si los nmeros estn escritos. Una computadora hace esto
con precisin y muy rpidamente. 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 rpido, esto puede
hacer esas actividades mucho ms eficiente y ms fiable. Las herramientas tambin pueden
hacer cosas que pueden saturar una persona, tales como comparar el contenido de una
archivo de datos de gran tamao o la simulacin de cmo se comportara el sistema.
Una herramienta que mide algn 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 transaccin 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 podra hacer que toda la operacin tardar un poco
ms de lo que hara si la herramienta no estaba midiendo el tiempo de respuesta. De
Por supuesto, el tiempo extra es muy pequeo, pero todava 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
podran ser ejercido para ver si una prueba ejerce o no. Esto se conoce como 'instrumento
Menting el cdigo '. Las pruebas se ejecutan a continuacin, a travs del cdigo de
instrumentos de medida
que la herramienta puede decirle (a travs de la instrumentacin) si es o no un hecho
sucursal (por ejemplo) se ha ejercido. Pero el cdigo instrumentado no es el
mismo que el cdigo de bienes - que tambin incluye el cdigo de instrumentacin. En teora,
el
cdigo es el mismo, pero en la prctica, 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 sera com-
comparacin con un nmero total de diferentes ramas. El tiempo de respuesta del instrumento
mentado cdigo tambin puede ser significativamente peor que el cdigo sin
instrumentacin. (Tambin hay herramientas de cobertura no intrusivos que observan la

pgina 171
bloques de memoria que contienen el cdigo objeto para obtener una medida aproximada
sin instrumentacin, por ejemplo, para el software embebido.)
Un ejemplo adicional del efecto de la sonda es cuando una herramienta de depuracin se
utiliza para
tratar de encontrar un defecto particular. Si se ejecuta el cdigo con el depurador, a
continuacin, el error
desaparece; slo reaparece cuando el depurador est apagada (con lo cual
es mucho ms difcil de encontrar). Estos son a veces conocidos como '' Heizenbugs
(Despus de principio de incertidumbre de Heizenberg).
En las descripciones de las herramientas a continuacin, indicaremos las herramientas que
son
ms probabilidades de ser utilizado por los desarrolladores durante las pruebas de
componentes y el componente
pruebas de integracin. Por ejemplo herramientas de medicin de cobertura son ms a
menudo
utilizados en las pruebas de componentes, sino que se utilizan con ms frecuencia las
herramientas de pruebas de rendimiento
en las pruebas del sistema, las pruebas de integracin de sistemas y pruebas de aceptacin.
Tenga en cuenta que para el examen Foundation Certificate, slo es necesario reconocer
los diferentes tipos de herramientas y lo que hacen; que no es necesario una comprensin
detallada
pie de ellos (o no saben cmo usarlos).
6.1.2 Herramienta de apoyo para la gestin de las pruebas y exmenes
Qu significa "gestin de pruebas '? Podra ser 'la gestin de pruebas "o
que podra ser 'la gestin del proceso de prueba'. Las herramientas de esta amplia categora
proporcionar soporte para uno o ambos de estos. La gestin de la prueba se aplica
sobre la totalidad del ciclo de vida del software de desarrollo, por lo que una gestin de
pruebas
herramienta podra estar entre los primeros en ser utilizado en un proyecto. Una herramienta
de gestin de pruebas
Tambin puede gestionar las pruebas, que comenzara al principio del proyecto y lo hara
a continuacin, seguir utilizndose durante todo el proyecto y tambin despus de que el
sistema tena
sido puesto en libertad. En la prctica, las herramientas de gestin de pruebas suelen ser
utilizados por especializacin
ist testers o gerentes de las pruebas a nivel de prueba del sistema o aceptacin.
herramientas de gestin de pruebas
Las caractersticas proporcionadas por las herramientas de gestin de prueba incluyen los
enumerados a continuacin.
Algunas herramientas proporcionarn todas estas caractersticas; otros pueden proporcionar
una o ms
de las caractersticas, sin embargo este tipo de herramientas todava seran clasificadas como
de gestin de pruebas
herramientas.
Rasgos o caractersticas de las herramientas de gestin de pruebas incluyen soporte para:
Gestin 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 comn, nmero de
de pruebas previstas, por escrito, correr, pasado o no);
programacin de pruebas para ser ejecutado (manualmente o mediante una herramienta de
ejecucin de la prueba);
La gestin de las actividades de prueba (tiempo de permanencia en el diseo de pruebas,
ejecucin de la prueba,
si estamos en la fecha prevista o en el presupuesto);
interfaces con otras herramientas, tales como:
- Herramientas de ejecucin de pruebas (herramientas de prueba de funcionamiento);
- Herramientas de gestin de incidentes;
- Herramientas de gestin de requisitos;
- Herramientas de gestin de configuracin;
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 gestin de
pruebas no se ejecuta pruebas,

pgina 172
pero podra resumir los resultados de herramientas de ejecucin de pruebas de que la prueba
de manejo
interfaces de las herramientas con Ment);
la preparacin de los informes de progreso basados en mtricas (anlisis cuantitativo), tales
como:
- Las pruebas se ejecutan y se pasan las pruebas;
- incidentes plantearon, defectos fijos y excepcional.
Esta informacin se puede utilizar para controlar el proceso de prueba y decidir qu
las acciones a tomar (control de prueba), como se describe en el captulo 5. La herramienta
tambin da
informacin sobre el componente o sistema que est siendo probada (el objeto de
prueba). Prueba
herramientas de gestin ayudan a reunir, organizar y comunicar informacin
acerca de las pruebas en un proyecto.
herramientas de gestin de requisitos
Son herramientas de gestin de requisitos herramientas realmente poniendo a
prueba? Algunas personas pueden decir
no lo son, sino que proporcionan algunas de las caractersticas que son muy tiles para las
pruebas.
Dado que las pruebas se basan en los requisitos, mejor ser la calidad de la exigencia
mentos, ms fcil ser para escribir pruebas de ellos. Tambin es importante estar
capaz de rastrear las pruebas a los requisitos y exigencias de pruebas, como vimos en el
Capitulo 2.
Algunas herramientas de gestin de requisitos son capaces de encontrar defectos en el
requisito
mentos, por ejemplo mediante la comprobacin de palabras ambiguas o prohibidas, tales
como
'Poder', 'y / o', 'segn sea necesario "o" (por decidir)'.
Funciones o caractersticas de las herramientas de gestin de requisitos incluyen
apoyo para:
almacenar declaraciones de requisitos;
almacenar informacin sobre los atributos de los requisitos;
verificacin de la coherencia de los requisitos;
identificar indefinido, desaparecidos o 'que se define ms adelante' requisitos;
fijacin de las prioridades para los propsitos de prueba;
trazabilidad de los requisitos a los ensayos y pruebas de los requisitos, funciones o
caracteristicas;
trazabilidad a travs de niveles de requisitos;
interfaz para probar las herramientas de gestin;
La cobertura de las necesidades por un conjunto de pruebas (a veces).
herramientas de gestin de incidentes
Este tipo de herramienta tambin se conoce como una herramienta de seguimiento de
defectos, a-gestin de defectos
herramienta, una herramienta de seguimiento de bugs o una herramienta de gestin de
errores. Sin embargo, 'incidente Hombre-
herramienta de gestin ' , porque no es probablemente un mejor nombre para l todas las
cosas
rastreado en realidad son defectos o errores; incidentes tambin pueden ser problemas
percibidos,
anomalas (que no son necesariamente defectos) o las solicitudes de mejora. Tambin lo que
Normalmente se registra es la informacin sobre el error (no el defecto) que era
generados durante la prueba - informacin sobre el defecto que caus que el fracaso
vendra 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 identificacin inicial
y el registro de los datos, mediante el anlisis, clasificacin, asignacin para

pgina 173
la fijacin, fijo, re-probado y cerrada, tal como se describe en el captulo 5. gestin de
incidentes
Ment herramientas hacen que sea mucho ms fcil hacer un seguimiento de los incidentes en
el tiempo.
Funciones o caractersticas de las herramientas de gestin de incidentes incluyen soporte
para:
almacenar informacin 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 asignacin de acciones a personas (fix, prueba de confirmacin, etc.);
Estado (por ejemplo, abierta, rechazado, duplicar, diferido, listo para la prueba de
confirmacin,
cerrado);
Informacin sobre las estadsticas sobre incidentes / mtricas (por ejemplo, tiempo medio
abierta,
nmero de incidentes con cada estado, el nmero total recaudado, abierta o
cerrado).
funcionalidad de la herramienta de gestin de incidencias se puede incluir en una prueba
comercial
herramientas administrativas.
herramientas de gestin de configuracin
Un ejemplo: Un grupo de prueba comenz a probar el software, esperando encontrar la
habitual
bastante alto nmero de problemas. Pero para su sorpresa, el software pareca estar
mucho mejor de lo habitual este tiempo - se encontraron muy pocos defectos. Antes de que
CEL
ebrated la gran calidad de esta versin, que acaba de hacer una comprobacin adicional para
ver si tenan la versin correcta y descubrieron que en realidad estaban probando
la versin de dos meses anteriores (que haba sido depurado) con las pruebas
para que la versin anterior. Era bueno saber que esto todava estaba bien, pero
no fueron en realidad probando lo que pensaban que estaban probando o lo que deberan
han estado probando.
Herramientas de gestin de configuracin no son estrictamente probando herramientas o
bien, pero
buena gestin de la configuracin es crucial para el ensayo controlado, como era
descrito en el captulo 5. Necesitamos saber exactamente qu es lo que estamos apoyo
planteado para probar, como la versin exacta de todas las cosas que pertenecen a una
sistema. Es posible llevar a cabo actividades de gestin de configuracin sin
el uso de herramientas, pero las herramientas hacen la vida mucho ms fcil, sobre todo en
el complejo
ambientes.
Testware necesita estar bajo la gestin de la configuracin y la misma herramienta
puede ser capaz de ser utilizado para testware as como para elementos de software. tambin
testware
tiene diferentes versiones y se cambia con el tiempo. Es importante para ejecutar el
versin correcta de las pruebas, as, como nuestro ejemplo anterior muestra.
Funciones o caractersticas de las herramientas de gestin de configuracin incluyen
apoyo para:
almacenar informacin 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 gestin;
baselining (por ejemplo, todos los elementos de configuracin que componen una versin
especfica);
Control de acceso (registro de salida).

pgina 174
6.1.3 Herramienta de apoyo para pruebas estticas
Las herramientas descritas en esta seccin apoyan las actividades de ensayo descritos en
Captulo 3.
herramientas de apoyo a proceso de revisin
El valor de los diferentes tipos de revisin se discuti en el captulo 3. Para una muy
revisin informal, donde una persona se ve en el documento de otra y da unos cuantos
comentarios al respecto, una herramienta como sta slo podra ponerse en el camino. Sin
embargo, cuando
el proceso de revisin es ms formal, cuando muchas personas estn involucradas, o cuando
el
personas involucradas estn en diferentes ubicaciones geogrficas, entonces el apoyo de
herramientas
se convierte en mucho ms beneficioso.
Es posible hacer un seguimiento de toda la informacin para un proceso de revisin
el uso de hojas de clculo y documentos de texto, sino una herramienta de revisin que est
diseado
con el propsito es ms probable que hacer un mejor trabajo. Por ejemplo, una cosa
que deben ser controlados para cada revisin es que los revisores no tienen
pasado el documento demasiado rpido, es decir, que la tasa de cheques (nmero de
pginas controladas por hora) fue similar a la recomendada para los que la revisin
ciclo. Una herramienta de apoyo a proceso de revisin podra calcular automticamente la
la comprobacin de tipos y la bandera excepciones. Las herramientas de apoyo a proceso de
revisin puede
normalmente ser adaptado para el proceso de revisin en particular o tipo de revisin
Siendo hecho.
Rasgos o caractersticas de las herramientas de apoyo proceso de revisin incluyen soporte
para:
 una referencia comn para el proceso de revisin o procesos para su uso en diferentes
situaciones;
almacenar y clasificar los comentarios de revisin;
comunicar a los comentarios de personas relevantes;
coordinar las revisiones en lnea;
Hacer un seguimiento de los comentarios, incluyendo defectos encontrados, y
proporcionando estadsti
cal informacin 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
exmenes, as
como criterios de entrada y salida;
supervisar el estado de la crtica (pasado, fue aprobada con correcciones, requiere re-
revisin);
recopilacin de mtricas e informar sobre los factores clave.
herramientas de anlisis esttico (D)
El '(D)' despus de esto (y otros tipos de herramienta) indica que estas herramientas son ms
propensos a ser utilizado por los desarrolladores. El anlisis esttico de herramientas se
discuti en
Captulo 3. En esta seccin se da un resumen de lo que hacen las herramientas.
Herramientas de anlisis esttico son utilizados normalmente por los desarrolladores como
parte del desarrollo
cin y el proceso de pruebas de componentes. El aspecto clave es que el cdigo (u otro
artefacto) no se ejecuta o se ejecuta. Por supuesto, la propia herramienta se ejecuta, pero el
cdigo fuente que nos interesa es la de datos de entrada a la herramienta.

pgina 175
herramientas de anlisis esttico son una extensin de la tecnologa de compilacin - de
hecho algunos
compiladores ofrecen funciones de anlisis esttico. Vale la pena comprobar lo que est
disponible
de compiladores existentes o entornos de desarrollo antes de mirar a propsito
persiguiendo una herramienta de anlisis esttico ms sofisticado.
El anlisis esttico tambin se puede llevar a cabo en otras cosas que el cdigo de software,
por
ejemplo, el anlisis esttico de requisitos o el anlisis esttico de los sitios web (por
ejemplo, para evaluar el uso adecuado de etiquetas de accesibilidad o el siguiente de HTML
normas).
herramientas de anlisis esttico de cdigo puede ayudar a los desarrolladores a entender la
estructura
tura del cdigo, y tambin se puede utilizar para hacer cumplir las normas de
codificacin. Mira la seccin
6.2.3 consideraciones especiales en la introduccin de herramientas de anlisis esttico en
una
organizacin.
Funciones o caractersticas de las herramientas de anlisis esttico incluyen soporte para:
calcular mtricas tales como la complejidad ciclomtica o niveles de anidamiento (que
puede
ayuda a identificar dnde ms pruebas puede ser necesaria debido al aumento del riesgo);
hacer cumplir las normas de codificacin;
analizar las estructuras y dependencias;
ayuda en la comprensin de cdigo;
identificar anomalas o defectos en el cdigo (como se describe en el captulo 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 difciles 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 informacin contradictoria en relacin con ese tema. Las herramientas de modelado
tambin 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 diseo de
El software.
Una gran ventaja de las dos herramientas de modelado y herramientas de anlisis esttico es
que se pueden utilizar antes de las pruebas dinmicas se pueden ejecutar. Esto permite que
cualquier
defectos que estas herramientas pueden encontrar para ser identificados tan pronto como sea
posible, cuando se
es ms fcil y ms barato para solucionarlos. Tambin hay un menor nmero 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 difcil de demostrar, ya que estos defectos no estn 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 informacin almacenada sobre un modelo en
particular (por ejemplo, una
diagrama de estado), por lo que se clasifican como herramientas de diseo del ensayo (vase
la Seccin 6.1.4).
Rasgos o caractersticas de las herramientas de modelado incluyen soporte para:
la identificacin de inconsistencias y defectos dentro del modelo;
ayudar a identificar y priorizar las reas del modelo para las pruebas;
la prediccin de la respuesta del sistema y el comportamiento bajo diversas situaciones,
tales como
nivel de carga;
facilitar la comprensin de las funciones del sistema e identificar las condiciones de prueba
utilizando una
lenguaje de modelado como UML.
 pgina 176
6.1.4 Herramienta de apoyo para la especificacin de las pruebas
Las herramientas descritas en esta seccin apoyan las actividades de ensayo descritos en
Captulo 4.
herramientas de diseo de la prueba
Herramientas de diseo 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 orculo automatizado est disponible, a continuacin, la
herramienta tambin puede con-
struct el resultado esperado, lo que en realidad puede generar casos de prueba (en lugar de
slo
entradas de prueba).
Por ejemplo, si los requisitos se mantienen en una gestin de requisitos o
herramienta de gestin 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 vlidos. Esta informacin de la distancia se puede usar para identificar
obligados-
los valores y las particiones de equivalencia aria. Si se almacena el rango vlido, 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 vlido
valor se conoce, a continuacin, que resultado esperado tambin se puede incluir en el caso
de prueba
construido por la herramienta de diseo de la prueba.
Otro tipo de herramienta de diseo 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 descripcin de estos
combinacin
tcnicas nacin.
Tenga en cuenta que la herramienta de diseo de la prueba puede tener slo un orculo parcial
- es decir,
conozca qu entrada los valores han de ser aceptados y rechazados, pero puede
No conocer el mensaje de error exacto o clculo resultante de la esperada
resultado de la prueba. As, la herramienta de diseo de la prueba puede ayudarnos a empezar
a trabajar con
diseo de la prueba e identificar todos los campos, pero no va a hacer todo el trabajo
de diseo de prueba para nosotros - no habr ms la verificacin de que pueden necesitar
estar
hecho.
Otro tipo de herramienta de diseo 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 grfica 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 botn, por ejemplo, y se seleccionar a cada cuadro de lista.
Este es un buen comienzo para un conjunto exhaustivo de pruebas y puede rpida y
fcilmente
identificar los botones que no funcionan. Sin embargo, a menos que la herramienta tiene
acceso a una
Oracle, puede no saber lo que realmente debera ocurrir como resultado de la
clic de botn.
Sin embargo, otro tipo de herramienta de diseo 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, tambin puede identificar la ruta que necesita ser tomada en
Para cubrir las ramas no probados. Al identificar cul de las decisiones anteriores
sin los resultados tienen que ser verdadera o falsa, la herramienta se puede calcular un valor
de entrada
que har que la ejecucin de tomar un camino en particular con el fin de aumentar la
cobertura.
Aqu la prueba est siendo diseado desde el propio cdigo. En este caso la presencia de
un orculo es menos probable, por lo que slo puede ser las entradas de prueba que se
construyen por
la herramienta de diseo de la prueba.

pgina 177
Rasgos o caractersticas de las herramientas de diseo de prueba incluyen soporte para:
valores de entrada la prueba de generacin a partir de:
- requisitos;
- Modelos de diseo (estado, datos u objeto);
- Cdigo;
- las interfaces grficas de usuario;
- condiciones de prueba;
Los resultados de generacin de esperar, si un orculo est disponible para la herramienta.
El beneficio de este tipo de herramientas es que se puede identificar fcilmente y rpidamente
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 ms 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 ms importantes para correr. La tala de un inmanejable
Nmero capaces de pruebas se puede hacer mediante el anlisis de riesgos (vase el captulo
5). El uso de un com-
tcnica de combinacin tales como matrices ortogonales tambin pueden ayudar.
herramientas de preparacin de datos de prueba
La creacin 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 preparacin
de datos de prueba
ayudar en esta rea. Pueden ser utilizados por los desarrolladores, pero tambin se pueden
usar
durante el sistema o pruebas de aceptacin. Son particularmente tiles para la persona
rendimiento y pruebas de fiabilidad, donde una gran cantidad de datos es realista
necesario.
herramientas de preparacin 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 ms
herramientas sofisticadas que pueden hacer frente a una serie de archivos y formatos de base
de datos.
Rasgos o caractersticas de las herramientas de preparacin de datos de prueba incluyen el
apoyo a:
Extraer seleccin de registros de datos a partir de archivos o bases de datos;
registros de datos 'masaje' para que sean annimos o no poder ser identificados
con personas reales (para proteccin 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 nmero 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 ejecucin de la prueba y la explotacin forestal
herramientas de ejecucin de pruebas
Cuando la gente piensa en una "herramienta de prueba ', por lo general es una herramienta
de ejecucin de la prueba que se
tener en cuenta, una herramienta que puede ejecutar las pruebas. Este tipo de herramienta
tambin se refiere como una
'Herramienta de prueba de marcha . La mayora de las herramientas de este tipo ofrecen una
manera de empezar capturando
o grabar las pruebas manuales; de ah que tambin se conocen como herramientas 'de
captura / reproduccin',
'/ reproduccin de captura' 'herramientas o herramientas de grabacin / reproduccin'. La
analoga es con la grabacin de una
programa de televisin, y reproduccin del mismo. Sin embargo, las pruebas no son algo

pgina 178
que se reproduce slo 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 ejecucin, como se describe en la Seccin 6.2.3.
herramientas de ejecucin de pruebas utilizan un lenguaje de script para manejar la
herramienta. el scripting
idioma es realmente un lenguaje de programacin. Por lo que cualquier tester que desea
utilizar una
herramienta de ejecucin de la prueba directamente tendr que utilizar conocimientos de
programacin 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 ejecucin de la prueba, tienden a
utilizarlo para
"Captura / reproduccin ', que suena muy bien cuando se escucha por primera vez al
respecto. los
La teora es que mientras se ejecutan las pruebas manuales, slo tiene que encender el
'Capturar', como una grabadora de vdeo para un programa de televisin. Sin embargo, la
teora
se rompe cuando intenta reproducir las pruebas capturados - este enfoque no hace
escalar para un gran nmero de pruebas. La razn principal de esto es que un capturaron
guin es muy difcil de mantener porque:
Est estrechamente ligado al flujo y la interfaz presentada por la interfaz grfica de usuario.
Se puede depender de las circunstancias, el estado y el contexto del sistema en el momento
el guin fue grabado. Por ejemplo, una secuencia de comandos capturar un nuevo orden
nmero asignado por el sistema cuando se graba una prueba. Cuando la prueba es
reproduce, el sistema asignar un nmero de orden diferente y rechazar sub
solicitudes subsiguientes que contienen el nmero de pedido previamente capturada.
La informacin de contacto de prueba es "no modificable ', es decir, que est incrustado en
el indi
UAL guin para cada prueba.
Cualquiera de estas cosas pueden ser superados mediante la modificacin de las secuencias
de comandos, pero luego
ya no son slo grabar y reproducir! Si se necesita ms tiempo para actualizar una
prueba capturado de lo que se necesitara para ejecutar la misma prueba de nuevo de forma
manual, las secuencias de comandos
tienden a ser abandonado y se convierte en la herramienta 'estantera-ware'.
Hay mejores maneras de utilizar las herramientas de ejecucin de pruebas para hacer que
funcionen bien y
realmente ofrecer los beneficios de correr sin supervisin de pruebas automatizadas. Existen
al menos cinco niveles de secuencias de comandos y tambin diferentes tcnicas de
comparacin. Datos-
scripting impulsado es un avance con respecto a las secuencias de comandos capturados pero
los scripts basado en palabras clave
dar significativamente ms beneficios. [Fewster y Graham, 1999], [Buwalda et al.,
2001]. [Mosley y Posey, 2002] describen el "control sincronizado impulsado por los datos
pruebas'. Ver tambin la seccin 6.2.3.
Hay muchas maneras diferentes de utilizar una herramienta de ejecucin de la prueba y las
herramientas
ellos continan para obtener nuevas caractersticas tiles. Por ejemplo, una prueba de eje-
cution herramienta puede ayudar a identificar los campos de entrada que formarn 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 comnmente como herramientas de prueba, que son en realidad
los ms utilizados para las pruebas de regresin (para que pudieran ser referidos como
"regresin
herramientas de prueba "en lugar de" herramientas de ensayo ). Una herramienta de
ejecucin de la prueba se ejecuta con mayor frecuencia
pruebas que ya se ha ejecutado antes. Uno de los beneficios ms significativos de
el uso de este tipo de herramientas es que cada vez que se cambia un sistema existente (por
ejemplo, para
una solucin defecto o una mejora), todos de las pruebas que se ejecutan antes podra

pgina 179
potencialmente ser ejecutado de nuevo, para asegurarse de que los cambios no han alterado
el
sistema existente mediante la introduccin o revelar un defecto.
Funciones o caractersticas de las herramientas de ejecucin de pruebas incluyen soporte
para:
captura (grabacin) 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 prxima vez que se ejecute la prueba;
ejecucin 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);
Comparacin dinmica (mientras se ejecuta la prueba) de las pantallas, elementos, enlaces,
controles, objetos y valores;
capacidad para iniciar la comparacin posterior a la ejecucin;
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 inters
para una prueba en particular;
la medicin de los tiempos de pruebas;
 sincronizacin de las entradas con la aplicacin que se est probando, por ejemplo, esperar
hasta que la apli
cacin est listo para aceptar la siguiente entrada, o insertar un retardo fijo para representar
velocidad de interaccin humana;
envo de resumen de los resultados de una herramienta de gestin 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 pequeas
programas que interactan con el software bajo prueba (por ejemplo, para las pruebas de
media
ware y software embebido). Vase el Captulo 2 para obtener ms detalles de cmo estos son
utilizado en las pruebas de integracin. 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
informacin que necesita el software que se est probando (por ejemplo, una entrada que
hara
han venido de un usuario) y tambin recibir cualquier informacin enviada por el software
(Por ejemplo, un valor que se muestra en una pantalla). Talones tambin pueden ser referidos
como
'' objetos simulados.
arneses de prueba o controladores se pueden desarrollar en el local para los sistemas
particulares.
Asesoramiento sobre el diseo de los pilotos de pruebas se puede encontrar en [Hoffman y
Strooper, 1995].
Hay un gran nmero de herramientas 'xUnit' para la programacin de diferentes len-
guas, por ejemplo JUnit para Java, NUnit para aplicaciones .Net, etc. Hay tanto
herramientas comerciales y tambin de cdigo abierto (es decir, libres) herramientas. marco
de pruebas unitarias
herramientas son muy similares a probar herramientas de ejecucin, ya que incluyen
instalaciones como
La capacidad de almacenar los casos de prueba y monitorear si las pruebas de aprobacin o
no, por ejemplo.
La diferencia principal es que no hay ninguna instalacin de captura / reproduccin y tienden
para ser utilizado en un nivel inferior, es decir, para el componente o pruebas de integracin
de componentes,
en lugar de para el sistema o pruebas de aceptacin.

pgina 180
Rasgos o caractersticas 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 recepcin generadas por el software estn probando;
la ejecucin de una serie de pruebas en el marco o usar el instrumento de prueba;
La grabacin de pasa / no pasa resultados de cada prueba (herramientas de marco);
Pruebas de almacenamiento de herramientas (marco);
Soporte para la depuracin (herramientas de marco);
Medicin de la cobertura en el nivel de cdigo (herramientas de marco).
comparadores de prueba
Es realmente una prueba de si poner algunos elementos de entrada en algn 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 debera producir. Una prueba
comparador ayuda a automatizar aspectos de esa comparacin.
Hay dos formas en las que los resultados reales de la prueba se puede comparar con el
Resultados esperados para el examen. comparacin dinmica es donde la comparacin es
hecho de forma dinmica, es decir, mientras se ejecuta la prueba. La otra forma es posterior
a la ejecucin
comparacin cin, donde se realiza la comparacin despus de la prueba ha terminado
la ejecucin y el software que se est probando ya no est en funcionamiento.
herramientas de ejecucin de pruebas incluyen la capacidad de realizar la comparacin
dinmica
mientras que la herramienta se ejecuta una prueba. Este tipo de comparacin es buena para
comparar
la redaccin de un mensaje de error que aparece en una pantalla con la redaccin correcta
para ese mensaje de error. comparacin dinmico 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 accin de recuperacin en este momento o ir a un conjunto diferente de las
pruebas.
la comparacin posterior a la ejecucin por lo general se realiza mejor mediante una
herramienta independiente (es decir, no
la herramienta de ejecucin de la prueba). Este es el tipo de herramienta que entendemos por
una prueba comparativa
tor o prueba de comparacin de herramienta y es tpicamente una herramienta de 'stand-
alone'. Operante
sistemas normalmente tienen herramientas de comparacin de archivos disponibles que
pueden ser utilizados para
la comparacin posterior a la ejecucin y, a menudo una herramienta de comparacin se
desarrollarn in-
casa para la comparacin de un determinado tipo de archivo o prueba de resultado.
comparacin post-ejecucin es el mejor para la comparacin de un gran volumen de datos,
por
ejemplo la comparacin de los contenidos de un archivo completo con el contenido esperado
de
dicho archivo o en la comparacin 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 lnea durante la noche del da) es probablemente
imposible
prescindir de soporte de la herramienta.
Si una comparacin es dinmica o posterior a la ejecucin, 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 orculo de prueba. Vase el Captulo 4
para informacin
cin sobre orculos de prueba.
Rasgos o caractersticas de los comparadores de prueba incluyen soporte para:
Comparacin dinmica de eventos transitorios que se producen durante la ejecucin de la
prueba;
comparacin posterior a la ejecucin de los datos almacenados, por ejemplo, en archivos o
bases de datos;
enmascaramiento o filtrado de subconjuntos de los resultados reales y esperados.

pgina 181
herramientas de medicin 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 podran
ser lneas de cdigo
o instrucciones de cdigo o los resultados de decisiones (por ejemplo, la salida Verdadero o
Falso de un SI
declaracin). En el nivel de integracin de componentes, el elemento de cobertura puede ser
una llamada a
una funcin o mdulo. Aunque la cobertura se puede medir en el sistema o aceptacin
ANCE niveles de prueba, por ejemplo, cuando el elemento de cobertura pueden ser una
declaracin requisito
cin, no hay muchos (si lo hay) herramientas comerciales a este nivel; hay ms
herramienta de apoyo a nivel de las pruebas de componentes o en cierta medida al
componente de inte-
gracin nivel.
El proceso de identificacin de los elementos de cobertura a nivel de prueba de componentes
es
llamado "instrumentar el cdigo ', tal como se describe en el captulo 4. Un conjunto de
pruebas se
a continuacin, ejecute a travs del cdigo instrumentado, usando ya sea automticamente
una prueba de eje-
cution herramienta o manualmente. La herramienta de cobertura a continuacin, cuenta el
nmero de cobertura
Los artculos que han sido ejecutadas por el banco de pruebas, e informa del porcentaje de
elementos de cobertura que se han ejercido, y tambin puede identificar los elementos que
todava no se han ejercido (es decir, an 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 ms sofisticadas de cobertura pueden proporcionar apoyo para ayudar a
iden-
tificar las entradas de prueba que ejercer las rutas que incluyen, que an no ejercidas
elementos de cobertura (o enlace a una herramienta de diseo de prueba para identificar la
no ejercidas
artculos). 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 instruccin IF) que ninguna prueba ha tenido hasta ahora, y puede entonces
tambin ser capaz
para calcular la entrada de prueba requerida para forzar la ejecucin de tomar esa decisin
resultado.
Rasgos o caractersticas de las herramientas de medicin de cobertura incluyen soporte
para:
Identificacin de los elementos de cobertura (instrumentar el cdigo);
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 identificacin de entradas de prueba para ejercer artculos que an no cubiertas
(herramienta de diseo 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 slo miden la cobertura de los elementos
que
se pueden identificar. El hecho de que las pruebas han logrado declaracin 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
 pgina 182
en la red, el software de soporte, el cdigo de la aplicacin o el subyacente
base de datos.
Funciones o caractersticas de las herramientas de pruebas de seguridad incluyen soporte
para:
la identificacin de los virus;
deteccin de intrusiones, tales como ataques de denegacin 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 contraseas y contraseas;
controles de seguridad durante el funcionamiento, por ejemplo, para comprobar la
integridad de los archivos, y
deteccin de intrusos, por ejemplo, comprobacin de los resultados de los ataques de prueba.
6.1.6 Herramienta de apoyo para el funcionamiento y la supervisin
Las herramientas descritas en esta prueba el apoyo seccin 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 podra ser despus de un sistema se libera en el modo Live.
Las herramientas de anlisis dinmico (D)
Las herramientas de anlisis dinmicos son "dinmico", ya que requieren que el cdigo
sea
corriendo. Son "anlisis" en lugar de herramientas de 'prueba' porque analizan lo
que est pasando "entre bastidores", mientras que el software est en ejecucin (ya sea siendo
ejecutado con casos de prueba o de ser utilizado en la operacin).
Una analoga con un coche puede ser til en este caso. Si usted va a mirar un coche para
comprar,
podra sentarse en ella para ver si es cmodo y ver lo que suenan las puertas hacen - esto
sera el anlisis esttico porque el coche no est siendo impulsada. Si se toma una prueba de
conduccin,
entonces sera 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 sera una prueba. Mientras que el coche
est en marcha,
si se va a comprobar el nivel de aceite o el lquido de frenos, esto sera lisis dinmico
sis - que slo 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 ms lento con el tiempo, pero es mucho
mejor despus de volver a arrancar, esto tambin puede deberse a una "prdida de memoria",
donde
los programas no liberan correctamente bloques de memoria de nuevo a la operacin
sistema. Finalmente, el sistema funcionar sin memoria por completo y se detendr. Re-
restaura el arranque de toda la memoria que se haba perdido, por lo que el rendimiento de la
sistema se ha restaurado a su estado normal.
Rasgos o caractersticas de las herramientas de anlisis dinmicos incluyen soporte para:
la deteccin de fugas de memoria;
la identificacin de puntero errores aritmticos tales como punteros nulos;
 la identificacin de dependencias de tiempo.
Estas herramientas normalmente seran utilizados por los desarrolladores en la prueba de
componentes y
las pruebas de integracin de componentes, por ejemplo, al probar el middleware, cuando las
pruebas
de seguridad o en la bsqueda de defectos de robustez.
Otra forma de anlisis dinmico para sitios web es comprobar si cada enlace
Se comunica efectivamente a otra cosa (este tipo de herramienta puede ser llamado un "Web
araa'). La herramienta no sabe si se ha vinculado a la pgina correcta, pero al
menos se puede encontrar enlaces muertos, que pueden ser tiles.

pgina 183
El rendimiento de pruebas, pruebas de carga y herramientas de pruebas de estrs
Actuacin-
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 nmero 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 "estrs" es uno
que va
ms all del uso normal esperado del sistema (para ver lo que sucedera
fuera de sus expectativas de diseo), 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
propsito
de la prueba es medir caractersticas, 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 algn tipo de
la actividad en el sistema, y esto se puede hacer de diferentes maneras. En una muy simple
nivelar la misma transaccin podra repetirse muchas veces, pero esto no es realis-
tic. Hay muchos niveles de realismo que se podran establecer, en funcin de la herramienta,
tales como diferentes perfiles de usuario, diferentes tipos de actividades, retrasos y
temporizacin
otros parmetros. Adecuadamente la replicacin de los entornos de usuario final o usuario
perfiles suele ser clave para obtener resultados realistas.
El anlisis 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 continuacin, algunos anlisis debe realizarse
para ver dnde est el problema y saber qu se puede hacer para mejorar la
actuacin.
Rasgos o caractersticas de las herramientas de pruebas de rendimiento incluyen soporte
para:
la generacin de una carga en el sistema a ensayar;
 la medicin de la temporizacin de las operaciones especficas como la carga en el sistema
de
vara;
la medicin de tiempos medios de respuesta;
la produccin de grficos 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 ms temprana de problemas y para mejorar el
servicio.
Hay herramientas de monitoreo para servidores, redes, bases de datos, seguridad, desempeo
Ance, sitio web y el uso de Internet y aplicaciones.
Rasgos o caractersticas de las herramientas de supervisin incluyen soporte para:
la identificacin de problemas y el envo de un mensaje de alerta al administrador (por
ejemplo,
administrador de red);
Inicio de sesin en tiempo real e informacin histrica;
encontrar los valores ptimos;
controlar el nmero de usuarios en una red;
El trfico de red de monitoreo (ya sea en tiempo real o que cubre una longitud dada de
momento de la operacin con el anlisis realizado despus).

pgina 184
6.1.7 Herramienta de apoyo para las reas especficas de la aplicacin (KL)
En este captulo, hemos descrito las herramientas de acuerdo a su funcionalidad en general
clasificaciones. Tambin 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 anlisis
esttico
herramientas para las plataformas de desarrollo y lenguajes de programacin especficos,
desde
cada lenguaje de programacin y cada plataforma tiene caractersticas distintas.
Hay herramientas de anlisis dinmicos que se centran en temas de seguridad, as como
Las herramientas de anlisis dinmicos para sistemas embebidos.
juegos de herramientas comerciales podrn agruparse para reas de aplicacin especficas,
tales como
o sistemas integrados basados en web.
6.1.8 Herramienta de apoyo utilizando otras herramientas
Las herramientas descritas en este captulo 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 clculo
como una
herramienta de prueba, pero a menudo se utilizan para almacenar los diseos de prueba,
scripts de prueba o datos de prueba.
Testers pueden tambin utilizar SQL para configurar y consultar bases de datos que contiene
los datos de prueba.
Las herramientas utilizadas por los desarrolladores cuando la depuracin, para ayudar a
localizar defectos y comprobar
sus correcciones, tambin estn probando herramientas.
Los desarrolladores utilizan herramientas de depuracin al identificar y corregir
defectos. los
herramientas de depuracin 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 cdigo de hecho va a corregir el defecto.
Es una buena idea para buscar en cualquier tipo de herramienta a su disposicin formas que
podra
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 automatizacin y la herramienta
apoyo para la prueba. (K2)
2 Reconocer que las herramientas de ejecucin de pruebas pueden tener diferentes
scripting tecnologa
tcnicas, incluyendo impulsado por los datos y basado en palabras clave. (KL)
La razn de la adquisicin 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 introduccin de herramientas en una organizacin se puede encontrar en
la web arti-
culos, revistas y libros, tales como [Dustin et al., 1999], [Siteur, 2005] y
[Fewster y Graham, 1999].

pgina 185
6.2.1 Los beneficios potenciales de la utilizacin de herramientas
Hay muchos beneficios que se pueden obtener mediante el uso de herramientas para apoyar
la prueba,
cualquiera que sea el tipo especfico de herramienta. Los beneficios incluyen:
Reduccin del trabajo repetitivo;
una mayor coherencia y capacidad de repeticin;
evaluacin objetiva;
facilidad de acceso a la informacin 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 ejecucin de pruebas de regresin, entrando en la misma
datos de prueba una y otra vez (ambos de los cuales se pueden hacer por una ejecucin de la
prueba
la herramienta), la comprobacin contra los estndares de codificacin (que puede ser
realizado por un anli- esttico
herramienta sis) o la creacin de una base de datos de ensayo especfico (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 estn 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
dnde
este aspecto es beneficioso incluir la comprobacin para confirmar la exactitud de una
solucin de
un defecto (que puede ser realizado por una herramienta de herramienta de depuracin o
ejecucin de la prueba), Enterprise
ING entradas de prueba (que se pueden hacer con una herramienta de ejecucin de la prueba)
y de generacin
pruebas de requisitos (que se pueden hacer con una herramienta de diseo de la prueba o,
posiblemente,
una herramienta de gestin 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 evaluacin es ms repetible y calculado de forma coherente.
Los ejemplos incluyen la evaluacin de la complejidad ciclomtica o niveles de imbricacin
de una
componente (que puede ser realizado por una herramienta de anlisis esttico), la cobertura
(cobertura
herramienta de medicin), el comportamiento del sistema (herramientas de monitoreo) y las
estadsticas de incidentes
(Herramienta de gestin de pruebas).
Tener gran cantidad de datos no significa que la informacin se comunica.
La informacin presentada visualmente es mucho ms fcil para la mente humana para tomar
en
e interpretar. Por ejemplo, una tabla o grfica es una mejor manera de mostrar informacin
cin de una larga lista de nmeros - esta es la razn por tablas y grficos de clculo en
sbanas son tan tiles. herramientas especiales dan estas funciones directamente para la
informacin que procesan. Los ejemplos incluyen estadsticas y grficos sobre la prueba
el progreso (ejecucin de la prueba o de la herramienta de gestin de pruebas), las tasas de
incidencia (incidente
herramienta de gestin o administracin de pruebas) y rendimiento (performance
herramienta de prueba).
Adems de estos beneficios generales, cada tipo de herramienta tiene beneficios especficos
en relacin con el aspecto de las pruebas que soporta la herramienta particular. estos
beneficios
son normalmente un lugar destacado en la informacin 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.

pgina 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 garanta de beneficios que alcanzan, al igual que
la compra
membresa en un gimnasio no garantiza que usted estar ms en forma. Cada tipo de
herramienta requiere una inversin de tiempo y esfuerzo para lograr el potencial
beneficios.
Hay muchos riesgos que estn presentes cuando el apoyo de herramientas para la prueba es
intro-
producida y utilizada, sea cual sea el tipo especfico de herramienta. Los riesgos incluyen:
expectativas poco realistas de la herramienta;
subestimar el tiempo, costo y esfuerzo para la introduccin 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 introduccin de algo nuevo en una organizacin rara vez es sencillo.
Despus de haber comprado un instrumento, tendr que pasar de la apertura de la caja para
tener
un nmero de personas que son capaces de utilizar la herramienta de una manera que traer
beneficios.
Habr problemas tcnicos que superar, pero tambin habr resistencia
de otras personas - tanto deben ser abordados con el fin de tener xito en la introduccin
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 ms 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 utilizacin de la herramienta con el fin de lograr lo que es posible.
Afortunadamente, hay algunos atajos (por ejemplo, libros y artculos sobre la lectura
Otras experiencias y aprender de ellos de la gente). Vase tambin la seccin 6.3 para
ms detalles sobre la introduccin de una herramienta en una organizacin.
una planificacin 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 planificacin de mantenimiento es tambin un factor con otros tipos
de
herramienta.
Las herramientas no son definitivamente la magia! Ellos pueden hacer muy bien lo que han
sido
diseados 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 cmo evaluar los usos actuales y futuras de la herramienta.
Por ejemplo, una herramienta de ejecucin de la prueba no reemplaza la necesidad de una
buena prueba
diseo y no debe ser utilizado para todas las pruebas - algunas pruebas son an mejores

pgina 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, cules deberan ser los casos de prueba y cmo
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 cmo dar el aumento de los beneficios del uso de la
herramienta.
6.2.3 Consideraciones especiales para algunos tipos de herramientas
herramientas de ejecucin de pruebas
A '/ herramienta de reproduccin de captura "es un trmino engaoso, aunque es de uso
comn.
Captura / reproduccin es un modo de utilizar una herramienta de ejecucin de la prueba y
probablemente el
peor manera de usarlo!
Con el fin de saber lo que pone a prueba a ejecutar y cmo ejecutar ellos, la ejecucin de
pruebas
la herramienta debe tener alguna forma de saber qu hacer - este es el guin de la
herramienta. Pero puesto que la herramienta es nico software, el guin debe ser exacta y
inequvoca al ordenador (que no tiene sentido comn). Esto significa que
el guin se convierte en un programa, escrito en un lenguaje de programacin. el Script
idioma ing puede ser especfica para una herramienta particular, o puede ser una ms general
idioma. Los lenguajes de script no se utilizan solo por las herramientas de ejecucin de
pruebas, pero la
scripts utilizados por la herramienta se almacenan electrnicamente a ser ejecutado cuando
las pruebas son
ejecutado bajo el control de la herramienta.
Existen herramientas que pueden generar secuencias de comandos mediante la identificacin
de lo que est en la pantalla
en lugar de mediante la captura de una prueba manual, pero todava generar secuencias de
comandos para ser utilizado
en la ejecucin; ellos no estn libres de la escritura.
Hay diferentes niveles de secuencias de comandos. Cinco se describen en [Fewster y
Graham, 1999]:
guiones lineales (que podran ser creadas manualmente o se capturan mediante el registro
de una
prueba manual);
guas estructuradas (mediante seleccin y estructuras de programacin de iteracin);
guiones compartidos (donde una secuencia de comandos puede ser llamado por otros
sistemas de escritura por lo que puede ser re-utilizados
- Guiones compartidos tambin requieren una biblioteca de scripts de configuracin formal
en virtud del hombre
gestin);
guiones basados en datos (cuando los datos de prueba est en un archivo o una hoja de
clculo para ser ledos por
una secuencia de comandos de control);
secuencias de comandos basado en palabras clave (donde se almacena toda la
informacin acerca de la prueba
en un archivo o una hoja de clculo, con una serie de secuencias de comandos de control que
poner en prctica 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
guin) no es una buena solucin, por una serie de razones, incluyendo:
La secuencia de comandos no sabe cul es el resultado esperado es hasta que se programa
en -
que slo almacena entradas que se han registrado, no se ponen a prueba los casos.

pgina 188
Un pequeo cambio en el software puede invalidar docenas o cientos de guiones.
El guin grabado slo puede hacer frente a exactamente las mismas condiciones que cuando
que fue grabado. Los acontecimientos inesperados (por ejemplo, un archivo que ya existe)
no sern
interpretado correctamente por la herramienta.
Sin embargo, hay algunos momentos en los que la captura de entradas de prueba (es decir
grabacin
ing una prueba manual) es til. Por ejemplo, si usted est haciendo exploratoria
prueba o si va a ejecutar pruebas sin guin con negocios con experiencia
usuarios, que pueden ser muy tiles simplemente para registrar todo lo que se hace, como
una
pista de auditora. Esto sirve como una forma de documentacin de lo que se prob
(Aunque el anlisis puede que no sea fcil). Esta pista de auditora tambin puede ser muy
til si se produce un fallo que no puede ser reproducido fcilmente - la grabacin
de la falla especfica 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 vlido. Slo que no espere para jugar de nuevo como pruebas de regresin
(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 trminos de
automatizar la ejecucin 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 cmo utilizar un lenguaje de script puede rellenar un archivo o
hoja de clculo con los datos de una prueba especfica. Esto es particularmente til cuando
hay un gran nmero de valores de datos que necesitan ser probados utilizando la misma
script de control.
secuencias de comandos basado en palabras clave incluyen no slo datos, sino tambin las
palabras clave en los datos
presentar u hoja de clculo. Esto permite un tester (que no es un programador de script) a
disear una gran variedad de pruebas (no slo 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
estn disponibles en la actualidad para usar (por alguien haber escrito un guin para l) y
los datos que la palabra clave se esperaba, pero el tester puede entonces escribir pruebas, no
slo
datos de prueba. El tester tambin puede solicitar palabras clave adicionales para ser aadido
a la
disponible programado que conjunto de scripts segn sea necesario. Las palabras clave
pueden hacer frente a tanto
entradas de prueba y los resultados esperados.
Por supuesto, alguien todava 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 utilizarn las tablas de datos o tablas de palabras clave. Una pequea
nmero de especialistas en automatizacin puede admitir un mayor nmero 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 tambin necesitan ser almacenados,
por lo
menos hasta que se comparan con los resultados esperados y las diferencias son
iniciado sesin.
Ms informacin sobre el procesamiento de datos impulsado y guiado por palabra clave se
puede encontrar
en [Fewster y Graham, 1999].

pgina 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 estn preocupados por lo tanto con funcionales
correccin, pero con caractersticas 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 precisin de un clculo dado, los recursos informticos que se utilizan para una
dado el nivel de transacciones, el tiempo necesario para determinadas operaciones o la
nmero 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 diseo 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 insercin de delaysto marca la entrada del usuario
simulado ms realista);
la duracin de la prueba y qu hacer si una prueba se detiene prematuramente;
la reduccin a la ubicacin de un cuello de botella;
exactamente qu aspectos de medir (por ejemplo, nivel de interaccin del usuario o de
servidor);
la forma de presentar la informacin recopilada.
herramientas de anlisis esttico
herramientas de anlisis esttico son muy tiles para los desarrolladores, ya que pueden
identificar el potencial
problemas en el cdigo antes de ejecutar el cdigo y tambin pueden ayudar a comprobar
que el cdigo se escribe en las normas de codificacin.
Cuando se introduce primero una herramienta de anlisis esttico, no puede haber algunos
problemas.
Por ejemplo, si la herramienta comprueba el estndar de codificacin actual frente a cdigo
escrito
Hace varios aos, puede haber una serie de cosas que se encuentran en el cdigo antiguo que
no cumplen con el nuevo estndar de codificacin ahora en su lugar. Si el cdigo de edad, ha
sido
trabajando bien durante aos, probablemente no es una buena idea para cambiarlo slo para
satisfacer
el nuevo estndar de codificacin (a menos que los cambios son necesarios por alguna otra
razn).
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 regresin.
herramientas de anlisis esttico pueden generar un gran nmero de mensajes, por ejemplo
encontrando la misma cosa cada pocas lneas. 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 anlisis esttico es producir cdigo que ser ms fcil de
mantener en el futuro, por lo que sera una buena idea para poner en prctica ms alta Stan-
nor- sobre nuevo cdigo que todava est siendo probado, antes de que se libera en el uso,
sino para
permitir que el cdigo ms antiguo pueda comprobarse de forma menos estricta. Todava 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 anlisis esttico podra eliminar algunas de las
mensajes menos importantes y que los mensajes ms importantes ms probabilidades de
hacerse notar y fijo.

pgina 190
herramientas de gestin de pruebas
herramientas de gestin de pruebas pueden proporcionar una gran cantidad de informacin
til, pero la informacin
CIN como los producidos por la herramienta no puede estar en la forma que ser ms eficaz
dentro de su propio contexto. Un cierto trabajo adicional puede ser necesaria para producir
interfaces con otras herramientas o una hoja de clculo con el fin de asegurar que la
informacin
cin se comunica de la manera ms eficaz.
Un informe producido por una herramienta de gestin de prueba (ya sea directa o
indirectamente
a travs de otra herramienta u hoja de clculo) puede ser un informe muy til en el
momento, pero puede no ser til en tres o seis meses. Es importante
monitorear la informacin producida para asegurar que es el ms relevante ahora.
Es importante disponer de un procedimiento de ensayo definido antes de gestin de pruebas
se introducen herramientas. Si el proceso de prueba est funcionando bien manualmente, a
continuacin, una
herramienta de gestin de pruebas puede ayudar a apoyar el proceso y hacerlo ms
eficiente. Si usted adopta una herramienta de gestin de prueba cuando sus propias pruebas
procesos son inmaduros, una opcin 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 especficos 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
organizacin.
6.3 La introduccin de una herramienta en AN
ORGANIZACIN
1 Estado de los principios fundamentales de la introduccin de una herramienta en una
organizacin.
(KL)
2 Estado de los objetivos de una prueba de concepto o fase para el pilotaje
evalua herramienta
cin. (KL)
3 Reconocer que otros factores, adems de simplemente la adquisicin de una
herramienta son
necesario
para una buena sujecin de la herramienta. (KL)
6.3.1 Principios fundamentales
El lugar para empezar a la hora de introducir una herramienta en una organizacin no es con
el
herramienta - es con la organizacin. Para que una herramienta para proporcionar un
beneficio, debe
coincidir con una necesidad dentro de la organizacin, 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
organizacin y direccin de sus debilidades. La organizacin tiene que estar lista
para los cambios que vendrn con la nueva herramienta. Si las prcticas actuales de prueba
No son buenos y la organizacin no est maduro, entonces es generalmente ms rentable
efectivo para mejorar las prcticas de prueba en lugar de tratar de encontrar herramientas
para apoyar
las malas prcticas. La automatizacin de caos apenas da el caos ms rpido!

pgina 191
Por supuesto, a veces podemos mejorar nuestros propios procesos en paralelo con
la introduccin de un instrumento de apoyo a esas prcticas 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
organizacin define.
Los siguientes factores son importantes en la seleccin de una herramienta:
evaluacin de la madurez de la organizacin (por ejemplo, preparacin para el cambio);
identificacin de las reas de la organizacin, donde el apoyo de herramientas se
ayudar a mejorar los procesos de prueba;
evaluacin 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;
Evaluacin del proveedor (formacin, apoyo y otros aspectos comerciales) o
la red de apoyo de cdigo abierto;
la identificacin y planificacin de implementacin interna (incluyendo entrenamiento y
tutora 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
pequea,
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 deberan
ser
resuelto en formas que pueden ser utilizados por todo el mundo ms adelante. El proyecto
piloto debera
experimentar con diferentes formas de utilizar la herramienta. Por ejemplo, los ajustes
diferentes
para una herramienta de anlisis esttico, diferentes informes de una herramienta de gestin
de pruebas, diferencia
tcnicas de scripting y la comparacin ENT durante una herramienta de ejecucin 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 ms informacin acerca de la herramienta (ms detalle, ms profundidad);
para ver cmo la herramienta encajara con los procesos existentes o documentacin, cmo
los que tendra que cambiar para trabajar bien con la herramienta y el uso de la
herramienta para optimizar los procesos existentes;
decidir sobre las formas estndar de la utilizacin de la herramienta que funcione para todos
los potenciales
los usuarios (por ejemplo, las convenciones de nombres, creacin de bibliotecas, que define
la modularidad,
donde se almacenarn los diferentes elementos, y la forma en que la propia herramienta sern
mantenido);
 evaluar el proyecto piloto respecto a sus objetivos (tienen los beneficios de estado
logrado a un costo razonable?).

pgina 192
6.3.3 Factores de xito
El xito no est garantizado o automtica en la aplicacin 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 (despus de que el piloto) con el resto de la organizacin;
la adaptacin 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 formacin adecuada, orientacin y tutora de nuevos usuarios;
definicin y comunicacin de directrices para el uso de la herramienta, en base a lo
que se ha aprendido en el piloto;
la implementacin de un mecanismo de mejora continua como herramienta de uso para
untar
a travs de ms de la organizacin;
supervisin de la utilizacin de la herramienta y los beneficios alcanzados y la adaptacin
de la
el uso de la herramienta para tener en cuenta lo que se aprende.
Ms informacin y consejos sobre la seleccin y herramientas de aplicacin pueden ser
encontrado en [Fewster y Graham, 1999] y [Dustin et al., 1999].

pgina 193
Repaso Captulo
Vamos a repasar lo que ha aprendido en este captulo.
De la Seccin 6.1, ahora debera ser capaz de clasificar los diferentes tipos de pruebas
herramientas de acuerdo con las actividades del proceso de pruebas que apoyan. Tambin
deberas
reconocer las herramientas que pueden ayudar a los desarrolladores en sus pruebas (mostrado
por '' (D)
abajo). Adems de la lista de abajo, hay que reconocer que existen herramientas
que prestan apoyo a reas especficas de aplicacin y que las herramientas de uso general
tambin puede
se utilizar para apoyar la prueba. Las herramientas que ahora debe reconocer son:
Las herramientas que soportan la gestin de las pruebas y exmenes:
- Herramienta de gestin de pruebas;
- requisitos de la herramienta de gestin;
- Herramienta de gestin de incidencias;
- Herramienta de gestin de la configuracin.
Herramientas que soportan pruebas estticas:
- Herramienta de revisin de soporte de procesos;
- Herramienta de anlisis esttico (D);
- Herramienta de modelado (D).
Herramientas que soportan la especificacin de prueba:
- Herramienta de diseo de la prueba;
- Herramienta de preparacin de los datos de prueba.
Herramientas que apoyan la ejecucin de pruebas y registro:
- Herramienta de ejecucin de la prueba;
- Instrumento de prueba y un marco de prueba de la unidad de herramienta (D);
- Comparador de ensayo;
- Herramienta de medicin de cobertura (D);
- Herramienta de seguridad.
Las herramientas que apoyan el desempeo y monitoreo:
- Herramienta de anlisis dinmico;
- Rendimiento en las pruebas, la carga de prueba y herramienta de pruebas de tensin;
- Herramienta de monitorizacin.
Adems de las herramientas mencionadas, usted debe conocer los trminos del glosario
herramienta de depuracin, conductor, efecto de sondeo y el trozo.
De la Seccin 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
ejecucin de prueba, per-
herramientas, herramientas de anlisis esttico y herramientas de gestin prueba de
rendimiento de pruebas de. T
debe conocer los trminos 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 ejecucin de
prueba.
De la Seccin 6.3, usted debe ser capaz de establecer los principios bsicos de introduccin
ing una herramienta en una organizacin (por ejemplo, la evaluacin de madurez de la
organizacin, clara
requisitos y criterios objetivos, la prueba de concepto, evaluacin de proveedores,
orientacin y tutora). Usted debe ser capaz de indicar los objetivos de una prueba-de-
concepto o fase de pilotaje para la evaluacin de herramientas (por ejemplo, aprenden acerca
de la herramienta, evaluar ajuste
con las prcticas actuales, decidir sobre las normas, evaluar los beneficios). Debe reco-
nocer que la simple adquisicin de una herramienta no es el nico factor en el logro de una
buena herramienta

pgina 194
apoyo; hay muchos otros factores que son importantes para el xito (por ejemplo incremental
mental de puesta en marcha, los procesos de adaptacin, capacitacin y entrenamiento, el uso
de la definicin
directrices, obtener experiencia y seguimiento de los beneficios). No hay finicin especfica
defini- para esta seccin.

pgina 195
PREGUNTAS examen de la muestra
Pregunta 1 Qu herramientas ayudan a apoyar esttica
pruebas?
a. herramientas de anlisis esttico y herramientas de ejecucin de pruebas.
segundo. proceso de revisin de los instrumentos de apoyo, anlisis esttico
herramientas e instrumentos de medicin de cobertura.
do. Dinmica herramientas de anlisis y herramientas de modelado.
re. proceso de revisin de los instrumentos de apoyo, anlisis esttico
herramientas y herramientas de modelado.
Pregunta 2 Qu actividades de prueba son apoyados por
arns de prueba o marco de pruebas unitarias herramientas?
a. Gestin de pruebas y control.
segundo. especificacin de las pruebas y el diseo.
do. Ejecucin de la prueba y la explotacin forestal.
re. Rendimiento y la supervisin.
Pregunta 3 Cules son los beneficios potenciales de la
el uso de herramientas en general para apoyar las pruebas?
a. Mayor calidad de cdigo, reduccin en el nmero
de testers necesarios, mejores objetivos para las pruebas.
segundo. Mayor repetibilidad de las pruebas, la reduccin de
trabajo repetitivo, la evaluacin objetiva.
do. Una mayor capacidad de respuesta de los usuarios, la reduccin de
las pruebas se ejecutan, los objetivos no es necesario.
re. Mayor calidad del cdigo, reduccin 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 ejecucin de la prueba tiene
ha comprado.
do. La herramienta puede detectar defectos que no estn all.
re. La herramienta se repetir exactamente lo mismo que lo hizo
la vez anterior.
Pregunta 5 Cul de las siguientes son avanzados
tcnicas de scripting para herramientas de ejecucin 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. Reproduccin impulsado y guiado por palabra clave
Pregunta 6 Cul de los siguientes no sera
realizado como parte de la seleccin de una herramienta para una organizacin?
a. Evaluar la madurez de la organizacin, los puntos fuertes y
debilidades.
segundo. Estirar la herramienta a tantos usuarios como sea posible
dentro de la organizacin.
do. Evaluar las caractersticas de la herramienta contra la clara
requisitos y criterios objetivos.
re. Identificar los requisitos internos para los entrenamientos y
tutora en el uso de la herramienta.
Pregunta 7 Cul de los siguientes es un objetivo para una
prueba de concepto o fase piloto para la evaluacin 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 formacin,
apoyo y aspectos comerciales.
re. Decidir sobre los procedimientos estndar para el uso, manejo,
almacenar y mantener la herramienta y la prueba
bienes.

pgina 196
examen de prueba
En el examen real, usted tendr 60 minutos para trabajar a travs de 40 preguntas
aproximadamente la misma mezcla de dificultad y distribucin Syllabus como se muestra en
la siguiente
examen de prueba. Despus de haber tomado este examen de prueba, verifique sus respuestas
con la respuesta
llave.
Pregunta 1 Qu es una clave
caracterstica de la especificacin basada en
tcnicas de prueba?
a. Las pruebas se derivan de informacin sobre
cmo 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 extensin de la
cobertura
de los elementos estructurales del sistema o
componentes.
Pregunta 2 Un conjunto de pruebas exhaustivas hara
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 afirmacin 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 despus de que el cdigo est escrito
as que eso
tenemos un sistema con el que trabajar.
do. Las pruebas se hacen ms econmicamente en el
final de
el ciclo de vida.
re. Testing slo 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 seran
la prioridad ms 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
lmite de crdito 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 clculo incorrecto de las tasas
podra
shortchange la organizacin.
II Un vendedor puede fallar para entregar una
componente del sistema a tiempo.
IIIA defecto podra permitir a los hackers
obtener privilegios administrativos.
brecha de habilidades IVA podra ocurrir en un nuevo
tecnologa utilizada en el sistema.
VA proceso de priorizacin de defectos podra
sobrecargar el equipo de desarrollo.
Cul 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.

pgina 197
Pregunta 6 Considere las siguientes afirmaciones
acerca de las pruebas de regresin:
Me Pueden automatizarse de manera til si estn bien
diseado.
II Ellos son los mismos que los ensayos de confirmacin (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 Cul de las siguientes podra ser utilizado para
evaluar la cobertura alcanzada para la estructura a base de
(caja blanca) tcnicas de prueba?
los resultados V decisin que se ejerce
Particiones W ejercidas
Los lmites 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 opinin de la parte siguiente de una
reporte de incidente.
1 coloco cualquier artculo 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 botn <Pedido>.
5 Yo esperaba que el sistema muestre el primer pago y envo
pantalla. En su lugar, nos muestra un mensaje de error emergente,
'No hay artculos 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 adicin y eliminacin
artculos 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 informacin narrativa es
incluida en el informe. Cul 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 comprobacin de la intermitencia.
re. El uso de un tono de objetivo.
Pregunta 9 Cul 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 evaluacin objetiva
4 Las expectativas poco realistas
5 La subestimacin del esfuerzo necesario para mantener
los activos de prueba generados por la herramienta
6 La facilidad de acceso a la informacin 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 Cul 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 afirmacin es cierta?
a. Los comentarios no son generalmente rentables como el
reuniones consumen mucho tiempo y requieren
preparacin y seguimiento.
segundo. Thereisnoneed toprepare Foror followuponreviews.
do. Los comentarios deben ser controladas por el autor.
re. Los comentarios son una prueba esttica temprana eficaz en el coste
sistema.

pgina 198
Pregunta 12 Considere la siguiente lista de
las actividades del proceso de prueba:
Anlisis y diseo I
las actividades de cierre de prueba II
IIIEvaluating criterios de salida y
la presentacin de informes
IVPlanning y control
V Aplicacin y ejecucin
Cul de los siguientes lugares en estos
su secuencia lgica?
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. Cul de las siguientes pruebas
objetivos pueden entrar en conflicto con el buen
mentalidad tester?
a. Demostrar que el sistema funciona, antes de
envalo.
segundo. Encontrar el mayor nmero posible de defectos.
do. Reducir el nivel general de riesgo del producto.
re. Prevenir los defectos hasta principios de
participacin.
Pregunta 14 actividades de prueba que son
con el apoyo de herramientas de preparacin de los datos de prueba?
a. gestin y control de prueba
segundo. especificacin de las pruebas y el diseo
do. Ejecucin de la prueba y la explotacin forestal
re. Rendimiento y monitorizacin
Pregunta 15 Si usted est volando con una
billete de economa, 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 aerolnea. Si tu
no estn en posesin de una tarjeta de oro, hay una posibilidad
que usted conseguir 'golpeado' fuera de la lnea area si esto
est lleno y te registras tarde. Esto se muestra
en la Figura 7.1. Tenga en cuenta que cada caja (es decir,
declaracin) 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
economa
Prueba 3: Una persona que recibe un golpe desde el
vuelo
Qu pruebas adicionales seran necesarios para
lograr una cobertura de decisin 100%?
a. Un titular de la tarjeta de oro que se queda en la economa
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 econmica.
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:
Gestin de pruebas V
herramientas
W herramientas de anlisis esttico
X herramientas de modelado
Las herramientas de anlisis dinmico Y.
herramientas de pruebas de rendimiento Z
Cul 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

pgina 199
Pregunta 17 Qu es una condicin de la prueba?
a. Una entrada, el resultado esperado,
condicin 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 especfico del software, por ejemplo,
antes de una prueba
se puede ejecutar
Pregunta 18 Cul de las siguientes es la
ms importante diferencia entre el metrics-
y enfoque basado en el enfoque basado en experto
para poner a prueba la estimacin de?
a. El enfoque basado en la mtrica es ms
preciso
que el enfoque basado en el experto.
segundo. Los usos de aproximacin basada en mtricas
clculos
a partir de datos histricos mientras que el experto-
basado
enfoque se basa en la sabidura del equipo.
do. El enfoque basado en la mtrica se puede utilizar
para verificar
una estimacin creado usando el experto-
basado
enfoque, pero no viceversa.
re. El enfoque basado en el experto lleva ms tiempo
que la
basada en mtricas de enfoque.
Pregunta 19 Si la temperatura cae
por debajo de los 18 grados, la calefaccin se desconecta
en. Cuando la temperatura alcanza 21
grados, la calefaccin se desconecta. Qu
se establece el mnimo de los valores de entrada de prueba para
cubrir todas las particiones de equivalencia vlidos?
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 Cul de estos
declaraciones acerca de las pruebas funcionales es
cierto?
a. Ensayos estructurales es ms importante
que
pruebas funcionales, ya que aborda la
cdigo.
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 ms poderoso que
pruebas estticas
ya que en realidad ejecuta el sistema y ver lo
que sucede.
re. La inspeccin es una forma de pruebas funcionales.
Pregunta 21 Cul es el propsito de
pruebas de confirmacin?
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 lgica detallada de una
componente
se ajusta a su especificacin.
Pregunta 22 factores de xito que son
necesaria para una buena soporte de la herramienta dentro de una
organizacin?
a. La adquisicin de la mejor herramienta y la garanta
que todos
testers utilizan.
segundo. procesos de adaptacin 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 adopcin de prcticas de otros exitosos
organizaciones y asegurar que formas iniciales
de
el uso de la herramienta se mantienen.
Pregunta 23 Cul de los siguientes mejor
describe las pruebas de integracin?
a. Pruebas realizadas para exponer fallos en
el
interfaces y en la interaccin
Entre
componentes integrados.
segundo. Pruebas para verificar que un componente est listo
para
integracin.
do. Pruebas para verificar que el entorno de prueba
puede ser
integrado con el producto.
re. Integracin de las pruebas de software automatizado
suites con
el producto.

pgina 200
Pregunta 24 De acuerdo con el ISTQB
Glosario, depuracin:
a. Es parte del proceso de prueba fundamental.
segundo. Incluye la reparacin de la causa de una
fracaso.
do. Consiste en aadir intencionadamente conocida
defectos.
re. Sigue los pasos de un procedimiento de prueba.
Pregunta 25 Cul de las siguientes podra
ser una causa de un defecto en la financiera
software en el que un tipo de inters incorrectos
es calculado?
a. La insuficiencia de fondos estaban disponibles para
pagar la tasa de inters calculada.
segundo. clculos insuficientes de compuesto
interesar
fueron incluidos.
do. Una formacin insuficiente se le dio a la
desarrolladores
en relacin con el clculo del inters 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 sera
seleccionados mediante anlisis de valores lmite?
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 decisin
mesa.
Teniendo en cuenta esta tabla de decisin, lo que se espera que la
como resultado de los siguientes casos de prueba?
TCI: A 26 aos de edad, por negocios, pero con
violacines o accidentes en su forma de conducir
grabar
TC2: Un turista de 62 aos de edad con una limpia
registro de conductor
a. TCI: No suministre coche; TC2: vehculo de suministro
con
de pagar prima.
segundo. TCI: vehculo de suministro de pago de prima;
TC2:
coche de alimentacin sin necesidad de pagar prima.
do. TCI: No suministre coche; TC2: vehculo de suministro
con ningn
de pagar prima.
re. TCI: vehculo de suministro de pago de prima;
TC2:
No suministrar coche.
Pregunta 28 Cul es la prueba exploratoria?
a. El proceso de anticipar o adivinar
dnde
se pueden producir defectos.
segundo. Un enfoque sistemtico para identificar
especfico
clases equivalentes de entrada.
do. La prueba llevada a cabo por un fletado
ingeniero.
re. diseo de la prueba concurrente, ejecucin de la prueba,
prueba
la tala y el aprendizaje.
Pregunta 29 Qu significa si un conjunto de
pruebas ha alcanzado una cobertura del 90% afirmacin?
a. 9 de cada 10 tienen resultados de la decisin
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
especficamente para describir un nivel de pruebas
donde el objetivo principal es el establecimiento

pgina 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
artculos
a. plan de pruebas maestro
segundo. plan de pruebas del sistema
V Confirmar que cambia a un elemento de prueba fijado un defecto
Cul de las siguientes afirmaciones es verdadera?
do. plan de pruebas de aceptacin
re. Plan de proyecto
a. Slo I es una tarea de gestin de configuracin.
segundo. Todas son tareas de gestin de configuracin.
Pregunta 31 Requisito 24.3. UN
'Asistente de franqueo' calcular la cantidad
de franqueo insuficiente para las letras y los pequeos
paquetes de hasta 1 kilogramo de peso. los
entradas son: el tipo de elemento (carta, libro o
otro paquete) y el peso en gramos.
Cul de las siguientes ajustarse a la
contenido que debe tener un caso de prueba?
do. I, II y III son las tareas de gestin de configuracin.
re. I, II y IV son las tareas de gestin de configuracin.
Pregunta 35 Considere la siguiente transicin de estado
diagrama.
a. Prueba de los tres tipos de artculo 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 Blgica. Prueba 2: libro
500 gramos a EE.UU.. Prueba 3: paquete, 999 gramos hasta
Sudfrica [Req 24.3]
thisdiagram dado, que casebelowcovers de prueba
cada transicin vlida?
a. SS-S1-S2-S4-S1-S3-ES
re. Prueba 1: 10grams letra, Blgica, gastos de envo 0,25.
Prueba 2: Paquetes de 999 gramos a Sudfrica,
gastos de envo 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 Cul es la mejor descripcin de esttica
anlisis?
Pregunta 36 Un plan de prueba incluye lo siguiente
clusulas entre los criterios de salida:
a. El anlisis de los programas de proceso por lotes
segundo. La revisin 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 anlisis de riesgo del producto.
do. El anlisis de cdigo 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 anlisis de riesgo del producto.
re. El uso de las pruebas de recuadro negro
Pregunta ejecucin de la prueba 33 del sistema en un proyecto es
planeado durante ocho semanas. Despus 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 nmero posible de defectos
durante la prueba del sistema "podra estar ms estrechamente conocido por
redirigir el esfuerzo de la prueba segn la cual la prueba
principio?
Durante la ejecucin de pruebas, el equipo de prueba detecta 430 debe-
corregir los defectos antes de su liberacin y todos los defectos debe-fix son
resuelto. Despus de la liberacin, los clientes encuentran 212 nuevo
defectos, no se detectaron ninguno de los cuales durante la prueba.
Esto significa que slo 67% de los defectos importantes
fueron encontrados antes de la liberacin, 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. agrupacin defecto.
II La organizacin tiene expectativas poco realistas de
el porcentaje de defectos que las pruebas se pueden encontrar.
Pregunta 34 Tenga en cuenta las siguientes actividades que
podra estar relacionado con la gestin de configuracin:
-tema de control de versiones IIIA ha dado lugar a la liberacin
de una versin del software que se utiliz durante
las primeras pruebas.
Yo identificar y documentar las caractersticas de una prueba
tem
Control II cambia a las caractersticas de una prueba
tem

pgina 202
IVThe anlisis de riesgos del producto no pudo
identificar todos los riesgos importantes de una
punto de vista del cliente.
V El anlisis de riesgos producto no era
actualizado durante el proyecto como nueva
la informacin estuviera disponible.
Cul de las siguientes afirmaciones indicar
los cuales son posibles explicaciones de la raz
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 Cul es el ms importante
factor para el buen desarrollo de
crticas?
a. Un escriba separada durante el registro
reunin
segundo. participantes capacitados y lderes de opinin
do. La disponibilidad de herramientas para apoyar la
revisin
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 regresin
y
puede requerir nuevas pruebas adicionales.
II Se est haciendo pruebas para demostrar lo fcil que ser
mantener
el sistema.
Iiiit es difcil alcance y, por tanto, las necesidades
cuidadoso
riesgos y anlisis de impacto.
IVIT no tiene por qu hacerse en caso de emergencia
correccin de errores. Cul 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 ESPECIFICACIN
tcnicas de ensayo basadas estn ms estrechamente
relacionados entre s?
a. Las tablas de decisin y de transicin de estados
pruebas
segundo. particin de equivalencia y el estado
transicin
pruebas
do. Las tablas de decisin y valores en la frontera
anlisis
re. Equivalencia de particin y
anlisis de valores lmite
Pregunta 40 Cul de los siguientes es
Una ventaja de las pruebas independientes?
a. testers independientes no tienen que gastar
hora
la comunicacin con el equipo del proyecto.
segundo. Los programadores pueden dejar de preocuparse
la calidad
de su trabajo y enfoque en la produccin
ms cdigo.
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 detrs de los requisitos,
y diseos
implementaciones.

pgina 203
RESPUESTAS A MUESTREAN preguntas del examen
Esta seccin contiene las respuestas y los objetivos de aprendizaje de la muestra
preguntas en cada captulo y para el papel maqueta completa en el Captulo 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 seccin. Por ejemplo, si tienes
Pregunta 4 en el captulo 1 equivocada, y luego ir a la Seccin 1.2 y ley el primer aprendizaje
ing objetivo. A continuacin, vuelva a leer la parte del captulo que se ocupa de ese tema.

pgina 204

pgina 205

pgina 206