Существует ли правильный способ реализации процесса непрерывного улучшения (упрочнение программного обеспечения AKA)?

Question

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

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

Есть ли хитрость для такого рода испытаний? Нужно ли указывать одну конкретную функцию за раз?

Answer 1

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

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

• регрессионное тестирование, которое вы упомянули

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

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

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

В зависимости от вашей среды эти тесты могут быть связаны с процессом разработки.

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

РЕДАКТИРОВАТЬ:

В моей среде мы используем комбинацию C ++ и C # для предоставления аналитики, используемой в финансах, код был C ++ и довольно старый, когда мы пытаемся перенести интерфейсы в сторону C # и сохранить ядро ​​аналитики в C ++ ( в основном из-за требований к скорости)

Большинство тестов C ++ - это рукописные модульные тесты и регрессионные тесты.

На стороне C # мы используем NUnit для модульного тестирования. У нас есть пара общих тестов.

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

Установка явных соглашений и рекомендаций - еще один способ улучшить качество вашего кода.

Answer 2

Есть ли хитрость для такого рода испытаний?

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

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

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

«Регрессионное тестирование» означает для меня, что вы делаете последнее.

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

Нужно ли указывать одну конкретную функцию за раз?

Что вы пытаетесь сделать, именно:

• Нашли ошибки до того, как клиенты их найдут?
• Убедите клиентов, что с новой новой разработкой все в порядке?
• Потратьте как можно меньше времени на тестирование?

Очень общий совет заключается в том, что жуки живут в семьях: поэтому, когда вы найдете жука, найдите его родителей, братьев и сестер и двоюродных братьев, например:

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

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

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

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

---

Редактировать: Стоит отметить, что тестирование - не единственный способ найти ошибки. Там же:

• Неофициальные отзывы о дизайне (35%)
• Формальные проектные проверки (55%)
• Неофициальные коды отзывов (25%)
• Официальные проверки кодов (60%)
• Персональная проверка кода (40%)
• Юнит тест (30%)
• Проверка компонентов (30%)
• Интеграционный тест (35%)
• Регрессионный тест (25%)
• Системный тест (40%)
• Бета-тест малого объема (<10 сайтов) (35%) </li>
• Бета-тест большого объема (> 1000 сайтов) (70%)

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

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

Answer 3

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

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

Answer 4

Здесь много говорят о модульном тестировании, и я не могу согласиться с этим. Я надеюсь, что Джош понимает, что модульное тестирование - это механизированный процесс. Я не согласен с PJ в том, что модульные тесты должны быть написаны до кодирования приложения, а не после. Это называется TDD или Test Driven Development.

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

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

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

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

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

• CruiseControl для непрерывной интеграции
• Subversion для контроля версий исходного кода, поскольку он хорошо интегрируется с CruiseControl
• Spring, потому что DI облегчает механизацию модульного тестирования в целях непрерывной интеграции
• JUnit для модульного тестирования среднего уровня
• HttpUnit для модульного тестирования GUI
• Apache JMeter для стресс-тестирования

Answer 5

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

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

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

Answer 6

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