Comments 2
Если я правильно понимаю, то вы готовите конкретные данные и переводите их в тесты.
Но вот тут вопрос возникает — почему бы не описать правила и на основе этих правил создавать полный набор данных?
Например, есть таблица, в которой есть поля с типами NVARCHAR2 и NUMBER. Есть ещё какой-нибудь foreign key, primary key и т.д. Ещё поля с Nullable = true/false. Короче, есть спецификация данных. Мы можем на каждое из правил придумать проверки: не уникальное значение, отсутствие соответствующего значения для внешнего ключа и т.д.
Всё, на основе этого мы можем просто подсунуть системе генерации схему данных в БД и сгенерировать наборы данных.
И тогда нам остаётся только поддерживать схему данных в актуальном состоянии.
Думали о таком подходе? Это вообще реально сделать за адекватное время? Или этот подход не взлетит потому что…?
Но вот тут вопрос возникает — почему бы не описать правила и на основе этих правил создавать полный набор данных?
Например, есть таблица, в которой есть поля с типами NVARCHAR2 и NUMBER. Есть ещё какой-нибудь foreign key, primary key и т.д. Ещё поля с Nullable = true/false. Короче, есть спецификация данных. Мы можем на каждое из правил придумать проверки: не уникальное значение, отсутствие соответствующего значения для внешнего ключа и т.д.
Всё, на основе этого мы можем просто подсунуть системе генерации схему данных в БД и сгенерировать наборы данных.
И тогда нам остаётся только поддерживать схему данных в актуальном состоянии.
Думали о таком подходе? Это вообще реально сделать за адекватное время? Или этот подход не взлетит потому что…?
Дело в том, что задача, которая изначально стояла перед нами — это «проверка корректности работы правил экспертной системы» (поверхностно я обмолвился по этому поводу в начале).
При такой постановке принципиально нужно формулировать тест в терминах «входные данные» + «правильный ответ», причем как-раз «правильный ответ» составляет суть бизнес требований к экспертной системе.
Т.е. если бы даже можно было бы создать довольно полный набор входных данных, их преобразование в «правильный ответ» не может быть сделано автоматически — это как раз задача подсистемы которую мы тестируем.
Что касается полноты тестового покрытия в нашем случае. Я могу только приблизительно оценить количество полных вариантов для одного правила — примерно 400 возможных адекватных бизнес-сценариев (про неадекватные, которые заказчик называет «exception», я даже говорить не хочу). Отдельные нюансы покрываются юнит тестами.
У нас есть на данный момент в среднем 40-50 сценариев на правило, но они покрывают наиболее вероятные сценарии — около 90% бизнес ситуаций.
Так что «техническое» покрытие выглядит незначительным — около 10%, и это не очень хорошо. Но поскольку мы не тестируем полностью «черный ящик», с точки зрения заказчика мы покрываем тестами около 90% ситуаций.
Как-то так…
При такой постановке принципиально нужно формулировать тест в терминах «входные данные» + «правильный ответ», причем как-раз «правильный ответ» составляет суть бизнес требований к экспертной системе.
Т.е. если бы даже можно было бы создать довольно полный набор входных данных, их преобразование в «правильный ответ» не может быть сделано автоматически — это как раз задача подсистемы которую мы тестируем.
Что касается полноты тестового покрытия в нашем случае. Я могу только приблизительно оценить количество полных вариантов для одного правила — примерно 400 возможных адекватных бизнес-сценариев (про неадекватные, которые заказчик называет «exception», я даже говорить не хочу). Отдельные нюансы покрываются юнит тестами.
У нас есть на данный момент в среднем 40-50 сценариев на правило, но они покрывают наиболее вероятные сценарии — около 90% бизнес ситуаций.
Так что «техническое» покрытие выглядит незначительным — около 10%, и это не очень хорошо. Но поскольку мы не тестируем полностью «черный ящик», с точки зрения заказчика мы покрываем тестами около 90% ситуаций.
Как-то так…
Sign up to leave a comment.
Генерация автоматических тестов: Excel, XML, XSLT, далее — везде