В.В. Кулямин - Тестирование на основе моделей, страница 8

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

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

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

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

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

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

К этому виду относится,например, тестирование на отказ (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. Критерии полноты тестированияНабор тестов, используемый при тестировании, всегда конечен и, более того, ограниченсоображениями экономической эффективности распределения ресурсов между разнымивидами деятельности при разработке ПО. Поэтому крайне важно строить его так, чтобыиспользуемые тесты проверяли как можно больше разных аспектов функциональностисистемы в как можно большем разнообразии ситуаций.