Учебник по тестированию. Guide to Software Test Design
 Скачать 2.51 Mb.
|
|
Перевод книги Ли Копланда “A Practitioner's Guide to Software Test Design” Автор перевода: Уфимцева Галина Глава 1. Процесс Тестирования Тестирование Распространенные проблемы Тестовые сценарии Входные данные Результаты Порядок выполнения Виды тестирования Уровни тестирования Невозможность тестирования всего Резюме Практика Глава 2. Учебные сценарии Для чего нужны учебные сценарии? Браун и Дональдсон Регистрационная система Государственного университета Секция I. Методы тестирования черного ящика Определение Применимость Недостатки Преимущества Литература Глава 3. Тестирование классов эквивалентности Введение Методика Примеры Пример 1 Пример 2 Пример 3 Пример 4 Применения и ограничения Резюме Практика Литература Глава 4. Тестирование граничных значений Введение Методика Примеры Пример 1 Пример 2 Применения и ограничения Резюме Практика Литература Глава 5. Тестирование таблиц решений Введение Методика Примеры 2 Пример 1 Пример 2 Применение и ограничения Резюме Практика Литература Глава 6. Попарное тестирование Введение Методика Ортогональные массивы Использование ортогональных массивов Алгоритм Allpairs Заключительные комментарии Применения и ограничения Резюме Практика Литература Глава 7. Тестирование состояний и переходов Введение Методика Диаграммы состояний и переходов Таблицы состояний и переходов Создание тест-кейсов Применение и ограничения Резюме Практика Ссылки Глава 8. Domain-тестирование Введение Методика Пример Применения и ограничения Резюме Практика Литература Глава 9. Тестирование вариантов использования Введение Методика Пример Применение и ограничения Резюме Практика Литература Секция II. Методы тестирования белого ящика Определение Применимость Недостатки Преимущества 3 Глава 10. Тестирование потока управления Введение Методика Граф потока управления Уровни тестового покрытия Уровень 1 Уровень 0 Уровень 2 Уровень 3 Уровень 4 Уровень 5 Уровень 7 Уровень 6 Структурное тестирование / Основной маршрут тестирования Пример Применения и ограничения Резюме Практика Литература Глава 11. Тестирование потока данных Введение Методика Статическое тестирование потока данных Динамическое тестирование потока данных Применения и ограничения Резюме Практика Литература 4 Глава 1. Процесс Тестирования Тестирование Что такое тестирование? Хотя и написано много определений, по своей сути тестирование — это процесс сравнения того "что есть" с тем, "как должно быть". Наиболее формальное определение дается в стандарте IEEE 610.12-1990, “Глоссарий стандартов IEEE по терминологии разработок программного обеспечения”, который определяет “тестирование” как: “Процесс наблюдения за выполнением программы в специальных условиях и вынесения на этой основе оценки каких-либо ее аспектов”. “Специальные условия”, упоминаемые в этом определении, воплощены в тестовые сценарии, которые и являются темой этой книги. По своей сути тестирование — это процесс сравнения того "что есть" с тем, "как должно быть". Рик Крэйг и Стефан Яскил предлагают более расширенное определение тестирования программ в их книге “Систематическое тестирование программного обеспечения”. “Тестирование - это параллельный жизненный цикл процесса разработки, использования и поддержки средств тестирования для того, чтобы измерять и улучшать качество тестируемой программы”. Тестирование включает планирование, анализ и дизайн, что приводит к созданию тестовых сценариев в дополнение к фокусировке IEEE на выполнении тестов. У разных организаций и разных людей разнообразные представления о целях тестирования программного обеспечения. Борис Бейзер описывает следующие пять уровней законченности тестирования (он называет их фазами, но мы знаем, что более корректен термин “уровень”, которых обычно пять): ● Уровень 0. Нет разницы между тестированием и отладкой. Тестирование не имеет никакой другой цели, кроме помощи при отладке ○ Дефекты могут быть обнаружены, но усилия для их нахождения не оформлены. ● Уровень 1. Целью тестирования является демонстрация того, что программа работает ○ Такой подход, который начинается с предпосылки, что программа работает верно (в основном), может ослепить нас при поиске дефектов. Глинфорд Майерс писал, что при таком проведении тестирования могут подсознательно выбираться тестовые сценарии, которые не должны провалиться. Не будут созданы “дьявольские” тесты, необходимые для поиска глубоко скрытых дефектов. ● Уровень 2. Целью тестирования является демонстрация того, что программа не работает ○ Это совсем другое мышление. Предполагается, что программа не работает, и задача тестировщика - найти ее дефекты. При таком подходе будут сознательно выбираться такие тестовые сценарии, которые смогут оценить уголки и трещины системы, её границы и краевые значения, используя дьявольски построенные тестовые сценарии. ● Уровень 3. Целью тестирования является не доказательство чего-либо, а уменьшение риска того, что программа не будет работать, до приемлемой величины ○ В то время как можно признать систему некорректной при помощи всего лишь одного тестового сценария, невозможно доказать, что она верна. Потребуются тесты со всевозможными валидными и невалидными сочетаниями во входных данных. Целью 5 является понимание качества программы при наличии в ней дефектов с предоставлением программистам информации о недостатках программы и обеспечение управления оценкой негативного воздействия на организацию в случае, если система будет поставлена клиентам в текущем состоянии. ● Уровень 4. Тестирование - это не игра. Это умственная дисциплина, результатом которой является программа с низким уровнем риска без больших усилий в тестировании ○ На этом заключительном уровне мы с самого начала концентрируемся на создании более проверяемых программ. Сюда входят просмотр и контроль требований, проектирование и разработка. Вдобавок это означает написание кода, включающего в себя такие средства, которые тестировщик легко сможет использовать для получения данных во время работы программы. Более того, это означает написание самодиагностируемого кода, который сообщит об ошибках быстрее, чем тестировщики их обнаружат. Распространенные проблемы Когда я спрашиваю своих студентов о проблемах, с которыми они сталкиваются в тестировании, то они, как правило, отвечают: ● не достаточно времени для проверки должным образом; ● слишком много входных комбинаций для тестирования; ● не хватает времени для полного тестирования; ● сложности в определении ожидаемых результатов для каждого теста; ● отсутствующие или быстро изменяющиеся требования; ● недостаточно времени для тщательного тестирования; ● отсутствие обучения в процессе тестирования; ● отсутствует инструмент для поддержки; ● менеджмент либо не понимает тестирование, либо (по-видимому) не заботится о качестве; ● не хватает времени. В этой книге нет "волшебной эльфийской пыльцы", которую можно использовать для создания дополнительного времени, лучших требований или более просвещенного менеджмента. Однако, она содержит методики, которые сделают вас более квалифицированными и эффективными в тестировании, помогая выбрать и построить тестовые сценарии, которые обнаружат существенно больше дефектов, чем было у вас раньше, используя меньше ресурсов. Тестовые сценарии Для того, чтобы быть наиболее квалифицированными и эффективными, тестовые сценарии должны быть спроектированы, а не придуманы на скорую руку. Слово "дизайн" имеет много определений: 1. задумать или моделировать в уме; изобретать: изобрести хорошую причину для посещения звездной конференции по тестированию . Сформулировать план; разрабатывать: разработать маркетинговую стратегию для нового продукта 2. Методично планировать, обычно в задокументированной форме: планировать строение; планировать тестовый сценарий ; 3. Создавать или придумывать для конкретной цели или эффекта: игра создана для привлечения всех возрастов 6 4. Для достижения цели или результата; намереваться. 5. Создавать или исполнять художественный или высококвалифицированный метод. Для того, чтобы быть наиболее профессиональными и эффективными, тестовые сценарии должны быть спроектированы, а не придуманы на скорую руку. Каждое из этих определений относится к разработке хорошего тестового сценария. Что касается проектирования тестов, Роджер Прессман писал: "Проектирование тестов для программного обеспечения и других технических продуктов может быть таким же манящим, как и первоначальное проектирование самого продукта. Тем не менее... программисты часто заботятся о тестировании с запозданием, разрабатывая тестовые сценарии которые "вроде правильные", имея при этом мало уверенности в том, что они являются полными. Помня о целях тестирования, мы должны разработать такие тесты, которые будут иметь наивысшую вероятность нахождения большинства ошибок при минимальном количестве времени и усилий". Хорошо спроектированный тест-кейс состоит из трех частей: ● входные данные, ● результаты; ● порядок выполнения. Тест-кейс состоит из входных данных, результатов и порядка выполнения. Входные данные В качестве входных данных обычно рассматриваются данные, введенные с клавиатуры. Несмотря на то, что они являются важным источником входных данных для системы, данные также могут поступать и из других источников - данные от взаимодействующих устройств; данные, считанные из файлов или баз данных; состояние, в котором система находится в момент поступления данных и окружение, в котором эта система выполняется. Результаты Результаты так же разнообразны. Часто результаты представляются всего лишь данными, отображаемыми на компьютерном экране. Кроме того, данные могут быть отправлены во взаимодействующие системы и на внешние устройства. Данные могут быть записаны в файлы или базы данных. При выполнении системы состояние или окружение могут быть изменены. Все уместные входные значения и результаты являются важными компонентами тестового сценария. Определение ожидаемых результатов при проектировании тестов является функцией "оракула". Оракулом является любая программа, процесс или данные, которые тестировщик предоставляет вместе с ожидаемым результатом теста. Бейзер перечисляет следующие пять типов оракулов: ● Детские оракулы - просто запустите программу и посмотрите, что появится. Если это выглядит правильно, это должно быть верным. ● Наборы регрессионных тестов - запустите программу и сравните результат с результатами таких же тестов, запущенных на предыдущей версии этой программы. ● Признанные данные - запустите программу и сравните результаты с образцом, таким как таблица, формула или другое допустимое описание действительного результата. 7 ● Приобретенные наборы тестов - запустите программу со стандартизированным набором тестов, который был создан ранее и проверен. Такие программы, как компиляторы, веб-браузеры, и SQL-процессоры (язык структурированных запросов) часто проверяются такими наборами. ● Существующая программа - запустите программу и сравните результат с другой версией этой же программы. Порядок выполнения Существуют два стиля оформления тестового сценария, касающиеся порядка проведения теста. 1. Последовательные тестовые сценарии - тестовые случаи могут основываться друг на друге. Например, первый тестовый сценарий использует конкретное свойство программы, а затем покидает систему в таком состоянии, чтобы мог быть выполнен второй тестовый сценарий. При тестировании баз данных рассматриваются такие тестовые сценарии: 1. Создать запись 2. Прочитать запись 3. Обновить запись 4. Прочитать запись 5. Удалить запись 6. Прочитать удаленную запись 2. Каждый из этих тестов можно построить на предыдущих тестах. Преимуществом является то, что каждый тест, как правило, меньше и проще. Недостатком является то, что если провалится один тест, то последующие тесты могут стать недействительными. 3. Независимые тестовые сценарии - каждый тестовый сценарий является полностью автономным. Тесты не зависят друг от друга и не требуют, чтобы другие тесты были выполнены успешно. Преимуществом является то, что любое количество тестов может быть выполнено в любом порядке. Недостатком является то, что каждый тест, как правило, больше и сложнее, и, следовательно, сложнее для проектирования, создания и поддержки. Виды тестирования Зачастую тестирование разделяется на тестирование черного ящика и тестирование белого ящика. Тестирование черного ящика представляет собой стратегию, в которой тестирование основано исключительно на требованиях и спецификациях. В отличие от своего дополнения, тестирования белого ящика, тестирование черного ящика не требует знания внутренних путей, структуры или реализации проверяемой программы. Тестирование белого ящика представляет собой стратегию, в которой тестирование основано на внутренних путях, структуре и реализации проверяемой программы. В отличие от дополняющего тестирования черного ящика, тестирование белого ящика обычно требует детальных знаний в области программирования. Дополнительным видом тестирования является тестирование серого ящика. При таком подходе мы заглядываем в проверяемый «ящик» настолько, чтобы понять, как он был реализован. Потом мы закрываем коробку и используем наши знания для того, чтобы выбрать наиболее эффективные тесты черного ящика. 8 Уровни тестирования Обычно тестирование, и, следовательно, проектирование тестового сценария, осуществляется на четырех различных уровнях: ● Модульное тестирование - единицей тестирования является "наименьший" кусочек программы, которую создает разработчик. Как правило, это работа одного программиста, которая хранится в одном файле на диске. Разные языки программирования содержат разные модули: в C++ и Java модулем является класс; в C модулем является функция; в менее структурированных языках, таких как Basic и COBOL, модулем может быть вся программа. ● Интеграционное тестирование - мы собираем модули вместе в подсистему и, в заключение, в систему. Вполне возможно, что модули прекрасно функционируют изолированно, но сломаются, когда будут объединены. Классическим примером является следующая программа на C и ее дочерняя функция: /* основная программа */ void oops(int); int main(){ oops(42); /* вызывается функция oops и передается целое число*/ return 0; } /* функция oops (в отдельном файле) */ #include } Если эти модули были протестированы индивидуально, то каждый из них, казалось бы, функционировал верно. В этом случае дефект возникает только тогда, когда два модуля объединены. Основная программа передает функции oops целое число, но oops ожидает действительное число и в результате получается беда. Жизненно важно выполнять интеграционное тестирование, пока процесс интеграции продолжается. ● Системное тестирование . Система состоит из всего программного обеспечения (и, возможно, включает устройства, руководство пользователя, обучающие материалы и т.д.), которое составляет продукт, поставленный клиенту. Системное тестирование фокусируется на дефектах, которые появляются на этом, высшем уровне интеграции. Обычно системное тестирование включает множество видов тестирования: функциональное, юзабилити-тестирование, тестирование безопасности, тестирование интернациолизации и локализации, тестирование надежности и доступности, тестирование производительности и эффективности, тестирование резервных копий и их восстановления, тестирование переносимости и многое другое. Эта книга разбирает только функциональное тестирование. Несмотря на то, что другие типы тестирования важны, они находятся за пределами этой книги. ● Приемочное тестирование - определяется как тестирование, которое при удачном завершении приведет к принятию клиентом программы и передаче нам его денег. С точки зрения клиента, они 9 обычно желают наиболее исчерпывающее приемочное тестирование (эквивалент уровня системного тестирования). С точки зрения поставщика, мы обычно желаем минимально возможный уровень тестирования, который приведет к передаче денег. Типичные стратегические вопросы, которые должны быть заданы перед приемочным тестированием: Кто определяет уровень приемочного тестирования? Кто создает тестовые сценарии? Кто выполняет тесты? Каков критерий прохождения/провала приемочного теста? Когда и как мы получим оплату? Классическими уровнями тестирования являются модульное, интеграционное, системное и приемочное тестирование. Не все системы поддаются использованию этих уровней. Эти уровни предполагают, что существует большой период времени между разработкой модулей и интеграцией их в подсистемы и в системы. В web-разработке обычно возможно развитие от концепта до разработки и готового продукта за несколько часов. В этом случае модульное, интеграционное и системное тестирование не имеют большого смысла. Многие веб-тестировщики используют альтернативный набор уровней: ● качество кода; ● функциональность; ● удобство использования; ● производительность; ● безопасность. |