Файл: Тестирования производительности программ: подходы в зависимости от категорий приложений.pdf
Добавлен: 29.03.2023
Просмотров: 346
Скачиваний: 1
Компромисс использования искусственных спецификаций - это дополнительные издержки в отладке. Когда исполнение во время производства нарушает такую спецификацию, сбой может быть вызван ошибкой, вызванной выполнением, или ошибка в тренировочных запусках программы, которые были отражены в прогнозах, или из-за к неточности прогнозов. Первые два случая выявляют ошибки (хотя второй случай потребует больше усилий для отладки). Однако провал в последнем - случай ложной тревоги (ложное срабатывание). Так как мы не знаем заранее, если нарушение является реальной ошибкой или ложным срабатыванием, нам нужно исследовать ее (отладка), что довольно трудоемко. Если оказывается ложным положительным, - усилия потрачены впустую. Несмотря на перспективность, исследования по использованию нейронных сетей в качестве искусственного спецификации немногочисленны. В [16] предложено использовать нейронную сеть и ГА для функционального тестирования. Здесь первая применяется для построения модели тестируемой программы, которая далее используется вместо этой программы при оценке качества тестов. Отметим, что в этом случае тестовые наборы генерируются, прежде всего на основе выходных данных, а не входных, как это делается при тестировании по методу «белого ящика». Для модели используется многослойная нейронная сеть прямого распространения, при обучении которой применяется алгоритм обратного распространения. Нейронная сеть обучается путем моделирования тестируемой программы. Выходные сигналы обученной нейронной сети используются в ГА при оценке значений фитнесс-функции, которая определяет качество тестовых наборов. Таким образом, ГА в процессе искусственной эволюции ищет входные тестовые наборы, качество которых оценивается с помощью нейронной сети (модели тестируемой программы). Фитнесс-функция определяется следующим образом:
, где c - реальное значение, a g - целевое значение выходного сигнала тестируемой программы. Особи популяции (тестовые наборы) оцениваются с помощью указанной фитнесс-функции и порождают особи следующего поколения ГА с помощью генетических операторов репродукции, кроссовера и мутации. При этом используются следующие модификации арифметического кроссовера:
Здесь X; и x2 - родительские особи, отобранные с помощью оператора репродукции, ayby2, y3 - новые особи-потомки, полученные в результате выполнения генетического оператора кроссовера, и г является случайным числом, сгенерированным в диапазоне (0,1). Заметим, что переменные Xb x2 иуьy2,Уз принимают вещественные (не двоичные) значения, то есть используется вещественное кодирование значений входных переменных. Построенные ГА текущие особи включаются в тестовую последовательность, если для них значение фитнесс-функции достигает или превышает f,MX.
Разница между целевым значением и фактическим значением выхода тестируемой программы, которое определяется с использованием нейронной сети, используется для расчета фитнесс-значений особей в популяции. Если фитнесс-значение превышает или достигает максимального, то поиск останавливается и текущая особь принимается в качестве тестового набора для соответствующих выходов. Отметим, что тестовые наборы генерируются на основе значений выходных переменных.
Результаты показывают, что этот подход с высокой эффективностью может построить тестовую последовательность из выходных значений тестируемой программы. Эксперименты проводились только на небольших программах. Эффективность такого подхода может в дальнейшем оцениваться по более сложным программам. Выходные результаты модели на основе нейронной сети близки к реальным. Для минимизации этой разницы необходимо улучшить фитнесс-функцию.
В работе [17] для генерации тестовых наборов программы предложен подход на основе нечеткого расширения ГА (FAexGA), целью которого является поиск минимального множества тестовых наборов, которые могут обнаружить сбои при использовании видоизмененных версий оригинальной программы. При этом вероятность кроссовера варьируется с помощью нечетких контроллеров в соответствии с «возрастными интервалами», назначенными при жизни. Здесь вероятности кроссовера молодой и старой особи присваивается низкое значение, в то время как для другого возрастного интервала эта вероятность может быть высокой. Очень молодые потомки кроссовера имеют низкую вероятность того, что способствуют расширению пространства поиска. У старых потомков вероятность кроссовера также меньше и в конечном итоге вымирание помогает избежать преждевременной сходимости в локальном оптимуме или. С другой стороны, потомки среднего возраста часто используются при выполнении генетического оператора кроссовера.
Для определения вероятности кроссовера используется нечеткий логический контроллер (FLC). Переменные состояния FLC включают возраст и продолжительность жизни хромосом (родителей). Следует отметить, что высокое значение вероятности кроссовера способствует расширению пространства поиска, а низкое - улучшает сходимость. Хороший алгоритм обеспечивает баланс между этими характеристиками, который здесь достигается с помощью нечетких контроллеров путем назначения соответствующих значений вероятностей кроссовера.
Интерфейс фаззификации FLC включает переменные, определяющие возраст потомка. FLC присваивает каждому родительскому значению «молодой» (Young), «средний» (Medium) или «старый» (Old). Эти значения определяют принадлежность для каждого правила в базе правил FLC. В табл. 2 представлена нечеткая база правил, использованная в эксперименте. Каждая ячейка определяет одно нечеткое правило. Например, если родитель 1 и родитель 2 старые, то вероятность кроссовера низкая. При дефаззификации используется метод «центр тяжести» (COG), который вычисляет четкое значение для вероятности пересечения значения языковых меток, как показано в табл. 1.
Таблица 1
Нечеткие правила для вероятностей кроссовера
|
Parent 1 Parent2 |
“Young” |
“Middle-age” |
“old” |
|
“Young” |
Low |
Medium |
High |
|
“Middle-age” |
Medium |
High |
Medium |
|
“old” |
Low |
Medium |
Low |
Тестовые наборы соответствуют входам тестируемого программного обеспечения и представлены в виде вектора двоичных или непрерывных значений. Эти наборы инициализируются случайным образом в пространстве поиска возможных входных значений. Новые тестовые наборы генерируются с помощью генетических операторов и далее они оцениваются на основе способности обнаружения ошибок путем использования мутантов - искаженных версий исходной программы.
В качестве примера использовалось булево выражение, состоящее из 100 булевых атрибутов, и 3 логических оператора: И, ИЛИ и НЕ. Булево выражение строилось случайным образом, далее оценивался потенциальный тестовый набор путем генерации и проверки мутантов - искаженных булевых выражений. Каждый тестовый набор кодируется двоичной строкой длиной 100 бит. Для оценки качества тестовых наборов использовалась следующая фитнесс-функция:
где T - 100-битная бинарная хромосома, представляющий один тестовый набор; Eval_Correct (Т) и Eval_Erroneous (Т) - булевы значения правильного и ошибочного выражения для данной двоичной строки Т. К сожалению, данный подход не апробирован для сложных реальных программ со входами, принимающими вещественные значения.
В целом генетические алгоритмы достаточно широко применяются при тестировании программного обеспечения как при структурном, так и при функциональном тестировании. Эксперименты показали, что генетические алгоритмы позволяют существенно повысить качество тестирования. Это направление, безусловно, является перспективным, но требует апробации на более сложных реальных программных проектах.
Анализ факторов, влияющих на процесс тестирования
Зависимость процесса тестирования от аппаратных характеристик устройства
Платформа Android является свободно - распространяемой бесплатной системой, и именно поэтому она завоевала такой большой процент рынка. Однако рынок занят не только «флагманскими» устройствами, но и устройствами более низких классов. Также, технологии в электронике и производстве постоянно совершенствуются, и поэтому мы видим ежегодное обновление линеек смартфонов всех производителей от корейского Samsung и тайваньского HTC до российского Highscreen и пакистанского QMobile. Оба этих фактора создают серьезную сегментацию на рынке устройств с фактически одной операционной системой, что создает дополнительные трудности в тестировании нативных Android - приложений, в отличие от того же iOS. Первым, на что стоит обратить внимание в процессе тестирования, являются аппаратные характеристики устройства, такие как:
1. Объем оперативной памяти RAM Низкий объем оперативной памяти, очевидно, может серьезно повлиять на скорость работы приложения. Но также полностью занятая RAM может привести к нестабильности приложения и нарушению его работы. Этот момент обязательно нужно учитывать в процессе тестирования, испытывая работу приложения в условиях занятой другими приложениями памяти. В этих случаях, помимо «вылетов» приложения, могут возникнуть проблемы функционального плана, ошибки и пропажа элементов пользовательского интерфейса, остановка фоновых сервисов приложения и т.д.
2. Объем внутренней памяти Этот параметр является довольно специфичным, поскольку внутренняя память в большом количестве требуется только для игровых и медиа - приложений. Однако, в случае, например, потокового воспроизведения аудио в условиях недостатка внутренней памяти, воспроизведение, очевидно, остановится, но в исходном коде приложения может быть не предусмотрен такой сценарий, и может возникнуть фатальная для приложения ошибка. Поэтому в тест - плане стоит предусмотреть такой вариант, выполняя тестирование с памятью, предварительно заполненной любой информацией.
3. Размер и разрешение экрана Важнейший параметр для любого приложения. От размера экрана зависит размер и положение элементов пользовательского интерфейса, поэтому надо уделить особое внимание устройствам с минимальными и максимальными параметрами экрана. На устройствах с минимальными параметрами экрана (для нынешнего рынка это порядка 3.5 дюймов и VGA - разрешение) возможны наложения элементов друг на друга, что делает невозможным использование этих элементов. На больших же экранах и разрешениях (для рынка сейчас это 12 дюймов и QHD - разрешение) элементы могут быть настолько малы, что пользователь просто не будет способен попасть по ним пальцем. Поэтому в процессе обеспечения качества ПО стоит учитывать эти параметры, и создавать элементы с динамическими размерами, которые подстраиваются под любые размеры и разрешения экрана.
4. Скорость и тип Интернет – соединения. Если в исходном коде приложения предусмотрено время отсечки запроса, приложение может просто не дождаться приходящей информации. Если скорость соединения чересчур мала, элементы интерфейса попросту не успеют загрузиться в отведенное время, что может привести к непредсказуемым последствиям, среди которых остановка приложения или невозможность использования приложения ввиду отсутствия части (или всех) элементов интерфейса. Тип соединения влияет в первую очередь на функционал приложения, предусматривающего загрузку пользовательской информации. Некоторые приложения позволяют пользователям запретить загрузку или фоновое обновление данных посредством мобильной сети, и это обязательно должно проверяться в процессе тестирования, поскольку от этого потенциально зависят расходы пользователя и, в конечном итоге, удовлетворение пользователя работой приложения.
5. Наличие дополнительных датчиков Самым важным из дополнительных датчиков смартфона является акселерометр, измеряющий ускорение свободного падения по трем осям, и из показаний вычисляющий ориентацию устройства в пространстве. Именно с помощью акселерометра интерфейс устройства меняется с портретного на ландшафтный при перевороте его на бок. Это устройство стоит учитывать в тестировании, если приложение имеет обе ориентации интерфейса, однако в данном случае акселерометр не играет ключевой роли, в отличие от самого процесса смены ориентации и вращения интерфейса, о котором речь пойдет ниже.
Остальные датчики – приближения, освещения, сердцебиения, гироскоп, барометр, термометр, устанавливаемые в современные смартфоны, используются в очень узкоспециализированных приложениях, и процесс их тестирования должен проходить в первую очередь на заводе - изготовителе данных датчиков.
Зависимость процесса тестирования и документирования ошибок от использования аппаратных и программных средств управления устройством
Можно выделить несколько действий, которые довольно распространены в процессе использования смартфона, и которые сам пользователь регулярно совершает.
- Сворачивание приложения.
Это очень распространенный случай возникновения ошибок, если приложение должно работать в фоновом режиме. При сворачивании оно может прекратить работу, или же работать неправильно.
- Выгрузка приложения.
Редкий случай возникновения ошибок, однако бывают случаи, когда при выгрузке приложение фактически продолжает работу, например, воспроизведение звука на выключенном плеере.