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

23

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

rsman
источник
3
когда это не удается ..
Хавьер
Я думаю, что вы могли бы прочитать сообщение в блоге Майкла Болтона об остановке эвристики для тестирования: http://www.developsense.com/blog/2009/09/when-do-we-stop-test/ Вы можете узнать некоторые из люди эвристики предложили в этой теме.
testerab
По моему опыту этого было достаточно, применяя принцип Парето .
Амир Резаи

Ответы:

3

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Джон Хопкинс
источник
4

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


источник
7
Ну, это постановка проблемы, перефразированная, не так ли?
Мартин Уикман
@Martin: очевидно нет. Вместо того, чтобы начинать с контрольного примера 1 и заканчивать контрольным примером ∞, этот ответ должен привести к тому, что спрашивающий должен начать с самого важного контрольного примера и завершить его, когда они больше не добавляют ценность.
1
Хотя философски правильно (и вдумчиво), я думаю, что ОП ищет что-то более практическое.
Мартин Уикман
«приемлемый» может быть определен заранее. Это очень помогает.
@ Thorbjørn: «Можно определить». Да, но как? Это то, что ищет ОП.
Мартин Уикман
3

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

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

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

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

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

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

CodexArcanum
источник
2

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

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

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

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

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

Брэд Купит
источник
2

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

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

mhatsu
источник
1

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

Маной Р
источник
3
Таким образом, даже если вы не проверили половину этого, вы отправляете? Это все, что не так с разработкой программного обеспечения. Вы не должны больше отправлять с неполным тестированием, если бы вы не закодировали его половину.
Джон Хопкинс
2
Это только приведет к определенной психологической отставке тестера. Я собираюсь подумать: «Что бы я ни делал, я не могу полностью протестировать эту вещь, потому что она все равно отправится на Х Январь, так что я просто сделаю все, что смогу до этого». Не так, как мы должны создавать программное обеспечение?
rsman
Как системный тестер, я редко оказывался в положении, когда дата выпуска откладывалась для дальнейшего тестирования. Я знаю, что никогда не буду ничего проверять полностью - я стараюсь расставлять приоритеты. Очевидно, что качество звонков, которые я делаю о том, какие области сначала нужно тестировать, зависит от информации, которую я получаю о техническом риске и важности для бизнеса. Самое главное, что это ВСЕГДА должно быть деловым решением, а не решением разработчика / разработчика относительно того, какой уровень риска компания готова взять на себя. Мы можем посоветовать, но это бизнес, который должен решить.
testerab
Хотя я бы полностью согласился: это не сделано, пока не проверено. (Я склонен согласиться с идеей, что нам было бы лучше использовать термин «фаза исправления», чем фазу тестирования.) Я не согласен с тем, что я считаю, что тестирование по своей сути является открытым - вы никогда не сможете провести черту и сказать «больше нет тестов, которые мы могли бы сделать сейчас», просто «больше нет тестов, которые, по нашему мнению, стоит делать сейчас».
testerab
1

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

Ларри Коулман
источник
1

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

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

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

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

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

Мартин Викман
источник
1

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

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

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

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

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

Билл
источник