Программист-прагматик. Путь от подмастерья к мастеру
Шрифт:
Кроме того, осознание, что вы прошли тест, дает вам большую степень уверенности в том, что этот фрагмент программы "готов".
Подсказка 63: Программа не считается написанной, пока не пройдет тестирование
Тот факт, что вы закончили работу с фрагментом программы, вовсе не означает, что можно идти к шефу или заказчику, чтобы сообщить ему о «готовности». Фрагмент не готов. Прежде всего, программа в реальности никогда не бывает готовой. И, что более важно, пока она не пройдет все имеющиеся тесты, вы не можете утверждать,
Необходимо рассмотреть три основных аспекта тестирования в масштабе всего проекта: что тестировать, как тестировать и когда тестировать.
Что тестировать
Существует несколько видов процедур тестирования программного обеспечения, которые вам приходится выполнять:
• Модульное тестирование
• Комплексное тестирование
• Подтверждение правильности и верификация
• Тестирование в условиях нехватки ресурсов, ошибки и их исправление
• Тестирование производительности
• Тестирование удобства использования
Этот перечень ни в коей мере не является полным, и в некоторых специализированных проектах потребуются другие виды процедур тестирования. Но это дает нам хорошую отправную точку.
Модульный тест представляет собой программу, занимающуюся тестированием некоего модуля. Эта тема освещена в разделе "Программа, которую легко тестировать". Модульное тестирование является основой для всех других видов тестирования, которые обсуждаются в данном разделе. Если части не работают по отдельности, то скорее всего они не будут хорошо работать и вместе. Все используемые модули обязаны пройти собственное модульное тестирование перед тем как продолжать работу.
Как только все соответствующие модули прошли индивидуальное тестирование, вы готовы к новому этапу. Вам придется проверить, как модули используют друг друга и взаимодействуют между собой по всей системе.
Комплексное тестирование показывает, что основные подсистемы, из которых состоит проект, работают и нормально взаимодействуют друг с другом. При наличии удачных и хорошо проверенных контрактов обнаружить любые проблемы интеграции не составляет особого труда. В противном случае интеграция становится благодатной почвой для размножения дефектов. Фактически в многих случаях она является единственным и самым крупным источником дефектов в системе.
В реальности комплексное тестирование является продолжением модульного тестирования, описанного выше, с той лишь разницей, что теперь вы проверяете, как целые подсистемы соблюдают свои контракты.
Как только в вашем распоряжении появляется рабочий пользовательский интерфейс или прототип, вам приходится отвечать на существенный вопрос: пользователи сказали вам, что они хотели бы увидеть, но то ли это на самом деле?
Отвечает ли продукт функциональным требованиям системы? Это также нуждается в тестировании. Бездефектная система, которая отвечает на неправильные вопросы, не приносит пользы. Необходимо осознавать схемы доступа конечного пользователя и их отличие от тестовых данных разработчика (в качестве примера обратите внимание на историю о рисовании кистью из раздела "Отладка")
Теперь вы понимаете, что система будет вести себя корректно в идеальных условиях, вам придется испытать, как она ведет себя в реальных условиях. В реальном мире ресурсы ваших программ не безграничны – они исчерпываются. Ваша программа может столкнуться со следующими ограничениями:
• Объем памяти
• Объем дискового пространства
• Мощность процессора
• Тактовая частота
• Скорость дискового обмена
• Пропускная способность сети
• Цветовая палитра
• Разрешающая способность экрана
Вы можете реально проверить нехватку дискового пространства или объема памяти, но как часто вы проверяете другие ограничения? Будет ли ваше приложение работать на экране с разрешением 640*480 и 256 цветами? Может ли оно выполняться на экране с разрешением 1600*1280 с 24-битным цветом и при этом не быть размером с почтовую марку? Завершится ли пакетное задание до момента запуска программы архивации?
Вы можете обнаружить наличие ограничений в операционной среде, таких как спецификация видеоподсистемы, и приспособиться к ним соответствующим образом. Однако не все сбои можно восстановить. Если программа обнаруживает нехватку памяти, то вы ограничены в своих действиях: вам не хватит ресурсов, чтобы завершить программу способом, отличным от аварийного завершения.
Когда система выходит из строя [50] , будет ли это делаться изящно? Постарается ли она сделать лучшее, на что она способна в данной ситуации, – сохранить свое состояние и предотвратить потерю данных? Или она выдаст пользователю сообщения типа "Общая ошибка защиты" или "core dump" (отключение ядра системы)?
50
Редактор американского издания требовал изменить это предложение на "Если система выходит из строя… ". Авторы сопротивлялись.
Тестирование производительности, нагрузочное тестирование или тестирование в реальных условиях эксплуатации может также оказаться важным аспектом проекта.
Задайте себе вопрос, отвечает ли программа требованиям производительности в условиях реального мира – с ожидаемым числом пользователей, подключений или транзакций в единицу времени. Является ли она масштабируемой?
При работе с некоторыми приложениями вам могут понадобиться специализированные тестовая аппаратура или программное обеспечение для реалистичной имитации нагрузок.
Тестирование удобства использования отличается от процедур тестирования, обсужденных выше. Оно осуществляется с реальными пользователями в реальных условиях окружающей среды.
Рассмотрим удобство использования с точки зрения человеческого фактора. Имелись ли какие-либо недоразумения в ходе анализа требований, на которые необходимо обратить внимание? Подходит ли программное обеспечение пользователю, становясь продолжением его рук? (Мы хотим, чтобы не только наши собственные инструменты были изготовлены по руке, но чтобы и те, которые мы создаем для пользователей, подходили им.)