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

На языках C, С++, Java или C# это может быть передано так: ( x >=0 )? x : -x.Можно, например, проверять, что abs(x) >= 0 для любого x.Попробуем взять x = –2147483648, например, в Java. Каков будет результат?Правильный ответ: –2147483648.Этот неожиданный результат — отрицательное число в качестве абсолютной величины— объясняется тем, что в машинной арифметике 32-битных целых чисел выполненосоотношение –(–2147483648) = –2147483648. Приведенное выше определение abs(x) остаетсяправильным, неверно только заключение о том, что abs(x) >= 0.Чтобы объяснить полученное «странное» соотношение, надо понимать, чемруководствовались создатели целочисленной машинной арифметики.

Им нужно было целыечисла, которых бесконечно много, представить в машине как некоторое конечное множество.При этом, однако, надо сохранить основополагающие свойства арифметических действий —сложения, вычитания и умножения. Наиболее похожими на целые числа конечнымимножествами с таким набором операций являются множества (кольца) классов целых чиселпо какому-то модулю, например Z2 = {[0], [1]}, где [0] — класс четных чисел, а [1] — класснечетных, или Z3 = {[0], [1], [2]}, где [n] — класс чисел, имеющих остаток n при делении на3. Поскольку в машине удобно представлять числа в двоичной записи, для эффективногорасхода памяти стоит взять модуль равным степени 2, например 232. То есть, машинноечисло n будет обозначать класс чисел, равных n по модулю 232.

Если к тому же хочется,чтобы действия с небольшими числами приводили к привычным результатам: 2+2 = 4, а 3–5= –2, в качестве представителей классов чисел по модулю 232 должны использоватьсянебольшие положительные и отрицательные числа. Таким образом, в качествепредставителей удобно выбрать числа 0, 1, –1, 2, –2, 3, –3, 4, –4 и т.д. Но, поскольку всего ихдолжно быть 232, для некоторого числа n, мы в итоге выберем n, но не выберем –n илинаоборот — ведь для 0 в этой последовательности уже нет соответствующегоотрицательного числа. Соответственно, конец ее выглядит как 2147483647, –2147483647,–2147483648 = –231. По причинам, связанным с эффективностью и простотой реализацииопераций, проще выбрать –231, чем 231 — при этом можно использовать первый битпредставления числа в значении его знака, а все вычисления производить побитно, по тем жепричинам не стоит вводить специальное число –0, что, например, сделано в арифметикечисел с плавающей точкой.

По модулю 232 выполнено –[–231] = [231] = [232–231] = [–231], что исоответствует выписанному выше соотношению.Другой пример. Как ведет себя tg(arctg(x)) при возрастающем x, которое является числом сплавающей точкой двойной точности? При x <= 1016 все идет как ожидается: tg(arctg(x)) = x снебольшой погрешностью, а вот дальше, как бы ни было велико x, tg(arctg(x)) дает один итот же результат 1.633123935319537⋅1016.

Для объяснения этого нужно знать, как устроенычисла с плавающей точкой, что служащее для представления π/2 число с плавающей точкойдвойной точности X = 884279719003555/562949953421312 меньше π/2 примерно на6.1232339957367658⋅10–17, и что получаемый результат является как раз значением tg(X) ≈1/(π/2 – X), вычисленным с двойной точностью.Заметьте, что половину страницы текста заняло объяснение лишь небольшой«странности» поведения операции взятия противоположного целого числа — одной изпростейших и наиболее точно определенных, которые только можно себе представить.

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

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

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

Во многих других случаях даже простонаписать четкое определение нелегко. Поэтому всегда необходим вдумчивый анализтребований, извлечение всех сведений, которые только можно получить из документации,стандартов, а также из личного общения с экспертами, архитекторами, разработчиками ипользователями тестируемой системы и другими заинтересованными лицами.Помогают в этом анализе попытки четко определить, как можно проверить требования.Например, попытка проверить правильность вычисление абсолютной величины при помощитождества abs(x) >= 0 проваливается, и этот факт вынуждает задуматься об основныхпринципах машинной арифметики. Формулируя требования в проверяемом виде, мы сразуполучаем очень хорошее определение правильного поведения, более аккуратное, чемсуществующие описания для подавляющего большинства программных систем.Если тесты создаются как обычно, в виде тестовых вариантов, их разработчик сразупытается определить, как именно проверять требования в той конкретной ситуации, котораявозникает в данном тесте.

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

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

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

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

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