Методы тестирования

Каков наиболее часто используемый подход, используемый для тестирования в Java-проектах (итеративная разработка)?

7 ответов

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

АВТОМАТИЗИРОВАННОЕ ИСПЫТАНИЕ

  • Тестирование устройств Используйте NUnit для проверки своих классов, функций и взаимодействия между ними. http://www.nunit.org/index.php

  • Автоматическое функциональное тестирование Если это возможно, вы должны автоматизировать много функционального тестирования. Некоторые рамочные работы имеют функциональное тестирование, встроенное в них. В противном случае вы должны использовать для этого инструмент. Если вы разрабатываете веб-сайты/приложения, вы можете посмотреть на Selenium. http://www.peterkrantz.com/2005/selenium-for-aspnet/

  • Непрерывная интеграция Используйте CI, чтобы убедиться, что все ваши автоматические тесты выполняются каждый раз, когда кто-то из вашей команды делает фиксацию проекта. http://martinfowler.com/articles/continuousIntegration.html

РУЧНАЯ ТЕСТИРОВАНИЕ Насколько мне нравится автоматическое тестирование, IMHO, а не замена ручного тестирования. Основная причина заключается в том, что автоматизированный способ может выполнять только то, что ему говорят, и проверять только то, что было проинформировано, для просмотра в качестве pass/fail. Человек может использовать его для обнаружения недостатков и постановки вопросов, возникающих при тестировании чего-то другого.

  • Исследовательское тестирование ET - очень дешевый и эффективный способ найти недостатки в проекте. Он использует преимущества интеллекта человека и учит тестировщиков/разработчиков больше о проекте, чем любой другой метод тестирования, о котором я знаю. Выполнение ET-сессии, предназначенной для каждой функции, развернутой в тестовой среде, - это не только эффективный способ быстро найти проблемы, но и хороший способ научиться и весело! http://www.satisfice.com/articles/et-article.pdf


Личный опыт предполагает, что наиболее популярным подходом является отсутствие вообще.


Я раньше работал с TDD (Test Driven Development), и мои чувства к нему неоднозначны. По сути, вы пишете свои тесты, прежде чем писать свой код, и напишите свой код, чтобы удовлетворить требованиям теста. TDD заставляет вас иметь четкое представление о ваших требованиях перед запуском. Дополнительным преимуществом является то, что, как только вы закончите разработку, предполагая, что внимательно следите за процедурами TDD, у вас будет полный набор тестовых наборов для работы с кодом. Нижняя сторона заключается в том, что она занимает очень много времени, и иногда вам просто нужно пропустить пару шагов (например, возможно, писать код перед тем, как тесты предпочитают нормальный человек).

Подробнее можно прочитать здесь (ссылка wiki)


В порядке наиболее часто используемого подхода:

  • никаких тестов вообще
  • ручные тесты: запуск приложения, щелчок или предоставление ввода, проверка Результаты
  • попробуйте написать некоторые JUnits, забудьте о них, сдвиньте до 2 и 1
  • Начните с TDD, убедитесь, что это сложно затем сдвиньте на 3, 2 и 1

на теоретической стороне есть множество способов правильно протестировать код. Если вы ищете что-то практическое, взгляните на Чистая кодовая беседа. Взгляните на всю серию, около 5 разговоров (не можете разместить более одной ссылки).


В предпосылке проведения тестирования я бы сказал, что тестирование с помощью JUnit - это общий подход к тестированию на Java.

Хотя большинство тестов написано с использованием JUnit, в большинстве тестов обычно больше тестов интеграции, чем модульных тестов. (что означает не тестирование одной вещи в изоляции, а некоторые вещи вместе)

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

Если вы перейдете к команде, которая делает более продвинутое использование тестирования, возможно, вы обнаружите, что CI Server (Cruise Control, Hudson) запускает тесты не реже одного раза в день во время ночной сборки.


Тестирование модулей?

Контрактное программирование, a la Eiffel?

Модель водопада?

Различные магазины делают разные вещи. Если бы был один метод, чтобы управлять ими всеми, вы бы не задавали этот вопрос.


Мое предложение по тестированию проекта java - это упростить его.

Шаги: - Ручное тестирование: -Учитывайте стабильный продукт. Тестирование автоматизации: - Поддерживайте качество продукта. Создание отчетов и отчетность: - Сообщите людям о качестве продукта. Непрерывная интеграция: - Создайте полный автоматизированный непрерывный инструмент.

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

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

Наконец, когда продукт становится стабильным, тогда начните автоматизацию модулей. Вы также можете следить за автоматизацией шаг за шагом, как: - 1. Автоматизация модулей. 2. Создайте отчет и отправьте почту для продукта HealthCheck. 3. Непрерывное тестирование интеграции и автоматизации на частном сервере на локальной машине.

licensed under cc by-sa 3.0 with attribution.