Тестирование. Ю. Б. Попова тестирование и отладка программного
 Скачать 0.6 Mb.
|
|
4. ПЛАНИРОВАНИЕ ФУНКЦИОНАЛЬНОГО ТЕСТИРОВАНИЯ После появления первой рабочей версии требований к програм- мному продукту тестировщики приступают к подготовительным работам для проведения функционального тестирования, т. е. пла- 32 нируют свою тестовую деятельность. На этом этапе необходимо определиться со следующими моментами: – какой программный продукт будет тестироваться, каково его назначение; – как будет использоваться продукт; – какие части продукта будут тестироваться, а какие нет; – какие методы и техники тестирования наиболее эффективны для данного проекта; – какие риски могут возникнуть в процессе тестирования (риск – это возможная ситуация, которая негативно повлияет на результа- тивность процесса либо приведет к увеличению сроков реализа- ции, например, эпидемия гриппа в осенний период или период от- пусков летом). Все указанные выше моменты оформляются в тестовый план и рассылаются ключевым участникам проекта. Параллельно тести- ровщиками разрабатываются тестовые случаи. 4.1. Тестовый план Тестовый план – это документ, согласно которому будут про- водиться все действия по тестированию. Ответственным за разра- ботку тестового плана, как правило, является руководитель коман- ды тестирования. Можно привести примерное содержание тестового плана: 1. Объемы тестирования (перечень тестируемых и нетестируе- мых компонент). 2. Критерии качества (какое количество ошибок может быть от- клонено при сдаче продукта). 3. Риски тестирования. 4. Документация тестирования (тестовый план, тестовые случаи, отчеты об ошибках). 5. Стратегия тестирования (это самый большой и самый важный пункт, в котором описываются применяемые виды тестирования и градация тестов). 6. Ресурсы (перечень человеческих ресурсов с разделением прав и обязанностей, а также аппаратные ресурсы: сервера, рабочие стан- ции, инструменты тестирования, описание тестового окружения). 33 7. График тестирования (основывается на графике выпуска версий). Составленный тестовый план должен быть проверен и удовле- творять следующим критериям: – является полным, корректным, недвусмысленным; – цели каждого вида тестирования определены; – четко определена стратегия тестирования; – является реально выполнимым; – определено тестовое оборудование; – оговорены условия прекращения тестирования; – определены ресурсы (человеческие, аппаратные, программные) для тестирования. 4.2. Разработка тестовых случаев Тестовый сценарий (англ., Test Script) – это алгоритм проверки некоторой функциональности программы в совокупности с ожида- емыми результатами. Примером тестового сценария может быть, например, проверка функциональности добавления некоторой сущ- ности в базу данных. В процессе добавления возможны разные слу- чаи: верно заполнить все поля сущности, выборочно верно запол- нить поля, неверно заполнить поля, оставить одно поле пустым, оставить два поля пустыми и т. д. Все отдельные случаи проверок называются тестовыми случаями (англ., Test Сase). Тестовые слу- чаи организуются в тестовые наборы (англ., Test Suite), например, режим работы администратора или незарегистрированного пользо- вателя. Тестовые случаи могут изменяться в течение работы над проектом и полностью формируются по мере понимания задачи, по мере изменения требований, а также по другим причинам. Процесс разработки тестовых случаев состоит из следующих этапов: 1. Ознакомление с проектной документацией: требованиями к программному продукту (либо спецификацией), тестовым планом и непроектной информацией (например, литературой по предмет- ной области для разрабатываемого ПО). 2. Проектирование тестовых случаев. При разработке тестовых случаев актуальным понятием является модульность. При модуль- ном проектировании система разбивается на отдельные компоненты, каждый из которых имеет свое назначение и четко определенные 34 входы и выходы. В функциональном тестировании этим модульным компонентом является тестовый случай. Это значит, что перед каж- дым тестовым случаем должна быть поставлена четко сформулиро- ванная цель (что именно подвергается тестированию), определена среда тестирования с известными начальными условиями (благодаря чему можно рассчитывать, что при каждом прогоне конкретный тест будет выдавать один и тот же результат). Также один тестовый случай должен проверять только одну функциональность и иметь строго определенный ожидаемый результат (чтобы было понятно успешно или неуспешно прошло испытание). Формирование тестовых наборов связано с градацией тестов, из которой наиболее распространенной является разбивка на три блока: – тесты для проверки «на дым» (англ., Smoke Test) – это краткая и быстрая проверка основной функциональности программы с це- лью принять или отклонить версию программы для дальнейшего тестирования; – тесты для позитивного тестирования – проверка работы про- граммы в стандартных ситуациях (вводятся верные данные, нажи- маются нужные кнопки, имитируется работа «положительного» пользователя); – тесты для негативного тестирования – проверка работы про- граммы в нестандартных ситуациях (вводятся неверные данные, нажимаются ненужные кнопки, имитируется работа «плохого» пользователя. 3. Написание тестовых случаев. На этом этапе необходимо при- держиваться следующих свойств тестовых случаев: a) тестовый случай должен обладать высокой вероятностью об- наружения дефекта (для этого тестировщик должен стать на пози- цию конструктивного разрушения); b) тестовый случай должен быть воспроизводимым; c) тестовый случай должен обладать четко определенными ожи- даемыми результатами и критериями успешного выполнения теста; d) набор тестовых случаев не должен быть избыточным. 4. Проверка тестовых случаев. По окончании разработки тесто- вых случаев проводится их проверка, в течение которой обращают внимание на следующие моменты: – соответствует ли тестовый случай функциональности, заявлен- ной в требованиях; 35 – покрывают ли тестовые случаи все требования к программно- му продукту (для этого используется матрица прослеживаемости требований); – организованы ли тестовые случаи достаточно эффективно, что- бы можно было обходиться минимальными конфигурациями средств тестирования; – включены ли тесты в систему управления конфигурациями; – имеются ли среди тестов избыточные, можно ли устранить эту избыточность; – снабжен ли каждый тестовый случай ожидаемыми результатами; – достаточно ли подробно разработана методика тестирования, чтобы стала возможной ее автоматизация. Пример тестового случая добавления нового студента в группу для позитивного теста приведен в табл. 4.1. Таблица 4.1 Пример тестового случая добавления нового студента № № требо- вания Название модуля/ экрана Описание тестового случая Ожидаемые результаты Тест пройден? Да/Нет 1 R1001 Режим Админист- ратора, Добавление студента в группу Добавление нового студен‐ та в группу 1. Нажать кноп- ку <Добавить>. 2. Заполнить поля данными: Иванов Иван Иванович, вы- брать группу 107222. 3. Нажать <Со- хранить> 1. Появляется окно с пусты- ми полями: Фамилия, Имя, Отчество, а также выпадаю- щий список с существую- щими номерами групп. 2. Вводимая информация по- является в полях, группа выбрана. 3. Если такого студента в базе данных нет, то он до- бавляется в список, иначе на экране появляется сооб- щение «Такой студент уже имеется. Изменить? Да/Нет». Если «Да», то система воз- вращает курсор в первое поле для изменений. Если «Нет», то система возвра- щается в первоначальное окно без добавления нового студента. 36 4.3. Эквивалентирование и анализ граничных значений При планировании функционального тестирования неизбежной является задача выбора тестовых данных. Для сокращения перебо- ров область всех входных данных программы можно разбить на ко- нечное число классов эквивалентности. Такое разбиение основано на принципе эквивалентности из общей теории систем, который в данном контексте можно выразить следующим образом: если сис- тема реагирует некоторым образом на входное значение x1, то су- ществует довольно большая вероятность, что система отреагирует аналогичным образом на входное значение x2, очень близкое к x1. Тогда все множество входных данных системы можно разбить, как минимум, на два класса эквивалентности: класс верных значений (они войдут в позитивный тест) и класс неверных значений (для не- гативного теста). Тогда граничными значениями будем называть те значения, которые располагаются на границах классов эквивалент- ности, а эквивалентными – те, которые расположены внутри клас- сов эквивалентности. Например, рассмотрим целочисленное поле для ввода цены товара, которое по требованиям может находиться в диапазоне [0; 1000000] рублей (табл. 4.2). Таблица 4.2 Пример разбиения на классы эквивалентности Класс верных значений Класс неверных значений Граничные Эквивалентные Граничные Эквивалентные 0, 1000000 1, 999999 500000 –1, 100000001 –2, 10000000000000, 0, –50000 10.5, абв, 2$ Как видно из примера, в качестве эквивалентных данных прини- маются значения, близкие к левой границе, к правой границе и для позитивного теста близко к середине диапазона. Эквивалентные зна- чения из класса неверных могут быть абсолютно разными, но вы- бранными с целью поломки программы и проверки ее реакции в не- предвиденных ситуациях. Независимо от классов эквивалентности рекомендуется проверять 0, –1, +1 и специальные символы. 37 5. РЕАЛИЗАЦИЯ ФУНКЦИОНАЛЬНОГО ТЕСТИРОВАНИЯ 5.1. Ошибка, свойства ошибки Функциональное тестирование направлено на поиск ошибок в заявленной функциональности программы. Поэтому ключевым понятием здесь является термин «ошибка». Существует довольно много определений ошибки, приведем некоторые из них: – ошибка – это расхождение между программой и ее специфика- цией. Определение часто критикуют, поскольку пользователь про- граммы может не иметь спецификации, но на экране увидеть, на- пример, Error 404. – если программа не делает того, чего пользователь от нее вполне обоснованно ожидает, значит налицо программная ошибка (Гленфорд Майерс, [1]); – не существует ни абсолютного определения ошибок, ни точно- го критерия наличия их в программе, можно лишь сказать, насколь- ко программа не справляется со своей задачей – это исключительно субъективная характеристика (Борис Бейзер, [12]). Последние два определения имеют право на существование, од- нако для краткости будем называть ошибкой несоответствие ожи- даемых результатов с фактическими полученными. Выделим следующие свойства ошибок: 1) Важность. В этом свойстве могут быть определены следую- щие уровни: – критическая важность, когда произошел сбой либо отказ сис- темы, и дальнейшая работа с программой невозможна; – серьезная важность, когда не работает основная функциональ- ность программы (например, добавление записи в базу данных); – средняя важность, когда не работает второстепенная функцио- нальность либо имеются недочеты в работе основной функцио- нальности (например, не работает сортировка товара в списке, или не появляется сообщение для подтверждения удаления товара из базы данных); – низкая важность, когда имеется мелкая ошибка (например, ошибка интерфейса либо орфографическая ошибка). 2) Воспроизводимость. Это свойство связано с частотой и усло- виями воспроизведения, поэтому здесь выделяют два уровня: 38 – всегда, т. е. ошибка воспроизводится на всех устройствах и не зависит ни от каких условий; – иногда, т. е. ошибка воспроизводится только при определен- ных условиях, например, только в определенном браузере. 3) Приоритет. Это свойство связано со скоростью исправления ошибки. Можно выделить следующие уровни приоритета: – очень высокий, когда ошибка должна быть исправлена не- медленно; – высокий, когда ошибка должна быть исправлена как можно скорее; – средний, когда ошибка может быть исправлена, когда появится свободное время; – низкий, когда ошибка может быть исправлена в последнюю очередь. 4) Симптом. Это свойство также называют категорией ошибки. К одной ошибке иногда может подходить несколько симптомов, по- этому при документировании ошибки достаточно указать один из них, но, желательно, самый точный. Перечень симптомов может от- личаться в зависимости от используемой системы управления ошиб- ками (см. п. 5.5), поэтому приведем наиболее часто встречающиеся: – неожиданное поведение, когда, например, вместо сообщения о со- хранении данных, появляется сообщение об их успешном удалении; – недружественное поведение, когда, как правило, программа не сопровождает свои действия сообщениями и предупреждениями; – неверное действие, когда программа не выполняет требуемое действие или выполняет неверно, например, не удаляет запись из базы данных; – отказ системы, когда дальнейшая работа с программой невоз- можна; – потеря данных, когда, например, добавленные данные исчезли; – искажение данных, когда произошла замена данных програм- мы искаженными, или, например, данные выводятся на экран в дру- гой кодировке; – низкая производительность, когда, например, слишком медлен- но идут вычисления, или медленно раскрывается таблица; – локализационная ошибка может быть связана с воспроизведе- нием на разных устройствах, а также, например, в связи со сменой локализации сайта на другой иностранный язык; 39 – инсталляционная ошибка, которая проявляется во время раз- ных способов инсталляции ПО; – косметическая ошибка связана с интерфейсом программы; – ошибка документации связана с недочетами в любой докумен- тации, используемой в процессе разработки ПО; – различия со спецификацией, когда, например, названия элемен- тов интерфейса, их количество, цвет, внешний вид и т. д. не соот- ветствуют заявленным в требованиях или в спецификации к про- граммному продукту; – отсутствующая функциональность, когда функциональность, заявленная в требованиях, отсутствует в программном продукте (например, отсутствует поле для поиска и, соответственно, вся функ- циональность поиска); – запрос на улучшение является симптомом, который может быть выставлен, когда тестировщик предлагает улучшить некото- рую функциональность программы либо ее внешний вид. Таким образом, ошибка с этим симптомом может не противоречить требо- ваниям, и, соответственно, может не быть исправлена. 5.2. Правила составления отчетов об ошибках Процесс поиска ошибок, как правило, состоит в прохождении одного за другим заранее запланированных тестовых случаев, свер- ки ожидаемых результатов с фактически полученными и вывода, прошел тест или нет. При этом заполняется последняя колонка табл. 4.1. Если тест не пройден, значит найдена ошибка, которая должна быть задокументирована и передана программисту на ис- правление. Для того чтобы исправление ошибки проходило без осо- бых затруднений, отчет об ошибке должен составляться быстро, но при этом его тон и содержание должны максимально способство- вать решению проблемы. Поэтому необходимо проанализировать ошибку, воспроизвести ее несколько раз, выяснить условия воспро- изведения, данные, при которых она появляется. И только потом описать ее предельно кратко и четко, поскольку слишком простран- ное и расплывчатое описание проблемы затрудняет понимание ее сути. Кроме свойств ошибки, описанных выше, необходимо запол- нить поля, приведенные в табл. 4.3. 40 Таблица 4.3 Информация об обнаруженной ошибке Характеристика Описание Обоснование Идентификатор ошибки Уникальный идентифи- катор, обычно строка из алфавитно-цифровых символов. Позволяет отслеживать ошибку в процессе изме- нения ее состояний. Статус ошибки Один из допустимых статусов. Присвоить ошибке статус «Новый» в момент обна- ружения. Кем обнаружен Имя исполнителя, обна- ружившего дефект. Обеспечивает возможность задавать вопросы относи- тельно дефекта. Дата обнаружения День/месяц/год. Позволяет отслеживать хронологию событий, свя- занных с ошибкой. Краткое описание проблемы Описание на концепту- альной форме, как пра- вило, одной строкой. Описание используется в сообщениях о статусе ошибки. Описание проблемы Детальное описание симптомов проблемы и того, как она ограни- чивает функциональные возможности продукта. Предназначено для тех, кому необходимо деталь- ное описание проблемы, например, разработчику, который работает над уст- ранением ошибки. Как воспроизвести проблему Детально проработанная методика воспроизведе- ния проблемы. Позволяет разработчикам локализовать проблему. Ошибки, как правило, сохраняют в автоматизированные системы документирования и отслеживания ошибок (см. п. 5.3). Каждая из таких систем имеет свои особенности при составлении отчетов об ошибках и поля для заполнения, однако можно предложить следу- ющие общие правила: 1) Составляйте отчет об ошибке сразу же после ее обнаружения, иначе про нее можно забыть. 41 2) Не составляйте отчет на бумаге (поскольку листок может лег- ко потеряться), а заносите в систему документирования и отслежи- вания ошибок. 3) Составьте полное описание ошибки с указанием операцион- ной системы, браузера, базы данных и/или других подробностей. 4) Опишите подробно шаги для воспроизведения ошибки, чтобы разработчик мог их повторить и увидеть ошибку. 5) Придумайте краткое, но емкое название для ошибки. 6) Не путайте описание ошибки и шаги воспроизведения, а так- же название ошибки и описание ошибки. 7) Укажите важность ошибки, симптом, частоту появления и приоритет. 8) Пользуйтесь простым и доходчивым языком при составлении отчета об ошибке. 9) Не обвиняйте никого в обнаруженной ошибке, поскольку отчет не должен приводить к конфликту между тестировщиками и про- граммистами, а лишь способствовать разработке качественного про- граммного продукта. |