Sugerencias para probar la aplicación heredada con uso intensivo de datos

Question

Estoy trabajando en una aplicación heredada con uso intensivo de datos muy grande. Tanto la base de datos de código base & son de escala masiva. Una gran parte de la lógica empresarial se extiende a todos los niveles, incluidos los procedimientos almacenados.

¿Alguien tiene alguna sugerencia sobre cómo comenzar a aplicar las pruebas de "unidad" (pruebas de integración técnica porque deben probar en niveles para un aspecto único de casi cualquier proceso) en la aplicación de una manera eficiente? La arquitectura actual no admite fácilmente ningún tipo de inyección o burla. Se está escribiendo un nuevo código para facilitar las pruebas, pero ¿qué pasa con el código heredado? Debido a la fuerte dependencia de los datos en sí y de la lógica de negocios en la base de datos, actualmente estoy usando sql en línea para encontrar datos que se utilizarán para las pruebas, pero estos requieren mucho tiempo. Crear vistas y/o procedimientos almacenados no será suficiente.

¿Qué enfoques ha tomado (si corresponde)? ¿Qué funcionó? ¿Qué no & por qué? Cualquier sugerencia sera apreciada. Gracias.

Answer 1

Obtenga una copia de Working Effectively with Legacy Code de Michael Feathers. Está lleno de consejos útiles para trabajar con grandes bases de datos no probadas.

Otro buen libro es Object Oriented Reengineering Patterns. La mayor parte del libro no es específico del software orientado a objetos. El texto completo está disponible para su descarga gratuita en formato PDF.

Desde mi propia experiencia: tratar de ...

• automatizar la construcción y el despliegue
• Obtener el esquema de base de datos en el control de versiones, si no lo es todavía. Por lo general, las bases de datos incluyen datos de referencia que el código transaccional debe existir antes de que pueda funcionar. Obtener esto bajo control de versión también. Herramientas como dbdeploy pueden ayudarlo a reconstruir fácilmente un esquema y datos de referencia de una secuencia de deltas.
• Instale una versión de la base de datos (y cualquier otro servicio de infraestructura) en su estación de trabajo de desarrollo. Esto le permitirá trabajar en la base de datos sin tener que pasar continuamente por los DBA. También es más rápido que usar un esquema en un servidor compartido en un centro de datos remoto. Todos los principales servidores de bases de datos comerciales tienen versiones de desarrollo gratuitas (como en la cerveza) que funcionan en Windows (si estás atrapado en la poco envidiable situación de desarrollar en Windows y desplegar en Unix).
• Antes de comenzar a trabajar en un área del código, escriba pruebas de extremo a extremo que cubran aproximadamente el comportamiento del área en la que está trabajando. Una prueba de extremo a extremo debe ejercer el sistema desde el exterior, controlando su interfaz de usuario o interactuando a través de servicios de red, por lo que no necesitará cambiar el código para ponerlo en su lugar. Actuará como una prueba de regresión (imperfecta) y le dará más confianza para refactorizar las partes internas del sistema hacia una estructura que sea más fácil de probar por unidad.
• Si hay planes de prueba manuales, léalos y vea lo que se puede automatizar. La mayoría de los planes de prueba manual están escritos casi en su totalidad y también lo son las frutas para automatización.
• Una vez que tiene cobertura de pruebas de extremo a extremo, refactorice el código en unidades más ligeramente acopladas a medida que lo modifique y/o amplíe. Rodee esas unidades con pruebas unitarias.

cosas que deben evitarse:

• Copiar datos de la base de datos de producción en el medio ambiente se utiliza para realizar pruebas automatizadas. Esto hará que tus pruebas sean impredecibles.Claro, ejecute el sistema contra una copia de los datos de producción, pero utilícelo para las pruebas exploratorias, no para las pruebas de regresión.
• Recuperación de transacciones al final de las pruebas para aislar las pruebas entre sí. Esto no probará el comportamiento que solo ocurre cuando se comprometen las transacciones, y descartará los datos que son valiosos para diagnosticar fallas de prueba. En cambio, las pruebas deben garantizar que la base de datos se encuentre en un estado inicial conocido cuando comienzan.
• Creando un conjunto de datos "minúsculos" para que se ejecuten las pruebas. Esto hace que las pruebas sean difíciles de entender porque no se pueden leer como una sola unidad. El conjunto de datos "pequeño" pronto crece muy grande a medida que agrega pruebas para diferentes escenarios. En cambio, las pruebas pueden insertar datos en la base de datos para configurar el dispositivo de prueba.

Answer 2

“modernización pruebas de aplicaciones Legacy,” Highlights:

visión general

1. alto nivel de cómo las pruebas se crean en AscentialTest

2. maneras de convertir el legado objetos a los nuevos componentes de la plataforma de objetos definición

3. Cómo asegurarse de que la versión modernizada de la aplicación produce los mismos resultados

Para más detalles sobre el uso de la aplicación de las pruebas de legado, no marque aquí:

http://application-management.cioreview.com/whitepaper/testing-legacy-application-modernization-wid-529.html