На всякий случай, стандарт устарел.

Смотрите википедию.

вроде всё прокликали, что могло пойти не так?

 

в результате оказывается что используя РЕСТ АПИ любой пользователь может удалять чужие сообщения! так как контроль доступа на бэк-энде сломался либо его забыли имплементировать вообще, и только на фронте кнопка появлялась или исчезала, а бэкэнд оказывается всегда исполняет команды

 

Это говорит только о неполноте регрессии. У нас на проекте, где лид был строго убежден в неэффективности автоматизации, все точки доступа всё равно проверяли руками через Fiddler.

Поправочка. Конечно, можно сказать, что пара [TypeRT] = "listRT" и [TypePT] = "listPT" будет невозможна по исходным данным.

Но не уверен, что PICT может выводить такое из зависимых условий. Может быть, ему надо указывать такие ограничения более явно.

Я не знаю исходных требований, поэтому подсказывать сложно.

Но последний вариант уже несовместим с первым.

И в последнем вообще запутались, например, "IF [Container] = "RTPTAT" THEN [TypeRT] = ..." определено 2 раза по-разному, да и не только это.

Взялся за задачу, т.к. до сих пор не приходилось опробовать на практике этот инструмент на чем-то достаточно сложном.

Во-первых, насчет Restrictive constraints. Противоречия в последнем варианте снова есть. Я больше не буду ни на что указывать, лучше найдите сами.

Во-вторых, результаты экспериментов. Вот максимальная модель, которая у меня заработала (некоторые обозначения поменял для своего удобства). Контейнеры выкинул, т.к. в них и была проблема. Всё же, для системы первичны значения AccessRT/PT/AT, а контейнеры - это просто их комбинация.

Solution:       Solution, None
AccessSolution: F, R, CRUD, CRU, CRD, None
AccessRT:       F, R, CRUDE, CRUD, CRU, CR, RUDE, RUE, RUD, None
AccessPT:       F, R, CRUDE, CRUD, CRU, CR, RUDE, RUE, RUD, None
AccessAT:       F, R, CRUDE, CRUD, CRU, CR, RUDE, RUE, RUD, None
TypeRT:         L, F, O, LFO, None
TypePT:         L, O, LO, None
TypeAT:         L, F, O, LFO, None
AccessTypeRT:   RUD, RU, R, None
AccessTypePT:   RUD, RU, R, None
AccessTypeAT:   RUD, RU, R, None

IF [Solution] = "None"
 THEN [AccessSolution] = "None"
 ELSE [AccessSolution] <> "None";

IF [AccessRT] = "None"
 THEN [TypeRT]  = "None" AND [AccessTypeRT]  = "None"
 ELSE [TypeRT] <> "None" AND [AccessTypeRT] <> "None";

IF [AccessPT] = "None"
 THEN [TypePT]  = "None" AND [AccessTypePT]  = "None"
 ELSE [TypePT] <> "None" AND [AccessTypePT] <> "None";

IF [AccessAT] = "None"
 THEN [TypeAT]  = "None" AND [AccessTypeAT]  = "None"
 ELSE [TypeAT] <> "None" AND [AccessTypeAT] <> "None";

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

Итого, есть 2 идеи:

1. На каждый тип контейнера вручную делать свою модель, и в ней лишние поля просто удалять. Пока получится 5 файликов, не страшно.
2. Тестов всё равно очень много - сотни. Это явно неподходящая техника для создания ручных тестов. А если автоматизируем, то можно вообще выкинуть pairwise и тестировать всё подряд. Здесь 2 "но": это можно сделать, если тесты быстрые (всё же, сплошным перебором их будет на порядок больше), и если технически возможно написать оракул для проверки любой комбинации.

Проверьте, если я ошибаюсь.

IF [Container] = "RTPT" THEN [TypeRT] = "listRT" OR [TypeRT] = "formRT" OR [TypeRT] = "operationRT";
IF [Container] = "RTPT" THEN [TypePT] = "listPT" OR [TypePT] = "operationPT";

Это означает, что валидно [Container] = "RTPT", [TypeRT] = "listRT", [TypePT] = "listPT".

Далее по модели:

IF [TypeRT] = "listRT" THEN [AccessTypeRT] = "RUD" OR [AccessTypeRT] = "RU" OR [AccessTypeRT] = "UD" OR [AccessTypeRT] = "R";
IF [TypeRT] = "listRT" THEN [AccessTypePT] = "0";

и:

IF [TypePT] = "listPT" THEN [AccessTypePT] = "RUD" OR [AccessTypePT] = "RU" OR [AccessTypePT] = "UD" OR [AccessTypePT] = "R";
IF [TypePT] = "listPT" THEN [AccessTypeRT] = "0";

Похоже на противоречие.

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

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

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

Если не ограничивать модель, то он пытается построить пары "все со всеми".

Условие:

IF [Solution] = "Solution" THEN [TypeRT] = "0" OR [TypePT] = "0" OR [TypeAT] = "0";

фактически означает, что не может быть Solution и RTPTAT. Соответственно, нельзя построить пары RTPTAT со всеми значениями AccessSolution.

Про RTPT так сразу не видно, но наверняка, тоже что-то не стыкуется.

А вообще, все ли комбинации имеют смысл? Может быть, надо ограничить подбор комбинаций только между определенными колонками?

 

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

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

А вообще да, куратору продукта (product owner'у) имеет смысл регулярно просматривать, что заведено за прошедший цикл. Даже если это не скрам, какая-то цикличность в больших проектах обычно присутствует.

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

Добрый день

Вы имеете в виду Lee Copeland. A Practitioner's Guide to Software Test Design?

Посоветуйте, для новичка, после Савина и Куликов х2, что  лучше начать Patton R. - Software Testing или Lee Copeland. A Practitioner's Guide to Software Test Design? 

Спасибо

 

Это разные книги, обе могут быть полезны.

Пэттон - больше о процессах и документации (как Савин, только в другом разрезе и более деловым тоном).

Коупленд - больше о техниках.

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

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

В реальности новички будут описывать баг совсем другими словами, чем опытные, и не будут понимать, что там вообще написано в трекере.

что это вот именно те шаги которые надо произвести чтобы сделать "правильное тестирование", что вот именно надо "сначала планируем, потом создаём кейсы, потом запускаем их"

Ну, каждый видит то, что хочет.

В первом же абзаце раздела 1.4, посвященного тестовому процессу (в Foundation!):

"The proper, specific software test process in any given situation depends on many factors. Which test activities are involved in this test process, how these activities are implemented, and when these activities occur may be discussed in an organization’s test strategy."

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

ISTQB вообще не учит, с чего начинать тестирование. Они описывают набор разных практик. Нужно к этому относиться как к багажу знаний и унификации некоторых понятий.

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

Уровень Foundation - "как бы" для начинающих (хотя у нас его часто сдают как раз после нескольких лет опыта). Поэтому там формальной стороне уделяется больше внимания.

Почитайте силлабусы для Advanced.

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

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

Есть другая проблема: при подготовке к ISTQB может возникнуть искажение целей. Они дают набор методик, и у человека появляется цель знать все эти методики, чтобы пройти экзамен. А потом кажется, что всё это непременно в той же пропорции надо применять на работе.

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

Теперь вопрос: а к чему в этом дереве применяется постпроцессор?

Видимо, не к тому, что подсвечено на скриншоте, а только к первому запросу.

Если настройка "Apply to sub-samples" не поможет, тогда делайте запрос именно на тот адрес, с которого приходят данные.

Это на самом деле может быть ошибка на сайте. Если то же самое делать в браузере (естественно, с открытой вкладкой Network), можно увидеть, выдает ли этот запрос 404 в нормальном состоянии.

vugen - это vugen. Может, он полностью движок браузера имитирует.

Вы смотрите, что в Jmeter в response приходит.

Недостаточно элегантно, но просто делали каждый раз один кейс, в нём ссылка на вики, а в вики чеклист.

 

Недостаточно элегантно, но просто делали каждый раз один кейс, в нём ссылка на вики, а в вики чеклист.

то есть есть список кейсов, проваливаешься в один, а там только ссылка и больше ничего?

 

Главное же идея, а как именно оформить - смотрите сами.

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

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

Для этого должна быть определенная культура обеспечения качества в компании.

Вокруг меня, как правило, разработчики считают, что на тесты нужно тратить минимум времени. Пишут для формального покрытия кода, и пишут в стиле "2+2=4" вместо проверки хотя бы граничных значений.

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

Действительно ли в теле ответа на первый запрос есть такой элемент? (Может быть, там идет редирект, или value заполняется скриптом.)

Соответствует ли то, что приходит, регулярке на 100% (пробелы и т.д.)?

Здравствуйте!

С недавних пор стали меня привлекать на собеседования в качестве "технического эксперта". (Эксперт я так себе, ну да ладно.) Проблема в том, что такой длительный разговор, тем более, с незнакомым человеком - для меня ситуация крайне стрессовая. Да еще приходится постоянно себя контролировать, чтобы не слишком проявить ограниченность своих знаний и не испортить лицо компании.

В итоге, после собеседования 2-3 часа я просто прихожу в себя, никак не могу сосредоточиться на работе. Практически, день насмарку.

Может быть, вы или ваши коллеги с таким сталкивались? Как справляетесь?

(Алкоголь не предлагать, мне же еще работать надо )

 

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

покрыть все варианты развития событий?

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

Что можно сделать:

- Для начала, отделить те проверки, которые не относятся к "развитию событий", а проверяют единовременное влияние каких-то условий ("Сама сумма предоплаты (полная/частичная) зависит от суммы заказа", "от места нахождения товара и суммы заказа зависит, включена ли в стоимость доставка" и т.п.)

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

- Если есть много времени и возможность делать подробные проверки, то да - можно нарисовать диаграмму состояний и пройти по ней все пути.  Только не нужно переусердствовать и включать туда всё, что есть в бизнесе. Нужно выделить какой-то ограниченный набор состояний. (Например, отдельно - статусы резервирования. Если какое-то действие приводит к переходу в следующий набор состояний, не относящийся к резервированию, то это будет последнее действие в тесте.) Способов обхода такой схемы множество. Например, отметить два состояния как "начальное" и "конечное" и сделать такой набор тестов, которые начинаются с "начального" и заканчиваются "конечным". При этом нужно, чтобы этот набор тестов покрывал все возможные переходы. Если начальных и конечных состояний несколько, то это не значит, что надо проходить от каждого к каждому, просто на конечных надо заканчивать. Также, разумеется, не надо покрывать переходы, которые уже проверены пользовательскими сценариями.

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

Как собираетесь регулировать нагрузку, если у нас неизвестная задержка на получение и чтение почты?

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

Здесь выпадает тестирование того, что при нагрузке на каждый запрос приходит e-mail. Но это уже надо делать не джейметром (он вообще для такого не приспособлен), а ловить почту на фейковый сервер, и потом отдельный скрипт запускать для постпроцессинга.

Потому что надо добавлять не в виде

--tags "@production"

а в виде

-Dcucumber-options="--tags '@production'"

(Попробовать сам сейчас не могу, пишу по своим старым докам. Может быть, не сработает - тогда кавычки как-то по-другому надо поставить, или действительно cucumber.options с точкой, а не с дефисом.)

UPDATE:

Нашел еще такой вариант: всё, передаваемое кукумберу, стоит в кавычках. И да, там с точкой.

"-Dcucumber.options= --tags @T5555 --tags ~@longRunning"

Но ведь время видимой загрузки элементов состоит из загрузки по сети, отработки скриптов и рендеринга в самом браузере.

Вы рискуете написать тесты, на которые потратите кучу сил, и которые не будут давать нужной информации: что именно фиксить?

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

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