Учебник по тестированию. Guide to Software Test Design
 Скачать 2.51 Mb.
|
|
Невозможность тестирования всего В своей монументальной книге "Тестирование объектно-ориентированных систем" Роберт Биндер предоставляет превосходный пример невозможности тестирования "всего". Рассмотрим следующую программу: int blech (int j) { j = j - 1; // должно быть j = j + 1 j = j / 30000; return j; } Обратите внимание, что вторая строка не правильная! Функция blech принимает целое j, вычитает из него единицу, делит получившееся значение на 30 000 (целочисленное деление целых чисел без остатка) и возвращает вычисленное значение. Если на компьютере, выполняющем эту программу, целые числа реализованы с использованием 16 бит, то наименьшим из возможных входных значений является число -32768, а наибольшим 32767. Таким образом, существует 65536 возможных входов в эту крошечную программу (а в программу вашей организации, вероятно, больше). Будет ли у вас время (и выносливость) для создания 65 536 тестовых сценариев? Конечно, нет. Поэтому, какие входные значения мы выбираем? Рассмотрим следующие входные значения и их способность обнаружить этот дефект. Входное значение (j) Ожидаемый результат Фактический результат 1 0 0 10 42 0 0 40000 1 1 -64000 -2 -2 Ой! Обратите внимание, что ни один из выбранных тестов не обнаружил этот дефект. На самом деле только четыре из возможных 65536 входных значений смогут обнаружить этот дефект. Каков шанс того, что вы выберите все четыре? Каков шанс того, что вы выберите одно из четырех? Какова вероятность того, что вы выиграете в лотерею? Является ли ваш ответ одинаковым для каждого из этих трех вопросов? Резюме ● Тестирование - это параллельный жизненный цикл процесса разработки, использования и поддержки средств тестирования для того, чтобы измерять и улучшать качество тестируемой программы (Крэйг и Яскил). ● Проектирование тестов для программного обеспечения и других технических продуктов может быть таким же манящим, как и первоначальное проектирование самого продукта. Тем не менее... программисты часто заботятся о тестировании с запозданием, разрабатывая тестовые сценарии которые "вроде правильные", имея при этом мало уверенности в том, что они являются полными. Помня о целях тестирования, мы должны разработать такие тесты, которые будут иметь наивысшую вероятность нахождения большинства ошибок при минимальном количестве времени и усилий (Прессман). ● Тестирование черного ящика - это стратегия, при которой тестирование основано исключительно на требованиях и спецификациях. Тестирование белого ящика - это стратегия, при которой тестирование основано на внутренних путях, структуре и реализации тестируемого программного обеспечения. ● Обычно тестирование и, следовательно, проектирование тестовых сценариев, представлено на четырех различных уровнях: модульном, интеграционном, системном и приемочном. Практика 1. Какие четыре входных значения для функции blech найдут скрытый дефект? Как вы определили их? Что это предлагает вам как подход для поиска других дефектов? 11 Глава 2. Учебные сценарии “У них была одна последняя оставшаяся ночь вместе, поэтому они обняли друг друга так крепко, как переплелись две нити двухвкусового сыра - оранжевого и желтовато-белого, оранжевый, возможно, был мягким Чеддером, а белый - Моцарелла, хотя это мог быть Проволон или просто чистый Американский сыр, как это реально не различимый вкус, несходный с оранжевым, все же они хотели бы, чтобы вы поверили этому, потому что они разных цветов." Мэриан Симс Для чего нужны учебные сценарии? В приложениях к этой книге представлены два учебных сценария: ● Приложение А описывает онлайн брокерскую фирму "Браун и Дональдсон". ● Приложение В описывает "Регистрационную систему Государственного университета". Примеры из этих учебных сценариев используются для того, чтобы показать техники разработки тестовых сценариев, описываемых в этой книге. В дополнение, некоторые из упражнений этой книги построены на этих учебных сценариях. Следующие разделы кратко описывают учебные сценарии. При необходимости, читайте детальную информацию в приложениях А и В. Браун и Дональдсон Браун и Дональдсон (БиД) - это вымышленная онлайн брокерская фирма, которую можно использовать для практики в разработке тестовых сценариев, представленных в этой книге. БиД первоначально была создана для курса "Тестирование качества программного обеспечения при проектировании Web/электронного бизнеса" (подробнее см. http://www.sqe.com ). В приложение А включены скриншоты различных страниц. На протяжении всей книги на некоторые из них будут даваться ссылки. Текущий сайт БиД находится по адресу http://bdonline.sqe.com . Любое сходство с существующим онлайн брокерским веб-сайтом является чисто случайным. Вы можете попробовать поработать с веб-сайтом БиД. Новым пользователям нужно будет создать онлайн-аккаунт. Эта учетная запись будет не настоящей. Любые сделки, запрошенные или выполненные через этот аккаунт, будут происходить не в реальном мире, а только в вымышленном мире БиД. После того, как аккаунт создан, этот шаг можно будет пропускать, и сразу входить под именем пользователя и паролем. При создании новой учетной записи вас попросят предоставить код авторизации. Код авторизации - "11111111". На этом веб-сайте также содержится несколько загружаемых документов из учебного сценария БиД, которые могут помочь в разработке планов тестирования для ваших собственных веб-проектов. Регистрационная система Государственного университета В каждом государстве есть Государственный университет. Этот учебный сценарий описывает систему онлайн регистрации студента для вымышленного Государственного университета. Пожалуйста, не пытайтесь обналичить свои акции из Браун и Дональдсон, чтобы поступить в Государственный университет! Документ в приложении В описывает запланированный пользовательский интерфейс Регистрационной системы Государственного университета. В нём содержатся изображения пользовательского интерфейса в 12 том порядке, в котором они обычно используются. Всё начинается с изображения входа в систему. Затем можно настроить поля базы данных, добавить / изменить / удалить студентов, добавить / изменить / удалить курсы и добавить / изменить / удалить разделы класса. В заключении отображается выбор конкретных разделов курса для каждого студента. Также определяются дополнительные административные функции. 13 Секция I. Методы тестирования черного ящика Определение Тестирование черного ящика - это стратегия, в которой тестирование основано исключительно на требованиях и спецификациях. В отличие от дополняющего его тестирования белого ящика, тестирование черного ящика не требует знания внутренних связей, структуры или реализации тестируемой программы. Основной процесс тестирования черного ящика: ● анализируются требования или спецификации; ● на основе спецификации выбираются допустимые входные данные для того, чтобы убедиться, что программа обрабатывает их корректно. Также нужно выбрать и некорректные входные данные для того, чтобы проверить, что программа определяет и обрабатывает их правильно; ● определяются ожидаемые результаты для этих входных данных; ● на основе выбранных входных данных строятся тесты; ● тесты запускаются; ● фактические результаты сравниваются с ожидаемыми результатами; ● принимается решение о надлежащем или ненадлежащем функционировании программы. Применимость Тестирование черного ящика может быть применено на всех уровнях разработки системы - модульном, интеграционном, системном и приемочном. По мере продвижения вверх, от модуля к подсистеме, от подсистемы к системе, сам ящик становится больше, с более сложными входными данными и более сложными результатами, но подход остается тем же. Поскольку ящик увеличивается в размере, то мы вынуждены использовать метод черного ящика - появляется слишком много вариантов для тестирования программы, чтобы осуществить тестирование методом белого ящика. Недостатки При использовании тестирования черного ящика тестировщик никогда не будет уверен, насколько полно была проверена тестируемая программа. Не имеет значения, насколько умным или прилежным является 14 тестировщик: некоторая функциональность может быть вообще не проверена. Например, какова вероятность того, что тестировщик подберет тестовый сценарий, чтобы обнаружить эту "особенность"? If (name=="Lee" && employeeNumber=="1234" && employmentStatus=="RecentlyTerminatedForCause") { послать Ли чек на $1,000,000; } Для того, чтобы тестированием черного ящика найти все дефекты, тестировщику нужно создать все возможные комбинации входных данных, как допустимых, так и недопустимых. Такое исчерпывающее тестирование входных данных почти всегда невозможно. Мы можем выбрать только подмножество (часто очень небольшое подмножество) входных комбинаций. В книге " Искусство тестирования программ " Гленфорд Майерс приводит замечательный пример бесполезности исчерпывающего тестирования: каким образом вы можете тщательно протестировать компилятор? Написав каждую возможно правильную и неправильную программу. Значительно серьезней данная проблема для тех систем, которые должны помнить, что происходило ранее (т.е. которые запоминают свое состояние). В таких системах нужно протестировать не только каждое возможное входное значение, но и каждую возможную последовательность каждого возможного входного значения. При тестировании методом черного ящика тестировщик никогда не будет уверен, насколько полно была проверена тестируемая программа. Преимущества Несмотря на то, что мы не можем протестировать всё, формально тестирование чёрного ящика указывает, как тестировщику выбрать подмножество тестов, одинаково целесообразных и эффективных при поиске дефектов. По существу, такие наборы найдут больше дефектов, чем эквивалентное количество случайно созданных тестов. Тестирование черного ящика помогает максимизировать отдачу от инвестиций в тестирование. Несмотря на то, что мы не можем протестировать всё, формально тестирование чёрного ящика указывает, как тестировщику выбрать подмножество тестов, одинаково целесообразных и эффективных при поиске дефектов. Литература Myers. Glenford J. (1979). The Art of Software Testing . John Wiley & Sons. 15 Глава 3. Тестирование классов эквивалентности "На четвертый день разведки Амазонки, Байрон вылез из своей автокамеры, проверил последние новости на своем карманном компьютере (далее PDA), оснащенном технологией беспроводной связи, и понял, что терзание, которое он чувствовал в желудке, было ни страхом - нет, он не боялся, скорее был в приподнятом настроении - ни напряжением - нет, он, вообще-то, был скорее расслаблен - так что это был, вероятно, паразит." Чак Килан Введение Тестирование классов эквивалентности - это техника, используемая для уменьшения числа тестовых наборов до выполнимого уровня при сохранении приемлемого уровня покрытия тестами. Эта простая техника используется интуитивно почти всеми тестировщиками, даже если они не знают о ней формально как о методе тест-дизайна. Многие тестировщики выявили её полезность логически, в то время как другие открыли её просто из-за нехватки времени на более тщательное тестирование. Рассмотрим ситуацию. Мы пишем модуль для системы отдела кадров, который определяет, в каком порядке нужно рассматривать заявления о приёме на работу в зависимости от возраста кандидата. Правила нашей организации таковы: ● от 0 до 16 - не принимаются ● от 16 до 18 - могут быть приняты только на неполный рабочий день ● от 18 до 55 - могут быть приняты как штатные сотрудники на полный рабочий день ● от 55 до 99 - не принимаются * Примечание Icon Если вы видите проблему в таком описании требований, не волнуйтесь. Они так написаны с определенной целью, и будут исправлены в следующей главе. Наблюдение Icon Следуя этим правилам, наша организация не приняла бы на работу ни доктора Дуги Хаузера, ни полковника Харланда Сандерса, потом что один из них слишком молод, а другой - слишком стар. Нужно ли нам проверять этот модуль для следующих значений возраста: 0, 1, 2, 3, 4, 5, 6, 7, 8, ..., 90, 91, 92, 93, 94, 95, 96, 97, 98, 99? Если у нас есть огромное количество времени (и это не учитывая отупляющего повторения при почасовой оплате), то, конечно, нужно. Если программист реализовал модуль со следующим программным кодом, то нам придется проверить каждое значение возраста (если у вас нет опыта в программировании, не переживайте. Эти примеры просты. Просто читайте код и вам станет все понятно): If (applicantAge == 0) hireStatus = "NO"; If (applicantAge == 1) hireStatus = "NO"; If (applicantAge == 14) hireStatus = "NO"; If (applicantAge == 15) hireStatus = "NO"; If (applicantAge == 16) hireStatus = "PART"; 16 If (applicantAge == 17) hireStatus = "PART"; If (applicantAge == 18) hireStatus = "FULL"; If (applicantAge == 19) hireStatus = "FULL"; If (applicantAge == 53) hireStatus = "FULL"; If (applicantAge == 54) hireStatus = "FULL"; If (applicantAge == 55) hireStatus = "NO"; If (applicantAge == 56) hireStatus = "NO"; If (applicantAge == 98) hireStatus = "NO"; If (applicantAge == 99) hireStatus = "NO"; Учитывая эту реализацию, факт того, что любой набор тестов прошел успешно, ничего не говорит нам о следующем тесте, который мы можем выполнить. Он может пройти успешно, а может завершиться ошибкой. К счастью, программисты не пишут код подобным образом (по крайней мере, не очень часто). Хороший программист напишет этот код так: If (applicantAge >= 0 && applicantAge <=16) hireStatus="NO"; If (applicantAge >= 16 && applicantAge <=18) hireStatus="PART"; If (applicantAge >= 18 && applicantAge <=55) hireStatus="FULL"; If (applicantAge >= 55 && applicantAge <=90) hireStatus="NO"; Из данной типовой реализации видно, что для первого требования нам не нужно проверять 0, 1, 2, ... 14, 15 и 16. Необходимо проверить только одно значение. И какое оно? Любое значение в данном диапазоне подойдет не хуже других. То же самое верно для всех остальных диапазонов. Диапазоны значений, подобные описанным, называются классами эквивалентности . Класс эквивалентности представляет собой набор данных, которые либо одинаково обрабатываются модулем, либо их обработка выдает одинаковые результаты. При тестировании любое значение данных, входящее в класс эквивалентности, аналогично любому иному значению класса. В частности, мы можем ожидать, что: ● если один тестовый сценарий в классе эквивалентности обнаруживает дефект, то все другие тестовые сценарии в том же классе эквивалентности обнаружат этот дефект. ● если один тестовый сценарий в классе эквивалентности не обнаруживает дефект, то все другие тестовые сценарии в том же классе эквивалентности не обнаружат этот дефект. Ключевой момент Icon Набор тестов формирует класс эквивалентности, если вы полагаете, что: ● они все проверяют одно и то же. ● если один тест ловит ошибку, то и остальные, вероятно, тоже его поймают. 17 ● если один тест не ловит ошибку, то и остальные, вероятно, тоже его не поймают. Сэм Канер."Тестирование программного обеспечения". Этот подход предполагает, что существует спецификация, которая определяет различные эквивалентные классы для тестирования. Также предполагается, что программист не сделал таких странных вещей, как: if (applicantAge >= 0 && applicantAge <= 16 ) hireStatus="NO"; if (applicantAge >= 16 && applicantAge <= 18 ) hireStatus="PART"; if (applicantAge >= 18 && applicantAge <= 41 ) hireStatus="FULL"; //странное условие ниже if (applicantAge == 42 && applicantName == " Lee") hireStatus="Немедленно принять на работу с огромной зарплатой"; if (applicantAge == 42 && applicantName <> " Lee") hireStatus="FULL"; //конец странного условия if (applicantAge >= 43 && applicantAge <= 55 ) hireStatus="FULL"; if (applicantAge >= 55 && applicantAge <= 99 ) hireStatus="NO"; Используя классы эквивалентности, мы уменьшаем число тестовых сценариев со 100 (тестирование каждого возраста) до 4 (тестирование одного возраста в каждом классе эквивалентности) - значительная экономия. Теперь мы готовы начать тестирование? Вероятно, нет. Что насчет таких входных данных как 969, -42, FRED или &$#! ? Должны ли мы создавать тестовые сценарии для некорректных входных данных? Ответ, который вы получите от любого хорошего консультанта: "Возможно". Для того, чтобы понять этот ответ, мы должны проверить подход, который пришел из объектно-ориентированного мира, названный " проектирование-по-контракту ". Заметка Icon По Библии, возраст Мафусаила, когда он умер, был 969 лет (Быт 5:27). Спасибо Гидеону, который сделал эту информацию легко доступной в комнате моего отеля без необходимости высокоскоростного интернет соединения. С точки зрения закона, контракт - это юридически обязательное соглашение между двумя (или более) лицами, которое описывает, что каждое из лиц обещает делать или не делать. Каждое из этих обещаний полезно другому. В подходе "проектирование-по-контракту" модули (в парадигме объектно-ориентированного программирования они называются "методами", но "модуль" является более общим термином) определены в терминах предусловий и постусловий. Постусловия определяют, что модуль обещает сделать (вычислить значение, открыть файл, напечатать отчет, обновить запись в базе данных, изменить состояние системы и 18 т.д.). Предусловия описывают требования к модулю, при которых он переходит в состояние, описываемое постусловиями. Например, если у нас есть модуль "openFile", что он обещает сделать? Открыть файл. Какие будут разумные предусловия для этого модуля? Во-первых, файл должен существовать, во-вторых, мы должны предоставить имя (или другую идентифицирующую информацию), в-третьих, файл должен быть "открываемым", т.е. он не может быть открытым в другом процессе, в-четвертых, у нас должны быть права доступа к файлу и т.д. Предусловия и постусловия основывают контракт между модулем и всеми, кто его вызывает. Тестирование-по-контракту основывается на философии проектирования-по-контракту. При использовании данного подхода мы создаем только те тест-кейсы, которые удовлетворяют нашим предусловиям. Например, мы не будем тестировать модуль "openFile", если файл не существует. Причина проста. Если файл не существует, то openFile не обещает работать. Если не существует требования работоспособности в определенных условиях, то нет необходимости проводить тестирование в этих условиях. Для дополнительной информации Icon Для дополнительной информации о проектировании-по-контракту смотрите книгу "Объектно-ориентированное конструирование программных систем" Бертрана Майера. В этот момент тестировщики обычно возражают. Да, они согласны, что модуль не претендует на работу в этом случае, но что делать, если предусловия нарушаются в процессе разработки? Что делать системе? Должны ли мы получить сообщение об ошибке на экране или дымящуюся воронку на месте нашей компании? Другим подходом к проектированию является оборонительное проектирование. В этом случае модуль предназначен для приема любого входного значения. Если выполнены обычные предусловия, то модуль достигнет своих обычных постусловий. Если обычные предварительные условия не выполняются, то модуль сообщит вызывающему, возвратив код ошибки или бросив исключение (в зависимости от используемого языка программирования). На самом деле, это уведомление является еще одним из постусловий модуля. На основе этого подхода мы могли бы определить оборонительное тестирование: подход, который анализирует как обычные, так и необычные предварительные условия. Понимание Icon На одном из моих уроков студент, давайте назовем его Фред, сказал, что его не беспокоит, какой подход к проектированию был использован, т.к. он собирался всегда использовать оборонительное тестирование. Когда я спросил: "Почему?", он ответил: "Если модуль не будет работать, то кто будет виноват - вон те ответственные или тестировщики?" Как это относится к тестированию классов эквивалентности? Нужно ли нам делать проверку с такими входными значениями, как -42, FRED и &$#! @? Если мы используем проектирование-по-контракту и тестирование-по-контракту, то ответ "Нет". Если мы используем оборонительное проектирование и, поэтому, оборонительное тестирование, то ответ "Да". Спросите ваших проектировщиков, какой подход они используют. Если их ответом будет «контрактный» либо «оборонительный», то вы знаете, какой стиль тестирования использовать. Если они ответят "Хм?", то это значит, что они не думают о том, как взаимодействуют модули. Они не думают о предусловиях и постусловиях контрактов. Вам стоит ожидать, что интеграционное тестирование будет главным источником дефектов, будет более сложным и потребует больше времени, чем ожидалось. 19 |