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

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

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

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

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


integration-testing testing test-plan process testimonials
person Danmaxis    schedule 30.12.2008    source источник
comment
Господи, как бы я хотел ответить на это :)   -  person annakata    schedule 30.12.2008
comment
Хе-хе, действительно. Наша самая большая проблема с интеграционным тестированием — его полное отсутствие.   -  person blank    schedule 30.12.2008

Ответы (2)


arrow_upward
1
arrow_downward

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

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

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

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

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

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

person John Nilsson    schedule 30.12.2008

arrow_upward
1
arrow_downward

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

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

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

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

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

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

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

person MatthewMartin    schedule 30.12.2008