Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

Parcial 2

Descargar como txt, pdf o txt
Descargar como txt, pdf o txt
Está en la página 1de 6

Debido a que el software es susceptible a tener defectos por ser desarrollado e

implementado por seres humanos, quienes podemos cometer errores, surge la


necesidad de realizar pruebas, con las que se busa reduvri al maximo su presnecia,
es importante decir que tambien al incrementar la funcionalidad, incorporar
modificaciones o hacer mantenimiento, es posible que se geneneren defectos

¿Qué es la prueba de software?: es el porceso de evaluar y verificar que un


producto o aplicación de software hace lo que debe hacer. Puede prebenir errores,
reducción de costos de desarrollo y mejora de rendimiento.

El conjunto de actividades de pruebas dentro del proceso de desarrollo de software,


son conocidas como procesos básico de pruebas, el cual incluye:
1.- PLANEACION
2.- ANALISIS Y DISEÑO DE PRUEBAS
3.- EJECUCION DE PRUEBAS
4.- EVALUACION DE RESULTADOS
5.- CIERRE DE PRUEBAS

Etapas, Técnicas y Tipos de Pruebas


El proceso de pruebas define etapas que especifican en que momento del desarrollo
del software comenzaremos a probar. Cada etapa tiene un objetivo diferente,
técnicas que nos ayudan a definir qué y cómo vamos a probar Lo anterior depende de
la etapa en la que se comience la prueba.

Por qué probar el software?


El propóstio de las pruebas es:
1.- Detectar la mayor cantidad de errores posibles
2.- Ayudar a los administtradores a la toma de decisiones
3.- Buscar los escenarios seguros para el uso del producto
4.- Evaluar la calidad
5.- Verificar la corrección del producto
6.- Asegurar la calidad

En resumen las pruebas son una inversion, a continuacion se mencion tres puntos
importantes por los cuales se debe probar el sotware.
1.- Mejora de la calidad de un producot software: El proceso de pruebas ayuda
a suministrar o aportar al software los atributos deseados, por ejemplo: retirar
defectos que conducen a fallos.
2.- Reduccion del riesgo de detectar errores: Las actividades de pruebas de
software adecuadas reduciran el riesgo de encontrar errores durante la fase de
operación del software
3.- Satisfacer compromisos: La ejecucion de pruebas puede ser un requisito
obligatorio por parte del clien,te debido a normas legales, así como el
cumplimiento de estandares popios de una industria

Revisiones tecnicas -> Pruebas de caja blanca -> Funcionales -> No funcionales ->
Aceptación

Etapas:
1.- Pruebas modulares: probar métodos y funciones individuales de las clases,
componentes o módulos que usa tu software.
2.- Pruebas Integracion: validar las interfaces o puntos de integración entre
funciones o componentes individuales.
3.- Pruebas de Sistema: investigaciones empíricas y técnicas que dan
información objetiva e independiente sobre la calidad del producto.
4.- Pruebas de Aceptación: se observan aspectos generales del sistema en un
escenario simulado, para verificar que su funcionamiento sea óptimo.

Tipos:
1.- Estáticas: son aquellas que se hacen sin necesidad de ejecutar el código.
ejemplo buesqueda de errores de patron de código
2.- Dinámicas: son aquellas en las que tengo que ejecutar el software para
poder probarlo.

Técnicas
1. Funcionales
2. No funcionales
3. Estructurales
4. Asociadas al Cambio

______________________________________________________________________

ETAPAS, TÉCNICAS Y TIPOS DE PRUEBAS

PRUEBAS MODULARES
Las pruebas modulares o unitarias, se centran en probar piezas/unidades
individuales de una aplicación de software al principio del SDLC. Cualquier
función, procedimiento, método o módulo puede ser una unidad que se someta a
pruebas unitarias unitarias para determinar su correción y comportamiento esperado.
Las pruebas unitarias son las primeras pruebas que los desarrolladores realizan
durante la fase de desarrollo.

¿Por qué probamos un módulo?


A veces, los desarrolladores de software intentan ahorrar tiempo probando
mínimamente un módulo.
Esto es imposible, por que escatimar en la prueba del módulo conduce a más errores
y costos más altos durante la prueba del sistema, el prueba
de integración e incluso, si el usuario recibe el sistema entregado, en la prueba
de aceptación. Las pruebas adecuadas del módulo durante la fase de desarrollo
ahorran tiempo dinero y espacio.

LIMITACIONES
No podemos esperar de la prueba del módulo encontrar todos los errores en un
programa. Es decir, no es posible probar todas las rutas de
ejecución, incluso en los programas más triviales. Debido a su naturaleza se centra
en el código del programa.

PRUEBAS MODULARES
Son principalmente modulos o trozos de código diseñados para comprobar que el
código principal está
funcionando como esperabamos. Pequeños test creados específicamente para cubrir
todos los requisitos del código y verificar sus resultados.

CARACTERISTICAS
-Automatizadas
-Completas
-Repetibles
-Independientes

PRUEBAS DE INTEGRACIÓN
En las pruebas de integración debe tenerse en cuenta que existe la pisibilidad de
tener que reunir los resultados de diferentes
desarrolladores y/o equipos de pruebas, pues cada componente puede tener un origen
distinto.

EJEMPLO
Func randomNumber(min:Int,max:Int)->Int{
return 10
}
let myNumber=randomNumber(min:5,max:31)//retornara siempre 10

TIPOS DE PRUEBAS DE INTEGRACIÓN


-Top-Down:
En esta estrategia la integración se lleva a cabo sistemáticamente de arriba
a abajo.
-Bottom-Up:
Se trata de la estrategia de pruebas inversa de topdown. Se lleva a cabo una
integración de abajo a arriba.
-End-to-End:
Es una estrategia de pruebas de integración orientada al proceso de negocio
en el cual se integran en cada caso de los componentes
necesarios por parte de un proceso completo de negocio.
-Funciones:
Consiste en diseñar la integración orientada a una función del sistema, de
manera que se integra cada uno de los componentes
necesitados por la función correspondiente al sistema.
-Ad-hoc:
Se enfoca el software como módulos independientes y una vez se finaliza su
implementación, validación.

PRUEBAS DE SISTEMA
Esta etapa consiste en probar un sistema integrado con el objeto
El entorno de pruebas debería corresponderse con el entorno de producción, sin
llegar a ser el entorno de producción real.
Para ello, deben omitirse los controladores de pruebas y stubs e interfaces
externas.
Validar el cumplimiento de los requisitos establecidos.

PRUEBAS DE SISTEMA
-Funcionales
-Interfaz gráfica
-Instalación
-Stress
-Seguridad

ISO 9126
-Funcionales
-No funcionales

PRUEBAS DE ACEPTACIÓN
Pruebas finales que realiza en cliente con el fin de verificar por sí mismo el
cumplimiento de los requisitos especificados y cumpla
con las expectativas.
UAT´S-> USER ACEPTING TESTING

CAJA NEGRA
Pruebas funcionales sin tener conocimiento técnico sobre el software
CAJA BLANCA
Pruebas técnicas de los módulos, con las programación.

___________________________________________

Casos de Prueba
La gesiton de proyectos es un complejo sistema de procediminetos de gestión,
ptáticas, tecnologías y conocimientos, en el que es necesaria la experiencia para
gestionarlos con éxito. La gestión de proyectos de software es una actividad lineal
en la Ingenieria de Software. Se inica antes que cualquier actividad técnica
comience y continúa durante todas las etapas desarrollo hasta el mantenimiento.

Definicion: Un conjunto de pasos y resultados esperados que se crean aprtitr de


los requisistos del software que se va a probar.

Es la unidad más pequeña del plan de prueba, en ella se invluye una descripcion de
las acciones y los parámetros necesarios para lograr y verificar el comportamiento
esperado de una funcion en particular o la parte del software probado.

Los casos de prueba se deven cerar teniendo en cuenta:


Que sean claros y concretos: Que cualquier persona del equipo de trabajo
pieda leerlos en cualquier moment para comprender la funcionalidad.
Que sean exactos: Demostrar que pueden probar y que arrojan los resutlados
esperados.
Que sean confiables y repetibles: Que se obtengan los mismos resultados cada
vez que se ejecuten
Que sean ratreables: Saber a que historia de usuario o requerimiento está
asociado el caso de prueba.

"PDCA":
Planear:
Definir objetivos, definir las politicas centrales necesarias. Determinar
procesos y condiciones.
Actuar:
si los resultados no se alcanzan tomar medidas correctivas para el siguiente
plan.
Chequear:
Checar el programa y los resultados obtenidos.
Ejecutar:
Ejecutar las condiciones, realizar trabajo de entrenamiento y aprendizaje
acordar el procesamiento.

Tipos de casos de prueba


Positivos: Pruebas destinadas a verificar el funcionamiento correcto de la
funcionalidad utilizanfo el formato de entrada correcto: Por ejemplo verificar los
formatos de correos electrónicos: (letras permitidas, coracteres especiales
permitidos, números,)
Negativos: Pruebas destinadas a verificar el funcionamiento correcto de la
funcionalidad utilizando el fomrato de entrada incorrecto, esperando como
resultado un mensaje de error. Por ejemplo: verificar los formatos de correos
electrónicas: (caracteres espciales que no están permitidos) se debe validar que
mediante mensajes informaticos se tenga conocimietno de la falla)
Valor límite: Pruebas destinadas a verificar el funcionamiento correcto de la
funcionalidad utiliazando formatos permitdos y no permitidos. Por ejemplo verifcar
los formatos de correos electrónicos: si se tiene contemplado que en el campo de
correo el número de caracteres no supere los 20 dígitos antes del símbolo @ se debe
validar la respuesta de la aplicación, al digtar diferentes valores, incluyendo
espacio.

Los criterios de aceptación son fundametales para establecer la utilidad y calidad


de un caso de prueba y así como un caso de uso se elabora alrededor del objetivo,
los caos de pprueba se elaboran alrededor de los criterios de aceptación.
Para desarrollar software de calidad y libre de errores, el plan de pruebas y los
casos de prueba son muy importantes. El Software Test Plan - STP - se diseña para
determinar el ambiente de aplicación de los recursos y el calendario de las
actividades de las pruebas, se debe identificar el dominio y sus características a
probar, lo mismo que el tipo de pruebas a realizar.
Un caso de preuba bein diseñado tiene gran posibilidad de llegar a resultados mas
fiables y eficientes, mejorar el rendimiento del sistea, y reducir los costos en
tres categorías:
1) productividad: menos tiempo para escribir y mantener los casos
2) capacidad de preuba: menos tiempo para ejecutarlos
3) programar la fiabilidad: estimaciones mas fiables y efectivas.

Un caso de prueba es sun conjunto de acciones con resultados y salidas previstas


basadas en los requisitos de especificación del sistema; sus componenetes son:
Propósito: de la prueba o descripción del requisito que se está probando
Método: o forma como se probará
Versión: o configuración de la prueba, versión de la aplicación en prueba, el
hordware, el software, el sistema operatico, los archivos de datos, entre otros.
Resultados: acciones y resultados esperados o entradas y salidas
Documentación: de las prueba y sus anexos

______________________________________________________

Planificación y revisiones de prueba


Alcance del Software
Comprende los procesos necesarios para asegurar que el proyecto iincluya todo el
trabajo requerido, y sólo el trabajo requerido. Encuentra la forma correta de
definir el alcance en un proyecto de software desde el inicio para ahorrarte
problemas futuros.
En primer lugar, el alcance puede hacer referencia al alcance del producto o al
alcance del proyexto. Es importante conocer la diferencia:
El alcance del producto se define como las funciones y características que
describen un producto o servicio
Por su parte, el alcance del proyecto es el trabajo que debe realizarse para
entregar un producto de acuerdo con el alcance del producto (funciones y
características requeridas).
Describe que cosas están dentro del esfuezo de testing u que coasas no.. Una forma
de presentarlo es mediante una tabla donde se indiquen que funcionlidades están y
cuales no están dentro del esfuerzo de testing. El alcance es definido en base al
análisis de riesfo realizado previamente.

Complejidad de sus Procesos


Podemos hablar de dos vistas de la complejidad de un producto de software: la
externa, que tiene que ver con el problema que resuelve el sistema (el proceso de
negocio); y la interna, que se refiere a la manera como está programada la
solución.
En la interna podemos distinguir al menos los sigueintes aspectos:
Su tamaño. Entre más grande sea un producto, mayor será su complejidad. Una
métrica de tamaño (bastante primitiva, pero muy accesible y común) son las líneas
de código (LCs).
Su estructura.
Donde la complejidad en el software es mayor, hay más propensión a errores, lo que
en particular implica que debemos...
La complejidades parte esencial d elos sitemas de software de gran tamaño. Se puede
manejar, pero no se puede eliminar.

Plataformas de prueba
La prube ade software es una fase crítica y, a menudo, tediosa de la finalización
del producto y mejora su precisión.
En los primeros días, los probadores pasaban horas probando una funcionalidad en
particular y todavia nunca obtenín resultados del 100%. Hoy en día, con muchas
herramientas inteligentes de prueba de software a mano, las pruebas...
Conocimientos y Formación

Normas Legales
Fianlmente, en Méciso, la Ley de la Propiedad Industrial regula el otrogamietno de
patentes en el país a las invenciones de productos o de procesos. en ella se
mecniona que los programas de cómputo no son considerados inveciones, por lo que en
México no existen tales patentes.
Los programas de software solamente se pueden...
La Ley Federal del Derecho de Autor define a los programas de cómputo como la
expresión original en cualquier forma, lengauje o código, de un cojunto de
instrucciones que, con una secuencia, estructura y organización determinada, tine
como propósito que una computadora o dispositivo realice una tarea o función
específica.

También podría gustarte