Файл: Отладка и тестирование программ: основные подходы и ограничения (Модульное тестирование).pdf

• программные ресурсы;

• аппаратные ресурсы;

• человеческие ресурсы;

• временные ресурсы;

• финансовые ресурсы (во многих компаниях финансовые ресурсы могут быть представлены отдельным документом, т.к. являются конфиденциальной информацией). - Расписание (test schedule). Фактически это календарь, в котором указано, что и к какому моменту должно быть сделано. Особое внимание уделяется т.н. «ключевым точкам» (milestones), к моменту наступления которых должен быть получен некий значимый ощутимый результат. - Роли и ответственность (roles and responsibility). Перечень необходимых ролей (например, «ведущий тестировщик», «эксперт по оптимизации производительности») и область ответственности специалистов, выполняющих эти роли. - Оценка рисков (risk evaluation). Перечень рисков, которые с высокой вероятностью могут возникнуть в процессе работы над проектом. По каждому риску даётся оценка представляемой им угрозы и приводятся варианты вы-хода из ситуации. - Документация (documentation).

Перечень используемой тестовой докумен-тации с указанием, кто и когда должен её готовить и кому передавать. - Метрики (metrics). Числовые характеристики показателей качества, которые могут включать описание способов оценки и анализа результата На этот раздел, как правило, формируется множество ссылок из других разделов тест-плана.

Метрики в тестировании являются настолько важными, что их необходимо рассмотреть отдельно. Метрики могут быть как прямыми (не требуют вычислений), так и расчётными (вычисляются по формуле). Типичные примеры прямых метрик – количество разработанных тест-кейсов, количество найденных дефектов и т.д. В расчётных метриках могут использоваться как совершенно тривиальные, так и довольно сложные формулы.

В тестировании существует большое количество общепринятых метрик, многие из которых могут быть собраны автоматически с использованием инструментальных средств управления проектами. Например: - процентное отношение (не) выполненных тест-кейсов ко всем имеющимся; - процентный показатель успешного прохождения тест-кейсов; - процентный показатель заблокированных тест-кейсов; - плотность распределения дефектов; - эффективность устранения дефектов; - распределение дефектов по важности и срочности; - и т.д. При формировании отчётности важно учитывать не только текущее значение метрики, но и её динамику во времени, которую очень удобно изображать графически (что тоже могут выполнять автоматически многие средства управления проектами).

Таким образом, метрики являются мощнейшим средством сбора и анализа информации. И вместе с тем здесь кроется опасность: ни при каких условиях нельзя допускать ситуации «метрик ради метрик», когда инструментальное средство собирает уйму данных, вычисляет множество чисел и строит десятки графиков, но… никто не понимает, как их трактовать. И, наконец, стоит упомянуть про так называемые «метрики покрытия».

Покрытие (coverage) – процентное выражение степени, в которой исследуемый элемент (coverage item) затронут соответствующим набором тест-кейсов. Самыми простыми представителями метрик покрытия можно считать:

- Метрику покрытия требований (требование считается «покрытым», если на него ссылается хотя бы один тест-кейс).

- Метрику плотности покрытия требований (учитывается, сколько тест-кейсов ссылается на несколько требований).

- Метрику покрытия классов эквивалентности (анализируется, сколько классов эквивалентности затронуто тест-кейсами).

- Метрику покрытия граничных условий (анализируется, сколько значений из группы граничных условий затронуто тест-кейсами).

- Метрики покрытия кода модульными тест-кейсами. Таких метрик очень много, но вся их суть сводится к выявлению некоей характеристики кода (количество строк, ветвей, путей, условий и т.д.) и определению, какой процент представителей этой характеристики покрыт тест-кейсами. Метрик покрытия настолько много, что даже в ISTQB-глоссарии дано определение полутора десяткам таковых.

2.2. Методика унификации процессов интерпретации программного кода

В настоящее время широкое распространение получило модульное программирование.

В результате аналитического исследования концепцию модульного программирования можно

сформулировать в виде нескольких понятий и положений.

1. Функциональная декомпозиция задачи - разбиение большой задачи на ряд более мелких, функционально самостоятельных подзадач - модулей. Модули связаны между собой только по входным и выходным данным.

2. Модуль – основа концепции. Каждый модуль в функциональной декомпозиции представляет собой “чёрный ящик” с одним входом и одним выходом.

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

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

Проблема интеграции модулей и частей систем решается разными способами. В распределенных системах вводят промежуточный уровень программного обеспечения, который в сетевых операционных системах позволяет более или менее скрыть от пользователя разнородность набора аппаратных платформ и повысить прозрачность распределения. Многие современные распределенные системы построены в расчёте на этот дополнительный уровень, который получил название программного обеспечения промежуточного уровня [2].

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

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

Многие современные компьютерные приложения используют модули, написанные на разных языках программирования. И интеграция этих модулей – деликатная операция. В первую очередь требуется наличие договоренностей, чтобы дать возможность программистам обозначить «сторонние» сущности как объекты или функции, а также связанные с ними типы данных. Необходимо обеспечить возможность создания иерархических структур, и правильного передачи данных: ссылок, указателей, если потребуется. Также необходимо перевести то, чем будут часто пользоваться программисты на уровень интерфейсов, вплоть до спецификации ABI (Application Binary Interfaces, Двоичный интерфейс приложения).

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

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

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

Процесс связывания программного кода разных языков программирования имеет явно выраженный комплексный характер и включает ряд основных этапов:

1) разделение обязанностей языковых процессоров на внутренние и внешние;

2) создание механизмов работы с данными: общих переменных, функций, создание механизмов передачи данных: контекст, стек значений, создание объектов, контролирующих процесс разбора кода.

В данной работе проведен анализ существующих инструментов, использующих или описывающих унификацию данных и процессов разбора программного кода [4]. В результате проведенного анализа были получены следующие результаты:

1. Рассмотрены существующие средства связывания данных: технология CORBA, инструмент SWIG, язык QtScript, рассмотрены способы хранения абстрактных данных в фреймворке Qt. Рассмотрены объекты типа QVariant, их создание, конвертирование, копирование. Возможность хранения в контейнерах других контейнеров.

2. Рассмотрены основные принципы разделения процесса разбора кода на отдельные этапы, а также особенности каждого этапа.

Универсальный доступ к процессам интерпретации может быть обеспечен путем выделения общих частей программного модуля в отдельный блок – внешний интерфейс – front-end. При разработке программного модуля «Универсальный командный интерпретатор», таким блоком стала библиотека SmMultiScriptFrontEnd.

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

1. Мультиязыковое программирование – формализм, доступный для обозначения и использования “сторонних” объектов других языков, а также инфраструктура для работы с такими объектами. Этот термин вводят Cyrille Comar, Matthew Gingell, Olivier Hainque, Javier Miranda в статье “Multi-Language Programming: The Challenge and Promise of Class-Level Interfacing”[6].

2. Фреймворк Qt - кросплатформенный инструментария разработки ПО на языке программирования C++. Этот фреймворк обладает встроенным интерпретатором JavaScript, который позволяет интегрировать код на данном языке в нативный код на языке C++. Два основных аспекта мультиязыкового программирования – это формализм, доступный для обозначения и использования “сторонних” объектов других языков, а также инфраструктура для работы с такими объектами. Взаимодействие может охватывать различные аспекты, такие как доступ к сторонним данным, представление сторонних типов, вызовы сторонних подпрограмм, обработка сторонних событий, таких как исключения, и повторное использование иерархий классов объектов. В любом случае, взаимодействие всегда подразумевает соглашение между заинтересованными сторонами. Например, вызов подпрограммы будет работать правильно только тогда, когда вызывающий и вызываемый договорились о том, как передаются аргументы (в каком порядке, используя какие вычислительные ресурсы), кто размещает, удаляет ту или иную часть стека, как работает указатель стека, и т.д.