Программист-прагматик

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

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

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

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

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

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

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

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

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

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

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

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

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

Подсказка 64: Используйте диверсантов для тестирования самих тестов

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

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

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

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

Ответ здесь краток: «никак», вы никогда это не узнаете. Но на программном рынке есть продукты, которые могут вам помочь. Эти средства анализа степени покрытия отслеживают программу при тестировании и регистрируют, какие строки были выполнены, а какие нет. Эти средства дают общее представление о том, насколько исчерпывающей является процедура тестирования, но не стоит ожидать, что степень покрытия составит 100 %.