суббота, 12 мая 2012 г.

Lesson 115

Внезапно. В екб есть работа для тех, кто владеет автокадом, 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.

9 комментариев:

  1. Блин, всю жизнь мечтала найти работу в айти, связанную с автокадом - не пропадать же навыкам ((

    А что такое соответствующий уровень абстракции?

    ОтветитьУдалить
  2. Работа не в it.
    Стройконтора небольшая.

    У нас 4 уровня абстракции.

    4. Объекты.
    3. Методы мзменения состояний/моделей объектов.
    2. Работа с интерфейсом.
    1. Взаимодействие с webDriver.

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

    ОтветитьУдалить
  3. А, понятно, большое спасибо. Я к автоматизации только мелкими шажочками подкрадываюсь :)

    ОтветитьУдалить
  4. принципы, кстати, общие для всех: модель отдельно от представления. что в тестировании, что в программировании.
    а мы вот на днях, кстати, тоже себе взяли дополнительного работника, и тоже со знанием автокада. сезонный спрос на автокад :)

    ОтветитьУдалить
  5. Принципы общие, но есть проблема - программисты редко идут в тестировщики.

    И помогают им редко. В результате автоматизацией тестирования - созданием достаточно сложной программы - занимаются люди, имеющие весьма отдаленное от реальности представление о программировании.

    В том числе поэтому автоматизация часто очень дорога и плохо работает.

    Впрочем это не главная проблема, сейчас и ручным тестированием часто занимаются люди далекие от разработки.

    ОтветитьУдалить
  6. Ты так говоришь, как будто нужен специалист по синхрофазотронам.

    ОтветитьУдалить
  7. у нас тестированием занимаются сами разработчики, в основном: потому что проще самому протестировать, чем объяснить другим, чего от них требуется :) ну и частично по составленному разработчиками плану его выполняет сборочный цех и сервисный центр.
    но, конечно, самое реальное и жосское тестирование - это запуск у заказчика :)

    ОтветитьУдалить
  8. А что такое 20-25к? Это зарплата? Если да, то в рублях или долларах? В год или в месяц?

    ОтветитьУдалить
  9. Зарплата, в рублях- екатеринбург же, в месяц - россия же.

    ОтветитьУдалить