Преподаватель который помогает студентам и школьникам в учёбе.

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

Содержание:

ВВЕДЕНИЕ

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

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

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

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

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

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

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

1.1 Понятие «тестирование программного обеспечения»

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

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

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

Тестирование программного обеспечения в целом подразделяется на два типа: функциональное и нефункциональное тестирование. [2, 5]

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

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

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

Процесс тестирования программного обеспечения состоит из перечисленных ниже действий:

планирование и контроль;
анализ и проектирование;
внедрение и выполнение;
соответствие критериям выхода;
действия по закрытию теста. [1]

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

Автомобили Nissan должны отозвать с рынка более 1 миллиона автомобилей из-за сбоя программного обеспечения в сенсорных детекторах подушек безопасности. Там было зарегистрировано две аварии из-за этого сбоя программного обеспечения.
Starbucks был вынужден закрыть около 60 процентов магазинов в США и Канаде из-за сбоя программного обеспечения в своей системе POS-терминалов.
В 2015 году истребитель F-35 стал жертвой программной ошибки, из-за которой он не мог правильно определять цели.
Аэробус China Airlines A300 разбился из-за ошибки в программном обеспечении 26 апреля 1994 года, в результате чего 264 человека погибли.

1.2 Характеристика качества программного обеспечения

К характеристикам качества ПО можно отнести следующие:

Функциональность (Functionality) — определяется способностью ПО решать задачи, которые соответствуют зафиксированным и предполагаемым потребностям пользователя, при заданных условиях использования ПО. Т.е. эта характеристика отвечает за то, что ПО работает исправно и точно, функционально совместимо, соответствует стандартам отрасли и защищено от несанкционированного доступа.
Надежность (Reliability) – способность ПО выполнять требуемые задачи в обозначенных условиях на протяжении заданного промежутка времени или указанное количество операций. Атрибуты данной характеристики – это завершенность и целостность всей системы, способность самостоятельно и корректно восстанавливаться после сбоев в работе, отказоустойчивость.
Удобство использования (Usability) – возможность легкого понимания, изучения, использования и привлекательности ПО для пользователя.
Эффективность (Efficiency) – способность ПО обеспечивать требуемый уровень производительности в соответствие с выделенными ресурсами, временем и другими обозначенными условиями. [15]
Удобство сопровождения (Maintainability) – легкость, с которой ПО может анализироваться, тестироваться, изменяться для исправления дефектов, для реализации новых требований, для облегчения дальнейшего обслуживания и адаптироваться к именующемуся окружению.
Портативность (Portability) – характеризует ПО с точки зрения легкости его переноса из одного окружения (software/hardware) в другое.

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

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

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

Тем не менее, перед тем как автоматизировать тестирование любого приложения, необходимо сначала выполнить серию тестов вручную. Мануальное тестирование требует значительных усилий, но без него мы не сможем убедиться в том, возможна ли автоматизация в принципе. Один из фундаментальных принципов тестирования гласит: 100% автоматизация невозможна. Поэтому, ручное тестирование – необходимость. [13]

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

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

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

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

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

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

автоматизация тестирования кода (Code-driven testing) – тестирование на уровне программных модулей, классов и библиотек (фактически, автоматические юнит-тесты);
автоматизация тестирования графического пользовательского интерфейса (Graphical user interface testing) – специальная программа (фреймворк автоматизации тестирования) позволяет генерировать пользовательские события – нажатия клавиш, клики мышкой, и отслеживать реакцию программы на эти действия – соответствует ли она спецификации;
автоматизация тестирования API (ApplicationProgrammingInterface) – программного интерфейса программы. Тестируются интерфейсы, предназначенные для взаимодействия, например, с другими программами или с пользователем. Здесь опять же, как правило, используются специальные фреймворки.

Для составления автоматизированных тестов, QA-специалист должен уметь программировать. Автоматические тесты – это полноценные программы, просто предназначенные для тестирования. [13]

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

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

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

Вручную можно протестировать практически любое приложение, в то время как автоматизировать стоит только стабильные системы. Автоматизированное тестирование используется главным образом для регрессии. Кроме того, некоторые виды тестирования, например, ad-hoc или исследовательское тестирование могут быть выполнены только вручную.

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

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

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

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. Нагрузочное тестирование.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Недостатки:

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

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

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

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

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

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

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

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

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

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

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

Недостатки:

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

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

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

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

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

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

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

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

3. Отладка программ

3.1 Методика отладки программ

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

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

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

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

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

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

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

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

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

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

3.2 Статические анализаторы кода

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

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

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

Недостатков у такого метода немало. Основным является то, что множество "подозрительных" конструкций в коде не всегда являются дефектами. В большинстве случаев такой код может быть синтаксически правильным и работать корректно. Соотношение "шума" к реальным дефектам может достигать 100:1 на больших проектах. Таким образом, разработчику приходится тратить много времени на его отсеивание от реальных дефектов, что отменяет плюсы автоматизированного поиска.

Cppcheck — это инструмент статического анализа для кода C/C++. В отличие от компиляторов C/C++ и многих других инструментов анализа он не обнаруживает синтаксических ошибок в коде. Cppcheck в первую очередь обнаруживает типы ошибок, которые компиляторы обычно не обнаруживают. Цель состоит в том, чтобы обнаружить только реальные ошибки в коде (т. Е. Иметь нулевые ложные срабатывания). [11]

Особенности:

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

CppCat — это плагин для Microsoft Visual Studio, который находит более сложные ошибки в коде на C/C++ (логические ошибки, опечатки, ошибки неопределенного поведения и др.) в дополнение к обычным предупреждениям компилятора. CppCat был разработан специально для программистов на C/C++, использующих Visual Studio, что позволило учесть особенности и потребности именно этой узкой группы. [10]

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

Ключевые особенности CppCat:

легкий поиск ошибок в коде на С/C++;
проверка всего кода проекта и список всех найденных ошибок;
возможность автоматической проверки перекомпилированных файлов и список ошибок, найденных только в этих файлах;
для работы требуется Microsoft Visual Studio.

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

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

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

Основная ценность статического анализа заключается в его регулярном использовании, благодаря чему многие ошибки могут быть выявлены и устранены на самых ранних этапах. Нет смысла тратить 50 часов на поиск ошибки, которую можно найти благодаря анализу кода. Но еще раз подчеркнем. Основная польза статического анализа не в том, чтобы найти одну запрятанную ошибку в день перед релизом. А регулярно устранять десятки обычных ошибок день за днем. [11]

Анализатор может запускаться ночью на сервере и сообщать о подозрительных местах в новом коде. Ошибки вообще могут быть обнаружены и исправлены ещё до попадания в репозиторий. PVS-Studio может автоматически запускаться сразу после компилятора на только что модифи PVS-Studio умеет интегрироваться в среду разработки Visual Studio 2010-2017. Если используется эта среда разработки, то скорее всего будет достаточно зайти в меню плагина PVS-Studio и выбрать команду "проверить проект".

Часто всё обстоит сложнее и может потребоваться интеграция PVS-Studio в сборочную систему, в том числе.

PVS-Studio для Windows и Linux предусмотрены специальные утилиты, собирающие информацию о запусках компилятора. Эти инструменты позволяют быстро выполнить анализ проекта, собираемого любым способом.

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

Сопоставление с шаблоном (pattern-based analysis) на основе абстрактного синтаксического дерева применяется для поиска мест в исходном коде, которые похожи на известные шаблоны кода с ошибкой.
Вывод типов (type inference) на основе семантической модели программы позволяет анализатору иметь полную информацию о всех переменных и выражениях, встречающихся в коде.
Символьное выполнение (symbolic execution) позволяет вычислять значения переменных, которые могут приводить к ошибкам, производить проверку диапазонов (range checking) значений.
Анализ потока данных (data-flow analysis) используется для вычисления ограничений, накладываемых на значения переменных при обработке различных конструкций языка. Например, какие значения может принимать переменная внутри блоков if/else.
Аннотирование методов (method annotations) предоставляет больше информации об используемых методах, чем может быть получено путём анализа только их сигнатуры. [11]

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

ЗАКЛЮЧЕНИЕ

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

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

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

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

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

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

СПИСОК ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫ

Корнеев И.К., Машурцев ВА. Информационные технологии в управлении. - М.: Инфр-М, 2001.
Кузнецов, П.У. Информационные технологии / П.У. Кузнецов. ― М.: Юрайт, 2011. ― 422 с.
Кент Бек Экстремальное программирование. Разработка через тестирование. — Питер, 2003. — 260 с.
Могилев А.В. Информатика : учебное пособие / А.В. Могилев, Н.И. Пак, Е.К. Хеннер. – М.: Академия, 2000. – 324 с.
Плаксин М. А. Тестирование и отладка программ для профессионалов будущих и настоящих. — Лаборатория знаний, 2015. — 170 с.
Рой Ошероув Искусство автономного тестирования с примерами на C#. — ДМК Пресс, 2014. — 362 с.
John R. Vacca Computer and Information Security Handbook. — Morgan Kaufmann, 2017. — 1280 с.
Мартин Роберт Идеальный программист. Как стать профессионалом разработки ПО. — Питер, 2011. — 240 с.
Software Testing [Электронный ресурс] Тестирование по фазам и по цепочкам: сходства и различия
Блог хост [Электронный ресурс] Анализаторы исходного кода — обзор рынка в России и в мире
PVS-Studio [Электронный ресурс] Анализатор PVS-Studio
QALight [Электронный ресурс] White/Black/Grey Box-тестирование
QALight [Электронный ресурс] Ручное и автоматизированное
Технология программирования [Электронный ресурс] Методы отладки программного обеспечения.
QALight [Электронный ресурс] Качество программного обеспечения.