Тестирование интерфейса пользователя

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

Во время тестирования интерфейса следует вводить всевозможные значения во все поля ввода, чтобы проверить, отвечает ли их диапазон требованиям, предъявленным к программе. Необходимо вводить и невозможные значе­ния, например, в числовые поля вводить символьные данные, чтобы про­смотреть сообщения системы, сделанные в ответ на ввод неправильных данных.

Тестирование безопасности и прав доступа

Подсистема безопасности требует отдельного тестирования. При этом про­веряются регистрация новых пользователей, локальный и удаленный доступ к системе, разграничение прав доступа к ней. Очень часто система строится так, что одни пользователи могут только просматривать доступную им ин­формацию, другие пользователи могут добавлять, редактировать и удалять ее, а третьи могут менять права пользователей первых двух категорий. Все это обязательно надо протестировать и проверить, правильно ли определя­ются права пользователей на те или иные действия в системе.

Для тестирования безопасности в системе создаются несколько временных пользователей с разными правами доступа. Тесты выполняются несколько раз от имени каждого из них. В наборе тестов следует предусмотреть все действия пользователя, имеющиеся в программе, и посмотреть, какие из них разрешены пользователю, а какие — нет.

Тестирование инсталляции программного продукта

Первая функция программного продукта, с которой сталкивается пользова­тель, — это его установка на компьютер. Если установить продукт не удаст­ся, то потребитель откажется от него. Если при установке возникнут труд­ности, то пользователь потеряет доверие к продукту и к фирме — разработчику этого продукта. Поэтому необходимо тщательно протестиро­вать процесс инсталляции на разном оборудовании, обратив внимание на безошибочное выполнение повторной установки, обновления предыдущей версии, адаптации к разному оборудованию.

Наборы тестов

Набор тестов (test suite) следует подготовить еще до проектирования про­граммного продукта, на этапе определения требований к нему. Именно тре­бования к программе и составляют круг тех задач, которые должны быть выражены в тестовых заданиях. Кроме того, спроектировав систему, уже трудно беспристрастно оценивать ее. Направление мысли разработчика во- лей-неволей будет идти в русле готового проекта, а это помешает всесторон­ней оценке проделанной работы. Поэтому подготовку тестов и последующее тестирование следует поручить не разработчикам проекта, а профессио­нально подготовленной команде специалистов-тестировщиков.

Как составить набор тестов? Это целиком зависит от тестируемой програм­мы и требований к ней. Здесь можно дать только самые общие рекоменда­ции. Во-первых, для каждой из перечисленных выше групп тестов надо составить свой набор тестов. Во-вторых, надо подобрать набор тестов, рабо­тающих с программой как с "черным ящиком", рассмотрев все возможные области значений исходных данных. В-третьих, надо изучить исходный текст программы и подобрать тесты для прохождения всех путей алгоритма, заложенного в программу, и тесты для выполнения каждого оператора про­граммы.

Каждый отдельный тест, называемый специалистами тестовым случаем (test case), состоит из исходных данных, вводимых в тестируемый программный модуль, и предполагаемого результата, который должен получить модуль.

Результатом не обязательно должны быть значения, возвращаемые модулем. Это могут быть обновления базы данных, изменения в конфигурационных файлах, отправка сообщений по сети. Важно, чтобы это были четко отсле­живаемые значения, влияющие на ход выполнения программы.

Процесс тестирования

Не следует думать, что тестирование завершает разработку и тестировать надо уже готовую программу. Напротив, этот процесс надо начинать на са­мых ранних стадиях разработки. Тестирование может выявить упущения в проектировании программного модуля, а такие упущения лучше устранить пораньше. Кроме того, известно, что исправление одних ошибок часто вно­сит другие. Хотя общее число ошибок уменьшается, после каждого исправле­ния приходится снова тестировать программу. Таким образом, тестирование вклинивается в процесс разработки. По этим причинам сейчас получила большую популярность методика непрерывного тестирования программы во время ее разработки. Она называется zero-defect mindset.

Согласно методике zero-defect mindset, все ошибки подразделяются на не­сколько уровней по своей грубости. Программист не имеет права добавлять новую функциональность в программу, пока он не исправит все крупные ошибки до определенного уровня. Допустимый уровень ошибки устанавли­вается для каждого этапа разработки, он повышается по мере завершения работы.

Итак, по всем современным методикам тестирование выполняется прямо в процессе разработки. При тестировании программы, состоящей из несколь­ких программных модулей, надо выбрать один из двух противоположных сти­лей тестирования: тестирование снизу вверх или тестирование сверху вниз.

Тестирование снизу вверх начинает с отдельных подпрограмм: функций и процедур, не вызывающих другие подпрограммы. На их вход подаются тес­товые данные, результаты их работы сравниваются с тестовыми результата­ми. После того как тесты уже не выявляют ошибок в таких подпрограммах, тестировщик переходит к тестированию подпрограмм, вызывающих уже протестированные подпрограммы. При этом выявляются ошибки, возни­кающие при взаимодействии подпрограмм. Затем тестируются подпрограм­мы, вызывающие только что протестированные подпрограммы и т. д. Нако­нец, в последнюю очередь проверяется работа головного модуля всей программы.

Тестирование сверху вниз, напротив, начинает сразу с готового прототипа головного модуля программы. Вместо подпрограмм, вызываемых из голов­ного модуля, подставляются заглушки (stubs), выдающие головному модулю заранее определенные значения. Убедившись в правильности работы такого скелета всей программы, тестировщик начинает по очереди заменять за- глушки настоящими подпрограммами или их прототипами, пока не дойдет до самых мелких программных единиц, уже не вызывающих никакие другие подпрограммы.

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

Какова бы ни была методика тестирования, сразу же после исправления ошибки прогоняется тот же набор тестов, с помощью которого была найде­на ошибка. Это так называемое регрессионное тестирование, позволяет убе­диться в том, что ошибка исправлена. Если регрессионное тестирование не выявило дефектов в программе, то этот набор тестов можно отложить и пе­рейти к следующему этапу тестирования.