Лекции. Тестирование ПО (all in one) (1186159), страница 11
Текст из файла (страница 11)
Генератор данных, удовлетворяющихнекоторому условию можно организовать, используя простой генератор данныхэтого типа и фильтрацию по данному условию — если поставляемые простымгенератором данные удовлетворяют условию, они передаются вовне, если нет —вычисляется следующая порция данных.oСоставной генератор. Генератор данных сложной структуры строится изгенераторов элементов этой структуры.
Например, если нужно построить объекты,у которых есть три поля, можно по отдельности строить значения полей, а потомобъединять их в объект. При объединении можно использовать декартовопроизведение множеств значений, то есть строить по объекту на каждуюсоздаваемую тройку значений полей, или использовать «диагональ» — объединятьтолько одновременно сгенерированные тройки значений полей.В составных генераторах данных, удовлетворяющих некоторым ограничениямцелостности (например, значение первого поля всегда должно быть большезначения второго), используются фильтры.Тестовые адаптеры.Тестовый адаптер предназначен для соединения теста с тестируемой системой в техслучаях, когда интерфейс тестируемой системы не соответствует тому, на которыйрассчитан тест.Такая ситуация может сложиться, если тесты для старой версии нужно перенести на•новую версию системы, причем изменений в проверяемой функциональности мало, ноесть изменения в интерфейсах — функции или команды названы по-другому, в нихизменен порядок параметров или типы параметров получили другие имена.Другая возможность — тесты создавались заранее, до разработки системы илипараллельно ей, на основе требований и проектной документации, а когда быларазработана сама тестируемая система, часть ее интерфейсов изменилась по сравнению спроектом.Третий случай использования адаптеров — тестирование на соответствие некоторомуобщему стандарту, для которого может быть много реализаций от разных поставщиков.Такая ситуация, например, в телекоммуникационном ПО — стандарты на протоколывзаимодействия фиксированы, но есть много разных разработчиков этого ПО и ихсистемы должны успешно взаимодействовать друг с другом.
При этом тестовый набордля стандарта делается при самых общих предположениях об интерфейсе (простоналичие определенных функций и структура данных их параметров) — такой тестовыйнабор называется абстрактным. Чтобы использовать абстрактный тестовый набор длятестирования некоторой реализации, он дополняется набором адаптеров,привязывающих использованный в нем абстрактный интерфейс к конкретномуинтерфейсу данной реализации.Заглушки.Тестовой заглушкой называется компонент, играющий роль необходимого тестируемойсистеме компонента, который еще не разработан.При интеграционном и модульном тестировании иногда приходится тестироватьотдельно компоненты, которым для работоспособности необходимы другие.
Эти другиекомпоненты могут быть еще не готовы или же они не включаются в тест, посколькусильно усложнили бы его. Чтобы тестируемый компонент мог работать во времятестирования, вместо отсутствующих компонентов подставляются заглушки, которыеимеют такой же интерфейс, что и отсутствующие компоненты, но устроены как можноболее просто, например, возвращают один и тот же результат или генерируют егослучайно.Виды тестированияТестировать можно соблюдение любых требований, соответствие которым выявляется вовремя работы ПО.
Из характеристик качества по ISO 9126 этим свойством не обладаюттолько атрибуты удобства сопровождения. Поэтому выделяют виды тестирования, связанныес проверкой определенных характеристик и атрибутов качества — тестированиефункциональности, надежности, удобства использования, переносимости ипроизводительности, а также тестирование отдельных атрибутов — защищенности,функциональной пригодности и пр. Кроме того, особо выделяют нагрузочное илистрессовое тестирование, проверяющее работоспособность, надежность ПО и показателиего производительности в условиях повышенных нагрузок — при большом количествепользователей, интенсивном обмене данными с другими системами, большом объемепередаваемых или используемых данных, и пр.Рассматриваемые в данном курсе методы построения тестов ориентированы в большеймере на тестирование функциональности.
Их можно использовать и для тестированияпереносимости, производительности или надежности. Однако при их использовании нужноиметь в виду следующее.•Для тестирования производительности необходим дополнительный анализ фактороввозможного снижения производительности — объема входных данных, объема базыданных системы, количества пользователей, количества процессов и потоков в системе,объема данных, передаваемых между компонентами системы и пр. Полнота такоготестирования сильно зависит от используемого в тестах набора факторов.Выделение адекватного набора аспектов, влияющих на производительность, нерассматривается в данном курсе.•При тестировании надежности должны измеряться статистические показатели работысистемы и должны использоваться близкие к реальным по своим статическим свойствамвходные данные.
Вопросы статистического моделирования различных аспектов входныхданных, поведения пользователей и других систем, которые могут оказывать влияние наработоспособность тестируемой системы, не рассматриваются в данном курсе. Также необсуждаются методы определения статистических показателей ее работы.Тестирование удобства использования сильно отличается от других видов тестирования,поскольку всегда связано с оценкой удобства выполняемых действий и представления ихрезультатов в системе.
По этой причине при таком тестировании всегда используютсяэкспертные оценки, требующие вовлечения квалифицированных специалистов по удобствуиспользования. Автоматизировать этот вид тестирования в той же мере, как другие, неудается.На основе исходных данных, используемых для построения тестов, тестирование делят наследующие виды.•Тестирование черного ящика, нацеленное на проверку требований. Тесты для него икритерий полноты тестирования строятся на основе требований и ограничений, четкозафиксированных в спецификациях, стандартах, внутренних нормативных документах.Часто такое тестирование называется тестированием на соответствие (conformancetesting). Частным случаем его является функциональное тестирование — тесты длянего, а также используемые критерии полноты проведенного тестирования определяютна основе требований к функциональности.Еще одним примером тестирования на соответствие является аттестационное илисертификационное тестирование, по результатам которого программная системаполучает (или не получает) официальный документ, подтверждающий ее соответствиеопределенным требованиям и стандартам.•Тестирование белого ящика, оно же структурное тестирование — тесты создаютсяна основе знаний о структуре самой системы и о том, как она работает.
Критерииполноты основаны на проценте элементов кода, которые отработали в ходе выполнениятестов. Для оценки степени соответствия требованиям могут привлекатьсядополнительные знания о связи требований с определенными ограничениями назначения внутренних данных системы (например, на значения параметров вызовов,результатов и локальных переменных).•Тестирование, при котором используются как требования, так и знания о внутреннемустройстве системы, используется на практике чаще, чем указанные выше крайниеразновидности. Оно иногда называется тестированием серого ящика, но термин этотупоминается реже, чем тестирование черного или белого ящика.•Тестирование, нацеленное на определенные ошибки.
Тесты для такого тестированиястроятся так, чтобы гарантированно выявлять определенные виды ошибок. Полнотатестирования определяется на основе количества проверенных ситуаций по отношениюк общему числу ситуаций, которые мы пытались проверить. К этому виду относится,например, тестирование на отказ (smoke testing), в ходе которого просто пытаютсявывести систему из строя, давая ей на вход как обычные данные, так и некорректные, снарочно внесенными ошибками.Еще одна классификация видов тестирования основана на том уровне, на который ононацелено.
Эти же разновидности тестирования можно связать с фазой жизненного циклатестируемой системы, на которой они выполняются.Модульное тестирование (unit testing) предназначено для проверки правильностиотдельных модулей, вне зависимости от их окружения. При этом проверяется, что еслимодуль получает на вход данные, удовлетворяющие определенным критериямкорректности, то и результаты его корректны. Для описания критериев корректностивходных и выходных данных часто используют программные контракты —предусловия, описывающие для каждой операции, на каких входных данных онапредназначена работать, постусловия, описывающие для каждой операции, как должнысоотноситься входные данные с возвращаемыми ею результатами, и инварианты,определяющие критерии целостности внутренних данных модуля.Модульное тестирование является важной составной частью отладочноготестирования, выполняемого разработчиками для отладки написанного ими кода.•Интеграционное тестирование (integration testing) предназначено для проверкиправильности взаимодействия модулей некоторого набора друг с другом.
При этомпроверяется, что в ходе совместной работы модули обмениваются данными и вызовамиопераций, не нарушая взаимных ограничений на такое взаимодействие, например,предусловий вызываемых операций. Интеграционное тестирование также используетсяпри отладке, но на более позднем этапе разработки.При интеграционном тестировании могут использоваться различные стратегииприсоединения новых компонентов к тестируемой системе.oПри стратегии «сверху вниз» сначала тестируют модули, находящиеся на самомверхнем уровне и непосредственно взаимодействующие с пользователями иливнешними системами. Затем к ним постепенно добавляют модули, вызываемыеими, выполняя тестирование после добавления каждого модуля, затем — модулиследующих уровней. На каждом шаге, кроме последнего, в котором участвуют всемодули системы, вместо отсутствующих модулей используются заглушки.oПри стратегии «снизу вверх» сначала тестируются модули нижнего уровня, независящие от других модулей системы, затем добавляются модули, зависящие отних, и т.д., вплоть до модулей самого верхнего уровня.
При этом заглушкииспользуются редко, только в тех случаях, когда только что добавленный втестируемую систему модуль зависит от других модулей того же уровня.Часто применяются смешанные стратегии — часть этапов интеграции выполняется«сверху вниз», часть — «снизу вверх».Метод, которым настоятельно не рекомендуется пользоваться, — проведениеинтеграционного тестирования сразу для всех модулей большой системы, безпредварительной отладки взаимодействия внутри отдельных групп модулей.•Системное тестирование (system testing) предназначено для проверки правильностиработы системы в целом, ее способности правильно решать поставленныепользователями задачи в различных ситуациях.Системное тестирование выполняется через внешние интерфейсы ПО и тесно связано стестированием пользовательского интерфейса (или через пользовательскийинтерфейс), проводимым при помощи имитации действий пользователей надэлементами этого интерфейса.
Частными случаями этого вида тестирования являютсятестирование графического пользовательского интерфейса (Graphical User Interface,GUI) и пользовательского интерфейса Web-приложений (WebUI).Если интеграционное и модульное тестирование чаще всего проводят, воздействуя накомпоненты системы при помощи операций предоставляемого ими программногоинтерфейса (Application Programming Interface, API), то на системном уровне безиспользования пользовательского интерфейса не обойтись, хотя тестирование через APIв этом случае также вполне возможно.Особняком стоит регрессионное тестирование, используемое для проверки того, чтовносимые небольшие изменения и исправления ошибок не нарушают стабильность и не•снижают работоспособность системы.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
