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

Публикация № 1243144 29.05.20

Разработка - Рефакторинг и качество кода

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

Добрый день, меня зовут Решитко Дмитрий, я работаю в компании C.T.Consultants. И сегодня мы в очередной раз поговорим о тестировании.

 

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

 

 

Почему тема доклада называется «Молчание Best Practices»?

После прочтения массы литературы и изучения каких-то документов в интернете все равно остается полное непонимание того, как вообще подходить к тестированию:

  • Сколько должно быть баз?
  • Какие должны быть базы?
  • Что там делать – куда выгружать, загружать?
  • Какая вообще должна быть структура теста?

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

У тестирования есть много задач – они зависят и от инструмента, и от методологии, которая применяется, и от многих других аспектов. Поэтому то, что вы видите в литературе – это, как правило, какие-то простые тесты, где нужно сложить два числа или нажать на одну кнопку, или посчитать стоимость билета со скидкой и т.д. А когда мы начинаем пробовать применять приемы тестирования в задачах заказчика (в ERP, в тех же бизнес-процессах) – все это, естественно, очень быстро уходит из-под ног. Мы не понимаем вообще – кликать, не кликать, писать, не писать.

Кроме этого, часто тестирование завязано на какую-то определенную методологию:

  • Если это, предположим, TDD, то многие опытные в этом специалисты вообще говорят, что само тестирование при таком подходе является побочным эффектом, а локомотивом разработки является именно методология.
  • Если речь идет о BDD (это тоже технология разработки программного обеспечения, куда входит процесс тестирования), то там тоже возникает много вопросов – особенно, когда люди только начинают работать. И какие-то конкретные сценарии, конкретные вопросы, как правило, могут замыливаться под предлогом того, что надо сначала понять, какая задача у заказчика и т.д.

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

 

Базы данных

 

 

Давайте перейдем к понятию базы данных.

Когда вы уже прочитали всю информацию по тестированию, скачали все возможные инструменты и обработки (например, лично я разрабатывал Тестер, может быть, вы его уже скачивали, смотрели), то начинаете мыкаться, как слепые котята, не понимая – что, где, откуда и куда.

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

  • Первый класс – это начальная база данных, где хранится минимальный набор данных. Если вы разрабатываете какое-то тиражное решение, у вас эта база должна существовать. Там может быть какой-то минимальный набор единиц измерений, валют, какие-то классификаторы. Если вы разрабатываете решение под проект конкретного клиента, где не предусмотрено различных вариантов включения/выключения функциональных опций (условия определены конкретнее), но сама бизнес-логика может меняться чаще, чем в типовом решении, то в качестве начальной базы, конечно же, может выступать какая-то уже настроенная база клиента. Начальная база, как правило, хранится где-то в общедоступном месте, чтобы разработчики и специалисты по тестированию могли ее в любой момент взять и начать запускать на ней тесты.
  • Тестовая база (она же рабочая) – это там, где запускаются тесты. Фактически это просто рабочая база, где ведется каждодневная работа, где вы нажимаете F7, F5 и создаете там ваши данные, запускаете сценарии.
  • И есть еще эталонная база – к ней много вопросов. Под эталонной базой часто подразумевают ту базу, с которой нужно свериться.

Иногда путают эталонную и начальную, потому что они в какой-то мере перекликаются. Но желательно это разделять:

  • Начальная база – это то, на что будут опираться ваши тесты. Вы знаете, что в ней есть как минимум один пользователь, какое-то основное подразделение, какие-то три единицы измерения – тот минимальный набор данных, который вы наверняка проверять не будете.
  • А эталонная база данных – это, скорее всего, та база, где воспроизведены сценарии. Эти сценарии сформировали какие-то правильные проводки, и эта база данных используется для того, чтобы потом с ней сверялись тесты.

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

Но проблема в том, что:

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

Хотя многие компании все-таки используют эталонную базу.

 

Каким должен быть сценарный тест

 

 

Плавно переходим к тому, каким должен быть сценарный тест.

  • Первое важное утверждение – сценарный тест должен быть коротким, точнее, у него должна быть короткая целевая часть – именно то, что вы проверяете. Понятно, что если вы тестируете какой-нибудь расчет себестоимости, вам необходимо будет подготовить какие-то поступления, перемещения и списания, сделать номенклатурную спецификацию, и, если взять этот большой тест в целом, то он, конечно, будет длинным. Но именно целевая часть теста должна быть короткой. Целевая часть в данном случае – это тот этап, где вы открываете журнал документов расчета себестоимости выпуска, находите нужный документ, формируете его движения и смотрите, совпадают ли они с движениями, которые вы сохранили у себя в инструменте тестирования (не в эталонной базе) либо в коде вашего теста. Что именно должно проверяться, вы решаете сами (либо бизнес-аналитик решает). Как правило, контролируется сумма полей проводок и каких-то ключевых регистров, после чего можно уверенно говорить, проходит тест или не проходит. Целевая часть теста должна быть короткой.
  • Любой инструмент тестирования, который вы будете использовать, позволяет разбивать сложные сценарии на подсценарии. Но тут тоже нужно понимать – какова природа сложности сценария. Если мы говорим о расчете себестоимости, то это – сложный сценарий, но он самодостаточный в том плане, что у нас есть короткая часть, которая проверяет какую-то бизнес-логику. Но часто ребята путаются и делают сложный сценарий, где проверяют разные тестовые случаи. Например, для сценария по расчету заработной платы делают тестовые случаи: «Расчет заработной платы от оклада по часам», «Расчет заработной платы от оклада по дням», «Расчет заработной платы, если сотрудник был в отпуске», «Расчет заработной платы, если сотрудника уволили в середине месяца» и т.д. И получается, что тест один – «Расчет заработной платы», а там внутри сидит очень много других тестов. Так делать не стоит, потому что если упадет какой-то из тестов на третьем уровне, то программисту, чтобы внести исправления и проверить прохождение только этого тестового случая, приходится ждать, когда пройдет весь этот тест. Либо ждать ночного прогона. А если мы говорим о том, что тестирование проводится только ночью или о том, что его отдельно проводят тестировщики и т.д., то значит, что мы не интегрировали процесс тестирования в разработку. А это – часть той мысли, которую я хотел бы донести до сообщества: тестирование должно исходить от разработки и дальше уже развиваться по мере сложности самого бизнеса и задач, которые перед ним стоят.
  • О том, что большие сценарии сложно изменять и отлаживать, это, я думаю, всем понятно, просто многие об этом забывают, потому что когда они находятся на этапе создания сценария, они сфокусированы на том, чтобы сделать этот сценарий как можно быстрее. А потом упускают тот момент, когда сценарий нужно все-таки менять. Когда он эволюционирует – тогда уже начинаются проблемы и вопросы

 

 

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

 

 

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

  • Связность тестов – очень часто задаваемый вопрос и возникающая в связи с этим путаница. Здесь подвох следующий – мы как программисты всегда любим что-то оптимизировать, складывать какие-то общие куски кода в процедуры, модернизировать код с тем, чтобы он был как можно более объектным, модульным и т.д. С тестами ситуация похожая, но тут нужно знать меру. Если мы будем делать из системы тестирования какую-то глобальную модульность, это может сыграть с нами злую шутку. Например, при написании теста нужно избегать ситуаций, где динамически по запросу с переданными параметрами создается контрагент или номенклатура, используя какой-нибудь вспомогательный тест, который открывает какую-то форму списка, с путем к сценарию, который будет создавать какая-то обертка. Потому что когда такой тест начинает падать, вы начнете путаться, не поймете, откуда ноги растут.
  • И также с очередностью – это очень частое заблуждение. Например, у вас есть тест на документ поступления материалов (для многих этот тест нерелевантный, потому что поступление материалов уже сделала фирма «1С», но я его здесь приведу, просто чтобы было понятно, о чем речь). А потом, предположим, через три дня вам приходит задача на создание документа «Перемещение материалов». И вы думаете: «У меня уже есть тест на документ поступления, с ним все в порядке, я просто сейчас его запущу первым, а вторым я запущу тест на перемещение, который я сейчас пишу». Логика прямая, но со временем она сыграет с вами злую шутку, потому что, во-первых, тест, который вы делали на поступление, вообще не знает о том, что вы потом будете делать перемещение. А во-вторых, тест на поступление привязан к какому-то бизнес-процессу, который может эволюционировать. Когда он будет эволюционировать, вы будете дорабатывать это поступление. И у вас тест на перемещение уже будет падать, потому что он не будет понимать, что там при поступлении, оказывается, были не рубли, а доллары. Или, например, в поступлении появились услуги, которые распределяются. Нельзя организовывать очереди из тестов и формировать их мысленную взаимосвязь. Это потом сложно анализировать, потому что уже непонятно – по какой причине тест упал, потому что поступление эволюционировало? Поэтому рекомендуется оставлять в покое тест поступления. Скопируйте из него только ту часть, которая нужна для создания тестовых данных, упрощая все, что можно упростить. За этой частью вы будете следить, и это даст вам большую свободу в выборе того, что будет происходить.

Поэтому тут с очередностью будьте очень аккуратны – не злоупотребляйте.

 

Алгоритм сценария

 

 

Я уже упоминал определенные тезисы про то, что сценарный тест должен быть структурированным. Теперь – сам алгоритм, его структура (блочность).

Я буду отталкиваться от структуры, которая, мне кажется, покрывает большую часть сценариев, которые могут быть. Это:

  • определение входных данных;
  • создание окружения;
  • и целевая часть.

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

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

Если переложить сценарий на ручное тестирование – вы начали делать задачу, создали для себя элементы справочника, сформировали нужные документы, все подготовили, что-то в избранное добавили, чтобы быстрее там бегать мышкой, и начинаете итерацию:

  • внесли изменения в конфигурацию, сохранили (нажали F7), запустили режим 1С:Предприятие;
  • входите в избранное, открываете нужный документ, проводите его;
  • смотрите движения, проверяете их правильность;
  • закрываете.

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

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

 

Входные данные

 

 

Я много говорил о тестовых данных, об их подготовке. И теперь поговорим о подходах и о сломанных копьях на этот счет.

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

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

А сейчас я хотел бы акцентировать ваше внимание на том, что необходимо научиться выделять, какие данные будут являться тестовыми. Надо попробовать и выбрать для себя ту стратегию, к которой вы будете прибегать. Например, ребята часто создают элементы справочника – «Товар №1, 5 штук в упаковке», или договор контрагента «Ромашка руб» или «Ромашка $». Они думают, что эти данные будут тестовыми, их не нужно будет каждый раз создавать на лету, и это позволит экономить время, понимать, что к чему. Но это все тоже плохо заканчивается. Рано или поздно появится тест, который будет брать этого контрагента «Ромашку» и проверять какое-то поступление либо реализацию без договора или, например, будет изменять валюту. И если этот тест упадет, восстановления этих данных уже не произойдет. И следующие тесты, которые будут опираться на то, что там должны быть доллары, дружно попадают.

Желательно так не делать. Желательно четко осознавать, какие тестовые данные вам нужны.

 

Создание окружения

 

 

Создание окружения. Мы плавно переходим к очень большому вопросу – как создавать тестовые данные.

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

  • Любой инструмент тестирования, по идее, позволяет формировать служебные сценарии, которые по переданным параметрам создают какие-то необходимые вам данные.
  • Но возникает вопрос – как достигается уникальность этих тестовых данных? Когда мы храним тестовые данные в макете или в базе, то они один раз развернулись, а потом их надо каким-то образом подтирать, чтобы под следующие тесты создавать новые элементы. Мы не можем использовать транзакции, потому что не все данные можно хранить на клиенте – если нам нужно проверить отчет, нам нужно, чтобы данные уже были в базе, мы не можем это все откатить. Плюс, если возникнет какая-то ошибка, а мы данные откатим, то – как проверить, что это за ошибка, если данных уже нет? Потом будет сложнее воспроизводить этот сценарий, чтобы получить ошибку. А если вы используете динамическое формирование тестового окружения, вы можете использовать какой-нибудь уникальный идентификатор, который позволяет формировать ваш инструмент тестирования. И ваши данные будут каждый раз формироваться заново.
  • Понятно, что база, на которой вы производите тестирование, рано или поздно превращается в хлам – там постоянно создаются какие-то новые элементы справочников и т.д. Но давайте говорить честно – даже если вы тестируете и разрабатываете вручную, ваша база все равно превращается в хлам. Рано или поздно вы все равно поменяете ее на реальную клиентскую базу или опять на начальную – это процесс неизбежный.

 

Целевая часть

 

 

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

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

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

 

Приемы тестирования №1

 

 

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

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

 

Приемы тестирования №2

 

 

Какие еще есть приемы тестирования.

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

 

Рефакторинг

 

 

  • Тесты не должны брать в заложники развитие функциональности. Довольно часто получается, что мы пишем тесты, а потом начинаем бояться менять функциональность, потому что боимся, что тесты начнут падать. Если нет нормального инструмента рефакторинга, или тесты организованы очень плохо, то получается «за что боролись, на то и напоролись».
  • И наоборот – мы боимся писать тесты, потому что у нас могут быть проблемы с функциональной частью. Это очень взаимосвязанные вещи, поэтому, чем быстрее вы можете рефакторить и изменять тесты, тем лучше.
  • Экспериментируйте, пробуйте заворачивать тестирование на сам процесс разработки, покрывайте ошибки, покрывайте какие-то пограничные случаи или отклонения (то, что сверху сценарием не спустится).

 

Ссылки на бесплатные инструменты тестирования

 

  1.  https://github.com/grumagargler/tester 
  2.  https://github.com/Pr-Mex/vanessa-automation 
  3.  https://github.com/silverbulleters/add 
  4.  https://github.com/ivanov660/TestingTool-3
  5.  https://github.com/DoublesunRUS/ru.capralow.dt.unit.launcher 

 

Надеюсь, вас эта тема заинтересовала.

 

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

Данная статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART EVENT 2019. Больше статей можно прочитать здесь.

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

Выбрать мероприятие

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

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. CheBurator 3114 29.05.20 23:56 Сейчас в теме
это тесты логики/поведения? как тестировать логику в запросе на 10 экранов?
2. CheBurator 3114 29.05.20 23:59 Сейчас в теме
зачем создавать входные данные какие-то? есть 1-2-3 набора входных данных, которые должны проходить стопудово. Далее пихаем на вход вообще всякий хлам и добиваемся чтобы система вела себя адекватно при этом (не крашилась, не делила на ноль итд)...?
3. CheBurator 3114 30.05.20 00:00 Сейчас в теме
Это нормально когда - например - тестируемая функция по существу 10 строк содержательного кода и 50-100 строк "защита от дурака"...?
4. CheBurator 3114 30.05.20 00:01 Сейчас в теме
Задача тестирования - попытаться уронить систему? - так?
5. grumagargler 720 30.05.20 00:54 Сейчас в теме
(4)
это тесты логики/поведения? как тестировать логику в запросе на 10 экранов?

Это тестирование написанной программы через эмуляцию работы пользователя в ней. Какие при этом вызываются процедуры и выполняются запросы - напрямую не связано с описываемой темой доклада.

зачем создавать входные данные какие-то? есть 1-2-3 набора входных данных, которые должны проходить стопудово. Далее пихаем на вход вообще всякий хлам и добиваемся чтобы система вела себя адекватно при этом (не крашилась, не делила на ноль итд)...?

Не уверен что понял про наборы данных. Есть сценарии на входе которых данные. Методика, при которой вы управляете созданием данных, позволяет идти в ногу с изменяющейся функциональностью вашей программы. Можно конечно создать где-то в сторонке пару наборов данных на основе тз или других требований, но на практике изменения в программе приходится делать не только по причине недоработанных тз.
Это нормально когда - например - тестируемая функция по существу 10 строк содержательного кода и 50-100 строк "защита от дурака"...?

Да, но вероятно я не понял вопрос.
Задача тестирования - попытаться уронить систему? - так?

Нет, не только.
6. BackinSoda 30.05.20 01:02 Сейчас в теме
Такое тестирование, видимо, окупается на крупных проектах, где над одними объектами работает несколько программистов. А то получается, что время затраченное на создание теста превышает время на саму разработку. Особенно для печатных форм, проще же внешнюю создать, сохранил-свернул в предприятие и сразу виден результат, а сколько времени надо на написание логики тестов п.ф. ?
8. grumagargler 720 30.05.20 03:01 Сейчас в теме
(6) мой небольшой цикл статей и докладов пронизан идеей, что для разработчика тестирование - это неотъемлемая часть профессии, и никак не связана с многообразием бизнес-процессов вокруг разработки, размером проектов и бюджетов (включая тестирование не разработчиками). Конечно, это не работает абсолютно для всего, но и тумблером (тестирование вкл/выкл) не является.
9. JohnyDeath 300 30.05.20 09:04 Сейчас в теме
(6) не понял про печатные формы. Вы их глазами что ль сравниваете?
Проверять печатные формы тестами достаточно просто (если речь идет о сверке результата с эталоном).
Вот например как можно гибко делать в тестере: http://test1c.com/businesslogic/#_2
А если же надо просто сравнить полностью два табличных документа, то для этого достаточно вызвать один метод, который вызовет исключение, если табличные документы не совпадают.

По поводу крупных проектов и большой команды. Не согласен с вами. Я в данный момент работаю один. На сопровождении несколько полутиповых допиленных конфигураций, которые надо периодически обновлять поставками от вендора. Каждое новое мажорное обновление - это страх, что может отвалиться то, что дописано сверху (иногда и что-то типовое). Когда у тебя есть хоть немного сценариев, которые эмулируют работу пользователей, то это уже дает +80 к уверенности, что завтра с утра тебе не будут насиловать по телефону и в чатах, что всё сломалось.
А если вести разработку "от тестирования", т.е. когда ты сначала пишешь тест, а потом под него код, то получается и весело и полезно. Пример такой работы есть в видео у автора статьи: https://www.youtube.com/watch?v=Lr6ew_Nu1aE&feature=emb_title
12. BackinSoda 30.05.20 10:09 Сейчас в теме
(9) Про печатные формы - имхо, для дымового теста внешней п.ф. достаточно "глазами сравнить". По идее, если вы её разработчик, то знаете, где какие параметры и что потенциально могло не заполниться.
Не доводилось работать в Тестере, но предполагаю, что на подготовку каждого эталона уходит не мало времени, да и для большинства пф придётся делать новый уникальный эталон, а не использовать готовые.

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

Вот тут согласен, без сценарного тестирования сложно будет обойтись.

пс: В комментариях к полуторачасовому видео есть хороший вопрос про то, какой функционал всё же покрывать тестами ? Вот такую бы статью еще прочитать
ппс: Для неподготовленного пользователя видео тяжело для восприятия, хоть оно и не носит обучающего характера, но всё же
13. JohnyDeath 300 30.05.20 10:42 Сейчас в теме
(12)
Про печатные формы - имхо, для дымового теста внешней п.ф. достаточно "глазами сравнить". По идее, если вы её разработчик, то знаете, где какие параметры и что потенциально могло не заполниться.

Один раз - да, возможно. Не не будешь же делать это при каждом обновлении и для каждой формы. Да и "глаз" очень часто промахивается. Недавно как раз был случай, когда вот так на глаз сравнивали печ форму и только те параметры, которые трогали. На старые не обращали внимания, и как раз один из старых просто перестал выводиться из-за связанных изменений двух разных разработчиков.
Не доводилось работать в Тестере, но предполагаю, что на подготовку каждого эталона уходит не мало времени, да и для большинства пф придётся делать новый уникальный эталон, а не использовать готовые.

Если нужно сверить один-в один, то достаточно сохранить однажды распечатанное.
Но лучше, конечно, сделать параметризированный шаблон сверки. Как это сделать в Тестере я кидал выше.
Вот еще из полезного по теме сверке шаблонов: http://test1c.com/faqtesting/#_37
Поверьте, окупается уже на второй-третьей сверке "на глаз".
7. acanta 30.05.20 01:05 Сейчас в теме
А крупных проектов мало потому что автоматизированное тестирование слишком сложное и дорогое, при том что ручное вообще невозможно.
10. acanta 30.05.20 09:10 Сейчас в теме
В екселе есть кнопка макрорекордер. В 1с по моему есть такая примочка, которая перехватывает нажатие клавиш пользователя и может записать это и воспроизвести. Можно ли из этой записи получить полноценный сценарный тест или хотя бы его основы?
11. JohnyDeath 300 30.05.20 09:13 Сейчас в теме
(10) На этом сейчас основаны все фреймворки тестирования, что перечислены в конце статьи (за исключением xUnit)
Пример создания в видео ниже. Но текущий релиз Тестера намного круче преобразовывает запись с клиента во внутренний язык. Просто качните и попробуйте.
https://www.youtube.com/watch?v=ZyqQ-YjKB3A
BackinSoda; acanta; +2 Ответить
14. sorb 30.05.20 15:08 Сейчас в теме
Имхо один из лучших докладов был, спасибо)
Оставьте свое сообщение

См. также

Ревьювер. Инструмент для проведения code review

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

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

16.05.2023    2335    leobrn    11    

44

Применение cтандартов и методик разработки конфигураций на практике

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

Практические кейсы для того, чтобы не устать применять стандарты и методики разработки конфигураций.

15.05.2023    3105    improg    33    

51

SonarQube: про объемы, ветки, покрытие кода и интеграцию с Gitlab

DevOps и автоматизация разработки Рефакторинг и качество кода Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Опыт применения SonarQube в нескольких командах. Плюс некоторые тонкости: уменьшение объемов базы SQ, интеграция, покрытие кода.

26.02.2023    2454    kraynev-navi    10    

47

Зачем и как читать чужой код? Какой результат ожидаем получить? Основные подходы

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

Данная статья является кратким содержанием статей цикла "Как читать чужой код". Цель такой публикации: создать чек-лист различных подходов для чтения непонятного кода. Более подробно каждый из методов можно прочитать в исходной статьей. Последовательность изложения материала полностью совпадает с исходными статьями, и разделена на 4 части.

06.02.2023    2905    biimmap    9    

29

Быстрый старт в тестировании на платформе 1С (Vanessa-ADD)

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

Если вы давно хотите освоить тестирование в мире 1С. Но не знали, с чего начать. Теперь знаете.

02.02.2023    8059    NikitaIvanchenko    28    

129

Как проверять код на языке 1С с помощью BSL Language Server

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

Некоторые разработчики на платформе 1С не проверяют свой код ни на соответствие стандартам 1С, ни на самые распространённые ошибки кодирования. И если раньше они могли оправдываться отсутствием инструментов для этого, то с появлением BSL Language Server оправданий больше нет.

13.01.2023    3734    aleksei_adamov    10    

45

Без комментариев!

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

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

05.01.2023    5357    ardn    161    

39

Правила работы с транзакциями 1С

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

Список правил при работе с транзакциями из BSL Language Server и SonarQube 1C (BSL) Plugin. Переработка и осмысление материала.

01.12.2022    4740    kuzyara    42    

78

Как избавиться от большого количества комментариев в коде с использованием EDT + Git

Рефакторинг и качество кода DevOps и автоматизация разработки Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Публикация освещает вопрос улучшения качества и читабельности кода путем отказа от излишних комментариев. Рассматривается пример из опыта работы команды разработки на EDT + Git. Команда работает в EDT меньше года. Конфигурация сильно доработана и не обновляется типовыми релизами.

15.11.2022    1130    shastin87    5    

9

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

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

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

21.06.2022    2298    fenixnow    0    

45

Рефакторинг и реинжиниринг в повседневной практике

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

В этой статье будут затронуты многие темы. Использование WS ссылок, HTTP запросов, асинхронных запросов к внешним сервисам, работа с XML, методики интеграции. Но лишь попутно. Для наглядности. На технических вопросах реализации останавливаться не буду. Все примеры работы с этими объектами есть в коде. Файлы обработки и расширения доступны. Главная цель - рассмотреть рефакторинг и реинжиниринг как инструменты для достижения вполне конкретных практических целей.

20.06.2022    1284    user1374747    0    

7

Модульность в 1С – как следовать принципам DRY в реалиях 1С: Предприятие 8.3

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

Принцип DRY – Don't repeat yourself (не повторяйся) – один из классических принципов программирования. Краеугольным камнем реализации этого принципа является модульная архитектура, которую можно реализовать в 1С с помощью расширений. Но экосистемы модулей общего назначения, сравнимой с существующими в других языках, в 1С пока что нет. О том, как спроектировать архитектуру таких модулей и управлять ими с помощью менеджера пакетов, на митапе «Путь к идеальному коду» рассказал технический директор компании «А1» Арсений Геращенко.

03.06.2022    3112    Enigma    3    

22

Красота разработки в 1С, или художественная верстка кода

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

Рекомендации по верстке и организации кода в 1С, которые я вывел для себя. P.S. Нет, это не про комментарии и номера версий.

02.06.2022    7492    TimofeySin    67    

65

Как выжить, если у тебя в базе 1С 50+ расширений

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

Расширения – это простой способ делать доработки на лету. Но администрировать большое количество расширений и не допустить бардак – очень сложно. О том, как выжить в такой ситуации, реализовать управление доработками и установкой актуальных версий расширений, на митапе «Путь к идеальному коду» рассказал Юрий Былинкин – архитектор 1С в компании Аскона.

16.05.2022    6070    ardn    44    

55

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

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

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

11.05.2022    1652    zeltyr    5    

13

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

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

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

25.04.2022    1642    ivanov660    0    

15

Про простой и понятный код

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

Внимание! Данная публикация с большой долей вероятности не добавит ничего нового к Вашим знаниям и Вашему опыту, поэтому если Вы читаете Инфостарт исключительно для целей "прокачки" своих навыков, не тратьте на её чтение своё время и перейдите сразу к следующей!

03.12.2021    5502    q_i    161    

71

Как читать чужой код? Часть 1. Общие вопросы. Доработка чужого кода. Code review

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

Во всех вакансиях есть требование - умение читать чужой код. Но ни на одних курсах специально этому не учат. Чтобы устранить это противоречие, пишу данную статью. Рассмотрю случаи, в которых нам необходимо разбирать чужой код, поймём, чей код мы пытаемся разобрать, зачем и, главное, как. В статье описан личный опыт длиною в 18 лет начиная с версии платформы 7.7. Статья будет большой, набираемся терпения). Статья содержит в себе описание сценариев разбора кода, т.е. набор шагов. В статье не получится показать это на практике. Для этого планирую сделать онлайн или оффлайн курс, где на примерах будет показан разбор незнакомого кода. Статья разбита на 4 публикации для удобства изучения.

20.09.2021    13210    biimmap    55    

137

Распространенные ошибки разработчиков, приводящие к проблемам производительности

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

Рассмотрим примеры ошибок, анализ, исправление и мероприятия по недопущению подобного в будущем. Всего будет 18 примеров.

02.08.2021    16447    ivanov660    77    

142

Антипаттерны программирования в 1С

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

Поговорим про плохой стиль программирования и рассмотрим 17 часто встречающихся антипаттернов.

19.07.2021    13052    ivanov660    121    

69

Чек-листы для проведения Code Review

Рефакторинг и качество кода Платформа 1С v8.3 Конфигурации 1cv8 1С:Франчайзи, автоматизация бизнеса Бесплатно (free)

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

17.05.2021    11618    Shining_ninja    99    

129

Эффективные приемы разработки

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

На Infostart Meetup Ekaterinburg.Online выступил Сергей Наумов – руководитель центра аналитики и консалтинга WiseAdvice. Сергей поделился с коллегами приемами разработки, которые помогут избежать потенциальных проблем при реализации сложных проектов.

07.04.2021    5302    SergeyN    13    

39

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    1656    kirinalex    0    

12

Ускорение расчета себестоимости УПП 1.3 в несколько раз

Рефакторинг и качество кода Закрытие периода Платформа 1С v8.3 1С:Управление производственным предприятием Бухгалтерский учет Управленческий учет Бесплатно (free)

Как определить причину медленного расчёта себестоимости в УПП 1.3, один из вариантов поиска проблем производительности с помощью инструментов 1С и ускорения расчёта средствами встроенного языка

02.02.2021    5708    RPGrigorev    23    

40

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

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

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

11.12.2020    7698    SvVik    0    

50

Практика применения DevOps. Работа с SonarQube

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

Во второй части мастер-класса «Практика применения DevOps» на конференции Infostart Event 2019 Inception выступил Виталий Подымников – он рассказал про процесс проверки качества кода и использование SonarQube для работы с ним.

07.12.2020    16301    arcius_7012    21    

84

Операторы перехода в программном коде: использовать или нет?

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

Рассмотрим ситуации использования операторов перехода Перейти (GoTo), Возврат (Return), Прервать (Break), Продолжить (Continue). Как вы считаете - это дурной тон, нормальная практика или зависит от ситуации?

16.11.2020    9902    ivanov660    23    

11

Чистый кот (Clean cat)

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

От автора легендарного бестселлера "Совершенный кот".

04.11.2020    2462    vasilev2015    25    

5

Доработайте это "немедленно", или как уменьшить доработки конфигурации

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

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

25.09.2020    5029    Богатырев Артур    24    

14

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

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

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

14.09.2020    4486    unichkin    18    

25

Как найти неиспользуемый код

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

Описание нескольких способов поиска и определения неиспользуемого кода

03.08.2020    6064    Infostart    29    

71

Как поставить качество кода на поток и при этом не разориться? Какие шаги стоит сделать уже завтра, чтобы повысить планку качества?

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

Наличие в 1С-решениях некачественного кода мешает их поддержке и эффективному развитию. Как добиться соблюдения стандартов разработки при написании кода и внедрить бюджетный Code Review с помощью инструментария на основе АПК (Автоматизированной проверки конфигураций) на конференции Infostart Event 2019 Inception рассказал технический руководитель компании Бизнес Лоджик Иван Козлов.

22.06.2020    5185    kozlov.alians    1    

23

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

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

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

01.06.2020    4979    SvVik    3    

29

Рефакторинг в редакторе модулей

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

Для тех, кто не пользуется Ctrl+Alt+R. “Контролируемый процесс улучшения кода без написания новой функциональности”, “Равносильное преобразование алгоритмов” и т.п в данной статье НЕ рассматриваются. Тема статьи: замечательные команды из подменю Рефакторинг контекстного меню редактора модулей в конфигураторе. В статье описано, как команды из подменю Рефакторинг помогают при написании кода

10.03.2020    6097    pparshin    6    

52

Качество кода: Поведенческие паттерны проектирования

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

Поговорим про применение паттернов проектирования в разработке на 1С.

03.03.2020    12696    ivanov660    0    

83

Боремся с запросами в циклах. Мой опыт рефакторинга запросов

Рефакторинг и качество кода Запросы Конфигурации 1cv8 Бесплатно (free)

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

02.03.2020    14401    aximo    55    

72

Код разработчика в зависимости от опыта работы

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

Пятничный пост! Как меняется код разработчика в зависимости от опыта работы.

14.02.2020    13658    Infostart    229    

106