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

то, что функция не сломалась, не значит, что функционал продолжает работать)

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

Тогда и тестировать должен сам разработчик?

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

функция в конце концов может в какой-то момент перестать вызываться.))

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

Блин, ты же должен понимать, что работающий код не является конечной целью.

а там уже пофиг, работает она или нет, функция эта

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

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

Помимо юнитов есть модульное, интеграционные, системное, нагрузка

Помимо юнитов есть модульное, интеграционные, системное, нагрузка

нагрузка!!!! опять?))

нагрузка!!!! опять?))

За живое потрогали??

Если говорить о типах тестов, которые можно выполнять.

За живое потрогали??

была тут дискуссия недавно)

о различии тестирования нагрузки и нагрузочного тестирвоания

А вот нагрузоустойчивость qa и разработчиков никто не меряет почему-то(

была тут дискуссия недавно)

я помню)) поэтому и спросил))

Толко мы обсуждали две разные вещи

еще разок попробуем? )

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

а почитать не пробовали, гугл там иль еще чего?

докопаемся до истины, может )

еще разок попробуем? )

Думаешь результат изменится?

Так мы уйдём в теологию. Если код выполняется и выполняется правильно, значит наша задача решена. :)

ток в приваты не уходите )))

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

Так мы уйдём в теологию. Если код выполняется и выполняется правильно, значит наша задача решена. :)

нет

Так мы уйдём в теологию. Если код выполняется и выполняется правильно, значит наша задача решена. :)

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

код ради кода оставьте опенсорсерам

Я все ещё не собираюсь давать рекомендации что именно им нужно от нагрузке анализировать, так как это сугубо личное.

Задача решена когда пользователь может выполнить свою задачу

а разработчик решает задачи бизнеса

Так мы уйдём в теологию. Если код выполняется и выполняется правильно, значит наша задача решена. :)

Тут вся засада в понятии "выполняется правильно"

У программистов это значит что не падает с ошибками. Поэтому они пишут юниты и не пишут то что выше

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

Тут вся засада в понятии "выполняется правильно"

Вот с этим не спорю.

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

А что тогда понимается под код работает? Ошибок логики нет и оно компилируется?

Я все ещё не собираюсь давать рекомендации что именно им нужно от нагрузке анализировать, так как это сугубо личное.

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

И возвращает то, что от него ожидается)

А что тогда понимается под код работает? Ошибок логики нет и оно компилируется?

я бы вообще не мыслил такими категориями :) значит, что есть сценарии использования кода, и то, что понаписали разрабы, их решает

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

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

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

ой всё )

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

у вас проводят тестирование без практичекого понимания его применения и необходимости?!

у вас проводят тестирование без практичекого понимания его применения и необходимости?!

всегда так делаю

Смысл жизни в тестировании

у вас проводят тестирование без практичекого понимания его применения и необходимости?!

Мы же тут обсуждаем "ситуацию, когда что-то делается за так"

в любой непонятной ситуации тестируй

не надо подменять понятия, пожалуйста )

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

А такое бывает вообще?

Любая утилита хоть какую метрику да показывает

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

Это как вообще?

wat

Любая утилита хоть какую метрику да показывает

Показывать - показывает, а вот смотришь ты на неё или нет, и на какую именно - другой вопрос.

Нагрузочное тестирование билд сервера?

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

Каких именно метрик? И почему она бесполезна без метрик?

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

Ага, обсуждалось что как тестировать апи. Я сказал, что можно использовать jmeter. Можно и функционал проверить, а можно те же кейсы запустить 1000 раз и получить нагрузку. Конец истории.

Каких именно метрик? И почему она бесполезна без метрик?

Откуда ж я знаю, Светлана все вам распишет почему это неправильно

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

давайте закроем тему, а то все катится в ад.

отсылки к древнему холивару не тру.

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

Запуск 1000 тестов параллельно, с разных инстансов, покажет только 1 метрику - апи не прилегло при 1000 одновременных пользователей. Метрика довольно унылая, потому что помимо этого есть ещё response time и прочие вещи. Да и 1000 юзеров это ниочем. Но если цель такового запуска этих тестов совпадает с результатами - то ок. :)

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

Хотя упал/не упал тоже можно считать метрикой.

Запуск 1000 тестов параллельно, с разных инстансов, покажет только 1 метрику - апи не прилегло при 1000 одновременных пользователей. Метрика довольно унылая, потому что помимо этого есть ещё response time и прочие вещи. Да и 1000 юзеров это ниочем. Но если цель такового запуска этих тестов совпадает с результатами - то ок. :)

Так ведь, что вы с этой нагрузкой будете делать - это решать вам. Инструмент у вас есть. Не?

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

ERROR: S client not available

Хотя упал/не упал тоже можно считать метрикой.

кроме упал не упал, есть еще как минимум период потери стабилизации работы

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

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

коллеги, вчерашнюю тему про сбор в баре Питерских из чата все осознали/прочитали? вот ссылка http://doodle.com/poll/yxmqu2ekbauryafr , поставьте галку кто когда может плз. темы встречи - популяризация миссии QA в рамках компаний, общение, попойка)

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

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

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

Всегда можно думать шире. Но я не исключаю ситуаций, когда метрик минимум.

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

а кто должен делать аналитику? специально обученный специалист по зеленым отметкам?

а кто должен делать аналитику? специально обученный специалист по зеленым отметкам?

Воу-воу, стоп.

а кто должен делать аналитику? специально обученный специалист по зеленым отметкам?

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

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

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

ты сейчас 3 суть в их обсуждение притащил

Если кому-то надо посмотреть, что у нас сервис выдержит 300 тыщ паралллельных пользователей, а проверка адекватного response time зашита в самих тестах - то тесты дадут ответ "можно ли запустить наш сервис для трансляции чемпионата по heartstone или оно умерт сразу".

Если умрёт сразу - тестировать глубже смысла нет. Умер - значит всё.

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

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

а как же мнение, что нагрузка и нагрузочное тестирование это две большие разницы (как говорят в Одессе)?

Давайте оперировать хорошими забугорными терминами.

Нагрузку ты можешь и руками сделать, не? Это станет нагрузочным тестированием?

Load \ Performance \ Stress \ Volume

а как же мнение, что нагрузка и нагрузочное тестирование это две большие разницы (как говорят в Одессе)?

Мне известно 4 вида нагрузочных тестов. Отличаются они тем, что тестируют разные атрибуты качества. Именно это важно.

Load \ Performance \ Stress \ Volume

Объемное забыл.

Объемное забыл.

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

"нагрузка" (не нагрузочное тестирование) это зачем и к чему относится?

из перечисленного

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

Ну, не совсем. вольюм измеряет степень деградации системы с течением времени. Т.е. в классификации ГОСТ 25010 это другой атрибут качества.

Ну, не совсем. вольюм измеряет степень деградации системы с течением времени. Т.е. в классификации ГОСТ 25010 это другой атрибут качества.

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

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

И вольюм крайне сложно проводить "ручками", а пефоманс ручками - совершенно стандартная практика.

Довольно спорно, но в целом всё зависит от конкретных кейсов. Не вижу особого смысла обсуждать. :)

Ребят, есть кто работал с амоСрм? нужна небольшая доработка

Тебе не в этот чатик.

О, а я пропустил

И вольюм крайне сложно проводить "ручками", а пефоманс ручками - совершенно стандартная практика.

Серьёзно? Стандартная практика 100 человек делать нагрузку?