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

Question

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

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

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

Answer 1

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

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

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

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

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

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

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

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

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

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

Большинство тестов C++ представляют собой написанные вручную модульные тесты и регрессионные тесты.

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

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

Явное установление соглашений и лучших практик — еще один способ улучшить качество вашего кода.

Answer 2

Есть ли какая-то хитрость в таком тестировании?

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

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

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

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

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

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

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

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

Самый общий совет: насекомые живут семьями:поэтому, когда вы обнаружите ошибку, поищите ее родителей, братьев и сестер, например:

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

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

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

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

---

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

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

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

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

Answer 3

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

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

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

Answer 4

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

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

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

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

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

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

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

Answer 5

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

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

Answer 6

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