Тестирование сверху внизначать с верхнего или начального модуля программы。После начала теста,Не существует единственного правильного способа выбора последующих модулей для постепенного тестирования.,Единственный принцип — стать квалифицированным следующим модулем.,Хотя бы один зависимый модуль этого модуля,Модуль, вызывающий его, был предварительно протестирован.

в большинстве случаев,Стратегия «снизу вверх» является противоположностью стратегии «сверху вниз».。Преимущества тестирования «сверху вниз» становятся недостатками тестирования «снизу вверх».,Недостатки тестирования «сверху вниз» становятся преимуществами тестирования «снизу вверх». Из-за этого,Наше введение в тестирование «снизу вверх» будет кратким.

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

Если бы подходы «сверху вниз» и «снизу вверх» были такими же разными, как инкрементное и неинкрементное тестирование, их было бы легко сравнивать, но, к сожалению, это не так.

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

Плюсы и минусы тестирования сверху вниз

преимущество:

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

2. После внедрения функций ввода-вывода будет проще отправлять тестовые примеры.

3. Ранние рамки программы могут быть продемонстрированы и стимулировать энтузиазм.

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

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

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

7. Симуляция проста: использование заглушек для замены неразработанных деталей интуитивно понятно и легко реализуемо.

недостаток:

1. Необходимо разработать модули-заглушки

2. Модуль-заглушка сложнее, чем кажется на первый взгляд.

3. До введения функции ввода-вывода в модуль-заглушку сложно внедрить тестовые примеры.

4. Создать тестовую среду может быть сложно или даже невозможно.

5. Наблюдение за результатами теста может быть затруднено

6. Непонимание того, что проектирование и тестирование могут пересекаться.

7. Это приведет к задержке завершения тестов конкретного модуля.

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

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

10. Проблемы с производительностью. Заглушки обычно не так эффективны, как реальные модули, поэтому при использовании заглушек сложно точно оценить производительность системы.

Преимущества и недостатки восходящего тестирования

преимущество:

1. Было бы очень выгодно, если бы основной недостаток возникал внизу программы

2. Тестовую среду относительно легко создать.

3. Легче наблюдать за результатами теста.

4. Раннее обнаружение ошибок: запуск тестирования с нижнего модуля позволяет заранее обнаружить и устранить проблемы в модулях низкого уровня.

5. Независимость: каждый модуль можно тестировать независимо, не дожидаясь завершения других частей.

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

7. Прогрессивное построение. Система строится шаг за шагом, что позволяет команде видеть прогресс и помогает поддерживать темп.

недостаток:

1. Необходимо разработать модуль драйвера.

2. Программа не образует единое целое, пока не будет добавлен последний модуль.

3. Отсутствие общей перспективы. На ранней стадии может оказаться невозможным проверить, является ли архитектурный проект всей системы разумным.

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

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

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