Методики тестирования
Что обычно используемый подход используется для тестирования в проектах Java (итерационная разработка)?
6 ответов
Я предлагаю вам создать здоровое сочетание автоматического и ручного тестирования.
АВТОМАТИЧЕСКОЕ ТЕСТИРОВАНИЕ
Модульное тестирование
Используйте NUnit для тестирования ваших классов, функций и взаимодействия между ними.
http://www.nunit.org/index.phpАвтоматическое функциональное тестирование
Если возможно, вам следует автоматизировать большую часть функционального тестирования. В некоторые каркасные работы встроено функциональное тестирование. В противном случае вам придется использовать для этого инструмент. Если вы разрабатываете веб-сайты / приложения, возможно, вам стоит взглянуть на Selenium.
http://www.peterkrantz.com/2005/selenium-for-aspnet/Непрерывная интеграция
Используйте CI, чтобы убедиться, что все ваши автоматические тесты выполняются каждый раз, когда кто-то из вашей команды выполняет фиксацию проект.
http://martinfowler.com/articles/continuousIntegration.html
РУЧНОЕ ТЕСТИРОВАНИЕ
Как бы мне ни нравилось автоматическое тестирование, оно, ИМХО, не заменяет ручное тестирование. Основная причина в том, что автоматическое устройство может делать только то, что ему говорят, и проверять только то, что ему проинформировали, чтобы он считал пройденным / неудачным. Человек может использовать свой интеллект, чтобы находить ошибки и задавать вопросы, возникающие при тестировании чего-то еще.
- Исследовательское тестирование
ET - это очень дешевый и эффективный способ поиска дефектов в проекте. Он использует интеллект человека и учит тестировщиков / разработчиков больше о проекте, чем любой другой метод тестирования, который я знаю. Проведение сеанса ET для каждой функции, развернутой в тестовой среде, - это не только эффективный способ быстрого поиска проблем, но и хороший способ учиться и развлекаться!
http://www.satisfice.com/articles/et-article.pdf
Личный опыт подсказывает, что наиболее популярный подход - вообще никакой.
Модульное тестирование?
Контрактное программирование, а-ля Эйфель?
Модель водопада?
В разных магазинах разные вещи. Если бы существовал один способ управлять ими всеми, вы бы не задавали этот вопрос.
Раньше я работал с TDD (разработка через тестирование), и мои чувства к нему неоднозначны. По сути, вы пишете свои тесты до того, как писать свой код, и пишете свой код, чтобы удовлетворить требованиям теста. TDD заставляет вас иметь предельно ясное представление о ваших требованиях до начала работы. Дополнительным преимуществом является то, что после завершения разработки, если вы внимательно следите за процедурами TDD, у вас будет полный набор наборов тестов для работы с кодом. Обратной стороной является то, что это занимает очень много времени, и иногда вам просто нужно пропустить пару шагов (например, возможно, написать код перед тестами, которые разумный человек предпочел бы сделать).
Подробнее можно прочитать здесь (ссылка на вики)
По поводу того, стоит ли вообще заниматься тестированием, я бы сказал, что тестирование с помощью JUnit - это общепринятый подход к тестированию в Java.
Хотя большинство тестов написаны с помощью JUnit, в основном тесты имеют тенденцию быть больше интеграционными тестами, чем юнит-тестами. (то есть тестирование не одной вещи в отдельности, а нескольких вещей вместе)
Кроме того, тесты в основном пишутся не по принципу "сначала тест, потом тест", а параллельно или после реализации определенной функции.
Если вы попадете в команду, которая использует более продвинутое тестирование, вы, вероятно, найдете какой-нибудь CI-сервер (Cruise Control, Hudson), запускающий тесты по крайней мере раз в день во время ночной сборки.
В порядке наиболее часто используемых подходов:
- никаких тестов вообще
- ручные тесты: запуск приложения, щелкнув или введя данные, отметьте results
- попробуйте написать несколько JUnits, забудьте о них, сдвиньте к 2 и 1
- Начните с TDD, убедитесь, что это сложно затем перейдите к 3, 2 и 1
с теоретической стороны есть множество способов правильно протестировать код. Если вы ищете что-то практичное, обратите внимание на Обсуждение чистого кода . Взгляните на всю серию, около 5 докладов (больше одной ссылки разместить нельзя).