Перейти к содержимому

Тестирование производительности: JMeter 5
онлайн, начало 2 июля
SQL: Инструменты тестировщика
онлайн, начало 1 июля
Docker: инструменты тестировщика
онлайн, начало 1 июля
Программирование на C# для тестировщиков
онлайн, начало 25 июня
Фотография

Тестирование программного обеспечения. Базовый курс


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 20

#21 svyatoslav

svyatoslav

    Новый участник

  • Members
  • Pip
  • 11 сообщений
  • ФИО:Святослав Куликов
  • Город:Минск

Отправлено 10 декабря 2015 - 14:46

Артём,
 

Есть некоторые вопросы:
1.  В рекомендациях по написанию тест кейсов категорически запрещается ссылаться на другие тест-кейсы (их части).
Как вы тогда на практике решаете следующую ситуацию:
 a) Есть несколько довольно объемных блоков данных  (адрес, место работы и т.д.) и эти блоки в разных вариациях встречаются у большого числа пользователей на большом числе шагов, при этом они могут незначительно отличаться по содержимому
 б) При этом требования к блокам дополняются/изменяются в течение спринта.


Пусть и не совсем такая конкретная ситуация, но предпосылки к подобному и пути решения даже описаны в книге (см. "Подробная классификация наборов тест-кейсов", начиная со 139-й страницы). Это можно сделать через т.н. "обобщённый свободный набор", указав для всех тестов в наборе некий эталонный/базовый перечень входных параметров, а уже в каждом тесте разместить "патч" этого набора, приводящий к нужному итоговому результату.
Что до пункта "б" вашего вопроса, то это вечный вопрос и вечная боль. Но тоже решаемо, если знать количественные и качественные изменения -- от подготовки избыточных наборов входных данных (покрывающих все варианты), до элементов исследовательского тестирования в рамках сценариев (как завещал Виттакер).
 

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


А зачем нам в остальных тестах проверка этого блока, если мы его уже проверили одним тестом?
Тут ведь одно из трёх:
а) Если нам надо В ТОЧНОСТИ выполнить некие действия для нескольких тестов -- делаем набор, выносим эти действия в его пригтовления.
б) Если нам надо "примерно" выполнить некие действия (не важно, как именно, но в стиле "указать верные ФИО") -- снова делаем набор, выносим это в общие приготовления и подчёркиваем, что тут нужна вариативность.
в) Если нам надо выполнить некие специфичные для каждого теста действия, от которых зависят дальнейшее развитие теста и его результат -- тут я бы не ленился и писал в каждом тесте заново (да, даже богомерзким копи-пейстом и правками). Если подавляющий набор шагов/данных одинаков, а дьявол кроется в деталях -- см. выше про единые набор + "патчи".

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

2. В блоке 'Исходные данные' (стр. 122) вы настоятельно не рекомендуете описывать действия по подготовке, которые выполняются в  самом тестируемом приложении.
a) Пример 1: Как тогда вы будете проверять таблицу на отображение только 10 первых строк (если её наполнение происходит средствами приложения): первые шаги теста будут заключаться в наполнении таблицы данными, а не в непосредственном тестировании требования ?


Персонально я вообще бы напрямую через СУБД накидал в БД то, что мне нужно :). Особенно, если строк не 10, а 10 миллионов.
Но если это невозможно или нежелательно, то:
а) Набор из последовательных тестов.
б) Формулировка приготовления в виде предусловия: "В БД в таблице такой-то должно быть столько-то строк". Тесту ставить "невозможно выполнить", если добавить строки не удалось. Но сам тест, если он направлен на отображение, фейлить из-за невозможности вставки... как-то... не по фен-шую.
в) Если цель теста -- "запихнуть N >> 10 и убедиться, что отображается только 10", да, в шагах теста указал бы добавление. Если бы не добавлялось, зафейлил бы тест с чистой совестью.
 

б) Пример 2: Есть некоторый длинный бизнес процесс и у нас в конце есть форма, которую нам надо проверить. И есть сквозной смоук тест, проходящий по данному процессу.


Смоук-тест в виде последовательного сценария или нескольких независимых друг от друга последовательных сценариев.
 

Как я рекомендую поступать: в Preconditons делать ссылку на Smoke (т.к. не факт что каждый из тестировщиков, а тем более новичков понимает как дойти до нужного шага) и указывать шаг процесса, который нам нужен для проверки.


И вот однажды тёмной-тёмной ночью кто-то что-то меняет/добавляет/удаляет в "объекте, на который мы сослались" так, что у него всё логично и работает, а у нас получается бред. Что делать тогда?

P.S. Ещё раз суть: если у нас есть гарантия, что без ведома и позволения "ссылающейся части" никто не поменяет ничего в "части, на которую ссылаются" -- в путь и с песней. Но если такой гарантии нет, я бы предпочёл не создавать хитросплетение из перекрёстных ссылок. Т.е. запретить ссылки вообще. Ниче они начинают плодиться как кролики, и через какое-то время получаем "спагетти-тесты", если можно так сказать по аналогии со спагетти-кодом.
  • 0


Первый Онлайн ИНститут Тестировщиков
онлайн
Школа для начинающих тестировщиков
онлайн
Логи как инструмент тестировщика
онлайн
Selenium 2.0: стартовый уровень
онлайн



Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных

Яндекс.Метрика
Реклама на портале