лекции, страница 8

К этому виду относится,например, тестирование на отказ (smoke testing), в ходе которого просто пытаютсявывести систему из строя, давая ей на вход как обычные данные, так и некорректные, снарочно внесенными ошибками.Еще одна классификация видов тестирования основана на том уровне, на который ононацелено. Эти же разновидности тестирования можно связать с фазой жизненного циклатестируемой системы, на которой они выполняются.•Модульное тестирование (unit testing) предназначено для проверки правильностиотдельных модулей, вне зависимости от их окружения. При этом проверяется, что еслимодуль получает на вход данные, удовлетворяющие определенным критериямкорректности, то и результаты его корректны. Для описания критериев корректностивходных и выходных данных часто используют программные контракты —предусловия, описывающие для каждой операции, на каких входных данных онапредназначена работать, постусловия, описывающие для каждой операции, как должнысоотноситься входные данные с возвращаемыми ею результатами, и инварианты,определяющие критерии целостности внутренних данных модуля.Модульное тестирование является важной составной частью отладочноготестирования, выполняемого разработчиками для отладки написанного ими кода.•Интеграционное тестирование (integration testing) предназначено для проверкиправильности взаимодействия модулей некоторого набора друг с другом.

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

Затем к ним постепенно добавляют модули, вызываемыеими, выполняя тестирование после добавления каждого модуля, затем — модулиследующих уровней. На каждом шаге, кроме последнего, в котором участвуют всемодули системы, вместо отсутствующих модулей используются заглушки.oПри стратегии «снизу вверх» сначала тестируются модули нижнего уровня, независящие от других модулей системы, затем добавляются модули, зависящие отних, и т.д., вплоть до модулей самого верхнего уровня. При этом заглушкииспользуются редко, только в тех случаях, когда только что добавленный втестируемую систему модуль зависит от других модулей того же уровня.Часто применяются смешанные стратегии — часть этапов интеграции выполняется«сверху вниз», часть — «снизу вверх».Метод, которым настоятельно не рекомендуется пользоваться, — проведениеинтеграционного тестирования сразу для всех модулей большой системы, безпредварительной отладки взаимодействия внутри отдельных групп модулей.•Системное тестирование (system testing) предназначено для проверки правильностиработы системы в целом, ее способности правильно решать поставленныепользователями задачи в различных ситуациях.Системное тестирование выполняется через внешние интерфейсы ПО и тесно связано стестированием пользовательского интерфейса (или через пользовательскийинтерфейс), проводимым при помощи имитации действий пользователей надэлементами этого интерфейса.

Частными случаями этого вида тестирования являютсятестирование графического пользовательского интерфейса (Graphical User Interface,GUI) и пользовательского интерфейса Web-приложений (WebUI).Если интеграционное и модульное тестирование чаще всего проводят, воздействуя накомпоненты системы при помощи операций предоставляемого ими программногоинтерфейса (Application Programming Interface, API), то на системном уровне безиспользования пользовательского интерфейса не обойтись, хотя тестирование через APIв этом случае также вполне возможно.Особняком стоит регрессионное тестирование, используемое для проверки того, чтовносимые небольшие изменения и исправления ошибок не нарушают стабильность и неснижают работоспособность системы.

Регрессионное тестирование используется на этапесопровождения, после внесения изменений и исправлений в систему, при выпуске ееочередной версии.Литература[1]IEEE Guide to Software Engineering Body of Knowledge, SWEBOK, 2004.[2]В. В. Кулямин. Технологии программирования. Компонентный подход. М: Интернетуниверситет информационных технологий — БИНОМ. Лаборатория знаний, 2007.http://www.ispras.ru/~kuliamin/lectures-sdt/Lecture01.pdf.Тестирование на основе моделейВ.

В. КуляминЛекция 3. Критерии полноты тестированияНабор тестов, используемый при тестировании, всегда конечен и, более того, ограниченсоображениями экономической эффективности распределения ресурсов между разнымивидами деятельности при разработке ПО. Поэтому крайне важно строить его так, чтобыиспользуемые тесты проверяли как можно больше разных аспектов функциональностисистемы в как можно большем разнообразии ситуаций. Чтобы систематическим образомперебирать существенно отличающиеся друг от друга ситуации, используют критерииполноты тестирования или критерии адекватности тестирования [1,2]. Тестовый набор,удовлетворяющий заданному критерию полноты, называют полным по этому критерию.Чаще всего для определения критерия полноты некоторые из возможных тестовыхситуаций рассматривают как эквивалентные и определяют количество классовнеэквивалентных тестовых ситуаций, встретившихся или «покрытых» во времятестирования.

Такие критерии полноты называются критериями тестового покрытия [1-3].При этом определяется и числовая метрика тестового покрытия — доля покрытых классовситуаций среди всех возможных. Критерий полноты может использовать различныезначения метрики, например, он может требовать, чтобы полный тестовый набор всегдапокрывал 100% выделенных классов ситуаций, или же считать достаточным покрытие 85%классов ситуаций. Поскольку для одной метрики покрытия можно определить многокритериев полноты, далее речь, чаще всего, идет о различных метриках тестового покрытия.Полноту тестирования можно определять по-разному, но в основе любого критерияполноты лежит представление о возможных ошибках в тестируемой системе. Различныеспособы классификации ситуаций, отражающие их разнообразие с точки зрениятестирования, перечислены ниже.

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

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

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

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