ISTQB_CTFL_Syllabus_2018-RU_3 — копия. Программа обучения Базового уровня Версия 2018 International Software Testing Qualifications Board
 Скачать 1.3 Mb.
|
|
Свободное рецензирование При свободном рецензировании предоставляется небольшое или вообще отсутствует руководство по выполнению. Рецензенты часто последовательно читают продукт, идентифицируя и документируя проблемы, с которыми они сталкиваются. Свободное рецензирование – это часто используемый метод, требующий небольшой подготовки. Эта техника в значительной степени зависит от навыков рецензента и может привести к повторяющимся вопросам у разных рецензентов. Рецензирование, основанное на чек-листах Рецензирование, основанное на чек-листах, представляет собой систематический метод, при котором рецензенты обнаруживают проблемы, основанные на чек-листах, распространяемых в начале рассмотрения (например, ведущим). Чек-лист состоит из набора вопросов, основанных на потенциальных дефектах, определенных исходя их опыта. Чек-листы должны соответствовать типу рассматриваемого рабочего продукта, их следует регулярно обновлять для охвата проблем, пропущенных в предыдущих рецензированиях. Основным преимуществом методики, основанной на чек-листах, является систематизированное покрытие характерных типов дефектов. Нужно следить за тем, чтобы искать дефекты не только по чек-листу, но и за его пределами. Сертифицированный тестировщик Программа обучения базового уровня International Software Testing Qualifications Board Версия 2018 Страница 55 of 94 24 февраля 2019 © International Software Testing Qualifications Board Рецензирование по сценарию и сухие прогоны В рецензировании по сценариям рецензентам предоставляются структурированные рекомендации о том, как нужно рассматривать рабочий продукт. Сценарный подход поддерживает рецензентов при выполнении сухих прогонов рабочего продукта, основанных на ожидаемом использовании продукта (если продукт задокументирован в подходящем формате, например, в формате сценариев использования системы). Эти сценарии, в отличие от чек- листов, дают рецензентам более четкое представление о том, как идентифицировать специфические типы дефектов. Как и с рецензированием по чек-листам, чтобы не пропустить другие типы дефектов (например, отсутствующие функции), рецензенты не должны ограничиваться документированным сценарием. Ролевое рецензирование Ролевое рецензирование – это метод, в котором рецензенты оценивают рабочий продукт с точки зрения отдельных ролей заинтересованных сторон. Типичные роли – это конкретные типы конечных пользователей (опытные, неопытные, взрослый, ребенок и т.д.), а также конкретные роли в организации (администратор, системный администратор, тестировщик производительности и т.д.). Рецензирование на основе точки зрения При анализе на основе точки зрения, аналогичном ролевому анализу, рецензенты берут на себя различные точки зрения заинтересованных сторон при индивидуальном рассмотрении. Типичные точки зрения заинтересованных сторон включают в себя конечного пользователя, маркетолога, дизайнера, тестировщика или оператора. Использование различных точек зрения заинтересованных сторон приводит к большей глубине при индивидуальном рассмотрении с меньшим дублированием вопросов среди рецензентов. Кроме того, чтение на основе точки зрения требует от рецензентов поиска пути применения рабочего продукта, что позволит разработать нужный продукт. Например, тестировщик пытается сгенерировать приемочные испытания на основе точки зрения по требованиям, чтобы узнать, достаточно ли информации по продукту было включено. Кроме того, при чтении, основанном на точке зрения, ожидается использование чек-листов. Эмпирические исследования показали, что рецензирование на основе точки зрения является наиболее эффективным общим методом рассмотрения требований к техническим продуктам. Ключевым фактором успеха является основанное на рисках рассмотрение и взвешивание различных точек зрения заинтересованных сторон. См. [Shul 2000] для получения подробной информации о рецензировании, основанном на точке зрения и [Sauer 2000] для эффективности различных типов рецензирования. 3.2.5 Факторы успеха рецензирования Чтобы получить успешное рецензирование, должны использоваться соответствующие типы и методы рецензирования. Кроме того, существует ряд других факторов, которые влияют на результаты рецензирования. Организационные факторы успеха включают: Каждое рецензирование имеет четкие цели, определенные при планировании рецензирования, и используемые как измеримые критерии выхода Применяются типы рецензирования, которые подходят для типа и уровня программных продуктов и участников Любые используемые методы рецензирования, такие как анализ на основе чек-листов или на основе ролей, пригодны для эффективной идентификации дефектов в рабочем продукте, подлежащем рецензированию Сертифицированный тестировщик Программа обучения базового уровня International Software Testing Qualifications Board Версия 2018 Страница 56 of 94 24 февраля 2019 © International Software Testing Qualifications Board Любые чек-листы учитывают основные риски и обновляются Большие документы пишутся и пересматриваются небольшими частями, поэтому контроль качества осуществляется путем предоставления авторам отзывов о дефектах на более ранней стадии и более часто У участников есть достаточно времени для подготовки Рецензирование запланировано с соответствующим уведомлением Менеджмент поддерживает процессы обзоров (например, путем предоставления достаточного времени для анализа в рамках проекта) Связанные с людьми факторы успеха обзоров: Для достижения целей обзора вовлечены нужные люди, например, с разными наборами навыков и точками зрения, использующие документ в качестве начала работы Тестировщики рассматриваются как ценные рецензенты, вносящие свой вклад в обзор и узнающие о работе продукта, что позволяет составлять более эффективные тесты на более ранних стадиях Участники уделяют достаточно времени и внимания деталям Рецензирование проводится на небольших частях продукта, рецензенты не теряют концентрацию во время индивидуального рецензирования и/или во время обзорного собрания (когда проводится) Найденные дефекты признаются, оцениваются и обрабатываются объективно Совещание эффективно управляется, поэтому участники считают его полезным использованием своего времени Рецензирование проводится в атмосфере доверия; результат не используется для оценки участников Участники избегают поведения, указывающего на скуку, раздражение или враждебность к другим участникам Обеспечивается адекватное обучение, особенно для более формальных типов рецензирования, таких как инспекция Повышается культура обучения и совершенствуются процессы См. [Glib 1993], [Wiegers 2002] и [van Veenendaal 2004] для получения дополнительной информации об успешном рецензировании. Сертифицированный тестировщик Программа обучения базового уровня International Software Testing Qualifications Board Версия 2018 Страница 57 of 94 24 февраля 2019 © International Software Testing Qualifications Board 4. Методы проектирования тестов – 330 мин Ключевые слова разработка тестов методом черного ящика, анализ граничных значений, тестирование на основе чек-листов, покрытие, покрытие условий, тестирование с помощью таблицы альтернатив, предположение об ошибках, эквивалентное разбиение, метод проектирования тестов на основе опыта, исследовательское тестирование, тестирование таблицы переходов, покрытие операторов, метод проектирования тестов, тестирование по сценариям использования, разработка тестов методом белого ящика Цели обучения для главы «Методы проектирования тестов» 4.1 Категории методов проектирования тестов FL-4.1.1 (K 2) Рассказать о характеристиках, сходствах и различиях между тестированием методом черного ящика, тестированием методом белого ящика и тестированием на основе опыта. 4.2 Тестирование методом черного ящика FL-4.2.1 (K 3) Применить метод эквивалентного разбиения для создания тестовых сценариев на основе заданных требований. FL-4.2.2 (K 3) Применить метод анализа граничных значений для создания тестовых сценариев на основе заданных требований. FL-4.2.3 (K 3) Применить метод таблицы альтернатив для создания тестовых сценариев на основе заданных требований. FL-4.2.4 (K 3) Применить метод тестирования таблицы переходов для создания тестовых сценариев на основе заданных требований. FL-4.2.5 (K 2) Объяснить, как создать тестовые сценарии из сценария использования. 4.3 Тестирование методом белого ящика FL-4.3.1 (K 2) Объяснить смысл покрытия операторов FL-4.3.2 (K 2) Объяснить смысл покрытия условий FL-4.3.3 (K 2) Объяснить пользу покрытия условий и операторов 4.4 Тестирование на основе опыта FL-4.4.1 (K 2) Объяснить смысл предположения об ошибках FL-4.4.2 (K 2) Объяснить смысл исследовательского тестирования FL-4.4.3 (K 2) Объяснить смысл тестирования на основе чек-листов Сертифицированный тестировщик Программа обучения базового уровня International Software Testing Qualifications Board Версия 2018 Страница 58 of 94 24 февраля 2019 © International Software Testing Qualifications Board 4.1 Категории методов проектирования тестов Цель метода проектирования тестов, включая перечисленные ниже, заключается в определении тестовых условий, тестовых сценариев и тестовых данных. 4.1.1 Выбор метода проектирования тестов Выбор конкретного метода проектирования тестов зависит от множества факторов, включая: Тип системы или компонента Сложность системы или компонента Нормативные документы Требования пользователей или контракта Уровни рисков Типы рисков Задачи тестирования Доступную документацию Знания и опыт тестировщиков Доступные инструменты Ресурсы времени и бюджет Жизненный цикл разработки Ожидаемое использование системы Прошлый опыт использования методов проектирования тестов для компонента или системы Ожидаемые типы дефектов компонента или системы Некоторые методы применимы к конкретным ситуациям и уровням тестирования, другие применимы на всех уровнях. Обычно, тестировщики используют комбинации различных методов в процессе создания тестовых сценариев для достижения наилучших результатов. Применение тех или иных методов на этапе анализа, дизайна и реализации тестов может варьироваться от неформального (минимум либо полное отсутствие документации) до строго формального. Уровень формальности зависит от контекста, включая зрелость процессов разработки и тестирования, временных ограничений, требований безопасности и требований регуляторов, знания и опыта вовлеченных людей, а также используемой модели жизненного цикла. 4.1.2 Категории методов проектирования тестов и их характеристики Здесь и далее методы проектирования тестов делятся на методы черного ящика, методы белого ящика и методы, основанные на опыте. Методы черного ящика (поведенческие, или методы, основанные на поведении) основываются на анализе соответствующего базиса тестирования (формальных требований, спецификаций, сценариев использования, пользовательских историй или бизнес-процессов). Эти методы применимы как для функционального, так и для нефункционального тестирования. Методы черного ящика сосредотачиваются на связи входных данных и выходных результатов объекта тестирования, а не на его внутренней структуре. Сертифицированный тестировщик Программа обучения базового уровня International Software Testing Qualifications Board Версия 2018 Страница 59 of 94 24 февраля 2019 © International Software Testing Qualifications Board Методы белого ящика (структурные, или методы, основанные на структуре) основаны на анализе архитектуры, детального проектирования, внутренней структуры или кода компонента либо системы. В отличие от методов черного ящика методы белого ящика сосредотачиваются на структуре и обработке внутри объекта тестирования. Методы, основанные на опыте, используют опыт разработчиков, тестировщиков и пользователей для проектирования, реализации и выполнения тестов. Их часто совмещают с методами черного и белого ящиков. Общие характеристики методов черного ящика: Тестовые условия, тестовые сценарии и тестовые данные получаются из базиса тестирования, который может включать в себя требования, спецификации, сценарии использования и пользовательские истории Тестовые сценарии могут использоваться для определения несоответствий и отклонений между требованиями и реализацией Измерение покрытия основано на элементах базиса тестирования и методе проектирования, применяемом к базису тестирования Общие характеристики методов белого ящика: Тестовые условия, тестовые сценарии и тестовые данные получаются из базиса тестирования, который может включать в себя код, архитектуру, детальную архитектуру или любой другой источник информации о структуре программного обеспечения Измерение покрытия основано на элементах структуры (коде, интерфейсах и т.д.) Спецификации используются как источник дополнительной информации для определения ожидаемых результатов тестовых сценариев Общие характеристики методов, основанных на опыте: Тестовые условия, тестовые сценарии и тестовые данные получаются из базиса тестирования, который может включать в себя знания и опыт тестировщиков, разработчиков, пользователей и других заинтересованных лиц Эти знания и опыт включают в себя возможное использование ПО, его окружение, возможные дефекты и их распределение. Международный стандарт ИСО (ISO/IEC/IEEE 29119-4) содержит описание методов проектирования тестов и соответствующие им методы измерения покрытия (см. также [Craig 2002] и [Copeland 2004] для описания дополнительных методов). 4.2 Методы черного ящика 4.2.1 Эквивалентное разбиение Эквивалентное разбиение делит данные на группы (классы эквивалентности), которые, как предполагается, обрабатываются схожим образом [Kaner 2013], [Jorgensen 2014]. Области эквивалентности могут быть как для правильных, или позитивных, так и неправильных, или негативных, значений. Позитивные значения – это значения, которые должны быть приняты. Класс, содержащий позитивные значения, называется «действительный класс эквивалентности». Негативные значения – значения, которые должны быть отвергнуты. Класс, содержащий негативные значения, называется «недействительный класс эквивалентности». Сертифицированный тестировщик Программа обучения базового уровня International Software Testing Qualifications Board Версия 2018 Страница 60 of 94 24 февраля 2019 © International Software Testing Qualifications Board Классы могут быть определены для любых данных, относящихся к объекту тестирования, включая: входные данные, выходные данные, внутренние данные, данные, связанные со временем (например, до или после события), интерфейсные параметры (например, в случае интеграционного тестирования компонентов). Любой класс может быть при необходимости разделен на подклассы Каждое значение должно принадлежать только одному классу эквивалентности Во избежание маскирования дефектов негативные классы эквивалентности в тестовых сценариях следует использовать по отдельности, то есть избегать комбинаций одних негативных классов с другими. Дефекты могут быть маскированы, если при наличии нескольких дефектов обнаруживается только один из них. Для достижения 100% покрытия с помощью этого метода, тестовые сценарии должны покрывать все позитивные и негативные классы, проверяя хотя бы одно значение из каждого класса. Покрытие вычисляется как отношение количества тестируемых классов к общему числу классов. Метод эквивалентного разбиения применим на всех уровнях тестирования. 4.2.2 Анализ граничных значений Метод анализа граничных значений является продолжением метода эквивалентного разбиения, но может быть применим, только если классы состоят из упорядоченных числовых значений. Максимальное и минимальное значение класса являются его границами [Beizer 1990]. Для примера, предположим, что некоторое поле ввода принимает положительное целое число от 0 до 9; ввод осуществляется через клавиатуру, поэтому нечисловые входные значения исключены. Допустимы значения от 1 до 5 включительно. Таким образом, можно выделить три области эквивалентности: негативная (слишком маленькие), позитивная, негативная (слишком большие). Для позитивной области эквивалентности значения 1 и 5 будут граничными. Для области с негативными большими значениями границами будут значения 6 и 9. Для области с негативными малыми значениями будет только одна граница – 0, поскольку эта область состоит из одного элемента. В рассмотренном выше примере мы можем определить по два граничных значения на каждую из границ. Граница между негативными малыми и позитивными значениями дает нам тестовые значения 0 и 1. Граница между позитивными и негативными большими значениями дает нам тестовые значения 5 и 6. Вариация данного метода определяет три граничных значения на каждую из границ: значения перед, на и сразу после границы. Для рассматриваемого примера применение этого метода даст следующие тестовые значения: для нижней границы – 0,1,2; для верхней границы – 4,5,6 [Jorgensen 2014]. Некорректное поведение более вероятно на границах класса, чем внутри класса. Важно помнить, что специфицированные и реализованные границы могут быть смещены вверх или вниз относительно истинных значений, они могут быть пропущены или дополнены новыми границами. Анализ и тестирование граничных значений может обнаружить большинство подобных дефектов, вынуждая программное обеспечение демонстрировать поведение, относящееся к области эквивалентности, отличной от той, к которой должна относиться граничная точка. Анализ граничных значений может использоваться на любом уровне тестирования. Данный метод применяется при тестировании требований, в которых присутствуют диапазоны значений (включая даты и время). Покрытие вычисляется как отношение числа тестируемых граничных значений к общему числу граничных значений и чаще всего выражается в процентах. Сертифицированный тестировщик Программа обучения базового уровня International Software Testing Qualifications Board Версия 2018 Страница 61 of 94 24 февраля 2019 © International Software Testing Qualifications Board 4.2.3 Тестирование с помощью таблицы альтернатив Комбинаторные методы полезны при тестировании требований, содержащих условия, которые дают разные результаты в зависимости от комбинаций. Одним из таких методов является тестирование с помощью таблицы альтернатив. Таблицы альтернатив – хороший способ записи сложных бизнес-правил, которые должны быть реализованы в системе. В процессе создания таблицы, тестировщик определяет условия (входы) и результирующие действия системы (выходы). Пары условий и действий образуют строки таблицы, при этом условия указываются сверху, а действия – снизу. Каждый столбец представляет собой бизнес-правило с уникальной комбинацией условий и действий, связанных с этим правилом. Значения условий часто отображаются в виде логических (истина или ложь) или дискретных (красный, синий, зеленый) значений, но могут быть также в виде чисел или числовых диапазонов. В одной таблице могут сочетаться значения разных типов. Обозначения, используемые для таблиц альтернатив: Условия: Y означает, что условие истинно (используется также обозначение Т или 1) N означает, что условие ложно (используется также обозначение F или 0) – означает, что значение условия может быть любым (используется также обозначение N/A) Действия: Х означает, что действие должно быть выполнено (используется также обозначение Y, Т или 1) Пустое поле означает, что действие не должно выполняться (используется также обозначение N, F или 0) Полная таблица альтернатив содержит по столбцу на каждую комбинацию условий. Таблицу можно сократить, убрав столбцы, которые содержат несуществующие комбинации или комбинации, не влияющие на результат. Более подробная информация размещена в программе подготовки продвинутого уровня (ISTQB-ATA Продвинутый уровень, Тест-аналитик). Стандарт покрытия для таблиц альтернатив подразумевает наличие хотя бы одного теста для каждого столбца таблицы. Обычно это подразумевает покрытие всех комбинаций условий. Покрытие измеряется как отношение количества правил, проверенных хотя бы одним тестом, к общему числу правил, выраженное в процентах. Преимущество метода заключается в том, что он выявляет комбинации условий, которые могли быть не проверены при тестировании. Метод помогает определить несоответствия в требованиях, может быть применен во всех ситуациях и на любом уровне, где поведение программного обеспечения зависит от комбинации условий. 4.2.4 Тестирование с помощью таблицы переходов В зависимости от прошлых условий и состояния система может вести себя по-разному. Описать прошлое системы можно с помощью концепции состояний. Диаграмма состояний и переходов показывает начальное и конечное состояния системы, а также описывает переходы между состояниями. Каждый переход вызывается событием (например, вводом данных пользователем). Если одно и то же событие может привести к разным переходам, выбор перехода может задаваться контрольным условием. Смена состояния может завершаться выполнением какого-либо действия (вывод результатов или сообщения об ошибке и т.д.). Сертифицированный тестировщик Программа обучения базового уровня International Software Testing Qualifications Board Версия 2018 Страница 62 of 94 24 февраля 2019 © International Software Testing Qualifications Board Таблица переходов представляет собой все возможные комбинации начальных и конечных состояний, включая действительные и недействительные переходы, инициирующие события, защитные условия и результирующие действия. Диаграммы состояний и переходов обычно, показывают только действительные переходы и исключают недействительные переходы. Тесты создаются для покрытия типичной последовательности состояний, покрытия каждого возможного состояния, покрытия каждого возможного перехода, проверки специфических последовательностей переходов, или для проверки недействительных переходов. Тестирование с помощью таблицы переходов наиболее распространено в сфере встроенного ПО и при тестировании программных меню. Метод также подходит для моделирования бизнес- сценариев, имеющих конкретные состояния, или для тестирования переходов по экранным формам. Концепция состояний абстрактна, она может отражать несколько строк кода или целый бизнес-процесс. Покрытие измеряется как отношение числа протестированных состояний или переходов к общему числу состояний или переходов в объекте тестирования, выраженное в процентах. Более подробная информация размещена в программе подготовки продвинутого уровня (ISTQB-ATA Продвинутый уровень, Тест-аналитик). 4.2.5 Тестирование с помощью сценариев использования Тесты можно разработать на основе сценариев использования, которые представляют собой способ описания взаимодействий с программными объектами. В сценариях использования всегда присутствуют участники (пользователи, внешние устройства и компоненты) и субъекты (компоненты или системы, к которым применяется сценарий использования). Каждый сценарий использования описывает поведение субъекта при взаимодействии с участником (UML 2.5.1 2017). Сценарий использования может быть описан взаимодействиями и активностями, предусловиями и постусловиями или естественным языком, если это возможно. Взаимодействия между участниками и субъектом могут приводить к изменению состояния субъекта; они могут изображаться графически, с помощью диаграмм или моделей бизнес-процессов. Сценарий использования может отражать различные варианты поведения, включая исключительные ситуации и обработку ошибок (реакцию системы и восстановление из-за ошибок программирования, приложений и связи, например, в результате чего появляется сообщение об ошибке). Тесты разрабатываются с целью проверки различных вариантов поведения (базового, исключительного, альтернативного, обработки ошибок). Покрытие может выражаться как процент протестированных вариантов поведения к общему числу вариантов. Более подробная информация о покрытии размещена в программе подготовки продвинутого уровня (ISTQB-ATA Продвинутый уровень, Тест-аналитик). 4.3 Методы белого ящика Тестирование белого ящика основывается на внутренней структуре объекта тестирования. Методы могут применяться на всех этапах, однако, методы, рассмотренные ниже, чаще всего используются в модульном тестировании. Существуют и другие методы, используемые в тестировании критичных систем и обеспечивающие более сильное покрытие, но здесь они не рассматриваются. Более подробная информация об этих методах размещена в программе подготовки продвинутого уровня (ISTQB Продвинутый уровень, Технический тест-аналитик). 4.3.1 Тестирование и покрытие операторов Сертифицированный тестировщик Программа обучения базового уровня International Software Testing Qualifications Board Версия 2018 Страница 63 of 94 24 февраля 2019 © International Software Testing Qualifications Board Тестирование операторов направлено на проверку исполняемых операторов в коде. Покрытие вычисляется как отношение количества операторов, выполненных тестом, к общему числу операторов в тестируемом коде. 4.3.2 Тестирование и покрытие условий Тестирование условий направлено на проверку логических условий в коде, а также кода, выполняемого в зависимости от исхода условия. Для этого тесты следуют потокам управления, которые выходят из условия (путь для выхода «истина» и для выхода «ложь»; для оператора выбора (CASE) тесты потребуются для всех возможных результатов, включая выход по умолчанию). Покрытие вычисляется как отношение числа исходов условий, проверенных тестом, к общему числу исходов тестируемых условий. 4.3.3 Ценность тестирования операторов и условий Стопроцентное покрытие операторов означает проверку всех исполняемых инструкций в коде хотя бы один раз, но это не дает уверенности в проверке логики условий. Из двух методов, рассматриваемых здесь, тестирование операторов обеспечивает более слабое покрытие, чем тестирование условий. Стопроцентное покрытие условий проверяет все ветки потока управления, что включает проверку выходов «истина» и «ложь» для условных операторов. Покрытие условий позволяет находить ситуации, в которых исполняемый код может быть пропущен в зависимости от результата условия. Стопроцентное покрытие условий гарантирует стопроцентное покрытие операторов, но не наоборот. 4.4 Методы, основанные на опыте При использовании методов тестирования, основанных на опыте, тесты создаются на основе умения, интуиции и опыта тестировщика. Данные методы могут пригодиться при создании тестов, которые невозможно получить, применяя другие, более системные методы. В зависимости от выбранного подхода и прошлого опыта можно получить очень разные степени покрытия и эффективности тестирования. Измерение покрытия для данных методов может быть затруднительным или вообще невозможным. Наиболее популярные методы рассматриваются в последующих разделах. 4.4.1 Предположение об ошибках Предположение об ошибках – это способ предотвращения ошибок, дефектов и отказов, основанный на знаниях тестировщика, включающих: Историю работы приложения в прошлом Наиболее вероятные типы дефектов, допускаемых при разработке Типы дефектов, которые были обнаружены в схожих приложениях Структурированный подход к предположению об ошибках предполагает создание списка всех возможных ошибок, дефектов и отказов с последующей разработкой тестов, направленных на поиск дефектов из этого списка. Списки отказов и дефектов могут быть построены на основе опыта, исторических данных об отказах и ошибках, а также на общих знаниях о причинах отказа программ. Сертифицированный тестировщик Программа обучения базового уровня International Software Testing Qualifications Board Версия 2018 Страница 64 of 94 24 февраля 2019 © International Software Testing Qualifications Board 4.4.2 Исследовательское тестирование Во время исследовательского тестирования неформальные (т.е. не созданные заранее) тестовые сценарии разрабатываются, выполняются, анализируются и оцениваются динамически во время выполнения тестов. Результаты тестирования используются для изучения компонента или системы и последующей разработки тестовых сценариев для непокрытых областей. Исследовательское тестирование может проводиться сессиями, что позволяет структурировать активность. При использовании сессионного подхода, исследовательское тестирование выполняется в определенном промежутке времени, при этом тестировщик использует концепцию тестирования, содержащую цели, и отмечает выполненные действия и обнаруженные факты. Исследовательское тестирование лучше всего подходит в ситуациях, когда документация недостаточная, либо вовсе отсутствует, в условиях очень сжатых сроков и как дополнение к другим, более формальным, методам тестирования. Исследовательское тестирование относится к реактивным стратегиям тестирования и может включать использование различных методов черного и белого ящиков или методов, основанных на опыте. 4.4.3 Тестирование на основе чек-листов При тестировании по чек-листам тестировщик проектирует, реализует и выполняет тесты, покрывающие тестовые условия, указанные в чек-листе. В качестве составной части анализа тестировщики могут создавать новые или расширять чек-листы, либо использовать готовые чек-листы, не меняя их. Такие списки могут быть построены на опыте, на исторических данных об ошибках, на информации о приоритетах для пользователей и понимании, как и почему происходят отказы в программе. Чек-листы могут создаваться для поддержки разных видов тестирования, включая функциональное и нефункциональное тестирование. При отсутствии детальных тестовых сценариев, чек-листы помогают определить направления тестирования и увеличивают согласованность тестирования. Поскольку чек-листы содержат общее описание, это снижает повторяемость результатов. |