Тема 17. Тестирование программного обеспечения

План лекции

1. Основы тестирования

2. Виды тестирования

3. Работа с ошибками

4. Тестирование с использованием тест-комплектов

5. Программные средства для тестирования программного обеспечения

Основы тестирования

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

Процесс разработки ПП с позиции тестирования выглядит следующим образом (рисунок 17.1). Отдел разработки бизнес-требованийпредоставляет группе тестирования и отделу разработки два документа: описание бизнес-логики выпускаемого продукта и описаниефункционального дизайна.

Рисунок 17.1. Схема процесса разработки ПП.

 

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

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

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

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

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

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

Изучение спецификации. Эта стадия самая важная, также ее называют «анализом дизайна и/или требований», иногда применяютназвание «тестирование спецификации». На данной стадии необходимо изучить документацию (спецификацию требований) по разрабатываемому приложению.

Дымовое тестирование. На этой стадии необходимо проверитьработает ли система вообще (правильно ли работает, правильно лиобрабатывает ошибки и пр.). Это делается для того, чтобы понятьпригодно ли приложение для дальнейшего тестирования или оноизначально работает неправильно.

«Позитивное» тестирование». На этой стадии необходимо проверить результат работы приложения при получении им «правильных» входных данных.

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

Рассмотрим эти стадии более подробно.

На стадии изучения спецификации определяется, когда и какдолжно работать само приложение, когда и как оно должно реагировать на ошибки, т. е. как система или ее модули должны реагировать на неправильные данные или неверное поведение пользователя. А также: что должно быть в результате правильной обработки, прикаких условиях и входных данных система должна работать корректно? что должно быть в результате неправильной отработки тестируемого приложения, при каких условиях это может происходить. На все эти вопросы должен быть ответ в документации тестируемого приложения. Если ответа там нет, то документация не полная, чторавняется, по сути, ошибке в документации. Эти первые дефекты (вспецификации, в требованиях), возникающие уже на данной стадииявляются для разрабатываемой системы не менее важными, чем прочие. Поэтому тестирование требований это полноценный вид тестирования, которому зачастую незаслуженно уделяют мало внимания. Основными показателями успешного тестирования требований является достижение критериев полноты и непротиворечивости требований.

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

Далее осуществляется процесс тестирования, который можноописать как следующую пошаговою процедуру:

1) проверьте, как работает приложение, когда оно получает навход корректные данные;

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

3) проверьте работу приложения при вводе данных, которые невходят в область допустимых значений (проверка обработки некорректных входных значений).

В первых двух пунктах описан процесс, который называется «позитивным» тестированием.

«Позитивное» тестирование – это тестирование на данных илисценариях, которые соответствуют нормальному (штатному, ожидаемому) поведению проверяемой системы. Основной целью «позитивного» тестирования является проверка того, можно ли припомощи системы делать то, для чего она создавалась.

«Негативное» тестирование – это тестирование на данных илисценариях, которые соответствуют нештатному поведению тестируемой системы, а также выдаче различных сообщений об ошибкахисключительным ситуациям, «запредельным» состояниям и т. п.

Основной целью «негативного» тестирования является проверкаустойчивости системы к воздействиям «негативного» рода: проверканеверного набора данных, проверка обработки исключительныхситуаций (как в реализации самих программных алгоритмов, так ив логике бизнес-правил) и т. п.

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

Как нужно расставлять приоритеты при тестировании? «Позитивное» тестирование считается на порядок более важным, чем «негативное». Предположим, что система не слишком устойчива к «плохим» вводимым данным. Это страшно? Зачастую не слишком. Пользователи могут научиться обходить «подводные камни», не будутделать «опасные» или «неразрешенные» действия, служба технической поддержки скоро запомнит, какие проблемы обычно возникаюту пользователей, и будет давать советы типа «ни в коем случае неоставляйте это поле пустым, а то…». Но если система не выполняетсвое основное предназначение, если пользователи (заказчики) немогут решить свои бизнес-задачи, если они все делают правильновводят хорошие данные, но не получают результата, то с такой системой никто работать не захочет. Такая система не выполняетсвоего основного предназначения. Поэтому «позитивное» тестирование гораздо важнее «негативного».

 

Виды тестирования

В настоящее время существует множество видов тестирования, ниже описаны наиболее распространенные.

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

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

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

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

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

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

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

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

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

Проверка совместимости. Основной целью данного вида тестирования является проверка корректной работы программного продукта в определенном окружении, в качестве которого может выступать, например, аппаратная платформа, сетевые устройства, периферийные устройства (принтеры, CD/DVD приводы, Web-камеры ипр.), операционная система (Windows, Unix, MACOS и т. д.), базыданных (Oracle, MS SQL, MYSQL и т. д.), системное программноеобеспечение (Web-сервер, фаервол, антивирус и т. д.), браузеры(InternetExplorer, Firefox, Opera, Chrome, Safariит. д.).

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

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

Одной из главных проблем автоматизированного тестированияявляется его трудоемкость: несмотря на то что оно позволяет устранить часть рутинных операций и ускорить выполнение тестов, большие ресурсы могут тратиться на обновление самих тестов, и это относится к обоим видам автоматизации. Автоматизация всех испытаний – очень дорогой процесс, и потому автоматическое тестированиеявляется лишь дополнением к ручному тестированию. Автоматические тесты не могут полностью заменить ручное тестирование.

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

Модульное тестирование не позволяет обнаружить все ошибки впрограмме. Это следует из практической невозможности трассировки всех вероятных путей выполнения программы, за исключениемпростейших случаев. Кроме того, происходит тестирование каждогоиз модулей по отдельности. Это означает, что ошибки интеграциисистемного уровня, функций, исполняемых в нескольких модуляхне будут определены. Кроме того, данная технология бесполезна дляпроведения тестов на производительность. Таким образом, модульноетестирование более эффективно в сочетании с другими методикамитестирования. Необходимо отметить, что для написания тестов можетпонадобиться написать большее количество кода, чем будет в самойпрограмме. Например, каждое возможное значение логической переменной потребует двух тестов: один на вариант true, другой – навариант false. В результате на каждую строку исходного кода потребуется 3 – 5 строк тестового кода.

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

Интеграционное тестирование является одной из фаз тестирования ПО, когда отдельные программные модули объединяются итестируются в группе. Обычно интеграционное тестирование проводится после модульного тестирования и предшествует системномутестированию. Интеграционное тестирование в качестве входныхданных использует модули, над которыми было проведено модульноетестирование, группирует их в более крупные структуры, выполняеттесты, определенные в плане тестирования для этих структур, и представляет их в качестве выходных данных и входных для последующего системного тестирования. Целью интеграционного тестированияявляется проверка соответствия проектируемых единиц функциональным, приемным требованиям и требованиям надежности. Тестирование этих проектируемых единиц (объединений или группмодулей) выполняется через их интерфейс, с использованием методологии тестирования «черного ящика».

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

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

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

 

Работа с ошибками

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

Главный компонент такой системы отслеживания ошибок – базаданных, содержащая сведения об обнаруженных дефектах.

В общем случае в составе информации об ошибке должно быть:

- номер (идентификатор) дефекта;

- кто сообщил о дефекте;

- дату и время, когда был обнаружен дефект;

- версия продукта, в которой обнаружен дефект;

- оценка степени серьезности (критичность) дефекта и приоритет решения;

- описание шагов для выявления дефекта (воспроизведения неправильного поведения программы);

- кто ответственен за устранение дефекта;

- обсуждение возможных решений и их последствий;

- текущее состояние (статус) дефекта;

- версия продукта, в которой дефект исправлен.

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

Система отслеживания ошибок использует тот или иной вариант «жизненного цикла» ошибки, стадия которого определяется текущимсостоянием (статусом), в котором находится ошибка.

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

 

Рисунок 17.2. Жизненный цикл ошибки.

 

Статус «Новый» определяет, что дефект зарегистрирован тестировщиком.

После назначения ответственного за исправление дефекта ошибка переходит в статус «Назначен».

Статус «Разрешен» определяет тот факт, что дефект переходитобратно в сферу ответственности тестировщика. Переход, как правило, сопровождается резолюцией, например: «Исправлено» (исправления включены в версию такую-то), «Дубль» (повторяет дефект, который уже находится в работе), «Не исправлено» (работает в соответствии со спецификацией, имеет слишком низкий приоритет, исправление отложено до следующей версии и пр.), «У меня всеработает» (запрос дополнительной информации об условиях, в которых дефект проявляется).

Далее тестировщик проводит проверку исправлений, в результате, которой дефект либо снова переходит в статус «Назначен» (если онописан как исправленный, но не исправлен), либо в статус «Закрыт».

Статус «Открыт повторно» свидетельствует о том, что дефектвновь найден в другой версии.

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