<100%-е Тестовое покрытие - лучшие практики в выборе [закрытых] зон испытания
7 ответов
100% покрытие кода не является желательной целью. См. этот блог по некоторым причинам.
Моя лучшая практика заключается в том, чтобы извлекать тестовые случаи из вариантов использования. Создайте конкретную прослеживаемость (я использую инструмент UML, но электронная таблица также будет работать) между вариантами использования, которые ваша система должна реализовать, и тестовыми случаями, которые доказывают, что она работает.
Четко определите наиболее важные варианты использования. Теперь посмотрите на тестовые случаи, которые они прослеживают. У вас есть много тестовых случаев для критических вариантов использования? Охватывают ли они все аспекты использования? Охватывают ли они негативные и исключительные случаи?
Я обнаружил, что это лучшая формула (и лучшее использование времени команды) для обеспечения хорошего покрытия.
EDIT:
Простой, надуманный пример того, почему 100% покрытие кода не гарантирует вам тестирование 100% случаев. Скажем, CriticalProcess() должен вызывать AppendFile() для добавления текста, но вместо этого вызывает WriteFile() для перезаписи текста.
[UnitTest]
Cover100Percent()
{
CriticalProcess(true, false);
Assert(FileContents("TestFile.txt") == "A is true");
CriticalProcess(false, true);
Assert(FileContents("TestFile.txt") == "B is true");
// You could leave out this test, have 100% code coverage, and not know
// the app is broken.
CriticalProcess(true, true);
Assert(FileContents("TestFile.txt") == "A is trueB is true");
}
void CriticalProcess(bool a, bool b)
{
if (a)
{
WriteFile("TestFile.txt", "A is true");
}
if (b)
{
WriteFile("TestFile.txt", "B is true");
}
}
Если у вас есть устаревшая кодовая база, хорошее место для начала:
Добавьте модульный тест для каждой найденной и исправленной ошибки. Модульный тест должен воспроизвести ошибку, затем вы исправляете код и используете модульный тест, чтобы убедиться, что он исправлен, а затем убедиться, что в будущем он не сломается снова по какой-либо причине.
По возможности добавляйте тесты к основным высокоуровневым компонентам, чтобы многие низкоуровневые поломки по-прежнему вызывали сбой модульного теста (например, вместо независимого тестирования каждой процедуры доступа к базе данных, добавьте один тест, который создает базу данных и добавляет 100 пользователей. , удаляет 50 из них, проверяет результат и удаляет базу данных.Вы не сможете легко увидеть , где сбой (вам придется выполнить отладку, чтобы выяснить, почему это не удалось), но, по крайней мере, вы знаете, что у вас есть тест, который проверяет всю систему базы данных и предупредит вас быстро, если что-то серьезное пойдет не так в этой области кода. Как только у вас будут покрыты области более высокого уровня, вы можете беспокоиться о том, чтобы копаться глубже.
Добавьте модульные тесты для вашего нового кода или при изменении любого кода.
Со временем это само по себе поможет вам расширить охват в более важных местах.
(Имейте в виду, что если ваша кодовая база - это рабочий код, который работал годами, то по большей части вам не «нужны» модульные тесты, чтобы доказать, что он работает. Если вы просто добавляете модульные тесты ко всему, они почти все пройдут и поэтому мало что вам скажут. Конечно, со временем, по мере роста вашего охвата, вы можете начать обнаруживать регрессии из этих тестов, и вы обнаружите ошибки в процессе добавления модульных тестов для ранее непроверенных кода, но если вы просто пропустите код вслепую, добавляя модульные тесты для всего, вы получите очень низкое соотношение цены за исправленную ошибку)
Есть 3 основных компонента, о которых вы должны знать:
- важные особенности - вы должны знать, что является более важным. Спросите себя: «Насколько я (или мой клиент) облажался бы, если бы обнаружил ошибку в этом компоненте / фрагменте кода?». Ваш клиент, вероятно, может помочь вам в определении таких приоритетов. То, что напрямую связано с деньгами, обычно сопровождается этот случай
- часто используемые функции - Наиболее распространенные варианты использования должны быть максимально свободными от ошибок. Никого не волнует, есть ли ошибка в той части системы, которую никто не использует
- самые сложные функции - Разработчики обычно хорошо понимают, какие части кода с большей вероятностью содержат ошибки. Вам следует уделять им особое внимание.
Если у вас есть эта информация, то, вероятно, будет несложно выбрать, как распространять ваши ресурсы по тестированию.
Это полностью зависит от типа программного обеспечения, которое вы разрабатываете. Если он доступен удаленно, то тестирование безопасности должно быть наивысшим приоритетом. В случае веб-приложений можно использовать автоматизированные тесты, такие как Sitewatch или Wapiti. Существуют также инструменты, помогающие создавать модульные тесты для SOAP.
Если вы не занимаетесь разработкой с нуля с использованием TDD, вы вряд ли получите (или захотите) 100% тестовое покрытие. Покрытие кода - это скорее рекомендация, что-то, чтобы спросить: «Что я не тестировал?»
Вы можете посмотреть на другие показатели, такие как цикломатическая сложность . Найдите сложные области своего кода и протестируйте их (затем выполните рефакторинг для упрощения).
Ложное чувство безопасности: Вы должны всегда помнить о том, что тестовое покрытие может привести к ложному чувству безопасности. Отличную статью об этом факте можно найти в блоге disco. Тем не менее, полагаясь на информацию "зеленых" индикаторов, вы можете пропустить непроверенные пути.
Хороший индикатор для непроверенных путей: С другой стороны, отсутствие тестового покрытия, чаще всего отображаемое красным цветом, всегда является отличным индикатором для путей, которые не покрыты. Вы можете проверить их в первую очередь, потому что их легко обнаружить, и это позволит вам оценить, хотите ли вы добавить тестовое покрытие здесь или нет.
Код-ориентированный подход для выявления критических элементов: Существует отличная инструментальная поддержка, которая поможет вам найти беспорядок и возможные ошибки в вашем коде. Вы можете взглянуть на IDE IntelliJ и ее функции анализа кода или, например, на Findbugs, Checkstyle и PMD. Отличным инструментом, объединяющим эти инструменты статического анализа кода и доступным бесплатно, является Sonar.
Ориентированный на особенности подход к выявлению критических элементов: Оцените свое программное обеспечение и разбейте его на особенности. Задайте себе такие вопросы, как: "Какие функции наиболее важны и должны быть наиболее надежными? Где мы должны заботиться о правильности результатов? Где ошибка или сбой будут наиболее разрушительны для программного обеспечения?"
.Возможно, лучший намек на то, что модуль недостаточно защищен, - это сообщения об ошибках против него. Любой модуль, который вы редактируете снова и снова, должен быть хорошо защищен. Но цикломатическая сложность также очень хорошо коррелирует с частотой ошибок - и вы можете измерить это до появления ошибок!