Home

Меня зовут Юрий Заковряшин. Я занимаюсь разработкой ПО более 40 лет, преподаю курсы по технологиям разработки программного обеспечения и программированию на платформе Java в СПбПУ Петра Великого.

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

Какие бывают характеристики

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

Количественной характеристикой программной системы называется ее свойство, которое можно измерить и выразить числом. С ним тесно связано понятие метрики — меры, позволяющей получить численное значение этого свойства. В тестировании с метрикой связываются единица измерения, метод измерения и критерий приемлемости значения метрики. Количественные характеристики программных систем — это, например, количество элементов пользовательского интерфейса, объем занимаемой оперативной памяти, скорость передачи данных. Замечу, что характеристики, имеющие логические значения, также относятся к количественным, потому что легко сводятся к численной оценке — например, по правилу «ложь = 0, истина = 1».

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

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

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

Протестируем качественные характеристики

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

Что с ним не так? Дело в том, что, если нет пояснений, детализирующих и конкретизирующих это требование, его нельзя протестировать в принципе! Попытка написать тест вида «Проверка интуитивной понятности пользовательского интерфейса…» может ввергнуть тестового инженера в глубокую депрессию и вызвать настоятельную необходимость посетить психиатра. Почему? Попробуем разобраться.

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

Что же делать, когда всё-таки нужно проверить подобное требование? Для решения этой задачи можно предложить следующий общий алгоритм, который в терминах таблицы выше можно выразить последовательностью преобразований:

QII → QI → MII → M1.         

Рассмотрим этот алгоритм более подробно в виде последовательности шагов.

Шаг 1. Выявляем неопределенные характеристики

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

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

2. Выделение на основе ключевых слов. Качественные характеристики описываются характерными словами, например «удобство», «информативность», «доступность», «логичность», «корректность». Список подобных ключевых слов можно оформить в виде справочника, который можно использовать при автоматизации тестов. Замечу, что первый подход неявно или интуитивно основан на втором.

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

Шаг 2. Снижаем неопределенность

На втором этапе следует максимально конкретизировать качественные характеристики и представить их в наиболее простом виде. Другими словами, нужно характеристики класса QII привести к классу QI. Самый очевидный прием такого преобразования — замена сложной качественной характеристики набором более простых или более конкретных качественных характеристик. Например, «интуитивную понятность» интерфейса можно заменить на «стандартность» и «информативность» интерфейса.

Снизить неопределенность помогают следующие подходы:

1. Уточнение требований к качественным характеристикам системы с помощью заказчиков системы и ее пользователей.

2. Более тщательный анализ предметной области, составление подробной ее модели и словаря предметной области.

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

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

5. Анализ исходного кода системы.

Этот этап на практике бывает самым трудоемким, поэтому работу желательно распределить между разработчиками, выполняющими разные роли. Например, пункты 1, 2 и 3 в идеале должны выполнять разработчики требований (в отечественной практике их роль играют бизнес-аналитики или системные аналитики), пункт 4 — дизайнеры системы (архитекторы, дизайнеры пользовательского интерфейса, разработчики баз данных), пункты 3 и 5 могут частично выполнять тестовые инженеры.

Шаг 3. Заменяем качественные характеристики на количественные

На этом этапе каждая характеристика класса QI преобразуется в набор характеристики класса MII, а затем каждая характеристика класса MII преобразуется в набор характеристик класса MI. Проще говоря, каждая качественная характеристика сводится к набору количественных. Например, характеристику «информативность поля ввода» в конечном счете можно свести к набору хорошо проверяемых количественных характеристик, в число которых входят:

• наличие поясняющей надписи или всплывающей подсказки;

• индикация доступности поля для ввода значений;

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

• наличие указателя текущей позиции ввода;

• сообщения об ошибках ввода.

Шаг 4. Разрабатываем тесты для проверки количественных характеристик

На последнем шаге разрабатываются тесты для всех характеристик классов MI и MII, определенных на предыдущем шаге.

Если стоит задача разработать тест по проверке простой количественной характеристики класса MI, то обобщенный алгоритм разработки теста выглядит следующим образом:

1. Выбираем подходящую метрику для измерения проверяемой величины и единицу ее измерения.

2. Выбираем метод измерения нужной величины.

3. Определяем критерий успешности/приемлемости результата измерений.

4. Разрабатываем и документируем спецификацию теста.

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

1. Выбираем метрику — длину, измеряемую в миллиметрах.

2. Метод измерения — вручную с помощью линейки с миллиметровыми делениями.

3. Критерий приемлемости определяем из спецификации требований заказчика к длине карандаша или выбираем его из документов типа ГОСТов или технических условий.

4. В соответствии с принятыми правилами документируем тест.

Всё это замечательно работает, если речь идет о количественной и простой характеристике. Однако и тестирование сложных количественных характеристик класса MII в целом выполняется по этой же схеме. Различия проявляются лишь в том, что в случае сложных количественных характеристик применяются более сложные метрики, более сложные методы измерений и более сложные критерии приемлемости. Например, если нужно проверить объем карандаша, метрикой будет служить единица объема, измеряемая в кубических миллиметрах. Кроме этого, метод измерения объема карандаша должен включать методы измерения длины, площади основания карандаша и вычисления его объема.

Подведем итоги

Нетрудно заметить, что описанный метод основан на двух хорошо известных подходах. Первый — это принцип декомпозиции сложной задачи на более простые, как повелось еще со времен Древнего Рима: «Разделяй и властвуй». Второй заключается в поэтапной замене сложной качественной характеристики на набор более простых количественных характеристик, что позволяет:

• Относительно просто разрабатывать и выполнять тесты.

• Получать объективные оценки результатов тестов, поскольку они основаны на математически точных операциях сравнения чисел. Это важное преимущество, потому что на практике качественные характеристики часто оцениваются субъективно.

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

Надеюсь, теперь вы знаете один из подходов к этому. Удачи!

Обсудить в форуме