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

У меня есть продукт X, который мы поставляем клиенту, C каждый месяц, включая исправления, улучшения, новые разработки и т. Д.) Каждый месяц меня просят ошибаться, «гарантируя» качество продукта.

Для этого мы используем ряд статистических данных, полученных из тестов, которые мы делаем, таких как:

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

и различные другие цифры.

По причинам, по которым мы не пойдем, невозможно каждый раз проверять все.

Итак, мой вопрос:

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

Я знаю, что это немного открытый вопрос, но, эй, я также знаю, что простых решений не существует.

Спасибо.

18.08.2008 20:18:22
7 ОТВЕТОВ
РЕШЕНИЕ

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

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

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

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

2
18.08.2008 20:43:17
Ошарашивание - ответ на получение статистически правдоподобной оценки скрытых ошибок, en.wikipedia.org/wiki/Bebugging
Tim Williscroft 14.04.2010 03:54:18

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

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

1
18.08.2008 20:27:06

Вопрос в том, кто требует от вас предоставить статистику.

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

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

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

2
18.08.2008 20:36:56

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

0
18.08.2008 20:41:12

Большинство гибких методологий довольно четко решают эту дилемму. Вы не можете проверить все. Вы также не можете протестировать его бесконечное количество раз перед выпуском. Таким образом, процедура заключается в том, чтобы полагаться на риск и вероятность ошибки. И риск, и вероятность являются числовыми значениями. Продукт обоих дает вам номер RPN. Если число меньше 15, вы отправляете бета-версию. Если вы можете снизить его до менее чем 10, вы отправите продукт и отправите ошибку, которая будет исправлена ​​в будущем выпуске.

Как рассчитать риск?

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

Как рассчитать вероятность?

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

Что ж, мне любопытно узнать, хочет ли кто-нибудь еще использовать эту схему и хочет ли узнать об этом.

1
18.08.2008 20:44:11

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

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

Как я могу оценить ошибки в моем программном обеспечении?

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

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

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

Совещания по рассмотрению проекта, чтобы быстро определить, что было хорошо, чтобы можно было повторить то, что было плохо, и найти способ не делать это снова.

Надеюсь, это даст вам хорошее начало. Удачи!

0
17.09.2008 04:03:42

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

Моя компания полагается на тестирование уровня системы / интеграции. Я вижу много дефектов, потому что отсутствует регрессионное тестирование. Я думаю, что «ошибки», когда реализация требований разработчика отклоняется от видения пользователя, являются своего рода отдельной проблемой, которую, как заявили Dan и rptony, лучше всего решать с помощью Agile-методологий.

0
14.10.2008 15:46:24
Лучше, чем концентрироваться на каком-либо конкретном уровне тестирования (например, модульное тестирование), лучше иметь тесты на всех уровнях (модуль, интеграция, система), поскольку выявляются различные виды ошибок.
Edu 26.04.2012 05:54:23