Методы тестирования программного обеспечения. Степанченко И.В. - 15 стр.

ненты: описание входных данных и описание точного и корректного
результата, соответствующего набору входных данных.
    Необходимость этого подчеркивал логик Копи в работе [3]: «Про-
блема может быть охарактеризована как факт или группа фактов, кото-
рые не имеют приемлемого объяснения, которые кажутся необычными
или которые не удается подогнать под наши представления или предпо-
ложения. Очевидно, что если что-нибудь подвергается сомнению, то об
этом должна иметься какая-то предварительная информация. Если нет
предположений, то не может быть и неожиданных результатов».
 Следует избегать тестирования программы ее автором.
    К сожалению, реализация этого в целом верного принципа не всегда
возможна в силу трех факторов:
1) людские ресурсы разработки, как правило, недостаточны;
2) для регулярного применения этого принципа к каждой программе
    требуется весьма высокая квалификация всех программистов или
    большой группы программистов, тестирующих все программы, что
    не всегда осуществимо;
3) необходим высокий уровень формализации ведения разработки; тща-
    тельные формализованные спецификации требований к программам
    и данным, тщательное описание интерфейса и формализация ответ-
    ственности за качество продукта.
    В настоящее время проводится значительная работа по созданию и
внедрению формализованных методов в большинстве крупных разработок,
но опыт подобного ведения разработок пока еще недостаточно массовый.
    Этот принцип следует из того факта, что тестирование – это дест-
руктивный процесс. После выполнения конструктивной части при проек-
тировании и написании программы программисту трудно быстро (в тече-
ние одного дня) перестроиться на деструктивный образ мышления.
    Многие, кому приходилось самому делать дома ремонт, знают, что
процесс обрывания старых обоев (деструктивный процесс) не легок, но
он просто невыносим, если не кто-то другой, а вы сами вчера их наклеи-
вали. И вам не придет в голову срывать их, если где-то они чуть-чуть не-
ровно легли на стену. Вот так же и большинство программистов не могут
эффективно тестировать свои программы, потому что им трудно демон-
стрировать собственные ошибки.
    Это действительно сильный психологический фактор при коллек-
тивной разработке. Программист, тщательно отлаживающий программу,
невольно может работать медленнее, что становится известно другим
участникам разработки. С другой стороны, он вынужден запрашивать
дополнительное машинное время на отладку у своего непосредственного

                                  17