Отладка и тестирование программ: основные подходы и ограничения (Исследование предметной области)

Содержание:

ВВЕДЕНИЕ

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

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

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

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

Цель данной работы исследование вопросов отладки и тестирования программных продуктов. Объектом исследования данной работы является процесс разработки программного обеспечения, а предметом исследования отладка и тестирование программ.

В рамках курсового проекта должны быть решены следующие задачи:

• изучить литературу в данной области;
• раскрытие понятия «качество»;
• изучить понятие «верификация»;
• изучить виды тестирования;
• провести анализ методов отладки программ.

Для выполнения работы были изучена литература в области отладки и тестирования программных продуктов.

1. Исследование предметной области

1.1 Анализ понятия «качество»

Качество программного обеспечения (Software quality) — это то насколько программное обеспечение удовлетворяет предъявляемым к нему требованиям. Выдвигаемые требования могут зависеть от многих критериев, определяемых исходя из сферы применения программного продукта.

Качество программного обеспечения является постоянным объектом заботы программной инженерии и обсуждается во многих областях знаний.

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

«Приемлемое качество» можно сравнивать с уровнем обслуживания в рамках заданного SLA – Service Level Agreement. То есть, приемлемое качество может рассматриваться как <количественно выраженный> компромисс между заказчиком и исполнителем в отношении характеристик продукта, создаваемого исполнителем в интересах <решения задач> заказчика с учетом других ограничений проекта (в частности, стоимостью, что часто именуется как «cost of quality» – «стоимость качества»).

Согласие, достигнутое по требованиям к качеству (в оригинале — quality requirements), наравне с четким доведением до инженеров того, что составляет качество получаемого продукта, требуют обсуждения и формального определения многих аспектов качества. [7, 8, 16]

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

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

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

Можно выделить несколько основных критериев оценки качества программного обеспечения:

1. Качество исходного кода.

• соответствие кода стандартам;
• легкость поддержки;
• малое число предупреждений при компиляции.

2. Качество программного продукта.

• функциональность;
• надежность;
• удобство использования;
• эффективность;
• безопасность.

Становится понятно, что предъявляемые требования должны удовлетворять потребностям, как разработчиков программного обеспечения, так и его пользователей. [7, 8, 16]

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

• тестирование (модульное, интеграционное, системное, регрессионное);
• статический анализ кода;
• динамический анализ кода;
• просмотр исходных кодов программы (обзор кода).

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

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

Ожидается, что инженеры по программному обеспечению воспринимают вопросы качества программного обеспечения как часть своей профессиональной культуры. [7, 8, 16]

Этические аспекты могут играть значительную роль в обеспечении качества программного обеспечения, культуре и отношении инженеров <к своей работе>. IEEE Computer Society и ACM разработали кодекс этики (“моральный кодекс” – code of ethics) и профессиональной практики, основанный на восьми принципах, помогающих инженерам укрепить их отношение к качеству и независимость в решении вопросов обеспечения достойного качества создаваемых программных продуктов в их повседневной работе.

Понятие “качество”, на самом деле, не столь очевидно и просто, как это может показаться на первый взгляд. Для любого инженерного продукта существует множество интерпретаций качества, в зависимости от конкретной “системы координат”. Характеристики качества могут требоваться в той или иной степени, могут отсутствовать или могут задавать определенные требования, все это может быть результатом определенного компромисса. [16]

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

1.2 Верификация

Проверка и аттестация программного обеспечения – упорядоченный подход в оценке программных продуктов, применяемый на протяжении всего жизненного цикла. Усилия, прилагаемые в рамках работ по проверке и аттестации, направлены на обеспечение качества как неотъемлемой характеристики программного обеспечения и удовлетворение пользовательских требований. [16]

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

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

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

Аттестация – попытка обеспечить создание правильного продукта (построен правильный продукт; обычно, в контексте конечного продукта), с точки зрения достижения поставленной цели.

Оба процесса – верификация и аттестация – начинаются на ранних стадиях разработки и сопровождения. Они обеспечивают исследованию (экспертизу) ключевых возможностей продукта как в контексте непосредственно предшествующих результатов (промежуточных продуктов), так и с точки зрения удовлетворения соответствующих спецификаций. Целью планирования V&V является обеспечение процессов верификации и аттестации необходимыми ресурсами, четкое назначение ролей и обязанностей. Получаемый план V&V документирует и <детально> описывает различные ресурсы, роли и действия, а также используемые техники и инструменты.

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

1.3 Тестирование программных продуктов

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

Процесс должен начинаться, как только началась разработка ПО, чтоб уже к первой сборке проекта был некоторый план тестирования. В первую очередь проводится дымовое тестирование — это совокупность общих, критических сценариев, которые проверяют основную функциональность. На основе этого делается вывод о возможности и целесообразности дальнейшего тестирования. Далее основная работа централизованное тестирование по тест-кейсам и/или исследовательское тестирование. Процесс завершается написанием отчета и предоставлением баг-репортов. С процессом тестирования связано еще одно интересное понятие – это тест дизайн. Тест дизайн — это процесс проектирования определенных тестовых случаев в соответствии с определенными критериями. [7, 8, 14]

При тестировании ПО должен быть отдельный сервер, виртуальный или реальный, на котором для тестировщика есть некоторая сборка с которой работает только он.

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

В данной главе были раскрыты теоретические основы понятия тестирования программ, рассмотрено понятие «качество» ПО.

2. Тестирование программных продуктов

2.1 Классификация видов тестирования

Существует большое количество видов тестирования. Типы функционального тестирования включают в себя:

• модульное тестирование;
• интеграционное тестирование;
• системное тестирование;
• санитарное тестирование;
• дымовое тестирование;
• тестирование интерфейса;
• регрессионное тестирование;
• бета тестирование.

Нефункциональные типы тестирования включают в себя:

• тестирование производительности;
• нагрузочное тестирование;
• стресс-тестирование;
• объемное тестирование;
• тестирование безопасности;
• тестирование совместимости;
• тестирование на восстановление
• Тестирование стабильности;
• юзабилити-тестирование;
• тестирование на соответствие;
• тестирование локализации. [3]

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

1. Альфа-тестирование.

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

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

2. Приемочные испытания.

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

Это последний этап тестирования, после которого программное обеспечение запускается в производство. Оно также называется пользовательским приемочным тестированием.

3. Специальное тестирование.

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

Специальное тестирование является неофициальным способом поиска дефектов и может быть выполнено любым участником проекта. Трудно идентифицировать дефекты без тестового случая, но иногда возможно, что дефекты, обнаруженные во время специального тестирования, могли не быть идентифицированы с использованием существующих тестовых случаев. [4, 7]

4. Тестирование доступности.

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

5. Бета-тестирование.

Бета-тестирование является формальным типом тестирования программного обеспечения, которое проводится заказчиком. Он выполняется в реальной среде перед выпуском продукта на рынок для реальных конечных пользователей.

Бета-тестирование проводится для того, чтобы убедиться в отсутствии серьезных сбоев в программном обеспечении или продукте, и оно удовлетворяет бизнес-требованиям с точки зрения конечного пользователя. Бета-тестирование заканчивается успешно, когда клиент принимает программное обеспечение.

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

Таким образом, конечный пользователь фактически использует программное обеспечение и делится обратной связью с компанией. Затем компания предпринимает необходимые действия перед выпуском программного обеспечения по всему миру. [4]

6. Внутреннее тестирование.

Всякий раз, когда ввод или данные вводятся во внешнем приложении, они сохраняются в базе данных, и тестирование такой базы данных называется тестированием базы данных или внутренним тестированием. Существуют различные базы данных, такие как SQL Server, MySQL, Oracle и т. д. Тестирование базы данных включает в себя тестирование структуры таблицы, схемы, хранимой процедуры, структуры данных и так далее.

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

7. Тестирование совместимости браузеров.

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

8. Тестирование обратной совместимости.

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

9. Тестирование черного ящика.

Внутренний дизайн системы не рассматривается в этом типе тестирования. Тесты основаны на требованиях и функциональности. [7]

10. Тестирование граничных значений.

Этот тип тестирования проверяет поведение приложения на граничном уровне. Тестирование проводится для проверки наличия дефектов на граничных значениях. Тестирование граничного значения используется для тестирования другого диапазона чисел. Существует верхняя и нижняя границы для каждого диапазона, и тестирование проводится на этих граничных значениях.

Если для тестирования требуется диапазон значений от 1 до 500, то тестирование граничных значений выполняется для значений 0, 1, 2, 499, 500 и 501.

11. Тестирование веток.

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

12. Сравнительное тестирование.

Сравнение сильных и слабых сторон продукта с его предыдущими версиями или другими подобными продуктами называется сравнительным тестированием.

13. Тестирование на совместимость.

Это тип тестирования, в котором проверяется, как программное обеспечение ведет себя и работает в другой среде, веб-серверах, оборудовании и сетевой среде. Тестирование совместимости гарантирует, что программное обеспечение может работать в другой конфигурации, другой базе данных, разных браузерах и их версиях. Тестирование на совместимость выполняется командой тестирования. [7]

14. Тестирование компонентов.

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

15. Сквозное тестирование.

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

16. Эквивалентное разбиение.

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

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

Предположим, что приложение принимает значения в диапазоне от -10 до +10, поэтому с помощью эквивалентного разделения значения, выбранные для тестирования, равны нулю, одному положительному значению, одному отрицательному значению. Таким образом, Эквивалентное разбиение для этого теста: -10 до -1, 0 и от 1 до 10.

17. Тестирование примеров.

Это означает тестирование в реальном времени. Пример тестирования включает сценарий в реальном времени, а также сценарии, основанные на опыте тестировщиков.

18. Исследовательское тестирование.

Исследовательское тестирование — это неформальное тестирование, проводимое командой тестирования. Целью этого тестирования является изучение приложения и поиск дефектов, которые существуют в приложении. Иногда может случиться так, что во время этого теста обнаруженный серьезный дефект может даже вызвать системный сбой. [7]

Методика поисковых испытаний выполняется без документации и контрольных примеров.

20. Функциональное тестирование.

Этот тип тестирования игнорирует внутренние детали и фокусируется только на выводе, чтобы проверить, соответствует ли он требованиям или нет. Это тестирование типа «черного ящика», ориентированное на функциональные требования приложения.

21. Тестирование графического интерфейса пользователя.

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

Это тестирование включает в себя размер кнопок и поля ввода, представленные на экране, выравнивание всего текста, таблиц и содержимого таблиц.

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

22. Тестирование инкрементной интеграции

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

23. Интеграционное тестирование.

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

24. Нагрузочное тестирование.

Это тип нефункционального тестирования, и целью нагрузочного тестирования является проверка того, какую максимальную рабочую нагрузку может выдержать система без какого-либо снижения производительности. [8]

Нагрузочное тестирование помогает определить максимальную емкость системы при определенной нагрузке и любых проблемах, которые вызывают снижение производительности программного обеспечения. Нагрузочное тестирование выполняется с использованием таких инструментов, как JMeter, LoadRunner, WebLoad, Silk Performer и т.д.

25. Тестирование мутаций.

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

26. Нефункциональное тестирование.

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

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

Загрузка любой страницы или системы не должна занимать много времени и должна выдерживать пиковую нагрузку. [8]

27. Тестирование производительности

Этот термин часто используется взаимозаменяемо с «стрессовым» и «нагрузочным» тестированием. Тестирование производительности проводится для проверки соответствия системы требованиям к производительности. Для этого тестирования используются разные инструменты производительности и нагрузки.

28. Регрессионное тестирование

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

29. Тестирование безопасности

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

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

30. Дымовое тестирование.

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

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

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

31. Статическое тестирование.

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

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

32. Стресс-тестирование.

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

33. Тестирование системы.

В соответствии с методикой тестирования системы вся система тестируется в соответствии с требованиями. Это типовое тестирование типа «черный ящик», которое основано на общих требованиях спецификации и охватывает все объединенные части системы. [8]

34. Модульное тестирование.

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

35. Юзабилити-тестирование.

В этапе «Юзабилити-тестирование» выполняется проверка на удобство использования. Приложение проверяется на то, чтобы узнать, может ли новый пользователь легко понять приложение. В основном, системная навигация проверяется в этом тестировании.

36. Объемное тестирование.

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

2.2 Автоматизированное и ручное тестирование

При ручном тестировании (manualtesting) тестировщики вручную выполняют тесты, не используя никаких средств автоматизации. Ручное тестирование – самый низкоуровневый и простой тип тестирования, не требующих большого количества дополнительных знаний. [14]

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

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

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

Плюсы ручного тестирования:

1. Пользовательский фидбек. Весь отчёт тестировщика может быть рассмотрен как обратная связь от потенциального пользователя.
2. UI-фидбек. В наше время пользовательский интерфейс играет огромную роль, и поэтому полностью протестировать его можно только вручную. Кстати, знаете ли вы, какие 7 элементов интерфейса вам лучше убрать с вашего сайта?
3. Дешевизна. В краткосрочной перспективе ручное тестирование дешевле, чем инструменты автоматизированной проверки.
4. Тестирование в реальном времени. Незначительные изменения могут быть исследованы сразу, без написания кода и его исполнения.
5. Возможность исследовательского тестирования. Его целью является проверка разнообразных возможностей приложения. Важно, что используются не заранее составленные тест-кейсы, а придуманные на лету сценарии.

Минусы ручного тестирования:

1. Человеческий фактор. Хотя UI и может быть протестирован только вручную, люди часто склонны к неэффективности. Некоторые ошибки могут остаться незамеченными.
2. Трудоемкость повторного использование. Провести серию стандартных автоматических тестов проще, чем протестировать проект вручную после внесения даже небольших изменений.
3. Невозможность нагрузочного тестирования. Нельзя смоделировать большое количество пользователей вручную. [14]

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

Плюсы автоматизированного тестирования:

1. Возможность нагрузочного тестирования. Можно достаточно быстро смоделировать большое количество пользователей.
2. Экономия времени. Ручное тестирование больших приложений — долгий и трудоёмкий процесс, в то время как сценарии пишутся лишь один раз.
3. Возможность повторного использования. Тестовый сценарий, написанный один раз, может быть использован и в будущем при очередном обновлении проекта.

Минусы автоматизированного тестирования:

1. Дороговизна. Инструменты автоматизированного тестирования, а также обучение их использованию стоят недёшево, поэтому нужно тщательно оценивать бюджет.
2. UI-тестирование. Автоматизированное тестирование не может в полной мере покрыть требования к пользовательскому интерфейсу.
3. Отсутствие «человеческого взгляда». Возможно существование ошибок, которые заметит только человек. [14]

2.3 Методы «белого» и «черного» ящиков

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

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

Согласно ISTQB тестирование черного ящика – это:

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

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

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

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

Пример: тестировщик проводит тестирование веб-сайта, не зная особенностей его реализации, используя только предусмотренные разработчиком поля ввода и кнопки. Источник ожидаемого результата – спецификация. [13]

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

Техника черного ящика применима на всех уровнях тестирования (от модульного до приемочного), для которых существует спецификация. Например, при осуществлении системного или интеграционного тестирования, требования или функциональная спецификация будут основой для написания тест-кейсов.

Техники тест-дизайна, основанные на использования черного ящика, включают:

• классы эквивалентности;
• анализ граничных значений;
• таблицы решений;
• диаграммы изменения состояния;
• тестирование всех пар.

Преимущества:

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

Недостатки:

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

Противоположностью техники черного ящика является тестирование методом белого ящика, речь о котором пойдет ниже. [13]

Тестирование методом белого ящика (также: прозрачного, открытого, стеклянного ящика; основанное на коде или структурное тестирование) – метод тестирования программного обеспечения, который предполагает, что внутренняя структура/устройство/реализация системы известны тестировщику. Мы выбираем входные значения, основываясь на знании кода, который будет их обрабатывать. Точно так же мы знаем, каким должен быть результат этой обработки. Знание всех особенностей тестируемой программы и ее реализации – обязательны для этой техники. Тестирование белого ящика – углубление во внутренне устройство системы, за пределы ее внешних интерфейсов. [13]

Согласно ISTQB тестирование белого ящика – это:

• тестирование, основанное на анализе внутренней структуры компонента или системы;
• тест-дизайн, основанный на технике белого ящика – процедура написания или выбора тест-кейсов на основе анализа внутреннего устройства системы или компонента.

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

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

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

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

Преимущества:

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

Недостатки:

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

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

Эту технику тестирования также называют методом полупрозрачного ящика: что-то мы видим, а что-то – нет.

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

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

Таблица 1 —Сравнительный анализ «белого» и «черного» ящиков [12]

Критерий	Черный ящик	Белый ящик
Определение	Тестирование, как функциональное, так и нефункциональное, не предполагающее знание внутреннего устройства компонента или системы	Тестирование, основанное на анализе внутренней структуры компонента или системы
Уровни, к которым применима техника	В основном: Приемочное тестирование и системное тестирование	В основном; Юнит-тестирование и интеграционное тестирование
Кто выполняет	Как правило, тестировщики	Как правило, разработчики
Знание программирования	Не нужно	Необходимо
Знание реализации	Не нужно	Необходимо
Основа для тест-кейсов	Спецификация, требования	Проектная документация

2.4 Отладка программ

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

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

Статические методы включают:

• ручную прокрутку программы;
• прокрутку программы программными анализаторами ( нап­ример, компилятором); автоматизированный анализ программы в этом случае проводится без выполнения ее на ЭВМ и поэтому попадает в категорию «статических»;
• коллективную проверку программ;
• проверку программы программистом-технологом с целью выявления и исправления в ней технологических ошибок.

Экспериментально установлено, что в программах ручными методами удается обнаруживать от 30 до 70 % программных и алгоритмических ошибок из общего числа ошибок, выявленных при отладке. При этом одновременно осуществляется доработка программ с целью улучшения их структуры, логики обработки данных и для снижения сложности последующего автомати­зированного тестирования на ЭВМ. [15]

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

К динамическим методам относятся:

• тестирование;
• поиск ошибок с использованием системных средств;
• отладка программы в интерактивном режиме.

Важнейшее правило отладки: не делать следующего выхода на ЭВМ, пока не будет разобрана каждая найденная ошибка. Из этого правила существует единственное исключение: если най­дены 5—6 ошибок, которые не дают эффекта, то можно сделать новый выход на машину (устранив эти ошибки), чтобы получить эффект в чистом виде (если он есть), поскольку наложение нес­кольких ошибок иногда может дать самый неожиданный ре­зультат. [15]

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

В данной главе были изучены виды тестирования и проанализирована методика отладки программ.

ЗАКЛЮЧЕНИЕ

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

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

• крайние сроки тестирования;
• завершение цикла выполнения тестового набора;
• завершение функционального тестирования и покрытия кода до согласованного предела;
• не обнаружена ошибка с высоким приоритетом и скорость обнаружения ошибка снижается после определенного уровня.

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

В рамках курсового проекта решены следующие задачи:

• изучена литература в данной области;
• раскрыто понятие «качество»;
• изучено понятие «верификация»;
• изучены виды тестирования;
• проведен анализ методов отладки программ.

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

Данная работа может быть расширена более глубоким изучением существующих видов тестирования.

СПИСОК ЛИТЕРАТУРЫ

1. Корнеев И.К., Машурцев ВА. Информационные технологии в управлении. - М.: Инфр-М, 2001.
2. Кузнецов, П.У. Информационные технологии / П.У. Кузнецов. ― М.: Юрайт, 2011. ― 422 с.
3. Кент Бек Экстремальное программирование. Разработка через тестирование. — Питер, 2003. — 260 с.
4. Могилев А.В. Информатика : учебное пособие / А.В. Могилев, Н.И. Пак, Е.К. Хеннер. – М.: Академия, 2000. – 324 с.
5. Плаксин М. А. Тестирование и отладка программ для профессионалов будущих и настоящих. — Лаборатория знаний, 2015. — 170 с.
6. Рой Ошероув Искусство автономного тестирования с примерами на C#. — ДМК Пресс, 2014. — 362 с.
7. John R. Vacca Computer and Information Security Handbook. — Morgan Kaufmann, 2017. — 1280 p.
8. Bill Laboon A Friendly Introduction to Software Testing. — CreateSpace Independent Publishing Platform, 2016. — 230 p.
9. Мартин Роберт Идеальный программист. Как стать профессионалом разработки ПО. — Питер, 2011. — 240 с.
10. Software Testing [Электронный ресурс] Тестирование по фазам и по цепочкам: сходства и различия Режим доступа: http://software-testing.ru/library/testing/general-testing/2682-phased-vs-threaded-testing Дата обращения (12.02.2019)
11. Блог хост [Электронный ресурс] Анализаторы исходного кода — обзор рынка в России и в мире Режим доступа: https://www.anti-malware.ru/reviews/Code_analyzers_market_overview_Russia_and_world Дата обращения (12.02.2019)
12. PVS-Studio [Электронный ресурс] Анализатор PVS-Studio Режим доступа: https://www.viva64.com/ru/pvs-studio/ Дата обращения (12.02.2019)
13. QALight [Электронный ресурс] White/Black/Grey Box-тестирование Режим доступа: https://qalight.com.ua/baza-znaniy/white-black-grey-box-testirovanie/ Дата обращения (12.02.2019)
14. Tproger [Электронный ресурс] Ручное и автоматизированное тестирование: рассматриваем преимущества и недостатки подходов Режим доступа: https://tproger.ru/translations/manual-automation-testing/ Дата обращения (20.03.2019)
15. Технология программирования [Электронный ресурс] Методы отладки программного обеспечения. Режим доступа: http://www.tehprog.ru/index.php_page=lecture0113.html Дата обращения (20.03.2019)
16. Business Analysis [Электронный ресурс] Качество программного обеспечения (Software Quality). Режим доступа: https://iiba.ru/software-quality/ Дата обращения (20.03.2019)