Без рисунков до нас бы не дошли сведения о древних людях, знания не передавались бы, а язык не эволюционировал.
Графические иллюстрации и диаграммы находят свое место в мире высокоразвитого письма и словесного выражения. В частности, их широко применяют в технологической индустрии. В этой статье представлены самые распространенные диаграммы, с которыми работают тестировщики ПО.
#1) Блок-схема
Блок-схемы лучше всего описывают определенные процессы. В них используются специальные символы для каждого задания/действия, которые происходят в рамках процессов. Обычно они содержатся в плане тестирования ПО и прочей документации (BRD, FRD).
Распространенные символы и их значение:
Овал — старт и стоп
Прямоугольник — действие или задание
Ромб — решения
Блок-схема — это справочник, который быстро знакомит с программным продуктом. Вот несколько способов применения этой диаграммы.
а) Блок-схема для анализа потока управления и статистики
Цикломатическая сложность — это метрика, которая позволяет определить сложность конкретной программы. Она дает возможность понять, сколько требуется времени на функциональное тестирование до полного покрытия.
Алгоритм. Трассировка. Тестирование. Блок-схема|| информатика 8 класс
Просто создайте блок-схему, как показано ниже, и используйте эту формулу:
Цикломатическая сложность: = Число соединений или линий – количество узлов + 2
Узлов — 7, соединений тоже — 7.
Таким образом, цикломатическая сложность: 7-7+2= 2.
б) Блок-схема для иллюстрации процесса:
Ниже процесс дефект-треккинга представлен в формате блок-схемы. Здесь все также предельно просто:
#2) Диаграмма переходов
Таблицы или диаграммы переходов — аналитические инструменты для комплексных систем, в которых происходит множество переходов из одного состояния в другое. Эти переходы можно сравнить с работой выключателя освещения: вкл/выкл.
Переходные состояния демонстрируют в виде таблицы или диаграммы.
Рассмотрим пример посложнее. Пусть это будет система выдачи балетов.
Пример. Билет, который выдается посредством приложения. Первая часть процесса может включать навигацию в системе через несколько страниц:
Страница 1-> Выберите количество пассажиров — взрослые, дети и люди старшего возраста.
Страница 2-> Выберите тип билета: суточный пропуск, недельный, месячный и т.д.
Как быстро нарисовать блок-схемы бизнес-процессов для технического задания CRM
Страница 3-> Проверка деталей.
Страница 4-> Платеж, и т.д.
Таким образом, может быть много переходов с одной страницы на другую. Диаграммы переходов обычно создаются не для иллюстрации визуальных переходов (это применяется редко), а ключевых элементов системы.
На диаграмме будут видны тестовые сценарии и трансакции пользователей:
Три желтых линии — это три end-to-end кейса, которые охватывают самые важные и часто используемые зоны приложения. Это полезный инструмент для создания тест-кейсов.
#3) Контекстная диаграмма
Приложения редко функционируют как независимые системы. Простые программы (калькуляторы, блокноты и прочие) могут работать сами по себе, но корпоративные приложения чаще совмещаются с другими программными продуктами.
К примету, с зарплатной ведомостью можно работать в бухгалтерском приложении, системе учета человеко-часов и HR-порталах. Контекстная диаграмма наглядно показывает все эти взаимосвязи.
Ниже представлена контекстная диаграмма для системы начисления зарплаты:
Четко виден контекст определенной системы и как с ней соотносятся другие объекты. Эти диаграммы помогают тестировщикам понять систему в более широком смысле; составлять стратегии тестирования, которые включают все эти входящие и исходящие связи с другими объектами. Обычно если во время тестирования представляется возможным составить контекстную диаграмму, это упрощает понимание.
#4) Диаграмма связей:
Каждая идея развивается с добавлением дополнительных нюансов. А с помощью такой диаграммы можно все это отслеживать. Этот вид диаграммы предназначен для начального этапа — проиллюстрировать главную идею и записать каждую производную.
Диаграммы связей используются практически для всего.
Они популярны в индустрии программного обеспечения. К примеру, помогают отслеживать ход исследовательского тестирования. (В случае, если применяется agile, rapid development и другие быстрые методологии разработки ПО).
Пример. Диаграмма для e-commerce-приложения, где отслеживаются следующие аспекты:
Начните с основной идеи, отправной точки — и добавляйте другие. Существует множество удобных (и бесплатных) онлайн-инструментов для создания диаграмм. Например, mindmup.com.
#5) ER-диаграммы (сущность-связь)
ER-диаграммы используются для проектирования баз данных. Они показывают сущности базы данных и их взаимосвязи. Такие диаграммы на начальном этапе выполняют иллюстративную функцию.
Есть множество вариантов ER-диаграмм, простейшая выглядит примерно так:
#6) Бонус: макет
Простые изображения (скриншоты), которые показывают будущую UI-страницу/компонент в диаграмме. Макеты очень помогают в тестировании, т.к. с их помощью можно составить представление о конечном продукте. Таким образом, улучшается проектирование и анализ теста. Как следствие, выше эффективность тестирования.
Это могут быть простые, нарисованные от руки изображения, схемы веб-страниц, или любые другие диаграммы, которые показывают, как будет выглядеть конечный продукт.
Простая схема экрана логина может быть такой:
В большинстве случаев тестировщикам приходится расшифровывать диаграммы, реже — создавать их собственноручно. MS Visio и SmartDraw — полезные инструменты, но если ищете бесплатный и простой инструмент — можете воспользоваться draw.io.
Если у нет доступа к сети, придется взять в руки фломастер и нарисовать диаграмму вручную. Это несколько трудоемкий способ, но от этого не менее эффективный.[/fusion_text]
Источник: getbug.ru
Обобщенная блок-схема алгоритма работы тестера ИМС (блок-схема алгоритма работы тестера). Разработка детальной блок-схемы алгоритма тестирования ИМС , страница 9
Примем tвнутр.цикла = 500 мкс, t внеш.цикла = 20 мс. Необходимо определить значения переменных EXTR и INTR, задающие, соответственно, tвнутр.цикла и tвнеш.цикла. Можно записать:
tвнутр.цикла = 2*3мкс* INTR = 6мкс * INTR.
INTR = 500 мкс / 6 мкс = 83, 33 = 53Н.
Для времени внешнего цикла:
t внеш.цикла = ( 2+ 2+ 2) * 3мкс + [(2+2)*3мкс + 500]*EXTR = 18мкс+ 512мкс *EXTR.
EXTR = ( 20 – 0,018)мс/ 512 мс = 39,03 = 27Н
Рис. 8. Блок – схема алгоритма подпрограммы тестирования ИМС К155ЛА1
3.5.3. Программа работы прибора на языке Ассемблера
INTR EQU 53H ; Времязадающие константы
EXTR EQU 27H ; для подпрограммы DELAY
ORG 0000H ; Начальный адрес программы
MOV P3, #1FH ; Выключить индикаторы
MOV SP, #70H ; Определить стек
READY: SETB P3.5 ; Включить индикатор «ГОТОВ»
WAIT1: JB P3.3, WAIT1 ; Ожидание нажатия кнопки «ТЕСТ»
CALL DELAY ; Вызов подпрограммы задержки
WAIT2: JNB P3.3, WAIT2 ; Ожидание отжатия кнопки «ТЕСТ»
CLR P3.5 ; Погасить индикатор «ГОТОВ»
MOV A, P0 ; Ввод кода номера ИМС
CPL A ; Получить прямой код номера N
CJNE A, #0, NEXT1 ; Номер ИМС N=00?
CALL TEST00 ; Да, вызов подпрограммы тестирования
JMP CHECK ; Переход на метку CHECK
NEXT1: CJNE A, #1, NEXT2 ; Номер ИМС N=01?
CALL TEST01 ; Да, вызов подпрограммы тестирования
: ; Проверка остальных ИМС
NEXT98: CJNE A, #98, NEXT99 ; Номер ИМС N=98?
CALL TEST98 ; Да, вызов подпрограммы тестирования
NEXT99: CALL TEST99 ; Да, вызов подпрограммы тестирования
; Проверка результата тестирования
CHECK: JB F0, NORM ; Переход, если F0=1 (НОРМА)
SETB P3.7 ; Включить индикатор «БРАК»
NORM: SETB P3.6 ; Включить индикатор «НОРМА»
WAIT3: JB P3.4, WAIT3 ; Ожидание нажатия кнопки «СБРОС»
CALL DELAY ; Вызов подпрограммы задержки
WAIT4: JNB P3.4, WAIT4 ; Ожидание отжатия кнопки «СБРОС»
; Установка портов Р1, Р2, Р3 на ввод, гашение всех индикаторов
JMP READY ; Переход в исходное состояние
; DELAY – подпрограмма временной задержки на 20мс
; Входные параметры: константы INTR, EXTR
DELAY: MOV R6, # EXTR ; Загрузка
LOOP2: MOV R7, # INTR ; времязадающих констант
LOOP1: DJNZ R7, LOOP1 ; Цикл, если (R7) 0
DJNZ R6, LOOP2 ; Цикл, если (R6) 0
RET ; Возврат из подпрограммы
; TEST01 – подпрограмма тестирования ИМС К155ЛА1 с номером N=01
; Выходной параметр: флаг F0 – при F0 = 1 результат тестирования
; положительный (НОРМА), при F0 = 0 – отрицательный (БРАК)
CALL DELAY ; Вызов подпрограммы задержки
MOV R2, # 0FH ; Загрузить счетчик состояний
MOV R0, # 0 ; В (R0)– начальное значение входного
Источник: vunivere.ru
Таблица решений для тестирования алгоритмов
В предыдущих статьях Таблица решений для тестирования фильтрации с зависимыми фильтрами и Таблица решений для тестирования сложных форм были описаны варианты применения техники тест-дизайна «Таблица решений» для тестирования фильтрации и сложных веб-форм.
В этой статье я хочу показать, как эту технику можно применять для тестирования алгоритмов, в том числе и алгоритмов с приоритетом выбора данных.
Алгоритмы могут быть не очень сложными и на такие алгоритмы тест-дизайн в виде «таблицы решений» делать достаточно быстро. Ниже для примера представлено два простых алгоритма и «таблицы решений» для них.
Пример 1: Алгоритм расчета итоговой стоимости товара с учетом скидки в зависимости от общей стоимости выбранного товара
Ниже представлена «таблица решений» для этого алгоритма.
Пример 2: Алгоритм определения возможности возврата/обмена или ремонта товара
Ниже представлена «таблица решений» для этого алгоритма.
Но на любом крупном проекте алгоритмы имеют очень сложную бизнес-логику и тест-дизайн для них выглядит намного масштабнее.
Один из самых сложных тест-дизайнов в виде «таблицы решений», которые мне приходилось делать для алгоритмов – был тест-дизайн для алгоритма выбора «приоритетного диапазона цен».
Пример 3: Алгоритм выбора «приоритетного диапазона цен».
Сначала кратко опишу суть этого алгоритма.
Есть сущность «Торговая точка» (сокращенно ТТ), у которой в карточке могут быть заполнены (не обязательные) поля:
Но если не заполнена страна, то регион тоже не заполнен.
Есть сущность «Диапазон цен», у которой в карточке также могут быть заполнены (не обязательные) поля:
Также для «Диапазона цен» указывают тип ценника («обычный» (без акции), «по акции»).
Для выбора приоритетного «Диапазона цен» есть следующие уровни приоритета:
- 1 уровень: Для ТТ и «Диапазона цен» данные совпадают по «Страна + Регион + Сегмент + Ритейлер»
- 2 уровень: Для ТТ и «Диапазона цен» данные совпадают по «Страна + Сегмент + Ритейлер»
- 3 уровень: Для ТТ и «Диапазона цен» данные совпадают по «Сегмент + Ритейлер»
- 4 уровень: Для ТТ и «Диапазона цен» данные совпадают по «Страна + Регион + Ритейлер»
- 5 уровень: Для ТТ и «Диапазона цен» данные совпадают по «Страна + Ритейлер»
- …
- 11 уровень: Для ТТ и «Диапазона цен» данные совпадают по «Страна»
- 12 уровень: Для ТТ и «Диапазона цен» не заполнены поля Страна, Регион, Ритейлер, Сегмент
Т.е. в коде выбор «Диапазона цен» идет с более верхнего уровня на более нижний, пока не будет совпадения по заполненным полям для ТТ и «Диапазона цен».
Если в поле одной из сущностей не выбрано значение, то при сравнении с ним подходит любое значение в аналогичном поле другой сущности.
Алгоритм отрабатывает на лету при выполнении GET-запроса для отдельной ТТ, в результате чего в ответе запроса должны быть только два «Диапазона цен» типов «обычный» и «по акции» для каждого продукта из списка продуктов.
Для тест-дизайна этого алгоритма я применила технику «Таблица решений», но немного необычным способом, так как тут нужно протестировать, что выбор будет идти именно с 1 по 12 уровень по порядку, указанному выше.
Сначала нужно было понять, какие есть варианты данных.
Для каждого из 4 полей ТТ значение либо будет выбрано, либо нет. Значит может быть по 2 варианта для каждого их 4 полей, значит всего вариантов 2*2*2*2 = 16. Но так как есть условие, что если не заполнена страна, то регион тоже не заполнен, то 4 варианта для ТТ исключаются (выделены красными квадратами). Поэтому в итоге всего 12 вариантов заполнения нужных полей карточки ТТ.
Так как вариантов данных для тестов при сравнении заполнения полей ТТ и «Диапазона цен» получится очень много, то я сразу решила разделить данные как раз на 12 отдельных таблиц (одна таблица для одного варианта заполнения полей карточки ТТ).
Т.е. для первой таблицы во всех тестах будет идти набор данных для ТТ, когда все поля «Страна», «Регион», «Ритейлер», «Сегмент» заполнены. Для следующей таблицы – следующий набор данных для ТТ.
Эти 4 поля для ТТ я первыми добавила в таблицу в самом верху блока условий.
Дальше уже нужно было определиться с вариантами данных для «Диапазона цен». У «Диапазона цен» есть те же 4 поля с данными. Но так как в коде они еще и сравниваются с полями карточки ТТ, то для «Диапазона цен» уже будет три варианта значений для каждого поля:
- пусто
- заполнено и имеет такое же значение, как в карточке ТТ (в таблице “Да(заполнено)”)
- заполнено и имеет другое значение, чем в карточке ТТ (в таблице “Нет(заполнено)”)
Эти 4 поля для «Диапазона цен» я добавила следующими в таблицу в блок условий. Но пока не стала проставлять сразу значения, так как нужно было еще учесть как-то условие приоритета выбора «Диапазона цен» в зависимости от уровня, на котором получилось совпадение данных в полях карточки ТТ и «Диапазона цен». Для этого под уже добавленными полями я сразу добавила строку «Пункт из списка приоритетов», где проставила значения для каждого уровня, начиная с 1 и по 12 уровень.
Затем я уже размножала для каждого уровня 1-12 столбики таблицы и смотрела какие комбинации данных в 4 полях для «Диапазона цен» могут быть из возможных значений.
При составлении тестов были покрыты все возможные комбинации для заполнения полей ТТ и «Диапазона цен», а также их равенства или отличия при сравнении. При этом повторяющиеся тесты были удалены из этих 12 таблиц для сокращения тестов. Еще больше урезать тесты уже не стала, так как для этого алгоритма нужно было хорошее покрытие, чтобы была уверенность в точности выбора именно требуемого «Диапазона цен» в каждом из возможных наборов данных.
В итоге получилось 12 таблиц, в каждой из которых было по 44 теста, т.е. 528 тестов для проверки этого алгоритма.
Пример таблицы №1: Для ТТ заполнены все поля «Страна», «Регион», «Ритейлер», «Сегмент»:
Пример таблицы №6: Для ТТ заполнены только поля «Страна» и «Сегмент»:
Тесты по таким таблицам я проводила следующим образом:
- Подготовила 12 ТТ с разным заполнением данных в карточке согласно тест-дизайну
- Для каждого теста создала по «Диапазону цен» каждого типа «обычный» и «по акции» и прописала в таблицах их id.
- Затем делала GET-запрос для каждой ТТ и проверяла, что в его ответе выводятся два нужных «Диапазона цен» и не выводятся другие (для каждой из 12 таблиц — свои)
- Потом удаляла первые два «Диапазона цен» из базы
- Снова делала GET-запрос для каждой ТТ и проверяла, что в его ответе выводятся два нужных «Диапазона цен» и не выводятся другие (для каждой из 12 таблиц — свои)
- Потом удаляла следующие два «Диапазона цен» из базы
- Снова делала GET-запрос для каждой ТТ и проверяла, что в его ответе выводятся два нужных «Диапазона цен» и не выводятся другие (для каждой из 12 таблиц — свои)
- Потом удаляла следующие два «Диапазона цен» из базы
- И т.д.
При этом «Диапазоны цен», которые должны были пропускаться во всех тестах (ячейки выделены светло-синим) не удалялись во время тестов, так как их наличие никак не должно было влиять на данные в ответе GET-запроса.
Конечно составить такую таблицу было не просто, так как сначала нужно было продумать все параметры, которые нужно учесть, а также все варианты их значений.
Также тут важно было сразу разделить тесты на несколько таблиц, так как сразу было понятно, что тестов получится очень много, и есть параметр, по которому можно сделать такое разделение. Это уменьшило количество тестов в одной таблице и облегчало ее поддержку в будущем, а также возможность расширения тестов при добавлении новых параметров.
На такой тест-дизайн я потратила в общей сложности примерно 3 дня. Но после этого неоднократно использовала эти таблицы на ретестах после доработок этого алгоритма. Также все тесты из этих таблиц были достаточно быстро покрыты автотестами.
Для таблиц из примеров выше в следующих доработках были добавлены еще параметры, что еще больше увеличило количество тестов в каждой из 12 таблиц. Но времени на расширение было потрачено мало, так как изначально формат таблицы и набор параметров были выбраны удачно.
Надеюсь, что пример такого тест-дизайна вдохновит кого-то и на своем проекте начать применять технику тест-дизайна «Таблицы решений» для алгоритмов. Особенно это удобно на проектах со сложной бизнес-логикой, когда много условий и достаточно много тестов, которые сложно удержать в голове или долго описывать в более подробном формате в виде тест-кейсов, а также, если для фич постоянно добавляют новые параметры.
- тестирование
- тестирование веб-приложений
- тестирование мобильных приложений
- тестирование сайтов
- тест-дизайн
- таблицы решений
- Тестирование IT-систем
- Тестирование веб-сервисов
- Тестирование мобильных приложений
Источник: habr.com