Сколько Времени Должно быть Выделено для Тестирования и [закрытого] Устранения ошибки
Многие объяснения уже присутствуют, чтобы объяснить, как это происходит и как это исправить, но вы также должны следовать рекомендациям, чтобы избежать NullPointerException вообще.
См. также: A хороший список лучших практик
Я бы добавил, очень важно, хорошо использовать модификатор final. Использование "окончательной" модификатор, когда это применимо в Java
Сводка:
- Используйте модификатор
finalдля обеспечения хорошей инициализации. - Избегайте возврата null в методы, например, при возврате пустых коллекций.
- Использовать аннотации
@NotNullи@Nullable - Быстрое завершение работы и использование утверждений, чтобы избежать распространения нулевых объектов через все приложение, когда они не должен быть пустым.
- Сначала используйте значения с известным объектом:
if("knownObject".equals(unknownObject) - Предпочитают
valueOf()поверх toString (). - Используйте null safe
StringUtilsStringUtils.isEmpty(null).
4 ответа
Это действительно зависит от большого количества факторов. Упоминать только некоторые: методология разработки, которую Вы используете, объем тестирования ресурса, который Вы имеете, число разработчиков, доступных на данном этапе в проекте (многие менеджеры проектов перейдут людей на что-то новое в конце).
Как Rob Rolnick говорит 1:1, хорошее эмпирическое правило однако в случаях, где спецификация плоха, клиент может стремиться к "ошибкам", которые являются на самом деле плохо указанными функциями. Я был недавно вовлечен в проект, который использовал много выпусков, но больше времени было проведено на устранении ошибки, чем фактическая разработка из-за ужасной спецификации.
Гарантируйте хорошую спецификацию/дизайн, и Ваше время тестирования/устранения ошибки будет уменьшено, потому что для тестеров будет легче видеть, какой и как протестировать, и у любых клиентов будет меньше дрейфа для стремления к дополнительным функциям.
От тестирования Библия:
Тестирование программного обеспечения
p. 31: "Тестирование [...] составляет 45% начального развития продукта". Хорошее эмпирическое правило состоит в том, чтобы таким образом выделить приблизительно половину Вашего общего усилия к тестированию во время начального развития.
Только хорошая сумма накопленной статистики из предыдущих проектов может помочь Вам дать точные оценки. Если у Вас есть четко определенный набор требований, можно сделать грубое вычисление того, сколько вариантов использования Вы имеете. Как я сказал, у Вас должна быть некоторая статистика для Вашей команды. Необходимо знать, что среднее число ошибок на местоположение оценивает общее количество ошибок. Если у Вас нет таких чисел для Вашей команды, можно использовать числа среднего показателя по отрасли. После оценки LOC (количество вариантов использования * NLOC) и средние ошибки на строки можно дать более или менее точную оценку, вовремя требуемую к проекту версии.
От моего практического опыта время, проведенное на устранении ошибки, равно или больше (в 99% случаев :)), чем время, проведенное на исходной реализации.
Возможно, я просто пишу содержащий код, но мне нравится иметь 1:1 отношение между devs и тестами. Я не ожидаю до альфы, чтобы протестировать, а скорее сделать это в течение целого проекта. Логика? В зависимости от Вашего плана выпуска могло быть много времени между тем, когда разработка запускается и когда Ваша альфа, бета и даты поставки. Кроме того, чем ранее Вы ловите ошибки, тем легче (и более дешевый) они должны зафиксировать.
Хороший тестер, кто находит ошибки вскоре после каждой регистрации, неоценим. (Или еще лучше перед регистрацией от PR или DPK) Проще говоря, я все еще чрезвычайно знаком со своим кодом, таким образом, большинство исправлений ошибок становится супер простым. С этим подходом я склонен оставлять примерно 15% своего dev времени к устранению ошибки. По крайней мере, когда я делаю оценки. Таким образом в 16-недельном выполнении я разбросал бы 2-3 недели.