Лекция 2. Основные задачи и виды тестирования (1186161), страница 3
Текст из файла (страница 3)
Соответственно, для мантиссы используется 112 бит и смещениепорядка равно 16383. Они не специфицированы в стандарте, но имеют аналогичнуюструктуру.В качестве примера укажем представление числа -1710 в виде чисел однократной и двойнойточности. Поскольку -1710 = (-1)1·2131-127·1.00012 = (-1)1·21027-1023·1.00012, соответственно, онопредставляется в виде числа однократной точности как1 10000011 00010000000000000000000, а в виде числа двойной точности как1 10000000011 0001000000000000000000000000000000000000000000000000.Некоторые граничные значения таких чисел для разных форматов указаны в Таблице 1. Приэтом для расширенной двойной точности используются параметры 32-битной архитектурыIntel.ОбщийвидОднократнаяточностьДвойнаяточностьРасширеннаядвойнаяточностьЧетырехкратнаяточностьСамоемаленькоеденормализованноеположительное число2-b-n+k+22-1492-10742-164462-16494Самоемаленькоенормализованноеположительное число2-b+12-1262-10222-163822-16382Самоебольшоеположительное число2b-n+k+1··(2n-k-1)2104·(224-1) 2971·(253-1)216319·(265-1)216271·(2113-1)Самое большое число,меньшее 11-2-n+k1-2-241-2-531-2-651-2-113Самоемаленькоечисло, большее 11+2-n+k+11+2-231+2-521+2-641+2-112Таблица 1.
Граничные значения чисел с плавающей точкой.Заметьте, что половину страницы текста заняло объяснение лишь небольшой «странности»поведения операции взятия противоположного целого числа — одной из простейших инаиболее точно определенных, которые только можно себе представить.
Для полного иаккуратного разбора примера с арктангенсом потребовалась бы еще дополнительно парастраниц. При рассмотрении же более сложных функций программных систем, не имеющихтаких точных математических аналогов, возникают гораздо более серьезные проблемы.Именно поэтому здесь в качестве примеров взяты математические функции — любойчеловек, окончивший два курса ВУЗа по физико-математической или техническойспециальности, достаточно хорошо представляет себе, что это такое, и при желании можетсамостоятельно понять, как должна работать такая функция.
Если же надо понять, какработают менее однозначно определенные операции, возникает такое количество возможныхразнообразных смыслов, что чисто умозрительно решить, какой именно правилен,практически невозможно — необходима документация, зафиксированные в документахтребования, общение с разработчиками системы или с экспертами в данной предметнойобласти.Например, для адекватного понимания работы операции чтения заданного количествабайт из файла нужно уметь четко отвечать на множество вопросов.
Что происходит, еслифайла нет? Что будет, если он есть, но у данного процесса нет прав на работу с ним? Чтобудет результатом, если размер файла меньше запрашиваемого количества байт? А еслидругие операции в тоже время записывают данные в этот же файл? И пр., и т.д., и т.п.В то же время для операций ввода-вывода, как и для большинства других операций,реализованных в рамках широко используемых библиотек, можно, после определенныхусилий, достаточно строго определить математическую модель, адекватно описывающую ихработу. Для многих же практических примеров — операций биллинговой системы, системыавтоматического управления боевым кораблем или гидроэлектростанцией — таких моделейвообще нет, никто никогда не продумывал такие сложные системы во всех их деталях.
Наформальную проработку их при современных технологиях уйдет времени и усилий гораздобольше, чем это допустимо с точки зрения экономической оправданности таких систем.Таким образом, одна из наиболее сложных задач — адекватно понять требования,понять, что именно обозначает каждое утверждение в документации, которое относится кданной операции. В примере с абсолютной величиной вроде бы удалось сразу написатьчеткое определение, но понять его помогает только приведенный пример «странного»поведения. Только после проведенного дополнительного анализа становится возможным безошибок выводить следствия из этого определения (первоначальный вывод о том, чтоабсолютная величина больше 0 был ошибкой).
Во многих других случаях даже простонаписать четкое определение нелегко. Поэтому всегда необходим вдумчивый анализтребований, извлечение всех сведений, которые только можно получить из документации,стандартов, а также из личного общения с экспертами, архитекторами, разработчиками ипользователями тестируемой системы и другими заинтересованными лицами.Помогают в этом анализе попытки четко определить, как можно проверить требования.Например, попытка проверить правильность вычисление абсолютной величины при помощитождества abs(x) >= 0 проваливается, и этот факт вынуждает задуматься об основныхпринципах машинной арифметики.
Формулируя требования в проверяемом виде, мы сразуполучаем очень хорошее определение правильного поведения, более аккуратное, чемсуществующие описания для подавляющего большинства программных систем.Если тесты создаются как обычно, в виде тестовых вариантов, их разработчик сразупытается определить, как именно проверять требования в той конкретной ситуации, котораявозникает в данном тесте. Методы тестирования на основе моделей требуют описыватьтребования к поведению операции «вообще», в произвольной ситуации, в которой онадолжна работать.
При этом в качестве результата анализа требований получается некотораямодель требований — целостное, полное, непротиворечивое и точное описание того, чтодолжна делать система. Она указывает, как проверять правильность работы системы и даетвозможность разделить формулировку проверяемых требований и придумывание ситуацийдля их проверки на два отдельных вида деятельности, повышая качество и того, и другого.Отчеты о результатах тестированияХотя основной целью тестирования является лишь проверка соответствия требованиям,или же, наоборот, проверка наличия ошибок в тестируемой системе, тестирование, послекоторого остается только информация вида «ошибок нет» или «ошибки есть», практическибесполезно. На практике нужны тесты, после выполнения которых остается достаточноинформации о найденных ошибках, чтобы разработчик мог локализовать их в ходе отладки снебольшими усилиями.
Кроме того, нужна еще и информация о полноте выполненныхтестов. В общем случае отчеты о ходе тестирования должны содержать следующее.•Данные обо всех обнаруженных ошибках.Тип ошибки по некоторой классификации, который поясняет, что же произошло.Например: затребовано слишком много памяти, функция работает слишком долго,выдается некорректный результат, выполняется запись неверных данных кудалибо, не возвращается управление, разрушение процесса.oКакая проверка зафиксировала ошибку, что именно было сочтено некорректным,какое требование при этом проверялось.oКаков наиболее короткий выделяемый сценарий действий, который позволяетповторить эту ошибку.
Иногда достаточно указания только одной неправильносработавшей операции или функции, но в сложных случаях необходимо повторитьнекоторый набор действий, в совокупности приведший к некорректной работесистемы. Операция, при выполнении которой ошибка проявляется, вовсе необязательно сама содержит ошибку, она может просто использовать некорректныерезультаты работы других операций.Данные о полноте тестирования по нескольким критериям — какие тестовые ситуациивозникали в ходе тестирования, а какие нет, каковы значения измерявшихся метриктестового покрытия.Информацию о затронутых элементах тестируемой системы — вызываемых функциях иметодах, выполняемых командах, затрагиваемых классах, компонентах, подсистемах —а также о проверяемых в ходе тестирования требованиях всегда полезно иметь, дажекогда полнота тестирования определяется другими способами.o•Организация тестовых наборовПоскольку часто набор тестов представляет собой довольно сложную систему, онадолжна быть хорошо организована.
Это особенно важно для тестов, которые планируетсяподдерживать, сопровождать и пополнять долгое время. При организации тестов нужнотакже аккуратно выделять отдельные модули, учитывая возможности их повторногоиспользования, как и при проектировании любой другой программной системы. Такимобразом, хорошо спроектированный тестовый набор всегда использует те же базовыепринципы программной инженерии, что и любая хорошо спроектированная программнаясистема — абстракцию и уточнение, модульность и многократное использование [4].Помимо этого, хорошая организация тестовых наборов должна подчинятьсядополнительным ограничениям, связанным уже с самой природой тестов.•Тесты должны иметь дополнительную структуру, основанную на их связи скомпонентами тестируемой системы. Она может быть представлена, например, в явноуказанной в описании каждого теста или в комментариях к нему ссылке насоответствующие компоненты.Наличие такой информации облегчает сопровождение тестового набора при небольшихизменениях в тестируемой системе, без изменения ее функциональности.
В этих случаяхстановится возможным быстро найти все тесты, подлежащие корректировке в связи стакими изменениями.Другая выгода от наличия явных связей с тестируемыми компонентами — возможностьминимизации количества повторно выполняемых тестов при небольших изменениях,которые никак не отражаются на интерфейсе системы или ее функциях. При этом можновыполнять только те тесты, которые затрагивают измененные или зависящие отизмененных компоненты.•Тесты должны быть явно связаны и с проверяемыми требованиями.Такая привязка позволяет, помимо оценки полноты тестового набора, снижатьтрудозатраты на его модификацию при изменениях в требованиях, быстро выделяятолько те тесты, которые должны измениться.Если возникает необходимость проверить только заданное подмножество функцийсистемы, привязка тестов к требованиям также поможет минимизировать исполняемыйтестовый набор.•Тесты должны быть разбиты на группы по нескольким различным аспектам.
Эторазбиение может влиять на порядок выполнения тестов.oНапример, полезно отделять тесты, выполнение которых полностьюавтоматизировано, от тех, где требуется вмешательство человека. При этом частоавтоматические тесты удобно выполнять раньше, поскольку обнаруживаемые имиошибки могут сделать выполнение тестов под контролем человека более трудным.oПри тестировании сложных систем часто требуются достаточно сложныесценарии работы теста.