Добавлен: 07.11.2023
Просмотров: 81
Скачиваний: 5
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
-
проблемы интеграции выявляются и исправляются быстро, что оказывается дешевле; -
немедленный прогон модульных тестов для свежих изменений; -
постоянное наличие текущей стабильной версии вместе с продуктами сборок — для тестирования, демонстрации, и т. п. -
немедленный эффект от неполного или неработающего кода приучает разработчиков к работе в итеративном режиме с более коротким циклом.
-
Недостатки
-
затраты на поддержку работы непрерывной интеграции; -
потенциальная необходимость в выделенном сервере под нужды непрерывной интеграции; -
немедленный эффект от неполного или неработающего кода отучает разработчиков от выполнения периодических резервных включений кода в репозиторий. -
в случае использования системы управления версиями исходного кода с поддержкой ветвления, эта проблема может решаться созданием отдельной «ветки» (англ. branch) проекта для внесения крупных изменений (код, разработка которого до работоспособного варианта займет несколько дней, но желательно более частое резервное копирование в репозиторий). По окончании разработки и индивидуального тестирования такой ветки, она может быть объединена (англ. merge) с основным кодом или «стволом» (англ. trunk) проекта.
-
Средства непрерывной интеграции
-
Bamboo (англ. Bamboo (software))
-
Hudson и Jenkins -
CruiseControl -
TeamCity -
BuildBot -
Travis CI
-
-
Покрытие кода тестами
9.1 Покрытие кода
Определения для общего понимания темы:
-
Тестовое покрытие (Test Coverage) – это одна из метрик оценки качества тестирования программного обеспечения. Представляет собой величину, выраженную в процентах, которая отображает степень плотности покрытия тестами функциональных требований или исполняемого кода.
Существует два основных подхода к оценке и измерению тестового покрытия: покрытие требований (можно соотнести с тестированием по методу черного ящика), покрытие кода (можно соотнести с тестированием по методу белого ящика).
-
Покрытие требований (Requirements Coverage) – оценка покрытия тестами функциональных и не функциональных требований к продукту путем построения матриц трассировки (traceability matrix);
-
Покрытие кода (Code Coverage) – оценка покрытия исполняемого кода тестами, путем отслеживания непроверенных в процессе тестирования частей программного обеспечения.
Покрытие кода является важной метрикой для обеспечения качества тестируемого приложения, особенно если речь о проектах со сложной логикой и большим объемом кода. Анализ покрытия кода выполняется с помощью специального инструментария, который позволяет проследить в какие строки, ветви и т.д. кода, были вхождения во время работы автотестов. Наиболее известные инструменты для проведения измерения покрытия кода: AQTime, Bounds Checker, Bullseye Coverage, Coverage Meter, Clover, NCover, IBM Rational PurifyPlus, Intel Compiler, Intel Code Coverage Tool Prototype, JetBrains. С помощью анализа покрытия кода можно оценить плотность покрытия авто-тестами исполняемого кода тестируемого приложения (можно ответить на вопрос “какой объем тестирования мы (наши автотесты) выполняем?”). При детальном анализе результатов покрытия кода автотестами можно оценить покрытие отдельных компонентов системы (т.е. можно ответить на вопросы: что и в каком объеме мы тестируем?, в каких местах нужно оптимизировать покрытие?, какие места системы не проверяются тестами? и т.д.). Таким образом, зная данную метрику, станет ясно для каких тестовых случаев нужно создать новые тесты, или убрать дублирующие тесты. Данные мероприятия помогут увеличить значение метрики Code Coverage, что в свою очередь должно повысить качество кода и качество тестируемого приложения в целом. Естественно, чем выше показатель данной метрики – тем лучше, однако уже хорошо если у вас покрыты тестами наиболее сложные и важные фрагменты кода.
Покрытие кода тестами - мера, показывающая, на сколько процентов исходный код программы был протестирован.
Техника покрытия кода была одной из первых методик, изобретённых для систематического тестирования программного обеспечения.
Первое упоминание покрытия кода в публикациях появилось в 1963 году. Существует несколько различных способов измерения покрытия, основными из них являются:
-
Покрытие операторов - каждая ли строка исходного кода была выполнена и протестирована? -
Покрытие условий - каждая ли точка решения (вычисления истинно ли или ложно выражение) была выполнена и протестирована? -
Покрытие путей - все ли возможные пути через заданную часть кода были выполнены и протестированы? -
Покрытие функций - каждая ли функция программы была выполнена? -
Покрытие вход/выход - все ли вызовы функций и возвраты из них были выполнены? -
Покрытие комбинаций – проверка всех возможных комбинаций результатов условий.
При оценке покрытия кода тестируемого ПО собирается со специальными настройками или библиотеками и запускается в особом окружении, в результате чего для каждой выполняемой функции программы определяется местонахождение этой функции в исходном коде. Этот процесс позволяет разработчикам и специалистам по обеспечению качества определить части системы, которые при нормальной работе используются редко или никогда не используются (такие, как код обработки ошибок и т.п.). Тестировщики могут использовать результаты проверки покрытия для разработки дополнительных тестов или тестовых данных.
9.2 Практическое применение
Обычно исходный код снабжается тестами, которые регулярно выполняются. Полученный отчёт анализируется с целью выявить невыполнявшиеся области кода, набор тестов обновляется, пишутся тесты для непокрытых областей. Цель состоит в том, чтобы получить набор тестов для регрессионного тестирования, тщательно проверяющих весь исходный код.
Степень покрытия кода обычно выражают в виде процента. Например, «мы протестировали 67 % кода». Смысл этой фразы зависит от того какой критерий был использован. Например, 67 % покрытия путей — это лучший результат чем 67 % покрытия операторов. Вопрос о связи значения покрытия кода и качества тестового набора ещё до конца не решён.
Покрытие кода, по своей сути, является тестированием методом белого ящика. Тестируемое ПО собирается со специальными настройками или библиотеками и/или запускается в особом окружении, в результате чего для каждой используемой (выполняемой) функции программы определяется местонахождение этой функции в исходном коде. Этот процесс позволяет разработчикам и специалистам по обеспечению качества определить части системы, которые, при нормальной работе, используются очень редко или никогда не используются (такие как код обработки ошибок и т.п.). Это позволяет сориентировать тестировщиков на тестирование наиболее важных режимов.
Тестировщики могут использовать результаты теста покрытия кода для разработки тестов или тестовых данных, которые расширят покрытие кода на важные функции.
Как правило, инструменты и библиотеки, используемые для получения покрытия кода, требуют значительных затрат производительности и/или памяти, недопустимых при нормальном функционировании ПО. Поэтому они могут использоваться только в лабораторных условиях.
Литература
1) Анашкина Н.В., Петухова Н.Н., Смольянинов В.Ю. Технологии и методы программирования.
2) Кнут Д. Искусство программирования для ЭВМ
3) Соммервил И., Инженерия программного обеспечения. 6-е изд.
4) Орлов С.А., Технологии разработки программного обеспечения.
5) Брауде Эрик Дж., Технология разработки программного обеспечения.
6) Жоголев Е.А., Технология программирования.
7) Мейер Б., Бодуэн К. Методы программирования.
8) http://www.refu.ru/refs/67/14960/1.html
9) http://social.msdn.microsoft.com/Forums/ru-RU/e750a78b-0c1f-4766-81a2-7cea9b4b3ea2/-
10) http://sergiek.narod.ru/index/0-2
11) http://bibliofond.ru/view.aspx?id=553022
12) http://bugscatcher.net/archives/1103
Приложение 1
Т
Написать тест
ест
п
рошел
Написать код
Тест Один из тестов
н е прошел не прошел
В се тесты
завершились успешно
Почистить код
Приложение 2
Сравнение восходящего и нисходящего тестирования | |
Преимущества | Недостатки |
Нисходящее тестирование | |
1. Имеет преимущества, если ошибки, главным образом, в верхней части программы. | 1. Необходимо разрабатывать модули-заглушки, которые часто оказываются сложнее, чем кажется вначале. |
2. Раннее формирование структуры программы позволяет провести ее демонстрацию пользователю и служит моральным стимулом. | 2. Может оказаться трудным или невозможным создать тестовые условия. |
| 3. Сложнее оценка результатов тестирования. |
| 4. Стимулируется незавершение тестирования некоторых модулей. |
Восходящее тестирование | |
1. Имеет преимущества, если ошибки, главным образом, в модуле нижнего уровня. | 1. Программа как единое целое не существует до тех пор, пока не добавлен последний модуль. |
2. Легче создавать тестовые примеры. | |
3. Проще оценка результатов. | |