С чего начать внедрение автотестов

Публикация № 1661264 18.05.22

Приемы и методы разработки - Тестирование QA

На митапе «Путь к идеальному коду» выступил программист 1С Алексей Степаненко. Алексей рассказал о важности автоматического регрессионного тестирования и предложил инструмент, реализующий методику «Тестирование черного ящика», с внедрения которого легче всего начать внедрение автотестов.

 

 

Немного о себе:

  • Я программист уже 28 лет, начал программировать еще в школе.

  • В 1С – с 2000 года.

  • В последние 5 лет я, помимо разработки, занимаюсь проектированием и проверкой архитектуры систем на 1С.

  • Мой опыт в руководстве командами – 10 лет.

  • Последние 3 года я активно применяю автотестирование – это связано со стремлением повысить качество кода в разработке, где тестирование является одним из краеугольных камней.

В начале доклада я провел опрос, чтобы выяснить, работает ли уже кто-то из участников митапа с автотестированием:

  • тем, кто не использует тестирование (среди слушателей митапа таких 17%) – это доклад для вас, слушайте внимательно, вам будет очень полезно;

  • тем, кто уже внедряет тестирование или понимает, что это необходимо, будет интересна практическая реализация подходов;

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

 

 

В ходе доклада мы обсудим следующие темы:

  • Я расскажу о том, почему ручное тестирование не работает, и почему утверждение, что ручным тестированием мы обеспечиваем качество – миф.

  • Поговорим про методику тестирования «Черный ящик»

  • Покажу практическую реализацию этого подхода.

 

Почему ручное тестирование не работает?

 

Разберемся на практике, как могут возникать ошибки при разработке, и почему надеяться на ручное тестирование – не вариант.

 

Задача №1: Сделать учет заказов покупателей

Типовая задача: у нас есть организация, которая использует у себя в качестве управленческой системы «Бухгалтерию предприятия». Там нет учета заказов покупателей, и программистам поручают эту функцию «прикрутить».

Задачу берет программист Миша, который очень качественно разрабатывает и следует стандартам разработки.

Он понимает, что «Заказ покупателя» в рамках терминологии «Бухгалтерии» – это «Счет на оплату», документ, который проводится, но не делает никаких движений.

 

 

Для Миши все просто – он создает регистр накопления «наш_ЗаказанныеТовары».

 

 

Чтобы не курочить основную конфигурацию, он создает подписку на событие «наш_ПроведениеДокументов», куда включает все необходимые документы.

 

 

Для размещения обработчика подписки он создает общий модуль «наш_ОбработкаПроведенияДокументов».

 

 

В этот общий модуль он добавляет процедуру «наш_ПроведениеДокументовОбработкаПроведения», реализующую вход в обработку проведения.

Процедура сделана качественно, вплоть до того, что он сделал защиту – если кто-то включит в подписку не тот документ, мы это увидим по журналу регистрации.

 

 

Вот так выглядит процедура «ОбработкаПроведения»: выборка данных, запись в соответствующий регистр.

 

 

Чтобы уменьшить количество записей в регистре, Миша в запросе делает дополнительную группировку по номенклатуре.

 

 

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

 

 

Бинго, задача выполнена на отлично!

 

Задача №2. Статистика заказанных товаров

Через какое-то время появляется другая задача. Кто-то из менеджеров хочет видеть статистику по заказанным товарам без учета отгрузок – нужно знать, как часто на товар приходят заказы. Эта задача попадает Маше.

Маша у нас тоже очень качественный разработчик, она владеет терминологией, понимает, что такое OLTP-нагрузка, OLAP-нагрузка. Она понимает: раз это статистика, оперативные данные не нужны, здесь классическая OLAP-нагрузка.

 

 

Маша не хочет обращаться напрямую к регистрам, которые участвуют в транзакционной нагрузке. Поэтому она разрабатывает свой регистр накопления «наш_НоменклатураПоЗаказам»: периодический и независимый, в котором статистика по заказам собирается за каждый день.

 

 

Заполняться этот регистр будет по регламентному заданию «наш_РассчитатьСтатистикуЗаказовЗаТекущийДень», которое должно отрабатывать раз в сутки.

 

 

Обработчик регламентного задания находится в отдельном модуле «наш_СтатистикаЗаказов».

 

 

Вот так выглядит процедура загрузки данных. Ничего сложного нет, Маша качественный разработчик, и тоже ставит защиту: если записи не произойдет, в журнал регистрации упадет нужное ей событие.

 

 

Так как Маша проанализировала, как заполняется нужный ей регистр, она видит, что там уже происходит предварительная группировка, и решает выбирать данные не через виртуальную таблицу оборотов, а напрямую из таблицы движений. Этим она хочет добиться оптимизации – не создавать вложенный запрос, а обращаться к реальной таблице.

 

 

Она проверяет результаты: сверху показано, как выглядят исходные данные в регистре «наш_ЗаказанныеТовары», снизу – как данные заполняются в ее регистре «наш_НоменклатураПоЗаказам».

 

 

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

 

Задача №3: Доработать учет заказов покупателей в разрезе аналитик

 

Через какое-то время поступает новая задача: доработать учет заказов покупателей и добавить туда разрез аналитики. Эта задача попадает Мише.

 

 

Миша открывает регистр, добавляет туда новую аналитику.

 

 

Добавляет соответствующее поле в сам документ.

 

 

Чтобы не получить проблем при обновлениях, доработку формы он делает кодом.

 

 

А в первоначальную процедуру, которая срабатывает в подписке на событие «Обработка проведения», он добавляет заполнение поля «Аналитика».

 

 

Аналитика выбирается из табличной части, и по ней делается дополнительная группировка.

 

 

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

 

 

Все отлично, задача выполнена.

 

Задача №4: Ошибка со статистикой

 

 

Через какое-то время Маша получает сообщение о том, что со статистикой что-то не так.

 

 

Маша обнаруживает, что, действительно, за какие-то дни статистика посчитана некорректно. Она проверяет журнал регистрации и находит в нем сообщения об ошибке записи в ее регистр.

 

 

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

 

 

Она находит, что ошибка возникла из-за этого запроса, потому что в текущей ситуации, после того, как прошли изменения, этот запрос уже не работает.

Маша исправила запрос, пересчитала статистику, и проблема ушла.

Этим примером я хотел показать, что даже если мы разрабатываем по стандартам, занимаемся оптимизацией, ратуем за качество кода – мы не защищены от ситуации, когда в бизнес-логике возникает ошибка. С точки зрения качества кода все отлично, но не работает.

Возникает риторический вопрос.

 

Что важнее: «чистый код» или правильно работающая программа?

Все мы прекрасно знаем ответ на этот вопрос.

 

 

Выдам цитату Роберта Мартина из «Идеального программиста»:

Не забывайте – они [Заказчики] платят нам за создание программ, которые делают именно то, что им нужно

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

Что нам делать в ситуации, когда мы выдаем качественный код, но ошибки все равно возникают?

Ведь во всех вышеперечисленных случаях наши разработчики всегда тестировали разработку перед тем, как выкатить ее клиенту.

Самое интересное, что ответ на этот вопрос был дан еще в 1975 году.

 

 

Об этом говорил Фредерик Брукс.

Фундаментальная проблема при сопровождении программ состоит в том, что исправление одной ошибки с большой вероятностью (20-50%) влечет появление новой. Поэтому весь процесс идет по принципу «два шага вперед, шаг назад».

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

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

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

Единственный выход, как говорит Брукс – проводить тестирование, причем тестировать не только ту функциональность, которую мы разработали, а всю функциональность.

Соответственно, с каждым новым изменением объем ручного тестирования будет расти. Это будет дорого.

 

 

Если ручное регрессионное тестирование – это дорого, нам нужно уменьшить его стоимость. Сделать это можно через автоматизацию.

 

Методика «тестирование черного ящика»

 

Эта методика существует в теории тестирования давно.

 

 

Идея заключается в том, что:

  • у нас есть доработанная конфигурация;

  • документации на нее нет;

  • конфигурацию нужно изменять;

  • себестоимость изменения должна быть минимальной;

  • времени на написание классических сценарных текстов у нас нет.

 

 

Методика говорит, что черный ящик – это и есть наша конфигурация.

Мы не знаем, как она работает, но мы знаем:

  • входную информацию;

  • и знаем, какой должна быть выходная информация.

На основе сравнения реальной выходной информации с тем, какой эта выходная информация должна быть, мы делаем вывод: система работает верно или неверно.

 

 

Как мы трансформируем эту методику, когда хотим проверить нашу конфигурацию?

У нас есть две копии информационной базы – до изменения и после изменения (после внесения новой функциональности).

Мы проводим одни и те же действия в обеих базах и получаем результаты

После этого мы в этих результатах ищем различия.

  • Ожидаемый результат – это когда различий нет или различия есть, но это произошло из-за изменения функциональности.

  • Неожиданные различия свидетельствуют о том, что есть ошибка.

Эта методика не приводит к точной идентификации ошибки. Она приводит к промежуточному результату: мы видим информацию, которую следует проанализировать и сделать выводы.

 

Практическая реализация

 

Тестировать по этой методике можно информацию, которая оставляет артефакты в системе.

 

 

Допустим, мы проверяем движение документов.

  • Действием является перепроведение документов за период.

  • Результат – движения документа в виде текстового файла.

  • Инструмент – наша обработка.

  • Сравнение можно выполнять любыми инструментами сравнения, но на первом этапе я рекомендую использовать для этой цели программу WinMerge. Это open-source-инструмент, который очень быстро ищет различия в файлах.

 

 

Давайте посмотрим, как делать перепроведение.

  • Перепроведение мы выполняем по данным основной таблицы движений.

  • Обязательно указываем период, за который перепроводим документы. Можно встретить рекомендации перепровести 5-10-15 документов для выявления ошибок, но я рекомендую не останавливаться на количестве перепроводимых документов, а выбрать период, за который будем перепроводить. В ситуации, когда мы не знаем, как работает система, мы не можем определить минимальное количество данных, которое нам нужно для тестирования. Чтобы добавить определенности, мы выбираем период.

  • Период выбирается так, чтобы в него попали все операции, которые осуществляются в нашей базе.

    • для БП – это квартал;

    • для ЗУП – месяц, все зависит от количества людей, по которым производится расчет;

    • для финансовых систем это может быть год, а может быть и три – все зависит от того, какие у нас бюджеты, и на какой период они заключаются.

  • Для оптимизации все ссылочные типы в запросе показываем в виде представления.

  • Делаем сортировку по моменту времени.

  • Используем выборку запросов, а не выгрузку в таблицу значений.

  • Перепроведение делаем в транзакции.

  • Для записи лога используем объект ЗаписьТекста.

 

 

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

 

 

Вот так может выглядеть код для перепроведения документов. Главное здесь: если документ не перепровелся – нас это не должно смущать. Возможно, он и не проведется в базе после изменения, главное, чтобы в обеих базах – до и после изменений – лог-файл был одинаковым.

 

 

Как мы получаем результат – выгрузку движений?

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

  • Определяем период, за который выгружаем.

  • Остальное – все то же самое, что и в запросе по документам для проведения: представление для ссылочных типов, сортировка по моменту времени, выборка запроса, а не выгрузка.

  • Для лога используется объект ЗаписьТекста.

 

 

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

 

 

Вот так может выглядеть кусок кода для выгрузки движений.

 

Готовая обработка для выгрузки движений регистров по методике «Тестирование черного ящика»

 

 

Такая обработка для выгрузки движений регистров в текстовые файлы уже существует – ее исходники в формате конфигуратора у меня опубликованы в репозитории на ГитХабе. В качестве первоначального варианта вам подойдет.

  • В ней есть вся обвязка по получению параметров запроса &ПериодНачало и &ПериодОкончание.

  • Реализовано так, что проведение документов производится на сервере, а потом результаты передаются на клиент и записываются в каталог выгрузки в клиентской процедуре.

  • Для гибкости сделано, что на каждый из регистров, которые проверяем, пользователь может создать два запроса – отдельно на выборку регистраторов и на выборку движений.

  • К тексту самих запросов есть определенные требования, они подробно описаны в документации, которая тоже выложена в репозитории.

Эту обработку можно забирать и использовать.

 

Применимость методики «черного ящика»

 

По методике «черного ящика» я тестировал не только проведение, но и заполнение документов. Правда, в этом случае вы должны уметь работать с Vanessa Automation, потому что в этом случае используются свои шаги по обработке заполнения и определенным образом построенные feature-файлы. Там смысл в том, что мы получаем табличную часть документа до заполнения, после чего заполняем ее, используя команду в интерфейсе, получаем два разных файла: до заполнения и после. И потом сравниваем эти файлы с эталонными данными.

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

По этой методике мы можем получить «быстрые» тесты. Это не значит, что мы получим тесты, которые быстро выполняются – выполняться они могут как раз-таки очень долго, но для получения таких текстов никаких особых усилий не требуется.

А уже потом мы поймем, какие проверки нам нужно ускорять и переводить на сценарные тесты – будем потихоньку уходить в этих проверках от методики «черного ящика».

 

Вопросы

 

Есть вопросы к Машиному коду.

Сразу хочу сказать, что я выбрал тот пример, в котором мы сразу можем увидеть проблематику. Конечно, можно придраться, сказать, что Маша – нехороший программист. Я к тому, что бывают такие заковырки, что мы очень быстро не найдем эту проблему. Ведь мы не можем заранее знать, как система будет изменяться. И требования к коду могут поменяться. Если бы Маша эту задачу разрабатывала после того, как Миша второй раз внес изменения, то, конечно же, она пошла бы по другому пути. Но заранее мы это не можем спрогнозировать, потому что мы оцениваем задачу «здесь и сейчас». В этом – основной посыл, что на момент написания это был качественный код, но по прошествии какого-то времени он уже становится некачественным даже без внесения туда изменений.

Вы как-то снимаете покрытие кода?

Нет, покрытие кода – очень интересная задача, но нет, не снимаем.

Печатные формы как-то тестируете?

По этой методике – нет. А вообще Vanessa Automation прекрасно тестирует печатные формы – и документов, и отчетов.

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

Мой опыт показывает, что декларативно с помощью какого-то кнута это не зайдет. Ни качество кода, ни автотесты. Это нужно уметь продать разработчикам. Продавать будете долго, но, если это у вас получится сделать, разработчики будут это использовать. Если вы сами поняли, что вам нужны автотесты, начните их писать, начните покрывать свой код, будьте лидером в этом направлении. Через какое-то время, когда вы этими тестами выловите какую-то ошибку в своем или в чужом коде, только после конкретных кейсов, когда это пригодилось, разработчики к этому тоже потянутся. Не факт, что им зайдет сценарное тестирование – это все-таки отдельная холиварная тема. Но юнит-тестирование может очень хорошо зайти, плюс вы убьете двух зайцев. У вас будет тест, и у вас улучшится качество кода, потому что юнит-тестирование накладывает определенные требования к структуре кода. И если юнит-тестирование разработчикам зайдет (а как правило, заходит), то и код у вас будет более структурированный даже без внедрения SonarQube, АПК и всего остального.

Какая в итоге база берется для тестирования – выгрузка рабочей на текущий момент? Или как-то отдельно подготавливается?

У нас берется выгрузка рабочей. Да, мы нарушаем best practice в тестировании, мы берем именно рабочую базу, потому что мы не знаем, как она работает, и не знаем, какой минимальный набор тестовых данных нам нужен для проведения тестирования. Поэтому берется рабочая. Почему я и говорю, что это – первые тесты, которые вы уже можете сейчас запустить. Но в дальнейшем вы будете избавляться от этих тестов, вам нужно будет часть функциональности уже переводить на юнит-тестирование или на сценарные тесты. Таким образом, редактируя запросы по выборке документов для перепроведения, в какой-то момент (через год или через два) вы поймете, что вам документы уже не нужно выбирать, вы их уже покрыли какими-то другими тестами. Поэтому через какое-то время уже не нужна будет полная копия рабочей базы.

Если Маша завернула свою статистику в отчете, разве такой случай можно покрыть тестами?

У этой методики есть свои ограничения, по этой методике мы тестируем именно артефакты. То, что у нас в базе появляется. Это не волшебная палочка, часть функциональности мы все равно проверить не сможем. Но могу привести практический пример – по этой методике внедрили тестирование в конфигурации «Проверка начислений ЖКХ», и вначале это тестирование шло 8-10 часов, но с разрастанием кодовой базы, с внесением изменений у нас эти тесты стали проходить несколько суток. Но разработчики к этому моменту уже поняли плюсы этого тестирования, что действительно очень много ошибок – неявных, они этой методикой вылавливаются. Поэтому через какое-то время разработчики бизнес-задач пошли навстречу и внедрили параллельное проведение документов с точки зрения основной функциональности программы. И время выполнения тестов опять спустилось с неприемлемых трех суток до приемлемых нескольких часов. Это тоже большой плюс.

Представленный подход – это попытка сделать регрессионное тестирование самым быстрым доступным способом?

Да, мы сразу же выбираем ту функциональность, которая не должна упасть на все 146%, потому что всю конфигурацию проверять очень долго. Здесь мы берем именно то, что вообще никогда не должно упасть и проверяем только это. Но да, это действительно регресс.

Тут в любом случае есть побочный эффект, и сложно будет не зависеть от данных. Если есть ошибки в данных, и из-за этого тесты падают, то тут беда.

Да, но у нас же есть две копии базы. У нас эти ошибки появятся как в первой, так и во второй базе. И мы их увидим. Главное, чтобы эти ошибки совпали. Допустим, два документа не провелись из-за того, что ошибки в данных. Но если ошибка одинаковая – да и ладно. Мы же проверяем не только движение документов, но и логику перепроведения. Главное, чтобы все это совпадало. А если в одной базе документ провелся, а в другой – нет, то наверняка это ошибка, потому что набор из начальных данных – одинаковый.

Мне такой подход знаком по обработке «Сценарное тестирование» от фирмы «1С». У них даже есть шаг «Сверить с эталоном».

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

Кто-то проводил реверс-инжиниринг кода, сколько тестов нам нужно, чтобы покрыть этот код, просчитать все сценарии, которые заложены в коде? У меня был такой опыт, я неделю проводил такой анализ. Я плюнул, когда количество тестовых сценариев у меня получилось около 50. Причем я еще не до конца дошел.

Это большой больной вопрос, особенно с учетом всех функциональных опций. И вообще вопрос глобальный – нужно ли тестировать типовой код и в каком объеме.

Согласен, но это более философский вопрос – нужно ли нам все тестировать, когда у нас и так все хорошо работает. В реальности для наших клиентов, они же не разделяют – это типовой код или это наш код. Это, в принципе, программа. И даже если ошибка в типовом коде – это не значит, что мы не должны ее исправлять. Тут все зависит от рисков, которые несет бизнес при возникновении этой ошибки. Если это допустимый риск, то, наверное, тестировать не нужно. Если не допустимый – даже если типовой код, надо писать тесты.

Есть мнение, что тесты на типовой код должны поставляться фирмой «1С». Отчасти так и есть, сейчас с УНФ поставляются сценарии тестирования. Раньше команда «Бухгалтерии предприятия» поставляла тесты для «Сценарного тестирования». Факт в том, что нужно уметь эти тесты запустить – для этого нужна инфраструктура. Сам процесс тестирования длительный. И набор поставляемых тестов не покрывает все сценарии на 100% с учетом всех функциональных опций. У нас пока еще типовые конфигурации не адаптированы под тестирование глобально. Движение в эту сторону только еще начинается.

Хорошо, что оно началось. Есть термин «В мире большого программирования» – я всегда смеюсь, когда его слышу. Если смотреть open-source-решения на GitHub – как правило, там в требованиях к контрибьютеру написано, что вы должны писать тесты на свой код. И это нормально. У других программистов даже не возникает мысли о том, что можно написать код и не покрыть его юнит-тестами своими собственными. Но почему-то в мире 1С к теме автотестирования такой скептический настрой.

В оправдание мира 1С могу сказать, что в отличие от остального мира программирования у нас очень сложно написать быстрые модульные тесты, которые за секунды выполняются. Даже если параллелить потоки, у нас 10 секунд на один тест, а в других фреймворках – 10 секунд на все тестирование. Многих отталкивает то, что результат тестирования нельзя увидеть сразу. Особенно, если нужно прогнать большое количество тестов.

Да, это большая холиварная тема. Из-за того, что система получается очень сложно-связная, невозможно понять, какое количество тестов нужно запустить, чтобы проверить ту функциональность, которую я поменял. Мы этого заранее не знаем.

В тему запуска тестов – на хабре недавно опубликовали перевод письма бывшего разработчика Oracle, в котором он рассказывал, как у них идет разработка. Это очень интересно – там количество тестов исчисляется миллионами. И если разработчик исправит какую-то ошибку, его задача будет тестироваться двое-трое суток. Он за это время приступает к другой задаче, потратит на нее день и так же ее отправляет в тестирование. Для его тестов поднимается своя собственная ферма серверов и опять же, на двое-трое суток уходит в тестирование. А к моменту, когда он отправил на тестирование вторую задачу, придет результат по первой. И там таким образом работают. Основной посыл статьи – почему решение Oracle стабильное, несмотря на то, что там очень много кода двадцатилетней давности. Количество тестов очень большое, процент покрытия очень большой. И тогда вероятность ошибки снижается на несколько порядков.

 

*************

Данная статья написана по итогам доклада (видео), прочитанного на онлайн-митапе "Путь к идеальному коду". Больше статей можно прочитать здесь.

Приглашаем всех 6-8 октября принять участие в INFOSTART EVENT 2022 в Санкт-Петербурге: //infostart.ru/events/1573038/

*************

Специальные предложения

Оставьте свое сообщение

См. также

Тестер: частые вопросы Промо

Тестирование QA Платформа 1С v8.3 Бесплатно (free)

Ошибкам бой - тесты норма жизни!

25.07.2018    32786    grumagargler    31    

Интерактивная справка и помощник первого запуска Vanessa Automation

Тестирование QA Платформа 1С v8.3 Бесплатно (free)

Недавно у нас появился помощник первого запуска и интерактивная справка

21.06.2022    1763    fenixnow    0    

Нагрузочное тестирование 5000+ пользователей онлайн — играем в игру

HighLoad оптимизация Тестирование QA Бесплатно (free)

Тестируем ERP под Postgre SQL. Альтернативный нагрузочный тест.

16.05.2022    5414    ivanov660    50    

Как начать писать тесты без регистрации и СМС

Тестирование QA Платформа 1С v8.3 Бесплатно (free)

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

11.05.2022    1093    zeltyr    3    

Тестирование - игровое моделирование

HighLoad оптимизация Тестирование QA Платформа 1С v8.3 Бесплатно (free)

Мы рассмотрим подход к тестированию с применением элементов искусственного интеллекта

25.04.2022    1160    ivanov660    0    

Практические кейсы и примеры создания сценарных тестов с использованием фреймворка Тестирование 3.0

Тестирование QA Бесплатно (free)

Начальник сектора разработки ООО «Группа Полипластик» Владимир Крючков на Infostart Meetup DevOps продемонстрировал коллегам работу фреймворка «Тестирование 3.0», рассказал о процессе совместной разработки тестов и порассуждал о мировых тенденциях в тестировании.

11.06.2021    8067    ivanov660    26    

Использование mock при интеграции с внешним API

Тестирование QA Бесплатно (free)

На Infostart Meetup DevOps инженер-программист Андрей Крапивин поделился с коллегами опытом тестирования интеграции с внешним API – показал возможности мокирования и рассмотрел их применение на реальном примере тестирования погодного виджета для конфигурации «Бухгалтерия 3.0».

28.05.2021    8165    Scorpion4eg    0    

Vanessa Automation. Как начать создавать видеоинструкции

Тестирование QA Бесплатно (free)

Автоматические видеоинструкции на основе сценариев тестирования поражают воображение. Но многие сталкиваются с проблемами при попытке создать собственные фичи для видео. В ходе мастер класса на онлайн-митапе «DevOps в 1С» Светлана Попова рассмотрела особенности создания видеоинструкций с помощью Vanessa Automation для SikuliX и веб-клиента. И рассказала, какие подводные камни нужно учесть при их написании.

26.05.2021    6708    SvVik    12    

Ищем паттерны в сценарных тестах. Практика - Фреймворк Тестирование 3.0

Корректировка данных Тестирование QA Бесплатно (free)

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

29.03.2021    1948    ivanov660    0    

Hello world в Vanessa-ADD bddRunner

Тестирование QA Платформа 1С v8.3 Бесплатно (free)

Минимальный пример на Vanessa-ADD bddRunner без теории. При написании использовались: 1С 8.3.10.2753, Vanessa add 6.6.5.

24.02.2021    1386    kirinalex    0    

Практика применения DevOps. Тестирование

Тестирование QA Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

В третьей части мастер-класса «Практика применения DevOps» на конференции Infostart Event 2019 Inception выступила Светлана Попова. Она рассмотрела возможности использования двух инструментов тестирования от фирмы «1С» – «Сценарного тестирования» и связки СППР и Vanessa Automation, и рассказала про плюсы и минусы каждого из этих вариантов.

11.12.2020    6699    SvVik    0    

Тестирование серверного поведения с Vanessa Automation

Тестирование QA Платформа 1С v8.3 Бесплатно (free)

Обзор модуля "ИнициаторДанных" (версия VA 1.2.034), пример скрипта

14.09.2020    3725    unichkin    18    

Vanessa, видеоинструкции для web-клиента

Тестирование QA Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Vanessa-Automation. Использование видеоинструкций в web-клиенте.

01.06.2020    4475    SvVik    3    

Молчание "best practices": тестовые и эталонные данные, структура и связность, падения и новая функциональность, и другие неудобные вопросы к сценарному тестированию

Рефакторинг и качество кода Тестирование QA Платформа 1С v8.3 Бесплатно (free)

Непонимание некоторых базовых вопросов мешает программистам начать применять инструменты тестирования в процессе разработки для 1С. Как разобраться в терминологии и интегрировать процесс тестирования в разработку 1С-решений на конференции Infostart Event 2019 Inception рассказал руководитель отдела разработки компании C.T.Consultants Решитко Дмитрий.

29.05.2020    6126    grumagargler    14    

Использование машинного обучения для решения инцидентов. Практическое применение

Тестирование QA Бесплатно (free)

Продолжаю (и заканчиваю) тему с автоматическим решением инцидентов. Перейдем от теории к практике.

25.02.2020    5289    Repich    9    

Использование машинного обучения для решения инцидентов

Тестирование QA Бесплатно (free)

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

18.02.2020    8776    Repich    17    

Тестирование: Отлаживаем и тестируем REST интерфейс 1С с помощью SoapUI

Тестирование QA Платформа 1С v8.3 Бесплатно (free)

Рассмотрим быстрый и удобный способ облегчения разработки и отладки REST, SOAP веб сервисов, а также создания автоматизированных тестов.

03.02.2020    8036    ivanov660    4    

Vanessa Automation + СППР

Тестирование QA Платформа 1С v8.3 Бесплатно (free)

Vanessa Automation. Использование автоматизированного тестирования в СППР.

07.11.2019    18552    SvVik    15    

Vanessa, улучшаем инструкции

Тестирование QA Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Vanessa Automation умеет делать хорошие инструкции, давайте посмотрим, какие инструменты для этого есть.

30.10.2019    12466    OPM    12    

Vanessa, хочу все и сразу

Тестирование QA Платформа 1С v8.3 Бесплатно (free)

Vanessa Automation это инструмент для тестирования прикладных решений на платформе 1С, но он/она может больше, чем только тестирование.

11.10.2019    17096    OPM    36    

Интерактивная отладка

Тестирование QA Платформа 1С v8.3 Конфигурации 1cv8 Россия Бесплатно (free)

Инструменты не панацея - главное подход эффективный.

13.08.2019    4862    kuzyara    7    

Как стать контрибьютором Vanessa Automation?

Тестирование QA Платформа 1С v8.3 Конфигурации 1cv8 Россия Бесплатно (free)

Краткая инструкция о том, как помочь проекту VA

15.07.2019    8314    fenixnow    43    

Интеграция сценарного тестирования в процесс разработки

Тестирование QA Бесплатно (free)

Разработчик системы «Тестер» Дмитрий Решитко в своем докладе на конференции INFOSTART EVENT 2018 EDUCATION показывает, что процесс тестирования можно очень плотно интегрировать в процесс разработки, что внедрение тестирования – это возможность развития программиста как такового, позволяющая ему упорядочивать ход мыслей и оставаться «в фокусе». Навыки построения процесса кодирования на стыке с тестированием сокращают время на концентрацию, освобождают от страха перед изменениями и улучшают память разработчика.

08.07.2019    10837    grumagargler    7    

Разработка и сценарное тестирование с Vanessa-ADD. Отчетность Allure. Автоматизация запуска сценариев

Тестирование QA Платформа 1С v8.3 Россия Бесплатно (free)

Формируем отчетность о результатах выполнения сценариев. Автоматизируем запуск.

26.02.2019    32651    Vladimir Litvinenko    28    

Разработка и сценарное тестирование с Vanessa-ADD. Установка инструментов. Запись действий пользователя и выполнение сценариев

Тестирование QA Бесплатно (free)

Вторая часть цикла публикаций, посвященных Vanessa-ADD и автоматизации тестирования.

21.01.2019    56806    Vladimir Litvinenko    98    

Автоматизация тестирования с помощью WinAutomationUI

Тестирование QA Платформа 1С v8.3 Бесплатно (free)

Рассматривается использование инструмента WinAutomationUI для создания автоматизированных сценарных тестов на примере 1 + 1 = 2.

11.12.2018    7817    AlexKo    30    

Новичок в TDD

Тестирование QA Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Краткие итоги первых шагов при разработке в 1С через TDD.

08.10.2018    12469    Alligator84    86    

Автоматизация тестирования

Тестирование QA Бесплатно (free)

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

04.10.2018    13651    ivanov660    23    

Проблемы с запуском TestClient. "Ошибка сетевого взаимодействия при вызове"

Тестирование QA Платформа 1С v8.3 Конфигурации 1cv8 Россия Бесплатно (free)

При выполнении кода автоматического тестирования появляется ошибка "Ошибка сетевого взаимодействия при вызове"

05.07.2018    6266    chugada    3    

BDD в 1С

Математика и алгоритмы Тестирование QA Бесплатно (free)

Я расскажу вам про магию BDD. Сначала будет немного теории, а потом я покажу, как это применимо к 1С на практике. BDD расшифровывается как Behavior Driven Development, разработка через поведение системы. Это означает, что мы выстраиваем весь наш процесс разработки, исходя из ожидаемого поведения.

30.08.2016    30763    Pr-Mex    19    

Опыт практического применения методики BDD на 1С. Написание сценариев

Тестирование QA Платформа 1С v8.3 Бесплатно (free)

Эта статья открывает цикл публикаций, в которых я хочу поделиться опытом использования методики BDD при разработке на 1С. В этой статье речь пойдёт о написании сценариев.

03.07.2016    26476    oleynik.dv    131    

Как протестировать неэкспортные процедуры модулей

Тестирование QA Платформа 1С v8.3 Бесплатно (free)

Процедура для доступа к внутренним методам модуля без нарушения инкапсуляции.

17.11.2015    14461    json    30    

xUnitFor1C - набор инструментов для выполнения тестирования (модульного/юнит, приемочного, сценарного для 1С 8.3, интеграционного) в 1С:Предприятии 8

Тестирование QA Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

xUnitFor1C - простой и мощный фреймворк для тестирования в 1С. Позволяет тестировать в разных режимах обычное приложение, тонкий и толстый клиент управляемого приложения. Поддерживаются любые платформы 1С - от 8.2.17 до 8.3.5 и выше. Любые наборы тестов могут прогоняться в полностью автоматическом режиме. Автозапуск используется в различных build-серверах в системах Continuous Integration. Также возможно очень простое создание тестовых данных на основании табличных макетов. Эти макеты можно генерировать из реальных боевых данных. Полученные данные в тестах загружаются одной строкой кода. В статье я кратко описал историю продукта + вставил небольшое описание различных возможностей нашего фреймворка + список полезных статей/примеров/видео, обучающих/рассказывающих о практическом применении инструмента

13.11.2015    49516    artbear    53    

Механизмы тестирования в 1С. Использование методики TDD (разработка через тестирование) в 1С

Тестирование QA Бесплатно (free)

Данная статья написана по материалам доклада, прочитанного автором на первой конференции инфостарта 2012 года. Она опубликована в журнале Инфостарта №1.

09.02.2015    89398    artbear    54    

Автоматизированное тестирование в 8.3

Тестирование QA Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

В данной статье будет рассмотрен новый механизм системы "1С:Предприятие 8" поддерживаемый начиная с платформы версии 8.3. Механизм позволяет легко и быстро создавать различные сценарии тестирования, без необходимости написания сложных процедур и функций для имитации действий пользователя.

06.03.2014    71408    M.Shalimov    47    

Простая отладка внешних обработок

Тестирование QA Платформа 1С v8.3 Бесплатно (free)

Простой способ, упрощающий отладку внешних обработок, печатных форм и тд. ВНИМАНИЕ! Данный метод НЕ работает в режиме работы "Управляемое приложение"! Статья актуальна только для режима "Обычное приложение"

22.10.2013    69244    EvilDoc    69    

Неблагодарное это дело – выдавать сообщения об ошибках

Тестирование QA Платформа 1С v8.3 Бесплатно (free)

Методика формирования и выдачи сообщений об ошибках. Описывается способ работы над ошибками в данных, прилагается программный код. Приводятся примеры.

28.09.2013    6277    pakill    16