Тест-кейс ‒ шаги по достижению ожидаемого результата.
Часто у тест-кейса нет шагов. В том же TMS Testlink, много версий подряд было только поле «Описание» без шагов и ожидаемых результатов. И даже тест-кейсы без описания были тест-кейсами.
Тест-кейс (он же тестовый сценарий или test case) — набор входных значений, предусловий выполнения, ожидаемых результатов и постусловий выполнения, разработанный для определенной цели или тестового условия, таких как выполнение определенного пути программы или же для проверки соответствия определенному требованию. [IEEE 610]
Если допустить, что некоторые наборы могут быть пустыми. То тестовый сценарий, состоящий лишь из хорошего заголовка и помещённый в определённую группу, становится полноценным тестовым сценарием, соответствующим определению.
Выделяют сценарии высокого уровня (90% для ручных тестов), и низкого уровня (90% для автоматических тестов). Низкого уровня те, что указывают на конкретные значения входных данных и ожидаемых результатов. Примечание про 90% — сугубо личная оценка, в конкретных случаях может быть не так.
Прогон ‒ выполнение тест-плана.
Не уточнено прогон чего, и оказывается, что это про весь план тестирования. Закрепилось в голове, что прогон, это прогон теста.
Прогон теста (test run) — выполнение теста на определенной версии объекта тестирования. [ISTQB]
«Тестирование» — наиболее подходящее общее слово, которое можно раскрыть как выполнение плана тестирования. У понятия тестирование есть и более развернутые определения, не затрагивающие другие определения.
Неточно описано. Если есть брандмауэр, то изначально всё заблокировано. Устанавливаемые службы могут добавлять исключения в правила брандмауэра. И в правилах может быть не только номер порта.
Нужно следить за списком правил брандмауэра. Если ограничиться контекстом данного раздела (слушаемые порты), то следить за правилами брандмауэра для входящих соединений.
Использование модульных тестов для организации нагрузки повышает требования к аппаратуре агентов. Но тесты писать просто, при готовом API для работы с тестируемым приложением.
Тут есть интересный момент. Количество работающих пользователей надо считать на стороне сервера (по факту). Так как на стороне нагрузочного агента (при таком способе организации тестирования) некоторые пользователю могут спать, если их сделать много. Может, как бы, начать работу 1000 параллельных пользователей, а эффект от них как от 700-т, 300 запущены, но спят или теряются где-то (пропорция 7/10 примерная, в конкретном проекте может быть другой). В результате, понадобится несколько агентов.
Думаю потому, что модульные тесты, прослойка в виде готового API тянут за собой дополнительный код, тратится память, создаётся больше потоков, большая изоляция выполняемых потоков. И в результате меньшая параллельность. Причин не знаю, гадать дальше не буду.
А вот если отсылать WebTestRequest-ы, то нагрузка выше, при том же профиле нагрузки. Но API, формирующее WebTestRequest и обрабатывающее ответ на него придётся написать и поддерживать.
При использовании нескольких агентов нет никаких особых проблем. Кроме, пожалуй двух:
1. Свободных машин для агентов может не быть.
2. Нужно правильно запускать, чтобы не получилось так, что с двух и более машин начинают выполняться одни и те же действия (возникает логический race condition, логический на уровне логики теста — трижды удалить документ, так как для всех трёх агентов на момент начала удаления документ не был удалён, но должен быть удалён). Тут разделяю пул учётных записей по агентам (первый работает с первой 1000, второй со второй 1000, ...), и каждый агент использует набор неповторяющихся учётных записей, размер набора меньше пула.
Часто у тест-кейса нет шагов. В том же TMS Testlink, много версий подряд было только поле «Описание» без шагов и ожидаемых результатов. И даже тест-кейсы без описания были тест-кейсами.
Тест-кейс (он же тестовый сценарий или test case) — набор входных значений, предусловий выполнения, ожидаемых результатов и постусловий выполнения, разработанный для определенной цели или тестового условия, таких как выполнение определенного пути программы или же для проверки соответствия определенному требованию. [IEEE 610]
Если допустить, что некоторые наборы могут быть пустыми. То тестовый сценарий, состоящий лишь из хорошего заголовка и помещённый в определённую группу, становится полноценным тестовым сценарием, соответствующим определению.
Выделяют сценарии высокого уровня (90% для ручных тестов), и низкого уровня (90% для автоматических тестов). Низкого уровня те, что указывают на конкретные значения входных данных и ожидаемых результатов. Примечание про 90% — сугубо личная оценка, в конкретных случаях может быть не так.
Не уточнено прогон чего, и оказывается, что это про весь план тестирования. Закрепилось в голове, что прогон, это прогон теста.
Прогон теста (test run) — выполнение теста на определенной версии объекта тестирования. [ISTQB]
«Тестирование» — наиболее подходящее общее слово, которое можно раскрыть как выполнение плана тестирования. У понятия тестирование есть и более развернутые определения, не затрагивающие другие определения.
Неточно описано. Если есть брандмауэр, то изначально всё заблокировано. Устанавливаемые службы могут добавлять исключения в правила брандмауэра. И в правилах может быть не только номер порта.
Нужно следить за списком правил брандмауэра. Если ограничиться контекстом данного раздела (слушаемые порты), то следить за правилами брандмауэра для входящих соединений.
Тут есть интересный момент. Количество работающих пользователей надо считать на стороне сервера (по факту). Так как на стороне нагрузочного агента (при таком способе организации тестирования) некоторые пользователю могут спать, если их сделать много. Может, как бы, начать работу 1000 параллельных пользователей, а эффект от них как от 700-т, 300 запущены, но спят или теряются где-то (пропорция 7/10 примерная, в конкретном проекте может быть другой). В результате, понадобится несколько агентов.
Думаю потому, что модульные тесты, прослойка в виде готового API тянут за собой дополнительный код, тратится память, создаётся больше потоков, большая изоляция выполняемых потоков. И в результате меньшая параллельность. Причин не знаю, гадать дальше не буду.
А вот если отсылать WebTestRequest-ы, то нагрузка выше, при том же профиле нагрузки. Но API, формирующее WebTestRequest и обрабатывающее ответ на него придётся написать и поддерживать.
При использовании нескольких агентов нет никаких особых проблем. Кроме, пожалуй двух:
1. Свободных машин для агентов может не быть.
2. Нужно правильно запускать, чтобы не получилось так, что с двух и более машин начинают выполняться одни и те же действия (возникает логический race condition, логический на уровне логики теста — трижды удалить документ, так как для всех трёх агентов на момент начала удаления документ не был удалён, но должен быть удалён). Тут разделяю пул учётных записей по агентам (первый работает с первой 1000, второй со второй 1000, ...), и каждый агент использует набор неповторяющихся учётных записей, размер набора меньше пула.