Как объять необъятное, или советы по тестированию

Публикация № 554255

Администрирование - Администрирование данных 1С - Тестирование и исправление

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

О чем пойдет речь в статье?

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

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

Обо мне

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

  • Я занимаюсь тестированием уже больше 10 лет.
  • Работала в различных компаниях: Acronis, Kaspersky, 1С и некоторыхдругих.
  • С 2009 года я руковожу компанией «Лаборатория качества». Мы занимаемся аутсорсингом, оказываем консалтинг в сфере тестирования, помогаем реализовывать различные проекты (крупные и не очень).

На кого рассчитан этот материал?

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

Как растут проекты

Давайте для начала посмотрим, как вообще измеряются проекты.

Если говорить про совсем маленькие проекты, то я думаю, что в рамках 1С-деятельности вы с такими, скорее всего, не работаете.

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

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

В результате наш проект растет.

А когда мы уже начинаем интегрироваться с какими-то внешними сторонними решениями, мы уже становимся совсем большими. И, как в случае с тем же 1С, наш продукт вырастает в целую «платформу разработки».

В чем выражается такое повышение сложности?

  • Во-первых, в количестве строк кода. Я работала на одном проекте, где было 2 миллиона строк кода – задача протестировать их все была физически невыполнима.
  • Во-вторых,в количестве заказчиков (источников требований)
  • И в-третьих, в количестве тех окружений, где все это должно работать.

Тут еще важно понимать, что на конкретных данных что-то может работать по-разному. Например, у меня есть три заказчика, которые используют одну и ту же «фичу» на пяти разных окружениях и в пяти разных последовательностях. Соответственно, конкретных комбинаций использования у меня получается 5*5*3=75 (потому что заказчиков три, а платформ пять и сценариев пять). Немало.

Получается, что весь наш рост идет по экспоненте. Сложность повышается и непрерывно растет все дальше и дальше.

Как это обычно происходит?

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

И вот этот менеджер приходит к разработчику и говорит: «нужно поддерживать». И разработчик отвечает: «да без проблем, будет работать, никуда не денется!»

И на этом работа и менеджера по продажам, и разработчика завершена – все счастливы. А тестировщик сидит и думает: «ребята, мне же на то, чтобы это проверить на одной платформе, два дня надо было, а теперь еще и на пяти платформах проверять, что ли?

Если он проверяет на пяти платформах и там все работает, то получается, что он был вообще единственный, кому пришлось «попахать». А если там выявляются проблемы, то уже понятно, что они потом вернутся к разработчику – и на исправление, и на переисправление. И дальше уже циклы будут более длительными.

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

Зачем вообще нужны тестировщики? Казалось бы, разработчики – такие умные ребята! Взяли, написали и все сразу хорошо работает! Но так не получается. Необходима некоторая эмпирическая проверка, чтобы подтвердить, что все хорошо, либо убедиться в том, что существует ошибка. Иначе, основываясь на каких-то логических предпосылках, которые были у нас в голове при разработке, мы всегда можем столкнуться с какими-то сложностями. И, когда нам кажется, что все должно работать, оно может не работать, поэтому проверять все равно приходится.

Неправильные решения по организации тестирования

Так вот, представьте, что наш проект растет: у него появляются различные интеграции, связи, и соответственно, хочется все это как-то лучше тестировать. Какие решения по тестированию могут оказаться неправильными?

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

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

Следующее решение – не самое правильное, но на него от отчаянья соглашаются очень многие: «давайте пользователю отдадим, и там посмотрим, что получится».

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

Еще есть решение, которое обычно предлагают разработчики – «автоматизаторы до мозга костей». Они говорят: «давайте, если тестировать, то автоматизированно».

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

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

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

Правильные решения по организации тестирования

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

Во-первых, есть такая модель, которую предложил Алистер Коберн, автор таких методологий разработки, как crystal и crystallight.

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

Так вот, Алистер Коберн сказал следующее: «чем выше риски и чем больше людей на проекте, тем больше для него требуется документации». Потому что когда количество людей на проекте растет, передавать им информацию устно становится уже недопустимо, поскольку при этом теряется возможность непрерывно контролировать все эти процессы. Ответственность повышается: людей больше, вовлеченных задач больше, интеграции больше, тестовых данных больше – всего больше.

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

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

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

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

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

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

Проводится тестирование, которое называется «регрессионным» – это когда разработчики что-то поменяли или «впилили» новое, и нужно проверить, работает старое или нет, есть там какой-то регресс (провал) или все в порядке. Однако, когда продукт большой, объем такого «регрессионного тестирования» может вырасти как снежный ком, и проверить весь функционал целиком становится уже невозможно, но если мы не станем этого делать, риски возрастут.

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

Что мы делаем с этой табличкой дальше?

Выпускается какая-то новая версия продукта. Мы знаем, что в ней затронуты 3 фичи: из строки 22, 35 и 47.И я сразу же вижу, с какими столбцами они связаны немного (эти ячейки помечены желтым цветом) или сильно (оранжевым). Мы начинаем с оранжевого и переходим к желтому. Все остальное, что вроде бы как не связано, мы уже не смотрим.

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

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

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

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

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

«Читерские» способы увеличения качества тестирования

Кроме уже упомянутых решений, есть еще несколько «читерских» методов, которые нам обычно помогают.

В чем заключается это «читерство»? Тестирование – это очень зависимая область, в которой нагрузка получается очень неравномерной:

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

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

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

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

Недавно мы делали такой проект для одной очень известной многопользовательской системы, которую все знают. У них в компании было пять тестировщиков, которые всей командой за месяц находили в системе, допустим, 200 каких-то ошибок. И мы решили устроить бета-компанию, привлечь к тестированию этой системы участников на портале тестировщиков software-testing.ru. И тому, кто заведет наибольшее количество полезных ошибок, пообещали в рамках этой бета-компании приз – iPhone. Ошибки начали сыпаться: и сыпались, и сыпались. Вся команда сидела, их обрабатывала и заводила в багтрекер. За время этой компании (две недели) было заведено, допустим, 250 ошибок – имеются в виду только те ошибки, которые были приняты командой на исправление. Но если поделить стоимость iPhone на 250 и если поделить зарплату 5 тестировщиков в месяц, сидящих в офисе, на 100 (количество ошибок, заводимое штатными тестировщиками за две недели), то получается, что стоимость одной ошибки из этой бета-компании нам обошлась в 10 раз дешевле. И мы так удивились, что за маленькую детальку iPhone получили столько полезного фидбека.

Помимо портала software-testing.ru есть и другие специальные площадки – fixber.ru, utest.com, freelansim.ru – их достаточно много. На них мы можем привлекать людей за вознаграждение, чтобы они поделились с нами информацией о конкретных найденных ошибках. Это очень помогает наращиванию покрытия наших платформ.

Следующее «читерство» – это, конечно, аутсорс.

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

Но когда же все-таки выгодно использовать аутсорс?

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

Ну и третий момент – это, конечно же, некоторые «ролевые игры» в команде.

Что я имею в виду под ролевыми играми?

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

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

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

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

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

Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2015 CONNECTION 15-17 октября 2015 года.

Приглашаем вас на новую конференцию INFOSTART EVENT 2019 INCEPTION.

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

Комментарии
Избранное Подписка Сортировка: Древо
1. TODD22 18 18.10.16 09:55 Сейчас в теме

Следующее решение – не самое правильное, но на него от отчаянья соглашаются очень многие: «давайте пользователю отдадим, и там посмотрим, что получится».

А разве в самой фирме 1С не так тестируют? Вся страна в бэта тестерах сидит....

И тому, кто заведет наибольшее количество полезных ошибок, пообещали в рамках этой бета-компании приз – iPhone.

Всё тестирование в 1С в одном предложении.... Может тогда конкурсы сделать разнообразными? С разными призами? Дело может лучше пойдёт.
rayastar; +1 Ответить
2. корум 311 18.10.16 11:23 Сейчас в теме
(1) TODD22, хороший тамада, и конкурсы интересные :)
stroganov_ru; Sheff; CyberCerber; TODD22; +4 Ответить
3. pythonchik 19.10.16 07:27 Сейчас в теме
Был такой опыт - привлекали аутсорсеров. Столкнулся с тем, что за ними потом еще нужно хорошенько все проверять. Да и глубина тестирования оставляет желать лучшего. Эти ребята классно отыскали все места, где наши доработки внешне отличаются от типовых (например, не хватало кнопки Структура подчиненности). Но ошибки в рассчетах себестоимости мы ловили сами
acanta; Krasnyj; sulfur17; +3 Ответить
4. romansun 191 19.10.16 11:15 Сейчас в теме
А расскажите кто-нить про опыт организации регресс-тестирования для 1С конфигураций. При постоянной команде разработки, скажем, 3-5 человек и примерно 30-40 пользователях системы. С постоянным выпуском релизов раз в месяц, например.
5. Infactum 286 19.10.16 13:31 Сейчас в теме
Имхо вода. Как насчет конкретных практик? Для сравнения рекомендую посмотреть на статьи/проекты silverbullets.
А тем кто просто процессом тестирования в компании 1С интересуется , очень рекомендую прочитать соответствующую статью (только там про платформу речь) в официальном блоге 1С на хабре.
team bios; dunpil; kuzyara; davydoff; vano-ekt; sashocq; zqzq; shalimski; CSiER; +9 1 Ответить
7. CSiER 29 20.10.16 04:48 Сейчас в теме
(5) Infactum, дополню: также в общих чертах о процессе разработки в 1С можно почитать на http://1c-dn.com/blogs/techblog/
6. Sheff 19.10.16 15:30 Сейчас в теме
8. zqzq 19 20.10.16 08:28 Сейчас в теме
Забавно, сначала написано, что автоматизированное тестирование не катит. А в следующих абзацах про документирование через (авто-)тестирование, регрессионное тестирование и т.д.. Как всегда 1С идёт своим путём, чтобы в конце-концов окольным путём выйти к общемировым практикам (с 10 летним отставанием).
9. ivanov660 1929 20.10.16 14:07 Сейчас в теме
Многие вещи в статье на мой взгляд притянуты за уши с определенным уклоном. Тестирование само по себе не решит вопроса повышения качества, этого можно добиться только в комплексном подходе к разработке. И не всегда есть возможность передавать тестирование на аутсорс. Скажите сколько по времени аутсерсеры будут разбираться в существующих процессах, которые надо проверить? А будут ли?

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

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

А вот практические вопросы по созданию сценариев тестирования не озвучены.
vano-ekt; +1 Ответить
10. rus128 2 20.10.16 17:56 Сейчас в теме
все хорошо, но смущает опечатка в самом начале: "имы помогали им"
так и не понял - кто такие "имы"? :-)
11. vano-ekt 532 20.10.16 21:18 Сейчас в теме
так вот кто так хреново тестирует типовые! а мы всё на 1С тут грешили...
12. SunShinne 618 24.10.16 15:15 Сейчас в теме
Ничего полезного для себя не нашел. Но, наверное, кому-то пригодится.
13. DonAlPatino 137 04.11.16 13:54 Сейчас в теме
"Дело в том, что наша команда работала с фирмой 1С, и мы помогали им налаживать тестирование типовых конфигураций". Ну расскажите же наконец-то КАК В 1С тестируются типовые! В блоге на habr 1Ски рассказали как тестируют платформу. Для меня было открытием, что они знают про TDD/BDD/unit- тесты и т.п. На вопрос "а почему всего этого нет в типовых" ответа так и не последовало. Ну и собственно мы все знаем, что автоматическое тестирование для типовых 1С делают люди не из 1С (Знаем кто и огромное им за это спасибо). Так как же тестируют типовые в 1С?
Оставьте свое сообщение

См. также

Ошибка Frontol 5, 6 при работе с базой (internal gds software consistency check)

Статья Системный администратор Нет файла Розничная и сетевая торговля (FMCG) Windows Бесплатно (free) Тестирование и исправление

При продаже товара выскакивает критическая ошибка "Ошибка работы с базой! Internal gds software consistency check (can't continue after bugcheck)" и работа базы прекращается, любые повторные попытки войти в базу приводят к огромным количествам не понятных ошибок, сбоев, зависаний и вообще может выдать что база не обнаружена (перемещена или удалена). При попытка остановить/перезапустить службу Frontol она вообще зависала и помогала только перезагрузка терминала

23.01.2020    952    ClickUp    2       

Голосование за доклады на INFOSTART MEETUP Kazan - до 25 февраля. Промо

Выбирайте и голосуйте за самые интересные доклады! Лучшие из лучших попадут в окончательную программу казанского митапа. Оставить свой голос можно до 25 февраля 2020 года.

Зависает полнотекстовый поиск! Что было? Что я сделал?

Статья Системный администратор Программист Стажер Нет файла v8 БП3.0 Россия MS SQL Бесплатно (free) Тестирование и исправление

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

10.01.2020    2976    VID1234    14       

"Объект не найден" - не приговор! Простой способ восстановить удаленный объект

Статья Программист Нет файла v8 1cv8.cf Бесплатно (free) Тестирование и исправление

В статье будет рассмотрен простой способ восстановления удаленного объекта с помощью обработки «Выгрузка и загрузка данных XML».

12.11.2019    2948    OlesiaM    12       

Управление ИТ-проектами. Модуль 2: продвинутый онлайн-курс по классическим методам управления проектами. Вебинары проходят с 12 марта по 11 июня 2020 года. Промо

Продвинутый онлайн-курс по классическому управлению ИТ-проектами позволит слушателям освоить инструменты из PMBoK® и 1С:Технологии корпоративного внедрения и научиться их применять для проектов любого масштаба. Курс включает в себя 12 вебинаров и 12 видеолекции, разбор кейсов и рекомендации экспертов по проектам слушателей. Ведущая курса - Мария Темчина.

от 13000 рублей

Решение для клиент-серверной архитектуры на базе POSTGRE SQL при возникновении ошибки "Нарушена целостность структуры конфигурации"

Статья Системный администратор Программист Нет файла v8 1cv8.cf Бесплатно (free) Тестирование и исправление

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

07.11.2019    3826    leaguener    5       

Восстановление индексов СУБД

Статья Программист Нет файла v8 1cv8.cf Россия Бесплатно (free) Тестирование и исправление

Восстановление индексов СУБД на основе структуры хранения базы данных 1С.

09.10.2019    2889    kadr    2       

Подборка программ для взаимодействия с ЕГАИС Промо

ЕГАИС (Единая государственная автоматизированная информационная система) - автоматизированная система, предназначенная для государственного контроля за объёмом производства и оборота этилового спирта, алкогольной и спиртосодержащей продукции. Инфостарт рекомендует подборку проверенных решений для взаимодействия с системой.

О Unit-тестах замолвите слово.Часть 1

Статья Программист Нет файла Бесплатно (free) Тестирование и исправление

Последнее время в контексте 1С очень много говорят о функциональном тестировании, BDD. А Unit-тестирование обходят стороной. Попробуем разобраться, для чего Unit-тестирование применять стоит.

22.07.2019    4276    Сурикат    27       

Подборка решений для взаимодействия со ФГИС «Меркурий» Промо

С 1 июля 2019 года все компании, участвующие в обороте товаров животного происхождения, должны перейти на электронную ветеринарную сертификацию (ЭВС) через ФГИС «Меркурий». Инфостарт предлагает подборку программ, связанных с этим изменением.

Исправление ошибки при открытии внешнего отчета "Не удалось обновить вспомогательные данные расширений"

Статья Программист Стажер Нет файла v8 Россия Бесплатно (free) Тестирование и исправление

Способы исправления ошибки при открытии внешнего отчета "Не удалось обновить вспомогательные данные расширений. Обратитесь к администратору."

30.05.2019    3206    AlkB    4       

INFOSTART MEETUP Kazan. 13 марта 2020 г. Промо

Инфостарт продолжает путешествие по России. Следующая остановка - Казань. Тема мероприятия - управление и технологии автоматизации учета на платформе "1С: Предприятие". Ждем всех: докладчиков и участников! Стоимость участия - 5 500 рублей. Цена действительна до 30.01.2020

5 500

MS SQL Ошибка СУБД: Предоставленный поток статистики разрушен. Как решить проблему с разрушенной статистикой

Статья Системный администратор Нет файла v8 1cv8.cf Бесплатно (free) Тестирование и исправление

MS SQL Ошибка СУБД: Предоставленный поток статистики разрушен... Как решить проблему с разрушенной статистикой

16.04.2019    4242    ikorulev    1       

Базовый курс по обмену данными в системе 1С:Предприятие. Онлайн-интенсив с 12 по 28 мая 2020 г. Промо

Данный онлайн-курс предусматривает изучение механизмов платформы “1С:Предприятие”, обеспечивающих обмен данными между различными прикладными 1С-решениями и взаимодействие с другими информационными системами. Курс предназначен для тех, кто уже имеет определенные навыки конфигурирования и программирования в системе “1С:Предприятие”.

5500 рублей

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

Статья Программист Нет файла v8 Россия Бесплатно (free) Тестирование и исправление

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

17.01.2019    21235    PoZiTiFFF    53       

Восстановление базы 1С, ошибка источника потока

Статья Системный администратор Программист Нет файла v8 Бесплатно (free) Тестирование и исправление

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

09.01.2019    14274    idle    25       

Новый раздел на Инфостарте - Electronic Software Distribution Промо

Инфостарт напоминает: на нашем сайте можно купить не только ПО, связанное с 1С. В нашем арсенале – ESD-лицензии на ПО от ведущих вендоров: Microsoft, Kaspersky, ESET, Dr.Web, Аскон и другие.

  • Низкие цены, без скрытых платежей и наценок
  • Оперативная отгрузка
  • Возможность оплаты с личного счета (кешбек, обмен стартмани на рубли и т.п.)
  • Покупки идут в накопления для получения скидочных карт лояльности Silver (5%) и Gold (10%)

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

Статья Программист Нет файла Бесплатно (free) Тестирование и исправление

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

04.10.2018    9085    ivanov660    23       

​​​​​​​CorelDRAW Graphics Suite 2019 Промо

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

Авто-восстановление "битых ссылок" при обменах с несколькими базами данных в режиме управляемых форм

Статья Системный администратор Программист Нет файла v8 v8::УФ 1cv8.cf Россия Бесплатно (free) Тестирование и исправление

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

31.07.2018    5101    SvkMaster    5       

1С: Сценарное тестирование 3.0. Запись и отладка интерактивного сценария

Статья Программист Нет файла v8 1cv8.cf Бесплатно (free) Тестирование и исправление

Конфигурация «Сценарное тестирование 3.0» (далее СТ) позволяет записывать интерактивные действия пользователей и формировать на их основании сценарий тестирования, который в последующем можно использовать в тестах. Рассмотрим это на примере.

07.11.2017    13309    user759624    7       

Программы для исполнения 488-ФЗ: Маркировка товаров Промо

1 января 2019 года вступил в силу ФЗ от 25.12.2018 № 488-ФЗ о единой информационной системе маркировки товаров с использованием контрольных (идентификационных) знаков, который позволяет проследить движение товара от производителя до конечного потребителя. Инфостарт предлагает подборку программ, связанных с применением 488-ФЗ и маркировкой товаров.

Окно "Зарегистрировано 0 изменений из 1 на узле "Имя узла""

Статья Системный администратор Программист Нет файла v8 1cv8.cf Бесплатно (free) Тестирование и исправление

Почему может появляться окно предупреждения "Регистрация изменений" с текстом " Зарегистрировано 0 изменений из 1 на узле "Имя узла" "" ? Как исправить проблему?

02.08.2017    18230    StudentM    3       

Рекурсия тестирования баз 1С. Когда однократного тестирования базы недостаточно

Статья Системный администратор Программист Нет файла v8 1cv8.cf Россия Windows Бесплатно (free) Тестирование и исправление

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

22.06.2017    8962    iskan    7       

Программы для исполнения 54-ФЗ Промо

С 01.02.2017 контрольно-кассовая техника должна отправлять электронные версии чеков оператору фискальных данных - правила установлены в 54-ФЗ ст.2 п.2. Инфостарт предлагает подборку программ, связанных с применением 54-ФЗ, ККТ и электронных чеков.

Отладка не работает, или отладка фоновых заданий

Статья Системный администратор Программист Нет файла v8 1cv8.cf Бесплатно (free) Тестирование и исправление

На написание данной статьи вдохновила статья http://infostart.ru/public/633522/ Я разработчик старой формации, до сих пор обслуживаю клиентов на платформах 7.7, 8.1, 8.2, времени изучать все мануалы и отслеживать новые тенденции не хватает. Цель этой статьи помочь разработчикам, таким же людям, как и я. Если эта статья сэкономит, хотя бы, 1 человеко-час жизни, значит, написана не зря.

16.06.2017    19978    IvanovAV    22       

Когда перестает работать отладчик

Статья Системный администратор Программист Нет файла v8 Россия Windows Бесплатно (free) Тестирование и исправление

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

13.06.2017    24909    mickey.1cx    20       

Готовые переносы данных из различных конфигураций 1C Промо

Рекомендуем готовые решения для переноса данных из различных конфигураций 1C. C техподдержкой от разработчиков и гарантией от Инфостарт.

Перенос данных из базы с поврежденными таблицами

Статья Системный администратор Программист Нет файла v8 БП2.0 Казахстан БУ УУ Бесплатно (free) Тестирование и исправление Обмен через XML Перенос данных из 1C8 в 1C8

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

06.06.2017    14096    ermek6    14       

1C:Предприятие для программистов: Расчетные задачи (зарплата). Онлайн-интенсив с 01 по 17 июня 2020 г. Промо

Данный онлайн-курс предусматривает изучение механизмов платформы “1С:Предприятие”, которые предназначены для автоматизации периодических расчетов, а именно - для расчета зарплаты. Курс предназначен для тех, кто уже имеет определенные навыки конфигурирования и программирования в системе “1С:Предприятие”, а также для опытных пользователей прикладного решения “1С:Зарплата и управление персоналом” и прочих прикладных решений, в которых реализован функционал расчета зарплаты.

4900 рублей

Ошибка формата потока. Решение с описанием проблемы

Статья Системный администратор Нет файла v8 1cv8.cf Россия Бесплатно (free) Тестирование и исправление

Ошибка формата потока. Страшная, но симпатишная своей загадочностью. 1С ничего толком не объясняет и не подсказывает. Ниже решение, которое мне помогает решать данную проблему на 100%. Всё очень просто. Данная ошибка возникает (на моей практике) только у клиент серверного варианта. просто потому что с другим форматом не работаю. Рекомендация: Старайтесь избегать динамического обновления, особенно если у вас возможны кратковременные проблемы с 220 и LAN. Далее описание лечения:

25.04.2017    24156    juker    1       

Ошибка в 1С: Не удается вставить повторяющуюся строку ключа в объект

Статья Системный администратор Программист Нет файла v8 1cv8.cf Бесплатно (free) Тестирование и исправление

В 1С может появиться ошибка такого рода: Ошибка при чтении изменений при обмене РИБ: Ошибка при вызове метода контекста (ПрочитатьИзменения): Попытка вставки неуникального значения в уникальный индекс: Microsoft SQL Server Native Client 11.0: Не удается вставить повторяющуюся строку ключа в объект "dbo._AccRgAT118760" с уникальным индексом "_AccR118760_ByPeriod_TRRRRN". Повторяющееся значение ключа: (ноя 1 5999 12:00AM, 0xab52f3e52b35efa847b0cfef9c90ff9d, 0x95eb00112f2a1abf11dac09f12116a47, NULL, NULL, NULL, NULL, 0). HRESULT=80040E2F, SQLSrvr: SQLSTATE=23000, state=1, Severity=E, native=2601, line=1 Техническая информация: Ошибка при чтении изменений при обмене РИБ: {ОбщийМодуль.ПроцедурыОбменаДанными.Модуль(1559)}: Ошибка при вызове метода контекста (ПрочитатьИзменения): Попытка вставки неуникального значения в уникальный индекс: Для ее решения делаем следующее:

18.04.2017    19103    tonn12    11