1. Правильный ли метод используется для того или иного запроса? Если вы отправляете сообщение, а на сервер уходит только GET-запрос, то что-то здесь явно не так.
2. Казалось бы, клик по одной и той же функциональной клавише генерирует один и тот же запрос. Но есть прецеденты, когда клик по кнопке приводил к ситуации, в которой JavaScript переписывал запрос рядом находящейся кнопки, таким образом меняя ее предназначение.
3. Вникайте в отправляемые запросы. В них довольно легко разобраться, особенно если это GET – они логически понятны даже рядовому пользователю. Анализ запросов – это возможность обнаружить спрятавшийся дефект гораздо быстрее, чем осуществляя его поиск в интерфейсе.
4. Мониторьте трафик на предмет запросов на другие (не ваши) сервера. Пример из жизни: фронтэнд сайта делал фриланс-разработчик, по завершению работы которого мы принялись за тестирование. Я имею привычку мониторить весь трафик тестируемого приложения: это позволило обнаружить, что вышеупомянутый разработчик без зазрения совести спрятал в «фронт» сайта запросы, которые работали на благо его личного интернет-магазина.
5. Мониторя трафик, внимательно следите за кодами состояний. Мы подробнее остановимся на этом пункте.
Коды состояния глазами адепта качества
Каждый ответ на любой запрос несет в себе массу полезной для разработчиков и специалистов по тестированию ПО информации. Одним из источников такой информации может стать код состояния: по этому коду клиент узнаёт о результатах его запроса и определяет, какие действия ему предпринять дальше. Набор кодов состояния является стандартом, он описан в соответствующихдокументах RFC. Каждый раз, когда вы создаете баг-репорт о неработающих ссылках, иных элементах веб-страницы или системных ошибках, обязательно указывайте ответы сервера: они сэкономят время разработчику при определении причин дефекта.
|
|
Все коды можно поделить на группы (сотые, двухсотые, трехсотые, четырехсотые и пятисотые) каждая группа-«сотня» несет свой тип информации.
По клику на картинку откроется полная версия.
Более детально с кодами состояния можно ознакомиться на Wikipedia.
На практике, используя при тестировании специальные приложения (тот же Fiddler), вы без труда сможете отсортировать свои запросы и ответы по коду состояния и отобрать, например, все 400-е и 500-е с последующим их анализом. Таким образом очень быстро «отлавливаются» дефекты с «отвалившимися» стилями, скриптами, файлами, функциями приложения и т.п.
Чем еще отличается веб-приложение от десктопного: больше особенностей – больше проблем!
Многопользовательская сущность веб-приложений
Широта аудитории приложений накладывает свой отпечаток на специфику работы.
1. Одно приложение одновременно может использоваться огромным количеством людей. Мы уже рассматривали вопрос нагрузочного тестирования, но также следует обратить внимание на то, что в число пользователей могут входить представители разных культур, языков и религий. Нам необходимо помнить об этом, особенно если речь идет о тестировании международного приложения.
2. Каждый пользователь может иметь свои уровни доступа. В идеальном варианте тестировщик создает для себя матрицу уровней доступа и тестирует каждый доступ в отдельности.
|
|
По клику на картинку откроется полная версия.
3. Пользователи с одним уровнем доступа могут обращаться к одним и тем же сущностям, что приводит к конкурентному доступу. Тестируется это довольно просто. Для примера рассмотрим систему, имеющую дело с договорами, которые можно создавать, публиковать, редактировать, аннулировать. Алгоритм работы таков: под несколькими окнами в режиме инкогнито авторизуемся в приложении под пользователями с разными уровнями доступа; далее выбранную для теста сущность открываем на редактирование, а под второй учетной записью эту же сущность пробуем перевести в статус «Аннулировано» – на этом этапе должен сработать контроль на конкурентный доступ. Операция аннулирования блокируется, а пользователю выдается сообщение о том, что сущность редактируется другим пользователем (поведение и приоритет действий определяются в соответствии с требованиями и особенностями продукта, но логика не меняется).
4. Широта аудитории говорит о том, что за монитором может находиться человек, имеющий злой умысел в отношении вашего ПО.
Сетевые страсти: веб-приложение в разных условиях передачи данных
Веб-приложения активно используют сеть, и это является источником возможных проблем. Таковой, например, является использование приложения в условиях низкой скорости передачи данных (в браузер Google Chrome, например, встроена функция Throttling, которая позволяет сильно занижать скорость передачи данных), в условиях потери пакетов или при отключении сети во время активной фазы работы приложения (способ имитации: сначала делаем скорость передачи данных с помощью Throttling минимальной, а потом прерываем сетевое соединение во время обработки запроса).
|
|
В любом из описанных выше случаев приложение должно работать корректно. При «падении» запроса (time out) или иной проблеме мы должны, перезагрузив страницу, снова получить полностью работающее веб-приложение без какого-либо намека на только что пережитый «урон». Для всех ли функций приложения необходимо подобные тесты? Ни в коем случае! В будущем можете ориентироваться на свой опыт, а на первых этапах в этих вопросах лучше проконсультироваться с разработчиками.
Тестирование безопасности веб-приложения: спаси, сохрани, защити
Тестирование безопасности – отдельное направление тестирования, которое требует от специалиста фундаментальных знаний технического характера и хорошей профильной квалификации. Я отмечу ряд общих моментов, которые могут помочь любому тестировщику находить классические уязвимости, не допуская их выход на продакшен. Вопросы безопасности приложений регламентируются OWASP Guide, CHECK, ISACA, NIST Guideline, OSSTMM.
Существует ряд принципов безопасности, к которым относятся конфиденциальность, целостность и доступность:
1) Конфиденциальность – ограничение доступа к той или иной информации для определенной категории пользователей (или наоборот предоставление доступа только ограниченной категории).
2) Целостность включает в себя:
а) возможность восстановить данные в полном объеме при их повреждении;
б) доступ на изменение информации только определенной категории пользователей.
3) Доступность – иерархия уровней доступа и четкое их соблюдение.
Перечислим классические уязвимости современных веб-приложений:
1. XSS – генерация на странице продукта скриптов, представляющих опасность для пользователей продукта;
2. XSRF – уязвимость, при которой пользователь переходит с доверенной страницы на вредоносную, где воруются представляющие ценность пользовательские данные;
3. сode injection (PHP, SQL) – инъекция части исполнительного кода, которая делает возможным получить несанкционированный доступ к программному коду или базе данных и вносить в них изменения;
4. authorization bypass – это вид уязвимости, при котором можно получить несанкционированный доступ к учетной записи или документам другого пользователя;
5. переполнение буфера – явление, которого можно достичь во вредоносных целях, по своей сути представляет использование места для записи данных далеко за пределами выделенного буфера памяти.
При тестировании рекомендую использовать чит-листы уязвимостей XSS Filter Evasion Cheat Sheet и MySQL SQL Injection Cheat Sheet.
Практические советы: еще раз о насущном
Начинаем тестировать не с тестирования: с чего начать?
Я хочу акцентировать ваше внимание на необходимости согласовать все ключевые аспекты с ответственными лицами (аналитиками, проектными менеджерами, разработчиками) еще до начала тестирования. Необходимо заранее выяснить следующие моменты:
· цель тестирования (с их точки зрения);
· виды тестирования, которые необходимо провести;
· специфику приложения и его целевую аудиторию;
· перечень устройств, на которых необходимо проводить тестирование;
· список ОС и браузеров для тестирования;
· разрешения экранов на которых необходимо проверить приложение;
· предусмотрены ли требования к разного рода формам, есть ли стайл-гайд, актуальное ЧТЗ;
· необходимость предоставления конкретной документации по результатам тестирования (отчет, чек-листы, тест-кейсы и т. д.).
Получив ответы на эти вопросы, о которых часто забывают новички, вы сэкономите свое время. Дальше переходите к непосредственной подготовке окружения и формированию стратегии тестирования.
Некогда думать, нужно тестировать!
Любое тестирование требует содержательного подхода с применением техник тест-анализа и тест-дизайна. В противном случае вы рискуете навсегда остаться «monkey-тестером», ценность труда которого будет мизерна. В целом, ключевые положения тест-анализа и тест-дизайна применимы как к тестированию десктоп-приложений, так и к веб-у, но с существенной оговоркой: вы должны учитывать все упомянутые в статье нюансы. Отдельно хочу акцентировать внимание на том, что без стойкого понимания методик и способов применения тест-анализа и тест-дизайна тестировать качественно ПО практически невозможно.
Рассмотрим классический набор методик тест-дизайна, которые можно применять при тестировании веб-приложений:
· разбиение на классы эквивалентности;
· попарное тестирование;
· тестирование переходов состояний;
· анализ граничных значений;
· тестирование с помощью таблиц решений;
· методика тест-туров Виттакера и множество других.
Подай ключ «на 13»
В настоящее время существует огромное множество разнообразных инструментов, которые упрощают жизнь всем участникам разработки нового ПО. Следовательно, не стоит забывать о том, что помимо развития личных качеств, технических знаний и навыков, мы должны уметь хорошо пользоваться вспомогательными инструментами, каждый раз испытывая все новые и новые.
Отмечу лишь некоторые из них:
· Ресайзер – оперативное изменение всяческих настроек размеров отображения, просмотр метрик, переключение ориентаций отображения.
· Opera Mobile Classic Emulator – классический одноименный эмулятор.
· Mobile Phone Emulator – классический эмулятор.
· Fiddler – ПО для отслеживания всего вашего трафика. Я всегда сопровождаю любое тестирование его фоновой работой, а потом сортирую по ошибкам и анализирую трафик. Также с помощью этого приложения можно отправлять ложные запросы на сервер с нужными вам параметрами.
· Xenu Link Evaluator (альтернатива – Black Widow) – «чекер» веб-приложения на предмет наличия в нем «битых» ссылок. Также можно использовать его для формирования карты приложения.
· Skipfish – активный сканер уязвимостей веб-приложений.
· OpenVAS – бесплатный сканер уязвимостей.
· Nikto – веб-сканер, проверяющий веб-серверы на самые частые ошибки, возникающие обычно из-за человеческого фактора.
Выводы и напутствия
Подводя итоги, я хочу еще раз акцентировать внимание читателя на том, что «веб» развивался, развивается и будет развиваться, а количество используемых технологий, как и разнообразие дефектов, – увеличиваться. Возможно, когда-то придет закат эры «веб-а», но это не случится в ближайшие 5-10 лет, поэтому знание основ и понимание сути веб-приложений поистине бесценно. Любой тестировщик рано или поздно прикоснется к «веб-у» своей профессиональной «разрушительной» рукой, но только хороший специалист получит из этого максимально приближенный к требуемому результат.
Важно помнить, что тестирование ПО ставит перед каждым вступившим в стройные ряды сферы обеспечения качества ПО такие задачи, которые практически невозможно решать однозначно и по четкому алгоритму. Тестирование – это философия, творчество, полет мысли, основанный на четких и безоговорочных технических аспектах. Пожалуй, только тестировщикам приходится одновременно быть разработчиком, системным аналитиком, пользователем, заказчиком (для которого первоочередной интерес – финансовый или иной успех продукта), специалистом в предметной области и даже DBA.
Каждый из этих навыков QA Engineer должен развивать постоянно, и тогда он сможет избежать многих возможных проблем и остаться востребованным высококвалифицированным профессионалом. Остановка в развитии для специалиста из сферы обеспечения качества фактически приравнивается к профессиональной смерти (как минимум, «клинической» в том случае, если стремление к новым знаниям со временем возвращается). Движение – это жизнь. Всем добра!
https://quality-lab.ru/key-principles-of-web-testing/