Требования к
Для нетривиальных классов программ в общем случае не существует полного и надежного критерия, зависящего от программ или спецификаций.
Поэтому мы стремимся к идеальному общему критерию через реальные частные.
На приведен пример простой программы. Рассмотрим условия ее тестирования в соответствии со
1 public void Method (ref int x)
{
2 if (x>17)
3 x = 17-x;
4 if (x==-13)
5 x = 0;
6 }
1 void Method (int *x)
{
2 if (*x>17)
3 *x = 17-*x;
4 if (*x==-13)
5 *x = 0;
6 }
Тестовый набор из одного теста, удовлетворяет критерию команд (C0):
(X,Y)={(xвх=30, xвых=0)} покрывает все операторы трассы 1-2-3-4-5-6
Тестовый набор из двух тестов, удовлетворяет критерию ветвей (C1):
(X,Y)={(30,0), (17,17)} добавляет 1 тест к множеству тестов для С0 и трассу 1-2-4-6. Трасса 1-2-3-4-5-6 проходит через все ветви достижимые в операторах if при условии true, а трасса 1-2-4-6 через все ветви, достижимые в операторах if при условии false.
Тестовый набор из четырех тестов, удовлетворяет критерию путей (C2):
(X,Y)={(30,0), (17,17), (-13,0), (21,-4)}
Набор условий для двух операторов
| (30,0) | (17,17) | (-13,0) | (21,-4) | |
2 if (x>17) |
> |
$$\le$$ | $$\le$$ | > |
4 if (x==-13) |
$$\ne$$ | $$\ne$$ | = |
$$\ne$$ |
Критерий путей С2 проверяет программу более тщательно, чем критерии - C1, однако даже если он удовлетворен, нет оснований утверждать, что программа реализована в соответствии со спецификацией.
Например, если спецификация задает условие, что |x|<=100, невыполнимость которого можно подтвердить на тесте (-177,-177). Действительно, операторы 3 и 4 на тесте (-177,-177) не изменят величину х=-177 и результат не будет соответствовать спецификации.
Ниже приведены частные виды
Тестирование пунктов спецификации - набор тестов в совокупности должен обеспечить проверку каждого тестируемого пункта не менее одного раза.
Спецификация требований может содержать сотни и тысячи пунктов требований к программному продукту и каждое из этих требований при тестировании должно быть проверено в соответствии с критерием не менее чем одним тестом
Тестирование классов входных данных - набор тестов в совокупности должен обеспечить проверку представителя каждого класса входных данных не менее одного раза.
При создании тестов классы входных данных сопоставляются с режимами использования тестируемого компонента или подсистемы приложения, что заметно сокращает варианты перебора, учитываемые при разработке тестовых наборов. Следует заметить, что перебирая в соответствии с критерием величины входных переменных (например, различные файлы - источники входных данных), мы вынуждены применять мощные тестовые наборы. Действительно, наряду с ограничениями на величины входных данных, существуют ограничения на величины входных данных во всевозможных комбинациях, в том числе проверка реакций системы на появление ошибок в значениях или структурах входных данных. Учет этого многообразия - процесс трудоемкий, что создает сложности для применения критерия
Тестирование правил - набор тестов в совокупности должен обеспечить проверку каждого правила, если входные и выходные значения описываются набором правил некоторой грамматики.
Следует заметить, что грамматика должна быть достаточно простой, чтобы трудоемкость разработки соответствующего набора тестов была реальной (вписывалась в сроки и штат специалистов, выделенных для реализации
Тестирование классов выходных данных - набор тестов в совокупности должен обеспечить проверку представителя каждого выходного класса, при условии, что выходные результаты заранее расклассифицированы, причем отдельные классы результатов учитывают, в том числе, ограничения на ресурсы или на время (time out).
При создании тестов классы выходных данных сопоставляются с режимами использования тестируемого компонента или подсистемы, что заметно сокращает варианты перебора, учитываемые при разработке тестовых наборов.
Тестирование функций - набор тестов в совокупности должен обеспечить проверку каждого действия, реализуемого тестируемым модулем, не менее одного раза.
Очень популярный на практике критерий, который, однако, не обеспечивает покрытия части функциональности тестируемого компонента, связанной со структурными и поведенческими свойствами, описание которых не сосредоточено в отдельных функциях (т.е. описание рассредоточено по компоненту).
Критерий тестирования функций объединяет отчасти особенности
Комбинированные критерии для программ и спецификаций - набор тестов в совокупности должен обеспечить проверку всех комбинаций непротиворечивых условий программ и спецификаций не менее одного раза.
При этом все комбинации непротиворечивых условий надо подтвердить, а условия противоречий следует обнаружить и ликвидировать.
Пусть для решения задачи тестирования системы "Система управления автоматизированным комплексом хранения подшипников" (см. Приложение 1, FS) был разработан следующий фрагмент спецификации требований:
GetStoreStat ). Добавить в журнал сообщений запись "СИСТЕМА : Запрошен статус СКЛАДА". В зависимости от полученного значения произвести следующие действия:GetRollerPar ).Значение, возвращенное функцией GetRollerPar |
Действия системы |
|---|---|
| ... | ... |
| 0 | GetR - "ПОЛУЧИТЬ ИЗ ПРИЕМНИКА В ЯЧЕЙКУ" |
| 1 | Добавить в журнал сообщений запись "ТЕРМИНАЛ ПОДШИПНИКА: 1 - нет данных" |
| ... | ... |
Значение, возвращенное функцией GetAxlePar |
Действия системы |
|---|---|
| ... | ... |
| 1 | Добавить в журнал сообщений запись "ТЕРМИНАЛ ОСИ: 1 - нет данных" |
| ... | ... |
Определим классы входных данных для параметра - статус склада:
Теперь рассмотрим тестовые случаи:
Тестовый случай 1 (покрывает класс 4):
Состояние окружения (входные данные - X ):
Статус склада - 32.
...
Ожидаемая последовательность событий (выходные данные - Y ):
Система запрашивает статус склада (вызов функции GetStoreStat ) и получает 32
...
Тестовый случай 2 (покрывает класс 5):
Состояние окружения (входные данные - X ):
Статус склада - 12dfga.
...
Ожидаемая последовательность событий (выходные данные - Y ):
Система запрашивает статус склада (вызов функции GetStoreStat ) и согласно пункту спецификации при ошибочном значении статуса склада в журнал добавляется сообщение "СКЛАД : ОШИБКА : Неопределенный статус".
...
(X,Y) имеет громадную мощность. В случаях, когда подобный набор невозможно разработать и исполнить на
{x}.{y} для соответствующих входных сигналов {x} и получить тестовый набор (X,Y).(X,Y), используя два способа контроля результатов:y, полученному в результате {x} - случайной последовательности входных сигналов, сгенерированной имитатором.Стохастический контроль - проверка соответствия множества значений {yв}, полученного в результате прогона тестов на наборе входных значений {x}, заранее известному распределению результатов F(Y).
В этом случае множество Y неизвестно (его вычисление невозможно), но известен закон распределения данного множества.
Критерии
St ), метод Хи-квадрат ( $$\chi ^{2}$$ ) и т.п.
(рис 3.1) Зависимость скорости выявления ошибок от времени выявления
При формализации модели скорости выявления ошибок (рис 3.1) использовались следующие обозначения:
N - исходное число ошибок в программном комплексе перед тестированием,
C - константа снижения скорости выявления ошибок за счет нахождения очередной ошибки,
t1, t2,… tn - кортеж возрастающих интервалов обнаружения последовательности из n ошибок,
T - время выявления n ошибок.
Если допустить, что за время T выявлено n ошибок, то справедливо соотношение (1), утверждающее, что произведение скорости выявления i ошибки и времени выявления i ошибки есть 1 по определению:
(1) (N-i+1)*C*ti = 1
В этом предположении справедливо соотношение (2) для n ошибок:
Если из (1) определить ti и просуммировать от 1 до n, то придем к соотношению (3) для времени T выявления n ошибок
Если из (2) выразить C, приходим к соотношению (4):
Наконец, подставляя C в (3), получаем окончательное соотношение (5), удобное для оценок:
Если оценить величину , или данные о t1, t2 … tn, полученные на tn+1 -временного интервала необходимого для нахождения и исправления очередной ошибки (будущей ошибки).
Если tn+1>Td - допустимого времени тестирования проекта, то тестирование заканчиваем, в противном случае продолжаем поиск ошибок.
Наблюдая последовательность интервалов ошибок t1, t2 … tn, и время, потраченное на выявление n ошибок $$T=\Sigma t_{i}$$, можно прогнозировать интервал времени до следующей ошибки и уточнять в соответствии с (4) величину C.
Критерий Moranda очень практичен, так как опирается на информацию, традиционно собираемую в процессе тестирования.
Постулируется, что профессиональные программисты пишут сразу почти правильные программы, отличающиеся от правильных мелкими ошибками или описками типа - перестановка местами максимальных значений индексов в описании массивов, ошибки в знаках арифметических операций, занижение или завышение границы цикла на 1 и т.п. Предлагается подход, позволяющий на основе мелких ошибок оценить общее число ошибок, оставшихся в программе.
Подход базируется на следующих понятиях:
Метод мутационного тестирования - в разрабатываемую программу P вносят P1, P2... Затем программа P и ее (X,Y).
Если на наборе (X,Y) подтверждается P и, кроме того, выявляются все внесенные в программы-
Если некоторые (X,Y) и продолжать тестирование.
Тестируемая программа . Для нее создается две программы-мутанта P1 и P2.
В ).
В ).
При запуске тестов (X,Y) = {(x=2,n=3,y=8),(x=999,n=1,y=999), (x=0,n=100,y=0 } выявляются все ошибки в программах-мутантах и ошибка в основной программе, где в условии цикла вместо n стоит n-1:
// Метод вычисляет неотрицательную
// степень n числа x
static public double PowerNonNeg(
double x, int n)
{
double z=1;
if (n>0)
{
for (int i=1;n-1>=i;i++)
{
z = z*x;
}
}
else Console.WriteLine(
"Ошибка ! Степень числа n должна
быть больше 0.");
return z;
}
double PowerNonNeg(double x, int n)
{
double z=1;
int i;
if (n>0)
{
for (i=1;n-1>=i;i++)
{
z = z*x;
}
}
else printf(
"Ошибка ! Степень числа n должна
быть больше 0.\n");
return z;
}
Измененное начальное значение переменной z в z=2 ):
// Метод вычисляет неотрицательную
// степень n числа x
static public double PowerMutant1(
double x, int n)
{
double z=2;
if (n>0)
{
for (int i=1;n>=i;i++)
{
z = z*x;
}
}
else Console.WriteLine(
"Ошибка ! Степень числа n должна
быть больше 0.");
return z;
}
double PowerMutant1(double x, int n)
{
double z=2;
int i;
if (n>0)
{
for (i=1;n>=i;i++)
{
z = z*x;
}
}
else printf(
"Ошибка ! Степень числа n должна
быть больше 0.\n");
return z;
}
Измененное начальное значение переменной i и границы цикла в i=0;n-1 ):
// Метод вычисляет неотрицательную
// степень n числа x
static public double PowerMutant2(
double x, int n)
{
double z=1;
if (n>0)
{
for (int i=0;n-1>=i;i++)
{
z = z*x;
}
}
else Console.WriteLine(
"Ошибка ! Степень числа n должна
быть больше 0");
return z;
}
double PowerMutant2(double x, int n)
{
double z=1;
int i;
if (n>0)
{
for (i=0;n-1>=i;i++)
{
z = z*x;
}
}
else printf(
"Ошибка ! Степень числа n должна
быть больше 0.\n");
return z;
}
Требования к
Для нетривиальных классов программ в общем случае не существует полного и надежного критерия, зависящего от программ или спецификаций.
Поэтому мы стремимся к идеальному общему критерию через реальные частные.
На приведен пример простой программы. Рассмотрим условия ее тестирования в соответствии со
1 public void Method (ref int x)
{
2 if (x>17)
3 x = 17-x;
4 if (x==-13)
5 x = 0;
6 }
1 void Method (int *x)
{
2 if (*x>17)
3 *x = 17-*x;
4 if (*x==-13)
5 *x = 0;
6 }
Тестовый набор из одного теста, удовлетворяет критерию команд (C0):
(X,Y)={(xвх=30, xвых=0)} покрывает все операторы трассы 1-2-3-4-5-6
Тестовый набор из двух тестов, удовлетворяет критерию ветвей (C1):
(X,Y)={(30,0), (17,17)} добавляет 1 тест к множеству тестов для С0 и трассу 1-2-4-6. Трасса 1-2-3-4-5-6 проходит через все ветви достижимые в операторах if при условии true, а трасса 1-2-4-6 через все ветви, достижимые в операторах if при условии false.
Тестовый набор из четырех тестов, удовлетворяет критерию путей (C2):
(X,Y)={(30,0), (17,17), (-13,0), (21,-4)}
Набор условий для двух операторов
| (30,0) | (17,17) | (-13,0) | (21,-4) | |
2 if (x>17) |
> |
$$\le$$ | $$\le$$ | > |
4 if (x==-13) |
$$\ne$$ | $$\ne$$ | = |
$$\ne$$ |
Критерий путей С2 проверяет программу более тщательно, чем критерии - C1, однако даже если он удовлетворен, нет оснований утверждать, что программа реализована в соответствии со спецификацией.
Например, если спецификация задает условие, что |x|<=100, невыполнимость которого можно подтвердить на тесте (-177,-177). Действительно, операторы 3 и 4 на тесте (-177,-177) не изменят величину х=-177 и результат не будет соответствовать спецификации.
Ниже приведены частные виды
Тестирование пунктов спецификации - набор тестов в совокупности должен обеспечить проверку каждого тестируемого пункта не менее одного раза.
Спецификация требований может содержать сотни и тысячи пунктов требований к программному продукту и каждое из этих требований при тестировании должно быть проверено в соответствии с критерием не менее чем одним тестом
Тестирование классов входных данных - набор тестов в совокупности должен обеспечить проверку представителя каждого класса входных данных не менее одного раза.
При создании тестов классы входных данных сопоставляются с режимами использования тестируемого компонента или подсистемы приложения, что заметно сокращает варианты перебора, учитываемые при разработке тестовых наборов. Следует заметить, что перебирая в соответствии с критерием величины входных переменных (например, различные файлы - источники входных данных), мы вынуждены применять мощные тестовые наборы. Действительно, наряду с ограничениями на величины входных данных, существуют ограничения на величины входных данных во всевозможных комбинациях, в том числе проверка реакций системы на появление ошибок в значениях или структурах входных данных. Учет этого многообразия - процесс трудоемкий, что создает сложности для применения критерия
Тестирование правил - набор тестов в совокупности должен обеспечить проверку каждого правила, если входные и выходные значения описываются набором правил некоторой грамматики.
Следует заметить, что грамматика должна быть достаточно простой, чтобы трудоемкость разработки соответствующего набора тестов была реальной (вписывалась в сроки и штат специалистов, выделенных для реализации
Тестирование классов выходных данных - набор тестов в совокупности должен обеспечить проверку представителя каждого выходного класса, при условии, что выходные результаты заранее расклассифицированы, причем отдельные классы результатов учитывают, в том числе, ограничения на ресурсы или на время (time out).
При создании тестов классы выходных данных сопоставляются с режимами использования тестируемого компонента или подсистемы, что заметно сокращает варианты перебора, учитываемые при разработке тестовых наборов.
Тестирование функций - набор тестов в совокупности должен обеспечить проверку каждого действия, реализуемого тестируемым модулем, не менее одного раза.
Очень популярный на практике критерий, который, однако, не обеспечивает покрытия части функциональности тестируемого компонента, связанной со структурными и поведенческими свойствами, описание которых не сосредоточено в отдельных функциях (т.е. описание рассредоточено по компоненту).
Критерий тестирования функций объединяет отчасти особенности
Комбинированные критерии для программ и спецификаций - набор тестов в совокупности должен обеспечить проверку всех комбинаций непротиворечивых условий программ и спецификаций не менее одного раза.
При этом все комбинации непротиворечивых условий надо подтвердить, а условия противоречий следует обнаружить и ликвидировать.
Пусть для решения задачи тестирования системы "Система управления автоматизированным комплексом хранения подшипников" (см. Приложение 1, FS) был разработан следующий фрагмент спецификации требований:
GetStoreStat ). Добавить в журнал сообщений запись "СИСТЕМА : Запрошен статус СКЛАДА". В зависимости от полученного значения произвести следующие действия:GetRollerPar ).Значение, возвращенное функцией GetRollerPar |
Действия системы |
|---|---|
| ... | ... |
| 0 | GetR - "ПОЛУЧИТЬ ИЗ ПРИЕМНИКА В ЯЧЕЙКУ" |
| 1 | Добавить в журнал сообщений запись "ТЕРМИНАЛ ПОДШИПНИКА: 1 - нет данных" |
| ... | ... |
Значение, возвращенное функцией GetAxlePar |
Действия системы |
|---|---|
| ... | ... |
| 1 | Добавить в журнал сообщений запись "ТЕРМИНАЛ ОСИ: 1 - нет данных" |
| ... | ... |
Определим классы входных данных для параметра - статус склада:
Теперь рассмотрим тестовые случаи:
Тестовый случай 1 (покрывает класс 4):
Состояние окружения (входные данные - X ):
Статус склада - 32.
...
Ожидаемая последовательность событий (выходные данные - Y ):
Система запрашивает статус склада (вызов функции GetStoreStat ) и получает 32
...
Тестовый случай 2 (покрывает класс 5):
Состояние окружения (входные данные - X ):
Статус склада - 12dfga.
...
Ожидаемая последовательность событий (выходные данные - Y ):
Система запрашивает статус склада (вызов функции GetStoreStat ) и согласно пункту спецификации при ошибочном значении статуса склада в журнал добавляется сообщение "СКЛАД : ОШИБКА : Неопределенный статус".
...
(X,Y) имеет громадную мощность. В случаях, когда подобный набор невозможно разработать и исполнить на
{x}.{y} для соответствующих входных сигналов {x} и получить тестовый набор (X,Y).(X,Y), используя два способа контроля результатов:y, полученному в результате {x} - случайной последовательности входных сигналов, сгенерированной имитатором.Стохастический контроль - проверка соответствия множества значений {yв}, полученного в результате прогона тестов на наборе входных значений {x}, заранее известному распределению результатов F(Y).
В этом случае множество Y неизвестно (его вычисление невозможно), но известен закон распределения данного множества.
Критерии
St ), метод Хи-квадрат ( $$\chi ^{2}$$ ) и т.п.
(рис 3.1) Зависимость скорости выявления ошибок от времени выявления
При формализации модели скорости выявления ошибок (рис 3.1) использовались следующие обозначения:
N - исходное число ошибок в программном комплексе перед тестированием,
C - константа снижения скорости выявления ошибок за счет нахождения очередной ошибки,
t1, t2,… tn - кортеж возрастающих интервалов обнаружения последовательности из n ошибок,
T - время выявления n ошибок.
Если допустить, что за время T выявлено n ошибок, то справедливо соотношение (1), утверждающее, что произведение скорости выявления i ошибки и времени выявления i ошибки есть 1 по определению:
(1) (N-i+1)*C*ti = 1
В этом предположении справедливо соотношение (2) для n ошибок:
Если из (1) определить ti и просуммировать от 1 до n, то придем к соотношению (3) для времени T выявления n ошибок
Если из (2) выразить C, приходим к соотношению (4):
Наконец, подставляя C в (3), получаем окончательное соотношение (5), удобное для оценок:
Если оценить величину , или данные о t1, t2 … tn, полученные на tn+1 -временного интервала необходимого для нахождения и исправления очередной ошибки (будущей ошибки).
Если tn+1>Td - допустимого времени тестирования проекта, то тестирование заканчиваем, в противном случае продолжаем поиск ошибок.
Наблюдая последовательность интервалов ошибок t1, t2 … tn, и время, потраченное на выявление n ошибок $$T=\Sigma t_{i}$$, можно прогнозировать интервал времени до следующей ошибки и уточнять в соответствии с (4) величину C.
Критерий Moranda очень практичен, так как опирается на информацию, традиционно собираемую в процессе тестирования.
Постулируется, что профессиональные программисты пишут сразу почти правильные программы, отличающиеся от правильных мелкими ошибками или описками типа - перестановка местами максимальных значений индексов в описании массивов, ошибки в знаках арифметических операций, занижение или завышение границы цикла на 1 и т.п. Предлагается подход, позволяющий на основе мелких ошибок оценить общее число ошибок, оставшихся в программе.
Подход базируется на следующих понятиях:
Метод мутационного тестирования - в разрабатываемую программу P вносят P1, P2... Затем программа P и ее (X,Y).
Если на наборе (X,Y) подтверждается P и, кроме того, выявляются все внесенные в программы-
Если некоторые (X,Y) и продолжать тестирование.
Тестируемая программа . Для нее создается две программы-мутанта P1 и P2.
В ).
В ).
При запуске тестов (X,Y) = {(x=2,n=3,y=8),(x=999,n=1,y=999), (x=0,n=100,y=0 } выявляются все ошибки в программах-мутантах и ошибка в основной программе, где в условии цикла вместо n стоит n-1:
// Метод вычисляет неотрицательную
// степень n числа x
static public double PowerNonNeg(
double x, int n)
{
double z=1;
if (n>0)
{
for (int i=1;n-1>=i;i++)
{
z = z*x;
}
}
else Console.WriteLine(
"Ошибка ! Степень числа n должна
быть больше 0.");
return z;
}
double PowerNonNeg(double x, int n)
{
double z=1;
int i;
if (n>0)
{
for (i=1;n-1>=i;i++)
{
z = z*x;
}
}
else printf(
"Ошибка ! Степень числа n должна
быть больше 0.\n");
return z;
}
Измененное начальное значение переменной z в z=2 ):
// Метод вычисляет неотрицательную
// степень n числа x
static public double PowerMutant1(
double x, int n)
{
double z=2;
if (n>0)
{
for (int i=1;n>=i;i++)
{
z = z*x;
}
}
else Console.WriteLine(
"Ошибка ! Степень числа n должна
быть больше 0.");
return z;
}
double PowerMutant1(double x, int n)
{
double z=2;
int i;
if (n>0)
{
for (i=1;n>=i;i++)
{
z = z*x;
}
}
else printf(
"Ошибка ! Степень числа n должна
быть больше 0.\n");
return z;
}
Измененное начальное значение переменной i и границы цикла в i=0;n-1 ):
// Метод вычисляет неотрицательную
// степень n числа x
static public double PowerMutant2(
double x, int n)
{
double z=1;
if (n>0)
{
for (int i=0;n-1>=i;i++)
{
z = z*x;
}
}
else Console.WriteLine(
"Ошибка ! Степень числа n должна
быть больше 0");
return z;
}
double PowerMutant2(double x, int n)
{
double z=1;
int i;
if (n>0)
{
for (i=0;n-1>=i;i++)
{
z = z*x;
}
}
else printf(
"Ошибка ! Степень числа n должна
быть больше 0.\n");
return z;
}
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.