Презентация на тему Содержание:

значений
Покрытие кода

2

и/или
• потенциальным дефектом (failure) в системе

на разных уровнях – от отдельных функций до целого

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

Почему?

том, что другие переменные/комбинации из того же диапазона приведут

к аналогичному результату.
Увеличивает тестовое покрытие

Parallels Confidential

и тому же результату.
- Они тестируют одну и ту

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

Prallels

которым ПО применяет одинаковую логику.

классов эквивалентности.



Confideial

к какому классу будет относиться каждая граница.
Определить уникальные данные

(исключения)
Для каждой границы нам нужно провести тесты по проверке значения до границы, на границе, и сразу после границы.

протестирован.
Виды:
Покрытие требований к ПО (на основе спецификаций, документаций, здравого

смысла)
Покрытие кода (белый ящик)

Parallels Confidential

Tcov = (Lcov/Ltotal) * 100%
где:
Tcov - тестовое покрытие
Lcov - количество требований, проверяемых тест кейсами
Ltotal - общее количество требований

Tcov = (Ltc/Lcode) * 100%
где:
Tcov - тестовое покрытие
Ltc - кол-ва строк кода, покрытых тестами
Lcode - общее кол-во строк кода.

должен быть выполнен хотя бы один раз.
В данном

фрагменте кода входными переменными являются prev и ShowMessage.

if (prev == "оператор" || prev == "унарный оператор") {
if (ShowMessage) {
MessageBox.Show(“text1");
} else {
Log.Write(" text2 ");
}
Program.res = 4;
return "&Error 04";
}

входа и выхода в программе и во всех ее

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

первый условный оператор if имеет неявную ветвь – пустую ветвь else. Для обеспечения покрытия по ветвям необходимо покрывать и пустые ветви.

условия в результате выполнения тестовых примеров должна принимать все

возможные значения, но при этом не требуется, чтобы само логическое условие принимало все возможные значения. 

if (condition1 || condition2)
MethodA();
else
MethodB();

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

его компонента приняла все возможные значения.

if (condition1 || condition2)
MethodA();
else
MethodB();

все возможные наборы значений компонент логических условий. Т.е. в

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

Метод редко применяется на практике в связи с его сложностью и избыточностью.

при 3-м уровне покрытия кода (Для уменьшения количества тестовых

примеров Modified Condition/Decision Coverage )
Для обеспечения полного покрытия по этому методу необходимо выполнение следующих условий:
каждое логическое условие должно принимать все возможные значения;
каждая компонента логического условия должна хотя бы один раз принимать все возможные значения;
должно быть показано независимое влияние каждой из компонент на значение логического условия, т.е. влияние при фиксированных значениях остальных компонент.
Покрытие по этой метрике требует достаточно большого количества тестов для того, чтобы проверить каждое условие, которое может повлиять на результат выражения, однако это количество значительно меньше, чем требуемое для метода покрытия по всем условиям.

{
...
}
else
{

...
}
}

Для тестирования первого условия по MC/DC надо показать независимость результата (т.е. функции A || B ) от каждого аргумента. Соответственно, для этого используются три тестовых примера:

A = 0, B = 0, A || B = 0 (начальное значение)
A = 1, B = 0, A || B = 1 (показано влияние аргумента A )
A = 0, B = 1, A || B = 1 (показано влияние аргумента B )

Для тестирования ветвей (входящего в MC/DC) в зависимости от условия C необходимо, чтобы в тестовых примерах C принимало значение как true, так и false.

после полного покрытия требований. 
Полное покрытие программного кода не гарантирует

того, что тесты проверяют все требования к системе.

как минимум один раз.
покрытие условий: каждое условие, имеющее TRUE

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

тестами, выражается в %. 100% покрытие означает, что каждая

строка кода была вызвана в тестах хотя бы один раз.

кода (функций или методов), содержащий для каждого структурного элемента

информацию:

Название функции или метода
Тип покрытия (по строкам, по ветвям, MC/DC или иной)
Количество покрываемых элементов в функции или методе (строк, ветвей, логических условий)
Степень покрытия функции или метода (в процентах или в абсолютном выражении)
Список непокрытых элементов (в виде участков непокрытого программного кода с номерами строк)
Заголовочную информацию и общий итог - общую степень покрытия всех функций, для которых собирается информация о покрытии.

Parallels Confidential

UI
структурное покрытие - каждый UI элемент должен быть использован

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

Parallels Confidential

интерфейсу;
разработка тест-требований и тест-планов для проверки пользовательского интерфейса;
выполнение тест-кейсов

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

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

функциональности системы при помощи пользовательского интерфейса.

Требования к размещению элементов управления на экранных формах

Требования к содержанию и оформлению выводимых сообщений

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

Требования к времени отклика на команды пользователя

Требования к форматам ввода, в т.ч. определяющие реакцию системы на некорректный ввод.

:
легкость обучения - быстро ли человек учится использовать систему;
эффективность

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

формулирования требований к системе и разработки прототипа интерфейса.
Оценочное

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

с реальным миром (терминология)
Пользовательское управление и свобода действий (дуракоустойчивость)
Целостность

и стандарты (терминология).
Помощь пользователям в распознавании, диагностике и устранении ошибок.
Предотвращение ошибок (дизайн + валидация)
Распознавание, а не вспоминание.
Гибкость и эффективность использования (hotkeys).
Эстетичный и минимально необходимый дизайн.
Помощь и документация.