Testing en aplicaciones móviles iOS, Android

12,774 views

Published on

Sesión de formación realizada por SlashMobility enfocada al Testing de las aplicaciones móviles (Mobile Apps): IPhone, IOs, Android, BlackBerry...

Published in: Technology

Testing en aplicaciones móviles iOS, Android

  1. 1. Sesión 1 – Testing<br />Jose Cortés<br />SlashMobility<br />
  2. 2. LET’S TEST IT!<br />Testing<br /><ul><li>Procesos que permiten verificar y revelar la calidad de un producto software.
  3. 3. Es decir: que las aplicaciones funcionen como se espera que lo hagan y de forma eficiente y efectiva.
  4. 4. Conceptos como estabilidad, escalabilidad, eficiencia y seguridad se relacionan a la calidad de un producto</li></ul>Program testing can be a very effective way to show the presence of bugs, but it is hopelessly inadequate for showing their absence.<br />
  5. 5. Testing: ¿para qué?<br />+<br />=<br />
  6. 6. BUG!<br />Ordenador Mark II<br />Bug encontrado por Grace Murray Hopper<br />
  7. 7. Alcance del testing<br /><ul><li>Se pueden realizar testing de aspectos funcionales y no-funcionales:
  8. 8. FUNCIONAL: ¿Puede el usuario realizar una acción? ¿funciona correctamente una parte de la App? => APP FUNCIONA
  9. 9. NO FUNCIONAL: Aspectos no relacionados con acciones o funcionalidades: rendimiento, seguridad … => CALIDAD:
  10. 10. Testeabilidad: los componentes sean fácilmente aislables.
  11. 11. Escalabilidad: se pueden añadir cambios no-traumáticos
  12. 12. Mantenibilidad: fácil de modificar
  13. 13. Usabilidad: no hay que hacer maniobras “extrañas” para usarlo
  14. 14. Rendimiento: lo que la app hace, lo hace bien</li></li></ul><li>Testing y bugs<br /><ul><li>¿Pruebas? Tengo otras cosas que hacer…!!
  15. 15. Cuanto antes aparezca un fallo menos cuesta solventarlo (en $$ y tiempo)</li></li></ul><li>¿Qué testear?<br /><ul><li>Fallo común: testear aspectos no requeridos en la aplicación:
  16. 16. ¡La estrategia de testing dependerá de los requerimientos!</li></li></ul><li>¿Cómo testear?<br /><ul><li>¿Testeamos todas las posibles combinaciones?
  17. 17. ¿ Testeamos sólo algunas partes? Si hay algún bug remoto, quizás no lo encuentren… (una posibilidad entre 1.000)
  18. 18. Posibilidad de que 1 usuario NO encuentre bug: 99’99%
  19. 19. Posibilidad de que 2 usuarios NO encuentren bug: 99’98 %
  20. 20. Probabilidad de que 1.000 usuarios NO encuentren bug: 90’4%
  21. 21. Probabilidad de que 100.000 usuarios NO encuentren bug: 4’5%
  22. 22. Debemos definir estrategia de testing para buscar un punto medio: nosotros utilizaremos estrategias inspiradas en box-approach</li></ul>10^90 posibles posiciones<br />
  23. 23. Testing: boxapproach<br /><ul><li>Metáfora para visualizar las funcionalidades.
  24. 24. Desde fuera la funcionalidad sólo nos importa lo que hace, no COMO lo hace (black-box).
  25. 25. Desde dentro de la funcionalidad, nos importan los detalles y cómo se llevan a cabo (white-box)</li></li></ul><li>Testing: white-box<br /><ul><li>Testeamos la App conociendo sus componentes internos: funciones, algoritmos, estructuras de datos…
  26. 26. Perspectiva interna: vemos el mundo desde el interior.
  27. 27. Ejemplos:
  28. 28. Validación de la API de la aplicación (clases, métodos…)
  29. 29. Code-coverage: requerimiento que en los tests se ejecuten el 90% de las líneas de código.
  30. 30. Problemas: no puede detectar errores funcionales.
  31. 31. Podemos testear la clase Oferta, sus métodos, el Controlador que utiliza esta clase, pero no cómo se está utilizando.
  32. 32. Algoritmo tarda 1ms en ordenar 100 elementos. Si la aplicación tiene 500 millones, no cumplirá los requisitos funcionales. </li></li></ul><li>Testing: black-box<br /><ul><li>Testeamos la App sin conocimiento interno de la aplicación.
  33. 33. Perspectiva externa: vemos el mundo desde el espacio
  34. 34. Dada una entrada el componente debe devolver una salida concreta.
  35. 35. Testing de una función que dados X y Y, devuelve la multiplicación.
  36. 36. Al introducir un texto se devuelve una lista que coincida con el texto
  37. 37. Testing de un componente que devuelve la ubicación.
  38. 38. Ventajas:
  39. 39. Si tenemos ladrillos testeados correctamente
  40. 40. Si tenemos vigas testeadas correctamente
  41. 41. Si tenemos cemento testeado correctamente</li></li></ul><li>Testing: clasificación<br /><ul><li>Durante el ciclo de vida del software:
  42. 42. Unittesting (ComponentTesting): validan código, normalmente funciones y clases (WB). Útil para encontrar casos “raros” (corner cases)
  43. 43. Integrationtesting: verifican los “conectores” entre los componentes (APIs, servicios…)
  44. 44. SystemTesting: Verifica todo en conjunto.
  45. 45. SystemIntegrationTesting: Integración con sistemas de terceros.
  46. 46. Por objetivos:
  47. 47. Regressiontests: se buscan bugs que vuelven al asalto
  48. 48. Acceptancetests: realizado por el cliente para validar que todo está correcto.</li></li></ul><li>Testing en Apps Móviles<br /><ul><li>TestingApps Móviles vs otros entornos (WEB) muy diferente.
  49. 49. Testing en Web es feliz, rosa y la persona se puede simplificar en “clicks”
  50. 50. Testing en Apps Móviles puede ser infernal: hay que gestionar sensores, el usuario puede cambiar orientación del dispositivo, darle patadas…
  51. 51. Hay requerimientos funcionales y no-funcionales inherentes: batería, llamadas entrantes, soporte multidispositivos…</li></li></ul><li>Testing en Apps Móviles: Testing Interface<br /><ul><li>Validación de botones, inputs de texto…
  52. 52. Validar cada pantalla de forma integral (¿hace lo que se supone que debe hacer?)
  53. 53. Validar el flujo de navegación (¿desde la pantalla de listado de restaurantes puedo acceder a los favoritos?)
  54. 54. ¿Qué pasa cuando cambia la orientación del dispositivo?¿y si se hace muy rápido?</li></li></ul><li>Testing en Apps Móviles: Usabilidad<br /><ul><li>¿Es fácil navegar entre pantallas o hay que realizar combinaciones esotéricas?
  55. 55. ¿Se muestra información redundante y que no aporta valor?
  56. 56. ¿Se puede visualizar en el idioma que corresponde?
  57. 57. TODAS (repetimos, TODAS) las interacciones del usuario con el sistema debe generar algún tipo de FEEDBACK!
  58. 58. Clicks en botones
  59. 59. Llamadas a través de Internet
  60. 60. Cualquier operación POTENCIALMENTE lenta: suponer siempre el caso peor!
  61. 61. Verificación de las funcionalidades OFFLINE / ONLINE. ¿el usuario va a perder información al enviarla a un server por haber perdido la cobertura temporalmente?</li></li></ul><li>Testing en Apps Móviles: Performance<br /><ul><li>¿Qué pasa si la conexión a un server se hace por 3G en lugar de WIFI?¿y en 2G?
  62. 62. ¿Qué pasa si se debe enviar/recibir mucha información de un servicio web?
  63. 63. ¿Las imágenes que usamos son del tamaño “adecuado”?
  64. 64. Optimizar: código redundante => ciclos de CPU => +consumo batería => usuario infeliza
  65. 65. ¿Cumple la App con los tiempos exigidos por los usuarios?
  66. 66. ¿Existen memoryleaks?
  67. 67. ¿Liberamos los recursos (GPS, cámara de fotos) que reservamos?</li></li></ul><li>Testing en Apps Móviles: Seguridad<br /><ul><li>Los envíos/recepción de datos sensibles deben ir codificados: CODIFICACIÓN + AUTENTICACIÓN (HMAC-SHA)
  68. 68. Detección de puntos en la app que puedan recibir información maliciosa. Corolario: el server no es nuestro amigo (necesariamente)
  69. 69. No suponer: ¡el mundo es malvado, cruel y vil!
  70. 70. Cualquier archivo que guardemos en la aplicación puede llegar a manos de terceros
  71. 71. Soporte de multiusuarios sin que interfieran los datos entre ellos</li></li></ul><li>Testing en Apps Móviles: Servicios<br /><ul><li>Las Apps móviles deben actuar como clientes, no como servidores.
  72. 72. Debemos validar qué pasa cuando se cae un Servicio, devuelve respuestas mal formadas, errores controlados…
  73. 73. ¿Qué pasa si el Servicio tarda demasiado en responder?
  74. 74. ¿Qué pasa si se intenta acceder a un Servicio sin conexión?¿Y si cae la conexión durante la transmisión de info?</li></li></ul><li>Testing en Apps Móviles: Recursos de bajo nivel<br /><ul><li>¿La App está generando “basura” de algún tipo? Ficheros temporales sin limpiar, base de datos local creciendo demasiado…
  75. 75. ¿Estamos utilizando correctamente los sensores?¿Liberamos el GPS?¿Hacemos más llamadas al servidor de las que tocan?
  76. 76. ¿Usamos demasiada memoria o no la liberamos correctamente?</li></li></ul><li>Testing en Apps Móviles: Operacional<br /><ul><li>¿Estamos “backupeando” información necesaria en la App?
  77. 77. ¿Estamos preparados para el modo “espantada”? Si muere la batería, necesitamos tener un plan de Save y Recovery
  78. 78. ¿Si se actualiza a una nueva versión del Market correspondiente, se pierden datos?
  79. 79. ¿Qué pasa si llaman mientras estamos utilizando la App?¿Y si llega un SMS?
  80. 80. ¿La batería parece bajar radicalmente con el uso de nuestra App?</li></li></ul><li>Testing en Apps Móviles: Compatibilidad, multidispositivo y entornos<br /><ul><li>¿Se ha validado la App en los dispositivos, versiones de SO y modelos acordados?
  81. 81. ¿Cómo se comporta la aplicación en distintas pantallas y resoluciones?
  82. 82. ¿Qué pasa si el servidor de integración cambia?¿Se soporta bien el cambio y sin traumas?
  83. 83. ¿Puede nuestra aplicación afectar a los sistemas de terceros? ¿Puede poner en riesgo los sistemas de otros o degradarlos?</li></li></ul><li>Testing: casos prácticos SIT10<br />
  84. 84. Testing: casos prácticos LetsBonus<br />
  85. 85. Testing: casos prácticos Push-cars<br />

×