Какова связь между требованиями и контрольными примерами? - PullRequest
3 голосов
/ 14 октября 2010

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

Ответы [ 6 ]

2 голосов
/ 15 октября 2010

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

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

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

Если контрольные примеры не являются требованиями и требуют больше, чем задокументированные требования (например, тестирование большего количества ошибок и т. Д.), То, конечно, набор требований является неполным?

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

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

Посмотритеat: http://www.ibm.com/developerworks/rational/library/04/r-3217/

В этой статье автор объясняет, как перейти от вариантов использования к тестам.Автор подчеркивает, что, хотя варианты использования содержат все потоки и подпотоки, контрольные примеры представляют собой конкретные данные и конкретный поток в системе.

Являются ли требования просто абстрактными контрольными примерами?

Я бы сказал, да, их можно посмотреть таким образом.Некоторые люди даже заходят так далеко, что не пишут тестовые примеры, а просто используют требования в качестве «контрольного списка», на котором основывается их тестирование.

Отслеживание от тестовых примеров до требований - очень хорошая идея, иочень популярный подход.Инструменты реализуют эту функцию, потому что она продается.Но у этого подхода есть ограничения и ловушки.Часто существует ложное ощущение полноты, когда инструмент сообщает о 100% покрытии, потому что у вас есть 1 тест на каждое требование.Это на самом деле не решает проблему, что некоторые требования требуют гораздо больше, чем просто один тест.Это также не влияет на содержание тестов или на то, действительно ли тесты охватывают то, что они должны.

Если вас интересуют Требования-> Отслеживаемость тестов, вы должны знать об ограничениях подхода иосознайте, что его следует использовать осторожно в сочетании с другими подходами, чтобы обеспечить более комплексный подход к вашему тестированию.

1 голос
/ 14 октября 2010

В моем случае,

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

Таким образом, вы можете отследить контрольные примеры до требований.

1 голос
/ 14 октября 2010

На самом деле это зависит от процесса разработки, который используется командой / организацией.

  • В Agile (Scrum, XP и вариациях) процессах обычно нет требований и приемочные тесты не используются.чтобы убедиться, что пользовательская история реализована правильно.Таким образом, User Story является своего рода требованием / спецификацией.

  • В тестовой управляемой разработке есть требования.

  • В Waterfall вы обычно создаетедокумент, в котором перечислены все требования к вашему программному обеспечению и утвержден с заинтересованными сторонами.Затем вы разрабатываете в соответствии с этими требованиями и тестируете свое программное обеспечение в соответствии с ними.Как упоминалось в ответе Фрэнка, в этом процессе вам необходимо проследить от требования до контрольного примера, поскольку CMMI обязывает вас проверить все ваши требования.

1 голос
/ 14 октября 2010

В TDD тестовые случаи являются требованиями.

Но некоторые требования не поддаются проверке или требуют огромных средств для испытаний.

0 голосов
/ 14 октября 2010

Насколько я понимаю, требования несколько более общие, чем контрольные примеры.

Требованием может быть, например, следующее: Метод не должен принимать числа за пределами диапазона 18-64. В этом случае тестовые примеры могут выглядеть примерно так:17 в качестве входных данных

обеспечивают 65 в качестве входных данных обеспечивают -1 в качестве входных данных

Но в целом это вопрос общего понимания в команде разработчиков ...

Томас

0 голосов
/ 14 октября 2010

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

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

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...