Кабылова, Д. А. Расширенный конечный автомат для тестирования мобильных приложений / Д. А. Кабылова, Г. Д. Когай. — Текст : непосредственный // Молодой ученый. — 2016. — № 21 (125). — С. 141-144. — URL: https://moluch.ru/archive/125/34496/ (дата обращения: 13.07.2023).
Ключевые слова: тестирование, мобильное приложение, метод тестирования, расширенный конечный автомат
С каждым годом рынок мобильных приложений постоянно увеличивается: системные и дополнительные утилиты, приложения на базе оповещений. Но к какому бы типу эти приложения не относились, каждое из них должно быть хорошо протестировано.
На первый взгляд кажется, что тестирование мобильных приложений достаточное простое, ведь приложение чаще всего состоит лишь из нескольких экранов-страниц. Но вся суть в том, что новые версии мобильного приложения разрабатываются и собираются во много раз чаще, чем веб-приложения или десктоп-приложения, и, как следствие, приемочное тестирование выполняется очень часто. Довольно обыденно становится для тестировщика повторять однотипные действия: установить приложение, запустить, проверить, что все необходимые элементы присутствуют и т. д. Средства для Android-приложений были выбраны темой исследования неслучайно: устройства отличаются большим разнообразием и тестирование необходимо выполнять на каждом из них (устройства могут отличаться версиями операционной системы, разрешением экранов, наличием или отсутствием фронтальной камеры и др.). То есть, если рассматривать iOS-устройства, то в таком случае процесс тестирования немного упрощается, так как произвести проверку необходимо только на некоторых устройствах: iPhone, iPad, iPod для конкретных версий ОС [1].
Функциональное и нефункциональное тестирование
В контексте тестирования приложений для мобильных устройств (ПМУ) на системном уровне, взаимодействие конечного пользователя и ПМУ можно разбить на следующие типы:
Взаимодействие с элементом UI (пользовательского интерфейса), который не предусматривает ввод данных (детерминированный элемент). В дальнейшем будем называть такой тип — «детерминированное действие» (ДД). Множество различных ДД напрямую зависит от разнообразия типов элементов интерфейса ПМУ и способов действия на них и является конечным числом.
Взаимодействие с элементом UI, который предусматривает ввод данных (поля ввода, формы и др.). В общем случае пользователь может ввести в приложение любой набор данных, это предполагает бесконечное число подобных действий ввода данных. Любое действие, связанное с вводом данных будем обозначать типом «вариационное действие» (ВД).
Определив конечный набор детерминированных действий, и ограничив бесконечный набор вариационных действий конечным набором, можно свести взаимодействие пользователя с ПМУ к детерминированному, конечному набору операций.
Во всех мобильных операционных системах (Android, iOS, Symbian, Blackberry и др.) существует определенный, конечный набор элементов пользовательского интерфейса. Большинство типов элементов одинаково для всех ОС, поэтому можно задать общий для всех операционных систем, конечный набор детерминированных действий.
В чём идея? — Конечный автомат (Finite-state machine)
Для каждой конкретной операционной системы данный набор может быть расширен с учетом элементов, не вошедших в пересечение элементов интерфейса всех операционных систем. Такой набор позволяет формально описывать взаимодействия типа «детерминированное действия» в унифицированном виде (в независимости от типа операционной системы).
Очевидно, что существует некоторое отображение элементов UI на действия, которые можно совершить с данными элементами. Обозначим его action(ed). Это отображение возвращает набор действий, которые применимы для данного элемента UI∙ed, который предполагает конечный, детерминированный набор действий с собой. Введенное отображение будет использовано позднее при определении расширенного конечного автомата для ПМУ.
В общем случае пользователь может ввести в приложение любой набор данных. Для ограничения данного числа наборов предлагается воспользоваться принципом эквивалентного разбиения вводимых данных [2]. В соответствии с этим принципом необходимо все данные, которые может ввести пользователь в данный набор элементов UI, предполагающих ввод данных разделить на несколько классов. На всех данных из заданного класса эквивалентности приложение ведет себя одинаково. Обозначим V = =v1,еv2. еvl) — набор всех вариационных элементов UI, которые видит пользователь в текущем состоянии приложения, evобозначает вариационный элемент UI, который предполагает ввод данных.
В общем случае число классов эквивалентности конечное число. Рассмотрим пример: допустим, в некотором состоянии приложения существует набор вариационных элементов интерфейса. В зависимости от данных, которые можно ввести получаем следующий набор классов эквивалентности.
Приложений для мобильных устройств разрабатываются с использованием принципа отделения логики работы приложения и представления (пользовательского интерфейса). Особенности данного принципа и рассматриваемая метрика тестирования ПМУ позволяют использовать конечные автоматы для формального описания прототипов приложений для мобильных устройств [3].
При анализе существующих мобильных приложений было выявлено, что количество основных видов приложений — конечное небольшое число (не более 100), но переход в каждый вид может зависеть от вводимых конечным пользователем данных. Возникает проблема «размножения» одинаковых видов при вводе «однотипных» данных. Действительно, допустим в данном виде существует некоторая форма ввода, которая принимает любые строковые значения на вход и после отправки данных «в приложение», происходит переход к следующему виду, в котором отображаются введенные данные. При построении соответствующего конечного автомата (КА) получаем бесконечное число состояний. Размножение числа состояний представлено на рисунке 1.
Рис. 1. Размножение состояний конечного аппарата
Решение этой проблемы состоит в разбиении всех вводимых данных на классы эквивалентности, это ограничит число «конечных» состояний. Вторая проблема, которая возникает при построении КА для ПМУ — зависимость «будущих» переходов от вводимых данных в «текущем» переходе. Например, в случае существования ролевой модели в приложении, переход к некоторым видам может быть «закрыт» для пользователей одних ролей и открыт для пользователей других ролей (рис. 2):
Рис. 2. Пример условия на переходе конечного автомата
При построении КА такого приложения возникает необходимость «запоминать» под каким пользователем мы вошли в систему и «проверять» запомненное значение при каждой попытке перейти в состояние, требующее определенных прав.
Решение этой проблемы состоит в разбиении всех вводимых данных на классы эквивалентности, это ограничит число «конечных» состояний. Вторая проблема, которая возникает при построении КА для ПМУ — зависимость «будущих» переходов от вводимых данных в «текущем» переходе.
Решение этой проблемы заключается в использовании расширенного конечного автомата для построения прототипа приложения. Такой способ задания КА позволит «запоминать» необходимые данные в виде параметров РКА и проверять значения этих параметров при переходе к «закрытым» страницам, предварительно задав условия на переходах.
«Расширенная конечно-автоматная модель — это усовершенствованная модель конечного автомата. В традиционном конечном автомате переход из состояния в состояние связан с набором входных булевых условий и набором выходных булевых функций. В расширенной модели переход может быть выражен «IF» выражением. Если все условия перехода соблюдены, то происходит переход, переводя автомат в следующее состояние, при этом производятся требуемые операции с данными» [3]. Формально: «расширенный конечный автомат — набор (S, V, P, s0, P0, I, n1, X, 0, n0, Y, T), где:
S — конечное множество состояний автомата;
V — множество, возможно бесконечное, значений внутренних данных автомата;
Р — отображение конечного набора [1..n] индексов в W,Р: [1..N] —>W; значение Р на индексе i называется значением i-ой переменной автомата, которое также обозначается рi.
s0 — элемент S, называемый начальным состоянием;
Р0 — отображение [1..n] индексов в W, называемое начальными значениями переменных;
I — конечное множество, элементы которого называются операциями или стимулами, само I называют входным алфавитом автомата;
n1 — отображение I в неотрицательные числа, определяет число параметров для каждого стимула;
X — множество, возможно бесконечное, значений параметров стимулов;
О — конечное множество, элементы которого называются реакциями, само О называют выходным алфавитом автомата;
n0 — отображение О в неотрицательные числа, определяет число параметров или данных каждой реакции;
Y — множество, возможно бесконечное, значений данных реакций;
Т — множество переходов автомата; каждый переход t включает начальное управляющее состояние s1, стимул I, условие перехода gt (guard condition) — предикат на множестве V n ×X n i, конечное управляющее состояние s2, и действие at — некоторое отображение V n ×X n i во множество V n , определяющее новые значения переменных.
Выполнение расширенного автомата отличается от выполнения обычного тем, что помимо текущего состояния имеются текущие значения переменных, при подаче стимула с набором аргументов охранное условие определяет, может ли быть выполнен данный переход при текущем наборе значений переменных и заданных значениях параметров стимула. Выполняемый переход выбирается не детерминировано из всех, помеченных данным стимулом, начинающихся в данном управляющем состоянии и имеющих выполненное охранное условие. При выполнении некоторого перехода новое управляющее состояние автомата равно конечному управляющему состоянию перехода, новые значения переменных определяются при помощи его действия — новое pi = at(p1. рn, х1. xn1), значения параметров реакции — по соответствующему отображению в переходе» [4].
1. Кабылова Д. А., Когай Г. Д., Ашимова Д. Е. Метрика тестового покрытия приложений для мобильных устройств: Тезис/Труды Международной научно-практической конференции «Интеграция науки, образования и производства — оснава реализации Плана нации», Караганда, КарГТУ 2016.
2. Степанченко И. В. Эквивалентное разбиение. Методы тестирования программного обеспечения: РПК «Политехник», Волгоград 2006.
3. Хатько Е. Е. Об одном методе тестирования «мобильных» приложений: Труды МФТИ, 2012 г.
Основные термины (генерируются автоматически): ввод данных, данные, переход, конечный набор, приложение, расширенный конечный автомат, действие, общий случай, операционная система, пользовательский интерфейс, решение этой, элемент.
Источник: moluch.ru
Тестирование и тест-дизайн. Основы функционального тестирования. Модульные тесты
1. Тестирование и тест-дизайн. Основы функционального тестирования. Модульные тесты.
2. 1.Тестирование и тест-дизайн.
• Любое тестирование, в том числе тестирование ПО это поиск багов.
• Баг — это отклонение фактического результата (неких
действий) от ожидаемого.
Чтобы проводить тестирование, нужно:
• 1. Узнать ожидаемый результат
• 2. Узнать фактический результат
• 3. Сравнить эти результаты
3.
• Например, нам нужно протестировать
пуленепробиваемое стекло. Ожидается, что его нельзя
пробить пулей. Чтобы протестировать, мы должны
попытаться опровергнуть это ожидание, то есть
выстрелить в стекло и узнать фактический
результат. Затем сравним его с ожидаемым: если пуля
пробила стекло, значит, найден баг.
Таким образом, для тестирования нужно еще выбрать
некоторое действие (в данном случае — выстрел), получаем,
что процесс тестирования состоит из четырех стадий:
• 1. Выбрать действие
• 2. Узнать ожидаемый результат этого действия
• 3. Узнать фактический результат
• 4. Сравнить эти результаты
4.
Первые две стадии относятся к тест-дизайну — написанию тестов.
• 1. Выбор действия (тестового сценария).
• Если у нас есть официальный документ с требованиями к продукту
(спецификация), то тестовые сценарии следует написать, исходя из
этих требований.
В хорошей спецификации основные сценарии использования (usecases) прописаны явно, в виде пошаговых инструкций, которые
можно использовать при тестировании «как есть».
Если спецификация не содержит пошаговых инструкций, а лишь
общие слова, дизайнер тестов должен написать такие инструкции
сам.
• Для более тщательного тестирования можно придумать свои
тестовые сценарии. Существует много разных техник выбора таких
сценариев.
5.
• 2. Информацию об ожидаемом результате, опять же, правильнее всего взять из
спецификации.
Если же в требованиях это не описано, можно использовать :
• 2.1. Авторитетное мнение (правильнее всего — того человека, который
составляет спецификации)
• 2.2. Устоявшиеся стандарты (официальные, например, RFC, или стандарты дефакто, например, то, что при нажатии правой кнопки мыши появляется
контекстное меню)
• 2.3. Здравый смысл
• 2.4. Заглянуть в код программы
• 2.5. Прочее
Последние две стадии — это собственно тестирование (прохождение тестов):
• 3. Узнать фактический результат мы можем, произведя действие, выбранное на
первом этапе.
• 4. После этого нам остается сравнить фактический результат с ожидаемым и
зарепортить баг в случае несоответствия.
6.
Например, проведем тестирование электрического чайника.
• 1. Какое действие покажет нам, работает ли чайник? Самое очевидное включить чайник.
• 2. Что мы примем за ожидаемый результат? Вероятно, то, что вода в
чайнике через определенное время вскипит.
• 3. Как мы узнаем фактический результат? Включим чайник и подождем
определенное время.
• 4. А теперь сравним фактический результат с ожидаемым. Здесь важен
вопрос — как понять, что вода вскипела? Нужен критерий соответствия
фактического результата и ожидаемого.
• Критерием может быть, например:
• а) Вода бурлит. Минус этого критерия — его нечеткость. Что значит
«бурлит»? Как сильно должна вода бурлить? Кроме того, критерий
пригоден только для тестирования с участием человека и практически
непригоден для автоматического тестирования. Основываясь на этом
критерии, сложно будет сделать чайник, который сам умеет отключаться.
• б) Температура воды достигла 99 градусов. Это уже более четкий критерий.
Если мы ждали достаточно долго, а вода так и не закипела, это означает, что
мы нашли баг.
7.
• Для тестировщика найденный баг — это всегда
праздник, потому что это значит, что результат
работы можно предъявить начальству.
• Не так важно количество найденных багов, как их
серьезность (severity). Серьезность определяется
тестовым сценарием, по результату которого был
найден баг.
8. Тестовая документация.
• Тестовая документация состоит обычно из отдельных
сценариев, которые называются тест-кейсами и могут быть
для удобства объединены в группы.
• Написание тестовой документации имеет много общего с
написанием ПО: следует разбивать код на отдельные модули
и избегать дублирования кода.
9. 2.1. Что должна содержать тестовая документация и почему.
• заголовок,
• пошаговое описание,
• ожидаемый результат,
• критерий соответствия ожидаемого результата
фактическому.
10.
11. Жизненный цикл бага.
• Итак, тесткейсы написаны, назначены тестировщикам и
пройдены. Тестировщик нашел некоторые баги при
прохождении тесткейсов, занес их в систему учета багов
(bug tracking system), например в Bugzilla, и пометил
тесткейсы в системе тестовой документации как
• 1) пройденные успешно,
• 2) пройденные с багами, или
• 3) заблокированные (невозможно пройти из-за более
общих багов).
12.
• Таким образом, баги чинятся не всегда. А если чинятся, то в
большинстве случаев тестировщик должен проверить,
действительно ли баг починили.
• Жизнь бага представляет собой довольно сложный и
разветвленный процесс. Чтобы было удобно этот процесс
контролировать, в системе учета багов каждый баг имеет
некий статус (состояние) и назначенного человека,
который должен заниматься этим багом.
• Баг может переходить из одного состояния в другое и от
одного человека к другому, пока не будет закрыт.
• В разных проектах жизненный цикл бага и список таких
состояний различен, но в основном используются
следующие состояния:
13.
• NEW — баг только что найден
• ASSIGNED — назначенный человек начал заниматься этим
багом
• RESOLVED — проблема решена (баг разрезолвен), это состояние
имеет несколько вариантов
• FIXED — баг починили
• DUPLICATE — такой баг уже был занесен в систему учета,
• INVALID — такое поведение системы является ожидаемым
• WORKSFORME — баг не удалось воспроизвести
• WONTFIX — баг признали багом, но фиксить не будут. такая
ситуация, как правило, возникает в случае несущественного
бага, требующего больших трудозатрат на починку, точнее в
случае слишком большого соотношения затрат к серьезности
бага (цена/качество). Такую резолюцию вправе устанавливать
на баг, как правило, только руководитель разработчиков или
руководитель проекта.
14. Основы функционального тестирования (Black-Box)
15. 1. Определение
Функциональное тестирование — это проверка ПО на правильность
функционирования в идеальных условиях, в отличие от
нефункционального, где либо условия неидеальны (нагрузочное
тестирование), либо тестируется не правильность
функционирования(тестирование удобства пользования или
структура программы).
Как правило, функциональное и нефункциональное тестирование
ПО можно проводить параллельно, поэтому обычно это делается
разными людьми или командами.
В большинстве источников указывается, что функциональное
тестирование — это синоним black-box тестирования (при котором
программа рассматривается как черный ящик).
16. Black-box, white-box, grey-box тестирование.
• По степени доступа к коду различают два типа тестирования:
тестирование «черного ящика» (black box), или функциональное
тестирование — без доступа к коду, и «белого ящика» (white box),
или структурное тестирование — тестирование кода.
• В случае «черного ящика» программа рассматривается как
конечный автомат, с входными и выходными данными, набором
внутренних состояний и переходов между ними.
• В случае «белого ящика» тестировщик пишет тесткейсы,
основываясь исключительно на коде программы (тесты на
правильность кода).
• Расширение black-box тестирования, в котором также
применяется изучение кода, называется тестированием «серого
ящика» (grey box).
17. Тестирование сценариев использования — юз-кейсов (use-cases)
Тестирование сценариев использования — юзкейсов (use-cases)
• Чтобы уменьшить число тестов, можно проверить только те
переходы, которые имеют смысл для пользователя.
• Use-case — это логически завершенная последовательность
действий.
• Тестирование сценариев является самым необходимым видом
тестирования. Программа должна выполнять операции, для
которых она предназначена. Если пользователь может выбрать
пункт меню, но файл не открывается — это очень серьезный баг.
18.
• Главным минусом Black-box тестирования является то, что
тестировщик не знает, какую часть ПО он тестирует. Некоторые
существующие пути в программе (о которых нет информации
ни в требованиях, ни в документации), могут никогда не быть
проверены. Уменьшить количество таких путей можно путем
анализа внутреннего устройства программы.
19. Взаимосвязь разработки и тестирования (V-диаграмма)
Павловская Т.А. (СПбГУ ИТМО)
19
20. Модульное тестирование (Unit testing)
• Модульное тестирование — это тестирование программы на уровне
отдельно взятых модулей, функций или классов.
• Цель модульного тестирования состоит в выявлении локализованных
в модуле ошибок в реализации алгоритмов, а также в определении
степени готовности системы к переходу на следующий уровень
разработки и тестирования.
• Модульное тестирование чаще всего проводится по принципу
«белого ящика“.
21. Обнаруживаемые ошибки
• На уровне модульного тестирования проще всего обнаружить
дефекты, связанные с алгоритмическими ошибками и ошибками
кодирования алгоритмов.
• Ошибки, связанные с неверной трактовкой данных, некорректной
реализацией интерфейсов, совместимостью, производительностью
и т.п. обычно выявляются на более поздних стадиях тестирования.
Источник: ppt-online.org
Русские Блоги
[Тестирование программного обеспечения] тестирование черного ящика
1. Обзор тестирования черного ящика
Тестирование черного ящика также называется функциональным тестированием или тестированием на основе данных. Это функция, которой должен обладать известный продукт. Он тестируется, чтобы определить, может ли каждая функция использоваться нормально. При тестировании программа рассматривается как черный ящик, который нельзя открыть.
Без учета внутренней структуры и внутренних характеристик программы тестировщик выполняет тест интерфейса программы. Он только проверяет, нормально ли работает программа в соответствии с требованиями. Используйте, может ли программа правильно получать входные данные для генерации правильной выходной информации и поддерживать целостность внешней информации (такой как базы данных или файлы), как показано на рисунке.
Тестирование черного ящика в основном используется для обнаружения следующих ситуаций
① Есть ли некорректная или отсутствующая функция
② Можно ли правильно принять входные данные в интерфейсе и правильно ли сгенерировать выходную информацию?
③Бывают ли ошибки при доступе к внешней информации?
④Соответствует ли производительность требованиям
⑤ Неправильный интерфейс или некрасивый
⑥ Ошибка инициализации или завершения
Метод тестирования черного ящика
Разделение классов эквивалентности Анализ граничных значений Метод таблицы решений Диаграмма причинно-следственной связи Метод сцены Ортогональный тест Карта функций Неправильные предположения
1. Метод разделения классов эквивалентности
Основная идея состоит в том, чтобы разделить все возможные входные данные, то есть поле ввода программы, на несколько частей (подмножеств), а затем выбрать несколько репрезентативных данных из каждого подмножества в качестве тестовых примеров. Этот метод является важным и часто используемым методом разработки тестовых случаев в виде черного ящика.
Класс эквивалентности можно разделить на две разные ситуации: допустимый класс эквивалентности и недопустимый класс эквивалентности.
Класс эффективной эквивалентности: набор значимых и разумных входных данных. Вы можете проверить, выполняет ли программа функции и производительность, указанные в спецификации.
Недопустимый класс эквивалентности. Определение эффективного класса эквивалентности прямо противоположно.
При разработке тестовых примеровРассмотрим оба класса эквивалентности. Потому что программное обеспечение должно не только получать разумные данные, но и выдерживать неожиданные тесты. Только благодаря положительным и отрицательным тестам программное обеспечение может быть более надежным.
Шаги по разработке тестовых случаев:
1) Разделите классы эквивалентности: сначала рассмотрите, является ли тип данных допустимым, а затем рассмотрите, допустим ли диапазон данных.
2) Создайте таблицу эквивалентных классов: перечислите все эквивалентные классы и пронумеруйте каждый эквивалентный класс.
3) Разработайте тестовые примеры, чтобы максимально охватить все классы эквивалентности.
Проблема с NexDate
1) Описание заголовка:
Функция NextDate содержит три переменные: месяц, день и год. Результатом функции является дата, которая наступает через день после даты ввода. Например, если на входе 16 мая 1989 года, на выходе функции будет 17 мая 1989 года. Требуется, чтобы входные переменные month, day и year были целочисленными значениями и удовлетворяли следующим условиям, что является допустимым классом эквивалентности:
Студентам предлагается разработать контрольные примеры в соответствии с методом разделения классов эквивалентности.
2) Вопрос-ответ:
- Класс эквивалентности
- Разработка тестовых примеров для классов эквивалентности
2. Метод анализа граничных значений
Определение: Метод анализа граничных значений — это метод испытания методом черного ящика для проверки граничного значения ввода или вывода. Обычно метод анализа граничных значений используется в качестве дополнения к методу разделения классов эквивалентности, в этом случае тестовые примеры исходят из границы класса эквивалентности.
Отличие от деления эквивалентности : 1) Анализ граничных значений заключается не в случайном выборе одного из классов эквивалентности в качестве репрезентативного, а в том, чтобы сделать каждую границу класса эквивалентности в качестве условия проверки.
2) Анализ граничных значений учитывает не только входные условия, но и тестовые условия, создаваемые выходным пространством.
Метод проектирования: 1) Определить граничное условие (граница входного или выходного класса эквивалентности)
2) Выберите в качестве тестовых данных точно равное, чуть больше или чуть меньше граничного значения.
Принципы анализа граничных значений:
(1) Если условие ввода определяет диапазон значений, значение, которое только что достигло границы этого диапазона, и значение, которое только что вышло за границу этого диапазона, должно использоваться в качестве тестовых входных данных.
(2) Если входные условия определяют количество значений, используйте в качестве теста максимальное количество, минимальное количество, на единицу меньше минимального числа и на единицу больше максимального числа. данные.
(3) Примените правила 1) и 2) к условиям вывода, то есть спроектируйте тестовые случаи так, чтобы выходное значение достигло граничного значения и значения вокруг него.
(4) Если поле ввода или поле вывода, указанное в спецификации программы, является упорядоченным набором, первый и последний элементы набора должны быть выбраны в качестве тестовых примеров.
(5) Если в программе используется внутренняя структура данных, значение на границе этой внутренней структуры данных должно быть выбрано в качестве тестового примера.
(6) Проанализируйте спецификации и найдите другие возможные граничные условия.
3. Таблица решений / метод таблицы решений
Таблица оценок состоит из двух частей: «условия и действия», то есть в ней перечисляется комбинация условий, необходимых для выполнения тестового действия. Все возможные комбинации условий определяют ряд вариантов, и тестовое действие должно учитывать каждый выбор.
Элементы таблицы решений:
⦁ Заготовка с условием: перечислить все условия проблемы.
⦁ Заготовка действий: список действий, которые могут быть предприняты в ответ на проблему.
⦁ Элемент условия: конкретное назначение для перечисленных условий
⦁ Элементы действий: перечислите действия, которые должны быть выполнены при сочетании элементов условий (различных значений).
⦁ Правило: конкретное значение любой комбинации условий и соответствующей операции, которую необходимо выполнить.
Шаги метода таблицы решений
⦁ Список всех ставок условий и действий;
⦁ Заполните элементы условий;
⦁ Заполните элементы действий и составьте таблицу первоначального суждения;
⦁ Упростите, объедините похожие правила или одинаковые действия
4. Диаграмма причинно-следственной связи
Комбинация нескольких входных условий дает несколько результатов для разработки тестовых примеров.
Метод проектирования:
1) Проанализируйте, что является причиной (условие ввода), а какое является результатом (условие вывода), описанным в документе спецификации программного обеспечения, и назначьте идентификатор каждой причине и результату.
2) Выясните причину и следствие, соответствующие отношения между причиной и причиной, нарисуйте диаграмму причин и следствий.
3) Отметьте невозможные причинно-следственные связи на причинно-следственной диаграмме, чтобы указать ограничения или ограничения.
4) В соответствии с диаграммой причин и следствий создайте таблицу оценок, чтобы очень конкретно и четко выразить сложную логическую взаимосвязь и комбинацию нескольких условий.
5) Разработайте тестовые примеры на основе каждого столбца оценочной таблицы.
Компенсация за халатность ежегодных и не годовых сотрудников
1) Описание заголовка
В спецификации требований для модуля определенного программного обеспечения описываются:
(1) Сотрудники системы годовой заработной платы: за серьезную халатность вычитается 4% риска на конец года; за небрежность вычитается 2% риска на конец года.
(2) Сотрудники негодовой системы оплаты труда: за серьезную халатность вычитается 8% из заработной платы текущего месяца; за небрежность вычитается 4% из зарплаты текущего месяца.
Нарисуйте причинно-следственную диаграмму и таблицу оценок и приведите соответствующие тестовые примеры.
2) Вопрос-ответ:
- Анализ вопроса показывает:
- Диаграмма причин и следствий выглядит следующим образом:
- Преобразуйте диаграмму причин и следствий в таблицу решений:
- Прецедент
5. Сюжетный метод
Сценарий варианта использования используется для описания пути, который проходит через вариант использования, проходя все основные потоки и альтернативные потоки на этом пути от начала до конца варианта использования.
Шаги по разработке тестовых случаев с использованием сценарного метода:
1) Определите элементы данных, необходимые для выполнения сценария варианта использования.
2) Построить матрицу
⦁ Определите содержимое столбца: помимо элементов данных, необходимых для выполнения сценария, он также должен включать идентификатор тестового набора, идентификатор или имя тестируемого сценария.
⦁ Определите содержимое строки:
⦁ В соответствии с каждым сценарием определите соответствующие входные элементы тестового набора. При разработке убедитесь, что каждый сценарий содержит по крайней мере один положительный тестовый пример и один отрицательный тестовый набор.
⦁ В соответствии с характеристиками тестируемой сцены дополнить соответствующими тестовыми случаями
Варианты использования газовых карт
1. Описание заголовка
Используйте газовую карту для заправки на заправочной станции. Пользователь показывает газовую карту, вставляет ее в машину и информацию о считывании карты, чтобы проверить, находится ли она в черном списке карт. Путем проверки количества топлива, введенного пользователем, система проверяет, соответствует ли количество топлива требованиям.После заправки топлива создается баланс карты, и карта закрывается. Метод сценария необходим для разработки тестовых случаев.
2. Вопрос-ответ
- Дизайн сценария использования
- Дизайн данных
6. Метод функциональной диаграммы
⦁ Метод функциональной диаграммы — это метод разработки тестовых примеров для решения задачи динамического описания.
⦁ Функциональная диаграмма состоит из диаграммы перехода состояний (STD) и модели логической функции (LFM).
⦁ Диаграмма перехода состояний: используется для представления последовательности входных данных и соответствующих выходных данных, выходные данные и последующие состояния определяются входом и текущим состоянием.
Таблица логических функций: используется для обозначения соответствующей связи между условиями ввода состояния и условиями вывода.
Источник: russianblogs.com