Анна Сергеева. Эффективные возможности повышения качества разработки программных приложений //Системный администратор. 2015. № 10. С. 54-57.
Как сокращать сроки разработки ПО, предотвращать возможные ошибки и повышать качество выпускаемых приложений, если не всегда есть возможность продлевать сроки разработки и оплачивать дополнительные расходы на привлечение большего числа программистов и тестировщиков
Опубликовано в разделе "Разработка / Тестирование"
Эта же статья на сайте журнала
Выпуск ПО с точки зрения руководителей компаний
Крупные компании-разработчики с мировым именем способны поставлять на рынок достаточно масштабные программные пакеты, вплоть до корпоративного уровня. Такие приложения, как правило, имеют довольно сложную структуру и большой объем исходного кода, на создание которого расходуется много времени и человеческих ресурсов.
Разумеется, здесь речь идет об обороте крупных финансовых вложений. А значит, велики и риски от срыва сроков поставки, от неучтенных и неисправленных проблем и ошибок в ПО, слишком поздно обнаруженных конечными пользователями, уже на этапе эксплуатации.
Стоит заметить, что ничуть не меньшие риски преследуют и создателей небольших проектов, запущенных в формате стартапов. Здесь, в большинстве случаев, используется заемный капитал, который нужно своевременно возвращать банкам и кредитным организациям, и в то же время, в развитии таких проектов заняты очень небольшие команды инженеров.
Соответственно, руководство и тех, и других компаний-разработчиков преследует две противоречащие друг другу цели. С одной стороны, речь идет о жесткой экономии времени и денег, а значит, нужно выпускать готовые версии ПО в самые сжатые сроки. С другой стороны, нужно обеспечить высокий уровень качества выпускаемой продукции, чтобы она была конкурентоспособной на большом рынке.
Практика показывает, что потенциальные клиенты быстро теряют интерес к программным продуктам, если они содержат множество дефектов, что делает эксплуатацию неудобной или ограничивает спектр поддерживаемых функциональных возможностей. В некоторых случаях, для такого отрицательного эффекта порой бывает достаточно и одной ошибки, зато с высоким уровнем критичности.
В действительности, этот факт способен поставить крест на любых только начинающих набирать баллы стартапах, даже самых бюджетных на начальной стадии формирования имиджа компании. В равной степени, это может также серьезно пошатнуть репутацию крупных компаний-разработчиков, а значит, привести к снижению уровня доверия клиентов и к спаду продаж.
И с точки зрения технических специалистов
Итак, менеджмент ставит перед разработчиками непростую задачу сокращать сроки разработки ПО, предотвращать возможные ошибки и повышать качество выпускаемой продукции.
Разумеется, можно привлечь к работе большее число программистов, запланировать и провести тестирование в большем объеме, прибегнуть к внедрению автоматизации и т.п. Однако, стоит задуматься, где взять на это время и дополнительных сотрудников. А также, что немаловажно, готово ли руководство компании идти навстречу своим сотрудникам и оплачивать все эти дополнительные расходы.
Скорее всего, стоит взглянуть на ситуацию с другой стороны и качественно изменить сам подход к организации процесса разработки и тестирования ПО.
Существуют определенные методики, применение которых позволяет, если не вообще избежать, то серьезно снизить возможность возникновения ошибок в программном коде в ходе его разработки. Одновременно эти методы позволяют разработчикам более удобно воспринимать и поддерживать код друг друга, взаимодействовать между собой.
Но, не будем забегать вперед и поговорим обо всем по порядку.
Соблюдение стандартов кодирования
Начнем с того, как вообще создается исходный код программных приложений.
Каждому инженеру характерен свой стиль кодирования. Кто-то аккуратно соблюдает правила табуляции, присваивает переменным, константам и функциям осмысленные имена, подробно комментирует код. Кто-то работает предельно оперативно, но при этом создает файлы, в которых с трудом смогут сориентироваться все другие участники проекта. А значит, поддержка и интеграция такого кода будет затруднена и отнимет больше времени, которое всегда в дефиците в современных условиях ведения гибкой разработки ПО [1].
Для подавляющего большинства наиболее востребованных языков программирования уже существуют свои стандарты кодирования или стили программирования.
Их принятие и использование облегчает восприятие и поддержание кода, когда он разрабатывается одновременно несколькими программистами в одной команде. Также применение единого стиля упрощает и характер взаимодействия между разработчиками [2].
По сути, стандарт - это перечень формализованных соглашений и правил, которые определяют некоторое подмножество конкретного языка и принципы его применения. Хотя сами стандарты кодирования очень сильно зависят от специфики конкретного языка программирования, тем не менее, в основном все они описывают:
-
способы выбора имен для переменных и идентификаторов;
-
регистр символов (верхний, нижний, применение знака подчеркивания при разделении слов и т.д.);
-
использование табуляций или пробелов в качестве отступов при оформлении логических блоков, а также определение ширины таких отступов;
-
применение пробелов для оформления арифметических и логических выражений;
-
способ расстановки скобок при ограничении отдельных логических блоков;
-
стиль комментирования кода.
Кроме этого, хороший стиль подразумевает отсутствие магических чисел и перенос строк кода, чтобы для удобства восприятия он помещался на экране.
Ко всему этому стоит добавить, что с точки зрения менеджмента проекта, соблюдение таких стандартов повышает безопасность, совместимость и надежность выпускаемого кода [3].
Анализ сложности и метрики исходного кода
Очень часто сложность исходного кода приложений является показателем возможных проблем в будущем. Тому есть ряд причин. Слишком сложный код со временем становится все труднее понимать, тестировать и поддерживать. К тому же, чем больше итераций и условных конструкций в коде, тем выше степень его сложности и, соответственно, тем больше вероятность имеющихся в нем ошибок.
Для измерения сложности кода широко применяются показатели сложности кода для каждой из функций в программном коде. Также учитывается информация об объеме строк кода, используемых для реализации каждой такой функции [4].
Распространены и другие типы метрик кода.
В частности, оценивается число строк в файлах и функциях, а также цикломатическая сложность кода и уровень его комментирования. Подобные оценки удобно проводить как на уровне всего проекта, так и на уровне отдельных файлов.
Анализируя эти показатели, разработчики могут определять, какие части кода нуждаются в улучшении, что обычно приводит к снижению числа ошибок и упрощению поддержки кода.
Такое измерение и управление сложностью кода является одним из наиболее дешевых и лучших способов снижения объема ошибок и затрат на дальнейшее обслуживание приложений, уже на этапе их эксплуатации.
Экспертная оценка исходного кода
Еще один способ снижения уровня ошибок и дефектов на ранних стадиях разработки — это экспертная оценка или обзор кода.
Суть его в том, что одни разработчики проекта изучают код, написанный другими.
Менеджмент проекта определяет область кода для изучения, назначает экспертов и предоставляет им возможности комментирования кода, чтобы они описали характер обнаруженных проблем и предполагаемой степени их серьезности.
Данная процедура удобна тем, что не имеет ограничений по срокам применения. Она может инициироваться неоднократно, практически на всех этапах проекта, как до выпуска альфа- или бета-версий, так и уже после реализации или обновления каких-либо ключевых возможностей.
Как правило, выполняется экспертная оценка исходного кода в три шага.
-
Этап индивидуального исследования кода. Здесь эксперты изучают исходный код, созданный коллегами, и формируют перечень своих замечаний. Указывается характер проблем и присваивается предполагаемый уровень важности.
-
Этап командного исследования кода. Эксперты проводят совещание, где обсуждают, что делать с каждой из выявленных в коде проблем. Обычно часть комментариев признается несущественными или обоснованными. Другие замечания считаются допустимыми, но не требуют немедленных исправлений. Оставшиеся являются справедливыми и должны быть немедленно обработаны. Для них назначаются конкретные исполнители (участники команды), ответственные за переработку кода.
-
Этап модификации кода для устранения проблем. Каждый участник команды сосредоточен на решении проблем, назначенных ему по результатам коллективного совещания.
Применение метода экспертной оценки исходного кода предоставляет возможность обнаруживать проблемы самого разного характера. В том числе, это могут быть логические ошибки, проблемы оптимизации или совместимости кода, нарушения стандартов кодирования и т.д.
Модульное тестирование
Подавляющее число разработчиков понимают и принимают тот факт, что непосредственное написание кода - это самая простая составляющая их работы. В действительности же заставляет прилагать максимум усилий и доставляет массу неприятностей - последующая борьба с ошибками в уже написанном программном коде.
При этом, причины всех таких ошибок могут быть самыми разными, включая случайные опечатки, ошибки при невнимательной и спешной работе или сбои программ при непредсказуемых условиях.
Для установления причин возникновения большинства ошибок в коде разработчики пользуются отладчиками. Но, до того как исправить ошибку, сначала еще нужно ее обнаружить.
Здесь очень важно понимать, что ошибки, которые будут обнаружены самим разработчиком еще до начала тестирования и уж тем более эксплуатации, обойдутся гораздо дешевле. Вот почему команды разработчиков должны ставить перед собой цель находить и исправлять ошибки на как можно более ранних этапах цикла разработки.
В настоящее время все больше команд разработчиков признают, что внедрение модульного тестирования (unit testing) является весьма эффективным способом для тестирования программных приложений, именно на ранних стадиях развития проекта [5].
Модульные тесты по своей сути направлены на конкретные функции языка кодирования, вызывая их с различными комбинациями значений входных параметров, что приводит к различным путям исполнения кода тестируемых функций.
Существует широкий спектр специализированных инструментов модульного тестирования, подходящих для самых разных языков кодирования. Они автоматизируют процесс создания модульных тестов, внедряют их в исследуемые приложения и позволяют запускать их в режиме отладки.
Как следствие, применение подобных инструментов приводит к максимальной производительности и оптимальному использованию рабочего времени.
А иногда даже используется и еще более прогрессивный подход. Некоторые среды разработки (IDE) поддерживают непосредственное интегрирование средств автоматизации модульного тестирования. Это позволяет всегда поддерживать синхронизацию постоянно меняющегося исходного программного кода и предназначенных для него модульных тестов.
В любом случае, после того как модульные тесты сгенерированы, они помещаются в исходный код, компилируются и запускаются на исполнение в режиме отладки.
Далее осуществляется обработка всех имеющихся тестов, анализ результатов прохождения тестов, а также измерение достигнутого покрытия кода для оценки качества выполненной работы.
Анализ тестового покрытия кода
Во время тестирования программных приложений выявляется целое множество самых разнообразных ошибок. Но для получения уверенности в том, что тестирование действительно привело к повышению качества программного обеспечения, нужно также понимать и оценивать качество самих проведенных тестовых процедур.
А это значит, что после завершения стадий разработки и тестирования кода, стоит уделить внимание проведению количественной оценки объема и качества работ, выполненных во время тестирования на самом деле.
Принципиально важным является вопрос, насколько полно исходный код приложения покрыт имеющимися тестами? Ведь польза от достижения 100% успеха прохождения тестов будет не так уж велика, если эти тесты покрывают лишь незначительную часть кода, в то время как большая его часть остается совершенно не охваченной тестированием и потенциально содержит множество не обнаруженных (и, как следствие, не исправленных) ошибок.
Одним из хороших способов измерения качества тестов является анализ тестового покрытия исходного кода программных приложений.
Данную оценку можно уверенно считать прямым показателем качества тестирования, поскольку она помогает ясно понять, какие части кода были протестированы, а какие остались без внимания [6].
Все методы анализа тестового покрытия можно классифицировать на относительно примитивные и более строгие по требованиям к качеству покрытия.
-
Покрытие по выражениям или блокам кода
Метод позволяет определить, какое количество выражений языка или блоков кода было исполнено за время данного сеанса тестирования. Это наименее строгий вид оценки, поскольку он не учитывает дополнительные обстоятельства обработки кода, и для полноценного обеспечения приемлемого качества тестирования одно только его применение не будет достаточным.
-
Покрытие функций кода
Метод позволяет оценить, какие именно функции были вызваны за время данного сеанса тестирования, и какую часть от общего числа функций, содержащихся во всем коде, они составляют. При этом, нет возможности оценивать качество тестирования самих этих функций. Соответственно, метод достаточно прост и удобен, но все же не относится к числу строгих и не подходит для тестирования приложений с высоким уровнем критичности.
-
Покрытие вызовов функций
В отличие от предыдущего, этот метод дает возможность оценивать, какие вызовы функций были фактически выполнены во время тестирования, а также понять, каким образом эти вызовы осуществлялись.
Конечно же, не стоит причислять этот вид анализа покрытия кода к числу наиболее прогрессивных. Тем не менее, он является достаточно хорошим средством оценки количества выполненных вызовов функций.
-
Покрытие ветвей кода
Метод позволяет оценить, все ли ветви кода были пройдены в процессе тестирования. Наибольшее покрытие обеспечивается, если при обходе всех альтернативных ветвей выполняются и все используемые в них блоки кода.
Это наиболее строгий вид оценки, и применяется он для тех приложений, в которых необходимо обеспечить достаточно высокий уровень надежности.
Разумеется, более строгие методы анализа покрытия подразумевают применения больших усилий и проведения большего количества тестов, но именно за счет этого можно выявлять и больше ошибок и потенциальных проблем в коде. А своевременное обнаружение и устранение дефектов значительно повышает качество готовых программных приложений, выпускаемых на рынок и предоставляемых конечным пользователям.
Заключение
По роду своей профессиональной деятельности и в силу бесконечной любознательности, автор находится в постоянном поиске подобных возможностей повышения качества разработки программных приложений. А значит, могут найтись и другие способы, и, соответственно, приведенный здесь перечень может быть дополнен.
Тем не менее, внедрение таких способов не требует значительных материальных и трудозатрат, и в то же время, делает работу легче и удобнее, позволяет создавать и поддерживать код на порядок более высокого качества, существенно уменьшать время, усилия и затраты на дополнительную отладку и, конечно, предоставлять потребителям всегда только исправные и надежные продукты.
Литература
[1] Анна Сергеева. Гибкие методологии разработки современных программных приложений // Системный администратор. 2015. № 1-2.
[2] Анна Сергеева. Инструменты тестировщика или с чего начать новичку // Системный администратор. 2014. № 7-8.
[3] Анна Сергеева. Возможности статического анализатора Atollic TrueINSPECTOR для повышения качества встраиваемых приложений // Компоненты и технологии. 2015. № 4.
[4] Анна Сергеева. Возможности Atollic TrueSTUDIO для повышения качества разработки и отладки встраиваемых систем на базе ARM // Компоненты и технологии. 2015. № 6.
[5] Анна Сергеева. Автоматизация модульного тестирования с Atollic TrueVERIFIER для повышения качества встраиваемых приложений // Компоненты и технологии. 2015. № 5
[6] Анна Сергеева. Измерение качества тестирования встраиваемых приложений с Atollic TrueANALYZER // Компоненты и технологии. 2015. № 7.
Ключевые слова
Тестирование, повышение качества разработки ПО, стандарт кодирования, стиль программирования, анализ сложности кода, метрики исходного кода, сложность кода, уровень комментирования, экспертная оценка кода, анализ тестового покрытия.