Verificación y validación

Question 1

Que preguntas ofrece la verficación?

Answer 1

❑¿Estamos construyendo el producto correctamente?
❑¿El software está de acuerdo con su especificación?

Question 2

Que preguntas ofrece la validación?

Answer 2

❑¿Estamos construyendo el producto correcto?
❑¿El software cumple con las expectativas del cliente?

Question 3

Objetivo de la validación y verificación?

Answer 3

V&V deberían establecer confianza que el software es adecuado para su
propósito. Debe ser suficientemente bueno para su uso previsto. El tipo de
uso determinará el grado de confianza que es necesario

Question 4

Relación entre error, defecto y Fallo

Answer 4

El error puede generar un defecto (implementación de ese error en el código) que puede generar un fallo (Manifestación del defecto al usar el sistema)

Question 5

Como son las V&V estática, dinámica y formal?

Answer 5

Estatica: ❑Análisis de la representación
estática del sistema para
descubrir defectos
(inspecciones)
* Puede ser complementado
por documentación basada en
herramientas y análisis de
código (manual o
automática)

Dinámica:
❑observar el
comportamiento del
producto (testing)
▪ El sistema es ejecutado con
datos de test y se observa su
comportamiento.

Formal: ❑métodos lógicomatemáticos (llamados
métodos formales) para
verificar (probar) la
correctitud del programa,
generalmente para
aplicaciones de misión
crítica

Question 6

¿Qué detecto si realizo una prueba estatica y/o dinamica?

Answer 6

Estática: ERRORES O DEFECTOS
Dinámica: FALLOS

Question 7

Cuales son los 7 principios del testing?

Answer 7

1. testeo exhaustivo
2. Defect Claustering
3. Paradoja del pesticida
4. Dependiente del contexto
5. Cuanto mas temprano mejor
6. Muestra la presencia de defectos
7. Ausencia de error es una falacia

Question 8

Que dice el Principio nro 1 – El testeo exhaustivo no es posible

Answer 8

Si tuviéramos que testear todas las combinaciones posible, la ejecución de las pruebas elevaría el costo y tiempo exponencialmente

Necesitamos un conjunto óptimo de tests basado en la evaluación de riesgo de
la aplicación.

Question 9

Que dice el Principio nro 2 – Defect Clustering,

Answer 9

Un nro. de
módulos contienen gran parte de los defectos.

Question 10

Que dice el Principio nro 3 – La Paradoja del pesticida.

Answer 10

Repetir
sistemáticamente los mismos test puede
eventualmente no encontrar más bugs.
Revisar periódicamente la efectividad de los test

Question 11

Que dice el Principio nro 4 –

Answer 11

El testing es dependiente del
contexto

Question 12

QUe dice el Principio nro 5

Answer 12

Cuanto mas temprano mejor. El error se
propaga por todo el ciclo de vida. El costo de corregirlo
aumenta a medida que avanza el proyecto

Question 13

Que dice el Principio nro 6 –

Answer 13

Los tests muestran la presencia, no la
ausencia de errorrs (ley de Dijkstra)

Question 14

Que dice el Principio nro 7 -

Answer 14

Ausencia de error es una falacia

Question 15

Que es el testing dinamico?

Answer 15

Testing implica ejecutar un programa, esto es
evaluar su comportamiento dinámico

❑Es necesario ejecutar el programa para
asegurarnos que todos los factores ambientales
que pueden influir en la ejecución son tenidos
en cuenta
❑Los programas pueden arrojar distintos
resultados dependiendo el estado del sistema

Question 16

Que es el testing Finito?

Answer 16

Aún los programas mas triviales tienen un
conjunto muy grande (“semi-infinito”) de posibles
entradas y ejecuciones
❑Idealmente se debería hacer un testing
exhaustivo (testear todas las posibles
ejecuciones; esto es esencialmente una prueba
de correctitud de fuerza bruta)
❑Esto claramente la mayoría de las veces no es
factible

Question 17

Que es el testing esperado?

Answer 17

Para evaluar el resultado de un test se debe saber
que se espera, es decir, cuando es “correcto”
❑Esto no es tan fácil como se supone, dado que
los requerimientos muchas veces no están
completamente especificados, por tanto no se
sabe cuales son los resultados esperados

Question 18

Inspeccionar o Testear, ¿qué va primero?

Answer 18

❑Es importante inspeccionar el software antes de testearlo
extensivamente
❑La razón es que la inspección permite encontrar rápidamente muchos
defectos
❑Si se testea primero y luego los inspectores recomiendan que es
necesario un rediseño, el trabajo de testing ha sido desperdiciado
❑Aún antes que el testing del desarrollador

Question 19

Cuales son los niveles de testing?

Answer 19

• Testing de Componentes
  (Unitario): Testing de los componentes individuales de un programa, lo cual puede incluir clases, métodos, funciones, etc.
• Testing de Integración: Es la fase del testeo del software en la cual los módulos de software individuales son
  combinados y testeados como grupo.
• Testing del Sistema: Testing de grupos de componentes ya integrados para crear un sistema o subsistema.

Question 20

Que es el modelo V?

Answer 20

El Modelo-V es una representación
gráfica del ciclo de vida del
desarrollo de sistemas.
Resume los pasos principales
conjuntamente con los entregables
correspondientes en un framework
de validación de sistemas
automatizados

Question 21

como es el modelo V?

Answer 21

https://drive.google.com/file/d/1Q2vLPg6PO1QVBT7HxU6FskqbBCFZIrtY/view?usp=sharing

Question 22

Diga caracteristicas de la Estrategia de integración: Big-Bang

Answer 22

❑ Poner juntas todas las unidades
❑ Confiar en los resultados de los test
unitarios
❑ (Relativamente) pocos test son
requeridos
❑ Muy difícil aislar errores

Question 23

Carcateristicas de la estrategia Testing de Integración Incremental

Answer 23

Para simplificar la localización de errores, el sistema
debería ser integrado incrementalmente

Question 24

Que es un driver y que es un stub?

Answer 24

Driver:
❑Es un componente, que llama al módulo a testear
❑Controla los casos de test

Stub:
❑ Un componente que dependen del módulo bajo test.
❑ Hace las llamadas como lo haría la unidad original a los niveles mas bajos
❑ Software Dummy
❑ Misma interfaz que el original
❑ Retorna resultados fingidos (fake)

Question 25

Menciona las tecnicas de testing:

Answer 25

**Técnicas de Caja Negra
**
Partición de Equivalencia ( Es las resultados de cada programa (positivos y negativos), la vision de los rangos posibles)
Análisis del Valor Límite
Tablas de decisión (tabla de true o false)
Transición de estados
Prueba de Casos de Uso (El caso de uso es la descripción de un uso particular del sistema iniciado por un actor
(usuario))

**Técnicas de Caja Blanca
**Basadas en el Flujo de Control
Basadas en el Flujo de los datos

Técnicas según quién hace la Prueba
Pruebas de Aceptación
Pruebas Alfa y Beta
Pruebas de usuario
Pruebas de pares

**Técnicas Basadas en la experiencia **
Prueba Ad hoc
Conjetura de errores
Testing Exploratorio

Question 26

CUantas coberturas hay?

Answer 26

Cobertura de Sentencia: Requiere que se ejecute por lo menos una vez cada sentencia del programa. Es un
criterio débil–No se comprueban ambas vertientes de las condiciones.

** Cobertura de Decisiones.**:
Casos de prueba como para que cada decisión tenga por lo menos un resultado
verdadero o falso. Este criterio es más fuerte, pero en sentencias condicionales
compuestas puede quedar enmascarada una de las condiciones.

Cobertura de Condiciones.:
Casos de prueba de modo que cada condición en una decisión tenga, al menos una
vez, todos los resultados posibles. Este criterio es más fuerte que el anterior.

COBERTURA MÚLTIPLE:
Requiera un número suficiente de casos de prueba tal que todas las combinaciones
posibles de resultados de condición en cada decisión y todos los puntos de entrada se
invoquen al menos una vez. Satisface los criterios de cobertura anteriormente citados.

Question 27

Que implica un test de HUmo o Sanidad?

Answer 27

❑ Implica chequear las funcionalidades críticas
del sistema, antes de que se proceda a
realizar otras pruebas más complejas.
❑ El test de sanity es superficial y no exhaustivo.
❑ El objetivo no es encontrar defectos sino
testear el comportamiento general del
sistema

Question 28

Cuales son las categorias en las pruebas de sistema?

Answer 28

Test Funcional: Basado en Req. Funcionales

Test de stress: Testea el comportameinto frente a falla.

Test de humo: Se verifican las funcionalidades criticas del sistema.

Test de desempeño: Basado en requerimientos no funcionales.

Question 29

Que es el testing de aceptación?

Answer 29

Se testea para ver si cumple las necesidades del
usuario. A veces realizado por el usuario
Test piloto: trabajando cada día
Alfa test: realizado por el cliente en el área
de desarrollo.
El informático toma nota de los errores y
problemas de uso
Beta test: realizado por el cliente, en su lugar
de trabajo. A diferencia de la prueba Alfa los
desarrolladores no se encuentran presentes.
El cliente es el que registra los errores

Question 30

QUe es el test de liberación?

Answer 30

❑ Posterior a la aceptación del Usuario
❑ Es el proceso de testear un release que va a ser
distribuido a los clientes
❑ El principal objetivo es incrementar la confianza que
el sistema cumpla además de cumplir con los
requerimientos y funcionará en el ambiente de
negocios existente:
❑ Afecta a otros sistema corriendo en el
hardware?
❑ Es compatible con otros sistemas?
❑ Tiene performance aceptable bajo carga?
❑ Las respuestas a estas pregunta podrían tener un
impacto financiero significativo, por ej. si nuevo
hardware debe ser adquirido, y afectar
adversamente el “Caso de Negocios

Question 31

Que queremos que revelen los test?

Answer 31

❑ Testing Funcional (o de conformidad)
¿El sistema cumple las especificaciones?
❑ Testing de Performance
¿El sistema funciona bien en todas los escenarios?
❑ Testing de Aceptación
¿El sistema satisface las necesidades de la organización y del
usuario?
❑ Testing de Instalación
¿El sistema funciona en su ambiente de trabajo? (una extensión
del testeo del sistema)
❑ Testing Alfa y Beta
Distribuir distribuciones prematuras interna y externamente

Question 32

Que es el testing de regresion?

Answer 32

Consiste en ejecutar todas las
pruebas de test, luego que se realiza un cambio para que no se vuelvan a introducir defectos. * Para evitar el ”efecto rizo”, el cual
consiste en que la corrección de un bug que introduce un nuevo bug.
* Ocurre cuando quien hace el cambio no entiende completamente las ramificaciones del mismo.

Question 33

QUe es la inspeccion de software?

Answer 33

Es una tecnica de evaluacion formal en el cualo los requerimientos de software, diseño, o código son examidados en detalle por un grupo de personas, distintas a los autores para detectar faltas, incumplimientos, de estandaress de desarrollo y otros problemas.