Ошибка в проверке наличия элемента

Скриншоты ниже...

Опишите ошибку Проверка наличия элемента не работает: параметр не заполняется результатами проверки.

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

Screenshots

Дополнительно Если переписать получение имени параметра из структуры параметров, то проверка "Элемент существует" работает как ожидается. ИмяПараметра = мПараметры.ИмяПараметра; ВозможноОшибка

Спасибо. Проблему увидели. Постараемся в ближайшее время поправить.

Ошибку исправили. Последний релиз менеджера "2019.08.06"

@ivanov660 Спасибо. Обновлять релиз пока не буду, те же самые исправления я уже сделал в текущей версии. Вопрос не по теме: вы говорили, что возможно в ближайшее время появится документация по фреймворку. С одной стороны с каждым днем документация вроде бы нужна все меньше, т.к. получается разобраться отладкой или с помощью ваших консультаций тут, либо даже просто "методом тыка", а с другой стороны такое изучение продукта как минимум очень затратное по времени и, возможно, мы все равно пользуемся им неправильно, не так как задумывалось. Мы накопили уже некоторое количество тестов по одной конфигурации и планируем начинать покрывать тестами вторую, пока не торопимся как раз из-за опасений, что что-то делаем неправильно. Подскажите, пожалуйста, можно ли ориентироваться на какие-то сроки по появлению документации?

@uramalyutin

В планах стоит обновление документации, структурирование уже имеющейся информации и добавление новой (часть работ будем выполнять в середине-конце августа этого года).
Из вашего сообщения следует, что объем, качество явно не достаточен или не адекватен решаемым задачам задачам.
Можете привести примеры с Вашей точки зрения: чего именно не хватает, какие пробелы существуют, либо Вы столкнулись и решили, а здорово было бы узнать и расширить. Это могут быть организационные вопросы, логические, алгоритмические.
От вас приходит достаточно хорошая обратная связь, поэтому мы готовы на основании Ваших замечаний попробовать устранить существующие пробелы.

Ну у меня несколько вопросов, на самом деле. Повторюсь, все вопросы вызваны незнанием и опасением, что мы делаем что-то неправильно или неоптимальным способом. Хочется научиться сразу правильно пользоваться, а не переучиваться в последствии (возможно еще и тесты придется переделывать). Повествование получилось несколько сумбурное =)

По менеджеру сценарного теста. Оказывается, чтобы была доступна отмена изменений, нужно включить опцию «Использовать сохранение дерева». А на что еще влияет эта опция? Я не знаю рекомендовать ее включать или нет. 01_Отмена изменений 02_Использовать сохранение дерева

По некоторым настройкам еще как-то можно интуитивно понять для чего они, но вот что за режим агента вообще непонятно, следовательно, и не понятно для чего эта настройка и как ее использовать. 03_Настройки редактора 04_Режим агента

Было бы хорошо, если бы на форме были подсказки по настройкам, например, как в типовых.

Далее: 05_Команды «Код клиент» - мне сейчас понятно где можно «подсмотреть» какие методы я там могу использовать, но хотелось бы тоже описания возможностей, это легче, чем искать в коде обработки. «Код сервер» - непонятная для меня команда. Насколько я знаю, мы не можем выполнять код на сервере в тестируемой базе. Значит этот код будет выполняться на сервере менеджера тестирования (TestingTool). Но как тогда и для чего мы можем использовать эту команду? «Тестовый случай» - тоже не разобрался еще. Предполагаю, что эта команда используется для группировки шагов в сценарии. А вдруг нет? Поскольку я еще не знаю точно что делает эта команда, я рекомендовал для группировки шагов использовать команду Комментарий. Получается как-то так (сценарий, активирующий пользователей для тестирования, в рабочей базе они отключены): 06_Комментарии

Вопросы по методологии. Сейчас мы во всех сценариях делаем параметры и указываем какие-то значения для них. Вот пример для этого же теста (служебные пользователи для тестирования ЗУП): 07_Параметры сценария Пример не очень удачный, т.к. пользователи не меняются и именно их всегда и нужно активировать, картинка вставлена просто для иллюстрации.

Поскольку значения параметров сохраняются вместе с тестом, то для того чтобы их изменить и выполнить проверку на других данных, нужно изменять тест. Понятно, что этот подход неправильный. А как правильно сделать я еще тоже не разобрался. И вот вроде бы вижу в конфигурации есть решение для этого, но, боюсь, мне нужна инструкция, так не разберусь. 08_DDT

Еще такой вопрос: можно ли сделать несколько заданий-проверок для одной базы? Предположим, у меня были доработки в функционале подбора персонала, было бы удобно запустить проверку только по этому блоку и не дожидаться выполнения тестов по блокам, которые не изменялись. Или это неправильный подход?

Как можно разделить тесты по разным репозиториям? Насколько я понял, если я хочу использовать одну базу TestingTool, то все тесты должны быть в одном репозитории. Но предполагается тестировать разные конфигурации, да и тесты делают разные люди. Пока опыта мало, они могут мешать друг другу.

По объектам конфигурации тоже вопросы есть, еще даже не разбирался, если честно. Например, как использовать все это? 09_Метаданные1

Есть подсистемы, в них есть какие-то объекты, но вообще не ясно как ими пользоваться. Предположу, что этот функционал еще не реализован, из-за этого также нет шаблонов для заданий. 10_Метаданные2

Пока для меня в приоритете хоть какое-то ощутимое покрытие сценарными тестами двух конфигураций (ЗУП и УТ), поэтому с объектами этих подсистемам я даже не пытался разбираться и поэтому не буду пока накидывать вопросов, тем более, что, возможно, в вашей документации уже будут ответы. Еще есть довольно большая область - коллективная работа с использованием GIT. Тут вроде разобрались, выработали какие-то правила для себя, но было бы интересно посмотреть "а как у других?" и перенять опыт.

P.S. все написанное фактически не относится к этому запросу (ошибка в проверке наличия элемента), поэтому можно этот запрос закрыть, а общение перенести в другой, возможно кому-то тоже окажется интересно увидеть ответы на эти вопросы.

@uramalyutin Хорошие замечания. В целом:

Мы добавляем в каждом релизе немного функционала, а потом, если он не "поехал" мы его убираем - т.е. что-то вроде экспериментов. Это не должно влиять на стабильный существующий функционал.
Инструмент живет и методология его прикладного применения может усовершенствоваться. К чему-то мы приходим по результатам опытного применения, учимся на своих и чужих ошибках. Это нормальный процесс.
Нам понятно, что не хватает структурированности. В ближайшее время появится небольшое завершенное руководство (по примеру 1С "Сценарное тестирование описание"), мы продолжаем работу над ним. Думаю оно как раз закроет основные вопросы и добавит необходимую связь между всеми частями функционала).

Ответы по функционалу:

Функционал отмены действий - это экспериментальный функционал. Сейчас одна из основных его проблем - это низкое быстродействие при больших объемах сценария (нужна оптимизация)
Исключать команду "focus" - функционал для работы с записью действий для веб-браузера. Фильтрует события из сценария focus. Исключать xPath - функционал для работы с записью действий для веб браузера. По результату работы с веб-приложениями 1С, мы поняли, что это поле практически бессмысленно, а вот для других веб вполне оправдано. Исключать поиск форм - функционал для работы с 1С. Если установить этот флаг, то значительно уменьшается объем сценария, т.к. для поиска подчиненных элементов вполне достаточно нахождения окна (появился относительно недавно).
Режим работы агента - это экспериментальный функционал для работы в режиме smok теста ("интеллектуальное тестирование") и для выполнения нагрузочного тестирования. Пока в разработке и настройке. Идея по подсказкам хорошая тема, добавим #60.
"Код сервер" - выполняется на сервере. Одно из применений может быть, если вы запускаете менеджер тестирования в той конфигурации на которой тестируете, тогда выполняя запросы, имея объектную модель и т.п. вы сможете менять или получать данные в процессе теста (подобная идея в конфигурации от 1С Сценарное тестирование). К примеру, создали документ сценарным тестом и выполнили проверку заполнения ТЧ (мы обычно делаем такую проверку через unit тесты)
"Тестовый случай" - экспериментальный функционал, была мысль выделять в тестовые случаи в сценарии для отчета Allure (по умолчанию всегда один тестовый случай). Думаю, что этот функционал мы отключим (не поехал). Для функционала сценария эквивалентен действию "комментарий".

Ответы по методике:

Упрощение подобной работы стоит в рамках задачи #48 (Создание в базе тестирования информации о пользователях и передача их в сценарий). Сейчас мы обходим эту ситуацию следующим образом: а) Создаем пустой сценарий в библиотеке (к примеру, "настройки пользователей") и заполняем в нем только параметры (пользователей) и ставим для них флаг затирать значения родителей б) В полном сценарии в самом начале добавляем загрузку из библиотеки файла "настройки пользователей" в) Далее добавляем остальные шаги.
Использование в качестве функционала "DDT" для решения проблемы пользователей это небольшой фейк). DDT (data driven test) - тестирование управляемое данными. Это новый функционал. Мы его сейчас используем для проверки открытия форм. - испытания прошел. DDT - можно использовать для выполнения проверки открытия форм (сейчас я готовлю статью с примерами на infostart), или посмотрите пример на сайте testingtool.ru
Можно сделать несколько проверок для одной базы, главное чтобы они не пересекались. Но если исходить из методологии, то так делать нехорошо. Т.е. маленькое изменение в како-то неважном блоке может завалить всю базу - поэтому вопрос принятия рисков на Вас. Я бы делал так, на базе разработчика запустил маленький тест, а уже на базе сборки отработал целиком.
Разделение по репозиториям. а) В базе Тестирвоание 3.0 можете разделить тесты по папкам, задания разбейте на паки или присвойте им разные группы. б) В самом гите мы разбивали на папки корневые (ЕРП, Портал и т.п.), а библиотека по функционалу (Продажи, Отгрузка, Портал и т.п.)- сейчас мы так работаем. Вот тут описывал идею Структура GIT хранилища тестов ИЛИ Можете создать набор репозиториев и объединить их в один общий репозиторий. Это сложнее (вроде как-то в этом ключе работает 1С при разработке и сборке ЕРП - но они очень большие).
В большинстве своем это вспомогательные регистры и лезть в них не должно быть необходимости (технические). Все задачи по нашим планам должны выполняться через АРМ.
Сейчас пользователям доступны подсистемы "Планировщик", "Тестирование". Остальные находятся в экспериментальном режиме (пока есть некоторые сложности для пользователей, которые мешают простому использованию). "Игровое моделирование" - данная система предназначена для упрощения создания тестов, т.е. использование искусственного интеллекта. Кратко идея в том, что вы грубо говоря создаете только маленькие кусочки библиотеки тестов, а далее создавая связи между блоками ИИ получаются динамические сценарии (если интересно посмотрите мое промо выступление на конференции QADays). "Нагрузочное тестирование" - выполнение нагрузочных тестов (если интересно посмотрите мое промо выступление на конференции QADays).
Коллективная работа с GIT. Могу отдельно рассказать про наш опыт.

Спасибо за развернутый ответ.

По функционалу все понятно. Еще одно предложение: каким-то образом помечать экспериментальный функционал, чтобы было понятно, что этот функционал может быть существенно изменен или пропасть в следующих релизах. Чтобы не возникло ситуации, что добавленные в сценарии шаги, например "Тестовые случаи", больше не будут корректно обрабатываться Менеджером сценарных тестов и тесты окажутся неработоспособными из-за этого.

По методике тоже понятно, буду ждать пример работы с DDT. В качестве ремарки немного поясню про Пользователей. Мы для тестирования решили не использовать реальных пользователей, а создали служебных и настроили им соответствующие права, под которыми будут работать тесты. Но этих служебных пользователе в рабочей базе мы, естественно, не включаем. Включать их вручную каждый раз в тестовой базе желания нет, поэтому родился тест, который проверяет включены ли тестовые пользователи и если не включены, включает этих пользователей (наверное для этого больше бы подошли unit-тесты, но их я еще не освоил). А для запуска сценариев под разными пользователями мы как раз пользуемся вашим методом, который достаточно подробно разобран в видео-уроках. Как я и писал, скриншоты этого теста я вставил для иллюстрации такой ситуации, когда фактически одни и те же блоки шагов выполняются несколько раз, только каждый раз с новыми параметрами. К сожалению тест, в котором это реально нужно, мне не доступен (остался в чужом репозитории). Смысл того теста заключается в том, что нужно проверить разные варианты начисления для разных людей: для одного только оклад, для другого оклад+премия, для третьего еще северная надбавка. Сейчас фактически это пытаются реализовать последовательно выполняя одни и те же блоки шагов с передачей разных параметров, проверкой результата и вызовом исключения, если условие проверки не выполняется. Вот для этого, мне кажется, и нужно использовать DDT. А вот с вашим опытом коллективной работы с использованием GIT с удовольствием бы ознакомился.

@uramalyutin

По вопросу скрытия лишних кнопок хорошая идея, мы ее реализуем в задаче #57
Как используются DDT тесты пример DDT калькулятор
Да, для случая проверки расчетов зарплаты необходимо использовать DDT тест.
Решение в принципе нормальное для включения пользователей. И даже у него есть свои плюсы в отличии от программного.
По опыту использования GIT попробую написать, но позже, скину вам ссылку (пока некогда готовлю доклад для конференции на инфостарте).

ivanov660 / TestingTool-3

Ошибка в проверке наличия элемента #58