Trabajo 4 ADS II
Trabajo 4 ADS II
4to Trabajo
ADS II.
Profesor: Alumno:
C.I: 25.561.120
Las personas pueden tener definiciones que difieren un poco entre sí, pero la
idea general es la misma.
También hay que tener en cuenta que a veces los equipos se organizan para
ejecutar conjuntos de pruebas. A estos grupos de pruebas se les conoce
como "test suites" e incluyen pruebas de los distintos tipos.
También ten en cuenta que en algunos casos los equipos deciden "armar su
propio vocabulario" y asignan nombres a sus grupos de tests.
2
3
Fundamentos en el diseño de documentaciones de sistemas.
Preparación de manuales
Durante el desarrollo de un sistema, desde su concepción hasta su puesta
en marcha se ha generado gran cantidad de documentos, que en muchas
ocasiones se han visto modificados por documentos posteriores debido a
cambios en el sistema.
Concreto.
Ser preciso y definir los términos utilizados.
Utilizar párrafos cortos.
Utilizar títulos y subtítulos.
Utilizar formas activas en lugar de pasivas.
No emplear frases largas que presenten hechos distintos.
No hacer referencia a una información solamente con el número de
referencia
4
4. Nombre del personal encargado del análisis y diseño del sistema.
Manual De Usuario
Expone los procesos que el usuario puede realizar con el sistema
implantado. Para lograr esto, es necesario que se detallen todas y cada una
de las características que tienen los programas y la forma de acceder e
introducir información. Permite a los usuarios conocer el detalle de qué
actividades ellos deberán desarrollar para la consecución de los objetivos del
sistema. Reúne la información, normas y documentación necesaria para que
el usuario conozca y utilice adecuadamente la aplicación desarrollada.
Objetivos
5
Los resultados de las operaciones realizadas a partir de los datos
introducidos.
Contenido
6
Cada actualización requiere un plan, y cada plan sigue el mismo proceso de
actualización básico.
Estrategias de actualización.
7
Métodos de prueba de software
Tipos de métodos
Los diferentes tipos de pruebas
1. Pruebas unitarias
Las pruebas unitarias son de muy bajo nivel y se realizan cerca de la fuente
de la aplicación. Consisten en probar métodos y funciones individuales de las
clases, componentes o módulos que usa tu software. En general, las pruebas
unitarias son bastante baratas de automatizar y se pueden ejecutar
rápidamente mediante un servidor de integración continua.
2. Pruebas de integración
8
puede probar la interacción con la base de datos o asegurarse de que los
microservicios funcionan bien en conjunto y según lo esperado. Estos tipos
de pruebas son más costosos de ejecutar, ya que requieren que varias
partes de la aplicación estén en marcha.
3. Pruebas funcionales
Las pruebas integrales son muy útiles, pero son costosas de llevar a cabo y
pueden resultar difíciles de mantener cuando están automatizadas. Se
recomienda tener algunas pruebas integrales clave y depender más de
pruebas de menor nivel (unitarias y de integración) para poder detectar
rápidamente nuevos cambios.
5. Pruebas de aceptación
9
6. Pruebas de rendimiento
7. Pruebas de humo
Las pruebas de humo son pruebas básicas que sirven para comprobar el
funcionamiento básico de la aplicación. Están concebidas para ejecutarse
rápidamente, y su objetivo es ofrecerte la seguridad de que las principales
funciones de tu sistema funcionan según lo previsto.
Las pruebas de humo pueden resultar útiles justo después de realizar una
compilación nueva para decidir si se pueden ejecutar o no pruebas más
caras, o inmediatamente después de una implementación para asegurarse
de que la aplicación funciona correctamente en el entorno que se acaba de
implementar.
Características
Las pruebas de software siguen un proceso en común. Las tareas o pasos
incluyen definir el entorno de prueba, desarrollar casos de prueba, desarrollar
scripts, analizar los resultados de las pruebas y enviar los informes de los
defectos.
Las pruebas pueden llevar mucho tiempo. Las pruebas manuales o las
pruebas ad-hoc pueden ser suficientes para compilaciones pequeñas. Sin
embargo, para sistemas más grandes, se utilizan con frecuencia
herramientas para automatizar las tareas. Las pruebas automatizadas
ayudan a los equipos a implementar diferentes escenarios, probar
diferenciadores (como mover componentes a un entorno de nube) y obtener
rápidamente comentarios sobre lo que funciona y lo que no.
10
embargo, las soluciones de los proveedores ofrecen características que
pueden agilizar las tareas clave de administración de pruebas, tales como:
11
Es probable que el nivel de importancia tecnológica determine el grado de
rigor aplicado a la verificación, prueba y mantenimiento de la tecnología.
Para un sistema que va a ser utilizado en una función electoral clave, como
una votación electrónica, el nivel de rigor requerido será mayor.
Verificación
Probar los equipos bajo condiciones que simulen las de operación real.
Probar los programas para asegurar que se siguen los estándares
apropiados y que desempeñan las funciones esperadas.
Asegurar que la documentación sea la adecuada y esté completa.
Asegurar que los sistemas de comunicación se ciñan a los estándares
establecidos y funcionen de manera efectiva.
Verificar que los sistemas sean capaces de operar bajo condiciones
normales, pero también bajo potenciales condiciones inesperadas.
Asegurar que se cuente con las debidas medidas de seguridad y que estas
se ciñan a las normas establecidas.
Asegurar que la calidad
Prueba
12
Aplicar pruebas funcionales para determinar si se han satisfecho los criterios
de prueba.
Aplicar evaluaciones de calidad para determinar si se han satisfecho los
criterios de prueba.
Conducir pruebas en condiciones de "laboratorio" y en una variedad de
condiciones "reales".
Conducir pruebas durante un periodo prolongado, para cerciorarse que los
sistemas pueden funcionar de manera consistente.
Conducir "pruebas de carga", simulando tanto como sea posible una
variedad de condiciones reales utilizando o excediendo los volúmenes de
información que se pueden esperar en una situación concreta.
Verificar que lo que entra es lo que sale, introduciendo información conocida
y verificando que el resultado sea consecuente con ella.
Mantenimiento
Consumo de Recursos
Esta sub-característica principal se refiere a la capacidad del producto de
software para utilizar una apropiada cantidad y tipos de recursos cuando el
software desempeña su función bajo condiciones establecidas. Los recursos
humanos están incluidos como parte de la productividad.
13
Consumo de Recursos
Documentación.
En general se habla mucho de la documentación, pero no se la hace, no se
le asigna presupuesto, no se la mantiene y casi nunca está al día en los
proyectos de desarrollo de software.
Muchas veces se hace porque hay que hacerla y se escribe, con pocas
ganas, largos textos, a la vez que se está convencido de estar haciendo un
trabajo inútil.
A veces se peca por exceso y otras por defecto. Ocurre mucho en la Web y
con productos RAD. En ocasiones se olvida que el mantenimiento también
debe llegar a la documentación.
14
Hay decenas de notaciones, tanto estructuradas como orientadas a objetos.
Un caso particular es el de UML, que analizamos en otra obra. De todas
maneras, los diagramas son muy útiles, pero siempre y cuando se
mantengan actualizados, por lo que más vale calidad que cantidad.
15
Es incluso deseable proveer un software tutorial que guíe al usuario en el uso
del sistema, con apoyo multimedia, y que puede llegar a ser un curso online.
Buena parte de la documentación para los usuarios puede empezar a
generarse desde que comienza el estudio de requisitos del sistema. Esto
está bastante en consonancia con las ideas de extreme programming y con
metodologías basadas en casos de uso.
Es necesario que tenga una descripción de los errores posibles del sistema,
así como los procedimientos de recuperación. Como esto no es algo estático,
pues la aparición de nuevos errores, problemas de compatibilidad y demás
nunca se puede descartar, en general el manual de operaciones es un
documento que va engrosándose con el tiempo.
16
Conclusión
Así como es importante verificar que nuestros usuarios pueden usar nuestra
aplicación (pueden iniciar sesión, enviar mensajes, y/o actualizar datos), es
igual de importante verificar que nuestro sistema siga funcionando
adecuadamente cuando se ingresen datos incorrectos o se realicen acciones
inesperadas.
Entonces:
17
Bibliografía
- https://aceproject.org/main/espanol/et/ete05.htm
18
INDICE
Introducción 2
Fundamentos en el diseño de documentaciones de sistemas. 4
Preparación de manuales 4
Manual del Sistema 4
Manual De Usuario 5
Estrategias de actualización. 7
Métodos de prueba de software 8
Tipos de métodos 8
Características 10
Métodos de evaluación y verificación 11
Consumo de Recursos 13
Documentación. 14
Conclusión 17
Bibliografía 18
19