Share via


Este artículo proviene de un motor de traducción automática.

Visual Studio 2012

Pruebas para un desarrollo continuo

Larry Brader
Alan Cameron Wills

 

Las aplicaciones Web son típicamente actualizadas o extendidas cada pocas semanas (o incluso días) en reacción al cambio de las necesidades del negocio y comentarios de los clientes.Para apoyar el desarrollo continuo, cada aspecto del ciclo de desarrollo debe ser más eficiente y ligero que los procesos de desarrollo más tradicionales.Por ejemplo, es en la naturaleza del software que incluso el más mínimo cambio requiere todo para volver a analizar.Pero repetir una serie completa de pruebas manuales cada pocos días es imposible.Esto significa que pruebas eventualmente deben ser automatizadas, incluso si empiezan como exploraciones manuales.En este artículo mostramos cómo Microsoft Visual Studio 2012 admite la prueba en un entorno de desarrollo continuo.

El ciclo de DevOps

Algunos proyectos de software lleguen a su fin cuando el software está implementado y funcionando.Retroalimentación se obtiene de las partes interesadas, se prevén mejoras o extensiones y eventualmente una nueva versión, con lo cual el ciclo comienza de nuevo.Este proceso, conocido como los DevOps ciclo, se ilustra en la figura 1.

The Continuous Development CycleFigura 1 el ciclo de desarrollo continuo

En un proyecto de software tradicional, cada ciclo puede durar años.La primera versión normalmente es rica en características, entregado en un DVD e instalado en máquinas locales de los usuarios.Por el contrario, en una aplicación Web moderna, la primera versión podría ser mínimo, pero las extensiones y mejoras son liberados cada pocas semanas (o incluso días).

Por ejemplo, los administradores de un sitio de redes sociales podrían intentar una nueva característica para una semana, durante la cual afirmaron monitorear cómo utilizan los clientes.Al final del periodo de prueba, se ajustan los detalles de cómo funciona la característica.

En este ciclo mucho más rápido, es importante para los equipos de desarrollo a pensar el ciclo DevOps como todo un proceso.En particular, necesitan hacer cada actividad en el ciclo más eficientes, retirar las barricadas que obstaculizan el progreso alrededor del bucle.

Todas las mejoras en el proceso de pruebas que discutiremos aquí están encaminadas a reducir el tiempo que tarda en recorrer el bucle DevOps.En particular, estas nuevas herramientas y técnicas pretenden reducir los cuellos de botella que prueba tradicionalmente ha causado en este bucle.

Pruebas en el ciclo de DevOps

El papel esencial de la prueba es demostrar que han aplicado historias de usuario y otros requisitos.La forma más efectiva de hacer esto es ejecutar la aplicación manualmente y ejercer cada historia así como los usuarios finales será.Evaluador experimentado aplica una variedad de estrategias para exponer los errores y explora todas las variantes y casos de borde de comportamiento de la aplicación.

Cuando se cambia el código de la aplicación, es prudente probar todo lo que puede depender de ella.Las dependencias de software típicamente forman una trama compleja y bugs notoriamente suba en características que parecen relacionados con el enfoque de la actualización.Por esta razón, los equipos de desarrollo tradicionales no les gusta cambiar cualquier componente que ha sido escrito y probado.Como se señaló, el más mínimo cambio exige un completo vuelva a probar, por lo que si se prueba todo manualmente, esto requiere un gran esfuerzo y recursos.

En contraste, los ciclos cortos inherentes en continuo desarrollo requieren que cada parte del software con frecuencia examinarse como su funcionalidad es mejorada y ampliada.Sería imposible probar manualmente cada característica cada pocos días.Ciclos cortos requieren pruebas automatizadas, que sustituyen a las pruebas manuales con código de programa.Puede ejecutar pruebas codificadas rápidamente y tantas veces como desee.

¿Deben equipos de desarrollo continuo de todas sus pruebas de código y abandonar pruebas manuales en total?Ese enfoque ha sugerido a veces, pero en la práctica, hay un compromiso eficaz, que funciona como sigue.

Prueba historias nuevas o sustancialmente modificadas manualmente.Cuando cada prueba pasa constantemente, crear versiones automatizadas de las pruebas para esa historia.En consecuencia, aunque el número total de pruebas aumenta gradualmente como se expande el producto, la carga de pruebas manuales permanece constante porque pruebas manuales son algo sólo para funciones relativamente nuevos.

De hecho, la mayor parte de pruebas codificadas en un proyecto de desarrollo continuo típico son pruebas de unidad, que se escriben junto con el código de la aplicación y probar componentes individuales dentro del software, en lugar de probar el comportamiento de toda la aplicación.Pruebas unitarias es una poderosa herramienta para mantener la estabilidad mientras se actualiza la base de código.

Figura 2 muestra una transición gradual de manual para pruebas automatizadas con el tiempo, junto con la expansión de las pruebas de unidad junto con el código de aplicación.El diagrama es una imagen ideal; en la práctica, la mayoría de equipos automatizan sólo cierta proporción de sus pruebas manuales.Visual Studio 2012 (y otras versiones) también proporciona automatización parcial, que puede utilizarse para acelerar pruebas sin escribir código.

Ideal Transition from Manual to Automated Tests over TimeFigura 2 transición Ideal del Manual para pruebas automatizadas con el tiempo

Pruebas en Visual Studio 2012

Vamos a ver cómo prueba es compatible con Visual Studio 2012 y sus productos asociados, Visual Studio Team Foundation Server (TFS) y Microsoft Test Manager (MTM).

Si su especialidad está probando toda la aplicación, se interesan más por el apoyo prestado por MTM.Si eres un desarrollador, podría tomar más interés en el apoyo para pruebas automatizadas en 2012 de Visual Studio.Sin embargo, el continuo desarrollo exige una relación más estrecha entre estas dos funciones, y algunos equipos prescinden por completo la distinción.Por lo tanto, las herramientas de Visual Studio 2012 están diseñadas para integrar los diferentes estilos de pruebas, y apoyan a un amplio espectro de pruebas prácticas, desde los enfoques más tradicionales a través de un desarrollo continuo.

Pruebas con Visual Studio 2012 automatizadas

Pruebas automatizadas incluyen todos los tipos de pruebas que se definen por escrito o generar código de programa.Crear pruebas automatizadas en Visual Studio 2012, donde inicialmente ejecutarlas para la depuración.

Cuando la prueba — y el código de aplicación que pone a prueba — son correctos, comprobar en la prueba, junto con el código de aplicación.Desde el repositorio de código fuente, se ha recogido por el servicio de compilación y ejecutar regularmente según las definiciones de compilación de su equipo.

Pruebas de integración y unidad pruebas unitarias es una de las más efectivas maneras de mantener libre de bug codebase a través de sucesivos cambios en una aplicación.

Una prueba unitaria es un método que pone a prueba un método, clase o componente mayor de su aplicación aislada de otras partes, recursos y sistemas externos.En la práctica, los programadores a menudo escribir pruebas de integración — es decir, pruebas escritas en forma similar a las pruebas unitarias, pero que podría depender de bases de datos externas, sitios Web u otros recursos.De cualquier manera, estas pruebas utilizan las mismas herramientas y la infraestructura.

En 2012 de Visual Studio, puede escribir pruebas que utilizan cualquiera de varios marcos de prueba, como NUnit, xUnit y el valor predeterminado VSTest.Cuando se han codificado pruebas en cualquiera de estos marcos, simplemente abra la ventana del explorador de prueba y elija Ejecutar todo.Los resultados se resumen en la ventana.

Pruebas de fondo son una opción que funciona eficientemente sus pruebas en segundo plano cada vez que usted construir su solución.Primero se realizan las pruebas afectadas por los cambios.Esto significa que mientras trabaja, puede constantemente ver qué pruebas se superan o no.

Aislar unidades por utilizando falsos unidad verdadera prueba significa desconectarse el código de la que depende la unidad bajo prueba.Esto tiene una serie de ventajas.Si su unidad está siendo desarrollado o actualizado al mismo tiempo como otras unidades de la que depende, se puede probar sin esperar a los demás a ser completa.Si usted reestructurar la aplicación para que utilice esta unidad de forma diferente, o en una aplicación diferente, las pruebas de ir con ella y no necesitan cambiar.

2012 De Visual Studio proporciona dos mecanismos, llamados colectivamente fakes, para desconectar una unidad de sus dependencias.Llamadas desde su unidad a métodos fuera de sus límites pueden ser manejadas por pequeños trozos de código que usted proporcione.Por ejemplo, puede definir una cuña que intercepta las llamadas a cualquier método externo como DateTime.Now.Porque siempre recibe la misma respuesta de la cuña, su unidad demostrará el mismo comportamiento cada vez que se invoca.También puede definir talones, que proporcionan el marcador de posición de implementaciones de métodos en las Asambleas que no han sido cargadas.

Rendimiento y pruebas de carga Visual Studio 2012 Ultimate proporciona instalaciones de pruebas específicas de rendimiento y pruebas de estrés.Una aplicación puede ser instrumentada e impulsada con el fin de medir su rendimiento bajo cargas especificadas.Las aplicaciones Web pueden ser controladas con varias solicitudes, simulando a muchos usuarios.

Pruebas de IU codificadas pruebas de IU codificadas permiten ejecutar su aplicación y generar código que impulsa su interfaz de usuario.2012 De Visual Studio incluye herramientas especializadas para crear y editar pruebas de IU codificadas, y también puede editar y añadir al código usted mismo.Por ejemplo, puede crear un procedimiento simple para comprar algo en un sitio Web y, a continuación, editar el código para agregar un bucle que compra muchos artículos.

Pruebas de IU codificadas son particularmente útiles cuando existe validación u otra lógica en la interfaz de usuario — en una página Web, por ejemplo.Puede utilizarlas pruebas unitarias para la interfaz de usuario o como pruebas de integración para toda la aplicación.

Manual de pruebas con Microsoft Test Manager

Pruebas manuales pueden ser planificada o exploratorio.Realizar pruebas manuales con la ayuda de MTM.Normalmente se realizan pruebas en las versiones de la aplicación que se han construido desde código registrado.

Normalmente, pruebas manuales están vinculadas a casos de usuario (o elementos de acumulación de producto u otros requisitos), y los resultados de las pruebas se muestran en los informes del panel Proyecto.Esto significa que cada­uno puede ver rápidamente qué historias se han aplicado con éxito.

Pruebas exploratorias pruebas exploratorias significa simplemente ejecutando la aplicación a probarlo.Sin embargo, ¿por qué necesita MTM para ayudarle a ejecutarlo?

MTM puede grabar tus acciones, comentarios y capturas de pantalla mientras trabaja.Si usted decide crear un informe de fallo, toda esta información se agrega automáticamente, haciendo innecesario para agregar una descripción precisa de cómo reproducir el error.Figura 3 se muestra un ejemplo de la ventana de prueba exploratoria de MTM junto a una aplicación Web que se está probando.

Recording a Screenshot and Making Notes in the Exploratory Testing WindowFigura 3 grabar una captura de pantalla y hacer notas en la ventana de prueba exploratoria

MTM también puede instrumentar la aplicación en sí, tanto en el cliente y el servidor y los datos de registro de eventos que pueden utilizarse para depurar la aplicación.Estos datos se adjuntan automáticamente a su reporte.

Cuando el fallo está arreglado, que querrá repetir los pasos realizados en la exploración para comprobar la corrección.Para ayudar con esto, puede generar un caso de prueba de la sesión exploratoria, en la que se incluyen los pasos pertinentes.

Previsto pruebas con casos de prueba casos de prueba son pruebas manuales que se definen como una serie de pasos que debe realizar el probador.Figura 4 muestra los pasos definidos en un caso de prueba.

Defining Steps and Expected Results in a Test CaseFigura 4 definir pasos y resultados esperados en un caso de prueba

Casos de prueba proporcionan una gran manera para aclarar lo que necesitan los usuarios.Al comienzo del sprint, cuando se están discutiendo cuentos o requerimientos con los usuarios y otros interesados, puede utilizar los pasos como un ejemplo preciso de lo que los usuarios serán capaces de hacer al final del sprint.Cada caso de prueba es sólo una instancia de la exigencia, y así cada requisito está usualmente asociado con más de un caso de prueba.Por ejemplo, si el requisito es poder comprar helado, un caso de prueba detallaremos los pasos para comprar un sabor particular.Se crearía otro caso de prueba para describir una mezcla de sabores de compra.Debe ser el principio rector de la discusión con las partes interesadas: "Cuando se puede realizar con éxito estos casos de prueba, luego te consideramos la historia a aplicarse".

En TFS, tanto las historias o los requisitos y los casos de prueba están representados por elementos de trabajo.Puede enlazarlos para que el progreso de un requisito puede realizar un seguimiento de los resultados de las pruebas.

Al ejecutar un caso de prueba, los pasos se muestran en el lado de la pantalla.Marcar cada paso mientras se ejecuta la aplicación.Al final, marcar si ha pasado la prueba o no.

Al igual que con pruebas exploratorias, tus acciones, comentarios, datos de imágenes y aplicaciones se registran para que pueda crear un reporte detallado muy rápidamente.

Una gran ventaja de estos pasos es que ayuden a cualquier persona Repita la prueba fiable, incluso si no están familiarizados con la aplicación.Cuando una prueba se repite, puede estar seguro de que no si pasa o no, es simplemente porque la prueba era diferente desde la última vez.

También puede generar un caso de prueba planificado desde una sesión exploratoria.Hacer esto ayuda a garantizar que siempre se ejecute la prueba utilizando las mismas acciones.

Automatización de pruebas manuales

Automatizar una parte sustancial de sus pruebas manuales es esencial para minimizar el tiempo de pruebas en el ciclo de DevOps.Visual Studio 2012 apoya esta automatización de varias maneras.

Grabación/reproducción usted puede volver a ejecutar un caso de prueba semiautomatica.En las segunda y sucesivas veces que ejecuta una prueba, MTM reproduce las pulsaciones de teclas y gestos que utilizó en la primera carrera.Todo lo que tienes que hacer es verificar que los resultados que ves son conformes a las expectativas que se detalla en los pasos.

Reproducción hace pruebas manuales más rápido y más fiable.También es posible distribuir la carga de prueba entre colegas que podrían no estar completamente familiarizado con la aplicación.

Incluso si no automatizar completamente una prueba, reproducción rápida y confiable ayuda a reducir la DevOps tiempo de ciclo.Esta función no requiere Visual Studio 2012 para instalarse y no implica escribir código.

Generar pruebas de IU codificadas puede generar una prueba de IU codificada completamente automatizada de un caso de prueba manual grabado ejecutar.El código generado realiza las mismas acciones como la prueba manual.Mediante un editor especial en 2012 de Visual Studio, también puede ampliar la prueba para verificar los resultados y generalizar para repetir la prueba para diferentes datos de entrada.Figura 5 muestra el editor especial.

Editing UI Actions in Visual Studio 2012Figura 5 edición de acciones de la interfaz de usuario en Visual Studio 2012

Vinculación a casos de prueba para probar métodos puede vincular un caso de prueba a cualquier método de prueba, incluso si no ha sido obtenido de la ejecución de pruebas.Se informará el resultado de la ejecución de la prueba como si habían ejecutado los pasos manuales.Normalmente sería vincular el caso de prueba a una prueba de integración que realiza las mismas acciones como la prueba manual, pero impulsa la lógica de negocio directamente, en lugar de utilizar la interfaz de usuario.

Este enfoque tiene la ventaja de que los cambios en el diseño de la interfaz de usuario no invaliden la prueba.También es útil cuando el equipo de desarrollo ya ha creado una prueba de integración adecuada.

Lab Management

Cuando se prueba una aplicación, lo primero que necesita es una máquina para ejecutarlo.De hecho, la mayoría de las aplicaciones hoy en día necesitan varias máquinas.Para un entorno de prueba realista, podría, por ejemplo, necesita instalar un servidor Web, un servidor de base de datos y un explorador cliente en equipos independientes.Figura 6 ilustra este tipo de entorno.

A Sample Lab Environment for Testing a Sales Web SiteFigura 6 muestra el entorno del laboratorio para probar un sitio Web de ventas

Además de la instalación básica, también deseará instalar a agentes que pueden recopilar los datos de evento que fue mencionados en la sección "Pruebas exploratorias".

En MTM una característica denominada Centro de laboratorio hace todo esto sencillo.Centro de laboratorio permite definir entornos de laboratorio.Un entorno de laboratorio es un conjunto de máquinas que se utilizará como un grupo para fines de prueba.

Además de manejar la asignación de las máquinas (para que accidentalmente no utiliza una máquina que ejecuta pruebas de otra persona), centro de laboratorio también instala a los agentes de prueba necesario.Centro de laboratorio proporciona una consola donde puede rápidamente entrar a cualquiera de las máquinas en un entorno.

Centro de laboratorio también es buena en la creación y administración de máquinas virtuales (VMs).Puede crear un entorno virtual, instalar el software de la plataforma correspondiente y luego guarde una copia de la biblioteca de la misma que puede utilizar cuando se desea probar la aplicación.Todo lo que tienes que hacer es declarar una copia limpia del medio ambiente e instalar las nuevas versiones de los componentes de la aplicación.También puede automatizar este proceso de implementación.

Mediante el centro de laboratorio — y, en particular, aprovechando sus instalaciones con VMs — puede reducir significativamente el tiempo de configuración de laboratorio en comparación con los enfoques más tradicionales para mantener a un laboratorio.Centro de laboratorio es un contribuyente importante a reducir el tiempo empleado en cada ciclo de DevOps.

Pruebas en TFS automatizadas

Inicialmente se realizan pruebas automatizadas en Visual Studio 2012 en equipo de los desarrolladores.Después de que el código ha sido registrado en el repositorio de origen, hay varias maneras en que pueden realizar pruebas sobre el código integrado por el servicio de compilación.

Compilaciones periódicos el servicio de compilación el código se compila y ejecuta las pruebas.Puede crear definiciones de compilación para especificar qué pruebas se deben ejecutar, y puede especificar cuándo debería ejecutar.Por ejemplo, podría ejecutar un conjunto básico de pruebas sobre una base continua y ejecutar un conjunto más extenso de cada noche.

Construir los resultados pueden verse en Visual Studio 2012 y también están disponibles en Web de TFS servicio su proyecto.Correos electrónicos pueden avisarle de fallas.

Implementación de laboratorio como hemos descrito anteriormente, puede asignar un grupo de equipos de laboratorio para una prueba mediante el centro de laboratorio.Definiendo una compilación de laboratorio, puede automatizar este proceso.Cuando se activa su generación — por ejemplo, cuando código está marcada en, o en un momento determinado del día — la construcción comienza por compilar todo el código de aplicación y prueba.Si es exitosa, se le asigna un entorno de laboratorio, y si es un entorno virtual, se puede establecer volver a un estado fresco.Los componentes de la aplicación, a continuación, se despliegan en las máquinas correctas, y las pruebas están instaladas en la máquina cliente designado desde donde conducen la aplicación.

Las pruebas pueden ser pruebas automatizadas de ningún tipo, pero normalmente se utiliza este tipo de construcción para realizar pruebas de integración grande o pruebas de toda la aplicación.

Si sus pruebas están vinculadas a casos de prueba, los resultados serán registrados en comparación con las historias de usuario relacionados o los requisitos y aparece en los informes de progreso del proyecto.

Informes

TFS proporciona una serie de gráficos y tablas que muestran el progreso de un proyecto.Puede verlas individualmente o en paneles de proyecto.Entre los informes son varias relacionadas a los ensayos.

Por ejemplo, el informe de estado de prueba de historia de usuario, se muestra en la figura 7, muestra la lista de historias que está trabajando en el sprint actual.Además del trabajo de desarrollo realizado para cada caso, el gráfico muestra el éxito o el fracaso de las pruebas asociadas.Si fallas fueron descubiertos durante la ejecución de las pruebas, los informes de error resultante también están vinculados a los requerimientos.

Figura 7 historia de usuario prueba informe de estado

 
 

       
         
                 
           
     
         
                                     

Los resultados en la tabla provienen de ambos las pruebas manuales de ejecución más recientemente y se ejecuta la prueba automatizada.

El informe de progreso del Plan de prueba, se ilustra en la figura 8, muestra cuántos casos de prueba fueron creados para el sprint actual y cuántos se han ejecutado.

Test Plan Progress Report for a SprintFigura 8 prueba el informe de progreso del Plan para un Sprint

Algunos equipos como crear casos de prueba al comienzo de cada sprint, como un destino para el equipo.Todas las pruebas deben ser verdes al final del sprint.

Visual Studio 2012 y desarrollo continuo

Ahora tiene cierta familiaridad con el rango de la Visual 2012 estudio prueba de las funciones, de pruebas unitarias para toda aplicación de pruebas manuales.

Los DevOps ciclo desarrollo de vistas como sólo la mitad de un proceso que también incorpora comentarios de operaciones.Dependiendo del contexto, el ciclo de DevOps será corto o largo.Si está desarrollando una central nuclear, esperemos que irás alrededor del bucle muy lentamente.Si está ejecutando una aplicación Web, puede pasar alrededor de ella cada pocos días.Ciclos lentos y rápidos son igualmente válidos y apropiados para diferentes tipos de sistemas.Ambos incorporan la necesidad de pruebas, en diferentes grados.Si el ciclo rápido de desarrollo continuo es apropiado para su proyecto, es importante reducir el tiempo que lleva para realizar cada acción en el bucle.Probablemente también hacer menos distinción entre las funciones del programador y tester que en proyectos que funcionan en una medida más ritmo.

Las herramientas disponibles en Visual Studio 2012 pueden reducir considerablemente la cantidad de tiempo que se necesita para probar la aplicación.Aquí están algunos puntos que debe recordar:

  • Entornos de laboratorio limpio pueden configurarse rápida y automáticamente, especialmente mediante el uso de máquinas virtuales.Aprovechar el centro de laboratorio.
  • Grabación de acciones durante la exploratoria y planificada de pruebas permite crear informes de error rápida y confiable, reduciendo la probabilidad de que un error desaparecerá cuando alguien intenta reproducirlo.
  • Puede implementar una transición gradual de pruebas manuales para pruebas automatizadas.Las pruebas automatizadas manejar la mayor parte de las pruebas de regresión mientras manual pruebas centrarse en historias nuevas y actualizadas.
    • De las pruebas exploratorias, puede generar casos de prueba manual repetibles.
    • Puede grabar pruebas y el juego de vuelta rápida y fiable.
    • Puede generar pruebas de IU codificadas de ejecuciones de prueba.Como alternativa, puede enlazar pruebas de integración codificada por separado para casos de prueba.

Figura 9 muestra la progresión de las pruebas exploratorias para pruebas automatizadas.

Test ProgressionFigura 9 prueba progresión

  • Casos de prueba puede ayudarle a describir sus historias de usuario precisamente.Puede trabajar con los interesados para escribir los pasos para reducir cualquier malentendido sobre lo que hacen las historias.
  • Las pruebas están vinculadas a los requisitos (o historias de usuario o elementos de acumulación de producto) para que pueda ver informes completos sobre hasta qué punto se han cumplido las necesidades de los usuarios — no simplemente en términos de la labor realizada sobre ellos, pero si son exitosos.Las pruebas proporcionan la meta para el equipo de desarrollo en cada sprint.
  • Casos de prueba y requisitos pueden vincularse con guiones gráficos en PowerPoint, documentos de requerimientos o modelos de lenguaje de modelado unificado.Cuando realice cambios en el guión gráfico, se pueden rastrear los cambios necesarios para las pruebas.
  • Un casos de prueba juntos prueba plan enlaces, código, requisitos, entornos de pruebas y ajustes de prueba y el proyecto de equipo.Si el equipo pasa unos meses trabajando en otra cosa antes de regresar para mejorar un producto, es fácil de todo lo necesario para la prueba reconstruir.

Le hemos dado una visión general de cómo Visual Studio 2012 encaja con el ciclo de DevOps.Ahora debe comprender por qué necesita un enfoque racionalizado para pruebas y lo que ofrece herramientas de Visual Studio 2012 para ayudarle a cumplir con este objetivo.Si desea más información, lea "Pruebas de continua entrega con Visual Studio 2012 RC" en MSDN Library, en bit.ly/KHdOq4.Es una guía detallada que cubre todos los aspectos de la infraestructura de prueba proporcionado por Visual Studio 2012.Relacionados con artículos incluyen "Verificar código por usar pruebas unitarias" a bit.ly/dz5U3m y "Pruebas de la aplicación" a bit.ly/NbJ01v.

Larry Brader ha sido un tester senior en los patrones de Microsoft & equipo de prácticas de los últimos años.Antes de trabajó como programador y tester en tecnologías médicas y militares.

AlanCameron Wills es un escritor de programación en la División de desarrollo de Microsoft.En vidas anteriores ha sido un desarrollador, arquitecto de software y consultor en métodos de desarrollo.

Gracias a los siguientes expertos técnicos por su ayuda en la revisión de este artículo: Howie Hilliker, Katrina Lyon-Smith, Peter Provost y Rohit Sharma