tehnologia (1018792), страница 43
Текст из файла (страница 43)
Никакое тестирование не может доказать отсутствие ошибок в хотьсколько-нибудь сложном программном обеспечении. Для такого программногообеспечения выполнение полного тестирования, т. е. задания всех возможных комбинацийисходных данных, становится невозможным, а, следовательно, всегда имеется вероятностьтого, что в программном обеспечении остались невыявленные ошибки. Однако соблюдение263основных правил тестирования и научно обоснованный подбор тестов может уменьшить ихколичество.Примечание.
Обычно на вопрос о цели тестирования начинающие программистыотвечают, что целью тестирования является «доказательство правильности программы». Этоабсолютно неверное мнение. Г. Майерс [47] предлагает очень удачную аналогию дляпояснения этого положения. Представьте себе, что вы пришли на прием к врачу ипожаловались на боль в боку. Врач выслушал вас и направил на обследование.
Черезнекоторое время вы возвращаетесь к врачу с ворохом заключений и результатов анализов, иво всех этих бумагах написано, что все исследуемые параметры у вас в норме. Но бок тоболит, значит, что-то не в порядке, хотя анализы этого и не показывают... Так и сложноепрограммное обеспечение, безошибочно работающее на всех тестовых наборах, можетсодержать и обычно содержит некоторое количество ошибок.Процесс разработки программного обеспечения, в том виде, как он определяется всовременной модели жизненного цикла программного обеспечения, предполагает тристадии тестирования:• автономное тестирование компонентов программного обеспечения;• комплексное тестирование разрабатываемого программного обеспечения;• системное или оценочное тестирование на соответствие основным критериямкачества.Для повышения качества тестирования рекомендуется соблюдать следующие основныепринципы:264• предполагаемые результаты должны быть известны до тестирования;• следует избегать тестирования программы автором;• необходимо досконально изучать результаты каждого теста;• необходимо проверять действия программы на неверных данных;• необходимо проверять программу на неожиданные побочные эффекты на неверныхданных.Следует также иметь в виду, что вероятность наличия необнаруженных ошибок в частипрограммы пропорциональны количеству ошибок уже найденных в этой части.Формирование тестовых наборов.
В соответствии с определением тестирования вначале данного параграфа, удачным следует считать тест, который обнаруживает хотя быодну ошибку. С этой точки зрения хотелось бы использовать такие наборы тестов, каждый изкоторых с максимальной вероятностью может обнаружить ошибку.Формирование набора тестов имеет большое значение, поскольку тестирование являетсяодним из наиболее трудоемких этапов (от 30 до 60 % общей трудоемкости) созданияпрограммного продукта. Причем доля стоимости тестирования в общей стоимостиразработки имеет тенденцию возрастать при увеличении сложности программногообеспечения и повышении требований к их качеству.Существуют два принципиально различных подхода к формированию тестовыхнаборов: структурный и функциональный.Структурный подход базируется на том, что известна структура тестируемогопрограммного обеспечения, в том числе его алгоритмы («стеклянный ящик»).
В этом случаетесты строят так, чтобы проверить правильность реализации заданной логики в кодепрограммы.Функциональный подход основывается на том, что структура программного обеспеченияне известна («черный ящик»), В этом случае тесты строят, опираясь на функциональныеспецификации. Этот подход называют также подходом, управляемым данными, так какпри его использовании тесты строят на базе различных способов декомпозиции множестваданных.Наборы тестов, полученные в соответствии с методами этих подходов, обычнообъединяют, обеспечивая всестороннее тестирование программного обеспечения.Более подробное рассмотрение перечисленных вопросов начнем с обсуждения методовручного контроля.9.2.
Ручной контроль программного обеспеченияРучной контроль, как указано выше, обычно используют на ранних этапах разработки.Все проектные решения, принятые на том или ином этапе, должны анализироваться с точкизрения их правильности и целесообразнос-265ти как можно раньше, пока их можно легко пересмотреть. Поскольку возможностьпрактической проверки подобных решений на ранних этапах разработки отсутствует,большое значение имеет их обсуждение, которое проводят в разных формах.Различают статический и динамический подходы к ручному контролю. Пристатическом подходе анализируют структуру, управляющие и информационные связипрограммы, ее входные и выходные данные.
При динамическом - выполняют ручноетестирование, т. е. вручную моделируют процесс выполнения программы на заданныхисходных данных.Исходными данными для таких проверок являются: техническое задание,спецификации, структурная и функциональная схемы программного продукта, схемыотдельных компонентов и т. д., а для более поздних этапов - алгоритмы и текстыпрограмм, а также тестовые наборы.Доказано, что ручной контроль способствует существенному увеличениюпроизводительности и повышению надежности программ и с его помощью можно находитьот 30 до 70 % ошибок логического проектирования и кодирования. Следовательно, один илинесколько из методов ручного контроля обязательно должны использоваться в каждомпрограммном проекте.Основными методами ручного контроля являются:• инспекции исходного текста,• сквозные просмотры,• проверка за столом,• оценки программ.Инспекции исходного текста.
Инспекции исходного текста представляют собой наборпроцедур и приемов обнаружения ошибок при изучении текста группой специалистов. В этугруппу входят: автор программы, проектировщик, специалист по тестированию и координатор— компетентный программист, но не автор программы. Общая процедура инспекциипредполагает следующие операции:• участникам группы заранее выдается листинг программы и спецификация на нее;• программист рассказывает о логике работы программы и отвечает на вопросыинспекторов;• программа анализируется по списку вопросов для выявления историческисложившихся общих ошибок программирования.Список вопросов для инспекций исходного текста зависит, как от используемого языкапрограммирования, так и от специфики разрабатываемого программного обеспечения.
Вкачестве примера ниже приведен список вопросов, который можно использовать прианализе правильности программ, написанных на языке Pascal.2661. Контроль обращений к данным• Все ли переменные инициализированы?• Не превышены ли максимальные (или реальные) размеры массивов и строк?• Не перепутаны ли строки со столбцами при работе с матрицами?• Присутствуют ли переменные со сходными именами?• Используются ли файлы? Если да, то при вводе из файла проверяется ли завершениефайла?• Соответствуют ли типы записываемых и читаемых значении?• Использованы ли нетипизированные переменные, открытые массивы, динамическаяпамять? Если да, то соответствуют ли типы переменных при «наложении»формата?Не выходят ли индексы за границы массивов?2.
Контроль вычислений• Правильно ли записаны выражения (порядок следования операторов)?• Корректно ли выполнены вычисления над неарифметическими переменными?• Корректно ли выполнены вычисления с переменными различных типов (в том числе сиспользованием целочисленной арифметики)?• Возможно ли переполнение разрядной сетки или ситуация машинного нуля?• Соответствуют ли вычисления заданным требованиям точности?• Присутствуют ли сравнения переменных различных типов?3. Контроль передачи управления• Будут ли корректно завершены циклы?• Будет ли завершена программа?• Существуют ли циклы, которые не будут выполняться из-за нарушения условиявхода? Корректно ли продолжатся вычисления?• Существуют ли поисковые циклы? Корректно ли отрабатываются ситуации«элемент найден» и «элемент не найден»?4. Контроль межмодульных интерфейсов• Соответствуют ли списки параметров и аргументов по порядку, типу, единицамизмерения?• Не изменяет ли подпрограмма аргументов, которые не должны изменяться?• Не происходит ли нарушения области действия глобальных и локальных переменныхс одинаковыми именами?Кроме непосредственного обнаружения ошибок, результаты инспекции позволяютпрограммисту увидеть другие сделанные им ошибки, получить возможность оценитьсвой стиль программирования, выбор алгоритмов и методов тестирования.
Инспекцияявляется способом раннего выявления частей программы, с большей вероятностьюсодержащих ошибки, что позволяет при тестировании уделить внимание именно этимчастям.267Сквозные просмотры. Сквозной просмотр, как и инспекция, представляет собой наборспособов обнаружения ошибок, осуществляемых группой лиц, просматривающих текстпрограммы. Такой просмотр имеет много общего с процессом инспектирования, ноотличается процедурой и методами обнаружения ошибок.
Группа по выполнению сквозногоконтроля состоит из трех-пяти человек: председатель или координатор, секретарь,фиксирующий все ошибки, специалист по тестированию, программист и независимыйэксперт. Сквозной просмотр предполагает выполнение следующих процедур:• участникам группы заранее выдают листинг программы и спецификацию на нее;• участникам заседания предлагают несколько тестов;• участники заседания мысленно выполняют каждый тест в соответствии с логикойпрограммы, при этом состояние программы (значения переменных) отслеживается набумаге или доске;• при необходимости программисту задают вопросы о логике проектирования ипринятых допущениях.В большинстве сквозных просмотров при выполнении самих тестов находят меньшеошибок, чем при опросе программиста.Проверка за столом.
Исторически данный метод ручного тестирования появилсяпервым, так как он не требует наличия группы специалистов. Это -проверка исходного текстаили сквозные просмотры, выполняемые одним человеком, который читает текст программы,проверяет его на наличие возможных ошибок по специальному списку часто встречающихсяошибок и «пропускает» через программу тестовые данные. Исходя из принциповтестирования, проверку за столом должен проводить человек, не являющийся авторомпрограммы. Метод наименее результативен, так как проверка представляет собой полностьюнеупорядоченный процесс, при ней отсутствует обмен мнениями и здоровая конкуренция.Оценка программ. Этот метод непосредственно не связан с тестированием, но егоиспользование также улучшает качество программирования.