Профессия: тестировщик

Вербальное взаимодействие и его отсутствие

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

Невербальное тестирование предполагает наглядное представление информации. Объект получает чертежи, картинки, графики. Речевые способности необходимы, чтобы понять инструкции, а исполнение собственно задания обусловлено психомоторикой. Классический пример невербального исследования – матрица Равена. Такие тесты менее чувствительны к языковым отличиям, культурным особенностям. Можно тестировать людей, страдающих нарушениями речевой, слуховой функции, лиц с ослабленными интеллектуальными способностями, а также тех, у кого выявлены проблемы с обучаемостью. Невербальные подходы получили распространение как методы оценки комбинаторных мыслительных процессов, пространственных. Нередко невербальные тесты являются дополнительным этапом оценки интеллекта, способностей, достижений испытуемого.

Нефункциональное тестирование

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

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

Тестирование производительности

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

• Задержка сети
• Обработка на стороне клиента
• Обработка транзакций базы данных
• Балансировка нагрузки между серверами
• Передача данных

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

• Скорость (т.е. время отклика, передача данных и доступ)
• Вместимость
• стабильность
• Масштабируемость

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

Тестирование нагрузки

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

В большинстве случаев тестирование нагрузки выполняется с помощью таких автоматизированных инструментов, как Load Runner, AppLoader, IBM Rational Performance Tester, Apache JMeter, Silk Performer, Visual Load Load Test и т.д .

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

Стресс-тестирование

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

Цель стресс-тестирования состоит в том, чтобы протестировать программное обеспечение, применяя нагрузку к системе и используя ресурсы, используемые программным обеспечением для определения точки прерывания. Это тестирование может быть выполнено путем тестирования различных сценариев, таких как:

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

Ну а по существу?

• Что у него есть 10 точек входа, для простоты, в нашем случае расположенных на одном IP
• Мы знаем все они принимают GET-запрос на вход, возвращая какие-либо данные в формате json.

• Выполнив один простой GET-запрос к одной из этих точек входа, и получив ответ в формате json, мы уже убеждаемся что дымное тестирование пройдено.
  Если же одна из этих точек входа так же возвращает данные из БД, тогда как первая — нет, нужно дополнительно выполнить ещё один запрос, чтобы убедиться что приложение
  верно обрабатывает запросы к базе. И на этом «дымный» тест закончен.
  То есть мы выполнили запрос — от сервиса пришёл ответ, и он не «задымился», то есть не вернул ошибку 4хх или 5хх, и что-то невнятное, вместо json. На этом можно сказать что «дымный» тест пройден. Для проверки того, что работает так же и UI достаточно просто один раз открыть страницу в браузере.
• Санитарное тестирование в данном случае будет состоять из выполнения запроса ко всем 10 точкам входа в api, сверкой полученного json с ожидаемым, а так же наличием требуемых данных в нём.
• Регрессионные тесты будут состоять из smoke + sanity + UI выполняемые вместе в одной куче. Цель: проверить что добавление 11-ой точки входа не поломало, к примеру, восстановление пароля.
• Ре-тест в данном примере это точечная проверка что, к примеру, сломавшаяся точка входа в api в следующем билде отрабатывает как задумывалось.

Диаграмма переходов состояний

Техника

Состояние (State) — Условие в котором система ожидает одно или несколько событий.Состояние помнит что было получено на вход и определяет ответную реакцию, которая должна произойти. Это событие может быть приводить в новое состояние и/или инициировать новое действие. Состояние обычно отражает значение некоторой переменной в системе. Изображается в форме круга.

Переход (Transition) — Представляет переход из текущего состояния в новое, в результате выполнения какого-то действия. Изображается в виде стрелки.

Событие (Event) — Событие, ставшее причиной изменения состояния. Обычно событие поступает в систему из внешнего мира посредством некоторого интерфейса. Иногда это событие инициируется внутри самой системы например такие как срабатывание таймера, снижение ниже какого-то уровня. Считается, что событие происходит моментально. Событие может быть как независимым, так и связанным. Когда событие случается, система может изменить состояние или остаться в прежнем состоянии и/или инициировать действие. События могут иметь, связанные с ними параметры (номер карты, сумма на счете). Изображается как подпись к стрелке перехода.

Действие (Action) — Операция, инициированная в результате смены состояния. Зачастую это некоторый ответ системы. Помните, что действие происходит при переходе между состояниями. Состояния сами по себе статичны. Указывается через слеш в подписи к стрелке перехода после события.

Диаграмма перехода состояний представляет собой одну специфическую сущность (например, процесс резервирования). Частая ошибка — попытка смешивать разные сущности в одной диаграмме (например Резервирование и Пассажира с событиями и действиями, связанными с каждым из них).

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

На основании Диаграммы перехода состояний составляется Таблица перехода состояний. Таблица содержит 4 колонки: текущее состояние, событие, действие, следующее состояние.

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

Может быть выбран один из 4 вариантов создания тест-кейсов:

1. Создать наборы тест-кейсов так, чтобы все состояния были пройдены хотя бы по одному разу. В одном тест-кейсе может быть описан переход через несколько состояний. Это довольно слабый уровень тестового покрытия.
2. Создать наборы тест-кейсов так, чтобы все события были инициированы хотя бы по одному разу. Тест-кейсы, которые покрывают все события в то же время покрывают и все состояния. Снова слабый уровень тестового покрытия.
3. Создать наборы тест-кейсов так, чтобы все пути были пройдены хотя бы по одному разу. Такой способ хорош с точки зрения тестового покрытия, однако практически не осуществим. Если диаграмма имеет циклы, то количество возможных путей может оказаться бесконечным.
4. Создать наборы тест-кейсов так, чтобы все переходы были выполнены хотя бы по одному разу. Этот способ обеспечивает хороший уровень тестового покрытия, поэтому рекомендуется использовать именно его.
   Рекомендуемая стратегия создания тест-кейсов состоит в том, чтобы хотя бы по разу протестировать все переходы между состояниями. В высокорисковых системах, где требуется более надежное тестовое покрытие, возможно создавать тест-кейсы на каждый путь (цепочку переходов) между состояниями.

Виды тестирования

Unit-тестирование (модульное тестирование) — данный вид подразумевает тестирование отдельных модулей приложения. Для получения максимального результата тестирование проводится одновременно с разработкой модулей.

Функциональное тестирование — цель данного тестирования состоит в том, чтобы убедиться в надлежащем функционировании объекта тестирования. Тестируется правильность навигации по объекту, а также ввод, обработка и вывод данных.

Тестирование БД — проверка работоспособности БД при нормальной работе приложения, в моменты перегрузок и многопользовательском режиме. 

Unit-тестирование

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

В выходную документацию данных тестов входят тестовые процедуры, входные данные, код, исполняющий тест, выходные данные. Далее представлен вид выходной документации. 

Функциональное тестирование

Функциональное тестирование объекта тестирования планируется и проводится на основе требований к тестированию, заданных на этапе определения требований. В качестве требований выступают бизнес-правила, диаграммы use-case, бизнес-функции, а также при наличии, диаграммы активности. Цель функциональных тестов состоит в том, чтобы проверить соответствие разработанных графических компонентов установленным требованиям.

Данный вид тестирования не может быть полностью автоматизирован. Следовательно, он подразделяется на:

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

Цель: протестировать ввод, обработку и вывод данных;

Ручное тестирование (в остальных случаях).

Цель: тестируется правильность выполнения пользовательских требований.

Необходимо исполнить (проиграть) каждый из use-case, используя как верные значения, так и заведомо ошибочные, для подтверждения правильного функционирования, по следующим критериям:

• продукт адекватно реагирует на все вводимые данные (выводятся ожидаемые результаты в ответ на правильно вводимые данные);
• продукт адекватно реагирует на неправильно вводимые данные (появляются соответствующие сообщения об ошибках).

Тестирование БД

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

Необходимо последовательно использовать максимально возможное число обращений к базе данных. Используется подход, при котором тест составляется таким образом, чтобы «нагрузить» базу последовательностью, как верных значений, так и заведомо ошибочных. Определяется реакция БД на ввод данных, оцениваются временные интервалы их обработки.

Tags:

• модели жизненного цикла
• начинающему тестировщику
• общие вопросы
• теория тестирования

View the discussion thread.

blog comments powered by DISQUS

Бета-тестирование

Этот тест выполняется после успешного выполнения альфа-тестирования. В бета-тестировании образец целевой аудитории тестирует приложение. Бета-тестирование также известно как предварительное тестирование. Бета тестовые версии программного обеспечения идеально распределяются среди широкой аудитории в Интернете, отчасти для того, чтобы дать программе «реальный» тест и частично обеспечить предварительный просмотр следующего выпуска. На этом этапе аудитория будет тестировать следующее:

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

Писать или не писать тесты?

Я видел очень множество мнений на этот счёт, но сам пришел к своему собственному: надо ориентироваться на потребности бизнеса.

Для сделанного за пару часов на коленке куска кода тесты не нужны. С другой стороны, для крупного корпоративного проекта на сотни человеколет обязательны все популярные виды тестов. А все, что находится между этими полюсами, надо рассматривать как частный случай, оценивая стоимость тех или иных видов тестирования: с тестами она должна быть меньше, чем без них. Лично я пишу smoke тесты даже для крошечного CRUD-проекта длинной в пару недель, потому что уже на такой дистанции они приносят пользу и уменьшают стоимость разработки.

Плюсы тестирования, кратко и тезисно:

• Значительное снижение стоимости исправления бага из-за раннего обнаружения.
• Фиксирование контрактов.
• Документация низкого уровня.
• Обнаружение архитектурных проблем.

Так что если ваши проекты не являются одноразовыми скриптами из несколько файлов, то я однозначно рекомендую писать тесты. Поэтому вопрос из заголовка стоит переформулировать: «В каком объеме писать тесты, и какие?» Об этом далее.

iSpring — платформа для онлайн-обучения и тестирования и сотрудников

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

Обзор возможностей iSpring

iSpring — интернет-сервис. Не нужно устанавливать его на свой сервер и привлекать IT-специалистов для настройки. Создаёте аккаунт и тестируете сотрудников.

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

Описание iSpring

1. Пробная версия. У iSpring есть бесплатная пробная версия на 14 дней. Чтобы её получить, заполните форму на сайте: имя, почта и номер телефона.
2. Возможности. В iSpring встроен мощный конструктор для создания опросов, психологических тестов и тестов на проверку знаний.
3. Виды тестов. В iSpring можно собирать опросы, психологические тесты и тесты на проверку знаний. В вашем распоряжении 14 типов заданий: на соответствие, выбор одного или нескольких вариантов ответа, выбор области, drag-and-drop, последовательность.
4. Особые опции. Вы можете изменить дизайн каждого вопроса и задать правила тесту: установить баллы и штрафы, автоматически перемешивать задания перед тестированием, указать количество попыток и ограничить время ответа на каждый вопрос, чтобы сотрудники не списывали.
5. Формат платформы. iSpring работает через интернет. Тестируйте и обучайте сотрудников онлайн сразу после регистрации.
6. Уровень сложности интерфейса: 1 из 5.
7. Брендирование. Вы можете оформить платформу под корпоративный стиль: добавить логотип, изменить цвета и URL-адрес.
8. Статистика. В iSpring доступно 15 типов отчетов. Платформа самостоятельно проверяет, какие варианты ответа выбирают ваши сотрудники по каждому заданию, в каких вопросах они допускают ошибки, какие результаты получают и сколько времени в целом тратят на тест. Всю информацию система собирает в отчёты, которые можно скачать в excel-формате.
9. Цена. Вы платите за количество пользователей. Цена за одного пользователя — 82 рубля в месяц. Минимальный пакет — 12 человек.

Кому подходит iSpring

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

Управлять платформой может один человек, к примеру, менеджер по обучению или HR-специалист.

Клиенты iSpring

Платформу используют как крупные корпорации, так и средний бизнес. Среди клиентов Johnson & Johnson, Redmond, «Яндекс», «Додо Пицца», «Альфа Капитал» и мясоперерабатывающий завод «Богородский»

Актуальность вопроса

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

Классификация видов тестирования предполагает разделение всего существующего массива методов и подходов на несколько групп. Есть две системы классификации. Первая предполагает оценку критериев, вторая – норм.

Главная деятельность тестировщиков

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

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

Существует наука — «теория систем». В ней определяется такое понятие как «обратная связь»:

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

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

И та, и другая разновидности обратной связи равноценно важны.

В разработке программных систем положительной обратной связью, конечно же, является какая-то информация, которую мы получаем от конечных пользователей. Это запросы на какую-то новую функциональность, это увеличение объема продаж (если мы выпускаем качественный продукт).

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

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

Рекомендации по созданию тест-кейсов на основе вариантов использования

1. Начать с валидных данных и наиболее частых сценариев.
2. Проверить граничные значения и невалидные значения (с использованием ранее рассмотренных техник).
3. Редко используемые сценарии, крайне важные для системы (так называемая “Остановка ядерного реактора” Shut Down The Nuclear Reactor)
4. Тесты на каждое ветку-альтернативу (Extension) каждого шага
5. Попробовать выполнить операцию в непривычном порядке
6. Извратить предусловие, если это действительно может произойти
7. Если транзакция имеет циклы, запустите ее в цикле, и не один-два раза — будьте жестче
8. Найти очень долгий и извилистый путь и пройдите по нему
9. Если ожидается, что транзакция будет выполняться в логичном порядке, попробовать выполнить ее в обратном порядке (например заполнить поля не сверху вниз, а снизу вверх)
10. Создать тесты на защиту от дурака

Шаблон описания вариантов использования

Психология и тестирование

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

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

Проверка и проверка

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