Автоматизация для сложной системы БД+отчеты

Не знаю, с какой стороны подступиться к проекту) Есть большая база данных, далее с помощью определенных тулов разрабатываются юниверсы, на основе которых будут строиться отчеты (web и excel). Тестирование нужно проводить в 2 этапа, т.е. сначала проверить корректно ли созданы юниверсы (т.е. правильные ли данные из них можно получить), ну и второй этап - проверка самих отчетов (логика). Нужно по-максимому все автоматизировать, поскольку количество юниверсов и отчетов велико, а объем данных для них вообще огромный. Хотелось бы подобрать некую единую систему для проверки всех частей, ну или хотя бы набрать инструментарий, который можно бы было объединить в эту систему. По сути, мы имеем доступ только к базе и к специфичному инструментарию (т.е. ГУИ сторонних программ), а так же возможность сохранить итоговые отчеты в файлы. Может у кого-то есть опыт работы на подобных проектах или идеи по подбору подходящего инструментария для тестирования?

• ФИО: Petrov Sergey
• Город: МО, Лобня

Очень интересная (для меня) задачка! Люблю копаться с запросами :)

Можете объяснить, что такое "юнивёрсы"? XSLT?

Если я правильно понял, то сначала в юнивёрс пихается модель отчёта, которая потом конвертится в веб/эксель. Так?Для тестирования этой конвертации количество тестов минимальное, т.к. нам нужно лишь удостовериться, что данные из "юнивёрса" правильно импортировались в отчёт.Тесты для отчётов достаточны такие, чтобы они покрывали все поля отчёта "ненулловыми" значениями.

Далее техническая составляющая.Я бы сформировал свой класс "модель отчёта", в котором внутренние поля - поля отчёта/юнивёрса. Если множества полей различны, то класс юнивёрса отдельно и класс отчёта отдельно. Если веб- и эксель-отчёты разные (по набору полей), то и для них отдельные классы.Класс работы с этой/этими моделью/-ями (конвертация из юнивёрса в любой класс отчёта).Класс проверки. Три метода: проверка юнивёрса (на вход юнивёрс), проверка веб и проверка эксель-отчётов. Плюс метод сравнения поля: на вход значение "должно быть" и значение "есть".

Тесты на юнивёрс:1) по одному тесту на каждое поле (только значение). В целях выявления зависимостей я бы при проверке тестировании одного поля проверял бы весь юнивёрс (в методе проверки юнивёрса вызов методов сравнения по всем полям). Это, так называемые, смоук тесты. Проверяемые значения полей - рандомные (фикс не использовать ни в коем случае, ибо эффект пестицида!)2) сложные случаи (явные зависимости). Например, поле "тип" может принимать значения от 0 до 19. Прогон в цикле по всем значениям этого поля и проверка для каждого значения всего юнивёрса.

Тесты на веб-отчёт:1) генерим свой юнивёрс на каждое поле (N раз), чтобы оно было ненулловым. Проверяем полное соответствие в отчёте и в юнивёрсе. Тестов N штук. Почему при тесте на одно поле проверяем все поля? Чтобы выявить зависимости, если они есть.Тесты на эксель-отчёт:1) аналогично тестам на веб-отчёт. Тоже на каждое поле по одному тесту с ненулловым значением поля.

• ФИО: Юлия
• Город: НН

Юниверс (universe) - семантический срез данных предназначен для удобства восприятия данных при составлении отчета.

По сути, юниверс - это промежуточный слой, которые представляет данные в разрезе бизнес-логики, а не хранения базы данных.

(на мой взгляд, понятно описано тут с примерами http://www.interface. sp?artId=24980)

Соответственно, юниверс - это не модель отчета, а скорее источник агрегированных данных для отчета. Цепочку построения отчета стоит рассматривать так: есть логика построения отчета (поля, значения, агрегированные значения) - отчет при построении запрашивает данные из своего источника данных, т.е. из юниверса, а юниверс в свою очередь обращается к базе данных и получает нужные данные оттуда, сам их перерабатывает и возвращает отчету. Собственно поэтому и требуется тестирование в 2 этапа. 1 - проверка, а правильно ли построен сам юниверс и те ли данные он возвращает и обрабатывает (тут еще сложность в том, что сам юниверс руками не пощупать - он создается и храниться только в определенной программе), 2 этап - это уже проверка самих отчетов, сгенерированных на основе юниверса. Отчетов много, на основе одного юниверса строяться несколько отчетов. Тут сложность в том, что отчеты тоже генеряться в определенной программе, но результаты могут быть сохранены в файл. Отчеты могут быть или в веб форме или в экселе (т.е. один отчет не может быть и в той и в другой форме - это частично сокращает время на тестирование :) ). Как-то так.

• ФИО: Dmitry Petrov

судя по описанию, юниверс это файл. Если это файл то посмотреть его содержимое и проверить, проблемы быть не должно.

вообще и то и другое является отчётом, одно просто называется по другому, а второе это отчёт на основе отчёта.

я бы сделал проверку типа такого:

- анализ "юниверса" на предмет получаемых данных

- наполнение этими данными БД

- запуск построения среза юнивёрса

- проверка ожидаемых значений

те же яйца тока с боку для отчётов.

• ФИО: Petrov Sergey
• Город: МО, Лобня

Из терминологии :) Юниверс (universe) - семантический срез данных предназначен для удобства восприятия данных при составлении отчета. Соответственно, юниверс - это не модель отчета, а скорее источник агрегированных данных для отчета. Цепочку построения отчета стоит рассматривать так: есть логика построения отчета (поля, значения, агрегированные значения) - отчет при построении запрашивает данные из своего источника данных, т.е. из юниверса, а юниверс в свою очередь обращается к базе данных и получает нужные данные оттуда, сам их перерабатывает и возвращает отчету. Собственно поэтому и требуется тестирование в 2 этапа. 1 - проверка, а правильно ли построен сам юниверс и те ли данные он возвращает и обрабатывает (тут еще сложность в том, что сам юниверс руками не пощупать - он создается и храниться только в определенной программе), 2 этап - это уже проверка самих отчетов, сгенерированных на основе юниверса. Отчетов много, на основе одного юниверса строяться несколько отчетов. Тут сложность в том, что отчеты тоже генеряться в определенной программе, но результаты могут быть сохранены в файл. Отчеты могут быть или в веб форме или в экселе (т.е. один отчет не может быть и в той и в другой форме - это частично сокращает время на тестирование :) ). Как-то так.

Если юнивёрс хранится в определённой программе (его нельзя пощупать), то как Вы собрались его тестировать? Только косвенным путём: по следу в отчёте.Я бы написал свой аналог юнивёрса, чтобы не быть завязанным на статические входы-выходы.Так как щупать и сравнивать я могу только отчёты, то буду на основе данных в БД формировать свой юнивёрс, вытягивать необходимые данные в нужные поля отчёта и сравнивать с тем, что лежит в отчёте чёрного ящика.

А это легко прикручивается к тому, что я описал в предыдущем своём комменте.Мой ключевой упор: не завязываться на статику, а зависеть от текущего состояния БД (которое каждый раз новое).