Калайда В.Т., Романенко В.В. Технология разработки программного обеспечения (1015641), страница 14
Текст из файла (страница 14)
Во-первых, исчерпывающее тестирование маршрутов не может дать гарантии того, что программа соответствует описанию. Например, вместо требуемойпрограммы сортировки по возрастанию случайно была написана программа сортировки по убыванию. В этом случае ценностьтестирования маршрутов невелика, поскольку после тестирования в программе окажется одна ошибка, т.е. программа неверна.Во-вторых, программа может быть неверной в силу того, чтопропущены некоторые маршруты. Исчерпывающее тестирование маршрутов не обнаружит их отсутствия. В-третьих, исчерпывающее тестирование маршрутов не может обнаружить ошибок, появление которых зависит от обрабатываемых данных.Существует множество примеров таких ошибок. Приведем92один из них. Допустим, в программе необходимо выполнитьсравнение двух чисел на сходимость, т.е.
определить, являетсяли разность между двумя числами меньше предварительноопределенного числа. Может быть написано выражениеIF ((A – B) < EPSILON)…Безусловно, оно содержит ошибку, поскольку необходимовыполнить сравнение абсолютных величин. Однако обнаружение этой ошибки зависит от значений, использованных для A иB, и ошибка не обязательно будет обнаружена просто путем исполнения каждого маршрута.В заключение отметим, что, хотя исчерпывающее входноетестирование предпочтительнее исчерпывающего тестированиямаршрутов, ни то, ни другое не могут стать полезными стратегиями, потому что оба они нереализуемы. Возможно, поэтомуреальным путем, который позволит создать хорошую, но, конечно, не абсолютную стратегию, является сочетание тестирования программы и как черного, и как белого ящиков. Этот вопрос обсуждается в п.
6.4.6.2.3 Принципы тестированияСформулируем основные принципы тестирования, используя главную предпосылку настоящего раздела о том, чтонаиболее важными в тестировании программ являются вопросыпсихологии. Эти принципы интересны тем, что в основном ониинтуитивно ясны, но, в то же время, на них часто не обращаютдолжного внимания.Описание предполагаемых значений выходных данных илирезультатов должно быть необходимой частью тестовогонабора.Нарушение этого очевидного принципа представляетодну из наиболее распространенных ошибок. Ошибочные, ноправдоподобные результаты могут быть признаны правильными, если результаты теста не были заранее определены.
Здесьмы сталкиваемся с явлением психологии: мы видим то, что мыхотим увидеть. Другими словами, несмотря на то, что тестирование по определению — деструктивный процесс, есть подсознательное желание видеть корректный результат. Один изспособов борьбы с этим состоит в поощрении детального ана-93лиза выходных переменных заранее при разработке теста.Поэтому тест должен включать две компоненты: описаниевходных данных и описание точного и корректного результата,соответствующего набору входных данных.Необходимость этого подчеркивал логик Копи: «Проблема может быть охарактеризована как факт или группа фактов,которые не имеют приемлемого объяснения, кажутся необычными или которые не удается подогнать под наши представления или предположения.
Очевидно, что если что-нибудь подвергается сомнению, то об этом должна иметься какая-то предварительная информация. Если нет предположений, то не может быть и неожиданных результатов».Следует избегать тестирования программы ее автором.Этот принцип следует из обсуждавшихся ранее положений, которые определяют тестирование как деструктивный процесс. После выполнения конструктивной части, при проектировании и написании программы трудно быстро (в течение одногодня) перестроиться на деструктивный образ мышления. Многие, кому приходилось самому делать дома ремонт, знают, чтопроцесс обрывания старых обоев (деструктивный процесс) нелегок, но он просто невыносим, если не кто-то другой, а высами первоначально их наклеивали.
Вот так же и большинствопрограммистов не могут эффективно тестировать свои программы, потому что им трудно демонстрировать собственные ошибки.В дополнение к этой психологической проблеме следуетотметить еще одну, не менее важную: программа может содержать ошибки, связанные с неверным пониманием постановкиили описания задачи программистом. Тогда существует вероятность, что к тестированию программист приступит с таким женедопониманием своей задачи.Тестирование можно уподобить работе корректора илирецензента над статьей или книгой. Многие авторы представляют себе трудности, связанные с редактированием собственной рукописи.
Очевидно, что обнаружение недостатков в своейдеятельности противоречит человеческой психологии.Отсюда вовсе не следует, что программист не может тестировать свою программу. Здесь лишь делается вывод о том,что тестирование является более эффективным, если оно вы-94полняется кем-либо другим. Заметим, что все наши рассуждения не относятся к отладке, т.е.
к исправлению уже известныхошибок. Эта работа эффективнее выполняется самим авторомпрограммы.Программирующая организация не должна сама тестировать разработанные ею программы.Здесь можно привести те же аргументы, что и в предыдущем случае. Во многих смыслах проектирующая или программирующая организация подобна живому организму с его психологическими проблемами. Работа программирующей организации или ее руководителя оценивается по их способности производить программы в течение заданного времени и определенной стоимости. Одна из причин такой системы оценок состоитв том, что временные и стоимостные показатели легко измерить, но в то же время чрезвычайно трудно количественно оценить надежность программы.
Именно поэтому в процессе тестирования программирующей организации трудно быть объективной, поскольку тестирование в соответствии с данным определением может быть рассмотрено как средство уменьшениявероятности соответствия программы заданным временным истоимостным параметрам.Как и ранее, из изложенного не следует, что программирующая организация не может найти свои ошибки; тестирование в определенной степени может пройти успешно. Мы утверждаем здесь лишь то, что экономически более целесообразновыполнение тестирования каким-либо объективным, независимым подразделением.Необходимо досконально изучать результаты применения каждого теста.По всей вероятности, это наиболее очевидный принцип,но и ему часто не уделяется должное внимание. В проведенныхэкспериментах многие испытуемые не смогли обнаружить определенные ошибки, хотя их признаки были совершенно явнымив выходных листингах.
Представляется достоверным, что значительная часть всех обнаруженных в конечном итоге ошибокмогла быть выявлена в результате самых первых тестовых прогонов, но они были пропущены вследствие недостаточно тщательного анализа результатов первого тестового прогона.95Тесты для неправильных и непредусмотренных входныхданных следует разрабатывать так же тщательно, как дляправильных и предусмотренных.При тестировании программ имеется естественная тенденция концентрировать внимание на правильных и предусмотренных входных условиях, а неправильным и непредусмотренным входным данным не придавать значения.
Например, притестировании задачи о треугольниках, приведенной в п. 6.2.1,лишь немногие смогут привести в качестве теста длины сторон1, 2 и 5, чтобы убедиться в том, что треугольник не будет ошибочно интерпретирован как неравносторонний. Множествоошибок можно также обнаружить, если использовать программу новым, не предусмотренным ранее способом. Вполне вероятно, что тесты, представляющие неверные и неправильныевходные данные, обладают большей обнаруживающей способностью, чем тесты, соответствующие корректным входным данным.Необходимо проверять не только, делает ли программато, для чего она предназначена, но и не делает ли она то, чтоне должна делать.Это логически просто вытекает из предыдущего принципа.
Необходимо проверить программу на нежелательные побочные эффекты. Например, программа расчета зарплаты, котораяпроизводит правильные платежные чеки, окажется неверной,если она произведет лишние чеки для работающих или дваждызапишет первую запись в список личного состава.Не следует выбрасывать тесты, даже если программауже не нужна.Эта проблема наиболее часто возникает при использовании интерактивных систем отладки. Обычно тестирующий сидит за терминалом, на лету придумывает тесты и запускает программу на выполнение.
При такой практике работы после применения тесты пропадают. После внесения изменений или исправления ошибок необходимо повторять тестирование, тогдаприходится заново изобретать тесты. Как правило, этого стараются избегать, поскольку повторное создание тестов требуетзначительной работы. В результате повторное тестирование бывает менее тщательным, чем первоначальное, т.е.
если модификация затронула функциональную часть программы и при этом96Вероятность наличиянеобнаруженных ошибокбыла допущена ошибка, то она зачастую может остаться необнаруженной.Нельзя планировать тестирование в предположении,что ошибки не будут обнаружены.Такую ошибку обычно допускают руководители проекта,использующие неверное определение тестирования как процесса демонстрации отсутствия ошибок в программе, корректногофункционирования программы.Вероятность наличия необнаруженных ошибок в частипрограммы пропорциональна числу ошибок, уже обнаруженныхв этой части.Этот принцип, не согласующийся с интуитивным представлением, иллюстрируется рис. 6.2.Число обнаруженных ошибокРис.
6.2 — Неожиданное соотношение числа оставшихсяи числа обнаруженных ошибокНа первый взгляд он лишен смысла, но тем не менее подтверждается многими программами. Например, допустим, чтонекоторая программа состоит из модулей A и B. К определен-97ному сроку в модуле A обнаружено пять ошибок, а в модулеB — только одна, причем модуль A не подвергался более тщательному тестированию.Тогда из рассматриваемого принципа следует, что вероятность необнаруженных ошибок в модуле A больше, чем в модуле B. Справедливость этого принципа подтверждается еще итем, что для ошибок свойственно располагаться в программе ввиде неких скоплений, хотя данное явление пока никем еще необъяснено.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
