ГлавнаяБитриксБитрикс тест

1С Битрикс: ответы на тесты (сертификация битрикс). Битрикс тест


1С Битрикс: ответы на тесты (сертификация битрикс)

Добрый день уважаемые читатели.

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

Возможность создания интернет магазина посредством 1С Битрикс дает вам возможность объединить все ваши стремительные намерения в области моментального обслуживания продаваемых товаров бухгалтерией через 1С… Все дело в том что это эти два программных скрипта можно объединять и работать они могут как одно целое, это и практично и удобно по большому счету…

Не так давно пришлось в срочном порядке пополнить свою коллекцию сертификатов 1С Битрикс, для получения более высокого уровня компетенции, поэтому начал проходить онлайн сертификацию.

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

И так, на своем блоге решил выложить ответы на тесты 1с Битрикс.

Ниже будет список ссылок на 1С битрикс тесты, а соответственно каждая ссылка это ответы на данные тесты.

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

Список 1С Битрикс тестов:

1. Контент-менеджер. Элементы управления

2. Контент-менеджер. Информация на сайте и работа с ней

3. Контент-менеджер. Управление структурой

4. Контент-менеджер. Визуальный редактор

5. Контент-менеджер. Информационные блоки

6. Администрирование системы. Часть 2

Хотите увидеть новые тесты и ответы на них? — поделитесь в любой соц. сети или поставьте лайк!

joomlasecret.ru

Ответы на тест | Разработчик Bitrix Framework. Вступительный тест

Вопросы к тесту:

  1. Требуется ли в PHP в обязательном порядке объявлять тип переменной?
  2. Какое из условий будет истинно, если хотя бы одна из переменных true?
  3. Какая конструкция может использоваться для вывода текста?
  4. Как вывести на экран определенную ниже константу:
  5. Есть код: Что у нас будет выведено в результате работы кода?
  6. В каком случае в функции можно изменять значения переменной, заданное вне функции:
  7. Какие типы значения может вернуть функция инструкцией return?
  8. С помощью какой инструкции функция может вернуть значение?
  9. Есть код: Что будет выведено в результате работы кода.
  10. С помощью какой конструкции можно подключить файл в php?
  11. В каком варианте правильно объявляется массив?
  12. Какая конструкция позволяет включить файл только один раз, вне зависимости от количества вызовов?
  13. Что означает такое объявление функции:
  14. Какой код нужно использовать, если нам нужно вывести сообщение хотя бы один раз?
  15. С помощью какого цикла, можно выполнить обход массива?
  16. Какой оператор создан специально только для обхода массива
  17. Что означает запись:
  18. Найдите ошибку в данном коде:
  19. В каком случае на экран будет выведен текст "Версия Битрикс 12"?
  20. С помощью какой функции можно проверить, является ли переменная массивом?
  21. Что будет результатом работы кода:
  22. Какой максимальный уровень вложенности многомерных массивов
  23. Что будет выведено в результате работы кода?
  24. Как преобразовать значение переменной в целое число?
  25. Имеем массив: Как нам напрямую обратиться к элементу со значением "Don" и заменить значение его на "Volgo-Don"?
  26. Какой из операторов является условным?
  27. Что в цикле foreach будет в $a и $b?

Комментарии:

Комментировать могут только авторизованные пользователи.

bitrix100.ru

Автоматизированное тестирование проектов на 1С-Битрикс

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

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

Современный софт — не музейный экспонат, он постоянно меняется вместе с условиями работы компании.

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

Решение — автоматизированное тестирование и непрерывная интеграция (continuous integration).

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

Мы в отделе сопровождения сайтов в крупных проектах (Альфа-Банк, mybox, Издательство “Учитель”) освоили работу на основе автотестов и непрерывной интеграции.

Расскажем зачем это нужно, как работает и сколько стоит.

Идея автоматического тестирования сайтов

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

Хозяйке на заметку: Чтобы быть уверенным в корректности работы программы, нужно проверять её на отсутствие ошибок. В ответственных проектах enterprise-сегмента вопрос качества становится важнейшим. Сайт, портал, сервис, которому нельзя доверять — плохой продукт. В разработке программного обеспечения этот процесс называется тестированием.  При больших объемах работы тестирование нужно автоматизировать.

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

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

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

Тестирование по частям принято называть модульным или Unit-тестированием. Тестирование сценариев, которые позволяют пользователям решать определённые задачи (например, оформлять заказы), называется функциональным тестированием.

Мы расскажем о том, как внедрить оба вида тестирования в крупном проекте.

Модульное тестирование

Хозяйке на заметку: 

Для использования модульного тестирования весь проект должен разрабатываться как набор модулей и связей между ними. Автомобиль - система, состоящая из отдельных частей (ДВС, ГУР, климат-контроль и т.д). Это отдельные модули, работу которых можно проверить. Мясной фарш - не модульная система, хотя и состоит из отдельных частей.

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

Для модульного тестирования веб-проектов на 1С-Битрикс мы используем PHPUnit. Если проект запрограммирован аккуратно (с соблюдением принципов объектно-ориентированного программирования), PHPUnit позволяет быстро покрывать код тестами.

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

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

Из опыта: Для покрытия кода на 60% уходит 1/10 времени затраченного на разработку (5 дней пишем код, пол дня пишем тесты). Код считается “покрытым”, если в ходе тестирования он выполнялся хотя бы 1 раз, а лучше 2.

Функциональное тестирование

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

Сценарий оформления заказа:

  1. Открыть главную страницу

  2. Найти первый товар в списке и кликнуть на его название (или фото)

  3. Запомнить название товара

  4. Найти на странице кнопку с текстом “Купить” и нажать на неё

  5. Открыть страницу “Корзина”

  6. Проверить есть ли в корзине элемент с нужным названием (мы его запомнили на шаге 3)

  7. Найти кнопку “Оформить заказ” и нажать на неё

  8. Заполнить поля формы оформления заказа тестовыми данными (в поле “имя” ввести имя и т.д.)

  9. Найти кнопку “Отправить заказ” и нажать на неё

  10. Запомнить номер, присвоенный заказу

  11. Открыть список заказов и найти заказ с нужным номером

  12. Если заказ найден - тест пройден успешно

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

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

Проблемы: Любое изменение верстки требует внесения изменений в тесты. 

Из нашего опыта:   На создание теста для формы обратной связи уходит 2-4 часа.

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

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

Jenkins пришёл в веб из мира разработки десктопного программного обеспечения. Процесс превращения программы из исходных кодов в нечто исполняемое и вразумительное называется сборкой.

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

Шаги сборки

Создание независимой копии проекта

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

Синтаксический анализ

На этом этапе Jenkins проверяет код проекта на наличие синтаксических ошибок, а также ищет копипаст в коде.

Модульное тестирование

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

Функциональное тестирование

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

Построение отчётов и e-mail уведомления

На этом этапе Jenkins подбивает накопившуюся информацию о результатах тестирования и рассылает их по почте.

Важно:

Заключение, или “Сколько это стоит?” и “Что для этого нужно?”

Что нужно:

  1. Организовать сервер, на котором будет работать Jenkins.

  2. Купить сервер, на котором будут размещены виртуальные машины с разными операционными системами (+лицензии для операционных систем) и разными версиями браузеров

  3. Настроить VPN между серверами

  4. Установить и настроить Jenkins

  5. Написать тесты

Сколько стоит:

  1. Настройка серверов, установка операционных систем, установка и настройка Jenkins и прочих программных пакетов для среднего проекта — 40 часов работы.

  2. Разработка тестов — очень индивидуальная процедура, ее трудоемкость сильно зависит от конкретики. Например, автотест для проверки процедуры авторизации — 3 часа работы, тест оформления заказа с выбором первой системы оплаты и первой службы доставки 8 часов

Для каких веб-проектов нужно автоматическое тестирование и непрерывная интеграция

Веб-разработка по модели “continuous integration” с использованием автоматического тестирования требует заметных организационных и технических затрат.

В небольших, коротких и простых проектах это не окупается.

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

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

А это — качество.

Оцените статью:

Спасибо, ваш голос успешно добавлен!

www.intervolga.ru

[БУСТЕСТ] 🐱‍🏍Скрипт для тестирования сервера 1C Битрикс

Перед установкой 1С Битрикс на новый сервер/хостинг важно протестировать сервер по многим параметрам, необходимые для корректной установки и дальнейшей работы сайта.

Конкретно проверятся вообще все, что знаешь: PHP, MySQL, NGINX, APACHE, Память, Диск, Канал, Хосты, Почта, Требования 1С-Битрикс, Необходимые расширения, Необходимые тесты и др.

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

<?phpinfo()?>

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

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

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

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

БУСТЕСТ 1.0.0

БУСТЕСТ (BUSTEST) - скрипт для тестирования сервера, пока проверяет важные параметры PHP, MySQL, Hosts, выводит текущее состояние памяти и характеристики процессора.

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

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

Для работы некоторых тестов необходимы PHP-функции: exec, fsockopen, allow_url_fopen

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

Скрипт запускается одним файлом bustest.php, удобно закинуть на сервер и проверить, по сути это аналог скрипта Битрикса bitrix_server_test.php, только что-то более современное, визуально приятное и на основе моего опыта и знаний.

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

Память

В этом разделе просто выводится память сервера в Мегабайтах free -m

PHP

Тут буду дополнять инфу по PHP-параметрам, это блок хорошо доработан.

MySQL

Параметры сервера MySQL пока тестировал на трех VPS: 1Гб, 2 Гб, 4Гб оперативной памяти, пока весь этот раздел и будет изменяться.

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

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

Hosts

Тут выводится содержимое файла /etc/hosts на сервере, позже подробно напишу, что знаю, FQDN корректный там выводится.

Процессоры

Просто инфа по процессорам сервера

Файлы к статье

bustest v.1.0.0

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

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

tuning-soft.ru

Юнит-тестирование и Битрикс. Часть 1. – osotov

Про юнит-тестирование (его также называют модульным) уже очень много сказано. Вот его определение из википедии:

Модульное тестирование, или юнит-тестирование (англ. unit testing) — процесс в программировании, позволяющий проверить на корректность отдельные модули исходного кода программы.

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

Немного теории

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

one does not simply write a unit tests

Чтобы писать юнит-тесты, надо быть в курсе некоторых практик разработки. Следование этим практикам максимально упростит как написание, так и поддержку тестов.

Наверняка вы слышали о принципах SOLID (если нет, то самое время ознакомиться). Обратим внимание на первый принцип. Вот что об этом принципе пишет википедия:

В объектно-ориентированном программировании принцип единственной обязанности (англ. Single responsibility principle) обозначает, что каждый объект должен иметь одну обязанность и эта обязанность должна быть полностью инкапсулирована в класс. Все его сервисы должны быть направлены исключительно на обеспечение этой обязанности.

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

Перейдем к внедрению зависимостей (DI). Посмотрим, что пишет об этом википедия:

Внедрение зависимости (англ. Dependency injection, DI) — процесс предоставления внешней зависимости программному компоненту. Является специфичной формой «инверсии управления» (англ. Inversion of control, IoC), где изменение порядка связи осуществляется путём получения необходимой зависимости.

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

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

Подведем промежуточные итоги.

Что нужно знать перед тем, как написать свой первый тест? Требуется понимание ООП и практика его использования. Если вы не используете ООП и хотите писать модульные тесты, у меня для вас плохие новости.

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

Существует такая величина как покрытие тестами, она показывает насколько полно вы покрыли каждый аспект поведения класса тестами. Покрытие в 100% это, конечно, круто. Но! Это не значит, что нужно всегда стремиться к этому значению. Не забывайте о времени, потраченном на написание тестов. Важно собственное понимание того, достаточно ли тестов вы написали. Это приходит с опытом.

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

А какие плюшки даст модульное тестирование?

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

К менее очевидному, но не менее важному моменту я отношу повышение качества ООП архитектуры. В чем это выражается? При проектировании класса приходится задумываться о том как сделать его тестируемым. Это ведет к тому, что классы становятся проще, менее связанными (coupling) и более связными (cohesion) в лучших традициях SOLID. Все это, конечно, приходит с опытом, но на мой взгляд, оно того стоит. С точки зрения производительности, разработчик начинающий писать тесты, несомненно будет тратить больше времени, чем на разработку без тестов. Но в перспективе уже опытный разработчик суммарно будет более производителен, т.к. тесты будут писаться очень быстро, а время на отлов багов значительно сократится.

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

Очевидно, одной теории будет мало, поэтому во второй части я расскажу о том, как подготовиться к написанию первого теста и приведу пример в контексте Битрикса.

phpbitrixphpunittesting 14.09.2015

osotov.github.io

Prostoy-Site | Все права защищены © 2018 | Карта сайта