Часть первая
Слово Канеру:
Техники тестирования основанные на том, что тестируется.
Тестирование репрезентативных значений Репрезентативные значения класса эквивалентности те, которые чаще приводили к ошибкам. В тестировании граничных значений - граничные значения всегда наиболее репрезентативны. Но предположим, что вы не можете отобразить класс эквивалентности на числовую ось. Например принтеры Hewlett-Packard PCL-5 являются классом эквивалентности, потому как должны работать одним и тем же образом. Теперь предположим, что для конкретной задачи один из принтеров имеет немного больше шансов заполучить проблему, чем другие. Это принтер и будет репрезентативным значением класса, и если он нас не подведет - не подведут и остальные.
Тестовая матрица для полей ввода Для каждого типа поля ввода ты можешь разработать достаточно стандартный набор кейсов и использовать их в этом и других продуктах. Пример мы приведем далее в этой главе.
Карта и проверка всех способов редактирования полей Часто есть возможность изменить значение переменной несколькими путями. Например, есть способ импортировать данные в поле, ввести значение напрямую, скопировать результат в поле, поле может программно вычисляться и перевычисляться автоматически и так далее. Поле имеет ограничения. Некоторые ограничения могут быть постоянными, друггие могут меняться в зависимости от значений в соседних полях. Например, если J и K - целые положительные числа, они ограничены значениями от 0 до MaxInt. Это постоянное ограничение, зависящее от языка программирования. Предположим, что N тоже положительное целое, N = J + K, и если N=5, то J = 5 − K, и J не может быть больше 5(значение N). Это меняющееся ограничение, чей диапазон допустимых значений зависит от N. Чтоб проверить, что J находится в диапазоне допустимых значений (5-K) мы должны попытаться изменить его значение в каждом возможном направлении.
Логическое тестирование Переменные имеют зависимости в программе. Например, в программе может быть правило, которое говорит, что если PERSON-AGE больше 50 и если SMOKER = YES, то OFFER-INSURANCE должно быть равно NO. Правило выражает логическую зависимость. Логическое тестирование пытается проверить все логические зависимости в программе. График причинно-следственных связей - техника проектирования широкого набора тестов основанных на логике системы.
Тестирование состояний Программа двигается от состояния к состоянию. В данном состоянии некоторые входные данные корректны, другие будут проигнорированы или отклонены. В ответ на валидные входные данные тестируемая программа делает то, что может и не пытается делать то, что не должна. В тестировании состояний мы ходим по программе согласно большому набору переходов между состояниями и тщательно проверяем результаты на каждом шаге.
Тестирование путей Путь включает все шаги, что ты совершил и все состояния через которые прошел, чтоб дойти до текущего состояния. Тестирование путей включает в себя тестирование множества путей в пhограмме. Нельзя проверить все пути в нетривиальной программе. Некоторые тестировщики проводят тестирование "подпутей" - тестирование частей пути. Тестирование базовых путей включает в себя все подпути одного типа, предполагая, что вы тестируете эти длинные пути, чтоб найти ошибки, которые пропустили более мелкие тесты.
Покрытие линий и ветвей кода Вы достигли 100% покрытия, если ваши тесты исполняют каждую линию или ветвь кода программы. Проектирование тестов для достижения покрытия называют "Тестирование основанное на покрытии" (После того, как вы достигли этого вы можете прекратить тестирование или прекратить создание новых тестов). Мы называем это покрытием строк и ветвей кода, чтоб отличить от других типов тестирования, основанных на покрытии. Покрытие конфигураций - отличный пример техники, которая проверяет один и тот же код несколько раз, но при этом все равно может потенциально привести к отличным результатам. Есть много других примеров. Для тестирования основанного на достижении высокого покрытия строк и ветвей кода характерно упущение многих видов ошибок, таких как(но не только) баги с участием пропущенного кода, баги некорректного обращения с граничными значениями, проблемы со временем, проблемы с совместимостью с железом и ПО, баги delayed-fuse, такие как дикие указатели, утечки памяти или stack corruption, которые в конечном счете ведут к переполнению стека, проблемы юзабилити и другие неисправности с точки зрения заказчика. Эта техника является более ценной в плане выявления неполноты тестирования (какой код сейчас не тестируется), как стандарт минимального необходимого объема тестирования. И в действительности опасно, если тестировщики останавливаются только потому, что они достигли определенного процента покрытия (Marick 1999).
Покрытие конфигураций Вам нужно протестировать совместимость 100 принтеров, а вы проверили 10, вы достигли 10% покрытия конфигураций. В общем виде, покрытие конфигураций означает процент конфигураций, на которых запускались и успешно прошли ваши тесты в сравнении с общим числом конфигураций, на котором вы запланировали запустить тесты. Почему мы назвали это техникой тестирования? Обычно мы считаем, что это просто мера - сколько определенных типов тестов мы повели. Однако сами тестировщики создают специальные серии тестов, которые работают с большим объемом конфигураций быстро и просто. В их руках оптимизация тестов для достижения большого покрытия становится техникой.
Тестирование спецификаций Тестирование, сфокусированное на каждом минимальном фактическом требовании к продукту, которое можно получить из спецификаций (Фактическое требование - это то, что для определенного состояния продукта может быть представлено в виде "да" или "нет"). Оно часто включает в себя проверку всех утверждений, сделанных в руководстве пользователя, рекламе, технической литературе или письме заказчику.
Тестирование требований Тестирование сфокусированное на том, насколько программа удовлетворяет требованиям (как вариант доказательство того, что требования выполнить нельзя).
Комбинированное тестирование Тестирование двух или более переменных в комбинации. Мы поговорим об этом позднее в этой главе. Это важный вид тестирования, но многие тестировщики пренебрегают им. Профит от программ обычно заключается как раз во взаимодействии множества переменных и если вы не не учитываете это в тестах, то имеете шанс пропустить множество ошибок, вызванных сочетанием значений нескольких переменных, а не значением одной.
Комментариев нет:
Отправить комментарий