mti calidad de software trabajo grupal_lg_lg_mfv

Calidad de Software MTI-2013 Pgina 1

CALIDAD DE SOFTWARE - TRABAJO GRUPAL

Alumnos:

Mauricio Figueroa / Luis Gatica / Luis Guzmn

Universidad Tcnica Federico Santa Mara

MTI-2013

04 de mayo de 2013


Parte I (65 pts.) Considere las siguientes especificaciones y utilice la estrategia caja negra (es decir, clases de equivalencia; valores frontera; adivinanza de errores) para derivar un conjunto apropiado de casos de prueba. Indique cualquier supuesto que haga.

1. Suponga que queremos probar un sistema de monitoreo del nivel del agua de una represa que le informa a una agencia involucrada en control de inundaciones. La definicin de requerimientos para una de las funciones del sistema dice lo siguiente: el sistema enva un mensaje al operador de la represa respecto a la seguridad del nivel del lago. A esta definicin de requerimiento le corresponde el siguiente diseo: Input: la sintaxis de la funcin es NIVEL(A,B), donde es A es la altura en metros del agua tras la represa, y B es el nmero de centmetros de lluvia de las ltimas 24 horas. Procesamiento: la funcin calcula si el nivel del agua est dentro de un rango seguro, o es muy bajo, o es muy alto. Output: La pantalla muestra uno de los siguientes mensajes: NIVEL = SEGURO cuando el resultado es seguro o bajo NIVEL = ALTO cuando el resultado es alto SINTAXIS INVLIDA dependiendo del resultado del clculo.

2. Al sistema se ingresan ciudades de origen y destino y fecha de viaje (suponga que el sistema ya cuenta con tablas de informacin indicando vuelos y asientos disponibles). Si no hay vuelo se imprime el mensaje 1 no hay vuelo; si hay vuelo pero no hay asientos se despliega el mensaje 2 copado; si hay vuelo con asientos disponibles se despliega la informacin del vuelo. Si las ciudades o fecha que se ingresa no es correcta se indica un mensaje de error.

3. Un usuario puede conectarse al banco por Internet y realizar una serie de operaciones bancarias. Una vez accedido al banco con las consiguientes medidas de seguridad (clave de acceso y dems), se requiere la siguiente entrada: Cdigo del banco. En blanco o nmero de tres dgitos. En este ltimo caso, el primero de los nmeros tiene que ser mayor que 1. Cdigo de sucursal. Un nmero de cuatro dgitos. El primero de ellos mayor de 0 Nmero de cuenta. Nmero de cinco dgitos Clave personal. Valor alfanumrico de cinco posiciones. Este valor se introducir segn la orden que se desee realizar Orden. Puede estar en blanco o ser una de las dos cadenas siguientes: Talonario


Movimientos En el primer caso el usuario recibir un talonario de cheques, mientras que en el segundo recibir los movimientos del mes en curso. Si este cdigo est en blanco, el usuario recibir los dos documentos.

Parte II (35 pts.)

Investigue sobre Web Testing y describa en no ms de 3 pginas conceptos fundamentales, estado del arte y de la prctica, herramientas disponibles, y principales desafos futuros desde la perspectiva de aseguramiento de calidad de software.


Desarrollo Parte I Ejercicio 1

Supuestos: Mxima altura de agua tras la represa en metros = 100

Mnima altura de agua tras la represa en metros = 0

Mximo nmero de centmetros de agua lluvia cados = 500

Mnimo nmero de centmetros de agua lluvia cados = 0

Funcin, suma la altura del agua con el agua lluvia cada.

Nivel Seguro = =100

Nivel Muy bajo= =0

Nivel muy alto= >301


Valor mayor a 99

Muy Alto Rango 301 hasta 600 Valor no numrico

Valor negativo

Valor menor a 301

Valor mayor a 600

Nivel Seguro Valor Seguro o Muy Bajo Valor numrico

Valor que no sea

Seguro o muy bajo

Nivel Alto Valor Muy Alto Valor numrico

Valor que no sea muy

alto

Prueba de valores frontera

Anlisis de valor frontera

Los errores generados por los programadores tienden a agruparse alrededor de las fronteras. Por

ejemplo, si un programa debera aceptar una secuencia de nmeros entre 1 y 10, el error ms

probable ser que los valores justo fuera del rango sean aceptados de forma incorrecta o que

los valores justo en los lmites del rango sean rechazados. El anlisis del valor frontera est

basado en probar los valores frontera de las particiones.

Al hacer comprobaciones de rango, probablemente se est usando de forma inconsciente el

anlisis del valor frontera. En esta tcnica, tambin, se cuenta con fronteras vlidas (en las

particiones vlidas) y fronteras no vlidas (en las particiones no vlidas).

Clase Valores frontera

A 0-100 1-101

B 0-500 1-501

Seguro 100-300 101-301

Muy bajo 0-100 1-101


Muy alto 301-600-302-601

Adivinanza de errores

Enfoque ad hoc basado en intuicin y experiencia, para identificar pruebas que probablemente expondrn defectos Idea bsica: lista de defectos posibles o situaciones propensas a error, desarrollo de pruebas basadas en la lista Historias de los defectos pueden ser muy tiles

Clase Adivinanza de error

A Negativo, nulo, Letras, decimales

B Negativo, nulo, Letras, decimales

Casos de prueba: Se escriben los casos de prueba tal que cubran la mayor cantidad de clases de Equivalencia vlidas. (Podra escribirse slo uno que cubriera todo todas las cev.) Se escribe un caso de prueba por cada clase de equivalencia invlido

N Caso

Clase de equivalencia

Altura

(A)

Lluvia

cada 24

hrs (B)

Nivel Seguro

Nivel Bajo

Nivel alto Resultado

1 0 0 X Nivel seguro

2 100 200 X Nivel seguro

3 99 400 X Nivel alto

4 Blanco 200 Sintaxis invlida

5 100 Blanco Sintaxis invlida

6 101 200 Sintaxis


invlida 7 100 501 Sintaxis

invlida 8 -100 400 Sintaxis

invlida 9 80 -200 Sintaxis

invlida

10 &/ 100 Sintaxis invlida

11 20 Hola Sintaxis invlida

12 30,5 100,40 X Nivel seguro

Ejercicio 2

Condicin de Entrada

Tipo Clase Equivalencia Vlida Clase Equivalencia No Vlida

Ciudad / Aeropuerto de origen

Valor 01: Ciudad / Aeropuerto validos como origen. 02: Asientos Disponibles (A320-A319 - B737)

03: En blanco 04: Ciudad / Aeropuerto origen igual a la ciudad de destino. 05: Ciudad / Aeropuerto no consideradas validas como origen.

Ciudad / Aeropuerto destino

Valor 06: Ciudad / Aeropuerto validos como destino.

07: En blanco 08: Ciudad / Aeropuerto de destino igual a la ciudad de origen. 9: Ciudad / Aeropuerto de destino no validas como destino.

Fecha de salidas de vuelos

Valor 10: Fecha validas

considerando fechas

especiales.

11: En blanco 12: Formato fecha no valida 13: Fecha de vuelo no valida. 14: fecha fuera de programa.


Casos de prueba de ciudades o fecha que se ingresa no sean correctas, rutas vlidas y disponibilidad de asientos, donde se indica un mensaje para cada caso.

Ciudades disponibles

Antofagasta

Concepcin

La Serena

Pueto Montt

Punta Arenas

Santigo

Valdivia

Anlisis de valor frontera

Clase Valores frontera

Caso Clase de Equivalencia

Ciudad Origen Asientos Aeropuerto

Ciudad Destino

Aeropuerto Fecha Mensaje

1 01;06;13 Santiago - Arturo Merino Bentez

Concepcin Carrier sur 29-02-2013 Fecha no valida

2 04;08 Punta Arenas - Carlos Ibaez Punta Arenas

Carlos Ibaez 01-09-2013 La Ciudad de Origen y destino iguales


Valdivia Pinchay "" Fecha en Blanco

5 01,06,12 La Serena - La Florida La Serena La Florida 06-31-2012 Fecha de formato no valido


"" 23-07-2013 Ciudad destino incorrecto

7 03;06;10 "" - Punta Arenas

Carlos Ibaez 15-08-2013 Ciudad de origen no corresponde

8 02;06;10 Santiago Copado Arturo Merino Bentez

Punta Arenas

Carlos Ibaez 20-07-2013 2 Copado

9 01;06;10 Punta Arenas Disponible Carlos Ibaez Santiago Arturo Merino Bentez

21-07-2013 Informacin del vuelo

10 01;06;10 Santiago Disponible Arturo Merino Bentez

Concepcin Carrier sur 22-07-2013 Informacin del vuelo

11 02;06;10 Concepcin Copado Carrier sur Santiago Arturo Merino Bentez

23-07-2013 2 Copado

12 02;06;10 Santiago Copado Arturo Merino Bentez

Pueto Montt

El Tepual 24-07-2013 2 Copado

13 01;06;10 Pueto Montt Disponible El Tepual Santiago Arturo Merino Bentez

25-07-2013 Informacin del vuelo

14 05;09 Santiago - Arturo Merino Bentez

Temuco Maquehue - No hay vuelos - ruta no existe

15 01;06;10;14 Pueto Montt Disponible El Tepual Santiago Arturo Merino Bentez

20-06-2016 No hay vuelos programados


Capacidad de asientos A737 120 aisentos; B319 156 asientos B320 -168 asientos

Fechas programada Mximo 12 meses

Adivinanza de errores

Clase Adivinanza de error Ciudad origen destino No deben ser iguales

Ciudades dentro de la rutas Vuelos en ciudades de los viajes ofrecidos

Formato Fechas Formato dd/mm/aaaa

Fecha especiales Aos bisiestos

Ejercicio 3

Para este ejercicio se han definido las siguientes clases de equivalencia, cada clase ha sido numerada para facilitar despus la realizacin de los casos de prueba.

Condicin de Entrada

Tipo Clase Equivalencia Vlida Clase Equivalencia No Vlida

Cdigo banco Lgica (puede estar o no) Si est, es Rango

1: En blanco 2: 100


prueba. Este es el caso por ejemplo, de la clases de equivalencia 2 y 6 que representan un rango de valores y para los que la tcnica de Anlisis de Valores Lmite indica que se generen dos casos de prueba con el lmite inferior y el superior del rango respectivamente (para identificar estos casos de prueba se ha aadido el sufijo a y b a las clases de equivalencia correspondientes). Los casos de prueba resultantes se muestran a continuacin: N Caso Clase de

equivalencia Banco Sucursal Cuenta Clave Orden Resultado

1 1, 6a, 9a, 2a, 15

- 1000 00000 00000 Todos los movimientos y talonarios.

2 2a, 6b, 9b, 12b, 16

100 9999 99999 zzzzz Talonario Envo de talonario.

3 2b, 6, 9, 12, 17

999 1001 12345 Hyu56 Movimientos Envo de movimientos

4 3, 6, 9, 12, 15 30A 1989 12347 Kuh98 Cdigo banco errneo

5 4, 6, 9, 12, 15 99 1989 12347 Kuh98 Cdigo banco errneo

6 5, 6, 9, 12, 15 1000 1989 12347 Kuh98 Cdigo banco errneo

7 1, 7, 9, 12, 15 - 999 12347 Kuh98 Cdigo sucursal errneo

8 1, 8, 9, 12, 16 - 10000 12345 Hyu56 Talonario Cdigo sucursal errneo

9 1, 6, 10, 12, 16

- 2345 9999 Jkgy5 Talonario Nmero cuenta errneo

10 1, 6, 11, 12, 16

- 7863 100000 Jut8 Talonario Nmero cuenta errneo

11 1, 6, 9, 13, 16 - 6754 89765 Jut890 Talonario Clave errnea

12 1, 6, 9, 14, 16 - 9998 89765 hy78 Talonario Clave errnea

13 1, 6, 9, 12, 18 - 8765 89765 Ghy78 988 Orden errnea

14 1, 6, 9, 12, 19 - 7654 89765 Ghy78 Talonarios Orden errnea

15 1, 6, 9, 12, 20 - 8769 89765 Ghy78 Movimiento Orden errnea


Desarrollo Parte II Web Testing

Para contextualizar debemos indicar que en estos momentos hay miles de sitios web en marcha y

en desarrollo todos los aos, por lo cual resulta interesante clasificar en alguna estructura que

permite determinar que pruebas son aplicables. Thomas A. Powell, 1988, propuso la siguiente

clasificacin basada en el tipo de interaccin usuario-sistema ([RYD00]):

1. Sitios Web Estticos: Corresponde al tipo ms simple de sitio web, esto es, un documento HTML sin dinamismo donde la nica opcin de pgina es efectuando clicks. 2. Sitios Web Estticos con Formularios: Formularios son utilizados para recopilar informacin del usuario, por ende, est orientado a mecanismos de recoleccin de informacin. 3. Sitios Web con Acceso Dinmico de Datos: Se utiliza el sitio web simplemente como un front-end de datos, los cuales estn almacenados en un repositorio externo. Los resultados son archivos HTML generados por algn motor especfico. 4. Sitio Web Dinmicamente Generado: La interfaz grfica, y cada una de las pginas retornadas por el servidor son generadas dinmicamente. Esto es, no se retorna un archivo sino que un simple flujo de cdigo interpretable por el navegador. 5. Aplicaciones de Software Web: Conjunto de funcionalidad y componentes que utilizan ambientes web (mediante mtodos estndar) como medio de difusin.

Estos sitios o aplicaciones web deben evitar un mal funcionamiento, por lo cual existen algunas

medidas de calidad que deben ser usadas con el fin de entregar un experiencia satisfactoria a los

usuarios:

1. Puntualidad - pginas web tienen que ser actualizadas constantemente. Cundo fue la

ltima vez de actualizacin? Cun consistente es la noticia o informacin de hoy en da?

2. Calidad estructural - Todas las partes de la web tienen que estar funcionando bien. Son

todos los enlaces (dentro o fuera) de trabajo? Se estn cargando todas las imgenes?

3. Contenido - Esto no chequeando solo demuestra despreocupacin en la coherencia de

los contenidos con todas las otras pginas, o bien con la solicitud del usuario,

especialmente con las pginas web dinmicas. El contenido de las pginas crticos

coincidir con lo que se supone que es all?


4. La precisin y la consistencia - Las pginas es coherente con lo que el usuario solicito?

Cun consistente es la pgina web con la pgina web de ayer?

5. Tiempo de respuesta y latencia - Esto es lo ms esencial ya que el tiempo de respuesta

del servidor debe ser rpido despus de hacer clic en Enviar. El Servidor web responde a

una peticin del navegador dentro de ciertos resultados parmetros? Hay partes de un

sitio que son tan lentos los interrumpe usuario trabajo?

6. Performance - Se trata de rendimiento de carga o uso. La pgina web carga en menos de

ocho segundos? Puede su sistema de manejar 10.000 transacciones por minuto?

Como se puede apreciar, crear un sitio o aplicacin web no termina al finalizar el desarrollo y

puesta en produccin, este debe ser probado y revisado, para asegurar la calidad antes de

enviarlo a la World Wide Web y evitar problemas derivados de la incompatibilidad por el uso de

mltiples navegadores, tiempo de descarga de los grficos, componentes de Flash, o medios de

transmisin, requisitos de hardware, requisitos de tamao de la memoria, velocidad de conexin

del usuario, la carga por el nmero de usuarios, vnculos rotos, faltas de grficos, comandos mal

escritos, etc., lo cual busca como objetivo revisar todos los aspectos que aseguren al usuario la

mejor experiencia posible y evitar todo defecto que pueda crear una mala impresin, obteniendo

como resultado que el usuario no visite o ingrese nunca ms.

Debido a lo anterior Web testing es el nombre para las pruebas de software de aplicaciones o

sitios web, y que de forma automatizada abordan de forma completa aspectos como Seguridad,

Funcionalidades Bsicas, Accesibilidad (Usuarios capacitados y discapacitados), Cantidad de

Usuarios, Aumento Masivo de Usuarios, Optimizacin, Repercusin Social, otros., que permitan

comprobar la verdadera calidad del sitio o aplicacin web.

De acuerdo a lo investigado el proceso de testing debe tener en consideracin ciertos aspectos como:

1. Reunir el equipo de testing. 2. Preparar documentacin que incluya: requerimientos que fueron aceptados por el cliente y el equipo de testing, el completo diseo funcional y especificaciones internas del diseo. 3. Creacin de un plan de proyecto, con la identificacin de los aspectos de alto riesgo. 4. Diseo del mbito del testing, en el cual se determina los tiempos para cada fase as como una priorizacin de los elementos a ser probados. 5. Verificar el ambiente de testing: hardware y software. 6. Crear test scripts. 7. Desarrollar un mtodo para el seguimiento de un problema. 8. Decidir el nmero de iteraciones a realizar.


9. Establecimiento de requerimientos de negocio, que ayudarn a entender la funcionalidad de la aplicacin Web.

Este tipo de testing se realiza se desarrolla en forma paralela al ciclo de desarrollo, ya que en cada una de las

etapas se debe realizar alguna prueba, como lo muestra la siguiente tabla:

Para apoyar las pruebas de aplicaciones y sitios web existen herramientas de rendimiento de las

aplicaciones web (WAPT) que se utiliza para probar aspectos de funcionamiento, carga sitio web,

carga servidores web y otros interfaces web, simulando usuarios virtuales y el nmero de

iteraciones que estos tendrn que repetir, de esta manera la herramienta es til para comprobar si

hay fugas de cuello de botella y rendimiento, por lo que deben ser capaces de llevar a cabo

pruebas de:

Deteccin Errores de programacin.

Pruebas de Rendimiento.

Pruebas funcionales.


Compatibilidad del navegador.

Compatibilidad del sistema operativo.

Compatibilidad de aplicaciones de Windows en caso necesario.

Etc.

Algunas de estas herramientas son:

Cdigo Abierto:

Apache JMeter: programa Java para pruebas de carga y medicin del desempeo.

Curl-loader: Poderosa herramienta para pruebas de carga en diferentes escenarios.

Selenio: Conjunto de herramientas para la automatizacin de los navegadores web.

Disponible en varios idiomas.

Watir: Automatizacin de Pruebas Web en Ruby para la automatizacin de los

navegadores web.

Basados en Windows:

HP LoadRunner: Rendimiento automatizada y pruebas de carga fromHP software.

HP Quick Test Professional: Software automatizado para pruebas funcionales y

regresin.

IBM Rational Functional Tester

NeoLoad: Herramienta de pruebas de rendimiento de Neotys.

Ranorex: Software de pruebas funcionales automatizado de Ranorex.

Silk Performer: Herramienta de pruebas de rendimiento de Borland.

SilkTest: Herramienta de automatizacin para probar la funcionalidad de las aplicaciones

empresariales.

TestComplete: Herramienta de prueba automatizada, desarrollada por SmartBear

Software y que posee muchos tipos de pruebas, como por ejemplo: Unitarias, Funcionales,

Keyword-Driven, Caja Blanca, Data-Driven, Regresin, Distribucin, Paralelo, Cobertura,

Funcionales, Sistemas Operativos y Carga.

Testing Anywhere: Herramienta de prueba de automatizacin de todo tipo de pruebas

de Automation Anywhere.

TOSCA Testsuite: Herramienta de software para la realizacin de pruebas de software

funcionales y de regresin.

Basadas en la Nube:

Blitz: Herramienta para pruebas de carga y rendimiento de sitios web, aplicaciones web,

mviles y APIs REST.

mti calidad de software trabajo grupal_lg_lg_mfv

Documents