Как узнать, когда прекратить тестирование?

Я знаю, что это очень очень простой вопрос. Для некоторых программных приложений существует большое, почти бесконечно большое количество тестовых случаев для приложения. Испытывать все эти контрольные примеры непрактично. Как мы решаем, когда прекратить тестирование? (кроме «когда деньги заканчиваются»).

Книга Гленфорда Майерса « Искусство тестирования программного обеспечения» имеет простое, но принципиальное правило для этого: тестирование завершено, когда вы перестали находить ошибки. Или, на практике, когда скорость, с которой вы находите новые ошибки, сильно замедляется.

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

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

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

Простой ответ - это зависит от системы. Если вы пишете встроенное программное обеспечение для кардиомонитора или инструменты контроля безопасности для ядерного реактора, тогда этот стандарт намного выше, чем если бы вы писали блог-платформу.

Это действительно вопрос для хорошего системного тестера (а я не один), но я попробую.

Ваша основная мера будет охватить тестирование: сколько приложений действительно было протестировано (как модульным тестом, так и функционально).

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

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

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

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

(Я думаю, что это называется чередование, но не цитируйте меня об этом.)

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

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

«Тестирование программы может использоваться, чтобы показать наличие ошибок, но никогда не показывать их отсутствие!» - Эдсгер Дейкстра

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

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

По сути, вы хотите быть покрыты в двух больших местах:

1. Проходит ли программное обеспечение тесты BDD, которые демонстрируют, что оно соответствует указанным требованиям. Программное обеспечение даже нельзя назвать готовым, если это не так.

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

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

Если вы говорите о модульном тестировании и выполняете TDD (сначала пишете тесты), то это не проблема: вы просто прекращаете тестирование, когда все функции завершены.

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

Вот отличный пример.

Статистики также смотрели на эту проблему - на самом деле еще в 1970-80-х годах. Учитывая соответствующие предположения о том, как обнаруживаются ошибки, они пытаются оценить количество ошибок по данным тестирования. Затем он используется для определения момента остановки на основе оптимизации функции потерь. Смотрите, например, https://rpubs.com/hoehle/17920 ... для краткого описания одной из статей по этому вопросу, включая код R, как это сделать на практике.

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

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

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

Все сводится к доверию. Вы уверены, что система достаточно протестирована?

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

Вот несколько тестов, связанных с «Done-Indicators»:

• Ваша сборка и установка полностью автоматизированы и все тесты (юнит, графический интерфейс, интеграция) выполнены автоматически?
• Вы пишете свои тесты во время (или предпочтительно до) написания кода, а не после?
• Чувствуете ли вы себя достаточно безопасно, чтобы сделать большой рефакторинг кода без ошибок?
• Достаточно ли высок уровень покрытия вашего кода?
• У вас есть специальный тестер в вашей команде? Он / она вовлечен ежедневно на протяжении всего развития, а не только в конце?
• Ваш тестер вручную (пробный) пытался сломать его безуспешно?

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

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

Но, как мы знаем, вы не можете проверить «навсегда», поэтому я думаю, что предел зависит в основном от:

• Когда риск, связанный с использованием программного обеспечения, был снижен до приемлемого уровня. (как говорит @Graham Lee)
• Кто системный пользователь? это может быть вы или президент Соединенных Штатов. В первом случае вас не волнует, если ошибка появляется, потому что вы ее решаете и все готово. Во втором случае вы не хотите, чтобы появилась ЛЮБАЯ ошибка.
• Каковы ваши отношения с вашим клиентом? Может быть, клиент - это твой папа, так что это не так страшно, или, может быть, это большая компания.
• Насколько серьезен для пользователей системы баг? Это вызовет третью мировую войну или просто уродливое сообщение?

Когда люди, которые должны подписаться на развертывание, удовлетворены.

или в некоторых случаях большинство ответственных сторон удовлетворены.