Конфигурационное тестирование

Конфигурационное тестирование — это тестирование влияния на производительность системы изменений в конфигурации (в отличие от предыдущих видов тестирования системы с точки зрения увеличения подаваемой нагрузки).

Конфигурационное тестирование — проверка работы ПО на различных программных и аппаратных окружениях.

Данный вид тестирования применяется, если известно, что информационный продукт будет использоваться, например, на разных платформах, в различных браузерах, будет поддерживать разные версии драйверов.

В зависимости от типа проекта конфигурационное тестирование может иметь разные цели:

■ определение оптимальной конфигурации оборудования, обеспечивающей требуемые характеристики производительности и времени реакции тестируемой системы;

■ проверка объекта тестирования на совместимость с объявленным в спецификации оборудованием, операционными системами и программными продуктами третьих фирм. Конфигурационное тестирование также может быть совмещено с нагрузочным, стресс- или тестированием стабильности.

РЕГРЕССИОННОЕ ТЕСТИРОВАНИЕ

Регрессионное тестирование — тестирование программного обеспечения, направленное на обнаружение ошибок в уже протестированных участках исходного кода.

 

Когда после внесения изменений в программу перестает работать то, что прежде работало, то такие ошибки называют регрессионными ошибками.

Регрессионное тестирование включает:

■ проверку исправления вновь найденного дефекта;

■ проверку того, что исправленный ранее и верифицированный дефект не воспроизводится в системе снова;

■ проверку того, что не нарушилась работоспособность работающей ранее функциональности, если ее код был затронут при исправлении некоторых дефектов в другой функциональности. Обычно используемые методы регрессионного тестирования

включают повторные прогоны предыдущих тестов, а также проверки, не попали ли регрессионные ошибки в очередную версию в результате слияния кода.

Повторное появление одних и тех же ошибок происходит из-за слабой техники управления версиями или по причине человеческой ошибки. Кроме того, при переписывании какой-либо части кода часто всплывают те же ошибки, что были в предыдущей реализации. Поэтому считается хорошей практикой при исправлении ошибки создать тест на нее и регулярно прогонять его при последующих изменениях программы. Хотя регрессионное тестирование может быть выполнено и вручную, но чаще всего это делается с помощью специализированных программ, позволяющих выполнять все регрессионные тесты автоматически. В некоторых проектах даже используются инструменты для автоматического прогона регрессионных тестов через заданный интервал времени. Использование автоматизированных тестов делает процедуру проверки менее трудоемкой.

В процессе тестирования программного обеспечения формируется библиотека регрессионных тестов. Это полный набор тестов, охватывающий всю программу и выполняющий каждый раз, когда программисты сдают ее очередную рабочую версию. Первоначально в библиотеке может оказаться больше тестов, чем это действительно необходимо. Как минимум в нее должны входить примеры для проверки граничных условий и временных характеристик. Некоторые из тестов при первом проведении тестирования могут выявить ошибки, но после их окончательного исправления повторные выполнения тех же тестов бесполезны. Такие тесты можно исключить из библиотеки, оставив только те, в которых проявлялись ошибки.

Можно сформулировать некоторые правила построения библиотеки регрессионных тестов.

Тесты, которые эквивалентны другим тестам библиотеки, нужно удалять. В идеале такие тесты, конечно, не должны попадать в библиотеку. Когда библиотека создается несколькими сотрудниками, подобные ситуации вполне возможны.

Количество тестов, объектом которых является уже исправленная ошибка, нужно уменьшать. Если ошибка или некоторые ее разновидности проявляются в течение целого ряда циклов тестирования, то в библиотеку стоит добавить достаточное число тестов для их выявления. Но после того как соответствующая часть программного обеспечения была протестирована (устранены ошибки), большую часть тестов, направленных на поиск исправленной ошибки, можно удалить из библиотеки.

При последующем тестировании следует комбинировать тесты. В начале тестирования этого делать не нужно, но в дальнейшем объединение тестов позволит значительно ускорить работу.

Тестирование должно быть автоматизированным. Если определенная группа тестов будет выполняться в течение нескольких последующих циклов тестирования, то этот процесс требует автоматизации.

Все тесты регрессионной библиотеки не обязательно выполнять после каждого изменения программы. Это можно делать реже — на каждом втором или на каждом третьем цикле. На последней стадии тестирования лучше выполнить максимально возможное число тестов, чтобы убедиться, что программа готова к выпуску, на других циклах достаточно половины или даже трети всех тестов.

Регрессионная библиотека должна включать в себя все лучшие тесты из тех, что уже разработаны, но если она будет слишком велика, не останется времени на разработку новых тестов. А ведь именно новейшие тесты с наибольшей вероятностью выявляют еще не найденные ошибки. Поэтому планировать работу надо так, чтобы регрессионная библиотека служила средством повышения эффективности тестирования, а не его тормозом.

 

ТЕСТИРОВАНИЕ ДОКУМЕНТАЦИИ

Тестирование документации (documentation testing) помогает избежать логических дефектов и ненужных изменений в продукте до начала его фактической разработки. Оно также позволяет сократить число обращений в службу поддержки благодаря улучшению пользовательской документации.

Тестирование документации охватывает следующие виды документов:

• функциональные спецификации;

• описание графического интерфейса пользователя;

• руководства пользователя и онлайновые справочные системы.

В ходе тестирования документации выполняется проверка следующих аспектов:

• логика и согласованность (последовательность изложения и однородность формы подачи информации);

• полнота и ясность изложения (соответствие уровня детализации целевой аудитории, достаточность изложенной информации для понимания);

• точность (актуальность информации, правильность ссылок и графических элементов);

• структура документа (соответствие порядка следования элементов документа его цели);

• орфография, грамматика, правильность употребления слов и пунктуации;

• форматирование (отсутствие отклонений от стиля оформления, соответствие элементов документа корпоративному стилю).

 

 

Тестирование и тест-дизайн.

 

Любое тестирование, в том числе тестирование ПО - это поиск багов.

Баг - это отклонение фактического результата (неких действий) от ожидаемого.

Для чего нужно тестирование? Чтобы найти баги до того, как их найдут пользователи, то есть до выпуска продукта.

 

Чтобы проводить тестирование, нужно:

1. Узнать ожидаемый результат

2. Узнать фактический результат

3. Сравнить эти результаты

 

Например, нам нужно протестировать пуленепробиваемое стекло. Ожидается, что его нельзя пробить пулей. Чтобы протестировать, мы должны попытаться опровергнуть это ожидание, то есть выстрелить в стекло и узнать фактический результат. Затем сравним его с ожидаемым: если пуля пробила стекло, значит, найден баг.

 

Таким образом, для тестирования нужно еще выбрать некоторое действие (в данном случае - выстрел), получаем, что процесс тестирования состоит из четырех стадий:

1. Выбрать действие

2. Узнать ожидаемый результат этого действия

3. Узнать фактический результат

4. Сравнить эти результаты

 

Первые две стадии относятся к тест-дизайну - написанию тестов.

1. Выбор действия (тестового сценария).

Если у нас есть официальный документ с требованиями к продукту (спецификация), то тестовые сценарии следует написать, исходя из этих требований. В хорошей спецификации основные сценарии использования (use-cases) прописаны явно, в виде пошаговых инструкций, которые можно использовать при тестировании "как есть". Если спецификация не содержит пошаговых инструкций, а лишь общие слова, дизайнер тестов должен написать такие инструкции сам.

Для более тщательного тестирования можно придумать свои тестовые сценарии. Существует много разных техник выбора таких сценариев, о них в следующих лекциях.

 

2. Информацию об ожидаемом результате, опять же, правильнее всего взять из спецификации. Если же в требованиях это не описано, можно использовать:

2.1. Авторитетное мнение (правильнее всего - того человека, который составляет спецификации)

2.2. Устоявшиеся стандарты (официальные, например, RFC, или стандарты де-факто, например, то, что при нажатии правой кнопки мыши появляется контекстное меню)

2.3. Здравый смысл

2.4. Заглянуть в код программы

2.5. Прочее

 

Последние две стадии - это собственно тестирование (прохождение тестов):

3. Узнать фактический результат мы можем, произведя действие, выбранное на первом этапе.

4. После этого нам остается сравнить фактический результат с ожидаемым и зарепортить баг в случае несоответствия.

 

Например, проведем тестирование электрического чайника.

1. Какое действие покажет нам, работает ли чайник? Самое очевидное - включить чайник.

2. Что мы примем за ожидаемый результат? Вероятно, то, что вода в чайнике через определенное время вскипит.

3. Как мы узнаем фактический результат? Включим чайник и подождем определенное время.

4. А теперь сравним фактический результат с ожидаемым. Здесь важен вопрос - как понять, что вода вскипела? Нужен критерий соответствия фактического результата и ожидаемого. Критерием может быть, например:

а) Вода бурлит. Минус этого критерия - его нечеткость. Что значит "бурлит"? Как сильно должна вода бурлить? Кроме того, критерий пригоден только для тестирования с участием человека и практически непригоден для автоматического тестирования. Основываясь на этом критерии, сложно будет сделать чайник, который сам умеет отключаться.

б) Температура воды достигла 99 градусов. Это уже более четкий критерий.

Если мы ждали достаточно долго, а вода так и не закипела, это означает, что мы нашли баг.

 

Для тестировщика найденный баг - это всегда праздник, потому что это значит, что результат работы можно предъявить начальству. Не так важно количество найденных багов, как их серьезность (severity). Серьезность определяется тестовым сценарием, по результату которого был найден баг. Например, баг "у чайника пятно краски на боку" менее серьезен, чем "чайник не кипятит воду", потому что кипячение воды - это основная функция чайника, а красивые бока - побочная. В популярной системе учета багов Bugzilla severity имеет 6 уровней - blocker, critical, major, normal, minor и enhancement. В разных организациях и разных проектах количество реально используемых уровней может быть различным.

 

Тестовая документация.

Тестовая документация состоит обычно из отдельных сценариев, которые называются тест-кейсами и могут быть для удобства объединены в группы или тест-сьюты.

Написание тестовой документации имеет много общего с написанием ПО: следует разбивать код на отдельные модули и избегать дублирования кода.

 

3.1. Что должна содержать тестовая документация и почему.

В общем случае, тестовая документация может содержать: заголовок, пошаговое описание, ожидаемый результат, критерий соответствия ожидаемого результата фактическому.

 

Тест-кейс должен обязательно содержать хотя бы ожидаемый результат (даже, может быть, без описания действий, которые к нему ведут). Например, "Программа должна уметь показывать файлы формата BMP". Такой тесткейс представляет собой просто перепечатку из документа с требованиями.

 

Однако, из такого тесткейса непонятно, как осуществить проверку. Человек, незнакомый с программой, может попросту не найти в ее интерфейсе, как показывать графические файлы, и напишет баг об отсутствии такой возможности.

 

Поэтому, кроме ожидаемого результата, необходимо еще пошаговое описание действий, которые позволят нам прийти к результату фактическому и сравнить его с ожидаемым.

 

Краткое описание тест-кейса имеет смысл вынести в заголовок.

 

Пример.

 

Заголовок: "Проверка того, что программа умеет показывать файлы формата BMP"

Шаг 1. Нажать кнопку "Выбрать файл"

Шаг 2. Выбрать файл с расширением BMP

Шаг 3. Нажать кнопку "Открыть"

Ожидаемый результат: содержимое файла показано в графическом виде, в полноэкранном режиме.

 

Здесь сравнение ожидаемого результата и фактического осуществить довольно просто, и критерий соответствия не нужен. Приведем более сложный пример:

 

Заголовок: "Проверка изменения домашнего телефона пользователя в ActiveDirectory"

Шаг 1. Нажать кнопку "Создать пользователя"

Шаг 2. Ввести имя пользователя, логин и пароль.

Шаг 3. Нажать кнопку OK

Шаг 4. Выбрать только что созданного пользователя в списке, кликнув на его логин.

Шаг 5. Нажать кнопку "Редактировать"

шаг 6. Ввести номер телефона в поле "Домашний телефон"

шаг 7. Нажать кнопку ОК

Ожидаемый результат: домашний телефон сохранился в ActiveDirectory.

 

Здесь ожидаемый результат было бы неплохо также расписать в виде последовательности шагов: как посмотреть в ActiveDirectory, что домашний телефон сохранился. Это и будет описанием критерия соответствия. Можно записать эти шаги здесь же, начиная с номера 8, и уточнить ожидаемый результат:

 

Шаг 8. Залогиниться на сервер AciveDirectory

Шаг 9. Открыть оснастку dsa.msc

Шаг 10. Найти пользователя по логину

Шаг 11. Посмотреть значение поля Home phone

Ожидаемый результат: это значение соответствует номеру телефона в поле "Домашний телефон"

 

Однако, строго говоря, эти шаги не являются частью тестируемого сценария. При изменении или удалении сценария эта инструкция может быть потеряна. Поэтому имеет смысл записать ее на специальном сайте - базе знаний (Knowledge Base, KB), а в тесткейсе дать ссылку на эту инструкцию.

Кроме того, если эта инструкция будет использована в других тесткейсах, нам не нужно будет ее каждый раз копировать, достаточно будет давать ссылку.

 

Таким образом, возвращаемся к предыдущему варианту и вставляем ссылку в поле "Ожидаемый результат":

 

Ожидаемый результат: домашний телефон сохранился в ActiveDirectory (смотри ссылку)