El documento habla sobre la gestión de pruebas en el desarrollo de software. Explica que todas las piezas de software necesitan pruebas para identificar errores. Detalla diferentes tipos de pruebas como pruebas de unidad, integración y aceptación. También cubre técnicas de prueba como pruebas funcionales, estructurales y no funcionales. El documento enfatiza la importancia de basar las pruebas en una especificación clara y de monitorear métricas como errores encontrados y cobertura de código.
Las Pruebas de Software son todavía una de las áreas más desatendidas del desarrollo y espliegue de los productos de software. Las Pruebas de Software son predominantemente vistas como una actividad periférica, casi una formalidad, antes del espliegue del software. Un cambio de actitud y un buen programa de estudios como fundamento hacia las Pruebas de Software pueden reducir tremendamente los problemas normalmente asociados con el lanzamiento del nuevo software y minimizar el riesgo implicado. El programa de estudio del ISTQB (International Software Testing Qualifications Board) Probador Certificado (Certified Tester) ofrece el mejor
entrenamiento estandarizado del mundo para los probadores de software.
Este libro le proporcionará el conocimiento esencial para ser un profesional en Pruebas, que incluye:
Fundamentos de Pruebas
Pruebas a través del Ciclo de Vida de Software
Técnicas Estáticas
Técnicas de Diseño de Pruebas
Gestión de Pruebas
Soporte de las Herramientas de Pruebas
Adquisición de Herramientas y Software en General en una Organización
Más de 200 preguntas de examen de muestra con soluciones
Ejercicios prácticos y soluciones por cada tema cubierto
Caso real, resuelto, como ejemplo a lo largo de los temas
Dos exámenes de simulación del examen real
Estándares de Pruebas
Excelente Bibliografía
Cabe señalar que este libro no es sólo para los probadores sino también para quienes están encargados de la adquisición de software en general, gerentes de tecnología, gerentes del Aseguramiento de la Calidad/Control de la Calidad (QA/QC), gerentes de sistemas, jefes de proyectos de software, analistas, arquitectos, desarrolladores, estudiantes y profesores de TI.
Asimismo este libro está diseñado para el autoestudio. El contenido comprende el programa de estudios necesario para aprobar el examen de certificación nivel básico definido por el ISTQB versión 2011 (Syllabus 2011).
Las Pruebas de Software son todavía una de las áreas más desatendidas del desarrollo y espliegue de los productos de software. Las Pruebas de Software son predominantemente vistas como una actividad periférica, casi una formalidad, antes del espliegue del software. Un cambio de actitud y un buen programa de estudios como fundamento hacia las Pruebas de Software pueden reducir tremendamente los problemas normalmente asociados con el lanzamiento del nuevo software y minimizar el riesgo implicado. El programa de estudio del ISTQB (International Software Testing Qualifications Board) Probador Certificado (Certified Tester) ofrece el mejor
entrenamiento estandarizado del mundo para los probadores de software.
Este libro le proporcionará el conocimiento esencial para ser un profesional en Pruebas, que incluye:
Fundamentos de Pruebas
Pruebas a través del Ciclo de Vida de Software
Técnicas Estáticas
Técnicas de Diseño de Pruebas
Gestión de Pruebas
Soporte de las Herramientas de Pruebas
Adquisición de Herramientas y Software en General en una Organización
Más de 200 preguntas de examen de muestra con soluciones
Ejercicios prácticos y soluciones por cada tema cubierto
Caso real, resuelto, como ejemplo a lo largo de los temas
Dos exámenes de simulación del examen real
Estándares de Pruebas
Excelente Bibliografía
Cabe señalar que este libro no es sólo para los probadores sino también para quienes están encargados de la adquisición de software en general, gerentes de tecnología, gerentes del Aseguramiento de la Calidad/Control de la Calidad (QA/QC), gerentes de sistemas, jefes de proyectos de software, analistas, arquitectos, desarrolladores, estudiantes y profesores de TI.
Asimismo este libro está diseñado para el autoestudio. El contenido comprende el programa de estudios necesario para aprobar el examen de certificación nivel básico definido por el ISTQB versión 2011 (Syllabus 2011).
software testing, Regression testing meaning,
requirement of regression testing,
techniques of regression testing:- hybrid, retest all, Test case prioritization, Regression test selection.
pros and cons of using regression testing,
tools for regression testing :-
Relational Functional Tester(RFT)
Quick Test Professional (QTP)
selenium
Las Pruebas de Software son todavía una de las áreas más desatendidas del desarrollo y espliegue de los productos de software. Las Pruebas de Software son predominantemente vistas como una actividad periférica, casi una formalidad, antes del espliegue del software. Un cambio de actitud y un buen programa de estudios como fundamento hacia las Pruebas de Software pueden reducir tremendamente los problemas normalmente asociados con el lanzamiento del nuevo software y minimizar el riesgo implicado. El programa de estudio del ISTQB (International Software Testing Qualifications Board) Probador Certificado (Certified Tester) ofrece el mejor
entrenamiento estandarizado del mundo para los probadores de software.
Este libro le proporcionará el conocimiento esencial para ser un profesional en Pruebas, que incluye:
Fundamentos de Pruebas
Pruebas a través del Ciclo de Vida de Software
Técnicas Estáticas
Técnicas de Diseño de Pruebas
Gestión de Pruebas
Soporte de las Herramientas de Pruebas
Adquisición de Herramientas y Software en General en una Organización
Más de 200 preguntas de examen de muestra con soluciones
Ejercicios prácticos y soluciones por cada tema cubierto
Caso real, resuelto, como ejemplo a lo largo de los temas
Dos exámenes de simulación del examen real
Estándares de Pruebas
Excelente Bibliografía
Cabe señalar que este libro no es sólo para los probadores sino también para quienes están encargados de la adquisición de software en general, gerentes de tecnología, gerentes del Aseguramiento de la Calidad/Control de la Calidad (QA/QC), gerentes de sistemas, jefes de proyectos de software, analistas, arquitectos, desarrolladores, estudiantes y profesores de TI.
Asimismo este libro está diseñado para el autoestudio. El contenido comprende el programa de estudios necesario para aprobar el examen de certificación nivel básico definido por el ISTQB versión 2011 (Syllabus 2011).
U.T.N. - F.R.T. Cátedra de Diseño de Sistemas. 3K1. 2011. Unidad VI. Verificación y Validación del Diseño. Pruebas del Software. Ian Sommerville, Cap. 23
software testing, Regression testing meaning,
requirement of regression testing,
techniques of regression testing:- hybrid, retest all, Test case prioritization, Regression test selection.
pros and cons of using regression testing,
tools for regression testing :-
Relational Functional Tester(RFT)
Quick Test Professional (QTP)
selenium
Las Pruebas de Software son todavía una de las áreas más desatendidas del desarrollo y espliegue de los productos de software. Las Pruebas de Software son predominantemente vistas como una actividad periférica, casi una formalidad, antes del espliegue del software. Un cambio de actitud y un buen programa de estudios como fundamento hacia las Pruebas de Software pueden reducir tremendamente los problemas normalmente asociados con el lanzamiento del nuevo software y minimizar el riesgo implicado. El programa de estudio del ISTQB (International Software Testing Qualifications Board) Probador Certificado (Certified Tester) ofrece el mejor
entrenamiento estandarizado del mundo para los probadores de software.
Este libro le proporcionará el conocimiento esencial para ser un profesional en Pruebas, que incluye:
Fundamentos de Pruebas
Pruebas a través del Ciclo de Vida de Software
Técnicas Estáticas
Técnicas de Diseño de Pruebas
Gestión de Pruebas
Soporte de las Herramientas de Pruebas
Adquisición de Herramientas y Software en General en una Organización
Más de 200 preguntas de examen de muestra con soluciones
Ejercicios prácticos y soluciones por cada tema cubierto
Caso real, resuelto, como ejemplo a lo largo de los temas
Dos exámenes de simulación del examen real
Estándares de Pruebas
Excelente Bibliografía
Cabe señalar que este libro no es sólo para los probadores sino también para quienes están encargados de la adquisición de software en general, gerentes de tecnología, gerentes del Aseguramiento de la Calidad/Control de la Calidad (QA/QC), gerentes de sistemas, jefes de proyectos de software, analistas, arquitectos, desarrolladores, estudiantes y profesores de TI.
Asimismo este libro está diseñado para el autoestudio. El contenido comprende el programa de estudios necesario para aprobar el examen de certificación nivel básico definido por el ISTQB versión 2011 (Syllabus 2011).
U.T.N. - F.R.T. Cátedra de Diseño de Sistemas. 3K1. 2011. Unidad VI. Verificación y Validación del Diseño. Pruebas del Software. Ian Sommerville, Cap. 23
03 gestión de pruebas de software diseño de casos de pruebasAntonio Quiña
Un caso de prueba es un conjunto de entradas, condiciones de ejecución y resultados esperados, desarrollado para conseguir un objetivo particular o condición de prueba. Ejemplo: verificar el cumplimiento de un requisito específico
Presentación Corporativa del CITIC (Centro de Investigación en Tecnoogías de la Información y las Comunicaciones).
El CITIC es un Centro Tecnológico impulsado por la Universidade da Coruña, para fomentar la I+D+i aplicada en las TIC y ubicado en el Parque Tecnológico de la UDC, Campus de Elviña.
El Centro es un punto de encuentro entre Universidad y Empresa en la que se combinan departamentos de I+D de empresas con investigadores universitarios, constituyendo un entorno mixto que posibilita la colaboración y la transferencia de conocimientos.
Enfoque estrategico para la prueba de softwareJorge Bustillos
Pruebas de software.
Características de estrategias de prueba.
Verificación y Validación.
Organización para la prueba de software.
Estrategias de prueba de software
Estrategias.
Criterios para completar la prueba.
Prueba de Unidad.
Prueba de Integración.
Prueba de Validación.
Las Pruebas de Software son todavía una de las áreas más desatendidas del desarrollo y espliegue de los productos de software. Las Pruebas de Software son predominantemente vistas como una actividad periférica, casi una formalidad, antes del espliegue del software. Un cambio de actitud y un buen programa de estudios como fundamento hacia las Pruebas de Software pueden reducir tremendamente los problemas normalmente asociados con el lanzamiento del nuevo software y minimizar el riesgo implicado. El programa de estudio del ISTQB (International Software Testing Qualifications Board) Probador Certificado (Certified Tester) ofrece el mejor
entrenamiento estandarizado del mundo para los probadores de software.
Este libro le proporcionará el conocimiento esencial para ser un profesional en Pruebas, que incluye:
Fundamentos de Pruebas
Pruebas a través del Ciclo de Vida de Software
Técnicas Estáticas
Técnicas de Diseño de Pruebas
Gestión de Pruebas
Soporte de las Herramientas de Pruebas
Adquisición de Herramientas y Software en General en una Organización
Más de 200 preguntas de examen de muestra con soluciones
Ejercicios prácticos y soluciones por cada tema cubierto
Caso real, resuelto, como ejemplo a lo largo de los temas
Dos exámenes de simulación del examen real
Estándares de Pruebas
Excelente Bibliografía
Cabe señalar que este libro no es sólo para los probadores sino también para quienes están encargados de la adquisición de software en general, gerentes de tecnología, gerentes del Aseguramiento de la Calidad/Control de la Calidad (QA/QC), gerentes de sistemas, jefes de proyectos de software, analistas, arquitectos, desarrolladores, estudiantes y profesores de TI.
Asimismo este libro está diseñado para el autoestudio. El contenido comprende el programa de estudios necesario para aprobar el examen de certificación nivel básico definido por el ISTQB versión 2011 (Syllabus 2011).
Automatic generation of UML sequence diagrams from test counterexamplesLaura M. Castro
In this paper, we present a tool to automatically transform test counterexamples, as produced by test automation tools like QuickCheck, into UML sequence diagrams.
It is intended to ease debugging, and improve both documentation and communication between stakeholders of the software development process.
Estas slides son una presentación a las pruebas de software. Para qué sirven, qué tipos de pruebas existen, qué librerías, frameworks y herramientas se pueden utilizar para implemenar pruebas automatizadas, etc.
Siguiendo con los apuntes de Ingeniería de Software para la Ingeniería en Computación, de la Universidad Tecnologica de la Mixteca en Huajuapan de León, Oaxaca México.
Presentacion sobre cómo elaborar procesos de QA en proyectos de desarrollo de software desde una etapa temprana hasta la validación final del software.
Se realizará caso práctico con Selenium.
Ola, ChatGPT... que carreira sería boa para min?Laura M. Castro
Cumprimos case un ano da popularización das intelixencias artificiais xeneradoras en xeral, e ChatGPT en particular.
Nesta presentación exploramos os nesgos poden apresentarse nas respostas producidas por estes sistemas, a fin de visibilizar, divulgar e sensibilizar ao respecto.
Introdución histórica e de alto nivel á evolución da IA, e a popularidade actual das IAs xerativas ou xeradoras de contido, e presentación dun caso de estudo sobre os nesgos de xénero en ChatGPT.
As intelixencias artificiais como xeradoras de cultura: exploración dos nesgo...Laura M. Castro
As intelixencias artificiais xeneradoras están xa producindo textos que pasan a formar parte do noso mundo. A lingua (escrita, neste caso) é un piar fundamental da cutura, polo que cabe preguntarnos que tipo de "axentes creadores de cultura" son estes sistemas.
Para visibilizar esta cuestión, preséntase un experimento que ten como protagonista ChatGPT e como contexto, as mulleres (novas) en STEM.
David vs. Goliat: lecciones aprendidas de una experiencia fallida de adopción...Laura M. Castro
Cryptpad (https://cryptpad.org) es una alternativa a plataformas privativas de almacenamiento y edición colaborativa en la nube de documentos.
En 2022, en una pequeña asociación cultural gallega (Semente Corunha) decidimos adoptar Cryptpad como herramienta. Lamentablemente, meses después tuvimos que reconocer nuestro fracaso.
Esta charla pretende ilustrar las razones que condujeron al desenlace, desde un punto de vista constructivo, que pueda servir de inspiración y aprendizaje para la comunidad.
We all have heard that functional programming requires a change of mind. But... do we really know what does mean? How does it go beyond learning about pattern-matching, tail recursion, gen_server and supervisors? How does it reflect in the way we approach problems and design solutions? We will address these and other questions, and discuss to which extent our BEAM hammer can turn everything into a lightweight, concurrent nail.
Elixir é unha desas linguaxes que soan moito nos últimos tempos, un dos 'new cool kids on the block'. Nesta charla, vemos unha introdución a Elixir desde a perspectiva de quen está familiarizada/o co mundo Java: teñen algo en común? cales son as diferenzas? Quen sabe... se tes demasiada cafeína no teu sistema, quizais te animes a probar esta nova brebaxe!
This is a short introduction to one of the newest and noisiest additions to the functional family. Chances are you have heard about Elixir before: created six years ago by José Valim, it has emerged rapidly in the Erlang ecosystem, attracting lots of attention. But what's so special about it? What's all the fuzz about? This talk will offer you a few selected sips for you to get a taste... but beware! You may want to drink all the bottle: if so, you may end up following the white rabbit down the hole and wake up in the Erlang wonderland.
Making property-based testing easier to read for humansLaura M. Castro
Agile practices have taught us that both stakeholder involvement and early testing are key to quality software. However, it is usually the case that tools for good communication are not that good for testing, and vice-versa.
In this talk, readSpec (one of the results of the PF7 EU PROWESS project) is presented, a tool that attempts to fill in this gap.
Erlang as a supporting technology for teaching Software ArchitectureLaura M. Castro
At university, it is usually the case that students are introduced to programming languages to the extent in which they serve a teaching purpose usually related to acquiring some paradigm-bounded programming skills. Thus, they (we) learn to code our first source lines using PASCAL, are introduced to C programming to handle memory and threads, enter the Java world hand-in-hand with UML and object-orientation. However, Erlang is seldom the choice for learning about the declarative paradigm, for which ML or Haskell are often preferred candidates.
Two years ago, the University of A Coruña (UDC) stepped out of this box and decided to use Erlang as supporting technology for teaching Software Architecture. In this subject, we go beyond programming and, in helping students build up a more abstract, system-wide design competence, we make them face the strengths and weaknesses of different architectures (client-server, multi-layered, repository, pipe & filter, master-slave, peer-to-peer) in terms of non-functional requirements (availability, flexibility, performance, security). In this setting, Erlang has worked as an excellent tool in order to quickly prototype and compare systems of different architectural nature, as we will illustrate in more detail during this talk.
A Backpack to go the Extra-Functional Mile (a hitched hike by the PROWESS pro...Laura M. Castro
Property-based testing is an already known testing methodology for the Erlang community, with tools such as QuickCheck and PropEr being highly popular among Erlang developers in the last few years. However, they are commonly used for functional testing... Which are the challenges in using them for testing non-functional properties of software? What other tools or libraries are there to help Erlang developers?
Experiencias Industriales con Programación DeclarativaLaura M. Castro
Building software imposes a set of general challenges, which are complemented by those specific to the business context. The use of declarative programming as key implementation technology provides several advantages in both areas, a fact that has not gone unnoticed by companies of all sizes and domains.
In particular, the functional programming language Erlang is getting big momentum in the last years thanks to its built-in capabilities for high availability, robustness, maintainability.
This presentation shows some practical examples and discusses the role that the implementation technology (Erlang) played in their successful outcome.
Functional programming goes to Hollywood... and around the world!Laura M. Castro
In a moment in which clearly declarative languages and functional programming use are on the increase in industry, this is a recap of the most recent success stories of the MADS (Models and Applications of Distributed Systems) research group, at the Department of Computer Science (University of A Coruña, Spain) in this area.
Failover and takeover contingency mechanisms for network partition and node f...Laura M. Castro
Proper definition of suitable mechanisms to cope with network partition and to recover from node failure are among the most common problems when designing and implementing a fault-tolerant distributed system. The concern is even more serious when the different scenarios could not be predicted beforehand and are detected once the system is at deployment stage.
There are a number of decisions that can be made when choosing the right contingency mechanisms to deal with these distribution-bounded problems. The factors that must be taken into account include not only the technology in use, the node layout, the message protocol and the properties of the messages to be exchanged, certain desired/demanded features such as latency, bandwidth,... but also the communications network reliability, and even the hardware where the system is running on.
In this paper we present ADVERTISE, a distributed system for advertisement transmission to on-customer-home set-top boxes (STBs) over a Digital TV network (iDTV) of a cable operator. We use this system as a case study to explain how we addressed the aforementioned problems, and present a set of good practices that can be extrapolated to comparable systems.
3Redu: Responsabilidad, Resiliencia y Respetocdraco
¡Hola! Somos 3Redu, conformados por Juan Camilo y Cristian. Entendemos las dificultades que enfrentan muchos estudiantes al tratar de comprender conceptos matemáticos. Nuestro objetivo es brindar una solución inclusiva y accesible para todos.
(PROYECTO) Límites entre el Arte, los Medios de Comunicación y la Informáticavazquezgarciajesusma
En este proyecto de investigación nos adentraremos en el fascinante mundo de la intersección entre el arte y los medios de comunicación en el campo de la informática.
La rápida evolución de la tecnología ha llevado a una fusión cada vez más estrecha entre el arte y los medios digitales, generando nuevas formas de expresión y comunicación.
Continuando con el desarrollo de nuestro proyecto haremos uso del método inductivo porque organizamos nuestra investigación a la particular a lo general. El diseño metodológico del trabajo es no experimental y transversal ya que no existe manipulación deliberada de las variables ni de la situación, si no que se observa los fundamental y como se dan en su contestó natural para después analizarlos.
El diseño es transversal porque los datos se recolectan en un solo momento y su propósito es describir variables y analizar su interrelación, solo se desea saber la incidencia y el valor de uno o más variables, el diseño será descriptivo porque se requiere establecer relación entre dos o más de estás.
Mediante una encuesta recopilamos la información de este proyecto los alumnos tengan conocimiento de la evolución del arte y los medios de comunicación en la información y su importancia para la institución.
Actualmente, y debido al desarrollo tecnológico de campos como la informática y la electrónica, la mayoría de las bases de datos están en formato digital, siendo este un componente electrónico, por tanto se ha desarrollado y se ofrece un amplio rango de soluciones al problema del almacenamiento de datos.
Es un diagrama para La asistencia técnica o apoyo técnico es brindada por las compañías para que sus clientes puedan hacer uso de sus productos o servicios de la manera en que fueron puestos a la venta.
1. GESTIÓN DE PRUEBAS
EN DESARROLLO SOFTWARE
25 de octubre de 2011 – Facultade de Informática
2. Agenda
I. ¿Qué software necesita pruebas?
II.¿Qué pruebas necesita mi software?
III.¿Cómo hago pruebas a mi software?
[pausa]
Taller de pruebas software
4. ¿Qué sabemos de las pruebas
software?
● ¿Para qué sirven?
● ¿Cómo se hacen?
● ¿Cuándo se hacen?
● ¿Quién las hace?
5.
6.
7. ¿Qué es un bug?
El software...
● NO hace algo que debería
● Hace algo que NO debería
● Hace algo que NO dice su especificación
● Hace algo que su especificación NO dice,
pero debería
8. ¿Qué es un bug?
El software...
● NO hace algo que debería
● Hace algo que NO debería
● Hace algo que NO dice su especificación
● Hace algo que su especificación NO dice,
pero debería
...es difícil de entender, de usar, lento.
9. ¿Qué los causa?
● Especificación
– Porque no se escribe, no se detalla,
cambia constantemente o no se propaga
● Diseño
– No se detalla suficiente, cambia y no se
comunica
● Código
– Complejidad, documentación pobre,
presión, errores tontos
10. ¿Cuánto cuestan?
● “El 50% del coste del proyecto”
● “Al menos 1/3 y probablemente más de
1/2 del coste del proyecto”
● “Al menos la mitad del coste de todas
las demás actividades del proyecto”
11. ¿Cuánto cuestan?
● ¡Más cuanto más tarde se detectan!
– Cuesta 0'10 € cambiar una especificación
– Cuesta entre 1 y 10 € corregir un error
durante el desarrollo o las pruebas
– Cuesta desde 100 € subsanarlo si lo
encuentra el cliente
12. ¿Cuánto cuestan?
● ¡Más cuanto más tarde se detectan!
– Cuesta 0'10 € cambiar una especificación
– Cuesta entre 1 y 10 € corregir un error
durante el desarrollo o las pruebas
– Cuesta desde 100 € subsanarlo si lo
encuentra el cliente
… en el caso medio.
25. Definitivamente, no hacer pruebas
resulta más caro
… y además el coste de mantenimiento
cae drásticamente
cuando se prueba
26. Definitivamente, no hacer pruebas
resulta más caro
… y además el coste de mantenimiento
cae drásticamente
cuando se prueba bien
27. ¿Para qué valen las pruebas?
● Las pruebas exitosas son las que
encuentran errores
● Las pruebas no pueden demostrar que
el software no tiene
fallos
● Las pruebas no pueden
demostrar que el
software se ajusta a su
especificación
28. ¿Para qué valen las pruebas?
● Las pruebas pueden mostrar la
presencia de errores
● Las pruebas pueden mostrar que los
intentos de hacer fallar el software con
respecto a su especificación fracasaron
● Las pruebas pueden mostrar que no se
pudo encontrar ninguna
disconformidad con respecto a la
especificación
29. ¿Para qué valen las pruebas?
● No se puede probar un programa
por completo
● No siempre se pueden arreglar todos
los errores que se encuentran
● A veces, cuantas más pruebas, menos
errores se encuentran (paradoja del
pesticida)
● Casi siempre, cuantos más errores se
encuentran, más errores hay
30. ¿Para qué vale
la gestión de pruebas?
● Debemos ser capaces de responder
claramente y con cierta confianza a:
– ¿Está el producto listo?
– ¿La cobertura de pruebas es suficiente?
● Si la respuesta es no...
debe estar claro por qué
31. ¿Para qué vale
la gestión de pruebas?
● Las pruebas deben estar bien
integradas con el ciclo de desarrollo y
vida del proyecto, sea cual sea, para
poder responder a
– Qué hay que probar
– Cuándo se empieza a probar
– Cuándo se para de probar
– Quién hace qué
– Cuáles son los resultados
33. Historia
● Prehistoria (<1956): depuración
– Objetivo: que el software se ejecute
● Edad Antigua (1957-1978): demostración
– Objetivo: respaldar empíricamente que el
software cumple su especificación
● Edad Media (1979-1982): destrucción
– Objetivo: forzar la aparición de errores
34. Historia
● Edad Moderna (1983-1987): evaluación
– Objetivo: detectar errores en el diseño o en
la especificación
● Edad Contemporánea (>1998): prevención
– Objetivo: prevenir errores de diseño y de
especificación
● Métodologías ágiles
● Test-driven development
35. ¿Qué sabemos de las pruebas
software?
Verificación Validación
¿Desarrollamos el ¿Desarrollamos el
software software correcto?
correctamente?
36. ¿Qué sabemos de las pruebas
software?
Verificación Validación
¿Desarrollamos el ¿Desarrollamos el
software software correcto?
correctamente?
(de acuerdo a su (de acuerdo a la
especificación) necesidad del
usuario)
37. ¿Qué sabemos de las pruebas
software?
● Niveles de prueba
– Pruebas de unidad
– Pruebas de integración
– Pruebas de sistema
– Pruebas de aceptación
38. ¿Qué sabemos de las pruebas
software?
● Técnicas de prueba
– Dinámicas vs. Estáticas vs. Simbólicas
● Requieren o no de la ejecución del
software, o lo simulan
– Caja blanca vs. Caja negra
● Necesitan o no de conocimiento sobre la
estructura interno del software
– Positivas vs. Negativas
● Buscan o no ejercitar el software en
condiciones normales de uso y
funcionamiento
39. ¿Qué sabemos de las pruebas
software?
● Técnicas de prueba:
– Funcionales
● Se ocupan de lo que el software debe hacer
● Suelen ser técnicas dinámicas de caja negra
– Estructurales
● Se ocupan de lo que el software debe hacer
● Suelen ser técnicas de caja blanca
– No funcionales
● Se ocupan de cómo el software debe hacerlo
● Suelen ser técnicas dinámicas de caja negra
40. Técnicas de prueba
● Pruebas funcionales de caja negra
– Particiones equivalentes
● Se examina el conjunto de posibles
entradas para una unidad y se divide en
rangos que, de acuerdo con la
especificación, deban recibir el mismo
tratamiento
● Para cada rango, se elige un elemento
representante, bajo la premisa de que
cualquier valor dentro de cada rango es
tan bueno para encontrar errores
como el resto
41. Técnicas de prueba
● Pruebas funcionales de caja negra
– Valores-frontera
● Complementa la técnica de particiones
equivalentes seleccionando valores de
entrada (y de salida) pertenecientes a las
fronteras entre rangos
● Las fronteras no siempre son obvias
(especialmente a la salida):
– primero/último, inicio/fin, vacío/lleno,
lento/rápido, grande/pequeño,
cercano/lejano, mínimo/máximo,
encima/debajo, corto/largo, pronto/tarde,
alto/bajo... (+/-1)
42. Técnicas de prueba
● Pruebas funcionales de caja negra
– Mapas de transiciones
● Para unidades con estado/memoria
● Fronteras en los mapas de transiciones
suelen rebelar problemas de
temporización, race conditions,...
43. Técnicas de prueba
● Pruebas funcionales de caja negra
– Árboles causa-efecto + tablas de
decisión
– Selección de datos aleatoria
● En realidad, que siga la gramática
especificada para la unidad
● Generará datos que ni probadores ni
desarrolladores se plantearían
normalmente
44. Técnicas de prueba
● Pruebas funcionales de caja negra
– Basadas en modelos y propiedades
● Aserciones, enunciados
● Máquinas de estados finitos
45. Técnicas de prueba
● Pruebas funcionales de caja blanca
– Cobertura de instrucciones
● Seleccionar casos de prueba para que se
ejecute cada sentencia en el código al
menos una vez
– Cobertura de decisiones (ramas)
● En el caso de las sentencias de decisión, la
cobertura de instrucción puede hacer que
se ejecute la toma de la decisión, pero no
todas sus posibles ramas
46. Técnicas de prueba
● Pruebas funcionales de caja blanca
– Cobertura de condiciones
● Seleccionar casos de prueba para que la
toma de una decisión sea ejercitada
explorando todas las posibilidades de
la(s) condición(es) asociada(s)
– Análisis de flujo de datos
● Búsqueda de variables sin utilizar,
referenciadas sin inicializar, sin
dereferenciar...
– Análisis de flujo de control
47. Técnicas de prueba
● Pruebas funcionales de caja blanca:
– Mutación de código
– Inserción de fallos
● Pruebas estructurales de caja blanca:
– Revisión de código
48. Técnicas de prueba
● Pruebas no funcionales de caja blanca
– Análisis del tiempo de ejecución
y el uso de recursos
● Explora la presencia de bugs
monitorizando estos dos parámetros
● Muy valioso para optimización
49. Técnicas de prueba
● Pruebas no funcionales de caja negra
– Configuración (instalación)
– Estrés (seguridad, fiabilidad)
● Qué carga aguanta el software sin fallar
● Qué avisos da antes de fallar
● Qué pasa cuando soporta alta carga largo
rato
● Cuánto tarda en recuperarse
● Qué asistencia es necesaria para la
recuperación
– Usabilidad
50.
51. Métricas de prueba
● Métricas de proceso
– Bugs en desarrollo vs. en producción (fault
slip-through), edad media de bugs/bugs
abiertos, tiempo de respuesta a 30 días,
densidad de bugs...
● Métricas de robustez
– Tiempo medio de fallo
● Métricas de usabilidad
– Facilidad de uso (tiempo experto/tiempo
usuario), ratio de trabajo/productividad,...
53. ¿Cómo hago pruebas al
software?
● Las pruebas deben derivarse de una
línea base (especificación)
– Determina qué es un error
● No necesita ser completa, pero debe
contener suficiente información útil
● Debe ser estable pero flexible, sus
cambios deben controlarse
– Debe interpretarse unívocamente
– Ser visible y legible para los
stakeholders
54. Tipos de errores
● Cambios y correcciones son la primera
causa de los bugs
– Porque se actualiza el código y no las
especificaciones
● Inconsistencias
● Falta de trazabilidad
● Efectos secundarios imprevistos
– Porque no se revisa o prueba suficiente
55. Tipos de errores
● Hay 3 principales motivos para cambiar el
software:
– Corregir bugs
– Añadir funcionalidades
– Adaptarse a cambios en el entorno
56. Tipos de errores
● Errores de especificación
● Errores funcionales
– Previstos pero no suficientemente
controlados
– Que deberían haberse previsto
– Que no podrían haberse previsto
● Errores no funcionales
57. ¿Por dónde empiezo a hacer
pruebas?
● Monitorización del progreso de prueba:
– ¿Cuánta cobertura necesito?
– ¿Cuántos casos de prueba necesito para
alcanzarla?
– ¿Cuántos casos de prueba tengo?
– ¿Cuántos casos de prueba he ejecutado?
– ¿Cuántos bugs he encontrado?
– ¿He encontrado tantos bugs como
esperaba?
58. ¿Cuándo paro de hacer
pruebas?
● Las funcionalidades son estables
– Ha caído el ratio de detección de errores
– Ya no aparecen bugs de cierta gravedad
– Code turmoil es satisfactorio
● Se han ejecutado todas las pruebas
– Se ha ejercitado todo el
código/funcionalidades/escenarios
– El número y severidad de los bugs
encontrados está en un nivel
satisfatorio
59. Calidad de las pruebas
● Métricas e indicios internos:
– Bugs detectados en pruebas vs.
detectados en producción
– Bugs vs. cambios
– Bugs por iteración, bugs por parche,
parches por release
● ¿Se reducen los de mayor
gravedad/prioridad respecto al total?
– Bugs abiertos vs. cerrados
– Pruebas ejecutadas/abandonadas
60. Calidad de las pruebas
● Métricas e indicios externos:
– Nuevos proyectos no avanzan porque
hay que dedicar personal a
mantenimiento
– Evolución de los retrasos en entrega
– Evolución de horas extras próximas a las
fechas de entrega
– Evolución de LOC/bug en cada release,
en cada producto
61. Gestión de las pruebas
● Para cada proyecto software, debe
definirse una estrategia de prueba
– Visión global de la tarea
– Dirección, prioridades
– Documento de estrategia:
● Situación hoy + top 10 problemas +
posibles soluciones, cómo abordarlos
– Revión cada 6 meses o cuando haya
cambios significativos en el proyecto o
el entorno
62. Gestión de las pruebas
● Para cada release, debe redactarse y
ejecutarse un plan de pruebas
– Centrado en los posibles problemas de
cada release
● Nuevas features, interacción con features
ya existentes (backwards-compatibility)...
– Documento de plan de pruebas
● Actividades necesarias para llevar a cabo
unas pruebas eficaces + herramientas y
entorno de pruebas + planificación
63. Gestión de las pruebas
● Para cada unidad, debe mantenerse un
documento de monitorización de
pruebas:
– Casos de prueba esperados y reales
– Cobertura de funcionalidades
– Prioridad de funcionalidades
– Bugs esperados y encontrados
– Bugs por funcionalidad
64. Gestión de las pruebas
● Especificación de diseño de pruebas
– Qué se prueba, técnica, entorno, criterios
de aceptación/rechazo.
● Especificación de casos de prueba
– Objetivo, especificación, entradas/salidas,
dependencias, nº de bugs esperados
● Especificación del proceso de prueba
– Release/configuración, pasos para
ejecución/medición, procedimiento en
caso de error, criterios de inicio/parada
65. Gestión de las pruebas
d criterios
Especificación de diseño de pruebas
●
a
id
Qué se prueba, técnica, entorno,
–
l
a de prueba
de aceptación/rechazo.
Especificación de C casos
e
●
– d nº de bugs esperados
Objetivo, especificación, entradas/salidas,
n
la
dependencias,
●
P
Especificación del proceso de prueba
– Release/configuración, pasos para
ejecución/medición, procedimiento en
caso de error, criterios de inicio/parada
66. “Software exhibits weak-link behaviour:
failures in even unimportant parts of the
code can have important repercussions
elsewhere”
“Bugs remain in software after testing
because testers and developers have the
same view of the way the software will be
used by users”
68. “There are things you can specify and
things you can test for, and there are
things you'd never ever think of guarding
against”.
“If you can't plan or model it, what makes
you think you can do it?”
71. El espectro de las pruebas
Casos de prueba con Generación de
generación de datos secuencias de prueba
Pruebas individuales Propiedades generales
Ejemplos concretos Especificación completa