Относительная эффективность методик контроля качества ПО

Не все методы контроля качества ПО имеют одинаковую эффективность.

Характеристики:

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

2. Стоимость нахождения дефектов. Некоторые методики обнаружения дефектов дороже других.

3. Стоимость исправление дефектов. Стоимость нахождения дефектов, только одна часть затрат. Другой частью является стоимость их исправления. Чем дольше дефект остается в системе, тем больше затрат придется средств придется потратить на его устранения.

4. Когда проводить контроль качества ПО. Дефекты проникают в ПО на всех стадиях разработки, поэтому контроль качества нужно проводить на всех этапах разработки проекта, начиная с самых ранних.

Главный «закон» контроля качества ПО

Лучшим способом повышения производительности труда разработчиков и качества ПО является минимизация времени затрачиваемое на исправление кода, чем бы оно не объяснялось.

Ключевые моменты качества ПО

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

2. Стремление к одним характеристикам качества препятствует достижению других.

3. Никакая методика обнаружения дефектов не является достаточно эффективной. Эффективна только их комбинация.

4. Чем раньше вы обнаружите дефект, тем слабее он пересечется с остальным кодом и тем меньше вреда он успеет нанести.

Методы оптимизации

Оптимизация программного обеспечения деятельность направленное на повышение характеристик качества ПО, с минимальным ухудшением других характеристик.

При оптимизации следует помнить, что конечного пользователя, интересует только внешние характеристики ПО. Любая оптимизация в конечном счете, должна вести к улучшению внешних характеристик.

 

Производительность и оптимизация кода

Перед тем как приступать к оптимизации кода, следует подумать об эффективности в контексте:

1. Требование к программе

2. Проекта программы.

3. Проектов компонентов.

4. Взаимодействие программы с операционной системой.

5. Компиляции кода

6. Оборудование

7. Оптимизации кода

Требования к программе:

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

2. Проект программы.

 

24.11.12.

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

1. Производительность компонентов.

Одним из способов повышения производительности на этом уровне является оптимальный подбор типов данных и алгоритмов.

2. Взаимодействие программы с операционной системой.

Низкая производительность разрабатываемой системы может быть связана с слишком частым обращением к операционной системе.

3. Компиляция кода

Хорошие компиляторы преобразуют ясный высокоуровневый код в оптимизированный машинный код.

4. Оборудование

5. Оптимизация кода

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

Принцип Парето – известен как «правило 80 на 20». Гласит, что 80 процентов результата, можно получить приложив 20 процентов усилий. Менее 4% кода соответствуют более, чем 50% времени выполнения.

При оптимизации кода нужно найти «горячие точки» и сосредоточиться на их оптимизации большее всего.

Заблуждение относительно оптимизации кода:

1. Сокращение числа строк высокоуровневого кода повышает быстродействие и уменьшает объем итогового машинного кода.

2. Одни операции выполняются быстрее и компактнее других.

3. Оптимизацию следует выполнять по мере написания программы.

4. Быстродействие программы не менее важно, чем ее корректность.

Частые причины снижения эффективности:

1. Операции ввода вывода.

2. Системные вызовы – обращение к сети, прослушивание событий. Если вас не устраивает скорость выполнения системных вызовов, напишите свои.

3. Ошибки.

Оценка производительности

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

 

26.11.12.

1. …

2. …

3. …

… неадекватный проект, неудачные технологии, неправильный алгоритм.

Оптимизируйте узкое место, определенное на этапе б):

a. Оцените каждое улучшение по одному за раз.

b. Если оптимизация не привела к улучшению, вернутся к сохраненному коду на этапе а).

4. Повторите процесс начиная с пункта 2.

Тестирование. Философия тестирования.

Тестирование – это процесс выполнения программы с целью обнаружения ошибок.

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

Экономика тестирования

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

Основные принципы тестирования:

1. Описание предполагаемых значений выходных данных или результатов, должно быть необходимой частью тестового набора.

2. Следует избегать тестирования программы ее автором.

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

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

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

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

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

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

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

Типы ошибок и ручные методы тестирования.

Классификация ошибок.

По времени появления ошибки можно разделить на три вида:

1. Структурные ошибки.

2. Ошибки компиляции.

3. Ошибки периода выполнения.

В теоретической информатике, программные ошибки классифицируются по степени нарушения логики:

1. Синтаксические

2. Семантические

3. Прагматические

Классификация ошибок, основанных на опыте:

1. Ошибка адресации.

2. Ошибка ввода-вывода.

3. Ошибка вычисления.

4. Ошибка интерфейса

5. Ошибки обращения к данным.

6. Ошибки описания данных.

 

03.12.12

…

Стратегии белого ящика:

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

2. Покрытие решений – предполагает выполнение достаточного количества тестов, чтобы каждое решение на этих тестах принимала значение истина или ложь по крайней мере один раз.

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

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

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

Стратегии черного ящика:

1. Эквивалентное разбиение требует выбора такого теста, который обладает двумя свойствами:

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

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

2. Анализ граничных значений – предполагает тестирование граничных условий. Граничные условия, это ситуации, возникающие непосредственно на выше или ниже границ классов и эквивалентности. Отличается от предыдущего в двух отношениях:

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

b. При разработке тестов рассматриваются не только входные условия (пространство входов) но и выходные (пространство результатов).

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

Этапы:

a. Спецификация разбивается на рабочие участки.

b. Определяются причины и следствия. Причины это входное условие, а следствие это выходное

c. Анализируется содержание спецификаций, которая преобразуется в булевский граф, связывающий причины и следствия.

d. Диаграмма снабжается примечаниями, задающими ограничения и описывающие комбинации причин или следствий.

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

f. Столбцы таблицы решений преобразуются в тесты.

4. Предположение об ошибке.

Нисходящее и восходящее тестирование.

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

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

Сравнение восходящих и нисходящих.

 

10.12.12

Нисходящая тестирование. Преимущества:

1. Эффективней, если ошибки преимущественно в верхней части программы.

2. Представление теста облегчается после подключения функции ввода и вывода.

3. Ранее формирования структуры программы позволяет провести ее декомпозицию и служит моральным стимулом.

Недостатки:

1. Необходимо разрабатывать заглушки.

2. Заглушки часто оказываются сложнее, чем казалось вначале.

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

4. Создание тестовых условий может оказаться трудным или невозможным.

5. Сложная оценка результатов тестирования.

6. Допускает мысль о возможности совмещения тестирования и проектирования.

7. Стимулируется не завершение тестирования некоторых классов или модулей.

Восходящее тестирование. Преимущества:

1. Эффективней, если ошибки преимущественно в классах или модулях нижнего уровня.

2. Легче создавать тестовые условия.

3. Проще оценка результатов.

Недостатки:

1. Необходимо разрабатывать драйверы.

2. Программа как единое целое не существует до тех пор, пока не добавлен последний класс модуль.

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

Включает в себя следующие этапы:

1. Задаться целью теста.

2. Написать входные значения.

3. Написать предполагаемые выходные значения.

4. Выполнить тест и зафиксировать результат

5. Проанализировать результат.

Тестирование объектно-ориентированных систем.

Объектно-ориентированные программы добавляют специфические проблемы в технологии тестирования.

Эти проблемы определяются двумя основными аспектами:

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

2. Элементом тестирования является не подпрограмма, структура которой хорошо представляется и по графу управления, а класс имеющий набор атрибутов и методов поведений, которые не связанны друг с другом жестко.

3. Основные принципы Объектно ориентированного подхода добавляют новые аспекты тестирования:

a. Инкапсуляция – создает проблему видимости данных, так как они доступны только через итерации. В процессе тестирования это может создать определенные проблемы с выводом значений.

b. Наследование – составить вопросы о повторение тестирования наследуемых операций.

c. Полиморфизм – приводит к неоднозначности с вызовом операций, которая может быть разрешена, только на этапе выполнения.

Основные принципы ООП ставят новые вопросы:

1. Какая часть наследованных свойств должна заново тестироваться.

2. Когда и как можно проверить информацию о состоянии объекта.

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

4. Как следует тестировать интеграцию классов и какие стратегии тестирования применять.

Методы тестирования объектно-ориентированных систем.

Основные черты нового модуля тестирования:

1. Нет глобальных данных или они

2. Класс не является тестируемым элементом. Тестируются только объекты.

3. Нельзя тестировать методы поведения класса изолированно друг от друга, поскольку они используют общие атрибуты.

Тестирование наследование – наследуемые методы должны быть протестированы заново при добавлении или переопределении базового метода.

Инкапсуляция.

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

Тестирование полиморфизма.

Каждый возможный вариант полиморфного вызова метода должен быть протестирован.

Тестирование с учетом внутренней структуры.

Существует два варианта подобного тестирования:

1. Основанное на интерфейсе класса

2. Тестирование основанное на методах класса.