С.Трофимов
Никтоне сомневается в необходимости тестирования программ. Будь то небольшой учебныйпример или целая информационная система. Вопрос только в том, сколько нужнотестировать и когда можно считать программу протестированной?
Людямсвойственно ошибаться при любом виде деятельности, в том числе и при созданиипрограмм. Конечно, эти ошибки неумышленные и человек в конце концов их исправит,но как говорят, программ без ошибок не бывает, и на некотором этапетестирования возникает вопрос, стоит ли дальше искать ошибки или смириться с ихнекоторым количеством до поры до времени. Этот вопрос подводит нас копределению критериев, по которым можно судить, что программа более или менееработоспособна.
Известно,что можно написать программу из одного оператора без единой ошибки. Казалось бык одному безошибочному оператору можно добавить еще один, а затем еще один, напервый взгляд, безошибочный, однако, людям свойственно ошибаться… и результатполучается не тот, которого ожидали.
Ошибкибывают разные и время на их поиск будет различно. От простых опечаток, которыенаходятся в первый же запуск программы, до неявных ошибок алгоритма илинеправильного использования языковых конструкций, на поиск которых можнопотратить не только часы, а дни. Последние найти особенно тяжело.
Современныеязыки программирования — это чрезвычайно сложный инструмент, на освоениекоторого уходят годы кропотливого труда. Иногда ошибки в документации, а чащепросто недостаточное понимание работы той или иной конструкции языка илиназначения библиотеки, ведет к неправильной работе программы.
Программистсмотрит в код и не понимает, почему он работает не так, как задумано. В такихслучаях говорят «уперся» и зовут соседа на помощь. В этом случае«свежий» взгляд может значительно ускорить поиск ошибки.
Сократитьколичество ошибок можно несколькими путями:
применитьспециальные методы и средства написания программ, например, CASE-средстваRational Rose;
применитьнадежные, многократно протестированные компоненты и библиотеки;
строгособлюдать и главное контролировать соответствие создаваемых программ проектнойдокументации.
Ещеодним, достаточно эффективным, но трудоемким методом сокращения ошибок (яговорю именно о сокращении, а не полном устранении) будет тестирование. Обычноресурсов (читай времени) для полного тестирования не хватает. Поэтому полноетестирование с проверкой системы во всех режимах и со всеми параметрами труднореализуемо.
Однойиз основных особенностей тестирования является отсутствие эталона программы, скоторым можно было бы сравнить нечто уже созданное. Из этого истекает трудностьопределения момента, когда необходимое качество программы достигнуто.
Основнымэталоном в этом случае будет проектная документация, которая приводит разницувзглядов различных людей на качество программы к одному знаменателю. Приотсутствии такой документации, я считаю, что в принципе невозможнопротестировать программу, поскольку взгляд на объем и качество выполняемыхфункций не совпадает не только у разных людей, но и может различаться у одногочеловека в разные промежутки времени.
Поэтомуважно определить несколько уровней достижения необходимого качества программ:
отсутствиесинтаксических ошибок и аварийных остановок в программе, что достигаетсяпрогоном программы с различными данными по максимальному числу ветвей. Дляопределения участков, которые ни разу небыли запущены при прогоне программы, существуютспециальные средства, например Rational Pure Coverage. Из практики работы ямогу сделать вывод, что участок кода, который ни разу не был запущен притестировании, примерно в 80% случаев неработоспособен;
выполняемыефункции программ соответствуют технической документации;
расчетныезначения, полученные при помощи процедур расчета, соответствуют эталонным.
Частопервые два уровня можно тестировать одновременно, внося коррективы всопроводительную документацию. Последний пункт самый длительный и труднотестируемый, невозможно подготовить тест на все возможные сочетания данных, поэтомусуществует так называемое бета-тестирование, т.е. тестирование самимипользователями.
Теперь,когда некоторые критерии тестирование были здесь упомянуты, можно ответить навопрос, вынесенный в заголовок статьи.
Первыйэтап тестирования можно прекращать, когда есть уверенность, что большая частьсинтаксических ошибок и аварийный остановов устранена. Остальные постепеннобудут устраняться в процессе других этапов тестирования.
Второйэтап тестирования можно прекращать, когда большая часть функциональностипроверена и работает в соответствии с проектной документацией. Остальныенесоответствия будут устраняться в процессе написания сопроводительной документации.
Инаконец, третий этап тестирования можно прекращать, когда основные расчетныетесты дают правильные результаты.
Тестированиепользователями будет продолжаться на всем этапе жизненного цикла программногообеспечения, и вплоть до смены ПО на более современное, пользователи будутнаходить в нем неточности и ошибки, к которыми, в конце концов, они привыкнут иначнут воспринимать их как само собой разумеющееся, пока программисты невыдадут «нагора» новую версию, в которой «исправлены старыеошибки и добавлены новые» и все начнется сначала.
Список литературы
Дляподготовки данной работы были использованы материалы с сайта progcpp.narod.ru/doc/prog.htm