Процесс тестирования который позволяет выявлять ошибки при объединении модулей

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

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

Цель тестирования модулей – сравнение функций, реализуемых модулем, со спецификациями его функций или интерфейса.

Тестирование модулей в основном ориентировано на принцип «белого ящика». Это объясняется, прежде всего, тем, что принцип «белого ящика» труднее реализовать при переходе в последующем к тестированию более крупных единиц, например программ в целом. Кроме того, последующие этапы тестирования ориентированы на обнаружение ошибок различного типа, т. е. ошибок, не обязательно связанных с логикой программы, а возникающих, например, из–за несоответствия программы требованиям пользователя.

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

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

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

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

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

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

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

При этом подходе возникают два вопроса: 1. «Что делать, когда тестируемый модуль вызывает модуль более низкого уровня (которого в данный момент еще не существует)?» и 2. «Как подаются тестовые данные?»

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

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

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

Преимуществом нисходящего подхода очень часто считают отсутствие необходимости в драйверах; вместо драйверов вам просто следует написать «заглушки».

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

Второй тонкий недостаток нисходящего подхода состоит в том, что он может породить веру в возможность начать программирование и тестирование верхнего уровня программы до того, как вся программа будет полностью спроектирована. Эта идея на первый взгляд кажется экономичной, но обычно дело обстоит совсем наоборот. Большинство опытных проектировщиков признает, что проектирование программы – процесс итеративный. Редко первый проект оказывается совершенным. Нормальный стиль проектирования структуры программы предполагает по окончании проектирования нижних уровней вернуться назад и подправить верхний уровень, внеся в него некоторые усовершенствования или исправляя ошибки, либо иногда даже выбросить проект и начать все сначала, потому что разработчик внезапно увидел лучший подход. Если же головная часть программы уже запрограммирована и оттестирована, то возникает серьезное сопротивление любым улучшениям ее структуры. В конечном итоге за счет таких улучшений обычно можно сэкономить больше, чем те несколько дней или недель, которые рассчитывает выиграть проектировщик, приступая к программированию слишком рано.

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

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

Возникает вопрос: «Что лучше – выполнить по отдельности тестирование каждого модуля, а затем, комбинируя их, сформировать рабочую программу или же каждый модуль для тестирования подключать к набору ранее оттестированных модулей?». Первый подход обычно называют монолитным методом, или методом «большого удара», при тестировании и сборке программы; второй подход известен как пошаговый метод тестирования или сборки.

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

Детального разбора обоих методов мы делать не будем, приведем лишь некоторые общие выводы.

1.Монолитное тестирование требует больших затрат труда. При пошаговом же тестировании «снизу– вверх» затраты труда сокращаются.

2.Расход машинного времени при монолитном тестировании меньше.

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

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

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

6.Результаты пошагового тестирования более совершенны.

В заключение отметим, что п. 1, 4, 5, 6 демонстрируют преимущества пошагового тестирования, а п. 2 и 3 – его недостатки. Поскольку для современного этапа развития вычислительной техники характерны тенденции к уменьшению стоимости аппаратуры и увеличению стоимости труда, последствия ошибок в математическом обеспечении весьма серьезны, а стоимость устранения ошибки тем меньше, чем раньше она обнаружена; преимущества, указанные в п. 1, 4, 5, 6, выступают на первый план. В то же время ущерб, наносимый недостатками (п. 2 и 3), невелик. Все это позволяет нам сделать вывод, что пошаговое тестирование является предпочтительным.

Убедившись в преимуществах пошагового тестирования перед монолитным, исследуем две возможные стратегии тестирования: нисходящее и восходящее. Прежде всего внесем ясность в терминологию.

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

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

В этой главе излагаются вопросы, связанные с проведением тестирования на всех этапах конструирования программной системы. Классический процесс тестирования обеспечивает проверку результатов, полученных на каждом этапе разработки. Как правило, он начинается с тестирования в малом, когда проверяются программные модули, продолжается при проверке объединения модулей в систему и завершается тестированием в большом, при котором проверяются соответствие программного продукта требованиям заказчика и его взаимодействие с другими компонентами компьютерной системы. Данная глава последовательно описывает содержание каждого шага тестирования. Здесь же рассматривается организация отладки ПО, которая проводится для устранения выявленных при тестировании ошибок.

Методика тестирования программных систем

Процесс тестирования объединяет различные способы тестирования в спланированную последовательность шагов, которые приводят к успешному построению программной системы (ПС) [3], [13], [64], [69]. Методика тестирования ПС может быть представлена в виде разворачивающейся спирали (рис. 8.1).

В начале осуществляется тестирование элементов (модулей), проверяющее результаты этапа кодирования ПС. На втором шаге выполняется тестирование интеграции, ориентированное на выявление ошибок этапа проектирования ПС. На третьем обороте спирали производится тестирование правильности, проверяющее корректность этапа анализа требований к ПС. На заключительном витке спирали проводится системное тестирование, выявляющее дефекты этапа системного анализа ПС.

Охарактеризуем каждый шаг процесса тестирования.

1. Тестирование элементов. Цель — индивидуальная проверка каждого модуля. Используются способы тестирования «белого ящика».

Рис. 8.1. Спираль процесса тестирования ПС

2. Тестирование интеграции. Цель — тестирование сборки модулей в программную систему. В основном применяют способы тестирования «черного ящика».

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

4. Системное тестирование. Цель — проверка правильности объединения и взаимодействия всех элементов компьютерной системы, реализации всех системных функций.

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

Ответ практика обычно основан на статистическом критерии: «Можно с 95%-ной уверенностью сказать, что провели достаточное тестирование, если вероятность безотказной работы ЦП с программным изделием в течение 1000 часов составляет по меньшей мере 0,995».

Научный подход при ответе на этот вопрос состоит в применении математической модели отказов. Например, для логарифмической модели Пуассона формула расчета текущей интенсивности отказов имеет вид:

, (8.1)

где — текущая интенсивность программных отказов (количество отказов в единицу времени); — начальная интенсивность отказов (в начале тестирования); р — экспоненциальное уменьшение интенсивности отказов за счет обнаруживаемых и устраняемых ошибок; t —время тестирования.

С помощью уравнения (8.1) можно предсказать снижение ошибок в ходе тестирования, а также время, требующееся для достижения допустимо низкой интенсивности отказов.

Тестирование элементов

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

Тестированию подвергаются:

q интерфейс модуля;

q внутренние структуры данных;

q независимые пути;

q пути обработки ошибок;

q граничные условия.

Интерфейс модуля тестируется для проверки правильности ввода-вывода тестовой информации. Если нет уверенности в правильном вводе-выводе данных, нет смысла проводить другие тесты.

Исследование внутренних структур данных гарантирует целостность сохраняемых данных.

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

Наиболее общими ошибками вычислений являются:

1) неправильный или непонятый приоритет арифметических операций;

2) смешанная форма операций;

3) некорректная инициализация;

4) несогласованность в представлении точности;

5) некорректное символическое представление выражений.

Источниками ошибок сравнения и неправильных потоков управления являются:

1) сравнение различных типов данных;

2) некорректные логические операции и приоритетность;

3) ожидание эквивалентности в условиях, когда ошибки точности делают эквивалентность невозможной;

4) некорректное сравнение переменных;

5) неправильное прекращение цикла;

6) отказ в выходе при отклонении итерации;

7) неправильное изменение переменных цикла.

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

1) донесение об ошибке невразумительно;

2) текст донесения не соответствует, обнаруженной ошибке;

3) вмешательство системных средств регистрации аварии произошло до обработки ошибки в модуле;

4) обработка исключительного условия некорректна;

5) описание ошибки не позволяет определить ее причину.

И, наконец, перейдем к граничному тестированию. Модули часто отказывают на «границах». Это означает, что ошибки часто происходят:

1) при обработке n-го элемента n-элементного массива;

2) при выполнении m-й итерации цикла с т проходами;

3) при появлении минимального (максимального) значения.

Тестовые варианты, ориентированные на данные ситуации, имеют высокую вероятность обнаружения ошибок.

Тестирование элементов обычно рассматривается как дополнение к этапу кодирования. Оно начинается после разработки текста модуля. Так как модуль не является автономной системой, то для реализации тестирования требуются дополнительные средства, представленные на рис. 8.2.

Рис. 8.2.Программная среда для тестирования модуля

Дополнительными средствами являются драйвер тестирования и заглушки. Драйвер — управляющая программа, которая принимает исходные данные (InData) и ожидаемые результаты (ExpRes) тестовых вариантов, запускает в работу тестируемый модуль, получает из модуля реальные результаты (OutData) и формирует донесения о тестировании. Алгоритм работы тестового драйвера приведен на рис. 8.3.

Рис. 8.3.Алгоритм работы драйвера тестирования

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

Создание драйвера и заглушек подразумевает дополнительные затраты, так как они не поставляются с конечным программным продуктом.

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

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

Тестирование интеграции

Тестирование интеграции поддерживает сборку цельной программной системы.

Цель сборки и тестирования интеграции: взять модули, протестированные как элементы, и построить программную структуру, требуемую проектом [3].

Тесты проводятся для обнаружения ошибок интерфейса. Перечислим некоторые категории ошибок интерфейса:

q потеря данных при прохождении через интерфейс;

q отсутствие в модуле необходимой ссылки;

q неблагоприятное влияние одного модуля на другой;

q подфункции при объединении не образуют требуемую главную функцию;

q отдельные (допустимые) неточности при интеграции выходят за допустимый уровень;

q проблемы при работе с глобальными структурами данных.

Существует два варианта тестирования, поддерживающих процесс интеграции: нисходящее тестирование и восходящее тестирование. Рассмотрим каждый из них.

Воспользуйтесь поиском по сайту:

Говорят, что попытка запуска одного из первых искусственных спутников Земли закончилась неудачей, так как в одной из программ была неверно поставлена десятичная точка. Ошибки программирования редко приводят к столь серьезным последствиям, однако известно, что отыскание ошибок в логике программ стоит огромного количества времени и сил. Средства, затрачиваемые на это, исчисляются миллионами долларов. Ошибки же в программах операционной системы приводят к значительным простоям дорогостоящего оборудования. Телефонная компания, использующая автоматизированную систему расчетов, может выплатить абоненту 7000 долларов, вместо того чтобы получить с него 7. А кому не приходилось встречаться с определенными недоразумениями, связанными с использованием ЭВМ для расчетов с помощью кредитных карточек?

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

Модульное программирование

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

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

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

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

Рис. 12.6. Блок-схема программы учета запасов.

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

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

Центральная часть блок-схемы представляет собой управляющую

программу, функции которой состоят в осуществлении контроля за порядком выполнения подпрограмм и задании им исходных данных. Таким образом, задача основной управляющей программы состоит в интерпретации входных команд и реакции на них посредством запросов на выполнение соответствующих подпрограмм, вызовов подпрограмм (подробнее о подпрограммах см. в гл. 13).

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

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

2. Считывание карты модулем ввода.

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

4. Проверка управляющей программой введенной управляющей информации, определение требуемой операции и вызов подпрограммы работы с дисками.

5. Считывание информации с диска модулем ввода подпрограммы работы с дисками.

6. Вызов подпрограммы корректировки.

7. Работа модуля изменения общего количества подпрограммы обработки записей.

8. Вызов управляющей программой подпрограммы обмена с дисками.

9. Возврат модифицированной информации на соответствующее место дисковой памяти модулем записи на диск новых данных вызванной подпрограммы.

10. Вызов подпрограммы печати, производящей преобразование формы представления данных и вывод этих данных на печать.

Заметим, что в рассмотренном примере каждый модуль выполняет свою специфическую функцию. Если бы программа учета была составлена как единое целое, т. е. без подразделения на модули и подпрограммы, то задача ее отладки стала бы значительно более сложной, если не невыполнимой. После устранения ошибок, обнаруженных ЭВМ или операционной системой, программа может получить некоторые результаты, но ведь они могут быть и неверны:

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

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

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

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

Тестирование и отладка модулей

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

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

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

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

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

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

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

В программах вычислительного типа ошибочные случаи должны быть рассмотрены с такой же тщательностью, как и нормальные. Возьмем в качестве примера программу обращения матриц. Предположим, что мы обратили вручную матрицу размером 3 на 3, затем использовали для обращения написанную программу и получили тот же результат. Вам следует четко представлять, что это только начало тестирования. К сожалению, некоторые программисты, успешно пройдя лишь этот первый этап, полагают, что составленные ими модули работают должным образом. Тем не менее, осталось еще несколько невыясненных вопросов. Мы вообще привыкли мыслить категориями трехмерного пространства, поэтому вполне вероятно предположить, что создаваемые нами программы гораздо лучше подходят для работы именно в трехмерных случаях. Итак, следует проверить правильность работы программы и тогда, когда размерность матрицы больше чем 3, и тогда, когда она меньше. Программа должна охватывать и такие специальные случаи, как обращение матриц размерностью 0x0, 1×1, 2×2. Также правильно должно выполняться обращение матриц с высокой размерностью.

Что можно сказать о вырожденных (необратимых) матрицах? Модуль должен производить проверку условия вырожденности и в случае его выполнения посылать соответствующее сообщение вызывающей программе и возвращать ей управление вместо попыток деления на 0, неизбежно производящихся при отсутствии подобных проверок. Одним из тестов должно служить задание матриц, близких к вырожденным (при обращении таких матриц обычно получаются значительные ошибки). Информация о прохождении программой всех тестов, ограничениях на размерность обращаемых матриц и величине ошибок, возникающих вследствие округлений, должна быть внесена в документацию, прилагаемую к модулю.

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

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

ABEND n, DUMP

Дамп, выдаваемый по команде ABEND, ничем не отличается JOT уже рассматривавшихся нами дампов. Параметр n представляет собой пользовательский код завершения, который появляется в распечатке вместе с дампом.

Макрокоманда ABEND вызывает прекращение выполнения программы и поэтому делает невозможным продолжение отладки модуля в пределах того же задания. Во многих конкретных вычислительных системах существуют средства, позволяющие распечатывать содержимое памяти и регистров по требованию, не вызывая прекращения выполнения основной программы. Вы можете пользоваться также своими собственными отладочными макро. Существует, кроме того, процедура PDUMP, входящая в набор стандартных процедур языка ФОРТРАН. Используя PDUMP, можно распечатать содержимое указанных областей памяти в одном из нескольких форматов. Вызывается эта процедура обычными командами вызова подпрограмм. Более подробно эти вопросы освещены в руководстве «Библиотека OS ФОРТРАН IV. Вычислительные и обслуживающие подпрограммы» (GC28—6818).

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

Сборка программы

После того как модули окончательно проверены и отлажены, встает вопрос о компоновке из этих модулей программного пакета.

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

Каждая подпрограмма должна быть отлажена точно таким же образом, что и входящие в нее модули. Это обычно требует разработки генераторов входных данных и программ вывода. Снова необходимо проверить правильность работы каждой подпрограммы и обеспечить диагностику возможных ошибок.

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

На рис. 12.7 приведена блок-схема управляющей программы системы, изображенной на рис. 12.6. Отметим, что весь ввод-вывод, вычисления и проверка на наличие ошибок производятся внутри подпрограмм; основная программа лишь определяет последовательность их выполнения.

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

Совершенствование и поддержка

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

Рис. 12.7. Блок-схема управляющей программы системы учета запасов.

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

Модульное тестирование является одним из основных видов тестирования программного обеспечения. Как и в случае с тестированием программного обеспечения, модульное тестирование не может гарантировать отсутствие ошибок после развертывания приложения. Однако, тестируя наименьшие повторяющиеся фрагменты кода в ваших приложениях, модульное тестирование помогает выявлять ошибки в строительных блоках вашего проекта до того, как они повлияют на ваше интегрированное приложение.

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

Сегодня мы рассмотрим обзор модульного тестирования и лучших практик модульного тестирования.

Обзор модульного тестирования

Что такое модульное тестирование?

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

Модуль — это наименьший фрагмент кода в вашей программе, который повторяем, тестируем и функционален. Единицами могут быть функции, классы, методы и так далее.

Уровни тестирования программного обеспечения

На предыдущем рисунке показано модульное тестирование наряду с другими уровнями тестирования программного обеспечения, где каждый уровень имеет свою область применения:

• Модульное тестирование проверяет каждый программный модуль.
• Интеграционное тестирование проверяет объединенные модули в соответствии с проектной документацией системы и функциональными требованиями.
• Функциональное тестирование проверяет желаемую функциональность программы на основе документов анализа требований и руководства пользователя (т. е. обеспечение ожидаемого результата для заданных входных данных). Это иногда делится на системное тестирование и приемочное тестирование.

Тестирование «черного ящика» и «белого ящика» — это два подхода к тестированию программного обеспечения, в которых:

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

Для модульного тестирования наиболее подходящим вариантом обычно является тестирование белого ящика, особенно когда наши модули меньше и их код легче понять. С другой стороны, тестирование «черного ящика» — хороший вариант для более поздних стадий проекта, когда модули были интегрированы для создания сложного программного обеспечения.

Преимущества модульного тестирования

Некоторые преимущества модульного тестирования включают в себя:

• Упрощает отладку : тестируя функциональность небольших модулей, вы можете обнаруживать ошибки до того, как они повлияют на другие модули в интегрированном приложении.
• Поощряет более слабосвязанный код : намеренно уменьшая взаимозависимости между модулями, мы получаем более слабосвязанный код, что является передовой практикой кодирования.
• Быстрее, чем функциональное тестирование : поскольку модули очень маленькие, вы можете запустить несколько модульных тестов за секунды (при условии, что вы их автоматизировали).
• Минимизация регрессии кода : после рефакторинга или расширения кода вы можете повторно запустить все наборы тестов, чтобы убедиться, что ваш новый или обновленный код не нарушает существующие функции.
• Лучшее покрытие кода. Разбивая приложение на мельчайшие тестируемые компоненты, модульное тестирование помогает увеличить покрытие кода.

Тестовое покрытие

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

Тестовое покрытие можно дополнительно классифицировать следующим образом:

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

Среды модульного тестирования

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

Существуют десятки фреймворков для модульного тестирования, доступных для различных языков программирования. Некоторые популярные среды модульного тестирования включают Cunit, Moq, Cucumber, Selenium, Embunit, Sass True, HtmlUnit и JUnit (одна из наиболее широко используемых сред с открытым исходным кодом для языка программирования Java).

Мы можем сэкономить много времени и ресурсов с помощью фреймворков модульного тестирования, которые включают следующие функции:

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

9 лучших практик модульного тестирования

1. Напишите тесты для ряда сценариев

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

2. Напишите хорошие названия тестов

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

3. Настройте автоматические тесты

Выберите автоматизированное модульное тестирование с помощью среды модульного тестирования. Еще лучше автоматизировать тесты в конвейере непрерывной интеграции (CI/CD).

Альтернативой автоматизированному тестированию является ручное тестирование, при котором мы вручную выполняем тестовые случаи и собираем их результаты. Как вы понимаете, ручное тестирование небольших модулей невероятно утомительно. Он также менее надежен. Автоматические тесты, безусловно, помогут вам в этом.

4. Пишите детерминированные тесты

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

5. Организовать, действовать и утверждать (ААА)

Протокол AAA является рекомендуемым подходом для структурирования модульных тестов. В качестве передовой практики модульного тестирования это улучшает читабельность вашего теста, придавая ему логическую последовательность. ААА иногда называют протоколом «Дано/Когда/Тогда».

Вы можете использовать протокол AAA для структурирования модульных тестов, выполнив следующие шаги:

• Упорядочить: Упорядочить настройку и инициализацию для теста.
• Act: Действуйте на единицу для данного теста.
• Утвердить: Утвердить или проверить результат

Следующий код демонстрирует структуру AAA при тестировании функции абсолютного значения в Python:

def test_abs_for_a_negative_number():
 
  # Arrange
  negative = -2
   
  # Act
  answer = abs(negative)
   
  # Assert
  assert answer == 2

6. Пишите тесты до или во время разработки

В идеальном мире мы пишем тестовый код перед написанием рабочего кода. Это известно как разработка через тестирование (TDD) — процесс разработки программного обеспечения, посредством которого мы параллельно улучшаем наши тестовые примеры и программный код. TDD помогает увеличить покрытие кода модульными тестами.

Процесс TDD выглядит следующим образом:

• Разработка модульных тестов для подмножества большого проекта
• Быстрое написание кода вышеупомянутого подмножества
• В случае каких-либо ошибок, рефакторинг вашего кода. В противном случае повторите цикл TDD.
• Продолжайте, пока весь ваш проект не будет завершен без явных ошибок.

Следующий рисунок иллюстрирует этот процесс:

Цикл разработки через тестирование

7. Один вариант использования на модульный тест

Каждый тест должен фокусироваться на одном варианте использования и проверять, что результат соответствует ожидаемому для этого тестируемого метода. Сосредоточив внимание на одном варианте использования, вы получите более четкое представление о корне проблемы в случае, если тест не пройден (в отличие от тестирования нескольких вариантов использования).

8. Избегайте логики в тестах

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

9. Сокращение тестовых зависимостей

Тесты не должны зависеть друг от друга. Уменьшая зависимости между модулями, исполнители тестов могут одновременно запускать тесты для разных фрагментов кода. Модуль может считаться пригодным для тестирования только в том случае, если его зависимости размещены (т. е. заглушки) в тестовом коде. Никакие реальные или внешние зависимости не должны влиять на результат теста.

10. Стремитесь к максимальному охвату тестами

Хотя мы можем стремиться к 100% охвату тестами, это может быть не всегда желательно или возможно. Такое всестороннее тестирование может иметь финансовые и временные требования, превышающие наши возможности. В некоторых случаях такое комплексное тестирование теоретически невозможно (т.е. неразрешимо). При этом мы должны стремиться к максимально возможному охвату с учетом наших ограничений.

11. Храните надлежащую тестовую документацию

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

Тестовая документация должна соответствовать следующим критериям:

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