Содержание

8. Минимально грубое тестирование

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

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

  1. для каждого цикла с предусловием должна быть проверена правильность при нулькратном, однократном и многократном повторении тела цикла. Многократным считается любое повторение более одного раза;

  2. для каждого цикла с постусловием должна быть проверена правильность при однократном и многократном повторении тела цикла;

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

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

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

графы — тестам.

Для каждого условного оператора в таблице МГТ создаются 2 строки: для ветви «то» и ветви «иначе».

Тест 1

Тест 2

Тест 3

Тест 4

Тест 5

if a > b

+

Для каждого цикла с предусловием — 3 строки: для нулькрат-ного, однократного и многократного повторения тела цикла.

Тест 1

Тест 2

Тест 3

Тест 4

Тест 5

while a > b

=0

=1

>1

Для каждого цикла с постусловием — 2 строки: для однократного и многократного повторения тела цикла.

Тест 1

Тест 2

Тест 3

Тест 4

Тест 5

repeat until a > b

=1

>1

Для каждого цикла со счетчиком — 3 строки: для нулькрат-ного, однократного и многократного повторения тела цикла.

Тест 1

Тест 2

Тест 3

Тест 4

Тест 5

=0

for k := l to n

=1

>1

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

Для каждого оператора выбора записывается столько строк, сколько он имеет ветвей (включая ветвь «иначе»):

Тест 1

Тест 2

Тест3

Тест 4

Тест 5

case color

red

green

blue

else

Если в условном операторе, в цикле с пред- или постусловием стоит сложное условие, то к строкам, соответствующим самому оператору, добавляются по 2 строки на каждое простое условие:

Тест 1

Тест 2

Тест3

Тест 4

Тест 5

if (a > b) and (х = у)

+

a > b

+

х = у

+

12

Интервью по тестированию программного обеспечения

1. Что такое исследовательское тестирование?

Исследовательское тестирование — это практический подход, при котором тестировщики участвуют в минимальном планировании и максимальном выполнении теста. Планирование включает в себя создание протокола испытаний, краткую декларацию объема коротких (от 1 до 2 часов) временных испытаний, целей и возможных подходов, которые будут использоваться. Проектирование теста и выполнение теста выполняются параллельно, как правило, без официального документирования условий теста, тестовых случаев или сценариев теста. Это не означает, что другие, более формальные методы тестирования не будут использоваться. Например, тестировщик может решить использовать анализ граничных значений, но продумает и протестирует наиболее важные граничные значения, не записывая их обязательно. Некоторые примечания будут написаны во время сеанса поискового тестирования, чтобы впоследствии можно было составить отчет.

2. Что такое «тестирование варианта использования»?

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

3. В чем разница между STLC (жизненный цикл тестирования программного обеспечения) и SDLC (жизненный цикл разработки программного обеспечения)?

SDLC занимается разработкой / кодированием программного обеспечения, в то время как STLC занимается валидацией и верификацией программного обеспечения.

4. Что такое матрица отслеживания?

Связь между тестовыми примерами и требованиями показана с помощью документа. Этот документ известен как матрица прослеживаемости.

5. Что такое эквивалентное тестирование?

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

6. Что такое тестирование белого ящика и перечислите типы тестирования белого ящика?

Метод тестирования белого ящика включает выбор тестовых случаев на основе анализа внутренней структуры (покрытия кода, покрытия ветвей, покрытия путей, покрытия условий и т. Д.) Компонента или системы. Он также известен как тестирование на основе кода или структурное тестирование. Различные виды тестирования белого ящика

  1. Заявление покрытия
  2. Охват решений

7. Что вы проверяете в тестировании белого ящика?

В тестировании белого ящика проверяются следующие шаги.

  1. Проверьте дыры в безопасности в коде
  2. Проверьте неполные или неработающие пути в коде
  3. Проверьте поток структуры согласно спецификации документа
  4. Проверьте ожидаемые результаты
  5. Проверьте все условные циклы в коде, чтобы проверить полную функциональность приложения
  6. Проверяйте построчное кодирование и покрывайте 100% тестирование

8. Что такое тестирование черного ящика? Каковы различные методы тестирования черного ящика?

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

  1. Эквивалентное разбиение
  2. Анализ граничных значений
  3. Причинно-следственная графика

9. В чем разница между статическим и динамическим тестированием?

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

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

10. Что такое проверка и валидация?

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

11. Каковы различные уровни тестирования?

Есть четыре уровня тестирования

  1. Тестирование модуля / компонента / программы / модуля
  2. Интеграционное тестирование
  3. Тестирование системы
  4. Приемочное тестирование

12. Что такое интеграционное тестирование?

Интеграционное тестирование — это уровень процесса тестирования программного обеспечения, при котором отдельные модули приложения объединяются и тестируются. Обычно выполняется после модульного и функционального тестирования.

13. Из чего состоят планы испытаний?

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

  1. Идентификатор теста
  2. Объем
  3. Особенности для тестирования
  4. Особенности не должны быть проверены
  5. Тестовая стратегия и тестовый подход
  6. Тестовые результаты
  7. обязанности
  8. Кадровое обеспечение и обучение
  9. Риск и непредвиденные обстоятельства

14. В чем разница между UAT (User Acceptance Testing) и Системным тестированием?

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

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

15. Укажите разницу между тестированием на основе данных и повторным тестированием?

Повторное тестирование. Это процесс проверки ошибок, предпринимаемых командой разработчиков для проверки их исправления.

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

16. Каковы ценные шаги для решения проблем во время тестирования?

  • Запись: регистрировать и обрабатывать любые проблемы, которые произошли
  • Сообщить: сообщить о проблемах руководителю более высокого уровня
  • Контроль: определение процесса управления проблемами

17. В чем разница между тестовыми сценариями, тестовыми примерами и тестовым сценарием?

Разница между тестовыми сценариями и тестовыми случаями заключается в том, что

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

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

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

18. Что такое скрытый дефект?

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

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

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

  • Коэффициент брака брака
  • Коэффициент утечки дефекта

20. Какова функция инструмента тестирования программного обеспечения «Фантом»?

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

21. Объясните, что такое тестовые результаты?

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

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

  • Перед тестированием
  • Во время тестирования
  • После тестирования

22. Что такое мутационное тестирование?

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

23. Что нужно учитывать перед выбором средств автоматизации для AUT?

  • Техническая осуществимость
  • Уровень сложности
  • Стабильность приложения
  • Тестовые данные
  • Размер приложения
  • Повторное использование автоматизированных скриптов
  • Исполнение через среду

24. Как вы будете проводить анализ рисков?

Для анализа риска необходимо выполнить следующие шаги

  1. Нахождение оценки риска
  2. Создание профиля для риска
  3. Изменение свойств риска
  4. Разверните ресурсы этого теста риска
  5. Создание базы данных рисков

25. Какие категории отладки?

Категории для отладки

  1. Отладка грубой силы
  2. Откат
  3. Причина устранения
  4. Программа нарезки
  5. Анализ дерева отказов

26. Что такое маскировка ошибок, объясните примером?

Когда наличие одного дефекта скрывает наличие другого дефекта в системе, это называется маскированием неисправностей.

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

27. Объясните, что такое план тестирования? Какая информация должна быть включена в План тестирования?

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

  • Тестовая стратегия
  • Цель теста
  • Критерии выхода / приостановки
  • Планирование ресурсов
  • Результаты теста

28. Как вы можете устранить риск продукта в вашем проекте?

Это поможет вам устранить риск продукта в вашем проекте, и есть простой, но важный шаг, который может снизить риск продукта в вашем проекте.

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

29. Какой общий риск ведет к провалу проекта?

Общий риск, который приводит к провалу проекта:

  • Не хватает человеческих ресурсов
  • Среда тестирования может быть настроена неправильно
  • Ограниченный бюджет
  • Ограничения по времени

30. На каком основании вы можете прийти к оценке вашего проекта?

Чтобы оценить свой проект, вы должны учитывать следующие моменты

  • Разделите весь проект на самые маленькие задачи
  • Выделите каждое задание членам команды
  • Оцените усилия, необходимые для выполнения каждой задачи
  • Подтвердить оценку

31. Объясните, как бы вы распределили задачу среди членов команды?

задачачлен
  • Проанализировать спецификацию требований к программному обеспечению
  • Все участники
  • Создать спецификацию теста
  • Тестер / Тестовый Аналитик
  • Создайте тестовую среду
  • Тестовый администратор
  • Выполнить контрольные примеры
  • Тестер, администратор тестов
  • Сообщить о дефектах

32. Объясните, что такое тип тестирования и какой тип тестирования обычно используется?

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

Обычно используемые типы тестирования

  • Модульное тестирование: протестируйте самый маленький код приложения
  • Тестирование API: API тестирования, созданный для приложения
  • Интеграционное тестирование: отдельные программные модули объединены и протестированы
  • Тестирование системы: полное тестирование системы
  • Установка / удаление тестирования: тестирование проводится с точки зрения клиента / клиента
  • Agile Testing: тестирование с помощью Agile техники

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

Вещи, которые должны быть приняты во внимание

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

34. Каковы распространенные ошибки, которые создают проблемы?

  • Соответствие ресурсов неправильным проектам
  • Менеджер тестов отсутствие навыков
  • Не слушая других
  • Плохое планирование
  • Недооценка
  • Игнорирование мелких проблем
  • Не следуя процессу

35. Что содержится в типичном протоколе испытаний? Каковы преимущества отчетов об испытаниях?

Протокол испытаний содержит следующие вещи:

  • Информационный проект
  • Цель теста
  • Сводка теста
  • дефект

Преимущества протоколов испытаний:

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

36. Что такое проверка управления тестированием и почему это важно?

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

37. Каковы лучшие практики для обеспечения качества программного обеспечения?

Лучшие практики для эффективной реализации SQA

  • Непрерывное улучшение
  • Документация
  • Использование инструмента
  • метрика
  • Ответственность членов команды
  • Опытные аудиторы SQA

38. Когда готовится RTM (матрица отслеживания требований)?

RTM готовится до разработки тестового примера. Требования должны быть прослежены от действий обзора.

39. В чем разница между тестовой матрицей и трассируемой матрицей?

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

Матрица прослеживаемости : сопоставление между тестовыми примерами и требованиями заказчика называется Матрица прослеживаемости

40. При ручном тестировании что такое заглушки и драйверы?

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

41. Каким шагом вы будете следовать, если обнаружите дефект?

Как только дефект найден, вы должны выполнить шаг

а) воссоздать дефект

б) Прикрепить скриншот

c) Зарегистрируйте дефект

42. Объясните, что такое метод тестирования по плану тестирования или по ключевому слову?

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

43. Что такое DFD (диаграмма потока данных)?

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

44. Объясните, что такое LCSAJ?

LCSAJ расшифровывается как «линейная последовательность кода и переход». Он состоит из следующих трех пунктов

а) начало линейной последовательности исполняемых операторов

б) Конец линейной последовательности

c) Целевая линия, которой передается поток управления в конце линейной последовательности

45. Объясните, что такое тестирование N + 1?

Вариант регрессионного тестирования представлен как N + 1. В этом методе тестирование выполняется в несколько циклов, в которых ошибки, обнаруженные в тестовом цикле «N», устраняются и повторно тестируются в тестовом цикле N + 1. Цикл повторяется, если не найдено ошибок.

46. ​​Что такое Fuzz-тестирование и когда оно используется?

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

47. Укажите, в чем заключаются основные преимущества метрики покрытия отчетности тестирования программного обеспечения?

Преимущество метрики покрытия заявления состоит в том, что

а) не требует обработки исходного кода и может применяться непосредственно к объектному коду

b) Ошибки распределяются равномерно по коду, благодаря чему процент покрываемых исполняемых операторов отражает процент обнаруженных ошибок.

48. Как сгенерировать контрольные примеры для метода «заменить строку»?

а) Если символы в новой строке> символы в предыдущей строке. Ни один из персонажей не должен быть усечен

б) Если символы в новой строке <символы в предыдущей строке. Нежелательные символы не должны быть добавлены

c) Пробелы после и до строки не должны быть удалены

г) Строка должна быть заменена только для первого вхождения строки

49. Как вы будете решать конфликты между членами вашей команды?

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

50. Укажите, какие категории дефектов?

В основном есть три категории дефектов

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

51. Объясните, как работает инструмент тестирования покрытия?

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

52. Укажите, в чем разница между «дефектом» и «отказом» в тестировании программного обеспечения?

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

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

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

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

54. Объясните, в каких тестовых кейсах написаны первые черные или белые ящики?

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

55. Объясните, в чем разница между скрытыми и замаскированными дефектами?

  • Скрытый дефект: скрытый дефект — это существующий дефект, который не вызвал сбой, поскольку наборы условий никогда не выполнялись
  • Замаскированный дефект: это существующий дефект, который не вызвал сбой, поскольку другой дефект помешал выполнению этой части кода

56. Укажите, что такое тестирование снизу вверх?

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

57. Упомяните, какие существуют разные типы тестовых покрытий.

Различные типы методов покрытия испытаний включают

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

58. Укажите, в чем смысл тестирования дыхания?

Тестирование дыхания — это набор тестов, который реализует полную функциональность продукта, но не тестирует функции в деталях.

59. Объясните, в чем смысл Code Walk Through?

Code Walk Through — это неформальный анализ исходного кода программы для выявления дефектов и проверки методов кодирования.

60. Укажите, каковы основные компоненты формата отчета о дефектах?

Основные компоненты формата отчета о дефектах включают

  • название проекта
  • Имя модуля
  • Обнаружен дефект на
  • Дефект обнаружен
  • ID и имя дефекта
  • Снимок дефекта
  • Статус приоритета и серьезности
  • Дефект решен
  • Дефект решен на

61. Укажите, какова цель проведения сквозного тестирования?

Сквозное тестирование проводится после функционального тестирования. Целью проведения сквозного тестирования является то, что

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

62. Объясните, что это значит под испытательным ремнем безопасности?

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

63. Объясните в проекте тестирования, какие действия по тестированию вы бы автоматизировали?

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

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

64. Какова ОСНОВНАЯ выгода от разработки тестов в начале жизненного цикла?

Это помогает предотвратить появление дефектов в коде.

65. Что такое тестирование на основе риска?

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

66. В чем КЛЮЧЕВАЯ разница между профилактическим и реактивным подходами к тестированию?

Профилактические тесты разрабатываются рано; реактивные тесты разрабатываются после того, как программное обеспечение было произведено.

67. Какова цель критериев выхода?

Цель критериев выхода — определить, когда тестовый уровень пройден.

68. От чего зависит уровень риска?

Вероятность неблагоприятного события и влияние события определяют уровень риска.

69. Когда используется тестирование таблицы решений?

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

Узнайте больше о методике тестирования таблиц решений в видео-учебнике здесь

70. Почему мы используем таблицы решений?

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

71. Какова ОСНОВНАЯ цель при рассмотрении результатов поставки программного обеспечения?

Для выявления дефектов в любом программном продукте.

72. Что из следующего определяет ожидаемые результаты теста? Спецификация тестового набора или проект теста.

Спецификация тестового набора определяет ожидаемые результаты теста.

73. В чем выгода теста независимости?

Это позволяет избежать предвзятости автора при определении эффективных тестов.

74. В рамках какого процесса тестирования вы определяете критерии выхода?

Критерии выхода определяются на основе «Планирования испытаний».

75. Что такое альфа-тестирование?

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

76. Что такое бета-тестирование?

Тестирование проводится потенциальными клиентами на своих местах.

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

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

78. С учетом следующего фрагмента кода, сколько тестов требуется для обеспечения 100% принятия решения?

if width > length 
   thenbiggest_dimension = width
     if height > width 
             thenbiggest_dimension = height 
     end_if
elsebiggest_dimension = length  
            if height > length 
                thenbiggest_dimension = height 
          end_if
end_if

4

79. Вы разработали контрольные примеры, чтобы обеспечить 100% утверждение и покрытие 100% решений для следующего фрагмента кода. если ширина> длина, то самая большая_ди_мерность = ширина еще самая большая_ди_мерность = длина end_if Следующее было добавлено внизу фрагмента кода выше. print «Самое большое измерение — это» & big_dimensionprint «Width:» & width печать: «Length:» & length Сколько еще тестовых случаев требуется?

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

80. В чем разница между методами тестирования и инструментами тестирования?

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

Инструменты тестирования: — это транспортное средство для выполнения процесса тестирования. Инструмент является ресурсом для тестировщика, но сам по себе недостаточен для проведения тестирования.

Узнайте больше об инструментах тестирования здесь

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

Пользовательские тесты

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

Регрессионное тестирование

83. Оптовик продает картриджи для принтеров. Минимальное количество заказа — 5. При заказе 100 и более картриджей для принтера предоставляется скидка 20%. Вас попросили подготовить тестовые наборы, используя различные значения для количества заказанных картриджей. Какие из следующих групп содержат три входных теста, которые будут сгенерированы с использованием анализа граничных значений?

4, 5, 99

84. Что такое тестирование компонентов?

Тестирование компонентов, также известное как тестирование модулей, модулей и программ, ищет дефекты и проверяет функционирование программного обеспечения (например, модулей, программ, объектов, классов и т. Д.), Которые можно тестировать отдельно. Тестирование компонентов может выполняться изолированно от остальной системы в зависимости от контекста жизненного цикла разработки и системы. Чаще всего заглушки и драйверы используются для замены отсутствующего программного обеспечения и простой имитации интерфейса между программными компонентами. Заглушка вызывается из тестируемого компонента программного обеспечения; драйвер вызывает компонент для тестирования.

Вот отличное видео о модульном тестировании

85. Что такое функциональное тестирование системы?

Тестирование сквозной функциональности системы в целом определяется как функциональное тестирование системы.

86. Каковы преимущества независимого тестирования?

Независимые тестеры беспристрастны и выявляют различные дефекты одновременно.

87. В РЕАКТИВНОМ подходе к тестированию, когда вы ожидаете, что большая часть работы по проектированию теста будет начата?

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

88. Каковы различные методологии в модели гибкого развития?

В настоящее время мне известны семь различных гибких методологий:

  1. Экстремальное программирование (XP)
  2. Scrum
  3. Бережливая разработка программного обеспечения
  4. Функционально-управляемая разработка
  5. Agile Unified Process
  6. кристалл
  7. Модель развития динамических систем (DSDM)

89. Какая деятельность в процессе фундаментального тестирования включает оценку тестируемости требований и системы?

«Анализ испытаний» и «Дизайн» включают оценку тестируемости требований и системы.

90. Какова обычно САМАЯ важная причина использовать риск для стимулирования тестирования?

Потому что тестирование нереально.

91. Что такое случайное / обезьянье тестирование? Когда это используется?

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

92. Что из перечисленного является действительными целями для отчетов об инцидентах?

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

93. Рассмотрим следующие приемы. Какие статические, а какие динамические?

  1. Эквивалентность
  2. Использование Case Testing.
  3. Анализ потока данных.
  4. Разведочные испытания.
  5. Тестирование решений.
  6. Осмотры.

Анализ потока данных и проверки являются статическими; Разделение эквивалентности, тестирование прецедентов, предварительное тестирование и тестирование решений являются динамическими.

94. Почему статическое тестирование и динамическое тестирование описываются как дополнительные?

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

95. Каковы этапы официального обзора?

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

  1. планирование
  2. Подать мяч
  3. подготовка
  4. Обзорная встреча
  5. Rework
  6. Следовать за.

96. Какова роль модератора в процессе проверки?

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

Узнайте больше о процессе рецензирования в видео-учебнике здесь

97. Что такое раздел эквивалентности (также известный как класс эквивалентности)?

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

98. Когда следует применять процедуры управления конфигурацией?

Во время планирования испытаний.

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

Тестирование безопасности

100. Тестирование, в котором мы подвергаем цель теста различным рабочим нагрузкам, чтобы измерить и оценить поведение производительности и способность цели и теста продолжать функционировать должным образом при этих различных рабочих нагрузках?

Нагрузочное тестирование

101. Тестирование деятельности, которая выполняется для выявления дефектов в интерфейсах и во взаимодействии между интегрированными компонентами?

Тестирование уровня интеграции

102. Каковы методы тестирования на основе структуры (белого ящика)?

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

103. Когда следует проводить «регрессионное тестирование»?

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

104 . Что такое отрицательное и положительное тестирование?

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

105. Какова цель критерия завершения теста?

Цель критерия прохождения теста — определить, когда прекратить тестирование.

106. Что статический анализ НЕ может найти?

Например утечки памяти.

107. В чем разница между повторным тестированием и регрессионным тестированием?

Повторное тестирование гарантирует, что первоначальная ошибка была устранена; Регрессионное тестирование ищет неожиданные побочные эффекты.

108. Какие методы тестирования основаны на опыте?

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

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

осмотр

110. Могут ли обзоры или проверки считаться частью испытаний?

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

111. В поле ввода указывается год рождения между 1900 и 2004 годами. Каковы граничные значения для проверки этого поля?

1899,1900,2004,2005

112. Какой из следующих инструментов будет задействован в автоматизации регрессионного теста? а. Тестер данных б. Граничный тестер c. Захват / воспроизведение d. Выходной компаратор.

д. Выходной компаратор

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

Водитель

114. Что является одной из ключевых причин, почему разработчики испытывают трудности при тестировании своей собственной работы?

Недостаток объективности

115. «Сколько тестов достаточно?»

Ответ зависит от риска для вашей отрасли, контракта и особых требований.

116. Когда следует прекратить тестирование?

Это зависит от рисков для тестируемой системы. Есть несколько критериев, по которым вы можете прекратить тестирование.

  1. Сроки (Тестирование, Релиз)
  2. Бюджет теста был исчерпан
  3. Уровень ошибок падает ниже определенного уровня
  4. Тестовые случаи выполнены с определенным процентом пройдено
  5. Альфа или бета периоды для тестирования заканчиваются
  6. Покрытие кода, функциональности или требований выполняется до определенной точки

117. Что из нижеперечисленного является основной целью стратегии интеграции для интеграционного тестирования в малом?

Основная цель стратегии интеграции — указать, какие модули объединять, когда и сколько одновременно.

118. Что такое полуслучайные тестовые случаи?

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

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

Читать р

Читать д

ЕСЛИ p + q> 100

ПОТОМ печать «Large»

ENDIF

ЕСЛИ р> 50

ПОТОМ Печать «P Large»

ENDIF

1 тест для покрытия выписки, 2 для покрытия филиала

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

Технический обзор.

121. Найденные неисправности должны быть первоначально задокументированы кем?

По тестерам.

122. Каким является действующий официальный всемирно признанный стандарт документации?

Там нет ни одного.

123. Что из нижеперечисленного является участником проверки, создавшим элемент для проверки?

автор

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

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

125. Почему анализ граничных значений дает хорошие контрольные примеры?

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

126. Чем инспекция отличается от других типов проверки?

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

127. Почему тестер может зависеть от управления конфигурацией?

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

128. Что такое V-модель?

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

129. Что такое техническое обслуживание?

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

130. Что такое тестовое покрытие?

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

131. Почему инкрементная интеграция предпочтительнее, чем интеграция «большого взрыва»?

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

132. Что называется процессом, начинающимся с терминальных модулей?

Интеграция снизу вверх

133. Во время какого теста можно найти ошибку наиболее эффективно?

Во время планирования теста

134. Целью этапа требования является

Заморозить требования, понять потребности пользователей, определить объем тестирования

135. Почему мы разделяем тестирование на отдельные этапы?

Мы разделили тестирование на отдельные этапы по следующим причинам:

  1. Каждый этап испытаний имеет свое назначение
  2. Проще управлять поэтапно
  3. Мы можем запустить разные тесты в разных средах
  4. Производительность и качество тестирования улучшаются с помощью поэтапного тестирования

136. Что такое DRE?

Чтобы измерить эффективность теста, мощный показатель используется для измерения эффективности теста, известного как DRE (Эффективность удаления дефектов). Из этого показателя мы узнаем, сколько ошибок мы обнаружили в наборе тестовых случаев. Формула для расчета DRE имеет вид

DRE = Количество ошибок во время тестирования / количество ошибок во время тестирования + количество ошибок, обнаруженных пользователем

137. Что из нижеперечисленного может извлечь наибольшую пользу от использования инструментов тестирования, обеспечивающих средства захвата и воспроизведения тестов? а) регрессионное тестирование б) интеграционное тестирование в) тестирование системы г) приемочное тестирование пользователя

Регрессионное тестирование

138. Как бы вы оценили количество повторного тестирования, которое может потребоваться?

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

139. Что изучает анализ потока данных?

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

140. Что такое неудача?

Отказ — это отклонение от указанного поведения.

141. Что такое тестовые компараторы?

Действительно ли это тест, если вы вводите какие-то данные в какое-то программное обеспечение, но никогда не смотрите, дает ли программа правильный результат? Суть тестирования состоит в том, чтобы проверить, дает ли программа правильный результат, и сделать это, и мы должны сравнить, что программное обеспечение производит с тем, что оно должно производить. Тестовый компаратор помогает автоматизировать аспекты этого сравнения.

142. Кто отвечает за документирование всех проблем, проблем и открытых вопросов, которые были выявлены в ходе обзорной встречи?

писец

143. Какова основная цель неофициального обзора

Недорогой способ получить выгоду

144. Какова цель методики проектирования тестов?

Идентификация условий тестирования и Идентификация тестовых случаев

145. При тестировании системы подсчета оценок тестировщик определяет, что все оценки от 90 до 100 будут давать оценку A, а оценки ниже 90 — нет. Этот анализ известен как:

Эквивалентное разбиение

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

147. Во время тестирования тестера модулей «Х» обнаружил ошибку и назначил ее разработчику. Но разработчик отвергает то же самое, говоря, что это не ошибка. Что должен делать «Х»?

Отправьте подробную информацию об обнаруженной ошибке и проверьте воспроизводимость

148. Тип интеграционного тестирования, при котором программные элементы, аппаратные элементы или оба сразу объединяются в компонент или общую систему, а не поэтапно.

Тестирование большого взрыва

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

V-модель

150. Какой метод можно использовать для достижения входного и выходного охвата? Он может применяться к вводу человеком, вводу через интерфейсы в систему или к параметрам интерфейса при интеграционном тестировании.

Эквивалентное разбиение

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

V-модель

152. В каком порядке следует проводить тесты?

Самый важный должен быть проверен первым

153. Чем позже в жизненном цикле разработки обнаруживается ошибка, тем дороже ее устранять. Почему?

Ошибка была встроена в дополнительную документацию, код, тесты и т. Д.

154. Что такое измерение покрытия?

Это частичная мера тщательности теста.

155. Что такое граничное тестирование?

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

156. Что представляет собой COTS?

Коммерческая с полки.

157.Цель, которая позволяет проводить конкретные тесты в системе или сети, максимально приближенной к среде, в которой тестируемый элемент будет использоваться после выпуска?

Тестовая среда

158. Что можно считать основанным на плане проекта, но с большим количеством деталей?

План фазовых испытаний

159. Что такое быстрая разработка приложений?

Быстрая разработка приложений (RAD) формально является параллельной разработкой функций и последующей интеграцией. Компоненты / функции разрабатываются параллельно, как если бы они были мини-проектами, разработки откладываются по времени, доставляются и затем собираются в рабочий прототип. Это может очень быстро дать клиенту что-то, что можно увидеть и использовать, а также предоставить обратную связь относительно доставки и их требований. Быстрое изменение и развитие продукта возможны с использованием этой методологии. Однако в какой-то момент для продукта необходимо будет разработать спецификацию продукта, и проект должен быть поставлен под более формальный контроль перед началом производства.

Порекомендуйте нашу — Тестирование Тест

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

 

Использование техник тест-дизайна — QA evolution

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

О некоторых техниках тест-дизайна поговорили тут:

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

Ну что обновляем тестовый сервер, и приступаем…

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

К чему приводит неправильное использование техник тест-дизайна

Подзаголовок правильнее было бы назвать даже не неправильное использование тест-дизайна. И в принципе не использование его. Как же это происходит на практике.

Получает тестировщик задачу, о том, что надо протестировать новый функционал в виде загрузки изображений. И начинается рандомное засовывание рандомных файлов в окно загрузки. Бессистемное изменение форматов, размеров, подстановка неправильных или несуществующих файлов, очень больших или абсолютно пустых, исполняемых и так далее. Буквальное через несколько минут начинают в мессенджерах лететь нотификации о том что драг-н-дроп в поле не работает, сервер выдает “500” если “тестер” ( уж извините) грузит фильм в формате 4К, а исполняемый скрипт выдает ошибку в поле имени. 

К чему же это приводит. Ну например владелец продукта вечером не смог загрузить обычное фото ( плюс минус стандартное) и показать своим клиентам демку новой фичи. Зато ребята успели пофиксить секьюрный баг ( он же такой критикал и заодно дган-н-дроп заработал) Почему это плохо ? Я думаю здесь нет смысла объяснять. Если нужно — пишите %-( .

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

Попробуем разобраться…

Использование техник тест-дизайна

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

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

Для чего создавалась фича ? Кто ее будет использовать ? На каких окружениях ? 

Какие форматы картинки нам не обходимы ? Размеры ? Разрешение ? Соотношение сторон важно ? Цветность фотографии важна ? Ширина / высота в пикселях ? 

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

Выберем параметры для проверки

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

Форматы: jpeg, png, ico, tiff, jpg, pdf, pnm, bmp, gif, raw, heic

Разрешение фотографии (количество точек): 320*240, 320*480, 640×480, 800×600, 1024×768, 1280×720, 1600×900, 1920*1080 

Соотношение сторон: 4:3, 5:3, 2:3, 5:4, 16:9, 8:5, 256:135 

Размер файла: 1 b, 1kb, 1mb, 10mb, 100 mb, 

Цветность фотографии: black and white, multi, specific, transparent ( казалось бы причем здесь цвета ) 

Стандарты размера фотографии ( при печати, пожалуй очень спорный пункт но оставим для массовки): 9×13, 10×15, 15×20, 15×30, 20×30, 30×40

По большому счету мы сейчас использовали аналитический подход, изучая нашу документацию с требованиями и выделили “эквивалентные классы” наших параметров, ошибки по которым будут отвечать за одну и ту же область. И наш метод не такой явный: как градация на цифры, буквы или только по формату файла ( например загруженный .doc будет открываться в гугл доках приложением  — документы, а excel в таблицах). Мы выделили далеко не все, но многие вещи. Возьмем за основу, что все остальное будет эквивалентный класс негативных тестов и будет приводить к одной и той же ошибке, иначе мы в нашем с вами сферическом тесте закопаемся. А еще у нас был случай, когда вот так вот закапывались в тестах…

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

Совершенствуем тесты с помощью техники тест-дизайна

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

Из форматов изображений сложно что-то убрать, уж слишком специфический у нас набор получился и любое исключение может привести к багу. А вот разрешение вполне подходит под один эквивалентный класс и взять можно граничные значения 320*240 и 1920*1080. В соотношении сторон тоже все понятно, а файл если отработает самый маленький и самый большой то будет все окей. Цветность фотографий в условиях переборки большинства форматов, тоже не волнует ( хоть и вряд ли повлияет на работу загрузки и отображения). Стандартные размеры фотографии для печати не так важны, но могут не верно отображаться, а значит стоит протестировать. Пожалуй стоит рискнуть и все же убрать несколько форматов в целях уменьшения тестов (при минимальном наборе можно было бы оставить — но в дальнейшем точно нужно будет избавится), предположим что мы это выяснили у БА — избавимся от jpg ( есть jpeg), pnm/bmp ( не столь популярен) и ico ( формат хранения файлов значков ).

Test-case
IIIIIIIVVVIVII
Форматjpegpngpdftiffgifrawheic
Разрешение фотографии320*240any1920*1080800×600anyany1280×720
Соотношение сторон2:35:316:95:48:5256:135 any
Размер файла1kb1bany1mb10mb100mb4,7mb
Цветность фотографиblack and whitetransparentanytransparentmultispecificany
Стандарты размера фотографии10×15,15×3020×3015×2030×40any9×13
ИСПОЛЬЗОВАНИЕ ТЕХНИК ТЕСТ-ДИЗАЙНА

Немного поработав во всех направлениях, как с техниками тест-дизайна так и БА/DEV, мы получаем минимальный набор тестов. Который с какой то высокой ) долей вероятности покроет большой процент возможных кейсов. Привыкайте думать в таких масштабах — фраза мы все протестировали — тянет в бездну. И наш клиент будет рад — а что еще нужно ? ) Там где мы добавили any — это возможность для большей фантазии и использования параметров не включенных в требования. Таким образом потратив совсем немного времени наш маленький большой QA сможет проведя около 7 тестов — спать спокойно сегодня вечером.

Вместо выводов о техниках

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

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

Тестируйте не числом, а умением

Автор: Scott Sehlhorst
Оригинал: Test Smarter, Not Harder
Перевод: Дмитрий Дудников по заказу Software-Testing.Ru

Эта статья о комбинаторных методах построения тестов первоначально была написана для developer.* в марте 2006 года. Недавняя статья на Dailytech обращает внимание на одно очень интересное исследование о новых методах генерации многомерных комбинаций (четверок и более), выполненное Лабораторией информационных технологий Национального института стандартов и технологий США (NIST, the National Institute of Standards and Technology). Данная переработанная и дополненная версия статьи учитывает эти результаты.

Введение

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

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

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

Часть 1

Проблемы

Вот краткое описание проблемной ситуации, с которой мы будем иметь дело:

  • У нас есть команда разработки, регулярно выпускающая новые версии программного обеспечения.
  • У нас есть набор тестов, с помощью которых мы тестируем наше ПО.
  • Наш набор тестов достаточно велик, и даже автоматизирован, но этого всё равно не хватает, потому что продукт сложен и нет способа протестировать все возможные сценарии.
  • Мы по-прежнему выпускаем продукт с ошибками, и как итог – не достигаем наших целей по качеству.
Aut Caesar aut nilil

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

Мы не можем позволить себе тестировать это

Несколько лет назад я смог посетить тренинг Кента Бека (Kent Beck). Вечером после занятий я имел удовольствие поужинать и выпить с ним пива. Когда я спросил его, как он отвечает людям, жалующимся на высокую цену хорошего качества, Кент дал очень простой ответ: «если тестировать стоит дороже, чем НЕ тестировать, то НЕ тестируйте». И я согласен с ним.

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

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

Просто тестируйте все подряд – ведь это автоматизировано

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

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

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

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

Сложность – причина тщетности усилий

Рассмотрим веб-страницу, позволяющую уточнить параметры покупаемого ноутбука. Если вы никогда не выбирали ноутбук в онлайне, то взгляните, к примеру, на страничку Dell для ноутбуков начального уровня – выберите какой-нибудь ноутбук, и на страничке с описанием его характеристик нажмите кнопку «Personalize».

На странице пользователю даны одиннадцать вопросов, каждый из которых имееет от двух до семи вариантов ответов. Точнее говоря, у нас есть (2,2,2,2,2,3,2,2,3,4,7) вариантов, которые может выбрать пользователь. Число вариантов, которые может выбрать пользователь, это произведение этих чисел. В нашем случае имеется 32 256 вариантов. Страница для конфигурирования профессиональных ноутбуков Dell на момент написания этой статьи имела похожий набор элементов с большим количеством вариантов — (3,3,3,2,4,2,4,2,2,3,7,4,4). Посетитель этой страницы может сформировать 2 322 432 различные конфигурации ноутбука! Если бы Dell добавил еще один управляющий элемент с пятью вариантами выбора, то мы бы имели более десяти миллионов возможных комбинаций!

Разумеется, набор тестов, перебирающий все два миллиона комбинаций для профессионального ноутбука, можно автоматизировать, но даже если бы каждый тест занимал одну секунду, весь набор работал бы более 640 часов! Это почти целый месяц. Dell чаще изменяет свой набор продуктов.

Если бы мы использовали группу серверов, распределив набор тестов между десятью машинами, мы смогли бы провести тестирование за 64 часа. Игнорируя тот факт, что такой тест придется делать для каждой модели ноутбука, которая есть у Dell, это время выглядит уже не столь нелогичным. Но всё равно Dell иногда изменяет свой набор продуктов ещё быстрее J

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

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

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

Часть 2

Решаем проблему

Существует множество приложений, которые имеют миллионы или миллиарды вариантов комбинаций входных параметров. Однако мы только что обсудили, насколько нерационально тестирование полным перебором. Как же они тестируют свое сложное программное обеспечение?

Случайная выборка

Вполне очевидно, что случайным образом проверяя различные сочетания входных параметров, можно найти ошибки. Однако представим, что программа имеет миллион комбинаций входных параметров (половину от предыдущего примера). Каждый случайный набор параметров дает нам покрытие в 0,000001% всего числа вариантов. Даже запустив 1000 тестов, мы будем иметь всего лишь 0,001-процентное покрытие множества входных данных.

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

Для начала давайте определим цель по качеству: мы хотим быть уверены, что наше ПО на 99% свободно от ошибок. Это означает, что не более, чем в 1% пользовательских сессий будут возникать ошибки. Чтобы быть на 100% уверенными, что это высказывание истинно, мы должны будем протестировать по меньшей мере 99% от всех возможных пользовательских сессий, то есть выполнить более 990 000 тестов.

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

Определим в качестве нашей цели 95% уровень достоверности того, что наше ПО на 99% свободно от ошибок. Уровень достоверности в 95% говорит о том, что если мы будем постоянно проводить эксперименты (то есть в нашем примере – делать случайную выборку определенного размера из множества входных данных и запускать на ней тесты), то в 95% случаев результаты этих экспериментов будут находиться в пределах допустимого (то есть среди них будет не более 1% завершившихся неуспешно).

Если у нас есть миллион комбинаций, то сколько из них требуется проверить, чтобы определить уровень качества с уверенностью в 95% и уровнем допустимых ошибок 1%? Алгоритмы расчета легко доступны, в сети есть бесплатные калькуляторы для определения размеров выборки. Требуемый для этого размер выборки – 9 513.

То есть, если мы протестируем 9 513 пользовательских сессий со 100%-м успехом, мы тем самым получим 95%-ную уверенность, что наше качество находится как минимум на уровне 99%. Для достижения 99%-ной уверенности нам потребовалась бы выборка несколько большего размера – 16 369.

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

99% уровень достоверности для 99% уровня качества
Количество уникальных комбинаций параметров Количество требуемых тестов (проверок)
100 99
1 000 943
10 000 6 247
100 000 14 627
1 000 000 16 369
10 000 000 16 613
100 000 000 16 638
Неизвестно 16 641

Вы видите, что несмотря на усложнение программного обеспечения, требуется не так много дополнительных тестов, чтобы достичь того же уровня качества. Если мы имеем умеренные цели по качеству, такие как 99/99 (99% уверенность в 99% качестве), этот подход является очень эффективным.

С другой стороны, этот подход не слишком хорошо масштабируется на более высокие уровни качества. Рассмотрим задачу получения «пяти девяток» (кода, свободного от ошибок на 99,999%). С увеличением желаемого уровня качества количество тестов, которые требуется выполнить, возрастает и быстро превращается в тот же самый полный перебор.

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

99% уровень достоверности для различных уровней качества
Желаемый уровень качества Количество требуемых тестов
90% 166
95% 9 513
99% 16 369
99,9% 624 639
99,99% 994 027
99,999% 999 940

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

Попарное тестирование входных параметров

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

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

Варианты выбора
Процессор Память Диск
Экономный Минимальная Большой
Стандартный Средняя Очень большой
Профессиональный Максимальная Гигантский

Мы можем успешно пройти тесты для каждого значения, доступного для параметра «Процессор», а после этого обнаружить, что тест выдает ошибку, если пользователь выбирает «Стандартный» процессор и «Гигантский» размер диска. Это показывает наличие зависимости между параметрами «Процессор» и «Диск».

Попарное тестирование (pair-wise testing) предназначено для покрытия всех сочетаний пар переменных без учета всевозможных комбинаций всех остальных переменных. В данном примере имеется 27 различных комбинаций выбора. Следующая таблица показывает первые 9 комбинаций, для остальных вариантов выбора Процессора также требуется по 9 комбинаций.

Варианты выбора
Процессор Память Диск
Экономный Минимальная Большой
Экономный Минимальная Очень большой
Экономный Минимальная Гигантский
Экономный Средняя Большой
Экономный Средняя Очень большой
Экономный Средняя Гигантский
Экономный Максимальная Большой
Экономный Максимальная Очень большой
Экономный Максимальная Гигантский

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

Варианты выбора
Процессор Память Диск
Экономный Минимальная Большой
Стандартный Средняя Очень большой
Профессиональный Максимальная Гигантский
Экономный Средняя Гигантский
Стандартный Максимальная Большой
Профессиональный Минимальная Очень большой
Экономный Максимальная Очень большой
Стандартный Минимальная Гигантский
Профессиональный Средняя Большой

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

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

Если мы вернемся к нашему предыдущему примеру с конфигурациией ноутбука, мы сможем посчитать количество тестов, требуемых для полного покрытия всех пар. Для конфигуратора ноутбука начального уровня имеется 32 256 уникальных комбинаций входных данных. Мы можем проверить все уникальные комбинации пар переменных с помощью 31 теста. Для конфигуратора профессиональных ноутбуков имеется 2 322 432 уникальных комбинации. Чтобы проверить все уникальные пары переменных, достаточно выполнить 36 тестов.

Тестирование сочетаниями по N

Концепция попарного тестирования может быть расширена до тестирования «сочетаниями по N» – комбинациями по N возможных параметров.

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

Покрытие тестами сочетаниями по N
N Экономная Профессиональная
1 7 7
2 31 36
3 110 179
4 318 749
5 814 2812

Этот способ гораздо лучше масштабируется. Используя N=3, мы получаем 179 тестов против 2,3 миллионов, требуемых для полного покрытия! Существующие исследования показывают, что N=3 обеспечивает порядка 90% покрытия кода, хотя это значение может меняться от приложения к приложению. Мы будем использовать N=3, поскольку практический опыт показывает, что тесты с N=4 редко обнаруживают ошибки, которые были бы пропущены при N=3.

Зависимость от порядка и статистическое тестирование

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

Имея в пользовательском интерфейсе 5 элементов, мы имеем 5! = 1*2*3*4*5 = 120 возможных последовательностей ввода. И хотя интерфейс может включать в себя динамическую фильтрацию, предохраняющую пользователя от определенных некорректных подмножеств значений аргументов, тестирование сочетаниями по N является «тестированием черного ящика» и не может иметь доступа к подобной информации.

Для того чтобы получить полное покрытие для интерфейса с M возможными элементами управления, каждый скрипт, созданный генератором тестирования сочетаниями по N, будет необходимо протестировать M! способами в соответствии с числом способов последовательно выбрать каждый из M элементов. Если элементы разнесены по нескольким экранам, то мы можем уменьшить число этих способов. Например, если на первом экране имеется пять элементов, и пять на втором, то вместо того, чтобы рассматривать 10! (3,6 млн последовательностей), мы можем рассмотреть все последовательности первого экрана в комбинации со всеми последовательностями второго экрана (5! * 5! = 120 * 120 = 14 400 последовательностей).

В нашем примере с ноутбуками имеется 11 и 13 элементов управления (все на одной странице) для экономной и профессиональной конфигурации соответственно (примечание: так было на момент написания статьи, сейчас Dell использует многостраничный конфигуратор). Следовательно возникает 11! и 13! возможных последовательностей (40 миллионов и 6 миллиардов).

Однако нам не нужно выполнять полное покрытие тестами последовательных перестановок всех параметров. Тестирование сочетаниями по N в особенности помогает анализировать кросс-зависимость между комбинациями из N управляющих элементов, остальные мы сознательно игнорируем, когда используем этот подход. Поэтому в качестве нижней границы нам потребуется запустить только N! наборов входных аргументов для каждого сгенерированного скрипта. Так, наш набор из 179 скриптов для профессиональных ноутбуков с N=3 потребует 3! * 179 = 1074 запуска.

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

Тестирование сочетаниями по N в случае, когда важна последовательность действий
N Экономная Профессиональная
1 7 7
2 62 73
3 660 1 074
4 7 632 17 976
5 97 680 337 440

Это нижняя граница, поскольку она предполагает доступность всех последовательностей в каждой группе из N элементов.

Существующие инструменты тестирования сочетаниями по N (насколько знает автор) не принимают в расчет порядок действий.

Для N=2 это тривиально – просто сделайте ещё один набор тестов с аргументами в обратной последовательности.

Мы можем учесть порядок действий, рассматривая его как дополнительный входной параметр. Он будет принимать столько значений, сколько существует подмножеств заданного размера N. Для вычисления используем соответствующую математическую формулу: M!/(N!*(M-N)!), где M – число входных параметров.

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

Число уникальных последовательностей для заданного запуска теста сочетанием по N
N Экономная Максимальная
1 11 13
2 55 78
3 165 286
4 330 715
5 462 1 287

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

Число уникальных последовательностей для заданного запуска теста сочетанием по N для разного количеуправляющих элементов
N Число управляющих элементов
3 4 5 6 7 8 9 10 15 20
1 3 4 5 6 7 8 9 10 15 20
2 3 6 10 15 21 28 36 45 105 190
3 1 4 10 20 35 56 84 120 455 1 140
4   1 5 15 35 70 126 210 1 365 4 845
5     1 6 21 56 126 252 3 003 15 504

Теперь можно сгенерировать тесты, задав инструменту N+1 параметр, и указав число уникальных последовательностей, как если бы это был элемент ввода.

К сожалению, нам не удалось найти элемент, способный работать с параметрами, принимающими больше 52 значений. Это ограничивает наши возможности по созданию тестов для N=3 всего семью параметрами.

Чтобы показать влияние последовательности ввода на количество тестов, рассмотрим интерфейс с 7 параметрами, каждый из которых имеет 5 возможных значений. N=3 потребует 236 тестов в случае, если порядок не важен. Затем включим последовательность выбора как параметр (добавив 8-й элемент управления с 35 возможными значениями и N=4). В этом случае инструмент генерирует 8 442 тестов. А теоретическая нижняя граница равна 236 * 35 = 8 260.

Часть 3 из 3
Как сделать это еще лучше

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

Карта зависимостей элементов управления

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

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

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

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

Мы сгруппировали в голубую рамку все элементы управления слева – это элементы, которые будут использованы для создания набора тестов в инструменте генерации сочетаниями по N. Группа справа также будет использована для генерации набора тестов.

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

Число уникальных последовательностей для заданного N-элементного сочетания против числа управляющих элементов
N 7 элементов 4 элемента + 4 элемента
Порядок неважен Порядок важен Порядок неважен Порядок важен
3 236 8 260 306 1 440

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

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

Эквивалентные значения можно объединить

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

Рассмотрим следующий пример требований к приложению:

Требования
Серебряный статус доступен учетным записям, имеющим 10 и более заказов
Золотой статус доступен учетным записям, имеющим 100 и более заказов
Платиновый статус доступен учетным записям, имеющим 500 и более заказов
Учетные записи должны иметь максимальный доступный им статус

Имеются две переменные, которые мы рассматриваем в нашем тестировании – представьте, что они являются элементами управления в пользовательском интерфейсе или величинами, получаемыми из внешней системы.

Все значения двух элементов управления
Число заказов Статус учетной записи
1-9 Платиновый
10-49 Золотой
50-99 Серебряный
100-499  
500-999  
1000+  

Для наших целей тестирования мы можем свернуть множества в следующий вид:

Все значения двух элементов управления
Число заказов Статус учетной записи
1-9 Платиновый
10-99 Золотой
100-499 Серебряный
500+  

Это слияние эквивалентных величин уменьшает количество тестов. Для нашего простого примера количество сочетаний уменьшилось с 18 до 12. Если используется больше элементов управления, и мы выполняем тестирование сочетаниями по N при N=3, сокращение гораздо более значительное.

Заключение

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

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

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

Тестирование сочетаниями по N при N=3 дает высокие по качеству тестовые наборы, но ценой увеличения количества тестов. В случае, когда имеет значение порядок ввода значений, возникает ограничение по числу переменных (менее 10), которое поддерживают современные инструменты генерации тестов.

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

Обсудить в форуме

Блеск и нищета автоматизации тестирования / Блог компании Wrike / Хабр


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

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

Преимущества автоматических тестов

Автоматизированное тестирование имеет ряд существенных преимуществ по сравнению с ручным тестированием.

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

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

Скорость — автоматические тесты выполняются на порядки быстрее, чем те же проверки, выполненные вручную. Конечно, бывают и сравнительно медленные тесты, но это скорее исключение, подтверждающее правило.

Точность — автоматические тесты проверяют ровно то, что описано в сценарии, во всех деталях и мелочах. Они не отвлекаются, не путают и не забывают.

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

Преимущества ручного тестирования

Ручное тестирование, тем не менее, превосходит автоматизированное по многим аспектам.

Проворность — проверить что-то вручную в первый раз легко и быстро. Автоматический тест нужно прежде разработать. Практически всегда это гораздо медленнее ручной проверки.

Гибкость — ручное тестирование можно проводить гораздо разнообразнее, и изменение способа тестирования практически ничего не стоит. Давайте протестируем в Safari — пожалуйста, на Chromebook — нет проблем, IE6 — придется запустить виртуальную машину, но тоже можно.

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

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

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

Выразительность — мало найти проблему на уровне “ничего не работает!”, важно правильно объяснить, в чем она заключается и уметь ответить на дополнительные вопросы разработчика. И в этом люди также лучше автоматических тестов.

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

Блеск парадоксов тестирования

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

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

Потратив на тестирование 1 день, мы добьемся 90% довольных пользователей. Тестируя неделю — 99%, тестируя месяц 99.5%. На достижение все меньшего и меньшего результата мы тратим все больше времени. Это нецелесообразно.

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

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

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

Ситуация в корне меняется в длительной перспективе. Код приложения необходимо рефакторить, чтобы он не умер. Когда программисты все переделали — тестировщики должны все проверить. Полный цикл регрессионных тестов. Неделя? Две? Месяц? Или еще хуже: программисты обновили версию ключевой библиотеки. День работы, вроде все компилируется — отлично! И все равно тестировщики должны проверить все. Безумие. Пройдя через такое несколько раз, любой будет готов пойти на что угодно, лишь бы избежать подобных ситуаций в будущем. Для обеспечения стабильного базового уровня качества необходимо вкладываться в автоматизацию тестирования.

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

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

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

Решение: написать автоматические тесты, которые все это делают.

Но не все так просто.

Написание тестов — это разработка, точно такая же, как и разработка основной бизнес-логики. Она требует ресурсов и квалификации. Обеспечивая качественное покрытие кода приложения тестами мы одновременно замедляем разработку как таковую. И замедляем не на 10%, а вдвое, втрое или даже больше.

Скорость — понятие относительное. Каждый конкретный тест, конечно, выполняется очень быстро, особенно чистые unit-тесты, когда все проверки происходят локально. Интеграционные тесты, REST-тесты тоже сравнительно быстрые. Что такое 100 миллисекунд, ну пусть даже 1 секунда, даже десятки секунд для selenium тестов — ерунда по сравнению с ручным тестированием. Но когда количество тестов хоть сколько-нибудь существенно, быстрые тесты оказываются очень даже медленными. Прогон тестов за 5 минут? Полчаса? Три часа? Два дня? Еще даже не добившись полноценного покрытия бизнес-логики, всерьез встает вопрос о том как запускать не все тесты, или запускать тесты не каждый раз — иначе уже автоматические тесты начинают тормозить разработку.

Примечание: Тесты можно существенно ускорить, вложившись в железо — выделить под них отдельный сервер, 10 серверов, 50 и т. д. Некоторые компании могут позволить себе и 1000 тестовых серверов, но далеко не все.

Инструментарий плох. Ни одна из мейнстримных платформ программирования не проектировалась с целью обеспечить возможность максимально просто и полноценно разрабатывать тесты. В Java все тестовые фреймворки являются сторонними библиотеками. Запуск тестов, осуществление проверок, создание mock-объектов — все это есть, но по частям и вне платформы. В Go тестовый фреймворк уже добавили в экосистему языка изначально, но это только запуск тестов. Выбор подходящего инструментария для написания тестов это отдельная проблема, требующая решения.

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

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

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

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

Количество тестов обманчиво: 3000 тестов в сумме — на веб-интерфейс, REST API, бизнес-логику и юнит-тесты — могут проверять с натяжкой 1000 ситуаций. Все остальное — дублирование.

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

Неудивительно что некоторые уходят из разработки продавать пластиковые окна, обучать бильярду или варить кофе (и это все реальные случаи).

О том, какие выводы мы в Wrike сделали из собственных и чужих ошибок, расскажу в следующем посте.

Дмитрий Мамонов

Департамент разработки,
Подразделение мержа в мастер,
Отдел работы с гит,
Ведущий оператор баш консоли 1 разряда

Тестирование CWDM систем

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

Применение CWDM

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

Стандартная схема системы CWDM основана на передаче между двумя и более узлами до 18 сигналов из диапазона 1270-1610 нм. На текущий момент в волоконно-оптических линиях не часто встречаются волокна с «водяным» пиком, поэтому используются все доступные длины волн. При работе с волокнами начальных версий спецификации g.652, из системы исключается возможность использования минимум двух длин волн: 1370 и 1390 нм.

Рисунок 1. Стандартная схема CWDM системы

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

Тестирование при развертывание CWDM

На этапе развертывания стабильной системы CWDM, после включения в линию пассивных устройств (мультиплексоры CWDM и OADM), необходимо протестировать каждую ветку системы на предмет вносимых затуханий для всего диапазона длин волн, которые будут использоваться. Для подобного тестирования идеально подходит оптический рефлектометр. При использовании рефлектометра снижается время измерений, сокращаются финансовые издержки на тестирование линии, особенно если речь идет о системе, ветки которой соединяют значительные расстояния. Стандартный рефлектометр для длин волн 1310 и 1550 нм для данной задачи подходит лишь в редких случаях, например, когда в линии не выводится ни одна из этих длин волн. В противном случае, рефлектометр проведет измерения только для одной-двух веток системы, а их может быть 9. Это связано с тем, что в точках установки мультиплексоров OADM 1310 и 1550 нм длины волн измерения будут выведены из системы.

Выходом в данной ситуации может послужить применение специализированного рефлектометра CWDM. Данный рефлектометр может проводить измерения на всех доступных длинах волн CWDM. Если в системе есть единый центральный узел, то из него возможно тестирование всех ответвлений системы. С рефлектометром CWDM для  каждой длины волны и каждого направления возможно проведение полноценного рефлектометрического исследования ВОЛС (рис. 2).

Рисунок 2. Тестирование потерь на ветке

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

Рисунок 3. Рефлектограмма CWDM OTDR

Рефлектограмма CWDM для каждой длины волны будет содержать информацию о потерях мощности на всех элементах линии, включая мультиплексоры OADM (рис. 3). На рисунке изображена рефлектограмма, полученная при помощи CWDM OTDR. Черный график отображает затухание для излучения на длине волны 1430нм, серые графики – для остальных испытуемых длин волн и направлений. Каждая рефлектограмма достоверно показывает снижение мощности сигнала и события на каждой ветке CWDM системы.

Тестирование сервисов в CWDM системе

Архитектура CWDM системы не подразумевает использования в линии активных устройств, таких как усилители оптической мощности. Транспортная часть CWDM системы содержит в своем составе только ВОЛС и мультиплексоры/демультиплексоры. Ошибки в работе системы возникают по вполне определенным причинам: неверное подключение портов, отказ передатчика на передающей стороне (или приемника на принимающей), неполадка в одном из мультиплексоров системы или в самой ВОЛС.

При запуске любого сервиса на узле необходимо убедиться в том, что уровень сигнала, который приходит из ВОЛС на приемник и уровень сигнала, излучаемого передатчиком, соответствуют минимальным расчетным требованиям. Сигналы в CWDM системе могут передаваться в диапазоне длин волн 1270-1610 нм, в свою очередь одновременно могут распространяться несколько сигналов на разных длинах волн и с различным уровнем, поэтому обычный измеритель мощности не подходит и требуется специализированное устройство. Этим устройством является измеритель мощности CWDM. Такой измеритель позволяет быстро определить наличие и уровень сигнала на 18-ти длинах волн из диапазона CWDM. Результаты измерения выводятся на экран cwdm-тестера и сохраняются в памяти для последующей обработки.

Рисунок 4. Измерение уровня сигналов CWDM

Для подтверждения соответствия уровня сигнала на передатчиках CWDM расчетным значениям при запуске системы, достаточно подключить измеритель мощности CWDM к линейному порту (com) головного мультиплексора CWDM (рис. 4, 1). Этот способ допустимо использовать только при запуске системы, потому что на работающей системе это приведет к отключению всех сервисов, передающихся через мультиплексор. Если мультиплексор имеет порт мониторинга (рис. 4, 2), на который отводится незначительная часть композитного сигнала, измерения уровней достаточно проводить подключаясь к данному порту. Измеритель мощности CWDM обладает высокой чувствительностью и позволяет проводить мониторинг сигналов, ослабленных на величину до 40 и более дБ.

Тестирование наличия и уровня сигнала при поиске неисправностей на удаленном узле заключается в проверке сигнала приходящего с сопряженного узла и мощности излучения передатчика (рис. 4, 3).

В общем случае, при подключении CWDM тестера в любой точке системы можно получить достоверные данные о присутствующих длинах волн и уровне сигнала на каждой из них (рис. 4, 4).

Для измерений параметров излучения в CWDM сетях можно использовать анализатор спектра, который позволяет работать с широким спектром длин волн. Это решение неэффективно в силу дороговизны и избыточности функций. Конкретно будет излишней функция определения отношения сигнал/шум (OSNR). Уровень OSNR в подавляющем большинстве случаев не имеет значения в системах спектрального уплотнения CWDM из-за отсутствия активных компонентов в системе, которые могли бы снижать его значение. Пара приемник-передатчик в CWDM системах сбалансирована и имеет допуски, достаточные для безотказной работы канала связи. Приобретение анализатора спектра CWDM экономически оправдано, если в дальнейшем оператор планирует активно использовать технологию уплотнения DWDM.

Устранение неисправностей в системах CWDM

При устранении неисправностей в системе CWDM удобно использовать CWDM OTDR совместно с измерителем оптической мощности CWDM. Измеритель мощности позволит определить причину неисправности (низкий уровень или отсутствие сигнала), а рефлектометр определит место возникновения неисправности, будь то неработающий трансивер, неисправный мультиплексор или проблема с ВОЛС.

Итог

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

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

Тестирование стратегий — Алгоритмический трейдинг, торговые роботы

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

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

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

К тестеру стратегий может быть подключено неограниченное количество агентов, работающих удаленно. Помимо этого в тестере стратегий доступна для использования огромная сеть облачных вычислений MQL5 Cloud Network. Она объединяет тысячи агентов по всему миру, и эта вычислительная мощь доступна любому пользователю торговой платформы.

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

Как провести тестирование #

Тестированием советника называется его одиночный проход с фиксированными параметрами на исторических данных. Оно позволяет проверить работоспособность стратегии перед ее использованием на реальном рынке.

Посмотреть видео: Бесплатное тестирование советников и индикаторов перед покупкой

Посмотрите краткое видео, как протестировать торгового робота перед покупкой в Маркете. Для тестирования в Маркете имеются специальные демо-версии, которые можно проверить в Тестере стратегий. О том, как это делается мы и расскажем в этом видео.

Быстрый выбор задачи тестирования #

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

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

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

Ниже будут рассмотрены все доступные параметры тестирования.

Выбор торгового робота для тестирования #

Выполните команду » Тестировать» в контекстном меню нужного советника в окне «Навигатор».

После этого советник будет выбран в тестере стратегий.

Включение необходимых символов в окне «Обзор рынка» для мультивалютных экспертов #

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

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

Перед началом тестирования мультивалютного эксперта включите требуемые для тестирования инструменты в «Обзоре рынка». В контекстном меню нажмите » Символы» и включите показ необходимых инструментов.

Выбор настроек тестирования #

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

Символ и период

Выберите основной график для тестирования и оптимизации. Выбор символа необходим для срабатывания событий OnTick(), заложенных внутри экспертов. Также выбранные символ и период влияют на специальные функции в коде советника, которые используют параметры текущего графика (например, Symbol() и Period()). Иными словами, здесь выбирается график, к которому был бы присоединен советник.

Интервал

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

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

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

Форвард-период

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

Первая часть называется периодом бэк-тестирования. На ней проводится адаптация работы советника. Вторая часть называется периодом форвард-тестирования, на ней проводится проверка выбранных параметров советника.

Режим торговли

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

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

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

Без задержки

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

Произвольная задержка

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

Таким образом, вероятность задержки исполнения на 0-8 секунд составляет 90%, а вероятность задержки на 9-18 секунд составляет 10%.

Фиксированная задержка

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

Режим генерации тиков

Выберите один из режимов генерации тиков:

  • Все тики — наиболее точный, но и наиболее медленный режим моделирования. В нем моделируются все тики.
  • Каждый тик на основе реальных тиков — максимально приближенный к реальным условиям режим. Используются реальные тики, накопленные брокером по финансовым инструментам. Моделирование не осуществляется. Тиковые данные имеют большой размер, при первом запуске тестирования их скачивание с сервера брокера может занять продолжительное время.
  • OHLC на М1 — в данном режиме моделируются лишь 4 цены каждого минутного бара — цены Open, High, Low и Close.
  • Только цены открытия — в данном режиме моделируются также цены OHLC, однако для тестирования/оптимизации используется лишь цена открытия.
  • Математические вычисления — в данном режиме тестер не будет подкачивать исторические данные, информацию о символах и не будет генерировать тики. Будут вызваны только функции OnInit(), OnTester() и OnDeinit(). Таким образом тестер можно использовать для различных математических вычислений, где требуется подбор параметров.

Более подробно режимы генерации тиков описаны в отдельном разделе.

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

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

Начальный депозит и плечо

Укажите объем начального депозита для тестирования и оптимизации советника. По умолчанию используется валюта депозита счета, который в данный момент подключен, но вы можете указать любую другую. При этом учитывайте, что для корректного тестирования на счете должны быть доступны кросс-курсы для пересчета прибыли и маржи в указанную валюту депозита. В качестве кросс-курсов могут быть использованы только инструменты с типом расчета «Forex» или «Forex No Leverage».

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

Быстрый переход к редактированию советника

Если у вас есть исходный код выбранного советника, то при помощи этой кнопки вы можете быстро перейти к его редактированию в MetaEditor.

Управление настройками тестирования

Используйте это меню для удобного управления настройками тестера: сохраняйте наборы настроек для разных экспертов в виде ini-файлов, чтобы потом возвращаться к ним в пару кликов. Вы также можете скопировать текущие настройки тестирования в буфер обмена, просто нажав Ctrl+C. Далее отредактируйте их в любом текстовом редакторе, скопируйте и загрузите в тестер, нажав Ctrl+V.

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

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

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

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

Расширенные настройки тестирования

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

Визуальное тестирование

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

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

Выбор входных параметров #

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

Задайте значение для каждого входного параметра.

Наборы параметров. Чтобы вы могли в любой момент вернуться к текущим настройкам MQL5-программы, сохраните набор параметров через контекстное меню:

  • Чтобы сохранить набор в виде set-файла на компьютере, нажмите «Сохранить». Такие файлы можно переносить между платформами на разных компьютерах, передавать другими пользователям.
  • Чтобы сохранить набор для последующего удобного использования в текущей платформе, нажмите «Сохранить набор». Сохраненные таким образом параметры будут доступны в подменю «Загрузить версию». Их можно в любой момент применить, просто выбрав из списка.

Расширенные настройки тестирования #

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

Общие настройки

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

Маржа

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

Уровень средств на счете, при достижении которого он переходит в состояние Margin call.

Уровень средств, при достижении которого на счете принудительно снимаются ордера и закрываются торговые позиции. Оба уровня можно указывать в деньгах и в процентах. В первом случае уровни определяются как значение показателя «Средства» на счету. При выборе опции «В процентах» уровни определяются как значение показателя «Уровень маржи» на счету (Средства/Маржа*100).

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

  • Не использовать нереализованную прибыль/убыток — не учитывать открытые позиции при расчете.
  • Использовать нереализованную прибыль/убыток — использовать при расчете убыток и прибыль по открытым позициям.
  • Использовать нереализованную прибыль — использовать только прибыль.
  • Использовать нереализованный убыток — использовать только убыток.

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

  • Использовать дневную фиксированную прибыль/убыток — учитывать прибыль и убыток, зафиксированные в течение торгового дня, в свободной марже.
  • Использовать дневной фиксированный убыток — учитывать только убыток, зафиксированный в течение торгового дня, в свободной марже. В течение дня накопленная прибыль фиксируется в отдельном поле счета («Заблокировано»). По окончании торгового дня накопленная прибыль освобождается (обнуляется) и отражается на балансе счета (учитывается в свободной марже).

Освобождать накопленную прибыль в конце дня — данная опция доступна только при включении опции «Использовать дневной фиксированный убыток». Если она включена, то в конце торгового дня прибыль, накопленная в течение дня, будет освобождаться и записываться на баланс (а соответственно учитываться в свободной марже). В ином случае — не будет.

Комиссия

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

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

Чтобы использовать настройки комиссии текущего торгового счета, включите опцию «Использовать предопределенные комиссии».

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

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

Комиссию можно взимать немедленно после каждой совершенной сделки или же накапливать в течение торгового дня или месяца и затем взимать единой операцией:

  • Немедленное — комиссии начисляются немедленно при каждом совершении сделки. Размер комиссии, начисляемой немедленно, отображается в поле «Комиссия» сделок. При немедленном начислении уровни комиссий указываются в объеме (не в обороте).
  • Ежедневное — сумма комиссий накапливается в течение дня в специальном поле состояния счета «Заблокировано». В конце дня накопленная сумма списывается со счета отдельной балансовой операцией (сделка с типом Daily commission или Daily agent commission).
  • Ежемесячное — сумма комиссий накапливается в течение месяца в специальном поле состояния счета «Заблокировано». В конце месяца накопленная сумма начисляется/списывается со счета отдельной балансовой операцией (сделка с типом Monthly commission или Monthly agent commission).

Также комиссию можно взимать в зависитот от объема каждой сделки или от ежедневного или ежемесячного оборота. От выбранного варианта зависит, объемы чего указываются в полях «От» и «До» — сделки или оборота.

  • Объем — уровни комиссии задаются по объему (количеству лотов) каждой совершенной торговой операцией сделки. Например, если задать уровни 0 — 10 и 12 — 20, сделка объемом 15 лотов попадет во второй уровень комиссии. Этот вариант используется, если выбран режим «Ежедневно», «Ежемесячно» или «Немежденно».
  • Оборот в деньгах — уровни комиссии задаются по обороту в деньгах за выбранный период (день или месяц). Например, заданы уровни 0 — 500, 501 — 1000, начисление производится ежемесячно. Пока общая стоимость операций не превышает 500 единиц, будет взиматься комиссия в соответствии с первым уровнем. Как только денежный оборот превысит значение 500, комиссия за последудющие сделки будет взиматься в соответствии со вторым уровнем.
    По умолчанию, оборот в деньгах рассчитывается в валюте депозита: рассчитывается стоимость каждой сделки, а затем эта стоимость приводится к валюте депозита. Например, стоимость позиции Buy 1 lot EURUSD при размере контракта 100 000 составляет 100 000 EUR. Если вы используете валюту депозита USD, стоимость позиции будет сконвертирована по курсу EURUSD на момент совершение сделки (в данном случае, по цене сделки).
  • Оборот в объеме — уровни комиссии задаются по совокупному объему торговых операций (количество лотов) за выбранны период (день или месяц).

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

По сделкам разворота в режиме «Сделки входа» комиссия взимается только с объема вновь открытой позиции, в режиме «Сделки выхода» — только с закрытого объема. Для сделок на закрытие позиции встречной (Close By) действуют следующие правила:

  • При настройках «Сделки входа/выхода» и «Сделки входа» комиссия со сделок Close By не взимается, так как она уже удержана со сделок, образовавших обе позиции. Например, комиссия взимается в размере 1 USD за каждую сделку. При совершении сделок входа Buy 1.00 EURUSD и Sell 1.00 EURUSD с клиента будет удержана комиссия в размере 2 USD. При закрытии позиции 1.00 EURUSD позицией Sell 1.00 EURUSD с клиента не будет удержана комиссия.
  • При настройке «Сделки выхода» комиссия взимается с обеих сделок Close By, ее итоговое значение записывается в основную сделку выхода (в которой указана прибыль/убыток). Например, комиссия взимается в размере 1 USD за каждую сделку. При совершении сделок входа Buy 1.00 EURUSD и Sell 1.00 EURUSD с клиента не будет удержана комиссия. При закрытии позиции 1.00 EURUSD позицией Sell 1.00 EURUSD будет удержана комиссия в размере 2 USD. В первой сделке out by будет указана комиссия 2 USD, во второй сделке out by комиссия будет указана как нулевая.

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

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

Объем комиссионных сборов. Единицы измерения зависят от способа начисления комиссии, выбираемого в поле «Режим».

Минимальный объем взимаемой комиссии. Единицы, в которых указывается значение, зависят от выбранного способа начисления (в базовой валюте, валюте группы, пунктах и т.д.). Чтобы не ограничивать минимальный размер комиссии, установите значение 0.

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

Единицы расчета комиссионных соборов:

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

Тип начисления комиссии:

  • За сделку — при выборе данного типа комиссионные сборы будут взиматься с каждой совершенной сделки.
  • За объем — данный тип начисления позволяет взимать комиссию с объема (с каждого лота) совершаемых сделок. Учитывается только исполненный объем торговых запросов.

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

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

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

Запуск тестирования #

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

Где посмотреть результаты тестирования #

Результаты тестирования советников отображаются на вкладках «Бэктест» и «График».

Отчет о тестировании

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

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

Подробная информация о показателях представлена в разделе «Отчет о тестировании».

График тестирования

На вкладке «График» можно легко визуально определить, насколько успешно отработал советник на выбранном инструменте на выбранном интервале времени.

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

  • Значения баланса выводятся на график каждый раз при их изменении (закрытии позиции), значение средств дополнительно выводятся с некоторой периодичностью между изменениями баланса.
  • При тестировании на счетах с биржевой моделью управления рисками на графике отображается только средства (эквити), баланс и нагрузка на депозит не показываются. Торговое состояние таких счетов оценивается по уровню средств. Сам по себе баланс показывает лишь сумму собственных денег на счету и не учитывает активы и обязательства трейдера. Нагрузка на депозит (margin/equity) не показывается, так как маржа в биржевом расчете представляет собой текущую стоимость актива/обязательства с учетом дисконта, и она изменяется вместе с эквити.

Ход тестирования в журнале

Ход выполнения тестирования отображается на вкладке «Журнал», дополнительно в журнал выводятся сообщения самого советника. При включении режима визуального тестирования, ход тестирования можно просмотреть непосредственно на графике.

Ход тестирования на графике

После окончания тестирования можно открыть график, на котором был протестирован советник (выбранные символ и период). Для этого нажмите » Открыть график» в контекстном меню вкладки «Бэктест». На графике отображаются все сделки, совершённые советником во время тестирования. При наличии шаблона с названием tester.tpl в каталоге /profiles/templates торговой платформы, именно он будет применен к открываемому графику. При его отсутствии применяется шаблон по умолчанию (default.tpl).

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

Форвард тестирование для проверки робота на неоптимизированном участке #

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

Чтобы включить форвард-тестирование, на вкладке «Настройки» в поле «Форвард-период» укажите, какую часть общего периода необходимо использовать для него:

  • нет — не использовать форвард-тестирование;
  • 1/2 — использовать половину указанного периода для форвард-тестирования;
  • 1/3 — использовать треть указанного периода для форвард-тестирования;
  • 1/4 — использовать четверть указанного периода для форвард-тестирования;
  • пользовательский — при выборе данного поля, в поле справа укажите дату, с которой будет начато форвард тестирование.

  • Для форвард-тестирования всегда берется вторая (последняя) часть общего периода.
  • На графике дата начала форвард-период отмечается вертикальной линией.

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

Результаты тестирования на форвард-периоде отображаются на отдельной вкладке «Форвард». На графике дата начала форвард-период отмечается вертикальной линией.

Более подробно о получаемой в результате тестирования информации можно узнать в разделе «Где посмотреть результаты тестирования».

Визуальное тестирование #

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

Для визуального тестирования поставьте галочку «Визуализация» в настройках:

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

Настройте параметры тестирования и входные параметры, а затем нажмите «Старт».

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

Управление процессом тестирования

Чтобы приостановить, ускорить или замедлить тестирование, используйте панель инструментов. Здесь же можно прокрутить тестирование до определенной, интересующей вас, даты.

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

Наблюдение за торговлей советника на графике

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

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

  • Вы можете изменить внешний вид графика, отобразить на нем индикаторы или графические объекты. Для этого используйте шаблон. Чтобы шаблон был применен, его имя должно совпадать с именем тестируемого советника, например, ExpertMACD.tpl. Сам шаблон должен располагаться в папке /profiles/templates торговой платформы.
  • Список символов, по которым можно просмотреть график, ограничивается основным символом тестирования, а также символами, чьи данные использует советник.
  • Отсутствует возможность переключения периода графика. Для основного графика тестирования, используется период, выбранный в настройках. Для остальных символов используются периоды, запрошенные советником.
  • Переключение между символами осуществляется через меню «Вид — Графики».

Просмотр ценовых данных в Обзоре рынка

В окне «Обзор рынка» отображаются цены, генерируемые в процессе тестирования. Оно схоже с одноименным окном торговой платформы, однако обладает рядом особенностей. Показать/скрыть данное окно можно выполнив команду «Обзор рынка» в меню «Вид» или нажав сочетание клавиш «Ctrl+M».

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

На вкладке «Тики» отображается график цен, генерируемых в процессе тестирования. Количество отображаемых тиков ограничивается 64 тысячами.

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

В окне данных можно посмотреть информацию о ценах (OHLC), дате и времени бара, спреде, объеме, а также об используемых индикаторах. Здесь можно быстро получить требуемую информацию об отдельном баре и наложенных индикаторах в выбранной точке графика. Включение/отключение данного окна происходит при нажатии кнопки «Окно данных» в меню «Вид» или сочетанием горячих клавиш «Ctrl+D».

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

Просмотр деталей торговых операций в окне Инструменты

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

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

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

Дополнительную информацию тестировании можно найти в Журнале. В него записываются вся информация о тестировании и действиях советника во время него.

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

Тестирование индикаторов в визуальном режиме #

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

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

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

 

стратегий тестирования минимально жизнеспособного продукта (MVP)

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

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

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

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

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

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

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

Качество

при минимальном тестировании — вопросы и ответы с Питом Валеном

** Это продолжение в блоге вопросов и ответов, последовавшее за гостевым вебинаром, который Пит Вален провел в рамках серии веб-семинаров PractiTest.

Достижение качества с минимальным количеством «испытаний»

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

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

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

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

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

Чтобы просмотреть исходную сессию вебинара, к которой относятся вопросы, перейдите сюда

Вопрос 1: Мы всегда говорим о критических моментах тестирования или о том, как обеспечить максимальное качество.А как насчет качества тестера? Считаете ли вы, что по мере роста спроса на тестировщиков все больше и больше людей становятся тестировщиками независимо от требуемого набора навыков?

[Пит] Трудно научиться вдумчивому тестированию, работе, которая выходит за рамки проверки «ожидаемых результатов» и «критериев приемки». Трудно учить, когда люди не открыты для идеи.

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

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

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

Если выполняется ТОЛЬКО тестирование исполняемого кода, нет реальной связи между тестированием и качеством. Никакое количество программного обеспечения для тестирования после того, как оно было закодировано, не сделает его качественным продуктом.

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

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

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

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

Вопрос 3: Что вы думаете о кросс-функциональных scrum-командах, включая сотрудников UX / UI и Ops в каждую команду?

[Pete]: Полностью укомплектованные, кросс-функциональные команды, в которых представлены все области специализации, немного похожи на «Золотое руно» — все думают, что это фантастическая идея, и очень хотят ее.Потом пытаются подобрать и узнать, насколько тяжелое золотое руно. Для большинства компаний это очень дорогое предложение.

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

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

Если они ДЕЙСТВИТЕЛЬНО встроены в вашу команду, и они хороши в своем деле, то радуйтесь и радуйтесь.

Вопрос 4: Какой самый интересный баг или неожиданный результат вы видели в своей карьере?

[Пит]: Я подумал об этом минуту.Моя первая реакция была — «Нет. Большинство вещей довольно обыденны. Множество людей нашли более крутые ошибки ».

Затем я вспомнил об инструменте «System Health Monitor», который тестировал несколько лет назад. Идея заключалась в том, что на хост-сервере (или серверах) в фоновом режиме будет работать небольшой фрагмент кода. Он будет делать такие вещи, как периодическая проверка состояния файловой системы или системы БД. Также будет проверяться состояние самой системы, памяти, производительности и так далее.

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

Довольно крутая штука для того времени.

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

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

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

Вопрос 5: Есть ли какие-либо рекомендации по достижению качества путем принятия правила 80 x 20 с минимальным тестированием?

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

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

Ключ — экспериментирование.

Вопрос 6: Как быть добрыми к разработчикам?

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

О. Время от времени приносите им сладости или выпечку.

Вопрос 7 a: Какие-либо предложения для руководящих работников старшего возраста… над какими областями им нужно работать… как они могут перейти к автоматизации \ новым технологиям?
Вопрос 7 b: Как стажер по контролю качества Сэр, что бы вы предпочли сделать, чтобы улучшить себя в этой области?


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

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

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

Вопрос 8: Как изменить мнение разработчиков о тестировании?

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

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

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

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


О Пите Валене

Питер Г.Вален обладает более чем 25-летним опытом разработки, качества, тестирования и гибкой разработки программного обеспечения. Он много работает, чтобы помочь командам понять, как их программное обеспечение работает и взаимодействует с другим программным обеспечением и людьми, которые его используют. Он является членом Agile Alliance, Scrum Alliance и Американского общества качества (ASQ), а также активным участником встреч по программному обеспечению и частым докладчиком на конференциях.

О программе PractiTest

Practitest — это инструмент для сквозного управления тестированием, который дает вам контроль над всем процессом тестирования — от ручного тестирования до автоматизированного тестирования и CI.

Разработанный тестировщиками для тестировщиков, PractiTest может быть адаптирован к постоянно меняющимся потребностям вашей команды.

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

Передовой опыт испытаний на твердость по Роквеллу

Основы испытаний на твердость

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

Что такое испытание на твердость при вдавливании?

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

Важность хорошей практики

Для получения точных и надежных результатов измерения твердости по Роквеллу первостепенное значение имеет обеспечение того, чтобы операторы и применяемые методы следовали надлежащей методике и практике испытаний. Точный характер и точность теста Роквелла требуют строгого соблюдения протокола твердости и соблюдения стандартов. С единицей измерения для одной обычной точки Роквелла, равной всего 0.002 мм (прибл. 0,00008 дюйма) становится очевидным, что такое точное измерение требует очень точной измерительной системы и процесса. Неспособность правильно подготовить и выполнить испытание на твердость по Роквеллу может привести к скомпрометированным данным испытаний или ошибочным показаниям, что потенциально может способствовать производству и поставке некачественного продукта. Это может иметь пагубные и катастрофические последствия для производительности и целостности товаров, в которых они используются.

  • Тип материала
  • Толщина образца
  • Площадь / ширина
  • Место проведения испытания
  • Однородность материала
  • Ограничения масштаба

Методы испытаний по Роквеллу — шкала испытаний

Следование передовой практике и соблюдение применимых стандартов относительно несложно и в значительной степени будет способствовать получению достоверных и точных результатов.Прежде всего в процессе испытаний по Роквеллу определение правильной шкалы твердости, которая будет использоваться на тестируемом компоненте. Существует 30 различных шкал Роквелла, и большинство приложений покрывается шкалами Rockwell HRC и HRB для тестирования большинства сталей, латуни и других металлов. В связи с увеличением использования материалов, отличных от обычной стали и латуни, а также требований к испытаниям тонких материалов и листовой стали, необходимы базовые знания факторов, которые необходимо учитывать при выборе правильной шкалы, чтобы гарантировать точный тест Роквелла в случае необходимости.Выбор делается не только между обычным испытанием на твердость и испытанием на поверхностную твердость, с тремя различными основными нагрузками для каждого, но также между алмазным индентором и сталью диаметром 1/16, 1/8, 1/4 и 1/2 дюйма. шариковые инденторы. Часто технические условия устанавливаются на этапе проектирования материалов, и оператор может полагаться на задокументированные требования к масштабу. Если спецификации не существует или есть сомнения в пригодности заранее определенной шкалы, следует проанализировать следующие факторы, которые влияют на выбор шкалы:

Тип материала

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

Толщина материала

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

Поддерживать

Поддержка образца также чрезвычайно важна при испытаниях по Роквеллу из-за того, что метод включает измерение глубины. Любое движение образца передается индентору и измерительной системе, в результате чего в испытание вносится ошибка. Учитывая точный характер теста (учитывая, что один балл Роквелла по обычной шкале равен 0.002 мм или 0,00008 дюйма) перемещение всего на 0,001 дюйма может вызвать ошибку более 10 пунктов Роквелла. Опорную опору следует выбирать в соответствии с геометрией образца и обеспечивать полную и бескомпромиссную опору, при этом важно, чтобы опора была достаточно жесткой, чтобы предотвратить любую деформацию во время использования. Есть определенные критерии, которым должны соответствовать все наковальни; Хорошей ссылкой является ASTM E18, где можно найти основные рекомендации, включая рекомендации по твердости наковальни. Опорный выступ и поверхность, на которой находится образец, должны быть параллельны друг другу, а наковальня должна располагать испытуемый образец перпендикулярно индентору.И опорная поверхность и плечо должны быть свободны от зазубрин, царапин и грязи, и быть достаточно дизайна, чтобы должным образом поддерживать материал при тестировании. Наковальни следует проверять на регулярной основе, обычно перед каждым использованием, и, если обнаруживается, что они слишком повреждены, их следует заменить. Поврежденные, зазубренные или грязные инденторы могут вызвать значительный дрейф и проблемы с воспроизводимостью показаний твердости. Существует множество стандартных приспособлений, а также приспособлений, изготовленных по индивидуальному заказу, для приспособления к испытуемым образцам различной геометрии.Некоторые из наиболее распространенных наковальней включают плоские или плоские наковальни для поддержки плоских поверхностей, наковальню типа «V» для поддержки цилиндрических деталей и цилиндрическую наковальню для деталей большего диаметра. Еще одна часто используемая наковальня — это опорная наковальня, которая имеет небольшое выступающее плоское пятно и используется при проверке небольших, тонких деталей или деталей неправильной формы, а также испытательных материалов, не имеющих действительно плоского дна. Поскольку важно, чтобы между испытуемой деталью и частью наковальни непосредственно под индентором был обеспечен контакт, небольшое выступающее пятно сводит к минимуму эффект, который может быть реализован с неплоскими испытательными образцами, за счет уменьшения площади поверхности контакта.Неплоские образцы для испытаний следует поместить на точечную наковальню изогнутой стороной вниз, чтобы обеспечить прочный контакт с наковальней в точке испытания. Для поддержки изделий из тонкого листа рекомендуется использовать алмазную пятно наковальню. Эта наковальня состоит из слегка приподнятой плоской полированной алмазной поверхности, которая поддерживает образец для испытаний и предотвращает повреждение и влияние, которые могут возникнуть при использовании стандартной наковальни. Эта наковальня используется только с весами Rockwell 15 или 30 T. Никогда не рекомендуется использовать алмазный индентор с алмазной наковальней, поскольку возможна поломка как индентора, так и наковальни.Наковальня с гусиной шеей рекомендуется для проверки поверхностей наружного диаметра тонкостенных труб. Обычно он навинчивается на ходовой винт тестера или опорный держатель и включает в себя оправку в верхней части для поддержки тестируемой детали, которая помещается поверх этой оправки, чтобы предотвратить соответствие материала во время испытания. Более крупные детали могут поддерживаться с помощью испытательных столов большого диаметра или стола с Т-образным пазом, который можно использовать для закрепления испытательного образца на столе. Из-за размера и веса стола с Т-образным пазом их можно использовать только с тестерами Rockwell®, которые приводят индентор вниз к неподвижному столу, прикрепленному к основанию тестера, а не для введения детали в алмаз через провод. винт срабатывания.Еще одно полезное приспособление — приспособление Vari-Rest, которое выдвигается горизонтально для поддержки удлиненных деталей.

Перпендикулярность

Основным требованием является то, чтобы поверхность, на которой должен быть нанесен отступ, была перпендикулярна направлению движения индентора и чтобы испытательный образец не двигался или не скользил во время цикла испытания. Исследование показало, что влияние на шкалу HRC показало, что угол наклона в один градус между поверхностью образца и осью индентора может привести к 5% погрешности в твердости.Угол наклона никогда не должен превышать 2 градуса, чтобы обеспечить точность тестирования. Перпендикулярность индентора на образце зависит от многих факторов, в том числе противоположных поверхностей материала, опорной наковальни и механических компонентов в тестере. Кроме того, индентор и держатель индентора играют решающую роль в перпендикулярности.

Расстояние между отступами

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

Цилиндрические испытания и поправочные коэффициенты

При испытании на цилиндрических поверхностях результаты обычно показывают более низкое значение твердости, чем если бы материал был плоским. Это условие связано с кривизной образца для испытаний и зависит от приложенной силы; твердость материала; размер и форма углубления; и диаметр образца для испытаний. Если испытания будут использоваться только для целей контроля, а все другие факторы остаются равными (диаметр образца, масштаб и индентор), будет достаточно информации, чтобы сравнивать данные и последующие испытания.Однако в большинстве случаев лучше сравнивать твердость закругленного материала со значением твердости плоского изделия, что требует поправочных коэффициентов. В цилиндрической детали уменьшение боковой поддержки приведет к дальнейшему проникновению индентора в материал, что приведет к более низким показаниям твердости. Если диаметр материала больше 25 мм (1 дюйм), поверхность будет обеспечивать подходящую структуру поверхности для испытаний, и корректировки не требуются. Для материалов с меньшим диаметром потребуется поправочный коэффициент, добавленный к результату испытания.Большинство доступных цифровых тестеров Rockwell обеспечивают соответствие диаметру цилиндра, и к результату автоматически добавляется поправочный коэффициент. В ручных тестерах циферблатных манометров необходимо обращаться к таблицам поправок ASTM, чтобы определить правильный коэффициент для регулировки. В качестве альтернативы, и в отличие от выпуклых поверхностей, вогнутые поверхности будут обеспечивать более высокую опору материала из-за кривизны в направлении индентора и приводить к очевидно более твердому материалу из-за образования более мелкой выемки.В этом случае необходимо вычесть поправочный коэффициент. Следует отметить, что все исправления дают приблизительные результаты, и не следует ожидать, что они будут соответствовать точным спецификациям. Кроме того, при испытании цилиндров очень важно обеспечить точное выравнивание индентора по радиусу.

Чистота поверхности

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

Другие важные факторы, которые следует учитывать

    При проведении испытаний по Роквеллу следует также учитывать многие основные, но важные факторы.
  • Важнейшими элементами являются чистота материала, опорных пят, инденторов и любых соприкасающихся поверхностей, а также общее состояние машины.
  • Также следует учитывать окружающую среду инструмента. Избегайте участков с чрезмерной вибрацией, чтобы не повлиять на работу тестера и показания твердости. Следует обеспечить поддержание постоянного температурного диапазона в месте установки тестера, ASTM рекомендует проводить испытания при температуре окружающей среды от 50 до 95 ° F (10-35 ° C).Эксплуатация тестера при экстремальных температурах может иметь неблагоприятные результаты по результатам испытаний.
  • Также важна ежедневная косвенная проверка работоспособности тестирующего инструмента; используемые весы должны быть проверены с помощью стандартных тестовых блоков или купонов. По возможности рекомендуется проверять систему при каждой смене шкалы и при каждом запуске смены. Следует выбирать блоки, которые примерно соответствуют исследуемому материалу, и использовать их только на калиброванной стороне.Для установки наковальни, блока и индентора необходимо сделать два «посадочных» углубления. Эти значения следует отбросить до фактической записи результатов. В процессе проверки должно быть сделано пять общих показаний; измеренные значения должны находиться в пределах допуска, указанного на блоке и в сертификате блока. Если проверка не удалась, машину следует вывести из эксплуатации до тех пор, пока не будут выполнены соответствующие настройки или ремонт. Следует проводить периодический визуальный осмотр алмазных и шариковых инденторов на предмет повреждений, которые могут возникнуть во время испытаний, и их следует заменить.
  • Наконец, техническое обслуживание и авторизованная проверка прибора являются обязательными для непрерывной бесперебойной работы и гарантии того, что система соответствует требованиям точности теста Роквелла. ASTM рекомендует ежегодное обслуживание и проверку тестера Rockwell и более частую проверку при интенсивном использовании или экстремальных условиях. Проверка должна выполняться аккредитованным контролирующим агентством, а отчет должен соответствовать методу испытаний ASTM E18 Rockwell и ссылаться на него.
  • Испытания на твердость — важный и полезный инструмент при испытании материалов, контроле качества и приемке, а также рабочих характеристик материалов. Мы полагаемся на данные, полученные для проверки термообработки, структурной целостности и качества компонентов, чтобы определить, обладает ли материал свойствами, необходимыми для обеспечения того, чтобы материалы, используемые в вещах, которые мы используем каждый день, способствовали созданию хорошо спроектированного, эффективного и безопасного мира. . Правильная техника, процедура, строгое соблюдение стандартов и передовой практики в значительной степени повлияют на точность и полезность испытаний по Роквеллу.

Интуиция, лежащая в основе A / B-тестирования. В чем смысл проверки гипотез… | Адитья Рустги

Цель

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

Цель этой статьи — ответить на многие из этих вопросов.

Справочная информация

Когда происходит изменение предлагаемого препарата (будь то изменение вводимого нового препарата или изменения на веб-сайте), мы хотим знать

  1. Оказывает ли изменение желаемое влияние, чтобы оно надежды.
  2. Любое наблюдаемое воздействие является результатом внесенного вами изменения.

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

Давайте рассмотрим это на примере:

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

Предыстория : Один из членов вашей команды Анна наблюдает за веб-сайтом конкурента и замечает, что на его веб-сайте на странице корзины покупок написано «Пришлите мне мои плакаты». [ Мы называем это «Наблюдение »] Анна думает про себя: «Это интересно. Я думаю, что текст кнопки, который говорит людям отправлять плакаты, более привлекателен и побудит больше людей оформить заказ.- Мы называем это альтернативной гипотезой.

Контроль и вариант для A / B-теста

Анна : Я видела интересную вещь, которую делает PostersRUs.com. На их странице корзины покупок кнопка гласит: «Отправить мне мои плакаты». Я думаю, нам стоит сделать это на нашем веб-сайте, это повысит нашу скорость оформления заказа.

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

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

You : «Итак, Анна, мы проверим вашу гипотезу. Как вы думаете, насколько это изменит скорость выезда? »

Анна : «Не знаю.Разве не в этом смысл теста, чтобы выяснить это? »

Вы : «Ну .. Не совсем. Цель теста — определить, существует ли улучшение, о котором вы заявляете, или нет. Кроме того, мне нужен этот номер для разработки моего теста. Например, если вы скажете, что этот тест удвоит нашу процентную ставку с 20% (мы называем это базовой ставкой) до 40% всех пользователей, которые переходят в корзину, тогда, поскольку это такая большое изменение, интуитивно должно быть намного легче (быстрее) наблюдать.Если вы скажете, что этот тест увеличит процент оформления заказа с 20% до 20,4% (относительное изменение 2%), то это такое небольшое изменение, может быть трудно найти это изменение ». Интуитивно вы понимаете, что это имеет смысл.

Анна : Хорошо, это не может быть настолько радикальным, как 100%, потому что в противном случае так поступили бы все остальные компании. Так что, я полагаю, это небольшой эффект. Проверим, хотя бы 10%. Поэтому я думаю, учитывая, что на прошлой неделе мы выполнили 20% выезда, новый коэффициент конверсии составит 22%.Я подсчитал, что это изменение принесет нам дополнительно 85 000 долларов в течение этого года.

Вы : Хорошо. Давай попробуем это. Давайте подставим эти числа в средство оценки Evan Miller’s A / B Sample Size . Я вижу, что потребуется 6 347 образцов для каждого варианта (или всего около 12 700), чтобы обнаружить эффект не менее 10%. Обычно у нас на странице корзины покупок 800 клиентов, поэтому на выполнение теста у вас уйдет примерно 16 дней.

You : Анна, можем ли мы провести A / B-тест, при котором половина людей, оказавшихся в корзине покупок, видит «Оформить заказ», а другая половина — «Пришлите мне мои плакаты». А потом подождем 16 дней. [Вы также читали статью Эвана Миллера Как не проводить A / B-тест (даже если вы не совсем понимаете ее), и поэтому вы не смотрите на результаты в течение следующих 16 дней. .]

Что происходит за кадром? Давайте посмотрим на некоторые основные идеи.

Снимок экрана с превосходного калькулятора размера выборки A / B от Эвана Миллера

Чтобы понять, что происходит, как работают эти вычисления и что они означают, очень важно сначала понять две основные концепции: совокупность и выборки.

  1. Население : Это все возможные покупатели плакатов, которые могут посетить ваш веб-сайт в будущем. Что вы хотите, чтобы ваша сдача в среднем увеличивала процент выезда на 10%. Реальность такова, что вы никогда не узнаете настоящего ответа на этот вопрос. Вы должны оценить это через меньшую выборку.
  2. Образец : Образец представляет участников вашего теста. Это люди, которые посещают ваш сайт в течение этих 16 дней и проверяют его. Ваш A / B-тест пытается оценить поведение всего населения, запустив тест на выборке . [На самом деле в вашем тесте 2 набора образцов.Один примерный набор содержит всех пользователей, которые видят кнопку «Оформить заказ», а другой — всех пользователей, которые видят кнопку «Отправить мне мои плакаты».] Сделав так, чтобы люди в двух группах имели одинаковый опыт, за исключением кнопки, вы можете гарантировать что разница в двух выборках объясняется изменением и ничем иным, как изменением (при условии, что тест настроен правильно).

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

Возможные результаты теста

Здесь есть 4 возможных результата (два — хорошие результаты, а 2 — нежелательные для вас).

Хорошие результаты:

  1. На самом деле разница в 10% существует, и ваш тест может ее обнаружить. Поздравляем!
  2. На самом деле разницы в 10% не существует, и ваш тест не обнаруживает никакой разницы. Да ладно, по крайней мере, вы знаете!

Нежелательные результаты:

  1. На самом деле существует разница в 10%, но ваш тест ее не обнаруживает. Упущенная возможность!
  2. На самом деле 10% различий не существует, но ваш тест, по вашему мнению, их обнаруживает. О, мальчик!

Почему это происходит?

Это несоответствие существует, потому что мы используем выборки для оценки популяций. (технический термин для этого — ошибки выборки). Например, если вы запускаете этот тест с 3 по 19 января 2019 г., то вы делаете утверждение, что этот набор образцов представляет собой совокупность.

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

Как хороший дизайн A / B-теста предотвращает нежелательные результаты и увеличивает желаемые результаты?

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

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

Значимость (или p-значение): это число, которое вы указываете, которое ограничивает размер ложных срабатываний. То есть он гарантирует, что если разница в 10% (указанная вами в своих тестовых расчетах) между элементом управления и вариантом не существует, то вы не обнаружите ее по ошибке. Когда вы указываете p-значение 0.05, это означает, что если вы запустите этот тест 100 раз и реальной разницы не существует, в 95 раз из 100 вы не обнаружите ложного срабатывания. Это дает определенную уверенность в том, что тест не вводит вас в заблуждение.

Power (альфа) : это число, которое вы указываете, когда разница действительно существует, ваш тест может обнаружить ее до определенной степени. Когда вы указываете альфа-значение 0,80, вы говорите, что если вы запустите это 100 раз и существует реальная разница, 80 раз из 100, вы обнаружите это изменение.

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

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

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

Изменение статистической мощности с 80% на 90%, изменение уровня значимости с 5% до 1% → Размер тестовой выборки для каждого варианта удваивается с 6 347 до 12 046.

Изменение статистической мощности с 80% на 90%, изменение уровня значимости с 5% до 1%

Ключевые выводы
  1. Результат вашего A / B-теста — утверждение о точности реальности. Это оценка реальности.
  2. Как разработчик тестов, вам необходимо понять и усвоить значение значимости, мощности, базовой скорости, минимального обнаруживаемого эффекта и размера выборки, а также того, что эти значения связаны между собой.
  3. Как разработчик тестов, вы должны иметь в виду либо минимальный обнаруживаемый эффект (подробнее об этом в другой статье), либо продолжительность теста.
  4. Один из способов планирования теста — начать со значения значимости и мощности, которые вы хотите получить для своего теста (с учетом реалий вашей бизнес-среды и теста), а затем включить базовую скорость и минимально обнаруживаемый эффект, чтобы получить размер выборки и приблизительная продолжительность теста (с учетом оценки скорости)
  5. Другой способ планирования теста — начать со значимости и мощности теста, которые вы хотите получить (отражая реалии вашей бизнес-среды и теста), а затем включить ваши размер выборки (и приблизительная продолжительность теста), чтобы определить минимальный размер эффекта, который может обнаружить ваш тест.(Любой более низкий эффект не будет надежно обнаружен с вашим размером выборки)
  6. Изменение степени (альфа) и значимости (значение p) не меняет реальности. Это меняет то, что тест думает о реальности.
  7. Наконец, если в вашей компании есть специалист по обработке данных или статистик, тесно сотрудничайте с ними над дизайном тестирования и интерпретацией результатов тестирования. Не думайте, что пакетное программное обеспечение, которое вы используете для A / B-тестов, дает вам 100% точную интерпретацию результатов.

Заключение

Когда я делал свой первый A / B в качестве менеджера по продукту, мое понимание этих концепций было очень поверхностным. В результате мы закончили разработку и выполнение тестов, которые, оглядываясь назад, были ошибочными (в большинстве случаев мы останавливали тесты слишком рано). Мы потратили много времени и усилий на реализацию и повторную реализацию этих тестов и очень мало извлекли из них (не говоря уже о множестве победителей), пока не поняли концепции, лежащие в основе этих тестов.

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

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

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

5 шагов к испытанию на падение картонной коробки

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

Вы хотите, чтобы ваши товары были «мертвыми по прибытии», потому что они были непоправимо повреждены во время транспортировки?

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

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

Итак, как вы можете проверить качество упаковки, чтобы ваши продукты были защищены? Ответ может быть проще, чем вы думаете.

Один из лучших способов убедиться, что ваша упаковка соответствует вашим стандартам качества и защищает ваши продукты внутри, — это провести испытание на падение с картонной коробки. Вы или ваша группа контроля качества можете легко внедрить испытание на падение картонной коробки в любом плане проверки упаковки перед транспортировкой (: Руководство по проверке упаковки [электронная книга]).

Кому нужно проводить испытание на падение картонной коробки?

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

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

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

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

Стандарты испытаний упаковки на падение

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

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

  • Международная ассоциация безопасного транзита (ISTA ) Процедура A1 ISTA: этот стандарт применим к упакованным товарам весом 150 фунтов (68 кг) или менее
  • Американское общество испытаний и материалов (ASTM) ASTM D5276 — 98 (2017): этот стандарт применим для контейнеров весом 110 фунтов (50 кг) или менее

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

Процедура испытания упаковки на падение

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

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

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

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

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

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

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

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

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

2. Найдите подходящую площадку для испытаний с ровным и твердым полом

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

3.10 раз уронить картонную коробку с подходящей высоты с разных сторон

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

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

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

4. Откройте картонную коробку и проверьте состояние упаковки и продуктов внутри

Картонная коробка не проходит испытание на падение, если после испытания обнаруживается одна из следующих проблем:

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

Что считается «значительным повреждением» картонных коробок и коробок?

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

5. При необходимости отрегулируйте испытание картонной коробки на падение

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

Что делать, если ваш поставщик выдержит испытание на падение упаковки во время проверки упаковки?

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

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

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

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

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

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

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

Заключение

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

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


Заинтересованы в других методах управления качеством упаковки? Нажмите кнопку ниже, чтобы загрузить полную электронную книгу InTouch!

Как выбрать размер выборки (для лиц с ограниченными возможностями)

Один из наиболее частых вопросов, которые мне задают люди, проводящие опросы в области международного развития, — «насколько большой должен быть размер моей выборки?». Хотя существует множество калькуляторов размера выборки и статистических справочников, те, кто никогда не занимался статистикой в ​​университете (или забыл все это), могут найти их пугающими или сложными в использовании.

Если это похоже на вас, продолжайте читать. В этом руководстве объясняется, как выбрать размер выборки для базового обследования без каких-либо сложных формул. В качестве более простых практических правил относительно размеров выборки для других ситуаций я настоятельно рекомендую «Размер выборки: приблизительное руководство» Ронана Конроя и «Справочник по исследованию опросов» Памелы Алрек и Роберта Сеттла.

Этот совет предназначен для:

  • Базовые опросы, такие как формы обратной связи, оценка потребностей, опросы общественного мнения и т. Д.проводится в рамках программы.
  • Опросы, в которых используется случайная выборка.

Этот совет НЕ предназначен для:

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

Минимальный размер выборки — 100

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

Хороший максимальный размер выборки обычно составляет 10%, если он не превышает 1000

Хороший максимальный размер выборки обычно составляет около 10% генеральной совокупности, если он не превышает 1000.Например, в населении 5000 человек 10% будет 500. В населении 200000 человек 10% будет 20 000 человек. Это превышает 1000, поэтому в этом случае максимум будет 1000.

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

Выберите число от минимального до максимального в зависимости от ситуации

Предположим, вы хотите опросить учеников в школе, в которой учатся 6000 учеников.Минимальная выборка — 100. Это даст вам приблизительное, но все же полезное представление об их мнениях. Максимальная выборка — 600, что даст вам довольно точное представление об их мнениях.

Выберите число ближе к минимум , если:

  • У вас ограничено время и деньги.
  • Вам нужна только приблизительная оценка результатов.
  • Вы не планируете делить выборку на разные группы во время анализа или планируете использовать только несколько больших подгрупп (например,грамм. мужчины / женщины).
  • Вы думаете, что большинство людей дадут похожие ответы.
  • Решения, которые будут приняты по результатам, не имеют существенных последствий.

Выберите число ближе к максимум если:

  • У вас есть на это время и деньги.
  • Очень важно получать точные результаты.
  • Вы планируете разделить выборку на множество разных групп во время анализа (например, разные возрастные группы, социально-экономические уровни и т. Д.).
  • Вы думаете, что люди могут давать очень разные ответы.
  • Решения, которые будут приняты по результатам опроса, важны, дороги или имеют серьезные последствия.

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

Если вы хотите быть более научным, используйте эту таблицу

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

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

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

Расслабьтесь и перестаньте беспокоиться о формулах

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

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

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

Фото Джеймса Кридленда

UT 2: Обучение неразрушающему контролю

UT 2: Обучение неразрушающему контролю — переменные, влияющие на результаты испытаний NDT.net — июнь 1999 г., Vol. 4 № 6

Ультразвуковой контроль 2


Обучение неразрушающему контролю —
Переменные, влияющие на результаты испытаний
Эд Гинзель
Эл. Почта: [email protected]
Домашняя страница: http://www.mri.on.ca
Заочное обучение на дому (UT, ECT, LPI и MPI), включая NDT Программное обеспечение для решения проблем (стандарт решения уравнения в UT, RT и ECT)

Введение

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

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

  1. производительность прибора
  2. производительность преобразователя
  3. варианты материалов
  4. варианты дефекта

Еще один фактор, связанный с результатами проверки, — это человеческий фактор. Фактор, это широко обсуждаемая тема.Тема не обсуждается в эта глава и не относится к теме «Вероятность обнаружения». За дополнительную информацию о POD см. в более ранних публикациях на NDTnet.

Производительность прибора

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

    Scope — Первичной переменной в области видимости является линейность временной развертки.Для методов проверки обычно требуется допуск точности в процентах от общего диапазона экрана (обычно +/- 2%). Это гарантирует, что при измерении расстояния погрешность не превышает 2%, например для диапазона 250 мм возможна погрешность не более +/- 5 мм для стали.

    Генератор-приемник — Неопределенность амплитуды возникает из-за изменений линейности вертикального отклонения прицела или из-за неточностей в регулировке амплитуды. Вертикальная линейность осциллографа гарантирует, что соотношение между двумя сигналами разной амплитуды сохраняется во всем диапазоне высоты экрана.Это делается путем сравнения относительной высоты двух эхо-сигналов на разных высотах экрана. например установка двух эхо-сигналов с разницей в 6 дБ, начиная с одного при 80% полной шкалы, а другая — при 40% полной шкалы, чтобы сначала увеличить сигнал 80% полной шкалы до 90 и 100%. Нижний сигнал должен составлять 45% и 50% соответственно. Уменьшая более высокий сигнал с шагом 10% FSH, более низкий должен оставаться на половине его высоты. Допуск для этого параметра составляет +/- 5% от высоты экрана. Это гарантирует, что соотношение сигналов двух разных амплитуд действительно указывает на размер или влияние расстояния.Это было бы наиболее важно для сравнения типов DGS.

    Другой аспект изменчивости вертикальной линейности — это регулировка усиления амплитуды. Это относится к калиброванной регулировке усиления, обычно измеряемой дефектоскопом с шагом в дБ. Поскольку дБ получается из (дБ = 20 log A2 / A1 изменение усиления в дБ на фиксированную величину должно изменить соотношение сигналов. Это позволяет нам ожидать, что сигнал при 50% полной шкалы увеличится до 100% полной шкалы при добавлении 6 дБ к усилению приемника. Код ASME требует, чтобы сканирование сварного шва выполнялось с превышением эталонного уровня на 14 дБ.Это означает, что сигнал, который был на 20% от исходной амплитуды при опорном усилении затем подойти к опорному уровню, обозначенному ЦАП. Если усиление приемника не является линейным, наименьшее записываемое показание может быть больше или меньше заданного уровня. Это будет еще одним источником неправильного определения размера дефекта по отношению к ссылке.

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

Характеристики преобразователя

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

    BS 4331, часть 3 *, рекомендует следующие проверки производительности датчика / системы;

    Часть 3 будет заменена EN 12668-2, Неразрушающий контроль. Характеристики и проверка оборудования для ультразвукового исследования. Часть 2: Зонды.

    Вышеупомянутые элементы контроля относятся к контактным пробникам. Износ, возникающий при движении по металлическим поверхностям, имеет тенденцию ускорять изменение характеристик. Некоторые изменения, вызванные износом, могут значительно изменить результаты испытаний. В качестве примера рассмотрим изменение угла луча. Если в начале дня было обнаружено, что номинальный зонд 60 ° имеет фактический угол 62 °, это означает, что звуковой путь составляет 150 мм в стыковом сварном шве пластины толщиной 100 мм. Быстрый расчет, сделанный оператором, позволяет построить график положения дефекта 132.4 мм по поверхности от точки выхода, а затем на 70,4 мм ниже испытуемой поверхности. После нескольких часов интенсивного сканирования оператор случайно надел зонд на нос, и фактический угол изменился до 58 ° (62 ° и 58 ° находятся в пределах допустимых допусков для номинального зонда 60 °). Когда то же самое указание исследуется снова, оператор находит указание в той же самой области, но это не похоже на то же самое. Звуковой тракт для «новой» индикации составляет всего 133 мм. Оператор, полагая, что угол преломления составляет 62 °, теперь рисует дефект на 62 мм ниже поверхности.Эта ситуация проиллюстрирована на Рисунке 8-1.

    ПУНКТ ЧАСТОТА МОНИТОРИНГА
  • индекс зонда
  • суточный на грубых поверхностях, таких как отливки, два раза в день
  • угол луча
  • перекос луча (косоглазие)
  • профиль луча
  • ежемесячно и когда наблюдаются большие изменения угла или индекса зонда
  • преобладающая частота
  • ежемесячно и всякий раз, когда был произведен ремонт датчика или прибора и если один прибор заменен другим
  • длительность импульса
  • мертвая зона
  • ближнее поле
  • отношение сигнал / шум
  • общий коэффициент усиления системы
  • ежедневно и после ремонта или замены, как указано выше
  • разрешающая способность
  • ежемесячно и после ремонта или замены, как указано выше

    Рисунок 8-1

    Рисунок 8-2
    Подобные ошибки при построении поперечного позиционирования могут возникать из-за перекоса луча. При нанесении индикации с помощью углового луча мы предполагаем, что луч выходит прямо вперед по линии корпуса датчика, но износ одной или другой стороны клина будет уводить луч в сторону от центральной линии. Если мы воспользуемся предыдущим примером с датчиком 62 °, обнаружившим указание на 150-миллиметровом звуковом пути, график вида сверху покажет, что он находится примерно на 132 мм прямо перед датчиком от точки выхода.Если бы существовал перекос в 5 °, который не учитывался, ошибка определения местоположения этого индикатора составила бы около 11,5 мм (см. Рисунок 8-2).

    Индексная точка или точка выхода луча для углового датчика луча легко устанавливается на блоке 11W. Он используется для определения фактического угла преломления, поэтому важна его точность в пределах +/- 1,5 мм. Для более длинных звуковых путей (> 25 мм влияние на расположение дефекта вперед или назад не будет слишком критичным. Например, если дефект, нанесенный на рис. 8-1, был на 1 мм вперед или назад из-за того, что точка выхода смещена на 1 мм от его размеченного положения, это будет мало влияют на оценку дефекта.Если, однако, испытанный сварной шов был на трубе толщиной 6 мм с корневым швом TIG, ширина корневого шва могла бы составлять около 2 мм. Ошибка в размещении точки выхода может привести к появлению дефекта на неправильной стороне сварного шва.

    В таблице элементов, проверяемых в соответствии с BS 4331, первые три элемента являются уникальными для контактных датчиков, но остальные элементы могут учитываться при любой оценке преобразователя, включая погружные датчики. Обработка и старение могут вызвать изменения основы элемента, степени поляризации, формы линзирующего материала, сцепления материала линзы с элементом или степени нагрузки (для тонкой золотой поверхности на элементах из PVDF).Эти изменения приводят к изменениям как амплитуды, так и частоты. Влияние на производительность многоступенчатое.

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

    Эксплуатация зондов в теплой воде (> 50 ° C) или сильных полях излучения (несколько MegaRads) может вызвать образование пузырей или отслоение эпоксидного материала, используемого для линз.Это может иметь эффекты, аналогичные эффектам, отмеченным для отсоединения подложки, а также искажения и перенаправления центральной линии луча.

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

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

Варианты материалов

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

Переменные входной поверхности включают:

  1. шероховатость поверхности
  2. поверхностные покрытия
  3. состояние контактной жидкости.
Шероховатость поверхности
Шероховатость поверхности будет иметь несколько возможных последствий при контроле испытательного образца.При контактных испытаниях шероховатость в крупном масштабе возникает из-за брызг сварного шва, окалины, грязи (песка) и шероховатых поверхностей отливки в песчаные формы. Эти неровности приведут к тому, что некоторые точки контакта оттолкнут контактную жидкость и заставят ее проникнуть в нижние области вокруг зонда. Если связующее вещество недостаточно вязкое, оно быстро стечет и не сможет соединить зонд с испытуемым образцом. См. Рисунок 8-3.

Рисунок 8-3

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

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

Независимо от того, является ли она однородной или нерегулярной, шероховатая поверхность может вызвать эффект рассеяния на границе раздела, куда падает луч. Степень рассеяния зависит от отношения шероховатости к длине волны.Когда шероховатость меньше примерно 1/10 длины волны, разброс будет незначительным. Чтобы уменьшить потери сигнала из-за рассеяния, оператор может выбрать зонд с более низкой частотой. При длине волны 0,37 мм в воде для зонда с частотой 4 МГц потеря сигнала из-за рассеяния может произойти для неровностей размером около 0,04 мм. В дополнение к уменьшению сигнала еще одним эффектом неровностей поверхности является перенаправление и преобразование в режиме некоторой энергии, которая при возврате в зонд может быть источником паразитных сигналов.При контактном испытании ложные показания из-за стоячих волн, возникающих в результате рассеяния на шероховатых поверхностях, обычно имеют короткие звуковые пути. Их можно устранить как истинные недостатки, если не обнаружить никаких следов индикации от полного пропуска или с противоположной стороны.

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

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

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

    Стальная пластина номинальной толщиной 25 мм имеет целлюлозное лакокрасочное покрытие толщиной 0,5 мм. V сталь = 5980 м / с, краска V = 2600 м / с. Если цифровой толщиномер откалиброван на куске стальной пластины толщиной 25 мм без лакокрасочного покрытия, а затем помещен на окрашенную поверхность, возникнет ошибка.Покрытие достаточно тонкое, чтобы его поверхность соприкасалась с металлом в мертвой зоне, но время, проведенное в краске, добавляется ко времени прохождения до противоположной стенки пластины. Если истинная толщина пластины в точке измерения составляет 25,16 мм, а толщина лакокрасочного покрытия 0,5 мм, время нахождения краски составляет 0,5 (2,6 x 10 6 = 0,19 мкс. 0,19 микросекунды эквивалентны 1,15 мм для стали. Показания цифрового измерителя объединят две толщины, как если бы весь ход был по стали.Это дает 25,16 + 1,15 = 26,31 мм в качестве указанной толщины. Эту проблему можно решить, используя дисплей A-scan и измеряя интервал между первым и вторым эхо-сигналом вместо основного и первого эхо-сигнала. Это показано на Рисунке 8-4.

Рисунок 8-4
Состояние сцепления
Как контактный, так и погружной методы используют промежуточную среду для передачи звука от зонда в испытуемый образец и обратно в приемник. В методах погружения это достигается одной жидкой средой.В контактном тестировании почти всегда участвуют как минимум две среды; линия задержки или защитная поверхность и тонкая пленка связующей жидкости или смазки. Затухание и скорость звука — это два основных свойства, определяющих рабочие характеристики связующего вещества. Затухание влияет на амплитуду сигнала, а скорость определяет как время прохождения, так и углы преломления.

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

Затухание связующих веществ зависит от состава материала, как и следовало ожидать. Опубликованные значения затухания доступны для многих материалов, как указано в таблице ниже. Коэффициенты ослабления часто указываются в неперах, что учитывает частотную зависимость. 1 Np = 8,686 x f 2 = дБ / см. В таблице 8-1 указано затухание в некоторых распространенных жидкостях.

Таблица 8-1

Материал Затухание (Np x 10-15)
воды 25.3
силиконовое масло 6200
касторовое масло 10100
ртуть 5,8
этиленгликоль 128
метанол 30,2

С практической точки зрения для воды это будет означать ослабление около 5 дБ на метр. Поскольку такие длинные водные пути обычно не используются, затухание 0,005 дБ / мм считается незначительным.Но для более тяжелых нефтей затухание в 200-500 раз может иметь значительное влияние на амплитуду и частотный состав сигнала. Для фиксированных линий задержки или материалов клина, используемых в контактных испытаниях, вариации затухания могут быть гораздо более выраженными, а различия между производителями могут вызвать значительные различия в откликах. Например, пластмассы, перечисленные в таблице 8-2, являются типичными материалами клина, выбранными производителями и основанными на скорости для целей преломления, но различия в затухании могут привести к заметному изменению амплитудной характеристики и частотному составу передаваемых сигналов.Поскольку оператор редко знает, какой материал клина использовал производитель, мало что можно сделать, чтобы исправить возможные отклонения в периодических проверках, когда сравниваются результаты испытаний, проведенных с разделением на один или несколько лет.

Таблица 8-2

Материал Затухание дБ / см при 5 МГц Акустическая скорость
Оргстекло (акрил) от 6,4 до 12,4 от 2,75 до 2,61
лексан (поликарбонат) 32.2 2,30
полистирол от 1,8 до 3,6 от 2,32 до 2,48
нейлон 2,8 до 16 от 2,6 до 2,77

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

При стандартном давлении и температуре (1 атмосфера и 20 ° C) затухание в воде составляет 25.3 x 10 -15 Np. При температуре 0 ° C и затухании в водной неподвижной жидкости 56,9 x 10 -15 Np, а при 40 ° — 14,6 x 10 -15 Np. При 1000 атмосфер затухание падает до 12,7 x 10 -15 Np и увеличивается до 18,5 x 10 -15 Np в вакууме (ноль атмосфер), когда температура поддерживается на уровне 30 ° C.

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

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

Так же, как пластиковые композиции изменяют скорость, меняется и вода. Чистая вода при 20 ° C и давлении 1 атмосфера имеет скорость 1480 м / с. Но обычно вода не чистая. По мере увеличения солености, как в морской воде, скорость звука увеличивается. При 20 ° C в морской воде с соленостью 3% скорость звука увеличивается примерно до 1515 м / с.Для работ, выполняемых на морских сооружениях, где погружение будет происходить с использованием окружающей морской воды, любые калибровки, выполняемые на борту судна, должны использовать воду той же солености, которая будет иметь место на глубине испытания или размещения зонда, а угол преломления будет равным. неправильно рассчитанный. Кроме того, скорость звука увеличивается с увеличением давления в воде, поэтому с увеличением глубины воды скорость также увеличивается. Это относительно несущественно, но может быть исправлено уравнением.

V d = V o + (d x 0.018)
    где V d = акустическая скорость на глубине d
    d = глубина в метрах
    V o = акустическая скорость на поверхности.
Для нашего примера с соленостью 3% поправка для работы на 50 м будет 1515 + (50 x 0,018) или 1515,9 м / с.

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

В таблице 8-3 показаны некоторые изменения температурной зависимости (V / t) для некоторых материалов.

Таблица 8-3

Материал Скорость звука при 25 ° C (В / т (м / с ° C)
касторовое масло 1470 -3.6
этиленгликоль 1658 -2,1
керосин 1324 -3,6
метанол 1103 -3,2
вода (чистая) 1498 +2,4
вода (море) 1531 +2,4



полистирол 2400 -4.4
полиметилметакрилат 2690 -2,0
поливинилхлорид (твердый) 2380 -8,0

Для сравнения, большинство металлов имеют температурную зависимость от -0,5 до -5,0 м / с / ° C в зависимости от режима и оси распространения.

Таблица 8 — 3a:
Изменение скорости в зависимости от температуры
Температура
° C
Скорость
м / с
Дельта
м / с ° C
5 1440 3,14
15 472 2,65
25 1498 2,15
35 1520 1,67
45 1536 1,18
55 1548 0,68
65 1555 0,20
75 1557
Когда проверка размеров выполняется путем определения времени прохождения в соединительной жидкости, как показано на рисунке 5-20, изменение температуры может легко повлиять на точность.Еще сложнее исправить изменения в течение определенного периода времени. например Температура в начале теста составляет 20 ° C, но через полчаса она повысилась до 35 ° C. Для воды это увеличивает скорость звука до 1520 м / с, она не изменяется линейно с температурой (см. Таблицу 8 — 3a).
При применении к испытанию углового луча проблемы становятся более очевидными. Закон Снеллиуса позволяет нам предсказывать углы преломления в материале, зная скорость звука и угол падения.Отношение скоростей определяет степень преломления. При покупке стандартного клина для контактных испытаний на нем указывается номинальный угол преломления, который он создает в стали, при скорости сдвига, равной 3250 м / с. Пластиковый клин, имеющий акустическую скорость 2600 м / с, обрабатывают под углом 43,9 ° для получения номинального преломленного луча 70 ° в стали. Это предполагает рабочую температуру 20 ° C. Если проверять образец, теплый на ощупь (~ 40 ° C), скорость движения стали и пластика будет меньше предполагаемой.Если пластик изменится на -4,0 м / с / ° C, а сталь — примерно на -2 м / с ° C, то скорости будут 2312 для пластика и 3210 для стали. Фактический угол преломления будет ближе к 74 °.

На рис. 8-5 показано влияние температуры на углы преломления в стали для трех обычных фиксированных углов клина.


Рисунок 8-5

Углы падения, указанные в легенде на рис. 8-5, соответствуют номинальным углам преломления 45 °, 60 ° и 70 ° при стандартных условиях.Пластмасса рассчитана на UVA II со скоростью звука 2760 м / с. Влияние на наклонные продольные волны еще более выражено, это связано с большей разницей в соотношении скоростей между пластиком и сталью в режиме сжатия.

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

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

Чтобы избежать обработки калибровочных блоков для каждого возможного радиуса и состояния поверхности, компенсация выполняется путем добавления усиления к приемнику. Величина компенсирующего усиления может быть определена простым передаточным значением или рассчитана с использованием формул и диаграмм. Примеры диаграмм, используемых для компенсации выпуклой кривизны, приведены на рисунках 8-6 и 8-7. Они взяты из Австралийского стандарта 2207 «Методы ультразвукового контроля сварных соединений плавления в стали». Рассмотрены два условия.На первом рисунке номограмма используется для корректировки потерь при контакте зонда с изогнутой поверхностью. Радиус исследуемой детали указан на левой шкале, а линия, проведенная через соответствующий диаметр зонда, на средней шкале. Точка на правой шкале, которую пересекает эта линия, — это величина усиления, добавляемая в качестве поправочного коэффициента.

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


Рисунок 8-6

Рисунок 8-7

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

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

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


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

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

Изогнутые поверхности затрудняют построение графиков, чем простая тригонометрия для плоских поверхностей. Сравните аналогичные условия для балки под углом 45 ° в плоской и изогнутой пластине. При толщине 20 мм сигнал, полученный на расстоянии 35 мм для проверки трубы радиусом 100 мм, возникает на расстоянии 19,2 мм от испытательной поверхности OD и 31,7 мм вдоль испытательной поверхности от точки выхода до точки над индикатором. На плоской детали это будет указывать на 15,2 мм вниз и 24,8 мм от точки выхода. См. Рисунок 8-9.


Рисунок 8-9

Геометрия также может ограничивать проверки. Опять же, концентрические геометрии — обычная проблема в этом отношении. Существует критическое отношение внутреннего диаметра к внешнему диаметру, которое не позволяет угловому лучу от внешнего диаметра пересекаться с внутренним диаметром. Это показано на Рисунке 8-10.


Рисунок 8-10

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

Уравнение, связывающее толщину стенки t, внешний диаметр трубы D и угол преломления, можно записать

D (1-Sin)
т = ——————-
2
t — максимальная толщина, при которой центр луча все еще будет выходить за пределы внутреннего диаметра.

Другой искомый параметр, максимальный угол, будет использовать следующее уравнение:

Sin = 1- —-
D
На рис. 8-11 показано соотношение t / D, которое удовлетворяет приведенному выше уравнению.Когда толщина увеличивается до половины диаметра, это то же самое, что и у сплошного цилиндра, и не существует внутреннего диаметра, который мог бы отскочить.

Рисунок 8-11

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

Некоторые авторы указали, что контактный осмотр трубы в окружном направлении может быть выполнен простым перемещением зонда по поверхности трубы на расстояние, равное одному полному пропуску. Используемый принцип показан на Рисунке 8-12.


Рисунок 8-12

Это хорошо подходит для центра луча луча, но в применении к реальным условиям это может обеспечить немногим больше, чем проверка типа годен / запрещен. Распространение луча, преобразование мод и затухание не позволят точно определить местонахождение каких-либо дефектов, возникающих на расстоянии нескольких переходов.Фактически, затухание, вероятно, ограничит обнаружение дефектов этим методом трубами диаметром менее 10-20 см. Такой метод может быть полезен, когда доступ ограничен только половиной окружности. Присутствие (но не обязательно местоположение) дефекта может быть обнаружено путем сканирования сначала в одном направлении до препятствия, а затем в другом, как показано на рис. 8-13.


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

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

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

a) введение небольшого количества элементов для измельчения зерна
; b) ограничение температуры нагрева стали до
; c) путем горячей обработки стали для измельчения аустенитных зерен.

Несмотря на эти эффекты, изделия из нержавеющей стали не всегда имеют однородную структуру зерна. При испытании поковок из нержавеющей стали возможно наличие участков с более высоким затуханием, чем в других. В таких случаях наблюдательные операторы должны будут распознавать повышение уровня травы.
Скорость также меняется в зависимости от материала и состояния. Клинья с углом контакта обычно изготавливаются для стали, поэтому угол преломления, указанный на клине, предполагает, что он будет использоваться для стали с продольной скоростью около 5900 м / с и скоростью поперечной волны около 3250 м / с.Когда тот же клин используется на алюминиевой пластине с продольной скоростью 6320 м / с и сдвигом со скоростью 3100 м / с, указанный «номинальный» угол преломления не будет указывать на истинный угол.

Но не нужно переходить к совершенно другому металлу, чтобы проиллюстрировать изменения скорости. Прокатный лист для строительства трубопроводов показывает колебания скоростей поперечных волн на 8-10%. Это связано с различиями в прокатке и термообработке и, как следствие, с различиями в удлинении и ориентации зерен. Даже сплавы стали показывают заметные колебания скорости звука; Сталь 4340 имеет скорость сдвига 3240 м / с, а сталь 4150 — 2770 м / с, то есть разница составляет почти 17%.

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

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

Вариант дефекта

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

    1. размер и геометрия 2. расположение относительно прилегающих поверхностей 3. ориентация большой оси 4. тип прерывности и условия отражения.

    Размер и геометрия дефекта
    И размер дефекта, и форма дефекта оказывают значительное влияние на амплитуду сигнала. Принципы системы AVG показали, как амплитуда сигнала зависит от отношения площади отражателя к площади элемента. Обычно небольшие дефекты дают сигналы меньшей амплитуды, чем большие дефекты.Однако неправильная форма дефекта может означать, что не все дефекты отражают звук обратно в приемник. Неровные грани трещины или близкое расположение пор в кластерах пористости могут привести к значительным потерям из-за разброса, когда принимаются очень слабые сигналы, несмотря на то, что отсутствует большой объем металла; т.е. амплитуда сигнала не является гарантией размера дефекта. Определение размера дефекта методом AVG может привести к ошибкам от 3: 1 до 6: 1. С помощью метода SAFT точность размеров может достигать почти 100% (опубликовано IZFP).
    Расположение относительно прилегающих поверхностей
    Положение дефекта по отношению к соседним поверхностям представляет несколько причин различных результатов. Простое затухание позволяет уменьшить амплитуду сигнала за счет увеличения звукового пути (в дальней зоне) до дефекта. Если дефект находится близко к другой отражающей поверхности, это может привести к ошибочным сигналам или потерям сигналов. На рис. 8-14 показано, как модовый преобразованный сигнал может возникнуть из-за отражения от плоского дефекта вблизи плоской поверхности.

    Дефект в режиме конвертированной волны с радиусом поражения 65 °, обеспечивающий большой амплитудный сигнал, который при нанесении на график дает виртуальное местоположение дефекта отличается от его фактического положения
    Рисунок 8-14

    Если бы прилегающая поверхность в 8-14 была плоской, отраженные сигналы сдвига и преобразования моды не были бы обнаружены.Такие сигналы, создаваемые преобразованием мод, можно отличить от дефектов, если протереть испытательную поверхность пальцем, смоченным контактной жидкостью. Режим сжатия заметно затухает.

    Преобразованные в моду продольные и перенаправленные поперечные волны можно увидеть при построении кривых коррекции амплитуды расстояния на некоторых калибровочных блоках. В типичном калибровочном блоке ASME используется просверленное сбоку отверстие на четверть толщины (1/4 тонны). Выпуклый радиус отверстия допускает обе ситуации (см. Рисунок 8-15).


    Рисунок 8-15
    Ориентация большой оси
    Когда большая ось дефекта не совсем перпендикулярна отражению луча, отраженный сигнал направляется от простого обратного пути обратно к передатчику. Для малых углов это не приведет к полной потере сигнала, поскольку размеры луча достаточны для того, чтобы зонд все еще мог обнаруживать смещенные от центра участки. Даже небольшие углы отклонения от нормы (например, +/- 5 °) могут привести к значительному снижению сигнала.Когда ожидаемые дефекты являются плоскими и невозможно расположить удобный угол эхо-импульса, чтобы луч попадал на дефект под прямым углом, предпочтительны тандемные зонды.
    Тип несплошности и условия отражения
    В некоторой степени это было решено другими аспектами. Размер и геометрия дефекта обычно определяется его типом; например пористость обычно небольшая и сферическая, шлак неправильной формы и размера, а несплавление обычно плоское. Однако отражательная способность дефектов — это не просто угол падения.Для очень мелкой пористости может не быть заметного сигнала обратного отражения, но рассеяние, которое может вызвать такой дисперсионный дефект, уменьшило бы передаваемую энергию.

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

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

| Вверх |
© NDT.net , [email protected] / DB: Article / DT: tutor / AU: Ginzel_E_A / IN: MRI / CN: CA / CT: UT / ED: 1999-06 .
Автор записи

Добавить комментарий

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