Основные принципы тестирования и верификации программного обеспечения

Тестирование является одним из этапов жизненного цикла ПИ, направленным на повышение качественных характеристик. При создании типичного ПИ около 40% общего времени и более 49% общей стоимости расходуется на проверку (тестирование) разрабатываемой программы. Программы как объекты тестирования имеют ряд особенностей, которые отличают процесс их тестирования от общепринятого, применяемого при разработке аппаратуры и других технических изделий. Особенностями тестирования ПИ являются: отсутствие эталона (программы), которому должна соответствовать тестируемая программа; высокая сложность программ и принципиальная невозможность исчерпывающего тестирования; практическая невозможность создания единой методики тестирования (формализации процесса тестирования) в силу большого разнообразия ПИ по их сложности, функциональному назначению, области использования и т.д. Применительно к ПИ тестирование – это процесс многократного выполнения программы с целью обнаружения ошибок. Программа тестируется для того, чтобы повысить уровень ее надежности, т.е. выявить максимальное число ошибок. Цель тестирования – выявление как можно большего числа ошибок. Из правильного определения тестирования вытекает ряд принципов, которые интуитивно ясны, но именно поэтому на них не обращают внимания. Принцип 1. Процесс тестирования более эффективен, если проводится не автором программы. Тестовый прогон, в результате которого не выявлено ошибок считается неудачным (неэффективным). Таким образом, тестирование – это процесс деструктивный (разрушительный). И особенно трудным и малоэффективным он является для самого автора программы, так как после выполнения конструктивной части при проектировании и написании программы ему трудно перестроиться на деструктивный образ мышления и, создав программу, тут же приступить к пристрастному выявлению в ней ошибок. Очевидно, что обнаружение недостатков в своей деятельности противоречит человеческой психологии. Принцип 2. Описание предполагаемых значений результатов тестовых прогонов должно быть необходимой частью тестового набора данных. Этот принцип довольно сложно, а в некоторых случаях даже невозможно реализовать на практике. Сложность его заключается в том, что при тестировании программы (модуля) необходимо для каждого входного набора данных рассчитать вручную ожидаемый результат или найти допустимый интервал изменения выходных данных. Процесс этот очень трудоемкий даже для небольших программ, так как он требует ручных расчетов, следуя логике алгоритма программы. Из рассмотренного принципа, который трудно реализуем, но которого следует придерживаться логически, вытекает следующий. Принцип 3. Необходимо досконально изучать результаты каждого теста. Из практики видно, что значительная часть всех обнаруженных в конечном итоге ошибок могла быть выявлена в результате самых первых тестовых прогонов, но они были пропущены вследствие недостаточно тщательного анализа первых тестовых прогонов. Принцип 4. Тесты для неправильных и непредусмотренных входных данных должны разрабатываться также тщательно, как для правильных, предусмотренных. При обработке данных, выходящих за область допустимых значений, в тестируемой программе должна быть предусмотрена диагностика в виде сообщений. Если же сообщение о причине невозможности обработки по предложенному алгоритму отсутствует, и программа завершается аварийно или ведет себя непредсказуемо, то такая программа не может считаться работоспособной и требует существенной доработки. Принцип 5. Необходимо проверять не только, делает ли программа то, для чего она предназначена, но и не делает ли она то, что не должна делать. Необходимо любую программу проверить на нежелательные побочные эффекты. Например, если программа обработки и печати какой-нибудь ведомости дублирует первую или последнюю строку, то она содержит ошибку. Принцип 6. Вероятность наличия необнаруженных ошибок в части программы пропорциональна числу ошибок, уже обнаруженных в этой части. Из этого принципа можно сделать вывод: если в какой-нибудь части программы обнаружено больше ошибок, чем в других, то ее необходимо тестировать более тщательно. Метод верификации. Один пользователь заполняет БД с документов, второй сравнивает на соответствие Таким образом выявляются ошибки. (массивный подход) Один заполняет, второй заполняет посимвольно. При этом ошибки блокируются в дальнейшем заполнении БД. (символьный подход) Верность данного метода составляет 95-98%. Остальные 2-5% достоверности информации обнаруживаются после использования БД. Немедленное размещение собранных на входных бланках данных в БД не представляется целесообразным по следующим причинам: данные неминуемо содержат большое число ошибок, допущенных как при сборе информации, так и при переносе ее на бланки. Эти ошибки проще выявить и исправить до загрузки данных в БД. Попытка же помещения в БД ошибочных данных может привести к нарушению ограничений целостности, что в конечном счете скажется на эффективности информационной системы; собранные данные отражают форматы входных бланков, которые, в свою очередь, разработаны на основе структуры исходных документов. При этом организация данных не ориентирована на оптимизацию алгоритма загрузки БД, вследствие чего непосредственный ввод в базу данных может оказаться крайне длительной процедурой, а соответствующий алгоритм неоправданно сложным. Поскольку речь идет о вводе большой и заранее подготовленной порции данных, то перед загрузкой в БД целесообразнее выполнить проверку корректности данных и преобразовать их к виду, ориентированному на последующую обработку. На входе такой программы используются значения заполненных входных бланков, а на выходе - протокол обнаруженных ошибок и файл, содержащий подмножество данных со структурой, ориентированной на алгоритм их загрузки в БД. Назовем этот файл загрузочным файлом (ЗФ). На практике функции контроля и преобразования могут выполнять несколько программ, каждая из которых ориентирована на определенный формат входного бланка. Выявленные ошибочные данные подлежат исправлению, повторному вводу. Цель тестирования- убедиться в том, что программа функционирует как следует, что она соответствует спецификациям и что она решает задачу. Цель верификации- устранить ошибки в программе, и здесь не обязательно добиваться такого результата, как при тестировании. При тестировании выявляются ошибки, которые должны быть исправлены. При верификации на любой стадии некоторые части программы могут оставаться неоттестированными, поскольку рассматриваются только те ошибки, которые проявляются, а остальные так и остаются нетронутыми. В идеальном случае программа должна быть оттестирована для всех возможных комбинаций входных данных, а выходные данные должны сравниваться с заранее рассчитанными правильными результатами. Однако даже для самых простых программ число входных комбинаций очень велико и может приближаться к бесконечности. Но внутренние операции вычислительной системы можно рассматривать обобщенно: если они работают с одним набором операндов, то они будут работать и с другими схожими наборами операторов. Но такое утверждение не верно для программ, которые содержат условные переходы. Тестирование должно быть сосредоточено на проверке небольших отдельных фрагментов, которые обладают указанными свойствами. Такой принцип хорошо согласуется с принципами структурного программирования (см рисунок в "сверху-вниз"), требующими разбиения на логические и функциональные модули. Каждый из них проверяется индивидуально, но не изолированно. Тестировании, согласно общему принципу проводится сверху-вниз. На каждом этапе функции более низких модулей моделируются при тестировании данного модуля по всем его логическим ветвям. После завершения теста данные, выданные программой должны быть сверены с предварительно вычисленным результатом. Процесс тестирования удостоверяет качество программы, поэтому он должен быть документирован. В документации должно содержаться детальное описание тестовых процедур, тестовые наборы данных и результаты, которые должны быть для них получены. Верификация. Единственный симптом, первоначально указавший на наличие ошибки, как правило сам по себе не несет достаточно информации. Дополнительная информация может быть получена после прогона теста. Однако генерация слишком большого объема информации может препятствовать обнаружению необходимых фактов. Более удачным решением является трассировка программы в "окрестностях" ошибки. Некоторые компиляторы обеспечивают трассировку, при помощи которой можно легко проследить за ходом выполнения программы оператор за оператором, узнать значения интересующих выражений. Одним из полезных средств отладки является избирательный вывод, т.е. выдача на печать выбранных переменных в ключевых точках программы. Отладка не заканчивается нахождением источника ошибки, ошибка должна быть исправлена. Поспешное исправление ошибок может привести к генерации новых (думать надо). Также в процессе верификации могут быть выявлены внешние ошибки программного и аппаратного обеспечения.