Техники тест-дизайна

Классы эквивалентности (Эквивалентное разбиение)

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

есть позитивные и негативные

 

Граничные значения (Анализ граничных значений)

+1 и -1 значение на границе каждого класса эквивалентности

 

Попарное тестирование (PAIRWISE TESTING)

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

 

Таблица принятия решений

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

Какие возможны сценарии:
1.       Правильный логин и правильный пароль.
2.       Правильный логин, неправильный пароль.
3.       Неправильный логин, правильный пароль.
4.       Неправильный логин, неправильный пароль.

 

Тестирование состояний и переходов

Техника для визуализации ТЗ. Она наглядно показывает, как некий объект переходит из одного состояния в другое.

Причина и следствие

Это, как правило, ввод комбинаций условий (причин), для получения ответа от системы (Следствие). Например, вы проверяете возможность добавлять клиента, используя определенную экранную форму. Для этого вам необходимо будет ввести несколько полей, таких как “Имя”, “Адрес”, “Номер Телефона” а затем, нажать кнопку “Добавить” – эта “Причина”. После нажатия кнопки “Добавить”, система добавляет клиента в базу данных и показывает его номер на экране – это “Следствие”.

Предугадывание ошибок

Это когда тест аналитик использует свои знания системы и способность к интерпретации спецификации на предмет того, чтобы “предугадать” при каких входных условиях система может выдать ошибку. Например, спецификация говорит: “пользователь должен ввести код”. Тест аналитик, будет думать: “Что, если я не введу код?”, “Что, если я введу неправильный код? “, и так далее. Это и есть предугадывание ошибки.

Модели разработки

Waterfall (классическая\водопадная\каскадная)

каждый этап разработки продолжает предыдущий

для перехода на новый этап обязательно должны завершить текущий

 

V модель

этапы разработки и тестирования идут попарно начиная с первого этапа разработки

 

Итерационный подход

жизненный цикл продукта разбит на ряд небольших циклов

каждый цикл это самостоятельная единица

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

Компонентное \ Модульное \ Unit тестирование

тестирование компонентов(модулей) системы

например корзины на веб  сайте

 

Интеграционное тестирование

тестирование взаимодействия между модулями системы или внешними интеграциями и системой

 

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

полная проверка приложения \ сайта

 

Приемочное тестирование

тестирование проводимое при сдаче функционала заказчику

  • Пользовательское приемочное тестирование UAT (тестирование конечным пользователем)
  • Эксплуатационное (тестирование бекапов, восстановления системы, безопасность)
  • Тестирование на соответствие контракту (проверка на соответствие госту или приемочной спецификации)
  • Альфа тестирование (Эксплуатационное тестирование на стороне разработчиков)
  • Бета тестирование (во внешней среде без участия разработчиков, группой пользователей)

 

Идентификация, аутентификация и авторизация: определения

Идентификация, аутентификация и авторизация: серьезные определения

Итак, что же значат термины «идентификация», «аутентификация» и «авторизация» — и чем соответствующие процессы отличаются друг от друга? Для начала проконсультируемся с «Википедией»:

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

Объясняем идентификацию, аутентификацию и авторизацию на енотах

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

  • Для начала система запрашивает логин, пользователь его указывает, система распознает его как существующий — это идентификация.
  • После этого Google просит ввести пароль, пользователь его вводит, и система соглашается, что пользователь, похоже, действительно настоящий, раз пароль совпал, — это аутентификация.
  • Скорее всего, Google дополнительно спросит еще и одноразовый код из SMS или приложения. Если пользователь и его правильно введет, то система окончательно согласится с тем, что он настоящий владелец аккаунта, — это двухфакторная аутентификация.
  • После этого система предоставит пользователю право читать письма в его почтовом ящике и все в таком духе — это авторизация.

Баг репорт / Severity и Priority / Цикл жизни бага

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

Атрибуты Баг-репорта:

  • Короткое описание проблемы
    • Шаги воспроизведения
    • Полученный результат
    • Ожидаемый результат
  • Проект
  • Компонент
  • Версия билда/программы
  • Серьезность (Severity)
  • Приоритет (Priority)
  • Статус
  • Автор
  • Назначение
  • Окружение (environment)
  • Прикрепленные файлы

Серьезность (Severity)

  • Blocker (Ошибка приводящая программу в нерабочее состояние)
  • Critical (Ошибки приводящие ключевой функционал в нерабочее состояние, отклонение от бизнес логики, потеря пользовательских данных, в отличии от Блокера часть программы может функционировать)
  • Major (Серьезные ошибки в логике, не приводящие приложение в нерабочее состояние)
  • Minor (Незначительный дефект, не нарушающий функционал приложения)
  • Trivial (Тривиальные баги, не мешающие работать программе, например опечатка)

Окружение (environment)

  • dev (разработчики, тестирование нового функционала)
  • stage (стабильная версия приложения, доведение до пред-релиза, тестирование)
  • prod (работа конечных пользователей)

Цикл жизни бага

  1. Unconfirmed (Не проверен)
  2. New (Новый, внесен в баг-трекер)
  3. Assigned (В работе, открыт)
  4. Resolved (Закрыт)
  5. Reopen or Verifed (Переоткрыт или подтвержденно решен)
  6. Closed (Закрыт)

Posts navigation

1 2 3
Scroll to top