- •"Управление качеством разработки программного обеспечения" Содержание
- •1. Введение
- •2. Основные определения
- •3. Процесс разработки программного обеспечения.
- •3.1 Жизненный цикл программного обеспечения.
- •3.2 Модели жизненного цикла программного обеспечения.
- •3.2.1 Каскадная модель (1970, w.W. Royce)
- •3.2.2. Инкрементная модель жизненного цикла разработки программного обеспечения
- •3.2.3 Итерационная модель
- •3.2.4 Спиральная модель (Бари Боэм, 1988.)
- •3.2.6 Модель быстрого прототипирования
- •3.2.7 Agileметодологии
- •Преимущества непрерывной интеграции:
- •Недостатки непрерывной интеграции:
- •3.2.7.3 Гибкая разработка - scrum(Ken Schwaber & Jeff Sutherland, 1996)
- •Планирование спринта, митинг первый
- •Планирование спринта, митинг второй
- •Остановка спринта (Sprint Abnormal Termination).
- •Демо и ревью спринта.
- •3.2.8 Подгонка модели жизненного цикла разработки.
- •4 Качество программных продуктов.
- •4.1 Определение качества. Стандарты качества.
- •Методы контроля качества
- •4.2 Стоимость качества.
- •4.3 Введение в cmmi
- •4.4. Управление требованиями
- •Способы описания требований и анализ требований.
- •Виды требований по уровням
- •Виды требований по характеру
- •Типы документов требований
- •5. Тестирование программного обеспечения.
- •5.1. Цели и задачи. Основные определения.
- •5.1.1 Методологии тестирования
- •5.1.2 Уровни тестирования
- •5.2 Процесс тестирования.
- •5.2.3 Планирование тестирования.
- •Кто будет тестировать?
- •Что нужно тестировать?
- •В каком объеме тестировать?
- •Виды тест планов
- •Оценка качества тестов
- •Тестовые метрики
- •5.2.4. Автоматизация тестирования
- •Упрощение интеграции
- •Документирование кода
- •Отделение интерфейса от реализации
- •Ограничения
- •Приложения модульного тестирования
- •5.3. Дефекты. Причины, описания, отслеживание.
- •***Этимология
- •Жизненный цикл дефекта
- •Примеры систем отслеживания ошибок
- •5.4. Типы дефектов и статические методы тестирования (Майерс)
- •5.5 Техники создания тест-кейсов.
- •5.5.1 Проектирование и исполнение.
- •5.5.2 Техники создания тест-кейсов: методология «черного ящика»
- •Свойства правильно выбранного теста
- •Техники стратегии чёрного ящика
- •Эквивалентное разбиение
- •Анализ граничных значений
- •Анализ причинно-следственных связей
- •Предположение об ошибке
- •5.5.3 Техники создания тест-кейсов: методология «белого ящика».
- •Структура rup
- •Продукты, поддерживающие rup
- •Артефакты и роли
- •Введение в uml
- •Принципы моделирования
- •Сущности в uml
- •Отношения в uml
- •Виды диаграмм uml
- •Автоматизированное тестирование
- •Обработка требований на ошибки
- •Приемка
- •Приемосдаточные испытания
- •Регрессионное тестирование
- •Система отслеживания ошибок
- •Тестирование
Упрощение интеграции
Модульное тестирование помогает устранить сомнения по поводу отдельных модулей и может быть использовано для подхода к тестированию «снизу вверх»: сначала тестируются отдельные части программы, затем программа в целом.
Документирование кода
Модульные тесты можно рассматривать как «живой документ» для тестируемого класса. Клиенты, которые не знают, как использовать данный класс, могут использовать юнит-тест в качестве примера.
Отделение интерфейса от реализации
Поскольку некоторые классы могут использовать другие классы, тестирование отдельного класса часто распространяется на связанные с ним. Например, класс пользуется базой данных; в ходе написания теста программист обнаруживает, что тесту приходится взаимодействовать с базой. Это ошибка, поскольку тест не должен выходить за границу класса. В результате разработчик абстрагируется от соединения с базой данных и реализует этот интерфейс, используя свой собственный mock-объект. Это приводит к менее связанному коду, минимизируя зависимости в системе.
Ограничения
Как и любая технология тестирования, модульное тестирование не позволяет отловить все ошибки программы. В самом деле, это следует из практической невозможности трассировки всех возможных путей выполнения программы, за исключением простейших случаев. Кроме того, происходит тестирование каждого из модулей по отдельности. Это означает, что ошибки интеграции, системного уровня, функций, исполняемых в нескольких модулях не будут определены. Кроме того, данная технология бесполезна для проведения тестов на производительность. Таким образом, модульное тестирование более эффективно при использовании в сочетании с другими методиками тестирования.
Тестирование программного обеспечения — комбинаторная задача. Например, каждое возможное значение булевской переменной потребует двух тестов: один на вариант TRUE, другой — на вариант FALSE. В результате на каждую строку исходного кода потребуется 3-5 строк тестового кода.
Для получения выгоды от модульного тестирования требуется строго следовать технологии тестирования во всём процессе разработки программного обеспечения. Нужно хранить не только записи обо всех проведённых тестах, но и обо всех изменениях исходного кода во всех модулях. С этой целью следует использовать систему контроля версий ПО. Таким образом, если более поздняя версия ПО не проходит тест, который был успешно пройден ранее, будет несложным сверить исходный код вариантов и устранить ошибку. Также необходимо убедиться в неизменном отслеживании и анализе неудачных тестов. Игнорирование этого требования приведёт к лавинообразному увеличению неудачных тестовых результатов.
Приложения модульного тестирования
Экстремальное программирование предполагает как один из постулатов использование инструментов автоматического модульного тестирования. Этот инструментарий может быть либо созданным третьей стороной (например, Boost.Test), либо быть создан группой разработчиков данного приложения.
В экстремальном программировании используются модульные тесты для разработки через тестирование. Для этого разработчик до написания кода пишет тесты, отражающие требования к модулю. Очевидно, ни один из этих тестов до написания кода работать не должен. Дальнейший процесс сводится к написанию кратчайшего кода, удовлетворяющего данному набору тестов.
Разработка через тестирование (test-driven development) — техника программирования, при которой модульные тесты для программы или её фрагмента пишутся до самой программы (test-first development) и, по существу, управляют её разработкой. Является одной из основных практик экстремального программирования.
Разработка в стиле TDD состоит из коротких циклов (длительностью от 2 минут, в зависимости от опытности и стиля работы программиста). Каждый цикл состоит из следующих шагов:
Из репозитория извлекается программная система, находящаяся в согласованном состоянии, когда весь набор модульных тестов выполняется успешно.
Добавляется новый тест. Он может состоять в проверке, реализует ли система некоторое новое поведение или содержит ли некоторую ошибку, о которой недавно стало известно.
Успешно выполняется весь набор тестов, кроме нового теста, который выполняется неуспешно. Этот шаг необходим для проверки самого теста — включён ли он в общую систему тестирования и правильно ли отражает новое требование к системе, которому она, естественно, еще не удовлетворяет.
Программа изменяется с тем, чтобы как можно скореевыполнялись все тесты. Нужно добавить самое простое решение, удовлетворяющее новому тесту, и одновременно с этим не испортить существующие тесты. Большая часть нежелательных побочных и отдалённых эффектов от вносимых в программу изменений отслеживается именно на этом этапе, с помощью достаточно полного набора тестов.
Весь набор тестов выполняется успешно.
Теперь, когда требуемая в этом цикле функциональность достигнута самым простым способом, программа перестраивается (рефакторинг) для улучшения структуры и устранения избыточного, дублированного кода.
Весь набор тестов выполняется успешно.
Комплект изменений, сделанных в этом цикле в тестах и программе заносится в репозиторий (операция commit), после чего программа снова находится в согласованном состоянии и содержит четко осязаемое улучшение по сравнению с предыдущим состоянием.
Этот цикл упрощенно описывается Кентом Беком в своей книге как «красный-зеленый-рефакторинг». Красный и зеленый — это цвета полоски в среде тестирования JUnit, которая показывает, все тесты сработали или нет. При этом на первом («красном») этапе необходимо добиться того, чтобы программа просто компилировалась, без срабатывания добавленного теста.
Для большинства популярных языков программирования высокого уровня существуют инструменты и библиотеки модульного тестирования. Некоторые из них:
Для Java
JUnit JUnit.org
TestNG testNG.org
JavaTESK UniTESK.ru
NUnit— для языков платформы .NET: C#, Visual Basic .NET и др.
Для C
CTESK UniTESK.ru
cfix cfix
Для C++
CPPUnit
Boost Test
Google C++ Testing
Symbian— фреймворк для Symbian OS всех версий.
DUnit— для Delphi
Для Perl
Test
Test::Simple
Test::Unit
Test::Unit::Lite
Для PHP
SimpleTest
PHPUnit
Для Python
PyUnit
PyTest
Nose
vbUnit— Visual Basic
utPLSQL— PL/SQL
Для T-SQL
TSQLUnit
SPUnit
Для ActionScript 2.0 — язык сценариев, используемый виртуальной машиной Adobe Flash Player версии 7 и 8
AsUnit
AS2Unit
Для ActionScript 3.0 — скриптовый язык, используемый виртуальной машиной Adobe Flash Player версии 9
FlexUnit
Test::Unit— для Ruby
AsUnit
JsUnit - для JavaScript