En antiguas entradas tratamos como realizar pruebas en diferentes navegadores ahora veremos que considerar cuando las hacemos.
1. Identificar Navegadores - Primero tenemos que definir lo que tendrá que ser probado en qué navegadores. El equipo de la analítica general, puede ayudar en esta tarea, ya que tendrán hasta la fecha los datos de uso del navegador.
Otras cosas a tener en cuenta
- Los modos de compatibilidad del navegador (Esto es importante ya que algunos sitios obligan ciertos navegadores en vista de compatibilidad)
- Configuraciones de sistemas operativos
2 Defina el enfoque - También sería necesario definir en qué estado realizamos prueba completa compatibilidad con los navegadores y en qué etapa se utiliza un solo navegador.(Dependiendo de la metodología de desarrollo utilizada) En mi experiencia he encontrado usando IE7 para la prueba de regresión completa y el uso de todos los navegadores para la prueba funcional es un método eficaz. Mi razonamiento es que IE históricamente se encuentra con más problemas que cualquier otro navegador.
Otras cosas a tener en cuenta
- Entender lo que hace cada uno utiliza navegadores facilitará su agrupación.
. 3 Identificar Herramientas - Herramientas como Fiddler será útil porque van a identificar estas llamadas, también puede utilizar las herramientas de desarrollo que vienen con el navegador embargo violinista tiene la ventaja añadida de que permite al usuario romper y manipular estas llamadas.
4. Entender Servicio y llamadas a la API - comprender el funcionamiento interno de la AUT nos ayudará a determinar los puntos de falla y nos ayuda a plantear preguntas lógicas. Por ejemplo, ¿Qué pasa si la API de falla antes de una respuesta?
Otras cosas a tener en cuenta
- Características de HTML5 no están disponibles para todos los navegadores en función de cómo la AUT se implementa esto puede tener importancia. Sobre todo si los desarrolladores están implementando una solución del lado del cliente. ( http://html5test.com/compare/browser/ )
5. Cómo probar - visualizaciones de hardware son una manera eficaz de realizar navegadores, sin embargo entornos visualizados hardware se encontrará con desaceleraciones significativas e imponer una gran capacidad de memoria. Así que es una buena alternativa a la prueba de hardware del host nativo cómo tiene sus inconvenientes.
Otras cosas a tener en cuenta
- Trate de evitar la realización de pruebas en modo de compatibilidad no siempre proporciona una visión coherente de la compatibilidad. Por ejemplo, en las pruebas de IE7 y pruebas en IE8 en modo de compatibilidad IE7 no son los mismos que se utilizan diferentes DLL.
- Spoon.net siempre proporciona una buena solución, las aplicaciones virtuales Spoon funcionan a la misma velocidad que las aplicaciones se ejecutan de forma nativa en contra del equipo anfitrión, con un tamaño mínimo de memoria pero que Spoon sistema operativo virtual sólo virtualiza funciones del sistema operativo en modo de usuario, mientras que la virtualización de hardware sistemas de emular toda la pila del sistema operativo, incluidos los componentes en modo kernel.Las aplicaciones que requieren controladores de dispositivo u otro software de usuario de modo que no pueden exigir un entorno de hardware virtualizado para que funcione correctamente.
Fuente:
No hay comentarios:
Publicar un comentario