Автоматизация тестов в прикладной системе
#1
Отправлено 22 июля 2004 - 13:52
При реализации прикладного проекта на основе готового продукта (скажем так, что готовый продукт - это достаточно универсальная среда разработки и проектирования бизнес-процессов) возникает необходимость тестирования реализованных прикладных алгоритмов, которые выполняют прикладные специфические для данного проекта действия. Понимаю, что это достаточно расплывчато... :unsure:
Более подробно - среда разработки позволяет без программирования сделать визуальную настройку системы, динамически формировать формы, отображать списки, сделать настройку рабочего пространства, возможность использования атрибутов различных типов (дата, текст и т.д...), выполнить настройку модели данных без программирования и "ковыряния" в БД, т.е. настроить связи между прикладными сущностями, их множественость и т.д.. Тем не менее, для реализации прикладного проекта этого не достаточно :( Необходимо написать ещё кучу всякой всячины, которая присуща только данному проекту, ну, например, специфические расчеты для той отрасли, в которой реализуется проект (расчет потребления электоэнергии потребителем, расчет индексации, регистрация показаний промышленных потребителей и т.д.), надо в соответствии с проектом присвоить наименования сущностям (объекты типа "договор", "потребитель", "прибор учета" и т.д.), настроить специфические связи (например, точка учета электроэнергии связана с прибором учета) и т.д.. То, что касается настроечной части можно подвергнуть очень поверхностному тестированию и в основном проверить на соответствие здравому смыслу. Кроме того, если уж там, что и обнаружится, то это исправляется без перепрограммирования, это не очень трудоемко и несложно. Кроме того, контроль того, что касается настройки выполняет само ядро... :rolleyes:
Совсем по-другому обстоят дела с тем, что пишется программистами именно для этого прикладного проекта :(
Вот тут-то я и прошу совета. Дело в том, что, например, для тестирования расчета индексации необходима просто куча данных, которые можно получить только реализовав какие-то другие сценарии (регистрация договора для того, чтобы в процессе индексации знать признаки, которые влияют на ее расчет; проведение расчетов и выставление по ним платежных докуметов, их оплата и т.д. для того, чтобы иметь предмет индексации). В общем, если количество тестовых ситуаций для расчета индексации было не очень большим, то можно было бы реализовать поочередно каждый сценарий и только потом проверить индексацию. Но это слишком долго, а вариатов индексирования/неиндексирования очень много :( Это только лишь индексация, а бизнес-процессов в реализуемом проекте просто куча. Как их тестировать..??? Руками? Долго и не очень эффективно. Писать автоматические тесты? Как их писать и не будет ли сложность тестов превышать сложность реализуемых алгоритмов? Посоветуйте что-нибудь, может, у кого-нибудь есть опыт в решении подобных проблем...
#2
Отправлено 22 июля 2004 - 14:35
Протестировать абсолютно все в такой большой системе не удастся - не хватит ни времени, ни ресурсов. Остается выделить наиболее критичные для данной системы бизнес-процессы и сосредоточиться на их тестировании. Руками или автоматизированными тестами - это другой вопрос. Если одни и те же сценарии предполагается выполнять десятки раз и сам интерфейс достаточно стабилен, то можно попробовать и автоматизировать, если есть соответствующие инструменты и специалисты. Чем дольше длится проект и чем больше циклов тестирования будет в нем, тем большей будет отдача от автоматизации тестирования. Только сразу настройтесь на то, что нормальный автоматизированный тест это намного больше, чем record & replay. Насколько трудоемко будет разрабатывать такие тесты и потом поддерживать их - решать вам совместно со специалистам, которые будут этим заниматься. Сложность разработки автоматизированных тестов будет пропорциональна сложности выполнения тех же самых бизнес-процессов вручную.В общем, если количество тестовых ситуаций для расчета индексации было не очень большим, то можно было бы реализовать поочередно каждый сценарий и только потом проверить индексацию. Но это слишком долго, а вариатов индексирования/неиндексирования очень много :( Это только лишь индексация, а бизнеспроцессов в реализуемом проекте просто куча. Как их тестировать..??? Руками? Долго и н очень эффективно. Писать автоматические тесты? Как их псать и не будет ли сложность тестов превышать сложность релизуемых алгоритмов? Посоветуйте что-нибудь, может у кого-нибудь есть опыт в решении подобных проблем...
#3
Отправлено 22 июля 2004 - 14:47
Автоматизировать или нет - это отдельный вопрос. Это зависит от того сколько ваш продукт будет проходить итераций перед релизом без значительных изменений в графическом интерфейсе. Это определяющий фактор.
Конечно, можно и в тесты запихнуть сложную логику, но тогда понадобится и их тестировать. Замкнутый круг.
Что еще? Если у вас нет хорошего спеца по автоматизации то настройтесь на то, что в ближайшие полгода-год отдачи от нее вы не увидите.
#4
Отправлено 23 июля 2004 - 06:10
1. Визначити найважливіші (з точки зору замовника) віріанти індксації/неіндексації і найтиповіші вхідні дані.
2. Постаратись згрупувати варіанти (вхідні дані > індексація > результат) по групах схожих (з точки зору тестування, це будуть тест кейси) і заскріптувати їх. На мою думку це дає значний виграш (при умові що таких груп багато і в них входить багато тест кейсів) оскільки 1 раз написавши автоматизований скріпт для однієї групи і врахувавши незначні відхилення (від стандарту групи) можна заскріптувати значну кількість тест кейсів.
Якщо ж кожен тест кейс унікальний (свої вхідні дані, свій тип індексації) то прийдеться тестувати все в ручну. :(
#5
Отправлено 23 июля 2004 - 07:23
Самая главная беда, что есть тенденция к изменению описания самого бизнес-процесса. Изменился бизнес процесс - изменился результат теста - беда :( Изменяются даже те бизнес-процессы, которые считаются реализованными, поэтому если один бизнес-процесс опирается на результаты другого, то изменение первого - это смерть тестовых данных, уже загнанных в систему :( Видимо, в этом и есть самая главная проблема.
Можно, конечно, динамическ формировать тестовые данные в ходе выполнения автоматического теста, но в таком случае автоматический тест должен будет реализовать несколько бизнес-процессо только для того, чтобы подготовить тестовые данные для теста :unsure:
Что-то я разошлась :D
#6
Отправлено 23 июля 2004 - 07:46
#7
Отправлено 23 июля 2004 - 07:46
Была ещё идея сделать автоматические тесты на прикладой api. Т.е. тестировать методы относительно общие, используемые при реализации многих бизнес-процессов. А логику бизнес-процессов проверять вручную, полагаясь на то, что какая-то базовая часть уже протестирована автоматическими тестами. Но , опять -таки, к сожалению, прикладной api не совсем состоялся, т.к. методы довольно уникальные и могут быть использованы при реализации одного бизнес-процесса. Но даже это если бы это было не так, то все равно остается вопрос, если автоматические тесты проходят, то с какой долей уверенности можо утверждать, что работает алгоритм бизнес-процесса? И как распределить время на создание автоматических тестов и тестирование вручную, если его постоянно не хватает? :(
#8
Отправлено 23 июля 2004 - 10:58
С какой вероятностью ты можешь утверждать об этом после "ручных" тестов? С той же самой.если автоматические тесты проходят, то с какой долей уверенности можо утверждать, что работает алгоритм бизнес-процесса?
А на самом деле, вамавтоматизацией все-таки лучше бцдет заняться на факультативном уровне. То есть, есть время - попробуйте что-нибудь написать, нет - тестируйте как тестировали.
#9
Отправлено 23 июля 2004 - 16:48
При таком раскладе я бы не стал заниматься автоматизацией тестирования. Эффективность будет очень низкая, потому что придется постоянно заниматься доработкой тестов из-за изменения логики работы вашей системы.Самая главная беда, что есть тенденция к изменению описания самого бизнес-процесса. Изменился бизнес процесс - изменился результат теста - беда :( Изменяются даже те бизнес-процессы, которые считаются реализованными, поэтому если один бизнес-процесс опирается на результаты другого, то изменение первого - это смерть тестовых данных, уже загнанных в систему :( Видимо, в этом и есть самая главная проблема.
Количество пользователей, читающих эту тему: 2
0 пользователей, 2 гостей, 0 анонимных