Написание тестов качества

Question

Мы знаем, что охват кода - плохой показатель, который можно использовать при оценке качества кода теста. Мы также знаем, что тестирование языка / фреймворка - пустая трата времени.

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

Answer 1

1. Убедитесь, что ваши тесты независимы друг от друга. Тест не должен зависеть от выполнения или результатов другого теста.
2. Убедитесь, что в каждом тесте четко определены критерии входа, шаги теста и критерии выхода.
3. Настройка матрицы прослеживаемости проверки требований (RVTM). Каждый тест должен проверить одно или несколько требований. Кроме того, каждое требование должно быть проверено как минимум одним тестом.
4. Убедитесь, что ваши тесты идентифицируемы. Установите простое соглашение об именовании или маркировке и придерживайтесь его. При регистрации дефектов обращайтесь к идентификатору теста.
5. Относитесь к своим тестам так же, как к своему коду. Иметь процесс разработки тестового программного обеспечения, который отражает ваш процесс разработки программного обеспечения. Тесты должны иметь рецензирование, быть под контролем версий, иметь процедуры контроля изменений и т. Д.
6. Категоризация и организация ваших тестов. Упростите поиск и запуск теста или набора тестов по мере необходимости.
7. Сделайте свои тесты максимально краткими. Это облегчает их запуск и автоматизацию. Лучше выполнить много маленьких тестов, чем один большой тест.
8. Если тест не пройден, легко понять, почему тест не пройден.

Answer 2

Убедитесь, что писать тесты легко и быстро. Тогда напишите их много.

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

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

Answer 3

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

Answer 4

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

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

Answer 5

Есть два хороших способа проверить качество теста

1. Отзыв по коду

С помощью проверки кода можно проверить шаги импортеров, определенные @Patrick Cuff в его ответе https://stackoverflow.com/a/197332/516167

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

2. Мутация

Второе дешевле - это автоматизированная работа, которая измеряет качество теста.

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

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

• Как обеспечить качество тестов junit?

Answer 6

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

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

Answer 7

Мои эмпирические правила:

1. Включите в свой план тестирования еще более простые тестовые примеры (не рискуйте оставить наиболее использованные функции непроверенными)
2. Обведите соответствующие требования рядом с каждым контрольным примером
3. Как говорит Джоэл , есть отдельная команда, которая проводит тестирование