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

1. Понятие и роль тестовых случаев

1.1. введение

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

Методы проектирования тестирования не существуют сами по себе. В каждом тестовом проекте существует множество методов, и каждый тип имеет свои особенности.

1.2. Определение тестового примера:

1.1.1. Что такое тестовый пример?

Тест-кейсы являются основой для выполнения тестов и описывают этапы работы тестовой системы в виде документов.

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

（2）Тестовый пример — это наименьший объект для выполнения.

（3）Тестовые примеры — это руководство по тестированию, рекомендации, которым необходимо следовать при тестировании программного обеспечения, и фундаментальная гарантия стабильности качества тестирования программного обеспечения.

1.1.2. Характеристики тестовых случаев:

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

2. Повторяемость. В хороших тестовых примерах есть многоразовые функции. (регрессионное тестирование)

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

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

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

1.3. Преимущества написания тест-кейсов:

1.1.3. Роль тестовых случаев:

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

Использование тестовых примеров делает тестирование программного обеспеченияРеализация целенаправленная и целенаправленная.。

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

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

1.4. 4 характеристики тестовых случаев

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

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

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

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

1.5. Тестовые случаи обычно включают в себя следующие элементы:

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

1.6 Пример тестового примера:

2. Основные методы написания тест-кейсов

2.1. Метод разделения классов эквивалентности

Сценарий применения: в основном используется в полях ввода.

1.1.4. концепция

действительный, недействительный

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

Класс эквивалентности. Что такое класс эквивалентности? Это набор полей ввода, в которых каждое входное условие эквивалентно.

Обычно их можно разделить на действительные классы эквивалентности и недействительные классы эквивалентности.

Например: балл ЕГЭ подростка (примечание: подростки 13-17 лет)

Предположим, что возраст подростка равен x.,13<=x<=17,Математический баллy：0<=y<=100

Тогда возраст соответствует Классу эквивалентности Подразделение можно разделить наx<13,13<=x<=17,x>17,эффективный Класс эквивалентностида13<=x<=17,неверный Класс эквивалентностидаx<13,x>17

Баллы по математике по Классу эквивалентности Подразделение можно разделить наy<0,0<=y<=100,y>100,эффективный Класс эквивалентностида0<=y<=100,неверный Класс эквивалентностидаy<0,y>100

1.1.5. Пример

Вычислите сумму двух целых чисел от 1 до 100.

Если необходимо провести полное тестирование, сколько всего тестовых примеров следует разработать?

Сложение 1 имеет всего 100 значений от 1 до 100, а сложение 2 также имеет всего 100 значений от 1 до 100, поэтому между ними существует 100*100=10000 возможных комбинаций, но это всего лишь проверка нормального значения в пределах. Если данные, введенные пользователем, не находятся в диапазоне от 1 до 100, исчерпывающее тестирование определенно невозможно. Это вводит идею разделения классов эквивалентности.

Классы эквивалентности делятся на:

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

Неверный класс эквивалентности: относится к необоснованному набору данных, не соответствующему «Спецификации требований».

Мы разделяем поле ввода на действительный класс. эквивалентности (1~100) и два неверных класса эквивалентности（<1,>100）,И для каждого Класса эквивалентности провести серийный номер, то мы можем начать с каждого класса Выберите репрезентативные данные из эквивалентности для проверки и разработайте тест, как показано в следующей таблице.

1.1.6 Практические примеры:

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

2.2. метод граничных значений

　Общий анализ граничных значенийда Поскольку число, взятое при разработке программы тела цикла, может быть связано с<,<=Сделать ошибку。

Например, следующий код

for(int i = 0;i <100; i ++)

{

int j = i+1;

System.out.println("Повторить "+j+" раз")//Сделать что-нибудь в цикле

}

Программа здесь повторяется 100 раз, поэтому она будет выполнена 100 раз;

　　Если программист неосторожен, изменение i <100написано какi <= 100, а затем добавьте его один раз в несколько циклов. В настоящее время проверка граничных значений является хорошим методом тестирования.

Например: В системе введите оценку подростка, сколько ему лет (предполагая, что возраст взрослого равен x,13<=x<=17,Математический баллy：0<=y<=100

Согласно методу выше разделения классов эквивалентности Мы знаем, что эффективность возраста Класс эквивалентностида13<=x<=17,Таким образом, граничное значение равно 12, 18

Баллы по математике, действительные Класс эквивалентностида0<=y<=100,Таким образом, граничное значение равно -1,0,100,101

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

1.1.7. Метод определения граничного значения()

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

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

[1 100] Максимальный балл 1, 100 Оставить балл 0 101 принадлежность

(1,100) находится в точке 2, 99 и вдали от точки 1, 100

(1100] В точке 2, на расстоянии 100 от точки 1, 101

2.3. диаграмма причин и следствий

1.1.8. концепция:

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

1.1.9. Основные графические символы причинно-следственных диаграмм.

Тождество: если возникает причина, возникает и следствие; если причины не возникает, не возникает и следствия.

Не (~): если причина появляется, результат не появляется, если причина не появляется, появляется результат;

Или (∨): если возникает одна из нескольких причин, результат возникает; если ни одна из нескольких причин не возникает, результат не возникает;

И (∧): если возникает несколько причин, результат появится, если одна из причин не возникнет, результат не произойдет;

1.1.10. Символы ограничений для диаграмм причин и следствий

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

I (включительно): указывает, что хотя бы одна из трех причин должна быть верной.

O (уникальный): указывает на то, что должна быть одна из двух причин и только одна из них верна.

R (требование): указывает на две причины. Когда появляется a, должно появиться и b. Когда появляется a, b не может не появиться.

M (маска): два результата: когда a равно 1, b должно быть равно 0, когда a равно 0, значение b неопределенно.

1.1.11. Тестовые примеры диаграммы причин и следствий

Например: существует программное обеспечение для торговых автоматов, которое продает упакованные напитки по цене 2,5 юаня за единицу. Если положить монету номиналом 2,5 юаня и нажать кнопку «Кола», «Пиво» или «Чай с молоком», то будет выдан соответствующий напиток. Если вы положите монету номиналом 3 юаня, при доставке напитка вам вернут 50 центов.

Анализируя этот параграф, можно перечислить причины и последствия.

Причина (ввод):

Вставьте монеты номиналом 2,5 юаня;

Вложите 3 юаня;

Нажмите кнопку «Кола»;

Нажмите кнопку «Пиво»;

Нажмите кнопку «Чай с молоком».

Промежуточное состояние: ① Монета вставлена ​​② Кнопка нажата;

Результат (выход):

Возврат 5 центов;

Раздавать напитки «Кола»;

Раздавать «пивные» напитки;

Раздавайте напитки «чай с молоком»;

метод таблицы решений

2.4. Сценарный метод

1.1.12. Идеи дизайна тестовых примеров

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

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

Этот потоковый процесс должен охватывать все основные и альтернативные потоки в варианте использования от начала до конца.

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

1.1.1. Банковский кейс для банкомата:

Персональный идентификационный номер (ПИН = личный идентификационный номер), секретный идентификационный код, используемый для защиты смарт-карт от неправомерного использования. ПИН-код аналогичен паролю тем, что ПИН-код знает только владелец карты. Смарт-картой может пользоваться только тот, кто владеет смарт-картой и знает PIN-код.

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

Базовый поток – снятие заданных сумм (100 юаней, 200 юаней, 500 юаней, 1000 юаней)

Альтернативный вариант 2 – Нет наличных в банкомате

Альтернативный поток 3 – Недостаточно наличных в банкомате

Альтернативный вариант 4 – неправильный PIN-код.

Альтернативный вариант 5 – учетная запись не существует/неверный тип учетной записи.

Альтернативный поток 6 – Недостаточная балансовая стоимость

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

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

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

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

2.5. ошибка в догадке

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

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

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

1) Совершение исходящих вызовов (неэкстренных вызовов), когда SIM-карта не вставлена.

2) Вставьте просроченную SIM-карту для совершения исходящих звонков.

3) Если радиочастотное устройство повреждено или нет зоны сигнала, вставьте действительную SIM-карту, чтобы позвонить.

4) Сеть в норме, вставьте действительную SIM-карту и позвоните на неверный номер (например, 1, 888, 333333, не вводите никакой номер и т. д.).

5) Сеть в норме, вставьте действующую SIM-карту и используйте функцию «быстрого набора», чтобы набрать цифры недействительного номера.

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

2.6. метод ортогональной таблицы

Ортогональный экспериментальный метод заключается в использовании аккуратно расположенных таблиц. –Ортогональная таблицаразработать общий эксперимент、Комплексное сравнение、Статистический анализ,Достичь лучших условий производства посредством небольшого количества экспериментов.,Для достижения максимального эффекта производственного процесса,Этот метод планирования эксперимента выбирает подходящее количество репрезентативных точек из большого количества тестовых точек.,Используйте уже созданные формы—Ортогональная таблица для постановки экспериментов и выполнения методов анализа данных. Ортогональная Таблица способна сбалансировать выборку в диапазоне изменения факторов, что делает каждое испытание высокорепрезентативным за счет Ортогональной таблица имеет характеристики сбалансированной дисперсии,Гарантированные определенные требования для комплексных экспериментов,Эти эксперименты часто лучше или лучше достигают цели эксперимента.。ортогональный экспериментальный планВключает в себя две части：Первый,Как организовать эксперимент второй;,Как анализировать результаты экспериментов.

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

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

Официально: Ln(mk)

k – количество столбцов в таблице, обозначающих количество контролей (количество факторов)

m — количество значений для каждого контроля (уровень фактора)

n — количество строк в таблице, то есть количество комбинаций, которые необходимо проверить.

Ортогональная таблица Адрес запроса：https://www.york.ac.uk/depts/maths/tables/orthogonal.htm

ортогональное расположение：http://support.sas.com/techsup/technote/ts723_Designs.txt

Каковы характеристики метода разработки тестовых примеров с использованием ортогональной таблицы?

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

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

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

3. Обзор тест-кейса и изменения

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

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

Если это проверка внутри группы тестирования, она должна быть сосредоточена на:

1. Понятно ли описание самого тестового примера?

2. Учитывали ли вы эффективность выполнения тест-кейсов? Часто шаги в тест-кейсах выполняются неоднократно, но точки проверки разные, а избыточность дизайна теста все это приводит к низкой эффективности;

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

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

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

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

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

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

2. Сроки рассмотрения

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

3. Участвующие рецензенты

Здесь будет несколько уровней проверки.

1) Проверка отдела — проверка с участием всех членов отдела тестирования.

2) Обзор компании, в который входят менеджеры проектов, аналитики требований, дизайнеры архитектуры, разработчики и тестировщики.

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

4. Просмотрите контент

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

1) Является ли структурная организация проекта варианта использования ясной и разумной и способствует ли она эффективному покрытию требований.

2) Является ли приоритетное соглашение разумным.

3) Охвачены ли все функциональные пункты требований к тестированию.

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

5) Были ли удалены избыточные варианты использования.

6) Содержит ли он достаточно отрицательных тестовых случаев. адекватное определение,Если здесь используется2&8закон,Это в 4 раза больше положительных вариантов использования,Ведь надежное программное обеспечение,80% кода «защищает» 20% функциональной реализации.

7) Следует ли разрабатывать тестовые сценарии для сценариев использования пользователей и процессов использования на уровне пользователя.

8) Является ли он кратким и пригодным для повторного использования? Например, часто повторяющиеся шаги или процессы могут быть извлечены и определены как несколько стандартных шагов, допускающих многократное использование.

5. Метод оценки

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

2)Общий адрес электронной почты для связи с соответствующим персоналом

3) Общий инструмент обмена мгновенными сообщениями (офисная связь) для прямого общения с соответствующим персоналом.

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

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

6. Критерии завершения оценки

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

Издатель: Full stack программист и руководитель стека, укажите источник для перепечатки: https://javaforall.cn/167177.html Исходная ссылка: https://javaforall.cn