Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
docs / Modelirovanie_3k_Lektsia_2_4_Tekhn_Osn_yazykov_pro.pptx
Скачиваний:
81
Добавлен:
20.03.2015
Размер:
6.76 Mб
Скачать

СТОИМОСТЬ КАЧЕСТВА

Preventive costs (стоимость предотвращения низкого качества продукта\сервиса):

Планирование качества

Разработка/оценка процессов

Планирование улучшения качества

Обучение

Стоимость всех активностей для предотвращения ошибок (QA)

Appraisal costs (стоимость оценки):

Стоимость тестирования Стоимость выполнения ревью Стоимость выполнения инспекций

Все затраты на выявление дефектов (QC)

Failure cost (цена «неудач»/ошибок, обнаруженных до и после поставки продукта\предоставления сервиза заказчику, internal failure cost and external failure cost):

Стоимость идентификации, анализа, исправления ошибок и проверки исправления ошибок

Повторное тестирование

Стоимость переработок, работ по обработке жалоб заказчика

СТОИМОСТЬ КАЧЕСТВА

B. Boehm and V. Basili «Software Defect Reduction Top 10 List» (IEEE Computer, IEEE Computer Society, Vol. 34, No.1, January 2001, pp. 135-137.): стоимость исправления дефекта после ввода системы в эксплуатацию вдвое превышает аналогичную стоимость на стадии тестирования продукта и более чем в тысячу раз — в период

УПРАВЛЕНИЕ ТРЕБОВАНИЯМИ

ГОСТ Р и ISO/IEC 12207

V&V

Спецификация — (Specification) набор требований и параметров, которым удовлетворяет некоторая сущность.

Согласно определению, приведенному в Единой системе конструкторской документации (ЕСКД) спецификация — документ, определяющий состав сборочной единицы, комплекса, комплекта. В спецификации содержится подробное перечисление узлов и деталей какого-либо изделия, конструкции, установки, и т. п., входящих в состав сборочного или монтажного чертежа.

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

Техническое задание

ТРЕБОВАНИЯ К ПО

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

Виды требований по уровням:

Бизнес-требования — определяют назначение программного обеспечения

Бизнес-правила — определяют ограничения, проистекающие из предметной области и свойств автоматизируемого объекта (предприятия)

Пользовательские требования — определяют набор пользовательских задач, которые должна решать программа, а также способы (сценарии) их решения в системе (use case)

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

диаграммы: ER (IDEF1FX), IDEF0, IDEF3, DFD, UML, OCL, SysML, ARIS (eEPC, VAD)

ТЕСТИРОВАНИЕ ПО

Тестирование – проверка соответствия ПО требованиям, осуществляемая с помощью

СТАНДАРТЫ ТЕСТИРОВАНИЯ

IEEE 829-1998 Standard for Software Test Documentation - описывает виды документов, служащих для подготовки тестов

IEEE 1008-1987 (R1993, R2002) Standard for Software Unit Testing - описывает организацию модульного тестирования

ISO/IEC 12119:1994 (ГОСТ Р-2000, IEEE 1465-1998) Information Technology. Software packages — Quality requirements and testing - описывает

требования к процедурам тестирования

ОРГАНИЗАЦИОННЫЕ ПРИНЦИПЫ УПРАВЛЕНИЯ ТЕСТИРОВАНИЕМ

Программирующая организация не должна сама тестировать разработанные ею программы

Необходимо досконально изучать результаты применения каждого теста

Тесты для неправильных и непредусмотренных входных данных следует разрабатывать так же тщательно, как для правильных и предусмотренных

Необходимо проверять не только, делает ли программа то, для чего она предназначена, но и не делает ли она то, что не должна делать

Не следует выбрасывать тесты, даже если программа уже не нужна

Нельзя планировать тестирование в предположении, что ошибки не будут обнаружены

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

Тестирование — процесс творческий

ТЕСТОВЫЕ МЕТРИКИ

Покрытие функциональных требований

Покрытие кода продукта. Наиболее применимо для модульного уровня тестирования

Покрытие множества сценариев

Количество или плотность найденных дефектов

Соотношение количества найденных дефектов с количеством тестов на данную функцию продукта

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

ТЕСТИРОВАНИЕ ПО

метод белого ящика (white-box testing, прозрачного ящика,

структурное тестирование) – разработчик теста имеет доступ к исходному коду и может тесты, связанные с библиотеками тестируемого ПО

метод чёрного ящика доступ к ПО через стандартные интерфейсы. Нацелено на проверку требований (тесты на основе требований и ограничений из спецификаций, стандартов, внутренних нормативных документов)

Тестирование на соответствие (conformance testing)

УРОВНИ ТЕСТИРОВАНИЯ

Модульное тестирование (Unit-testing) – тестируется

минимально возможный для компонент (отдельный класс

или функция)

Интеграционное тестирование (Integration testing) –

отдельные программные модули объединяются и тестируются в группе

Системное тестирование (System testing) – тестирование

на полной, интегрированной системе для проверки

соответствия системы исходным требованиям (метод

«черного ящика»)

Приемочное тестирование (Acceptance testing) –

Соседние файлы в папке docs