Lecture02 (Лекции в ПДФ), страница 3

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

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

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

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

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

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

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

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

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

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

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

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