Процесс выполнения программы целью которого является выявление ошибок

Обновлено: 22.01.2025

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

Основные термины

Тестирование (testing) – процесс выполнения программы с целью найти ошибки. Может выполняться как с компьютером, так и без него (общий термин).
Доказательство (proof) – попытка найти в программе ошибки путем доказательств на основе математических теорем о правильности программы безотносительно к внешней программной среде (вид тестирования).
Контроль (verification) – попытка найти ошибки, выполняя программу в тестовой или моделируемой среде (вид тестирования).
Испытание (validation) – попытка найти ошибки, выполняя программу в заданной программной среде (вид тестирования).
Аттестация (certification) – авторитетное подтверждение правильности программы (итоговое тестирование, для критичного ПО).

Отладка (debugging) – средство установления точной природы ошибок, процесс, противоположный тестированию, ведет к устранению ошибок.

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

Автономное тестирование, тестирование модуля (module testing) – контроль отдельного модуля в изолированной среде (например, с помощью ведущей программы), инспекция текста модуля на сессии программистов, которая иногда дополняется математическим доказательством правильности модуля.
Тестирование сопряжений (integration testing) – контроль сопряжений между частями системы, как между компонентами в комплексе, так и между модулями отдельного компонента (например, у заглушки).
Комплексное тестирование (system testing) – контроль и/или испытание системы по отношению к исходным целям. Является процессом контроля, если оно выполняется в моделируемой среде, и процессом испытания в реальной среде.

ПРИНЦИПЫ (аксиомы) тестирования

Мои примечания к аксиомам тестирования:

Не гордитесь тестом, который не обнаружил ни одной ошибки.
При планировании разработки выделяйте не менее 50% времени на тестирование и отладку, тогда у вас появится шанс закончить работу в срок.
Другой человек не будет испытывать уважения к вашим способностям писать правильный код. Поэтому, когда нет возможности передать тестирование другому разработчику, следует отстраниться от своей разработки и отнестись к ней как чужой (такой психологический настрой).
Если вы не описали заранее ожидаемые результаты, то даже неумышленно можно истолковать фактические результаты как верные.
Не воспроизводимые тесты – тесты, которые нельзя повторить нужное количество раз.
Обязательно в наборе тестов должны быть входные данные, которые могут не соответствовать смыслу задачи (смотри пример с формулой Герона), либо формату вводимых данных.
Тестирование «с лету» подразумевает, что тесты не следует придумывать после написания кода, это следует делать заранее.
Группируйте ошибки тестирования, постарайтесь понять их природу.
Рекомендация относится к коллективной разработке, когда менее опытный программист делает много ошибок в своем коде программы.
Тестирование – творческий процесс, автор тестов должен понимать технологию тестирования и иметь собственный опыт программирования.
Например, методология структурного программирования обеспечивает обозримость ПО за счет деления его на модули и стандартизации их взаимодействия. Полезными свойствами программного кода является осмысленный выбор идентификаторов объектов наличие комментариев.
Вы можете изменить программу в процессе отладки. Важно – не забыть восстановить полезный код.
Для каждого процесса тестирования начинайте с определения цели.

Связь процесса тестирования с процессом проектирования ПО

В процессе проектирования ПО обычно принимаются следующие решения:

Требования к ПО (область применения, назначение, условия эксплуатации);
Цели создания ПО (решение определенных задач);
Внешние спецификации «что должно делать ПО» (функции и требования к ним)
Архитектура системы;
Структура программы (разбиение на программные модули);
Внешние спецификации модуля (функции модуля);
Логика модуля (алгоритмы);

Как вы видите, процесс непосредственного кодирования не включен в проектирование.

Процессы тестирования (в скобках указаны номера связанных с ними процессов проектирования):

1. Автономный тест (6, 7)
2. Тест сопряжений (4, 5)
3. Тест функций (3)
4. Комплексный тест (2)
5. Тест приемлемости (1)

Тестирование ПО включает:

1) постановку задачи;
2) проектирование тестов;
3) написание тестов;
4) тестирование тестов;
5) выполнение тестов;
6) изучение результатов тестирования.

Два крайних подхода к проектированию тестов:

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

Две стратегии тестирования: восходящее и нисходящее

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

Критерии выбора стратегии тестирования

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

Отладка

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

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

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

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

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

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

Процесс тестирования предполагает:

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

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

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

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

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

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

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

Анализ результатов и предложения по улучшению продукта

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

Обычно в процессе тестирования берутся в расчет следующие аспекты:

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

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

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

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

Тестирование веб сервисов;Тестирование мобильных приложений;Бекенд тестирование.

Мы проверяем наше ПО по 7 основным критериям:

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

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

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

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

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

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

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

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

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

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

Цель лекции: ознакомиться с видами и способами контроля и тестирования ПО, методами и средствами отладки программ.

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

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

а) предполагаемые результаты должны быть известны до тестирования;

б) следует избегать тестирования программы автором;

в) необходимо досконально изучать результаты каждого теста;

г) необходимо проверять действия программы на неверных данных;

д) необходимо проверять программу на неожиданные побочные эффекты на неверных данных.

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

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

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

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

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

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

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

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

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

б) ошибки компоновки - обнаруживаются компоновщиком (редактором связей) при объединении модулей программы;

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

1) ошибки определения исходных данных (ошибки передачи, ошибки преобразования, ошибки перезаписи и ошибки данных);

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

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

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

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

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

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

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

Общая методика отладки программных продуктов, написанных для выполнения в операционных системах MS DOS и Win32:

1 этап - изучение проявления ошибки;

2 этап – определение локализации ошибки;

3 этап - определение причины ошибки;

4 этап — исправление ошибки;

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

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

а) программу наращивать «сверху-вниз», от интерфейса к обрабатывающим подпрограммам, тестируя ее по ходу добавления подпрограмм;

б) выводить пользователю вводимые им данные для контроля и проверять их на допустимость сразу после ввода;

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

Дополнительную информацию по теме можно получить в [1, 2, 4, 7, 9, 14, 15].

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

Функциональные.
Нефункциональные.
Связанные с изменениями.

Функциональные тесты базируются на функциях и особенностях, а также на взаимодействии с другими системами и могут быть представлены на всех уровнях тестирования: компонентном или модульном (Component/Unit testing), интеграционном (Integration testing), системном (System testing), приемочном (Acceptance testing). Функциональные виды тестирования рассматривают внешнее поведение системы. Далее перечислены одни из самых распространенных видов функциональных тестов.

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

1.Функциональные тесты основываются на функциях, выполняемых системой, и могут проводиться на всех уровнях тестирования (компонентном, интеграционном, системном, приемочном). Как правило, эти функции описываются в требованиях, функциональных спецификациях или в виде случаев использования системы (use cases).

Тестирование функциональности может проводиться в двух аспектах:

2. Тестирование безопасности (Security and Access Control Testing)

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

Общая стратегия безопасности основывается на трех основных принципах:

Конфиденциальность.
Целостность.
Доступность.

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

Существует два основных критерия при определении понятия целостности:

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

3. Тестирование взаимодействия или Interoperability Testing

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

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

Тестирование производительности ( Performance testing ).

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

Измерение времени выполнения выбранных операций при определенных интенсивностях выполнения этих операций.

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

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

Исследование производительности на высоких, предельных, стрессовых нагрузках.

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

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

Измерение времени выполнения выбранных операций при определенных интенсивностях выполнения этих операций.

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

Тестирование стабильности или надежности( Stability / Reliability Testing)

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

В англоязычной терминологии вы можете так же найти еще один вид тестирования - Load Testing - тестирование реакции системы на изменение нагрузки (в пределе допустимого). Нам показалось, что Load и Performance преследуют все же одну и ту же цель: проверка производительности (времени отклика) на разных нагрузках. Собственно поэтому мы и не стали разделять их. В то же время кто то может разделить. Главное все таки понимать цели того или иного вида тестирования и постараться их достигнуть.

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

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

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

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

3. Тестирование удобства пользования (Usability Testing)

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

Тестирование удобства пользования дает оценку уровня удобства использования приложения по следующим пунктам:

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

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

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

Дымовое тестирование (Smoke Testing)
Регрессионное тестирование (Regression Testing)
Тестирование сборки (Build Verification Test)
Санитарное тестирование или проверка согласованности/исправности (SanityTesting)

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

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

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

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

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

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

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

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

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

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

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

Статическое тестирование начинается на ранних этапах жизненного цикла ПО и является, соответственно, частью процесса верификации.

Можно поделить статическое тестирование на 2 типа:

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

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

В рамках этого подхода тестированию могут подвергаться:

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

Основная идея этого вида тестирования состоит в том, что проверяется реальное поведение (части) приложения.

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

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

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

Понятие дымовое тестирование пошло из инженерной среды:

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

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

Регрессионное тестирование (по некоторым источникам) включает new bug-fix - проверка исправления найденного ранее дефекта, old bug-fix - проверка, что исправленный ранее и верифицированный дефект не воспроизводится в системе снова, а также side-effect - проверка того, что не нарушилась работоспособность работающей ранее функциональности, если ее код мог быть затронут при исправлении некоторых дефектов в другой функциональности. Обычно используемые методы регрессионного тестирования включают повторные прогоны предыдущих тестов, а также проверки, не попали ли регрессионные ошибки в очередную версию в результате слияния кода.

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

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

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

Приемочное тестирование или Приемо-сдаточное испытание (User Acceptance Testing)

Формальный процесс тестирования, который проверяет соответствие системы требованиям и проводится с целью:

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

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

продукт достиг необходимого уровня качества;
заказчик ознакомлен с Планом Приемочных Работ (Product Acceptance Plan) или иным документом, где описан набор действий, связанных с проведением приемочного тестирования, дата проведения, ответственные и т.д.

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

V. Виды тестирования по доступу к коду (методы тестирования)

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

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

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

Читайте также: