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

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

Содержание:

ВВЕДЕНИЕ

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

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

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

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

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

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

1. Введение в тестирование программного обеспечения

1.1 Основные термины и определения

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

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

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

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

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

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

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

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

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

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

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

Доказательство – попытка найти ошибки в программе безотносительно к внешней для программы среде. Большинство методов доказательства предполагает формулировку утверждений о поведении программы и затем вывод и доказательство математических теорем о правильности программы. Доказательства могут рассматриваться как форма тестирования, хотя они и не предполагают прямого выполнения программы. Многие исследователи считают доказательство альтернативой тестированию -- взгляд во многом ошибочный. [8]

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

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

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

1.2 Особенности программного обеспечения

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

Программное обеспечение можно рассматривать как переменную часть компьютера, а аппаратную часть — неизменную часть. Один из видов классификации программного обеспечения показан на рисунке 1. Программное обеспечение часто подразделяется на прикладное программное обеспечение (программы, которые работают, в которых непосредственно заинтересованы пользователи) и системное программное обеспечение (которое включает в себя операционные системы и любую программу, которая поддерживает прикладное программное обеспечение). Термин промежуточное программное обеспечение иногда используется для описания программирования, которое является посредником между прикладным и системным программным обеспечением или между двумя различными типами прикладного программного обеспечения (например, отправка запроса удаленной работы из приложения на компьютере, на котором установлена операционная система одного типа, в приложение в компьютер с другой операционной системой). [6]

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

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

$D:\stud\3 - Отладка и тестирование программ основные подходы и ограничения\Классификация ПО.png$

Рисунок 1 – Классификация ПО

Свободное программное обеспечение, несколько более новая и не связанная с этим концепция, — это программное обеспечение, которое можно свободно использовать, модифицировать и распространять только с одним ограничением: любая распространяемая версия программного обеспечения должна распространяться с оригинальными условиями бесплатного использования, модификации и распространения (известны как авторское право). В отличие от бесплатного программного обеспечения, бесплатное программное обеспечение может распространяться за плату. Бесплатное программное обеспечение может быть более ограниченным в возможностях, чем свободное программное обеспечение. [3]

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

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

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

Дополнительной и трудно классифицируемой категорией программного обеспечения является утилита, которая представляет собой небольшую полезную программу с ограниченными возможностями. Некоторые утилиты поставляются с операционными системами. Как и приложения, утилиты, как правило, устанавливаются отдельно и могут использоваться независимо от остальной части операционной системы. Например, апплеты — это небольшие приложения, которые иногда поставляются с операционной системой как «аксессуары». Они также могут быть созданы независимо с использованием Java или других языков программирования. [6]

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

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

Некоторые общие виды прикладного программного обеспечения включают в себя:

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

В данной главе были рассмотрены основные понятия и определения, которые относятся к тестированию программного обеспечения, приведен один из видов классификации ПО,

2. Современные методы тестирования ПО

2.1 Критерия тестирования программного обеспечения

Можно выделить требования к идеальному критерию тестирования:

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

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

Классы критериев:

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

2.2 Виды тестирования программного обеспечения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

$D:\author24\Создание программного комплекса для синхронизации разнородных данных между компьютерными устройствами\Альфа тестирование.png$

Рисунок 2 – Бета тестирование с пользователями

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.3 Отличие автоматизированного тестирования от ручного

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

Автоматизированное тестирование – это процессы, которые запускают программы и скрипты для тестирования отдельных модулей, используя повторяющиеся действия. Фактически, это значит, что программа запускает определенные скрипты, чтобы проверить все составляющие проекта и оценить его. Для того, чтобы создать программу тестирования требуются определенные ресурсы. [14]

В автоматизированном тестировании должен присутствовать тестировщик, который создаст программу и затем будет ее запускать. Наиболее популярной программой тестирования является Selenium Web Driver IDE. Используя язык Java или Python можно начать тестирование.

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

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

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

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

Ручное тестирование – это процессы через которые разработчики, или manual QA тестировщик тестируют продукт: вебсайт, платформу, SaaS, что угодно чтобы найти дефекты и ошибки. Ручное тестирование идеально подходит для тех проектов с малым бюджетом, либо же краткосрочных (до 2 месяцев). Ручное тестирование проходит от лица тестировщика, который выступает как конечный пользователь системы. [14]

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

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

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

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

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

2.4 Тестирование «белого» и «черного» ящиков

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

Если альфа- и бета-тестирование относятся к стадиям до выпуска продукта (а также, неявно, к объему тестирующего сообщества и ограничениям на методы тестирования), тестирование «белого ящика» и «черного ящика» имеет отношение к способам, которыми тестировщик достигает цели. [12]

Чуть меньшее количество тестировщиков тестируют стратегией серого ящика, который подразумевает частичный доступ, например, к структуре баз данных или наборов параметров, которые принимают сервисы. Краткое пояснения по всем видам «ящиков» представлено на рисунке 3.

$D:\stud\3 - Отладка и тестирование программ основные подходы и ограничения\ящики.png$

Рисунок 3 – Виды «ящиков»

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

2.5 Особенности отладки программ

Отладка не является разновидностью тестирования. Хотя слова «отладка» и «тестирование» часто используются как синонимы, под ними подразумеваются разные виды деятельности. Тестирование – деятельность, направленная на обнаружение ошибок; отладка направлена на установление точной природы известной ошибки, а затем – на исправление этой ошибки. Эти два вида деятельности связаны – результаты тестирования являются исходными данными для отладки. Отладка – это процесс локализации и исправления ошибок в программе. [9]

Отладка бывает двух видов:

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

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

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

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

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

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

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

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

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

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

$D:\stud\3 - Отладка и тестирование программ основные подходы и ограничения\Ошибки.png$

Рисунок 4 – Виды ошибок

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

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

ЗАКЛЮЧЕНИЕ

Целью данной работы было рассмотрение вопросов касательно тестирования программного обеспечения.

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

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

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

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

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

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

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

Вольфсон Б. Гибкое управление проектами и продуктами. — Питер, 2016. — 160 с.
Джефф Сазерленд Scrum. Революционный метод управления проектами. — Манн, Иванов и Фербер (МИФ), 2014. — 320 с.
Плаксин М. А. Тестирование и отладка программ для профессионалов будущих и настоящих. — Лаборатория знаний, 2015. — 170 с.
Мартин Роберт Идеальный программист. Как стать профессионалом разработки ПО. — Питер, 2011. — 240 с.
Рой Ошероув Искусство автономного тестирования с примерами на C#. — ДМК Пресс, 2014. — 362 с.
Bittner K., Spence I. Managing Iterative Software Development Projects. – Addison Wesley Professional, 2016.
John R. Vacca Computer and Information Security Handbook. — Morgan Kaufmann, 2017. — 1280 p.
Software Testing [Электронный ресурс] Тестирование по фазам и по цепочкам: сходства и различия Режим доступа: http://software-testing.ru/library/testing/general-testing/2682-phased-vs-threaded-testing Дата обращения (07.02.2020)
Блог хост [Электронный ресурс] Анализаторы исходного кода — обзор рынка в России и в мире Режим доступа: https://www.anti-malware.ru/reviews/Code_analyzers_market_overview_Russia_and_world Дата обращения (07.02.2020)
QALight [Электронный ресурс] White/Black/Grey Box-тестирование Режим доступа: https://qalight.com.ua/baza-znaniy/white-black-grey-box-testirovanie/ Дата обращения (07.02.2020)
QALight [Электронный ресурс] Ручное и автоматизированное Режим доступа: https://qalight.com.ua/baza-znaniy/ruchnoe-i-avtomatizirovannoe/ Дата обращения (07.02.2020)
Технология программирования [Электронный ресурс] Методы отладки программного обеспечения. Режим доступа: http://www.tehprog.ru/index.php_page=lecture0113.html Дата обращения (07.02.2020)
QALight [Электронный ресурс] Качество программного обеспечения. Режим доступа: https://qalight.com.ua/baza-znaniy/kachestvo-programmnogo-obespecheniya/ Дата обращения (07.02.2020)
Merehead [Электронный ресурс] Автоматизированное или ручное тестирование – что выбрать? Режим доступа: https://merehead.com/ru/blog/manual-testing-vs-automated-testing-difference-definition-tools/ Дата обращения (07.02.2020)