Тестирование. Ю. Б. Попова тестирование и отладка программного
 Скачать 0.6 Mb.
|
|
5.3. Системы документирования и отслеживания ошибок Системы документирования и отслеживания ошибок (англ., Bug Tracking Systems, BTS) в большинстве своем, не ограничива- ются работой с ошибками, а представляют собой системы управле- ния проектами. Они позволяют отслеживать процесс тестирования, проверять и составлять отчеты. Общее назначение таких систем можно описать следующим образом: 1) повышать взаимодействие между сотрудниками; 2) ни одна ошибка не должна быть не исправлена, потому что так решил разработчик; 3) как можно меньше ошибок должно остаться из-за проблем взаимодействия сотрудников. Несмотря на то, что существует довольно большой перечень BTS, все их количество можно разбить на классы: – свободно распространяемые (например, Bugzilla, Mantis, Redmine, Track); – платные системы (например, Jira, ClearQuest, TestTrackPro); 42 – собственная разработка (т. е. компания разработала для себя такую систему). Следует отметить, что выбор ВТS зачастую определяется заказ- чиком программного обеспечения, молодые и немногочисленные компании останавливаются на бесплатных системах, а крупные компании в состоянии позволить себе собственную разработку по своим требованиям. Тем не менее, можно предложить следующие критерии выбора BTS: 1) доступная система для различных платформ; 2) наличие клиент-серверного приложения; 3) поддержка работы с различными базами данных; 4) стоимость и схема лицензирования; 5) интегрирование в различные среды; 6) гибкость настройки системы; 7) электронная поддержка формирования событий и отчетов. 5.4. Жизненный цикл ошибки Жизненный цикл ошибки – это путь, который проходит ошибка с момента ее обнаружения до закрытия либо другого терминального статуса. Каждый этап жизни ошибки характеризуется ее статусом. Не все BTS имеют одинаковые названия статусов ошибок и, соответ- ственно, жизненные циклы. Рассмотрим основные из них (рис. 5.1). Рис. 5.1. Жизненный цикл ошибки 43 Жизненный цикл ошибки начинается с ее обнаружения и присво- ения статуса новая (или найдена, или обнаружена, или submitted). Затем ошибка направляется разработчику для исправления и полу- чает статус исправить (или назначить, или assigned). После исправ- ления ошибка получает статус исправлена (или fixed). Затем исправ- ленная ошибка проверяется тестировщиком еще раз (как правило в новой версии ПО) и, если она не воспроизводится, то получает статус проверена (или закрыта, или verified). На этом жизненный цикл ошибки заканчивается, однако это идеальный случай, который не всегда происходит. Возможны и другие пути жизненного цикла ошибки: 1. Исправленная ошибка повторяется снова, тогда она отправля- ется на рассмотрение по новому кругу. 2. Задокументированная ошибка не воспроизводится, тогда ей может быть присвоен статус игнорировать (или не воспроизводит- ся, или declined). 3. Возможны также случаи, когда задокументированная ошибка, например, не может быть исправлена в текущей версии, тогда ее откладывают с присвоением статуса отложена (или deffered). Возможны и другие статусы ошибок, определяемые системами документирования ошибок, например, статус дубликат, когда в BTS уже задокументирована такая ошибка, или статус не ошибка, когда тестировщик ошибочно составил отчет. 5.5. Реализация градации тестов 5.5.1. Тест «на дым» и критерии его непрохождения Как указывалось выше (п. 4.2), тест на «дым» (в литературе так- же встречается название приемочный тест) – это быстрая проверка выполнения основной функциональности программы. После прие- мочного теста делается вывод о пригодности программы для даль- нейшего тестирования или нет. Каждая версия разрабатываемого ПО подвергается проверке «на дым», поскольку нет смысла тратить усилия тестировщиков на версию, в которой не работает даже ос- новная функциональность. Критерии непрохождения приемочного теста часто зависят от специфики решаемой задачи и должны быть отражены в тестовом плане, однако можно выделить общие из них: 44 1) отсутствие каких-либо файлов или компонент, без которых любое тестирование ПО невозможно; 2) сбой программного обеспечения или системы в начале рабо- ты, и дальнейшее тестирование невозможно; 3) ошибка в программе, приводящая к сбою в середине работы и делающая дальнейшее тестирование невозможным; 4) достижение определенного процента ошибок, недопустимого для приемочного тестирования, например, 20–25 % тестовых слу- чаев не проходит (как правило, недопустимый процент указывается в тестовом плане). 5.5.2. Позитивный тест Позитивный тест – это основной вид функционального тести- рования, при котором проверяется типичная, логически верная рабо- та программы. Этот вид тестирования проводят в случае пройденно- го приемочного теста посредством запуска программы и проверки работы каждой функциональности по заранее подготовленным тес- товым случаям. Отработанный тестовый случай помечается как «пройденный» или «не пройденный». Для этого в таблице с тестовы- ми случаями существует отдельная колонка (табл. 4.1). Если тест не пройден, тестировщик составляет отчет об ошибке и сохраняет его в BTS. Если в процессе тестирования обнаруживается ошибка, не предусмотренная тестовыми случаями, то тестировщик также со- ставляет отчет об ошибке и добавляет новый тестовый случай в име- ющийся список. Такой подход позволит не потерять возможную ошибку в следующих версиях тестируемой программы. 5.5.3. Негативный тест Негативный тест проверяет работу программы в непредвиден- ных и нестандартных ситуациях, например, при некорректно вво- димом значении, при незаполненных полях для ввода, при дублиро- вании данных и т. д. Негативный тест часто объединяют с мелкими проверками (например, на разный формат даты или перемещение по элементам интерфейса через табуляцию), тогда он получает назва- ние «углубленный тест» (или расширенный, англ., Extended Test). Такой тест проводят на стабильно работающей программе ближе 45 к окончанию разработки, что связано с экономией времени, по- скольку нет смысла проверять нестандартную работу программы, если не работают стандартные ситуации. Негативный тест проводят на основе заранее разработанных тестовых случаев, а также с ис- пользованием контрольных перечней (листов проверок, чек-листов, англ., Сheck List). Чек-листы – это мини-тестовые случаи, которые создаются для стандартных элементов и полей приложений, применяемых практи- чески в любых проектах, например, тестовых полей, числовых, по- лей даты, времени и т. д. Поэтому нет смысла для каждого отдель- ного проекта разрабатывать свои тестовые случаи для таких полей и элементов, а достаточно использовать контрольные перечни, вы- работанные опытным путем в течение времени каждым тестиров- щиком, и имеющиеся, как правило, в каждой компании. Рассмотрим некоторые из них. Проверка одного текстового поля: – проверить на заполненность (должно быть первоначально пус- тым или нет); – проверить на пробелы в начале и в конце текста (если не ого- ворено в требованиях, то пробелы должны быть опущены); – проверить на одни пробелы в поле; – проверить на пробелы в середине текстового поля; – проверить на специальные символы; – проверить на символы конкретного языка, если имеется реали- зация приложения на нескольких иностранных языках; – проверить на минимальную и максимальную длину поля; – проверить на работу с кнопками Проверка нескольких текстовых полей: – проверить по всем пунктам чек-листа для одного текстового поля, а также на сохранение текста, состоящего только из одной строки. Проверка числовых полей: – проверить на минимально и максимально допустимое число; – проверить на отрицательные значения; – проверить на буквенные символы; – проверить на 0, 1, –1. 46 Проверка ListBox: – проверить на выпадение списка по стрелке и комбинации кла- виш <Сtrl> + <А>; – проверить сортировку в списке (если не оговорено иначе, то должна быть по алфавиту); – выделенное значение отображается и при сохранении не долж- но сброситься. Проверка ComboBox: – проверить внешний вид бокса; – проверить на ввод своих значений – они должны отображаться. Проверка CheckBox: – проверить работу с помощью мыши и клавиатуры. Проверка RadioButton: – проверить на установку позиции по умолчанию; – проверить выделение поля после его выбора. Поле валюты: – проверить на количество знаков для разменной монеты; – проверить точку или запятую для обозначения целой части. Поле даты: – проверить на пустую дату; – проверить на минимальную и максимальную дату, допустимые для этого поля; – проверить, чтобы минимальная дата не была больше макси- мальной (для случая работы с периодом времени); – проверить на некорректную дату; – проверить на формат даты (программа должна реагировать на неформатную дату или уметь ее конвертировать). Возможны форма- ты дат: дд.мм.гггг (Беларусь, Россия, Германия), дд-мм-гггг (Италия, Дания, Нидерланды), дд/мм/гггг (Великобритания, Латинская Аме- рика), мм-дд-гггг (США), мм/дд/гггг (Литва), гггг-мм-дд (Канада, Бельгия, Швеция) и другие. Кнопки: – проверить расположение кнопки и ее вид; – проверить текст на кнопке (нельзя использовать аббревиатуру и сокращения); – проверить, поместится ли текст на кнопке при переходе на другой иностранный язык; 47 – проверить на однократное и двойное нажатие на кнопку, а так- же на табуляцию; – проверить доступность кнопки согласно требованиям. Окна: – проверить на позиционирование окна в зависимости от разре- шения экрана; – проверить цветовую гамму; – проверить появление скроллинга в необходимых случаях; – проверить, чтобы все текстовые поля были выравнены, а шриф- ты были одинаковые. – проверить, верный ли номер версии стоит в окне Аbout. 5.6. Особенности тестирования standalone и веб-приложений Все приложения принято делить на две группы: веб-приложения и standalone-приложения. Веб-приложения классифицируются по раз- меру проекта, по сфере использования и по целевому устройству, а standalone-приложения – по архитектуре, по принципу хранения данных, по рабочей платформе и по функционированию. Общими видами тестирования для всех приложений являются: 1) Функциональное тестирование. 2) Тестирование интерфейса. 3) Тестирование удобства использования. 4) Тестирование производительности (для standalone-приложений учитывают время старта и запуска, время загрузки формы и отчета, для веб-приложений – время отклика страниц). 5) Тестирование безопасности (для standalone-приложений про- веряется корректность работы с операционной системой, лицензи- рование, устойчивость к случайным сбоям и проверка разграниче- ний прав доступа, для веб-приложений – зависимость от браузера, устойчивость к инъекциям, модификации get и post запросов, изме- нение информации в URL, прямые запросы в базу, проверка на уяз- вимость, проверка разграничений прав доступа). 6) Тестирование локализации – это проверка на соответствие локальным стандартам, языковым стандартам и пользовательского интерфейса. 48 7) Тестирование доступности (включая людей с ограниченными возможностями), реагирование на CAPTCHA, отключение изобра- жений для экономии трафика. 8) Тестирование интеграции с другими приложениями. Особенными видами тестирования для standalone-приложений являются следующие: a) кросс-платформенное тестирование. Приложение не должно быть зависимо от операционной системы, если иное не написано в требованиях; b) тестирование использования ресурсов (утечка памяти); c) тестирование установки программ и лицензирования. Исполь- зуются различные способы установки, обращается внимание на типы установок, интерфейс установщика, роли пользователя, язык уста- новки, сообщения в процессе установки, доступность приложения в процессе установки; d) тестирование механизма обновления; e) деинсталляция и проверка после этого состояния системы; f) проверка работы программы на заданной конфигурации и за- пуск всех поддерживаемых локализаций. К специальным видам тестирования веб-приложений можно от- нести следующие: a) кроссбраузерное тестирование, т. е. проверка работы приложе- ния в браузерах, предусмотренных в документе требований к про- граммному продукту; b) тестирование для мобильных устройств. Должны быть специ- альные версии для этих устройств или проверка на разрешение экра- на. Как правило, для такого тестирования используются эмуляторы; c) поиск поврежденных ссылок и отсутствующих страниц. 6. АВТОМАТИЗАЦИЯ ФУНКЦИОНАЛЬНОГО ТЕСТИРОВАНИЯ Автоматизация тестирования – это процесс замены ручного тестирования некоторым инструментальным средством. Как пра- вило, этот процесс основывается на ATML-методологии и состоит из следующих этапов: 1) принятие решения об автоматизации тестирования; 2) выбор инструментальных средств тестирования; 49 3) планирование и проектирование тестирования; 4) выполнение и управление тестированием; 5) оценка результатов тестирования. Наиболее распространенной формой автоматизации функциональ- ного тестирования является тестирование приложений через графи- ческий пользовательский интерфейс (англ., Graphic Users Interface, GUI). Популярность такого вида тестирования объясняется двумя факторами: во-первых, приложение тестируется тем же способом, которым его будет использовать человек, во-вторых, можно тестиро- вать приложение, не имея при этом доступа к исходному коду. На сегодняшний день для автоматизации функционального тес- тирования через GUI на рынке представлено множество инструмен- тов, среди которых можно выделить SilkTest, Win Runner, Rational Robot, Test Complete, QTP, Watir, Sahi, MS Coded UI и, конечно же, семейство Selenium. Каждый из приведенных инструментов обладает определенными преимуществами и недостатками, а также специфи- кой применения. Например, TestComplete поддерживает различные виды автоматизации тестирования, включая модульное, функциональ- ное и нагрузочное, однако является очень дорогим. Но для учебных целей существует возможность скачать демонстрационную версию на 30 дней с официального сайта производителя [13]. Семейство Selenium, наоборот, является бесплатным, но позволяет тестировать только веб-приложения. Общим свойством всех инструментов явля- ется получение тестового автоматизированного скрипта. Если рассматривать области применения автоматизации, то наи- больший эффект ее применения наблюдается с тестами, которые не- обходимо проводить большое количество раз, на разных наборах операционных систем и браузеров, при работе с большим количе- ством данных и для имитации большого количества пользователей, при длинных сценариях, с труднодоступными местами в системе (back-end процессы, работа с лог-файлами, запись в базу данных), при проверке данных, требующих точных математических расчетов. Также выгодно использовать автоматизацию для регрессионного тес- тирования (набора тестов, которые нужно повторять снова и снова, чтобы быть уверенным, что приложение работает корректно, не- смотря на вносимые изменения), для приемочного и углубленного тестов, чтобы проверять основную функциональность работы про- граммы, и объемные негативные проверки Следует добавить, что 50 автоматизацию следует применять только на стабильно работаю- щем программном продукте. 6.1. Достоинства и недостатки автоматизации функционального тестирования Среди достоинств автоматизации функционального тестирования рассмотрим следующие: 1. Автоматизированные тесты могут прогоняться множество раз. 2. Большая скорость выполнения теста по сравнению с ручным. 3. Протекают каждый раз одинаково. 4. Повышается качество регрессионного тестирования. 5. Повышается качество проверки на совместимость. 6. Возможна автоматизация однообразных и однотипных задач. 7. Возможность прогона тестов ночью и в выходные дни. 8. Автоматизированные испытания генерируют отчеты и журна- лы о выполнении. 9. Уменьшаются временные затраты на формирование статисти- ческих данных о проекте. 10. Возможно проведение нагрузочного тестирования, а также тестирование под разными серверами для каждой отдельной конфи- гурации и на разных иностранных языках. 11. Исключение ошибок, связанных с человеческим фактором. 12. Управление несколькими машинами одновременно (распре- деленный тест). 13. Перезагрузка машины в другую операционную систему и вход под разными пользователями. 14. Взаимодействие с базами данных напрямую. 15. Поиск поломанных ссылок на веб-страницах. 16. Создание теста на одном браузере, а запуск его на другом. 17. Освобождение человека от рутинной работы с возможностью заняться более интересными и креативными задачами. Недостатков у автоматизированного тестирования не так уж и много. Обычно принято указывать, что разработка и отладка тестов требует больших затрат времени и средств, а также, что автомати- зированные тесты не находят новых ошибок (только те, что тести- ровщик может сам предусмотреть, ведь, выполняя тест вручную, человек может обратить внимание на некоторые детали и, проведя 51 несколько дополнительных операций, найти ошибку, а автоматизи- рованный скрипт этого сделать не может). К недостаткам можно еще отнести и стоимость инструмента для автоматизации: в случае, если используется лицензионное ПО, его стоимость может быть достаточно высока. Свободно распространяемые инструменты, как правило, отличаются более скромным набором функциональности и меньшим удобством работы. Большой список достоинств и мелкий недостатков может произ- вести впечатление идеального подхода к тестированию через ее ав- томатизацию. Развеять этот миф поможет перечень необоснованных ожиданий от автоматизации тестирования: 1. Автоматизировать можно все что угодно (ложь, поскольку нельзя автоматизировать тесты, где нельзя обойтись без участия человека, например, тестирование удобства использования). 2. Можно обнаружить бόльшее количество ошибок (ложь, по- скольку автоматизированные тесты работают тоже по тестовым слу- чаям, разработанным тестировщиком). 3. Можно исключить или значительно сократить ручное тести- рование (следствие из п. 1). 4. Возможно 100 % покрытие функциональности (следствие из п. 1). 5. Все необходимое тестирование может выполнять одно инст- рументальное средство (средства автоматизации имеют свою специ- фику, поэтому одним инструментом все покрыть не получится). 6. Временной график тестирования сократится (по статистике, на разработку одного автоматизированного тестового случая уходит до 15 раз больше времени, чем на прохождение его вручную). 7. Автоматизация недорога (для проведения автоматизации тес- тирования необходимы квалифицированные специалисты с немалой заработной платой, а также большинство инструментов являются платными). 8. Средства автоматизации просты в использовании (во-первых, чтобы научиться работе с этими инструментами необходимо пройти специальное обучение, а во-вторых, инструменты автоматизации довольно капризны в использовании, и, зачастую, причины не про- хождения тестов очень трудно определить). |