Сообщений в теме: 8

[Настя]

Прошу поделиться соображениями и опытом...
При реализации прикладного проекта на основе готового продукта (скажем так, что готовый продукт - это достаточно универсальная среда разработки и проектирования бизнес-процессов) возникает необходимость тестирования реализованных прикладных алгоритмов, которые выполняют прикладные специфические для данного проекта действия. Понимаю, что это достаточно расплывчато... :unsure:
Более подробно - среда разработки позволяет без программирования сделать визуальную настройку системы, динамически формировать формы, отображать списки, сделать настройку рабочего пространства, возможность использования атрибутов различных типов (дата, текст и т.д...), выполнить настройку модели данных без программирования и "ковыряния" в БД, т.е. настроить связи между прикладными сущностями, их множественость и т.д.. Тем не менее, для реализации прикладного проекта этого не достаточно :( Необходимо написать ещё кучу всякой всячины, которая присуща только данному проекту, ну, например, специфические расчеты для той отрасли, в которой реализуется проект (расчет потребления электоэнергии потребителем, расчет индексации, регистрация показаний промышленных потребителей и т.д.), надо в соответствии с проектом присвоить наименования сущностям (объекты типа "договор", "потребитель", "прибор учета" и т.д.), настроить специфические связи (например, точка учета электроэнергии связана с прибором учета) и т.д.. То, что касается настроечной части можно подвергнуть очень поверхностному тестированию и в основном проверить на соответствие здравому смыслу. Кроме того, если уж там, что и обнаружится, то это исправляется без перепрограммирования, это не очень трудоемко и несложно. Кроме того, контроль того, что касается настройки выполняет само ядро... :rolleyes:
Совсем по-другому обстоят дела с тем, что пишется программистами именно для этого прикладного проекта :(
Вот тут-то я и прошу совета. Дело в том, что, например, для тестирования расчета индексации необходима просто куча данных, которые можно получить только реализовав какие-то другие сценарии (регистрация договора для того, чтобы в процессе индексации знать признаки, которые влияют на ее расчет; проведение расчетов и выставление по ним платежных докуметов, их оплата и т.д. для того, чтобы иметь предмет индексации). В общем, если количество тестовых ситуаций для расчета индексации было не очень большим, то можно было бы реализовать поочередно каждый сценарий и только потом проверить индексацию. Но это слишком долго, а вариатов индексирования/неиндексирования очень много :( Это только лишь индексация, а бизнес-процессов в реализуемом проекте просто куча. Как их тестировать..??? Руками? Долго и не очень эффективно. Писать автоматические тесты? Как их писать и не будет ли сложность тестов превышать сложность реализуемых алгоритмов? Посоветуйте что-нибудь, может, у кого-нибудь есть опыт в решении подобных проблем...

[Dmitry_NJ]

В общем, если количество тестовых ситуаций для расчета индексации было не очень большим, то можно было бы реализовать поочередно каждый сценарий и только потом проверить индексацию. Но это слишком долго, а вариатов индексирования/неиндексирования очень много :( Это только лишь индексация, а бизнеспроцессов в реализуемом проекте просто куча. Как их тестировать..??? Руками? Долго и н очень эффективно. Писать автоматические тесты? Как их псать и не будет ли сложность тестов превышать сложность релизуемых алгоритмов? Посоветуйте что-нибудь, может у кого-нибудь есть опыт в решении подобных проблем...

Протестировать абсолютно все в такой большой системе не удастся - не хватит ни времени, ни ресурсов. Остается выделить наиболее критичные для данной системы бизнес-процессы и сосредоточиться на их тестировании. Руками или автоматизированными тестами - это другой вопрос. Если одни и те же сценарии предполагается выполнять десятки раз и сам интерфейс достаточно стабилен, то можно попробовать и автоматизировать, если есть соответствующие инструменты и специалисты. Чем дольше длится проект и чем больше циклов тестирования будет в нем, тем большей будет отдача от автоматизации тестирования. Только сразу настройтесь на то, что нормальный автоматизированный тест это намного больше, чем record & replay. Насколько трудоемко будет разрабатывать такие тесты и потом поддерживать их - решать вам совместно со специалистам, которые будут этим заниматься. Сложность разработки автоматизированных тестов будет пропорциональна сложности выполнения тех же самых бизнес-процессов вручную.

[Kaluga]

Ну для начала наверное стоит попробовать свести сложные алгоритмы к простым тестовым сценариям. Их можно делать и руками, и автоматически.

Автоматизировать или нет - это отдельный вопрос. Это зависит от того сколько ваш продукт будет проходить итераций перед релизом без значительных изменений в графическом интерфейсе. Это определяющий фактор.

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

Что еще? Если у вас нет хорошего спеца по автоматизации то настройтесь на то, что в ближайшие полгода-год отдачи от нее вы не увидите.

[romanl]

В такому випадку виграти час за рахунок автоматизованого тестування можна наступним чином:

1. Визначити найважливіші (з точки зору замовника) віріанти індксації/неіндексації і найтиповіші вхідні дані.
2. Постаратись згрупувати варіанти (вхідні дані > індексація > результат) по групах схожих (з точки зору тестування, це будуть тест кейси) і заскріптувати їх. На мою думку це дає значний виграш (при умові що таких груп багато і в них входить багато тест кейсів) оскільки 1 раз написавши автоматизований скріпт для однієї групи і врахувавши незначні відхилення (від стандарту групи) можна заскріптувати значну кількість тест кейсів.


Якщо ж кожен тест кейс унікальний (свої вхідні дані, свій тип індексації) то прийдеться тестувати все в ручну. :(

[Настя]

Разработкой автоматизированных тестов в данном случае буду заниматься я . А проект на самом деле очень большой и длительный. Особенно, если учесть то, что не так уж много народа занимается его реализацией, разработкой , проектированием и внедрением. В общем-то, нам не всегда приходится многократно выполнять одни и те же тесты. Фактически дело обстоит так: тест повторяется только лишь в том случае, когда, скажем, результат расчета индексации был неправильный и программист исправил это. Тест повторяется для того, чтобы убедиться в том, что алгоритм отработал верно. Ну, ещё это касается случаев с рефакторингом - для того, чтобы убедиться, что этот замечательный процесс не привел к полной неработоспособности всей системы :) . Рассматривая все ту же индексацию могу сказать, что тест заключается именно в проведении индексации для договора со специфическими характеристиками. Поэтому фактически надо 1 раз зарегистрировать договор, а индексацию для договора с этими признаками можно производить сколько угодно раз. Но чем больше система, тем сложнее этот процесс. Например, какой-нибудь бизнес-процесс, который базируется на результатах индексации. Ситуация будет повторяться: надо будет зарегистрировать договор, произвести индексацию, а потом многократно выполнять тесты. Использовать 1 договор (или несколько) для всех тестов (для тестов по всем бизнес-процессов) так же не всегда целесообразно, т.к. например в одном бизнес-процессе важны характеристики договора, в другом - характеристики прибора учета, в третьем - наличие и время связи между тем же прибором учета и его показаниями, а ещё может быть схема электроснабжения, дата выставления платежного документа и т.д.. В общем - создать один или несколько универсальных договоров для тестирования всего - лучше застрелиться, чем потом разбираться, откуда взялась цифра в индексации у договора с сотней точек учета и,приборами учета с разными характеристиками и т.д. :) . Но даже такой подход является работоспособным в некоторой мере.
Самая главная беда, что есть тенденция к изменению описания самого бизнес-процесса. Изменился бизнес процесс - изменился результат теста - беда :( Изменяются даже те бизнес-процессы, которые считаются реализованными, поэтому если один бизнес-процесс опирается на результаты другого, то изменение первого - это смерть тестовых данных, уже загнанных в систему :( Видимо, в этом и есть самая главная проблема.
Можно, конечно, динамическ формировать тестовые данные в ходе выполнения автоматического теста, но в таком случае автоматический тест должен будет реализовать несколько бизнес-процессо только для того, чтобы подготовить тестовые данные для теста :unsure:
Что-то я разошлась :D

[romanl]

Ситуація вроді зрозуміла > все тече все змінюється :). В такій ситуації треба обмежити круг тесткейсів (що замовнику найважливіше) і тестувати це ручками. При малій кількості команди розробників (на скільки я зрозумів) і тестерів теж не багато, тому скріптувати не получиться (це дуже трудоємка задача, а якщо врахувати постійні зміни то дуже і дуже трудоємка). :unsure:

[Настя]

Кстати, совсем забыла...
Была ещё идея сделать автоматические тесты на прикладой api. Т.е. тестировать методы относительно общие, используемые при реализации многих бизнес-процессов. А логику бизнес-процессов проверять вручную, полагаясь на то, что какая-то базовая часть уже протестирована автоматическими тестами. Но , опять -таки, к сожалению, прикладной api не совсем состоялся, т.к. методы довольно уникальные и могут быть использованы при реализации одного бизнес-процесса. Но даже это если бы это было не так, то все равно остается вопрос, если автоматические тесты проходят, то с какой долей уверенности можо утверждать, что работает алгоритм бизнес-процесса? И как распределить время на создание автоматических тестов и тестирование вручную, если его постоянно не хватает? :(

[Kaluga]

если автоматические тесты проходят, то с какой долей уверенности можо утверждать, что работает алгоритм бизнес-процесса?

С какой вероятностью ты можешь утверждать об этом после "ручных" тестов? С той же самой.

А на самом деле, вамавтоматизацией все-таки лучше бцдет заняться на факультативном уровне. То есть, есть время - попробуйте что-нибудь написать, нет - тестируйте как тестировали.

[Dmitry_NJ]

Самая главная беда, что есть тенденция к изменению описания самого бизнес-процесса. Изменился бизнес процесс - изменился результат теста - беда :( Изменяются даже те бизнес-процессы, которые считаются реализованными, поэтому если один бизнес-процесс опирается на результаты другого, то изменение первого - это смерть тестовых данных, уже загнанных в систему :( Видимо, в этом и есть самая главная проблема.

При таком раскладе я бы не стал заниматься автоматизацией тестирования. Эффективность будет очень низкая, потому что придется постоянно заниматься доработкой тестов из-за изменения логики работы вашей системы.