5 проверок для функционального типа тестирования сайта

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

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

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

Зачем проводить тестирование сайта?

Казалось бы, ответ очевиден. Но почему-то многие без капли сомнения обходят этот важный этап разработки стороной. А ведь до тестирования сайт похож на кота Шрёдингера: до момента запуска неизвестно, всё ли работает исправно – интернет-ресурс и жив, и мертв одновременно.

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

Что представляет собой тестирование функционала

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

Есть два способа проверки сайта – автоматически и вручную. Каждый из этих способов имеет свои преимущества и недостатки. Рассмотрим оба варианта подробнее.

Автоматическое тестирование

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

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

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

Тестирование вручную

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

Главное, что нужно знать: сложные проекты тестируются только вручную. Запомните это, как диджитал-мантру, и повторяйте её при создании нового интернет-ресурса. Запомнили? Отлично. Тогда поехали дальше.

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

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

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

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

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

Чек-лист по тестированию функционала сайта

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

  • Наличие всех согласованных страниц (уверяем, только кажется, что это очевидно) и их соответствие макетам.
  • Работа главных функций сайта.
  • Корректность работы каталога: верно ли отображаются товары, цены, правильно ли работают сортировка и фильтры.
  • Гиперссылки, поиск нерабочих.
  • Функции всех кнопок на сайте.
  • Наличие защиты от спама.
  • Работа поиска и релевантность результата.
  • Покупка товара и оформление заказа.
  • Работоспособность пользовательских форм.
  • Иконки социальных сетей, RSS, новостей.
  • Работа корзины.
  • Логотип компании – ведёт ли он на главную страницу.
  • Интеграция со сторонними инструментами: CRM, программным обеспечением электронной коммерции или маркетинговыми платформами.
  • Корректность работы авторизации/регистрации.
  • Добавление, удаление и редактирование данных пользователей, товаров и заказов.

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

Тестирование. Фундаментальная теория

Материал взят на dou.ua.

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

Тестирование программного обеспечения — проверка соответствия между реальным и ожидаемым поведением программы, осуществляемая на конечном наборе тестов, выбранном определенным образом. В более широком смысле, тестирование — это одна из техник контроля качества, включающая в себя активности по планированию работ (Test Management), проектированию тестов (Test Design), выполнению тестирования (Test Execution) и анализу полученных результатов (Test Analysis).

Качество программного обеспечения (Software Quality) — это совокупность характеристик программного обеспечения, относящихся к его способности удовлетворять установленные и предполагаемые потребности. [ISO 8402:1994 Quality management and quality assurance]

Верификация (verification) — это процесс оценки системы или её компонентов с целью определения удовлетворяют ли результаты текущего этапа разработки условиям, сформированным в начале этого этапа[IEEE]. Т.е. выполняются ли наши цели, сроки, задачи по разработке проекта, определенные в начале текущей фазы.
Валидация (validation) — это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, требованиям к системе [BS7925-1].
Также можно встретить иную интерпритацию:
Процесс оценки соответствия продукта явным требованиям (спецификациям) и есть верификация (verification), в то же время оценка соответствия продукта ожиданиям и требованиям пользователей — есть валидация (validation). Также часто можно встретить следующее определение этих понятий:
Validation — ’is this the right specification?’.
Verification — ’is the system correct to specification?’.

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

Этапы тестирования:
1. Анализ
2. Разработка стратегии тестирования
и планирование процедур контроля качества
3. Работа с требованиями
4. Создание тестовой документации
5. Тестирование прототипа
6. Основное тестирование
7. Стабилизация
8. Эксплуатация

Тест план (Test Plan) — это документ, описывающий весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков с вариантами их разрешения.
Отвечает на вопросы:
Что надо тестировать?
Что будете тестировать?
Как будете тестировать?
Когда будете тестировать?
Критерии начала тестирования.
Критерии окончания тестирования.

Основные пункты тест плана
В стандарте IEEE 829 перечислены пункты, из которых должен (пусть — может) состоять тест-план:
a) Test plan identifier;
b) Introduction;
c) Test items;
d) Features to be tested;
e) Features not to be tested;
f) Approach;
g) Item pass/fail criteria;
h) Suspension criteria and resumption requirements;
i) Test deliverables;
j) Testing tasks;
k) Environmental needs;
l) Responsibilities;
m) StafÞng and training needs;
n) Schedule;
o) Risks and contingencies;
p) Approvals.

Тест дизайн — это этап процесса тестирования ПО, на котором проектируются и создаются тестовые случаи (тест кейсы), в соответствии с определёнными ранее критериями качества и целями тестирования.
Роли, ответственные за тест дизайн:
• Тест аналитик — определяет «ЧТО тестировать?»
• Тест дизайнер — определяет «КАК тестировать?»

Техники тест дизайна

• Эквивалентное Разделение (Equivalence Partitioning — EP). Как пример, у вас есть диапазон допустимых значений от 1 до 10, вы должны выбрать одно верное значение внутри интервала, скажем, 5, и одно неверное значение вне интервала — 0.

• Анализ Граничных Значений (Boundary Value Analysis — BVA). Если взять пример выше, в качестве значений для позитивного тестирования выберем минимальную и максимальную границы (1 и 10), и значения больше и меньше границ (0 и 11). Анализ Граничный значений может быть применен к полям, записям, файлам, или к любого рода сущностям имеющим ограничения.

• Причина / Следствие (Cause/Effect — CE). Это, как правило, ввод комбинаций условий (причин), для получения ответа от системы (Следствие). Например, вы проверяете возможность добавлять клиента, используя определенную экранную форму. Для этого вам необходимо будет ввести несколько полей, таких как «Имя», «Адрес», «Номер Телефона» а затем, нажать кнопку «Добавить» — эта «Причина». После нажатия кнопки «Добавить», система добавляет клиента в базу данных и показывает его номер на экране — это «Следствие».

• Предугадывание ошибки (Error Guessing — EG). Это когда тест аналитик использует свои знания системы и способность к интерпретации спецификации на предмет того, чтобы «предугадать» при каких входных условиях система может выдать ошибку. Например, спецификация говорит: «пользователь должен ввести код». Тест аналитик, будет думать: «Что, если я не введу код?», «Что, если я введу неправильный код? », и так далее. Это и есть предугадывание ошибки.

• Исчерпывающее тестирование (Exhaustive Testing — ET) — это крайний случай. В пределах этой техники вы должны проверить все возможные комбинации входных значений, и в принципе, это должно найти все проблемы. На практике применение этого метода не представляется возможным, из-за огромного количества входных значений.

Traceability matrix — Матрица соответствия требований — это двумерная таблица, содержащая соответсвие функциональных требований (functional requirements) продукта и подготовленных тестовых сценариев (test cases). В заголовках колонок таблицы расположены требования, а в заголовках строк — тестовые сценарии. На пересечении — отметка, означающая, что требование текущей колонки покрыто тестовым сценарием текущей строки.
Матрица соответсвия требований используется QA-инженерами для валидации покрытия продукта тестами. МСТ является неотъемлемой частью тест-плана.

Тестовый случай (Test Case) — это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.
Пример:
Action Expected Result Test Result
(passed/failed/blocked)
Open page «login» Login page is opened Passed

Каждый тест кейс должен иметь 3 части:
PreConditions Список действий, которые приводят систему к состоянию пригодному для проведения основной проверки. Либо список условий, выполнение которых говорит о том, что система находится в пригодном для проведения основного теста состояния.
Test Case Description Список действий, переводящих систему из одного состояния в другое, для получения результата, на основании которого можно сделать вывод о удовлетворении реализации, поставленным требованиям
PostConditions Список действий, переводящих систему в первоначальное состояние (состояние до проведения теста — initial state)
Виды Тестовых Случаев:
Тест кейсы разделяются по ожидаемому результату на позитивные и негативные:
• Позитивный тест кейс использует только корректные данные и проверяет, что приложение правильно выполнило вызываемую функцию.
• Негативный тест кейс оперирует как корректными так и некорректными данными (минимум 1 некорректный параметр) и ставит целью проверку исключительных ситуаций (срабатывание валидаторов), а также проверяет, что вызываемая приложением функция не выполняется при срабатывании валидатора.

Чек-лист (check list) — это документ, описывающий что должно быть протестировано. При этом чек-лист может быть абсолютно разного уровня детализации. На сколько детальным будет чек-лист зависит от требований к отчетности, уровня знания продукта сотрудниками и сложности продукта.
Как правило, чек-лист содержит только действия (шаги), без ожидаемого результата. Чек-лист менее формализован чем тестовый сценарий. Его уместно использовать тогда, когда тестовые сценарии будут избыточны. Также чек-лист ассоциируются с гибкими подходами в тестировании.

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

Error — ошибка пользователя, то есть он пытается использовать программу иным способом.
Пример — вводит буквы в поля, где требуется вводить цифры (возраст, количество товара и т.п.).
В качественной программе предусмотрены такие ситуации и выдаются сообщение об ошибке (error message), с красным крестиком которые.
Bug (defect) — ошибка программиста (или дизайнера или ещё кого, кто принимает участие в разработке), то есть когда в программе, что-то идёт не так как планировалось и программа выходит из-под контроля. Например, когда никак не контроллируется ввод пользователя, в результате неверные данные вызывают краши или иные «радости» в работе программы. Либо внутри программа построена так, что изначально не соответствует тому, что от неё ожидается.
Failure — сбой (причём не обязательно аппаратный) в работе компонента, всей программы или системы. То есть, существуют такие дефекты, которые приводят к сбоям (A defect caused the failure) и существуют такие, которые не приводят. UI-дефекты например. Но аппаратный сбой, никак не связанный с software, тоже является failure.

Баг Репорт (Bug Report) — это документ, описывающий ситуацию или последовательность действий приведшую к некорректной работе объекта тестирования, с указанием причин и ожидаемого результата.
Шапка
Короткое описание (Summary) Короткое описание проблемы, явно указывающее на причину и тип ошибочной ситуации.
Проект (Project) Название тестируемого проекта
Компонент приложения (Component) Название части или функции тестируемого продукта
Номер версии (Version) Версия на которой была найдена ошибка
Серьезность (Severity) Наиболее распространена пятиуровневая система градации серьезности дефекта:
• S1 Блокирующий (Blocker)
• S2 Критический (Critical)
• S3 Значительный (Major)
• S4 Незначительный (Minor)
• S5 Тривиальный (Trivial)
Приоритет (Priority) Приоритет дефекта:
• P1 Высокий (High)
• P2 Средний (Medium)
• P3 Низкий (Low)
Статус (Status) Статус бага. Зависит от используемой процедуры и жизненного цикла бага (bug workflow and life cycle)

Автор (Author) Создатель баг репорта
Назначен на (Assigned To) Имя сотрудника, назначенного на решение проблемы
Окружение
ОС / Сервис Пак и т.д. / Браузера + версия / … Информация об окружении, на котором был найден баг: операционная система, сервис пак, для WEB тестирования — имя и версия браузера и т.д.

Описание
Шаги воспроизведения (Steps to Reproduce) Шаги, по которым можно легко воспроизвести ситуацию, приведшую к ошибке.
Фактический Результат (Result) Результат, полученный после прохождения шагов к воспроизведению
Ожидаемый результат (Expected Result) Ожидаемый правильный результат
Дополнения
Прикрепленный файл (Attachment) Файл с логами, скриншот или любой другой документ, который может помочь прояснить причину ошибки или указать на способ решения проблемы

Severity vs Priority
Серьезность (Severity) — это атрибут, характеризующий влияние дефекта на работоспособность приложения.
Приоритет (Priority) — это атрибут, указывающий на очередность выполнения задачи или устранения дефекта. Можно сказать, что это инструмент менеджера по планированию работ. Чем выше приоритет, тем быстрее нужно исправить дефект.
Severity выставляется тестировщиком
Priority — менеджером, тимлидом или заказчиком

Градация Серьезности дефекта (Severity)

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

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

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

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

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

Градация Приоритета дефекта (Priority)
P1 Высокий (High)
Ошибка должна быть исправлена как можно быстрее, т.к. ее наличие является критической для проекта.
P2 Средний (Medium)
Ошибка должна быть исправлена, ее наличие не является критичной, но требует обязательного решения.
P3 Низкий (Low)
Ошибка должна быть исправлена, ее наличие не является критичной, и не требует срочного решения.

Уровни Тестирования

1. Модульное тестирование (Unit Testing)
Компонентное (модульное) тестирование проверяет функциональность и ищет дефекты в частях приложения, которые доступны и могут быть протестированы по-отдельности (модули программ, объекты, классы, функции и т.д.).

2. Интеграционное тестирование (Integration Testing)
Проверяется взаимодействие между компонентами системы после проведения компонентного тестирования.

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

4. Операционное тестирование (Release Testing).
Даже если система удовлетворяет всем требованиям, важно убедиться в том, что она удовлетворяет нуждам пользователя и выполняет свою роль в среде своей эксплуатации, как это было определено в бизнес моделе системы. Следует учесть, что и бизнес модель может содержать ошибки. Поэтому так важно провести операционное тестирование как финальный шаг валидации. Кроме этого, тестирование в среде эксплуатации позволяет выявить и нефункциональные проблемы, такие как: конфликт с другими системами, смежными в области бизнеса или в программных и электронных окружениях; недостаточная производительность системы в среде эксплуатации и др. Очевидно, что нахождение подобных вещей на стадии внедрения — критичная и дорогостоящая проблема. Поэтому так важно проведение не только верификации, но и валидации, с самых ранних этапов разработки ПО.

5. Приемочное тестирование (Acceptance Testing)
Формальный процесс тестирования, который проверяет соответствие системы требованиям и проводится с целью:
• определения удовлетворяет ли система приемочным критериям;
• вынесения решения заказчиком или другим уполномоченным лицом принимается приложение или нет.

Виды / типы тестирования

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

• Функциональное тестирование (Functional testing)
• Тестирование безопасности (Security and Access Control Testing)
• Тестирование взаимодействия (Interoperability Testing)

Прокрутить вверх

©2015- 2022 stydopedia.ru Все материалы защищены законодательством РФ.

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

Функциональные тесты базируются на функциях и особенностях, а также взаимодействии с другими системами, и могут быть представлены на всех уровнях тестирования: компонентном или модульном (Component/Unit testing), интеграционном (Integration testing), системном (System testing) и приемочном (Acceptance testing). Функциональные виды тестирования рассматривают внешнее поведение системы. Далее перечислены самые распространенные виды функциональных тестов:

Функциональное тестирование (Functional testing)

Тестирование безопасности (Security and Access Control Testing)

Тестирование взаимодействия (Interoperability Testing)

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

Функциональные тесты основываются на функциях, выполняемых системой, и могут проводиться на всех уровнях тестирования (компонентном, интеграционном, системном, приемочном). Как правило, эти функции описываются в требованиях, функциональных спецификациях или в виде случаев использования системы (use cases).

Тестирование функциональности может проводиться в двух аспектах: «требования»; «бизнес–процессы».

Тестирование в перспективе «требования» использует спецификацию функциональных требований к системе как основу для дизайна тестовых случаев (Test Cases). В этом случае необходимо сделать список того, что будет тестироваться, а что нет, приоритезировать требования на основе рисков (если это не сделано в документе с требованиями), а на основе этого приоритезировать тестовые сценарии (test cases). Это позволит сфокусироваться и не упустить при тестировании наиболее важный функционал.

Тестирование в перспективе «бизнес–процессы» использует знание этих самых бизнес–процессов, которые описывают сценарии ежедневного использования системы. В этой перспективе тестовые сценарии (test scripts), как правило, основываются на случаях использования системы (use cases).

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

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

Тестирование безопасности. Стратегия тестирования, используемая для проверки безопасности системы, а также для анализа рисков, связанных с обеспечением целостного подхода к защите приложения, атак хакеров, вирусов, несанкционированного доступа к конфиденциальным данным. Тестирование безопасности может выполняться как автоматизированно так и в ручную, включая проверку как позитивных, так и негативных тестовых случаев. Основывается на трех основных принципах – это конфиденциальность, целостность и доступность (confidentiality, integrity, availability)

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

Существует два основных критерия при определении понятия целостности:

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

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

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

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

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

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

Развитие и карьерный рост

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

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

Основные преимущества функционального тестирования

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

Этапы ручного функционального тестирования

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

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

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

Протестируем системы любой сложности

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

Таблица 5 –
Характеристики испытательного сигнала

Число
изменений

в
минуту

Относительное
изменение напряжения U/U,
%

1

2,72

2

2,21

7

1,46

39

0,905

110

0,725

1620

0,402

Во всех случаях
кратковременная доза фликера Pst,
измеряемая прибором, должна быть равна
1,0 ± 0,05 (см. 4.10.1)

Дополнительно
необходимо определить диапазон
относительных
изменений напряжения, для которых
соответствующие значения Pst
имеют погрешность не более ± 5 %. Для
этого величины U/U,
приведенные в таблице 5, увеличивают и
уменьшают, сохраняя неизменной частоту
повторения, и измеряют Pst.

Если,
например, при частоте повторения 7
изменений в минуту, колебания входного
напряжения увеличить в 3 раза от 1,46
до 4,38 %, то Pst
должно увеличиваться от (1,0 ±
5) %
до (3,0 ± 5)
%.

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

Примечание –
Оценка влияния фазовой модуляции
входного напряжения и

изменяющихся
гармонических составляющих напряжения
на показания

11

ГОСТ
Р 51317.4.15-99 (МЭК 61000-4-15-97)

фликерметра
находится на рассмотрении.

6 Методы испытаний

6.1 Общие положения

При испытаниях
приборов проверку отдельных блоков не
проводят. В соответствии с таблицами
1 и 2 должна быть проверена обобщенная

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

5%, то прибор признается
удовлетворяющим
требованиям.

6.2 Проверка
электрической прочности и сопротивления
изоляции и испытания на соответствие
требованиям электромагнитной совместимости

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

Таблица 6 –
Проверка электрической прочности и
сопротивления изоляции электрических
входных цепей и цепей электропитания

Номер

Испытания

Наименование
испытания

Единица
измерения

Способ
подачи испытательного напряжения1),
значение параметра

а

Б

1

Электрическая
прочность
изоляции

2кВ

(среднеквадратичное
значение)

2

2

Сопротивление

Изоляции

0,5кВ

(постоянный
ток)

0,5

1)
См.примечание
к таблице 7

Проверка
электрической прочности и сопротивления
изоляции электрических цепей прибора
– по ГОСТ 22261.

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

12

ГОСТ Р
-99 (МЭК 61000-4-15-97)

Таблица 7 – Испытания
на устойчивость к помехам

Номер

Испыта-ния

Вид помехи

Единица
измере-ния пара-метра

Приме-

чание

Способ
подачи испытательноговоздействия1)
,
значение параметра

Критерий качества
функциони-рования
2)

а

б

1

Кондуктв-ные

помехи

Микросекундные
импульсные помехи большой энергии

1/50 мкс по

ГОСТ Р 51317.4.5

кВ

3

2

1

В

2

Кондуктивные
помехи, наводимые радиочастотными
полями(0,15-80 МГц) по
ГОСТ Р51317.4.6

В

4

10

А

3

Колебательные
затухающие помехи по ГОСТ
Р
51317.4.12

кВ

5

1

0,5

В

4

Наносекундные
импульсные помехи по ГОСТ
Р
51317.4.4

кВ

6

2

2

В

5

Динами-ческие
измене-ния напряже-ния электро-питания
по

ГОСТ Р

51317.4.11

Прерыв-ния
напряж-ния, длитель-ность

перид

7

5

А

Проваы
напряе-ния
:

Уровень

Длитель-ность

%
Uном

период

7

30

25

А

Выброы
напряе-ния
:

уровень

длитель-ность

%
Uном
период

7

120

25

А

13

ГОСТ Р
51317.4.15-99 (МЭК 61000-4-15-97)

Продолжение
таблицы
7 – Испытания на устойчивость к помехам

Номер

Испыта-ния

Вид помехи

Единица
измерения параметра

Приме-

Чание

Способ
подачи испытательноговоздействия 1)
,
значение параметра

Критерий качества
функциони

Рования
2)

а

б

6

Электростати-ческие
разряды по ГОСТ
Р 51317.4.2

кВ

8

8
(воздушный

разряд)

4
(контактный

разряд)

А

В

7

Излуча-емые

помехи

Магнитное
поле промышленной

частоты
по

ГОСТ
Р

50648

А/м

9

30

А

8

Импульсное
магнитное поле по ГОСТ Р 50649

А/м

10

100

В

9

Радиочастотноеэлектромагнит-ное
поле (80-1000 МГц) по

ГОСТ
Р

51317.4.3

В/м

11

10

А

14

ГОСТ Р 51317.4.15-99
(МЭК 61000-4-15-97)

Окончание
таблицы
7

Испытания
на устойчивость к помехам

Примечания
к таблицам 6 и 7

  1. Методы
    подачи испытательных напряжений:

а) между каждым зажимом цепи и заземленным
корпусом прибора;

б) между каждыми двумя из зажимов цепи.

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

Критерий качества функционирования
А

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

Критерий
качества функционирования В

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

  1. Метод
    испытаний – по ГОСТ
    Р 51317.4.5.

  2. Метод
    испытаний – по ГОСТ
    Р 51317.4.6.

  3. Метод
    испытаний – по ГОСТ
    Р 51317.4.12.

  4. Метод
    испытаний – по ГОСТ
    Р 51317.4.4.

  5. Метод
    испытаний–поГОСТ Р
    51317.4.11,
    Uном
    – номинальное
    напряжение сети электропитания.

  6. Метод
    испытаний – по ГОСТ
    Р 51317.4.2
    .

  7. Метод
    испытаний – по ГОСТ
    Р 50648.

  8. Метод
    испытаний – по ГОСТ
    Р 50649.

11
Метод испытаний – по ГОСТ
Р 51317.4.3.

Допускаемые
значения индустриальных радиопомех,
создаваемых прибором, и методы испытаний
— в соответствии с ГОСТ Р 51318.22 (класс Б)

6.3. Испытания на
воздействие климатических и механических
факторов

Методы
испытаний на воздействие климатических
и механических факторов — по ГОСТ 22261

15

ГОСТ
Р 51317.4.15-99 (МЭК 61000-4-15-97)

Рисунок
1- Функциональная схема прибора

16

ГОСТ Р 51317.4.15-99
(МЭК 61000-4-15-97)

Рисунок
2а — Уровень фликера, как функция времени

В
качестве примера показано наличие
сигнала в классе 7

Рисунок
2б – Интегральная функция вероятности
наличия сигнала а классах 1 — 10

Рисунок
2 — Основные положения метода
статистического анализа “время
– уровень фликера ”

17

ГОСТ
Р 51317.4.15-99 (МЭК 61000-4-15-97)