Для чего нужны тесты
Задача, для которой разрабатывается автотест, определяет как дизайн самого теста, так и информацию, которую этот тест должен выдать.
Можно выделить следующие задачи, которые решают тесты:
Нахождение и анализ ошибок
Формальная отчетность
Для анализа и для формальной отчетности информация требуется своя, но иногда удается делать один отчет для нескольких целей.
Разберем каждую задачу и то, какая информация для нее нужна.
Поиск ошибок
Это то, что тесты делают по определению. В любом тесте нужно, чтобы отчет позволял идентифицировать тестовые сценарии, а также софт и оборудование, которое тестировалось. А также при анализе ошибок полезно иметь подробные логи.
При анализе бага половина всей работы — это чтение логов. Часто, получив задачу и прочитав всё, что прислал тестировщик, обнаруживший дефект, думаешь: «И как только я не додумался до такого кейса?»
Лог теста может содержать ценную информацию для отладки. Для отладки ценны такие подробности, которые обычно скрыты от пользователя: сетевые адреса, 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 знака после запятой по правилам округления? Если задана относительная погрешность, то может получиться ширина интервала с каким-угодно количеством знаков, так что округлять ее придется.
Вот что мы увидим в отчете:
Проверить, что | Фактический результат | Вердикт |
Значение: 2.2 ± 0.2 | Значение было 2.5 | Pass |
Немая сцена.
Я предлагаю сначала округлять числа и приводить к типу с фиксированной запятой, а уже потом их складывать, вычитать и сравнивать. Так вердикт всегда будет соответствовать отображаемому фактическому результату.
Что бывает, если складывать числа с плавающей запятой, читайте, например, тут.
Правдивость
Фальсификация – это любая запись, не соответствующая действительности. Фальсификации бывают умышленными и случайными, но и те, и другие недопустимы.
В ходе ручного тестирования случайные фальсификации возникают из-за невнимательности. Автоматизация избавляет от этого.
Однако, фальсификации также могут возникать и при автоматическом тестировании.
Например, автотест неаккуратно формирует отчет. Причем, таких фальсифицированных отчетов будет столько, сколько раз запустят тест.
Недопустимо ради упрощения писать, например, “пульс был 60”, если он был 59, и это в пределах допустимого отклонения.
Выше я описал, как важно написать в отчете о том, что видна именно кнопка, а не какой-то элемент с заданным текстом. Такими словами нельзя разбрасываться. Писать в отчет тип элемента можно только после соответствующей проверки.
Одно слово в отчете может стоить тысячи строк кода для проверки условия. Если пренебречь этими проверками и просто добавить требуемую фразу в отчет, то получится не фреймворк для тестирования, а инструмент для фальсификаций.
Фальсификации при измерений времени
Значения, фактически присутствующие на экране, мы определяем без случайной погрешности.
Но иногда мы сталкиваемся с требованиями вида ��окно закрывается через 30 секунд». При этом у нас нет интерфейса, чтобы устройство уведомляло нас о закрытии окна. Всё, что мы можем, это проверять, открыто ли окно сейчас, т.е. заниматься поллингом. В таком случае мы знаем время последнего запроса, когда окно еще открыто, и первого запроса, когда уже закрыто. Эти два времени – это границы доверительного интервала времени закрытия окна, которое мы измерили.
Например, 29.5 и 30.5 секунд. Тогда в отчете так и надо писать: «Время было от 29.5 до 30.5 сек» или «30 ± 0.5 сек».
Результаты измерения не имеют смысла без указания погрешности. Некоторые методики измерений обеспечивают неизменную погрешность. Тогда ее можно указать один раз где-нибудь в документации. Но здесь другой случай.
Фальсификации при тестировании цвета
Как пользователь видит цвет? Для пользователя есть, например, красный и зеленый, и такие слова можно встретить в требованиях. А для автоматического теста есть такие цвета, как #FF0000 и #00FF00. Можно ли перевести коды в человекочитаемые названия? #EE0000 – это какой цвет? Красный? Алый? Бордовый? Бурый?
Люди называют одни и те же цвета по-разному.
Восприятие зависит от индивидуальных особенностей сетчатки и мозга. Многие люди не различают какие-то оттенки, и это считается нормой.
Один и тот же цвет может называться по-разному в разных контекстах. Например, на железной дороге официально есть лунно-белый сигнал, а есть молочно-белый. Как их различить, машинисты не понимают.
Кроме того, восприятие определяется опытом и, в частности, родным языком. Так количество цветов в радуге зависит от языка, на котором вы говорите.
Но дело не только в названиях. Люди воспринимают один и тот же цвет по-разному в зависимости от того, что вокруг. На этой картинке клетки, помеченные буквами, одного и того же оттенка. Если не верите, откройте картинку в графическом редакторе и используйте пипетку.
Выходит, даже если выбрать одного представителя из всех пользователей и поселить его в палату мер и весов, даже так не получится определить название цвета как функцию спектра излучения.
В довершение всего, спектр излучения пикселя не является функцией от числа в видеопамяти, если у монитора можно регулировать яркость и контрастность. Так что же теперь, добавлять в тест шаги вида “выкрутить яркость и контрастность на максимум”?
Если мы тестируем софт, а не монитор и видеокарту, то это неоправданное усложнение.
Разумным вариантом видится указывать в тестах непосредственно коды цветов. Можно для перевода кодов в названия ввести соглашения.
Выводы
Покрытие требований тестом
��ля того, чтобы было очевидно, что тест покрывает требование, формулировка отчета должна соответствовать формулировке требования. Чтобы формировать такие отчеты, приходится реализовывать в тестовом инструменте отдельные команды с требуемыми формулировками. Каждая такая команда выполняет особые проверки, соответствующие формулировкам.
Сравнение факта с ожиданием
При сравнении факта с ожиданием учитываются погрешность измерения и допустимый диапазон для фактической величины. Эта информация должна быть в отчете.
Фальсификации
Как в ручном, так и в автоматическом тестировании возможны фальсификации. В автотестах это более серьезная проблема, так как ложные результаты повторяются от запуска к запуску.
Непреднамеренные фальсификации в автотестах происходят из-за того, что при формировании отчета делаются предположения, или опускается часть информации.
Для предотвращения этого при разработке автотестов следует учитывать риск того, что та или иная проверка даст неверный результат. Анализ и снижение этого риска в отдельных случаях занимает большую часть времени разработки.
