3.2 Технология тестирования программного обеспечения

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

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

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

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

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

Итак, качество ПС – совокупность наиболее существенных качественных показателей (факторов) в достаточной степени характеризующих ПС. К общим факторам относят [8]:

• функциональность – как набор функций, реализующих установленные или предполагаемые потребности пользователей;

• корректность – соответствие реализации системы ее спецификации и непротиворечивости;

• интерфейс – как средство общения с пользователями системы;

• открытость – характеризующая модифицируемость системы;

• комфортность – характеризующая удобность использования ПС;

• современность - характеризующая степень использования современных информационных технологий представления информации и систем связи на текущий момент времени.

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

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

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

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

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

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

При рассмотрении объектно-ориентированного тестирования наименьшим тестируемым элементом является объект (класс). В данном случае нельзя тестировать отдельную операцию изолированно, как это принято в стандартном подходе к тестированию модулей. Любую операцию приходится рассматривать как часть класса. Объектно-ориентированное программное обеспечение не имеет иерархической управляющей структуры, поэтому здесь неприменимы методики как восходящего, так и нисходящего тестирования.

Предлагается две методики тестирования объектно-ориентированных систем:

• тестирование, основанное на потоках;

• тестирование, основанное на использовании.

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

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

67