Винниченко И.В. Автоматизация процессов тестирования

Подождите немного. Документ загружается.

1 о Содержание

SilkTest ИЗ

Rational Robot 114

Функции работы с системой 117

WinRunner 117

SilkTest 118

Rational Robot 119

Функции оповещения о результатах 120

WinRunner 120

SilkTest 121

Rational Robot 121

Функции синхронизации 122

WinRunner 123

SilkTest 123

Rational Robot 124

Функции проверки существования объекта 124

WinRunner 124

SilkTest 125

Rational Robot 125

Функции работы с файлами 126

WinRunner 126

SilkTest 127

Rational Robot 129

Практический пример 1 130

WinRunner 131

SilkTest 131

Rational Robot 132

Глава 6. Функции работы

базами данных

.... 133

WinRunner .134

SilkTest 136

Rational Robot 138

Практический пример 2 140

WinRunner 141

SilkTest 141

Rational Robot 142

Содержание 11

Глава 7. Обработка ошибок 143

WinRunner 144

SilkTest. 144

Rational Robot 146

Глава 8. Функции пользователя 148

WinRunner 149

SilkTest 150

Rational Robot 151

Практический пример 3 152

WinRunner 153

SilkTest 154

Rational Robot 156

Глава

9. Управление процессом исполнения ... 159

Вызов тест-скриптов из мастер-скрипта 160

WinRunner 160

SilkTest 160

Rational Robot 161

Загрузка/выгрузка библиотеки функций 161

WinRunner .... 161

SilkTest 162

Rational Robot 162

Загрузка/выгрузка библиотеки объектов 162

WinRunner 162

SilkTest 163

Rational Robot 163

Приложение A. Работа с нестандартными

объектами в SilkTest 164

Набор графических объектов распознается как один объект... 164

Объект не распознается вообще и требует написания методов

работы с ним с нуля 165

Объект распознается как нестандартный класс, но может быть

передекларирован как стандартный 166

12 Содержание

Приложение Б. Работа с нестандартными

объектами в WinRunner 167

Объект

не

распознается

требует написания методов работы

с ним

нуля

167

Объект имеет текстовый определитель, который

незначительно изменяется

каждым вызовом

программы тестирования

168

Объект распознается

как

нестандартный класс,

но может быть передекларирован

как

стандартный

168

Приложение В. Автоматизация приложения

Pizza Order средствами Silkiest

и WinRunner 169

Бизнес-спецификация

169

Функциональная спецификация

169

Техническая спецификация

170

Тестовая документация

178

Структура автоматизации

180

WinRunner

180

SilkTest

192

Алфавитный указатель 200

Предисловие

Идея создания этой книги появилась у меня довольно давно. На про-

тяжении длительного времени меня очень расстраивал тот факт, что

такая обшир1{ая тема компьютерных наук, как автоматизация про-

цессов тестирования, остается не охваченной печатным словом. Это

верно как для безбрежхюго моря англоязычных публикащп! на компью-

терные темы, так и для российского книжного рынка. И хотя вышло

несколько публикаций по теории автоматизации, нет ни одной книги,

которая бы взяла «читателя за руку» и показала, как начать и с чего

начать. Книги, которая на примерах реально суш;ествующих программ

показала бы, что же все-таки кроется за этим труднопроизносимым

термином

—

программные средства автоматизации процессов тести-

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

премудрости этого ремесла в оптоволоконных дебрях Силиконовой

Долины.

Окончательно в необходимости создания такой книги и в том, что

она может быть востребована в России, я убедился, когда, бороздя

просторы Интернета, зашел на российский сайт поиска работы. Вро-

жденная любознательность заставила меня задать поиск по параметру

QA/Tester. Сказать честно, я был очень удивлен количеством пред-

лагаемых вакансий. Я что называется «вживую» увидел, что процесс

глобализации пустил в России корни и такая вещь, как Software

Development Outsourcing все больше и больше входит в экономиче-

скую жизнь страны. Там же, где разрабатывается программное обес-

печение, если это, конечно, серьезная разработка приложений мирово-

го уровня, требуется наличие многочисленных и знающих инженеров

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

можность это тестирование автоматизировать. Я думаю, что в совре-

менном мире нет необходимости объяснять важность автоматизации

чего бы то ни было, особенно когда речь идет о таком мощном сред-

стве улучшения качества и уменьшения затрат разработки про-

граммного обеспечения, как автоматизация процессов тестирования.

14 Предисловие

Поэтому очень надеюсь, что эта книга окажется полезной людям, за-

нимающимся проверкой качества выпускаемого ПО.

Эта книга создавалась как практический справочник, одинаково год-

ный как для освоения материала, так и для быстрого восстановле-

ния в памяти необходимой информации. В ней затронуты такие темы,

как Record/Playback, основные элементы графического интерфейса

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

ных и инструменты обработки ошибок. Эти темы являются актуаль-

ными, какое бы средство автоматизации тестирования вы не исполь-

зовали и какое бы программное обеспечение вам не приходилось тес-

тировать. В книге рассматриваются три программных продукта

—

WinRunner, SilkTest, Rational Robot, являющихся лидерами рынка

автоматизации процессов тестирования. И рассматриваются они в

контексте общей концепции автоматизации тестирования. Подобный

подход при всей его привлекательности имеет одно «но»: некоторая

специфическая функциональность программ может оказаться не от-

раженной. Вместе с тем я не пытался объять необъятное и создать

абсолютно полное практическое пособие. Основная моя цель была

помочь оценить важность автоматизации, раскрыть ее возможности,

дать основу знаний в области автоматизации процессов тестргрова-

ния, привести примеры решенР1я возникающих проблем. Надеюсь, что

эта книга окажется для вас полезной и послужит надежным лоцма-

ном в море автоматртзированного тестирования программного обес-

печения.

От издательства

Ваши замечания, предложения и вопросы отправляйте по адресу

электронной почты comp@piter.com (издательство «Питер», компью-

терная редакция).

Все исходные тексты, приведенные в книге, вы можете найти по ад-

ресу: http://www.piter.comdownloacl.

Мы будем рады узнать ваше мнение!

Подробную информацию о наших книгах вы найдете на веб-сайте

издательства: http://www.piter.com.

Глава 1

Основы автоматизации

В этой главе, пожалуй единственной из всех, поговорим о теории,

а не о практике. Профессия тестировщика программного обеспече-

ния, как и ее сестра — профессия инженера по качеству, а также

«выросшая» из них профессия инженера по автоматизации процессов

тестирования, очень молода и зачастую овеяна мифами и подверже-

на влиянию предрассудков. Эта профессия, появившаяся в Соеди-

ненных Штатах Америки больше 15 лет назад, даже там не пользу-

ется большим уважением у программистов

—

«белой кости» 1Т-мира.

Заслуживают ли специалисты в этой области подобного отношения?

Что представляет собой тестировщик, QA (инженер по качеству),

Automation Developer? Что представляет собой автоматизация про-

цессов тестирования? Каковы ее основные принципы? На эти вопро-

сы постараемся ответить в данной главе. Итак, начнем...

Тестировщик: профессионал

или обслуживающий персонал?

Давайте проведем небольшой экскурс в прошлое

—

зададим простой

вопрос: «Когда это все началось?» Думаю, мало кто в мире высоких

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

массовый феномен появился благодаря Биллу Гейтсу. Да, до него бы-

ли Sun Microsystems, IBM и Unix. Да, до него суш[ествовали вычис-

лительные лаборатории в СССР, США и Японии. Да, до него писа-

лись (и тестировались) программы. Но давайте посмотрим правде в

глаза: именно Windows при всех своих неисчислимых дефектах по-

служила тем камнем, который породил лавину компьютеризации на

нашей планете в той ее форме (компьютер в каждом доме и офисе),

в которой она существует сейчас. И хотя я хорошо понимаю огром-

ное количество людей, сочинявших и продолжающих сочинять бес-

16 Глава 1. Основы автоматизации

численные анекдоты про Билла Гейтса, нельзя не отдать должного

этому человеку. Так вот, и профессия «тестировщик программного

обеспечения» родилась в недрах именно Microsoft. Когда товарищ

Гейтс решил потеснить махину Sun Microsystems и весь лагерь Unix

как таковой на рынке операционных систем для серверов, создав Win-

dows NT, он пришел к здравому заключению. Бороться с ОС, кото-

рую писали и отлаживали десятки тысяч человек, можно лишь про-

тивопоставив им свою армию спецов. Но программисты, особенно

когда их много и они работают над гигантским проектом, не способ-

ны следить за качеством выпускаемой продукции. И вот именно для

создания конкурентоспособной ОС и была «создана» группа людей,

ответственных за тестирование и качество конечного продукта.

Вот мы и подошли к вопросу о том, кто же такой тестировщик, чем

он занимается и чем он отличается от инженера по качеству. Итак,

тестировщик — это

человеку

оценивающий программный продукт с

точки зрения пользователя. Собственно, его задача заключается в

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

щий программу, будет в состоянии полностью использовать ее

функциональность, не испытывая при этом неудобства от «зависа-

ния» системы, появления сообщений об ошибках, ни с того ни с сего

закрывающихся окон и прочих «прелестей», которыми изобилуют

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

проверка того, что программный продукт делает именно то, что он

должен, и так, как он это должен делать. Ситуация, когда пользо-

ватель щелкает на кнопке Печать, а вместо отправки документа на

принтер он просто сохраняется, является неприемлемой для хорошо

протестированного продукта. Инженер по качеству — это тот же

тестировщик,

только

ответственный

за

качество

продукта в тече-

ние

всего цикла

разработки.

Давайте взглянем на типичную схему та-

кого цикла.

Как видно из этой схемы, отдел разработки бизнес-требований

(ОРБТ) (Product Specialists) предоставляет группе тестирования (QA)

и группе программистов (Development) два документа: BRD (Bu-

siness Requirement Document), описывающий бизнес-логику выпус-

каемого продукта, и FDD (Functional Design Document), описываю-

щий функциональные требования к выпускаемому продукту. После

того как программисты рассмотрят эту документацию, они создадут

еще один документ

—

TDD (Technical Design Document), который

затем будет отправлен на рассмотрение в отдел разработки бизнес-

требований и группе тестирования. После его рассмотрения и утвер-

Тестировщик: профессионал или обслуживающий персонал?

ждения отделом разработки бизнес-требований группа тестирования

приступает к написанию тест-плана, тест-сценариев и тест-кейсов,

которые послужат основой для дальнейшего тестирования продукта.

Тем временем программисты пишут код. Когда код становится отно-

сительно стабильным, его начинает тестировать группа тестирования.

В ходе тестов обнаруживаются дефекты, программисты их исправ-

ляют, и так продолжается до тех пор, пока продукт не приобретает

должную стабильность или не начинают поджимать сроки. Вот, соб-

ственно, и весь цикл разработки «в разрезе».

Зона ответственности инженера по качеству начинается во время чте-

ния BRD и FDD. В его обязанности входит не только и не столько

тестирование непосредственно кода, сколько проверка того, что ка-

чество всех компонентов (а в особенности документации) программ-

ного продукта находится на высоте. То есть если ОРЕТ пишет что-

то заведомо неосуществимое или не дружественное пользователю,

инженер по качеству должен забить тревогу. В его обязанности вхо-

дит и рассмотрение TDD

—

если он знает, что пользователю необхо-

димо будет иметь открытыми несколько окон, каждое из которых

должно регулярно производить чтение/запись базы данных, то его

долг Цастоятельно рекомендовать не использовать такие громозд-

кие по времени исполнения вещи, как JavaApplets и JDBC «в одном

флаконе». Если инженер по качеству знает, что строчная длина ка-

1 8 Глава 1. Основы автоматизации

кого-то поля должна превышать длину, описанную в TDD (напри-

мер,

в поле «Город» значение «Комсомольск-на-Амуре» должно быть

видно целиком), то он обязан об этом сообщить до начала кодиро-

вания. Даже такие элементы программы, как цветовая гамма и ис-

пользуемые шрифты, входят в зону ответственности инженера по

качеству. Никто не требует от него быть специалистом в графиче-

ском дизайне или гуру в программировании на C++, но все, что ка-

сается удобства использования в будущем и качества программного

продукта, должно сразу бросаться ему в глаза.

Как уже, надеюсь, ясно, профессии тестировщика и инженера по ка-

честву (в дальнейшем QA) являются очень важными и нужными в

современном 1Т-мире. Профессионалам в этой области следует быть

не только компьютерно грамотными (в том числе знать языки про-

граммирования

—

но об этом позже), но и уметь «увидеть» продукт

глазами пользователя, а также быть очень внимательными к дета-

лям. Нельзя забывать и о том, что хороший инженер по качеству

—

это хороший дипломат. Ведь если смотреть правде в глаза, далеко не

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

ошибку, которую вы потом обнаружили. Верно?

Черный ящик, белый ящик

в классической, если ее можно так назвать, интерпретации сущест-

вуют два основных метода тестирования: с открытым (whitebox tes-

ting) и с закрытым (ЫаскЬох testing) кодом. Некоторые переводчики

буквально переводят эти термины как «тестирование черного ящи-

ка» и «тестирование белого ящика». Не будем дискутировать на эту

тему, а просто для данной главы примем мой перевод этих терми-

нов.

Итак, как и следует из названия, тестирование с открытым кодом про-

исходит тогда, когда QA непосредственно «видит» код программно-

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

программистом, и вносит свои поправки (например, «Если значе-

ние этой переменной выйдет за рамки, поставленные руководством

пользователя, этот цикл станет бесконечным» или «При подключе-

нии к базе данных из этого метода по его завершении это подключе-

ние не освобождается, что приведет к тому, что после N-ro вызова

метода подключение к базе данных станет невозможным»). Как легко

догадаться, человек, способный проводить анализ подобного рода,

должен являться как специалистом в области тестирования (он дол-

Что такое автоматизация и с чем ее едят? 1 9

жен уметь «увидеть», что может «отчебучить» пользователь), так и

высококлассным программистом. Зачастую к обязанностям whitebox

QA относят и написание так называемых модульных тестов (unit

tests).

Но это отдельная тема, которой в данной книге касаться не

будем.

Тестирование с закрытым кодом является наиболее распространен-

ным и, как опять-таки следует из названия, не предполагает возмож-

ность доступа QA к исходному коду программного продукта. В пол-

ном объеме такое тестирование описано в разделе «Тестировщик:

профессионал или обслуживающий персонал?».

К счастью Р1ЛИ к сожалению, ничто в этом мире не является абсо-

лютно белым или же абсолютно черным. Так и в области тестирова-

ния существует понятие тестирования с полуоткрытым кодом

(graybox testing). Сюда как раз и попадает автоматизация процессов

тестирования. Полуоткрытый код подразумевает, что тестировщик

знаком с архитектурой (например, со стандартной схемой индустри-

альных (enterprise level software) приложений: Oracle

—

WebLogic

—

JavaApplet) программного продукта; что он может зайти на сервер и

посмотреть журнал исполнения; что он знает структуру модели дан-

ных этого представляемого программного продукта и в случае чего

—

сможет написать SQL-запрос для подтверждения результатов, выдан-

ных программным продуктом (ПП). То есть он как бы и не специа-

лист в программировании (как whitebox QA), но уже и не просто

тестировщик. На самом деле, все три направления тестирования

должны курировать специалисты именно этого направления.

Что такое автоматизация

и с чем ее едят?

Автоматизация в теории представляет собой мечту Сыроежкина из

книги «Приключения Электроника»: «Вкалывают роботы, а не чело-

век».

Зачастую работа тестировщика превращается в одну большую,

длинную лямку. Это происходит на стадии перепроверочного тести-

рования (regression testing). Так называется тестирование того, чтобы

все,

что работало нормально, так и продолжало работать нормально

даже после того, как программисты что-то исправили в коде. Нужно

провести сотни тест-кейсов, которые перепроверяются каждые N не-

дель или даже дней. После того как ты 5 раз ввел название «Алек-

сандровск-Сахалинский» в поле «Города», очень скоро захочется