†Ø Ð∂†∂ ک†Øяε

PLAN DE PRUEBAS

Prueba Funcional: Es una prueba basada en la ejecución, revisión y retroalimentación de las funcionalidades previamente diseñadas para el software. Las pruebas funcionales se hacen mediante el diseño de modelos de prueba que buscan evaluar cada una de las opciones con las que cuenta el paquete informático.

Pruebas de Rendimiento: Son las pruebas que se realizan para determinar lo rápido que se hace una tarea en un sistema de condiciones particulares de trabajo. También puede servir para validar y verificar otros atributos de la calidad del sistema, tales como la habilidad, fiabilidad y uso de los recursos.

Prueba Unitaria: Es una forma de probar el correcto funcionamiento de un módulo de código. Esto sirve para asegurar que cada uno de los módulos funcione correctamente por separado. Luego, con las Pruebas de Integración, se podrá asegurar el correcto funcionamiento del sistema o subsistema en cuestión.

Pruebas de Carga: Una prueba de carga se realiza generalmente para observar el comportamiento de una aplicación bajo una cantidad de peticiones esperada. Esta carga puede ser el número esperado de usuarios concurrentes utilizando la aplicación y que realizan un número específico de transacciones durante el tiempo que dura la carga. Esta prueba puede mostrar los tiempos de respuesta de todas las transacciones importantes de la aplicación.

Prueba de estrés: Esta prueba se utiliza normalmente para romper la aplicación. Se va doblando el número de usuarios que se agregan a la aplicación y se ejecuta una prueba de carga hasta que se rompe. Este tipo de prueba se realiza para determinar la solidez de la aplicación en los momentos de carga extrema y ayuda a los administradores para determinar si la aplicación rendirá lo suficiente en caso de que la carga real supere a la carga esperada.

Plan de Pruebas: Describe la estrategia, recursos y planificación de las pruebas. La estrategia incluye la definición del tipo de pruebas a realizar para cada iteración y sus objetivos, el nivel de cobertura de la prueba y el porcentaje de la misma que deberían ejecutarse con un resultado específico.

Documentos:

· Definición de los objetivos de las pruebas en el ámbito de la iteración.

· La definición de los elementos que se van a probar.

· Una explicación del enfoque o estrategia que se usará.

· Los recursos y planificación necesarios.

· Los resultados que se obtienen del proceso de prueba.

· Plan estratégico que se va seguir en las pruebas

ROLES

- Usuario

- Administrador de configuraciones

- Desarrollador

- Comité de control d cambios

Metodología de pruebas de rendimiento de aplicaciones Web: Consiste en las siguientes actividades:

• Actividad 1: Identificar el entorno físico de pruebas y el entorno de producción, así como las herramientas y recursos de que dispone el equipo de prueba, este incluye hardware, software y configuraciones de red. Tener un profundo conocimiento de todo el entorno de prueba desde el principio permite diseños más eficientes de pruebas y la planificación y ayuda a identificar problemas en las pruebas en fases tempranas del proyecto.
• Actividad 2: Identificar los criterios de aceptación de rendimiento, es decir, determinar el tiempo de respuesta (usuario), el rendimiento (negocio), la utilización de los recursos (sistema) y los objetivos y limitaciones.
• Actividad 3: Planificar y diseñar las pruebas, identifica los principales escenarios, determinar la variabilidad de los usuarios y la forma de simular esa variabilidad, definir los datos de las pruebas, y establecer las métricas a recoger. Consolidar esta información en uno o más modelos de uso del sistema a implantar, ejecutarlo y analizarlo.
• Actividad 4: Configurar el entorno de prueba. Preparar el entorno de prueba, herramientas y recursos necesarios para ejecutar cada una de las estrategias, así como las características y componentes disponibles para la prueba.
• Actividad 5: Aplicar el diseño de la prueba. Desarrollar las pruebas de rendimiento de acuerdo con el diseño del plan.
• Actividad 6: Ejecutar y monitorizar las pruebas. Validar las pruebas, los datos de las pruebas, y recoger los resultados.
• Actividad 7: Analizar los resultados, realizar un informe y repetirlo. Consolidar y compartir los resultados de la prueba. Analizar los datos, tanto individualmente, como con un equipo multidisciplinario. Volver a priorizar el resto de las pruebas y volver a ejecutarlas de ser necesario. Cuando todas las métricas estén dentro de los límites aceptados, ninguno de los umbrales establecidos han sido rebasados, y toda la información deseada se ha reunido, las pruebas han acabado para el escenario definido por la configuración.

Constraints: Son validaciones en cada campo a nivel de creación de tablas. Por ejemplo no puedes borrar un registro de un archivo si existe un registro en otro archivo que depende del primero. Su ventaja principal es que limita la "basura" en los archivos e impide eliminaciones accidentales.

TIPOS DE CONTRAINTS

• CHECK

La restricción CHECK asegura que todos los valores en una columna cumplan ciertas condiciones.

Por ejemplo, en la siguiente instrucción,

CREATE TABLE Customer
(SID integer CHECK (SID > 0),
Last_Name varchar (30),
First_Name varchar(30));

La columna “SID” sólo debe incluir enteros mayores a 0.

• NOT NULL

En forma predeterminada, una columna puede ser NULL. Si no desea permitir un valor NULL en una columna, querrá colocar una restricción en esta columna especificando que NULL no es ahora un valor permitido.

Por ejemplo, en la siguiente instrucción,

CREATE TABLE Customer
(SID integer NOT NULL,
Last_Name varchar (30) NOT NULL,
First_Name varchar(30));

Las columnas “SID” y “Last_Name” no incluyen NULL, mientras que “First_Name” puede incluir NULL.

• UNIQUE KEY

La restricción UNIQUE asegura que todos los valores en una columna sean distintos.

Por ejemplo, en la siguiente instrucción,

CREATE TABLE Customer
(SID integer Unique,
Last_Name varchar (30),
First_Name varchar(30));

La columna “SID” no puede incluir valores duplicados, mientras dicha restricción no se aplica para columnas “Last_Name” y “First_Name”.

Por favor note que una columna que se especifica como clave primaria también puede ser única. Al mismo tiempo, una columna que es única puede o no ser clave primaria.

• PRIMARY KEY (CLAVE PRIMARIA):

La clave primaria se utiliza para identificar en forma única cada línea en la tabla. Puede ser parte de un registro real, o puede ser un campo artificial (uno que no tiene nada que ver con el registro real). Una clave primaria puede consistir en uno o más campos en una tabla. Cuando se utilizan múltiples campos como clave primaria, se los denomina claves compuestas.

Las claves primarias pueden especificarse cuando se crea la tabla (utilizando CREATE TABLE) o cambiando la estructura existente de la tabla (utilizando ALTER TABLE).

A continuación se presenta un ejemplo para la especificación de una clave primaria cuando se crea una tabla:

MySQL:

CREATE TABLE Customer
(SID integer,
Last_Name varchar(30),
First_Name varchar(30),
PRIMARY KEY (SID));

A continuación se presenta un ejemplo para la especificación de una clave primaria al modificar una tabla:

MySQL:

ALTER TABLE Customer ADD PRIMARY KEY (SID);

Nota: Antes de utilizar el comando ALTER TABLE para agregar una clave primaria, necesitará asegurarse de que el campo esté definido como 'NOT NULL' -- en otras palabras, NULL no puede aceptarse como valor para ese campo.

• FOREIGN KEY (CLAVE EXTERNA):

Una clave externa es un campo (o campos) que señala la clave primaria de otra tabla. El propósito de la clave externa es asegurar la integridad referencial de los datos. En otras palabras, sólo se permiten los valores que se esperan que aparezcan en la base de datos.

Por ejemplo, digamos que tenemos dos tablas, una tabla CUSTOMER que incluye todos los datos del CUSTOMER, y la tabla ÓRDENES que incluye los pedidos del CUSTOMER. La restricción aquí es que todos los pedidos deben asociarse con un CUSTOMER que ya se encuentra en la tabla CUSTOMER. En este caso, colocaremos una clave externa en la tabla ORDERS y la relacionaremos con la clave primaria de la tabla CUSTOMER. De esta forma, nos aseguramos que todos los pedidos en la tabla ORDERS estén relacionadas con un CUSTOMER en la tabla CUSTOMER. En otras palabras, la tabla ORDERS no puede contener información de un CUSTOMER que no se encuentre en la tabla CUSTOMER.

La estructura de estas dos tablas será la siguiente:

Tabla CUSTOMER

nombre de columna	característica
SID	Clave Primaria
Last_Name
First_Name

Tabla ORDERS

nombre de columna	característica
Order_ID	Clave Primaria
Order_Date
Customer_SID	Clave Externa
Amount

En el ejemplo anterior, la columna Customer_SID en la tabla ORDERS es una clave externa señalando la columna SID en la tabla CUSTOMER.

A continuación se muestra un ejemplo de cómo especificar la clave externa a la hora de crear la tabla ORDERS:

MySQL:

CREATE TABLE ORDERS
(Order_ID integer,
Order_Date date,
Customer_SID integer,
Amount double,
Primary Key (Order_ID),
Foreign Key (Customer_SID) references CUSTOMER(SID));

A continuación se presenta un ejemplo para la especificación de una clave externa al modificar una tabla: Esto asume que se ha creado la tabla ORDERS, y que la clave externa todavía no se ha ingresado:

MySQL:

ALTER TABLE ORDERS
ADD FOREIGN KEY (customer_sid) REFERENCES CUSTOMER(SID);

Trigger: Es un procedimiento que se ejecuta cuando se cumple una condición establecida al realizar una operación de inserción (INSERT), actualización (UPDATE) o borrado (DELETE). Son usados para mejorar la administración de la Base de datos, sin necesidad de contar con que el usuario ejecute la sentencia de SQL.

Además, pueden generar valores de columnas, previene errores de datos, sincroniza tablas, modifica valores de una vista, etc.

Permite implementar programas basados en paradigma lógico (sistemas expertos, deducción).

TIPOS:

Existen dos tipos de disparadores que se clasifican según la cantidad de ejecuciones a realizar:

- Row Triggers (o Disparadores de fila): son aquellas que se ejecutaran n-veces si se llama n-veces desde la tabla asociada al trigger

- Statement Triggers (o Disparadores de secuencia): son áquellos que sin importar la cantidad de veces que se cumpla con la condición, su ejecución es única.




FUNCTIONS: permiten almacenar registros almacenados en una base de datos estilo-dbm. Este tipo de base de datos almacena parejas clave/valor (a diferencia de los registros completos soportados por las bases de datos relacionales).




PROCEDURES: Su implementación varía de un manejador de bases de datos a otro. La ventaja de un procedimiento almacenado es que al ser ejecutado, en respuesta a una petición de usuario, es ejecutado directamente en el motor de bases de datos, el cual usualmente corre en un servidor separado. Como tal, posee acceso directo a los datos que necesita manipular y sólo necesita enviar sus resultados de regreso al usuario, deshaciéndose de la sobrecarga resultante de comunicar grandes cantidades de datos salientes y entrantes.




PACKAGES: Un package es una agrupación de clases afines. Equivale al concepto de librería existente en otros lenguajes o sistemas. Una clase puede definirse como perteneciente a un package y puede usar otras clases definidas en ese o en otros packages.

Los packages delimitan el espacio de nombres (space name). El nombre de una clase debe ser único dentro del package donde se define. Dos clases con el mismo nombre en dos packages distintos pueden coexistir e incluso pueden ser usadas en el mismo programa.

Una clase se declara perteneciente a un package con la clausula package, cuya sintaxis es:

package nombre_package;

La clausula package debe ser la primera sentencia del archivo fuente. Cualquier clase declarada en ese archivo pertenece al package indicado.

Por ejemplo, un archivo que contenga las sentencias:

package miPackage;
. . .
class miClase {
. . .

declara que la clase miClase pertenece al package miPackage.

La claúsula package es opcional. Si no se utiliza, las clases declaradas en el archivo fuente no pertenecen a ningún package concreto, sino que pertenecen a un package por defecto sin nombre.

La agrupación de clases en packages es conveniente desde el punto de vista organizativo, para mantener bajo una ubicación común clases relacionadas que cooperan desde algún punto de vista. También resulta importante por la implicación que los packages tienen en los modificadores de acceso

INDICE: Un índice es un objeto de base de datos que ayuda al servidor a encontrar un dato más rápidamente

INDICE ÚNICO: Un índice único es un índice que no permite valores duplicados

Ejemplo:

create unique index idx_u_authors_1

on authors(au_id)

Apropiado cuando cada valor en la columna indizada debe ser único

Ejemplo:

select * from authors

where au_id = "213-46-8915"

Puede ser creado solamente sobre columnas que no tengan valores duplicados

INDICE COMPUESTO: Un índice compuesto es un índice creado sobre dos o más columnas

Ejemplo:

create index idx_authors_3

on authors(au_lname, au_fname)

Apropiado cuando las consultas se hacen sobre múltiples columnas

Ejemplo:

select * from authors

where au_lname = "Ringer" and au_fname = "Anne"

TIPO DE DATOS

Tipo de datos Adabas	Tipo de datos de SQL	Longitud	Descripción
Fecha de Adabas Natural	FECHA	4
Adabas Natural Tiempo	TIEMPO	7
Binario	BINARY	1-30000	El campo binario no se convierte. Proporciona acceso a crudo, los datos sin alterar.
Char (Derecho rellena con espacios)	BINARY (Texto)	-1	Los datos binarios.
Doble float Prec (Mainframe)	DOBLE	8	8-byte de gran precisión de mainframe endian doble: USAGE COMP-2
LongWord (BE)	SQL_INTEGER	4	USAGE COMP
Bolsas Decimal -> Entero	LARGO	1-5	Decimal empaquetado (1-255 bytes) se convierte en un largo plazo.
Firmado Overpunch -> Decimal	DECIMAL	1-17 caracteres	Overpunched Decimal convierte a SQL decimal.
Single Prec float (Mainframe)	REAL	4	4-byte big-endian float mainframe: USAGE COMP-1
Texto (terminada en nulo)	VARCHAR	-1	USAGE COMP
Word (Big Endian)	SQL_SMALLLINT	2	USAGE COMP