Советы по тестированию устаревшего приложения с большим объемом данных

Question

Я работаю над очень большим устаревшим приложением с большим объемом данных.Как база кода, так и база данных огромны по масштабу.Большая часть бизнес-логики распределена по всем уровням, в том числе и в хранимых процедурах.

Есть ли у кого-нибудь какие-либо предложения о том, как начать эффективно применять "модульные" тесты (технически интеграционные тесты, потому что им нужно тестировать на разных уровнях для одного аспекта практически любого данного процесса) в приложении?Текущая архитектура с трудом поддерживает какой-либо тип внедрения или издевательства.Для облегчения тестирования пишется новый код, но как насчет устаревшего кода?Из-за сильной зависимости от самих данных и бизнес-логики в базе данных в настоящее время я использую встроенный sql для поиска данных для использования при тестировании, но это отнимает много времени.Создания представлений и / или хранимых процедур будет недостаточно.

Какие подходы вы использовали (если применимо)?Что сработало?Что не сработало и почему?Будем признательны за любые предложения.Спасибо.

Answer 1

Получите копию Эффективная работа с устаревшим кодом автор: Майкл Фезерс.Он полон полезных советов по работе с большими, непроверенными кодовыми базами.

Еще одна хорошая книга - это Шаблоны Объектно-ориентированного реинжиниринга.Большая часть книги не посвящена конкретно объектно-ориентированному программному обеспечению.Полный текст доступен для бесплатного скачивания в формате PDF.

Из моего собственного опыта:постарайся...

• Автоматизируйте сборку и развертывание
• Переведите схему базы данных в систему управления версиями, если это еще не сделано.Обычно базы данных содержат справочные данные, которые необходимы для существования транзакционного кода, прежде чем он сможет работать.Получите это тоже под контролем версий.Такие инструменты, как развертывание dbdeploy может помочь вам легко перестроить схему и справочные данные из последовательности дельт.
• Установите версию базы данных (и любых других инфраструктурных сервисов) на свою рабочую станцию разработки.Это позволит вам работать с базой данных без необходимости постоянно обращаться к администраторам баз данных.Это также быстрее, чем использование схемы на общем сервере в удаленном центре обработки данных.Все основные коммерческие серверы баз данных имеют бесплатные (как в beer) версии для разработки, которые работают на Windows (если вы застряли в незавидной ситуации разработки на Windows и развертывания на Unix).
• Перед началом работы над областью кода напишите сквозные тесты, которые примерно описывают поведение области, над которой вы работаете.Сквозной тест должен проверять систему извне - управляя ее пользовательским интерфейсом или взаимодействуя через сетевые службы, - поэтому вам не нужно будет изменять код, чтобы установить его на место.Это будет действовать как (несовершенный) регрессионный тест и даст вам больше уверенности в проведении рефакторинга внутренних компонентов системы в направлении структуры, которую легче тестировать с помощью модуля.
• Если существуют планы тестирования вручную, прочтите их и посмотрите, что можно автоматизировать.Большинство ручных планов тестирования почти полностью написаны по сценарию, и поэтому они представляют собой низко висящие плоды автоматизации
• Как только вы получите сквозное покрытие тестами, реорганизуйте код в более слабо связанные блоки по мере его изменения и / или расширения.Окружите эти модули модульными тестами.

Вещи, которых следует избегать:

• Копирование данных из производственной базы данных в среду, которую вы используете для автоматического тестирования.Это сделает ваши тесты непредсказуемыми.Конечно, запустите систему с копией производственных данных, но используйте ее для поискового тестирования, а не для регрессионного тестирования.
• Откат транзакций в конце тестов для изоляции тестов друг от друга.Это не будет проверять поведение, которое происходит только при фиксации транзакций, и приведет к удалению данных, ценных для диагностики сбоев тестирования.Вместо этого тесты должны гарантировать, что база данных находится в известном начальном состоянии при их запуске.
• Создание "крошечного" набора данных для выполнения тестов.Это затрудняет понимание тестов, поскольку они не могут быть прочитаны как единое целое."Крошечный" набор данных вскоре становится очень большим по мере добавления тестов для различных сценариев.Вместо этого тесты могут вставлять данные в базу данных для настройки тестового приспособления.

Answer 2

& # 8220; Тестирование устаревших приложений, & # 8221; основные моменты:

<Ол>

Общий обзор того, как создаются тесты в AscentialTest

Способы преобразования устаревших объектов в новую платформу. Компоненты определения объекта

Как обеспечить, чтобы модернизированная версия приложения давала одинаковые результаты

Для получения более подробной информации об использовании тестируемого устаревшего приложения, проверьте здесь:

http: // application-management .cioreview.com / Whitepaper / тестирование-наследие-приложения модернизация-УЖР-529.html