Реферат. Индивидуальное задание. Техники создания тесткейсов
 Скачать 133.55 Kb.
|
|
ГОУ ВПО ЛНР «ЛУГАНСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ имени ВЛАДИМИРА ДАЛЯ» Кафедра информатики и программной инженерии ИНДИВИДУАЛЬНОЕ ЗАДАНИЕ по дисциплине «Качество программного обеспечения» на тему: «Техники создания тест-кейсов» Выполнил студент гр. ИТ-601М Капустин Богдан Юрьевич Принял старший преподаватель Сычёв Евгений Владимирович Луганск 2021 Содержание1Техники создания тест-кейсов 3 1.1.Проектирование и исполнение 9 2Методология черного ящика 11 Список использованных источников 15 Техники создания тест-кейсовПри создании IT-продукта большую роль играет обеспечение качества – Quality Assurance (QA). Для того, чтобы устранять ошибки и «баги», QA-инженеры в числе прочих инструментов применяют техники тест-дизайна. Тест-дизайн – это разработка, создание тестов. Каждый тест направлен на проверку конкретного предположения. Например: «Что будет, если пользователь по ошибке кликнет здесь не левой, а правой кнопкой мыши». QA моделирует набор тестовых случаев (тест-кейсов), чтобы проверить, как приложение ведет себя в разных условиях. Задача специалиста – найти баланс и выявить максимальное количество ошибок при необходимом минимуме тестовых сценариев. При этом нужно проверить все наиболее важные кейсы, поскольку время тестирования ограничено. Типы тестирования Статическое тестирование, как следует из названия, не требует запуска программы или приложения, оно позволяет находить самые очевидные ошибки еще на ранних этапах создания продукта. Например, частью статического тестирования является проверка параметров ПО на соответствие требованиям технического задания, вычитка кода. Динамическое тестирование требуется для проверки ПО в действии. Этот вид, в свою очередь, также делится на две обширные группы: Техники белого ящика (они же структурное тестирование) применяют в том случае, если специалист хорошо знает архитектуру продукта, его код, «начинку» – то есть может ориентироваться в самой программе. Техники черного ящика позволяют проверять работу продукта, не зная внутреннего устройства системы. При этом тестирование проводится на основе требований, указанных в спецификации проекта или в ТЗ. Техники серого ящика позволяют тестировать продукт, когда специалист частично знает его внутреннее устройство. Для выполнения тестирования «серого ящика» не нужен доступ к исходному коду. Этапы тестирования 1. Подготовка. На этом этапе QA-инженер читает проектную документацию, выясняет требования к продукту, прорабатывает план, продумывает стратегию, расставляет задачи по приоритетности и анализирует возможные риски. 2. Непосредственно тестирование. Предварительно специалисты анализируют собранную ранее информацию, составляют список тестируемых функций, знакомятся с уже известными багами, если они есть, пишут тест-кейсы. 3. Анализ результатов и составление отчетов. При работе над созданием тестов QA-специалист ориентируется не только на документацию, но и на устные сведения от других QA, аналитиков, разработчиков, менеджеров проекта. Рассмотрим несколько основных методик, однако зачастую их используют в комплексе. Одной техники может быть недостаточно, поскольку она не обеспечит максимальный охват тестовых сценариев. Эквивалентное разбиение Метод эквивалентного разбиения позволяет минимизировать число тестов, не создавая сценарий для каждого возможного значения, а выбрав только одно значение из целого класса и приняв за аксиому, что для всех значений в данной группе результат будет аналогичным. Например, при тестировании функциональности приложения, позволяющего покупать авиа - и железнодорожные билеты онлайн. Стоимость билета будет зависеть от возраста пассажира, так как дети, студенты и пенсионеры относятся к льготным категориям. То есть всего четыре возрастных группы: младше 15 лет, от 15 до 25 лет, старше 25 и младше 60 лет и люди старше 60. При этом в поле для ввода возраста помещается всего два символа, поэтому указать возраст более 99 лет технически невозможно. QA-специалисту не нужно писать 99 тестов для каждого возраста, хватит пяти: по одному для каждой возрастной группы (скажем, 10, 18, 35 и 75 лет) и один для случая, если возраст человека превышает 99 лет. Да, последний тест на практике невыполним (поскольку в поле возраста невозможно ввести более двух знаков), и все же не следует забывать об этой проверке. Данный тест показан на рис.1.  Рисунок 1 – Эквивалентное разбиение по возрасту Граничные значения Техника граничных значений основана на предположении, что большинство ошибок может возникнуть на границах эквивалентных классов. Она тесно связана с вышеописанной техникой эквивалентного разбиения, из-за чего часто используется с ней в паре. Тогда для примера из предыдущего пункта границами будут являться значения 0, 15, 25, 60 и 99. Граничными значениями будут 0, 1, 14, 15, 16, 24, 25, 26, 59, 60, 61, 98, 99, 100. Данный тест показан на рис.2.  Рисунок 1 – Граничные значения по возрасту Часто сложности возникают, если возрастные категории указаны «внахлест», например, 0-12, 12-25 лет и т.д. Таблица принятия решений Другое название метода – матрица принятия решений. Эта техника подходит для более сложных систем, например – двухфакторной аутентификации. Предположим, чтобы войти в систему, пользователю нужно ввести сначала логин и пароль, а затем еще подтвердить свою личность присланным в смс кодом. Какие возможны сценарии: 1. Правильный логин и правильный пароль. 2. Правильный логин, неправильный пароль. 3. Неправильный логин, правильный пароль. 4. Неправильный логин, неправильный пароль. Первый из этих сценариев сопровождается либо правильным, либо неправильным вводом смс-кода, итого получается 5 тестов. При этом только один из сценариев приведет к положительному результату (пользователь успешно авторизуется), а остальные закончатся неудачей. Однако, может быть так, что система выдает разные сообщения в зависимости от того, на каком этапе была допущена ошибка, скажем: invalid login, invalid password. Соответственно, групп потребуется больше, а таблица станет обширнее. Этот метод хорош тем, что он показывает сразу все возможные сценарии в форме, понятной даже неспециалисту. На рис.3 показана матрица принятия решений.  Рисунок 3 – Матрица принятия решенийПопарное тестирование Суть этого метода, также известного как pairwise testing, в том, что каждое значение каждого проверяемого параметра должно быть протестировано на взаимодействие с каждым значением всех остальных параметров. После составления такой матрицы мы убираем тесты, которые дублируют друг друга, оставляя максимальное покрытие при минимальном необходимом наборе сценариев. Попарное тестирование позволяет обнаружить максимум ошибок без избыточных проверок. Pairwise testing: пример Для Parwise достаточно, чтобы каждое значение всех параметров хотя бы единожды сочеталось с другими значениями остальных параметров. Таким образом, матрицу можно значительно сократить. Пример показан в таблице 1. Таблице 1 Парное сочетание в матрице принятия решений
При составлении матрицы принятия решений для двух браузеров, двух ОС и двух языков было бы нужно 8 сценариев. При попарном тестировании достаточно четырех. Все это можно просчитать и вручную, но не обязательно – гораздо удобнее автоматизировать процесс. Для этого существует программа попарного независимого комбинированного тестирования – Pairwise Independent Combinatorial Testing (PICT). Для проведения тестирования специалист создает текстовый файл с перечислением и их возможных значений, а затем запускает PICT через cmd – командную строку. Скомбинированные тесты отображаются в виде таблицы в самой консоли. Так же результаты по желанию можно выгрузить в файл Excel. Пример содержимого файла для программы PICT: Браузер: Chrome, Opera ОС: Windows, Linux ; Язык: RU, ENG. Выполнение расчетов в программе PICT показано на рис.4.  Рисунок 4 – Выполнение попарного тестирования в программе PICT Причина и следствиеПростая проверка базовых действий и их результата. Например, если нажать крестик в правом верхнем углу окна (причина), оно закроется (следствие), и т.д. Этот метод позволяет проверить все возможности системы, а также обнаружить баги и улучшить техническую документацию продукта. Примерный алгоритм использования техники: 1. Выделяем причины и следствия в спецификациях. 2. Связываем причины и следствия. 3. Учитываем «невозможные» сочетания причин и следствий. 4. Составляем «таблицу решений», где в каждом столбце указана комбинация входов и выходов, т.е. каждый столбец – это готовый тестовый сценарий. 5. Расставляем приоритеты. Эта техника помогает: Определить минимальное количество тестов для нахождения максимума ошибок. Выяснить все причины и следствия – таким образом, мы убедимся, что на любые манипуляции с системой у системы будет ответ. Найти возможные недочеты в логике описания приложения (что, в свою очередь, поможет улучшить документацию). Например, QA-специалист тестирует приложение типа “записная книжка”. После ввода всех данных нового контакта и нажатия кнопки. Создать (причина) приложение должно автоматически создать карточку с номером телефона, фотографией и ФИО человека (следствие). Тесты покажут, можно ли оставлять одно или несколько полей пустыми, распознает ли система кириллицу, латиницу или оба алфавита, а также другие параметры. Предугадывание ошибок Используя свои знания о системе, QA-специалист может «предугадать», при каких входных условиях есть риск ошибок. Для этого важно иметь опыт, хорошо знать продукт и уметь выстроить коммуникации с коллегами. Например, в спецификации указано, что поле должно принимать код из четырех цифр. В числе возможных тестов: Что произойдет, если не ввести код? Что произойдет, если не ввести спецсимволы? Что произойдет, если ввести не цифры, а другие символы? Что произойдет, если ввести не четыре цифры, а другое количество? Преимущества: 1.Эта проверка эффективна в качестве дополнения к другим техникам. 2. Выявляет тестовые случаи, которые “никогда не должны случиться”. Недостатки: 1. Техника в значительной степени основана на интуиции. 2. Необходим опыт в тестировании подобных систем. 3. Малое покрытие тестами. Проектирование и исполнениеПроектирование теста может быть достаточно трудоемким процессом. Оно включает в себя следующие этапы: 1) задаться целью теста; 2) написать входные значения и шаги; 3) написать предполагаемые выходные значения; 4) выполнить тест и зафиксировать результат; 5) проанализировать результат. От правильного подхода к каждому этапу зависит качество тестирования в целом. О проблеме неверной постановки цели говорилось в первой главе. Необходимость второго этапа обосновано технологической необходимостью. Третий этап проектирования позволит избежать неоднозначности на пятом этапе. Очень часто, при отсутствии описания, что должно получиться, пытаются «подогнать» логику рассуждений в анализе результатов. Кроме того, очень часто этот пункт требует формирования либо независимой оценки (критерия), либо альтернативного просчета по алгоритму. В первом случае очень легко контролировать общий результат, во втором – более детально понять работу алгоритма. Бывают случаи, когда при ручном просчете предполагаемых выходных значений находят ошибки в логике работы программы. Четвертый этап является практически механическим. На этом этапе не нужно думать, а только строго следовать предписанию и аккуратно фиксировать полученные значения. Если исполнение теста приносит результаты, не соответствующие предполагаемым, то это означает, что либо имеется ошибка, либо неверны предполагаемые результаты (ошибка в тесте). Для устранения такого рода недоразумений нужно тщательно проверять набор тестов («тестировать» тесты). Применение автоматизированных средств позволяет снизить трудоемкость процесса тестирования. Например, существуют средства, которые позволяют избавиться от потребности в драйверах. Средства анализа потоков дают возможность пронумеровать маршруты в программе, определить неисполняемые операторы, обнаружить места, где переменные используются до присвоения им значения. Также существуют программы позволяющие выполнять функции с набором параметров, которые варьируются в заданных пределах, что в общем случае, позволяет методом перебора проверить работу функции или метода. При подготовке к тестированию модулей целесообразно еще раз пересмотреть психологические и экономические принципы. При исполнении теста следует обращать внимание на побочные эффекты, например, если метод делает то, чего он делать не должен. В общем случае такую ситуацию обнаружить трудно, но иногда побочные эффекты можно выявить, если проверить не только предполагаемые выходные переменные, но и другие, состояние которых в процессе тестирования измениться не должно. Поэтому при его исполнении наряду с предполагаемыми результатами необходимо проверить и эти переменные. Во время тестирования возникают и психологические проблемы, связанные с личностью тестирующего. Программистам полезно поменяться кодом, чтобы не тестировать свой собственный. Так, программист, сделавший функцию вызова метода, является хорошим кандидатом для тестирования вызываемого метода. Заметим, что это относится только к тестированию, а не к отладке, которую всегда должен выполнять автор класса или модуля. Не следует выбрасывать результаты тестов; представляйте их в такой форме, чтобы можно было повторно воспользоваться ими в будущем. Если в некотором подмножестве классов обнаружено большое число ошибок, то эти классы, по-видимому, содержат еще большее число необнаруженных ошибок. Такие классы должны стать объектом дальнейшего тестирования; желательно даже дополнительно произвести контроль или просмотр их текста. Наконец, следует помнить, что задача тестирования заключается не в демонстрации корректной работы, а в выявлении ошибок. Методология черного ящика Black-box тестирование – это функциональное и нефункциональное тестирование без доступа к внутренней структуре компонентов системы. Метод тестирования «черного ящика» – процедура получения и выбора тестовых случаев на основе анализа спецификации (функциональной или нефункциональной), компонентов или системы без ссылки на их внутреннее устройство. Где используется метод «черного ящика»? Интеграционное тестирование. Тестирование, в котором программные и аппаратные компоненты объединяются и тестируются для оценки взаимодействия между ними. При использовании метода «черного ящика» тестировщик проверяет, корректно ли работают все компоненты в целом тогда, когда они интегрированы в большую систему. И действительно, нормальная работа каждой составляющей по отдельности – это еще не гарантия того, что они будут работать вместе в рамках всего проекта. Например, данные могут не отправиться через интерфейс, или интерфейс не отработает согласно документации. При планировании таких тестов тестировщики опираются на спецификацию. Функциональное тестирование. Используя этот метод, тестировщик проверяет, выполняет ли программное обеспечение все заявленные функции и требования клиента в полном объеме согласно документации. Стресс-тестирование. Предположим, что у нас есть букмекерская онлайн-контора, в документации к которой заявлена возможность одновременной регистрации 1000 пользователей. В этом случае стрессовым тестированием будет непрерывный поток автоматизированных регистраций (как минимум, 1000 регистраций в минуту) на протяжении 12 часов. Usability-тестирование. Пусть в упомянутой букмекерской конторе есть функционал «Купон»: мы проверяем, сколько времени уходит у пользователя для добавления ставки в купон, ввода суммы и завершения ставки. Тестирование производительности. Таким видом тестирования проверяется: есть ли утечки памяти, насколько быстро система работает и выдает обратную связь, не потребляет ли наше ПО слишком много трафика и не создает ли избыточное количество подключений. Приемочное тестирование. После проверки ПО тестировщиками его отдают заказчику, который запускает приемочные тесты «черного ящика» на основе ожиданий от функциональности. Как правило, набор тестов в этом случае определяет сам заказчик, за ним же остается право отказаться от приемки (если его не устроили результаты тестирования). Регрессионное тестирование. Проводится на протяжении всего цикла разработки. Цель такого тестирования – проверить работоспособность нового кода и выяснить, не привел ли он к ошибкам или поломкам в старом функционале. При выборе набора регрессионных тестов следует использовать следующие рекомендации: делаем репрезентативную выборку тестов, в которой используются все функции ПО; выбираем тесты, сосредоточенные на программных компонентах/функциях, которые подверглись изменениям; используем дополнительные тестовые примеры, уделяя основное внимание функциям, на которые с наибольшей вероятностью повлияли изменения. Beta-тестирование. Это тестирование также проводится методом «черного ящика». Практически готовое ПО отдают для «обкатки» желающим для выявления максимального количества ошибок еще до того, как оно попадет к конечному пользователю. Что это дает: идентификацию непредвиденных ошибок (так как бета-тестеры используют ПО нестандартно); широкий набор окружений для проверки, который трудно обеспечить иными методами (разные операционные системы, разные настройки, разные версии браузеров); снижение расходов (так как работа бета-тестеров, как правило, не оплачивается). Техники тестирования «черным ящиком» 1. Эквивалентное разбиение. Эта техника включает в себя разделение входных значений на допустимые и недопустимые разделы и выбор репрезентативных значений из каждого раздела в качестве тестовых данных. Она может быть использована для уменьшения количества тестовых случаев. Допустим, у нас есть целая переменная N в диапазоне от -99 до 99: позитивными классами эквивалентности будут [-99, -10], [-9, -1], 0, [1, 9], [10, 99], а недействительными (негативными) – <-99, >99, пустое значение, нечисловые строки. 2. Анализ граничных значений. Техника, которая включает в себя определение границ входных значений и выбор в качестве тестовых данных значений, находящихся на границах, внутри и вне границ. Многие системы имеют тенденцию вести себя некорректно при граничных значениях, поэтому оценка значений границ приложения очень важна. При проверке мы берем следующие величины: минимум, (минимум-1), максимум, (максимум+1), стандартные значения. Например, в том же случае -99 <= N <= 99 будет использоваться набор: -100, -99, -98, -10, -9 -1, 0, 1, 9, 10, 98, 99, 100. 3. Тестирование таблицы переходов. При данной технике сценарии тестирования выбираются на основе выполнения корректных и некорректных переходов состояний. Допустим, мы хотим записаться на прием к врачу и зарезервировать время своего приема: заходим в форму, выбираем удобное для нас время и нажимаем кнопку «Записаться». Сразу после этого выбранное нами время становится недоступно для другой записи, так как первая запись привела к изменению в базе. 4. Тестирование по сценариям использования. Эта техника используется при написании тестов для индивидуального сценария пользователя с целью проверки его работы. Достоинства метода Тестирование методом «черного ящика» позволяет найти ошибки, которые невозможно обнаружить методом «белого ящика». Простейший пример: разработчик забыл добавить какую-то функциональность. С точки зрения кода все работает идеально, но с точки зрения спецификации это – сверхкритичный баг. «Черный ящик» позволяет быстро выявить ошибки в функциональных спецификациях (в них описаны не только входные значения, но и то, что мы должны в итоге получить). Если полученный при тестировании результат отличается от заявленного в спецификации, то у нас появляется повод для общения с аналитиком для уточнения конечного результата. Тестировщику не нужна дополнительная квалификация. Часто мы пользуемся различными сервисами и приложениями, не очень в них разбираясь. Для того, чтобы открыть инстаграм и обработать свою фотографию, нам совсем не нужно знать способ реализации фильтров. Мы хотим открыть фотографию, выбрать фильтр и получить красивую картинку на выходе. Задача тестировщика, который тестирует эту функцию в инстаграм, – убедиться, что пользователь получит эту самую красивую картинку в соответствии с выбранным фильтром. При этом нам совсем не обязательно иметь какую-либо специализацию – нужны лишь телефон и инстаграм. Тестирование проходит «с позиции пользователя». Пользователь всегда прав, он конечный потребитель практически любого ПО, а значит, ему должно быть удобно, комфортно и понятно. Составлять тест-кейсы можно сразу после подготовки спецификации. Это значительно сокращает время на тестирование: к тому моменту, как продукт готов к тестированию, тест-кейсы уже разработаны, и тестировщик может сразу приступать к проверке. Недостатки метода Основным недостатком метода «черного ящика» является возможность пропуска границ и переходов, которые не очевидны из спецификации, но есть в реализации кода (собственно, это и заставляет тестировщиков использовать метод «белого ящика»). Вспоминается случай, когда система получала котировки валют с биржи Forex и округляла до 3 знаков после запятой. Система успешно прошла тестирование методом «черного ящика» (так как ни одна валюта не выходила за соответствующие границы) и хорошо работала до тех пор, пока курс доллара к биткоин не вышел за границы 1000 долларов. Тестирование «белым ящиком» выявило бы ошибку: специалист увидел бы, что коэффициент конверсии валюты ограничен 3 знаками. Можно протестировать только небольшое количество возможных вводных (входящих) значений; многие варианты остаются без проверки. Тесты могут быть избыточными, если разработчик уже проверил данную функциональность (например, Unit-тестом). При отсутствии четкой и полной спецификации проектировать тесты и тест-сценарии оказывается затруднительно. Из представленной информации мы можем сделать следующий вывод: метод «черного ящика» является эффективным при различных видах тестирования; но следует помнить, что некоторые ошибки невозможно найти, используя только этот метод (например, ошибки во внутренней структуре кода). Проведение «black-box» тестирования увеличивает уверенность в том, что приложение надежно работает на широком диапазоне входных данных, так как набор тестовых данных зависит только от спецификации, а не от особенностей внутренней реализации продукта (как в случае применения методов «белого» и «серого» ящиков). Метод «черного ящика» выгодно применять, если вы ищете: неправильно реализованные функции приложения или сервиса; ошибки в пользовательском интерфейсе; ошибки в функциональных спецификациях. Список использованных источниковМайерс Г. Искусство тестирования программ М.: Финансы и статистика, 1982. -176 с. Канер Кем, Фолк Джек, Нгуен Енг Кек Тестирование программного обеспечения.— Киев: ДиаСофт, 2001. — 544 с. — ISBN 9667393879 Калбертсон Роберт, Браун Крис, Кобб Гэри Быстрое тестирование. — М.: «Вильямс», 2002. — 374 с. Бейзер Б. Тестирование чёрного ящика. Технологии функционального тестирования программного обеспечения и систем. — СПб.: Питер, 2004. — 320 с. Рекс Блэк. Ключевые процессы тестирования. Планирование, подготовка, проведение, совершенствование пер. с англ., - М.: Лори, - 544с.: ил., ISBN 5-85582-239-7, ISBN 0-201-74868-1 (англ.) Денис М. Ахен, Арон Клауз, Ричард Тернер. “CMMI:Комплексный подход к совершенствованию процессов. Практическое введение в модель.” Бек Кент Экстремальное программирование: разработка через тестирование : пер. с англ. / Кент Бек . - СПб. : Питер , 2003. - 224 с. (Библиотека программиста) Дастин Элфрид Автоматизированное тестирование программного обеспечения. Внедрение, управление и эксплуатация : пер. с англ. / Элфрид Дастин ; Джефф Рэшка ; Джон Пол . - М. : Лори , 2003. - 567 с. Луиза Тамре. Введение в тестирование программного обеспечения. - Издательство: Вильямсб Год: 2003 ISBN: 5-8459-0394-7003 г. Элфрид Дастин, Джефф Рэшка, Джон Пол Автоматизированное тестирование программного обеспечения. 2003 г. |