Строгость в захвате тестовых случаев для модульного тестирования

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

Еще одно замечание, которое я хочу сделать об инструментах покрытия кода. В языке, подобном C# или Java, где у вас есть много get / set и подобных методов,вы не должны снимать для покрытия 100%. Это означает, что вы тратите слишком много времени на написание тестов для тривиального кода. Вам нужно только 100% покрытие для вашей сложной бизнес-логики. Если ваша полная кодовая база ближе к охвату 70-80%, вы делаете хорошую работу. Если ваш инструмент покрытия кода позволяет использовать несколько метрик покрытия, лучшим из них является 'block coverage', который измеряет покрытие 'basic blocks'. Другие типы-это покрытие класса и метода (которое не дает вам столько информации) и покрытие линии (которое является слишком мелким зерном).

Как узнать, когда вы 'done' захватываете тестовые случаи?

Вы не можете добраться до t.You до 100%, за исключением самых тривиальных случаев. Также 100% покрытие (линий, путей, условий...) не говорит вам, что вы попали во все граничные условия.

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

Отрывок из искусство тестирования программного обеспечения Гленфорд Дж. Майерс:

1. Если входное условие задает диапазон значений, напишите тестовые наборы для концов диапазона, а недопустимые входные тестовые наборы-для ситуаций сразу за его пределами.
2. Если входное условие задает некоторое количество значений, запишите тестовые случаи для минимального и максимального количества значений, а также один ниже и за пределами этих значений.
3. Используйте руководство 1 для каждого выходного условия.
4. Используйте руководство 2 для каждого выходного условия.
5. Если вход или выход программы представляет собой упорядоченный набор, сосредоточьте внимание на первом и последнем элементах набора.
6. Кроме того, используйте свою смекалку для поиска других граничных условий

( Я вставил только самый минимум по соображениям авторского права. )

Пункты 3. и 4. вышесказанное очень важно. Люди склонны забывать о граничных условиях для выходных данных. 5. это OK. 6. действительно не помогает :-)

Короткий экзамен

Это гораздо сложнее, чем кажется. Майерс предлагает этот тест:

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

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

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

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

Хороший инструмент покрытия кода действительно помогает.

100% покрытие не означает, что он определенно достаточно протестирован, но это хороший показатель.

Для .Net NCover это довольно хорошо, но больше не является открытым исходным кодом.

---

@Mike камень - Да, возможно, это должно было быть "high coverage" - мы стремимся к минимуму 80%, но около 95% это обычно уменьшает отдачу, особенно если у вас есть код с фигурными скобками 'n'.

@Keith

Я думаю, что вы поймали его, покрытие кода важно посмотреть, если вы хотите увидеть, как "done" вы есть, но я думаю, что 100%-это немного нереалистичная цель. Стремление к 75-90% даст вам довольно хорошее покрытие, не выходя за борт... не тестируйте только ради того, чтобы попасть в 100%,, потому что в этот момент Вы просто теряете свое время.