Estrategia de Pruebas - Historial de revisiones

Carlos idict: Texto reemplazado: «
» por «»

2019-08-11T22:53:59Z

Texto reemplazado: «<div align="justify">» por «»

Yuneisi0401ad en 21:06 4 abr 2013

2013-04-04T21:06:17Z

Indiana ciget.ssp en 18:59 5 jun 2012

2012-06-05T18:59:30Z

Mostrar los cambios

Romeliacinfo jc en 15:00 17 may 2012

2012-05-17T15:00:18Z

Romeliacinfo jc en 19:00 9 may 2012

2012-05-09T19:00:48Z

Romeliacinfo jc en 20:53 24 abr 2012

2012-04-24T20:53:11Z

Humbertojccmg en 21:17 5 dic 2011

2011-12-05T21:17:31Z

Omdelacruz0401ad: Página creada con '{{Definición |nombre= Estrategia de Pruebas }}
==Qué es una estrategia de pruebas== Son las líneas guia del equipo de pruebas de un proyecto de desarr...'

2011-12-02T19:22:06Z

Página creada con '{{Definición |nombre= Estrategia de Pruebas }} <div align="justify"> ==Qué es una estrategia de pruebas== Son las líneas guia del equipo de pruebas de un proyecto de desarr...'

Página nueva

{{Definición
|nombre= Estrategia de Pruebas
}}
<div align="justify">

==Qué es una estrategia de pruebas==

Son las líneas guia del equipo de pruebas de un proyecto de desarrollo de software. A menudo éstas son escritas por el director del equipo de pruebas, en un documento, que será entregado formalmente al director del proyecto, para su posterior revisión y aprobación.
Se debe tener claridad en que dicho documento no debe ser visto como un entregable más, éste debe ser visto como un artefacto especialmente creado para reunir las ideas más representativas del proceso de pruebas que se llevará a cabo.
La estrategia que se ha de seguir a la hora de evaluar dinámicamente un sistema software debe permitir comenzar por los componentes más simples y más pequeños e ir avanzando
progresivamente hasta probar todo el software en su conjunto. Más concretamente, los pasos a
seguir son:

1. Pruebas Unitarias. Comienzan con la prueba de cada módulo.<br>
2. [[Pruebas]] de Integración. A partir del esquema del diseño, los módulos probados se
vuelven a probar combinados para probar sus interfaces<br>
3. Prueba del Sistema. El [[software]] ensamblado totalmente con cualquier componente
hardware que requiere se prueba para comprobar que se cumplen los requisitos
funcionales<br>
4. Pruebas de Aceptación. El [[cliente]] comprueba que el software funciona según sus
expectativas<br>

== Pruebas Unitarias<br> ==

La prueba de [[unidad]] es la primera fase de las pruebas dinámicas y se realizan sobre cada
módulo del software de manera independiente. El objetivo es comprobar que el módulo,
entendido como una unidad funcional de un programa independiente, está correctamente
codificado. En estas pruebas cada módulo será probado por separado y lo hará, generalmente, la
persona que lo creo. En general, un módulo se entiende como un componente software que
cumple las siguientes características:
*Debe ser un bloque básico de construcción de programas.
*Debe implementar una función independiente simple.
*Podrá ser probado al cien por cien por separado.
*No deberá tener más de 500 líneas de código.
Tanto las pruebas de caja blanca como las de caja negra han de aplicar para probar de la manera
más completa posible un módulo. Nótese que las pruebas de caja negra (los casos de prueba) se
pueden especificar antes de que módulo sea programado, no así las pruebas de caja blanca.

==Pruebas de Integración<br>==

Aún cuando los módulos de un programa funcionen bien por separado es necesario probarlos
conjuntamente: un módulo puede tener un efecto adverso o inadvertido sobre otro módulo; las
subfunciones, cuando se combinan, pueden no producir la función principal deseada; la
imprecisión aceptada individuamente puede crecer hasta niveles inaceptables al combinar los
módulos; los datos pueden perderse o malinterpretarse entre interfaces, etc.
Por lo tanto, es necesario probar el software ensamblando todos los módulos probados
previamente. Ésta es el objetivo de la pruebas de integración.
A menudo hay una tendencia a intentar una integración no incremental; es decir, a combinar
todos los módulos y probar todo el programa en su conjunto. El resultado puede ser un poco
caótico con un gran conjunto de fallos y la consiguiente dificultad para identificar el módulo (o módulos) que los provocó.
En contra, se puede aplicar la integración incremental en la que el programa se prueba en
pequeñas porciones en las que los fallos son más fáciles de detectar. Existen dos tipos de
integración incremental, la denominada ascendente y descendente. Veamos los pasos a seguir
para cada caso:
Integración incremental ascendente:
1. Se combinan los módulos de bajo nivel en grupos que realicen una subfunción
específica.<br>
2. Se escribe un controlador (un programa de control de la prueba) para coordinar la
entrada y salida de los casos de prueba<br>
3. Se prueba el grup.<br>
4. Se eliminan los controladores y se combinan los grupos moviéndose hacia arriba por la
estructura del programa.<br>

==Pruebas del Sistema<br>==

Este tipo de pruebas tiene como propósito ejercitar profundamente el sistema para verificar que se han integrado adecuadamente todos los elementos del sistema (hardware, otro software, etc.)y que realizan las funciones adecuadas. Concretamente se debe comprobar que:

*Se cumplen los requisitos funcionales establecidos.
*El funcionamiento y rendimiento de las interfaces hardware, software y de usuario.
*La adecuación de la documentación de usuario.
*Rendimiento y respuesta en condiciones límite y de sobrecarga.

Para la generación de casos de prueba de sistema se utilizan técnicas de caja negra.
Este tipo de pruebas se suelen hacer inicialmente en el entrono del desarrollador, denominadas
Pruebas Alfa, y seguidamente en el entrono del cliente denominadas Pruebas Beta.

== Pruebas de Aceptación <br> ==

A la hora de realizar estas pruebas, el producto está listo para implantarse en el entorno del
cliente. El usuario debe ser el que realice las pruebas, ayudado por personas del equipo de
pruebas, siendo deseable, que sea el mismo usuario quien aporte los casos de prueba.
Estas pruebas se caracterizan por:
*Participación activa del usuario, que debe ejecutar los casos de prueba ayudado por
miembros del equipo de pruebas.
*Están enfocadas a probar los requisitos de usuario, o mejor dicho a demostrar que no se
cumplen los requisitos, los criterios de aceptación o el contrato. Si no se consigue
demostrar esto el cliente deberá aceptar el producto.
*Corresponden a la fase final del proceso de desarrollo de software.
Es muy recomendable que las pruebas de aceptación se realicen en el entorno en que se va a
explotar el sistema (incluido el personal que lo maneje). En caso de un producto de interés
general, se realizan pruebas con varios usuarios que reportarán sus valoraciones sobre el
producto.Para la generación de casos de prueba de aceptación se utilizan técnicas de caja negra.

== Pruebas de Regresión <br> ==

La regresión consiste en la repetición selectiva de pruebas para detectar fallos introducidos
durante la modificación de un sistema o componente de un sistema. Se efectuarán para
comprobar que los cambios no han originado efectos adversos no intencionados o que se siguen
cumpliendo los requisitos especificados.
En las pruebas de regresión hay que:

*Probar íntegramente los módulos que se han cambiado.
*Decidir las pruebas a efectuar para los módulos que no han cambiado y que han sido
afectados por los cambios producidos.
Este tipo de pruebas ha de realizarse, tanto durante el desarrollo cuando se produzcan cambios en el software, como durante el mantenimiento.

== Fuentes ==
* http://www.buenastareas.com/ensayos/Proceso-De-Pruebas-De-Software/4887.html
* http://gemini.udistrital.edu.co/comunidad/grupos/arquisoft/index.php?id=81&type=
* http://www.slideshare.net/LGasperin/estrategias-de-pruebas-de-software
*http://www.wiziq.com/tutorial/41789-pruebas
<br>

[[Category:Desarrollo_web]] [[Category:Internet]]

@@ Línea 2: / Línea 2: @@
 |nombre= Estrategia de Pruebas
 |imagen=Estrategias_de_prueba.jpg
-}}<div align="justify">'''Estrategia de Pruebas'''. Son las líneas guía del equipo de pruebas de un proyecto de desarrollo de [[software]]. A menudo éstas son escritas por el director del equipo de pruebas, en un documento, que será entregado formalmente al director del proyecto, para su posterior revisión y aprobación.
+}}'''Estrategia de Pruebas'''. Son las líneas guía del equipo de pruebas de un proyecto de desarrollo de [[software]]. A menudo éstas son escritas por el director del equipo de pruebas, en un documento, que será entregado formalmente al director del proyecto, para su posterior revisión y aprobación.
 == Elementos ==
 Se debe tener claridad en que dicho documento no debe ser visto como un entregable más, éste debe ser visto como un artefacto especialmente creado para reunir las ideas más representativas del proceso de pruebas que se llevará a cabo.

@@ Línea 1: / Línea 1: @@
 {{Definición
 |nombre= Estrategia de Pruebas
 }}<div align="justify">'''Estrategia de Pruebas'''. Son las líneas guía del equipo de pruebas de un proyecto de desarrollo de [[software]]. A menudo éstas son escritas por el director del equipo de pruebas, en un documento, que será entregado formalmente al director del proyecto, para su posterior revisión y aprobación.
 == Elementos ==

← Revisión anterior		Revisión del 21:17 5 dic 2011
Línea 1:		Línea 1:
		+	{{Normalizar\|motivo=}}
	{{Definición		{{Definición
	\|nombre= Estrategia de Pruebas		\|nombre= Estrategia de Pruebas

@@ Línea 2: / Línea 2: @@
 {{Definición
 |nombre= Estrategia de Pruebas
-}}<div align="justify">'''Estrategia de Pruebas'''.Son las líneas guia del equipo de pruebas de un proyecto de desarrollo de [[software]]. <br />
+}}<div align="justify">'''Estrategia de Pruebas'''.Son las líneas guia del equipo de pruebas de un proyecto de desarrollo de [[software]]. A menudo éstas son escritas por el director del equipo de pruebas, en un documento, que será entregado formalmente al director del proyecto, para su posterior revisión y aprobación.
 == Elementos ==
-Se debe tener claridad en que dicho documento no debe ser visto como un entregable más, éste debe ser visto como un artefacto especialmente creado para reunir las ideas más representativas del proceso de pruebas que se llevará a cabo.
+Se debe tener claridad en que dicho documento no debe ser visto como un entregable más, éste debe ser visto como un artefacto especialmente creado para reunir las ideas más representativas del proceso de pruebas que se llevará a cabo.<br />
 La estrategia que se ha de seguir a la hora de evaluar dinámicamente un sistema [[software]] debe permitir comenzar por los componentes más simples y más pequeños e ir avanzando
 progresivamente hasta probar todo el software en su conjunto. Más concretamente, los pasos a
 seguir son:
 . Pruebas Unitarias. Comienzan con la prueba de cada módulo.<br>
-. [[Pruebas]] de Integración. A partir del esquema del diseño, los módulos probados se  vuelven a probar combinados para probar sus interfaces<br>
+. [[Pruebas de Integración]]. A partir del esquema del diseño, los módulos probados se  vuelven a probar combinados para probar sus interfaces<br>
-. Prueba del Sistema. El software  ensamblado totalmente con cualquier componente  hardware que requiere se prueba para comprobar que se cumplen los requisitos
+. Prueba del Sistema. El software  ensamblado totalmente con cualquier componente  [[hardware]] que requiere se prueba para comprobar que se cumplen los requisitos  funcionales<br>
-funcionales<br>
+. Pruebas de Aceptación. El [[cliente]] comprueba que el software funciona según sus  expectativas<br>
 == Pruebas Unitarias<br> ==
-La prueba de [[unidad]] es la primera fase de las pruebas dinámicas y se realizan sobre cada
+La prueba de [[unidad]] es la primera fase de las pruebas dinámicas y se realizan sobre cada  módulo del software de manera independiente.
-módulo del software de manera independiente. El objetivo es comprobar que el módulo,
+=== Objetivo ===
-entendido como una unidad funcional de un programa independiente, está correctamente
+El objetivo es comprobar que el módulo,  entendido como una unidad funcional de un programa independiente, está correctamente
 codificado. En estas pruebas cada módulo será probado por separado y lo hará, generalmente, la
 persona que lo creo. En general, un módulo se entiende como un componente software que
@@ Línea 100: / Línea 96: @@
 afectados por los cambios producidos.
 Este tipo de pruebas ha de realizarse, tanto durante el desarrollo cuando se produzcan cambios en el software, como durante el mantenimiento.
 == Fuentes ==
 *[http://www.buenastareas.com/ensayos/Proceso-De-Pruebas-De-Software/ 4887.html]
@@ Línea 107: / Línea 102: @@
 *[http://www.wiziq.com/tutorial/41789-pruebas]
 <br>
+== Enlace relacionado ==
 [[Category:Desarrollo_web]] [[Category:Internet]]