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

Книг не очень много, быстрая базовая вещь «art of performance testing”, “performance testing guidance for web applications”. Если хочется совсем задрочиться, то

Сложная книга на фото

Если что, 5 декабря в Питерском яндексе будет митап, там выступает Толя Пластковский, можно будет его послушать и его расспросить про рекомендации

Если что, 5 декабря в Питерском яндексе будет митап, там выступает Толя Пластковский, можно будет его послушать и его расспросить про рекомендации

А какая нить трансляция будет для непитерцев?

Хз

Всем привет ! Вопрос немного банальный но все же задам, напишите пжлста топ книг которые должен обязательно прочитать тестировщик.

Привет, це маст хев для начала, Почитай Саввина (“Тестирование DOT.com”) и Канберра/Фолка “Тестирование ПО”.

Пора базу знаний сделать. Вопросьі повторяються.

в джуночате есть какой-то гуглодок

в джуночате есть какой-то гуглодок

Можно джуно чат? Ссылку

у меня нет

@qajuniors

Там запинена табличка

Там запинена табличка

Благодарю !

Пора базу знаний сделать. Вопросьі повторяються.

?

Спасибо за ответы !

Всем привет, есть кто шарит в настройке конфига тора torrc?

Добрый вечер! Посоветуйте, пожалуйста, как организовать тестирование мобильных игр. На создающийся проект разработки мобильных игр требуется тестировщик (iOs + Android) На первых порах будет одна-две игры(довольно простых), и загрузка эпизодическая, когда наберём объём, то возможен фултайм. Но как поступить в начале? 1) Искать человека на фрилансе со своим железом? Теоретически можно, но как тестируют тестировщиков? :) В смысле у программиста или моделера есть портфолио, а если чел говорит, что он крутой тестировщик, как понять, что правду говорит? 2) Найти какой-то сервис внешнего тестирования. Есть такие, которым можно доверять и не слишком дорого запросят? 3) Что-то ещё.

мобильные игры ничем не отличаются от обычных мобильных рпиложений.

просто в мобильном геймдеве обычно нет денег.

Ну почти не отличаются. Только я не понял, как это отвечает на мой вопрос. Тестировщик нужен за деньги, если что. :)

это не чат вакансий, если что.

создайте свой зоопарк устройств и наймите тестера.

Да я и не то чтобы ищу тестировщика прямо здесь, здесь я ищу совета на два вышеозвученных вопроса 1) Как проверяют тестировщиков. 2) Есть ли сервисы, которым можно давайть задачи на внешнее тестирование.

Что значит "проверяют тестировщиков"? Как проверяют программистов? Как проверяют сисадминов? Тестировщик - это тоже профессия, есть собеседования, есть тестовые задания.

Я не понимаю вопроса.

Спасибо.

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

Ну почти не отличаются. Только я не понял, как это отвечает на мой вопрос. Тестировщик нужен за деньги, если что. :)

Можно отдать тестирование на аутсорс, есть конторы, у которых уже есть свой парк. На фрилансе «человек с девайсами» - я такого не встречала, чтобы фрилансер имел свой зоопарк устройств и тестил. Обычно можно узнать, есть ли у вас в конторе человек, который связан с тестированием, например, бывает, что человек ушёл из тестировщиков в разрабы, продакты, и можно попросить его тряхнуться стариной и пособеседовать.

Можно отдать тестирование на аутсорс, есть конторы, у которых уже есть свой парк. На фрилансе «человек с девайсами» - я такого не встречала, чтобы фрилансер имел свой зоопарк устройств и тестил. Обычно можно узнать, есть ли у вас в конторе человек, который связан с тестированием, например, бывает, что человек ушёл из тестировщиков в разрабы, продакты, и можно попросить его тряхнуться стариной и пособеседовать.

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

Сейчас, спросила у знакомой.

Жду когда ответит

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

Пинганите меня в понед. Тогда будет известна инфа

Хорошо, спасибо!

Подскажите как можно совместить и есть ли смысл TESTRAIL + jenkins?

можно

конечно есть

Дерзай

Подскажите как можно совместить и есть ли смысл TESTRAIL + jenkins?

А что хочется решить?

Ручные тестеры хотят test management систему, автотестеры думают как же им это использовать

просто в мобильном геймдеве обычно нет денег.

Ой спорно)

Ручные тестеры хотят test management систему, автотестеры думают как же им это использовать

Тестеры хотят видеть прогон тестов? Я совмещала роботфреймворк и тестреил

Тестеры хотят видеть прогон тестов? Я совмещала роботфреймворк и тестреил

Приветствую. Я правильно понимаю идею, что после пуша, дженкинс стартует тесты, а в тестреиле фиксируются результаты?

у тестрейла есть апи по добавлению результатов. Соответственно использовать можно его 2 способами (мб больше, но основных я вижу такие). 1. В качестве tearDown метода на кейс передавать информацию о тесте вызовом post запроса. 2. Если результат тестов не может разруливаться тестовым фреймворком (его нет), а этим занимается CI (на основе правил парсинга stdout сообщений от слейвов), то это достигается дополнительным шагом в билде, где парсится лог и шлется N запросов анлогичных POST с инфой о проходе кейса, но уже по отработанному набору. ( в случае (1) сьют будет заполняться по мере прохождения тестов). В случае (2) это будет много post на финише. Также для (2) можно накостылить, например, в рамках другого билда-poller'a(запускаемого в зависимости с основным билдом-гоняльщиком тестов), который изменение файла лога будет докидывать по мере прохождения.

Так а ещё аллюр в эту связку получается удобно запихнуть?

Получается все автотесты тоже надо вручную запихнуть и поддерживать в репозитории тестов в TESTRAIL? Или это можно как то автоматически делать? Помечать их автоматизированными..

Кстати может тогда их тестрейла сделать отдельный дашборд с задачами todo для автоматизации, тупо брать все оттуда ручные тесты и начинать их автоматизировать, потом статус теста менять на "автоматизировано"?

В тестрейле можно свои поля делатт

Мне вот просто хочется понять воркфлоу и сценарий использования тестрейла всеми ролями в разработке в общем

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

И пересечение ручных тестеров с аналитиками и автоматизаторами

мне вообще не нравится идея кучи всяких тулов, это от лукавого

Ручные тестеры хотят test management систему, автотестеры думают как же им это использовать

Ну хорошо, рейлз будет удобен для классических тестировщиков и менеджмента кейсов. Какие ожидания у автоматизаторов?

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

Покрыт\ не покрыт - это одна страничка в Конфлюенсе с чекбоксами напротив каждого тест сьюта. При желании от руки дописываете % покрытия. Всё. Рокет сайенс городить не нужно

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

Тимсити, к сожалению, ничего проанализировать не может. просто посчитать passed/failed это не анализ для активно развивающегося проекта, где постоянно может появляться регресс, новые тесты и новые баги. То что вчера зафейлилось 10 тестов в сегодня 9 из 3000 - это вообще не анализ.

В этом плане прикольные идеи у епамовского репорт портала. У нас на похожих принципах анализатор написан, мне кажется это верное направление.

То есть тут по-хорошему нужна балалайка для хранения тестов и ручных сценариев, балалайка ci и балалайка - анализатор

Тимсити, к сожалению, ничего проанализировать не может. просто посчитать passed/failed это не анализ для активно развивающегося проекта, где постоянно может появляться регресс, новые тесты и новые баги. То что вчера зафейлилось 10 тестов в сегодня 9 из 3000 - это вообще не анализ.

Какой анализ вам нужен, можно конкретики? И что на результатах этой метрики потом делается

Какой анализ вам нужен, можно конкретики? И что на результатах этой метрики потом делается

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

Если постоянно фейлился - проставить резолюции автоматом

это типа метрика?)

Если нестабильность - скажем 5 из 10 - пометить как необходимо исследовать

нестабильность при неизменяемом коде в большинстве современных CI есть из коробки и метиться как flaky тест

это типа метрика?)

Это описание состояния продукта

нестабильность при неизменяемом коде в большинстве современных CI есть из коробки и метиться как flaky тест

Нестабильность какого характера? Какой степ фейлится?

Нужно лезть в логи смотреть

Само собой нужно, а что, машины будут разбирать еще и это? Автотесты - это про чек состояний, а не про исследование инцидентов

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

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

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

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

Решение в итоге принимают же всё же люди. На основе анализа тестов.

Выше упомянуто правило: закрывать баг, если связанный тест стал зелёным. Тут уже не важно, робот его закроет или человек, по тому же правилу. Работать по такому принципу само по себе рискованно.. Одному мне кажется что в случае, когда тест был долгое время красный, и вдруг стал зелёный, то скорее вероятно что тест устарел, а не баг исчез?

Tdd

Фу, брось каку

Не про это же тут речь сейчас

А что не так с ТДД? Где-то опять написали, что он умирает?...

Если автор реплики, которую я прокомментировал, про тдд говорил, то я помою руки

А есть какая-то конкретика кроме "пойду помою руки" и "фу кака"?

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

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

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

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

Можно отделить известные фейлы от новых, посмотреть историю по билда и т д

В сыром виде логи теста разбирать значительно затратнее по времени