Отчёт о тестировании SQLDetective 5.0.1 (build 173), опубликованном 28 мая 2019 года. Проверки основаны на пунктах Release Notes. Билд состоит только из фиксов багов без каких-либо новшеств, предыдущий билд публиковался месяц назад, это значит, что кто-то из пользователей выявил критичный баг, не имеющий обходного пути.
BUGS FIXED -0.5+0+0.8+0+0.8+0.8+0+0+0+0.6+0=2.5 из 1+2+1+1+3+2+1+1+1+1+1=15 возможных, за баги -0.4-0.7-0.5-0.4-0.5-0.5-1=-4
Core -0.5 из 1 возможного, -0.2-0.2=-0.4 за баги
* The error “Invalid argument to time encode” no longer occurs on trying to fetch a timestamp field.
Ошибка инвалидного аргумента для перекодирования времени больше не случается при попытке выбрать поля типа timestamp.
Пункт RNs в группе Core означает, что считывание времени поправлено не только для отображения данных базы данных Oracle, но и во всех модулях приложения, показывающих статистику SD, сохранённую в файловую систему рабочей машины. Для усугубления проверок выставим различные форматы времени в базе (можно использовать модуль "DB Examiner / NLS Parameters"), операционной системе и приложении (настройка "Time format" на странице "Preferences / General"). В предыдущем и текущем билдах будем вводить в базу и просматривать в интерфейсе сохранённые данные. Среди модулей для проверки должны быть: SmartDataset + Calendar Wizard + QBE, Table Wizard, SQL Editor + all Ouput tabs + SQL Execution History, last DB Connections list, Export/Import Data Wizards, DDL Generator for sched. objects, DB Monitor + History graphs. Ни один из модулей, отображающих данные напрямую из базы Oracle, не дали как-бы исправленный баг. Единственный модуль, который хранит и работает с датой и временем только для приложения и в рамках которого удалось воспроизвести баг - это DB Monitor. При попытке просмотреть ранее сохранённые графики на закладке History, описанная ошибка не позволяет отобразить сохранённые в файловой системе данные. Фикс исключил появление описанной ошибки, но внёс более критичный баг - после двойного клика на строке из списка историй отображает графики и сопровождает Eureka-логом "Access violation at address 01D19D8C", троекратное срабатывание которого перегружает приложение. Это говорит о том, что либо программист фиксил вслепую, либо знал о шагах воспроизведения, но не проверил их в готовом приложении. Так рождается регрессия, из-за которой пункт RNs не получает, а теряет -0.5 балла, в том числе учтено неконкретное описание бага.
Пока создавалась таблица и её данные для тестов, были выявлены интерфейсные недочёты. Кнопки на тулбаре страницы Data в мастере таблицы размещены с нарушением дистанции, которое приводит к смещению хинтов для последующих кнопок. Если бы кнопки только были прилеплены друг к другу при полной видимости их картинок, то это не было бы багом. Но поскольку эта интерфейсная погрешность изменяет функционал - хинт кнопки не совпадает с видимой позицией курсора, то баг заслуживает снятия -0.2 балла.
Также в рамках комплексного тестирования выявлено необоснованное половинчатое отключение (или лучше сказать лишняя активность) кнопок основного тулбара в окне SQL Editor. Пока активный курсор находится в окне SQL Editor, все его кнопки "горят". А если курсор переключить, например, в Навигатор Объектов, то "гасятся" (сереют) не все кнопки.
Это, во-первых, сбивает визуально пользователя, ищущего рабочее текущее окно. Во-вторых, большинство из подсвеченных кнопок являются глобальными экшенами, что смущает пользователя в плане - "не применится ли действие из неактивного модуля к текущему?". По-моему, если уж из модуля переключается активность на другое окно, то экономнее (юзерское время, ресурс компьютера) отключить родительский интерфейсный элемент (в нашем случае - тулбар), нежели переключать каждый из подобъектов (два-три десятка кнопок на тулбаре). За баг сниму ещё -0.2 балла.
SQL Editor 0+0=0 из 2 возможных, -0.4-0.3=-0.7 за баги
* Open tabs, unless they are empty, are now automatically restored at the next application launch even if they were not saved in the previous session.
Открытые закладки, если они не пустые, теперь автоматически восстанавливаются при следующем запуске приложения, даже если они не были сохранены в предыдущей сессии.
За сохранность содержимого и открытие закладок редактора (только о них речь в баге - примечание моё, как знатока приложения) отвечают несколько настроек:
- "Preferences / General / Workspace / Remember open windows",
- "Preferences / General / Workspace / Window Settings / SQL Editor / Auto Open",
- "Preferences / Code Editors / Save changes to file when closing window" = [Prompt/Auto/No],
- "Preferences / Code Editors / SQL Editor / Save SQL statement after execution",
- "Preferences / Code Editors / SQL Editor / Save valid SQL statement only" (не стоит путать с "Preferences / Code Editors / SQL Editor / SQL Execution History / Remember SQL History List / Keep valid SQL only"),
- "Preferences / Code Editors / SQL Editor / Editor and Tab Handling / Remember SQL statements" (+ "Prompt?").
При определённом сочетании опций ни окно, ни тем более его закладки со скриптами вообще не должны открываться при запуске приложения. Поэтому пункт RNs для меня прозвучал как приговор - даже если юзер не хочет, но SQL Editor всегда будет открывать все мои отработанные редакторы? Но на моё счастье тех.писательница поленилась упомянуть, при каких включенных опциях теперь так будет отрабатывать окно редактора. Этот же факт вынуждает нас тестировщиков тратить время на поиск бага в предыдущем билде. Никакую из перечисленных опций не уничтожили из приложения, поэтому придётся искать баг через сочетания каждой из них. Больше всего меня смущают слова "автоматически откроется" и "не сохранённые ранее". К тому же, ни один из тестов на функциональность перечисленных опций не способствовал воспроизведению бага в предыдущем билде. Если названия и значения опций "наложить" на текст фикса, то можно предположить, что "Preferences / Code Editors / Save changes to file when closing window" теперь всегда равно Auto, но успокою вас - это не так. Ещё можно извратиться и предположить, что опция "Preferences / Code Editors / SQL Editor / Editor and Tab Handling / Remember SQL statements" функционирует всегда как включенная. Но это тоже к счастью не подтвердилось. Скорее всего словом "автоматически" тех.писательница пыталась зашифровать некий внутренний процесс, который нигде не описан, но закодирован. Под термином "запуск приложения" имелось ввиду переоткрытие окна SQL Editor, потому что для восстановления закладок редактора нет необходимости перезагружать целое приложение. Максимально щедро могу за такую приписку отсудить 0 баллов. Но баги от комплексного тестирования вынуждают снять -0.4 балла и настоятельно предложить изменить тексты сообщений при сохранении скриптов в файл (вместо "Save SQL statements?" сообщать "Save script from the [EditorTabName] editor to file?") и при сохранении списка редакторов для последующего открытия (вместо "Remember SQL statements?" сообщать "Remember the list of editor tabs for further opening?"), а к чек-боксу "Don't show me again (Save in Preferences)" повсеместно приписывать путь к опции.
Какую опцию изменит чек-бокс в сообщении мне, как давнему знатоку SD, известно. А обычный юзер, тем более триальный, может сильно запутаться в обилии установок и столь кратких сообщениях. Эти два предложения очень давно оформлялись в BTS, но PM и тогда и сейчас считает их мелочными и ненужными. Очередной раз повторюсь: именно из мелочей складывается общее впечатление, как из кирпичиков дом. Можно сказать, что настал момент, когда один надтреснутый кирпич начинает кренить стену. Могу допустить, что баг-то на самом деле какой-то исключительный и был, но скорее всего он также был забыт в BTS, как сугубо редкий, а вот от того, что замечен на проде, его решено исправить. От внимания тестировщика не должны утекать никакие мелочи, а уж их важность могут поднять только воспроизведения на стороне пользователя.
* The error “Grid index out of range” no longer occurs after changing the scale to 125% and higher.
Ошибка превышения ранга больше не случается после изменения масштаба экрана до 125% и более.
Изменить масштаб монитора можно в двух случаях: до запуска приложения или при открытом SD. Поскольку модуль конкретизирован в RNs, но его интерфейсный элемент нет, то тесты придётся проводить при открытом редакторе, но для всех доступных закладок и панелей. Приложение не имеет собственной настройки масштабирования, то есть размер монитора меняйте в операционной системе. К сожалению, ни для какого элемента SQL Editor в предыдущем билде не удалось воспроизвести баг выхода за рамки индекса. Поэтому пункт RNs считаю припиской и не даю ни балла. А за выявленные проблемы с интерфейсом Object Navigator, который увеличивает свою ширину с каждым переключением масштаба, и за увеличение символов амперсанда в заголовке закладки SQL Editor с геометрической прогрессией сниму -0.3 балла.
Object Navigator 0.8 из 1 возможного
* The “Object not found” error no longer occurs on trying to open an object dependence from the Object Navigator.
Ошибка ненахождения объекта больше не случается при попытке открыть зависимости объекта из Навигатора Объектов.
Почти у каждого типа объектов имеется подпапка Dependencies в дереве навигатора. В этом списке могут быть разные объекты, но баг воспроизводился только для хранимых подпрограмм: процедуры, тела пакетов, триггеры и прочие. Если объект можно открыть в собственном мастере объекта, например, синоним, то баг не воспроизводился. Очевидный фикс мог бы получить полный балл, если бы был полностью описан.
Stored Program Editor 0 из 1 возможного
* The “Open object from DB” option now works correctly on trying to open a stored object different from the one opened in the Stored Program Editor.
Функция открытия объекта из базы теперь работает корректно при попытке открыть хранимую подпрограмму, отличную от уже открытых в редакторе.
Обращаю ваше внимание на перевод слова option, как "функциональность", хотя тех.писательнице стоило воспользоваться термином action, чтобы не путать восприятие читателя технического текста художественностью перевода. О каких-таких скрытых правилах думала тех.писательница при использовании термина correctly будем выяснять в тестах. Открыть хранимую подпрограмму можно тремя путями:
- из главного меню приложения выполнить "Object / Open", тогда редактор откроется после выбора объекта;
- в уже открытом редакторе выполнить открытие объекта через кнопку на его тулбаре или экшен в контекстном меню;
- из всех иных списков объектов, начиная с Object Navigator или Object List.
Но поскольку у меня есть подозрение, что этот баг является техническим продолжением предыдущего (из списка Object Navigator), то при тестировании уделим внимание именно модулям Stored Program Editor и Object Navigator. Подключимся к базе и не раскрывая дерева Object Navigator откроем две-три хранимые подпрограммы через главное меню "Object / Open". А затем развернём дерево навигатора и попытаемся выполнить "Object / Open" (из главного меню приложения или контекстного меню навигатора объектов) для уже открытых в Stored Program Editor объектов, предварительно найдя их в дереве навигатора. Также покликаем по объектам из ниспадающего списка кнопки "Open object(s) from database" и через пункт "File / Open / Database Object..." контекстного меню редактора. К сожалению, мне не удалось найти хоть какую-то разницу в работе предыдущего и текущего билдов. Поэтому не даю ни балла.
Dataset/Datagrid 0+0.8+0=0.8 из 3 возможных, -0.5 за баги
* Changing the date and time format in the system settings no longer causes the error “’[Timestamp]’ is not a valid date and time” on trying to insert a record in a table.
Изменение формата дат и времени в системных настройках больше не сопровождается ошибкой о невалидном значении даты и времени при попытке вставить строку в таблицу.
Составим минимальный тест-кейс на основе описания фикса. В операционной системе (настройки календаря и часового пояса) и приложении ("Preferences / General") выставим формат даты и времени по-умолчанию. Примечание: приложение при первом запуске устанавливает формат даты и времени, равнозначные системным. Создадим или возмём готовую таблицу, в которой есть поле для ввода даты и времени - простейший тип Date (все другие типы дат и времени можно включить в расширенный тест). Откроем эту таблицу в SmartDataset с открытой возможностью на редактирование:
- в базе имеются гранты select, update, insert, delete;
- на таблицу нет ограничивающих триггеров; в SD выключена опция "Preferences / General / Data Protection / Enable data protection" для подключенной сессии;
- нет ограничений в опциях SD при выполнении запросов "Preferences / Code Editors / SQL Editor / SQL Execution Wrapper";
- в SmartDataset выключен режим "Read-only Mode" (кнопка с замочком на тулбаре или одноимённый пункт в главном и контекстном меню Dataset).
Введём текущую дату в поле даты и времени через Мастер Календаря, а потом через ручной ввод (набрать на клавиатуре в соседней ячейке, учитывая видимые разделители). В операционной системе, не закрывая SmartDataset и SD, поменяем формат даты на любой иной, отличный от дефолтного. Опять повводим значения дат. Перезапустим SmartDataset и повводим значения дат. Перезапустим SD и повводим значения дат. При открытом SmartDataset поменяем форматы дат и времени в приложении и повводим ещё даты. Ни на каком из шагов предыдущий и текущий билды не ругнулись, как описано в баге. Поэтому фикс не получает балл.
* All digits of the second fractions are now visible when a comma is used as a decimal separator.
Все цифры размерности секунд теперь видны, когда запятая используется в качестве десятичного разделителя.
Для работы с вышеописанными данными обычного поля типа Date недостаточно. Нам для теста либо придётся сменить настройки базы (смотри команду "alter session set nls_date_format" в документации Oracle), либо сразу тестить на типе данных timestamp. Воспользуемся таблицей, на которой мы тестировали первый пункт RNs этого билда. Будем менять значения опции "Preferences / General / Decimal separator", которое возможно быть точкой или зяпятой из списка, либо вручную введённым любым иным символом. Тесты показали, что текст фикса неточен. Фактические (истинные) значения секунд с указанной точностью в гриде отображались только при значении разделителя десятичных знаков - точка. При всех иных символах разделителя десятичная часть секунд обнулялась. А вот смена десятичного разделителя при открытом наборе данных как обрезала всю десятичную часть секунд в прошлом билде, так и осталось багом обновления грида. Из-за неточности описания пункт RNs получает только 0.8 балла, а за сопутствующий баг (нет предупреждения о необходимости переоткрытия грида, нет автоматического полного обновления) сниму -0.5.
* The error “Field is not a LOB” no longer occurs on trying to edit and/or insert a record.
Ошибка о не LOB формате поля больше не случается при попытке отредактировать или вставить запись.
Поскольку упомянут тип поля LOB, то для тестирования возьмём или создадим четыре таблицы с типами BLOB, CLOB, NCLOB, BFILE. Не стоит мучать базу и создавать одну таблицу со всеми четырьмя типами, смешивая тесты приложения с возможностями системы. Для ввода и просмотра значений CLOB, NCLOB в SD применяется текстовый редактор, работающий с файловой системой. А для полей BLOB, BFILE имеется так называемый Blob Editor, позволяющий работать с разными типами файлов через их внешние библиотеки. Но для BFILE редактор так до сих пор и не дописан, поэтому не пытайтесь им воспользоваться. Честно говоря, ошибки с полями дат и почему-то LOB у меня воспроизводились на таблице с тремя десятками полей самых простых типов: number (от 1 до 4 разрядов), date, varchar2 (от 10 до 4000 символов). И если ошибки про несоответствующий формат даты мне были понятны, то неожиданные проблемы со вставкой больших текстов в поля, никак не касающиеся LOB, меня сильно смущали. И поскольку мне тогда не довелось выявить причину бага, то и тех.писательница завуалировала фикс, так и не раскрыв исходной ситуации. Мне не известны конкретные условия для воспроизведения бага в предыдущем билде, поэтому не получится проверить фикс. А обычные тесты добавления записей в таблицы с полями типов BLOB, CLOB, NCLOB не показали никакой разницы в работе текущего и предыдущего билдов. Пункт RNs не получает балл.
Table Wizard 0.5+0.3=0.8 из 2 возможных, -0.4 за баги
* An access violation no longer occurs on trying to modifying a table.
Ошибка доступа больше не происходит при попытке редактировать таблицу.BUGS FIXED -0.5+0+0.8+0+0.8+0.8+0+0+0+0.6+0=2.5 из 1+2+1+1+3+2+1+1+1+1+1=15 возможных, за баги -0.4-0.7-0.5-0.4-0.5-0.5-1=-4
Core -0.5 из 1 возможного, -0.2-0.2=-0.4 за баги
* The error “Invalid argument to time encode” no longer occurs on trying to fetch a timestamp field.
Ошибка инвалидного аргумента для перекодирования времени больше не случается при попытке выбрать поля типа timestamp.
Пункт RNs в группе Core означает, что считывание времени поправлено не только для отображения данных базы данных Oracle, но и во всех модулях приложения, показывающих статистику SD, сохранённую в файловую систему рабочей машины. Для усугубления проверок выставим различные форматы времени в базе (можно использовать модуль "DB Examiner / NLS Parameters"), операционной системе и приложении (настройка "Time format" на странице "Preferences / General"). В предыдущем и текущем билдах будем вводить в базу и просматривать в интерфейсе сохранённые данные. Среди модулей для проверки должны быть: SmartDataset + Calendar Wizard + QBE, Table Wizard, SQL Editor + all Ouput tabs + SQL Execution History, last DB Connections list, Export/Import Data Wizards, DDL Generator for sched. objects, DB Monitor + History graphs. Ни один из модулей, отображающих данные напрямую из базы Oracle, не дали как-бы исправленный баг. Единственный модуль, который хранит и работает с датой и временем только для приложения и в рамках которого удалось воспроизвести баг - это DB Monitor. При попытке просмотреть ранее сохранённые графики на закладке History, описанная ошибка не позволяет отобразить сохранённые в файловой системе данные. Фикс исключил появление описанной ошибки, но внёс более критичный баг - после двойного клика на строке из списка историй отображает графики и сопровождает Eureka-логом "Access violation at address 01D19D8C", троекратное срабатывание которого перегружает приложение. Это говорит о том, что либо программист фиксил вслепую, либо знал о шагах воспроизведения, но не проверил их в готовом приложении. Так рождается регрессия, из-за которой пункт RNs не получает, а теряет -0.5 балла, в том числе учтено неконкретное описание бага.
 |
| Наложенные картинки первых кнпок сбивают хинты последующим кнопкам |
Также в рамках комплексного тестирования выявлено необоснованное половинчатое отключение (или лучше сказать лишняя активность) кнопок основного тулбара в окне SQL Editor. Пока активный курсор находится в окне SQL Editor, все его кнопки "горят". А если курсор переключить, например, в Навигатор Объектов, то "гасятся" (сереют) не все кнопки.
 |
| Странный принцип отключения кнопок неактивного окна |
SQL Editor 0+0=0 из 2 возможных, -0.4-0.3=-0.7 за баги
* Open tabs, unless they are empty, are now automatically restored at the next application launch even if they were not saved in the previous session.
Открытые закладки, если они не пустые, теперь автоматически восстанавливаются при следующем запуске приложения, даже если они не были сохранены в предыдущей сессии.
За сохранность содержимого и открытие закладок редактора (только о них речь в баге - примечание моё, как знатока приложения) отвечают несколько настроек:
- "Preferences / General / Workspace / Remember open windows",
- "Preferences / General / Workspace / Window Settings / SQL Editor / Auto Open",
- "Preferences / Code Editors / Save changes to file when closing window" = [Prompt/Auto/No],
- "Preferences / Code Editors / SQL Editor / Save SQL statement after execution",
- "Preferences / Code Editors / SQL Editor / Save valid SQL statement only" (не стоит путать с "Preferences / Code Editors / SQL Editor / SQL Execution History / Remember SQL History List / Keep valid SQL only"),
- "Preferences / Code Editors / SQL Editor / Editor and Tab Handling / Remember SQL statements" (+ "Prompt?").
При определённом сочетании опций ни окно, ни тем более его закладки со скриптами вообще не должны открываться при запуске приложения. Поэтому пункт RNs для меня прозвучал как приговор - даже если юзер не хочет, но SQL Editor всегда будет открывать все мои отработанные редакторы? Но на моё счастье тех.писательница поленилась упомянуть, при каких включенных опциях теперь так будет отрабатывать окно редактора. Этот же факт вынуждает нас тестировщиков тратить время на поиск бага в предыдущем билде. Никакую из перечисленных опций не уничтожили из приложения, поэтому придётся искать баг через сочетания каждой из них. Больше всего меня смущают слова "автоматически откроется" и "не сохранённые ранее". К тому же, ни один из тестов на функциональность перечисленных опций не способствовал воспроизведению бага в предыдущем билде. Если названия и значения опций "наложить" на текст фикса, то можно предположить, что "Preferences / Code Editors / Save changes to file when closing window" теперь всегда равно Auto, но успокою вас - это не так. Ещё можно извратиться и предположить, что опция "Preferences / Code Editors / SQL Editor / Editor and Tab Handling / Remember SQL statements" функционирует всегда как включенная. Но это тоже к счастью не подтвердилось. Скорее всего словом "автоматически" тех.писательница пыталась зашифровать некий внутренний процесс, который нигде не описан, но закодирован. Под термином "запуск приложения" имелось ввиду переоткрытие окна SQL Editor, потому что для восстановления закладок редактора нет необходимости перезагружать целое приложение. Максимально щедро могу за такую приписку отсудить 0 баллов. Но баги от комплексного тестирования вынуждают снять -0.4 балла и настоятельно предложить изменить тексты сообщений при сохранении скриптов в файл (вместо "Save SQL statements?" сообщать "Save script from the [EditorTabName] editor to file?") и при сохранении списка редакторов для последующего открытия (вместо "Remember SQL statements?" сообщать "Remember the list of editor tabs for further opening?"), а к чек-боксу "Don't show me again (Save in Preferences)" повсеместно приписывать путь к опции.
 |
Два диалога о сохранении
КАКОГО-ТО (одного и того же) контента КУДА-ТО (разные хранилища)
при закрытии закладки, перекрытой этим диалогом
|
* The error “Grid index out of range” no longer occurs after changing the scale to 125% and higher.
Ошибка превышения ранга больше не случается после изменения масштаба экрана до 125% и более.
Изменить масштаб монитора можно в двух случаях: до запуска приложения или при открытом SD. Поскольку модуль конкретизирован в RNs, но его интерфейсный элемент нет, то тесты придётся проводить при открытом редакторе, но для всех доступных закладок и панелей. Приложение не имеет собственной настройки масштабирования, то есть размер монитора меняйте в операционной системе. К сожалению, ни для какого элемента SQL Editor в предыдущем билде не удалось воспроизвести баг выхода за рамки индекса. Поэтому пункт RNs считаю припиской и не даю ни балла. А за выявленные проблемы с интерфейсом Object Navigator, который увеличивает свою ширину с каждым переключением масштаба, и за увеличение символов амперсанда в заголовке закладки SQL Editor с геометрической прогрессией сниму -0.3 балла.
 |
| Знак амперсанда прибавляется на заголовке закладки |
* The “Object not found” error no longer occurs on trying to open an object dependence from the Object Navigator.
Ошибка ненахождения объекта больше не случается при попытке открыть зависимости объекта из Навигатора Объектов.
Почти у каждого типа объектов имеется подпапка Dependencies в дереве навигатора. В этом списке могут быть разные объекты, но баг воспроизводился только для хранимых подпрограмм: процедуры, тела пакетов, триггеры и прочие. Если объект можно открыть в собственном мастере объекта, например, синоним, то баг не воспроизводился. Очевидный фикс мог бы получить полный балл, если бы был полностью описан.
Stored Program Editor 0 из 1 возможного
* The “Open object from DB” option now works correctly on trying to open a stored object different from the one opened in the Stored Program Editor.
Функция открытия объекта из базы теперь работает корректно при попытке открыть хранимую подпрограмму, отличную от уже открытых в редакторе.
Обращаю ваше внимание на перевод слова option, как "функциональность", хотя тех.писательнице стоило воспользоваться термином action, чтобы не путать восприятие читателя технического текста художественностью перевода. О каких-таких скрытых правилах думала тех.писательница при использовании термина correctly будем выяснять в тестах. Открыть хранимую подпрограмму можно тремя путями:
- из главного меню приложения выполнить "Object / Open", тогда редактор откроется после выбора объекта;
- в уже открытом редакторе выполнить открытие объекта через кнопку на его тулбаре или экшен в контекстном меню;
- из всех иных списков объектов, начиная с Object Navigator или Object List.
Но поскольку у меня есть подозрение, что этот баг является техническим продолжением предыдущего (из списка Object Navigator), то при тестировании уделим внимание именно модулям Stored Program Editor и Object Navigator. Подключимся к базе и не раскрывая дерева Object Navigator откроем две-три хранимые подпрограммы через главное меню "Object / Open". А затем развернём дерево навигатора и попытаемся выполнить "Object / Open" (из главного меню приложения или контекстного меню навигатора объектов) для уже открытых в Stored Program Editor объектов, предварительно найдя их в дереве навигатора. Также покликаем по объектам из ниспадающего списка кнопки "Open object(s) from database" и через пункт "File / Open / Database Object..." контекстного меню редактора. К сожалению, мне не удалось найти хоть какую-то разницу в работе предыдущего и текущего билдов. Поэтому не даю ни балла.
Dataset/Datagrid 0+0.8+0=0.8 из 3 возможных, -0.5 за баги
* Changing the date and time format in the system settings no longer causes the error “’[Timestamp]’ is not a valid date and time” on trying to insert a record in a table.
Изменение формата дат и времени в системных настройках больше не сопровождается ошибкой о невалидном значении даты и времени при попытке вставить строку в таблицу.
Составим минимальный тест-кейс на основе описания фикса. В операционной системе (настройки календаря и часового пояса) и приложении ("Preferences / General") выставим формат даты и времени по-умолчанию. Примечание: приложение при первом запуске устанавливает формат даты и времени, равнозначные системным. Создадим или возмём готовую таблицу, в которой есть поле для ввода даты и времени - простейший тип Date (все другие типы дат и времени можно включить в расширенный тест). Откроем эту таблицу в SmartDataset с открытой возможностью на редактирование:
- в базе имеются гранты select, update, insert, delete;
- на таблицу нет ограничивающих триггеров; в SD выключена опция "Preferences / General / Data Protection / Enable data protection" для подключенной сессии;
- нет ограничений в опциях SD при выполнении запросов "Preferences / Code Editors / SQL Editor / SQL Execution Wrapper";
- в SmartDataset выключен режим "Read-only Mode" (кнопка с замочком на тулбаре или одноимённый пункт в главном и контекстном меню Dataset).
Введём текущую дату в поле даты и времени через Мастер Календаря, а потом через ручной ввод (набрать на клавиатуре в соседней ячейке, учитывая видимые разделители). В операционной системе, не закрывая SmartDataset и SD, поменяем формат даты на любой иной, отличный от дефолтного. Опять повводим значения дат. Перезапустим SmartDataset и повводим значения дат. Перезапустим SD и повводим значения дат. При открытом SmartDataset поменяем форматы дат и времени в приложении и повводим ещё даты. Ни на каком из шагов предыдущий и текущий билды не ругнулись, как описано в баге. Поэтому фикс не получает балл.
* All digits of the second fractions are now visible when a comma is used as a decimal separator.
Все цифры размерности секунд теперь видны, когда запятая используется в качестве десятичного разделителя.
Для работы с вышеописанными данными обычного поля типа Date недостаточно. Нам для теста либо придётся сменить настройки базы (смотри команду "alter session set nls_date_format" в документации Oracle), либо сразу тестить на типе данных timestamp. Воспользуемся таблицей, на которой мы тестировали первый пункт RNs этого билда. Будем менять значения опции "Preferences / General / Decimal separator", которое возможно быть точкой или зяпятой из списка, либо вручную введённым любым иным символом. Тесты показали, что текст фикса неточен. Фактические (истинные) значения секунд с указанной точностью в гриде отображались только при значении разделителя десятичных знаков - точка. При всех иных символах разделителя десятичная часть секунд обнулялась. А вот смена десятичного разделителя при открытом наборе данных как обрезала всю десятичную часть секунд в прошлом билде, так и осталось багом обновления грида. Из-за неточности описания пункт RNs получает только 0.8 балла, а за сопутствующий баг (нет предупреждения о необходимости переоткрытия грида, нет автоматического полного обновления) сниму -0.5.
* The error “Field is not a LOB” no longer occurs on trying to edit and/or insert a record.
Ошибка о не LOB формате поля больше не случается при попытке отредактировать или вставить запись.
Поскольку упомянут тип поля LOB, то для тестирования возьмём или создадим четыре таблицы с типами BLOB, CLOB, NCLOB, BFILE. Не стоит мучать базу и создавать одну таблицу со всеми четырьмя типами, смешивая тесты приложения с возможностями системы. Для ввода и просмотра значений CLOB, NCLOB в SD применяется текстовый редактор, работающий с файловой системой. А для полей BLOB, BFILE имеется так называемый Blob Editor, позволяющий работать с разными типами файлов через их внешние библиотеки. Но для BFILE редактор так до сих пор и не дописан, поэтому не пытайтесь им воспользоваться. Честно говоря, ошибки с полями дат и почему-то LOB у меня воспроизводились на таблице с тремя десятками полей самых простых типов: number (от 1 до 4 разрядов), date, varchar2 (от 10 до 4000 символов). И если ошибки про несоответствующий формат даты мне были понятны, то неожиданные проблемы со вставкой больших текстов в поля, никак не касающиеся LOB, меня сильно смущали. И поскольку мне тогда не довелось выявить причину бага, то и тех.писательница завуалировала фикс, так и не раскрыв исходной ситуации. Мне не известны конкретные условия для воспроизведения бага в предыдущем билде, поэтому не получится проверить фикс. А обычные тесты добавления записей в таблицы с полями типов BLOB, CLOB, NCLOB не показали никакой разницы в работе текущего и предыдущего билдов. Пункт RNs не получает балл.
Table Wizard 0.5+0.3=0.8 из 2 возможных, -0.4 за баги
* An access violation no longer occurs on trying to modifying a table.
Под редактированием таблицы стоит понимать все выражения команды ALTER TABLE. Поскольку у таблицы можно менять очень многое, и на поиск причины бага у вас уйдёт уйма времени, то подскажу один свой вариант и заодно скину минус в карму тех.писательницы, которая в тексте бага не указала, что мастер таблицы раньше не мог обработать ошибку базы про несоответствие типов полей при создании внешнего ключа. Теперь вместо Eureka-лога показывается стандартная ошибка Oracle, если внешний ключ пытаются создать на поля разных типов данных. За такую несогласованную работу составителя RNs и программиста дам только 0.5 балла.
* The “Display Numbers as to Numeric” option no longer causes the error “Object doesn’t exist” on trying to open a table. The “Count records” feature now works correctly too.
Опция отображения числовых как Numeric больше не вызывает ошибку отсутствия объекта при попытке открыть таблицу. Функция подсчёта строк теперь тоже работает корректно.
В наименовании опции опечатка - лишний предлог to. А вот с неописанными правилами, по которым тоже стал работать подсчёт записей, будем разбираться в тестах. Честно говоря, изучая Oracle и продукты ConquestSS с 2002 года никак не могу увязать опцию отображения чисел с отсутствием объекта в базе и подсчётом строк, кроме как возможных проблем на страницах Segment, Data непростых таблиц, например, с LOB-полями или партициями. А на самом деле баг воспроизводился для любой простейшей таблицы, полагаю потому, что на всех страницах в строке состояния отображаются даты создания и последней правки объекта. Этот же баг был актуален для многих других мастеров объекта (вьювер, последовательность). Но из-за неточности описания дам за правку только 0.8 балла.
Как же проверить корректность подсчёта строк, если в предыдущем билде невозможно открыть страницу Data, на которой можно было бы попытаться воспроизвести баг через команду "Dataset / Count records". Даже если сменить опцию отображения чисел уже после благополучного открытия мастера, то никаких некорректных отработок функции узреть невозможно. Поэтому эту часть фикса считаю никчемной припиской, снижающей готовность модуля на полбалла. Если же отвлечься от тестируемых модуля и опции, то правильной работой счётчика строк можно считать исправленное отображение количества более одного символа: в одном из предыдущих билдов об этом говорилось, как об обрезании значения по первому символу. И если это грубое вуалирование тех.писательницей мега-критичного бага, исправленного спустя пару месяцев, то вот вам яркий пример острой надобности грамотного тестировщика в команде разработки. К тому же, исправление не прошло тест интерфейсных стандартов, поскольку цифры количества строк прилеплены к подписи и от этого плохо различимы. Программист забыл вставить один пробел.
 |
Чужой хинт у последующей кнопки (красным)
Дубляж выбранных строк (сиреневым)
|
Scenes 0 из 1 возможного
* If there are no objects in the active scene, active objects of the default scene are shown.
Если в текущей декорации нет объектов, то показываются активные объекты из декорации по-умолчанию.
Когда в пользовательской декорации может не оказаться объектов? Если все объекты удалили из декорации, то нет смысла такую декорацию сохранять, поэтому из декорации средствами интерфейса невозможно удалить все объекты (в ContentSelector всегда должна быть хоть одна закладка, даже не запиненая). Можно лишь удалить саму декорацию. Второй вариант отсутствия объектов в декорации: отсутствие объекта в базе данных или нехватка прав на доступ к нему. Нехватку прав легко воспроизвести на папках несхемных объектов при подключении юзером без админских прав. Также просто воспроизвести вариант удалённого из базы объекта. Так что пройдём простейший тест:
- создадим у себя в схеме любой объект для последующего его удаления;
- запиним его закладку в Object Navigator;
- создадим декорацию с одним этим объектом; включим опцию "Preferences / General / Object Navigator / Restore open scenes";
- выставим активной только одну только что созданную декорацию;
- закроем приложение; в SQL*Plus или sqldeveloper удалим объект из базы;
- запустим SD с подключением к нашей схеме.
В этот раз нельзя использовать собственное приложение на этой же машине, даже других версий, потому что это собьёт его единые настройки. Чтобы сохранить в дефолтную декорацию какие-нибудь неудаляемые и общедоступные для нашего случая закладки, надо включить опцию автоматического сохранения модифицированных декораций на странице "Preferences / General / Object Navigator", запинить нужные закладки и перезапустить SD. К сожалению, между предыдущим и текущим билдами нет никакой разницы - в обоих дефолтная декорация активируется при отсутствии объектов в текущей или при отключении всех юзерских декораций. Так что, этот пункт RNs - только приписка для массивности правок и не получает ни балла.
Одно радует, что в процессе тестов обнаружилась правка в SQL Editor, который не мог быстро и спокойно закрыть окно после выполнения скрипта на создание процедуры, а почему-то ругался "'-' is not a valid integer value.". Но за неописанные правки билд не может получить дополнительные баллы.
Extract DDL 0 из 1 возможного, -0.5 за баг
* Removed unnecessary empty spaces from object DDL.
Убраны ненужные пустоты из скриптов на создание объектов.
Если желаете, то можете для всех шести десятков типов сравнить скрипты. Я же ограничусь таблицами в модулях: Object Navigator, text/SQL Editor (оба типа выгрузки), Object Comparer, Fast Copier, Schema Extractor. Срипты в предыдущем и текущем билдах абсолютно идентичны и всё также состоят из множества излишних пробелов, например, в области описания колонок. То есть фикс - приписка, не дающая билду ни балла. А невозможность выгрузить структуры таблиц через Schema Extractor в обоих билдах снимает с билда -0.5 балла.
Session Navigator 0 из 1 возможного, -0.5 за баг
* Database sessions are no longer duplicated when the RAC Instance filter is set to “ALL”.
Сессии базы больше не дублируются, когда фильтр по кластерам отсутствует.
К сожалению этот фикс никак не получится проверить, потому что данные в модуль не загружаются давно из-за необработанной проблемы с мультибайтовыми символами.
 |
| Заполнение модуля данными из базы невозможно из-за перекодировки в служебном запросе |
Preferences 0.6 из 1 возможного
* Colors set for “Selection” and “Search Match” are no longer mixed up while searching in Preferences.
Установки цветов для выделений и совпадений поиска больше не смешиваются при поиске в установках приложения.
Цвет выделения и совпадения поиска можно выставить для редакторов на странице "Preferences / Code Editors / Color", выбирая их комбинацию из списков Elements и Color. В рамках окна Preferences имеется возможность поиска параметров приложения по их наименованию. Но упомянутые два параметра, фактически являясь значениями, не подпадают в условия поиска по страницам.
Возможно тех.писательница опечаталась и вместо Code Editors указала неверно окно Preferences, в котором цвет найденного значения и выделенного текста сливались. А точнее, в прошлом билде выделенный текст терял своё выделение сразу после нахождения первого искомого значения в области выделенного. В текущем билде выделение текста в редакторе не сбрасывается при срабатывании поиска среди выделенного текста. Для теста откроем любой текстовый файл в SQL Editor или Stored Program Editor, либо наберём разнообразное сочетание символов, выделим часть текста и попробуем поискать любые вхождения в эту выделенную область текста. Мастер поиска по тексту автоматически выставляет параметр Scope = "Selected text" и весь выделенный текст в "Text to Find", так что нам остаётся только вбить искомые символы и убедиться, что выделенный текст не теряет подсветки. Вот так опечатка меняет смысл фикса, запутывает пользователя, отнимает время у него и тестировщика на поиск истины и не позволяет мне дать за него полноценный балл.
Main Window 0 из 1 возможного, -1 за баги
* Fixed the correspondence between the topmost windows and active taskbar buttons.
Исправлена взаимосвязь между самыми верхними окнами и активными кнопками строки задач.
Рабочее пространство SD очень похоже на рабочий стол OS Windows: модули разбиты на окна, открытые окна имеют кнопки на строке задач, кнопки которых синхронно активируются с корреспондирующим окном. А поскольку некоторые окна имеют свойство показа поверх всех (Object List, Fast Copier), некоторые являясь модальными не имеют кнопок на таскбаре (Preferences, Code Analyzer Options), некоторые являясь внешними библиотеками могут работать вне рабочего пространства приложения и иметь (Report Generator, PL/SQL Profiler) или нет (Repository Installer) кнопки на таскбаре приложения, то тесты будем проводить при сочетании открытых, свёрнутых и максимизированных окон из всех вышеперечисленных групп в сочетании со всеми другими обычными и единственным не закрывающимся никогда - Object Navigator. Для полноценности теста лучше подключить какую-нибудь базу, потому что некоторые окна без сессии невозможно открыть. Первым шагом откроем все возможные окна в режиме максимизации через главное меню, покликаем по их кнопкам на таскбаре и поочерёдно активируем окна через новообразовавшиеся пункты в конце списка главного меню Window. Второй шаг теста - открыть все теже окна, но не в максимизированном виде (для удобства видимости всех можно выстроить все окна каскадом "Window / Stack"), и покликать в двух направлениях - по кнопкам на таскбаре и по заголовкам окон. В обоих случаях примечаем смену подсветки окна и его кнопки. Третий шаг теста - включаем/выключаем опции "Preferences / General / Task Bar / Combine buttons" и "Preferences / General / Task Bar / Display captions", открываем 5-10 окон SQL Editor (при выключенной опции "Preferences / Code Editors / SQL Editor / Allow only one SQL Editor window"), открываем 5-10 окон Stored Prgram Editor, открываем 5-10 окон SmartDataset (при включенной опции "Preferences / Dataset Editors / Smart Dataset / Open separate window for each object") и ещё каких-нибудь окон для переполнения таскбара (появится чёрная двойная стрелка у правого края). Опять кликаем по заголовкам окон и их кнопкам на таскбаре и сравниваем поведение в текущем и предыдущем билдах. Все тесты только на визуальное восприятие. А возможность открыть все окна - это часть смоук-теста билда. Во время теста вы легко можете заметить, что операции открытия и закрытия над некоторыми окнами путают действия (Server Side Installation), не отображаются (Object Wizard, Online Help, Update License) в логе Output Window, что вполне может быть причиной проблем при переключении между окнами. А активация самого окна Output Window различима лишь по её кнопке на таскбаре. Также тест открытия всех окон позволяет легко заметить неудобство статусов и начальных позиций некоторых окон, которые своим присутствием могут не только перекрыть рабочую область других, но и не позволяют добраться мышкой до сообщений об ошибках. Например, за уже открытым центрированным Fast Copier прячутся также центрированные ошибки при открытии Session Navigator и Top Session Locator о мультибайтовых символах. Поведение упомянутого интерфейса ничем не отличается в предыдущем и текущем билдах. Этим пунктом RNs ещё раз приходится подметить проблемы интерфейса:
1) через своё контекстное меню закрывает не то окно, что под курсором из числа внешних библиотек, а фактически активное, да и контекстное меню можно вызвать не только в области кнопок, но и на любом пространстве таскбара;
2) таскбар так и не обзавёлся прокруткой, потому активные окна из числа невидимых кнопок труднодоступны;
3) списки открытых окон в таскбаре и главном меню Window совпадают, но не учитывают некоторые внешние библиотеки (Online Help, Server Side Installation), поэтому к ним бывает затруднён доступ, но их окна могут перекрывать сообщения об ошибках;
4) казалось бы закрытые перед окончанием работы SD окна (Oracle Database Browser, Code Assistant) могут автоматически неожиданно открыться при следующем запуске приложения.
Так что, фикса нет и баллов нет. А за старые баги сниму в общей сложности -1 балл.
Итого билд получает 2.5 балла из 15 возможных, что равняется 2.5/15=16% готовности, и ещё сплоховали на -4 балла из-за привлечения внимания к багам.
Комментариев нет:
Отправить комментарий