Отчёт о тестировании SQLDetective 5.0.1 (build 159), опубликованном 30 апреля 2019 года. Тесты основаны на Release Notes.
IMPROVEMENTS 1.4+0=1.4 балла из 2+1=3 возможных
Object Navigator 1.4 балла из 2 возможных
• Added the ability to customize the behavior of Ctrl+Click for database objects.
Добавлена возможность настраивать поведение горячей клавиши для объектов базы данных.
• Added new options to “Preferences > Code Editor > Ctrl+click on an object”:
i. “Located it in Object Navigator”
ii. “Opens it in Object Wizard”
iii. “Opens it in Describe Object”
Добавлены новые опции в настройки редакторов кода по клику на объект: позиционирование в навигаторе объектов, открытие мастера объекта, открытие описания объекта.
Оба пункта объединяем в единый комплекс тестов, поскольку они являются частью друг друга.
Новшества касаются настройки функционала, то есть тесты будут двунаправленными. В настройках приложения найдём указанную опцию и проведём её исследование по чит-листу. Функциональные тесты её предназначения будем проводить в связке редакторов кода с навигатором объектов и мастерами объектов.
Пункты RNs расположены в группе навигатора объектов, но опция в Preferences расположена на странице "Code Editors", а не на "General / Object Navigator". Это минус в карму составителя RNs. Из описания новшеств можно было бы предположить, что кликать по объекту стоило в навигаторе (дереве или на какой-то из закладок с содержимым), но по расположению опции в настройках приложения понимаем, что в рамках функциональных тестов кликать будем из окон редактора кода. Подписи трёх вариаций понятны (позиционировать в дереве объектов, открывать мастер объекта, открывать описание объекта), но есть сомнения по выбору интерфейсного элемента - чек-боксы. Это значит, что срабатывать смогут сразу три варианта, но не понятна последовательность активации окон и их приоритетность. Все три окна самостоятельные, то есть будут работать параллельно, но возможно перекрытие одного другим, а следственно - потеря фокуса. К тому же, окно Describe Object не являясь модальным всё же имеет свойство показываться поверх всех остальных. Такое поведение можно считать диссонансом разработки: 1) странен выбор окна для авто-открытия, почему не Object Properties?; 2) насколько важна та или иная инфа юзеру? не лишний ли третий вариант?; 3) пора заменить статус "поверх всех" на "прижатость к краю рабочей области", чтобы не мешать работе в основном окне. В хелпе имеется описание каждого из трёх вариантов. Дефолтный вариант нигде не описан, тесты (запуск приложения с обнулёнными настройками, запуск после апдейта, выполнить возврат в окне настроек) указали на один вариант открытия мастера объекта. Сохранение/восстановление опций на открытии/закрытии окна и приложения, при экспорте/импорте в/из файл(а) работает без спутывания значений. Открытие соответствующих опциям окон работает в ожидаемых вариантах, кроме одного варианта порядка (чуть ниже об этом). Кстати, в рамках проверки этих двух пунктов RNs можно экономить время на тесты, совмещая проверки сохранения/восстановления с применением значений, то есть функционирование интерфейса и системы. В качестве редактора кода можно ограничиться SQL Editor, но для полноты проверок придётся покликать в множестве других (Stored Program Editor, View Wizard / SQL query, Object Navigator / ContentSelector / DDL, Session Navigator / Current Statement, ...) При всех включенных вариантах первым открывается окно мастера объекта, затем его описания, потом раскрывается дерево навигатора, но активный курсор остаётся в окне Describe Object. Такое странное поведение легко заметно, если перед началом теста не было открыто ни одно из активируемых окон, навигатор в свёрнутом состоянии (никакая из веток ещё не разворачивалась, ContentSelector спрятан). Если же ContentSelector развёрнут, то сначала в навигаторе объектов проходит перерисовка, затем открываются мастер объекта и окно с его составляющими. Не для всех типов объектов существуют самостоятельные мастера, поэтому хранимые подпрограммы активируют Stored Program Editor, одноимённые подобъекты подменяются их родительскими, синонимы и их оригиналы регулируются соседней настройкой "Preferences / Code Editors / Ctrl+Click on Synonym Navigates to: Synonym[Object]". При тестировании выявлена недоработка модуля Describe Object: при любом значении опции "Preferences / Code Editors / Ctrl+Click on Synonym Navigates to: Synonym[Object]" на первой позиции всегда стоит синоним, а в его структуре - родительский объект. Навигатор и мастер объекта отрабатывают в ожидаемом порядке: синоним для синонима, объект для объекта. Более логичным было бы открытие только объекта в режиме "Preferences / Code Editors / Ctrl+Click on Synonym Navigates to: Object" и синонима с объектом в режиме "Preferences / Code Editors / Ctrl+Click on Synonym Navigates to: Synonym".
Выявлен баг при попытке развернуть ноду Editions в дереве объектов (а также клик по имени в редакторе кода) запрос к базе не отрабатывает с оракловой ошибкой "ora-00900: invalid SQL statement".
Два пункта RNs по совокупности реализаций и выявленных проблем получают 1.4 балла
Preferences 0 из 1 возможного
• Increased the object name length to 128 characters.
Увеличена длина имени объекта до 128 символов.
Почему пункт RNs расположен в группе настроек приложения и что он вообще значит - большая загадка. Если бы это была группа Core или UI, то можно было бы предположить, что все интерфейсные элементы, отображающие наименование объекта, теперь автоматически расширяются до 128 символов или уже имеют заданную ширину. Если бы новшество конкретизировало версию DB Oracle (например, 12.2), то можно было бы предположить, что перед обращением к базе приложение дополнительно парсит код, вычленяя имя объекта размером до 128 символов. А как на счёт мультибайтовости и пропорциональности символов байтам (опция "Preferences / General / Session / Byte per character" и изначальная заявка Oracle про длину в байтах, а не в символах)? К сожалению, при таком скудном описании новшества не могу предложить каких-либо конкретных мест для тестирования, поэтому пункт не получает ни балла.
BUGS FIXED 0.8+0+1+1=2.8 баллов из 1+1+1+2=5 возможных
Core 0.8 из 1 возможного
• Fixed fetching of LONG fields and extraction of DDL triggers and views.
Поправлена выборка LONG-полей и выгрузка структуры триггеров и вьюверов.
В одно короткое предложение общей группы попытались вместить солидную переработку. Выборка полей возможна в гридах данных нескольких окон (SmartDataset, Object Navigator / ContentSelector / Data tab, Table[View] Wizard / Data page, гриды админских модулей и прочие окна) и SQL Output вьювере. Как связаны LONG-поля и структуры вьюверов, триггеров? Если поглубже изучить DB Oracle, то выясниться, что тело триггера и запрос вьювера хранятся в полях типа LONG (sys.all_views.text, sys.all_triggers.trigger_body). Это значит, что наши тесты можно ограничить вариантами триггеров и вьюверов с различным содержимым их тел и запросов. Поскольку тех.писательница поленилась уточнить смысл правки, то тесты придётся проводить по нескольким категориям: объём текста, наличие/нехватка спец.символов (в том числе и альтернативное цитирование, мультибайтовые региональные значки, синтаксис языков Oracle - DML, DDL, PL/SQL), форматирование текста. А поскольку она же не уточнила модуль приложения, то проверять будем не только мастера триггера и вьювера, но и все окна с гридами (смотри список выше) и ddl (Object Navigator / ContentSelector / DDL tab, Schema Extractor, Fast Copier, Objects Compare, DB Examiner / Triggers и прочие подобные). Моих возможностей хватило только на минимальную проверку по объёму (в простейшем запросе символьное выражение состоит из нескольких сотен строк латинских букв, объект создаётся и редактируется в своём мастере), так что тесты мультибайтовых или иных символов вы можете сделать самостоятельно, и с высокой вероятностью обнаружите ещё проблемы. Если бы текст фикса был более конкретным (для ориентировки по модулям и функционалу), то заслужил бы полный балл, а так -даю только 0.8.
Query Dataset 0 из 1 возможного
• The error “Out of system resources” no longer occurs on trying to run SQLDetective in trial mode when “Query All Records” is enabled.
Ошибка превышения ресурсов больше не случается при попытке запустить приложение в триальном режиме и включенной опции для запроса всех строк.
Опция запроса всех строк "Query all records" настраивается на странице "Preferences / Dataset Editors". Тесты открытия приложения с подключением к базе и без подключения в текущем и предыдущем билдах не показали никакой разницы, поэтому пункт RNs считаю припиской и не даю ни балла. Тем не менее выяснилось, что предупреждение об ограничении триала в 1000 запрашиваемых строк дублируется перед заполнением навигатора объектов. Полагаю, это происходит не только для заполнения грида в ContentSelector, но и для автоматического подсчёта количества объектов для каждой ноды в ObjectSelector. Но это действие понятно только мне, как хорошему знатоку внутренностей продукта. А обычный юзер вполне может это посчитать спамом. Поэтому такие предупреждения стоит конкретизировать текстом запроса или припиской о его назначении для внутренних нужд приложения.
Dataset/Datagrid 1 из 1 возможного
• Unicode symbols are no longer broken on inserting/updating LONG fields.
Юникодные символы больше не портятся при вставке и редактировании LONG-полей.
Этот пункт RNs можно считать продолжением предыдущей правки про выборку больших значений. Но в данном случае функционал ограничен гридами и не рассматривает текстовые редакторы в мастерах объектов. Но стоит пояснить, что гриды состоят из ячеек, в которых свои редакторы вызываются. Для теста возьмём готовую или создадим свою таблицу с LONG-полем (оно может быть только одно - см.ограничения в документации Oracle). Базы данных для полноты тестов должны быть двух типов - юникодная и обычная. Примеры юникодных символов имеются на ресурсных порталах тестировщиков. Вставку и редактирование данных проводим через текстовый редактор для ячеек LONG-полей и выполняя DML-команды в SQL Editor, просмотр данных осуществляем через редакторы ячеек и в "SQL Editor / SQL Output" окне. Результаты тестов таковы, что причиной проблемы являлись редакторы ввода и отображения содержимого полей. Хоть мои проверки и были ограничены базой одного типа, но фиксу дам полный балл.
Code Analyzer 0+1=1 из 2 возможных
• A naming rule violation is now triggered for sequences in PL/SQL.
Проверка правила наименования последовательностей теперь срабатывает в PL/SQL.
• A naming rule violation is now triggered for sequences on changing the NEXTVAL/CURRVAL keywords case.
Проверка правила наименования последовательностей теперь срабатывает при изменении регистра служебных слов NEXTVAL/CURRVAL.
Обе правки проверим единым тестом, потому что они касаются одной настройки анализатора кода "Tools / Code Audit / Code Analyzer Options / Code Review Options / Naming Rules / Sequence Name". .Тексты RNs более похожи на усовершенствование, а не баги. И такой факт не в пользу тех.писательницы, потому что владелец продукта оценивает билд по группе импрувов, а список багов даже не смотрит. Ещё одним промахом тех.писательницы стоит считать незаконченность понятия: вместо конкретного места "PL/SQL block" сказано обо всём PL/SQL, что сильно сбивает юзера. Для теста включаем вышеуказанную опцию (по-умолчанию, постфикс у последовательности считается равным "_seq" или "_s") и анализируем (путь из главного меню: "Tools / Code Audit / Analyze Code") PL/SQL код с обращением к последовательностям в Stored Program Editor или SQL Editor, Trigger Wizard. Предлагаю нижеследующий код вставить в текст подпрограммы и проанализировать как самостоятельный блок, поиграть с регистром служебных слов:
begin
select seq_tbl.nextval into prm from dual;
select seq_tbl.currval into prm1 from dual;
end;
В текущем билде на закладке Code Review с результатами анализатора кода будут записи в ноде "Readability / Naming Rule Template violation" пока последовательность не будет переименована соответствующим образом, например, в "my_seq". В предыдущем билде правило срабатывает только при соответствующем регистре служебных слов. Смущает тот факт, что мой пример является самостоятельным блоком, который якобы не должен был бы выявлять неверно названные последовательности в предыдущем билде. Но это не так, значит первый пункт RNs является ложью, поэтому не заслуживает ни балла. А второй пункт исполнен и билд за него получает балл.
Итого билд получает 1.4+2.8=4.2 балла из 3+5=8 возможных, что равняется 4.2/8=52.5% готовности.
IMPROVEMENTS 1.4+0=1.4 балла из 2+1=3 возможных
Object Navigator 1.4 балла из 2 возможных
• Added the ability to customize the behavior of Ctrl+Click for database objects.
Добавлена возможность настраивать поведение горячей клавиши для объектов базы данных.
• Added new options to “Preferences > Code Editor > Ctrl+click on an object”:
i. “Located it in Object Navigator”
ii. “Opens it in Object Wizard”
iii. “Opens it in Describe Object”
Добавлены новые опции в настройки редакторов кода по клику на объект: позиционирование в навигаторе объектов, открытие мастера объекта, открытие описания объекта.
Оба пункта объединяем в единый комплекс тестов, поскольку они являются частью друг друга.
Новшества касаются настройки функционала, то есть тесты будут двунаправленными. В настройках приложения найдём указанную опцию и проведём её исследование по чит-листу. Функциональные тесты её предназначения будем проводить в связке редакторов кода с навигатором объектов и мастерами объектов.
Пункты RNs расположены в группе навигатора объектов, но опция в Preferences расположена на странице "Code Editors", а не на "General / Object Navigator". Это минус в карму составителя RNs. Из описания новшеств можно было бы предположить, что кликать по объекту стоило в навигаторе (дереве или на какой-то из закладок с содержимым), но по расположению опции в настройках приложения понимаем, что в рамках функциональных тестов кликать будем из окон редактора кода. Подписи трёх вариаций понятны (позиционировать в дереве объектов, открывать мастер объекта, открывать описание объекта), но есть сомнения по выбору интерфейсного элемента - чек-боксы. Это значит, что срабатывать смогут сразу три варианта, но не понятна последовательность активации окон и их приоритетность. Все три окна самостоятельные, то есть будут работать параллельно, но возможно перекрытие одного другим, а следственно - потеря фокуса. К тому же, окно Describe Object не являясь модальным всё же имеет свойство показываться поверх всех остальных. Такое поведение можно считать диссонансом разработки: 1) странен выбор окна для авто-открытия, почему не Object Properties?; 2) насколько важна та или иная инфа юзеру? не лишний ли третий вариант?; 3) пора заменить статус "поверх всех" на "прижатость к краю рабочей области", чтобы не мешать работе в основном окне. В хелпе имеется описание каждого из трёх вариантов. Дефолтный вариант нигде не описан, тесты (запуск приложения с обнулёнными настройками, запуск после апдейта, выполнить возврат в окне настроек) указали на один вариант открытия мастера объекта. Сохранение/восстановление опций на открытии/закрытии окна и приложения, при экспорте/импорте в/из файл(а) работает без спутывания значений. Открытие соответствующих опциям окон работает в ожидаемых вариантах, кроме одного варианта порядка (чуть ниже об этом). Кстати, в рамках проверки этих двух пунктов RNs можно экономить время на тесты, совмещая проверки сохранения/восстановления с применением значений, то есть функционирование интерфейса и системы. В качестве редактора кода можно ограничиться SQL Editor, но для полноты проверок придётся покликать в множестве других (Stored Program Editor, View Wizard / SQL query, Object Navigator / ContentSelector / DDL, Session Navigator / Current Statement, ...) При всех включенных вариантах первым открывается окно мастера объекта, затем его описания, потом раскрывается дерево навигатора, но активный курсор остаётся в окне Describe Object. Такое странное поведение легко заметно, если перед началом теста не было открыто ни одно из активируемых окон, навигатор в свёрнутом состоянии (никакая из веток ещё не разворачивалась, ContentSelector спрятан). Если же ContentSelector развёрнут, то сначала в навигаторе объектов проходит перерисовка, затем открываются мастер объекта и окно с его составляющими. Не для всех типов объектов существуют самостоятельные мастера, поэтому хранимые подпрограммы активируют Stored Program Editor, одноимённые подобъекты подменяются их родительскими, синонимы и их оригиналы регулируются соседней настройкой "Preferences / Code Editors / Ctrl+Click on Synonym Navigates to: Synonym[Object]". При тестировании выявлена недоработка модуля Describe Object: при любом значении опции "Preferences / Code Editors / Ctrl+Click on Synonym Navigates to: Synonym[Object]" на первой позиции всегда стоит синоним, а в его структуре - родительский объект. Навигатор и мастер объекта отрабатывают в ожидаемом порядке: синоним для синонима, объект для объекта. Более логичным было бы открытие только объекта в режиме "Preferences / Code Editors / Ctrl+Click on Synonym Navigates to: Object" и синонима с объектом в режиме "Preferences / Code Editors / Ctrl+Click on Synonym Navigates to: Synonym".
Выявлен баг при попытке развернуть ноду Editions в дереве объектов (а также клик по имени в редакторе кода) запрос к базе не отрабатывает с оракловой ошибкой "ora-00900: invalid SQL statement".
Два пункта RNs по совокупности реализаций и выявленных проблем получают 1.4 балла
Preferences 0 из 1 возможного
• Increased the object name length to 128 characters.
Увеличена длина имени объекта до 128 символов.
Почему пункт RNs расположен в группе настроек приложения и что он вообще значит - большая загадка. Если бы это была группа Core или UI, то можно было бы предположить, что все интерфейсные элементы, отображающие наименование объекта, теперь автоматически расширяются до 128 символов или уже имеют заданную ширину. Если бы новшество конкретизировало версию DB Oracle (например, 12.2), то можно было бы предположить, что перед обращением к базе приложение дополнительно парсит код, вычленяя имя объекта размером до 128 символов. А как на счёт мультибайтовости и пропорциональности символов байтам (опция "Preferences / General / Session / Byte per character" и изначальная заявка Oracle про длину в байтах, а не в символах)? К сожалению, при таком скудном описании новшества не могу предложить каких-либо конкретных мест для тестирования, поэтому пункт не получает ни балла.
BUGS FIXED 0.8+0+1+1=2.8 баллов из 1+1+1+2=5 возможных
Core 0.8 из 1 возможного
• Fixed fetching of LONG fields and extraction of DDL triggers and views.
Поправлена выборка LONG-полей и выгрузка структуры триггеров и вьюверов.
В одно короткое предложение общей группы попытались вместить солидную переработку. Выборка полей возможна в гридах данных нескольких окон (SmartDataset, Object Navigator / ContentSelector / Data tab, Table[View] Wizard / Data page, гриды админских модулей и прочие окна) и SQL Output вьювере. Как связаны LONG-поля и структуры вьюверов, триггеров? Если поглубже изучить DB Oracle, то выясниться, что тело триггера и запрос вьювера хранятся в полях типа LONG (sys.all_views.text, sys.all_triggers.trigger_body). Это значит, что наши тесты можно ограничить вариантами триггеров и вьюверов с различным содержимым их тел и запросов. Поскольку тех.писательница поленилась уточнить смысл правки, то тесты придётся проводить по нескольким категориям: объём текста, наличие/нехватка спец.символов (в том числе и альтернативное цитирование, мультибайтовые региональные значки, синтаксис языков Oracle - DML, DDL, PL/SQL), форматирование текста. А поскольку она же не уточнила модуль приложения, то проверять будем не только мастера триггера и вьювера, но и все окна с гридами (смотри список выше) и ddl (Object Navigator / ContentSelector / DDL tab, Schema Extractor, Fast Copier, Objects Compare, DB Examiner / Triggers и прочие подобные). Моих возможностей хватило только на минимальную проверку по объёму (в простейшем запросе символьное выражение состоит из нескольких сотен строк латинских букв, объект создаётся и редактируется в своём мастере), так что тесты мультибайтовых или иных символов вы можете сделать самостоятельно, и с высокой вероятностью обнаружите ещё проблемы. Если бы текст фикса был более конкретным (для ориентировки по модулям и функционалу), то заслужил бы полный балл, а так -даю только 0.8.
Query Dataset 0 из 1 возможного
• The error “Out of system resources” no longer occurs on trying to run SQLDetective in trial mode when “Query All Records” is enabled.
Ошибка превышения ресурсов больше не случается при попытке запустить приложение в триальном режиме и включенной опции для запроса всех строк.
Опция запроса всех строк "Query all records" настраивается на странице "Preferences / Dataset Editors". Тесты открытия приложения с подключением к базе и без подключения в текущем и предыдущем билдах не показали никакой разницы, поэтому пункт RNs считаю припиской и не даю ни балла. Тем не менее выяснилось, что предупреждение об ограничении триала в 1000 запрашиваемых строк дублируется перед заполнением навигатора объектов. Полагаю, это происходит не только для заполнения грида в ContentSelector, но и для автоматического подсчёта количества объектов для каждой ноды в ObjectSelector. Но это действие понятно только мне, как хорошему знатоку внутренностей продукта. А обычный юзер вполне может это посчитать спамом. Поэтому такие предупреждения стоит конкретизировать текстом запроса или припиской о его назначении для внутренних нужд приложения.
Dataset/Datagrid 1 из 1 возможного
• Unicode symbols are no longer broken on inserting/updating LONG fields.
Юникодные символы больше не портятся при вставке и редактировании LONG-полей.
Этот пункт RNs можно считать продолжением предыдущей правки про выборку больших значений. Но в данном случае функционал ограничен гридами и не рассматривает текстовые редакторы в мастерах объектов. Но стоит пояснить, что гриды состоят из ячеек, в которых свои редакторы вызываются. Для теста возьмём готовую или создадим свою таблицу с LONG-полем (оно может быть только одно - см.ограничения в документации Oracle). Базы данных для полноты тестов должны быть двух типов - юникодная и обычная. Примеры юникодных символов имеются на ресурсных порталах тестировщиков. Вставку и редактирование данных проводим через текстовый редактор для ячеек LONG-полей и выполняя DML-команды в SQL Editor, просмотр данных осуществляем через редакторы ячеек и в "SQL Editor / SQL Output" окне. Результаты тестов таковы, что причиной проблемы являлись редакторы ввода и отображения содержимого полей. Хоть мои проверки и были ограничены базой одного типа, но фиксу дам полный балл.
Code Analyzer 0+1=1 из 2 возможных
• A naming rule violation is now triggered for sequences in PL/SQL.
Проверка правила наименования последовательностей теперь срабатывает в PL/SQL.
• A naming rule violation is now triggered for sequences on changing the NEXTVAL/CURRVAL keywords case.
Проверка правила наименования последовательностей теперь срабатывает при изменении регистра служебных слов NEXTVAL/CURRVAL.
Обе правки проверим единым тестом, потому что они касаются одной настройки анализатора кода "Tools / Code Audit / Code Analyzer Options / Code Review Options / Naming Rules / Sequence Name". .Тексты RNs более похожи на усовершенствование, а не баги. И такой факт не в пользу тех.писательницы, потому что владелец продукта оценивает билд по группе импрувов, а список багов даже не смотрит. Ещё одним промахом тех.писательницы стоит считать незаконченность понятия: вместо конкретного места "PL/SQL block" сказано обо всём PL/SQL, что сильно сбивает юзера. Для теста включаем вышеуказанную опцию (по-умолчанию, постфикс у последовательности считается равным "_seq" или "_s") и анализируем (путь из главного меню: "Tools / Code Audit / Analyze Code") PL/SQL код с обращением к последовательностям в Stored Program Editor или SQL Editor, Trigger Wizard. Предлагаю нижеследующий код вставить в текст подпрограммы и проанализировать как самостоятельный блок, поиграть с регистром служебных слов:
begin
select seq_tbl.nextval into prm from dual;
select seq_tbl.currval into prm1 from dual;
end;
В текущем билде на закладке Code Review с результатами анализатора кода будут записи в ноде "Readability / Naming Rule Template violation" пока последовательность не будет переименована соответствующим образом, например, в "my_seq". В предыдущем билде правило срабатывает только при соответствующем регистре служебных слов. Смущает тот факт, что мой пример является самостоятельным блоком, который якобы не должен был бы выявлять неверно названные последовательности в предыдущем билде. Но это не так, значит первый пункт RNs является ложью, поэтому не заслуживает ни балла. А второй пункт исполнен и билд за него получает балл.
Итого билд получает 1.4+2.8=4.2 балла из 3+5=8 возможных, что равняется 4.2/8=52.5% готовности.
Комментариев нет:
Отправить комментарий