Часть 2.2
- Рома
- 2 апр. 2015 г.
- 7 мин. чтения
КЛАССИФИКАЦИЯ ВИДОВ ТЕСТИРОВАНИЯ
Виды тестирования:
1. По знанию внутренностей системы:
• черный ящик (black box testing);
• серый ящик (grey box testing);
• белый ящик (white box testing).
2. По объекту тестирования:
• функциональное тестирование (functional testing);
• тестирование интерфейса пользователя (UI testing);
• тестирование локализации (localization testing);
• тестирование скорости и надежности (load/stress/performance testing);
• тестирование безопасности (security testing);
• тестирование опыта пользователя (usability testing);
• тестирование совместимости (compatibility testing).
3. По субъекту тестирования:
• альфа-тестировщик (alpha tester);
• бета-тестировщик (beta tester).
4. По времени проведения тестирования:
• до передачи пользователю
— альфа-тестирование (alphatesting);
- тест приемки (smoke test, sanity test или confidence test);
- тестирование новых функциональностей (new feature testing);
- регрессивное тестирование (regression testing);
- тест сдачи (acceptance or certification test);
• после передачи пользователю
— бета-тестирование (beta testing).
5. По критерию "позитивности" сценариев:
• позитивное тестирование (positive testing);
• негативное тестирование (negative testing).
6. По степени изолированности тестируемых компонентов:
• компонентное тестирование (component testing);
• интеграционное тестирование (integration testing);
• системное (или энд-ту-энд) тестирование (system or endto-end testing).
7. По степени автоматизированности тестирования:
• ручное тестирование (manual testing);
• автоматизированное тестирование (automated testing);
• смешанное/полуавтоматизированное тестирование (semi automated testing).
8. По степени подготовки к тестированию:
• тестирование по документации (formal/documented testing);
• эд хок-тестирование (ad hoc testing).
1. По знанию внутренностей системы:
-черный ящик
Черный ящик, т.е. область незнания, — это не что иное, как тестируемые части бэк-энда (например, код программиста, схема базы данных), составляющие невидимый поль- зователю виртуальный мост, который соединяет
• фактический ввод (шаги) и
• фактический вывод (фактический результат).
Признаки подхода "Черный ящик":
1. Тестировщик не знает, как устроен виртуальный мост.
Блэк бокс-тестировщику, знающему лишь то, для чего был написан код (т.е. функциональности), а не как он был написан, легче смотреть на тестирование с точки зрения пользователя, для удовлетворения чаяний которого весь софтверный сыр-бор и начался.
В случае с черным ящиком тестировщик не знает, как устроен виртуальный мост, и это может быть как полезно, так и вредно для дела.
2. ИДЕИ для тестирования идут от предполагаемых паттернов (pattern — образец) поведения пользователей. Поэтому подход "Черный ящик" также называют поведенческим.
То, что мы называли вводом (шагами), на самом деле является двумя вещами, которые неотрывно связаны: сценарии и данные для сценариев
Сценарий (scenario) — это последовательность ДЕЙСТВИЙ для достижения фактиче- ского результата.
Если исполнение тестирования идет по тест-кейсам, то можно сказать, что сценарий тест-кейса — это совокупность шагов тест-кейса.
Данные для сценариев, или просто "данные", — это конкретные ЗНАЧЕНИЯ ВВОДА, используемые для достижения фактического результата.
Предполагаемые паттерны поведения пользователей — это те сценарии и данные, которые, как мы ожидаем, будут реализовываться и вводиться пользователями.
Основные источники предполагаемых паттернов поведения пользователей могут быть:
а) напрямую взяты из спека.
б) найдены путем эксплоринга.
Иногда "брожение" по сайту является лучшим источником для понимания того, как реальный пользователь будет с ним обращаться;
в) получены путем применения методики черноящичного тестирования (black box testing methodology).
г) подарены интуицией.
д) присоветованы программистом или продюсером.
е) др.
При подходе "Черный ящик" тестировщик не основывает идеи для тестирования на знании об устройстве и логике тестируемой части бэк-энда. Идеи формируются путем предположений о сценариях, которые будут реализовываться и применяться пользователями. Такие сценарии называются паттернами поведения пользователей.
-белый ящик (white box testing) также известен под именами Стеклянный ящик (glass/clear box), Открытый ящик (open box) и даже Никакой ящик (по box).
В отличие от "Черного ящика" при подходе "Белый ящик" тестировщик основывает идеи для тестирования на знании об устройстве и логике тестируемой части бэк-энда.
Использование методик обоих подходов количественно и качественно увеличивает покрытие возможных сценариев.
Покрытие возможных сценариев — это одна из частей архиважнейшей концепции, называемой тестировочное покрытие.
Тестировочное покрытие (test coverage) состоит из двух вещей:
а. Покрытие возможных сценариев.
б. Покрытие исполнения тест-кейсов.
Покрытие возможных сценариев — это в большинстве случаев абстрактная величина, так как в большинстве же случаев невозможно даже подсчитать, сколько понадобится тест-кейсов, чтобы обеспечить 100%-ю проверку ПО.
Покрытие возможных сценариев может увеличиться либо уменьшиться путем прибавления либо отнятия уникального тест-кейса, т.е. тест- кейса,
• который тестирует реальный сценарий использования ПО и
• который не является дубликатомдругого тест-кейса.
Покрытие исполнения тест-кейсов — это всегда величина конкретная, и выражается она процентным отношением исполненных тест- кейсов к общему количеству тест-кейсов.
Симбиоз использования подходов "Черный ящик" и "Белый ящик" увеличивает покрытие возможных сценариев
• количественно, потому что появляется большее количест- во тест-кейсов;
• качественно, потому что ПО тестируется принципиаль но разными подходами: с точки зрения пользователя ("Черный ящик") и с точки зрения внутренностей бэк-энда ("Белый ящик").
• серый ящик (grey box testing);
Это подход, сочетающий элементы двух предыдущих подходов, это
• с одной стороны, тестирование, ориентированное на пользователя, а значит, мы используем паттерны поведения пользователя, т.е. применяем методику "Черного ящика";
• с другой — информированное тестирование, т.е. мы знаем, как устроена хотя бы часть тестируемого бэк-энда, и активно используем это знание.
2. По объекту тестирования:
-функциональное тестирование (functional testing);
- тестирование интерфейса пользователя (UI testing);
Это тестирование, при котором проверяются элементы интерфейса пользователя.
-тестирование локализации (localization testing);
Многогранная вещь, подразумевающая проверку множества ас- пектов, связанных с адаптацией сайта для пользователей из других стран.
-тестирование скорости и надежности (load/stress/performance testing);
Это проверка поведения веб-сайта (или его отдельных частей) при одновременном наплыве множества пользователей.
Скорость и надежность веб-сайта профессионально проверяется специальным ПО, которое легко может стоить под 100 тыс. долл. (например, Silk Performer от Segue или Load Runner от Mercury Interactive). Упомянутое ПО служит:
с одной стороны, для генерации наплыва пользователей,
с другой — для измерения скорости, с какой веб-сайт в среднем отвечает каждому из "наплывших" и
с третьей — для последующего анализа полученных данных.
-тестирование безопасности (security testing);
Тестирование безопасности — это множество вещей, суть которых заключается в том, чтобы усложнить условия для кражи — кражи данных, денег и информации.
-тестирование опыта пользователя (usability testing);
Проверяется, чтобы было легко ориентироваться в сайте. Удобное расположение линков.
-тестирование совместимости (compatibility testing).
Это проверка того, как наш веб-сайт взаимодействует с
• "железом" (например, модемами) и
• ПО (браузерами/операционными системами) наших пользователей.
Тестирование с разными браузерами называется кросс-браузер-тестированием (cross-browser testing). Тестирование с разными ОС называется кросс-платформ-тести- рованием (cross-platform testing).
3. По субъекту тестирования:
АЛЬФА-ТЕСТИРОВЩИК (alpha tester)
Это сотрудники компании, которые профессионально или непрофессионально проводят тестирование: тестировщики, программисты, продюсеры, бухгалтеры, сисадмины, секретарши. В стартапах накануне релиза нередко все работники, включая Харитоныча, сидят по 16 часов кряду, пытаясь найти непойманные баги.
БЕТА-ТЕСТИРОВЩИК (beta tester)
Это нередко баловень судьбы, который не является сотрудником компании и которому посчастливилось пользоваться новой системой до того, как она станет доступна всем остальным. За бета- тестирование иногда даже платят деньги.
4. По времени проведения тестирования:
ДО передачи пользователю — альфа-тестирование (alpha testing):
• тест приемки (smoke test, sanity test или confidence test);
• тестирования новых функциональностей (new feature testing);
• регрессивное тестирование (regression testing);
• тест сдачи (acceptance или certification test),
ПОСЛЕ передачи пользователю — бета-тестирование (beta testing)
5. По критерию "позитивности" сценариев:
-негативное тестирование (negative testing).
Итак, сценарий, проверяющий ситуацию, связанную с
• потенциальной ошибкой (error) пользователя и/или
• потенциальным дефектом (failure) в системе, называется негативным.
Пример ошибки пользователя ВВОД недействительных данных в поле "Имя" на странице регистрации.
Примердефекта в системе Вышеуказанный пример о неправильной генерации имени файла.
Создание и исполнение тест-кейсов с негативными сценариями называется НЕГАТИВНЫМ тестированием.
-позитивное тестирование (positive testing);
Позитивные сценарии — это сценарии, предполагающие нормальное, "правильное"
• использование и/или
• работу системы.
Первый пример позитивного сценария Ввод действительных данных в поле "Имя" на странице регистрации.
Второй пример позитивного сценария Проверка работы системы, когда имя файла имеет правильный формат: bofa_20040l 18_ach.txt.
Создание и исполнение тест-кейсов с позитивными сценариями называется ПОЗИТИВНЫМ тестированием.
Несколько мыслей вдогонку:
а. Как правило, негативное тестирование находит больше багов.
б. Как правило, негативное тестирование — вещь более сложная, творческая и трудоемкая, так как спеки описывают, как должно работать, когда "усе в порядке", а не как должно работать в ситуациях с ошибками или сбоями.
в. Если есть позитивные и негативные тесты как часть тест- комплекта, то позитивные тесты исполняются в первую очередь. Логика:
В большинстве случаев целью создания функционачьности является возможность реализации именно позитивных сценариев, т.е. работоспособность позитивных сценариев более приоритетна, чем работоспособность негативных сценариев.
г. Существуют спеки, полностью посвященные тому, как должна себя вести система при ошибках/дефектах. Следовательно, все тестирование такого спека будет негативным.
д. Два полезных термина:
• обращение с ошибкой/дефектом (error handling /failure handling) — это то, как система реагирует на ошибку/дефект;
• сообщение об ошибке (error message) — это информация (как правило, текстовая), которая выдается пользователю в случае ошибки/сбоя.
6. По степени изолированности тестируемых компонентов:
Компонентное тестирование (component testing) — это тестирование на уровне логического компонента. И это тестирование самого логического компонента. Интеграционное тестирование (integration testing) — это тестирование на уровне двух или больше компонентов. И это тестирование взаимодействия этих двух или больше компонентов.
Системное (или энд-ту-энд) тестирование (system or end-to-end testing) — это проверка всей системы от начала до конца.
7. По степени автоматизированности тестирования:
РУЧНОЕ ТЕСТИРОВАНИЕ
Это исполнение тест-кейсов без помощи каких-либо программ, автоматизирующих вашу работу. Например, для того чтобы создать эккаунт нового пользователя, мы идем на наш www.main.testshop.rs, открываем страницу регистрации, заполняем формы и т.д.
АВТОМАТИЗИРОВАННОЕ ТЕСТИРОВАНИЕ
Это отдельная дисциплина искусства тестирования. Значительная часть эффективности работы отдела тестирования зависит от того, какие задачи отданы для автоматизации и как эта автоматизация была осуществлена. Автоматизация может как принести огромное облегчение всем тестировщикам, так и завалить работу всего отдела и отложить релиз, премию, отпуск и другие сладкие вещи.
а. Тулы для помощи в черноящичном и сероящичном тестировании. Например,
• тул, который автоматически создает для нас эккаунт пользователя;
• тул, совершающий запросы к базе данных и генерирующий файлы формата, утвержденного системой VISA, используя извлеченные данные;
• тул, генерирующий транзакции покупки в нашем магазине, и т.д. и т.п.
б. Программы для регрессивного тестирования
Это специальное ПО, созданное для буквального воспроизведения действий тестировщика. Наиболее популярная и мощная программа для автоматизации регрессивного тестирования веб-проектов — это Silk Test, выпускаемый компанией Segue.
в. Программы для тестирования скорости и надежности.
г. Прочие программы
Это, например, "Проверяльщики линков" (link checkers).
СМЕШАННОЕ/ПОЛУАВТОМАТИЗИРОВАННОЕ ТЕСТИРОВАНИЕ
Здесь ручной подход сочетается с автоматизированным. Например, с помощью тула я создаю новый эккаунт и потом вручную генерирую транзакцию покупки.
8. По степени подготовки к тестированию:
Здесь все просто. Есть тестирование по тест-кейсам, а есть тестирование ad hoc (лат. — для этой цели, читается как "эд-хок"), т.е. мы просто интуитивно роемся в ПО, пытаясь найти баги. Интуитивное тестирование, как правило, применятся:
• тестировщиком в качестве теста приемки и/или теста сдачи (если тест-кейсы для них не формализованы в документации);
• тестировщиком в качестве успокаивающего для сердца в довесок к документированным тестированию новых функциональностей и регрессивному тестированию;
• тестировщиком, который только что пришел в компанию, где код уже написан и нужно срочно все протестировать;
• когда бухгалтерия и менеджмент протягивают тестировщикам руку помощи перед релизом;
• в других случаях, когда нет тест-кейсов. Нужно отметить, что эд хок-тестирование часто дает поразительные результаты: бывает, исполняешь только что пришедшие в голову сценарии, которые и не снились при подготовке к тестированию, и находишь дородные, розовощекие и ухмыляющиеся баги.
Comments