Файл: Функциональное тестирование программного обеспечения на примере мобильных приложений (Теоретические аспекты тестирования программного обеспечения).pdf
Добавлен: 31.03.2023
Просмотров: 93
Скачиваний: 2
Введение
Платформа Android в последние годы является лидером рынка операционных систем, занимая по состоянию на 2015 год 59 % рынка операционных систем и 89,4 % рынка мобильных платформ по всему миру. Соответственно, все больше компаний, стремясь увеличить количество пользователей своих сервисов, уделяют особое внимание именно этой платформе. Именно открытость исходного кода ОС Android позволила этой платформе завоевать такие позиции на рынке. Однако, разнообразие устройств приводит к печальным последствиям в плане поддержки этих устройств, а также программного обеспечения на них. Производитель не может позволить себе обновлять устаревшее устройство до последней версии ОС ввиду экономических причин, и, как это часто бывает, для побуждения пользователя купить новое устройство с новейшей версией ОС и техническими характеристиками. Разработчики ПО так же не поддерживают все устройства на всех версиях ОС, но разрабатывают приложения под нужды, в первую очередь, устройств,занимающих лидирующие позиции на рынке.
Вышеперечисленные причины, наряду с ошибками в программировании, неизбежно приводят к нежелательным последствиям, таким как падение спроса на тот или иной сервис и ухудшение «пользовательского опыта». Именно поэтому необходимо тестирование всего ПО, выпускаемого в широкие массы пользователей.
На сегодняшний день существующие методы тестирования не позволяют однозначно и полностью выявить все дефекты и установить корректность функционирования анализируемой программы. Поэтому существующие методы тестирования действуют в рамках формального процесса тестирования, который может доказать, что дефекты отсутствуют с точки зрения используемого метода.
Объектом исследования в курсовой работе является программное обеспечение.
Предметом исследования – процесс тестирования программного обеспечения на примере мобильных приложений.
Целью исследования является выявление особенностей процесс тестирования программного обеспечения на примере мобильных приложений.
Для достижения поставленной цели сформулированы следующие задачи:
- изучить теоретические аспекты тестирования программного обеспечения;
- проанализировать факторы, влияющие на процесс тестирования мобильных приложений.
Методологической основой исследования являются учебная и методическая литература, статьи в периодической печати и Интернет-ресурсы.
Теоретические аспекты тестирования программного обеспечения
Процесс тестирования играет важную роль в проектах, связанных с разработкой программного обеспечения (ПО). Руководители консалтинговых компаний, которые занимаются созданием и внедрением новых информационных продуктов, заинтересованы в обеспечении качественного выполнения этого вида работ. Несмотря на то, что успех проекта зависит от многих факторов, правильная организация процесса тестирования существенно влияет на подготовку качественного программного обеспечения. [2, с.102; 3, с.16]
Время проведения тестирования зависит от выбранной модели жизненного цикла (ЖЦ) программного обеспечения. Как правило, исключая водопадную модель ЖЦ ПО, планирование тестирования начинается в самом начале IT-проекта, когда совместно с заказчиком уже определены требования к будущему ПО. Готовится план тестирования и, согласно требованиям, тест кейсы, по которым будет проводиться проверка программного обеспечения. Специалисты пришли к выводу, что информация обо всех найденных ошибках обязательно должна быть сохранена, это значительно облегчает работу команды тестирования. Несмотря на продолжающиеся дискуссии о возможности применении других средств, обычно в компаниях используют багтрекинговую систему для создания, хранения, просмотра и модификации сведений о багах. От выбора функционального и удобного багтрекера зависит уровень взаимодействия команды тестирования и разработчиков, а также качество исполнения процесса тестирования. В данном случае рассматривалась система трекинга багов (СТБ) для среднестатистической небольшой компании. Таких фирм достаточно много на российском рынке, чаще всего, они параллельно занимаются несколькими проектами и осуществляют техническую поддержку. В ходе работы использовался алгоритм выбора программного обеспечения, его основные этапы показаны на рисунке 1. [5, с. 177]
Рисунок 1. Алгоритм выбора ПО
Таким образом, решалась задача многокритериального вывода, применялась методика MuSCoW для выделения более значимых показателей. Эта консалтинговая методика подразумевает, что есть 4 вида критериев – обязательные (must have), менее важные, но желательные показатели (should have, would have), а также показатели, которых не должно быть (won’t have). [6, с.213; 7, с.174]
Список программного обеспечения и его оценка по выделенным критериям проводилась с помощью экспертов в области тестирования. При подведении итогов применялся метод взвешенной оценки, учитывающий важность каждого показателя. Наиболее весомым и значимыми специалисты признали «Usability» и «Простоту освоения». Дело в том, что во время проекта возможна частичная или полная смена коллектива, как тестировщиков, так и разработчиков. Новый сотрудник должен легко освоить функционал багтрекера, чтобы как можно быстрее начать выполнять свои обязанности. Критерий «Простота освоения» важен для сотрудников, которые совмещают роли на проекте. Например, в целях оптимизации, консультанты могут быть задействованы в процессе тестирования. Поэтому, чем логичнее и проще устроена система трекинга багов, тем меньше сроки ее изучения. Следующим критерием была названа «Полнота функционала», в это понятие входит весь набор необходимых work items, то есть таких рабочих элементов, как user story, task, bag, test case, test suite. А также 120 наличие статусов, приоритетов и других показателей, которые необходимы для эффективной работы с дефектами ПО. «Надежность» – достаточно важный показатель, который критичен для любых реально работающих систем, в том числе и багтрекинговых. «Требования к аппаратному обеспечению (АО)» достаточно средние, больших ресурсов не требуется. «Поддержка работы с несколькими проектами» – выделяется особенно, так как компании чаще всего ведут работу по большому количеству проектов и всю информацию по дефектам необходимо хранить в багтрекере. «Учет рабочего времени» – отражает количество временных ресурсов затраченных на ту или иную ошибку. «Генерация отчетов» довольно важный показатель, так как для test lead, менеджера проекта, высшего руководства необходимо иметь полные и исчерпывающие сведения о процессе тестирования. Языковой барьер нередко является большой проблемой в ходе проекта, поэтому лучше иметь СТБ с функцией поддержки нескольких языков. «Наличие интеграции с email, мессенджерами» – для команды проекта важно иметь постоянный доступ к информации, ресурсам системы, так как успешное завершение проекта зависит, в том числе, и от оперативности реагирования персонала на то или иное событие. «Методическое обеспечение» также играет не последнюю роль, качественное описание структуры и наличие правил работы с багтрекером значительно упростит его освоение пользователями. «Поддержка и применение в РФ» – это залог обеспечения ее работоспособности системы, возможность технической поддержки. Затем нами были рассмотрены представленные на рынке, как opensource, так и проприетарные решения. Изначально стоимость, то есть финансовый критерий не определен, важно выбрать программное обеспечение, которое более всего соответствует названным показателям. Приобретение платной системы или использование СТБ с открытым кодом зависит от политики и финансовых возможностей компании. На рынке представлено большое количество программного обеспечения в области тестирования, нами были оценены Bugzilla от компании Mozilla Foundation, Trac от Edgewall Software, Atlassian JIRA компании Atlassian Software Systems, Test Rail Gurock Software, MantisBP от Mantis, Redmine разработчика JeanPhilippe Lang. Итоги сравнения приведены в таблице 1.
Таблица 1 - Матрица критериев по выбору системы трекинга багов
Исходя из полученных баллов, наилучшие показатели у ПО Atlassian JIRA. За ней следуют системы Bugzilla и Redmine. Несмотря на то, что Bugzilla опередила JIRA по критерию «Простота освоения», эта система значительно уступает по второму наиболее важному показателю «Usability». Redmine в целом была оценена ниже, чем две другие СТБ, в том числе и по двум значимым критериям. Система Trac, которая по сумме баллов находится на последнем месте, тем не менее, отмечена достаточно высоко по «Простоте освоения» и «Usability». Однако Trac проигрывает другим ПО в «Полноте функционала», а также не поддерживает работу с несколькими проектами. Названные критерии также учитываются при выборе багтрекера, им присвоены высокие коэффициенты. Именно поэтому эта система не была включена нами в список отобранных. Bugzilla и Redmine – open source решения, а Atlassian JIRA – проприетарное ПО, но на сайте разработчика представлен и тестовый вариант. Окончательное решение следует принимать исходя не только из финансовых возможностей компании. Необходимо провести экспериментальную проверку и сравнить лидирующее программное обеспечение, чтобы на практике убедиться в точности результатов исследования.
Процесс тестирования начинается с того, что команде тестировщиков предоставляется ПО, которое следует протестировать, и требования к этому ПО. Как только разработчики подготовили программу, необходимо провести дымовое тестирование, по результатам которого делается вывод о возможности и целесообразности дальнейшего тестирования:
– если дымовое тестирование прошло неудачно, вы отправляете приложение на доработку;
– если же удачно, то вы переходите к следующему виду тестирования - регрессионное тестирование.
Открыв систему отслеживания ошибок, следует перепроверить дефекты, которые разработчики перевели в статус «Исправлено», «Отклонено», «Нет возможности воспроизвести» и т.д. Заметим, что статусы «Отклонено» и «Нет возможности воспроизвести» для вас самые неприятные - это явное свидетельство того, что либо вы недостаточно хорошо локализовали дефект, не очень понятно описали шаги для воспроизведения, либо разработчик поленился воспроизвести ситуацию. Покончив с закрытием и переоткрытием дефектов, идёт переход к основной работе - централизованному тестированию по тест кейсам. Когда все, что было запланировано, пройдено, тестировщик имеете результаты прогона тест кейсов, бaг репорты, вопросы к аналитикам и заметки на полях своих тетрадей. Основываясь на всем этом, составляется отчет по проведенному тестированию и отправляется на проектную группу. Подобный процесс проходит от версии к версии, и через какое-то время результаты тестирования сойдутся, с прописанными в плане тестирования критериями окончания тестирования. На этом основная работа, связанная непосредственно с тестированием, окончена [1, с.12].
Тестирование ПO является одной из технических способов контроля качества и включает в себя активности по планированию работ, проектированию тестов, выполнению тестирования и анализу полученных результатов [3, с.15]. Необходимое условие: тестирование не возможно без объекта тестирования, отсюда получаем первое условие: наличие объекта тестирования, доступного для проведения испытаний. Далее, чтобы тестирование все же состоялось, нам нужен исполнитель, значит, вторым необходимым условием будет наличие исполнителя, причем им может быть, человек или машина, или комбинация человек и машина.
Перейдем к определению достаточных условий. Так как не каждое действие, совершенное над программой, с целью получения ожидаемого поведения, является тестированием, встал вопрос о том, что сама по себе цель, а именно: тестирование, является одним из достаточных условий. Принимая за основу то, что наличие плана тестирования прямо указывает на намерение проведения тестирования, получаем, что тест план является одним из достаточных условий. При проведении тестирования, человек или машина должны будут выполнять какие-то действия для проверки реального и ожидаемого поведения программы. Значит, наличие тест кейсов/тестов также является достаточным условием.
Для подтверждения, что тестирование произошло, нам необходим отчет о результатах. Значит, для подтверждения того, что тестирование имело место быть, отчет о результатах тестирования должен быть сформирован.
Тестирование – это процесс, который заключается в проверке соответствия программного продукта заявленным характеристикам и требованиям, требованиям эксплуатации в различных окружениях, с различными нагрузками, требованиям по безопасности, требованиям по эргономике и удобству использования. Именно поэтому тестирование является неотъемлемым компонентом создания ПО.
Оно решает несколько основных задач:
– дает уверенность в качестве конечного продукта, подтверждает, что все заявленные функциональные требования реализованы, приложение им соответствует и не имеет ошибок в программном коде;
– подтверждает, что приложение способно выполняться во всех заявленных режимах и на всех поддерживаемых ОС или Web-браузерах корректно;
– гарантирует, что хранимые и обрабатываемые данные надежно защищены от постороннего доступа и "взлома";
– определяет, какая максимальная нагрузка на сервер, локальную сеть, БД может быть корректно обработана приложением;