Компания
ConquestSS производит интерфейсные продукты для разработчиков БД Oracle, а
ClearSQL (далее - CS) полезен тестировщикам PL/SQL кода. Поскольку продукт в большинстве своём - визуализатор, то посмотрим на его производительность в области интерфейса. Примечания: приложение десктопное, все установки были на Windows 64bit, замеры (кадрирование через VideoPad) интерфейсной производительности проводились по видеозаписям.
Для теста были взяты версии CS 7.0, 7.1, 8.0, 8.1, 9.0 для Windows 32bit и 64bit, а последний релиз в "светлом" и "тёмном" исполнениях. Каждая инсталляция запускалась по три раза, в каждом из которых анализировался демо-проект. Первые два идентичны по установке на "чистую" машину и полному анализу демо-проекта со всеми диаграммами. Третий запуск отличается от второго тем, что приложению нет необходимости доустанавливать продукт (создавать папки, выставлять опции по-умолчанию и прочее), а анализ проекта проводился без генерации диаграмм. Количество скриптов в демо-проекте уменьшилось на один ("Wrapped function.fnc") с версии CS 9, то есть примем везде по 60 скриптов. Настройки анализатора во всех тестах идентичны, так как взяты дефолтные.
Но сначала поглядим на запуск приложения. До версии CS 9 процесс открытия приложения проходил в так называемом "невидимом" режиме, когда пользователь не понимал, что происходит в системе: на панели задач не было кнопки приложения, на рабочем столе никаких новых окон. Спасибо, в CS 9 через 5 секунд молчания добавили "пропеллер" загрузки, а в предыдущих версиях какой-либо реакции по запуску приложения приходилось ждать иногда и более двух минут. Окно выбора лицензии мелькнуло на 5-10 секунде, а далее - пустое молчание.
 |
| Зависание старта |
Казалось бы, первый и второй запуск должны быть идентичны, но график показывает реальные цифры. Напомню, все тесты проводились на одной машине, сначала первый, потом после очистки - второй и третий подряд (без очистки машины от инсталляции). Как видим из графика, пользователи 7-мых версий дольше всех ожидали в неведении отклика интерфейса. Но не стоит столь позитивно воспринимать значения 8-мых версии, так как по значениям следующего графика вам станет понятно, что фактически начать работу быстрее в 7-мых версиях, потом или почти в равной степени в 9-тых.
 |
| Ожидание полно-рабочего интерфейса |
Здесь показано время, затрачиваемое триальным пользователем на стандартные клики (выбор триала, согласие о сроке использования, выбор проекта, подтверждение некоторых интерфейсных настроек) до тех пор, пока на экране не прорисуется полностью демо-проект и можно будет с ним что-либо делать: смотреть результаты анализа, менять настройки, переанализировать или получать отчёт.
Следующий график является частью предыдущего, так как подсчитано время только до момента выбора проекта, без последующей прорисовки интерфейса главного окна приложения.
 |
| Затраты на выбор проекта |
Накручивание каких-то скрытых обработок от версии к версии неблагоприятно сказывается на работоспособности интерфейсного приложения. Когда ваш маркетолог или аналитик просит вставить сбор статистики, то хорошенько оцените конкретное место для этого действия: при каждом запуске приложения или перед конкретными кликами. Любое ожидание пользователя - это его нервы, особенно, если экран никак не отображает процесс.
Например, программисты ConquestSS, как говорится в Release Notes, от версии к версии что-то ускоряют. Но мои замеры показывают, что это какие-то пустые хлопоты. Взгляните на значения для CS 7.1 64bit и сравните их с другими. Только в этой версии по-умолчанию открывалась панель Script Editor (редактор, дерево кода и первая из панелей с результатами анализа скрипта - Errors), тогда как во всех других (в том числе и в CS 7.1 32bit) отрисовывалась более красочная закладка Summary с множеством графиков.
 |
| Прорисовка главного окна при запуске приложения с открытием демо-проекта |
Раздражительность пользователя растёт от непонимания происходящего и, как факт, обновление главного окна юзеру приходится ожидать более 10 секунд при открытии проекта и по 5 секунд после каждого анализа.
 |
| Прорисовка главного окна после анализа проекта |
Для понимания этого графика стоит учесть, что процесс прорисовки юзер видит собственными глазами. Но в некоторых версиях были отличия: 1) как уже было сказано, CS 7.1 64bit активировал Script Editor (текст и пара таблиц) закладку, а все остальные - Summary (несколько чартов); 2) в 7-мых версиях после анализа курсор в дереве проекта перескакивал на первый скрипт и, следовательно, значения в панели с результатами анализа просчитывались только для одного скрипта; 3) в 8-мых и 9-тых версиях выбранные для анализа ноды в дереве проекта не теряли своих чекеров и, следовательно, значения в панели с результатами анализа просчитывались для всех выбранных скриптов и папок; 4) CS 7.1 64bit отличилась и в числе подсвеченных нод после анализа тем, что курсор в дереве раздваивался - на верхней ноде оставалась подсветка и на первом скрипте прорисовывался курсор-подсветка. Как видите из графика, снижение ожидания было за счёт закладки Script Editor в CS 7.1 64bit и, вероятно, за счёт каких-то снижений затрат на обработку интерфейса в 8-мых и 9-тых версиях.
 |
| CS 9 black - Summary tab |
 |
| CS 7.1 64bit - Script Editor tab |
 |
| Cs 7.1 64bit - Project Tree node highlighting |
Ещё некоторые графики мне показались интерсными. В них выведены цифры из панели самого процесса анализа. Напомню, что в каждой версии продукта ожидались идентичные данные для первых двух анализов и значительное снижение за счёт избегания генерации диаграмм и сбора инфы для них (убраны чекеры с Call Tree, Flowchart, CRUD1, CRUD2 и выбрано Delete при валидации диаграммных данных).
 |
| Время общего анализа и генерации Call Tree |
Добавив ещё по паре-тройке тестов для каждой версии и выкинув результаты анализа без генерации диаграмм, результаты не приблизились к желаемой скорости.
 |
серая линия - весь анализ, коричневая - call tree |
Большая часть анализа отводится на форматирование и разбор структуры подпрограмм для проверки правил кодирования. Но, к сожалению, программисты не вычленяют сбор данных для диаграмм из процесса форматирования и анализа, если опции формирования чартов выключены. В нижеследующем графике каждые два-три последних форматирования в рамках версии продукта выполнены без диаграмм (удаление без валидации), но времени затрачивается больше, чем с формированием с нуля или валидацией.
 |
| Время выборки данных анализатора и форматирования кода |
Для того, чтобы легче вам было разглядеть графики, они сгруппированы только по временным величинам (первая группа - полное время анализа и генерация call tree, второй - только форматирование или обработка данных для проверки правил кодирования, третья - генерация матриц crud и диаграмм flowchart).
 |
| Время генерации матриц crud и диаграмм flowchart |
Очень странно, что полный анализ (серая линия на первом графике и второй график) проходит за разное время во впервые открытом приложении и при повторном запуске проги. Весьма заметно, что в 9-й версии что-то "накрутили" (светло-зелёная линия) при генерации flowchart, и с версии 8.1 что-то намудрили (синяя линия резко взлетела) для CRUD1.
В демо-проекте 60 скриптов, по полсотни flowchart и call tree диаграмм, десяток crud матриц. Все запуски имели равные условия (одна машина и рабочий день, без лишних параллельных процессов), а линия обработки проекта показывает, что время не различается при генерации с диаграммами или только с анализом, без диаграмм. Соглашусь, что количество проведённых тестов для таких выводов маловато. Но тенденции по "совершенствованию" продукта вполне можно обнаружить.
Красота, конечно, требует жертв, но это совершенно нельзя применять к интерфейсным продуктам, которые хоть и помогают юзеру общаться с данными в упрощённом режиме, но пользователь в первую очередь желает не терять скорость обращения к данным и получать отчёты. Так, например, HTML Project Report с каждой версией замедляется.
 |
| Время генерации отчётов проекта |
График показывает время формирования отчёта по демо-проекту: впервые открытого в чистом триале, после полного анализа, после анализа без диаграмм и ещё раз после полного переанализа. Наименьшие значения по версиям соответствует проекту без диаграмм. Но среднее время по версиям отчего-то растёт, хотя ни в каких RNs не упоминалось ни о каких изменениях в алгоритме генерации отчёта. Значит общие интерфейсные изменения в продукте отрицательно сказывались на генерации отчёта.
Из вышеизложенного могу порекомендовать тестировщикам и программистам интерфейсных десктопных приложений следующее.
1. Все внутренние
процессы должны иметь
визуализацию:
конечную в виде "градусника" с процентами или
таймерную анимацию в виде "пропеллера". Даже движущийся "пропеллер" не всегда даёт уверенность, что процесс когда-то закончится. А наличие сменяемого счётчика (хотя бы с 5-ти секундным интервалом) обнадёживает юзера благополучным исходом.
2. Десктопное приложение с первых секунд
запуска должно быть обозначено на рабочем столе, на панели задач или трее. Юзер не должен рыскать по Диспетчеру Задач в поисках причин
визуальной тишины. Причём
подписи должны быть адекватными: обязательно актуальное название продукта (не как в CS 9 - пустая кнопка), информация о текущем состоянии продукта (инсталлируется, настраивается, запускается, закрывается, сохраняет или восстаналивает данные и тому подобное).
3.
Сбор статистики для аналитиков или маркетологов не должен отягощать обычную работу пользователя. Если же это временно или срочно необходимо производителям, то перед выпуском проведите замеры и в
Release Notes перечислите все
процессы, которые станут
замедляться.
4. Прежде чем кардинально менять интерфейс на
новомодные элементы, замерьте прорисовку часто используемых окон по
времени и объёму
памяти.
5. Перерисовку
основного окна не стоит выполнять
бэкграундом. Закрывайте текущее окно, а затем ОДИН раз обновляйте главное. Иначе, ваше основное окно будет затрачивать ресурсы дважды: под текущим и при активации (например, в CS по завершении анализа моргают панели в основном окне, а после закрытия диалога опять прорисовывают тоже самое).
Перед началом тестов у меня была мизерная надежда, что разработчики в ConquestSS услышали своих пользователей и вместе с "бантиками" в виде новых иконок и тем подложки ускорили работу в приложении. Но, как всегда, вся вера в лучшее рухнула при виде результатов тестов. Помимо того, новый интерфейс только усугубил неудобства в виде плохо просматриваемых элементов, а местами и отсутствие привычных полезностей. Среди последнего: кнопка приложения в режиме загрузки приложения не имеет подписи; в тёмной теме очень трудно разглядеть выбранные ноды в дереве, процесс не отображается на кнопке приложения в панеле задач; сочетание новых иконок и тёмной темы не продумано - чёрные или голубые тонкие линии не видны на сером фоне. Так что в моей копилке высказываний завелось ещё одно: "Декорирование - хитрая наука, но тестировщик знает, что
чем ярче банты, тем круче баги".
