тестирование gui

Коллеги, прошу вашей помощи!

В моём проекте появился новый продукт, а именно GUI написанный на c# который соединяется с сервером и ДБ. И вот на этой начальной стадии, пока не сильно требуется функциональное тестирование, нас, QA, попросили оценить производительность этого GUI. цифр не дали никаких, типа "ну вы там как-нибудь оцените, посмотрите". Безалаберность такого подхода - отдельный вопрос, а сейчас прошу помочь с такими:

1. где можно ознакомиться с различными метриками для комфортной работы с GUI? Какие-нибудь международные стандарты. Например время реакции на нажатие кнопок или время прорисовки таблиц и заполнения их данными.
2. с помощью чего это всё можно измерить? может быть что-нибудь вроде silk, который умеет нажимать на кнопки, ждать чего-нибудь где-нибудь и потом скидывать задержку в базу или лог. в идеале чтоб система была проста в обращении, умела рисовать графики, умела снимать показания загруженности системы, умела делать функциональное тестирование и была бесплатной. :)

Заранее спасибо.

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

На вопрос типа "ну вы там как-нибудь оцените, посмотрите" предлагаю поработать с ПО самим и написать отчет в стиле комфортно/не комфортно.
Если потребуют подробностей и объяснений, то тогда уже и следует искать международные стандарты.

Если потребуют подробностей и объяснений, то тогда уже и следует искать международные стандарты.

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

Попробуйте поискать в гайдлайнах у Microsoft и у юзабилистов

Для бизнес приложений:
Меньше 0.1 сек - пользователь не замечает задержки. Дальнейшая оптимизация смысла не имеет
0.1 - 1 сек - задержка ощутима, но работа все еще комфортна
1 -10 сек - задержки вызывают раздражение
Более 10 сек - пользователь регулярно теряет контекст и переключается на другие задачи. Эффективна работа невозможна.

---------------------------------------------------------------
Отсюда мораль про приложения на тонком клиенте. Багзила там, мантис...

Для бизнес приложений:
Меньше 0.1 сек - пользователь не замечает задержки. Дальнейшая оптимизация смысла не имеет
0.1 - 1 сек - задержка ощутима, но работа все еще комфортна
1 -10 сек - задержки вызывают раздражение
Более 10 сек - пользователь регулярно теряет контекст и переключается на другие задачи. Эффективна работа невозможна.

О! то что надо!
это применимо ко всему: как ко времени отклика на клик, так и ко времени прорисовки графиков и заполнения таблиц. правильно?

Для бизнес приложений:
Меньше 0.1 сек - пользователь не замечает задержки. Дальнейшая оптимизация смысла не имеет
0.1 - 1 сек - задержка ощутима, но работа все еще комфортна
1 -10 сек - задержки вызывают раздражение
Более 10 сек - пользователь регулярно теряет контекст и переключается на другие задачи. Эффективна работа невозможна.

О! то что надо!
это применимо ко всему: как ко времени отклика на клик, так и ко времени прорисовки графиков и заполнения таблиц. правильно?

Не, не правильно, только ко времени отклика. Т.е. должно что-то произойти в приложении, например прогресс бар нарисоваться. Ну и цифры Сергей, я думаю, из головы взял (хотя они, в принципе, правильные), лучше источники поискать, книжки всякие. Вы же не будете говорить, что вам там кто-то на форуме написал :)

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

Дополнение. Требования к времени отклика для разных операций разное.
* Контекстное меню по правому клику должно вызываться за доли секунды
* Открытие новой формы допустимо до 2 сек (но лучше в пределах одной)
* Формирование отчета может быть и больше 10

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

Извините за офф, но прям за живое задело:

Для бизнес приложений:
Меньше 0.1 сек - пользователь не замечает задержки. Дальнейшая оптимизация смысла не имеет
0.1 - 1 сек - задержка ощутима, но работа все еще комфортна
1 -10 сек - задержки вызывают раздражение
Более 10 сек - пользователь регулярно теряет контекст и переключается на другие задачи. Эффективна работа невозможна.

Сейчас у нас рассматривается тест менеджмент тул Qmetry. Я написал ишью, что при переходе с экрана на экран (например, с requirements на test cases) задержка составляет 1-2 секунды. В качестве ожидаемого результата у меня было 0.1 - 0.2 сек. Как к этому пришел? Книжек ни читаю, но играю в пейнтбол и контерстрайк. Как-то решил замерить свою максимальную скорость стрельбы одиночными и понял, что она составляет около 0.1 сек.
Также по ощущениям, скорость моргания глаза (то, что в обыденной жизни называется мгновением ока, мигом) составляет где-то примерно ту же величину.
Вывод: поменьше читайте книжек, побольше наблюдайте и анализируйте себя и окружающих ;-)

Qmetry-сты, естественно, ответили что для веб-приложения задержка 1-2 секунды это нормально. Я не хочу работать с Qmetry (придется ли, пока не знаю).
Но в другом проекте на тест линке ожидание составляет десятки секунд при нескольких тысячах тест кейсов в системе. Естественно, им Qmetry подойдет.

Более 10 сек - пользователь регулярно теряет контекст и переключается на другие задачи. Эффективна работа невозможна.

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