Pruebas automáticas
Joan Sebastián Ramírez Pérez
2015
Agenda
• Pruebas de software
• Mocking
• Pruebas unitarias
• Pruebas de integración
• Pruebas funcionales
• Pruebas de sistema
• Bibliografía
Pruebas de software
• Pruebas de Software es un proceso de evaluar un sistema ya sea manual o
automático y verificar que este satisface los requisitos o identifica diferencias
entre lo esperados y los resultados actuales.
• Subconjunto de las llamadas “prácticas técnicas” en la cual se automatizan las
pruebas del software.
• Alrededor del 30 40% del tiempo de la implementación se invierte en la
automatización de pruebas de software.
• Las pruebas de software apuntan a mejorar la calidad del producto.
Tipos de pruebas automatizadas
• Unitarias
• Integración
• Funcionales
• Sistema
¿Por qué hacer pruebas de software?
• Mitigar errores en la aplicación.
• Eficiencia de la aplicación.
• Aseguramiento de la calidad (proceso del desarrollo del software).
• Flexibilidad del software.
• Adaptación del sistema a cambios futuros.
Agenda
• Pruebas de software
• Mocking
• Pruebas unitarias
• Pruebas de integración
• Pruebas funcionales
• Pruebas de sistema
• Bibliografía
Agenda
• Pruebas de software
• Mocking
• Pruebas unitarias
• Pruebas de integración
• Pruebas funcionales
• Pruebas de sistema
• Bibliografía
Mocking
• Los mocks son objetos falsos que simulan el comportamiento de un objeto real.
• Se llaman Mock a los objetos que imitan el comportamiento de objetos reales de
una forma controlada. Se usan para probar a otros objetos en test unitarios que
esperan mensajes de una clase en particular para sus métodos, al igual que los
diseñadores de autos usan un crash dummy cuando simulan un accidente.
• Algunos frameworks para hacer mocks: Mockito, EasyMock, PowerMock, Jmock,
Jmockit, ngMock, JustMock, Nmock, RhinoMock.
Agenda
• Pruebas de software
• Mocking
• Pruebas unitarias
• Pruebas de integración
• Pruebas funcionales
• Pruebas de sistema
• Bibliografía
Pruebas Unitarias
• Testean la funcionalidad de una unidad de código emulando las llamas a otras
unidades (tanto internas como externas).
• La emulación se hace a través de mocking.
• las pruebas unitarias por lo general son simples y rápidas de codificar, el
desarrollo de una prueba unitaria no debería tomar más de cinco minutos.
• Algunos frameworks: Junit, Karma, Nunit, RSpec.
¿Qué debería cumplir una prueba unitaria?
• Unitaria: prueba solamente pequeñas cantidades de código.
• Independiente: no debe depender ni afectar a otras pruebas unitarias.
• Automatizable: la prueba no debería requerir intervención manual.
• Repetible y predecible: no debe incidir el orden y las veces que se repita la
prueba, el resultado siempre debe ser el mismo.
Patrón AAA
Hace referencia a la forma en la cual se debe organizar el código para
automatizar una prueba.
• Arrange: preparar objetos, variables, dependencias y mock necesarios para
hacer el llamado a la prueba.
• Act: se invoca la funcionalidad que se quiere probar con lo que se genero en
el arrange.
• Assert: verificar que el resultado del act coincide con el esperado a través de
un assert. Un único assert por prueba.
Set up y Tear Down
• Set up nos permite inicializar valores comunes a todos los test.
• Tear Down nos permite limpiar valores comunes a todos los test.
“
”
No hay ningún secreto en cómo escribir los tests, solo
hay secretos en cómo escribir código testeable.
MiskoHevery
Agenda
• Pruebas de software
• Mocking
• Pruebas unitarias
• Pruebas de integración
• Pruebas funcionales
• Pruebas de sistema
• Bibliografía
Pruebas de Integración
• Testean unidades de código.
• Se hacen similar a las unitarias solo que no es necesaria la emulación de las
unidades.
• Es importante probar excepciones y timeout en este tipo de pruebas.
• Se hacen con los mismos framework que las pruebas unitarias.
¿Cuándo es una prueba de integración?
• Cuando involucra una o más clases en simultaneo.
• Cuando el código se comunica fuera de las fronteras de su propio proceso
(base de datos, la red, sistemas de archivos)
Agenda
• Pruebas de software
• Mocking
• Pruebas unitarias
• Pruebas de integración
• Pruebas funcionales
• Pruebas de sistema
• Bibliografía
Pruebas Funcionales
• Testean la aplicación incluso interactuando con las diferentes capas de ella.
• Estas pruebas simulan la interacción del usuario con la aplicación.
• Jbehave, Cucumber, Protractor, Selenium, Code Ui, Spec Flow, etc.
Tipos de pruebas funcionales
• Visuales o de apariencia: garantizan que la interfaz de usuario se despliega de
la manera esperada con todas sus secciones, comportamientos y elementos
• Transversales: son las pruebas en las cuales se hace un robot que ingresa los
datos a la pantalla y hace la petición como lo haría un usuario.
Agenda
• Pruebas de software
• Mocking
• Pruebas unitarias
• Pruebas de integración
• Pruebas funcionales
• Pruebas de sistema
• Bibliografía
Pruebas del Sistema
• Testean la aplicación como un todo.
• Usualmente son usadas para realizar pruebas de stress o para verificar
atributos de calidad definidos para la aplicación.
• Pruebas requisitos no funcionales.
Tipos de pruebas de sistema
• Rendimiento: mide la aplicación respecto a los requisitos no funcionales
asociados a tiempo de respuesta. Pueden medir también consumo de
recursos, memoria, disco, procesador, ancho de banda, etc.
• Escalabilidad: mide que el rendimiento de la aplicación no desmejore
abruptamente en la medida que incrementa el número de usuarios.
• Profiling: análisis de rendimiento en un determinado momento. Usado
habitualmente para identificar problemas de rendimiento en ambientes de
producción.
Agenda
• Pruebas de software
• Mocking
• Pruebas unitarias
• Pruebas de integración
• Pruebas funcionales
• Pruebas de sistema
• Bibliografía

Pruebas automaticas

  • 1.
  • 2.
    Agenda • Pruebas desoftware • Mocking • Pruebas unitarias • Pruebas de integración • Pruebas funcionales • Pruebas de sistema • Bibliografía
  • 3.
    Pruebas de software •Pruebas de Software es un proceso de evaluar un sistema ya sea manual o automático y verificar que este satisface los requisitos o identifica diferencias entre lo esperados y los resultados actuales. • Subconjunto de las llamadas “prácticas técnicas” en la cual se automatizan las pruebas del software. • Alrededor del 30 40% del tiempo de la implementación se invierte en la automatización de pruebas de software. • Las pruebas de software apuntan a mejorar la calidad del producto.
  • 4.
    Tipos de pruebasautomatizadas • Unitarias • Integración • Funcionales • Sistema
  • 5.
    ¿Por qué hacerpruebas de software? • Mitigar errores en la aplicación. • Eficiencia de la aplicación. • Aseguramiento de la calidad (proceso del desarrollo del software). • Flexibilidad del software. • Adaptación del sistema a cambios futuros.
  • 6.
    Agenda • Pruebas desoftware • Mocking • Pruebas unitarias • Pruebas de integración • Pruebas funcionales • Pruebas de sistema • Bibliografía
  • 7.
    Agenda • Pruebas desoftware • Mocking • Pruebas unitarias • Pruebas de integración • Pruebas funcionales • Pruebas de sistema • Bibliografía
  • 8.
    Mocking • Los mocksson objetos falsos que simulan el comportamiento de un objeto real. • Se llaman Mock a los objetos que imitan el comportamiento de objetos reales de una forma controlada. Se usan para probar a otros objetos en test unitarios que esperan mensajes de una clase en particular para sus métodos, al igual que los diseñadores de autos usan un crash dummy cuando simulan un accidente. • Algunos frameworks para hacer mocks: Mockito, EasyMock, PowerMock, Jmock, Jmockit, ngMock, JustMock, Nmock, RhinoMock.
  • 9.
    Agenda • Pruebas desoftware • Mocking • Pruebas unitarias • Pruebas de integración • Pruebas funcionales • Pruebas de sistema • Bibliografía
  • 10.
    Pruebas Unitarias • Testeanla funcionalidad de una unidad de código emulando las llamas a otras unidades (tanto internas como externas). • La emulación se hace a través de mocking. • las pruebas unitarias por lo general son simples y rápidas de codificar, el desarrollo de una prueba unitaria no debería tomar más de cinco minutos. • Algunos frameworks: Junit, Karma, Nunit, RSpec.
  • 11.
    ¿Qué debería cumpliruna prueba unitaria? • Unitaria: prueba solamente pequeñas cantidades de código. • Independiente: no debe depender ni afectar a otras pruebas unitarias. • Automatizable: la prueba no debería requerir intervención manual. • Repetible y predecible: no debe incidir el orden y las veces que se repita la prueba, el resultado siempre debe ser el mismo.
  • 12.
    Patrón AAA Hace referenciaa la forma en la cual se debe organizar el código para automatizar una prueba. • Arrange: preparar objetos, variables, dependencias y mock necesarios para hacer el llamado a la prueba. • Act: se invoca la funcionalidad que se quiere probar con lo que se genero en el arrange. • Assert: verificar que el resultado del act coincide con el esperado a través de un assert. Un único assert por prueba.
  • 14.
    Set up yTear Down • Set up nos permite inicializar valores comunes a todos los test. • Tear Down nos permite limpiar valores comunes a todos los test.
  • 16.
    “ ” No hay ningúnsecreto en cómo escribir los tests, solo hay secretos en cómo escribir código testeable. MiskoHevery
  • 17.
    Agenda • Pruebas desoftware • Mocking • Pruebas unitarias • Pruebas de integración • Pruebas funcionales • Pruebas de sistema • Bibliografía
  • 18.
    Pruebas de Integración •Testean unidades de código. • Se hacen similar a las unitarias solo que no es necesaria la emulación de las unidades. • Es importante probar excepciones y timeout en este tipo de pruebas. • Se hacen con los mismos framework que las pruebas unitarias.
  • 19.
    ¿Cuándo es unaprueba de integración? • Cuando involucra una o más clases en simultaneo. • Cuando el código se comunica fuera de las fronteras de su propio proceso (base de datos, la red, sistemas de archivos)
  • 20.
    Agenda • Pruebas desoftware • Mocking • Pruebas unitarias • Pruebas de integración • Pruebas funcionales • Pruebas de sistema • Bibliografía
  • 21.
    Pruebas Funcionales • Testeanla aplicación incluso interactuando con las diferentes capas de ella. • Estas pruebas simulan la interacción del usuario con la aplicación. • Jbehave, Cucumber, Protractor, Selenium, Code Ui, Spec Flow, etc.
  • 22.
    Tipos de pruebasfuncionales • Visuales o de apariencia: garantizan que la interfaz de usuario se despliega de la manera esperada con todas sus secciones, comportamientos y elementos • Transversales: son las pruebas en las cuales se hace un robot que ingresa los datos a la pantalla y hace la petición como lo haría un usuario.
  • 23.
    Agenda • Pruebas desoftware • Mocking • Pruebas unitarias • Pruebas de integración • Pruebas funcionales • Pruebas de sistema • Bibliografía
  • 24.
    Pruebas del Sistema •Testean la aplicación como un todo. • Usualmente son usadas para realizar pruebas de stress o para verificar atributos de calidad definidos para la aplicación. • Pruebas requisitos no funcionales.
  • 25.
    Tipos de pruebasde sistema • Rendimiento: mide la aplicación respecto a los requisitos no funcionales asociados a tiempo de respuesta. Pueden medir también consumo de recursos, memoria, disco, procesador, ancho de banda, etc. • Escalabilidad: mide que el rendimiento de la aplicación no desmejore abruptamente en la medida que incrementa el número de usuarios. • Profiling: análisis de rendimiento en un determinado momento. Usado habitualmente para identificar problemas de rendimiento en ambientes de producción.
  • 26.
    Agenda • Pruebas desoftware • Mocking • Pruebas unitarias • Pruebas de integración • Pruebas funcionales • Pruebas de sistema • Bibliografía