Тестирование-книга. Ю. Н. Артеменко Научный редактор
 Скачать 6.27 Mb.
|
|
Глава 12: Планирование и документация 3 2 5 Таблица клавиатурных комбинаций Таблица клавиатурных комбинаций очень велика. Для ее создания луч ше всего подойдет электронная таблица. В нее включается информация о реакции в каждом из состояний программы на каждое нажатие клавиши. Если пользовательский интерфейс программы не согласован, т.е., на пример, нажатие клавиши ствующий блок (ой, сломалось!), отладочные фрагменты кода, странные сообщения, экзотические ролики или функции, реализацию которых руко водство отменило, но кто-то все равно их запрограммировал, никому ни чего об этом не сказав. Каждая строка в таблице посвящена одной клавише (А, а, Б, б, *, & и т.д.) или комбинации клавиш ( цу включаются и так называемые немые клавиши неанглийских раскладок. В первом столбце таблицы перечисляются клавиатурные комбинации. Остальные столбцы связаны со всеми возможными состояниями програм мы, ее диалоговыми окнами и формами ввода данных. Например, если нажать на клавишу <А> в форме ввода данных, программа отобразит бук ву А в текущем поле. Поэтому в строке таблицы, соответствующей клави ше <А> в колонке, относящейся к этой форме ввода, следует поставить букву А. Теперь предположим, что в диалоговом окне сообщения об ошиб ке пользователь для продолжения работы должен нажать клавишу щем этому окну, против клавиши <А> должно стоять Игнорируется. На практике таблицу клавиатурных комбинаций можно несколько со кратить, объединяя все эквивалентные клавиши или комбинации клавиш в одну строчку. Например, можно сгруппировать вместе все буквы нижнего регистра. Однако с критериями группировки следует быть очень аккурат ным, поскольку они сильно меняются от программы к программе. И даже после сжатия таблица все равно останется очень большой. К тому же вами или авторами спецификации целый ряд строк таблицы может быть зарезер вирован на будущее. К вопросу о группировке клавиатурных комбинаций мы еще вернемся в этой главе. 326 Часть II: Приемы и технологии тестирования На создание таблицы клавиатурных комбинаций обычно уходит не сколько дней. Когда она будет готова, распечатайте ее, пометьте маркером найденные в ней несоответствия, продумайте свои предложения по исполь зованию клавиш, оставшихся незанятыми, и передайте результаты руково дителю проекта. Если выполнить эту работу достаточно рано, в пользовательский интерфейс программы обязательно будет внесен ряд изменений и усовершенствований. Очень поблагодарят вас за нее и авто ры пользовательской документации. Таблица совместимых принтеров В настоящее время на рынке имеется более 1000 принтеров, и большая их часть эмулирует работу сравнительно небольшого количества принтеров известных марок (т.е. работает так же, как они). Поэтому если 50 принте ров, с которыми должна работать программа, эмулируют Hewlett Packard LaserJet II, не обязательно тестировать их все. В нашей практике хорошо зарекомендовали себя таблицы, отражающие совместимость тестируемых принтеров. Пример такой таблицы показан на рис. 12.16. (Разумеется, подобные таблицы можно создавать и для любых других устройств. Пример с принтерами выбран только потому, что в главе 8 на этом же примере рассматривалась целая область тестирования — работы програм мы с аппаратным обеспечением.) Форматы этих таблиц могут отличаться, но во всех обязательно должны присутствовать следующие столбцы. • Принтер. Марка и модель. • Режим. Некоторые принтеры могут работать в нескольких режимах — прежде всего, в своем собственном, а кроме того, эмулируя один или несколько других известных принтеров. • Совместимость. Марка и модель эмулируемого устройства. • Источник информации. Откуда вы знаете, что данный принтер эму лирует именно это устройство? Источником информации может Глава 12: Планирование и документация 327 служить человек, журнальная статья, реклама. При этом не все ис- точники одинаково надежны. • Протестирован. Укажите, протестированы ли принтеры, имеющи еся в вашей лаборатории на совместимость и какие при этом ис пользовались тесты. Проверена ли совместимость графических режимов? Одинаковы ли наборы боры символов? • Примечания. В этом столбце можно привести перечень причин не совместимости, собственные сомнения, отчеты пользователей и т.п. Диаграмма граничных значений Классы эквивалентности и граничные условия подробно обсуждались в главе 7. Там же описывался процесс разработки таблиц граничных значе ний. Еще один пример анализа граничных условий, на этот раз для систе мы отслеживания проблем, приведен на рис. 12.17. Не ждите, что эта таблица будет полностью завершена в самом начале тестирования. На самом деле вы будете собирать и корректировать необ ходимую информацию практически до самого конца проекта. Для начала же составьте список всех полей ввода (для чего можно воспользоваться уже имеющимся списком входных переменных). Выясните их функции. По мере изучения программы вносите и уточняйте информацию об их гранич ных значениях. Однако не пренебрегайте экспериментами и с теми пере менными, о которых вы еще мало знаете. Иерархические списки: перечень функций программы Перечень функций охватывает все, что может делать программа. Луч ше всего, если он отражает ваше собственное видение организации програм мы, тогда и планировать тестирование, и выполнять его будет гораздо удобнее. Именно этот список является ядром всей документации. Списков функций программы может быть несколько, и уровень их де тализации и полноты может быть самым разным. Наилучшим, на наш взгляд, является инкрементный подход: начните с самого простого, посте пенно добавляя все больше и больше информации. Этот подход показан на рис. 12.18. Программа, которую вы выберете для работы со списком функций, дол жна обладать достаточно мощными и гибкими средствами для просмотра, редактирования и реорганизации иерархических структур. Лучше всего, если она будет специально предназначена именно для этой цели, поскольку возможности средств, встраиваемых в текстовые процессоры, обычно до вольно ограничены. 3 2 8 Часть II: Приемы и технологии тестирования Глава 12: Планирование и документация 3 2 9 3 3 0 Часть II: Приемы и технологии тестирования На рис. 12.8 был приведен первый черновик перечня функций системы отслеживания проблем. Это скорее основа будущего списка, поскольку в нем отражены лишь функции самого верхнего уровня, очевидные после самого поверхностного знакомства с системой. Однако, несмотря на повер хностность, этот список уже обладает определенной ценностью. Держите его на своем рабочем столе, чтобы каждый раз, когда понадобится прове рить, не забыта ли какая-нибудь из функций программы, можно было с ним свериться. Распечатка может служить и контрольным списком, в ко тором одним цветом можно отмечать устойчивые функции программы, а другим — те, которые пока еще работают плохо. Второй черновик перечня функций может быть уже более организован ным. Выберите такую организацию, которая покажется вам наиболее есте ственной и удобной. Попробуйте составить алфавитный список всех команд программы. Для команд, активизируемых с помощью меню, скорее всего, больше подойдет иерархическая структура, повторяющая структуру меню. Но это вовсе не обязательно. В качестве альтернативы можно орга низовать информацию вокруг концептуальной схемы программы, объеди няя в группы те функции, которые логически связаны между собой, участвуют в решении общих задач, обработке одних и тех же входных дан ных или генерации одних и тех же выходных. На рис. 12.19 приведен второй черновик списка функций системы от слеживания проблем. Большинство функций его первой версии оставлены без изменений. Только функция 5, Работа с файлами данных, разбита на две составляющих: Чтение данных из файла и Запись данных в файл. Для первой из этих подфункций в план добавлено подробное описание. Глава 12: Планирование и документация 3 3 1 3 3 2 Часть II: Приемы и технологии тестирования Список функций программы можно расширять все дальше и дальше. Например, его элемент 5.1.3.6 (Необязательно) Печать записи можно разбить на составляющие, чтобы показать, что программа сначала прове ряет, включен ли принтер и готов ли он к печати. Лучше всего расширять список постепенно: если попытаться составить его сразу, вы просто утонете в обилии выполняемых программой мелких операций и у вас не хватит времени на ее тестирование. На рис. 12.20 развернут третий элемент списка — Ввод новых отчетов о проблемах. Такой детализированный и иерархически организованный список заслуживает названия функционального плана программы. Когда спи сок настолько подробный, каждый его элемент соответствует единственной логической операции программы. Это уже почти готовый набор тестовых заданий. Углубляя составленный план, лучше всего придерживаться следующих направлений анализа. • Все функции программы. • Все видимые подфункции. • Все команды, выполняемые программой. • Результаты нажатий каждой командной клавиши в каждом месте программы. • Каждое меню и каждая его команда. Для отображения этой инфор мации тестировщики обычно пользуются картами меню — диаграм мами свободной формы. Диаграмма показывает, куда ведет каждая команда. В нее вписываются названия всех меню и экранов. • Все способы достижения каждого режима или экрана программы. Как добраться до конкретного меню, диалогового окна, формы, как перевести программу в заданное состояние? Имеет ли значение, каким способом пользователь попадает в определенный режим, или это все равно? • Все способы выхода из каждого режима или экрана программы. Как перейти к следующему меню, диалоговому окну, форме, состоянию программы? Как затем вернуться назад? Как прервать ввод данных? Как прервать выполнение программы из данной точки? • Каждая форма ввода данных, диалоговое окно и окно сообщения. Проанализируйте граничные значения данных, внесите информацию в соответствующую таблицу. Покажите, как попасть в каждую из этих форм, каковы различия, определяемые последовательностью действий пользователя (например, различное поведение программы при первом и втором открытии данного окна). Перечислите специ- Глава 12: Планирование и документация 3 3 3 3 3 4 Часть II: Приемы и технологии тестирования альные команды, выясните, как выйти из данного окна с сохране нием и без сохранения информации. Покажите, куда пользователь попадает после этого. • Обработка ошибок в данной части программы. Как правило, удоб нее выносить обработку ошибок в отдельный раздел схемы, а не описывать ее внутри каждого подраздела. Матрицы Матрица похожа на таблицу — обе они состоят из строк и столбцов. В самой верхней строке (строке заголовков) показано, какая информация содержится в каждом из столбцов. В первом столбце многих таблиц и всех матриц показано, какая информация содержится в каждой из строк. Различия между терминами "таблица" и "матрица" состоят в следую щем. • Главная функция таблицы — описательная. В ней описывается поведение программы (как на рис. 12.16) или аппаратного обеспе чения. Имея достаточно полную спецификацию, можно полностью заполнить таблицу, даже и не приступая к тестированию. После этого, уже в ходе непосредственного тестирования, поведение про граммы будет сравниваться с данными таблицы. • Главная функция матрицы — сбор данных. Это исключительно удобная структура для тестирования пар значений переменных, со единения двух обстоятельств, типов аппаратного обеспечения или событий. Заголовки столбца и строки определяют условия теста. Его результат записывается в соответствующую ячейку. Часто такая за пись представляет собой просто "птичку", показывающую, что про грамма ведет себя правильно. Матрицы дискового ввода/вывода Матрица дискового ввода/вывода — это классический пример широко используемой тестовой матрицы. Предположим, что для записи данных на диск- в программе имеются следующие команды. • Сохранить. Копия данных памяти записывается на диск. • Сохранить как. Копия данных памяти записывается на диск с но вым именем. • Печать в файл (ASCII). Выходные данные форматируются так, как если бы они отправлялись на текстовый принтер (т.е. только с про стейшими управляющими кодами, такими как табуляции, перевод строки или возврат каретки), но записываются они не в порт прин тера, а в дисковый файл. Глава 12: Планирование и документация 3 3 5 • Печать в файл (форматированная). Выходные данные форматиру ются так, как если бы они отправлялись на текущий принтер, но записываются в дисковый файл. В файл включаются и все необхо димые управляющие коды. Предположим также, что в программе имеются следующие функции чтения данных с диска. • Открыть. Стирание из памяти информации текущего файла данных (возможно, после ее сохранения) и загрузка в память нового файла. • Добавить. Загрузка содержимого указанного файла в память в ко нец текущего открытого файла. • Вставить. Загрузка содержимого указанного файла в память со вставкой его в текущую позицию в уже открытом файле. • Импортировать текст. Открыть текстовый файл, созданный дру гим приложением и хранящийся в формате, не являющимся для программы родным. • Импортировать графику. Загрузить изображение в память. Теперь допустим, что пользователь пытается сохранить или прочитать файл одного из следующих типов. • Очень маленький файл (1—2 байта). • Типичный файл. • Большой файл (больший доступного объема RAM). Пусть программа может работать на компьютерах со следующими типа ми дисков. • Дискеты низкой емкости. • Дискеты высокой емкости. • Жесткий диск. • Сетевой диск. • Оптический диск. • RAM-диск. И наконец, предположим, что произошло одно из следующих событий. • Диск полон — на нем нет места для записи данных командами Со хранить, Сохранить как или Печать в файл. • Диск почти полон — он заполняется в процессе записи данных или при создании временного файла для их чтения. • Диск защищен от записи. 3 3 6 Часть II: Приемы и технологии тестирования • Тайм-аут. Диск (скорее всего, сетевой) слишком долго не отвечает. • Сбой или отключение питания. • Клавиатурный ввод. Нажатие клавиш во время чтения или записи данных. • Активность мыши. Перемещение или щелчки кнопок мыши во время чтения или записи данных. Вообще, вариантов подобных событий великое множество. Перечислен ные примеры можно разбить для анализа на четыре категории. • Файловые операции (такие, как открытие и сохранение). • Характеристики файлов, такие как тип, формат и размер. • Аппаратура, как, например, типы жестких дисков. Сюда может входить и список совместимого оборудования. • Условия сбоев, как, например, заполнение диска или аппаратный сбой. Организовать эти категории информации в матрицы ввода/вывода мож но многими способами. Один из них показан на рис. 12.21. Составленная матрица станет вашим путеводителем: следуя ей, вы по очереди выполните тесты, соответствующие каждой из ее ячеек, и поста вите в них соответствующие отметки. Например, работая по приведенной на рис. 12.21 матрице, тестировщик попытался сохранить данные (вторая строка) на защищенном от записи диске (третий столбец) низкой емкости. Программа выдала корректное сообщение об ошибке, и дальнейшие ее действия были вполне разумны, поэтому тестировщик отметил ячейку, лежащую на пересечении второй строки и третьего столбца (***). Матрица дискового ввода/вывода — это одна из самых важных диаг рамм тестировщика. На наш взгляд, лучше всего сначала составить спис ки для всех четырех перечисленных категорий, соответствующие возможностям именно вашей программы, а затем построить таблицы для ввода и вывода. Другие матрицы, связанные с аппаратным обеспечением На рис. 8.4 приводилась тестовая матрица для сравнения различных типов принтеров. Заголовками ее столбцов служили названия принтеров, а заголовками строк — их сравниваемые функции. В другой матрице можно было бы показать типы принтеров и объемы их оперативной памяти. Для тестирования подошло бы полностраничное графическое изображение. Если программа напечатает такое изображение без сообщения о нехватке памяти принтера, значит, тест пройден. Глава 12: Планирование и документация 3 3 7 3 3 8 Часть II: Приемы и технологии тестирования Матрица операционного окружения В этой матрице строки (или столбцы) могут соответствовать перемен ным окружения — типу и версии операционной системы, диспетчера па мяти, языку, стране и т.п. Столбцы (строки) могут также представлять переменные среды, а могут соответствовать отдельным параметрам, типам аппаратуры, кодам ошибок и всему остальному, что потребует тестирования в комплексе с параметра ми операционной среды. Матрица комбинаций входных данных Случается, что ошибки, связанные с вводом, определяются не самими данными или событиями, а их комбинациями. Если программа сбоит толь ко в том случае, когда пользователь вводит 60 символов в третьей строке экрана, после чего нажимает стрелку вправо — налицо ошибка, и эту ошибку ни за что не выявить, тестируя отдельные действия и переменные. К сожалению, в большинстве программ количество возможных комбинаций входных действий и данных столь велико (а чаще и просто бесконечно), что протестировать их все невозможно. Поэтому вопрос состоит в том, как выявить наиболее интересные из них. Майерсом (Myers, 1979) описан сложный, но комплексный подход к этой задаче, называемый причинно-следственными диаграммами (Cause-effect Graphing). Мы не будем описывать его в данной книге, однако тем, кому предстоит серьезно заниматься тестированием, рекомендуется его изучить. Наш собственный подход носит более экспериментальный характер. Комбинации входных условий мы изучаем прямо по ходу тестирования. Таким образом, в поле нашего зрения попадают не все теоретически воз можные варианты, а самые естественные из них. Очень полезно обратиться к программистам со списком переменных программы и спросить у них, какие из этих переменных абсолютно независимы. Но полностью полагать ся на их информацию не стоит: во-первых, память может их подводить, а во-вторых, кто-либо из программистов может найти занятным подбросить вам заведомо ложную информацию. Так что для надежности все равно выполните несколько проверочных тестов. Как следует поработав с программой и почувствовав, что связи между ее данными уже достаточно прояснились, мы приступаем к более последо вательному тестированию их комбинаций. Матрицы сообщений об ошибках и клавиатурных комбинаций В этой главе уже рассказывалось о таблице, описывающей реакцию программы на все возможные нажатия клавиш. Настало время более под робно рассмотреть этот вопрос. Глава 12: Планирование и документация 3 3 9 В системах с графическим пользовательским интерфейсом все сообще- ния об ошибках выводятся в диалоговых окнах. В ответ на сообщение пользователь должен щелкнуть на кнопке ОК или нажать клавишу Любые другие его действия окном игнорируются. Однако на практике даже в системах со встроенной поддержкой диалоговых окон программисты нередко снабжают отдельные окна возможностью реагировать и на другие события. Тестировщики часто спрашивают, зачем тестировать все окна сообще- ний в программе для Macintosh, если все они работают одинаково. Если тщательно протестировано одно из окон программы, можно считать, что протестированы все. Однако опытные специалисты знают, что это невер- но. Нам не раз приходилось сталкиваться с ситуациями, когда приложения Macintosh, Amiga, Windows и DOS разрушались именно нестандартными действиями пользователя в окне сообщения. Конечно, невозможно нажать каждую клавишу в каждом диалоговом окне программы, но следует всегда иметь в виду, что нажатие клавиш, не имеющих никакого эффекта в одном диалоговом окне, может разрушить другое. Поэтому мы выработали подход, позволяющий оптимальным обра зом протестировать программу на предмет подобных ситуаций. В его осно ве лежит матрица, строки которой связаны с диалоговыми окнами программы, а столбцы — с группами клавиши их сочетаний. Для каждой строки (т.е. в каждом окне сообщения) проверяется несколько клавиш из каждой группы. Один из способов разбиения клавиш на группы показан на рис. 12.22. Документирование тестовых материалов В этом разделе рассказывается о документах, описывающих процесс тестирования. Это не только плановые документы — в них записывается, что вы делали, почему, когда, какими были результаты и что должно быть сделано далее. Мы уже говорили о том, каково назначение тестовой документации и какую пользу она может принести, если ее правильно применять. Теперь давайте поговорим о типах плановых документов. Когда говорят о тестовой документации, вовсе не имеют в виду некую монолитную концепцию. Напротив, возможных типов документов огром ное множество. Некоторые из них более полезны, чем другие, некоторые дешевле, некоторые носят более фундаментальный характер. Приступая к каждому новому проекту, вам предстоит решать, какие из всех этих мно гочисленных документов лучше всего удовлетворят его нуждам. 3 4 0 Часть II: Приемы и технологии тестирования Глава 12: Планирование и документация 3 4 1 Кто пользуется тестовой документацией Главным критерием ценности документа является то, насколько он понятен читателю. Именно на это и ориентируется составитель докумен та, а потому он должен точно знать, кто его будет читать и какова степень компетентности этого человека. Кроме того, важно, для чего будет исполь зоваться данный документ — в одних случаях достаточно короткого пояс нительного описания, а в других требуются четкие и подробные инструкции. Временные оценки, приведенные в следующих разделах, основаны на опыте нашей собственной работы и, разумеется, очень приблизительны. Личные заметки Это простейшие из документов. Но все же их следует составлять так, чтобы, прочитав их несколько месяцев спустя, можно было разобраться, о чем идет речь, какие и почему выполнялись тесты и какие результаты были получены. Старайтесь писать их как можно аккуратнее, но при этом будьте кратки. Время, затрачиваемое на заметки о проведенных тестах, должно быть в пределах от половины до троекратного объема времени, необходи мого для их разработки и выполнения. Назначение личных заметок может быть следующим. • Описание тестов, которые будут проводиться повторно. Вместо того чтобы заново продумывать каждый тест, можно обратиться к заметкам, сделанным на предыдущем этапе работы. В этих заметках могут описываться достаточно сложные подробности. Если речь идет о комплексном тесте с множеством граничных условий и других специфических значений, опишите их все и не забудьте добавить, каково их назначение. Тогда после изменения программы сразу будет ясно, какие изменения нужно будет внести в такой тест. • Напоминание о том, что уже сделано. Как ни странно, выполнить один и тот же тест десяток раз на протяжении нескольких дней на самом деле ничего не стоит. Иногда тестировщик забывает, что тест уже выполнен, иногда не уверен в этом и на всякий случай выпол няет его еще раз. Если аккуратно вести журнал проводимых тестов, всей этой путаницы и потерь времени вполне можно избежать. • Напоминание о том, что еще предстоит сделать. Аккуратно запи сывайте все идеи о будущем тестировании. В дальнейшем, разраба тывая новые тесты, вы можете обращаться к этим записям. • Ответы на вопросы программистов. Если программисту не удает ся воспроизвести найденную вами ошибку, он может попросить провести дополнительные тесты, которые, на его взгляд, могут быть 342 Часть II: Приемы и технологии тестирования связаны с проблемой. Выполнили ли вы эти тесты? В точности ли те, о которых вас просили? Какими были результаты? Заметки для другого члена команды Речь идет о сотруднике, тестирующем тот же продукт, что и вы. У него могут возникнуть к вам вопросы, или же он может попросить описание одного или нескольких проводимых вами тестов. На составление такого описания может уйти столько времени, сколько необходимо для разработки теста, а даже в 5 раз больше. В заметках может быть следующая информация. • Как выполнить каждый тест. Это описание может быть коротким, поскольку предназначается для достаточно опытного сотрудника. • Ожидаемые результаты каждого теста. Иногда стоит также опи сать и вероятные условия сбоя. • Смысл каждого значения данных. Когда программа меняется, а проведенные вами тесты предстоит выполнять другому сотруднику, он может спросить у вас, что следует изменить. И прежде всего ему необходимо будет выяснить назначение данных исходного теста. Во многих случаях вам не придется писать длинных пояснений, по скольку назначение данных будет очевидно из ожидаемого резуль тата. • Любые другие специальные инструкции, например, как долго следует ждать определенного события или как быстро нажимать клавиши для определенного теста. • Какие тесты необходимо выполнять регулярно (регрессионные те сты), какие из них наиболее быстрые и простые и каковы ваши соображения по поводу дальнейшего тестирования. • Каково назначение данных тестов. Какая часть программы ими исследуется? Какие проблемы могут быть выявлены с наибольшей вероятностью? Если выполняются группы связанных тестов, опиши те их с этой точки зрения. В частности, можно описать общее на значение группы, затем подробно описать один из тестов, а остальные представить как вариации первого. Так и писать будет быстрее, и понять легче. Заметки для другого опытного тестировщика Разница между этим и предыдущим случаями в том, что на этот раз предполагается, что вас не будет поблизости, чтобы ответить на вопросы. Если, например, вы разрабатываете материалы по контракту, по его завер шении к вам уже нельзя будет обратиться. Поэтому на описание каждого Глава 12: Планирование и документация 3 4 3 теста планируйте вдесятеро больше времени, чем на его разработку и вы полнение. Вам придется предоставить следующие сведения. • Все, что пишется для члена команды, но в более подробном изло жении. Особенно аккуратно следует указывать, какой результат оз начает сбой, а какой — успешное прохождение теста. Если вам кажется, что определенные инструкции сложны для понимания, попросите кого-нибудь выполнить по ним тест и посмотрите, как он справится и что ему будет непонятно. (Особенно часто подобные сложности возникают при описании тестов, связанных с временны- ми параметрами выполнения программы.) • Дополнительные аналитические материалы, дополнительные опи сания тестов, их связей, подробные описания групп тестов, а не каждого входящего в них теста по отдельности. • Зависимости. Если, например, программа может читать максимум 80 байтов данных за один раз, вы будете тестировать ее с 80 и 81 байтом. Если затем возможности программы будут расширены до 256 байтов, старые тесты потеряют смысл. Теперь тестируемые объе мы данных необходимо будет увеличить до 256 и 257 байтов. В описании этих тестов должно быть явно указано, что они предназ начены для программы с потолком в 80 байтов. Это замечание луч ше всего вынести в отдельный раздел под названием "Зависимости" или "Предположения". Тогда вам не придется писать, что делать, если спецификация изменится. Опытный тестировщик прекрасно сообразит это сам — главное, чтобы у него была вся необходимая информация, т.е. чтобы он знал, что с данным параметром програм мы связаны такие-то и такие-то тесты. Заметки для следующего выпуска программы (планируемого, вероятно, через год) После выпуска программы работа тестировщиков над ней обычно пре кращается, чтобы вскоре возобновиться уже над следующим выпуском. При этом вовсе не обязательно, чтобы им занимались те же люди, а потому будущим тестировщикам очень пригодятся любые ваши заметки. Некото рые из тестовых материалов им, возможно, будет трудно понять. Поэтому подготовьте специальный комплекс записей для облегчения их понимания. Эти записи будут подобны описанным в предыдущем разделе. Представьте себе будущих тестировщиков как археологов. Им придет ся прокапываться сквозь ворох вашей документации, всевозможных заме ток, дисков и т.п. Вполне вероятно, что все, чего они не смогут понять, будет просто отброшено. Или же, что еще хуже, отдельные материалы будут 3 4 4 Часть II: Приемы и технологии тестирования неверно интерпретированы, и в результате будут пропускаться ошибки. Имейте также в виду, что будущим тестировщикам придется не только выполнять уже готовые тесты, но и модифицировать многие из них, по скольку к тому времени программа наверняка изменится. Итак, вашим последователям будут крайне необходимы следующие материалы. • Подробности о каждом тесте. Как его выполнить и какие ожида ются результаты. • История сбоев программы. Какие проблемы выявлялись каждым из тестов, как они выглядели и какие изменения были внесены в про грамму для исправления ситуации. • Дополнительные соображения и проблемные вопросы по поводу каж дого из тестов, зависимости тестов от поведения программы и спе цификации. Сценарий теста для неопытного тестировщика Этот человек может быть опытным пользователем компьютера (про граммистом, руководителем, системотехником), а может быть и совсем новичком. Как бы там ни было, опыта тестирования программных продук тов у него нет и с тестируемой программой он абсолютно незнаком. По этому ему необходимо подробное пошаговое руководство — сценарий теста. Назначение сценариев и обеспечиваемые ими выгоды могут быть сле дующими. • Работа по сценариям позволяет сократить размер группы тести рования. В критической ситуации можно подключить к работе над проектом дополнительный персонал и быстро его обучить. Таким людям необходимо будет просто следовать сценариям — от них не требуется особых знаний и навыков, и их зарплата обычно гораздо меньше, чем у основных специалистов. • Сценарии освобождают персонал от самой утомительной работы. В двадцатый раз выполняя один и тот же тест, кто угодно будет делать его сонно и невнимательно. Во многих случаях превосходным решением проблемы может быть поручение повторяющихся тестов временным сотрудником. • Сценарии прекрасно подходят для стандартизированных наборов тестов. Они могут быть основой регрессионного тестирования, однако самые сложные из тестов не следует поручать дилетантам. • Хороший сценарий производит неотразимое впечатление на руковод ство. Не следует недооценивать значение этого обстоятельства. |