Как выполняются интеграционные тесты в вашей компании / работе / проекте?

Question

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

На самом деле я тестирую веб-приложения, и планы тестирования управляются с помощью Test Link. Об обнаруженных ошибках сообщают на Bugzilla. Я пытаюсь автоматизировать тесты с помощью Selenium RC, но мне нужно время, чтобы написать планы и написать код для выполнения на Selenium. А у меня нет времени, потому что я тестирую 3 или более приложений.

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

Было бы очень хорошо, если бы кто-нибудь предложил что-то, что улучшило бы процесс тестирования (например, тестирование большего количества людей и т. Д.). Но в основном я хотел бы услышать , как процесс тестирования работает в других местах .
Спасибо.

Answer 1

Я предполагаю, что вы имеете в виду интеграционное тестирование, как проверку того, работают ли части приложения вместе (например, заставить базу данных и веб-сайт работать вместе после того, как администратор базы данных и веб-разработчик, соответственно, заявят, что они сделали) ) И я буду использовать пример из моего текущего проекта

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

• Я также использую скрипт сборки для создания копии приложения для каждого варианта файла конфигурации

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

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

Ключ автоматизирует столько, сколько вы можете. Частое интеграционное тестирование обнаруживает проблемы ранее.

От регистрации до упаковки кода для развертывания у меня уходит 8 минут на автоматизированную работу и 1/2 часа ручного щелчка для проверки дыма.

Answer 2

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

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

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

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

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

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