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

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

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

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

› Заказчик выполнил часть приложения, которая никогда не тестировалась. Неполное тестирование может быть преднамеренным из-за ограничений по времени или стоимости.

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

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

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

"Просто проверьте это"

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

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

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

Концепции покрытия

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

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

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

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

Не следует путать 3 различных использования термина «покрытие». Покрытие требований измеряет долю требований, которые были проверены тестами на основе требований. Покрытие структурным кодом измеряет долю кода, выполненного тестами. Покрытие тестами измеряет долю выполненных и пройденных тестов.

Соответствие стандартам

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

Стандарты программного обеспечения, критически важного для безопасности, такие как DO-178C и ISO26262, рекомендуют использовать покрытие требований, покрытие структурного кода и покрытие тестами. Правильное использование этих концепций также может помочь разработчикам за пределами критически важной для безопасности арены. Понимание терминов и их использования поможет создать более надежное и надежное приложение.

Ссылка на требования

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

Наблюдение за охватом кода

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

Различные метрики покрытия кода измеряют выполнение различных синтаксических конструкций в коде. Наиболее распространенные метрики покрытия кода:

›Точки входа в функцию / метод
› Вызов функции / метода (и их возврат)
›Строки (исполняемого кода)
› Операторы
›Базовые блоки (последовательных операторов)
› Решения
›Условия (логические операнды)
›Операторы отношения
› Циклы
›MC / DC (измененное условие / покрытие решений), как маскирование, так и формы уникальной причины

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

Результаты динамического теста

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

Ставьте цели

Постановка целей проекта на основе определенных показателей, таких как охват, дает несколько преимуществ для успеха проекта.

›Оптимизация использования ресурсов

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

›Сделайте встречи проекта более ясными

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

›Более простое измерение статуса проекта

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

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

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

› Не проверено на соответствие требованиям
› Не прошло все тесты
› Не было проверено любыми тестами

Что такое кантата?

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

Cantata предлагает комплексный инструмент тестирования программного обеспечения, который поддерживает измерение и достижение покрытия требований, покрытия структурного кода и покрытия тестами. Cantata можно приобрести в компании QA Systems и ее международной сети авторизованных реселлеров. Дополнительную информацию о продукте Cantata можно найти на веб-сайте QA Systems: https://www.qa-systems.com/tools/Cantata

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

Забрать

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

Если вы нашли эту вводную статью полезной, в QA-Systems есть подробная статья, которую можно загрузить бесплатно здесь . Это расширяет принципы, затронутые в этой короткой статье.

Загрузите 26-страничный технический документ в формате PDF

Вы также можете подписаться на информационный бюллетень QA-Systems…. Вы будете получать уведомления о другом полезном содержании разработки программного обеспечения прямо на свой почтовый ящик.