Для чего нужны тесты

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

Можно выделить следующие задачи, которые решают тесты:

• Нахождение и анализ ошибок

• Формальная отчетность

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

Разберем каждую задачу и то, какая информация для нее нужна.

Поиск ошибок

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

При анализе бага половина всей работы — это чтение логов. Часто, получив задачу и прочитав всё, что прислал тестировщик, обнаруживший дефект, думаешь: «И как только я не додумался до такого кейса?»

Лог теста может содержать ценную информацию для отладки. Для отладки ценны такие подробности, которые обычно скрыты от пользователя: сетевые адреса, HTTP-запросы, тексты эксепшенов. Если используется распознавание интерфейса на экране, то вместо «кнопка найдена» можно уточнить «координаты кнопки такие‑то», «кликаем по таким‑то координатам».

Формальная отчетность

Мы тестируем медицинское оборудование, поэтому знаем, какие требования закон предъявляет к процессу разработки. Эти требования касаются тестирования. Каждый протокол теста — это документ, который контролирующий орган может проверить.

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

Достоверность

Отчет о тесте – это документ, за достоверность которого тестировщик в ответе. Применяемый в медицине стандарт ISO 15489 и идентичный ему российский ГОСТ требуют, чтобы каждый документ был достоверным.

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

Лишняя информация в отчете

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

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

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

Отчеты с ошибками

В случае ошибки Actual Result должен ее описывать. Для каждой ошибки нужен уникальный текст, понятный пользователю.

Допустим, требуется проверить, что числовое значение на экране равно 40. Варианты ошибок могут быть такими:

• «на экране значение 42» – дает понять, что мы прочитали значение с устройства, и никаких проблем с соединением нет.

• «Не удалось установить соединение» или «Некорректный формат ответа» – значение не удалось прочитать.

На практике не всегда удается так подробно описать фактический результат.

• Например, если мы ищем на экране число 40 и не находим его, то всё, что мы можем сказать – это то, что на экране нет нужного числа. И мы не можем точно сказать, отсутствует ли на экране число или оно не соответствует искомому. Это уже приходится выяснять вручную. Ручной анализ увеличивает стоимость работ.

• При написании кода, читающего число, возникает соблазн в случае ошибки вернуть какое-то особенное число, например, ноль. В данном случае мы имеем дело с фальсификацией. Это более серьезно, чем недостаток информации, описанный в предыдущем пункте.

Формальные отчеты

Для каждой проверки отчет содержит Setup, Verify That, Actual Result и Verdict.

Вот основные правила для любого теста:

• Verify That должен быть таким, как ожидается после выполнения Setup, согласно требованиям, т.е. тест покрывает требование и не требует ничего такого, чего в требованиях нет.

• Вердикт должен быть Pass, если Actual Result соответствует Verify That.

• Actual Result должен быть правдив.

В автоматическом тестировании каждый их этих пунктов представляет определенные сложности.

Покрытие требования тестом

Если в требовании сказано «Кнопка должна быть видна. При нажатии на кнопку должно произойти то‑то и то‑то.», значит, в отчете должно быть «Кнопка видна», «Кнопка нажата».

Если мы говорим о кнопке, то важно, что видна именно кнопка, а не какой-то другой элемент с таким же текстом. Поэтому тест не может обойтись одной командой вида “найти на экране такой-то текст и кликнуть по нему” для всех элементов с текстом. Даже если сценарий может гарантировать, что такого же текста нет больше нигде на экране.

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

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

«Зачем проверять наличие этой кнопки. Она всегда есть,» — сказали нам как-то раз разработчики устройства. В коде продукта нет никаких условий, контролирующих видимость кнопки или ее текст. Так зачем ее проверять? Чиновники из FDA с этим не согласятся. Если есть требование, чтобы кнопка была, значит, нужен на это тест.

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

Сравнение факта с ожиданием

Ожидание и факт должны быть отражены таким образом, чтобы было очевидно, почему pass или почему fail.

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

Будьте осторожнее с округлением.

Допустим, требуемый интервал 2.24 ± 0.24, а фактическое значение 2.47. Вердикт: Pass. Пока всё логично.

Но что если для отчета вы округлите все числа до 1 знака после запятой по правилам округления? Если задана относительная погрешность, то может получиться ширина интервала с каким-угодно количеством знаков, так что округлять ее придется.

Вот что мы увидим в отчете:

Немая сцена.

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

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

Правдивость

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

В ходе ручного тестирования случайные фальсификации возникают из-за невнимательности. Автоматизация избавляет от этого.

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

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

• Недопустимо ради упрощения писать, например, “пульс был 60”, если он был 59, и это в пределах допустимого отклонения.

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

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

Фальсификации при измерений времени

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

Но иногда мы сталкиваемся с требованиями вида «окно закрывается через 30 секунд». При этом у нас нет интерфейса, чтобы устройство уведомляло нас о закрытии окна. Всё, что мы можем, это проверять, открыто ли окно сейчас, т.е. заниматься поллингом. В таком случае мы знаем время последнего запроса, когда окно еще открыто, и первого запроса, когда уже закрыто. Эти два времени – это границы доверительного интервала времени закрытия окна, которое мы измерили.

Например, 29.5 и 30.5 секунд. Тогда в отчете так и надо писать: «Время было от 29.5 до 30.5 сек» или «30 ± 0.5 сек».

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

Фальсификации при тестировании цвета

Как пользователь видит цвет? Для пользователя есть, например, красный и зеленый, и такие слова можно встретить в требованиях. А для автоматического теста есть такие цвета, как #FF0000 и #00FF00. Можно ли перевести коды в человекочитаемые названия? #EE0000 – это какой цвет? Красный? Алый? Бордовый? Бурый?

Люди называют одни и те же цвета по-разному.

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

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

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

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

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

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

Если мы тестируем софт, а не монитор и видеокарту, то это неоправданное усложнение.

Разумным вариантом видится указывать в тестах непосредственно коды цветов. Можно для перевода кодов в названия ввести соглашения.

Выводы

Покрытие требований тестом

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

Сравнение факта с ожиданием

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

Фальсификации

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

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

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