7 советов, как не взбесить коллегу-тестировщика в его праздник
Сегодня во всем мире отмечается день тестировщика. По этому случаю мы решили помочь вам взглянуть на работу этих специалистов с разных точек зрения, чтобы сотрудничество приносило всем участникам максимум пользы и минимум стресса.
Фото: David Goehring CC BY
1. «Перепроверь-ка еще разок, там точно нет бага»
Начнем с фундаментальной проблемы. На форуме Ars Technica есть старая ветка, в которой один разработчик рассказывает о глубокой ненависти к «педантичным» тестировщикам. Его ужасно раздражает, что некоторые специалисты по тестированию тратят часы на поиск мельчайших багов. И что самое неприятное, они их всё-таки находят.
Что может пойти не так: Не все готовы признавать свои ошибки. Кто-то заводит старую песню про «не баг, а фича», пытаясь доказать, что всё так и задумывалось. Другие упорно просят перепроверить код и убедиться, что бага нет. Тестировщик же просто старается хорошо делать свою работу, а вместо благодарности его отправляют на перепроверку.
Как быть: Всё просто: если тестировщик нашел недочет в вашем коде и вы понимаете, что он прав, лучше признать этот факт. У вас обоих одна и та же цель — выпустить отлаженный и работающий продукт. Юмор помогает прийти к взаимопониманию в этом вопросе. Вот статья, в которой тестировщики собрали «золотой фонд» высказываний разработчиков, пытающихся защитить свой код. Советуем пробежаться по ним и представить, как эти «классические» фразы звучат с точки зрения тестировщика.
2. «До релиза неделя. Надеюсь, на ближайшие два дня ты не планировал других дел»
Иногда код приходит к тестировщикам за несколько дней до релиза. Тогда им приходится работать в аврале. Некоторые QA-специалисты считают, что коллеги просто недооценивают их труд. Якобы они думают, что поиск багов — это легко и быстро, поэтому откладывают отладку на последний момент.
Что может пойти не так: В условиях авральной работы тестировщики не только раздражаются, но и теряют бдительность. Нехватка времени — одна из главных причин, по которой тестеры пропускают баги.
Как быть: Есть несколько моделей разработки. С точки зрения QA различают два основных подхода: каскадный и Agile. В первом случае тестировщики получают фрагменты кода поэтапно. Во втором случае они тестируют код параллельно с его написанием.
Agile помогает вовлечь QA-специалистов в проект на ранних этапах. Благодаря этому не приходится тестировать «за час до релиза». Кроме того, такой подход позволяет не отыскивать баги, а предотвращать их появление. Если ваши тестировщики жалуются на постоянный цейтнот и пропускают баги, присмотритесь к этой методологии.
Фото: Tim Regan CC BY
3. «Я быстренько подправил код. Посмотри, пожалуйста»
Допустим, ваша команда работает по каскадной модели и умеет грамотно планировать фазы разработки. Тестировщики получают код, и времени на отладку вроде бы хватает. Но у разработчиков есть привычка прилагать на этом этапе минимум усилий. Они получают подробный баг-репорт, поверхностно его читают, быстро устраняют очевидные ошибки и отправляют код на следующий цикл тестов.
Что может пойти не так: Проблема в том, что код после поверхностных изменений зачастую возвращается с еще большим количеством багов. Тестировщик тратил время на составление подробного отчета, а в ответ на него получил какую-то отписку. Ему предстоит пройти этот путь ещё несколько раз только потому, что разработчик не хочет тратить время на «незначительные баги».
Как быть: Очевидно, не стоит торопиться. Но этого мало. Нужно разобраться, почему вы не уделяете должное внимание отчету. Если это банальная лень, помочь себе можете только вы. Бывают и другие причины. Например, вы считаете, что QA-инженеры заваливают вас отчетами о малозначимых багах. Тогда нужно прояснить этот вопрос на уровне руководства — должны ли тестеры отвлекать вас «по мелочам». Скорее всего, ответ будет положительный. Некоторые продакт-менеджеры даже просят разработчиков специально добавлять в код мелкие баги, чтобы тестировщики были всегда настороже. Важно принять этот подход и относиться к баг-репортам с должным вниманием.
4. «Кажется, я уже разобрался с этим багом. Но точно не помню»
Иногда поверхностный подход — это системная проблема. В некоторых командах баг-репорты теряются во времени и пространстве. Никто не реагирует на отчеты должным образом, не помечает, решена ли проблема или всё еще находится в подвешенном состоянии.
Что может пойти не так: Разработчики устраняют какой-то баг, вносят, как им кажется, «незначительные» изменения в код, забывают уведомить об этом тестировщиков и отсылают код на релиз. В итоге проблема всплывает, когда уже слишком поздно. И «крайним» зачастую оказывается тестировщик.
Как быть: Проблему хаоса нужно решать системно. Беспорядок вредит разработке, поэтому придется полностью перестроить процесс коммуникаций в команде. Здесь стоит воспользоваться базовыми советами по налаживанию коммуникации между разработчиками и QA-инженерами: определиться с терминологией; понятно формулировать требования; ввести иерархию приоритетности для различных багов. Что касается путаницы с багами, есть хорошие практические советы: а) пусть баги репортят все; б) далее их важно приоретизировать; в) любой закрытый баг подразумевает, что будет написан функциональный тест; г) статус «решено» присваивает не разработчик, а тестировщик. Этот подход гарантирует, что проблема действительно будет решена.
Фото: Tim Regan CC BY
5. «Почему это я должен тестировать? Я же не тестировщик!»
В некоторых командах ответственность за отладку всецело лежит на тестировщиках. Разработчики не утруждают себя тратой времени на самые очевидные unit-тесты. Они уверены, что это не их работа. По большому счету, так и есть, хотя существуют разные точки зрения на вопрос (с мнениями сообщества можно ознакомиться здесь).
Что может пойти не так: Тестировщикам в такой ситуации приходится разбираться со всеми недочетами подряд — даже с самыми примитивными и глупыми ошибками. Разумеется, это раздражает.
Как быть: Многие разработчики выступают за самостоятельные тесты перед отправкой в QA-отдел. Это помогает не только разгрузить тестировщиков, но и научиться смотреть на продукт с точки зрения критика и пользователя. Есть мнение, что это полезно для профессионалов и лучшим образом сказывается на конечном результате. Для тех, кто не хочет себя утруждать проверками, есть автоматические инструменты. Они помогают найти самые очевидные баги. В любом случае — даже если в команде есть QA-инженеры, жесткое разделение на разработчиков и QA — не самый оптимальный подход.
6. «Игорь, сегодня работаешь в паре с Олегом. Тебе понравится»
Продакт-менеджеры не ограничиваются каскадным подходом и Agile. Некоторые из них любят экспериментировать. Например, устраивать сеансы парного программирования и тестирования.
Что может пойти не так: Это эффективный способ отлавливания багов, но у него есть и минусы — люди могут быть не в восторге от нововведений. QA-специалисту, привыкшему работать в одиночку, на другом этаже и на своем оборудовании, может быть попросту некомфортно покидать привычную среду. К тому же его может банально не устраивать опыт и знания напарника. В итоге вместо результативных тестов продакт-менеджеры получают двух недовольных работников.
Как быть: Главный совет — не рубить с плеча. Agile- и DevOps-практики могут казаться привлекательными, но без должной подготовки не дадут результата.
7. «Я возьму твой девайс для тестов, ты же не против?»
У разработчика появляется время заняться отладкой, он просит у тестировщика девайс для тестов «буквально на 20 минут» и удаляется с ним на долгие часы.
Что может пойти не так: Чаще всего разработчик вообще не возвращает устройство на место, а если и возвращает, то полностью разряженным. Учитывая, что у тестировщиков могут быть параллельные задачи на этом устройстве, такое не может не раздражать.
Как быть: Ставьте себе напоминания, клейте стикеры, делайте что угодно, но, пожалуйста, возвращайте вещи тестировщиков на место и в срок.
Фото: Dave Allen CC BY
И главный совет разработчикам и продакт-менеджерам, который напрашивается сам собой из всех предыдущих: уважайте чужой труд и время, и как можно чаще ставьте себя на место тестировщика. Ведь если бы не он, весь мир знал бы о ваших багах.
habr.com
День тестировщика — праздник 9 сентября, профессия тестировщика
Праздники — неизменные спутники народной жизни. Праздники для нас — это возможность доставить радость близким! И уж конечно, праздник — не календарное понятие, он происходит там, где его чувствуют, где его ждут. За последние годы в нашей жизни многое изменилось, но тяга людей к праздникам остается важным явлением любого человека.
Праздник «День тестировщика» является международным и отмечается он ежегодно 9 сентября. Хотя, День тестировщика и не стал пока официальным, но его могут отмечать все, кто имеет отношение к этой профессии.
Содержание статьи:
История праздника День тестировщика
День тестировщика — прекрасный повод заглянуть на страничку истории.
Нужно сказать, что дата празднования Дня тестировщика была выбрана совсем неслучайно. В 1945 году именно в этот день произошло одно знаменательное событие в мире компьютерной техники. Оно заключалось в том, что ученые Гарвардского университета официально зарегистрировали первый в истории баг. А случилось это во время тестирования одной из вычислительных машин. Тогда ими был обнаружен настоящий мотылек, случайно попавший между контактами электромеханического реле. Оказалось, что он и стал причиной выхода машины из строя.
Ученые даже сделали об этом событии запись в свой техдневник. Проделанную работу они записали как «debugging», что можно дословно перевести с английского как «избавление от насекомого». С тех пор так стали называть процесс обнаружения и избавления от сбоев в работе компьютера.
Нужно отметить, что тот знаменитый мотылек был передан в музей вычислительной техники, где он и хранится до сих пор. Под его стендом имеется надпись, которая гласит, что этот мотылек стал первым из обнаруженных багов в истории компьютерной техники. С тех пор это слово стало широко использоваться компьютерщиками во всем мире. А тот день, когда насекомое было обнаружено, решено было сделать профессиональным праздником всех тестировщиков.
Однако есть данные о том, что этот термин использовался и до этого. По крайне мере, исследователям удалось отыскать письмо знаменитого американского изобретателя Т. Эдисона, в котором уже фигурировало данное слово. Оказалось, что еще в 1878 году он употреблял слово «баг» в том же самом значении.
Отмечается День тестировщика и в России, но пока в нашей стране о нем мало кто знает.
Профессия и работа тестировщика
Работа тестировщика заключается в проверке программного обеспечения (ПО). Нужно сказать, что еще недавно в России эту работу воспринимали как подработку на время учебы или как место для программистов-неудачников. Однако прошло некоторое время и все убедились в важности качества ПО. После этого данная профессия начала набирать популярность. В настоящее время она является достаточно престижной и востребованной.
Настоящий тестировщик или тестер должен обладать большим набором знаний и навыков. Без этого просто невозможно осуществлять оптимальный контроль качества программного обеспечения. Такой специалист должен также уметь выполнять несколько разных функций одновременно. С одной стороны, он должен мыслить как разработчик программного продукта, анализируя поведение системы и полученные результаты. С другой стороны, тестировщик должен мыслить и как пользователь этого же продукта.
Если говорить проще, то такой специалист ищет причины неправильной работы компьютера.
Работа эта непростая и серьезная. Требует от человека внимания, усидчивости, терпения. Необходимо отметить, что такая работа требует от человека хорошо развитого умения мыслить логически, отличной памяти, умения быстро обучаться и приспосабливаться к существующим задачам. Очень важно также и уметь работать в команде. Кроме того, тестировщик должен обладать определенным аналитическим складом мышления. Своим трудом эти специалисты заслужили свой праздник День тестировщика.
Основной задачей тестировщика можно назвать обнаружение вероятных проблем и неполадок в функционировании программы. Он занимается также моделированием различных ситуаций, возникновение которых возможно во время использования программы. Это позволяет разработчикам исправить обнаруженные ошибки и устранить все недочеты.
Этот специалист должен также создавать и использовать разнообразные входные данные, которые были и не были предусмотрены создателями программы.
По мнению многих людей, специфика данной профессии заключается в ее монотонности и видимом однообразии трудового процесса. Однако существует мнение об этой профессии как о творческой исследовательской работе, если сравнивать со стандартизированной разработкой.
Одной из главных особенностей данной профессии можно назвать то, что она дает возможность удаленной работы. При этом расстояние может не иметь никакого значения.
Тестировщик может находиться даже в другой стране. Поэтому такая работа часто является промежуточным этапом, который позволяет накопить достаточно знаний и опыта в удалённой разработке ПО.
Может возникнуть вопрос, какое образование необходимо получить будущему тестировщику. Данной профессии не обучают ни в одном из ВУЗов нашей страны. Поэтому тем, кто хочет работать по данной специальности, необходимо закончить факультет, связанный с программированием и разработкой программного обеспечения.
Соискатель должен обладать базовыми навыками программирования, администрирования операционных систем и уметь работать с базами данных. Процесс тестирования подразумевает использование различных подходов и практик, даже требует применения дедукции. При этом важно уметь правильно комбинировать доступные методы тестирования.
Требуются также знания основных технологий построения программного обеспечения. Требования к уровню необходимых навыков и специализации при этом могут различаться в зависимости от поставленных перед тестировщиком задач.
В последнее время этой профессии уделяется все больше внимания. Начало появляться все больше материалов о тестировании и качестве ПО, выпускаются специализированные книги, развиваются сайты, посвящённые этому направлению. Появляются также форумы тестировщиков.
Тестировщики сегодня являются очень востребованными специалистами на рынке труда. Их зарплаты часто даже превышают зарплату программистов.
Нужно сказать, что данная профессия появилась в нашей стране совсем недавно. Самыми первыми тестировщиками принято считать специалистов по качеству, которые занимались проверкой программного обеспечения на соответствие ГОСТам. Однако обязанности современного тестировщика с тех пор существенно расширились.
Мы поздравляем тестировщиков с их праздником, с Днем тестировщика!
Статья защищена законом об авторских и смежных правах. При использовании и перепечатке материала активная ссылка на женский сайт www.inmoment.ru обязательна!
Теги: праздник 9 сентября, День тестировщика
www.inmoment.ru
7 советов, как не взбесить коллегу-тестировщика в его праздник
Сегодня во всем мире отмечается день тестировщика. По этому случаю мы решили помочь вам взглянуть на работу этих специалистов с разных точек зрения, чтобы сотрудничество приносило всем участникам максимум пользы и минимум стресса.
Фото: David Goehring CC BY
1. «Перепроверь-ка еще разок, там точно нет бага»
Начнем с фундаментальной проблемы. На форуме Ars Technica есть старая ветка, в которой один разработчик рассказывает о глубокой ненависти к «педантичным» тестировщикам. Его ужасно раздражает, что некоторые специалисты по тестированию тратят часы на поиск мельчайших багов. И что самое неприятное, они их всё-таки находят.
Что может пойти не так: Не все готовы признавать свои ошибки. Кто-то заводит старую песню про «не баг, а фича», пытаясь доказать, что всё так и задумывалось. Другие упорно просят перепроверить код и убедиться, что бага нет. Тестировщик же просто старается хорошо делать свою работу, а вместо благодарности его отправляют на перепроверку.
Как быть: Всё просто: если тестировщик нашел недочет в вашем коде и вы понимаете, что он прав, лучше признать этот факт. У вас обоих одна и та же цель — выпустить отлаженный и работающий продукт. Юмор помогает прийти к взаимопониманию в этом вопросе. Вот статья, в которой тестировщики собрали «золотой фонд» высказываний разработчиков, пытающихся защитить свой код. Советуем пробежаться по ним и представить, как эти «классические» фразы звучат с точки зрения тестировщика.
2. «До релиза неделя. Надеюсь, на ближайшие два дня ты не планировал других дел»
Иногда код приходит к тестировщикам за несколько дней до релиза. Тогда им приходится работать в аврале. Некоторые QA-специалисты считают, что коллеги просто недооценивают их труд. Якобы они думают, что поиск багов — это легко и быстро, поэтому откладывают отладку на последний момент.
Что может пойти не так: В условиях авральной работы тестировщики не только раздражаются, но и теряют бдительность. Нехватка времени — одна из главных причин, по которой тестеры пропускают баги.
Как быть: Есть несколько моделей разработки. С точки зрения QA различают два основных подхода: каскадный и Agile. В первом случае тестировщики получают фрагменты кода поэтапно. Во втором случае они тестируют код параллельно с его написанием.
Agile помогает вовлечь QA-специалистов в проект на ранних этапах. Благодаря этому не приходится тестировать «за час до релиза». Кроме того, такой подход позволяет не отыскивать баги, а предотвращать их появление. Если ваши тестировщики жалуются на постоянный цейтнот и пропускают баги, присмотритесь к этой методологии.
Фото: Tim Regan CC BY
3. «Я быстренько подправил код. Посмотри, пожалуйста»
Допустим, ваша команда работает по каскадной модели и умеет грамотно планировать фазы разработки. Тестировщики получают код, и времени на отладку вроде бы хватает. Но у разработчиков есть привычка прилагать на этом этапе минимум усилий. Они получают подробный баг-репорт, поверхностно его читают, быстро устраняют очевидные ошибки и отправляют код на следующий цикл тестов.
Что может пойти не так: Проблема в том, что код после поверхностных изменений зачастую возвращается с еще большим количеством багов. Тестировщик тратил время на составление подробного отчета, а в ответ на него получил какую-то отписку. Ему предстоит пройти этот путь ещё несколько раз только потому, что разработчик не хочет тратить время на «незначительные баги».
Как быть: Очевидно, не стоит торопиться. Но этого мало. Нужно разобраться, почему вы не уделяете должное внимание отчету. Если это банальная лень, помочь себе можете только вы. Бывают и другие причины. Например, вы считаете, что QA-инженеры заваливают вас отчетами о малозначимых багах. Тогда нужно прояснить этот вопрос на уровне руководства — должны ли тестеры отвлекать вас «по мелочам». Скорее всего, ответ будет положительный. Некоторые продакт-менеджеры даже просят разработчиков специально добавлять в код мелкие баги, чтобы тестировщики были всегда настороже. Важно принять этот подход и относиться к баг-репортам с должным вниманием.
4. «Кажется, я уже разобрался с этим багом. Но точно не помню»
Иногда поверхностный подход — это системная проблема. В некоторых командах баг-репорты теряются во времени и пространстве. Никто не реагирует на отчеты должным образом, не помечает, решена ли проблема или всёе еще находится в подвешенном состоянии.
Что может пойти не так: Разработчики устраняют какой-то баг, вносят, как им кажется, «незначительные» изменения в код, забывают уведомить об этом тестировщиков и отсылают код на релиз. В итоге проблема всплывает, когда уже слишком поздно. И «крайним» зачастую оказывается тестировщик.
Как быть: Проблему хаоса нужно решать системно. Беспорядок вредит разработке, поэтому придется полностью перестроить процесс коммуникаций в команде. Здесь стоит воспользоваться базовыми советами по налаживанию коммуникации между разработчиками и QA-инженерами: определиться с терминологией; понятно формулировать требования; ввести иерархию приоритетности для различных багов. Что касается путаницы с багами, есть хорошие практические советы: а) пусть баги репортят все; б) далее их важно приоретизировать; в) любой закрытый баг подразумевает, что будет написан функциональный тест; г) статус «решено» присваивает не разработчик, а тестировщик. Этот подход гарантирует, что проблема действительно будет решена.
Фото: Tim Regan CC BY
5. «Почему это я должен тестировать? Я же не тестировщик!»
В некоторых командах ответственность за отладку всецело лежит на тестировщиках. Разработчики не утруждают себя тратой времени на самые очевидные unit-тесты. Они уверены, что это не их работа. По большому счету, так и есть, хотя существуют разные точки зрения на вопрос (с мнениями сообщества можно ознакомиться здесь).
Что может пойти не так: Тестировщикам в такой ситуации приходится разбираться со всеми недочетами подряд — даже с самыми примитивными и глупыми ошибками. Разумеется, это раздражает.
Как быть: Многие разработчики выступают за самостоятельные тесты перед отправкой в QA-отдел. Это помогает не только разгрузить тестировщиков, но и научиться смотреть на продукт с точки зрения критика и пользователя. Есть мнение, что это полезно для профессионалов и лучшим образом сказывается на конечном результате. Для тех, кто не хочет себя утруждать проверками, есть автоматические инструменты. Они помогают найти самые очевидные баги. В любом случае — даже если в команде есть QA-инженеры, жесткое разделение на разработчиков и QA — не самый оптимальный подход.
6. «Игорь, сегодня работаешь в паре с Олегом. Тебе понравится»
Продакт-менеджеры не ограничиваются каскадным подходом и Agile. Некоторые из них любят экспериментировать. Например, устраивать сеансы парного программирования и тестирования.
Что может пойти не так: Это эффективный способ отлавливания багов, но у него есть и минусы — люди могут быть не в восторге от нововведений. QA-специалисту, привыкшему работать в одиночку, на другом этаже и на своем оборудовании, может быть попросту некомфортно покидать привычную среду. К тому же его может банально не устраивать опыт и знания напарника. В итоге вместо результативных тестов продакт-менеджеры получают двух недовольных работников.
Как быть: Главный совет — не рубить с плеча. Agile- и DevOps-практики могут казаться привлекательными, но без должной подготовки не дадут результата.
7. «Я возьму твой девайс для тестов, ты же не против?»
У разработчика появляется время заняться отладкой, он просит у тестировщика девайс для тестов «буквально на 20 минут» и удаляется с ним на долгие часы.
Что может пойти не так: Чаще всего разработчик вообще не возвращает устройство на место, а если и возвращает, то полностью разряженным. Учитывая, что у тестировщиков могут быть параллельные задачи на этом устройстве, такое не может не раздражать.
Как быть: Ставьте себе напоминания, клейте стикеры, делайте что угодно, но, пожалуйста, возвращайте вещи тестировщиков на место и в срок.
Фото: Dave Allen CC BY
И главный совет разработчикам и продакт-менеджерам, который напрашивается сам собой из всех предыдущих: уважайте чужой труд и время, и как можно чаще ставьте себя на место тестировщика. Ведь если бы не он, весь мир знал бы о ваших багах.
Автор: Андрей Пшеничнов
Источник
www.pvsm.ru
Как получить качественные котировки для тестера MetaTrader 4
В области торговли на финансовых рынках нельзя сделать заключение о работоспособности или непригодности того или иного метода или системы без качественных данных для тестов и оптимизации. Для разработки действительно прибыльных торговых систем трейдеру обязательно потребуются, как минимум, качественные исторические ценовые данные по интересующим валютным парам.
Как правило, у большинства брокеров качество котировок колеблется в районе от 90 до 96%. Терминал MT4 и так не слишком точный инструмент, поэтому добавлять еще 4-10% лишней неточности — не наш вариант. Наш выбор — котировки 100% качества. Где и каким образом их взять, как обработать и получить гарантированно качественный результат — в нашем сегодняшнем материале.
Типы исторических данных
Основной тип исторических данных, без которого просто не получится провести тестирование – это, естественно, данные по ценам. Исторические ценовые данные могут быть получены для различных периодов и из разных источников. Наиболее распространенные – для дневных, минутных и тиковых графиков. Как правило, глубже всего история именно для дневных графиков – ее можно получить, начиная с 1971 года (более длительную историю не поддерживает терминал MetaTrader). Минутные данные, как правило, идут максимум с 1999 — 1998 года, а тики в основном не ранее, чем с 2004 — 2007 года.
Как правило, для любого периода данные выглядят следующим образом: дата свечи, время, цена открытия, наивысшая цена, наинизшая цена, цена закрытия и тиковый объем. В некоторых источниках котировок тиковый объем может отсутствовать. Также для периодов от D1 и выше часто не указывают время открытия свечи или же не указывают максимальные и минимальные цены. Тиковые котировки отличаются от котировок, сконвертированных в определенный период. В таких котировках вы можете найти дату, время с точностью до секунд, цены Ask и Bid.
Помимо цены иногда могут понадобиться и некоторые специфические данные – например по выходу макроэкономических показателей, вроде уровня инфляции, цен на жилье или данных по безработице определенных стран, а также еще более специфические, вроде солнечной активности или мнения трейдеров относительно того или иного инструмента.
Вообще же, как правило, поиск необычных данных часто открывает интересные и выгодные возможности, на которых можно построить свою систему торговли и получать прибыль. У нас на форуме есть торговый робот, который анализирует данные из myfxbook об открытых трейдерами позициях и работает против них.
Временные масштабы данных
Данные можно использовать в своих естественных временных рамках, или же пересчитать их в другой временной масштаб. В зависимости от стратегии вам могут потребоваться различные таймфреймы, от М1 или даже тиков, до D1 или MN1. Из данных коротких таймфреймов можно легко сделать данные более длинных, но никак не наоборот. Например, из данных периода М1 мы легко можем получить и М5, и Н1, и D1. Именно поэтому важно иметь качественную базу данных именно М1 котировок.
Но М1 – не самый мелкий масштаб, ведь есть еще и тиковые данные. Тик – это не постоянная единица времени, иногда тики бывают очень частыми, особенно во время выхода новостей, а иногда, например, ночью, имеют большие временные промежутки друг между другом. Тиковая история в основном необходима для тестирования новостных советников, hft стратегий (использование которых вообще невозможно на платформе МТ4 или МТ5), а также для советников, использующих различные расчеты внутри свечей.
Но для таких советников слишком велико влияние брокеров, о чем я писал в этой статье. Если советник не пипсует по полпункта, нет никакой нужды тестировать его на тиковых данных – это очень долго и ресурсозатратно. К тому же бесплатные тиковые данные, которые можно найти в сети, не самого хорошего качества и за не слишком длительный период времени, а платные стоят довольно приличных денег – далеко не факт, что такие вложения вообще у вас окупятся.
Поэтому не стоит гнаться за сверхточностью, сам тестер стратегий все равно даст погрешность, которая все усилия нивелирует. Лучше запастись качественной историей минутного таймфрейма, дневного таймфрейма и различными специфическими данными, которые вам встретятся – никогда нельзя быть уверенным наверняка в том, что вам пригодится, а что нет.
Сколько нужно данных? Чем больше, тем лучше. Дело в том, что чем больше сделок в тесте, тем меньше риск «подгонки», тем более статистически весомый результат и тем больше вероятность того, что ваша система продолжит работать так же в будущем, как работала в прошлом. Поэтому очень желательно использовать всю доступную историю.
Выбор таймфрейма
Что касается таймфрейма, используемого для работы, то тут дело вкуса. При работе на низких периодах вроде М5 или М15, уходит много времени на тесты, к тому же такие системы очень требовательны к качеству котировок, сильно брокерозависимы и на конечный результат прилично влияют издержки, такие как спред, свопы, проскальзывания, комиссии.
С другой стороны, торговля при помощи подобных систем более динамична, ведь они могут совершать десятки сделок в день. Из-за относительно коротких стопов можно обойтись депозитом всего в 100 долларов. Как следствие, прирост депозита, как правило, более стремительный, чем у долгосрочных систем. Хотя и чаще всего более короткий – чем ниже период работы системы, тем она получается, как правило, менее стабильной.
При работе на высоких периодах, наоборот, системы получаются более стабильными и живучими, слабо зависят от брокера и от торговых издержек, не очень требовательны к качеству котировок, да и тесты можно делать очень быстро. Тем не менее, прирост депозита довольно долгий, так как каждая сделка может длиться неделями.
Еще одна проблема – для долгосрочных систем необходимо достаточно большое количество исторических данных. Плюс на тех же дневных графиках стопы даже размером в два ATR получаются порой довольно большими, и чтобы соблюдать правильный мани менеджмент может не хватить и 2 000 долларов. Кроме того, при работе на высоких таймфреймах, как правило, используют портфели систем, чтобы сгладить кривую доходности. Тем не менее, выдерживать психологически десятки открытых сделок, болтающихся то в плюс, то в минус целыми неделями — довольно нелегко.
Выбор таймфрейма – это все же личное дело каждого трейдера. На любом из них есть свои плюсы и минусы, поэтому стоит просто решить, что вас раздражает больше.
Качество исторических данных
Одной из распространенных причин получения недостоверных результатов при тестировании советника в тестере стратегий терминала MetaTrader 4 являются проблемы с целостностью исторических котировок. В силу разных причин в истории цен, имеющейся в наличии в терминале, могут присутствовать «дыры», которые приводят к разрывам в ценовом потоке, не имеющим ничего общего с реальностью. Надо ли говорить, что тестировать советник по таким котировкам не имеет большого смысла?
Плохие данные могут любой анализ системы привести в состояние полного хаоса, дать убыточные заключения стоящим системам или, что еще хуже, дать зеленый свет системам, которые того не стоят. Поэтому к историческим данным стоит подойти со всей ответственностью – это база, на которой в дальнейшем будет строиться вся ваша торговля. Некачественная историческая база может систематически приводить к ошибкам и, как следствие, к потере уймы времени и средств, причем вы так и не будете понимать, в чем же, собственно, проблема и почему ваши системы, зарабатывающие на тестах, не хотят работать на реале.
Ошибки в данных могут принимать несколько различных форм. Довольно часто при торговле попадаются тики с явно ошибочными ценами, просто невозможными. Например, цена на секунду взлетает до небес, а затем, в следующую секунду, возвращается обратно. Это так называемая «шпилька», которыми еще буквально несколько лет назад грешили почти все брокеры. Такая ошибка может привести к сделке с огромной прибылью или убытком. А если таких «шпилек» в данных много, то тест любой системы будет далек от реальности. Особенно это касается тестов различных сеточных стратегий, где «шпилька» — это гарантированный слив депозита, и, как следствие, тест не проходит фильтр.
Более распространены и менее заметны обычные небольшие ошибки в уровнях цен. Например, вместо цены закрытия 1.4378 у нас имеется цена 1,4387. Естественно, такую ошибку заметить сложно, особенно если она на высоком таймфрейме. Благо, чаще всего они не сильно влияют на результаты тестов, хотя бывают и исключения. Поэтому стоит сверять котировки от нескольких разных поставщиков, чтобы получить максимально достоверные цены.
Ну и самая распространенная ошибка — это пропуск данных. Просто по каким-то причинам определенный отрезок времени в базу не записывается, образуя разрывы котировок. Чаще всего такая проблема встречается в праздники, на Новый Год и в ночные периоды. Чем «дырявее» график, тем меньше реальности в тестах. Эта проблема также решается заполнением пробелов из других источников.
Как вы уже поняли, при тестировании советников вопрос формирования качественного архива котировок выступает в качестве задачи номер один. Но, к сожалению, терминал MT4 не имеет встроенных средств для проверки целостности исторических данных, поэтому приходится использовать вспомогательные инструменты, которые восполняют этот досадный пробел в оснащении платформы.
Какими, на мой взгляд, должны быть качественные исторические данные?
Качественные исторические данные формируются из баров периода М1. Все, что выше, дальше отодвигает нас от точности воспроизведения поведения советника. При формировании истории котировок лучше всего использовать котировки М1. Более того, в идеале тестирование советников лучше всего проводить по котировкам М1. При этом необходимо убедиться, что в самом коде советника жестко заданы периоды, а не выставлен период по умолчанию (Period()), иначе вы получите совсем не те результаты, на которые рассчитывали, ведь алгоритм будет работать не так, как планировалось.
Также стоит помнить, что советник просто обязан работать именно на открытии свечи. Для этого, как правило, в код советника прописывают специальную функцию, которая разрешает торговлю только когда открывается новая свеча заданного таймфрейма. Для того, чтобы делать надежные тесты не по закрытию свечи, вам будут нужны качественные тики и специальный софт, позволяющий проводить такие тесты. Если этого у вас нет — терминал будет сам придумывать то, что творилось внутри свечей. Сами понимаете — он может напридумывать все, что угодно.
Такие данные не имеют существенных провалов, то есть так называемых «дыр». Это зависит в первую очередь от поставщика котировок – насколько бесперебойно работало оборудование, сохраняющее исторические данные.
Такие котировки не имеют пропусков единичных или нескольких баров. В идеале нужно иметь стопроцентную полноту котировок (не путать с качеством моделирования). 100% полнота истории минутных котировок, на мой взгляд, необходима потому, что из минутки формируются последующие таймфреймы и отсутствие некоторых минутных баров, в конечном итоге, порождает «кривые» бары более высоких таймфреймов.
Сразу хочу обратить внимание, что мало в каком ДЦ есть собственная длительная история котировок в открытом доступе, особенно это касается котировок маленьких таймфреймов. О том, где можно взять исторические данные, мы говорили в этой статье.
Анализ дыр на истории котировок
Узнать качество графика поможет скрипт history_data_analysis.
Этот код выявляет в данных истории отсутствующие бары («дыры») и разрывы (большие дыры), определяет их размер, длительность и гэп. Работает на всех инструментах и предназначен для внутредневных графиков, поэтому таймфрейм ограничен периодом h5.
При анализе учитываются только выходные дни (суббота и воскресение — 48 часов), остальные моменты код считает дырами или разрывами. Для удобства работы на графике в коде предусмотрен фильтр, где можно задать количество отсутствующих баров на таймфреймах (M1,5,15,30), которые код будет игнорировать как дыры, количество отсутствующих баров (минимальное значение), которое код считал бы разрывом (по умолчанию 20 баров), а также количество отсутствующих пипсов, которые код будет игнорировать как гэп. После запуска скрипта и окончания его работы вы увидите сообщение:
Для примера я провел тестирование качества котировок пары EURUSD Alpari:
Ну и для примера сделаем такой же тест для котировок Dukascopy EURUSD M1:
Как вы можете убедиться, использовать для тестирования лучше всего данные от Dukascopy — общее качество котировок тут находится в районе 99,55%. Всего 0,45% пропусков и разрывов, очень неплохой результат. Тем не менее, у нас по-прежнему 4662 разрыва – не хватает почти двадцать пять тысяч баров и целых 39740 пунктов. А поэтому — для максимально достоверных тестов эту проблему придется устранять.
Доведение качества котировок до 100%
1. Я рекомендую для базовой истории котировок использовать данные от Ducaskopy, в них мало всего дыр и их потом меньше придется «латать». Для этого можно воспользоваться любой вспомогательной программой, которая загружает тики Ducaskopy. Я рекомендую Tickstory Lite.
2. После закачки тиков в программе Tickstory Lite, нажмите правой кнопкой мыши на интересующей вас валютной паре и выберите пункт «Экспорт в файл»:
3. Заполните поля с настройками:
4. Откройте каталог данных:
5. В каталоге данных находим папку history, затем находим нужную папку по названию нашего сервера:
6. Удаляем все hst файлы нужной валютной пары.
7. Экспортируйте скачанные котировки в терминал, нажав F2, выбрав нужную валютную пару, период М1 и нажав кнопку «Импорт»:
8. Откройте график валютной пары периода М1.
9. Проведите тест качества при помощи скрипта history_data_analysis. По полученному в результате тестирования текстовому файлу нужно найти наиболее критичные места. Затем эти критичные места удаляются. Их мы будем позже восполнять котировками из других источников (ставить так называемые «заплатки»).
Хочу отдельно обратить ваше внимание на отсутствие котировок во время новогодних праздников – многие брокеры в это время просто не работают, а те источники, брокеры которых работают, в канун нового года похожи на решето и найти сколь-нибудь адекватную историю за этот период бывает очень сложно. Поэтому ничего сильно страшного не случится, если пара дней в канун нового года просто будет отсутствовать – ее стоит удалить совсем, иначе советники на тестах могут показать неправильные результаты.
10. Откуда брать сырье для заплаток — мы уже обсуждали в этой статье. Вам понадобится один, может, два источника — все зависит от конкретного случая.
11. Прежде всего ваши данные для заплаток нужно привести к формату csv, если они у вас в hst формате, и в этом поможет скрипт hst2csv.
12. Затем эти данные из других источников нужно привести к правильному времени, а именно выставить для них тот же GMTOffset, что и у вашего брокера, и у корректируемых котировок. Не стоит упускать из виду, так это информацию о том, какой точно сдвиг относительно GMT у конкретного источника котировок, менялся ли он когда-либо и использовался ли перевод на зимнее/летнее время. Например, котировки Alpari до 2011 года имели GMT+2, а после 2011 – GMT+3.
Чтобы это сделать, вам потребуется отдельный терминал. В него нужно по очереди загружать котировки каждого из источников, изменять время GMT при помощи скрипта GMTconverter, который я написал, когда обнаружил, что по какой-то причине в сети подобных скриптов нет. Скрипт вы сможете найти/скачать в конце статьи. Также вы можете при импорте скачанных котировок в отдельный терминал указать нужный GMT, но иногда это не работает. Для того, чтобы указать нужный GMT при импорте котировок, нужно указать «Сдвиг» в часах. Затем эти котировки нужно экспортировать, нажав кнопку экспорт. Таким образом, котировки сохранятся в нужном формате и с нужным вам GMT.
13. После приведения котировок к нужному виду просто открываем наш файл с нашим тестом качества и источник заплаток, который мы получили. Причем открывать файлы нужно именно в Блокноте, так как Excel может не открыть файл целиком, если истории довольно много.
14. Находим каждый из проблемных отрезков в файле для заплаток и переносим куски в отдельно открытый файл Блокнота:
15. Если в одном из источников не хватает данных, пробуем найти в других источниках.
16. Далее сохраняем подготовленный файл в формате csv. Просто меняем расширение файла с txt на csv.
17. Импортируем в терминал к котировкам Ducascopy. Удаленные участки автоматически восстановятся из подготовленного нами файла.
18. После долгой и кропотливой работы по импорту заплаток нужно закрыть терминал и открыть его снова, чтобы залатанная история подгрузилась. Снова набрасываем скрипт history_data_analysis и смотрим на результат нашей работы.
19. Теперь приходит очередь второго скрипта AllMinutes_Step1. Что он делает? Дело в том, что те минутные бары, в которых ничего не происходило и не было никаких цен, терминал автоматически пропускает. Скрипт осуществляет техническое наполнение пропущенных баров для обеспечения в последующем правильной генерации свечей более высоких таймфреймов. Итак, бросаем его на график и включаем вкладку «Эксперты». Это вкладка нам нужна, чтобы увидеть сообщение о завершении работы этого скрипта и его краткий отчет.
20. Как только появилось сообщение о завершении работы скрипта, нужно открыть автономный график (Файл — Открыть автономно — ALLEURUSD1):
21. Бросаем на открывшийся график первый скрипт history_data_analysis. Получаем отчет, к которому мы вернемся несколько позднее.
22. Далее в работу запускаем третий скрипт — hst2csv. Дело в том, что предыдущий скрипт в процессе своей работы не просто заполнил на графике в автономном режиме все пропущенные бары, но еще и сформировал такую же полную базу котировок в формате hst. Файл образовался в папке истории и имеет название «ALLEURUSD1». Запускаем на автономном графике скрипт history_data_analysis. Теперь нам придется этот файл ALLEURUSD1.hst переформатировать в управляемый (с точки зрения сдвигов времени) формат .csv, что собственно и будет делать скрипт hst2csv.
23. А теперь вернемся к отчету, сделанному по результатам анализа автономного графика. Это необходимо для того, чтобы отследить те минимальные пробелы, которые могут быть не замечены скриптом. Такое случается не всегда, но иногда бывает. Скрипт нашел и заполнил тысячи одиноких баров, но, увы, мог несколько и пропустить. А поэтому этот недочет придется устранять вручную.
В принципе, это несложно — в отчете в таблице указаны конкретные координаты этих пропусков. Поэтому работа очень похожа на ту, что мы делали в пункте 14. В общем, заходим в папку «Файлы». Открываем «ALLEURUSD1.csv» при помощи программы Блокнот. Используя функцию «поиск», оказываемся в нужной дате. Заполняем пропущенные бары последней известной ценой, не забывая изменять время баров.
24. Открываем в терминале архив котировок (F2), удаляем всю хранящуюся в нем историю формата hst, после чего загружаем этот новый сконвертированный файл. Снова закрываем и открываем терминал. Открываем график, в нашем случае EURUSD M1 и делаем контрольный замер скриптом history_data_analysis на случай, если мы что-то упустили.
25. Дело осталось за малым — за скриптом period_converter_ALL. С ним вообще все просто — бросаем на график и смотрим в верхний левый угол — пока там бегут цифры, скрипт еще работает. Как только движение в том углу прекратится, значит работа завершена. И в конце последовательно переключаем все таймфреймы, чтобы они подгрузились.
Заключение
Вот и все — в нашем терминале теперь котировки 100% качества. Можно получить максимально точное тестирование и хорошую гарантию достоверности результатов, если есть вспомогательные таймфреймы периода М1, которые на 100% покрывают исследуемый период.
Таким образом — вопрос качественного тестирования превращается в поиск детальных исторических данных и последующей сборкой котировок максимально возможного качества. В любом случае, если вы хотите получать достоверные результаты тестов, вы должны озаботиться своей собственной качественной базой исторических данных.
Скачать набор необходимых скриптов
Инструкция по установке скриптов в MT4
Тема на форуме
С уважением, Дмитрий аkа Silentspec
TradeLikeaPro.ru
tlap.com
Как пользоваться тестером напряжения: пошаговая инструкция
Контроль за напряжением сети нужен всегда: во время монтажа электропроводки, замены или ремонта электрооборудования, прозвонки цепей. Самый верный способ это сделать – воспользоваться тестером напряжения, который по-народному называют пробником. Такой прибор гораздо дешевле, чем многофункциональный мультиметр. Как пользоваться тестером? Об этом ниже.
Тестер напряжения
Тестер электричества – это прибор, которым можно замерить напряжение и установить его наличие или отсутствие в сети. Тестер намного проще устроен, чем мультиметр, им несложно пользоваться, можно проводить работу оперативно, в неудобных условиях, например, держаться одной рукой на высоте, другой делать замер.
Как пользоваться тестером напряжения? Им можно замерять электричество розеток на оголенных проводах, контактах электроприборов, выходе генераторов. Более сложные устройства отображают информацию в цифровом виде, более простые – при помощи лампочки индикатора.
Виды тестеров напряжения
Есть много типов тестеров — от самых простых устройств до сложных приборов. Все они позволяют анализировать напряжение, но степень анализа, естественно, будет разной. Тестеры напряжения бывают выполнены как:
- Пробник-отвертка. Самый простой прибор, по форме напоминающий отвертку. Он состоит из прозрачного диэлектрического корпуса, металлического контакта с прямым шлицом, неоновой лампочки, сопротивления, пружинки и еще одного контакта–крепления.
- Тестер-отвертка. Устройство похоже на предыдущее, только корпус имеет жидкокристаллический экран и светодиодный индикатор.
- Тестер универсальный. Прибор с двумя щупами, один из которых снабжен ЖК-экраном.
- Тестер многофункциональный – мультиметр. Таким тестером пользуются как прибором для измерения не только напряжения, но и всех остальных электрических параметров. Такой прибор имеет два щупа и переключатель режимов измерения между постоянным видом тока и переменным.
Как работать пробником-отверткой
Устройство контроля напряжения сети – пробник — не способно определить уровень электричества. Его основная задача – обнаружить фазу. Это очень важно знать, так как при ремонте, отключая пробки, нужно быть уверенным, что фаза отсутствует. Именно она, замыкаясь через тело человека на землю, производит электрический удар.
Как пользоваться тестером-пробником:
- Убедиться, что он исправен визуально. Изоляционный материал на приборе не должен быть нарушен.
- Взять отвертку за изоляционную ручку одной рукой так, чтобы один палец был свободен.
- Вставить прибор в любое отверстие розетки и большим пальцем прикоснуться к контакту на торце рукояти.
- Если лампочка не горит, переставить отвертку в другое отверстие розетки. Горящая лампочка сигнализирует о наличии фазы на контакте.
Также легко понять, как пользоваться тестером-отверткой для прозвонки проводов, например в переноске. Для этого нужно определить контакт фазы в конкретной розетке. Далее вставить вилку тестируемой переноски и найти на выходе фазу. Меняя местоположение вилки, определить, через какой провод фаза не идет – там и есть обрыв.
Как измерять тестером-отверткой
Этот прибор-индикатор похож по форме на рассмотренный выше, но функционал его позволяет определять значительно больше параметров. Таким электрическим тестером пользуются как индикатором наличия в линии электрического напряжения, проверяют аккумуляторы на состояние разряда, определяют полярность выводов, находят точку разрыва провода в цепи, фиксируют присутствие излучений электромагнитного и микроволнового диапазона.
Тестер-отвертка имеет следующие технические параметры:
- Возможность измерения напряжения электричества постоянного и переменного значения в диапазоне: 220, 110, 55, 36, 12 вольт с отображением информации на цифровом табло.
- Определение полярности выводов постоянных источников питания и фазы переменной сети.
- Нахождение места разрыва в электрическом проводе в диапазоне сопротивлений от ноля до 50 МОм.
- Выявление наличия излучения в пределе частот от 50 до 500 Гц.
- Ток на входе – менее 0,25 миллиампер, напряжение – не более 250 вольт.
- Соответствие требованиям евростандарта и допускам DINVDE 0680 Teil 6/04.77.
Как пользоваться отверткой-тестером:
1. Метод контактного тестирования. Этим способом проводят замеры напряжения в допустимом диапазоне. Действия:
- Щупом устройства прикасаются к разъему в розетке, оголенному проводу или контакту электрического прибора под напряжением.
- Пальцем руки нажимают на сенсор-кнопку с обозначением Directtest, расположенную на приборе.
- Снимают показания с дисплея тестера.
2. Метод бесконтактного тестирования. Таким способом можно найти проводку переменной линии, скрытую под слоем штукатурки, если в ней протекает ток, излучения электромагнитного и микроволнового характера, проверить цельность электрического провода. Действия:
- Пальцем руки нажимают на сенсор-кнопку с обозначением InductanceBreak-pointtest.
- Прибор подносят к ориентировочному месту залегания проводки и аккуратно перемещают вдоль и поперек.
- Появление на экране значка в виде молнии Z говорит о том, что прибор зафиксировал слабое магнитное поле, создаваемое проводником.
- Проверяя провод на обрыв, вдоль него двигаются, пока значок Z не исчезнет.
Как пользоваться тестером напряжения при работе с аккумуляторами и химическими элементами питания?
- Нажимая пальцем на сенсор-кнопку Directtest, контактом со шлицом прикасаются к любому полюсу батареи.
- Второй рукой прикасаются к другому полюсу батареи.
- Отображение на индикаторе молнии Z подтверждает работоспособность питающего элемента.
- Полярность показывает светодиод, который загорается на плюсе и не горит на минусе контакта.
Как пользоваться тестером-мультиметром
Мультиметром довольно легко работать, он многофункционален, с понятным для пользователя интерфейсом. Но все же нужно быть предельно осторожным, так как из-за множества режимов работы и пределов измерений вполне возможно запутаться и сжечь прибор. У дешевых китайских измерителей лучше сразу заменить провода измерительных щупов на более надежные.
Как правильно пользоваться тестером, измеряя постоянное напряжение:
- Красный измерительный провод вставляют в гнездо VΩmA, черный — в гнездо COM.
- Ручку переключения режимов измерения круглой формы переставляют в положение DCV на самый высокий предел измерения.
- Щупы подключают к источнику электричества к плюсу и минусу. Переполюсовка в этом случае не страшна. Если ее допустить, это просто отобразится знаком «-» на табло экрана.
- Записывают показания прибора.
Если напряжение приблизительно известно, то предел измерений лучше выставлять чуть больше заведомо предполагаемого, для повышения точности измерений.
Как пользоваться тестером-мультиметром, измеряя переменное напряжение:
- Щупы остаются подключенными на прежнем месте.
- Переключатель режимов переводят в положение ACV на предел свыше 220 вольт для однофазной сети, свыше 380 вольт – для трехфазной.
- Очень аккуратно, не касаясь оголенных участков щупов руками, подключают последние к контактам розетки. Значения не имеет, куда какой измерительный провод подсоединять.
- Записывают показания прибора.
Что такое тестер Keweisi
USB-тестер KWS-V20 предназначен для измерения электрических параметров USB-зарядных устройств, подключаемых к ним приборов, а также емкости, получаемой и отдаваемой при зарядке, разрядке повербанка. Технические параметры:
- Измеряемое постоянное напряжение от 3 до 9 вольт.
- Измеряемый постоянный ток до 3 ампер.
- Измеряемая емкость до 99999 миллиампер-часов.
Как пользоваться тестером Keweisi
Порядок работы с прибором:
- Включить в USB порт измеряемой зарядки и нажать на кнопку сброса.
- Снять замеры напряжения, отображаемые на экране.
- Для замера потребляемого тока каким-либо устройством вставить его шнур в USB-разъем Keweisi.
- Снять показания на приборе.
- Для определения отдаваемой емкости повербанка на выход полностью заряженного устройства подключают тестер, на выход тестера — нагрузку.
- Как только повербанк полностью разрядится, тестер переключают на какой-либо источник напряжения и снимают показания, зафиксированные в памяти устройства.
Заключение
Если под рукой не оказалось ни одного тестера и даже пробника отвертки, а нужно срочно проверить, есть ли в розетке напряжение, проще всего – воспользоваться обыкновенной лампочкой накаливания. Для этого к ней через патрон подсоединяют провод с вилкой и включают в исследуемую розетку. Как правильно пользоваться тестером этого типа? Нужно быть предельно уверенным, что в сети нет повышенного напряжения. Иначе лампочка может взорваться и причинить вред.
fb.ru
LCR тестер компонентов TC-1
Приветствую всех читателей на страницах сайта!Наверное, не многие радиолюбители еще не слышали о LC тестере T4, а те кто обзавелся или собрал самостоятельно подобный прибор вряд ли назовут его бесполезным.
Интерпретаций данного тестера сегодня существует довольно большое множество – это и конструктор, и готовый модуль с питанием от кроны, и модули с литиевыми аккумуляторами, и эти же модели, но уже в корпусе из оргстекла/акрила.
Сегодня хочу поделиться информацией о еще одной версии LC-тестера – мультифункциональном тестере ТС-1 с цветным экраном, встроенным литий-ионным аккумулятором, приличным корпусом и парой дополнительных полезных функций.
Кому данная тема интересна, приглашаю под кат.
Сначала пара слов для тех, кто еще не знает для чего служат подобные приборы.
Как правило, большую часть радиокомпонентов можно проверить обычным мультиметром. Однако есть и такие, которые мультиметром не протестировать вовсе или удастся это сделать лишь частично. Например, полевые транзисторы MOSFET, J-FET. Кроме того, не все мультиметры могут измерять емкость конденсаторов, а те которые могут это делать, не могут измерять ESR – эквивалентное последовательное сопротивление и Vloss – напряжение утечки.
Не удастся так же мультиметром определить напряжение стабилизации стабилитронов при затертой или мелкой маркировке.
И вот в этих случаях очень может выручить многофункциональный тестер ТС-1, которым можно тестировать резисторы сопротивлением до 50 МОм, диоды, стабилитроны с напряжением стабилизации до 30 вольт, светодиоды, npn и pnp биполярные транзисторы, N и P канальные полевые транзисторы MOSFET и J-FET, IGBT биполярные транзисторы с изолированным затвором, тиристоры, симисторы, измерять индуктивность, емкость, ESR, Vloss конденсаторов, а так же напряжение литиевых аккумуляторов до 4,5 вольт. Тестер умеет дешифровать сигналы пультов дистанционного управления. Питается прибор от внутреннего литий-ионного аккумулятора и заряжается через microUSB разъем от любого источника напряжением не более 6 вольт. Информация о результатах теста выводится на цветной TFT дисплей размером 1,8 дюйма с разрешением 160*128 пикселей.
Поставляется тестер в небольшой коробке с цветным принтом и информацией о возможностях тестера.
Внутри лежит интуитивно понятная инструкция на английском языке и антистатический пакет.
Внутри антистатического пакета спрятан тестер, короткий шнур для зарядки и … еще два антистатических пакета).
В полностью распакованном виде содержимое пакетов выглядит так:
Большой плюс, что положили в комплект щупы – не нужно допаивать провода к радиодеталям с короткими ножками или аккумуляторам, чтобы вставить их в разъем. Наконечники щупов подпружинены и хорошо зажимают выводы радиокомпонентов.
Но есть и претензии к щупам – они могли бы быть и одного цвета с проводами. Позже, когда проводил тесты, испытывал дискомфорт от этого. Оно может и не имеет значения – тестеру все равно какой контакт детали, в какой контакт колодки вставлен. Он сам разберется, но все же когда внимание сосредоточено на приборе/щупах/измерениях, то лишний отвлекающий фактор не к месту (а может и придираюсь).
Конденсатор на 10 мкф*25 вольт и красный светодиод положили в качестве бонуса, а вызвавшие сначала недоумение неразрезанные контакты, позже пригодились для калибровки тестера – да, есть тут и такая задекларированная в инструкции процедура.
С самого начала прибор вызвал интерес тем, что у него приличный корпус, ничего делать как в случае с бескорпусным вариантом LC тестера Т4 не нужно. В руке лежит удобно.
Излишество или хороший тон, но экран закрыт транспортировочной пленкой.
К номерным контактам разъема подключаются любые контакты радиодеталей, кроме стабилитронов. Для стабилитронов предусмотрены контакты разъема КАА (катод, анод, анод).
В инструкции указано, что не следует одновременно в номерные контакты вставлять, например, транзистор, а в контакты для стабилитронов стабилитрон – будет проводиться тест только компонента в номерных контактах.
Рядом с разъемом расположено окно инфракрасного датчика для проверки и декодирования сигналов пультов ДУ.
Все управление прибором производится одной кнопкой, которая в инструкции обзывается многофункциональной. Под «много» имеется ввиду, краткое нажатие для активации прибора и начала теста, после установки компонента в разъем и длительное нажатие для принудительного выключения прибора. Как и в Т4 здесь не забыли про автоотключение после 25 секунд бездействия. Кому этого времени покажется много, тот может воспользоваться информацией из инструкции, вскрыть прибор и установить паяльником перемычку, задав нужный период до отключения от 10 до 25 секунд.
На задней стороне прибора находится разъем microUSB и светодиод. Во время зарядки он светится красным, а по ее окончании привычно зеленым цветом.
Дальняя и нижняя сторона корпуса
Размеры корпуса
Как и все приборы, содержащие аккумулятор, тестер перед использованием рекомендуется зарядить. Максимальный ток зарядки составляет 0,44 Ампера.
С описанием внешнего вида и характеристикам всё и можно переходить к тестированию радиокомпонентов.
Для включения тестера кратко нажимаем кнопку и видим следующее на экране:
Прибор пишет, что не обнаружил тестируемый компонент или компонент поврежден.
Выпрямительный диод 1N4007, диод Шоттки SR504, сдвоенный диод Шотки SBL2040CT.
Для светодиодов тестер показывает ёмкость перехода и минимальное напряжение, при котором светодиод открывается. Во время теста светодиод начинает мерцать.
Стабилитроны на разное напряжение:
Транзисторы структуры npn: BC547C, МJE1309, КТ312Б, КТ315Б
MJE13003С с защитным диодом и составной транзистор КТ827А
Транзисторы структуры pnp: МП40А, ВС557В, S8550
Полевые транзисторы: APM3055L – N-канальный MOSFET и LD1010D – N-канальный JFET с PN диодом:
Из имеющихся у меня под рукой компонентов тестер не совсем точно отобразил N- канальный MOSFET К3742. Его он показал как IGBT:
P-канальный MOSFET BSS92
А вот IGBT транзистор G20N50C тестер отобразил как N канальный MOSFET, но тут есть оговорка: по одному даташиту он N-канальный MOSFET, а по другому N-канальный IGBT и обозначения немного разные.
Не смотря на «путаетесь в показаниях») нужно сказать, что тестер суть компонента определил – будь транзистор пробитым или оборванным, мы бы увидели совсем иную картинку.
Последние две фотки снимались по случаю на телефон на радиорынке так, как в наличии P-канальных MOSFET и IGBT в наличии не было. Не обессудьте.
Следующими в очереди были симисторы MAC97A8 и BT134600E
В инструкции к прибору говорится, что тестер способен тестировать тиристоры и симисторы с током управляющего электрода до 6 mA, но у MAC97A8 этот параметр равен 7 mA, а у BT134600E — 25 mA. Выходит или в инструкции ошибка или прибор лучше). С конденсаторами такая же история – до 100 mF. Микро или мили? Учитывая, что тестер измеряет конденсаторы емкостью больше 100 мкФ, то тогда в инструкции имеются в виду миллиФарады, а это 100 000 микроФарад. Но вернемся к тестированию.
Измерение индуктивности:
Тестер умеет распознавать сигналы пультов дистанционного управления и декодировать их. Но касается это только пультов работающих в IR формате Hitachi. Из таковых оказался только ПДУ от ДВД плейера BBK. При нажатии кнопок на пульте картинка на дисплее тестера менялась.
В случае с остальными пультами на зеленом поле экрана мигала красная крупная точка, просто сигнализируя о том, что пульт работает и что то излучает.
Насколько полезная данная функция судить не берусь, но пусть лучше будет.
Сопротивление тестер измеряет в диапазоне 0,01 Ом — 50 Мом. Не всё нашлось в закромах, но общий вывод – справляется. Погрешность есть, как, впрочем, и у всякого измерительного прибора. В инструкции, кстати, она не указана.
На резисторах провел сравнительные замеры тремя приборами:
Как говорится, придраться к каждому можно. И в то же время каждый не далеко ушел от соседа. Где то больше, где то меньше, но все равно достаточно точно.
Проверку конденсаторов провел по той же схеме. Расхождения между приборами присутствуют, но иное представить трудно.
Опять же сравнительные замеры тремя приборами:
Примечательный факт — конденсаторы были разные — керамика, лавсан и другие, но с МБМ не смог справиться ни один из приборов. При этом, обозреваемый ТС-1 показал лишь на 35 % больше от номинала. Два других дали погрешность почти на +80 %).
Как уже говорил, важным параметром электролитических конденсаторов является ESR – эквивалентное последовательное сопротивление. Его возрастание приводит к некорректной работе схем. Не лишним будет знать и Vloss конденсатора – напряжение утечки, измеряющееся в процентах и показывающее, сколько процентов заряда теряет конденсатор через одну секунду после прекращения процесса заряда. При его значении в несколько процентов конденсатор лучше отложить в сторону.
Измеренные величины ESR сравниваются с табличными, обязательно следует учитывать напряжение, на которое рассчитан конденсатор.
Сначала фото приличных конденсаторов. Номиналы на фото написаны желтым цветом.
Пара сравнительных фото с мультиметром.
Тот же конденсатор 47 мкф*160 вольт и 2200 мкф*25 вольт.
Результаты сравнения показаний емкости трех приборов такие же как и в случае с резисторами и неэлектролитическими конденсаторами – плюс/минус, но все рядом.
В завершении конденсаторной главы несколько фото негодных конденсаторов.
4,7*25 В, 100 мкф*10 В, 10 мкф*50 В:
4,7 мкф*400 В, 22 мкф* 250 В, 470 мкф * 25 В
Следуя инструкции и по опыту угробленного Т4, скажу что перед проверкой конденсаторов их следует обязательно разрядить.
Кроме всего вышеперечисленного ТС-1 позволяет так же проверять напряжение элементов питания с напряжением до 4,5 Вольт.
Последним пунктом из функционала тестера остается калибровка. Тут, как в случае с Т4, не требуется конденсатор. Здесь для калибровки достаточно вставить в колодку те самые неразрезанные контакты из комплекта, что при распаковке удивили своим наличием в комплекте, и нажать кнопку.
После этого на экране появится сообщение о самотестировании и ниже шкала с процентами его выполнения.
На уровне 22 процентов тестер попросит извлечь замкнутые контакты и тест продолжится.
На этом повествование о богатом функционале маленького прибора можно заканчивать и переходить ко всем любимой разборке и тесту аккумулятора.
Разбирается прибор просто, для этого нужно лишь открутить четыре самореза. Аккумулятор приклеен на двухсторонний прозрачный скотч. Теперь ищу такой же – еле оторвал аккумулятор, пришлось поддевать пластикой картой. Если кто знает, прошу дать ссылку. Приклеено было так хорошо, что при отрывании аккумулятора обертка слегка поменяла рельеф, но с самим аккумулятором все в порядке.
Мозговым центром тестера является микроконтроллер Atmega 324PA, надпись на втором чипе старательно затерта.
Обратите внимание на область платы в красном прямоугольнике – замкнув контакты на массу можно изменить время до отключения тестера. С завода перемычек нет и установлено время 25 секунд. Добавив перемычки можно установить 10,15,20 секунд.
С обратной стороны платы все так же аккуратно и без следов флюса, а плата экрана припаяна через пины (надеюсь правильно назвал), что куда надежнее, чем шлейф, как в Т4.
Тест аккумулятора провел из спортивного интереса аж тремя способами: зарядка-разрядка iMax B6 (током 0,2 А), зарядка-разрядка EBD-USB (током 0, 18 А) и зарядка через USB-тестер. И на удивление все три теста дали практически одинаковый результат – аккумулятором прибор укомплектован качественным.
Под финал изучения тестера под руку попались динисторы DB3. С ними, не смотря на напряжение пробоя по даташиту от 28 до 32 вольт, тестер тоже как-то справился.
Подводя черту, по традиции и правилам сайта отмечу минусы и плюсы.
Минусы (или пожелания): прибору следует немного добавить точности измерений, вопросы по определению некоторых MOSFET и IGBT транзисторов и хотелось бы щупы и провода одного цвета.
Плюсы: многофункциональность, компактность и законченный вид благодаря корпусу, внутренний качественный аккумулятор, щупы, простая калибровка, цветной дисплей.
P.S. Из имеющихся теперь тестеров T4 и ТС-1 предпочту пользоваться обозреваемым.
Товар предоставлен для написания обзора магазином. Обзор опубликован в соответствии с п.18 Правил сайта.
mysku.ru