Flashcards
Ing. de Software 2025
Flashcards do conjunto (67)
- 1Metas del proceso de pruebas de Software1.- Demostrar al desarrollador y al cliente que el sw cumple con los requerimientos.
2.- Encontrar comportamientos donde el sw sea incorrecto, indeseable o no esté de acuerdo con sus especificaciones - 2Conduce a la prueba de Validación; en ella se espera que el sistema se desempeñe de manera correcta mediante un conjunto dado de casos de prueba, que refleje el uso previo del sistemaLa Primera Meta .- Demostrar al desarrollador y al cliente que el software cumple con los requerimientos
- 3Meta que se orienta a pruebas de defectos. Los casos de pruebas en las pruebas de defecto pueden ser deliberadamente confusos y no necesitan expresar como se usa normalmente el sistemaLa segunda meta .- Encontrar situaciones donde el comportamiento del sw sea incorrecto, indeseable o no esté de acuerdo a sus especificaciones.
- 4Pueden mostrar solo la presencia de errores, más no su ausenciaLas pruebas
- 5Buscan comprobar que el software por desarrollar cumpla con sus especificaciones, y brinde la funcionalidad deseada por las personas que pagan por élLos procesos de verificación y validación
- 6La finalidad de la _______ es comprobar que el software cumpla con su funcionalidad y con los requerimientos no funcionales establecidosverificación
- 7La meta de la _________ es garantizar que el software cumpla con las expectativas del clientevalidación
- 8Objetivo final de los procesos de verificación y validaciónEstablecer confianza de que el sistema software es adecuado.
- 9Técnica del proceso de verificación y validación que implicaría inspecciones y revisiones del software.Técnicas V&V estáticas
- 10Analiza y comprueban los requerimientos del sistema, los modelos de diseño, el código fuente del programa, e incluso las pruebas propuestas para el sistema.Las técnicas v&V estáticas
- 11Son especificaciones de las entradas a las prueba y la salida esperada del sistema.Los casos de prueba
- 12Son las entradas que se diseñaron para probar un sistemaLos datos de prueba
- 13Por lo general, un sistema de software comercial debe pasar por tres etapas de pruebas:1.- Pruebas de desarrollo
2.- Versiones de pruebas
3.- Pruebas de usuario - 14Prueba donde el sistema se pone a prueba durante el proceso para descubrir errores (buggs) y defectosPruebas de desarrollo
- 15Prueba donde un equipo de prueba por separado experimenta una versión completa del sistema, antes de presentarlo a los usuariosVersiones de prueba
- 16Prueba donde los usuarios reales o potenciales de un sistema prueban el sistema en su propio entornoPruebas de usuario
- 17Durante el desarrollo, las pruebas se realizan en tres niveles de granulación1.- Pruebas de unidad
2.- Pruebas del componente
3.- Pruebas del sistema - 18Son el proceso de probar componentes del programa, como métodos o clases de objetosPruebas de unidad
- 19Prueba donde muchas unidades individuales se integran para crear componentes compuestosPruebas del componente
- 20Prueba donde algunos o todos los componentes en un sistema se integran y el sistema se prueba por un todoPruebas del sistema
- 21Un conjunto automatizado de pruebas tiene tres partes1.- Una parte de configuración
2.- Una parte de llamada (call)
3.- Una parte de declaración - 22Es la parte en la cual se inicializa el sistema con el caso de pruebas, esto es, las entradas y salidas esperadasParte de Configuración de un conjunto automatizado de pruebas
- 23Es la parte en la cual se llama al objeto o al método que se va a probarParte de llamada Call de un conjunto automatizado de pruebas
- 24Parte en la cual se compara el resultado de la llamada con el resultado esperado. Si la información se evalúa como verdadera, la prueba tuvo excito, de lo contrario fracaso.Parte de Declaración de un conjunto automatizado de pruebas
- 25Estrategias posibles que serían efectivas para ayudarle a elegir casos de prueba.1.- Pruebas de partición
2.- Pruebas basadas en lineamientos - 26Estrategia donde se identifican grupos de entradas con características comunes y se procesan de la misma forma.Pruebas de partición
- 27Estrategia donde se usan lineamientos para elegir los casos de prueba. Dichos lineamientos reflejan la experiencia previa de los tipos de errores que suelen cometer los programadores al desarrollar componentes.Pruebas basadas en lineamientos
- 28Sirve para diseñar casos de prueba tanto para sistemas como para componentesLa prueba de partición
- 29Es un enfoque efectivo para las pruebas, porque ayuda a explicar los errores que cometen con frecuencia los programadores al procesar entradas en los bordes de las particionesLa partición de equivalencia
- 30Los lineamientos de prueba encapsulan conocimiento sobre que tipos de casos de pruebas son efectivos para la detección de errores. Lineamientos que pueden ayudar a revelar defectos?1.- Probar software con secuencias que tengan solo un valor único
2.- Usar diferentes secuencias de diversos tamaños en distintas pruebas
3.- Derivar pruebas de modo que se acceda a los elementos primero, medio y ultimo - 31Prueba que tiene que enfocarse en mostrar que la interfaz de componente se comporta según su especificaciónPrueba de componentes compuestos
- 32Existen diferentes tipos de Interfaz entre componentes de programas1.- Interfaces de Parametro
2.- Interfaces de memoria compartida
3.- Interfaces de procedimiento
4.- Interfaces que pasan mensaje - 33Son interfaces en que los datos, o en ocasiones referencias de función, pasan de un componente a otroInterfaz de parametro
- 34Son interfaces en que un bloque de memoria se reparte entre componentes. Los datos se colocan en la memoria de un subsistema y otros subsistemas lo recuperan de haí. Se usa con frecuencia en Sistemas embebidosInterfaces de memoria compartida
- 35Son interfaces en que un componente encapsula un conjunto de procedimientos que pueden ser llamados por otros componentes.Interfaces de procedimiento
- 36Se trata de interfaces donde, al enviar un mensaje, un componente solicita un servicio de otro componenteInterfaces que pasan mensaje
- 37Los errores de interfaz, son las formas más comunes de falla en los sistemas complejos. Dichos errores caen en tres clases:1.- Uso incorrecto de interfaz
2.- Mala interpretación de interfaz
3.- Errores de temporización - 38Un componente que llama a otro componente y comete algún error en e uso de interfaz. Es común en interfaces de parámetro.Uso incorrecto de interfaz
- 39Un componente que mal interpreta la especificación de la interfaz del componente llamado y hace suposiciones sobre su comportamientoMala interpretación de interfaz
- 40Ocurren en sistemas de tiempo real que usan una memoria compartida o una interfaz que pasa mensajes. El productor y el consumidor de datos operan a diferentes niveles de rapidezErrores de temporizacion
- 41Implica integrar diferentes componentes y, despúes, probar el sistema integrado que se creó.Pruebas del sistema
- 42Demuestran que los componentes son compatibles, que interactúan correctamente y que transfieren los datos correctos en el momento adecuado a través de sus interfaces.Pruebas del sistema
- 43Es un enfoque al diseño de programas donde se entrelazan el desarrollo de pruebas y el de código (Beck, 2002; Jeffries y Melnik, 2007)Desarrollo dirigido por pruebas
(Test-Driven Development TDD) - 44Se introdujo como parte de los métodos ágiles como la programación externa. Resulta ser exitoso para proyectos de dimensión pequeña y mediana.Desarrollo dirigido por pruebas
(Test-Driven Development TDD) - 45Beneficios del Desarrollo Dirigido por Pruebas TDD1.- Cobertura de código
2.- Pruebas de regresión
3.- Depuración simplificada
4.- Documentación del sistema - 46Beneficio del Desarrollo Dirigido por Pruebas TDD En principio, cualquier segmento de código que escriba debe tener al menos una prueba asociadaCobertura de código
- 47Beneficio del Desarrollo Dirigido por Pruebas TDD Un conjunto de pruebas se desarrolla incrementalmente conforme se desarrolla un programa. Se realizan para demostrar que los cambios al programa no introdujeron nuevos bugs al sistemaPruebas de regresión
- 48Beneficio del Desarrollo Dirigido por Pruebas TDD Cuando falla una prueba, debe ser evidente donde yace el problema. Es preciso comprobar y modificar el código recién escrito.Depuración simplificada
- 49Beneficio del Desarrollo Dirigido por Pruebas TDD Las pruebas en sí actúan como una forma de documentación que describen lo que debe hacer el códigoDocumentación del sistema
- 50Son el proceso de poner a prueba una versión particular de un sistema que se pretende usar fuera del equipo de desarrolloPruebas de versión
- 51Son un proceso de prueba de caja negra, donde las pruebas se derivan a partir de las especificación del sistema. Su principal meta es convencer al proveedor del sistema de que éste suficientemente apto para su usoPruebas de versión
- 52Son pruebas de validación más que de defecto: se intenta demostrar que el sistema implementó adecuadamente sus requerimientosPruebas basadas en requerimientos
- 53Son un enfoque a las pruebas de versión donde se crean escenarios típicos de uso y se le utiliza en el desarrollo de casos de prueba para el sistema.Pruebas de escenario
- 54Una vez integrado completamente el sistema, es posible probar propiedades emergentes. Pruebas que deben diseñarse para garantizar que el sistema procese su carga pretendida.Pruebas de rendimiento
- 55Funciones de las pruebas de rendimiento1.- Prueba el comportamiento de falla del sistema
2.- Fuerza al sistema y puede hacer que salga a la luz defectos que no descubrirían normalmente - 56Las ___________ son una etapa en el proceso de pruebas donde los usuarios o clientes proporcionan entrada y asesoría sobre las pruebas del sistema.Pruebas de usuario o del cliente
- 57En la práctica hay tres diferentes tipos de pruebas de usuarios:1.- Pruebas Alfa
2.- Pruebas Beta
3.- Pruebas de Aceptación - 58Prueba de Usuario donde los usuarios del software trabajan con el equipo de diseño para probar el software en el sitio del desarrolladorPruebas Alfa
- 59Prueba de Usuario donde una versión del software se pone a disposición de los usuarios, para permitirles experimentar y descubrir problemas que encuentran con los desarrolladores del sistemaPruebas Beta
- 60Prueba de Usuario donde los clientes prueban un sistema para decidir si está o no listo para ser aceptado por los desarrolladores del sistema y desplegado en el entorno del clientePruebas de Aceptación
- 61Etapas en el proceso de pruebas de aceptación1.- Definir los criterios de la aceptación
2.- Plan de pruebas de aceptación
3.- Derivar pruebas de aceptación
4.- Correr pruebas de aceptación
5.- Negociar los resultados de las pruebas
6.- Rechazo/aceptación del sistema - 62Esta etapa debe anticiparse antes de firmar el contrato del sistema y tienen que convenirse entre el cliente y el desarrolladorDefinir los criterios de aceptación
- 63Esta etapa incluye decidir sobre los recursos, el tiempo y el presupuesto para las pruebas de aceptación, así como establecer el calendario de pruebasPlan de pruebas de aceptación
- 64Etapa que consta de diseñar pruebas para comprobar si un sistema es aceptable o no.Derivar pruebas de aceptación
- 65Etapa donde las pruebas de aceptación acordadas se ejecutan sobre el sistemaCorrer pruebas de aceptación
- 66Etapa en la que es poco probable que se pasen todas las pruebas de aceptación definidas y que no haya problemas en el sistemaNegociar los resultados de las pruebas
- 67Esta etapa incluye una reunión entre los desarrolladores y el cliente para decidir si el sistema debe aceptarse o no.Rechazo/aceptación del sistema