2017

Especificacin del diseo de pruebas

PRUEBAS DE SOFTWARE
Introduccin

En el presente documento se mostrar el resultado del anlisis de dos documentos

acerca de las especificaciones del diseo de pruebas.

El objetivo de dicho documento es comparar dos documentos formales de algunos

sistemas contra el estndar de la IEEE 829 y ver qu cosas tienen diferentes, si han
omitido algn punto, o bien, han agregado algn otro.
Al estar analizando el documento de especificacin del diseo de pruebas
Application Entities Interconectivity y compararlo con el estndar de la IEEE 829 se
lleg a la siguiente conclusin:

El objetivo que tiene este documento analizado es dar a conocer las

especificaciones del diseo de pruebas para el refinamiento de detalles de la prueba
presentada en el plan de pruebas para la prueba de interconectividad de General
Electric Advantage Review Workstation.

Entre la estructura fijada en el estndar nos encontramos que cumple con todos los
puntos marcados en el.

Cumple con el identificador el cual es el: 1.2.840.113702.1.3.13.1, este elemento a

nuestra consideracin es muy importante ya que es la manera de poder identificar
el documento ya que este debe ser nico.

En el punto dos se explica las caractersticas a probar, las que son comprobables y
el diseo de pruebas de esas caractersticas. Aqu se probar la capacidad de la
clase proveedor de servicios de este sistema.

Caractersticas a probar:

Conectividad TCP/IP bsica.

Asociacin abortar.
Repetitividad.

El punto cuatro para nosotros tambin es algo sumamente importante, ya que son
la identificacin de cada prueba, estas deben tener el id, los casos que se utilizaran
y que procedimiento se va a seguir. El cual el documento lo tiene muy bien detallado.

Ahora bien, en el cinco, son los criterios de paso/falla para lo establecido en el punto
anterior, este al igual que el punto cuatro tiene el id, el caso a probar y el criterio de
paso/falla.

Con estos puntos nos damos cuenta que este documento entregable cumple con lo
establecido en la estructura fijada en el estndar.
Sin embargo, ellos incluyen dos puntos ms.

Uno en el que mencionan los requisitos especiales, aqu si ocupa algn

requerimiento especial el software es bueno incluirlo y detallar bien las cosas, para
as poder llevar a cabo este procedimiento de la manera correcta, por eso creemos
que no siempre ser necesario incluirlo.

El otro punto que se incluye en el documento son los pasos del procedimiento que
tambin en algunos casos creemos que es bueno incluirlo, ya que toda
documentacin es buena para la correcta prctica, y bien, as tambin te ahorras
tiempo.
El segundo documento analizado fue el del proyecto MUPePe fase 1.

Analizando dicho documento nos dimos cuenta que este est muy apegado con el
documento estndar de la IEEE 829, ya que cuenta con los puntos establecidos en
dicho estndar.

Este documento tiene dos versiones hechas por el mismo autor.

Tiene un identificador de documento es: MPPTDS-001 y est asociado con un plan

de pruebas MPPTP-002. Por lo tanto cumple con ambos requisitos del punto 1.

En el punto dos, caractersticas a probar se detalla un caso de uso, que muestra la

funcionalidad bsica del programa. Y as mismo se detalla la caracterstica y
prioridad de la misma. Las cuales son:

Discutir: Alto
Crear discusin: Alto
Aadir usuarios a la discusin: Alto
Sugerir a s mismo a la discusin: Alto
Leer los registros: Bajo
Manipular archivos pblicos: Medio

En cuanto a las combinaciones son las siguientes:

Crear discusin, discuta

Crear discusin, Aadir usuario a la discusin, discuta
Sugerir a s mismo a la discusin, discuta

Con estas caractersticas nos damos cuenta que cumple muy bien con este punto
tambin.

En el punto tres son los detalles del plan de pruebas del que surge este diseo y las
tcnicas de prueba especfica.

Ellos los separaron por mdulos, poniendo a un responsable y una identificacin,

con esto se cumple la tcnica de la prueba y el mtodo de anlisis.
En la parte de identificacin de cada prueba mencionan que estn previstas apenas,
pero que faltan anexarlas.

Se podra decir que ese punto aunque no est omitido, no se cumple.

Por ultimo en los criterios de paso/falla, los clasifican de acuerdo a su gravedad.

Menor
Normal
Grave
Critico

Y se menciona que requisitos se deben cumplir para que dicha prueba pueda
considerarse pasada, de lo contrario se puede considerar un fallo.
En conclusin:

Este documento se puede considerar importante, ya que es una de las bases de las
pruebas, ya que en l se incluyen las caractersticas a probar de los elementos de
software, tanto como las combinaciones, adems se ponen los detalles de el plan
de pruebas del que surge el diseo y las tcnicas a seguir as como los mtodos
de anlisis de resultados, y aqu mismo se detalla cada prueba que se utilizar, su
id, caso que se va a utilizar y los procedimientos a seguir, para por ultimo establecer
qu criterios se utilizarn para determinar si una caracterstica o combinacin de
caractersticas ha pasado con xito la prueba o no.

Como sabemos, los estndares son buenos, tanto por que con l se puede a llegar
a tener una cierta calidad, como para poder llevar un control de cmo hacer las
cosas.

Como pudimos darnos cuenta con los anteriores documentos, los dos se apegan al
estndar de la IEEE 829. Ambos no omiten ningn punto, pero uno de ellos si agrega
unas cosas ms que para su consideracin eran importantes para su software.
Anexos:

Documento 1:

http://dicom.nema.org/dicom/geninfo/GUIDELIN/TDV2L3.HTM

Documento 2:

http://www.soberit.hut.fi/T-76.115/01-
02/palautukset/groups/MUPePe/t1/testing/test_design.html