Prueba fallida:
Resultados no esperados
Prueba sin errores
martes, 6 de noviembre de 2012
martes, 23 de octubre de 2012
EVALUACIÓN DE PRUEBAS EQUIPO 7. INTEC
Debemos tomar en cuenta que cuando una prueba ya se
realizó –ya se obtuvieron resultados– eso no implica que ya concluyó, el ciclo
de vida de pruebas se concluye con la evaluación, en donde se especifica la
comparación entre los resultados esperados y los obtenidos con la prueba
determinando si ésta fue o no exitosa.
JMeter
Los reportes generados con JMeter nos proporcionan
información que podemos agrupar en tablas o cuadros comparativos o en un
resumen respecto a lo que arrojaron las pruebas efectuadas, indicando cuál fue
el objetivo.
Tipos
de resúmenes
JMeter proporciona un resumen de los reportes que se
generaron. Éstos pueden ser de tres tipos:
·
Un resumen de las pruebas realizadas.
·
Una estadística de cada llamada.
·
Todos los componentes que se llamaron.
Métricas
Se debe tener métricas de calidad establecidas para
calcular las cifras y hacer la comparación con los resultados arrojados por las
pruebas elaboradas con la herramienta.
·
Líneas de código. Número de líneas de código
del proyecto. Esta métrica sólo tiene en cuenta las líneas que corresponden al
código Java, no incluye comentarios, líneas en blanco o algo similar.
·
Clases. Número de clases del proyecto,
incluidas clases internas, interfaces, enumeraciones y anotaciones.
·
Métodos. Número de métodos, sin incluir get o
set. Los constructores se cuentan entre los métodos.
·
API público documentado. El número de clases,
métodos y atributos públicos con un bloque de Javadoc.
·
Complejidad ciclomática. Se suma los 'if',
'for', 'while' y sentencias de control; a cada una se le da el peso de “1”.
También cada método tiene un valor mínimo de “1”en el cálculo de la
complejidad, excepto los get y los set que no son considerados métodos.
·
Tamaño= n + a. Donde “n” es el número de
módulos y “a” es el número de líneas de control; esto es, si se tienen 17
módulos y 18 líneas de control entre éstas, el resultado es: tamaño = 17+18 =
35.
·
Profundidad. Es el camino más largo desde el
nodo raíz a un nodo hoja (siguiendo una integración descendente, primero en
profundidad).
·
Amplitud. Es el número máximo de nodos de
cualquier nivel de la arquitectura. Para el ejemplo de la imagen de módulos, la
amplitud es de 3.
CICLO DE PRUEBAS EQUIPO 6.
El ciclo de vida de la automatización comienza en la
etapa de diseño del modelo de desarrollo en cascada del software, para plantear
en principio los casos de prueba y elaborarlos en la herramienta
correspondiente, concluyendo en la etapa de mantenimiento del software, de
acuerdo a esta arquitectura, teniendo en consideración los requerimientos con
su respectiva gestión.
En cada desarrollo de software tenemos un ciclo de
pruebas y varios ciclos de vida de las pruebas, lo cual, normalmente, está
determinado por el modelo de desarrollo del software. En cada uno de estos
ciclos se tiene que planear, diseñar,
ejecutar las pruebas, obtener resultados y evaluar estos resultados.
Requerimientos
de Prueba
Los requerimientos de prueba del software son todos los
recursos que necesitamos para ejecutar una prueba. Para ello establecemos un
ambiente de pruebas, en el cual se considera: software, hardware,
configuración, personal y documentos.
De los requerimientos funcionales se desprende uno de los
documentos base para el buen desarrollo del sistema: el diagrama UML de Casos
de uso, con su respectiva especificación, donde podemos extraer las
precondiciones para establecer nuestras consideraciones para los valores de
entrada del caso de prueba.
Las pos condiciones que nos indican los resultados que se
deben esperar, los flujos básicos y alterno, de donde obtenemos nuestros
escenarios para los guiones de prueba.
Para manipular los escenarios podemos utilizar, en
JMeter, el “Controlador lógico”. Éste controla el comportamiento de la prueba
tomando decisiones en función de situaciones, por ejemplo, si se lleva a cabo
una petición HTTP con base en una condición. Este tipo de controlador trae
valores por default.
Administración
de Requerimientos
Para gestionar apropiadamente los requerimientos es
necesario controlar y da un seguimiento a las pruebas. Con JMeter se pueden
obtener distintos tipos de informes que de alguna manera nos permiten
administrar lo que se está llevando a cabo.
En los informes que configuremos evaluaremos los
resultados porque allí estarán reflejados, listos para ser analizados.
Tipos de informes:
·
Resultados Aserción
·
Resultados de Gráfico
·
Gráficos de Resultados
·
Mailer Visualizar
·
Resultados del Monitor
·
Escritor de Datos
·
Visualizador Spline
·
Informe Agregado
·
Ver los Resultados
·
Ver los Resultados en Árbol
CLIENTES DE PRUEBA EQUIPO 5.
El cliente de prueba deja a
los usuarios establecer parámetros de prueba , mandar la entrada al servicio y
observar la respuesta que este devuelve; provee un servicio de prueba sin
dificultades cuando se mezcla con el servidor que proporciona el trabajo que se
requiere.
Prueba
de carga
Esta es una de las pruebas que se puede realizar y donde
podemos simular la petición de 50 usuarios al servidor, esto se lleva a cabo
con una herramienta de software (JMeter)
Efectuar las pruebas en el entorno de desarrollo no es lo adecuado: se debe tener un ambiente propio donde se lleven a cabo todas las pruebas, separando el código producido del código a probar.
Efectuar las pruebas en el entorno de desarrollo no es lo adecuado: se debe tener un ambiente propio donde se lleven a cabo todas las pruebas, separando el código producido del código a probar.
Los problemas que se pueden presentar y para los cuales
se debe realizar las pruebas son los siguientes:
·
Interfaz grafica de usuario.
·
Entornos distintos atendiendo a las
plataformas usadas.
·
Procesamiento distribuido.
·
Base de datos distribuida.
·
Relaciones de rendimiento.
Un enfoque para probar el cliente consiste en tener la
aplicación cliente en el cliente de prueba y ejecutar la prueba en modo
desconectado del servidor.
Otro enfoque para la aplicación de pruebas a esta arquitectura es: probar en paralelo, en el
cliente de prueba y en el servidor de prueba, sin ejecutar operaciones de red,
probándose, de esta manera , la arquitectura completa debes tener en cuenta los
métodos que tienes disponibles en los usuarios del paquete.
Recordemos que el cliente es una interfaz de usuario
integrada por servicios, en las interfaces se prueban las interacciones entre
los objeto, su clasificación es la siguiente:
·
De parámetros
·
Proceduales
·
Que pasan mensajes
Errores más frecuentes de interfaz:
Abusos
de interfaces
Mal entendimiento de interfaces
Errores de tipo
Donde existen parámetros de tipo erróneo, en orden
incorrecto o con numero de parámetros erróneos
El comportamiento invocado no se comporta como se
esperaba.
En sistemas de tipo real en el que se usa memoria
compartida o una interfaz que pasa mensajes, la fuente de datos y el cliente de
datos operan a distintas velocidades.
Servidor
de pruebas
Uno de los elementos necesarios en la arquitectura
cliente-servidor, es el servidor. Para realizar las pruebas del lado del
servidor necesitamos crear un servidor de pruebas, el cual simulara el real.
La herramienta se llama WAMP, y nos crea y habilita un
servidor de pruebas, otra es XAMPP.
ARQUITECTURA DE SOFTWARE CLIENTE-SERVIDOR EQUIPO 4.
Pruebas cliente servidor
Las pruebas se deben
realizar al servidor, a la base de datos y a las comunicaciones. Las
herramientas que se utilicen deben tener la capacidad de medir, de aplicar
métricas y de obtener resultados observables permitiendo una comparación entre
versiones. Hay factores que se pueden medir dependiendo de la herramienta, como
el uso de memoria de la PC, latencia, carga de entrada-salida y conexiones
concurrentes.
En el servidor se comprueban
las funciones de coordinación y administración de datos, así como su desempeño
en cuanto a tiempo de respuesta y procesamiento completo de datos.
En la base de datos se
comprueban la exactitud e integridad de los mismos; se inspeccionan las
transacciones. También debemos cerciorarnos de que se guardan, modifica y
recuperan los datos.
En las pruebas de comunicación de red hay
que verificar la comunicación entre los nodos, el paso de mensajes,
transacciones y que el tráfico de la red se efectúe sin errores. “Para las
Comunicaciones, hay que incluir algunas cuestiones:
1. Elección de una distribución concreta de
Linux: Suse, RedHat, Mandrake, Debian.
2. Navegador, cliente de correo y
mensajería instantánea.
3. Autentificación y permisos sobre
recursos de red.
4. Antivirus, herramienta creadora de discos
maestros, gestión remota de equipos, actualización desatendida de los clientes.
5. Servidor de impresión, multimedia,
seguridad y software de emulación de Windows.
6. Pervivencia de equipos Windows en la red
Linux, si fuera necesario.”
En el plan de prueba se
requiere manejar la sesión de usuarios. Esto se logra a través del elemento:
HTTP URL Re-writing Modifier, para guardar los identificadores de sesión, este
componente se usa en aplicaciones web, en lugar de manejar cookies, con el
nombre de la ID, se puede hacer la búsqueda en la página e incluirla,
dependiendo de la ubicación, puede ser en el grupo de peticiones o en todas las
peticiones de su grupo de hilos. Este elemento esta optimizado para manejar las
sesiones de forma eficiente; es de fácil configuración y deja en términos más
sencillos el plan de pruebas.
HERRAMIENTAS DE VALIDACIÓN
Cuando se han elaborado pruebas, se ha
prestado atención a cinco áreas significativas (esto también lo observaste en
aplicaciones web); estas son:
1. “Herramientas de carga y rendimiento (Load
and Performance Test Tools)
2. Web Functional/Regression Test Tools (Java Test Tools)
3.
Autentificación y permisos sobre recursos de red.
4. Validadores de HTML (HTML Validators)
5. Comprobadores de Links (Link Checkers)
6. Herramientas de comprobación de
seguridad (Web Site Security Test Tools)"
¿QUÉ PERMITE LA VALIDACIÓN?
Corregir los datos (permite detectar los
valores incorrectos).
La
integridad de los datos.
El entendimiento compartido de los datos,
esto es, que la interpretación de la información sea la misma.
Suscribirse a:
Entradas (Atom)