Интеграционное тестирование - поиск ваших знаний, советов и ссылок! - PullRequest
3 голосов
/ 01 марта 2010

Привет, ребята, я после нескольких советов и указаний по тестированию интеграции для веб-приложения. Наш проект работает уже несколько лет, и он достаточно сложный. Мы довольно хорошо покрыты модульными тестами, но нам не хватает приличного набора интеграционных тестов. У нас нет документированных вариантов использования или даже разумного набора тестовых примеров за пределами наших модульных тестов. «Интеграционное тестирование» сегодня состоит из знания разработчика о возможном влиянии изменений и ручного специального тестирования приложения. Это действительно не идеально - сейчас мы хотим спроектировать и автоматизировать солидный набор тестов, чтобы позволить нам проводить регрессионное тестирование и повысить нашу уверенность в качестве приложения.

Мы наконец-то создали платформу (на основе Selenium), которая позволит нам быстро создавать и автоматизировать выполнение тестов. Проблема сейчас: у нас нет никаких тестов, страница хорошо и действительно пуста. Система имеет около 30 классов, которые взаимодействуют друг с другом и влияют на пользовательский интерфейс. Для регистрации нового пользователя доступно около 40 свойств, каждое из которых влияет на опыт. За время жизни пользователя они будут генерировать еще больше состояний. Учитывая так много переменных и возможных состояний, это пугающая перспектива, чтобы начать, и, вероятно, поэтому до сих пор им пренебрегали.

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

Помощь!

1 Ответ

4 голосов
/ 01 марта 2010

Если это огромное количество комбинаций, которые удерживают вас в попытке создать тестовые сценарии, вам обязательно стоит взглянуть на all-pair testing .

Мы использовали PICT от Microsoft в качестве инструмента, позволяющего успешно минимизировать количество тестовых случаев, при этом все еще будучи достаточно уверенным, чтобы охватить большинство случаев.

обоснование тестирования всех пар это: самые простые ошибки в Программа, как правило, запускается один входной параметр. Следующий Простейшая категория ошибок состоит из те, кто зависит от взаимодействия между парами параметров, которые могут быть пойманным с тестированием всех пар. 1 Ошибки, связанные с взаимодействием между три или более параметров прогрессивно реже 2 , в то время как в то же время постепенно более дорогой, чтобы найти исчерпывающим тестирование, которое имеет как предел исчерпывающее тестирование всего возможного входы.

...