Тестирование белого и черного ящика.

При тестировании белого ящика (англ. white-box testing, также говорят — прозрачного ящика), разработчик теста имеет доступ к исходному коду и может писать код, который связан с библиотеками тестируемого ПО. Это типично для юнит-тестирования (англ. unit testing), при котором тестируются только отдельные части системы. Оно обеспечивает то, что компоненты конструкции — работоспособны и устойчивы, до определенной степени.

При тестировании чёрного ящика (англ. black-box testing), тестировщик имеет доступ к ПО только через те же интерфейсы, что и заказчик или пользователь, либо через внешние интерфейсы, позволяющие другому компьютеру либо другому процессу подключиться к системе для тестирования. Например, тестирующий модуль может виртуально нажимать клавиши или кнопки мыши в тестируемой программе с помощью механизма взаимодействия процессов, с уверенностью в том, что эти события вызывают тот же отклик, что и реальные нажатия клавиш и кнопок мыши.

Любое ПО разрабатывается для работы в каких-то определенных программных (а иногда и аппаратных) конфигурациях (окружениях). Обычно набор этих конфигураций определяется сразу при установке рамок проекта и записывается в нефункциональные требования. А раз есть требование, то оно должно быть протестировано. Если какая-то функция работает под одной конфигурацией, то не факт что в разных окружениях все будет работать одинаково и правильно. А раз так, то значит что надо выполнить ВСЕ тесты для КАЖДОЙ конфигурации, чтобы быть стопроцентно уверенным в точном выполнении требований. Количество конфигурационных тестов равно произведению числа поддерживаемых конфигураций каждого типа. Так, для приведенного примера, если ПО имеет некоторые две кастомизированные версии, которые должны работать под операционными системами WinXP и Win2K и поддерживать браузеры IE и NN, то количество конфигурационных тестовых сценариев будет равно четырём.

Также можно выделить другие виды тестирования:

1. Разрушительные (краш) тесты.

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

2. Тестирование совместимости с другими модулями и системами.

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

3. Нагрузочное тестирование.

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

Таким образом тестирование ПО в некоторой степени подобно испытаниям ЭВС.

Тестирование ЭВС	Тестирование ПО
Испытание на внешние воздействия	Конфигурационное тестирование Совместимость с другими модулями и системами
По условиям технологии и организации проведения испытаний для ЭВС можно проводить испытания с искуственным и естественным заданием внешних факторов, можно использовать как физические так и математические модели	В тестирование программного обеспечения мы всегда проводим тестирование с естественным заданием внешних факторов и с испытанием физической модели
По организационному уровню проведения если испытания ЭВС проводятся на государственном, межведомственном и ведомственном уровне	В тестирование ПО мы проверяем соответствие только международным стандартам

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