Методы структурного тестирования программ

Лихицкий, А. С. Исследование стратегий тестирования программного обеспечения / А. С. Лихицкий. — Текст : непосредственный // Молодой ученый. — 2016. — № 9 (113). — С. 71-74. — URL: https://moluch.ru/archive/113/28881/ (дата обращения: 25.06.2023).

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

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

Динамическое тестирование (Техники тест дизайна) | Курс тестирование ПО с нуля — Урок 21 | QA Labs

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

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

‒ Изучить существующие методы тестирования программного обеспечения.

‒ Определить преимущества и недостатки существующих методов.

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

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

Black-box vs White-box testing. Методологии тестирования | Курс тестирование ПО — Урок 8 | QA Labs

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

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

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

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

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

Читайте также:
Налогоплательщик юл описание программы

Рис. 1. Тестирование методом черного ящика.

Методы функционального тестирования:

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

2) Анализ граничных условий — метод, при котором проверяются границы классов эквивалентности. Строятся тесты для границ классов, для минимальных и максимальных значений.

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

Выделяют следующие особенности методов функционального тестирования:

‒ Тестирование системы в целом, включая отдельные модули и интерфейсы между ними.

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

‒ Тесты основаны на спецификации и не зависят от исходного кода.

‒ Удобство автоматизации и регрессионного тестирования на базе тестов, построенных на основе стратегии «черного ящика».

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

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

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

Рис. 2. Структурное тестирование

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

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

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

Критерии структурного тестирования:

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

С1 — условие тестирование ветвей, требуется выполнение каждой ветви программы не менее 1 раза.

C2 — критерий покрытия всех путей в управляющем графе программы.

Кроме перечисленных выше критериев используют критерий покрытиях всех условий и критерия покрытия условий/решений, который совмещает C1 и критерий покрытия условий.

Выделяют следующие особенности структурного тестирования:

‒ Минимальная стоимость устранения ошибки, благодаря локализации ошибки внутри программного модуля.

‒ Тесты, построенные на базе исходного кода, обеспечат его полное покрытие.

‒ Тесты зависят от программного кода и тестировщик вынужден актуализировать состояние тестов следуя изменениям в программе.

‒ Специалист по тестированию должен разбираться в проверяемом коде.

‒ Сложность тестирования в целом

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

Среди особенностей тестирования в реальных условиях выделяются:

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

Читайте также:
Андроид не открывает программы

‒ Высокая стоимость устранения ошибки.

‒ Необходимость поддержки тестирование в виде консультаций специалистов по поддержке программных продуктов.

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

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

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

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

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

  1. Тамре Л. Введение в тестирование программного обеспечения. — М.: Вильямс, 2003. –359с.
  2. Липаев В. В. Тестирование программ. — М.: Радио и связь, 1986. — 295 с.
  3. Бейзер Б. Тестирование “черного ящика” Технология функционального тестирования программного обеспечения. — СПб.: Питер, 2004. — 318 с.
  4. Myers G. The art of software testing. New York: John Wiley https://moluch.ru/archive/113/28881/» target=»_blank»]moluch.ru[/mask_link]

    5.1. Стратегии тестирования

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

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

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

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

    Второй подход основан на анализе логики программы (стратегия ‘белого ящика’). Существо подхода — в проверке каждого пути, каждой ветви алгоритма. При этом внешняя спецификация во внимание не принимается. Методы этой группы называются методами структурного тестирования.

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

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

    5.2. Методы структурного тестирования

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

    5.2.1. Метод покрытия операторов

    Цель метода — выполнение каждого оператора программы хотя бы один раз.

    Это необходимое, но недостаточное условие для приемлемого тестирования по принципу “белого ящика”. Например, рассмотрим фрагмент программы, приведенный на рисунках 12 и 13. На рис. 12 приведен правильный фрагмент программы. С целью оценки чувствительности метода к ошибкам программы в правильный алгоритм внесены ошибки: в первом условии логическая связка “и” (“and”) заменена на связку “или” (“or”) и во втором условии вместо “x>1” записано “x

    В этой программе можно выполнить каждый оператор, записав один единственный тест, который реализовал бы путь ace. Т.е., если на вход подать: А=2, В=0, Х=3, каждый оператор выполнится один раз. Результаты тестирования приведены в таблице 3. Обратите внимание: ожидаемый результат определяется по алгоритму на рисунке 12, а фактический — по алгоритму рисунка 13, поскольку определяется чувствительность метода тестирования к ошибкам программы. Как видно из этой таблицы, ни одна из внесенных в алгоритм ошибок не обнаруживается.

    Рис. 12. Правильный алгоритм Рис. 13. Неправильный алгоритм

    Т а б л и ц а 3

    Результат тестирования методом покрытия операторов

    A=2, B=0, X=3 (асе)

    5.2.2. Метод покрытия решений (покрытия переходов)

    Более сильный метод тестирования известен как покрытие решений (покрытие переходов).

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

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

    Для программы приведенной на рисунке 12 покрытие решений может быть выполнено двумя тестами, покрывающими пути ace, abd>, либо aсd, abe>. Пути aсd, abe> покроим, выбрав следующие исходные данные: и (результаты тестирования см. в таблице 4).

    Т а б л и ц а 4

    Результат тестирования методом покрытия решений

    A=3, B=0, X=3 (aсd)

    Как видно из таблицы 4.2 ошибка обнаруживается на пути abe.

    5.2.3. Метод покрытия условий

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

    • A=2, B=0, X=4 (реализуем путь ace)
    • A=1, B=1, X=0 (реализуем путь abd).

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

    Тест (путь) Ожидаемый результат Фактический результат Результат тестирования
    A=2, B=0, X=4 (ace) X=3 X=3 неуспешно
    A=1, B=1, X=0 (abd) X=0 X=1 успешно

    Таблица 5 отражает тот факт, что ошибка не обнаруживается на пути ace и обнаруживается на пути abd. 5.2.4. Критерий решений (условий) Критерий покрытия решений/условий требует такого достаточного набора тестов, чтобы все возможные результаты каждого условия в решении выполнялись по крайней мере один раз, все результаты каждого решения выполнялись по крайней мере один раз и, кроме того, каждой точке входа передавалось управление по крайней мере один раз. Два теста метода покрытия условий A=2, B=0, X=4 (путь ace) и A=1, B=1, X=0 (путь abd) отвечают и критерию покрытия решений/условий. Это является следствием того, что одни условия приведенных решений скрывают другие условия в этих решениях. Так, если условие А>1 будет ложным, транслятор может не проверять условия В=0, поскольку при любом результате условия В=0, результат решения ((А>1)1, B=0; б)A>1, B0; в) A1, B=0; г) А1, B0; д) A=2, X>1; е) A=2, X1; ж) А2, X>1; з) А2, X1. Для того чтобы протестировать эти комбинации, необязательно использовать все 8 тестов. Фактически они могут быть покрыты четырьмя тестами:

    • A=2, B=0, X=4 ;
    • A=2, B=1, X=1 ;
    • A=0,5, B=0, X=2 ;
    • A=0.5, B=1, X=1 .

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

    Тест (путь) Ожидаемый результат Фактический результат Результат тестирования
    A=2, B=0, X=4 (ace) X=3 X=3 неуспешно
    A=2, B=1, X=1 (abe) X=2 X=1,5 успешно
    A=0,5 B=0, X=2 (abe) X=3 X=4 успешно
    A=0.5, B=1, X=1 (abd) X=1 X=1 неуспешно

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

    Источник: studfile.net

Рейтинг
( Пока оценок нет )
Загрузка ...
EFT-Soft.ru