Какие показатели качества программные продукты
Ка́чество програ́ммного обеспечения — способность программного продукта при заданных условиях удовлетворять установленным или предполагаемым потребностям (ISO/IEC 25000:2014)[1].
Другие определения из стандартов:
- весь объём признаков и характеристик программ, который относится к их способности удовлетворять установленным или предполагаемым потребностям (ГОСТ Р ИСО/МЭК 9126-93, ISO 8402:94)[2][3];
- степень, в которой система, компонент или процесс удовлетворяют потребностям или ожиданиям заказчика или пользователя (IEEE Std 610.12-1990)[4].
Ранние подходы к определению[править | править код]
Том Демарко в 1999 году предлагал при оценке качества программного обеспечения учитывать, что «качество программного продукта является показателем того, насколько он меняет мир к лучшему»[5].
Джеральд Вайнберг в своей работе 1992 года Quality Software Management: Volume 1, Systems Thinking давал определение качества как «значимого для какого-либо человека»[6][7], подчеркивая тем самым, что понятие качества является по своей природе субъективным — разные люди будут оценивать качество одного и того же программного обеспечения по-разному. Одной из сильных сторон этого определения являются вопросы, на которые должны ответить команды разработчиков программного обеспечения, такие как «Кто те люди, которые будут оценивать наше программное обеспечение?» и «Что будет ценным для них?».
Модели качества[править | править код]
Стандарт ISO/IEC 25010:2011 (ГОСТ Р ИСО/МЭК 25010-2015)[8] определяет модель качества продукта, которая включает восемь характеристик верхнего уровня:
- функциональная пригодность;
- уровень производительности;
- совместимость;
- удобство использования (юзабилити);
- надёжность;
- защищённость;
- сопровождаемость;
- переносимость (мобильность).
В этом стандарте модель качества продукта (англ. software product quality model) рассматривается отдельно от субъективного качества в использовании, которое может сильно отличаться для различных стейкхолдеров[9]. Модель качества в использовании (англ. quality in use model) включает следующие характеристики верхнего уровня[8]:
- результативность;
- производительность;
- удовлетворённость;
- свобода от риска;
- покрытие контекста.
Роберт Гласс в известной книге «Факты и заблуждения профессионального программирования» утверждает, что большинство профессиональных разработчиков согласны с выделением семи показателей качества как основных[10]:
- переносимость;
- надёжность;
- эффективность;
- удобство использования (юзабилити);
- тестируемость[en];
- понятность;
- модифицируемость.
Среди относительно новых моделей качества программного обеспечения можно упомянуть SQUALE и Quamoco[11], которые были применены в промышленных условиях, но пока не получили широкого распространения.
См. также[править | править код]
- Управление качеством
- Тестирование программного обеспечения
- Метрика программного обеспечения
- Технический долг
Примечания[править | править код]
- ↑ Software quality — capability of software product to satisfy stated and implied needs when used under specified conditions: ISO/IEC 25000:2014(en) Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — Guide to SQuaRE
- ↑ ГОСТ Р ИСО/МЭК 9126-93. Оценка программной продукции. Характеристики качества и руководства по их применению
- ↑ ISO 8402:94. Управление качеством и обеспечение качества. Словарь
- ↑ The degree to which a system, component, or process meets customer or user needs or expectations: IEEE Std 610.12-1990. IEEE Standard Glossary of Software Engineering Terminology
- ↑ DeMarco, T., Management Can Make Quality (Im)possible, Cutter IT Summit, Boston, April 1999
- ↑ Weinberg, Gerald M. (1992), Quality Software Management: Volume 1, Systems Thinking, New York, NY: Dorset House Publishing, с. 7
- ↑ Weinberg, Gerald M. (1993), Quality Software Management: Volume 2, First-Order Measurement, New York, NY: Dorset House Publishing, с. 108
- ↑ 1 2 ISO/IEC 25010:2011 Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — System and software quality models
ГОСТ Р ИСО/МЭК 25010-2015 Информационные технологии. Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модели качества систем и программных продуктов - ↑ Wijnholds, et al, 2016.
- ↑ Роберт Гласс. Факты и заблуждения профессионального программирования. = Facts and Fallacies of Software Engineering. — 2004. — ISBN 5-93286-092-8; 978-5-93286-092-2.
- ↑ Wagner, Stefan; Goeb, Andreas; Heinemann, Lars; Kläs, Michael; Lampasona, Constanza; Lochmann, Klaus; Mayr, Alois; Plösch, Reinhold; Seidl, Andreas. Operationalised product quality models and assessment: The Quamoco approach (англ.) // Information and Software Technology (англ.)русск. : journal. — 2015. — Vol. 62. — P. 101—123. — doi:10.1016/j.infsof.2015.02.009.
Литература[править | править код]
- ГОСТ 28195-89 — Оценка качества программных средств
- Gijs Wijnholds, Zeeger Lubsen, Sylvan Rigal, Joost Visser. Building Software Teams. — O’Reilly Media, Inc., 2016.
Ссылки[править | править код]
- OpenQuality.ru | Качество программного обеспечения
Источник
22.1. Общие положения
| № | Признак | Описание |
|---|---|---|
| 1 | Описание КИС | Критерии, с помощью которых осуществляется оценка непосредственно самой КИС |
| 1.1 | Структура | Критерии оценки структуры КИС |
| 1.2 | Функционал | Критерии оценки функциональных возможностей КИС |
| 1.3 | Принципы | Критерии оценки принципов построения КИС |
| 1.4 | Технические требования | Критерии оценки технических требований функционирования КИС |
| 1.5 | Архитектура | Критерии оценки особенностей архитектуры заложенной при создании КИС |
| 1.6 | Стоимость | Критерии оценки стоимостных параметров КИС |
| 1.7 | Интеграция | Критерии оценки внутренней и внешней интеграции КИС |
| 1.8 | Бизнес-логика | Критерии оценки реализации бизнес-логики, заложенной в КИС |
| 1.9 | Элементы КИС | Критерии оценки элементов КИС |
| 2 | Описание фирмы-разработчика и ее партнеров | Критерии оценки фирмы-разработчика КИС и фирм-партнеров по продвижению и внедрению данной КИС |
| 2.1 | Технологии | Критерии оценки технологий, подходов, методов, применяемых фирмами-внедренцами в процессе внедрения КИС |
| 2.2 | Опыт | Критерии оценки опыта успешных и неудачных проектов фирм-внедренцев |
| 2.3 | Специалисты | Критерии оценки квалификационного уровня специалистов фирм-внедренцев |
| 3 | Принципиальность | Отношение критериев выбора КИС к соответствующим этапам выбора КИС |
| 3.1 | Принципиальные | Критерии, которые должны быть оценены в первую очередь и, которые определяют основные принципы выбираемой КИС |
| 3.2 | Не принципиальные | Критерии, которые не являются сильно принципиальными при выборе КИС |
| 4 | По степени детализации | На сколько критерий конкретно описывает исследуемый объект |
| 4.1 | Общие | Критерии, описывающие объект исследования в общем виде |
| 4.2 | Конкретные | Критерии, конкретно описывающие объект исследования |
| 5 | По сложности оценки | Доступность и достоверность информации для самостоятельной оценки |
| 5.1 | Сложный | Возможность самостоятельного получения полной и достоверной информации по данному критерию очень мала |
| 5.2 | Средней сложности | Возможно самостоятельное получение полной и достоверной информации |
| 5.3 | Легкий | Возможно самостоятельное получение полной и достоверной информации. Информация в общедоступных источниках |
| 6 | По типу значения | В зависимости от типа значения критерия: возможность количественного измерения значения, либо качественный показатель |
| 6.1 | Количественный | Критерии, значения которых могут быть определены в виде конкретных числовых показателей |
| 6.2 | Качественный | Критерии, значения которых не могут быть определены в виде конкретных числовых показателей |
| 7 | По важности для потенциальных пользователей | Описывают степень важности того или иного критерия выбор а КИС для потенциальных пользователей |
| 7.1 | Высший приоритет | Критерии, имеющие наибольшую значимость для пользователя |
| 7.2 | Средний приоритет | Критерии, имеющие среднюю значимость для пользователя |
| 7.3 | Низший приоритет | Критерии, имеющие низшую значимость для пользователя |
Группы критериев оценки программных продуктов:
- назначение и возможности пакета (область использования, степень обеспечения функций, общего назначения или специализированный);
- отличительные признаки и свойства пакета (входной язык, структура массивов данных, способы проверки данных);
- требования к техническим и программным средствам (объем ОП, периферийные устройства, тип ОС);
- документация пакета (наличие руководства по использованию, руководства программиста, руководства системного программиста);
- факторы финансового порядка (затраты на приобретение, необходимость ежегодных платежей);
- особенности установки пакета (объем работ, время установки, требования к квалификации программистов);
- особенности эксплуатации пакета (надежность, защита данных, возможность эксплуатации силами предприятия);
- помощь поставщика по внедрению и поддержанию пакета (обучение персонала, внесение модификаций, обновление версий);
- оценка качества пакета и опыт его использования (число внедрений пакета, оценки пользователей, номер версии);
- перспективы развития пакета (совместимость версий, дополнение функциональных возможностей, развитие методов).
22.2. Пример оценки программного продукта
Для выбора программного продукта, наилучшим образом удовлетворяющего потребности Предприятия, консультанты провели анализ программных продуктов в соответствии с системой требований.
При этом использовались методики оценки, приведенные ниже в настоящем разделе.
22.2.1. Оценка существующей функциональности программного продукта
При анализе тиражируемых программных продуктов, предполагаемых к внедрению как основы ИСУ Предприятия, функциональные возможности программных продуктов оценивались по степени их соответствия разработанным требованиям по десятибалльной шкале.
При оценке применяется следующая шкала баллов:
| – функция отсутствует в имеющейся конфигурации; | |
| 2 | – функция реализована частично, для ее реализации необходима серьезная доработка программного кода при настройке/внедрении; |
| 4 | – функция реализована частично, для ее реализации необходима незначительная доработка программного кода при настройке/внедрении; |
| 6 | – функция реализована удовлетворительно, требуется адаптация под нужды Предприятия в процессе настройки/внедрения средствами ИСУ; |
| 8 | – функция реализована хорошо, однако в перспективе могут понадобиться ее доработки; |
| 10 | – функция реализована полностью, удовлетворяет требованиям (в том числе – на перспективу). |
Оценки “по умолчанию” выстроены по шкале четности, при заполнении теста могут применяться нечетные оценки в случае, если ответ находится на грани двух смежных четных оценок.
22.2.2. Оценка прочих аспектов
Оценка соответствия прочих аспектов тиражируемых программных продуктов и Поставщиков разработанным требованиям производится также по десятибалльной шкале. Количество баллов определяет степень соответствия программного продукта рассматриваемому требованию.
22.2.3. Система весовых коэффициентов
Для получения интегральной оценки программных продуктов и поставщиков введены весовые коэффициенты для определения значимости тех или иных критериев для Предприятия.
Используется следующая система весовых коэффициентов:
| 1 – реализация функции в ИСУ имеет низкую важность1; |
| 2 – реализация функции важна в ИСУ; |
| 3 – реализация функции в ИСУ критически важна для Предприятия. |
Предпочтение должно отдаваться программным продуктам, имеющим наибольший рейтинг (суммарную оценку с учетом весовых коэффициентов).
22.3. Основные выводы по результатам анализа программных продуктов
В соответствии с Техническим заданием консультантами были проанализированы следующие программные продукты:
- “Рос-1” версия 5.8;
- “Рос-2” версия 2.3.3;
- “”Рос-3″:Предприятие” версия 7.0;
- “Зап-1”;
- “Зап-2” версия 2.6.
Основные результаты анализа приведены в следующей таблице.
| № | Наименование критерия | “Рос-1” | “Рос-2” | “Рос-3” | “Зап-1” | “Зап-2” | Макс. балл |
|---|---|---|---|---|---|---|---|
| Общесистемные функциональные требования | 1 105 | 1 056 | 1 128 | 951 | 1 126 | 1 680 | |
| Функциональные требования по подсистемам управления | 5 452 | 3 431 | 3 334 | 3 486 | 3 385 | 8 310 | |
| 1. | Маркетинг | 400 | 146 | 262 | 112 | 110 | 610 |
| 2. | Сбыт | 328 | 284 | 262 | 300 | 300 | 420 |
| 3. | Производство | 1 410 | 684 | 420 | 810 | 918 | 2 070 |
| 4. | Снабжение | 327 | 183 | 210 | 372 | 381 | 720 |
| 5. | Управление складами | 222 | 174 | 72 | 222 | 186 | 300 |
| 6. | Управление персоналом | 555 | 402 | 552 | 90 | 24 | 900 |
| 7. | Управление транспортом | 168 | 18 | 114 | 24 | 210 | |
| 8. | Управление строительством | 36 | 36 | 24 | 12 | 18 | 120 |
| 9. | Взаиморасчеты | 490 | 340 | 278 | 406 | 342 | 660 |
| 10. | Финансы | 524 | 438 | 286 | 420 | 396 | 940 |
| 11. | Управление себестоимостью | 138 | 102 | 96 | 78 | 84 | 210 |
| 12. | Бухгалтерский и налоговый учет | 854 | 624 | 758 | 640 | 626 | 1 150 |
| Прочие требования | 564 | 460 | 525 | 362 | 434 | 730 | |
| Итого: | 7 121 | 4 947 | 4 987 | 4 799 | 4 945 | 10 720 | |
Анализ программных продуктов проведен в соответствии с описанной выше методикой.
В ходе анализа консультанты исходили из того, что наиболее важными для Предприятия являются те функции программных продуктов, которые дают Предприятию следующие возможности:
- планирование и контроль фактического выполнения работ (входит в подсистему управления “Производство” в табл. 22.2);
- управление движением товарно-материальных ценностей (подсистемы “Снабжение” и “Управление складами”);
- планирование и контроль финансовых потоков, контроль задолженностей и взаиморасчетов (подсистемы управления “Финансы” и “Взаиморасчеты”);
- бухгалтерский и налоговый учет (подсистема управления “Бухгалтерский и налоговый учет”);
- управление персоналом, включая кадровый учет и расчет заработной платы (подсистема “Управление персоналом”).
Анализ указанных выше программных продуктов показал следующее.
Из рассмотренных консультантами программных продуктов наилучшими функциональными характеристиками обладает система “Рос-1”. Основные причины этого следующие:
- только два программных продукта (“Рос-1” и “Зап-2”) обладают возможностями планирования и контроля фактического исполнения работ (подсистема “Производство”);
- по подсистеме “Снабжение” наилучшей функциональностью обладают программные продукты “Рос-1”, “Зап-1” и “Зап-2”;
- по подсистеме “Управление складами” лучше всего удовлетворяют выдвинутым требованиям программные продукты “Рос-1” и “Зап-1”;
- в подсистеме “Управление персоналом” наиболее развитую функциональность имеют программные продукты “Рос-1”, “Рос-2” и “Рос-3”;
- в подсистемах “Финансы”, “Взаиморасчеты” и “Бухгалтерский и налоговый учет” функциональные возможности “Рос-1” заметно шире, чем у других программных продуктов.
Таким образом, с точки зрения функциональности наиболее приемлемым программным продуктом для Предприятия является система “Рос-1”.
Источник
Аннотация: Рассматриваются характеристики качества программных продуктов. Отмечается, что вопросы качества должны решаться на протяжении всего жизненного цикла. Показано, тестирование программного продукта позволяет гарантировать заданные параметры качества. Рассматриваются различные типы тестов и инструментарий тестирования в VisualStudio 2012. Показано, что рефакторинг кода улучшает качество программного продукта.
Презентацию к данной лекции Вы можете скачать здесь.
Цель лекции:
Получить представление о способах и инструментарии обеспечения качества программных продуктов.
Введение
Качество программного продукта определяется по нескольким критериям. Качественный программный продукт должен отвечать функциональным и нефункциональным требованиям, в соответствии с которыми он создавался, иметь ценность для бизнеса, отвечать ожиданиям пользователей [37].
В жизненном цикле управления приложениями качество должно отслеживаться на всех этапах жизненного цикла ПО. Оно начинает формироваться с определения необходимых требований. При задании требований необходимо указывать желаемую функциональность и способы проверки её достижения.
Качественный программный продукт должен обладать высоким потребительским качеством, независимо от области применения: внутреннее использование разработчиком, бизнес, наука и образование, медицина, коммерческие продажи, социальная сфера, развлечения, веб и др. Для пользователя программный продукт должен удовлетворять определенному уровню его потребностей.
Важным аспектом создания качественного ПО является обеспечение нефункциональных требований, таких как удобство в эксплуатации, надежность, производительность, защищенность, удобство сопровождения. Надежность ПО определяет способность без сбоев выполнять заданные функции в заданных условиях и в течение заданного отрезка времени. Производительность характеризуется временем выполнения заданных транзакций или длительных операций. Защищенность определяет степень безопасности системы от повреждений, утраты, несанкционированного доступа и преступной деятельности. Удобство сопровождения определяет легкость, с которой обслуживается продукт в плане простоты исправления дефектов, внесения корректив для соответствия новым требованиям, управления измененной средой.
Управление жизненным циклом программного продукта помогает разработчикам целенаправленно добиваться создания качественного ПО, избегать потерь времени на переделку, повторное проектирования и перепрограммирование ПО.
Тестирование программного обеспечения
Тестирование программного продукта позволяет на протяжении всего жизненного цикла ПО гарантировать, что программные проекты отвечают заданным параметрам качества. Главная цель тестирования – определить отклонения в реализации функциональных требований, обнаружить ошибки в выполнении программ и исправить их как можно раньше в процессе выполнения проекта.
На протяжении всего жизненного цикла разработки ПО применяются различные типы тестирования для гарантии того, что промежуточные версии отвечают заданным показателям качества. При этом применяются автоматические и ручные тесты.
| Модульное тестирование | предназначено для проверки правильности функционирования методов классов ПО. Модульные тесты пишутся и исполняются разработчиками в процессе написания кода. Модульное тестирование применяется как для проверки качества кода приложения, так и для проверки объектов баз данных. |
| Исследовательское тестирование | предназначено для тестирования, при котором тестировщик не имеет заранее определенных тестовых сценариев и пытается интуитивно исследовать возможности программного продукта и обнаружить и зафиксировать неизвестные ошибки. |
| Интеграционное тестирование | используется для проверки корректности совместной работы компонентов программного продукта. |
| Функциональное тестирование | предполагает проверку конкретных требований к ПО и проводится после добавление к системе новых функций. |
| Нагрузочное тестирование | предназначено для проверки работоспособности программного продукта при предельной входной нагрузке. |
| Регрессионное тестирование | применяется при внесении изменений в программное обеспечение с целью проверки корректности работы компонентов системы, которые потенциально могут взаимодействовать с измененным компонентом. |
| Комплексное тестирование | предназначено для тестирования функциональных и нефункциональных требований всей системы программного продукта. |
| Приемочное тестирование | представляет собой функциональные испытания, которые должны подтвердить то, что программный продукт соответствует требованиям и ожиданиям пользователей и заказчиков. Приемочные тесты пишутся бизнес-аналитиками, специалистами по контролю качества и тестировщиками. |
Для разработчика программного обеспечения в VisualStudio 2012 предоставлена возможность создавать модульные и нагрузочные тесты, а также тесты пользовательского интерфейса. В VisualStudio 2012 имеются следующие шаблоны тестовых проектов[38]:
- проект модульного теста, который позволяет создавать модульные тесты в процессе разработки;
- проект с веб-тестами производительности и нагрузочными тестами;
- проект с закодированными тестами пользовательского интерфейса.
Инструментарием тестировщика в VisualStudio 2012 является MicrosoftTestManager (MTM). MTM предназначен для управления жизненным циклом тестирования программного обеспечения, включая планирование, тестирование и мониторинг. MTM интегрирован с TeamFoundationServer. С помощью Microsoft TestManager тестировщики подготавливают планы тестирования, управляют тестированием. При создании плана тестирования в него добавляются наборы тестов, тестовые случаи и конфигурации, необходимые для тестирования. Конфигурации используются для установления среды, в которой будут исполняться наборы тестов. Microsoft TestManager позволяет выполнять ручные и автоматические тесты, а также исследовательские тесты. Результаты тестирования сохраняются в базе данных, что позволяет подготавливать различные аналитические отчеты. Ошибки, выявленные в процессе тестирования, фиксируются, документируются и передаются разработчикам для их устранения.
При внесении изменений в код программной системы возникает необходимость в регрессионном тестировании, причем MTM автоматически формирует план регрессионного тестирования, выявляя какие тесты должны быть повторно выполнены.
Для тестировщиков и разработчиков программного обеспечения VisualStudio 2012 включает диспетчер виртуальной среды LabManagement. Инструментарий тестирования LabManagement позволяет создать инфраструктуру, которая максимально близко эмулирует реальную среду планируемого использования программного продукта. Такие среды могут использоваться для выполнения автоматических построений, автоматизации тестов и выполнения разработанного кода.
Рефакторинг
Качество кода программного продукта во многом определяется тем, насколько трудно или легко вносить изменения в код, а также тем насколько доступен код для понимания. Созданное программное приложение может выполнять требуемые функции, но иметь проблемы с внесением изменений или пониманием созданного кода. В этом случае такое ПО нельзя назвать качественным, так как на этапе его сопровождения могут возникнуть проблемы с его модификацией при изменении пользовательских требований.
Для улучшения качества кода программных приложений применяют рефакторинг [39, 40]. По определению Фаулера М. рефакторинг определяется как “процесс изменения программной системы таким образом, что её внешнее поведение не изменяется, а внутренняя структура улучшается”. Следовательно, в процессе проектирования для создания высококачественного программного продукта необходимо не только обеспечить выполнение функциональных требований, но и нефункциональных, в частности, удобства сопровождения, что предполагает возможность и простоту внесения изменений в код, а также возможность легкого понимания созданного кода.
Некачественный дизайн кода определяется по ряду признаков [39]:
- жесткость – характеристика программы, затрудняющая внесение изменений в код;
- хрупкость – свойство программы повреждаться во многих местах при внесении единственного изменения;
- косность характеризуется тем, что код содержит части, которые могли бы оказаться полезными в других системах, но усилия и риски, сопряженные с попыткой отделить эти части кода от оригинальной системы, слишком велики;
- ненужная сложность характеризуется тем, что программа содержит элементы, которые не используются в текущий момент;
- ненужные повторения, которые состоят в повторяющихся фрагментах кода в программе;
- непрозрачность, которая характеризует трудность кода для понимания.
Для создания качественного дизайна кода целесообразно применять некоторые принципы и паттерны проектирования ПО[41, 42].
Принцип единственной обязанности определяет, что у класса должна быть только одна причина для изменения. Из этого принципа следует, что классу целесообразно поручать только одну обязанность.
Принцип открытости/закрытости определяет, что программные сущности (классы, модули, функции) должны быть открыты для расширения, но закрыты для модификации.
Принцип подстановки Лисков определяет, что должна быть возможность вместо базового класса подставить любой его подтип.
Принцип инверсии зависимостей определяет два положения:
- модули верхнего уровня не должны зависеть от модулей нижнего уровня. И те и другие должны зависеть от абстракций;
- абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.
Принцип разделения интерфейсов определяет, что клиенты должны знать только об абстрактных интерфейсах, обладающих свойством сцепленности.
Паттерны проектирования предлагают универсальные, проверенные практикой решения. В [40] приведен обширный перечень паттернов. Среди общего списка паттернов следует выделить те, которые целесообразно применять при гибкой разработке программного обеспечения. Это паттерны Команда, Стратегия, Фасад, Посредник, Одиночка, Фабрика, Компоновщик, Наблюдатель, Абстрактный сервер/адаптер/шлюз, Заместитель и Шлюз, Посетитель и Состояние.
Использование паттернов при разработке позволяет создавать программное обеспечение, которое легко модифицировать и сопровождать.
Следует отметить, что для проведения рефакторинга необходимо иметь надежные тесты, которые обеспечивают контроль соблюдения функциональных требований при улучшении дизайна кода программного обеспечения.
Ключевые термины
| Модульное тестирование | тестирование, предназначенное для проверки правильности функционирования методов классов ПО. |
| Исследовательское тестирование | тестирование, при котором тестировщик не имеет заранее определенных тестовых сценариев и пытается интуитивно исследовать возможности программного продукта и обнаружить и зафиксировать неизвестные ошибки. |
| Интеграционное тестирование | тестирование, предназначенное для проверки корректности совместной работы компонентов программного продукта. |
| Функциональное тестирование | тестирование, предназначенное для проверки конкретных требований к ПО, которое проводится после добавление к системе новых функций. |
| Нагрузочное тестирование | тестирование, предназначенное для проверки работоспособности программного продукта при предельной входной нагрузке. |
| Регрессионное тестирование | тестирование, применяемое при внесении изменений в программное обеспечение, с целью проверки корректности работы компонентов системы, которые потенциально могут взаимодействовать с измененным компонентом. |
| Комплексное тестирование | тестирование, предназначенное для проверки соответствия функциональных и нефункциональных требований всей системы программного продукта. |
| Приемочное тестирование | тестирование, представляющее собой функциональные испытания, которые должны подтвердить то, что программный продукт соответствует требованиям и ожиданиям пользователей и заказчиков. |
| MicrosoftTestManager | инструментарий Microsoft, предназначенный для управления жизненным циклом тестирования программного обеспечения. |
| LabManagement | диспетчер виртуальной среды тестирования. |
Краткие итоги
Качество программного продукта определяется по нескольким критериям и качественный программный продукт должен отвечать функциональным и нефункциональным требованиям. В жизненном цикле приложения качество должно отслеживаться на всех его этапах. Тестирование программного продукта позволяет на протяжении всего жизненного цикла ПО гарантировать, что программные проекты отвечают заданным параметрам качества. На протяжении всего жизненного цикла разработки ПО применяются различные типы тестирования. Инструментарием тестировщика в VisualStudio 2012 является MicrosoftTestManager и диспетчер виртуальной среды LabManagement. Для улучшения качества кода программных приложений применяют рефакторинг.
Набор для практики
Вопросы
- Какими характеристиками должен обладать качественный программный продукт?
- Какие нефункциональные требования определяют качество программного продукта?
- Какая роль тестирования в обеспечении качества программного продукта?
- Какие типы тестов используют для проверки качества программного продукта?
- Для чего применяется регрессионное тестирование?
- Какие шаблоны тестовых проектов имеются вVisualStudio 2012?
- Для чего применяется MicrosoftTestManager? Какие он имеет функциональные возможности?
- Для чего используется LabManagement при тестировании?
- Для чего применяют рефакторинг кода?
- Приведите признаки некачественного кода.
Упражнения
- Подготовьте аналитический обзор по NUnit тестированию.
- Подготовьте аналитический обзор по xUnit.net тестированию.
- Подготовьте аналитический обзор по MbUnit тестированию.
Источник