Семь шагов переноса программы в 64-битную систему - Обновление процесса тестирования

7. Обновление процесса тестирования

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

Если ваша 64-битная программа обрабатывает более крупные объемы данных, чем 32-битная версия, вы должны расширить тесты, чтобы включить в них обработку данных объемом более 4 Гб. Это граница, за которой начинают проявляться многие 64-битные ошибки. Такие тесты могут занять гораздо больше времени, и вы должны быть готовы к этому. Обычно тесты пишутся так, чтобы каждый тест мог обрабатывать малое число элементов и тем самым позволять выполнять все внутренние тесты модулей за несколько минут, а автоматические тесты (например, с помощью AutomatedQA TestComplete) – за несколько часов. Почти несомненно, что функция сортировки, сортирующая 100 элементов, будет вести себя правильно на 100000 элементах в 32-битной системе. Но эта же функция может сбоить в 64-битной системе при попытке обработать 5 миллиардов элементов. Скорость выполнения теста модулей может упасть в миллион раз. Не забывайте о стоимости переделки тестов при овладении 64-битными системами. Удачным решением является разделение тестов модулей на быстрые (работающие с малыми объемами памяти) и медленные, обрабатывающие гигабайты, и проводимые, например, ночью. Автоматизированное тестирование ресурсоемких 64-битных программ можно выстроить на основе распределенных вычислений.

Есть еще один неприятный факт. Вы едва ли преуспеете в использовании инструментов, таких как BoundsChecker, для поиска ошибок в ресурсоемких 64-битных программах, потребляющих большой объем памяти. Причина – сильное замедление тестируемых программ, что делает такой подход крайне неудобным. В режиме выявления всех ошибок, относящихся к работе памяти, инструмент Parallel Inspector, входящий в Intel Parallel Studio, в среднем замедляет выполнение приложения в 100 раз (рисунок 10). Скорее всего, тестируемый алгоритм, работающий 10 минут, придется оставлять на ночь. И все же Parallel Inspector является одним из самых полезных и удобных инструментов для поиска ошибок работы памяти. Надо быть готовым изменить приемы диагностики ошибок и учитывать их при планировании овладения 64-битными системами.

Рисунок 10. Окно настроек программы Parallel Inspector перед запуском приложения.

И последнее. Не забудьте добавить тесты, проверяющие совместимость форматов данных между 32-битной и 64-битной версиями. Совместимость данных часто нарушается при переносе по причине записи в файлы таких типов, как size_t или long (в системах Linux).