Машинно-зависимые приемы оптимизации

Машинно-зависимые используют особенности устройства и работы конкретной системы. Ярким примером машинно-зависимой оптимизации является векторизация операций, т.е. использование потоковых расширений процессора, таких как MMX (MultiMedia eXtensions), SSE (Streaming SIMD Extensions) и т.п. Машино-зависимую оптимизацию можно выполнять двумя различными способами. Первый способ основан на понимании работы кодогенератора компилятора, его алгоритма и рекомендуется для приложений, в которых компилятор выбирается в начале проекта и в дальнейшем не меняется. При использовании такого способа преобразуется исходный код программы, написанный на языке высокого уровня. Для тех проектов, в которых заранее не известен компилятор (OpenSource проекты, кроссплатформенные приложения) применятся другой способ, основанный на замещении ресурсоемких участков кода ассемблерными вставками. При такой оптимизации ухудшается переносимость кода на другие платформы. Машинно-зависимые способы оптимизации довольно хорошо автоматизируются и большую часть их выполняют оптимизирующие компиляторы. Однако всегда остаются моменты в программе, которые можно оптимизировать вручную.

13) Тестирование.

Тести́рование программного обеспечения — процесс выявления ошибок в программном обеспечение (ПО). К сожалению, существующие на сегодняшний день методы тестирования ПО не позволяют однозначно и полностью устранить все дефекты и ошибки и установить корректность функционирования анализируемой программы особенно в закрытых частных программах. Поэтому все существующие методы тестирования действуют в рамках формального процесса проверки исследуемого или разрабатываемого ПО.

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

1. Необходимой частью каждого теста должно являться описание ожидаемых результатов работы программы; 2. Программе не должна тестироваться её автором; 3. Организация - разработчик программного обеспечения не должна "единолично " его тестировать; 4. Необходимо подбирать тесты не только для правильных (предусмотренных) входных данных, но и для неправильных (непредусмотренных); 5. При анализе результатов каждого теста необходимо проверять, не делает ли программа того, что она не должна делать; 6. "Принцип скопления ошибок" - вероятность наличия не обнаруженных ошибок в некоторой части программы прямо пропорциональна числу ошибок, уже обнаруженных в этой части; Процесс тестирования состоит из трёх этапов: 1. Проектирование тестов. 2. Исполнение тестов. 3. Анализ полученных результатов.

Тестирование программы по принципам (10 принципов Майерса).

Тестирование должно быть организовано по следующим принципам (согласно Майерсу):

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

2. желательно, чтобы кроме автора тестирование проводили и другие люди. Т.к. обнаружение недостатков в своей деятельности противоречит человеческой психологии, восприятие человека "со стороны" ближе к восприятию пользователя, чем психология автора, однако отладка программы эффективнее всего выполняется именно автором программы;

3. по тем же соображениям организация - разработчик программного обеспечения -не должна "единолично " его тестировать (должны существовать организации, специализирующиеся на тестировании программных средств);

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

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

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

7. следует сохранять использованные тесты (для повышения эффективности повторного тестирования программы после ее модификации или установки у заказчика);

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

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

10.следует всегда помнить, что тестирование - творческий процесс, а не относиться к нему как к рутинному занятию.

Тестирование по степени охвата проекта (изолированное, промежуточное, комплексное).

Изолированное тестирование

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

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

Второй вариант: вместо неготовых компонент можно использовать так называемые программы-заглушки и программы-драйверы. Заглушка не несет серьезной функциональности, а как правила просто выдает сообщение на экран. Программа драйвер передает тестируемому компоненту необходимые тестовые данные и отображает результаты.

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

Модули, содержащие операции ввода-вывода, а так же критические модули (т.е. наиболее важные для программы в целом) должны тестироваться как можно раньше.

Промежуточное тестирование

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

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

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

Комплексное тестирование, выполненное разработчиками, называется альфа-тестированием. В результате исправления ошибок появляется так называемая альфа-версия программы.

Обычно альфа-версию поставляют ограниченному кругу конечных пользователей для более жесткого тестирования. Хорошо известно, что пользователи иногда используют программное обеспечение не совсем для тех целей, для которых оно предназначалось. Поэтомy могут обнаружиться неожиданные ошибки в тех местах пpогpаммы, которые разработчики считают абсолютно правильными. Комплексное тестирование программного продукта пользователями называется бетта-тестированием. В результате исправления найденных ошибок появляется бетта-версия программы.

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

Стратегии тестирования (методы «черного» и «белого» ящика).

Тестирование программы как черного ящика

Одним из способов изучения поставленного вопроса является исследование стратегии

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

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

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