Калайда В.Т., Романенко В.В. Технология разработки программного обеспечения (2007), страница 14

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

Многие авторы представляют себе трудности, связанные с редактированием собственной рукописи. Очевидно, что обнаружение недостатков в своейдеятельности противоречит человеческой психологии.Отсюда вовсе не следует, что программист не может тестировать свою программу. Здесь лишь делается вывод о том,что тестирование является более эффективным, если оно вы-94полняется кем-либо другим.

Заметим, что все наши рассуждения не относятся к отладке, т.е. к исправлению уже известныхошибок. Эта работа эффективнее выполняется самим авторомпрограммы.Программирующая организация не должна сама тестировать разработанные ею программы.Здесь можно привести те же аргументы, что и в предыдущем случае. Во многих смыслах проектирующая или программирующая организация подобна живому организму с его психологическими проблемами. Работа программирующей организации или ее руководителя оценивается по их способности производить программы в течение заданного времени и определенной стоимости.

Одна из причин такой системы оценок состоитв том, что временные и стоимостные показатели легко измерить, но в то же время чрезвычайно трудно количественно оценить надежность программы. Именно поэтому в процессе тестирования программирующей организации трудно быть объективной, поскольку тестирование в соответствии с данным определением может быть рассмотрено как средство уменьшениявероятности соответствия программы заданным временным истоимостным параметрам.Как и ранее, из изложенного не следует, что программирующая организация не может найти свои ошибки; тестирование в определенной степени может пройти успешно.

Мы утверждаем здесь лишь то, что экономически более целесообразновыполнение тестирования каким-либо объективным, независимым подразделением.Необходимо досконально изучать результаты применения каждого теста.По всей вероятности, это наиболее очевидный принцип,но и ему часто не уделяется должное внимание. В проведенныхэкспериментах многие испытуемые не смогли обнаружить определенные ошибки, хотя их признаки были совершенно явнымив выходных листингах.

Представляется достоверным, что значительная часть всех обнаруженных в конечном итоге ошибокмогла быть выявлена в результате самых первых тестовых прогонов, но они были пропущены вследствие недостаточно тщательного анализа результатов первого тестового прогона.95Тесты для неправильных и непредусмотренных входныхданных следует разрабатывать так же тщательно, как дляправильных и предусмотренных.При тестировании программ имеется естественная тенденция концентрировать внимание на правильных и предусмотренных входных условиях, а неправильным и непредусмотренным входным данным не придавать значения.

Например, притестировании задачи о треугольниках, приведенной в п. 6.2.1,лишь немногие смогут привести в качестве теста длины сторон1, 2 и 5, чтобы убедиться в том, что треугольник не будет ошибочно интерпретирован как неравносторонний. Множествоошибок можно также обнаружить, если использовать программу новым, не предусмотренным ранее способом. Вполне вероятно, что тесты, представляющие неверные и неправильныевходные данные, обладают большей обнаруживающей способностью, чем тесты, соответствующие корректным входным данным.Необходимо проверять не только, делает ли программато, для чего она предназначена, но и не делает ли она то, чтоне должна делать.Это логически просто вытекает из предыдущего принципа. Необходимо проверить программу на нежелательные побочные эффекты. Например, программа расчета зарплаты, котораяпроизводит правильные платежные чеки, окажется неверной,если она произведет лишние чеки для работающих или дваждызапишет первую запись в список личного состава.Не следует выбрасывать тесты, даже если программауже не нужна.Эта проблема наиболее часто возникает при использовании интерактивных систем отладки.

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

если модификация затронула функциональную часть программы и при этом96Вероятность наличиянеобнаруженных ошибокбыла допущена ошибка, то она зачастую может остаться необнаруженной.Нельзя планировать тестирование в предположении,что ошибки не будут обнаружены.Такую ошибку обычно допускают руководители проекта,использующие неверное определение тестирования как процесса демонстрации отсутствия ошибок в программе, корректногофункционирования программы.Вероятность наличия необнаруженных ошибок в частипрограммы пропорциональна числу ошибок, уже обнаруженныхв этой части.Этот принцип, не согласующийся с интуитивным представлением, иллюстрируется рис. 6.2.Число обнаруженных ошибокРис. 6.2 — Неожиданное соотношение числа оставшихсяи числа обнаруженных ошибокНа первый взгляд он лишен смысла, но тем не менее подтверждается многими программами.

Например, допустим, чтонекоторая программа состоит из модулей A и B. К определен-97ному сроку в модуле A обнаружено пять ошибок, а в модулеB — только одна, причем модуль A не подвергался более тщательному тестированию.Тогда из рассматриваемого принципа следует, что вероятность необнаруженных ошибок в модуле A больше, чем в модуле B. Справедливость этого принципа подтверждается еще итем, что для ошибок свойственно располагаться в программе ввиде неких скоплений, хотя данное явление пока никем еще необъяснено. В качестве примера можно рассмотреть операционные системы IBM S/370.

В одной из версий операционной системы 47 % ошибок, обнаруженных пользователями, приходилось на 4 % модулей системы.Преимущество рассматриваемого принципа заключается втом, что он позволяет ввести обратную связь в процесс тестирования. Если в какой-нибудь части программы обнаруженобольше ошибок, чем в других, то на ее тестирование должныбыть направлены дополнительные усилия.Тестирование — процесс творческий.Вполне вероятно, что для тестирования большой программы требуется больший творческий потенциал, чем для ее проектирования. Выше было показано, что нельзя дать гарантию построения теста, обнаруживающего все ошибки.

В дальнейшемздесь будут обсуждаться методы построения хороших наборовтестов, но применение этих методов должно быть творческим.Чтобы подчеркнуть некоторые мысли, высказанные в настоящем разделе, приведем еще раз три наиболее важных принципа тестирования.Тестирование — это процесс выполнения программ с целью обнаружения ошибок.Хорошим считается тест, который имеет высокую вероятность обнаружения еще не выявленной ошибки.Удачным считается тест, который обнаруживает ещене выявленную ошибку.6.3 Ручное тестированиеВ течение многих лет большинство программистов былиубеждены в том, что программы пишутся исключительно длявыполнения их на машине и не предназначены для чтения чело-98веком, а единственным способом тестирования программы является ее исполнение на ЭВМ. Это мнение стало изменяться вначале 70-х годов, а значительной степени — благодаря книгеВейнберга «Психология программирования для ЭВМ».

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

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