Тема 2. 1 верификация и аттестация по

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

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

Основным методом обнаружения ошибок в программном обеспечении является его тестирование. Эффективность тестирования — важнейший фактор, определяющий стоимость и длительность разработки больших программных изделий с заданным качеством. Затраты на тестирование для обнаружения ошибок в программном обеспечении достигают 30—40% общих затрат на его разработку и в значительной степени определяют его качество.

Тестирование — это процесс выполнения программного обеспечения с намерением найти в нем ошибку — довольно необычный процесс (и поэтому трудный), т.к. этот процесс разрушительный.

Цель проверяющего (тестовика) — заставить программное обеспечение сбиться. Он доволен, если это ему удается.Если программное изделие правильно ведет себя для солид­

ного набора тестов, нет оснований утверждать, что в нем нет ошибок. Просто неизвестно, когда оно не сработает и можно говорить лишь о некотором уровне уверенности в его правильности.

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

Если задача тестовика — продемонстрировать, что в программном обеспечении нет ошибок, то подсознание побуждает его выбирать такие тесты, которые с большой вероятностью будут выполняться правильно, и найдет он ошибок не слишком много. Если же его цель — вскрыть наличие ошибок в нем, он найдет значительную их часть!

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

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

Тесты составляются после разработки алгоритма, но до программирования.

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

В некоторых случаях тестирования рекомендуется производить «миниатюризацию» программы, т.е. разумно сокращать объём данных по сравнению с реальным. Например, создать укороченную базу данных. Проверить матрицу 50x50 вручную невозможно. Поэтому в качестве теста может быть использована матрица 5x5. Точно так же, если некоторая подпрограмма работает в цикле 5 раз, она сможет работать и 105 раз. Правда, при миниатюризации программы могут произойти ситуации: либо существующие в программе ошибки в результате упрощающих изменений станут неявными или временно исчезнут, либо появятся новые ошибки.

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

В целом составление тестов — большое искусство, т.к. полностью этот процесс формализации не поддается.

Программные изделия как объекты тестирования имеют ряд особенностей, которые отличают процесс их тестирования от традиционного, применяемого для проверки аппаратуры и других технических изделий.

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

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

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

Поэтому тестирование программного обеспечения проводится в объёмах, минимально необходимых для его проверки в некоторых ограниченных пределах изменения параметров и условий их функционирования.

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

Для ускорения отладки не безразличен порядок пропуска тестов: сначала пропускаются простые тесты...

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

Усложнение тестовых данных должно происходить постепенно.

Процесс тестирования программного обеспечения можно разделить на три этапа:

— проверка в нормальных условиях;

— проверка в экстремальных условиях;

— проверка в исключительных ситуациях.

Каждый из этих трех этапов проверки должен гарантировать получение верных результатов при правильных входных данных и/или выдачу сообщений об ошибках при неправильных входных данных.

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

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

Типичные примеры — очень большие числа, очень малые числа или отсутствие информации.

Проверка в исключительных ситуациях. Используются исходные данные, значения которых лежат за пределами допустимой области их изменения.

Наихудшая ситуация когда программное обеспечение воспринимает неверные данные как правильные и выдаёт неверный, но правдоподобный результат.

Программное обеснечение должно самоотвергать любые данные, которые оно не в состоянии обрабатывать верно.

Пример тестов. Пусть требуется вычислить длину диагонали Параллелепипеда

Необходимо сформировать тестовые данные для нормальных, экстремальных и исключительных условий.

Создание программного обеспечения без ошибок — трудоемкая работа. Поэтому разумно всегда настаивать на выделении необходимого времени для обеспечения надлежащего качества тестирования программного обеспечения. Нарушение этого условия приводит к неполному тестированию и, как следствие, — к ненадежному программному продукту, в то время как его соблюдение дает хорошие результаты.

Различают еще так называемые «Альфа»- и «Бета»-тестирования.

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

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

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

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

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

Кстати, в данных случаях часто помогают протоколы обнаруженных и фиксированных ошибок.

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

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