Эндрю Хант - Программист-прагматик. Путь от подмастерья к мастеру

Когда система выходит из строя [50] Редактор американского издания требовал изменить это предложение на «Если система выходит из строя… «. Авторы сопротивлялись. , будет ли это делаться изящно? Постарается ли она сделать лучшее, на что она способна в данной ситуации, – сохранить свое состояние и предотвратить потерю данных? Или она выдаст пользователю сообщения типа «Общая ошибка защиты» или «core dump» (отключение ядра системы)?

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

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

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

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

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

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

Несоответствие критериям удобства использования является дефектом такого же порядка, как деление на ноль.

Мы рассмотрели то, что подлежит тестированию. Теперь мы обратим внимание на то, как это делается, включая следующее:

• Регрессионное тестирование

• Тестовые данные

• Тестирование систем с графическим интерфейсом

• Тестирование самих тестов

• Исчерпывающее тестирование

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

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

• Показатель цикломатической сложности Маккейба (измеряет сложность структуры решений)

• Коэффициент разветвления по входу при наследовании (количество базовых классов) и по выходу (количество производных модулей; используется в качестве родителя)

• Набор откликов (см. раздел «Несвязанность и закон Деметера»)

• Отношения связывания класса (см. [URL 48])

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

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

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

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