Selenium, Nunit ¿Mejores prácticas?

Question

Me gustaría obtener más información sobre cómo usar Selenium IDE y RC para crear buenas pruebas de automatización. ¿Hay alguien que esté interesado en compartir información? o discutiendo esto? Especialmente para cosas como:

1) ¿Cuál es una buena manera de organizar las pruebas de UI? En este momento estoy ejecutando estas pruebas a través de NUnit y eso ejecuta las pruebas en el orden de sus nombres alfabéticos. ¿Hay una mejor manera? (Estoy escribiendo los scripts de selenio en C# y no en java)

2) ¿Cómo se registran los resultados?

3) ¿Modularización de las pruebas de Selenium RC? Estoy teniendo un problema aquí. Dado que estoy ejecutando mis pruebas a través de NUnit, la única forma en que podía figurar era dar identificaciones a las pruebas para que se ejecutaran en el orden correcto. También tengo que escribir todas mis pruebas una después de la otra en la clase textfitxture. Nuevamente, ¿hay una mejor manera? Traté de crear archivos adicionales, pero cuando creo pruebas allí y las selecciono para ejecutarlas en NUnit, parece que el servidor de selenio ni siquiera se inicia.

4) ¿Cuáles son las mejores prácticas para las pruebas de automatización? ¿Alguna sugerencia sobre cualquier sitio/libro/etc.?

Estas cosas pueden parecer muy simples, pero he pasado semanas tratando de encontrar mejores formas, así que si alguien está dispuesto a ofrecer sugerencias o aportes, ¡realmente lo agradeceré!

Gracias!

Answer 1

He respondido cada una de las preguntas a continuación.

1. Las pruebas no deberían importar sobre el orden en que se ejecutan en. Si empieza a preocuparse de que va a empezar a introducir la descamación de las pruebas. Si tiene que iniciar sesión con cada prueba, hágalo, si necesita registrar un número de usuarios durante sus exámenes, hágalo. Las pruebas siempre deberían poder ejecutarse por sí mismas.

2. Nunit registra sus resultados en un archivo XML. Esto tendrá una lista de los correctos e incorrectos y, normalmente, se rindió de una forma bastante continua por casi todos

3. Véase mi respuesta para Best Practices for modularizing Selenium RC test scripts

4. • Las pruebas siempre deben tener un punto de partida conocido. En el contexto de Selenium esto podría significar abrir una página determinada para comenzar un flujo de trabajo.
   • Las pruebas no deberían tener que depender de ninguna otra prueba para ejecutarse. Si una prueba va a agregar algo, no haga una prueba por separado para eliminarla. Esto es para garantizar que si algo sale mal en una prueba, no significa que tenga muchas fallas innecesarias para verificar.
   • Las pruebas solo deben probar una cosa a la vez.
   • Las pruebas deben limpiarse por sí mismas.

Answer 2

Si desea utilizar Selenium, le sugiero que utilice el front-end TestPlan en lugar de otro idioma. Además de un lenguaje específico de dominio, ofrece una buena administración de casos de prueba. Puede organizar sus pruebas en una buena jerarquía y las ejecutará todas e informará los resultados.

Cuida muchos detalles del lanzamiento de Selenium y suaviza muchas dificultades en la RC API.

Answer 3

he acaba de pasar por esto. En términos de modularización y herramientas útiles. Creo que es realmente importante pensar más sobre la construcción de un marco de prueba ui automatizado ágil y bien mantenido que simplemente modular los scripts RC de selenio. Selenium 2: Testing Tools Begginner's Guide fue un gran comienzo para la idea de cómo comenzar a construir un buen marco de prueba. Tuve MUCHO éxito con el patrón (Objeto de página) [https://code.google.com/p/selenium/wiki/PageObjects] después de haber fallado 2-3 veces obteniendo un marco de prueba automatizado. En términos de proceso, me pareció mejor comenzar escribiendo código (estás escribiendo pruebas, por lo que debería ser bastante fácil de probar), pero refactorizando agresivamente usando un buen OOP a medida que los patrones y las estructuras comienzan a acumularse. También recomendaría How Google Tests Software para la motivación de QA de software en general, buenas prácticas de prueba a nivel organizacional y cuándo y cuándo no usar la automatización.