Лекции по "Информатике"

 

3.3. Попарное тестирование.

Метод классов эквивалентности  применяется для тестирования каждого  входного параметра по отдельности.

 

Пусть наша программа принимает  на вход десяток параметров. Баги, возникающие при определенном сочетании всех десяти параметров, довольно редки. Вообще, взаимное влияние параметров, о котором пользователь не знает - это баг интерфейса (интерфейс интуитивно не понятен).

 

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

 

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

 

Вот пример. Пусть имеется 3 двоичных входных параметра (3 чекбокса). Количество всех возможных комбинаций - 2 в степени 3 = 8 , значит, нужно произвести 8 тестов. Давайте попробуем сэкономить, тестируя чекбоксы попарно.

 

Выпишем все комбинации для первого  и второго чекбоксов:

 

1-й 2-й

0   0   

0   1

1   0

1   1

 

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

 

1-й 2-й 3-й

0   0   0  

0   1   0

1   0   1

1   1   1

 

 

Итак, с помощью четырех наборов  входных данных (четырех тестов) мы протестируем две пары параметров: первый со вторым и второй с третьим. Осталось протестировать пару "первый с третьим".

 

Выпишем отдельно 1 и 3 столбцы:

 

1-й     3-й

0       0  

0       0

1       1

1       1

 

Как видно, мы имеем здесь две  из четырех возможных комбинаций. Комбинации "01" и "10" здесь отсутствуют, а комбинации "00" и "11" присутствуют два раза. Ну что же, добавим еще 2 строки (еще два теста)

 

1-й     3-й

0       0  

0       0

1       1

1       1

0       1

1       0

 

Вернем второй столбец на его  законное место:

 

1-й 2-й 3-й

0   0   0   

0   1   0

1   0   1

1   1   1

0       1

1       0

 

Выходит, что последние два теста  можно проходить при любых  значениях второго параметра. Можно  дописать для определенности нули в  эти пустые места:

 

1-й 2-й 3-й

0   0   0   

0   1   0

1   0   1

1   1   1

0   0   1

1   0   0

 

Получаем 6 тестов вместо 8 при полном переборе.

Можно ли сэкономить еще? Оказывается, можно.

 

Вернемся к 1 шагу:

1-й 2-й

0   0   

0   1

1   0

1   1

 

Давайте допишем третий столбец другим способом, поменяв порядок комбинаций:

 

1-й 2-й 3-й

0   0   1  

0   1   0

1   0   0

1   1   1

 

Все комбинации для 1 и 2, а также  для 2 и 3 параметра здесь есть. Отлично.

Посмотрим теперь на комбинации 1 и 3 параметра

1-й     3-й

0       1

0       0

1       0

1       1

 

Ого! Что мы видим? Изменив порядок  значений в третьем столбце, мы одним  махом убили двух зайцев: скомбинировали и 2-й с 3-м, и 1-й с 3-м параметры.

 

Итого имеем всего 4 строки, то есть 4 теста, эквивалентные первоначальным шести:

1-й 2-й 3-й

0   0   1

0   1   0

1   0   0

1   1   1

 

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

 

http://www.pairwise.org/tools.asp - утилиты для генерации комбинаций

http://download.microsoft.com/download/f/5/5/f55484df-8494-48fa-8dbd-8c6f76cc014b/pict33.msi - PICT

 

Вот строгое определение ортогонального массива:

 

Ортогональный массив OA(N,k,s,t) - это двумерный массив из N рядов (итераций) и k колонок (факторов) из набора S (т.е. факторы могут принимать любое из s значений), обладающий свойством:

выбрав любые t колонок (0<=t<=k) мы получим в рядах все комбинации сочетаний из s по t (Количество повторений одинаковых комбинаций обозначают через λ. Чаще всего рассматривают массивы, где λ = 1, т.е. каждая комбинация встречается только один раз). Параметр t называют мощностью ортогонального массива.

 

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

4. Использование информации о программе при Gray-Box тестировании

Главным минусом Black-box тестирования является то, что тестировщик не знает, какую часть ПО он тестирует. Некоторые существующие пути в программе (о которых нет информации ни в требованиях, ни в документации), могут никогда не быть проверены.  Уменьшить количество таких путей можно путем анализа внутреннего устройства программы.

4.1. Информация о базе данных

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

Например, если вводимая фамилия пользователя  записывается в поле типа "строка" длиной 128 символов, мы должны:

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

2) вне зависимости от того, существуют  или нет такие фамилии, попробовать ввести строку длиннее 128 символов - программа не должна ломаться (должно показываться внятное сообщение об ошибке)

4.2. Информация о других внешних  системах

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

4.3. Информация о коде программы

Если мы имеем доступ к коду программы, мы можем 

а) увидеть специальные случаи, которые не попали в документ с  требованиями и которые необходимо протестировать или, напротив

б) увидеть, что какие-то вещи тестировать  не имеет смысла.

5. Методы отбора тестов для White-Box тестирования

White-box тестирование является не функциональным, а структурным - тестируется код программы. От тестировщика требуются, таким образом, навыки программиста. Главным минусом такого тестирования является то, что тестировщик никогда не сможет обнаружить, что какая-то функциональность не реализована, поскольку нельзя протестировать код, который не написан.

 

Различают два метода отбора тестов:

5.1. Тестирование путей исполнения (control-flow testing)

5.2. Тестирование работы с данными (data-flow testing)

 

Подробно эти методы описаны  в книге A Practitioner's guide to Sofware Test Design (Lee Copeland). Описание их выходит за рамки данной лекции, поскольку они не являются методами функционального тестирования.

 

Лекция 3. Как протестировать неизвестную программу или наращиваемый подход к первичному функциональному тестированию ПО.

 

Большинство программных продуктов  состоит из трех компонентов:

1. Инсталлятор

2. Пользовательская документация.

3. Собственно программа

 

Тестирование инсталлятора обычно включает в себя:

1. Тестирование свежей (первичной)  инсталляции

2. Тестирование апгрейда (повторной  инсталляции поверх уже существующей  копии)

3. Тестирование деинсталляции

 

Тестирование пользовательской документации обычно включает

1. Тестирование формальных требований (полнота, понятность, непротиворечивость, актуальность)

2. Тестирование правильности синтаксиса  и грамматики

3. Тестирование работоспособности  примеров

 

В этой лекции будет изложен подход к тестированию собственно программы (основной функциональности)

 

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

 

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

 

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

 

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

 

Один из таких подходов приведен Луизой Тамре в книге "Введение в тестирование программного обеспечения". Основываясь на этой книге и собственном опыте, предлагаю следующие этапы первичного тестирования нового ПО или новой функциональности в известном ПО:

 

1. Приемочное тестирование требований к ПО

2. Исследовательское тестирование.

3. Тестирование базовых сценариев

4. Анализ тенденций

5. Поэлементное тестирование входных данных (тестирование каждого элемента данных в отдельности на всех разрешенных классах эквивалентности) 

6. Комбинирование входных данных (тестирование комбинаций разрешенных значений для нескольких элементов данных)

7. Тестирование граничных значений

8. Тестирование ошибочных данных

 

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

Затем, по утвержденному черновику, можно проводить тестирование.

1. Приемочное тестирование требований

Приемочное тестирование - это минимально необходимое. Можно придумать множество  требований к требованиям, см. например http://ru.wikipedia.org/wiki/Требования_к_программному_обеспечению. С точки зрения автора, QA должно обращать внимание в первую очередь на

1. наличие

2. непротиворечивость 

3. проверяемость (testability)

4. полноту системы операций (CRUD).

CRUD - это 4 базовых функции персистентного хранилища: create, read, update, delete.

Большинство пользовательских интерфейсов  содержит эти операции, см. http://en.wikipedia.org/wiki/Create,_read,_update_and_delete

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

 

Другие требования должны проверяться  другими людьми.

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

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

2. Исследовательское тестирование  ПО.

Исследовательское тестирование - это  одновременное изучение продукта и  его тестирование. Это самый свободный  из этапов. Главной целью здесь  является изучение, побочной - выявление  и репортинг критичных багов. Здесь не следует отвлекаться на репортинг мелких багов, максимум, что по ним можно сделать - это неформальные заметки в блокноте.

 

Действия, которые можно предпринять  на этом этапе:

2.1. Чтение внешней документации (учебники, википедия)

2.2. Чтение внутренней документации (требования к ПО, гайды, прочее)

2.3. Привлечение специалиста (авторитетного  лица проекта), который может продемонстрировать  работу ПО 

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

2.4. Проверка всех возможностей  ПО. Пользователю ПО доступны, как  правило, три вида интерфейса:

 GUI - следует открыть важные экраны и диалоги графического интерфейса

 CLI - попробовать основные ключи интерфейса командной строки

 API - вызвать основные методы API

Здесь следует тестировать вширь, а не вглубь, стараясь охватить интерфейс  приложения по максимуму, пусть и  поверхностно.

2.5. Ad-hoc тестирование. Ad hoc означает "Для этого", для специальной цели. Если нам пришло в голову провести какую-то специальную проверку и такая проверка может вскрыть критичный баг, следует ее провести сейчас.

3. Тестирование базовых сценариев

На этом этапе нужно проверить  все базовые сценарии, описанные  в требованиях, при типичных или  дефолтных настройках. Если пользоваться моделью конечного автомата в виде графа, таким образом мы проверим наиболее важные пути в графе. См. Boris Beizer, Black-Box Testing.

 

Кроме того, мы должны протестировать операции CRUD над всеми объектами программы (или ее части, если мы тестируем новую функциональность для существующего ПО), с типичными или дефолтными настройками.

4.Анализ тенденций

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

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