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

Примером требований по размещению конкретного элемента может служить следующее:

Кнопка "Начать передачу" должна находиться непосредственно под строкой меню в левой части рабочей области окна.

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

Требования к содержанию и оформлению выводимых сообщений

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

Так, например, для тестирования требования

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

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

Однако в случае тестирования требования вида

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

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

Требования к форматам ввода

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

---

Ко второй группе относятся следующие типы требований:

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

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

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

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

Например, в требовании

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

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

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

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

Тестопригодность требований к пользовательскому интерфейсу

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

---

Примером тестонепригодного требования может служить классическое требование

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

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

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

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

Примером вероятностного критерия может служить следующее дополнение:

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

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

Полнота покрытия пользовательского интерфейса[21]

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

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

---

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

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

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

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

Ручное тестирование

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

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

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

---

ЗАКЛЮЧЕНИЕ

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

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

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ

1. 
   Гагарина, Л. Г. Технология разработки программного обеспечения : учебное пособие / Л.Г. Гагарина, Е.В. Кокорева, Б.Д. Сидорова-Виснадул ; под ред. Л.Г. Гагариной. — Москва : ФОРУМ : ИНФРА-М, 2022. — 400 с. — (Высшее образование: Бакалавриат). - ISBN 978-5-8199-0707-8. - Текст : электронный. - URL: https://znanium.com/catalog/product/1699927 – Режим доступа: по подписке.
   
2. 
   Дубовой, Н. Д. Основы метрологии, стандартизации и сертификации : учебное пособие / Н. Д. Дубовой, Е. М. Портнов. - Москва : ФОРУМ : ИНФРА-М, 2019. - 256 с. : ил. - (Профессиональное образование). - ISBN 978-5-8199-0338-4. - Текст : электронный. - URL: https://znanium.com/catalog/product/991962 – Режим доступа: по подписке.
   
3. 
   Исаченко, О. В. Программное обеспечение компьютерных сетей : учебное пособие / О.В. Исаченко. — 2-е изд., испр. и доп. — Москва : ИНФРА-М, 2022. — 158 с. — (Среднее профессиональное образование). - ISBN 978-5-16-015447-3. - Текст : электронный. - URL: https://znanium.com/catalog/product/1860121 – Режим доступа: по подписке.
   
4. 
   Мартишин, С. А. Основы теории надежности информационных систем : учебное пособие / С. А. Мартишин, В. Л. Симонов, М. В. Храпченко. — Москва : ФОРУМ : ИНФРА-М, 2020. — 255 с. — (Высшее образование: Бакалавриат). - ISBN 978-5-8199-0757-3. - Текст : электронный. - URL: https://znanium.com/catalog/product/1062374 – Режим доступа: по подписке.
   
5. 
   Морозова, Ю. В. Тестирование программного обеспечения : учебное пособие / Ю. В. Морозова. - Томск : Эль-Контент, 2019. - 120 с. - ISBN 978-5-4332-0279-5. - Текст : электронный. - URL: https://znanium.com/catalog/product/1845910 – Режим доступа: по подписке.
   
6. 
   Попова, Ю. Б. Тестирование и отладка программного обеспечения: пособие / Ю. Б. Попова. – Минск : БНТУ, 2020. – 66 с.
   
7. 
   Федорова, Г. Н. Разработка, внедрение и адаптация программного обеспечения отраслевой направленности : учебное пособие / Г.Н. Федорова. — Москва : КУРС : ИНФРА-М, 2022. — 336 с. — (Среднее профессиональное образование). - ISBN 978-5-906818-41-6. - Текст : электронный. - URL: https://znanium.com/catalog/product/1858587 – Режим доступа: по подписке.
   
8. 
   Царев, Р. Ю. Основы распределенной обработки информации: Учебное пособие / Царёв Р.Ю., Прокопенко А.В., Никифоров А.Ю. - Краснояр.:СФУ, 2015. - 180 с.: ISBN 978-5-7638-3386-7. - Текст : электронный. - URL: https://znanium.com/catalog/product/967646 – Режим доступа: по подписке.
   
9. 
   Черников, Б. В. Управление качеством программного обеспечения : учебник / Б.В. Черников. — Москва : ФОРУМ : ИНФРА-М, 2022. — 240 с. — (Среднее профессиональное образование). - ISBN 978-5-8199-0902-7. - Текст : электронный. - URL: https://znanium.com/catalog/product/1850732 – Режим доступа: по подписке.
   
10. 
    Тестирование, оценка програмного обеспечения. Учебно-методическое пособие по дисциплине «Тестирование, оценка программного обеспечения» для студ. всех форм обуч. спец. 1-58-01-01 Инженерно-психологическое обеспечение информационных технологий и направл. спец. 1-40 05 01-09 Информационные системы и технологии (в обеспечении промышленной безопасности), 1-40 05 01-10 Информационные системы и технологии (в бизнес-менеджменте) / М. М. Меженная, Т. В. Гордейчук, М. М. Борисик, О. С. Медведев, И.Ф. Киринович. – Минск: БГУИР, 2016. – 64 с. : ил.
    
11. 
    Портал специалистов по тестированию и обеспечению качества ПО, библиотека статей по тестированию ПО [Электронный ресурс]. URL: http://softwaretesting.ru/library. Яз. русский.
    

---

Смотрите также файлы

• Все мы едины, все мы оренбургцы так писал поэт и общественный деятель Гавриил Романович Державин.docx

• Протокол от 2022г. Рассмотрено на педагогическом совете Протокол .docx

• Отчет по производственной практике (по профилю специальности) Лит. Листов 100 втжт филиал ргупс содержание.pdf

• 10кл. Бжб2. Жер планетасындаы ауіпті алдытар, леуметтік тесіздік адам ытары жне кмек.docx

• Седьмая.docx