Читать в оригинале

<< ПредыдущаяОглавлениеСледующая >>


2.3. Основные проблемы тестирования

Реализация тестирования разделяется на три этапа:

1. Создание тестового набора (test suite) путем ручной разработки или автоматической генерации для конкретной среды тестирования (testing environment).

2. Прогон программы на тестах, управляемый тестовым монитором (test monitor, test driver) с получением протокола результатов тестирования (test log).

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

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

Простой пример

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

Рис. 8. Управляющий граф программы

// Метод вычисляет
// неотрицательную степень n числа x
1 static public double Power(double x, int n) {
2          double z=1;
3          for (int i=1;
4          n>=i;
5          i++)
6          {z = z*x;} //Возврат в п.4
7          return z;
}

Управляющий граф программы (УГП) на рис. 8 отображает поток управления программы. Нумерация узлов графа совпадает с нумерацией строк программы. Узлы 1 и 2 не включаются в УГП, поскольку отображают строки описаний, т. е. не содержат управляющих операторов.

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

Например, для функции Н путь (1,3,4) реализуем, путь (1,2,4) нереализуем в условиях нормальной работы. Но при сбоях даже нереализуемый путь может реализоваться.

public static float H(float x,float y) {
         float H;
1       if (x*x+y*y+2<=0)
2       H = 17;
3       else H = 64;
4       return H*H+x*x;
}

Рассмотрим следующие два примера тестирования.

Пусть программа H(x:int, y:int) реализована в машине с 64 разрядным словами, тогда мощность множества тестов ||(X,Y)||=264.

Это означает, что компьютеру, работающему на частоте 1 ГГц, для прогона этого полного набора тестов (при условии, что один тест выполняется за 100 команд) потребуется ~ 3K лет.

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

// Фрагмент программы срабатывания руки робота.
// Прочитать значения датчика
static public bool ReadSensor(bool Sensor) {
//...чтение значения датчика
         Console.WriteLine("...reading sensor value");
         return Sensor;
}
// Открыть схват
static public void OpenHand() {
//...открываем схват
         Console.WriteLine("...opening hand");
}
// Закрыть схват
static public void CloseHand() {
//...закрываем схват
         Console.WriteLine("...closing hand");
}
[STAThread]
static void Main(string[] args) {
         while (true) {
            Console.WriteLine("Enter Sensor value (true/false)");
            if (ReadSensor(Convert.ToBoolean(Console.ReadLine()))) {
                        OpenHand(); CloseHand();
            }
         }
}

Этот тривиальный пример требует прогона бесконечного множества последовательностей входных значений с разными интервалами срабатывания руки робота (Рис. 9).

Рис. 9. Тестовая последовательность сигналов датчика руки робота

Отсюда выводы:

1. Тестирование программы на всех входных значениях невозможно.

2. Невозможно тестирование и на всех путях.

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

Требование к тестам - программа на любом из них должна останавливаться, т. е. не зацикливаться. Можно ли заранее гарантировать останов на любом тесте?

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

Задача о выборе конечного набора тестов (X,Y) для проверки программы в общем случае неразрешима.

Поэтому для решения практических задач остается искать частные случаи решения этой задачи.

 



<< ПредыдущаяОглавлениеСледующая >>