1. Las pruebas de software, en inglés testing son los procesos que permiten
Verificar y revelar la calidad de un producto
software. Son utilizadas para identificar posibles fallos de implementación,
calidad, o usabilidad de un programa de ordenador o videojuego.
1.
¿Qué
son las pruebas de software?
Las Pruebas de
software son los procesos que permiten verificar y revelar la calidad de un
producto software. El programa se ejecuta con la intención de descubrir un
error.
2.
¿Con
que fin se realizan las pruebas de software?
El fin de las
pruebas es presentar información sobre la calidad del producto a las personas
responsables de este. Teniendo esta afirmación en mente, la información que
puede ser requerida es de lo más variada. Esto hace que el proceso de testing
sea completamente dependiente del contexto en el que se desarrolla
3.
¿Que
son las estrategias de prueba de software y para que se emplean?
Una estrategia
de prueba del software integra las técnicas de diseño de casos de prueba en una
serie de pasos bien planificados que dan como resultado una correcta
construcción del software. Y lo que es más importante, una estrategia de prueba
del software proporciona un mapa a seguir para el responsable del desarrollo
del software, a la organización de control de calidad y al cliente: un mapa que
describe los pasos que hay que llevar a cabo como parte de la prueba, cuándo se
deben planificar y realizar esos pasos, y cuánto esfuerzo, tiempo y recursos se
van a requerir. Por tanto, cualquier estrategia de prueba debe incorporar la
planificación de la prueba, el diseño de casos de prueba, la ejecución de las
pruebas y la agrupación y evaluación de los datos resultantes.
4.
¿Cuál
es la prueba que se enfoca en los requisitos necesarios para el usuario final y
que técnicas utiliza?
Prueba alfa y beta: En este servicio,
los consultores de Testhouse se encargan de
Dirigir a los
usuarios finales y asegurar que se prueban todos los requisitos y se cumplen
los criterios de aceptación especificados previamente en el plan de pruebas del
sistema. Como resultado de estas pruebas se elabora un informe que determina la
aceptación o rechazo del sistema en base los criterios de aceptación acordados.
5.
¿Cuáles
son los tres enfoques para el diseño de pruebas y en qué consiste?
Enfoque estructural o de caja blanca:
consiste en centrarse en la estructura interna (implementación) del programa
para elegir los casos de prueba.
Enfoque funcional o de caja negra:
consiste en estudiar la especificación de las funciones, la entrada y la salida
para derivar los casos.
Enfoque aleatorio: consiste en utilizar
modelos (en muchas ocasiones estadísticos) que representen las posibles
entradas al programa para crear a partir de ellos los casos de prueba.
6.
¿En
qué consiste el enfoque estructural o caja blanca?
Consiste en
centrarse en la estructura interna (implementación) del programa para elegir
los casos de prueba.
7.
¿En
qué consiste el enfoque funcional o de la caja negra?
Consiste en
centrarse en la estructura interna (implementación) del programa para elegir
los casos de prueba
8.
¿En que
consiste la prueba de regresión?
consiste intentan descubrir las causas de nuevos
errores (bugs), carencias de funcionalidad, o divergencias funcionales con
respecto al comportamiento esperado del software, inducidos por cambios
recientemente realizados en partes de la aplicación que anteriormente al citado
cambio no eran propensas a este tipo de error. Esto implica que el error
tratado se reproduce como consecuencia inesperada del citado cambio en el
programa.
9.
¿Cuáles
son las dos formas de integración y en qué consisten?
-
Integración
descendente
Es un enfoque incremental para la construcción de la
arquitectura del software. Los módulos se integran al descender por la
jerarquía de control, empezando con el módulo de control principal. Los módulos
subordinados al módulo de control principal se incorporan en la estructura de
una de dos maneras: primero en profundidad o primero de anchura.
-
Integración
ascendente
Empieza la construcción y la prueba con módulos
atómicos (es decir, componentes de los niveles más bajos de la estructura del
programa). Debido a que los componentes se integran de abajo hacia arriba,
siempre está disponible el procesamiento requerido para los componentes
subordinados a un determinado nivel y se elimina la necesidad de resguardos
10.
¿Qué
es un producto alpha, beta y master?
Alfa es la
primera versión del programa
El beta es la
primera versión completa del programa que puede ser inestable
Master pueden
responder a las necesidades actuales del área de desarrollo de software.
11.
¿Qué
diferencia hay entre una prueba de caja negra y caja blanca?
Las de caja negra se aplican a la
interfaz del software (examina un aspecto funcional con poca relación con la
arquitectura del sistema).
Las de caja blanca prueba las rutas
lógicas del software y la colaboración entre componentes. Se conoce y se tiene
en cuenta
12.
¿La
prueba y la depuración son lo mismo? ¿Por qué?
-
Prueba:
Es el proceso mediante el cual se establece la existencia de errores.
-
Depuración:
Es el proceso mediante el cual se localizan los errores.
Ambos casos tienen el objetivo de localizar y
establecer los posibles errores que se están presentando en la aplicación.
13.
¿Qué
tipo de prueba se basa en sus componentes y la forma como están sus estructuras?
Pruebas de
Integración, ya que este tipo de prueba está basado en los requisitos no
funcionales
14.
¿Las
pruebas de aceptación son definidas por el desarrollador? ¿Por qué?
Las pruebas de
aceptación aseguran el comportamiento del sistema, son escritas por el usuario
y especifican los aspectos a probar cuando una historia de usuario ha sido
correctamente implementada.
En esta
herramienta se definen las actividades que deben ser realizadas por el cliente
por lo tanto es a partir de ahí que el programador implementa los arreglos a
posibles fallas o correcciones.
15.
Defina
cada uno de los procesos de las pruebas de software
v
Pruebas Unitarias
v
Pruebas De Integración
v
Pruebas De Validación
v
Pruebas De Sistema
v
Caja Blanca
v
Caja Negra
v
Pruebas De Regresión
16.
¿Qué
diferencia existe entre un fallo, un erro y un defecto?
Falla: En terminología IEEE, una falla
es la discrepancia visible que se produce al ejecutar un programa con un
defecto, el cual es incapaz de funcionar correctamente (no sigue su curso
normal).
Error: Es una equivocación cometida por
el desarrollador. Algunos ejemplos de errores son: un error de digitación, una
malinterpretación de un requerimiento o de la funcionalidad de un método. El
estándar 829 de la IEEE coincide con la definición de diccionario de error como
"una idea falsa o equivocada". Por tal razón un programa no puede
tener o estar en un error, ya que los programas no tienen ideas; las ideas las
tienen la gente.
Defecto: Un defecto se encuentra en un
artefacto y puede definirse como una diferencia entre la versión correcta del
artefacto y una versión incorrecta. Coincide con la definición de diccionario, "imperfección".
17.
¿Es
necesario realizar las pruebas de aceptación?
Las pruebas de
aceptación, al igual que las de sistema, se realizan sobre el producto
terminado e integrado; pero a diferencia de aquellas, están concebidas para que
sea un usuario final quien detecte los posibles errores
18.
Establezca
a diferencia entre las diferentes estrategias de pruebas
Se han propuesto
varias estrategias de prueba del software en distintos libros. Todas
proporcionan al desarrollador de software una plantilla para la prueba y todas
tienen las siguientes características generales:
v
La prueba comienza en el nivel de módulo y
trabaja «hacia fuera», hacia la integración de todo el sistema basado en
computadora.
v
Según el momento son apropiadas diferentes
técnicas de prueba.
v
La prueba la lleva a cabo el responsable del
desarrollo del software y (para grandes proyectos) un grupo independiente de
pruebas.
v
La prueba y la depuración son actividades
diferentes, pero la depuración se debe incluir en cualquier estrategia de
prueba.
Una estrategia
de prueba del software debe incluir pruebas de bajo nivel que verifiquen que
todos los pequeños segmentos de código fuente se han implementado
correctamente, así como pruebas de alto nivel que validen las principales
funciones del sistema frente a los requisitos del cliente. Una estrategia debe
proporcionar una guía al profesional y proporcionar un conjunto de hitos para
el jefe de proyecto. Debido a que los pasos de la estrategia de prueba se dan a
la vez cuando aumenta la presión de los plazos fijados, se debe poder medir el
progreso y los problemas deben aparecer lo antes posible.
19.
¿Cuál
es la diferencia entre validación y verificación?
Muchas veces se
confunde “verificación” con validación”. Barry W. Boehm (1979) puso en claro
con pocas palabras la diferencia:
v
Validación:
¿Estamos construyendo el producto correcto? Se ocupa de controlar si el
producto satisface los requerimientos del usuario
v
Verificación:
¿Estamos construyendo correctamente el producto? implica controlar que el
producto conforma su especificación inicial.
En la Validación
el resultado final del desarrollo software se debe ajustar a lo que el usuario
quería (sus necesidades). En la mayoría de las ocasiones el producto
desarrollado no casa con la ideas del cliente, normalmente porque a éste suele
faltarle capacidad técnica de expresión.
En la
Verificación el código que estamos construyendo debe estar en armonía con la
especificación que hemos tomado del usuario. El resultado final del desarrollo
software debe concordar con la especificación (requisitos) del sistema, por lo
que debemos asegurarnos que el desarrollo final coincida con dicha
especificación
20.
¿Porque
es difícil aplicar pruebas de unidad a un módulo altamente acoplado?
Porque es
difícil aplicar pruebas de unidad a un módulo altamente acoplado.
si para cambiar
un módulo en un programa tenemos que cambiar otro módulo, entonces hay
acoplamiento entre ellos.
El acoplamiento
puede aparecer bajo varias formas. Por ejemplo, si hay código repetido
esparcido entre los módulos, también habrá un cierto acoplamiento, porque
cambiar un fragmento de código repetido implica cambiarlo en todos los módulos
que aparecen.
Incluso puede
que haya dependencias entre módulos y no nos demos cuenta de ello.
Pero el
acoplamiento también ocurre cuando el código de un módulo utiliza código de
otro módulo, bien porque llama a un método, o accede a sus datos.
Por ello, como
tal, el acoplamiento no es algo que debas evitar a toda costa.
Porque aunque
dividamos nuestro programa en módulos, esos módulos tendrán que interactuar
entre sí de alguna manera (si no tendríamos distintos programas independientes)
y tendremos algo de acoplamiento entre ellos.
Hay distintos
tipos y lo que es más importante, grados de acoplamiento.
Lo que es malo,
y puede que lo estés padeciendo, es tener un acoplamiento alto, fuerte, entre
los módulos.
Y peor si es
incontrolado, es decir, si no sabes claramente qué módulos dependen de otros
módulos.
21.
De
tres ejemplos de pruebas, aplique pruebas de caja negra y pruebas de caja
blanca
Tipos de pruebas
v
Pruebas Unitarias
v
Pruebas De Integración
v
Pruebas De Validación
v
Pruebas De Sistema
Prueba de caja blanca:
Las pruebas de
caja blanca (también conocidas como pruebas de caja de cristal o pruebas
estructurales)
Se centran en
los detalles procedimentales del software, por lo que su diseño está
fuertemente ligado al código fuente. El testeador escoge distintos valores de
entrada para examinar cada uno de los posibles flujos de ejecución del programa
y cerciorarse de que se devuelven los valores de salida adecuados.
Las principales
técnicas de diseño de pruebas de caja blanca son:
•
Pruebas de flujo de control
•
Pruebas de flujo de datos
•
Pruebas de bifurcación (branch testing)
•
Pruebas de caminos básicos
Pruebas de la caja negra:
Las pruebas de
caja negra ejercitan los requisitos funcionales desde el exterior del módulo.
En otras palabras, de una caja negra nos interesará su forma de interactuar con
el medio que le rodea entendiendo qué es lo que hace, pero sin dar importancia
a cómo lo hace. Por tanto, de una caja negra deben estar muy bien definidas sus
entradas y salidas, es decir, su interfaz; en cambio, no se precisa definir ni
conocer los detalles internos de su funcionamiento.
21.
Explique
los métodos de pruebas orientados a objetos
Prueba de Unidad
El
encapsulamiento dirige la definición de clases y objetos. Esto significa que
cada clase e instancia de clase (objeto) empaqueta los atributos (datos) y las
operaciones (también conocidas como métodos o servicios) que manipulan estos
datos. Por lo tanto, en vez de módulos individuales, la menor unidad a probar
es la clase u objeto encapsulado. Una clase puede contener un cierto número de
operaciones, y una operación particular puede existir como parte de un número
de clases diferentes. Por tanto, el significado de prueba de unidad cambia
ampliamente frente al concepto general visto antes.
Prueba de Integración
no tiene una
estructura de control jerárquica, las estrategias convencionales de integración
ascendente y descendente poseen un significado poco relevante en este contexto.
Generalmente se pueden encontrar dos estrategias diferentes de pruebas de
integración en sistemas. La primera, prueba basada en hilos (o threads),
integra el conjunto de clases necesario para responder a una entrada o evento
del sistema. Cada hilo se integra y prueba individualmente. El segundo enfoque
para la integración, prueba basada en el uso.
Concretamente,
se pueden realizar los siguientes pasos para generar casos de prueba a partir
de un diagrama de secuencias:
1.
Definir el conjunto de secuencias de mensajes a
partir del diagrama de secuencia. Cada secuencia ha de comenzar con un mensaje
m sin predecesor (habitualmente, un mensaje enviado al sistema por un actor), y
estará formada por el conjunto de mensajes cuya ejecución dispara m.
2.
Analizar sub-secuencias de mensajes a partir de
posibles caminos condicionales en los diagramas de secuencia.
3.
Identificar los casos de prueba que se han de
introducir al sistema para que se ejecuten las secuencias de mensajes
anteriores, en función de los métodos y las clases afectadas por la secuencia.
Prueba de Sistema
En el nivel de
prueba del sistema, los detalles de las conexiones entre clases no afectan. El
software debe integrarse con los componentes hardware correspondientes y se ha
de comprobar el funcionamiento del sistema completo acorde a los requisitos.
Como en el caso del software convencional, la validación del software se centra
en las acciones visibles del usuario y las salidas del sistema reconocibles por
éste. Para asistir en la determinación de casos de prueba de sistema, el
ejecutor de la prueba debe basarse en los casos de uso que forman parte del
modelo de análisis.
Prueba de Aceptación
La prueba de
aceptación en un sistema es semejante a la prueba de aceptación en un software
tradicional. El motivo es que el objetivo de este tipo de prueba es comprobar
si el cliente está satisfecho con el producto desarrollado y si este producto
cumple con sus expectativas, en términos de los errores que genera y de la
funcionalidad que suministra. Al igual que las pruebas convencionales serán los
clientes quienes realicen estas pruebas y suministren los casos de prueba
correspondientes.
