Модульные тесты и приемочные испытания достаточно?

Попробуйте установить Google Chrome CORS Plugin, а затем запросить снова.

9
задан cgp 18 May 2009 в 13:48
поделиться

10 ответов

Я бы порекомендовал прочитать главы 20–22 во 2-м издании Code Complete . Он очень хорошо описывает качество программного обеспечения.

Вот краткое описание некоторых ключевых моментов (вся заслуга МакКоннелла, 2004 г.)

Глава 20 - Пейзаж качества программного обеспечения:

  • Ни одного дефекта -техника обнаружения полностью эффективна сама по себе
  • Чем раньше вы обнаружите дефект, тем меньше он будет переплетаться с остальной частью вашего кода и тем меньше повреждений он нанесет

Глава 21 - Совместное построение:

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

    Может быть, это не совсем то, о чем вы спрашивали, но я бы сказал, что автоматизированного тестирования определенно недостаточно для стратегии . Вам также следует учитывать такие вещи, как парное программирование, формальные обзоры (или неофициальные обзоры, в зависимости от размера проекта) и тестовые строительные леса вместе с вашим автоматическим тестированием (модульные тесты, регрессионное тестирование и т. Д.).

8
ответ дан 4 December 2019 в 06:41
поделиться

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

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

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

Однако что-то есть. изменяется между этими двумя точками, которые также следует проверить. Это интеграция единиц в продукт перед передачей клиенту.

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

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

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

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

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

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

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

8
ответ дан 4 December 2019 в 06:41
поделиться

Это зависит от сложности вашей системы. Если ваши приемочные испытания (которые удовлетворяют требованиям клиентов) проверяют вашу систему от начала до конца, то нет, вы этого не сделаете.

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

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

Частые отзывы Циклы к клиенту и / или тесты, которые написаны / проанализированы способом, понятным клиенту (например, в стиле BDD ), действительно могут помочь.

0
ответ дан 4 December 2019 в 06:41
поделиться

Если у меня есть модульные тесты для каждого класса и / или членство и принятие тесты для каждой пользовательской истории у меня есть достаточно тестов, чтобы гарантировать проект работает должным образом?

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

0
ответ дан 4 December 2019 в 06:41
поделиться

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

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

It ' Также стоит отметить, что разные наборы тестов, как правило, тестируют продукт / код с другой «точки зрения». Примерно так же, как QA может обнаруживать ошибки, которые разработчики никогда не думали тестировать, один набор тестов может обнаружить то, чего не обнаружит другой набор.

0
ответ дан 4 December 2019 в 06:41
поделиться

Если у меня есть модульные тесты для каждого класса и / или функции-члена, а также приемочные тесты для каждой пользовательской истории, достаточно ли у меня тестов, чтобы гарантировать, что проект функционирует должным образом?

Нет. Тесты могут подтвердить только то, о чем вы думали. Не то, о чем вы не думали.

13
ответ дан 4 December 2019 в 06:41
поделиться

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

Тесты должны охватывать как хорошие, так и плохие пути, особенно в модульных тестах. Ваши приемочные тесты могут быть более или менее связаны с неправильным поведением пути, но должны, по крайней мере, устранять типичные ошибки, которые могут быть сделаны. В зависимости от того, насколько полны ваши истории, приемочные испытания могут быть или не быть адекватными. Часто между приемочными тестами и историями существует взаимосвязь «многие к одному». Если у вас есть только один автоматический приемочный тест для каждой истории, вам, вероятно, будет недостаточно, если у вас нет разных историй для альтернативных путей.

3
ответ дан 4 December 2019 в 06:41
поделиться

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

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

2
ответ дан 4 December 2019 в 06:41
поделиться

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

0
ответ дан 4 December 2019 в 06:41
поделиться

Короче говоря,

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

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

Кроме того, вам нужен автоматизированный тест производительности. Ежедневный или ночной запуск профилировщика позволит получить представление о потреблении ресурсов ЦП и памяти, а также о наличии утечек памяти. Кроме того, такой инструмент, как loadrunner, позволит вам разместить нагрузку на систему, которая отражает фактическое использование. Вы сможете измерять время отклика, а также потребление ЦП и памяти в производственной среде, например на машине, на которой выполняется loadrunner.

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

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

Наконец, есть приемочное тестирование пользователей (UAT). Это тесты, разработанные владельцем продукта / деловым партнером для тестирования всей системы перед выпуском. Как правило, из-за всех других тестов приложение нередко возвращает ноль дефектов во время UAT.

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

Наконец, есть приемочное тестирование пользователей (UAT). Это тесты, разработанные владельцем продукта / деловым партнером для тестирования всей системы перед выпуском. Как правило, из-за всех других тестов приложение нередко возвращает ноль дефектов во время UAT.

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

Наконец, есть приемочное тестирование пользователей (UAT). Это тесты, разработанные владельцем продукта / деловым партнером для тестирования всей системы перед выпуском. Как правило, из-за всех других тестов приложение нередко возвращает ноль дефектов во время UAT.

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

Наконец, есть приемочное тестирование пользователей (UAT). Это тесты, разработанные владельцем продукта / деловым партнером для тестирования всей системы перед выпуском. Как правило, из-за всех других тестов приложение нередко возвращает ноль дефектов во время UAT.

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

Наконец, есть приемочное тестирование пользователей (UAT). Это тесты, разработанные владельцем продукта / деловым партнером для тестирования всей системы перед выпуском. Как правило, из-за всех других тестов приложение нередко возвращает ноль дефектов во время UAT.

0
ответ дан 4 December 2019 в 06:41
поделиться
Другие вопросы по тегам:

Похожие вопросы: