Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
kernigan_paik.doc
Скачиваний:
0
Добавлен:
01.07.2025
Размер:
2.91 Mб
Скачать

6.6. Полезные советы

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

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

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

Напишите версию выделения памяти, которая специально даст сбой в скором времени — и вы протестируете код, восстанавливающий систему после ошибок нехватки памяти. Вот, например, версия, которая после 10 вызовов возвращает NULL:

/* testmalloc: через 10 вызовов возвращает NULL */

void *testmalloc(size_t n)

{

static int count = 0;

if (++count > 10)

return NULL;

else

return malloc(n);

}

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

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

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

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

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

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

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

Тесты быстродействия мы обсудим в главе 7.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]