Pruebas de software.

Esto es un resumen de la teoría que he estudiado. Por tanto, al ser un resumen de un contenido realizado por otra persona: 1) No soy su autor. 2) No es válido como material de estudio si necesitas conocimientos profundos del tema.

1.Introducción al desarrollo de software.

A pesar de que se realizan controles periódicos en la creación de software, con objeto de evaluar la calidad de los productos y detectar los defectos lo antes posibles; es necesario probar el producto mediante su ejecución controlada.

Las ejecuciones o ensayos realizadas posteriores a la terminación del código de un producto de software se llaman pruebas.

Las pruebas tienen el mismo objetivo que las revisiones (verificar y validar software), sin embargo, estas se aplican al producto cuando se encuentra en formato ejecutable.

Nota:

• Verificar: Proceso de evaluación de un sistema o un componente, con objeto de determinar si los productos de una fase cumplen las condiciones que tenían en la fase anterior.
• Validar: Proceso que evalúa un sistema o un componente al final del proceso de desarrollo para verificar que cumple los requisitos del usuario.

2. Definciones.

• Prueba: Actividad en la cuál un sistema (o uno de sus componentes), se ejecuta en circunstancias previamente especificadas. Los resultados son observados y registrados, a partir de ellos se evalúa algún aspecto.
• Caso de prueba: Conjunto de: entradas, condiciones de ejecución y resultados esperados. Se desarrollan para un objetivo particular: ejercitar un camino concreto de un programa, verificar el cumplimiento de un requisito. (También se define con este término a la documentación en la que se describen las entradas, condiciones y salidas de un caso de prueba)
• Error: Incorrección cometida por una persona en el desarrollo del producto.//Diferencia entre el valor calculado/observado/medido y el verdadero/especificado/correctamente teórico.
• Defecto: Proceso, definición de datos o paso de procesamiento incorrecto en un programa.
• Fallo: Incapacidad de un sistema/componente para realizar las funciones requeridas dentro de los requisitos de rendimiento especificados.

Defecto -> consecuencia de error.

Fallo -> consecuencia de defecto.

3. Filosofía de las técnicas de software.

• Debido a las características del software, es más difícil de probar que otros productos.
• La prueba exhaustiva del software es impracticable.
• Prejuicios: Mito de ausencia de errores en el buen profesional ->Las pruebas permiten la rectificación en el software. || Los defectos no son siempre resultado de negligencia, en su aparición influyen múltiples factores.
• El objetivo de las pruebas es detectar defectos en el sotware. -> Descubrir un defecto es un éxito de la prueba.
• Es una actividad a posteriori, para detectar.

Recomendaciones:

• Cada caso de prueba debe definir el resultado de salida esperado. Se compara con el obtenido: si son diferentes puede haber defectos en el software.
• El programador debe evitar probar sus propios programas. Las situaciones que olvida al crear el programa se pueden olvidar al probarlo.
•  Se debe inspeccionar a conciencia el resultado de cada prueba.
• Se deben incluir tanto datos de entrada válidos y esperados como no válidos e inesperados.
• Objetivos: Probar si no hace lo que debe, probar si hace lo que no debe.
• Evitar los caso desechables: sin documentar, sin cuidado en su diseño.
• No hacer las pruebas suponiendo que no hay errores.
• La probabilidad de descubrir nuevos defectos es proporcional al ya descubierto.
• No existen técnicas rutinarias->usar el ingenio.

Las pruebas deben ser planificadas y diseñadas de forma sistemática para poder detectar el mayor número y variedad de defectos con el mínimo tiempo y esfuerzo.

4. El proceso de prueba.

1. Generación del plan de pruebas. Se hace en base a la documentación: sobre el proyecto y el software.
2. Diseño de pruebas específicas. En base a la documentación del software.
3. Tomar la configuración del software a probar para ejecutar los casos.
4. Evaluar los resultados.->Depurar./Análisis de estadística de errores.

5. Técnicas de diseño de casos de prueba.

• Están totalmente influenciadas por la imposibilidad de probar exhaustivamente el software.
• Tienen como objetivo conseguir una confianza aceptable en que se detectaran los defectos existentes sin necesidad de consumir una cantidad excesiva de recursos. -> Equilibrio entre la disponibilidad de recursos y la confianza para descubrir los defectos.
• Idea fundamental: Elegir algunas de las posibilidades de funcionamiento que sean representativas del resto. (La dificultar es saber elegir los casos, ya que una elección aleatoria no proporciona demasiada confianza -> criterios de elección).

Enfoques principales para el diseño de casos:

• Estructural/ de caja blanca:

Se centra en la estructura interna para elegir los casos de prueba. Es independiente de la funcionalidad -> no se comprueban los resultados. Lo ideal sería probar todos los posibles caminos de ejecución que puedan trazarse a través de las instrucciones de código.

• Funcional/de caja negra:

Estudia la especificación de las funciones, la entrada y salida para derivar los casos. Ideal: probar todas las posibles entradas y salidas del programa.

• Enfoque aleatorio.

Uso de modelos que representen las posibles entradas al programa para crear a partir de ellos los casos de prueba.

Los enfoques no son excluyentes entre sí.

6. Prueba estructural.

Elegir caminos importantes para tener una seguridad aceptable en descubrir defectos. -> Uso de criterios de cobertura lógica.

• Cobertura de sentencias. Que cada sentencia se ejecute al menos una vez.
• Cobertura de decisiones. Que cada decisión tenga por lo menos una vez un resultado verdadero y uno falso.
• Cobertura de condiciones. Que cada decisión tenga el resultado verdadero y el falso al menos una vez.
• Criterio de decisión/condición. Exigir que se cumpla la cobertura de condiciones y a la vez el de decisiones.
• Criterio de condición múltiple. Cada decisión múltiple de descompone en varias de 1 sola condición.
• Cobertura de caminos. Cada uno de los posibles caminos se debe ejecutar al menos una vez.

Camino: Secuencia de sentencias encadenadas desde la  inicial del programa hasta la final.

Reducción del número de caminos y bucles:

Camino de prueba: un camino del programa que atraviesa, como máximo, una vez el interior de cada bucle que encuentra.

Se recomienda que se pruebe cada bucle tres veces: sin entrar en su interior, ejecutándolo una vez y ejecutándolo dos veces. -> comprobar cómo se comporta a partir de los valores de datos procedentes, de las operaciones de su interior.

Los bucles constituyen el elemento de los programas que genera un mayor número de problemas para la cobertura de caminos.

7. Prueba funcional.

• Estudio de la especificación del software, análisis de las funciones que debe realizar, de las entradas y las salidas. -> Búsqueda de criterios que permitan elegir un subconjunto de casos cuya ejecución aporte una cierta confianza en detectar los posibles defectos.
• Definición de un caso de prueba bien elegido: Reduce el número de otros casos necesarios para que la prueba sea razonable y cubre un extenso número de otros casos posibles.

Particiones/casos de equivalencia:

• Cada caso debe cubrir el máximo número de entradas.
• Se trata el dominio de valores de entrada dividido en un número finito de clases de equivalencia. Cada valor representativo de una clase permite suponer que el resultado obtenido sería el mismo que habiendo probado cualquier otro valor de esa clase.

Método de diseño de casos:

1. Identificar las clases de equivalencia.
2. Crear los casos de prueba correspondientes.

Pasos para identificar las posibles clases de equivalencia de un programa a partir de su especificación:

1. Identificar las condiciones de entrada.
2. Creación de clases de equivalencias de datos válidos y no válidos/erróneos.
3. Identificar los casos de prueba. Fases: 

• Asignar un valor único a cada clase de equivalencia.
• Tratar de escribir un caso que cubra tantas clases válidas no incorporadas como sea posible.

Actualización de más contenido en este tema próximamente.

Procedimientos almacenados-SQL Server.Resumen

Aquí os dejo un resumen genérico sobre procedimientos almacenados para SQL Server.

Para que nos entendamos: la parte en negro es el "molde" y la azul donde rellenas los campos para usarlo.

Este resumen sirve de guía si se tienen ciertos conocimientos de SQL.

Ejecución procedimiento almacenado en sistema:

USE base de datos

GO

procedimiento

Verificar si un objeto ha sido creado:

USE base de datos

SELECT OBJECTPROPERTY(OBJECT_ID((procedimiento),objeto)

Crear un procedimiento:

USE base de datos

GO

CREATE PROCEDURE procedimiento (PROCEDURE o PROC)

AS

SELECT mi seleccion

GO

      Vamos a llamar al procedimiento creado:

USE base de datos

EXEC procedimiento

GO

Creación procedimiento temporal:

CREATE PROC #procedimiento

AS

SELECT db_name() AS nombre

      *db_name( ) es una función.Enlace a su información oficial

Nota: #procedimiento temporal, ##procedimiento global. Los crea el usuario y se guardan en tempdb.

Lectura del código de un procedimiento:

EXEC sp helptext 'procedimiento'

Creación de procedimiento almacenado que se ejecuta en el inicio de SQL-Server:

Establecer que se ejecute en el inicio:

EXEC sp_procoption 'procedimiento','startup','true'

Deshacer que se ejecute en el inicio:

USE base de datos

GO

EXEC sp_procoption

@procname='procedimiento'

@optionname='startup'

@optionvalue='off'

GO

Crear procedimiento encriptado:

USE base de datos

GO

CREATE PROC procedimiento

WITH ENCRYPTION

AS SELECT seleccion

GO

   Visualización:

sp_helptext 'procedimiento'

Creación de procedimiento almacenado con parámetros:

USE base de datos

GO

CREATE PROC procedimiento

@parametro TIPO_PARAMETRO

AS

SELECT mi selección

GO

   Se le puede asignar un valor por defecto al parámetro:

USE base de datos

GO

CREATE PROC procedimiento

@parametro TIPO_PARAMETRO='valor'

AS

SELECT mi selección

GO

    También se pueden definir parámetros de entrada y de salida;

USE base de datos

GO

CREATE PROC procedimiento

@parametro TIPO_PARAMETRO *entrada

@parametro TIPO_PARAMETRO OUTPUT *salida

AS

SELECT mi selección

GO

    Se le pueden pasar tablas como parámetros:

USE base de datos

GO

CREATE PROC procedimiento

@tabla TIPO_PARAMETRO

AS

DECLARE @variable TIPO_PARAMETRO

SET @variable='SELECT mi selección FROM'+@table

EXEC (@variable)

GO

Modificar un procedimiento:

USE base de datos

GO

ALTER PROC procedimiento

@parametro_entrada TIPO_PARAMETRO

WITH ENCRYPTION *si se quiere encriptar

AS

DECLARE @variable='SELECT'+@parametro_entrada+'FROM'+@tabla

EXEC (@variable)

GO

Crear procedimiento y asignar valores de retorno:

USE base de datos

GO

CREATE PROC procedimiento

@variable TIPO_VARIABLE

AS

IF CONDICIÓN (mi seleccion) RETURN valor

ELSE mi selección

RETURN

GO

Ejecución de procedimientos almacenados:

   Vamos a hacerlo de uno con parámetros:

USE base de datos

GO

CREATE PROC procedimiento

@variable TIPO_VARIABLE = valor_defecto (opcional)

AS

INSERT INTO tabla

(nombre de las variables originales de la tabla)

VALUES

(variables que acabo de declarar)

GO

   Lo ejecutamos:

procedimiento

@variable='valor'

GO

Invocación de un procedimiento almacenado desde cualquier base de datos:

(El procedimiento debe estar definido en master)

USE base de datos

GO

EXEC master procedimiento (poner master es opcional)

Crear procedimientos almacenados con compilación:

USE base de datos

GO

CREATE PROC procedimiento

@variable TIPO_VARIABLE

WITH RECOMPILE

AS

SELECT mi seleccion

GO

   Ejecución:

USE base de datos

GO

EXEC procedimiento 'valor de variable' WITH RECOMPILE

Recompilar procedimientos almacenados sp_recompile:

USE base de datos

GO

sp_recompile 'tabla'

GO

Manejo de errores @@ERROR:

   Declaración de la variable:

USE base de datos

GO

DECLARE @Error TIPO_VARIABLE

   Insertar datos erróneos y captura del error:

INSERT INTO [tabla]

(variables)

VALUES

(valores)

SELECT @Error=@@ERROR

  Escritura de los calores de error:

PRINT ' '

PRINT 'El valor de @Error es '+CONVERT (VARCHAR,@Error)

PRINT 'El valor de @Error es'+CONVERT(VARCHARM,@@ERROR

   Ejecución de la secuencia y captura del resultado:

USE base de datos

GO

DECLARE @Error TIPO_VARIABLE

PRINT 'El valor de @@Error es'+CONVERT(VARCHAR,@@ERROR)

Manejo de errores con RAISERROR:

    Declarar la variable:

USE base de datos

GO

DECLARE @Error TIPO_VARIABLE

    Ejecución y captura del resultado:

RAISERROR ('Aquí hay un error', gravedad, estado)

SELECT @Error=@@Error

    Escritura de los valores de error:

PRINT ''

PRINT 'El valor de @Error es ' + CONVERT (VARCHAR, @Error)

PRINT 'El valor de @@ERROR es ' + CONVERT (VARCHAR, @@ERROR)

Agregar mensaje personalizado:

    Primero hay que hacerlo en inglés o da error al hacerlo en español:

USE base de datos

GO

sp addmessage

@msgnum = 50001,

@lang = 'us_english',

@severity = gravedad,

@msgtext = 'There was an error'

GO

    Tras esto ya se puede hacer en español:

sp_addmessage

@msgnum = 50001,

@lang = 'spanish',

@severity = gravedad,

@msgtext = 'Ha ocurrido un error'

GO