5 основных тенденций тестирования программного обеспечения в будущем и продвинутый путь тестирования программного обеспечения

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

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

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

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

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

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

　　2. Цифровая трансформация и непрерывная интеграция

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

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

　　3. Эффективное применение тестовых данных в бизнесе

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

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

　　4. Тестируйте смарт-приложения

　　Согласно отчету ResearchAndMarkets, «глобальный рынок интеллектуальных приложений составил 8,39 млрд долларов США в 2017 году и, по прогнозам, достигнет 93,4 млрд долларов США к 2026 году при среднегодовом темпе роста 30,7% в течение прогнозируемого периода». в технологиях для развертывания новых продуктов, а также рост рынка больших данных и аналитики стимулируют рост интеллектуальных приложений. Углубление признания в развивающихся странах открывает значительные возможности для расширения рынка.

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

　　5. Инжиниринг производительности, а не только тестирование производительности

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

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

 Путь обучения тестированию программного обеспечения

Карта планирования обучения: друзья, которые учатся и тестируют, могут нажать на маленькую карточку ниже
https://jq.qq.com/?_wv=1027&k=3T9tmL0t https://jq.qq.com/?_wv=1027&k=3T9tmL0t

 

1. Тестовая и программная модель

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

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

1 модель водопада

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

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

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

2 Итеративная модель разработки

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

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

3 Спиральная модель развития

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

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

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

4 Гибкая модель разработки

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

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

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

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

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

5 Сравнение четырех моделей

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

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

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

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

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

6 Тестирование при разработке программного обеспечения

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

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

7 Цель и принципы тестирования программного обеспечения

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

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

1. Тестирование — это выполнение программы для поиска ошибок
2. Успешный тестовый пример состоит в обнаружении до сих пор не обнаруженных ошибок.
3. Успешный тест — это тот, который находит до сих пор не обнаруженную ошибку.
4. Убедитесь, что продукт выполняет то, что он обещает или рекламирует, и что функции, к которым могут получить доступ пользователи, четко задокументированы.
5. Обеспечение соответствия продуктов требованиям к производительности и эффективности
6. Убедитесь, что продукт надежен и адаптируется к пользовательской среде.

Принципы тестирования программного обеспечения:

1. Обязательной частью тестового примера является определение ожидаемого результата или интерфейса.
2. Программистам следует избегать тестирования программ, которые они пишут
3. Организации, которые пишут программное обеспечение, не должны тестировать программное обеспечение, которое они пишут.
4. Результаты выполнения каждого теста должны быть тщательно проверены
5. Тестовые случаи должны быть написаны не только для действительных и ожидаемых входных данных, но также для недопустимых и неожиданных входных данных.
6. Проверка того, что программа «не делает того, что должна делать» — это только половина теста, вторая половина теста — проверка того, что программа «делает то, что не должна делать».
7. Следует избегать одноразовых тестовых случаев, если само программное обеспечение не является одноразовым.
8. При планировании тестирования не следует молчаливо предполагать, что ошибки не будут обнаружены.
9. Вероятность того, что часть программы содержит больше ошибок, пропорциональна количеству ошибок, уже обнаруженных в этой части.

8 Тестируемость программного обеспечения

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

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

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

2. Дизайн тестового примера

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

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

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

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

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

2 Дизайн тестового примера «белого ящика»

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

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

Покрытие решений требует, чтобы было написано достаточно тестовых случаев, чтобы каждое суждение имело по крайней мере один результат, который является «истинным» и «ложным». Покрытие решений имеет почти в два раза больше тестовых путей, чем покрытие операторов, и, конечно же, оно обладает более сильными тестовыми возможностями, чем покрытие операторов. Точно так же покрытие решений имеет ту же простоту, что и покрытие операторов, и тестовые примеры могут быть получены без разделения каждого решения. Большинство операторов решения часто состоят из нескольких логических условий (например, оператор решения содержит И, ИЛИ, СЛУЧАЙ).Если вы оцениваете только конечный результат в целом и игнорируете значение каждого условия, вы неизбежно пропустите часть условия. тестовый путь. (Некоторые условные значения в оценке отсутствующих комбинаций)

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

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

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

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

3 Дизайн тестового набора «черный ящик»

(1) Разделение класса эквивалентности

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

1. Когда входное условие определяет диапазон значений или количество значений, можно установить один допустимый класс эквивалентности и два недопустимых класса эквивалентности. Например: входное значение — оценки учащихся, диапазон — от 0 до 100; класс эквивалентности меньше 0 и больше 100 — недопустимый класс эквивалентности, а класс эквивалентности от 0 до 100 — допустимый класс эквивалентности.
2. Если входное условие указывает набор входных значений или указывает условие «должно быть», могут быть установлены действительный класс эквивалентности и недопустимый класс эквивалентности.
3. В случае, когда входное условие является булевой величиной, могут быть определены допустимый класс эквивалентности и недопустимый класс эквивалентности.
4. В случае, когда задан набор значений входных данных (при условии n), и программа должна иметь дело с каждым входным значением отдельно, может быть установлено n эффективных классов эквивалентности и один недопустимый класс эквивалентности. Пример: входные условия указывают, что уровень образования может быть одним из четырех типов: младший колледж, бакалавриат, магистратура и докторантура, тогда эти четыре значения принимаются за четыре эффективных класса эквивалентности, а любой уровень образования, отличный от четырех типы образования используются как недействительный класс эквивалентности.
5. В случае, когда оговорены правила, которым должны соответствовать входные данные, могут быть установлены действительный класс эквивалентности (соответствующий правилам) и несколько недействительных классов эквивалентности (нарушающих правила с разных сторон);
6. Если известно, что каждый элемент в разделенном классе эквивалентности обрабатывается в программе по-разному, класс эквивалентности следует дополнительно разделить на более мелкие классы эквивалентности.

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

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

(2) Анализ граничных значений

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

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

(3) Причинно-следственная диаграмма

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

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

(4) Проверка ошибок

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

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

1. Входная линейная таблица — это пустая таблица;
2. Таблица содержит только один элемент;
3. Все элементы во входной таблице сортируются;
4. Входная таблица сортируется в обратном порядке;
5. Некоторые или все элементы во входной таблице совпадают.

4 Комплексная стратегия разработки тестового примера

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

1. В любом случае необходимо использовать метод анализа граничных значений.Опыт показал, что использование этого метода для проектирования тестовых случаев имеет наибольшую способность находить программные ошибки.
2. При необходимости дополнить некоторые тестовые примеры методом деления классов эквивалентности.
3. Добавьте еще несколько тестовых случаев путем угадывания ошибок.
4. Проверьте логическое покрытие спроектированных тестовых случаев на соответствие логике программы.Если требуемый стандарт покрытия не соблюдается, добавьте достаточное количество тестовых случаев.
5. Если описание функции программы содержит комбинацию входных условий, то с самого начала можно использовать метод причинно-следственной диаграммы.

Этапы проектирования тестовых наборов: 1) Построение базовых функциональных тестовых наборов на основе проектных спецификаций; 2) Тестовые наборы граничных значений; 3) Тестовые наборы перехода состояний; 4) Тестовые наборы угадывания ошибок; 5) Аномальные тестовые наборы; 6) Тестовые наборы производительности. 7) Стресс-тесты.

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

модульный тест

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

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

Интеграционное тестирование

Интеграция сверху вниз и интеграция снизу вверх

функциональный тест

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

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

Тест системы

Цель системного тестирования — доказать, что программа не может достичь поставленных целей.Существует 14 типов тестовых случаев для системного тестирования:

1. Тест возможностей: он предназначен для оценки того, действительно ли реализованы все возможности (или функции), упомянутые в целевом документе.
2. Тест объема: протестируйте программу на больших объемах данных. Цель тестирования емкости — продемонстрировать, что программа не может справиться с емкостью данных, указанной в целевом документе.
3. Тестирование на прочность: Тест, который подвергает программу высокой нагрузке или силе. Так называемая высокая интенсивность относится к пиковому количеству данных или операций, достигнутых за короткий промежуток времени.
4. Тестирование удобства использования: попытки найти артефакты или проблемы с удобством использования.
5. Тестирование безопасности: процесс разработки тестовых случаев для преодоления проверок безопасности программы. Например, мы можем разработать тестовые примеры, чтобы обойти механизм защиты памяти операционной системы и разрушить механизм защиты данных системы управления базами данных.
6. Тестирование производительности. Многие программы имеют определенные цели производительности или эффективности, которые характеризуются временем отклика и пропускной способностью программы при определенной нагрузке и среде конфигурации.
7. Тест хранения:
8. Настроить тест:
9. Тестирование совместимости.
10. Тест установки: некоторые типы процесса установки программного обеспечения очень сложны, и тестирование процесса установки является важной частью тестирования системы. Это особенно важно для автоматизированных систем установки, входящих в состав программных пакетов. Если программа установки не работает, это может повлиять на успешную работу пользователя с программным обеспечением.
11. Тестирование надежности: все виды тестирования направлены на повышение надежности программного обеспечения, но если цель программного обеспечения содержит специальное описание надежности, необходимо разработать специальный тест на надежность.
12. Тестирование восстанавливаемости: Программное обеспечение, такое как операционные системы, системы управления базами данных и системы телеобработки, часто имеет цели по восстанавливаемости, которые описывают, как система восстанавливается после программных ошибок, аппаратных сбоев и ошибок данных. Одна из целей тестирования системы — продемонстрировать, что эти механизмы восстановления не работают должным образом. Мы можем намеренно запрограммировать ошибки в системе и определить, сможет ли система восстановиться после них.
13. Тест на применимость
14. Тестирование документации: проверьте правильность пользовательской документации. Пользовательская документация должна быть предметом обзора на правильность и ясность. Любые примеры, описанные в документации, должны быть скомпилированы в тест-кейсы и отправлены в программу.

4. Автоматизированное тестирование

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

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

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

1 Преимущества автоматизированного тестирования

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

2 Недостатки автоматизированного тестирования

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

3 Когда внедрять автоматизированное тестирование

1. Цикл проекта длинный, а версия системы постоянна. В основном в регрессионном тестировании.
2. Требования меняются редко.
3. Тестовые объекты в системе в основном нормально идентифицируются, и нет большого количества сторонних контролей.
4. Требуется повторное тестирование, например, тестирование надежности требует тысяч системных тестов.

4. Когда следует избегать автоматизированного тестирования

1. Цикл проекта короткий, а требования часто меняются. Внедрение автоматизированного тестирования при коротком цикле проекта не только не окупит затраты, но и увеличит время выпуска продукта. Частые изменения требований приведут к модификации бизнес-логики старых функций, что приведет к необходимости модификации соответствующих тестовых сценариев.
2. Версия ПО пока не стабильна.
3. Большинство объектов не распознаются, а обслуживание сценариев часто и сложно.

5 Дизайн автоматизированного тестового примера

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

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

5. Написание тестовых документов и управление дефектами

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

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

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

6. Часто используемые инструменты тестирования

1 функциональный тест UFT

Принцип автоматизированного тестирования UFT

1. Инкапсулируйте реальный измеряемый объект, преобразуйте его в объект UFT и отправьте в библиотеку объектов.
2. Сравните свойства идентификации объекта в библиотеке объектов со свойствами идентификации реального тестируемого объекта во время выполнения.
3. Если результаты сравнения согласуются, это означает, что объект успешно сопоставлен, и вы можете продолжать выполнять последующие операции над реальным тестируемым объектом; если они не согласуются, будет сообщено об ошибке, указывающей на то, что объект не может быть распознан. .

инкапсулированная объектная модель

Объект пакета в UFT разделен на два понятия: объекты тестирования (объект тестирования, TO) и объекты времени выполнения (объект времени выполнения, RO). TO — это объект, который добавляется в библиотеку объектов, а RO — это объект, который фактически запускает тестируемое программное обеспечение. Все они являются объектами, инкапсулированными UFT, и TO существует для идентификации RO.

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

GetTOProperty()
Основное значение: получить значение свойства объекта в библиотеке объектов.
Формула: ReturnValue = object.GetTOProperty("имя свойства инкапсуляции")

SetTOProperty()
Основное значение: Установить значение свойства объекта в библиотеке объектов.
Формула: object.SetTOProperty "инкапсулированное имя свойства" "инкапсулированное значение свойства"
Примечание: Изменение свойств объекта в виде кода является временным и действительным только во время выполнения скрипта. После завершения скрипта значения свойств в объекте библиотека будет восстановлена.

Основное значение GetROProperty()
: получить значение свойства объекта во время фактического выполнения.
Формула: ReturnValue = object.GetROProperty("имя свойства инкапсуляции")
Примечание. Используйте метод GetROProperty для динамического получения некоторой подтверждающей информации во время фактической операции, а затем сравните ее с ожидаемыми тестовыми данными. Например, функция регистрации, после отправки некоторой регистрационной информации, как правило, необходимо перейти на следующую страницу подтверждения, чтобы проверить некоторую информацию, поэтому вы можете использовать GetROProperty для динамического получения некоторой подтверждающей информации во время фактической работы.

Решение для нераспознанных объектов

1. Настройте фиктивные объекты. Не рекомендуется, виртуальный объект очень хрупок и сложен в обслуживании; даже если объект не изменяется, пока объект изменяется в направлении интерфейса, виртуальный объект не будет распознан.
2. Используйте относительные координаты с WSH для размещения объектов.
3. Используйте DOM для создания технологии интерфейсных приложений. Применяется только к веб-проектам.
4. Используйте клиент SDK пользовательского расширения UFT для вторичной разработки, чтобы UFT мог распознавать объекты. Высокая сложность.
5. Разрабатывать и предоставлять эксклюзивные плагины.
6. Инкапсулируйте некоторые методы нераспознанных объектов в dll и используйте UFT для их вызова.

Управляемое данными и восстановление сцены

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

2 Тест производительности LoadRunner

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

1. Легко создавайте виртуальных пользователей. Генератор виртуальных пользователей может генерировать виртуальных пользователей для имитации поведения реальных пользователей в бизнес-операциях в форме виртуальных пользователей. Сначала он записывает бизнес-процесс, затем преобразует его в тестовый сценарий и выполняет параметризованные операции (мастер данных напрямую подключается к серверу данных для получения данных). Использование виртуальных пользователей может генерировать десятки тысяч обращений пользователей в разных операционных системах одновременно, что может значительно сократить аппаратные и человеческие ресурсы, необходимые для нагрузочного тестирования.
2. Создавайте реалистичные нагрузки. После создания виртуального пользователя необходимо задать схему нагрузки, совмещение бизнес-процессов и количество виртуальных пользователей. С помощью Controller можно быстро организовать многопользовательские сценарии тестирования.
3. Выявление проблем с производительностью. LoadRunner включает в себя монитор в реальном времени, который может отслеживать операционную производительность системы приложений в любое время в процессе нагрузочного тестирования.
4. Проанализируйте результаты. После завершения теста LoadRunner собирает и обобщает все тестовые данные и предоставляет расширенные инструменты анализа и отчетности для быстрого обнаружения проблем с производительностью и внесения соответствующих корректировок.