Лекция
Это продолжение увлекательной статьи про web-тестирование.
...
очень быстро «отлавливаются» дефекты с «отвалившимися» стилями, скриптами, файлами, функциями приложения и т.п.
Многопользовательская сущность веб-приложений
Широта аудитории приложений накладывает свой отпечаток на специфику работы.
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-тестером», ценность труда которого будет мизерна. В целом, ключевые положения тест-анализа и тест-дизайна применимы как к тестированию десктоп-приложений, так и к веб-у, но с существенной оговоркой: вы должны учитывать все упомянутые в статье нюансы. Отдельно хочу акцентировать внимание на том, что без стойкого понимания методик и способов применения тест-анализа и тест-дизайна тестировать качественно ПО практически невозможно.
Все виды тестирования программного обеспечения, в зависимости от преследуемых целей, можно условно разделить на следующие группы:
Далее, мы постараемся более подробно рассказать о каждом отдельном виде тестирования, его назначении и использовании при тестировании программного обеспечения.
Функциональные тесты базируются на функциях и особенностях, а также взаимодействии с другими системами, и могут быть представлены на всех уровнях тестирования: компонентном или модульном (Component/Unit testing), интеграционном (Integration testing), системном (System testing) и приемочном (Acceptance testing). Функциональные виды тестирования рассматривают внешнее поведение системы. Далее перечислены одни из самых распространенных видов функциональных тестов:
Нефункциональное тестирование описывает тесты, необходимые для определения характеристик программного обеспечения, которые могут быть измерены различными величинами. В целом, это тестирование того, "Как" система работает. Далее перечислены основные виды нефункциональных тестов:
После проведения необходимых изменений, таких как исправление бага/дефекта, программное обеспечение должно быть пере тестировано для подтверждения того факта, что проблема была действительно решена. Ниже перечислены виды тестирования, которые необходимо проводить после установки программного обеспечения, для подтверждения работоспособности приложения или правильности осуществленного исправления дефекта:
В настоящее время существует огромное множество разнообразных инструментов, которые упрощают жизнь всем участникам разработки нового ПО. Следовательно, не стоит забывать о том, что помимо развития личных качеств, технических знаний и навыков, мы должны уметь хорошо пользоваться вспомогательными инструментами, каждый раз испытывая все новые и новые.
План тестирования предназначен для того, чтобы сформулировать цели задач тестирования. Очень важно подготовить этот документ как можно раньше. Лучше всего, если этот артефакт будет подготовлен уже в ходе первых итераций на этапе уточнения. Возможно, план тестирования тоже следует готовить в итерациях, добавляя разделы по мере появления соответствующей информации.
Особое внимание следует уделить четкому описанию области теста, требований, стратегии и требуемых ресурсов. Эта информация указывает цель и границы теста, что и как будет тестироваться, и какие для этого потребуются ресурсы. Ясная и точная информация позволит спланировать, уточнить и утвердить тест.
В начале работы над проектом необходимо создать план, описывающий в целом аспекты тестирования и называющийся "Общий план тестирования". В ходе планирования итераций создается более конкретный "план тестов в итерации", или же несколько таких планов для разных типов тестов, в котором указываются требования к тесту, стратегия и ресурсы, относящиеся к этой итерации. Эта информация может быть включена вместо этого в план итерации, если это не усложняет подготовку или использование плана итерации.
Следующие рекомендации помогают подготовить и сформулировать требования для теста, риски, приоритеты и стратегии теста.
Требования для теста указывают, что будет тестироваться. Они относятся к конкретной цели теста. При подготовке требований придерживайтесь следующих общих правил:
Источниками требований для тестов могут быть варианты использования, модели вариантов использования, вспомогательные спецификации, проектные требования, варианты бизнес-процесса, интервью с пользователями и документ архитектуры программного обеспечения. Все эти источники должны быть критическим образом пересмотрены, чтобы сформулировать требования для теста.
Функциональные требования создаются на основе описания функционального поведения целевого объекта тестирования. Каждый вариант использования должен быть отражен как минимум в одном требовании. Более подробный список требований может включать хотя бы одно требование для каждого из потоков варианта использования.
Требования по производительности возникают на основе изучения поведения, связанного с производительностью целевого объекта тестирования. Обычно производительность оценивается в единицах времени ответа и/или использования ресурсов в разных условиях, а именно:
Требования по производительности описаны в вспомогательных спецификациях. При работе с этими материалами обратите особое внимание на следующее:
Каждый из этих моментов спецификации должен быть отражен как минимум в одном требовании.
Источниками для создания тестов надежности являются вспомогательные спецификации, рекомендации по пользовательскому интерфейсу, рекомендации по проектированию и рекомендации по программированию.
При работе с этими материалами обратите особое внимание на следующее:
Каждый из этих моментов должен быть отражен как минимум в одном требовании.
Успех тестирования зависит от того, как удается сбалансировать такие факторы, как ограничения ресурсов и риски. Для этого тестирование должно планироваться таким образом, чтобы наиболее важные или рискованные варианты использования или компоненты тестировались в первую очередь. Оценка рисков и профайл работы служат основой для определения приоритетов в ходе тестирования.
В следующих разделах описаны способы определения приоритетов тестов.
Определение требований теста - это только часть подготовки к тестированию. Также необходимо определить приоритеты и очередность выполнения работы. Это этап необходим по следующим причинам:
В оценке рисков и определении приоритетов тестирования можно выделить три момента:
Для каждого из этих моментов далее приведены соответствующие рекомендации.
Определение приоритета в тестировании начинается с оценки риска. Первыми должны быть протестированы варианты использования или компоненты, которые представляют наибольшую опасность при отказе или имеют высокую вероятность отказа.
Начните с описания степени риска, используя следующие обозначения:
После этого составьте список всех вариантов использования и компонентов целевого объекта тестирования. Для каждого варианта использования и компонента укажите степень риска и краткое обоснование.
Оценка риска может выполняться в трех проекциях:
Выберите какую-либо проекцию, определите индикатор риска и обоснуйте свой выбор. Нет необходимости определять индикатор для каждой проекции. Однако рекомендуется для элементов с низкой степенью риска повторить оценку в другой проекции, чтобы убедиться, что риск действительно низкий.
Далее оценка риска в этих трех проекциях описана более подробно.
Для оценки риска по последствиям выберите условие, событие или действие и попробуйте определить его воздействие. Задайте вопрос:
"Что произойдет, если ___________?"
Пример:
Ниже приведена соответствующая таблица:
| Описание | Фактор риска | Обоснование |
|---|---|---|
| Недостаточно места на диске при установке | H | Установка программного обеспечения создает первое впечатление пользователя о продукте. Любые нежелательные эффекты из числа перечисленных ниже ухудшат впечатление пользователя о продукте и могут привести к нарушениям в работе системы и программного обеспечения:
|
| соединение с Internet нарушается в ходе запроса | L | Данные или база данных не повреждаются при обрыве соединения. Известно, что обрыв соединения может создать негативное впечатление у пользователя. |
| соединение с Internet нарушается в ходе покупки | H | Недопустимо, чтобы обрыв соединения или невыполненная транзакция приводили к нижеперечисленным эффектам, вследствие которых возрастают затраты и уменьшается прибыль:
|
| Ввод непредвиденного значения | H | Недопустимо, чтобы невыполненная транзакция приводила к нижеперечисленным эффектам, вследствие которых возрастают затраты и уменьшается прибыль:
|
Оценка риска по причинам противоположна оценке по последствиям. Начните с того, что укажите нежелательное событие или состояние, и определите набор событий, которые могут к нему привести. Задайте вопрос:
"Как могло произойти ___________ ?
Пример:
Ниже приведена соответствующая таблица:
| Описание | Фактор риска | Обоснование |
|---|---|---|
| Отсутствуют файлы приложения и записи реестра | H | Приложение (и система в целом) могут оказаться в нерабочем состоянии. Установка приложения - это первое, с чем сталкивается пользователь. Если установка завершается ошибкой, то какова бы ни была причина, у пользователя складывается негативное впечатление о продукте.
Возможные причины:
Среди всех этих причин только последняя не может быть предусмотрена программой установки. |
| неполный заказ | H | Неполные заказы выполнить невозможно, что приводит к потере дохода и заказчиков.
Возможные причины:
|
| Повреждение данных / базы данных | H | Повреждение данных является абсолютно недопустимым.
Возможные причины:
|
| Повторяющиеся заказы | H | Повторяющиеся заказы увеличивают нагрузку на компанию и уменьшают прибыль из-за дополнительных расходов на доставку, обработку и складирование.
Возможные причины:
|
| Неточные данные для заказа | H | Все заказы, которые не могут быть выполнены или влекут дополнительные расходы, недопустимы.
Возможные причины:
|
| В операторе указано неверное число записей | H | От точности отчетов зависят бизнес-решения и счета.
Возможные причины:
|
Оценка риска по вероятности позволяет определить вероятность отказа варианта использования или компонента. Обычно вероятность рассчитывается по внешним факторам, таким как:
Отметим, что при работе с этой проекцией риска, показатели факторов риска связаны с вероятностью отказа, а не с последствиями отказа, как это было при оценке риска по причинам и последствиям.
Эти факторы и вероятность отказа связаны между собой, как показано ниже:
| Внешний фактор | Вероятность |
|---|---|
| Частота обнаружения отказов | Вероятность отказа возрастает с увеличением частоты отказов. Ошибки имеют тенденцию к накоплению, поэтому если увеличивается частота обнаружения или число ошибок в варианте использования или компоненте, то вероятность других ошибок также возрастает. Также следует принять во внимание частоту отказов в предыдущих выпусках, так как если она была велика, то в этом выпуске с большой вероятностью будут обнаружены дополнительные ошибки. |
| Скорость изменений | Вероятность отказа возрастает с увеличением скорости изменения варианта использования или компонента. Чем больше внесено изменений, тем больше вероятность того, что они содержат ошибки. Всякий раз изменения в коде влекут за собой опасность новых ошибок. |
| Сложность | Вероятность отказа возрастает с увеличением сложности варианта использования или компонента. |
| Источник / автор | Знание того, кем и как был написан код, также влияет на вероятность отказов. Применение компонентов сторонних разработчиков обычно снижает вероятность отказа. Однако это справедливо только для проверенных компонентов, отвечающих вашим требованиям или прошедшим формальную проверку или тестирование. Вероятность ошибок меньше у знающих и опытных разработчиков. Однако такие факторы, как работа с новыми инструментами, технологиями или выполнение нескольких ролей повышает вероятность ошибок даже у лучших участников коллектива. |
Пример:
Ниже приведена соответствующая таблица:
| Описание | Фактор риска | Обоснование |
|---|---|---|
| Установка нового программного обеспечения | H | Мы пишем собственную программу установки.
Делает приложение неработоспособным. Установка приложения - это первое, с чем сталкивается пользователь. Если установка завершается ошибкой, то какова бы ни была причина, у пользователя складывается негативное впечатление о продукте. |
| Установка нового программного обеспечения | L | Мы используем опробованную коммерческую программу установки.
Хотя в результате установки приложение оказалось неработоспособным, выбранная программа установки поставляется производителем с мировым именем, который известен в бизнесе уже свыше четырех лет. Наши оценки говорят о том, что продукт отвечает нашим потребностям, и клиенты удовлетворены самим продуктом, производителем и уровнем обслуживания и поддержки. |
| Высокая частота обнаружения ошибок в вариантах использования 1, 10, 12. | H | Вследствие того, что в прошлых выпусках в вариантах использования 1, 10 и 12 было найдено много ошибок, эти варианты считаются рискованными. |
| Запросы на изменение в вариантах использования 14 и 19. | H | Большое число изменений в этих вариантах использования увеличивает вероятность возникновения в них ошибок. |
Далее необходимо определить операционный профайл, с тем чтобы оценить риски и определить приоритеты тестов.
Начните с
продолжение следует...
Часть 1 Web-тестирование, особенности, виды, последовательность
Часть 2 Основные подходы Практические советы - Web-тестирование, особенности, виды, последовательность
Часть 3 Вау!! 😲 Ты еще не читал? Это зря! - Web-тестирование, особенности, виды, последовательность
Надеюсь, эта статья об увлекательном мире web-тестирование, была вам интересна и не так сложна для восприятия как могло показаться. Желаю вам бесконечной удачи в ваших начинаниях, будьте свободными от ограничений восприятия и позвольте себе делать больше активности в изученном направлени . Надеюсь, что теперь ты понял что такое web-тестирование, web тестирование, вебтестирование и для чего все это нужно, а если не понял, или есть замечания, то не стесняйся, пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Качество и тестирование программного обеспечения. Quality Assurance.
Ответы на вопросы для самопроверки пишите в комментариях, мы проверим, или же задавайте свой вопрос по данной теме.
Комментарии
Оставить комментарий
Качество и тестирование программного обеспечения. Quality Assurance.
Термины: Качество и тестирование программного обеспечения. Quality Assurance.