La integración de Web Testing Automatizado en el proceso de construcción

Question

Busco sugerencias para mejorar el proceso de automatización de pruebas funcionales de un sitio web. Esto es lo que he intentado en el pasado.

Antes tenía un proyecto de prueba usando WATIN . Usted efectivamente escribe lo que ve como "pruebas de unidad" y el uso WATIN para automatizar un navegador para hacer clic en torno a su sitio, etc.

Por supuesto, se necesita un sitio para estar en ejecución. Así que hice la prueba en realidad copiar el código de mi proyecto web a un directorio local y comenzó un servidor web que apunta a ese directorio antes que cualquiera de las pruebas se ejecutan.

De esta manera, alguien nuevo podría simplemente obtener la última de nuestro control de código fuente y ejecutar nuestro script de creación, y ver todas las pruebas se ejecutan. También podrían simplemente ejecutar todas las pruebas desde el IDE.

El problema que encontré fue que pasé mucho tiempo mantener el código para configurar el entorno de prueba más de las pruebas. Por no mencionar que nos llevó mucho tiempo para correr por todo lo que la copia. Además, tenía que probar varios escenarios que incluyen la instalación, lo que significa que tenía que ser capaz de configurar la base de datos de varios estados iniciales.

Tenía curiosidad sobre lo que has hecho para automatizar pruebas funcionales para resolver algunos de estos problemas y que sea sencillo todavía.

Más información Dado que las personas pidieron más detalles, aquí está. Estoy corriendo ASP.NET utilizando Visual Studio y Cassini (el construido en el servidor web). Mis pruebas unitarias se ejecutan en MbUnit (pero eso no es tan importante. Podría ser NUnit o XUnit.NET). Por lo general, tengo un marco de pruebas unidad separada ejecutar todas mis pruebas Watin. En la fase AssemblyLoad, comienzo el servidor web y copiar toda mi código de la aplicación web localmente.

Estoy interesado en soluciones para cualquier plataforma, pero puede que necesite más descripciones sobre lo que significa cada cosa. :)

Answer 1

Phil,

Automatización solo puede ser difícil de mantener, pero cuanto más se use su automatización para el despliegue, cuanto más se puede aprovechar para la configuración de prueba (y viceversa).

Francamente, es más fácil para evolucionar código de automatización, factorización y refactorización en pequeñas unidades específicas, de funcionalidad cuando se utiliza una herramienta de construcción que no se
sólo la conducción compilados estáticamente, unidades de pre-factorizada de funcionalidad, como es el caso con de NAnt y MSBuild. Esta es una de las razones por las que muchas personas que eran relativamente primeros usuarios de Toole como de NAnt han movido fuera a Rake. La libertad para el tratamiento de construir código como cualquier otro tipo de código - evolucionando cotinually su contenido y forma - es mayor con el rastrillo. Que no terminan con la misma estasis en artefactos de automatización tan fácil y rápidamente con el rastrillo, y es mucho más fácil programar en Rake de Nant o MSBuild.

Por lo tanto, una parte de su lucha obedece a aspectos de las herramientas. Para mantener su automatización sensible y mantenido, usted debe tener cuidado con los obstáculos que las herramientas de la acumulación estática como de NAnt y MSBuild imponen.

Yo sugeriría que no par el entorno de prueba de arranque flejes de carga de montaje. Eso es un acoplamiento de adentro hacia afuera que sólo sirve breve conveniencia. No hay nada malo (y, probablemente todo a la derecha) con ir a la línea de comandos y ejecutar la tarea de compilación que configura el entorno antes de ejecutar las pruebas, ya sea desde el IDE o desde la línea de comandos o desde una consola interactiva, al igual que el C # REPL de el Proyecto Mono, o de IRB.

configuración de datos de prueba es simplemente un dolor en el trasero a veces. Tiene que ser hecho.

Vas a necesitar una biblioteca que se puede llamar para crear y limpiar el estado de base de datos. Puede hacer esas llamadas directamente desde su código de prueba, pero yo personalmente tienden a evitar hacer esto porque hay más de un buen uso de los datos de prueba o código de control de datos de ejemplo.

conduzco todo el control de datos de ejemplo de HTTP. Escribo controladores con acciones específicamente para el control de datos de la muestra y la cuestión reciba contra esas acciones a través de selenio. Yo uso estos para crear y limpiar los datos. Puedo componer llega a estas acciones para crear escenarios comunes de datos de configuración, y puedo pasar valores específicos para los datos como parámetros de la petición (o parámetros del formulario si es necesario).

guardo estos controladores en un área que se suele llamar "test_support".

Mi automatización para la implementación de la página web no despliega la zona test_support o sus rutas y la cartografía. Como parte de mi implementación de automatización de la verificación, me aseguro de que el código test_support no está en la aplicación de producción.

También utilizo el código test_support para automatizar el control sobre todo el entorno - la sustitución de los servicios con falsificaciones, apagando subsistemas para simular fallas y conmutaciones por error, la activación o desactivación de autenticación y control de acceso para las pruebas funcionales que no se ocupa de estas facetas, etc.

Hay un gran valor secundario para el control de datos de ejemplo de su aplicación web o datos de prueba desde la web: cuando demos la aplicación, o cuando se hace la prueba de exploración, puede crear los escenarios de datos que necesita sólo mediante la emisión de algunos obtiene contra conocida (o adivinables) URL en la zona test_support. Realmente hacer un esfuerzo disciplinado para pegarse a las rutas de descanso y de recursos orientación aquí será realmente valdrá la pena.

Hay mucho más a esta automatización funcional (incluidas las pruebas, despliegue, demos, etc) para que los mejor diseñados estos recursos son, mejor es el tiempo que va a los has mantener en el largo pasillo, y cuanto más oportunidades' encontrará a aprovechar de maneras imprevistas pero beneficiosas.

Por ejemplo, la escritura de código modelo de dominio sobre el modelo semántico de sus páginas web ayudará a crear mucho más comprensible código de prueba y disminuir la fragilidad. Si lo hace así, puede utilizar los mismos modelos con una variedad de diferentes conductores para quepuede aprovechar en las pruebas de resistencia y pruebas de carga, así como pruebas funcionales, así como su uso desde la línea de comandos como herramientas de exploración. Por cierto, este tipo de cosas es más fácil de hacer cuando no está limitado a los tipos de controladores como eres cuando se utiliza un lenguaje estático. Hay una razón por la que muchos principales pensadores y hacedores de prueba trabajan en Ruby, y por qué Watir está escrito en Ruby. La reutilización, la composición y la expresividad es mucho más fácil de lograr en Ruby que el código # ensayo C. Pero eso es otra historia.

Vamos a ponerse al día en algún momento y hablar más sobre el otro 90% de estas cosas:)

Answer 2

plasma en un proyecto. Emula un servidor web en el proceso - simplemente apunte en la raíz de su proyecto de aplicación web.

Fue sorprendentemente estable - no hay copia de archivos o la puesta en marcha de un proceso de servidor

.

Así es como una prueba con plasma se ve por nosotros ...

    [Test]
    public void Can_log_in() {
        AspNetResponse response = WebApp.ProcessRequest("/Login.aspx");
        AspNetForm form = response.GetForm();

        form["UserName"] = User.UserName;

        form["Password"] = User.Password;

        AspNetResponse loggedIn = WebApp.ProcessRequest(Button.Click(form, "LoginUser"));


        Assert.IsTrue(loggedIn.IsRedirect());

        AspNetResponse homePage = WebApp.ProcessRequest(loggedIn.GetRedirectUrl());

        Assert.AreEqual(homePage.Status, 200);
    }

Todas las categorías "AspNetResponse" "" AspNetForm se incluyen con plasma.

Answer 3

Actualmente estamos usando un proceso de construcción automatizado para nuestra aplicación asp.net mvc.

Nosotros utilizamos las siguientes herramientas:

• TeamCity
• SVN
• nUnit
• Selenio

Nosotros usamos un script msbuild que se ejecuta en un agente de compilación que puede ser cualquier cantidad de máquinas. El guión msbuild obtiene la última versión del código de SVN y construye.

En caso de éxito, entonces despliega los artefactos a una máquina / carpeta determinada y crea el sitio virtual en IIS.

A continuación, utilizamos tareas contrib MSBuild ejecutar secuencias de comandos SQL para instalar los datos de bases de datos y de carga, también se puede hacer una restauración.

En caso de éxito que inicio a las pruebas nUnit. La configuración de la prueba asegura que el selenio está en marcha y luego impulsa las pruebas de selenio mucho de la misma manera que lo hace Watin. El selenio tiene un buen grabador para las pruebas que se pueden exportar a C #.

Lo bueno de selenio es que se puede conducir FF, Chorme e IE en lugar de limitarse a IE como fue el caso con Watin la última vez que miré. También puede utilizar selenio hacer pruebas de carga con el selenio cuadrícula, por tanto, puede volver a utilizar las mismas pruebas.

En msbuild éxito, entonces las etiquetas La acumulación en el SVN. TeamCity tiene un trabajo que se ejecuta durante la noche que se desplegará la última etiqueta a un entorno de ensayo listo para los usuarios de negocios para comprobar el estado del proyecto a la mañana siguiente.

En una vida anterior que teníamos Nant y msbuild secuencias de comandos para gestionar por completo el medio ambiente (java instalación, selenio, etc), sin embargo esto no llevará mucho tiempo, así como req pre asumimos cada agente de compilación tiene estas instalado. Con el tiempo vamos a incluir estas tareas.

Answer 4

¿Por qué necesita para copiar el código? Pasa de Cassini y dejar que Visual Studio crea un directorio virtual para ti. De que los desarrolladores deben recordar para construir antes de ejecutar las pruebas web si la aplicación web ha cambiado. Hemos encontrado que esto no es un gran problema, especialmente cuando se ejecutan pruebas de CI web.

Los datos es un gran reto. Por lo que yo puedo ver, debe elegir entre alternativas imperfectas. Así es como lo manejamos. En primer lugar, debo explicar que estamos trabajando con un gran complejo Web Forms heredados aplicación. También debo mencionar que el código de dominio no es muy adecuado para la creación de datos de prueba desde dentro del proyecto de prueba.

Esto nos dejó con un par de opciones. Podríamos: (a) las secuencias de comandos de configuración de datos de ejecución en virtud de la acumulación, o (b) crear todos los datos a través de pruebas web usando el sitio web real. El problema con la opción (a) es que las pruebas se hacen junto con las secuencias de comandos en un nivel minuto. Se hace palpitar mi cabeza para pensar acerca de la sincronización de código de prueba web con T-SQL. Así que fuimos con (b).

Uno de los beneficios de (b) es que su configuración también valida comportamiento de la aplicación. El problema es ... tiempo .

Idealmente pruebas deben ser independientes, sin acoplamiento temporal (se puede ejecutar en cualquier orden) y no compartir cualquier contexto (por ejemplo, datos de prueba comunes). La forma más común de manejar esto es para configurar y derribar los datos con cada prueba. Después de pensarlo cuidadosamente, decidimos romper esta regla.

Utilizamos Galio (MbUnit 3), que ofrece algunas características interesantes que apoyan nuestra estrategia. En primer lugar, le permite especificar el orden de ejecución a nivel de fijación y de prueba. Tenemos cuatro partidos de "configuración" que se ordenan -4, -3, -2, -1. Estos ejecutar en el orden especificado y antes de todos los accesorios "no Setup", que por defecto tiene una orden de 0.

Nuestro proyecto web de prueba depende de la escritura de la estructura para una sola cosa: un nombre de usuario / contraseña única conocida. Se trata de un acoplamiento que puedo vivir con. Como las pruebas de instalación se ejecutan construyen un objeto "contexto de datos" que mantiene identificadores de datos (empresas, usuarios, proveedores, clientes, etc.) que se utiliza más tarde (pero nunca cambian) a lo largo de toda otros accesorios. (Por identificadores, no me refiero necesariamente llaves. En la mayoría de los casos nuestra interfaz de usuario web no expone las claves únicas. Hay que navegar por la aplicación utilizando nombres u otros sustitutos de identificadores verdaderos. Más sobre esto más adelante.)

Galio también le permite especificar que una prueba o un accesorio depende de otra prueba o accesorio. Cuando falla un precedente, el dependiente se omite. Esto reduce el mal de acoplamiento temporal mediante la prevención de "fallos en cascada", que pueden cosechar mucha confusión.

La creación de datos de prueba de línea de base una vez, en lugar de antes de cada prueba, acelera las cosas mucho. Sin embargo, las pruebas de configuración todavía podrían tomar 10 minutos para correr. Cuando estoy trabajando en nuevas pruebas Quiero correr y volver a ejecutar con frecuencia. Introduzca otra característica interesante Galio: Ambiente. Ambiente es una envoltura alrededor de DB4 que proporciona una forma muy simple de persistencia de objetos. La usamos para persistir el contexto de datos de forma automática. Por lo tanto las pruebas de instalación sólo se debe ejecutar una vez entre reconstrucciones de la base de datos. Después de que se puede ejecutar cualquiera o todas las otras instalaciones en varias ocasiones.

¿Qué pasa con la limpieza de los datos de prueba? No tenemos que comenzar desde un estado conocido? Esta es una regla hemos encontrado que es conveniente romper. Una estrategia que se está trabajando para nosotros es utilizar los valores de largo al azar para cosas como el nombre de la empresa, nombre de usuario, etc. Nosotros hemos encontrado que no es muy difícil mantener una prueba de funcionamiento dentro de un "espacio de datos" lógica de tal manera que no choque en otros datos. Ciertamente Temo el día que me paso horas persiguiendo a una prueba de no haber fantasma sólo para descubrir que se trata de alguna colisión de datos. Es una solución de compromiso que está trabajando para nosotros actualmente.

Estamos utilizando Watin. Me gusta bastante. Otra clave del éxito es algo de Scott Bellware aludido. A medida que creamos pruebas estamos construyendo un modelo abstracto de nuestra interfaz de usuario. Así que en lugar de esto:

browser.TextField("ctl0_tab2_newNote").TypeText("foo");

wiVeremos esto en nuestras pruebas:

User.NotesTab.NewNote.TypeText("foo");

Este enfoque proporciona tres beneficios. En primer lugar, nunca repetimos una cadena mágica. Esto reduce enormemente la fragilidad. En segundo lugar, las pruebas son mucho más fáciles de leer y entender. Por último, nos ocultan la mayor parte del marco Watin detrás de nuestras propias abstracciones. En el segundo ejemplo, sólo TypeText es un método Watin. Esto hará que sea más fácil cambiar a medida que cambia marco.

Espero que esto ayude.

Answer 5

Fue difícil, pero no imposible, para construir una fase de prueba de integración en el proceso de construcción utilizando Maven. Lo que pasó fue esencialmente la siguiente:

• No haga caso de todas las pruebas JUnit en un directorio específico a menos que los fuegos en fase de pruebas de integración.
• Añadir un perfil de experto para ejecutar las pruebas de integración.

• En la fase de prueba pre-integración -

• Inicio embarcadero que ejecuta la aplicación de golpear una base de datos de prueba.

• Inicie el servidor de selenio
• Ejecutar pruebas de integración de selenio en fase de prueba de integración
• Detener servidor de selenio
• Detener el selenio

La dificultad en este paso fue realmente estableciendo embarcadero - que no podía conseguir que acaba de lanzar una guerra, así que en realidad tiene que tener embarcadero desempaquetar la guerra, a continuación, ejecutar el servidor - pero funciona, también, y se automatiza -. todo lo que tiene que hacer es escribir mvn -PintegrationTest (que era nuestro nombre perfil de pruebas de integración) y fuera de él fue

Answer 6

Qué quiere decir el inicio automático de la prueba después de la acumulación de terminar? Se puede escribir secuencias de comandos automatizadas para copiar los archivos de generación de un trabajo de IIS mientras que la construcción cumple con éxito. Y luego iniciar el BVT automatizado mediante una llamada MSTest.exe u otros métodos.

Usted podría conseguir una oportunidad con autoitx o algún lenguaje de la función, tal como Python, Ruby.