75.52 - Taller de programación II
¿Por qué hacer tests?
1950
1960
1970
1980
1990
2000
Fix bugs
Exhaustive
Testing
Prove It
Works
Prove It does not
Works
Defect
prevention
& Test process
Test
automation
tools
Early
test
design
Advanced
test
automation
Agile
White Box
Gray Box
Black Box
Se tiene conocimiento del funcionamiento interno del sistema
Se utilizan ambos conceptos
No se tiene conocimiento del funcionamiento interno del sistema
Code debugging
Primitive manual testing
Designed manual testing
Scripted manual testing
Data-driven tests
Automated test scripts
Keyword-driven testing
Advanced Keyword-driven testing
MÉTODOS
DE TESTING
(*)Top-down and bottom-up design
donde hay humo, hay fuego”
Las pruebas de aceptación son las últimas pruebas realizadas donde el cliente prueba el software y verifica que cumpla con sus expectativas. Estas pruebas generalmente son funcionales y se basan en los requisitos definidos por el cliente y deben hacerse antes de la salida a producción.
Conjunto de pruebas a alto nivel que tienen como objetivo comprobar el funcionamiento de las partes críticas de un determinado firmware o software. Esencialmente se utiliza para verificar que una nueva versión de código no ha afectado a las funcionalidades existentes y, por consiguiente, que se puede proceder a realizar un ciclo de pruebas más exhaustivo.
Son realizadas cuando el sistema está en desarrollo y cuyo objetivo es asegurar que lo que estamos desarrollando es probablemente correcto y útil para el cliente.Son normalmente realizadas contra un prototipo desarrollado rápidamente y con poco coste realizado para poder experimentar con él
Se realizan cuando el sistema está teóricamente correcto y pasa a ejecutarse en un entorno real. Es la fase siguiente a las pruebas Alpha. Las pruebas beta son pruebas para localizar esos problemas que no han sido detectados y poder corregirlos antes de liberar una versión. Debería ser realizada por usuarios finales
As a consequence of the introduction of new bugs, program maintenance requires far more system testing per statement written than any other programming. Theoretically, after each fix one must run the entire bank of test cases previously run against the system, to ensure that it has not been damaged in an obscure way. In practice such regression testing must indeed approximate this theoretical ideal, and it is very costly.
Fred Brooks, The Mythical Man month
LOAD TESTING
VOLUME TESTING
STRESS TESTING
Discovery
Vulnerability Scan
Vulnerability Assessment
Security Assessment
Penetration Test
Security Audit
Security Review
void sortAndCheckSize(){
TreeSet<String> animals = new TreeSet<String>();
set.add("lol");
set.add("cat");
assertEquals(2, animals.size());
assertEquals(“lol”, animals.first());
assertEquals(“cat”, animals.last());
}
El test verifica precondiciones?
El test verifica condiciones de error?
Nombres precisos
Independently
La ejecución de una prueba no debe afectar a la ejecución de otra.
Organizar unit test en suites
Refactorizar evita duplicación
Extraer código común en métodos
Extraer funcionalidad común en clases
Eliminar test redundantes
Linting is the process of running a program that will analyse code for potential errors.
Continous Delivery https://martinfowler.com/bliki/ContinuousDelivery.html (accessed Apr 27, 2018)
Test Coverage https://martinfowler.com/bliki/TestCoverage.html (accessed Apr 27, 2018)
What is the history of automated software testing? https://www.quora.com/What-is-the-history-of-automated-software-testing/answer/Thuc-Nguyen-51 (accessed Apr 28, 2018)
Software testing tactics https://en.wikipedia.org/wiki/Software_testing_tactics (accessed Apr 28, 2018)
Frederik Brooks The Mytical Man Month [Online]; pp 122. https://is.muni.cz/www/208322/The.Mythical.Man.Month.F.Brooks.pdf (accessed May 1, 2018).