Прочел, что такое Codeception. А Вы не прочли про классификацию видов тестирования. Это схемы, там слов мало.
А если прочтёте, то станет понятно, что
Codeception в случае тестирования без браузера предлагает тестирование:
* по цели: Функциональное
* по степени автоматизации: Автоматизированное
* по знанию системы: Серого ящика (обращение к REST-методам, а не взаимодействие с пользовальесикм интерфейсом)
* ...
Тестирование остаётся функциональным. Пока, используя Codeception, вы не станете проверять нефункциональные требования:
* защищенность
* производительность
* удобство использования
* ...
тестирование будет оставаться функциональным.
Как только начнёте через REST API yii нагружать сайт или проверять на устойчивость к подбору пароля (защищённость) то тестирование перестанет быть функциональным - по целям тестирования.
По этому профилю за первые 15 секунд (Rump-Up period ) запустится 10 потоков (Number of Threads). И точно засчитается выполнение одной итерации теста, останется каждому потоку выполнить максимум ещё 99 итераций (Loop Count - 1).
Если так случиться, что каждый поток упеет выполнить 99 итераций раньше, чем за 300 сек (~285-300), то тест закончится в момент выполнения последним активным потоком своей 100-й итерации.
Если же 100 итераций не получится успеть выполнить за 300 сек, то тест просто прервётся. Сколько итераций успели сделать, столько и сделано.
Таким образом, тест будет не большее чем 300 секунд выполняться.
Используя 10 подключение (начиная с 15-й секунды).
На первой секунде будет только 1 подключение или 2.
На 7-й, примерно 5 подключений.
На 15-й запустятся все 10 потоков.
zumi: мне хватает шести месяцев, чтобы начать разбираться в предмете и около двух лет, чтобы знать предмет хорошо.
Есть две темы, которыми занимаюсь уже более десяти лет, до сих пор не узнал и десятой части. Но другие люди считают экспертом. Момент завершения изучения предмета нельзя определить.
Проведу аналогию с химией. В рамках школьной лабораторной работы по химии, ученик великолепно проводит эксперимент, и может объяснить все происходящие процессы. На текущий момент ученик является экспертом по этому эксперименту. Через год ему предлагают работу в здравоохранении, также по теме химии. Так как считают его знающим человеком. Но химические процессы в теле человека ему неведомы.
Справиться с работой ему поможет умение учиться, проводить аналогии, делать гипотезы, строить модели. А также выносливость, терпение, хорошее здоровье и самочувствие.
И через восемьдесят лет успешной работы, к ученику подойдёт человек, которого он считает экспертом, и признается, что восхищается его трудами. В этот момент ученик поймёт, что знает предмет великолепно, по мнению человека, которого считает экспертом. Но сам так считать не будет.
Kr1og5n: и дополнение, текущий сеанс моего пользователя включает ПО на 120 МБайт ОЗУ, но тут нет ни офиса ни 1С. Считаю, что 512 МБайт на человека - много. На 20 человек, хватит 8 ГБайт ОЗУ.
Она про Remote-App. Remote-App в тестах работал чуть быстрее, чем полноценный терминал. Но не на много быстрее. Когда занялся уже сравнением, шел третий час тестирования. Скроллить и кликать три часа подряд утомительно. И тестирование с Remote-App получилось уже по другому профилю, сравнивать результаты тестирования 1 в 1 с терминалом было некорректно.
Core-i5 3,2 ГГц; 16 ГБайт ОЗУ; SATA 3, 7200 RPM 250 ГБайт.
Сейчас на сервере 30 человек, сервер работает быстро. Десять активных, многие уснули уже, но сеансы не закрыли. 8 ГБайт ОЗУ занято, загрузка процессора 25%.
Сеть быстрая, критическим ресурсом не является. Но активный скроллинг яркого отчёта (красные, жёлтые, зелёные строки) ложит сеанс. Просмотр фото - тот же результат. Активная работа консольных утилит, с разноцветным выводом в консоль - опять тормоза. Это логично и нормально, провыкаешь, терминал ведь.
Два года назад, когда тестировал, сетевой канал и ОЗУ были узким местом, более узким чем сейчас. Оборудование было слабее.
RuJet: тоже проходил. Можно привыкнуть. После первого месяца чувствуются проблемы, и на пол месяца почти выпал из работы. После третьего месяца уже норма.
lostpassword: Пожалуйста.
Подумал, как можно используя простые инструменты (AutoIt, например) покрыть тестами сложное приложение.
Выделю два фактора:
1. Приложение ориентировано для автоматизации тестирования, у кнопок уникальные идентификаторы, элементы управления легко доступны.
2. У приложения есть отладочный режим, при котором в лог пишется факт начала и завершения выполнения всех событий (клик, выбор, запуск, ...), предупреждений и ошибок.
Так можно будет писать простой тест, который только посылает управляющие воздействия. А для проверки результатов использовать несложный единый механизм - работу с логами.
Если ссылки, которые вели на ваш сайт с других ресурсов при смене домена стали недействительными. То индекс цитирования снизится. Если поисковый робот Яндекса не спешил с переиндексацией, то он только сейчас это заметил, поэтому, может быть такая реакция с задержкой.
Не силён в поисковой оптимизации. Знания поверхностные.
Ошибся в коде: TextBox textBox = (TextBox)control;
Тут может быть брошено исключение (CastException).
Надо использовать "as": TextBox textBox = control as TextBox;
путаю иногда приведение типа и as.
Или использовать is
if(control is TextBox)
{
TextBox textBox = (TextBox)control;
...
}
[TestMethod]
public void Execute()
{
this.BDDfy();
}
}
}
Обратите внимание на метод GivenTheCardIsDisabled().
В этом методе создаётся экземпляр класса Card, в первый параметр передаётся значение false (вероятно, оно отвечает за то, что Card будет Disabled). После чего, считается что экземпляр класса Card будет успешно создан, что Card будет именно Disabled, ... (всё предполагается, проверок на Card.Disabled нет никаких).
Этот тест, как можно заметить, работает с Atm.CardIsRetained и Atm.Message. Зависит от корректности работы Card и Card.Disabled. Но не зависит от конкретного экземпляра класса Card, который при неправильном подходе к разработке тестов создавался бы в другом тесте.
Тут, как вы видите, экземпляр класса Card создаётся в этом же тесте в предусловии (GIven). И текущий тест самодостаточен.
Допустим, есть другой тест, который создаёт экземпляр класса Card, проверяет успешность создания и проверяет значение свойства Disabled. Но это другой тест. От успешности его работы, текущий тест независим.
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
А если прочтёте, то станет понятно, что
Codeception в случае тестирования без браузера предлагает тестирование:
* по цели: Функциональное
* по степени автоматизации: Автоматизированное
* по знанию системы: Серого ящика (обращение к REST-методам, а не взаимодействие с пользовальесикм интерфейсом)
* ...
Тестирование остаётся функциональным. Пока, используя Codeception, вы не станете проверять нефункциональные требования:
* защищенность
* производительность
* удобство использования
* ...
тестирование будет оставаться функциональным.
Как только начнёте через REST API yii нагружать сайт или проверять на устойчивость к подбору пароля (защищённость) то тестирование перестанет быть функциональным - по целям тестирования.