Lesson 115

May 12, 2012 16:13

Внезапно. В екб есть работа для тех, кто владеет автокадом, 20-25к. Обращайтесь.

Стартанули тесты на разных базах. Сперва приложение опало аки озимые на всех конфигурациях. После того как суровый челябинский программист(тм) объяснил системе, что сие моветон - проверили еще разок.
Неожиданно порадовал mssql, прошедший почти все испытания.
И огорчил oracle, с его нетипичным ограничением в 30 символов(ORA-00972), о котором забывают.

Пыщ-пыщ, тестируем дальше.

Слово Канеру:

Пользовательский интерфейс меняется.

Идите в ногу с изменениями пользовательского интерфейса, они являются основной проблемой автоматизации тестирования через интерфейс.

Просьба обращенная к программистам о том, что они они должны заморозить пользовательский интерфейс не сработает. Ранние версии интерфейса часто нуждаются в пересмотре. Не ставьте себя в положение «рекомендующего улучшение». Пользовательский интерфейс будет меняться постоянно.

Абстрагируйтесь от интерфейса в архитектуре тестов. Когда интерфейс изменится, вы обновите соответствующий уровень абстракции, работающий с изменившимся интерфейсом.

Вот несколько техник для обеспечения абстрагирования от GUI:

Window map Инструменты тестирования GUI поддерживают различные техники идентификации окон и управляющих элементов, такие как: внутренние имена, различные свойства, метки, порядковые номера. Вместо того, чтоб внедрять новую методику идентификации с каждым новым окном, используйте window map, чтоб связать название с идентификатором управляющего элемента или окна. Если пользовательский интерфейс заставит вас изменить технику идентификации, вам нужно будет обновить только window map. Некоторые инструменты тестирования включают в себя поддержку создания и использования window map, которые также называются GUI maps или window declarations. Если ваш инструмент не имеет встроенной поддержки подобных вещей, то ее, как правило, можно добавить без особых проблем. Window map поддерживают изменение незначительных изменений GUI, таких как переименование заголовков или перемещение управляющих элементов. Также они могут быть полезны для переиспользования тестов на пользовательский интерфейс, написанных на других языках.

Автоматизация, основанная на данных (Lesson 127: Автоматизация основанная на данных позволяет легко запускать множество вариантов теста). Эта техника обеспечивает абстракцию в том, что вы должны быть в состоянии изменить процедуру тестирования и по прежнему использовать созданные для нее данные.

Библиотеки задач (Lesson 126: Не создавайте библиотеки тестов просто для того, чтоб избежать повторения кода). Анализируйте кейсы на предмет подзадач. Все подзадачи должны быть принципиально разными. Обратите особое внимание на начальное и конечное состояние подзадачи. Создайте функцию для ее выполнения и используйте ее в кейсах. Если изменится пользовательский интерфейс, вы должны будете изменить только эту функцию, а не использующие ее тесты. Это позволит достичь высокой степени абстракции, но может увеличить объем работ на разработку и проектирование тестов.

Keyword-driven автоматизация (Lesson 128: Keyword-driven автоматизация позволяет непрограммистам легко создавать тесты).

Автоматизация основанная на API (Lesson 132: автоматизируйте тесты, используя программный интерфейс). В целом, избегайте GUI.

программисты, lessons learned in software testing, james bach, тестировщик, chapter 5, лекции, bret pettichord, офис, cem kaner

Previous post Next post
Up