Основы тестирования и отладки программ#

Тестирование программного обеспечения — процесс исследования, испытания программного продукта, имеющий своей целью проверку соответствия между реальным поведением программы и её ожидаемым поведением на конечном наборе тестов, выбранных определённым образом (ISO/IEC TR 19759:2005)

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

Для чего проводится тестирование ПО?

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

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

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

Дефект (bug) — отклонение фактического результата от ожидаемого.

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

Основополагающим документом для классификации видов тестирования является стандарт ISO (ISO/IEC TR 19759:2005) и ГОСТ Р 56920-2016/ISO/IEC/IEEE 29119-1:2013 Системная и программная инженерия. Тестирование программного обеспечения. Понятия и определения.

Классификация по запуску кода на исполнение:

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

• Тестирование белого ящика — метод тестирования ПО, который предполагает полный доступ к коду проекта.
• Тестирование серого ящика — метод тестирования ПО, который предполагает частичный доступ к коду проекта (комбинация White Box и Black Box методов).
• Тестирование чёрного ящика — метод тестирования ПО, который не предполагает доступа (полного или частичного) к системе. Основывается на работе исключительно с внешним интерфейсом тестируемой системы.
Классификация по уровню детализации приложения:

• Модульное тестирование — проводится для тестирования какого-либо одного логически выделенного и изолированного элемента (модуля) системы в коде. Проводится самими разработчиками, так как предполагает полный доступ к коду.
• Интеграционное тестирование — тестирование, направленное на проверку корректности взаимодействия нескольких модулей, объединенных в единое целое.
• Системное тестирование — процесс тестирования системы, на котором проводится не только функциональное тестирование, но и оценка характеристик качества системы — ее устойчивости, надежности, безопасности и производительности.
• Приёмочное тестирование — проверяет соответствие системы потребностям, требованиям и бизнес-процессам пользователя.
Классификация по степени автоматизации:

• Ручное тестирование.
• Автоматизированное тестирование.
Классификация по принципам работы с приложением

• Позитивное тестирование — тестирование, при котором используются только корректные данные.
• Негативное тестирование — тестирование приложения, при котором используются некорректные данные и выполняются некорректные операции.
Классификация по уровню функционального тестирования:

• Дымовое тестирование (smoke test) — тестирование, выполняемое на новой сборке, с целью подтверждения того, что программное обеспечение стартует и выполняет основные для бизнеса функции.
• Тестирование критического пути (critical path) — направлено для проверки функциональности, используемой обычными пользователями во время их повседневной деятельности.
• Расширенное тестирование (extended) — направлено на исследование всей заявленной в требованиях функциональности.
Классификация в зависимости от исполнителей:

• Альфа-тестирование — является ранней версией программного продукта. Может выполняться внутри организации-разработчика с возможным частичным привлечением конечных пользователей.
• Бета-тестирование — программное обеспечение, выпускаемое для ограниченного количества пользователей. Главная цель — получить отзывы клиентов о продукте и внести соответствующие изменения.
Классификация в зависимости от целей тестирования:

• Функциональное тестирование (functional testing) — направлено на проверку корректности работы функциональности приложения.

• Нефункциональное тестирование (non-functional testing) — тестирование атрибутов компонента или системы, не относящихся к функциональности.

1.  Тестирование производительности (performance testing) — определение стабильности и потребления ресурсов в условиях различных сценариев использования и нагрузок.
2.  Нагрузочное тестирование (load testing) — определение или сбор показателей производительности и времени отклика программно-технической системы или устройства в ответ на внешний запрос с целью установления соответствия требованиям, предъявляемым к данной системе (устройству).
3.  Тестирование масштабируемости (scalability testing) — тестирование, которое измеряет производительность сети или системы, когда количество пользовательских запросов увеличивается или уменьшается.
4.  Объёмное тестирование (volume testing) — это тип тестирования программного обеспечения, которое проводится для тестирования программного приложения с определенным объемом данных.
5.  Стрессовое тестирование (stress testing) — тип тестирования направленный для проверки, как система обращается с нарастающей нагрузкой (количеством одновременных пользователей).
6.  Инсталляционное тестирование (installation testing) — тестирование, направленное на проверку успешной установки и настройки, обновления или удаления приложения.
7.  Тестирование интерфейса (GUI/UI testing) — проверка требований к пользовательскому интерфейсу.
8.  Тестирование удобства использования (usability testing) — это метод тестирования, направленный на установление степени удобства использования, понятности и привлекательности для пользователей разрабатываемого продукта в контексте заданных условий.
9.  Тестирование локализации (localization testing) — проверка адаптации программного обеспечения для определенной аудитории в соответствии с ее культурными особенностями.
10. Тестирование безопасности (security testing) — это стратегия тестирования, используемая для проверки безопасности системы, а также для анализа рисков, связанных с обеспечением целостного подхода к защите приложения, атак хакеров, вирусов, несанкционированного доступа к конфиденциальным данным.
11. Тестирование надёжности (reliability testing) — один из видов нефункционального тестирования ПО, целью которого является проверка работоспособности приложения при длительном тестировании с ожидаемым уровнем нагрузки.
12. Регрессионное тестирование (regression testing) — тестирование уже проверенной ранее функциональности после внесения изменений в код приложения, для уверенности в том, что эти изменения не внесли ошибки в областях, которые не подверглись изменениям.
13. Повторное/подтверждающее тестирование (re-testing/confirmation testing) — тестирование, во время которого исполняются тестовые сценарии, выявившие ошибки во время последнего запуска, для подтверждения успешности исправления этих ошибок.

Классификация по запуску кода на исполнение#

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

Статическое тестирование может включать ревизию кода, проверку стиля кода, тестирование требований к системе и другие методы, которые позволяют проверить качество кода и документов без выполнения программы.
Методы статического тестирования:
1. Ревизия кода — это процесс просмотра программного кода другими разработчиками или специалистами по тестированию с целью выявления ошибок, нарушений стиля кода и других проблем.
2. Проверка стиля кода — это процесс анализа кода на соответствие определенным стандартам стиля кода, что позволяет обеспечить лучшую читаемость и сопровождаемость кода.
3. Статический анализ кода — это автоматическая проверка кода специальными инструментами, которые помогают выявить ошибки, уязвимости и нарушения рекомендаций по качеству кода.

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

Динамическое тестирование может включать различные методы, такие как модульное тестирование, интеграционное тестирование, системное тестирование и приемочное тестирование. Обычно динамическое тестирование используется после статического тестирования, когда программный код уже был проверен на наличие очевидных ошибок.
1. Модульное тестирование — проверка отдельных компонентов программы на правильность работы и соответствие требованиям.
2. Интеграционное тестирование — проверка взаимодействия между модулями программы и их совместной работы.
3. Системное тестирование — проверка полной системы на соответствие требованиям и правильность работы в реальных условиях.
4. Приемочное тестирование — проверка программы со стороны заказчика или пользователей на соответствие их потребностям и требованиям.

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

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

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

Функциональное и нефункциональное тестирования#

Функциональное тестирование (Functional testing) — Тестирование ПО, направленное на проверку того, что компонент либо система соответствует функциональным требованиям.

Тестирование функциональной корректности (Functional correctness testing) — Анализ функций приложение на корректность, правильность расчётов и соответствие указанным или подразумеваемым требованиям. Проводится на всех уровнях тестирования.

Тестирование функциональной пригодности\целесообразности (Functional appropriateness testing) — Анализ пригодности функций приложения для выполнения какой-то бизнес задачи. Обычно проводится на системном уровне тестирования, но может и проводиться на поздних стадиях интеграционного уровня тестирования

Тестирование функциональной полноты (Function completeness testing) — Анализ степени, в которой набор функций покрывает все указанные задачи и цели пользователя. Проводится на всех уровнях тестирования.

Нефункциональное тестирование (Non-functional testing) — Тестирование атрибутов компонента или системы, не относящихся к функциональности, то есть надежность, эффективность, практичность, сопровождаемость и переносимость, удобство, доступность и т.д.

Тестирование графического интерфейса (GUI testing) — Анализ соответствия графического пользовательского интерфейса программы спецификациям, макетам, прототипам, стандартам.

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

Тестирование инсталляции (Installation testing) — Тестирование, направленное на проверку процессов установки, удаления, восстановления, обновления, лицензирования.

Тестирование безопасности (Safety testing) — Тестирование программного продукта с целью с целью определить его безопасность.

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

Тестирование защищенности (Security testing) — Тестирование с целью оценить защищенность программного продукта.

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

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

Тестирование производительности (Performance testing) — Процесс тестирования с целью определить производительность программного продукта.

Нагрузочное тестирование (Load testing) — Вид тестирования производительности, проводимый с целью оценить поведение компонента или системы под увеличивающейся нагрузкой (число одновременно работающих пользователей и/или число транзакций) для определения максимально допустимого уровня нагрузки для исследуемого компонента или системы.

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

Тестирование по типу введенных данных#

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

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

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

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

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

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

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

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

Классы эквивалентности#

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

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

Чек-лист для тестирования числового поля#

Итак, у нас есть некое поле, куда нужно вводить число. Например, поле «возраст»
Какие проверки тут можно провести:

Корректные значения
Некорректные значения (за пределами валидных диапазонов или нелогичные: 200 лет, 88 секунд...)
Граничные значения
Пограничные значения
Дробное число — формат (через запятую и через точку)
Дробное число — округление (с кучей знаков после запятой)
Ноль
Один
Пустое поле
Очень большое число (поиск технологической границы)
Отрицательное число
Нечисловые и «не совсем числовые» значения

Проверка	Пример	Результат
Больше 18 лет	25	Успешная регистрация
Ровно 18 лет	18	Успешная регистрация
Меньше 18 лет	16	Ошибка: "Возраст должен быть 18 лет или выше"
Дробные значения
Через точку	21.5	Успешная регистрация
Через запятую	21,5	Успешная регистрация
Пограничные значения
Граница слева от 18	17	Ошибка: "Возраст должен быть 18 лет или выше"
Граница слева, дробное число	17.999999999999999999	Ошибка: "Возраст должен быть 18 лет или выше"
Граница справа от 18*	18.00000000000000001	Успешная регистрация
Ноль / Один
Ноль	0	Ошибка: "Возраст должен быть 18 лет или выше"
Пустое поле		Успешная регистрация (или ошибка, что поле обязательное)
Единица	1	Ошибка: "Возраст должен быть 18 лет или выше"
Большие числа
Поиск технологической границы	999999999999999999999	Ошибка: "Некорректное значение возраста"
Поиск тех. границы меньше нуля	-999999999999999999999	Ошибка: "Некорректное значение возраста"
Нечисловые значения
Число, записанное как строка	"Пять"	Ошибка: "Введите число"
Точно не число	"Тест"	Ошибка: "Введите число"
Лидирующий ноль	"025"	Успешная регистрация, возраст распознал как 25
Пробел перед числом	" 25"	Успешная регистрация, возраст распознал как 25
Пробел внутри числа	"2 5"	Ошибка: "Возраст должен быть 18 лет или выше" (распознает до пробела)
До пробела больше 18 лет	"25 6"	Успешная регистрация, возраст распознал как 25
После пробела текста	"25 тест"	Успешная регистрация, возраст распознал как 25
До пробела текст	"тест 25"	Успешная регистрация, возраст распознал как 25
Запись через е	"1.2e+2"	Ошибка: "Введите число"
Шестнадцатеричное значение	"0xba"	Ошибка: "Введите число"
Boolean значение	"TRUE"	Ошибка: "Введите число"
Строка Infinity	"Infinity"	Ошибка: "Введите число"
Строка NaN	"NaN"	Ошибка: "Введите число"

Тестирование по знанию системы#

Тестирование по знанию системы можно проводить с использованием различных методологий, таких как тестирование черного ящика (black-box testing), тестирование белого ящика (white-box testing) и тестирование серого ящика (grey-box testing).

Черный ящик#

Тестирование «черного ящика» — это способ проверки программного обеспечения, когда тестировщик не знает внутренней структуры или деталей работы самой программы. Он смотрит на нее как на «черный ящик», и проверяет, как система взаимодействует с внешним миром и выполняет свои функции.

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

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

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

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

Недостатки Black box testing:

Без каких-либо технических или программных знаний есть вероятность пропустить возможные условия тестируемого сценария;
В оговоренное время есть вероятность протестировать не все входные и выходные значения;
Полный Test Coverage невозможен для больших и сложных проектов;

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

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

Тестируем формы#

Элементы форм:

Текстовые поля и области (Text Field, Text Area)

Проверки:
Обязательность полей (оставляем пустыми поочередно и вместе)
Вводим минимально/максимально допустимые значения (на 1 меньше, само значение и на 1 больше).
Ввод разного типа символов (латиница, кириллица, Unicode, цифры, спецсимволы, пробелы в разных местах строки, html тэги, данные из буфера обмена).
Ссылки (Links)

Проверки:
Префиксы: пустой, разные протоколы (http, https, ftp).
Далее аналогично текстовым полям.
Чек боксы (Check box)

Проверки:
Выбираем разное количество(ничего, один, два, все).
Наличие галочки Check all (для большого количества чек боксов).
Область возле чек-бокса тоже должна быть кликабельной.
Radio button

Проверки:
Один всегда выбран
Не могут быть выбраны оба
Область возле кнопки тоже должна быть кликабельной.
Загрузка файла (File uploader)

Проверки:
Не выбираем файл
Загрузка файлов разных размеров (меньше, ровно по ограничению, больше ограничения на размер, очень маленький файл)
Валидность формата файла
Как работает, если можно вводить в поле путь до файла
Далее аналогично текстовым полям
Телефон, Почта (Phone, Email)

Проверки:
Проверяем как текстовые поля
Наличие плейсхолдера (подсказки).
Отдельно проверяем допустимые спецсимволы (+, (), @, @@,)
Наличие маски
Логин, пароль (Login, Password)

Проверки:
Проверяем как текстовые поля
Требования к сложности пароля (содержит/не содержит все/одно условия)
Выпадающий список (Dropdown)

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

Белый и серый ящики#

Тестирование методом белого ящика (white-box testing): Тестирование, основанное на анализе внутренней структуры компонента или системы (ISTQB).

Тестирование на основе структуры (structure-based testing): Динамическое тестирование, для которого тесты являются результатом анализа структуры элемента тестирования. Примечание. Тестирование на основе структуры не ограничено использованием на уровне компонентов, а может использоваться на всех уровнях, например при покрытии пункта меню, как части тестирования системы. (ГОСТ 56920)

Тестирование методом белого ящика (также: прозрачного, открытого, стеклянного ящика; основанное на коде или структурное тестирование) - метод тестирования ПО, который предполагает, что внутренняя структура/устройство/реализация системы известны тому, кто её тестирует. Мы выбираем входные значения, основываясь на знании кода, который будет их обрабатывать. Точно так же мы знаем, каким должен быть результат этой обработки. Знание всех особенностей тестируемой программы и ее реализации - обязательны для этой техники.

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

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

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

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

тестирование может производиться на ранних этапах: нет необходимости ждать создания пользовательского интерфейса;

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

Недостатки White box testing:

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

Выбранные тест-кейсы могут не содержать данные, которые будут чувствительны к ошибкам. Например: p=q/r; может выполняться корректно, за исключением случая, когда r=0. y=x^2; тест не выявит ошибок в случаях, когда x=0, y=0 и x=2, y=4;
Тестирование белого ящика предполагает, что поток управления правильный (или близок к правильному). Поскольку эти тесты основаны на существующих путях, с помощью нельзя обнаружить несуществующие пути;

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

White box testing нужно:

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

Отладчик#

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

Шаг за шагом отслеживание выполнения:

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

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

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

Классификация по уровню детализации приложения#

Уровни тестирования:
1. Unit/component/program/module testing - тестируется минимально-атомарный модуль программы, чаще всего это одна функция или метод. Таких тестов должно быть больше всего;
2. Integration testing - несколько модулей программы тестируются вместе;
3. System testing - вся программа тестируется полностью;
4. Acceptance testing - программа принимается заказчиком на соответствие заявленным требованиям либо тестировщики проходят end-to-end сценарии с точки зрения пользователя;

Модульное тестирование (оно же юнит-тестирование) используется для тестирования какого-либо одного логически выделенного и изолированного элемента системы (отдельные методы класса или простая функция, subprograms, subroutines, классы или процедуры) в коде. Очевидно, что это тестирование методом белого ящика и чаще всего оно проводится самими разработчиками. Целью тестирования модуля является не демонстрация правильного функционирования модуля, а демонстрация наличия ошибки в модуле, а также в определении степени готовности системы к переходу на следующий уровень разработки и тестирования. На уровне модульного тестирования проще всего обнаружить дефекты, связанные с алгоритмическими ошибками и ошибками кодирования алгоритмов, типа работы с условиями и счетчиками циклов, а также с использованием локальных переменных и ресурсов. Ошибки, связанные с неверной трактовкой данных, некорректной реализацией интерфейсов, совместимостью, производительностью и т.п. обычно пропускаются на уровне модульного тестирования и выявляются на более поздних стадиях тестирования. Изоляция тестируемого блока достигается с помощью заглушек (stubs), манекенов (dummies) и макетов (mockups).

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

Задание на практику#

Найдите все баги и разберите все кейсы
https://playground.learnqa.ru/puzzle/triangle
Testing Challenge #6 - Boundary testing
http://testingchallenges.thetestingmap.org/challenge6.php

Это форма для заказа такси.
Приложение должно работать только в 2017 году для таксомоторной компании в Амстердаме. Такси необходимо заказывать как минимум за 1 час. Если время прибытия составляет менее 1 часа, клиенты не смогут сделать заказ онлайн. Они должны позвонить. Формат даты - ДД/ММ/ГГГГ ЧЧ:мм. Для целей тестирования значением по умолчанию являются текущие дата и время (в Амстердаме), но они установлены на 2017 год плюс один час и 10 минут. Вы вошли в приложение и указали местоположение. Все, что вам нужно сделать, это указать дату и время. Ваша задача состоит в том, чтобы протестировать все недопустимые границы для поля даты и времени. Тестируйте по одной границе за раз. Не проводите тестирование с пропущенными значениями (например, пропущенный месяц 03/ /2017 04:44).
Даты, содержащие символы, отличные от цифр, или н

Домашнее задание#

Написать Unit-тесты для домашнего задания 1
Стурктура отчета:
Титульный лист, офрмленный согласно шаблону. Лабораторная работа №6 "Разработка Unit-тестов"
Опишите ожидаемое поведение алгоритма и сформулируйте Классы эквивалентности для входных данных.
Обновите код программ с учетом обработки неккоретных значений
Изменения задокументируйте

Литература#

“Библия QA” - это обновляемая база знаний объемом 560+ страниц: