Какие Тесты Вам Нужны? Часть 2. Матрица Типов Тестирования

Аннотация В первой части В серии статей я рассказывал о том, что определяет выбор тестов.

Поняв, чего вы хотите добиться с помощью тестирования, вы можете сделать следующий шаг — выбор тестов.

Для этого нужно понять, какие тесты вообще существуют. Почти во всех статьях, посвященных видам тестирования, тесты сгруппированы в ту или иную категорию.

Только это деление не везде совпадает. Читая подобные статьи, часто обнаруживаешь расхождения в терминологии у разных авторов.

Моя цель — разбить и визуализировать разнообразие тестов, чтобы помочь тем, кто выбирает, какие тесты им нужны, и тем, кто изучает само тестирование.

Я не берусь давать в этой статье четкие определения видов тестирования.

Интерпретация терминов, используемых для названия видов, будет рассмотрена в третьей части.

Это разделение связано с объемом информации.

Классификация типов тестирования

И классифицировать их так же сложно, как, например, кулинарные блюда.

Группировать блюда можно по национальной кухне, по времени употребления (на завтрак, обед, ужин), по используемым ингредиентам, по калорийности и так далее.

Сами изделия также можно разделить на группы по различным критериям.

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

То же самое касается тестов: регрессионный тест может быть интеграционным тестом.

Принадлежность к одной категории не исключает принадлежности к другой.

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

Тип теста — это характеристика, которой может обладать либо один тестовый сценарий, либо целый набор тестов.

Теперь посмотрите на это еще раз и перечислите вина по странам производства, как они расположены в супермаркете или в меню ресторана.

Не работает? Как тогда выбрать? Эта карта не подходит для выбора производителем.

Если присмотреться, там есть приписка «по стилю и вкусу».

То же самое и с типами тестов.

Ограничиваясь одним критерием группировки, мы упускаем из виду все многообразие тестов.

Карта типов тестирования

Я взял этот список за основу и дополнил его информацией, почерпнутой из других источников и личного опыта, и составил интеллект-карту (карту знаний).

Мне эта карта пригодится при планировании тестов — проверяю, не забыл ли я что-нибудь.

Делюсь с вами схемой:



Посмотреть в полном размере.

Скачать исходник в формате xmin ты можешь здесь .

Названия тестов даны на английском языке во избежание неточного перевода.

Цветовые коды

• Синий характеристики, применимые к наборам тестов, выделены
• Желтый выделены характеристики, применимые только к тестовым примерам
• Зеленый универсальные характеристики выделены

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

На самом деле конкретных тестовых случаев во много раз больше, чем тестовых наборов, и

Пропуская какой-то тип, вы теряете много ценных проверок, а значит, и дефектов.

Соблюдение этих методов приводит к проведению специальных испытаний.

Поэтому, на мой взгляд, уместно представить их как виды тестов.

Упомянутые методы считаются разновидностью тестов черного ящика.

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

Об этом нужно думать при написании модульных тестов, которые не имеют никакого отношения к Black Box. О зеленых блоках на карте знаний Эти имена на самом деле являются типами требований.

Тесты, охватывающие определенный тип требований, логически называются тестами этого требования.

Большинство названий тестов, помещенных в синие блоки, также произошли от названий требований.

Например, «приложение должно быть отказоустойчивым» генерирует тесты на отказоустойчивость.

Зеленые блоки отличаются от синих тем, что они вообще редко упоминаются в русскоязычных обзорах видов тестирования.

Однако если вы, например, введете в поиск фразу «проверка пригодности», вы найдете много полезной информации.

Как пользоваться картой

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

Но в тексте очень много букв, поэтому дерево становится широким и неудобным для чтения.

Это дерево имеет 10 больших ветвей — первый уровень графа является критерием классификации.

Очевидно, что сами по себе они не являются типами тестов.

Надеюсь, вы знаете разницу между поиском в ширину и поиском в глубину.

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

Этому очень способствуют двухуровневые (заголовок-список) списки типов тестирования.

Нужно искать по ширине.

Потому что на каждой ветке данного графа есть нужные вам тесты.

То же самое следует сделать и при попытке охарактеризовать существующие наборы тестов.

Один и тот же тест будет иметь несколько разных характеристик.

Спойлер: изучив все виды тестов, вы обнаружите, что в каждой категории есть нужные вам виды тестов.

Критерии классификации

1. Тип требований

Если нам есть что разрабатывать, значит, нам есть что тестировать.

Формально описать требования очень важно, но не обязательно.

Неважно, есть у вас бумажка с названием «ТЗ»/«СРС» или нет – требования, на основании которых вы проводите проверку, всегда есть.

Мы можем, конечно, уточнить какие именно операции нужны или понять и сделать по нашему видению, но так или иначе минимальные требования у нас уже есть.

Нет требований – нет развития.

Верно и обратное – есть развитие -> есть требования.

Я знаю хороших разработчиков, которые не приступают к разработке, пока не получат ответ на вопрос: «Почему это программное обеспечение должно делать то-то и то-тоЭ» Каково конечное использованиеЭ» Если разработчики работают, значит требования есть; другим вопросом остается точность их понимания.

Например, «задача сделать калькулятор, который будет иметь кнопки и который будет выполнять все математические операции» сама по себе содержит кучу требований.

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

Если вы стремитесь к полному покрытию тестами, то

Вам нужны все виды тестов из первой группы.

Функциональные тесты будут подробно рассмотрены в третьей части.

Многие люди останавливаются на этом этапе.

" Нам нужны функциональные тесты «Но мы должны двигаться дальше.

2. Объект испытаний

Существует большое разнообразие технологий, интерфейсов, архитектур, функциональных назначений и характеристик систем.

Все требует своего подхода к тестированию.

Методы и инструменты различаются.

Эту группу прикреплю отдельно:



Справа я написал три группировки, они условные, поэтому не являются родительскими узлами.

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

В целом, мы проведем инфраструктурные работы до и для передачи в производство.

А эксплуатационные будем проводить на прод-подобной среде, когда уже определено, на каком железе будет жить наша система.

Полное тестирование безопасности, например для сертификации ФСБ, может быть частью тестов инфраструктуры, если используются аппаратные методы защиты или внешние системные модули, которые мы не разрабатываем сами.

А некоторые меры безопасности будут «встроены» в наше программное обеспечение и протестированы в рамках функциональных требований.

Например, в рамках тестирования функции передачи сообщения о транзакции из банкомата в банк-эмитент мы проверим шифрование ПИН-кода.

Очень важно понимать, что

типы тестов для тестовых объектов не являются типами функциональных тестов

— не всегда типа NFR. Давайте посмотрим на примеры.

Пример 1. Существует нефункциональное требование «при выходе компонента из строя его функции должен выполнять другой, параллельный компонент».

Соответственно, требование будет покрыто нефункциональными тестами — стресс-тестами, тестами надежности и стабильности.

Пример 2. Рассмотрим случай, когда отказоустойчивость является функциональным требованием.

Например, разрабатывается и тестируется отказоустойчивый кластер, а не система, в которой он используется.

Цель разработки — создание продукта, который обеспечит отказоустойчивость.

В данном случае мы имеем дело с функциональными тестами отказоустойчивости.

Пример 3. Разработка приложения Джметр .

Это популярный инструмент для проведения нагрузочного тестирования.

Его функционал — нагрузочное тестирование.

Это тот случай, когда предмет тестирования стал объектом тестирования.

Рекурсивно, да? Тесты нагрузочного тестирования JMeter функциональны.

Другие возможные примеры: разработка криптомодуля (функциональные тесты ИБ), разработка интерфейса взаимодействия между системами (функциональные интеграционные тесты), разработка веб-интерфейса фронт-офиса в виде тонкого клиента с сохранением разделения бизнес-логики и представления данных.

(функциональные тесты пользовательского интерфейса).

И так далее.

В таких случаях нецелесообразно разделять функциональные тесты по типу функциональности (только по типу требований).

Да и сами функциональные тесты нецелесообразно относить к объектам при категоризации «по объекту тестирования».

3. Знание системы

Эти термины взяты из теории менеджмента, и я надеюсь, что они знакомы вам в более широком смысле, чем виды тестов.

Вы можете рассматривать как всю систему, так и ее отдельную часть как монохромную коробку.

Наиболее распространенный подход к тестированию Проведение тестов функциональной пригодности «черного ящика» .

Их еще называют приемочными испытаниями, но до приемочных испытаний мы еще не дошли, подождите.

Это тот тип тестирования, которому обучают большинство начинающих тестировщиков.

Существует распространенное заблуждение, что проведение таких тестов необходимо и достаточно, и если оно не приводит к повышению качества продукта, значит, тестировщики плохо справились.

О влиянии знания системы на тестирование подробно напишу отдельно.

4. Степень автоматизации

Я сама очень люблю эту тему.

Что мне не нравится, так это то, что автоматизацию чаще всего рассматривают в таком контексте: «вот у нас накопились регрессионные функциональные тесты, их некому запускать, надо как-то самим это делать».

Поэтому многие посмотрят на эту ветку дерева и скажут: «ну это на потом».

Автоматизация — это не только эволюционное развитие тестов.

Некоторые необходимые типы тестов просто невозможно выполнить вручную.

«Как мы это проверимЭ»

Иногда нам нужны симуляторы внешних систем.

Иногда — вспомогательные инструменты для подготовки тестовых данных.

Почти всегда — инструменты для выполнения нагрузочного тестирования.

Какие-то инструменты вы возьмете готовые, какие-то напишете сами.

Нам нужно вложить в это ресурсы, поэтому

подумайте об автоматизации заранее.

5. Степень изоляции компонентов.

Дело в масштабе – когда берешь все целиком.

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

Вы можете проверить не сами компоненты, а то, как они взаимодействуют – не теряются или не искажаются данные.

Выбор масштаба, в котором будет проводиться тот или иной тест, зависит от цели — какие ошибки вы ищете, какие требования хотите проверить.

А также от знания и доступности системы.

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

А до переноса — серый ящик, когда тестировщики знают, как работает система и где ее узкие места.

Они заливают данные в самый передний вход и ждут утечек из всех щелей и ожидаемого результата из самого заднего выхода.

Подготовка тестовых данных зависит от знания системы.

Зная, где оно может прорваться, можно подсунуть то, что влезет в нужную щель.

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

Если вы изолируете компонент и подаете данные на вход только ему, а результат проверяете только на его выходе, это будет тестирование компонента.

В зависимости от того, насколько мелко вы измельчите систему, возникают разногласия в терминологии относительно видов тестирования.

Об этом будет сказано в другой части.

6. Время тестирования

когда мы будем тестировать?

Переведено на нашу работу:

«Тестирование от критического дефекта до релиза».

Вопрос о сроках того или иного тестирования во многом зависит от методологии проекта.

Согласно SCRUM, вы будете проходить только те тесты, которые сможете выполнить за итерацию.

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

Сборку можно собирать каждый день и запускать на ней дымовые и/или регрессионные тесты.

Кто-то собирает билд непосредственно перед релизом и сидит по ночам, чтобы перепроверить или перепроверить все, что можно сделать.

В моем понимании линия, разделяющая тесты по времени, — это релиз.

Некоторые тесты делаются перед релизом, внутри команды — это альфа-тесты, некоторые — после передачи в эксплуатацию — это бета, гамма, дельта… омега-тесты.

Всем известен закон зависимости стоимости дефекта от времени его обнаружения.

Поэтому максимум тестов следует проводить на альфа-стадии.

Бета-тесты обычно означают «пререлиз».

Когда товар вроде бы готов и уже используется, но он еще не доработан.

Практика полного бета-тестирования распространена в индустрии разработки игр и в проектах с открытым исходным кодом.

7. Степень готовности к тестированию

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

Как бы то ни было, даже если сначала на все пункты вы ответили «нет», это не значит, что на вашем проекте будет проводиться только исследовательское тестирование.

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

Отсутствие регистрации тестов не означает, что они неподготовлены.

8. Глубина тестирования

Тестирование программного обеспечения Рон Паттон .

Вот цитата:

Существует два фундаментальных подхода к тестированию программного обеспечения: тест на прохождение и тест на провал.

Когда вы проводите тестирование до прохождения, вы на самом деле гарантируете лишь то, что программное обеспечение работает минимально.

Вы не расширяете его возможности.

Вы не видите, что можно сделать, чтобы сломать это.

Вы относитесь к этому с осторожностью, применяя самые простые и понятные тестовые примеры.

Если они не прошли, то остальные проверять не нужно.

Меня не удивляет, что этот тестовый сплит почти нигде не упоминается.

Причина в том, что эта характеристика почти эквивалентна разделению тестовых случаев на положительные и отрицательные.

В принципе, так оно и есть, за исключением одного:

Есть положительные и отрицательные тестовые случаи.

Метки «прошел тест» и «тест прошел неудачно» можно использовать для группировки наборов тестов для дымовых, приемочных и регрессионных тестов, которые могут содержать как отрицательные, так и положительные сценарии.

Тест до отказа - это испытания на неизведанной территории, которая может оказаться минным полем.

Вы не будете запускать эти тесты после каждой сборки.

Они нужны лишь для поиска особых состояний системы, при которых может возникнуть ранее необнаруженный дефект или даже отказ всей системы.

Такие тесты могут быть специальными, а отрицательные тесты могут быть случаями, которые проверяются при принятии исправления ошибки и должны пройти успешно.

Цель отрицательного теста — убедиться, что система правильно отреагирует на неправильное действие.

Цель метода «тест до отказа» — гарантированно сломать систему.

Мы помним, что чем раньше будут обнаружены дефекты, тем лучше.

И что к концу итерации система должна быть максимально протестирована, и базовые сценарии наверняка должны оказаться успешными.

Таким образом, мы получаем чередование тестов по глубине.

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

Когда первая часть Test-To-Pass пройдена успешно, мы переходим ко второй — Test-To-Fail, которая должна выявить как можно больше дефектов всех степеней критичности.

А после последней партии тестов дефектов вообще не должно возникнуть — они должны быть снова Test-To-Pass.

9. Сценарии

Сценарное мышление не является стратегической задачей.

При планировании стратегии тестирования можно быть уверенным только в одном:

Нам нужны все возможные сценарии.

10. Динамизм

Если состояние системы не меняется – это статическое тестирование.

Статическое тестирование часто упускают из виду.

Как можно протестировать ничего не меняя? Ответ в схеме.

Анализ кода и тестирование документации помогают выявить значительную долю ошибок, не тратя время на приведение системы в движение.

Это завершает широкий обзор.

Глубокое погружение оставим на следующий раз.

Составление тестовой матрицы

• Тип требований
• Тестовый объект
• Знание системы
• Степень автоматизации
• Уровень готовности к тестированию
• Глубина тестирования
• Время тестирования
• Степень изоляции компонентов
• Динамизм

— 1 измерение.

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

Их можно пометить как тесты, которые должны пройти, и как тесты, которые должны обнаружить дефекты.

— 2 измерения Проведение статических испытаний может стать стандартной практикой на организационном уровне.

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

— 1 измерение.

Специальное/исследовательское тестирование следует проводить во время простоя или в первые дни проекта/новой функциональности.

Все остальные испытания считаются подготовленными.

Осталось 4 тестовые характеристики:

• Тип требований * Объект тестирования = Функциональный компонент системы
• Знание системы
• Степень автоматизации
• Степень изоляции компонентов

Я прикинул, что даже при 4 характеристиках типов тестов, типов тестов настолько много, что нет смысла их генерировать.

Матрица, матрица.

Я считаю, что матрица тестов — это та самая интеллект-карта с типами тестов.

Глядя на него, нужно просто иметь в виду тот факт, что каждый отдельный тест одновременно является разновидностью теста всех перечисленных категорий верхнего уровня.

Заключение

Имея понимание цели тестирования и системное представление о видах тестов, уже вполне можно ответить на вопрос – какие виды тестов вам нужны.

Наконец, вот контрольный список — вопросы, на которые необходимо ответить при определении типов необходимых тестов:

1. Каковы функциональные и нефункциональные требования к системе?
2. Из чего будет состоять система?
3. Насколько хорошо тестировщики знают структуру системы?
4. Как и чем воспроизвести тестовые ситуации?
5. В каких областях и в каком масштабе будет тестироваться система?
6. На какой стадии разработки будут проводиться испытания?
7. Как вы будете описывать и хранить тесты?
8. Умеют ли ваши тестировщики писать тест-кейсы?
9. Будут ли разработчики проверять себя и друг друга?
10. Спецификация идеальна?

) Надеюсь, я не запутал читателей еще больше, и моя матрица будет вам полезна.

Теги: #тестирование #контроль качества #тестирование ИТ-систем

• Зарабатывайте Легкие Деньги В Интернете С Помощью Google Adsense

  19 Oct, 24

• Какой Должна Быть Современная Crm: От Разработки До Применения В Бизнесе

  19 Oct, 24

• "Ъ": Минкомсвязи Хочет Аннулировать Лицензии Lte У "Большой Четверки"

  19 Oct, 24

• 1 Миллион Рублей На Хостинг 96 Сайтов Мчс На 2011 Год

  19 Oct, 24

• Проверка Баланса Телефона В Консоли

  19 Oct, 24

• Вконтакте - Можно Просто Присоединиться Добровольно?

  19 Oct, 24

• Питер Пай #3 – Личные Впечатления

  19 Oct, 24

• Альтернатива Углеродным Нанотрубкам

  19 Oct, 24

• Круглый Дисплей От Toshiba И Matsushita

  19 Oct, 24

• Максимальное Исключающее Или

  19 Oct, 24