Тестирование программного обеспечения
Особенности определения корректности функционирования анализируемой программы. Анализ основных способов его проведения. Разработка и автоматизация тест-кейсов. Рассмотрение аннотация @Test. История развития тестирования программного обеспечения.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | дипломная работа |
| Язык | русский |
| Дата добавления | 30.08.2016 |
| Размер файла | 52,3 K |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
Введение
Писать программы -- не просто. Даже самые лучшие программисты, зачастую, не в состоянии написать программу так, чтобы она работала как положено в любых случаях. Поэтому, важной частью процесса разработки является тестирование. Написание тестов для кода является отличным способом повышения его качества и стабильности.
Существующие на сегодня методы тестирования программного обеспечения не позволяют однозначно и полностью выявить все дефекты и установить корректность функционирования анализируемой программы, поэтому все существующие методы тестирования действуют в рамках формального процесса проверки исследуемого или разрабатываемого программного обеспечения.
Такой процесс формальной проверки, или верификации, может доказать, что дефекты отсутствуют с точки зрения используемого метода. (То есть нет никакой возможности точно установить или гарантировать отсутствие дефектов в программном продукте с учётом человеческого фактора, присутствующего на всех этапах жизненного цикла программного обеспечения.)
Существует множество подходов к решению задачи тестирования и верификации программного обеспечения, но эффективное тестирование сложных программных продуктов -- это процесс в высшей степени творческий, не сводящийся к следованию строгим и чётким процедурам или созданию таковых.
Качество программного обеспечения можно определить, как совокупную характеристику исследуемого ПО с учётом следующих составляющих: надёжность, сопровождаемость, практичность, эффективность, мобильность, функциональность.
Пытаясь сделать большее с помощью меньшего, организации стремятся проводить адекватное тестирование своего программного обеспечения в минимальные сроки. Для достижения этой цели они обращаются к автоматизированному тестированию. Автоматизация работ по тестированию имеет огромную ценность там, где тестовые скрипты повторяются. Такое тестирование на стадиях разработки и интеграции, когда повторно используемые скрипты могут выполняться много раз, обеспечивает значительную отдачу.
Другой пример эффективного использования автоматизированного тестирования - регрессионное тестирование. Регрессионные тесты имеют целью проверку того, что функции, предоставляемые системой или программным продуктом, выполняются должным образом. Автоматизация позволяет выполнить регрессионное тестирование более эффективным образом. Возможности автоматизированного тестирования продолжают расти, позволяя идти в ногу с растущими потребностями в более быстром создании менее дорогостоящих приложений лучшего качества.
Данная дипломная работа посвящена разработке конечного набора тестов для проверки корректной работы программного обеспечения IP-телефонов.
автоматизация тест кейс программный
1. История развития и виды тестирования программного обеспечения
1.1 История развития тестирования программного обеспечения
Первые программные системы разрабатывались в рамках программ научных исследований или программ для нужд министерств обороны. Тестирование таких продуктов проводилось строго формализовано с записью всех тестовых процедур, тестовых данных, полученных результатов. Тестирование выделялось в отдельный процесс, который начинался после завершения кодирования, но при этом, как правило, выполнялось тем же персоналом.
В 1960-х много внимания уделялось «исчерпывающему» тестированию, которое должно проводиться с использованием всех путей в коде или всех возможных входных данных. Было отмечено, что в этих условиях полное тестирование ПО невозможно, потому что, во-первых, количество возможных входных данных очень велико, во-вторых, существует множество путей, в-третьих, сложно найти проблемы в архитектуре и спецификациях. По этим причинам «исчерпывающее» тестирование было отклонено и признано теоретически невозможным.
В начале 1970-х тестирование ПО обозначалось как «процесс, направленный на демонстрацию корректности продукта» или как «деятельность по подтверждению правильности работы ПО». В зарождавшейся программной инженерии верификация ПО значилась как «доказательство правильности». Хотя концепция была теоретически перспективной, на практике она требовала много времени и была недостаточно всеобъемлющей. Было решено, что доказательство правильности -- неэффективный метод тестирования ПО. Однако, в некоторых случаях демонстрация правильной работы используется и в наши дни, например, приемо-сдаточные испытания. Во второй половине 1970-х тестирование представлялось как выполнение программы с намерением найти ошибки, а не доказать, что она работает. Успешный тест -- это тест, который обнаруживает ранее неизвестные проблемы. Данный подход прямо противоположен предыдущему. Указанные два определения представляют собой «парадокс тестирования», в основе которого лежат два противоположных утверждения: с одной стороны, тестирование позволяет убедиться, что продукт работает хорошо, а с другой -- выявляет ошибки в ПО, показывая, что продукт не работает. Вторая цель тестирования является более продуктивной с точки зрения улучшения качества, так как не позволяет игнорировать недостатки ПО.
В 1980-х тестирование расширилось таким понятием, как предупреждение дефектов. Проектирование тестов -- наиболее эффективный из известных методов предупреждения ошибок. В это же время стали высказываться мысли, что необходима методология тестирования, в частности, что тестирование должно включать проверки на всем протяжении цикла разработки, и это должен быть управляемый процесс. В ходе тестирования надо проверить не только собранную программу, но и требования, код, архитектуру, сами тесты. «Традиционное» тестирование, существовавшее до начала 1980-х, относилось только к скомпилированной, готовой системе (сейчас это обычно называется системное тестирование), но в дальнейшем тестировщики стали вовлекаться во все аспекты жизненного цикла разработки. Это позволяло раньше находить проблемы в требованиях и архитектуре и тем самым сокращать сроки и бюджет разработки. В середине 1980-х появились первые инструменты для автоматизированного тестирования. Предполагалось, что компьютер сможет выполнить больше тестов, чем человек, и сделает это более надежно. Поначалу эти инструменты были крайне простыми и не имели возможности написания сценариев на скриптовых языках.
В начале 1990-х в понятие «тестирование» стали включать планирование, проектирование, создание, поддержку и выполнение тестов и тестовых окружений, и это означало переход от тестирования к обеспечению качества, охватывающего весь цикл разработки ПО. В это время начинают появляться различные программные инструменты для поддержки процесса тестирования: более продвинутые среды для автоматизации с возможностью создания скриптов и генерации отчетов, системы управления тестами, ПО для проведения нагрузочного тестирования. В середине 1990-х с развитием интернета и разработкой большого количества веб-приложений особую популярность стало получать «гибкое тестирование» (по аналогии с гибкими методологиями программирования).
В 2000-х появилось еще более широкое определение тестирования, когда в него было добавлено понятие «оптимизация бизнес-технологий» (en:business technology optimization, BTO). BTO направляет развитие информационных технологий в соответствии с целями бизнеса. Основной подход заключается в оценке и максимизации значимости всех этапов жизненного цикла разработки ПО для достижения необходимого уровня качества, производительности, доступности.
1.2 Виды тестирования
В процессе инсталляционного тестирования проверяется корректность установки и удаления программного продукта в среде, максимально приближенной к эксплуатационной. Об этом аспекте корректной работы программного обеспечения очень часто просто забывают (и напрасно). Правильно выполненная установка программы -- необходимое условие её корректной дальнейшей работы. Проверка правильности установки должна быть обязательным элементом проекта по тестированию любого продукта. Если программу невозможно корректно установить, и при этом что-то не будет работать или будет работать неправильно, работа по тестированию самого программного тестирования бессмысленна. Почему? Потому что заказчику не нужен продукт, который даже невозможно установить. Если пользователь уже на этапе установки сталкивается с проблемами в разработанном программном продукте, что он подумает о самом программном продукте? Будет ли он связываться с такой фирмой-разработчиком?
Регрессионное тестирование (regression testing)
Повторное выполнение тестов для проверки того, что изменения, внесённые в программу в результате разработки новой или изменения существующей функциональности, устранения ошибок, не повлияли на функциональность, которая не изменялась (т.е. текущая версия ведёт себя идентично предыдущей, за исключением измененных областей).
Тестирование новой функциональности (new feature testing)
В данном виде тестирования акцент делается на тестировании новой функциональности, появившейся в конкретном выпуске (build) программного продукта.
Конфигурационное тестирование (configuration testing)
С помощью конфигурационных тестов проверяется совместимость продукта с различным программным (software) и аппаратным (hardware) обеспечением. Как правило, программный продукт делается с тем расчётом, чтобы он сразу работал в максимально разнообразной внешней среде. Если же речь идёт о «коробочном продукте», то фактор совместимости приобретает ещё более важное значение. Для того, чтобы выяснить реакцию продукта на окружение и соседство с другим программным обеспечением, и проводят данные тесты.
Тестирование совместимости (compatibility testing)
Тестирование совместимости помогает убедиться в функциональных возможностях и надёжности работы продукта в поддерживаемых браузерах (если речь идет о Web-приложениях) и операционных системах. Также может проверяться работоспособность продукта при использовании различных аппаратных платформ.
Тестирование удобства эксплуатации (usability testing)
Тестирование интерфейса человек/машина производится в отношении таких моментов как внешний вид пользовательского интерфейса, удобство навигации (преимущественно для Web-сайтов). Практичность и удобство использования - очень важные характеристики программного продукта. Например, программа может вполне соответствовать всем предъявляемым к ней требованиям с точки зрения функциональности. Но функции реализованы неудобно: некоторые шаги приходится повторять много раз, тогда как по логике достаточно выполнить однажды; расположение элементов интерфейса нелогично, программа быстро вызывает утомление и т.д. Для выявления такого рода недочётов и применяют тесты на удобство использования. Часто эта группа тестов относится к категории некритичных, но когда речь идёт, например, о рыночном готовом продукте, пренебрегать удобством эксплуатации весьма опасно.
Интеграционное тестирование (integration testing)
Такой вид тестирования может представлять два направления деятельности: 1. Проверку того, как отдельные модули приложения взаимодействуют между собой. 2. Проверку того, как приложение взаимодействует с каким-то внешним приложением или компонентом системы.
Тестирование безопасности (security testing)
Тестирование безопасности представляет собой ряд работ: от разработки политики безопасности до тестирования безопасности на уровне приложения, операционной системы и сетевой безопасности. Тестирование безопасности может иметь различную степень покрытия:
- первичное тестирование безопасности;
- полное тестирование приложения;
- полное тестирование приложения и сервера.
Для тестирования безопасности на начальном уровне применяются специальные утилиты, способные проверить приложение или систему на наличие элементарных уязвимостей (список которых, однако, может включать тысячи и десятки тысяч пунктов).
На более глубоком уровне тестированием безопасности занимаются эксперты, т.к. данный вид тестирования требует глубочайших знаний особенностей технологий, с использованием которых разработано приложение.
Тестирование интернационализации (internationalisation testing)
Этот вид тестирования проверят готовность приложения к работе с различными языковыми интерфейсами. В частности, проверяется способность корректно отображать шрифты, пункты меню, производить поиск, сортировку, способность приложения обрабатывать файлы, поименованные на различных языках. Следующей стадией, как правило, является локализационное тестирование.
Локализационное тестирование (localisation testing)
Проверяет, насколько корректно продукт адаптирован к работе на том или ином языке: всё ли переведено и переведено правильно, не нарушилась ли логика построения интерфейса и обработки данных и т.д. Для локализационного тестирования рекомендуется обязательно приглашать в команду носителя того языка, перевод на который тестируется. В противном случае мы рискуем увидеть нечто подобное:
Пункт меню: «Сделать под себя» («Customise»)
Огромная красная кнопка «ВСЁ!» («Finish»)
Пункт меню «Ясные печенья» («Clear cookies»)
Тестирование прототипа (prototype testing)
Это метод выявления структурных, логических ошибок и ошибок проектирования на ранней стадии развития продукта до начала фактической разработки. Основная цель тестирования прототипа - выявить потенциальные проблемы в приложении, проверить, насколько приложение соответствует потребностям и ожиданиям пользователя и обнаружить расхождения с требованиями к графическому интерфейсу пользователя.
Тестирование производительности (performance testing), Нагрузочное тестирование (load testing), Стрессовое тестирование (stress testing)
Эти три вида тестирования тесно связаны между собой и перетекают в некоторых случаях друг в друга. Тестирование производительности проверяет способность программы выполнять заданное количество операций в заданный промежуток времени. Нагрузочное тестирование проверяет способность приложения работать при запланированной нагрузке. Стрессовое тестирование проверяет поведение приложения в условиях, выходящих за рамки оговоренных для эксплуатации приложения.
Модульное (компонентное) тестирование (Unit testing)
С термином Unit testing связана некоторая путаница. Во-первых, на русский его переводят и как «модульное тестирование», и как «компонентное тестирование». Во-вторых, под этим термином кроется два достаточно различных вида деятельности:
1. Если мы говорим и «компонентном тестировании» (здесь уместнее этот перевод) в общем смысле (в контексте «тестирования вообще»), мы имеем в виду тестирование отдельных частей приложения. Причём эти части могут быть достаточно крупными.
2. Если мы говорим о «модульном тестировании» (здесь уже лучше использовать такой перевод) в контексте автоматизации тестирования, мы имеем в виду тестирование отдельных участков кода, классов, методов.
Как и любая технология тестирования, модульное тестирование не позволяет отловить все ошибки программы.
В самом деле, это следует из практической невозможности трассировки всех возможных путей выполнения программы, за исключением простейших случаев. Кроме того, происходит тестирование каждого из модулей по отдельности.
Это означает, что ошибки интеграции, системного уровня, функций, исполняемых в нескольких модулях, не будут определены. Таким образом, модульное тестирование более эффективно при использовании в сочетании с другими методиками тестирования.
2. JUnit and JSystem
2.1 Описание
Оболочки модульного тестирования -- это программные средства для разработки тестов, включающие: построение, выполнение тестов и создание отчетов.
Первая оболочка модульного тестирования SUnit была создана Кентом Беком в 1999 году для языка Smalltalk. Позднее Эрик Гамма создал JUnit. Сейчас существует множество оболочек для модульного тестирования, которые известны как программные средства семейства XUnit. JUnit -- реализация XUnit, наиболее широко используемая и расширенная версия оболочек модульного тестирования. JUnit создан на языке Java и используется для тестирования Java кода.
Модульное тестирование или unit testing -- процесс проверки на корректность функционирования отдельных частей исходного кода программы путем запуска тестов в искусственной среде. Под частью кода в Java следует понимать исполняемый компонент. С помощью модульного тестирования обычно тестируют низкоуровневые элементы кода -- такие, как методы. JUnit позволяет вне исследуемого класса создавать тесты, при выполнении которых произойдет корректное завершение программы. Кроме основного положительного сценария может выполняться проверка работоспособности системы в альтернативных сценариях, например, при генерации методом исключения как реакция на ошибочные исходные данные.
Оценивая каждую часть кода изолированно и подтверждая корректность ее работы, точно установить проблему значительно проще, чем если бы элемент был частью системы.
Технология позволяет и предлагает сделать более тесной связь между разработкой кода и его тестированием, а также предоставляет возможность проверить корректность работы класса, не прибегая к пробному выводу при отладке кода.
JUnit 4 в отличие от JUnit 3 полностью построен на аннотациях.
Для использования технологии необходимо загрузить библиотеку JUnit с сервера junit.org и включить архив junit.jar в список библиотек приложения.
При включении модульного тестирования в проект:
-- тесты разрабатываются для нетривиальных методов системы;
-- ошибки выявляются в процессе проектирования метода или класса;
-- в первую очередь разрабатываются тесты на основной положительный сценарий;
-- разработчику приходится больше уделять внимания альтернативным сценариям поведения, так как они являются источником ошибок, выявляемых на поздних стадиях разработки;
-- разработчику приходится создавать более сфокусированные на своих обязанностях методы и классы, так как сложный код тестировать значительно труднее;
-- снижается число новых ошибок при добавлении новой функциональности;
-- устаревшие тесты можно игнорировать;
-- тест отражает элементы технического задания, то есть некорректное завершение теста сообщает о нарушении технических требований заказчика;
-- каждому техническому требованию соответствует тест;
-- получение работоспособного кода с наименьшими затратами.
2.2 Аннотация @Test
Аннотация помечает метод как тестовый, что позволяет использовать возможности класса org.junit.Assert и запускать его в режиме тестирования. Метод, предназначенный для функционирования в качестве теста, достаточно промаркировать аннотацией @Test.
Тестовый метод должен всегда объявляться как public void. Аннотация может использовать параметры:
expected -- определяет ожидаемый класс исключения;
timeout -- определяет время, превышение которого делает тест ошибочным.
2.3 JSystem
Для разработки и исполнения тестов используется приложение JSystem - это фреймворк с открытым исходным кодом, созданный, непосредственно, для написания и запуска автоматических тестов. Данный фреймворк написан на языке Java и базируется на нескольких java проектах, используемых Eclipse, как среду разработки.
JSystem делит процесс разработки тестирования и архитектуры на четыре слоя, что упрощает и ускоряет процесс разработки. Эти слои определяются следующим образом:
SystemObject Layer
Изначально создается SUT файл, содержащий в себе настройки для каждого сета, а также общие настройки для тестов. По сути SUT дает возможность выполнить тот же самый тест с другой конфигурацией. SUT - это устройство или же программное обеспечение, которое тестируется.
Tests Cases Layer
JSystem тестами являются JUnit тесты. В нашем проекте существует свой фреймворк, содержащий множество классов и методов, используемых для создания тестов.
Test Scenarios Layer
Тесты сгруппированы по иерархическому принципу в рамках сценария. Сценарии JSystem создаются в виде Ant скриптов.
Management Layer
Данный слой содержит приложения и услуги, целью которых является поддержка разработки и выполнения проектов автоматизации.
3. Разработка тест-кейсов
Была поставлена задача: разработать наборы тест-кейсов для того, чтобы покрыть определённый функционал телефона. В дальнейшем эти тесты будут использоваться в регрессионом тестировании, когда будут выходить новые версии ПО.
Так же, для удобства и ускорения процесса тестирования был создан ряд методов, которые используются при построении автоматических тестов.
Тест-кейс -- это такое описание проверки работы системы, которое может выполнить любой человек из команды, будь то тестировщик, разработчик, аналитик или даже бизнес-заказчик.
Набор тест-кейсов называется тестовым набором (test suite).
Иногда этот набор называют тест-планом.
Ниже приведена таблица (Таблица 1) с набором тестовых сценариев.
Таблица 1 (начало)
|
ExternalID |
Name |
Description |
Step number |
Step |
TestData |
Result |
|
|
1 |
Presence states of 250 contacts are correctly restored after relogin |
Check that presence states of 250 contacts are correctly restored after reboot. All watched contacts should show "Offline" presence state Test for: 9608, 9611, 9641 Setup: 1) User X has 250 contacts |
1 |
Phone A navigate |
Amenu -> Log out |
The phone shows Settings screen |
|
|
2 |
Log out from this extension |
The phone shows screen "Enter username" |
|||||
|
3 |
Login to user X |
Phone screen of user X |
|||||
|
4 |
Phone A navigate |
Address book |
Loading of contacts |
||||
|
5 |
Check presence states of 250 contacts |
All contacts have presence states "Offline" |
|||||
|
6 |
Relogin |
||||||
|
7 |
Check presence states of 250 contacts |
All contacts have presence states "Offline" |
|||||
|
8 |
Return to first extension |
Login to first extension which shows phone screen |
|||||
|
2 |
Presence states of 250 contacts are correctly restored after reboot |
Check that presence states of 250 contacts are correctly restored after reboot. All watched contacts should show "Offline" presence state Test for: 9608, 9611, 9641 Setup: 1) User X has 250 contacts |
1 |
Phone A navigate |
Amenu -> Logout |
The phone shows Settings screen |
|
|
2 |
Logout from this extension |
The phone shows screen "Enter username" |
|||||
|
3 |
Login to user X in address book |
The phone screen of user X |
|||||
|
4 |
Phone A navigate |
Address book |
Contacts loading |
||||
|
5 |
Check presence states of 250 contacts |
All contacts have presence states "Offline" |
|||||
|
6 |
Reboot |
From CRAFT menu |
Reboot finished normally and the phone shows phone screen |
||||
|
7 |
Check presence states of 250 contacts |
All contacts have presence states "Offline" |
|||||
|
8 |
Return to first extension |
Logout from user X, and login to first extension |
|||||
|
3 |
Impossible to create the 251st contact |
Check that when address book is had 250 contacts then can not create a contact Test for: 9608, 9611, 9641 Setup:1) User X has 250 contacts |
1 |
Phone A navigate |
Amenu -> Logout |
The phone shows Settings screen |
|
|
2 |
Logout from this extension |
The phone shows screen "Enter username" |
|||||
|
3 |
Login to user X |
The phone screen of user X |
|||||
|
4 |
Phone A navigate |
Address book |
Contacts loading |
||||
|
5 |
Check that button "New" is disappeared |
Button "New" is absent |
|||||
|
4 |
Update presence state of contact that has E.164 handle in profile |
Check, that Presence state of extension with E.164 matches with Presence state of this extension in address book of other extension when presence is changed Check, that Presence state of extension without E.164 matches with Presence state of this extension in address book of other extension when presence is changed Also check, that Presence state of extension in Automatic mode is available in idle state Test for: 9608, 9611, 9641 Setup: Phone A, Phone B, Phone C 1) User X has extension with E.164 handle 2) Phone A has extension non-E.164 handle 3) Phone C - watcher |
1 |
Check that presence state on phone A is working normally |
Presence is working normally on phone A |
||
|
2 |
Phone A navigate |
Amenu -> My Presence |
The phone shows My Presence menu |
||||
|
3 |
Set "Automatic" presence state on phone A |
Presence state: "Automatic" |
|||||
|
4 |
Check that Presence state of phone A is "Available" when automatic mode turn on |
Presence is available on phone A |
|||||
|
5 |
Check that presence state on phone C is working normally |
Presence is working normally on phone C |
|||||
|
6 |
Phone C navigate |
Amenu -> My Presence |
The phone shows My Presence menu |
||||
|
7 |
Set "Automatic" presence state on phone C |
Presence state: "Automatic" |
|||||
|
8 |
Check that Presence state of phone C is "Available" when automatic mode turn on |
Presence is available on phone C |
|||||
|
9 |
Delete all contacts on phone A |
All contacts have deleted |
|||||
|
10 |
Delete all contacts on phone C |
All contacts have deleted |
|||||
|
11 |
Logout from phone B |
The phone shows screen "Enter username" |
|||||
|
12 |
Login to user X |
Phone screen of user X |
|||||
|
13 |
Delete all contacts from user X |
All contacts have deleted |
|||||
|
14 |
Check that presence state on phone C is working normally |
Presence is working normally on phone C |
|||||
|
15 |
Phone C navigate |
Amenu -> My Presence |
The phone shows My Presence menu |
||||
|
16 |
Set "Automatic" presence state on phone C |
Presence state: "Automatic" |
|||||
|
17 |
Check that Presence state of phone C is "Available" when automatic mode turn on |
Presence is available on phone C |
|||||
|
18 |
Add user Y in address book of phone C |
Contact on phone C is created |
|||||
|
19 |
Add contact user X in address book of phone C |
Contact on phone C is created |
|||||
|
20 |
Check that presence state of user Y and presence of this contact in address book of watcher are the same |
Presence states are the same |
|||||
|
21 |
Check that presence state of user X and presence of this contact in address book of C are the same |
Presence states are the same |
|||||
|
22 |
Phone A navigate |
Amenu -> My presence |
The phone shows "My Presence" menu |
||||
|
23 |
Change presence state of user Y |
The presence state is available or away or busy |
|||||
|
24 |
Check that presence state of user Y and presence of this contact in address book of watcher are the same |
Presence states are the same |
|||||
|
25 |
Phone B navigate |
Amenu -> My presence |
The phone shows "My Presence" menu |
||||
|
26 |
Change presence state of user X |
The presence state is available or away or busy |
|||||
|
27 |
Check that presence state of user X and presence of this contact in address book of watcher are the same |
Presence states are the same |
|||||
|
28 |
Log out from user X |
The phone shows screen "Enter username" |
|||||
|
29 |
Login to first extension on phone B |
The phone shows phone screen |
|||||
|
30 |
Delete all contacts on phone C |
All contacts are deleted |
|||||
|
5 |
Comprasion of Presence state "Automatic" of extension, that has E.164 handle in profile with Presence state of this extension in address book of other extension |
Check, that Presence state "Automatic" of extension, which has E.164 handle in profile and Presence state of this contact in address book of other extension are similar Test for: 9608, 9611, 9641 Setup: Phone A; Phone B 1) Phone A - watcher 2) User X has E.164 handle in profile |
1 |
Delete all contacts on Phone A |
All contacts are deleted |
||
|
2 |
Login to user X on Phone B |
The phone screen of user X |
|||||
|
3 |
Add user X in address book of watcher |
Contact is created |
|||||
|
4 |
Phone B navigate |
Amenu -> My presence |
The phone shows "My Presence" menu |
||||
|
5 |
Set "Automatic" presence state of user X |
The presence state of user X is "Automatic" |
|||||
|
6 |
Check that presence state of user X and presence of this contact in address book of watcher are the same |
Presence states are the same |
|||||
|
6 |
Comprasion of Presence state "Available" of extension, that has E.164 handle in profile with Presence state of this extension in address book of other extension |
Check, that Presence state "Available" of extension, which has E.164 handle in profile and Presence state of this contact in address book of other extension are similar Test for: 9608, 9611, 9641 Setup: Phone A; Phone B 1) Phone A - watcher 2) User X has E.164 handle in profile |
1 |
Delete all contacts on Phone A |
All contacts are deleted |
||
|
2 |
Login to user X on Phone B |
The phone screen of user X |
|||||
|
3 |
Add user X in address book of watcher |
Contact is created |
|||||
|
4 |
Phone B navigate |
Amenu -> My presence |
The phone shows "My Presence" menu |
||||
|
5 |
Set "Available" presence state of user X |
The presence state of user X is "Available" |
|||||
|
6 |
Check that presence state of user X and presence of this contact in address book of watcher are the same |
Presence states are the same |
|||||
|
7 |
Comprasion of Presence state "Busy" of extension, that has E.164 handle in profile with Presence state of this extension in address book of other extension |
Check, that Presence state "Busy" of extension, which has E.164 handle in profile and Presence state of this contact in address book of other extension are similar Test for: 9608, 9611, 9641 Setup: Phone A; Phone B 1) Phone A - watcher 2) User X has E.164 handle in profile |
1 |
Delete all contacts on Phone A |
All contacts are deleted |
||
|
2 |
Login to user X on Phone B |
The phone screen of user X |
|||||
|
3 |
Add user X in address book of watcher |
Contact is created |
|||||
|
4 |
Phone B navigate |
Amenu -> My presence |
The phone shows "My Presence" menu |
||||
|
5 |
Set "Busy" presence state of user X |
The presence state of user X is "Busy" |
|||||
|
6 |
Check that presence state of user X and presence of this contact in address book of watcher are the same |
Presence states are the same |
|||||
|
8 |
Comprasion of Presence state "Away" of extension, that has E.164 handle in profile with Presence state of this extension in address book of other extension |
Check, that Presence state "Away" of extension, which has E.164 handle in profile and Presence state of this contact in address book of other extension are similar Test for: 9608, 9611, 9641 Setup: Phone A; Phone B 1) Phone A - watcher 2) User X has E.164 handle in profile |
1 |
Delete all contacts on Phone A |
All contacts are deleted |
||
|
2 |
Login to user X on Phone B |
The phone screen of user X |
|||||
|
3 |
Add user X in address book of watcher |
Contact is created |
|||||
|
4 |
Phone B navigate |
Amenu -> My presence |
The phone shows "My Presence" menu |
||||
|
5 |
Set "Away" presence state of user X |
The presence state of user X is "Away" |
|||||
|
6 |
Check that presence state of user X and presence of this contact in address book of watcher are the same |
Presence states are the same |
|||||
|
9 |
Comprasion of Presence state "Do Not Disturb" of extension, that has E.164 handle in profile with Presence state of this extension in address book of other extension |
Check, that Presence state "Do Not Disturb" of extension, which has E.164 handle in profile and Presence state of this contact in address book of other extension are similar Test for: 9608, 9611, 9641 Setup: Phone A; Phone B 1) Phone A - watcher 2) User X has E.164 handle in profile |
1 |
Delete all contacts on Phone A |
All contacts are deleted |
||
|
2 |
Login to user X on Phone B |
The phone screen of user X |
|||||
|
3 |
Add user X in address book of watcher |
Contact is created |
|||||
|
4 |
Phone B navigate |
Amenu -> My presence |
The phone shows "My Presence" menu |
||||
|
5 |
Set "Do Not Disturb" presence state of user X |
The presence state of user X is "Do Not Disturb" |
|||||
|
6 |
Check that presence state of user X and presence of this contact in address book of watcher are the same |
Presence states are the same |
|||||
|
10 |
Comprasion of Presence state "Out Of Office" of extension, that has E.164 handle in profile with Presence state of this extension in address book of other extension |
Check, that Presence state "Out Of Office" of extension, which has E.164 handle in profile and Presence state of this contact in address book of other extension are similar Test for: 9608, 9611, 9641 Setup: Phone A; Phone B 1) Phone A - watcher 2) User X has E.164 handle in profile |
1 |
Delete all contacts on Phone A |
All contacts are deleted |
||
|
2 |
Login to user X on Phone B |
The phone screen of user X |
|||||
|
3 |
Add user X in address book of watcher |
Contact is created |
|||||
|
4 |
Phone B navigate |
Amenu -> My presence |
The phone shows "My Presence" menu |
||||
|
5 |
Set "Out Of Office" presence state of user X |
The presence state of user X is "Out Of Office" |
|||||
|
6 |
Check that presence state of user X and presence of this contact in address book of watcher are the same |
Presence states are the same |
|||||
|
11 |
Comprasion of Presence state "Offline" of extension, that has E.164 handle in profile with Presence state of this extension in address book of other extension |
Check, that Presence state "Offline" of extension, which has E.164 handle in profile and Presence state of this contact in address book of other extension are similar Test for: 9608, 9611, 9641 Setup: Phone A; Phone B 1) Phone A - watcher 2) User X has E.164 handle in profile |
1 |
Delete all contacts on Phone A |
All contacts are deleted |
||
|
2 |
Login to user X on Phone B |
The phone screen of user X |
|||||
|
3 |
Add user X in address book of watcher |
Contact is created |
|||||
|
4 |
Phone B navigate |
Amenu -> My presence |
The phone shows "My Presence" menu |
||||
|
5 |
Set "Offline" presence state of user X |
The presence state of user X is "Offline" |
|||||
|
6 |
Check that presence state of user X and presence of this contact in address book of watcher are the same |
Presence states are the same |
|||||
|
12 |
Changing of numeric mode to character and vice versa |
Verify, that it possible to change from numeric mode to character when a contact is creating Test for: non-touch phones 9608, 9611, SONIC Setup: 1) First Name: tma123TMA Firsr part: tma Second part: 123 Third part: TMA |
1 |
Phone A navigate |
Phone Screen -> Address Book |
The phone shows address book |
|
|
2 |
Press button "New" to create a contact |
Press button "New" -> parameters of entering contact |
Screen with entity "First Name" "Last Name" and message: "Enter the First Name" |
||||
|
3 |
Change from uppercase to lowercase |
Press button "More" -> Set "abc" mode |
|||||
|
4 |
Enter the first part of name of contact |
First part of name has written |
|||||
|
5 |
Change from character mode to numeric |
Press button "More" -> Set "123" mode |
|||||
|
6 |
Enter the second part of name of contact |
First and second part have written |
|||||
|
7 |
Change from numeric mode to uppercase character mode |
Set "ABC" mode |
|||||
|
8 |
Check that uppercase mode button "ABC" has appeared |
Button "ABC" is located it should be |
|||||
|
9 |
Enter the third part of name of contact |
Full first name has written |
|||||
|
10 |
Enter some number of contact |
||||||
|
11 |
Save this contact |
Press button "Save" |
Contact has saved. In address book the record of this contact has appeared |
||||
|
12 |
Check that the name of created contact is correct |
The name of created contact is correct |
|||||
|
13 |
Delete all contacts |
All contacts has deleted |
|||||
|
13 |
Impossible to turn on Packet Capture when it's disabled |
Check that Packet Capture can not be started when it's disabled in debug menu Test for: 9608, 9611, 9641, SONIC |
1 |
Define 46settings.txt |
SLMSTAT 1 SLMCLIENT 1 SLMFSB 1 SLMPERF 1 SLMCTRL 2 SLMCAP 3 SLMPORT 50011 SLMTEST 50012 SLMSRVR 192.168.39.140:50011 PROCPSWD 1234 |
46settings.txt is defined |
|
|
2 |
Reboot Phone A to apply settings |
Login User/Station A |
Phone A reboots, User A is logged in |
||||
|
3 |
Phone A navigate |
CRAFT -> Debug |
Debug mode - Off; Service mode control - Disabled; Service mode record - Disabled |
||||
|
4 |
Turn on packet capture on SLA Monitor server |
||||||
|
5 |
Check no active capturing via SLA Server |
The message on SLA Server: The entered agent is not packet capture enabled :phoneA" |
|||||
|
6 |
Check no active capturing via /tmp/slamon/capturing file |
This file doesn't exists |
|||||
|
7 |
Check no active capturing via REC icon |
A record mode icon appears on the top line |
|||||
|
14 |
Impossible to turn on Remote Control when it's disabled |
Check that Remote Control can not be started when it's disabled in debug menu Test for: 9608, 9611, 9641, SONIC |
1 |
Define 46settings.txt |
SLMSTAT 1; SLMCLIENT 1; SLMFSB 1; SLMPERF 1; SLMCTRL 2; SLMCAP 3; SLMPORT 50011; SLMTEST 50012; SLMSRVR 192.168.39.140:50011; PROCPSWD 1234; |
46settings.txt is defined |
|
|
2 |
Reboot Phone A to apply settings |
Login User/Station A |
Phone A reboots, User A is logged in |
||||
|
3 |
Phone A navigate |
CRAFT -> Debug |
Debug mode - Off; Service mode control - Disabled; Service mode record - Disabled |
||||
|
4 |
Turn on remote control on SLA Monitor server |
||||||
|
5 |
Check no active remote control session via SLA Server |
The message on SLA Server: "Phone Remote Control not enabled for this phone" |
|||||
|
6 |
Check no active remote control session via /tmp/slamon/capturing file |
This file doesn't exists |
|||||
|
7 |
Check no active remote control session via CTRL icon |
A SLA control icon doesn't appears on the top line. |
|||||
|
15 |
Icon of Remote Control appears after relogin |
Check, that CTRL icon shows up after relogin of extention, when remote control turned on Test for: 9608, 9611, 9641 |
1 |
Define 46settings.txt |
SLMSTAT 1; SLMCLIENT 1; SLMFSB 1; SLMPERF 1; SLMCTRL 2; SLMCAP 3; SLMPORT 50011; SLMTEST 50012; SLMSRVR 192.168.39.140:50011; PROCPSWD 1234; |
46settings.txt is defined |
|
|
2 |
Reboot Phone A to apply settings |
Login User/Station A |
Phone A reboots, User A is logged in |
||||
|
3 |
Phone A navigate |
CRAFT -> Debug |
Debug mode - Off; Service mode control - Disabled; Service mode record - Disabled |
||||
|
4 |
Turn on service mode control |
Debug menu |
Service mode control - Enable |
||||
|
5 |
Turn on remote control on SLA Monitor server |
||||||
|
6 |
Check active remote control session via CTRL icon |
A SLA control icon appears on the top line. |
|||||
|
7 |
Check active control session via /tmp/slamon/control file |
This file exists |
|||||
|
8 |
Relogin |
From Amenu |
|||||
|
9 |
Check that CTRL icon to be located on the top line |
CTRL icon appears on the top line |
|||||
|
16 |
Icon of Packet Capture appears after relogin |
Check, that REC icon shows up after relogin, when packet capture is turned on Test for: 9608, 9611, 9641 |
1 |
Define 46settings.txt |
SLMSTAT 1; SLMCLIENT 1; SLMFSB 1; SLMPERF 1; SLMCTRL 2; SLMCAP 3; SLMPORT 50011; SLMTEST 50012; SLMSRVR 192.168.39.140:50011; PROCPSWD 1234; |
46settings.txt is defined |
|
|
2 |
Reboot Phone A to apply settings |
Login User/Station A |
Phone A reboots, User A is logged in |
||||
|
3 |
Phone A navigate |
CRAFT -> Debug |
Debug mode - Off; Service mode control - Disabled; Service mode record - Disabled |
||||
|
4 |
Turn on service mode record |
Debug menu |
Service mode record - Enable |
||||
|
5 |
Turn on packet capture on SLA Monitor server |
||||||
|
6 |
Check active capturing via REC icon |
A SLA record icon appears on the top line. |
|||||
|
7 |
Check active capturing via /tmp/slamon/control file |
This file exists |
|||||
|
8 |
Relogin |
From Amenu |
|||||
|
9 |
Check that REC icon to be located on the top line |
REC icon appears on the top line |
|||||
|
17 |
Clearing history from all calls and from missed calls |
Check, that when clear history from All Calls, it clear too in Missed calls Test for: 9608, 9611, 9641 Phone A, Phone B |
1 |
Create some history of calls (misssed, outgoing, incoming calls) on phone A |
|||
|
2 |
Phone A navigate |
CALL LOG |
History screen |
||||
|
3 |
Delete All Calls |
Press button "Clear All" |
Clear history screen |
||||
|
4 |
Check that missed calls is deleted too |
All Calls -> Missed calls |
Missed calls is deleted |
||||
|
5 |
Check that all history is deleted |
Missed calls -> All Calls |
All calls is deleted |
4. Автоматизация тест-кейсов
Собрана рабочая лаба (рис. 1), содержащая все вышеперечисленные сеты, подключена к сети. Для каждого сета были созданы extensions в системе SMGR. Так же на локальном компьютере установлена кроссплатформенная сборка веб-сервера XAMPP, необходимая для запуска сервера Apache, с которого происходит установка необходимых параметров для каждого сета, установка билда и выпол...
Подобные документы
История возникновения тестирования программного обеспечения, основные цели и особенности его проведения. Виды и типы тестирования, уровни его автоматизации. Использование и исследование необходимых технологий. Полный цикл прогона всей системы мониторинга.
дипломная работа [1,7 M], добавлен 03.05.2018История развития и виды тестирования программного обеспечения. Инсталляционное, регрессионное, конфигурационное, интеграционное, локализационное, модульное тестирование. Методы сокращения трудоемкости модульного тестирования разрабатываемого приложения.
курсовая работа [309,5 K], добавлен 16.12.2015Неразрешимость проблемы тестирования программного обеспечения. Виды и уровни тестирования. Стратегии восходящего и нисходящего тестирования. Методы "белого" и "черного" ящика. Автоматизированное и ручное тестирование. Разработка через тестирование.
курсовая работа [112,2 K], добавлен 22.03.2015Тестирование как составляющая часть процесса отладки программного обеспечения, его роль для обеспечения качества продукта. Обнаружение ошибок в программах, выявление причин их возникновения. Подходы к формулированию критериев полноты тестирования.
курсовая работа [1,6 M], добавлен 20.12.2012Изучение различных видов тестирования программного обеспечения. Выявление в программной системе скрытых дефектов до того, как она будет сдана заказчику. Тестирование методом черного ящика. Требования, предъявляемые к процессу тестирования больших систем.
курсовая работа [3,0 M], добавлен 19.11.2009Комплексное функциональное и структурное тестирование программного продукта - граф-программа решения квадратного уравнения. Постановка задачи структурного тестирования маршрутов. Заключение о типе и причине ошибки, предложение по ее исправлению.
курсовая работа [2,8 M], добавлен 05.01.2013Тестирование и отладка программного обеспечения: понятие, принципы, этапы, цели и задачи. Тестирование методом сандвича как компромисс между восходящим и нисходящим подходами. Сущность метода "белого и черного ящика", отладки программного обеспечения.
курсовая работа [36,9 K], добавлен 21.07.2012Проектирование базы данных, информационной подсистемы PLC-Tester, модуля тестирования и web-приложения. Разработка логической структуры программного продукта и общие требования к техническому обеспечению. Запуск программы и описание тестовых прогонов.
дипломная работа [3,2 M], добавлен 30.06.2011Реализация программного средства "Действия над матрицами". Разработка кода программного продукта на основе готовой спецификации на уровне модуля. Использование инструментальных средств на этапе отладки программного модуля. Выбор стратегии тестирования.
отчет по практике [296,1 K], добавлен 19.04.2015Возможности среды программирования delphi при разработке приложения с визуальным интерфейсом. Разработка спецификации программного обеспечения и на ее основе кода программного продукта. Отладка программы "трассировкой", ее тестирование и оптимизация.
курсовая работа [501,4 K], добавлен 07.12.2016Выбор инструментальной среды разработки программного обеспечения системы. Алгоритм создания теста и ввода его исходных данных. Анализ экономической эффективности применения программного обеспечения "Тестирования знаний обучающихся программированию".
дипломная работа [3,2 M], добавлен 11.09.2014Сравнительный анализ технологий тестирования. Разработка программного модуля "Интеллектуальная обучающая система для широкого перечня курсов". Обоснование необходимости и важности этапа отладки в процессе разработки данного программного обеспечения.
дипломная работа [101,2 K], добавлен 17.06.2011Схемы взаимодействия между заказчиком и разработчиком программного обеспечения. Качество программного обеспечения и определение основных критериев его оценка на современном этапе, особенности управления на стадиях жизненного цикла, анализ достаточности.
презентация [114,7 K], добавлен 14.08.2013Понятие и специфика автоматизированных систем. Описание методики разработки программы для автоматизации. Ее тестирование и отладка. Внедрение АС в работу предприятия. Расчет экономического эффекта от разработки и реализации программного продукта.
дипломная работа [1,4 M], добавлен 23.06.2015Общие сведения об исследуемой организации, направления ее хозяйственной деятельности, характеристика используемой вычислительной техники и программного обеспечения. Разработка пользовательского интерфейса, шаблонов, отладка и тестирование программы.
отчет по практике [159,3 K], добавлен 11.04.2016Разработка программного обеспечения, предназначенного для автоматизации деятельности туристической фирмы. Анализ и проектирование базы данных предметной области. Создание концептуальной, логической и физической моделей данных и программы их обработки.
курсовая работа [816,5 K], добавлен 05.02.2018Особенности аналитической и эмпирической моделей надежности программных средств. Проектирование алгоритма тестирования и разработка программы для определения надежности ПО моделями Шумана, Миллса, Липова, с использованием языка C# и VisualStudio 2013.
курсовая работа [811,5 K], добавлен 29.06.2014Изучение основных видов угроз программного обеспечения. Выявление наиболее эффективных средств и методов защиты программного обеспечения. Анализ их достоинств и недостатков. Описания особенностей лицензирования и патентования программного обеспечения.
курсовая работа [67,9 K], добавлен 29.05.2013Создание программного обеспечения в среде Visual Basic for Applications для проведения теста по работе полушарий мозга человека. Описание команд. Разработка интерфейса и тестирование программы. Листинг приветствия и задаваемых пользователю вопросов.
курсовая работа [387,1 K], добавлен 09.03.2014Процесс обучения ИТ-специалистов технологии MSF. Разработка информационной системы, моделирующей поведение "тестируемой программы" на стадии стабилизации для проведения практических занятий. Технология нефункционального тестирования, ее преподавание.
дипломная работа [2,3 M], добавлен 31.05.2016
