Алгоритмы для снятия логов и выполнения monkey
advertisement
Оглавление Введение. .............................................................................................................. 4 Основная часть .................................................................................................... 6 История развития тестирования программного обеспечения. .................... 6 Тестирование сегодня. ........................................................................................ 8 Функциональное тестирование. ................................................................... 10 Системные требования . ............................................................................. 10 Бизнес-требования ...................................................................................... 11 Пользовательские требования. .................................................................. 12 Бизнес правила. ........................................................................................... 14 Внешние интерфейсы.. ............................................................................... 14 Атрибуты качества: .................................................................................... 14 Функциональная декомпозиция. ............................................................... 15 Анализ требований ..................................................................................... 15 Планирование тестирования. ..................................................................... 15 Тестируемые особенности. ........................................................................ 16 Задачи тестирования (test tasks) ................................................................ 17 Матрица покрытия функциональных требований (traceability matrix) . 18 Разработка тестового сценария ................................................................. 18 Выполнение тестовых планов(test execution). ......................................... 19 Управление дефектами ............................................................................... 20 Виды тестирования по степени знания кода ............................................... 20 Тестирование методом белого ящика ......................................................... 20 Тестирование методом черного ящика ........................................................ 21 Тестирование методом серого ящика ..................................................... 21 Нагрузочное тестирование. ........................................................................... 21 Основные решения в области нагрузочного и стресс тестирования ........ 24 OpenSTA ...................................................................................................... 24 IBM Rational Performance Tester ................................................................ 25 2 JMeter............................................................................................................ 26 HP LoadRunner ............................................................................................ 27 SkillkPerformer ............................................................................................. 28 Siege .............................................................................................................. 29 Visual Studio Team System.......................................................................... 30 QTest ............................................................................................................. 31 Тестирование удобства пользования (usability testing) .............................. 31 Тестирование безопасности (security testing) .............................................. 34 Тестирование локализации ........................................................................... 35 Тестирование совместимости ....................................................................... 35 Тестирование стабильности .......................................................................... 35 РУЧНОЕ И АВТОМАТИЗИРОВАНОЕ ТЕСТИРОВАНИЕ ..................... 36 Ручное тестирование ................................................................................. 36 Автоматизированное тестирование .......................................................... 37 ВИДЫ ТЕСТИРОВАНИЯ ПО ВРЕМЕНИ ПРОВЕДЕНИЯ ТЕСТОВ ..... 39 ТЕСТИРОВАНИЕ МОБИЛЬНЫХ ПРИЛОЖЕНИЙ ................................. 40 Особенности мобильного тестирования ................................................... 40 Автоматизирование тестирование мобильных приложений ................. 43 Приложения для автоматизации мобильного тестирования .................. 45 ПРОЦЕСС ТЕСТИРОВАНИЯ МОБИЛЬНЫХ ПРИЛОЖЕНИЙ НА БАЗЕ ОС ANDROID ................................................................................................. 54 Конструкторско-технологическая часть ......................................................... 63 Экология и охрана труда ................................................................................. 76 Создание оптимальных условий трудовой деятельности программиста, оператора ЭВМ............................................................................................... 76 Влияние интеллектуального труда на здоровье. ........................................ 78 ЗАКЛЮЧЕНИЕ ................................................................................................. 78 Список литературы ........................................................................................... 79 3 Введение. Тестирование программного обеспечения является одной из важных стадий современной разработки ПО. На этом этапе проверяется соответствие разработанной системы заявленным требованиям и целям разработки. Без заключения отдела тестирования продукт не будет выпущен на рынок. Рис 1. Стоимость исправления ошибок на различных этапах разработки ПО (источник- IBM Systems Sciences Institute) Тестирование мобильных приложений имеет еще большее значение, так как рынок сейчас очень насыщен и если конечный пользователь увидит неполадки в вашей программе, он просто удалит ваше приложение и установит решение от конкурента. Тестирование бывает автоматизированным и ручным. Моя работа посвящена ручному тестированию, так как данный вид тестирования является основным. Невозможно автоматизировать тестирование всего функционала приложения, а во многих случаях автоматизация не будет эффективным решением в плане денежных затрат. Поскольку при тестирований на Android инженеру – тестировщику часто приходится прибегать к инструмента Android SDK, а в частности – android debug bridge (adb) , который имеет консольный интерфейс и поддерживает работу с консольными командами UNIX систем. Я решил разработать приложение, в котором благодаря простому графическому интерфейсу пользователь сможет получить доступ к самым распространенным командам adb, даже не знаю синтаксиса этого приложения, а так же увидеть результаты своей деятельности благодаря выводу на экран результатов выполнения этих команд. Это должно облегчить труд и увеличить производительность ручного тестирования, а так же его точность. 4 Объект исследования моей ВКР является процесс тестирования приложений на мобильных устройствах на платформе Android. Предмет исследования – оптимизация процесса тестирования приложений на мобильных устройствах на платформе Android. Целью работы является разработка системы информационного сопровождения процесса тестирования приложений на мобильных устройствах на платформе Android, которая позволит снизить время тестирования и порог вхождения для начинающих специалистов в этой области, еще слабо знакомых с функционалом Android sdk, а так же повысить качество и точность тестирования, что в целом повысит качество итогового продукта. Задания работы: - Изучить процесс тестирования - Изучить особенности процесса тестирования на мобильных устройствах - Выявить элементы процесса прохождения тестовых сценариев, которые следует включить в функционал разрабатываемого приложения. - Разработать приложение. - Проверить работоспособность приложения на конкретном примере. Теоретической основой для написания ВКР послужили работы отечественных и зарубежных авторов в области тестирования программного обеспечения а так же материала коммерческой и технической направленности, размещенные на сайтах производителей рассматриваемого в дипломной работе программного обеспечения. 5 Основная часть История развития тестирования программного обеспечения. Тестирование, как таковое , начало свое развитие еще в глубокой древности. Издревле люди проводили испытания своих способностей, знаний, навыков. Подобные состязания и испытания можно считать прародителями современных тестов, ведь им , по сути, так же были присуще все атрибуты современных процессов тестирования. Затем более широкое распространение тестирование получило в средних веках, когда начинали свою работу рабочие гильдии и цеха, выпускающие какую-либо продукцию, например, подковы в кузницах и мастерских. Эта продукция после создания проходила контроль у мастеров гильдии, которые обеспечивали постоянный контроль качества данной продукции. Такой порядок вещей просуществовал практически до 19 века, когда произошла индустриальная революция. Индустриальная революция начала менять представление людей о тестировании. Ремесленника из гильдии на заменил рабочий на мануфактуре. Следуя этим изменениям, необходимо было и обновить систему контроля качества. Это и сделал Фредерик Уинслоу Тейлор, ставший основоположником научной организации труда . Он первым начал применять на производстве систему дифференциальной оплаты труда. Тейлор полагал, что любой квалифицированный рабочий может быть проанализирован так, чтобы его можно было передать в процессе обучению любому другому человеку, что шло в разрез с тогдашней структурой правсоюза, которая сохраняла подобие кастового порядка. Так же Тейлор считал, что власть на предприятии не должна единолично принадлежать владельцам, а управлять на местах должны специально обученные специалисты –нынешнее менеджеры. Его идею подхватил Уолтер Шухарт (1891-1967) - всемирно известный ученый и консультант по управлению качеством. Он опубликовал книги «Экономическое управление качеством промышленной продукции» и «Статистический метод с точки зрения контроля качества» . Шухарт ввел в 6 обиход понятие о «контрольных картах» - графическое средство представление и принятия решений касательно стабильности и устойчивости процесса производства. Так же, Шухарт разработал процесс принятия решений, известный как PDCA(pian-do-check-act – планирования- действие – проверка – корректировка) . Это элеменентарный алгоритм, который руководит действиями руководителя по управлению процессом производства . Свое дальнейшие развитие этот алгоритм получил уже после второй мировой, когда генерал Дуглас МакАртур, работающий в Японии после ее поражения в войне совмести с Эдвардом Демингом над модернизацией японского производства. В процессе этого производства они искали способы улучшить качество труда на японских мануфактурах и фабриках , используя идею, что важнее фокусироваться на качестве продукта чем на итоговой цене продукта. Для достижения этой цели они работали на улучшенной версии PDSA модели, приспособленной для автоматизированной индустрии. В результате этой работы, покупатели стали отдавать предпочтение товарам из Японии, нежели из США ввиду их лучшего качества Деминг сильно лоббировал дальнейшую разработку PDSA в начале ее существования. Важно понимать, что Деминг поднял конфликтный вопрос между темпами производства и качеством производства. Вместо того, чтобы бездумно наращивать темпы производства, Деминг предлагал в своим методах управления качеством обращать большее внимание на структурирования и дальнейшую экономию времени путем анализа документации во всех аспектах процесса разработки. Вкратце, PDSA разрабатывался для обеспечения интегративной и инкрементной системы разработки, которые послужили основой той системы разработки, которой мы пользуемся сейчас. Первый из документированных примеров такой разработки был представлен командой из IBM. Этот проект состоял из более чем миллиона строк кода. Это была система контроля и управления подводной лодкой США и проект требовал 7 точности и очень сжатых сроков реализации. Приходилось уделять больше внимания пожеланиям заказчика, чем ведению надлежащей документации. Команда успешно подошла к заданным срокам и сам проект был успешен. Этот проект был первым, когда при при меньшей итерации и пониженным документооборотом был достигнут положительный результат. Если конечно качество управления было бы недостаточно хорошим, мы бы могли сказать, что процесс разработки не был бы завершен в должные сроки. Таким образом, сейчас существуют различные методологии разработки. Каскадная разработка подразумевает ведение документации и трату большего времени для того, чтобы добиться максимально хорошего кода, но при экстремальной разработке тратится меньшее время на выполнения более коротких итераций ,которые могут быть оправданы при специфических условиях разработки, таких как проектирование систем управление подводным лодками. Каждая из методологий имеет свои плюсы и минусы, по этому наиболее важно понимать каждую идею , которая может вести разработку как к успеху так и к провалу. Тестирование сегодня. Рис 2. Элементы контроля качества 8 Сегодня тестирование включает в себя большой комплекс процедур по обеспечению контроля качества над разрабатываемым программным обеспечением. Этот комплекс может варьироваться в зависимости от сложно разрабатываемого ПО, так и от конкретного объекта тестирования. В общем, контроль качества осуществляется путем проведения следующих мероприятий: 1. 2. 3. 4. 5. 6. 7. 8. Создания тестовых сценариев Функционального тестирования Тестирования безопасности и устойчивости Тестирования соответствий Тестирования масштабируемости Тестирования производительности Регрессионное тестирование Обновление тестовых баз 9 Функциональное тестирование. Рис 3. Элементы функционального тестрования Это вид тестирования является одним из основных. Его задача состоит в устранении различий в поведении программы между завяленными требованиями и фактическим результатом. В процессе функционального тестирования выявляются основные ошибки в реализации программы, которые влияют на ее качество. Процесс функционального тестирования начинается с ознакомления с системными требованиями, разработанными для этого приложения. Системные требования к разрабатываемому программному обеспечению - это строительные блоки, из которых разработчик воздвигает свою систему. Системные требования делятся на функциональные и дополнительные. Функциональные системные требования определяют то, как пользователь выполняет свои функции. Например, в систему необходимо ввести систему поиска устройства по данным gps – это требование будет является функциональным. Нефункциональными требования, как правило называют требования к качеству продукции . 10 Системные требования можно классифицировать по различным параметрам, таким как требования по уровням: Рис 4. Классификация системных требований Бизнес-требования – описывают то, как разрабатываемую систему видит компания-разработчик или заказчик. Эти требования так же содержат тот предполагаемый источник прибыли или выгоды, которые рассчитывают получить заинтересованные стороны. Они могут быть описаны в виде документов, кейсов либо в виденье проекта или в перечне функционала. Бизнес требования описывают виденья главы проекта или заинтересованных лиц на одном комплекте документации. Программное обеспечение не может быть написано исходя лишь из этой высокоуровневой информации. Бизнес-требования в первую очередь содержат информацию о: 1. Целях разрабатываемого проекта 2. Задачах разрабатываемого проекта 11 3. Области покрытия проекта 4. Ожидаемом результате разработки проекта 5. Приоритете и ожидаемых сроках завершения проекта 6. Целесообразности проекта, зачем нужно разрабатывать этот проект, как он будет приносить прибыл 7. Подразделениях и отделах компании, участвующие в разработке проекта. Пользовательские требования описывают поведение системы со стороны пользователя, какие действия может использовать пользователь, чтобы взаимодействовать с системой. Пользовательские требования должны быть документированы в руководстве пользователя, написанном на естественном языке. В разработке и дизайне программного обеспечения очень важно понимать, что хочет пользователь от взаимодействия с данной системой. Это вызвано тем, что пользователь часто бывает не в состоянии полностью взаимодействовать с системой из-за непродуманного интерфейса, который не обеспечивает должной функциональности или выдает пользователю неполную или неточную информацию о процессах и состоянии системы. Как правило, такие требования описываются с помощью пользовательских сценариев (user cases) . Пользовательские требования подчинены бизнес требованиям, а значит каждое требования должно быть связанное минимум с одним бизнес требованием. Задача разработать такой интерфейс лежит на отделе аналитике и дизайна. Бизнес-аналитики тщательно анализируют потребности пользователей и строит документированный набор требований к качеству продукта, который удовлетворял бы запросам пользователей. Пример пользовательского требования: User case: Включить компьютер. Актеры: Пользователь Частота: Каждый день Приоритет: 1 (высший) 12 Описание: пользователь включает выключенный ранее компьютер. Предусловия: компьютер исправен и доступен пользователю, на компьютере задан пароль для учетной записи пользователя Результат: пользователь видит рабочий стол своей операционной системы. Поток нормальный. Пользователь нажимает кнопку POWER на системном блоке Загружается BIOS BIOS инициализирует компоненты системы Загружается OS Система предлагает ввести пользователю пароль для доступа к его учетной записи 6. Пользователь вводит пароль 7. Пользователь попадает на рабочий столь Сценарий завершен 1. 2. 3. 4. 5. Сценарий 1а. 1. А) Пользователь нажимает кнопку POWER на системном блоке 2. А) BIOS не загружается. Конец сценария Сценарий 1а 2 3. Б)Компьютер не включен в сеть 4. Б)Пользователь включает компьютер 5. Б)Назад к шагу 1 Сценарий 1а 3 2. В) Компьютер включен в сеть 3. В) Нужно проверить исправности материнской платы Вторая группа требований – нефункциональные требования. Эти требования содержат требования к качеству работы системы, такие как работоспособность, масштабируемость, ремонтопригодность и удобство . Они так же важны, как и функциональные, так как они определяют, будет ли комфортно пользователю взаимодействовать с конечной системой. Невыполнение любого из этих пунктов может повлечь несоответствие системы с заявленными параметрами в плане использования и 13 функционирования. Нефункциональные требования определяют качество и стабильность к системе и обычно не меняются от релиза к релизу и остаются постоянными на весь период разработки. Нефункциональные требования встречаются на всех трех уровнях разработки. Основное «место обитания» - программный уровень. Это такой уровень, на котором определяется качество программного обеспечения – уровень работы программы. Так же нефункциональные требования существуют на уровне команд разработок – важный для реализации таких требований уровень, на котором определяются то , как будут функционировать между собой команды разработчиков. Эти связи способствуют более гладкому и гибкому процессу разработки, который позволит избежать множества ошибок и тем самым повысить качество системы. Уровень документации так же может содержать в себе нефункциональные требования. Выделяют следующие виды нефункциональных требований: Бизнес правила. Включают в себя какие-либо правила, по которым система должна быть описана так и никак иначе. Может содержать какиелибо правила и пожелания заказчика, отсылки на законодательство. Внешние интерфейсы. Включают в себя макеты интерфейсов пользователя, способы и правила взаимодействия с другими системами и сторонними приложениями. Атрибуты качества. К атрибутам качества обычно относят такие характеристики как: 1. легкость и простота использования 2. производительность 3. удобство эксплуатации 4. удобство технического обслуживания 5. надежность и устойчивость к сбоям 6. взаимодействие системы с пользователем 7. расширяемость и гибкость. Для процесса тестирования важно в первую очередь ознакомится с функциональными требованиями и пользовательскими сценариями. 14 Именно с ними в первую очередь отожествляется то, как будет выглядеть и функционировать конечный продукт. Функциональная декомпозиция. Функциональная декомпозиция применяется, когда необходимо разбить весь массив функционала приложения на более маленькие и детализированные части, над которыми будет удобнее проводить тестирование и строить специфические тест планы. Анализ требований Это процесс систематизации , анализа и выявления противоречий в написанных для разрабатываемого программного обеспечения требований. К таковому процессу тестирования он отношения не имеет и применяется аналитиками на стадии разработки и дизайна концепции приложения. Планирование тестирования. Планирование тестирования это уже непосредственная задача отдела тестирования. Основная ее задача сводится к созданию тест планов чтобы в дальнейшим покрыть с помощью этих планов требования тестовыми сценариями. Тест план – это документ, который детализирует цели, целевой рынок, состав команды бета-тестирования и процедуру проведения тестирования для программного продукта. Существует стандарт IEEE 829 для написания тест планов. Согласно нему, тест план состоит из: - Предметов тестирования. Это вещи, которые необходимо протестировать в рамках данного тест плана. Как правило, содержит: - Требования спецификации - Дизайн и системные требования - Пользовательские сценарии - Руководства по эксплуатации и установки. 15 В тест плане определяются критические элементы, на которые необходимо обращать внимание перед началом тестирования. Так же, тест план может быть рассчитан на разные уровни программы- либо покрывать весь функционал, либо какую-либо одну его часть, блок или модуль. Тестируемые особенности. Это список тех элементов программы, которые должны быть проверены с пользовательского сценария поведения. Это техническое описание функций программного обеспечения но через призму пользовательского поведения. Рекомендуется использовать данный подход для тестирования каждой особенности программы, с которой может взаимодействовать пользователь. Для каждой функции полезно будет установить приоритет (достаточно самый простой – высокий, средний, низкий).Это будет очень полезным при самом процессе тестирования и обработке неисправностей. Подход с составлению тест-плана. Это общая стратегия, которая использует для построения плана тестирования. Готовый тест план должен отвечать на следующие вопросы: - Существуют ли специальные инструменты, которые будут задействованы в процессе тестирования и что это за инструменты - Требуют ли они специальной подготовки для их использования - Какие метрики необходимо собрать по ходу выполнения тест плана - Какого порядка должны быть собранные метрики? - На каких конфигурациях должно быть проведено тестирование - Как должно быть построено регрессионное тестирование? - Будет ли регрессионное тестирования зависеть от тяжести найденных неполадок - Какие элементы требований или дизайна не будут включенные в тестирование - Существуют ли специальные требования для проведения тестирования 16 - Существую ли какие-либо ограничения для этого тест плана (время, ресурсы) Критерии прохождения тест плана: Когда тест план считается пройденным? Критерии прохождения должны быть подробно и четко описаны, чтобы не возникало двоякости в понимании того, когда тест план можно считать пройденным. - На уровне модульного тестирования все тестовые сценарии должны быть пройдены и указан процент допустимых дефектов - На уровне главного тестового плана должны быть пройдены все планы более низкого уровня и указан процент допустимых дефектов Критерии приостановления выполнения тестового плана: Порой продолжать прохождения тест плана является не целесообразным , намример, когда количество найденных багов становится через чур большим и они блокируют возможность прохождения остальных тестов. Так же, нужно детализировать что будет получено на выходе после прохождения тест плана: - техническое описание тестов - техническое описание тестовых сценариев - сопроводительные отчеты - зафиксированные баги Задачи тестирования (test tasks) Эти задачи должны быть определены для каждого вида и результата прохождения тест плана. Если процесс тестирования является многоэтапным, и этот тест план охватывает только часть функционала, то цели должны быть прописаны только для этого функционала. 17 Матрица покрытия функциональных требований (traceability matrix) Таблица 1. Пример матрицы функциональных требований Матрица покрытия функциональных требований это документ, который обычно содержит перечень отношений, которые определены в проекте. Он содержит список особенностей, который подлежат разработке на той или иной итерации продукта. Она используется для проверки текущего статуса разработки программного продукта. Эта матрица применяется на любых стадиях разработки, вплоть до оставления пользовательских сценариев. Она служит для контроля целостности продукта, по ней легко отследить, что уже сделано и что предстоит реализовать в дальнейшим. Разработка тестового сценария Тестовые сценарии состоят из сущностей, которые описывают входные условия, действия, события а так же ожидаемое поведение программы для того , чтобы определить, корректно ли работает тестируемая особенность или приложение. Чтобы это выяснить , как правило, создать два тестовых 18 сценария – положительный и отрицательный. Созданные тестовые сценарии должны содержать четкую последовательность шагов, по которым тестировщик может прийти к тому или иному результату. Пример тестового сценария. Test case 1. (идентификационный номер тестового сценария, что затем его можно было легко найти и использовать в других тестовых планах) Author: Anikin Anton Title: Включение компьютера Preconditions: Компьютер исправен и подключен к сети. ( состояние системы на момент начала прохождения тестового сценария. Обычно этот пункт опускают, если система находится в состоянии «по умолчанию» , но формально начальное состояние все же следует описывать). Таблица 2. Пример тестового сценария Шаги Нажать кнопку POWER на системном блоке Результат Включение компьютера, инициализация BIOS Загрузка компонентов Загрузка ОС Появилось окно ввода пароля Пароль принят Выбрать учетную запись: Admin Ввести пароль учетной записи: Qwerty12 -конец тестового сценария- Шаги тестового сценария должны быть максимально детализированы, чтобы у инженера не возникло проблем с толкованием тех или иных шагов. Например, если на шаге «выбрать учетную запись» не указать, какую именно запись следует выбрать, инженер может выбрать запись «гость» или другую (если она есть) и , соответственно, следующий шаг(ввод пароля) будет возможно содержать себе дефект, так как условия для его введения могут быть невыполненными. Выполнение тестовых планов(test execution). Когда тест план составлен и весь базовый функционал покрыт тестами, можно приступать к непосредственно выполнению тестовых сценариев. 19 При выполнение тестовых сценариев, каждый шаг непосредственно отмечается пройден он или нет( в этом случае этот шаг автоматически помечается, как шаг, содержащий дефект и тестеру предлагается подробно описать данный дефект) Если все шаги отмечены как пройденные, то и сам тестовый сценарий автоматически считается пройденным и тестер может приступать к выполнению следующего сценария. Если какой-либо шаг невозможно выполнить из-за того, что его функционал заблокирован каким-либо ранее найденным дефектом, то такой шаг следует помечать как заблокированный. Управление дефектами После завершения процесса тестирования необходимо составить отчет, в котором описывают результаты тестирования, найденные дефекты. Виды тестирования по степени знания кода В Процессе тестирования можно выделить 3 основные стратегии тестирования: тестирование черного ящика, серого ящика и белого ящика. Под тестированием методом белого ящика традиционно понимают использование исходного когда приложения в качестве основы для его отладки. Обычно такой вид тестирования выполняется непосредственно программистом, так как он подразумевает хорошее знание исходного кода. Такой вид тестирования может включать в себя отслеживание путей выполнения программы путем заранее известных входных значений на этих путях. Тестирование методом белого ящика не поможет определить несоответствие работы программы с заявленными требованиями, но оно может помочь выявить некоторые ошибки проектирования в исходном коде, такие как проблема управления потоком данных(бесконечные циклы) или в самих данных (использование неопределенной переменой). Статический анализ кода (с помощью инструментариев) так же поможет найти проблемы в программе но не сможет помочь разработчику/тестеру код в той степени, в которой это делает тестирование белого ящика. 20 Как правило, тестирование белого ящика связано с тестированием компонентов системы на предмет полного покрытия всех требований кодом и что эти компоненты находятся в исправном состоянии. Но такие тесты не могу быть полными, так как тестовые примеры в таком виде тестирования являются искусственными и не могут выявить всех ошибок поведения программы в реальной среде. Тестирование методом черного ящика применяется, когда тестер не имеет представления о внутреннем составе программы. Он может подавать какие-либо данные в качестве входных условий в тестируемое программное обеспечение и по полученным значениям определять, соответствует ли это обеспечение заявленным требованиям. Основными стратегиями тестирования черного ящика являются: 1. Разбиение на классы эквивалентности (используются, когда необходимо проверить множество входных условий, которые можно разбить на некоторые группы по формальным признаками и затем протестировать эти группы, взяв из каждой из них по 1-2 значения) 2. Анализ граничных значений ( проверка работоспособности программы при работе с данными, выходящими за пределы допустимых для ввода значений или находящихся близко к этому рубежу) 3. Проверка причинно-следственных связей ( проверка корректной работы пользовательских сценариев) 4. Свободный поиск ошибок ( прохождение нетипичных сценариев которые могут выявить ошибки в функционале работы программы, как правило, не очень высокого приоритета) Тестирование методом серого ящика объединяет в себе методы тестирования методом «черного» и «белого» ящика. По методу черного ящика обычно осуществляется ввод данных, например – запуска программы внутри отладчика. Нагрузочное тестирование. Вид тестирования, в котором измеряется в первую очередь производительность и время отклика разрабатываемой системы в 21 различных режимах работы в соответствии с заявленными требованиями. Производится посредством приближение работы приложения к его максимально допустимому. Оно происходит в контролируемых лабораторных условиях, для более точного снятия показателей. Обычно исследуют отклик системы и ее производительность падают на пиковых нагрузках, которая сильно превышает заявленную пропускную мощность системы. Такой вид тестирования называется стресстестированием. Основная цель нагрузочного тестирования состоит в создании запланированной нагрузки на систему с помощью технических или аппаратных и средств и последующим наблюдении за состоянием системы в этот момент. Основные принципы нагрузочного тестирования. 1. Уникальность запросов –нужно стараться генерировать как можно более разные и уникальные запросы к системе, так как конечный пользователь всегда будет так или иначе использовать недокументированные или нелогичные формы запросов к системе 2. Время ответа системы – измерение того, как ведет себя система под воздействием повышенных нагрузок. Из этого можно сделать вывод, что если мы имеем достаточное количество испытаний, то по ним можно определить, будет ли снижаться время доступа к системе вместе с ростом запросов к ней. 3. Зависимость времени ответа системы от ее сложности - влияет ли количество узлов и общая сложность системы на увеличение время ответа системы вместе с повышением количества и интенсивности запросов к ней. 4. Разброс времени ответа системы на запрос – некоторые команды программы при увеличении времени ответа системы перестают удовлетворять требованиям к проектируемой системе. Существуют различные инструменты для проведения нагрузочного и стресс тестирования. Но все эти инструменты работают с приложением как с совокупностью узлов, на которые следует оказывать давление. Всего выделяют следующие виды узлов, подверженные нагрузочному тестированию: 22 - база данных - приложение - сеть - балансировка нагрузки - клиентская часть приложения. 23 Основные решения в области нагрузочного и стресс тестирования OpenSTA Рис 5. Пример интерфейса программы Распространяется по свободной лицензии. Базируется на распределенной архитектуре приложений(CORBA) . Основное предназначение – тестирование веб-серверов. В настоящее время работает только на Windows-операционных системах. Тестирование осуществляется посредством скриптов, записанных на языке SCL, простом языке, который обеспечивает поддержку пользовательских функций, областей переменных и случайных , а так же последовательных списков команд. Разработка и поддержка данного приложения прекращена 24 IBM Rational Performance Tester Рис 6. Пример интерфейса программы Данный пакет предназначен для нагрузочного и автоматизированного тестирования веб-приложений и серверов. Он позволяет пользователь писать тесты, которые могли бы имитировать обмен данными между пользователями и серверной частью тестируемого приложения. Во время тестирования эти операции многократно повторяются для создания дополнительной нагрузки на сервер. Программа собирает данные, которые позволяют понять, насколько изменилось время ответа приложения после получение дополнительной нагрузки. Создание теста производится с помощью механизма записи, который фиксирует все операции, происходящие между клиентской и серверной частью разрабатываемой системы. Результат выводится в виде дерева, где каждая ветвь представляет с собой какой-либо клиентский запрос к серверной части. Чтобы редактировать таким образом записанный скрипт, пользователь изменяет непосредственно эти ветви дерева, вставляю в них дополнительные операторы, триггеры и счетчики проверок ответов. Так же можно использовать модуль JAVA для более точной настройки. 25 Программа поддерживает процесс корреляции данных, который обеспечивает непрерывность между тестовыми взаимодействиями с разрабатываемым приложением. JMeter Рис 7. Пример интерфейса программы Система нагрузочного тестирования, разработанная компанией Apache, приспособленная к анализу и измерению стабильности функционирования различных сервисов, в частности, веб-приложений. Jmeter может быть использован как часть тестового окружения для JDBC,FTP,LDAP и многих других стандартов. Он поддерживает широкие возможности для параметризации, валидации и составление отчетов, а его работа основана на поддержке плагинов, в том числе и неофициальных. 26 HP LoadRunner Утилита для автоматизированного нагрузочного тестирования. Помимо приложений, может тестировать сайты различных уровней сложности. Работает за счет подключения виртуальных пользователей, которые руководствуются созданными скриптами. Приложение состоит из следующих модулей: - Virtual user generation – разработка скриптов и управление виртуальными пользователям - Load Generator – генерация нагрузки - Controller – разработка скриптов - Analysis – анализ результатов тестирования Рис 7. Пример интерфейса программы 27 SkillkPerformer Рис 8. Пример интерфейса программы Продукт компании Borland для автоматизации выполнения нагрузочного тестирования для веб-систем различного уровня сложности. Сейчас выкуплен компанией Micro Focus. Отличается простотой и высокой мощностью, что позволяет использовать его для тестирований корпоративных приложений самого разного спектра и разного уровня массштабируемости. Основными преимуществами считается сниженное потребление ресурсов на обнаружение дефектов путем начала тестирования еще до начала основного цикла разработки, до получения конечных версий клиентского приложения. Стандартный цикл тестирования в SilkPerformer строится следующим образом: 1. Настраиваются новые параметры для тестируемого приложения 28 2. Создается тестовый сценарий ( обычно за счет встроенной функции записи) 3. Созданный тестовый скрипт обрабатывается и для текущей сессии 4. Устанавливается модель рабочей нагрузки 5. Запуск теста 6. Анализ результатов теста на стороне клиента 7. Создание и анализ дальнейшей отчетности Siege Рис 9. Пример интерфейса программы Утилита, специализирующаяся на тестировании веб-серверов. Siege имитирует подключение к серверу большого числа пользователей. Имеет три основных режима работы – 1. Режим регрессионного тестирования – программа считывает ссылки из файла конфигурации и по очереди проходит по ним 2. Режим интернета – программа в случайном порядке проходит по ссылкам в конфигурационном файле. 3. Режим грубой силы – программа обращается на один адрес Приложение является бесплатным и поддерживает почти все современные ОС 29 Visual Studio Team System Рис 10. Пример интерфейса программы Visual Studio Team System – пакет инструментов, которые упрощают совместную работу над проектами, обеспечивают ее тестовым окружением и средствами для построения отчетов. В состав этого пакета входит Team Test Load Agent, который отвечает за проведения нагрузочного тестирования в веб- или windows приложениях. Продукт тесно интегрирован с Team Fundation Server, что позволяет проводит такого рода тестирование на всем жизненном пути программы, однако лицензируется отдельно от TFS. 30 QTest Рис 11. Пример интерфейса программы QTest поддерживает не только нагрузочные тесты, но и полный цикл ручного тестирования. Так же обладает простым и интуитивным интерфейсом, который позволяет гибко подготовить проект к тестированию. Так же, QTest располагает возможностью интеграции с большинством решений в области отслеживания дефектов, что позволяет легко синхронизировать свою деятельность между платформами. Тестирование удобства пользования (usability testing) 31 Рис 12. Работа с фокус - группой Данный вид тестирования относится к оценке качества разработанной системы с точки зрения поведения пользователя. Как правило, участники такого тестирования (как правило, это небольшая фокус – группа) выполняют типичные задачи, используя разработанное приложения а наблюдатели собирают данные и на их основе делают выводы о удобстве использования приложения. Собираемые данные: 1. Легкость обучения – как быстро человек сможет освоить новый для себя интерфейс 2. Эффективность обучения – какова продуктивность человека после обучения 3. Усвояемость обучения – легко ли пользователь запоминает то, чему он научился 4. Ошибки – как много пользователь допускает ошибок после прохождения обучения 5. Удовлетворенность - складывается ли у пользователя положительное впечатление о работе с системой Задача данного вида тестирования – измерить все эти параметры Сам процесс тестирования может включать в себя следующие этапы: 1. Исследовательское – проведение тестирования интерфейса на предмет того, позволяет ли он с достаточной эффективностью использовать программу. 2. Оценочное тестирование – производится после большей детализации интерфейса. На данном этапе измеряемыми метриками уже являются такие показатели как количество обращений к помощи относительно количества совершенных операций, количество допущенных ошибок и т д. 32 3. Валидационное тестирование – на этом этапе производится анализ соответствия полученного интерфейса с системными стандартами, регламентирующими вопросы удобства интерфейса. Обычно оценка происходит с помощью эвристических критериев удобства. Примером таких критериев могут является критерии, выделенные Якобом Нильсеном: - Наблюдаемость состояния системы – пользователь всегда может получить информации о текущем состоянии системы - Соотнесение с реальными миром – терминология , использованная в интерфейсе должна быть понятна конечному пользователю - Пользовательское управление и свобода действий – пользователь должен иметь возможность в случае ошибки вернуть систему в исходное положение - Целостность – интерфейс должен использовать одинаковые обозначения и лексику для обозначения одних и тех же частей системы. - Помощь пользователям в распознавании и устранении ошибок – сообщения об ошибках должны быть понятные пользователю и передавать суть возникшей проблемы. - Предотвращение ошибок – дизайн интерфейса должен быть продуманным, чтобы у пользователя не возникала возможность допустить ошибку или совершить ложное нажатие - Гибкость использования – интерфейс должен иметь возможность кастомизации под нужды конкретного пользователя, а так же содержать горячие клавиши. - Эстетический и минимально необходимый дизайн – приложение не должно содержать лишних и отвлекающих пользователя от работы элементов, окна не должны быть назойливыми или рассеивать внимание. - Документация – интерфейс должен содержать файл помощи, который поможет разобраться и освоить весь функционал пользователю. 33 Тестирование безопасности (security testing) Рис 13.Тестирование безопасности Главная задача данного вида тестирования состоит в выявлении недостатков безопасности разрабатываемого приложения и поддержки должного уровня безопасности как предполагается в требованиях. Приложение считается безопасным, если удовлетворяет следующим принципам безопасности: 1. Конфиденциальность – сокрытие ресурсов и информации от некоторой категории пользователей, например, для не авторизированных пользователей. 2. Целостность – включает в себя доверие (данные могут быть изменены только доверенной группой пользователей) и повреждение и восстановление ( данные могут быть восстановлены в случае их повреждения) 3. Доступность - каким группам пользователей какие виды ресурсов могут быть доступны Существующие виды уязвимостей 34 - XSS(Cross-Site Scripting) – актуален для веб приложений. На тестируемом сайте выполняются вредоносные скрипты, которые атакуют клиента. - XSRF/CSRF - такой вид уязвимости использует брешь в HTTP протоколе, позволяющий установить на доверенном сайте ссылку на вредоносный сайт, при переходе на который активируется скрипт - Code injections – добавление вредоносного кода к исполняемому коду программы, в следвии чего становится возможным запуск кода с целью получение доступа к защищенным ресурсам - Server-Side Includes injection – использует вставку серверных команд в HTML код или запускает их напрямую с сервера - Authorization Bypass – получение доступа к учетной записи пользователя Тестирование локализации Это процесс тестирование локализованной версии разрабатываемого продукта. Проверяется корректность перевода пользовательского интерфейса и сопутствующей документации. Цель такого тестирования – убедиться в том, что данное приложение поддерживает мультиязычный интерфейс и может, по необходимости, легко переключатся между языками. Тестирование совместимости Проверка работоспособности системы в каком-либо окружении, таком как аппаратная платформа, сетевая конфигурация, операционная система, базы данных, переферия и т.п Тестирование стабильности Данный вид тестирования проверят работу системы на длительном промежутке времени с средним уровнем нагрузки. Основной задачей такого тестирования является поиск утечек памяти, следов увелечения потребления ресурсов. 35 РУЧНОЕ И АВТОМАТИЗИРОВАНОЕ ТЕСТИРОВАНИЕ Ручное тестирование Рис 14. Ручное тестирование Ручное тестирование – это процесс поиска дефектов в программе, когда тестировщик выступает в роли пользователя и проверяет все функции приложения на предмет их работоспособности. Ручное тестирования является базовым типом тестирования, так как автоматизированное тестирование не в состоянии покрыть весь функционал программы. Основной целью ручного тестирования является необходимость удостоверится в том, что тестируемое приложение не содержит в себе ошибок и функционирует в соответствии с документированными требованиями. Ручное тестирование применяют во время функционального и не функционального тестирования, такого как тестирования совместимости, интерфейса, удобства , локализации. При тестировании крупных проектов используется методология, которая позволяет выявить максимальное количество дефектов. Такая методология ,как правило, включает в себя: 1. 2. 3. 4. Выбор методологии тестирования Составление тест-планов и тестовых сценариев Ручное прохождение созданных тестов Передача результатов тестов разработчикам 36 Автоматизированное тестирование Рис 15. Автоматизирование тестирование Процесс тестирования подразумевает под собой процесс, когда тестовые сценарии прогоняются автоматически по заранее заданному сценарию и без участия тестера. Сейчас существуют два основных подхода к автоматизированному тестированию: тестирование на уровне кода и тестирования пользовательского интерфейса. К тестированию на уровне кода относят модульное тестирование, при котором разрабатываемое приложение проверяется по частям, часто по ходу ее разработки. 37 Наиболее распространенной же формой автоматизированного тестирования является именно тестирование приложений через графический интерфейс. По сути, это та же имитация действий пользователя что и при ручном тестировании, только выполнение происходит автоматически. На сей день существует следующие техники обеспечения такого тестирования: - Запись и воспроизведение. Данные утилиты записывают действия тестировщика во время ручного тестирования и затем воспроизводят их в заданные моменты. Такие тесты помогают оптимизировать время тестировщика, убрав из процесса монотонные действия. Но если тестируемое претерпит изменения – тесты придется переписывать с нуля. - Сценарии. Является формой программирования на специализированных скриптовых языках. Обычно написанием таких скриптов занимаются сам программисты. Скрипты хорошо подходят для тестирования пользовательского интерфейса, но так же имеют недостаток, связанный с их устареванием вместе с изменением внутри самой программы. - Data-driven testing. Вид скриптов, которые оперирует непосредственно потоками данных и сами тестовые скрипты верифицируются с помощью этих данных. -Метод координат. В этом методе каждый элемент графического интерфейса ищется по координатам на экране. Минусом является большая зависимость от настроек платформы (разрешение, шрифт и тп) и невозможность отслеживать состояние объекта. -Распознавание объектов. В основе этого метода лежит поиск элементов пользовательского интерфейса с использованием распознавание и взаимодействие с заданными образцами. Минусы такие же, как и в методе координат. Основной проблемой автоматизированного тестирования является трудоемкость, которая не всегда оправдывается выигрышем в времени. Чаще всего автоматизированное тестирование используется при 38 тестировании локализаций и а так же при тестировании интерфейса с точки зрения соответствия его требован ВИДЫ ТЕСТИРОВАНИЯ ПО ВРЕМЕНИ ПРОВЕДЕНИЯ ТЕСТОВ 1. Альфа тестирование. Тестирование, проводимое на самой ранней стадии разработки, как правило для показа готового функционала клиентам. Как правило состоит в систематическом использовании всех функций программы. 2. Приемочное тестирование. Этот вид тестирования применятся для тестирования модулей программы на предмет критических дефектов, которые блокируют сдачу или релиз текущей версии продукта. Если дефектов обнаружено не было, то такой релиз можно считать допущенным до распространения. 3. Тестирование нового функционала. Вид приемочного тестирования, в котором все внимание уделяется новому функционалу приложения. 4. Регрессионное тестирование. Вид тестирования, направленный на поиск ошибок в уже проверенных частях кода. Такие ошибки могу возникнуть с выходом новых версий программы или с фиксом старых багов. Как правило, регрессионное тестирование состоит из повторного прогона полного приемочного тест плана. Когда проводить регрессионное тестирование каждая команда тестеров решает сама, обычно его проводят раз в несколько релизов, чтобы убедиться, не «отвалился» ли кусок старого функционала после изменений, постигших программу за последние итерации. Так же регрессию желательно проводить после рефакторинга кода. 5. Бета тестирование. Проводится с целью выявление максимального количества ошибок и для проверки функциональности продукта в максимально приближенных к реальности условиях. Как правило, бета тестирование подразумевает привлечение штата добровольцев из числа будущих пользователей продукта. Так же бета-тестирование может быть использовано в качестве рекламы и продвижения продукта на рынок. 39 ТЕСТИРОВАНИЕ МОБИЛЬНЫХ ПРИЛОЖЕНИЙ Рис 16. Тестирование мобильных приложений Тестирование мобильных приложений проводится по тем же принципам, что и тестирование десктопных систем. Оно так же состоит из функционального тестирования, нагрузочного, тестирования производительности и стабильности и прерывания, простоты использования. Однако, в тестировании мобильных приложений есть много нюансов, о которых мы поговорим ниже. Особенности мобильного тестирования Для пользователя любое мобильное приложение должно быть простым и интуитивно понятным, иначе такой пользователь выберет другие приложение, так как конкуренция на этом рынке очень высока. В меньшей степени это можно отнести к корпоративному сегменту, хотя и тут эргономика и стабильность работы имеют решающие значение. Таким 40 образом, на ряду с функциональности крайне важно значение для успеха продукта имеют все виды юзабилити-тестирования. С технической точки зрения, важными отличиям является специфичность мобильных платформ и широкий спектр устройств, которые необходимо поддерживать. Частые обновления операционной системы вынуждают так же часто обновлять само приложение, ведь зачастую после обновления системы меняется не только часть функционала но и дизайн ОС и разработчики должны иметь возможность выпускать своевременные обновления для своего детища. Поскольку сейчас большинство операционных систем поддерживают функцию обновления через встроенный магазин приложений, проблем с дистрибьюцией таких обновлений вроде бы нет, но с другой стороны, встает вопрос о совместимости новой версии с предыдущей, ведь пользователю будет неудобно сначала удалять старую версию, теряя все свои настройки, и, затем, устанавливая обновленную версию приложения. Так же, важным является поддержка мультиязычности. Она позволяет сравнительно легко и дешево значительно увеличить охват целевой аудитории программы. Однако, важно, чтобы продукт был локализован корректно, не содержал в себе «машинного» перевода. Некачественный перевод может сыграть с разработчиками еще более злую шутку, чем его отсутствие. Удобство пользования. Тестирование и оптимизация интерфейса является одной из важнейших частей тестирования мобильного программного обеспечения, так как в условиях большой конкуренции именно удобный дизайн и безотказность во время работы может дать решающие преимущество над конкурентами. Нагрузочное тестирование. Наблюдение за потребление системных ресурсов. Так же необходимо отслеживать утечки памяти и проверять работоспособность и устойчивость серверной части приложения. Следует принимать во внимание, что передача данных в мобильных сетях может идти с потерей пакетов а так же следует проверить механизмы шифрования трафика на предмет его перехвата и использования сторонними пользователями. 41 Тестирование обработки случайных событий – разрабатываемое приложение должно корректно вести себя во время случайных и непредсказуемых событий, так как телефон часто попадает в условия, кода происходит хаотичное нажатие клавиш. Мультиплатформенное тестирование . Мобильный рынок обладает большим количеством типов устройств и конфигураций. Очевидно, что тем больше устройств будет поддерживать приложение, тем большей будет база его клиентов Основные моменты, на которые стоит обращать внимание при тестировании: 1. Интерфейс 1.1Элементы интерфейса должны быть легко доступны пользователю, он должен иметь возможность однозначно попасть по ним 1.2Приложение не должно содержать пустых или ведущих в никуда экранов. Пользователь всегда должен иметь возможность вернуть приложение к предыдущему рабочему состоянию 1.3Приложение должно стабильно обрабатывать многократное и быстрое нажатие одной кнопки 1.4Если заявлена поддержка жестов, то следует проверить, применимы ли те или иные жесты в тех или иных рабочих областях приложения и как это согласуется с требованиями 2. Производительность: 2.1Утечки памяти. Следует проверять потребление памяти при длительной работе или при появлении окон с большим количеством информации. 2.2Обработка ситуации нехватки ресурсов. Проверка стабильности работы приложения в условиях нехватки системных ресурсов 2.3Отсутствие поддержки устройством части функционала приложения 3. Работы с различными экранами и разрешениями: 3.1Ретина и обычные экраны. На ретине элементы интерфейса отображаются мельче 3.2Работа с портретной и альбомной ориентацией устройства 3.3Приложение должно работать только на заявленных версиях операционной системы 42 3.4Соответствие дизайна приложения общей концепции дизайна платформы. 4. Обработка внешних событий: 4.1Звонки/СМС, оповещения других приложений 4.2Выключение устройства 4.3Отключение устройства от сети, режим «в самолете» 4.4Подключение/отключение карты памяти Так же в приложении обязательно должна присутствовать форма обратной связи с разработчиком. Все эти пункты легко поддаются ручному тестированию и сейчас для проверки работоспособности приложений оно особенно актуально. Но так же существуют системы автоматизированного тестирования , разработанные специально для тестирования мобильных приложений под различные платформы. Автоматизирование тестирование мобильных приложений Для автоматизированного тестировании мобильных приложений справедливы те же подходы, что и актуальны для тестирования десктопных систем, а именно: - Запись и воспроизведение. Данные утилиты записывают действия тестировщика во время ручного тестирования и затем воспроизводят их в заданные моменты. Такие тесты помогают оптимизировать время тестировщика, убрав из процесса монотонные действия. Но если тестируемое претерпит изменения – тесты придется переписывать с нуля. - Сценарии. Является формой программирования на специализированных скриптовых языках. Обычно написанием таких скриптов занимаются сам программисты. Скрипты хорошо подходят для тестирования пользовательского интерфейса, но так же имеют недостаток, связанный с их устареванием вместе с изменением внутри самой программы. 43 - Data-driven testing. Вид скриптов, которые оперирует непосредственно потоками данных и сами тестовые скрипты верифицируются с помощью этих данных. -Метод координат. В этом методе каждый элемент графического интерфейса ищется по координатам на экране. Минусом является большая зависимость от настроек платформы (разрешение, шрифт и тп) и невозможность отслеживать состояние объекта. -Распознавание объектов. В основе этого метода лежит поиск элементов пользовательского интерфейса с использованием распознавание и взаимодействие с заданными образцами. Минусы такие же, как и в методе координат. Продукты, используемые для автоматизированного тестирования мобильных приложений, как правило предназначены для тестирования пользовательского интерфейса программы. 44 Приложения для автоматизации мобильного тестирования Appium Рис 17. Пример интерфейса программы Пакет приложений с открытым исходным кодом, предназначенный для автоматизации процесса тестирования приложений под Android и iOS. Поддерживает как тестирования нативных приложений так и веб-решений. Базовыми принципами данного проекта являются: 1. Возможность сохранить базу тестовых сценариев после обновления версии приложения 2. Возможность использовать различные языки для создание тестовых скриптов По сути, appium является веб-сервером, работающим под управлением REST API. Он отправляет команды на мобильные устройства по HTTP и ожидает их выполнения. Сами сценарии создаются на любом известном языке программирования и скриптинга и затем преобразуются в команды, понятные машине. Сами команды отправляются на установленный на мобильном устройстве клиент, который и инициирует их выполнение. 45 Calabash Рис 18. Структура программы Calabash –кросплатформеная тестовая утилита с открытым исходным кодом, разработанная для автоматизации процесса тестирования на iOS и Android. Calabash это по сути набор библиотек, которые позволяет через клиент взаимодействовать тестовому приложению с HTTP сервером тестового окружения. Команды могут передавать следующие действия: - жесты - проверки - снятие скриншота Calabash поддерживает работу Cucumbe, что позволяет создавать тестовые сценарии автоматизации на естественном языке. 46 Testdroid Рис 19. Пример интерфейса программы Это набор программных утилит, разработанных компанией Bitbar Technologies. Он включает в себя: Testdroid Cloud - база реальных android и ios устройств, которые доступны для запуска симуляционых тестов на основе cloud-based сервисов Testdroid Recorder- утилита для создания тестовых сценариев путем записи пользовательских действий и последующего воспроизведения их на тестируемом приложении Testdroid Enterprise – серверное программное обеспечение для управления процессом автоматизированного тестирования на множестве устройств на android и ios. 47 Perfecto Mobile Рис 20. Пример интерфейса программы Еще одна утилита, предназначения для облачного тестирования на реальных устройствах. Поддерживает больше количество устройств, в том числе платформу Blackberry. Имеет в своем распоряжении возможность получить доступ к множеству девайсов как к одному – действия, совершенные на одном устройстве будут автоматически продублированы на все другие выбранные устройства. 48 SOASTA TouchTest Рис 21. Пример интерфейса программы Многофункциональное решение для автоматизации и тестирования мобильных приложений. Основной особенностью является поддержка автоматизации тестирования путем интеграции визуального метода создания тестовых сценариев, который объединяет в себе запись и координатное распознавание объектов. Этот метод обеспечивает быстрое и точно прохождение тестовых сценариев, но так же подвержен всем тем недостаткам, что характерны для автоматизации тестирования. Так же имеется поддержка облачного тестирования на реальных мобильных устройствах. 49 Testin Рис 22. Пример интерфейса программы Специально разработанная утилита для автоматизированного поиска падений в тестируемых приложений. Специализируется на тестировании игр. Одной из особенностей продукта является то, что он функционирует после релиза программы, собираю информацию по падениям и отправляя подробный отчет разработчикам. Встраивается в код программы путем добавления пары строк в исходный код приложения. Так же имеет возможность проводить тестирование на облачных устройствах со всеми стандартными функциями автоматизации тестирования интерфейса. 50 Ranorex Рис 22. Пример интерфейса программы Утилита для тестирования нативных и web-based приложений на android и ios. Поддерживает широкий спектр возможностей, таких как: - Распознавание объектов интерфейса. С помощью установленного на мобильное устройство способен распознать все элементы интерфейса, даже в данный момент не активны. - Объектное- ориентированная функция записи/воспроизведения - Библиотеки для автоматизации процесса тестирования - Гибкий интерфейс автоматизации процесса тестирования Программный пакет поддерживает следующие типы тестирования: - Приемочное тестирование - Автоматизирование тестирование 51 - Тестирование методом черного ящика - Функциональное тестирование - Тестирование пользовательского интерфейса - Веб тестирование - Тестирование мобильных приложений - Тестирование JAVA приложений - Регрессионное тестирование - Keyword-driven тестирование -Data-driven тестирование - мультиплатформенное тестирование 52 eggPlant Рис 23. Пример интерфейса программы Средство автоматизации процесса тестирования методом черного ящика . Тестирование выполняется с помощью скриптов, созданных на управляющей машине и выполненных на клиентской части, установленной на тестируемом устройстве. Позже была введена поддержка записи и воспроизведения тестов. 53 ПРОЦЕСС ТЕСТИРОВАНИЯ МОБИЛЬНЫХ ПРИЛОЖЕНИЙ НА БАЗЕ ОС ANDROID В «ЗАО ЛАБОРАТОРИЯ КАСПЕРСКОГО» В качестве рабочего окружения для полной интеграции с процессом разработки используется Microsoft Visual Studio Team Foundation Server , который позволяет получить доступ к данным проекта, его требованиям, сборочным конвейерам и единым спискам задач и проблем для каждой команды разработки. Рис 24. Пример интерфейса программы Все требования и тестовые сценарии создаются там же, для этого используется специальная форма, которая специально разработана для создания того или иного объекта. Каждому таким образом созданному объекту присваивается свой порядковый номер, который затем можно использовать для поиска данной записи в единой базе данных. 54 Рис 25. Создание тестового сценария После создания тестового сценария, его следует залинковать к требованию, на которое написан этот сценарий. В идеале, к каждому требованию должно быть прилинковано минимум два таких тестовых сценария, содержащих позитивный и негативный вариант осуществления данного требования. Рис 26. Создания линков После покрытия всех требований тестовыми сценариями, на основе этих сценариев создается тест план. Как уже писалось выше, планы могу быть 55 разных направленностей, но обычно мы используем либо регрессионный, либо приемочный тест план. Иногда появляется необходимость составить тест план на какой-либо отдельный модуль, но такое бывает сравнительно редко. Как правило, тестовые планы создаются в Microsoft test manager – модуле Microsoft TFS, которые посвящен процессу тестирования. Создания тестового плана является, по сути, созданием запроса к базе данных, которой и является TFS , на основе составления регулярных выражений. Рис 27. Составление тестового плана Прохождение тестового плана производится там же. Тестеру, согласно выставленной конфигурации становятся доступны те или иные тесты, которые он затем проходи в произвольном или строго заданном порядке. Сам процесс прохождение представляет собой вывод тестового сценария, в котором каждый пройденный или не пройденный шаг отмечается соответствующим символом. 56 Рис 28. Выполнение тестового сценария Если хоть один шаг после завершение тест-кейса находится в состоянии “fail” то и весь кейс считается кейсом, завершенным с ошибкой. После завершения такого сценария тестер может оформить дефект, пользуясь автоматически собранной информацией на основе тестового сценарии или же задокументировать дефект самостоятельно. 57 Рис 29. Выполнение тестового сценария После прохождения тест плана все результаты компилируются в один отчет, который помимо самого результата теста содержит большой набор метрик которые, при желании, помогают оценить качество и продуктивность работы тестера. В самом же процессе тестирования в основном используется функционал android sdk,а именно - android debug bridge (adb) и eclipse sdk. Рис 30. Интерфейс adb Adb представляет собой консольное приложение, которое моделирует поведение unix систем, на которых и построен android. Adb прежде всего позволяет производить удаление управление оболочкой ос и отдавать ему простые команды типа установкам приложения, работы с картой памяти, снятия отдельных метрик а так же некоторые другие операции, которые мы рассмотрим ниже. В общем виде, синтаксис adb выглядит как adb [-d|-e|-s <serialNumber>] <command> список все доступных команд: 58 Категория Команда Описание Коментарий Целевое устройств о -d Подключает к adb к устройству, подключенную по usb Возвращает ошибку, если подключено больше одного устройства -e Подключает adb к эмулятору Возвращает ошибку, если подключено больше одного эмулятора -s <serialNumber> Подключает adb к конкретному устройству devices Показывает список всех подключенных устройств help Вызывает справку version Показывает версию adb logcat [option] [filterspecs] Показывает логи подключенной системы bugreport Показывает dumpsys, dumpstat e, и logcat .на экране jdwp Показывает все доступные JDWP процессы на устройстве install <path-to-apk> Устанавливает приложение на устройство pull <remote> <local> Копирует файл с устройства на компьютер push <local> <remote> Копирует файл с компьютера на устройство forward <local> <remote > Перенаправляет соединения с указанного порта на порт основные отладка Данные Сеть и порты 59 устройства Сценарии Сервер Консоль get-serialno Выводит серийный номер adb get-state Выводит adb статус подключенных устройств start-server Проверяет, запущен ли процесс adb.exe и запускает его, если он не запущен kill-server Прекращает работу всех процессов adb shell Открывает удаленную консоль на устройстве shell [shellCommand] Выполняет консольные команды на устройстве Используютс я Unix синтаксис Eclipse sdk представляет из себя программный продукт, который состоит из отдельных модулей и может быть использован не только для работы с android но и для работы, например, с tizen (tizen sdk). 60 Рис 31. Окно Eclipse SDK Основной функционал, помимо снятия метрик, подобных adb состоит в работе с встроенным эмулятором, который позволяет тестировать такие ситуации, которые было бы проблематично получить, используя только физически устройства из тестовой лаборатории (эмуляция различных режимов работы, сигнала сетей и передачи данных).система эмулируется с помощью реальных образов системы разных версий на программно созданных устройствах, моделирующих реально существующие аналоги. Такие эмуляторы как правило потребляют большое количеств о ресурсов отображаются антивирусными по как рутованные. Сам процесс эмулирование основан на работе AVD – android virtual device. 61 В нем задаются параметры эмулируемого устройства, такие как версия операционной системы, наличие и размер SD карты, разрешение экрана, элементы управления и настройки «железа» После подключения эмулятора с ни можно работать так же, как и с обычным устройством – передавать команды через ADB, устанавливать приложения, снимать метрики Рис 32. Окна AVD 62 Конструкторско-технологическая часть Проанализировав вышестоящую информацию и вооружившись собственным опытом проведения тестирования, я пришел к выводу, что ускорить прохождения тестирования и повысить качество тестов можно путем создания приложения, которое оперировало бы самыми часто используемыми командами adb и обеспечивало просто и гибкий доступ к ним. Исходя из своей практики я выделил группу команд, которые встречаются наиболее часто: - devices - logcat - install - pull - push - shell Итак, основной функционал будет строиться вокруг этих команд. Так же будет полезно добавить следующие команды: adb shell pm list packages – получение списка всех установленных приложений adb shell top (парарметры)- выводит список запущенных процессов и их потребление ЦПУ/памяти adb shell monkey (параметры)- запускает процедуру тестирования телефона или конкретного процесса на предмет случайных нажатий с указанной скоростью и количеством нажатий. После того, как появилась ясность касательно будущего функционала, можно приступать к разработке общего алгоритма работы системы и создания макетов интерфейса: 63 Алгоритм должен быть максимально простым и однозначным. После запуска программы мы можем вызвать команду adb devices, которая инициализирует и запустит процесс adb.exe и так же подключит к нему подключенное по USB порту устройство. Чтобы процесс успешно запустился, необходимо чтобы на компьютере был уже установлены файлы программы adb. Чтобы успешно инициализировался телефон, необходимо подключить его по USB кабелю к устройству и активировать опцию «отладка по USB» в меня настроек для разработчика. Так же необходимо скачать драйверы для Android adb device https://dlssl.google.com//android/repository/latest_usb_driver_windows.zip Согласно макетам, пользователь должен иметь возможность просмотреть содержимое SD карты устройства. Для визуализации этого действия удобнее использовать форму TreeView, которая обеспечивает наглядный вывод содержимого папок и файлов. 64 Рис 33.Алгоритм работы программы Алгоритмы для снятия логов и выполнения monkey тестирования линейны и состоят из нескольких шагов: инициализация команды, перевод ее в формат adb и вывод/сохранение результата. Для функционирования всех алгоритмов необходимо подключенное устройство и установленные драйверы. 65 После процесса разработке итоговая программа выглядит следующим образом: Главное окно программы 66 Вкладка снятия логов и метрик 67 Вкладка с дополнительными параметрами. Демонстрация работы разработанного программного обеспечения 68 Установим приложение Shazam на выбранное устройство: Найдем установленный пакет в списке приложений: 69 Если приложение уже установлено, то повторно его установить будет нельзя, так как имена пакетов буду совпадать: 70 Но если активировать пункт «переустановить», то команда adb install выполнится с ключом –r что позволит установить приложение повторно: Метрики можно выводить двух типов – использование процессора и использование памяти. Для начала процесса необходимо выбрать нужный тип метрики, выставить частоту обновления вывода и нажать кнопку «старт». Процессы буду автоматически располагаться в порядке убывания выбранной метрики: 71 72 Для удобства слежения за одним процессом можно использовать фильтр по данному процессу: 73 Для логирования состояние системы необходимо выбрать директорию, куда будет сохранятся файл с логом и придумать название для этого файла. Затем нажать кнопку «старт»: Содержимое файла logs.txt будет выглядеть примерно следующим образом: Для остановки записи необходимо нажать кнопку «стоп». Monkey тестирование – это вид тестирования, при котором телефону отдается команда о хаотичном нажимании всех элементов интерфейса заданное количество раз с заданным интервалом. Служит для проверки отказоустойчивости приложения в длительных или экстремальных режимах работы. 74 На экране с этим видом теста можно задать интервал нажатия (в миллисекундах ) и общее количество нажатий. Если нужно протестировать конкретное приложение, то следует ввести имя его пакета в соответствующую строку. Если вам не обязательно проверять, как ваше приложение ваше приложение обрабатывает нажатие системных клавиш, то их можно игнорировать, поставив галочку напротив «игнорировать системные клавиши» Сам процесс запускается нажатием кнопки «старт» и работает до тех пор, пока не буду произведены все нажатия или пока работа выбранного процесса не завершится с ошибкой. 75 Экология и охрана труда Создание оптимальных условий трудовой деятельности программиста, оператора ЭВМ. Проектирование рабочих мест трудящихся является важно проблемой организации труда в области вычислительной техники. Правильная организация рабочего места крайне важна для производительности труда и по этому должна соответствовать всем установленным нормам. Работа с ЭВМ сопряжена с большой умственной и зрительной нагрузкой, а так же нагрузкой на мышцы рук при работе с клавиатурой, по этому при работе с компьютером необходимо соблюдать режим труда и отдыха. Помещение должно быть надлежащим образом освещено. Всего существуют три типа освещения – естественное, совмещенное и искусственное. Естественное - освещение помещения дневным светом. Искусственное - освещение помещения искусственным светом. Совмещенное - освещение как естественным так и искусственным светом. Приоритет лучше отдавать естественному свету, хотя это редко когда бывает возможно, по этому лучше использовать совмещенный тип освещения. При непосредственно работе с ЭВМ величина естественного освещения не должна быть ниже 1.5% а при зрительной работе средней точности – не ниже 1%. Общая освещенность должна быть не ниже 300лк а комбинированная – 750лк. Так же, все пространство должно быть освещено полностью и равномерно, то есть яркость экрана не должна сильно контрастировать с общей освещенностью помещения. 76 Условия микроклимата могут сильно разнится в зависимости от климатического пояса того места, где расположена компания, однако необходимо поддерживать наиболее комфортные климатические условия для сохранения хорошей трудовой активности на протяжении всего рабочего дня. Для помещений, в которых установлены ЭВМ существуют следующие нормативы: При холодном времени года оптимальная температура в помещении 22.24С, влажность – 40.60% а скорость движения воздуха – 0.1м/с При теплом времени года оптимальная температура в помещении 23.25С, влажность – 40.60% а скорость движения воздуха – 0.1м/с Шум и вибрация при длительном воздействии оказывают вредное влияние на организм человека. Головные боли, раздражение, снижение памяти , головокружение – все это следствие работы в ненадлежащих условиях. По этому уровень шума при работе с ЭВМ не должен превышать 50дБА а в вычислительных центрах – 65дБА. По роду своей деятельности операторы ЭВМ проводят почти все рабочее время перед экраном компьютера а следовательно, подвергаются воздействию электромагнитного и ионизирующего излучения. Сейчас учеными не доказана безусловность вреда данных видов излучения для человека, однако оператору ЭВМ следует придерживаться следующих норм: Допустимые значения Наименование параметра Напряженность электрической составляющей электромагнитного 10В/м поля на расстоянии 50см от поверхности видеомонитора Напряженность магнитной составляющей электромагнитного 0,3А/м поля на расстоянии 50см от поверхности видеомонитора Напряженность электростатического поля не должна превышать: 77 20кВ/м 15кВ/м для взрослых пользователей для детей дошкольных учреждений и учащихся средних специальных и высших учебных заведений Эргономичность рабочего места так же является важной частью правильной организации труда. Оборудование должно быть размещено оптимальным образом: не мешаться и не закрывать рабочее место, но находится в удобной доступности от рабочего места. Рабочая поза не должна быть утомительной для программиста, высота кресла должна регулироваться. Стол так же должен позволять сидеть комфортно, не поджимая ноги и на удобной высоте. Монитор должен находится на приемлемом расстоянии от глаз, чтобы не портить их своей близостью, но и оставаться читабельным для программиста. Влияние интеллектуального труда на здоровье. К умственному труду относятся деятельность человека, требующая напряженного функционирования памяти, внимания, мышления. Сама по себе напряженная умственная деятельность не несет в себе вреда для организма человека. При устойчивом и спокойном регламенте вероятность сердечно – сосудистых заболеваний относительно низка. Если же такой труд осложняется эмоциональной составляющей, то повышается риск развития таких заболеваний, как гипертония, сердчено - сосудитсая недостаточность. У работников умственного труда отрицательные факторы вызывают патологию ЗАКЛЮЧЕНИЕ В ходе выполнения дипломной работы были изучены принципы и методы современного тестирования, как для настольных, так и для мобильных систем. 78 В теоретической части ВКР была изучена история развития тестирования. Были описаны элементы проектирования программного обеспечения, такие как создание пользовательских сценариев и бизнес-требований. Так же, был досконально изучен сам процесс тестирования как на настольных системах, так и на мобильных устройствах. Приведены в пример и описаны лидирующие на рынке решения в области организации как процесса автоматизированного тестирования, так и процесса тестирования на мобильных устройствах. На основе этих исследований была разработана программа, которая предоставляет доступ к самым часто используемым функциям adb в процессе тестирования и продемонстрирован ее алгоритм и работоспособность. Список использованной литературы: - Канер С., Фолк Дж., Енг Кек Нгуен. Тестирование программного обеспечения - Материалы сайта Wikipedia.org - Материалы сайта softwaretestinghelp.com - Материалы сайта tpl-it.wikispaces.com - Материалы сайта habrahabr.ru 79
