Тестирование ПО. Тестирование. Реферат актуальность. Основной всплеск интереса к теме тестирования пришёлся на 90е годы и начался в сша. Бурное развитие систем автоматизированной разработки
 Скачать 2.21 Mb.
|
|
8.4.1 Требования к обязательным полям баг репорта Обязательными полями баг репорта являются: короткое описание (Bug Summary), серьезность (Severity), шаги к воспроизведению (Steps to reproduce), результат (Actual Result), ожидаемый результат (Expected Result). Ниже приведены требования и примеры по заполнению этих полей. Короткое описание. В одном предложение нужно уместить смысл всего баг репорта, а именно: коротко и ясно, используя правильную терминологию сказать что и где не работает. Например: приложение зависает, при попытке сохранения текстового файла размером больше 50Мб; данные на форме "Профайл" не сохраняются после нажатия кнопки "Сохранить". Серьезность. В двух словах можно отметить, что если проблема найдена в ключевой функциональности приложения и после ее возникновения приложение становится полностью недоступно, и дальнейшая работа с ним невозможна, то она блокирующая. Обычно все 46 блокирующие проблемы находятся во время первичной проверки новой версии продукта (Build Verification Test, Smoke Test), т.к. их наличие не позволяет полноценно проводить тестирование. Если же тестирование может быть продолжено, то серьезность данного дефекта будет критическая. На счет значительных, незначительных и тривиальных ошибок вопрос достаточно прозрачный и зависит от ситуации. Шаги к воспроизведению/Результат/Ожидаемый результат. Очень важно четко описать все шаги, с упоминаем всех вводимых данных (имени пользователя, данных для заполнения формы) и промежуточных результатов. Например: 1) войдите в системы: Пользователь Тестер1, пароль xxxXXX: вход в систему осуществлен. 2) кликните линк Профайл: страница Профайл открылась. 3) введите Новое имя пользователя: Тестер2; 4) нажмите кнопку Сохранить. Результат. На экране появилась ошибка. Новое имя пользователя не было сохранено Ожидаемый результат. Страница профайл перегрузилась. Новое значение имени пользователя сохранено. 8.4.2 Основные ошибки при написании баг репортов Недостаточность предоставленных данных. Не всегда одна и таже проблема проявляется при всех вводимых значениях и под любым вошедшим в систему пользователем, поэтому настоятельно рекомендуется вносить все необходимые данные в баг репорт. Определение серьезности. Очень часто происходит либо завышение, либо занижение серьезности дефекта, что может привести к неправильной очередности при решении проблемы. Язык описания. Часто при описании проблемы используются неправильная терминология или сложные речевые обороты, которые могут ввести в заблуждение человека, ответственного за решение проблемы. Отсутствие ожидаемого результата. В случаях, если вы не указали, что же должно быть требуемым поведением системы, вы тратите время разработчика, на поиск данной информации, тем самым замедляете исправления дефекта. Вы должны указать пункт в требованиях, написанный тест кейс или же ваше личное мнение, если эта ситуация не была документирована. 47 8.4.3 Заполнение полей баг репорта В таблице 8.2 представлены основные поля баг репорта и роль работника, ответственного за заполнение данного поля. Жирным курсивом выделены обязательные для заполнения поля. Таблица 8.2 - Заполнение полей баг репорта Поле Ответственный за заполнение поля Короткое описание (Summary) Автор баг репорта (обычно это Тестировщик) Проект (Project) Автор баг репорта (обычно это Тестировщик) Компонент приложения (Component) Автор баг репорта (обычно это Тестировщик) Номер версии (Version) Автор баг репорта (обычно это Тестировщик) Серьезность (Severity) Автор баг репорта (обычно это Тестировщик), однако данный атрибут может быть изменен вышестоящим менеджером Приоритет (Priority) Менеджер проекта или менеджер ответственный за разработку компонента, на который написан баг репорт Статус (Status) Автор баг репорта (обычно это Тестировщик), но многие системы баг трекинга выставляют статус по умолчанию Автор (Author) Устанавливается по умолчанию, если нет, то указывается имя автора баг репорта Назначен на (Assigned To) Менеджер проекта или менеджер ответственный за разработку компонента, на который написан баг репорт ОС / Сервис Пак и т.д. / Браузера + версия / ... Автор баг репорта (обычно это Тестировщик) Шаги воспроизведения (Steps to Reproduce) Автор баг репорта (обычно это Тестировщик) Фактический Результат (Result) Автор баг репорта (обычно это Тестировщик) Ожидаемый результат (Expected Result) Автор баг репорта (обычно это Тестировщик) Прикрепленный файл (Attachment) Автор баг репорта (обычно это Тестировщик), а также любой член командной группы, считающий, что прикрепленные данные помогут в исправлении бага 8.4.4 Жизненный цикл бага Рисунок 8.1 иллюстрирует жизненный цикл дефекта, принятый во многих крупных компаниях. Баг может находится в одном из представленных на рисунке состояний. Обнаружен (submitted). Тестировщик находит баг и представляет его на рассмотрение в систему отслеживания ошибок. С этого момента баг начинает свою официальную жизнь и о его существовании знаю необходимые люди. Изначен (assigned). Тестировщик или ведущий разработчик рассматривает баг и назначего его направление кому-то команды разработчиков. Исправлен (fixed). Разработчик, которому было назначено исправление дефекта, исправляет его и сообщает о том, что задание выполнено. 48 Рисунок 8.1 - Жизненный цикл бага Проверен (verified). Тестировщик, который обнаружил ошибку проверяет на новом билде (в котором исправление данной ошибки заявлено), исправлен ли баг на самом деле. И только в том случае, если ошибка не проявится на новом билде, тестировщик меняет статус бага на Verified. Открыт заново (reopened). Если баг проявляется на новом билде, тестировщик снова открывает этот дефект. Баг приобретает статус Reopened. Отклонен (declined). Баг может быть отклонено. Во-первых, потому что для заказчика какие- то ошибки перестают быть актуальными. Во-вторых, это может случится по вине тестировщика из- за плохого знания продукта, требований (дефекта на самом деле нет). Отложен (deferred). Если исправление конкретного бага сейчас не очень важно или заказчик пока думает, или мы ждем какую-то информацию, от которой зависит исправление бага, тогда баг приобретает статус Deferred. Закрытые (closed) баги. Закрытым считается баг в состояниях Проверен (verified) и Отклонен (declined). Открытые (open) баги. Открытыми являются баги в состояних Обнаружен (submitted), Назначен (assigned), Открыт заново (reopened). Иногда к открытым относят и баги в состояниях Исправлен (fixed) и Отложен (deferred). 49 9 ТЕХНИКИ СОЗДАНИЯ ТЕСТОВ ДЛЯ ЧЕРНОГО ЯЩИКА Целью тестирования ставится выяснение обстоятельств, в которых поведение программы не соответствует спецификации. Для обнаружения всех ошибок в программе необходимо выполнить исчерпывающее тестирование, то есть тестирование на всевозможных наборах данных. Для большинства программ такое невозможно, поэтому применяют разумное тестирование, при котором тестирование программы ограничивается небольшим подмножеством всевозможных наборов данных. При этом необходимо выбирать наиболее подходящие подмножества, подмножества с наивысшей вероятностью обнаружения ошибок [6]. Свойства правильно выбранного теста: уменьшает более, чем на одно число других тестов, которые должны быть разработаны для разумного тестирования; покрывает значительную часть других возможных тестов, что в некоторой степени свидетельствует о наличии или отсутствии ошибки до и после ограниченного множества тестов. Техники черного ящика: эквивалентное разбиение; анализ граничных значений; анализ причинно-следственных связей; попарное тестирование; предположение об ошибке. 9.1 Эквивалентное разбиение Основу метода эквивалентное разбиение составляют два положения: исходные данные необходимо разбить на конечное число классов эквивалентности. В одном классе эквивалентности содержатся такие тесты, что, если один тест из класса эквивалентности обнаруживает некоторую ошибку, то и любой другой тест из этого класса эквивалентности должен обнаруживать эту же ошибку; каждый тест должен включать, по возможности, максимальное количество классов эквивалентности, чтобы минимизировать общее число тестов. Разработка тестов этим методом осуществляется в два этапа: выделение классов эквивалентности и построение теста. Эквивалентный класс — это одно или больше значений ввода, к которым ПО применяет одинаковую логику. 50 Классы эквивалентности выделяются путём выбора каждого входного условия, которые берутся с помощью технического задания или спецификации и разбиваются на две и более группы. Выделение классов эквивалентности является эвристическим способом, однако существует ряд правил: если входное условие описывает область значений, например «Целое число принимает значение от 0 до 999», то существует один правильный класс эквивалентности и два неправильных; если входное условие описывает число значений, например «Число строк во входном файле лежит в интервале (1..6)», то также существует один правильный класс и два неправильных; если входное условие описывает множество входных значений, то определяется количество правильных классов, равное количеству элементов в множестве входных значений. Если входное условие описывает ситуацию «должно быть», например «Первый символ должен быть заглавным», тогда один класс правильный и один неправильный; если есть основание считать, что элементы внутри одного класса эквивалентности могут программой трактоваться по-разному, необходимо разбить данный класс на подклассы. На этом шаге тестирующий на основе таблицы должен составить тесты, покрывающие собой все правильные и неправильные классы эквивалентности. При этом составитель должен минимизировать общее число тестов. Несколько тестов эквивалентны, если: они направлены на поиск одной и той же ошибки; если один из тестов обнаруживает ошибку, другие ее тоже, скорей всего, обнаружат; если один из тестов не обнаруживает ошибку, другие ее тоже, скорей всего, не обнаружат; тесты используют один и те же наборы входных данных; для выполнения тестов приходится совершать одни и те же операции; тесты генерируют одинаковые выходные данные или приводят приложение в одно и то же состояние; все тесты приводят к срабатыванию одного и того же блока обработки ошибок ("error handling block"); ни один из тестов не приводит к срабатыванию блока обработки ошибок ("error handling block"). 51 Определение тестов: каждому классу эквивалентности присваивается уникальный номер; если еще остались не включенные в тесты правильные классы, то пишутся тесты, которые покрывают максимально возможное количество классов; если остались не включенные в тесты неправильные классы, то пишут тесты, которые покрывают только один класс. 9.2 Анализ граничных значений Граничные условия — это ситуации, возникающие на высших и нижних границах входных классов эквивалентности [5]. Анализ граничных значений отличается от эквивалентного разбиения следующим: выбор любого элемента в классе эквивалентности в качестве представительного осуществляется таким образом, чтобы проверить тестом каждую границу этого класса; при разработке тестов рассматриваются не только входные значения (пространство входов), но и выходные (пространство выходов). Метод требует определённой степени творчества и специализации в рассматриваемой задаче. Существует несколько правил: 1) построить тесты с неправильными входными данными для ситуации незначительного выхода за границы области значений. Если входные значения должны быть в интервале [-1.0 .. +1.0], нужно проверить −1.0, 1.0, −1.000001, 1.000001; 2) обязательно писать тесты для минимальной и максимальной границы диапазона; 3) использовать первые два правила для каждого из входных значений (использовать пункт 2 для всех выходных значений); 4) если вход и выход программы представляет упорядоченное множество, сосредоточить внимание на первом и последнем элементах списка. Анализ граничных значений, если он применён правильно, позволяет обнаружить большое число ошибок. Однако определение этих границ для каждой задачи может являться отдельной трудной задачей. Также этот метод не проверяет комбинации входных значений. 9.3 Анализ причинно-следственных связей Анализ причинно-следственных связей позволяет системно выбирать высокорезультативные тесты. Метод использует алгебру логики и оперирует понятиями «причина» и «следствие». Причиной в данном случае называют отдельное входное условие или класс эквивалентности. Следствием - выходное условие или преобразование системы. 52 Идея метода заключается в отнесении всех следствий к причинам, т. е. в уточнении причинно-следственных связей. Данный метод дает полезный побочный эффект, позволяя обнаруживать неполноту и неоднозначность исходных спецификаций. Построение тестов осуществляют в несколько этапов. Сначала, поскольку таблицы причинно- следственных связей при применении метода к большим спецификациям становятся громоздкими, спецификации разбивают на «рабочие» участки, стараясь по возможности выделять в отдельные таблицы независимые группы причинно-следственных связей. Затем в спецификации определяют множество причин и следствий. Далее на основе анализа семантического (смыслового) содержания спецификации строят таблицу истинности, в которой каждой возможной комбинации причин ставится в соответствие следствие. При этом целесообразно истину обозначать «I», ложь - «О», а для обозначения безразличных состояний условий применять обозначение «X», которое предполагает произвольное значение условия (0 или 1). Таблицу сопровождают примечаниями, задающими ограничения и описывающими комбинации причин и/или следствий. которые являются невозможными из-за синтаксических или внешних ограничений. При необходимости аналогично строится таблица истинности для класса эквивалентности. И, наконец, каждую строку таблицы преобразуют в тест. При этом рекомендуется по возможности совмещать тесты из независимых таблиц. Данный метод позволяет строить высокорезультативные тесты и обнаруживать неполноту и неоднозначность исходных. 9.4 Попарное тестирование Pairwise testing - это техника формирования наборов тестовых данных, в которых каждое тестируемое значения каждого из проверяемых параметров хотя бы единожды сочетается с каждым тестируемым значением всех остальных проверяемых параметров. Для демонстрации данной техники возьмем в качестве примера абстрактную систему с большим числом параметров, влияющих на её работу, которую нужно протестировать. Опытный тестировщик знает, что для проверки всех комбинации не хватит времени. К примеру, для проверки всех сочетаний 10 параметров с 10 значениями каждый, потребуется 10 000 000 000 тестов, в то время как метод перебора пар позволяет реализовать сравнимое по качеству тестирование (учитывая количество и критичность найденных в результате багов) используя всего 177 тестов. Метод парного тестирования основан на довольно простой, но от того не менее эффективной идее, что подавляющее большинство ошибок выявляется тестом, проверяющим один параметр, либо сочетание двух. Ошибки, причиной которых явились комбинации трех и более параметров 53 как правило значительно менее критичны, чем пары параметров или одного. Если этого требует ситуация, то можно дополнить тестовое покрытие кейсами на желаемые комбинации параметров. Перебрать все пары не сложно, трудность заключается в том, чтобы обеспечить при этом минимум тестов, комбинируя проверки нескольких пар в одном тесте. Математические методы могут обеспечить такой необходимый минимум тестов. Одним из таких методов являются ортогональные матрицы. Для рассмотрения того как происходит оптимизация, возьмем для примера таблицу 9.1 параметров и значений. Таблица 9.1 - Параметры и их значения Параметр 1 Параметр 2 Параметр 3 Значение 1.1 Значение 2.1 Значение 3.1 Значение 1.2 Значение 2.2 Значение 3.2 Переберем значения первого параметра со вторым (строки №1-4), первого с третьим (строки №5-8) и второго с третьим (строки №9-12). Результат показан в таблице 9.2. Удалив повторяющиеся наборы параметров (выделены серым), получим следующий результат, показанный в таблице 9.3. Таблица 9.2 - Результат перебора значений # Параметр 1 Параметр 2 Параметр 3 1 Значение 1.1 Значение 2.1 Значение 3.1 2 Значение 1.1 Значение 2.2 Значение 3.1 3 Значение 1.2 Значение 2.1 Значение 3.1 4 Значение 1.2 Значение 2.2 Значение 3.1 5 Значение 1.1 Значение 2.1 Значение 3.1 6 Значение 1.1 Значение 2.1 Значение 3.2 7 Значение 1.2 Значение 2.1 Значение 3.1 8 Значение 1.2 Значение 2.1 Значение 3.2 9 Значение 1.1 Значение 2.1 Значение 3.1 10 Значение 1.1 Значение 2.1 Значение 3.1 11 Значение 1.1 Значение 2.2 Значение 3.1 12 Значение 1.1 Значение 2.2 Значение 3.2 |