http://autotestgroup.com/ru/blog/ Tue, 28 Oct 2008 17:49:31 +0200 http://autotestgroup.com/ru/blog/59.html <p>Часто при работе автотестов возникают ситуации, когда приложение может вести себя по-разному и в зависимости от полученной реакции приложения нужно выполнить определенные действия. Наиболее четко это выражено в тестировании GUI, когда после выполнения некоторых операций мы ожидаем один из возможных вариантов реакции системы. Самый простой пример: у нас есть окно Notepad и нам надо реализовать функционал по его закрытию. То есть, нужно нажать на крестик в правом верхнем углу. Но если уже был введен некоторый текст, то вначале появится сообщение о подтверждении сохранения изменений. В этом случае нам дополнительно надо еще обработать диалог закрытия окна. Если подобную задачу реализовывать в виде некоторой вспомогательной функции, то обе ситуации надо обрабатывать. post59 http://autotestgroup.com/ru/blog/58.html <div align="right"><small>Quis custodiet ipsos custodes?<br /> Кто будет сторожить сторожей?</small><br /> <br /> <strong>Ювенал, &quot;Сатиры&quot;</strong></div> <p><br /> Автоматизированное тестирование програмного обеспечения может выражаться в разных формах с точки зрения целей, подходов и реализации. Но суть одна: автотесты - это програмные модули, позволяющие проверить поведение тестируемого приложения на соответствие требованиям или предоставляющие достаточно информации, чтобы осуществить подобную проверку (те же тесты на производительность вполне могут ограничиться выдачей статистики, которую потом анализирует человек ). Ключевым моментов является то, что автотесты - это такое же по сути програмное обеспечение, что и непосредственно тестируемое приложение, из чего следует, что автотесты точно так же могут содержать в себе ошибки реализации. То есть, их тоже не мешало бы периодически проверять на работоспособность или хотя бы установить какие-то средства контроля, поскольку тесты не менее чувствительны к изменениям тестируемого приложения, чем другие программные модули, затронутые в ходе изменений.<br /> post58 http://autotestgroup.com/ru/blog/56.html <p>Веб-сервисы - достаточно распространенный вид компонент распределенных систем. Фактически это один из интерфейсов удаленного вызова процедур. То есть, из некоторой программы мы можем отправить запрос на выполнение некоторой операции на стороне сервера и получить результат выполнения операции, при этом графический интерфейс не задействован. Подобные компоненты позволяют реализовать интеграцию между различными системами, которые изначально между собой не связаны. Отчасти это делает веб-сервисы достаточно популярными, как результат - они используются в достаточно большом количестве приложений, а это в свою очередь влечет необходимость их тестировать, в том числе и автоматически. Для этой задачи есть и специальные средства, наподобие soapUI, но помимо этого возможность тестирования веб-сервисов имеется и в более полновесных средствах, в т.ч. и в TestComplete. В TestComplete, начиная с 6-й версии как раз была добавлена возможность тестирования веб-сервисов. Рассмотрим, как это реализуется и каким образом можно проверить веб-сервисы.<br /> post56 http://autotestgroup.com/ru/blog/55.html <p>Автоматизированное тестирование на уровне GUI содержит в себе много сюрпризов, связанных с работой с оконными объектами. Причем сюрприз заключается в том, что наиболее изящное решение проблемы с поддержкой описаний оконных объектов в актуальном состоянии для каждого отдельно взятого средства может быть свое. Но это наиболее удачное решение. Тем не менее, есть ряд механизмов, имеющих аналоги в различных средствах. Одним из примеров является Mapping оконных деклараций, позволяющий некоторым оконным объектам ставить в соответствие некоторый псевдоним. Подобное решение в TestComplete обладает одним ключевым недостатком: при изменении иерархии оконного объекта приходится переделывать маппинг всех дочерних объектов. Альтернативой этому стало введение с 6-й версии TestComplete такой функциональности как Alias, которая позволяла регулировать иерархию псевдонимов. Но у такого решения есть другой недостаток: низкая скорость. Соответственно, нужны механизмы, позволяющие оперативно реагировать на изменение GUI, при этом корректировки желательно минимизировать. Давайте рассмотрим конкретный пример. post55 http://autotestgroup.com/ru/blog/51.html <p>Одной из наиболее серьезных проблем при автоматизации функционального тестирования на уровне GUI является высокая чувствительность тестов к изменениям GUI. По-хорошему, подобная ситуация не должна возникать, так как автоматизация подобного рода ставится тогда, когда пользовательский интерфейс более-менее стабилен. Но это идеальная ситуация. В реальности, продукт меняется по всем направлениям и в том числе это касается пользовательского интерфейса. Так или иначе какие-то мелкие изменения имеют место (поле переименовали, переместили, поменяли некоторые идентификаторы) и это уже влияет на работоспособность тестов. post51 http://autotestgroup.com/ru/blog/48.html <p>Одной из наиболее серьезных проблем при разработке автотестов ( особенно функциональных на уровне GUI ) является синхронизация выполнения тестов с работой тестируемого приложения. Иными словами, действия, которые выполняются в автоматическом тесте, должны осуществляться именно в тот момент, когда приложение находится в требуемом для данного действия состоянии. В противном случае мы можем получить картину, когда тест пытается делать клики, вводить текст, в то время как форма, над которой осуществляются данные действия, отсутствует. В результате, наш тест идет проторенными методами, но совсем непонятными путями. Если при этом нет никаких механизмов выравнивания состояния, то подобное может серьезно подкосить выполнение пакета тестов в целом.<br /> post48 http://autotestgroup.com/ru/blog/41.html <p>Очень часто при автоматизации тестовых сценариев можно натолкнуться на шаги вида: &quot;повторите шаги 1-12&quot; или еще интересней, &quot;повторите все шаги&quot; + некоторые поправки. То есть в конечном итоге при реализации нам надо будет полностью продублировать код определенных шагов. А излишнее дублирование может вызвать ряд трудностей при модификациях тестов, при поддержке тестов. Любые изменения надо вносить во все вхождения повторяющегося кода. А это дополнительная потеря времени. Как этого избежать:<br /> post41 http://autotestgroup.com/ru/blog/40.html <p>В&nbsp;очередной раз, наталкиваясь на различные публикации по автоматизированному тестированию,&nbsp;наталкиваюсь на мнение людей, что как только упоминается какое-нибудь heavy-weight big vendor средство автотестирования (кстати как правило стараются не называть&nbsp;конкретное&nbsp;средство ), то к нему сразу же привязывается &quot;диагноз&quot; что ли - unmaintainable scripts. Но если упоминается что-нибудь писанное на коленке или представляющее собой некоторую библиотеку, то такой проблемы изначально якобы нет. Я, конечно, склоняюсь к идее, что лучше взять что-то мелкое, но оно будет успешно выполнять поставленные задачи, чем взять что-то здоровое и громоздкое, а потом думать, куда бы его прикрутить.<br /> <a name="cutid1"></a><br /> Тем не менее, подобное сопоставление возможности поддержки тестов и используемого средства мягко говоря некорректно. Кривые руки даже под линейку чертят криво. Соответственно, чтобы сделать тесты поддерживаемыми (а для автоматического тестирования это очень критично), нужно следовать одному основному принципу: одно изменение на один функционал. То есть, если у нас в тестируемом приложении поменялась одна функция (в любом проявлении, как на уровне реализации кода, так и на уровне интерфейса), то тесты обновляются путем внесения изменений в одном месте, именно там, где этот измененный функционал оказывает влияние. Опять же, модель идеальная, но есть вполне конкретные подходы, с помощью которых можно стремиться к этому.<br /> post40 http://autotestgroup.com/ru/blog/39.html <p>При написании автоматических тестов, как и любых других видов програмных компонент, мы должны добиться целого ряда показателей:</p> <ul><br /> <li>Читаемость</li> <li>Расширяемость</li> <li>Переносимость</li> <li>Оптимальность</li> <li>Соответствие требованиям</li> <li>Удобство модификации</li> <li>Прочее (добавить по вкусу)</li> </ul> <p><br /> post39 http://autotestgroup.com/ru/blog/38.html <p>Успех автоматизации тестирования во многом зависит от того, как тесты будут разработаны. Это напрямую влияет на то, насколько быстро тесты будут разрабатываться, насколько легко в них можно будет сориентироваться, насколько хорошо они смогут локализовать проблему, насколько хорошо они смогут выявлять проблему вообще. На эти и многие другие параметры влияет то, как будут структурированы тесты. То есть немаловажную роль в этом играет тест-дизайн. Ведь именно тестовый сценарий или тестовое предписание служит основой для реализации автоматического теста. Поэтому, если повлиять на процесс на стадии тест-дизайна, то можно заметно улучшить процесс автоматизации тестирования. Итак, что нужно тестам, чтобы их потом легче было легче автоматизировать: post38