Сколько тестирование достаточно? [закрытый]

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

Думайте, а не слепо следуйте одной метрике, такой как как покрытие кода.

Остановитесь, когда вы освоитесь с набором тестов и своим кодом. Вернитесь и добавьте больше тестов, когда (если?) Что-то начнет давать сбой.

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

Хороший вопрос!

Во-первых - звучит как будто ваше обширное интеграционное тестирование окупилось :)

Из моего личного опыта:

• Если это новый проект "зеленых полей", Мне нравится применять строгое модульное тестирование и тщательно (так же тщательно, как возможно) интеграционный план тестирования
• Если это уже существующая программа с плохим тестовым покрытием, тогда я предпочитаю разрабатывать комплексную интеграцию тесты, которые проверяют конкретные / известные функциональность. Затем я представляю тесты (юнит / интеграция) как я продвигайтесь дальше с кодовой базой.

Сколько достаточно? Сложный вопрос - я не думаю, что этого когда-либо может быть достаточно!

«Слишком много всего - достаточно»

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

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

В классической книге Джеральда Вайнберга « Психология компьютерного программирования» есть много хороших историй о тестировании. Одна из них, которая мне особенно нравится, - в главе 4 « Программирование как социальная деятельность » «Билл» просит коллегу просмотреть его код, и они находят семнадцать ошибок только в тринадцати утверждениях. Проверки кода предоставляют дополнительные возможности для поиска ошибок. Чем больше глаз вы используете, тем больше у вас шансов найти самые незаметные ошибки. Как сказал Линус: «При достаточном количестве глазных яблок все ошибки неглубокие», ваши тесты - это в основном роботизированные глаза, которые будут просматривать ваш код столько раз, сколько вы хотите, в любое время дня и ночи и сообщать вам, все ли все еще кошерно.

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

Начав с нуля, вы не хотите тратить все свое время на написание теста и в конечном итоге не выполнить его, потому что 10% функций, которые вы смогли кодировать, тщательно протестированы. Придется определить приоритеты. Один из примеров - частные методы. Поскольку частные методы должны использоваться кодом, который виден в той или иной форме (общедоступный / пакет / защищенный), частные методы можно рассматривать как охваченные тестами для более заметных методов. Здесь вам нужно включить некоторые тесты белого ящика, если в частном коде есть какие-то важные или неясные поведения или крайние случаи.

Тесты должны помочь вам убедиться: 1) вы понимаете требования, 2) придерживаться хороших практик проектирования, создавая код для тестирования, и 3) знать, когда ранее существующий код перестает работать. Если вы не можете описать тест для какой-либо функции, я готов поспорить, что вы недостаточно хорошо понимаете эту функцию, чтобы правильно ее кодировать. Использование кода модульного тестирования вынуждает вас делать такие вещи, как передавать в качестве аргументов такие важные вещи, как соединения с базой данных или фабрики экземпляров, вместо того, чтобы поддаваться искушению позволить классу делать слишком много самостоятельно и превратиться в объект «Бог». Если вы позволите своему коду стать вашей канарейкой, это означает, что вы можете писать больше кода. Если предыдущий пройденный тест не проходит, это означает одно из двух: либо код больше не выполняет то, что ожидалось, либо требования к функции изменились, и тест просто необходимо обновить, чтобы он соответствовал новым требованиям.

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

Вероятно, вы никогда не найдете 100% своих ошибок.

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

Примечание: Мой ответ в первую очередь обращаются к интеграционному тестированию. TDD очень отличается. Раньше он рассматривался в SO, и теперь вы прекращаете тестирование, когда у вас больше нет функций для добавления. TDD - это дизайн, а не обнаружение ошибок.

Все тестирую. Ненавижу это, но это важная часть моей работы.

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

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

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

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

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

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

Тем не менее, я по умолчанию требую покрытия юнит-тестами на уровне 90% ( линия и ветвь) с использованием junit и cobertura (для Java). Когда я чувствую, что эти требования не могут быть выполнены из-за природы конкретного класса (или ошибок в cobertura), я делаю исключения.

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

Я проработал в QA 1,5 года, прежде чем стать разработчиком.

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

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

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

Важно отметить, что из-за естественного отбора код может стать «невосприимчивым» к тестам. Code Complete говорит, что при исправлении дефекта нужно написать тестовый пример для него и искать похожие дефекты, также неплохо написать тестовый пример для дефектов, похожих на него.