2013A TPSW Clase11 PruebasNoFuncionales-ParteI V2

CLASE # 11

PRUEBAS NO

FUNCIONALES

PARTE I

750105M - TÉCNICAS DE PRUEBAS DE SOFTWARE

INGENIERÍA DE SISTEMAS Y COMPUTACIÓN

UNIVERSIDAD DEL VALLE

SEMESTRE 2013A - DOCENTE BEATRIZ FLORIAN GAVIRIA

AGENDA

Introducción a las pruebas no funcionales

Escenarios de pruebas no funcionales

• Probar la seguridad de un sistema

• Probar un repositorio centralizado de datos (data warehouse)

• Probar sistemas Web

Un proceso de pruebas no funcionales genérico

Práctica

2013 – EISC - TECNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 2

INTRODUCCIÓN A

LAS PRUEBAS NO

FUNCIONALES

CONCEPTOS Y TAXONOMÍAS

3 2013 – EISC - TECNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA

PRUEBAS NO FUNCIONALES

• Verificación de los requisitos no funcionales de

una aplicación. Es decir, todos los requisitos

que ni describen información a manejar, ni

funciones a realizar

• Verifican atributo de calidad con los que se

juzga la operación de un sistema

• Son comúnmente confundidas y sus alcances

tienden a sobreponerse.

• Permiten determinar la conformidad del sistema

bajo ciertas condiciones de uso.

• Permiten detectar problemas de

comportamiento del producto simulando

condiciones reales de funcionamiento.

• Las simulaciones se hacen con herramientas

automáticas.




Pruebas de aceptación

Usabilidad, accesibilidad,

etc.

Pruebas unitarias

Carga, Seguridad,

etc.

Negocio

Tecnología

Calidad del

Producto Programación

Categorías de Brian Marick

Generalmente manuales

Generalmente automáticas PRUEBAS NO FUNCIONALES


CASOS DE USO

FUNCIONALES

Comportamiento esperado

Salida normal y manejo de

excepciones

Requerimientos funcionales

CASOS DE ABUSOS NO

FUNCIONALES

Comportamientos por fuera de lo esperado

• Agentes maliciosos

• Leyes de Murphy

Programación defensiva

• Los desarrolladores deben pensar maliciosamente

• Los desarrolladores deben prepararse para los más exigentes escenarios

Requerimientos no funcionales


TAXONOMÍA (1) DE PRUEBAS NO FUNCIONALES


Pruebas

No Funcionales

Seguridad

Robustez

Interoperabilidad

Rendimiento o Desempeño

Escalabilidad

Estrés

Carga y estabilidad

Concurrencia

Confiabilidad

Confidencialidad

Usabilidad

Documentación (estáticas)

Regulatorias

Adaptado de

SOFTWARE TESTING

AND QUALITY

ASSURANCE

Theory and Practice

KSHIRASAGAR NAIK

PRIYADARSHI TRIPATHY

A JOHNWILEY & SONS, INC.

TAXONOMÍA (2) DE PRUEBAS NO FUNCIONALES


Pruebas

No Funcionales

Seguridad

Confidencialidad

Integridad

Autenticación

Autorización

Disponibilidad

Negación de culpa

Robustez

Interoperabilidad

Rendimiento o Desempeño

Confiabilidad

Estrés

Carga y estabilidad

Concurrencia

Resistencia (SOAK)

Prueba de Picos

Escalabilidad

Usabilidad

Documentación (estáticas)

Regulatorias

OTRAS TAXONOMÍAS Y SU EXPERIENCIA

• Modelos de calidad de software

• Recuerda alguno?

• Recuerda algún requerimiento no funcional que no se haya mencionado?

• Suele hacer pruebas no funcionales de sus aplicativos?

• Por qué?

• Cuáles le parecen importantes, cuáles no?

• Conoce herramientas automáticas para esta tarea?


PRUEBAS DE RENDIMIENTO

Es medir la utilización

de recursos del

sistema, identificando el

comportamiento de la

instrumentación tanto

de software como de

hardware en tiempo de

ejecución dentro del

contexto de un sistema

integrado.


PRUEBAS DE DESEMPEÑO

Permiten evaluar la conformidad de un sistema o componente con “requerimientos de desempeño específicos”.

Las pruebas de desempeño miden:

• Tiempos de respuesta

• Índices de procesamiento de transacciones

• Otros requisitos sensibles al tiempo.


PRUEBAS DE CONCURRENCIA

• Pruebas multiusuario

• Encaminada a determinar los efectos de acceder el mismo código de aplicación, modulo o registros de una base de datos por más de un usuario a la vez.

• Identifica y mide el nivel de bloqueo (locking),

Bloqueo mutuo entre usuarios (deadlocking),

Uso de hilos simples (single-threaded) y

Semáforos de bloqueo (locking-semaphores)


PRUEBAS DE VOLUMEN

Enfocadas a detectar los datos (como por ejemplo logs, archivos de datos, etc.), que en cierto plazo causarán que el sistema deje de trabajar o degrade su operación en alguna forma; de manera que se puedan tomar acciones para prevenirlo.


PRUEBAS DE RESISTENCIA (STRESS)

Están diseñadas para

enfrentar a los sistemas

con situaciones que

demanden recursos en

cantidad, frecuencia o

volúmenes anormales.

Se identifican los límites

en los que falla el

sistema.


ESCENARIOS DE

PRUEBAS NO

FUNCIONALES

PENSANDO COMO UN PROFESIONAL


Adaptado de: Effective Methods for Software Testing. William E. Perry. Published by Wiley Publishing, Inc.

ESCENARIO 1

PRUEBAS DE SEGURIDAD

• Determinar el nivel de

seguridad del sistema y

medir las mejoras.

• Verificar los mecanismos de

protección del sistema

contra accesos impropios.

• El riesgo puede ser interno

(empleados) o externo

(líneas de comunicación,

procesamiento en línea,

etc.)


ESCENARIO 1

PRUEBAS DE SEGURIDAD

Proceso costoso y complejo.

• Se buscan patrones para el diseño de casos de prueba (simulación de problemas de seguridad conocidos en sistemas similares)

• Se buscan los puntos con mayor riesgo de penetración


ESCENARIO 1

PRUEBAS DE SEGURIDAD - REQUISITOS

Conocimiento del sistema y sobre seguridad

• Redes de comunicación en uso

• Quien tiene acceso a estas redes

• Datos o procesos que requieren protección

• Valor de la información o procesos que requieren protección

• Flujo del proceso o datos en el sistema

• Sistemas de seguridad y conceptos

• Métodos de penetración de seguridad


ESCENARIO 1

PRUEBAS DE SEGURIDAD - EL PROCESO


ESCENARIO 1


Tarea 1: Crear una línea base

• Contestar las sig. Preguntas

• Que se está haciendo a cerca de la seguridad?

• Qué tan efectivo es nuestro programa de seguridad computacional?

• Tener en cuenta

• Proceso

Políticas, métodos, procedimientos, herramientas y técnicas

• Actos (Hechos)

Intentos y actos de penetración en el sistema, actitudes de las personas

• Procedimiento

1. Establecer el equipo.

2. Establecer los requisitos y objetivos de referencia.

3. Diseño de métodos de recopilación de datos de referencia.

4. Capacitar a los participantes iniciales.

5. Recopilar datos de referencia.

6. Analizar e informar sobre el estado de seguridad informática.


ESCENARIO 1


Tarea 1: Crear una línea base - Requerimientos de seguridad


ESCENARIO 1


Tarea 1: Crear una línea base - Recolección de datos de hechos


ESCENARIO 1


Tarea 1: Crear una línea base - Recolección de datos actitudinales


ESCENARIO 1


Tarea 1: Crear una línea base - Reporte de análisis de la línea base de

seguridad informática


ESCENARIO 1


Tarea 2: Construir una matriz de puntos de penetración


ESCENARIO 1


Tarea 2: Construir una matriz de puntos de penetración


ESCENARIO 1


Tarea 3: Análisis de resultados

• Existen controles

adecuados en los puntos de

mayor probabilidad de

penetración

• Fortalezas y debilidades

• Riesgos no controlados

• Puntos de penetración no

controlados


ESCENARIO 1

PRUEBAS DE SEGURIDAD - PRUEBAS ESPECÍFICAS DE SEGURIDAD


Pruebas

No Funcionales Seguridad

Confidencialidad

Integridad

Autenticación

Autorización

Disponibilidad

Negación de culpa

ESCENARIO 2

PROBAR UN DATA WAREHOUSE

• Un data warehouse es un repositorio central de datos

disponible para los usuarios.

• Ventaja: Procesamiento de datos más fácil

• Desventajas: seguridad, accesibilidad e integridad.


ESCENARIO 2

PROBAR UN DATA WAREHOUSE - PREOCUPACIONES

• Inadecuada asignación de responsabilidades.

Datos inexactos o incompletos en un almacén de datos. Problemas de integridad

• La pérdida de una actualización de un único elemento de datos. Concurrencia no

sincronizada

• Auditoría inadecuada para reconstruir transacciones.

• El acceso no autorizado a los datos en un almacén de datos.

• Nivel de servicio inadecuado.

• Colocación de datos en el período calendario equivocado.

• La falta de software de almacenamiento de datos para funcionar como se especifica.

• El uso inadecuado de los datos.

• La falta de revisores de almacenamiento de datos independientes calificados.

• Documentación inadecuada.

• Pérdida de la continuidad del tratamiento. Dependencia del data warehouse

• La falta de criterios para evaluar.

• La falta de apoyo a la gestión.


ESCENARIO 2

PROBAR UN DATA WAREHOUSE - PROCESO


ESCENARIO 2



ESCENARIO 2



ESCENARIO 2



ESCENARIO 3

PROBAR SISTEMAS WEB - PREOCUPACIONES

• Compatibilidad de navegadores y versiones

• Integración: sistema distribuidos (clientes y

servidores), sistemas multicapas

• Usabilidad

• Seguridad: muchas formas de ataques

• Desempeño bajo carga

• Validación de estándares Web


ESCENARIO 3

PROBAR SISTEMAS WEB - PROCESO


ESCENARIO 3

PROBAR SISTEMAS WEB - RIESGOS

• Compatibilidad de navegadores

Recarga, impresión, navegación, gráficos, cache.

• Seguridad: aplicación y datos

Intrusión externa, transacciones seguras, control de acceso, virus, niveles de autorización

• Desempeño: rápido Concurrencia, estrés,

rendimiento

• Disponibilidad

• Integridad de datos

• Usabilidad Fácil de usar y

entender, navegación fácil y correcta, interpretación y uso de informaición

• Recuperación Pérdida de conexión,

caida de líneas, clientes que se caen, servidores que se caen, aplicaciones que se caen.


ESCENARIO 3

PROBAR SISTEMAS WEB – RIESGOS, HERRAMIENTAS Y GUÍAS

• Herramientas

• HTML

• Validador de Navegación

• Carga/stress

• Simuladores de transacciones

• Guías

• Ser razonable

• Herramientas automáticas

• ´Pruebe todas las esquinas


ESCENARIO 3

PROBAR SISTEMAS WEB – TIPOS DE TEST A DESARROLLAR


ESCENARIO 3

PROBAR SISTEMAS WEB – HERRAMIENTAS DE PRUEBAS


ESCENARIO 3

PROBAR SISTEMAS WEB – CHEQUEO ANTES DE LAS PRUEBAS


UN PROCESO DE

PRUEBAS NO

FUNCIONALES

GENÉRICO

METODOLOGÍA GENÉRICA


Sección basada en material de la empresa GreenSQA S.A



ANÁLISIS


ANÁLISIS


2

4

3

1

Entradas Actividad Salidas Responsable

1. Reunión inicial.

2. Presentación del producto.

3. Entrega de la documentación del producto.

Documentación del producto. Cliente

4. Definición del alcance de pruebas. LC-Análisis PNF-Producto-v1.0 GreenSQA

5. Entrega de la Ficha Técnica para su diligenciamiento.

FT-Producto-v.1.0 Cliente

Resumen Recolección de la Información

5

ANÁLISIS

Definición del alcance de pruebas

• Tipo de pruebas (concurrencia, stress, volumen, rendimiento, etc.).

• Procesos candidatos para la ejecución de las pruebas.

• Valores esperados, es decir límites como la cantidad de usuarios

concurrentes.

• Tipo de herramientas a utilizar (gratuitas o licenciadas).

• Permisos de acceso.


ANÁLISIS

Procesos Críticos:

• Volumen de datos.

• Usuarios concurrentes.

• Probabilidad de falla.

• Accesos continuos a la base de datos.

• Core del negocio.

• Cálculos.

• Reportes.

• Interacción.

• Procedimiento.

• Automático.

• Navegadores.


ANÁLISIS


Tipo de Prueba Variables Entrada Variables Resultado

No. Usuarios Tiempo promedio de respuesta

Peso promedio de archivo % de error

Tiempo de ejecución Desviación estándar

Conexión (externa e interna)

Nivel



Conexión (externa e interna) Desviación estándar

Nivel



Tamaño de datos Desviación estándar


Nivel

No. Usuarios Contadores de procesador

Peso promedio de archivo Contadores de memoria

Tiempo de ejecución Contadores de disco duro

Tamaño de datos Contadores de red


Nivel



Nivel Desviación estándar

Concurrencia

Desempeño

Volumen

Rendimiento

Stress

GUÍA

Variables

ANÁLISIS


Herramienta Licencia Tipo de Aplicaciones Tipo Pruebas Plataforma Observación

Jmeter No

1-Servicios.

2-Base de datos.

3-Web.

Concurrencia.

Rendimiento.

Resistencia.

Volumen.

Desempeño.

Widows.

Linux.

MAC OS.

Solaris.

Idea para las pruebas a servicios. Cuando se deben

probar aplicaciones Web es recomendable usar el

BadBoy.

BadBoy No

1-Web. Concurrencia.

Rendimiento.

Resistencia.

Volumen.

Desempeño.

Windows. Se utiliza para la grabación de los scripts de Jmeter,

pero también se puede utilizar como herramienta

de ejecución de pruebas no funcionales, pero el

informe de resultados es insuficiente.

Visual

Studio Team

Systema

2010

Sí

1-Web.

2-Servicios.

3-Escritorio.

Concurrencia.

Rendimiento.

Resistencia.

Volumen.

Desempeño.

Windows.

Linux con

Gambas.

Ideal para probar aplicaciones Web y entrega de

informe de ejecución completo. Cuando se van a

realizar pruebas a una aplicación de escritorio es

necesario que se desarrolle un robot para su

ejecución (apoyo del equipo de desarrollo).

Sikuli No

1-Escritorio.

2-Web.

Automatización. Windows.

Linux.

MAC OS.

Debian.

Ideal para la automatización de pruebas. Trabaja

mediante la captura de imágenes y permite

ejecución en tiempo real.

GUÍA

Selección de Herramienta de Pruebas

DISEÑO


DISEÑO


DISEÑO

Variables de Evaluación:

• Tiempo de respuesta: Tiempo en que la aplicación brinda una respuesta a un

usuario.

• Porcentaje de error: Se traduce como el porcentaje de negación de peticiones.

• Validaciones funcionales: Se puede presentar el caso de que se requieran

realizar validaciones funcionales, como en el caso de las pruebas de volumen

para mirar la cantidad registros procesados.


EJECUCIÓN


EJECUCIÓN


EJECUCIÓN

Recolección de Resultados

Análisis e Interpolación de resultados


PRÁCTICA

PENSANDO PROFESIONALMENTE PARA SU PROYECTO


PRÁCTICA

(A ENTREGAR CON LA SUSTENTACIÓN DEL PROYECTO)

• Pensando en su proyecto de curso analice los puntos de penetración de seguridad y realice las pruebas de seguridad necesarias.

• Pensando en su proyecto de curso, determine las pruebas para el sistema de almacenamiento de datos centralizado.

• Pensando en su proyecto de curso, defina un escenario y proceso de prueba para características de rendimiento.

• Adicional a las pruebas anteriores, pensando en su proyecto de curso, el cual es un sistema Web, realice las pruebas no funcionales que puedan faltar para él.

• No olvide identificar y usar las herramientas automáticas que le permitan apoyar los procesos de escenarios de pruebas no funcionales anteriores (Seguridad, Data Warehouse, Rendimiento y Web).


Documents

2013A TPSW Clase11 PruebasNoFuncionales-ParteI V2