Pruebas de carga - 10 punteros a un mejor desempeño

Pruebas de carga - 10 punteros a un mejor desempeño

Word Count:
983

Resumen:
Las pruebas de carga cubre más que las pruebas de rendimiento. Incluye pruebas de resistencia, pruebas de resistencia, pruebas de fiabilidad y las pruebas de concurrencia. El "sus pruebas de rendimiento sólo" ver los resultados en la mayoría de los proyectos de hacer pruebas de carga muy poco lugar a costes adicionales y los clientes insatisfechos. Este artículo presenta un enfoque diferente que evita estos inconvenientes y genera beneficios comerciales adicionales.


Palabras clave:
rendimiento de carga de la prueba técnica de aplicación de pruebas de escalabilidad de software


Cuerpo del artículo:
La gente a menudo equiparan la prueba de carga con las pruebas de rendimiento. Pruebas de carga es visto como una manera de responder a la pregunta "¿Qué tan rápido el sistema de responder?" Esta visión se tiende a significar que las pruebas de carga se ve como una final de la actividad de proyecto. Sólo al final del desarrollo tendremos la final de ejecución de pruebas de rendimiento y por lo que sólo puede confirmar entonces que realiza con la suficiente rapidez en el mundo real y sin problemas de transición en servicio directo.

Enfoque equivocado! Esto es muy riesgoso y pierde los beneficios de iniciar las pruebas de carga temprana y su aplicación en todo el proyecto. Con este enfoque es la vela del sistema a través de pruebas de carga y la transición sin problemas en el servicio? De vez en cuando sí. Pero con más frecuencia el sistema empieza a fallar como la carga comienza a ser aplicado, incluso con pequeños aumentos en el volumen .. Por primera vez hay demandas concurrentes en el sistema de arbitraje y sobre los recursos es necesario. Caminos a través de código que nunca han sido ejecutadas se activan, se presentan situaciones que nadie realmente pensado. Transacciones no. Accidente de Sistemas. Después de estos problemas se solucionan y más carga se aplica en una prueba, entonces encuentras problemas como el agotamiento de los recursos, desbordamientos de buffer, tiempos de espera y el comportamiento incoherente. El verdadero trabajo necesarias para que un pre-funcional sistema de producción en una solución robusta ha hecho más que empezar.

Abundan los ejemplos de productos que fracasó cuando las pruebas de carga en marcha y, después de mucho esfuerzo, el estrés y los gastos, han sido dejados de lado. Peor aún son los que las pruebas de carga se perdió por completo y no de manera espectacular durante la operación en vivo. Un desarrollador de portal de Internet recientemente ha dejado de desarrollo de un nuevo servicio, que había completado el desarrollo funcional, cuando las pruebas de carga reveló los problemas estructurales fundamentales y la codificación ineficiente que condujo a un bajo rendimiento y un sistema inestable.

Entonces, ¿qué debe hacer para evitar estos riesgos? Todos sabemos que es mejor para encontrar fallas prematuras cuando cuestan mucho menos para fijar todavía las pruebas de carga sigue siendo la izquierda hasta lo más tarde posible. Los tipos de errores que encuentra con frecuencia necesitan cambios en la arquitectura y reescribe mayores, que son entonces son extremadamente costosas de aplicar. La respuesta es que usted debe comenzar temprano. Diferentes formas de la prueba de carga debe ser aplicado repetidas veces en todo el proyecto para identificar los problemas a tiempo y para comprobar que el sistema no es salirse de la pista.

Esta es una extensión natural de la práctica de la prueba la que orienta el desarrollo. LED de prueba de desarrollo, donde las pruebas automatizadas se escriben primero y el código debe pasar estas pruebas como se desarrolla, ofrece grandes beneficios. Sin embargo, en su forma actual, el objetivo de esta prueba es la funcionalidad. A medida que evoluciona la situación funcional del software siempre es conocida y por lo tanto, manejable, las fallas funcionales son cortados de raíz para evitar soluciones de alto costo, el riesgo funcional es muy reducido. No los riesgos para otros. Si un proyecto se realiza la carga temprana y continua de pruebas, es mucho más amplia y global de reducción de riesgos. Para hacer efectivo este:

1. Estudiar el sistema y realizar un análisis de riesgo a fin de ayudar a las amenazas al sistema, esto le ayudará a dar prioridad a las actividades de prueba de carga.
2. Recopilar datos para permitir la comparación de la eficacia de diferentes compilaciones. Esto permite controlar la tendencia a largo plazo, "es el sistema utilizando el tiempo de procesador más y más a hacer el mismo trabajo?" Estos datos pueden ser utilizados para predecir las necesidades de recursos en diferentes niveles de demanda y apoyo a las predicciones de escalabilidad.
3. Ejecutar las pruebas destinadas a evaluar el comportamiento del sistema y provocar errores en la carga. Utilice las cargas de trabajo que simulan los patrones esperados de la demanda de observar el comportamiento global del sistema. Utilice las cargas de trabajo extremas especialmente dirigido a investigar la vulnerabilidad del sistema.
4. Incluye toda la gama de pruebas de carga en la serie de pruebas. Esto significa que las pruebas de rendimiento con los típicos y las cargas de trabajo ocupados período; pruebas de tensión para comprobar los picos de demanda atípicos y los efectos de agotamiento de recursos, pruebas de resistencia que utiliza tanto período de funcionamiento y pruebas de funcionamiento acumulativo; pruebas de fiabilidad que se ejecuta un montón de operaciones y comprueba si las transacciones ocasionales no, pruebas de concurrencia de dos usuarios que trabajan en la misma cuenta al mismo tiempo.
5. Las actividades de medición de diseño como los científicos podrían diseñar un experimento, el diseño para proporcionar datos que pueden ser analizados. Muestra el sistema bajo diferentes cargas de trabajo de estado estacionario para proporcionar datos de múltiples conjuntos de apoyo a la interpolación. Elija las cargas de trabajo para permitir una estimación de los costos de recursos para cada tipo de transacción.
6. Objetivo para el middleware primero con las actividades genéricas y evolucionar la suite, como se desarrolla la funcionalidad. Comience temprano y luego probar cada versión incremental del sistema, en primer lugar con el conjunto anterior y luego con una suite vez que aborda la nueva funcionalidad.
7. Invertir el tiempo y recursos para trabajar en una escala representativa. Tal vez el banco de pruebas no puede ser plena escala, pero no debe ser de dos órdenes de magnitud menor que el sistema previsto. Sea inteligente e innovadora de utilizar eficazmente los recursos para proporcionar un adecuado banco de pruebas a gran escala. Los gastos en que incurrirá si no se hace esto será muy superior el coste de proporcionar el banco de pruebas.
8. No se demore, prueba de un incremento tan pronto como sea posible. No se salte uno o acabarás saltar a todos. Comparar las medidas y el comportamiento con el anterior, ¿es mejor o peor?
9. Proporcionar una carga de fondo para las pruebas funcionales. Características que descarga de trabajo puede fallar cuando el sistema tiene otras cosas en qué pensar.
10. Considere la posibilidad de eventos ocasionales, tales como fallas en el servidor y la reconfiguración del sistema. ¿Estos deben ser a prueba con carga?

En conclusión, es necesario incorporar las pruebas de carga en todo el proceso de desarrollo. Dejando de pruebas de carga hasta el tramo final en el que vivir servicio es una receta para el desastre. Si esto se convirtió en una práctica común entonces mucho más aplicaciones y sistemas que los trabajos se entreguen a tiempo y de presupuesto.