Калайда В.Т., Романенко В.В. Технология разработки программного обеспечения (2007), страница 13
Описание файла
PDF-файл из архива "Калайда В.Т., Романенко В.В. Технология разработки программного обеспечения (2007)", который расположен в категории "". Всё это находится в предмете "микропроцессорные системы (мпс)" из 8 семестр, которые можно найти в файловом архиве МГТУ им. Н.Э.Баумана. Не смотря на прямую связь этого архива с МГТУ им. Н.Э.Баумана, его также можно найти и в других разделах. Архив можно найти в разделе "книги и методические указания", в предмете "микропроцессорные системы" в общих файлах.
Просмотр PDF-файла онлайн
Текст 13 страницы из PDF
не содержит ошибок).Лучший способ доказать справедливость подобного утверждения — попытаться его опровергнуть, обнаружить неточности,нежели просто согласиться с тем, что программа на определенном наборе входных данных работает корректно.6.2 Экономика тестированияДав такое определение тестированию, необходимо на следующем шаге рассмотреть возможность создания теста, обнаруживающего все ошибки программы. Покажем, что ответ будетотрицательным даже для самых тривиальных программ. В общем случае, невозможно обнаружить все ошибки программы.
Аэто, в свою очередь, порождает экономические проблемы, задачи, связанные с функциями человека в процессе отладки, способы построения тестов.6.2.1 Тестирование программы как черного ящикаОдним из способов изучения поставленного вопроса является исследование стратегии тестирования, называемой стратегией черного ящика, тестированием с управлением по данным или тестированием с управлением по входу-выходу. Прииспользовании этой стратегии программа рассматривается какчерный ящик. Иными словами, такое тестирование имеет цельювыяснение обстоятельств, в которых поведение программы несоответствует ее спецификации.При таком подходе обнаружение всех ошибок в программе является критерием исчерпывающего входного тестирования. Последнее может быть достигнуто, если в качестве тестовых наборов использовать все возможные наборы входных данных.
Поэтому для тестирования даже небольшой программытребуется бесконечное число тестов. Как пример можно приве-89сти задачу о треугольниках. Даны три числа — A, B и C. Требуется определить, могут ли эти числа являться длинами сторонтреугольника, и если да, то является ли этот треугольник прямоугольным, равнобедренным или равносторонним. Очевидно,что если A, B и C являются вещественными числами, то имеется бесконечное количество комбинаций их значений.Если такое испытание представляется сложным, то ещесложнее создать исчерпывающий тест для большой программы.Образно говоря, число тестов можно оценить «числом,большим, чем бесконечность».Из изложенного следует, что построение исчерпывающего входного теста невозможно.
Это подтверждается двумя аргументами: во-первых, нельзя создать тест, гарантирующий отсутствие ошибок; во-вторых, разработка таких тестов противоречит экономическим требованиям. Поскольку исчерпывающеетестирование исключается, нашей целью должна стать максимизация результативности капиталовложений в тестирование(иными словами, максимизация числа ошибок, обнаруживаемых одним тестом). Для этого мы можем рассматривать внутреннюю структуру программы и делать некоторые разумные,но, конечно, не обладающие полной гарантией достоверностипредположения.6.2.2 Тестирование программы как белого ящикаСтратегия белого ящика, или стратегия тестирования,управляемого логикой программы, позволяет исследовать внутреннюю структуру программы.
В этом случае тестирующийполучает тестовые данные путем анализа логики программы (ксожалению, здесь часто не используется спецификация программы).Сравним способ построения тестов при данной стратегиис исчерпывающим входным тестированием стратегии черногоящика. Непосвященному может показаться, что достаточно построить такой набор тестов, в котором каждый оператор исполняется хотя бы один раз; нетрудно показать, что это неверно.Не вдаваясь в детали, укажем лишь, что исчерпывающему входному тестированию может быть поставлено в соответствие ис-90черпывающее тестирование маршрутов. Подразумевается, чтопрограмма проверена полностью, если с помощью тестов удается осуществить выполнение этой программы по всем возможным маршрутам ее потока (графа) передач управления.Последнее утверждение имеет два слабых пункта.
Одиниз них состоит в том, что число не повторяющих друг другамаршрутов в программе — астрономическое. Чтобы убедитьсяв этом, рассмотрим представленный на рис. 6.1 граф передачуправления простейшей программы. Каждая вершина или кружок обозначают участок программы, содержащий последовательность линейных операторов, которая может заканчиватьсяоператором ветвления. Дуги, оканчивающиеся стрелками, соответствуют передачам управления. По-видимому, граф описывает программу из 10–20 операторов, включая цикл DO, которыйисполняется не менее 20 раз.
Внутри цикла имеется несколькооператоров IF. Для того, чтобы определять число неповторяющихся маршрутов при исполнении программы, подсчитаем число неповторяющихся маршрутов из точки A в B в предположении, что все приказы взаимно независимы. Это число вычисляется как сумма 520 + 519 + … + 51 = 100 триллионов, где5— число путей внутри цикла. Приведем такой пример: если допустить, что на составление каждого теста мы тратим пять минут, то для построения набора тестов нам потребуется примерно один миллиард лет.91A≤ 20разBРис.
6.1 — Граф передач управления небольшой программыВторой слабый пункт утверждения заключается в том,что, хотя исчерпывающее тестирование маршрутов являетсяполным тестом и хотя каждый маршрут программы может бытьпроверен, сама программа может содержать ошибки. Это объясняется следующим образом. Во-первых, исчерпывающее тестирование маршрутов не может дать гарантии того, что программа соответствует описанию. Например, вместо требуемойпрограммы сортировки по возрастанию случайно была написана программа сортировки по убыванию. В этом случае ценностьтестирования маршрутов невелика, поскольку после тестирования в программе окажется одна ошибка, т.е.
программа неверна.Во-вторых, программа может быть неверной в силу того, чтопропущены некоторые маршруты. Исчерпывающее тестирование маршрутов не обнаружит их отсутствия. В-третьих, исчерпывающее тестирование маршрутов не может обнаружить ошибок, появление которых зависит от обрабатываемых данных.Существует множество примеров таких ошибок. Приведем92один из них. Допустим, в программе необходимо выполнитьсравнение двух чисел на сходимость, т.е.
определить, являетсяли разность между двумя числами меньше предварительноопределенного числа. Может быть написано выражениеIF ((A – B) < EPSILON)…Безусловно, оно содержит ошибку, поскольку необходимовыполнить сравнение абсолютных величин. Однако обнаружение этой ошибки зависит от значений, использованных для A иB, и ошибка не обязательно будет обнаружена просто путем исполнения каждого маршрута.В заключение отметим, что, хотя исчерпывающее входноетестирование предпочтительнее исчерпывающего тестированиямаршрутов, ни то, ни другое не могут стать полезными стратегиями, потому что оба они нереализуемы. Возможно, поэтомуреальным путем, который позволит создать хорошую, но, конечно, не абсолютную стратегию, является сочетание тестирования программы и как черного, и как белого ящиков.
Этот вопрос обсуждается в п. 6.4.6.2.3 Принципы тестированияСформулируем основные принципы тестирования, используя главную предпосылку настоящего раздела о том, чтонаиболее важными в тестировании программ являются вопросыпсихологии. Эти принципы интересны тем, что в основном ониинтуитивно ясны, но, в то же время, на них часто не обращаютдолжного внимания.Описание предполагаемых значений выходных данных илирезультатов должно быть необходимой частью тестовогонабора.Нарушение этого очевидного принципа представляетодну из наиболее распространенных ошибок.
Ошибочные, ноправдоподобные результаты могут быть признаны правильными, если результаты теста не были заранее определены. Здесьмы сталкиваемся с явлением психологии: мы видим то, что мыхотим увидеть. Другими словами, несмотря на то, что тестирование по определению — деструктивный процесс, есть подсознательное желание видеть корректный результат. Один изспособов борьбы с этим состоит в поощрении детального ана-93лиза выходных переменных заранее при разработке теста.Поэтому тест должен включать две компоненты: описаниевходных данных и описание точного и корректного результата,соответствующего набору входных данных.Необходимость этого подчеркивал логик Копи: «Проблема может быть охарактеризована как факт или группа фактов,которые не имеют приемлемого объяснения, кажутся необычными или которые не удается подогнать под наши представления или предположения.
Очевидно, что если что-нибудь подвергается сомнению, то об этом должна иметься какая-то предварительная информация. Если нет предположений, то не может быть и неожиданных результатов».Следует избегать тестирования программы ее автором.Этот принцип следует из обсуждавшихся ранее положений, которые определяют тестирование как деструктивный процесс. После выполнения конструктивной части, при проектировании и написании программы трудно быстро (в течение одногодня) перестроиться на деструктивный образ мышления. Многие, кому приходилось самому делать дома ремонт, знают, чтопроцесс обрывания старых обоев (деструктивный процесс) нелегок, но он просто невыносим, если не кто-то другой, а высами первоначально их наклеивали.