Чтоб оценить, насколько яростно у нас все происходит — из последнего:
Выставили на всех серверах непрерывной интеграции в /etc/postgresql/9.1/main/postgresql.conf параметр
fsync=off
Слово Канеру
Автоматизируйте тесты используя программные интерфейсы.
В настоящее время многие продукты имеют программные интерфейсы (публичное API), которое может быть использовано для тестирования. Другие продукты, могут иметь скрытые API, которые могут быть открыты, если вы попросите. Просите.
Открытый API документируется как часть продукта. Они сильно не меняются и эта стабильность делает их привлекательными для автоматизации тестирования. Закрытый API может быть очень полезен, но необходимо выяснить, насколько он подвержен изменениям.
Не зная о подобных альтернативах, многие автоматизаторы фокусируются на видимой части ПО — на GUI. С сожалению, часто это самый сложный интерфейс для автоматизации. Практически любой программный интерфейс проще, надежней и стабильней. В предыдущих лекциях мы обсуждали некоторые проблемы, связанные с автоматизацией через GUI и предлагали стратегии борьбы с ними. Но лучший выход — избежать их вообще. Программные интерфейсы, как правило, обеспечивают стабильность. Также они способствуют обнаружению и изоляции дефектов.
Когда мы смотрим на усилия тестировщиков во многих программных продуктах, мы наблюдаем корреляцию между наличием программного интерфейса и сложностью тестовых наборов. Программные интерфейсы включают API, интерфейс командной строки, COM интерфейс, HTTP и другие. Вам нужно знать жаргон и технологии. Не ожидайте, что ваши программисты предоставят вам учебник. Чем дольше вы ждете, тем меньше времени. Если вы всерьез занимаетесь автоматизацией, вы изучите это сами или найдете кого-нибудь, кто сможет помочь.
Часто автоматизаторы GUI тестирования считают, что должны изучить в деталях технологии GUI. С технической точки зрения GUI сложнее других интерфейсов. Так или иначе, вам придется изучить технологии GUI по мере использования тестов. Это ваш выбор, а мы считаем, что GUI должен быть последним в списке.
Вот небольшой пример. Многие люди просят у нас совета по автоматизации инсталлятора с использованием инструмента графического тестирования. Лучший подход, как правило, выбросить инструмент. Большинство инсталляторов имеют скриптовый интерфейс, обеспечивающий лучший доступ. InstallShield, например, популярная система установки, используемая в инсталляторах многих продуктов. Многие тестировщики не знают, что они могут работать с InstallShield с возможностью записи выбранных опций установки. Они сохраняются в файл. В дальнейшем возможна автоматическая установка с помощью этого файла указывающая все настройки. Это просто, это дешево, этот файл легко читать и редактировать. Это экономически эффективный способ автоматизации установки (см. «Создание скрытой инсталляции» http://support.installshield.com/kb/display.asp?documents_id=101901).
Но вы не тестируете GUI! Сфокусируйте свое внимание на том, где автоматизация может помочь в большей степени. Иногда можно эффективно автоматизировать тестирование GUI, иногда нет. Не допускайте предвзятого мнения о том, что автоматизация выглядит как ограничивающая вас.
Опыт Douglas Hoffman'а похож на наш. «Наиболее драматичный успех я имел, когда работал с исвестным пакетом настольных издательских систем. Его движок был скрыт и продукт воспринимался с точки зрения WYSIWYG GUI. Поскольку планировалась полная переработка пользовательского интерфейса, мы избежали автоматизации тестирования GUI. Вместо этого мы использовали public API для функционального тестирования и вручную тестировали GUI. Мы зарепортили много дефектов (в основном обнаруженных при автоматизации тестов) и смогли гораздо легче отделять проблемы с GUI от проблем с функциональностью»
Paul Szymkowiak не согласен. «Мой опыт отличается. Я обнаружил, что многие GUI более стабильны, чем программные интерфейсы, в контексте елей автоматизации тестирования. Это происходит потому, что GUI виден клиентам, использующим напечатанные учебные материалы и руководства. Таким образом, существуют расходы, связанные с изменениями GUI. Я работал с рядом руководителей проектов, которые просили «заморозить» пользовательский интерфейс задолго до заморозки программного интерфейса. Многие программные интерфейсы плохо документированы. Я также нашел много багов в программных интерфейсах с более низким порогом юзабилити, чем это обычно ожидается от пользовательского интерфейса».
Комментариев нет:
Отправить комментарий