Разработка тестов

Содержание

Слайд 2

Введение Мы рассмотрели общие вопросы организации процесса тестирования и вопросы планирования

Введение

Мы рассмотрели общие вопросы организации процесса тестирования и вопросы планирования тестовых

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

Какие бывают тесты. Обсуждение. Перед вами обыкновенная ручка. Давайте подумаем, как её можно протестировать?

Какие бывают тесты. Обсуждение.

Перед вами обыкновенная ручка. Давайте подумаем, как её

можно протестировать?
Слайд 4

Какие бывают тесты (1/12) Тесты на основе требований (requirements based tests)

Какие бывают тесты (1/12)

Тесты на основе требований (requirements based tests)
Извлекается и

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

Какие бывают тесты (2/12) Функциональные тесты (functional test) Вставить в ручку

Какие бывают тесты (2/12)

Функциональные тесты (functional test)
Вставить в ручку стержень.
Переключить в

рабочее положение.
Написать несколько слов.
Переключить в нерабочее положение.
Извлечь стержень.
Слайд 6

Какие бывают тесты (3/12) Сравнительные («параллельные») тесты (parallel testing) Что мы

Какие бывают тесты (3/12)

Сравнительные («параллельные») тесты (parallel testing)
Что мы можем сказать

об этой ручке в сравнении с другими ручками, которые выпускает наша фирма?
Что мы можем сказать об этой ручке в сравнении с ручками, которые выпускают конкуренты?
В чём преимущества именно этой модели ручек?
Слайд 7

Какие бывают тесты (4/12) Сценарные тесты (scenario tests) Как ручку может

Какие бывают тесты (4/12)

Сценарные тесты (scenario tests)
Как ручку может использовать:
Секретарь.
Преподаватель.
Студент.
Школьник.
Прораб.
Сантехник.
Милиционер.
Моряк.
…

Слайд 8

Какие бывают тесты (5/12) Тесты ошибочных ситуаций (fault injection tests) Что

Какие бывают тесты (5/12)

Тесты ошибочных ситуаций (fault injection tests)
Что произойдёт, если

препятствовать выходу стержня в рабочее положение?
Какое усилие и где надо приложить к ручке, чтобы её сломать?
Если стержень застрял, легко ли его извлечь?
Что произойдёт, если писать по стеклу, асфальту?
Слайд 9

Какие бывают тесты (6/12) Тесты интерфейса (interface tests, GUI tests) Измерения:

Какие бывают тесты (6/12)

Тесты интерфейса (interface tests, GUI tests)
Измерения: высота, ширина,

длина, вес.
Цвет.
Читаемость логотипа фирмы-производителя.
Слайд 10

Какие бывают тесты (7/12) Тесты удобства использования (usability tests) Есть ли

Какие бывают тесты (7/12)

Тесты удобства использования (usability tests)
Есть ли у нас

какие-либо замечания по юзабилити ручек от пользователей?
Есть ли у нас представители целевых групп, чтобы привлечь их к тестированию?
Как много времени у пользователя занимает переключение ручки из нерабочего положения в рабочее и обратно?
Как быстро пользователь понимает, как пользоваться ручкой?
Как быстро пользователь привыкает к этой ручке?
Легко ли понять, какие стержни подходят к ручке?
Легко ли заменить стержень?
Может ли ручкой пользоваться левша?
Слайд 11

Какие бывают тесты (8/12) Тесты упаковки и документации (packaging/documentation tests) Вложена

Какие бывают тесты (8/12)

Тесты упаковки и документации (packaging/documentation tests)
Вложена ли в

упаковку копия текста о гарантийных обязательствах?
Ясно ли видно на упаковке, что внутри?
Легко ли открыть упаковку?
Насколько материалы упаковки вредны для окружающей среды?
Есть ли какие-то особые требования к упаковке?
На сайте, в каталоге, на упаковке написано и нарисовано одно и то же?
Текст на упаковке и в гарантийном обязательстве – на одном и том же языке?
На упаковке и в документации нет грамматических ошибок, опечаток и т.д.?
Слайд 12

Какие бывают тесты (9/12) Стрессовые тесты (stress tests) При какой температуре

Какие бывают тесты (9/12)

Стрессовые тесты (stress tests)
При какой температуре расплавится пластиковая

часть ручки?
При какой температуре потечёт стержень?
При какой температуре ручка перестаёт писать?
Какое воздействие необходимо применить к ручке, чтобы сломать её?
Пишет ли ручка под водой? А по мокрой бумаге?
Если ручку уронить в песок – что произойдёт?
А если уронить со стола?
А если из окна офиса?
Слайд 13

Какие бывают тесты (10/12) Тесты производительности (performance tests) Сколько текста можно

Какие бывают тесты (10/12)

Тесты производительности (performance tests)
Сколько текста можно написать ручкой

в единицу времени?
Как быстро ручку можно привести в рабочее положение?
Как много раз ручку можно переключить из нерабочего в рабочее положение, прежде чем её начнёт заедать?
Слайд 14

Какие бывают тесты (11/12) Конфигурационные тесты (configuration tests) Какие стержни подходят

Какие бывают тесты (11/12)

Конфигурационные тесты (configuration tests)
Какие стержни подходят к нашей

ручке?
На каких поверхностях она может писать?
Слайд 15

Какие бывают тесты (12/12) Законодательные тесты (regulation tests) Подлежит ли этот

Какие бывают тесты (12/12)

Законодательные тесты (regulation tests)
Подлежит ли этот продукт какому-то

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

Задача о треугольнике (1/5) Эту задачу предложил в 1979 году Гленфорд

Задача о треугольнике (1/5)

Эту задачу предложил в 1979 году Гленфорд Майерс

в своей книге «Искусство тестирования программ» («The Art Of Software Testing»). С тех пор она известна как «задача о треугольнике» и является своего классическим вопросом на множестве собеседований на должность тестировщика.
Программа производит чтение с перфокарты трёх целых чисел, которые интерпретируются как длины сторон треугольника. Далее программа печатает сообщение о том, является ли треугольник неравносторонним, равнобедренным или равносторонним.
Напишите на листе бумаги (или в файле) набор тестов, которые, как вам кажется, будут адекватно проверять эту программу. На это у вас десять минут.
Слайд 17

Задача о треугольнике (2/5) Были изучены различные версии данной программы и

Задача о треугольнике (2/5)

Были изучены различные версии данной программы и составлен

список общих ошибок. Оцените ваш набор тестов, попытавшись с его помощью ответить на приведенные ниже вопросы. За каждый ответ «да» присуждается одно очко.
Составили ли вы тест, который представляет правильный неравносторонний треугольник? (Ответ «да» на этот вопрос не засчитывается, если вы имеете в виду тесты, проверяющие значения длин сторон вида «1, 2, 3» или «2, 5, 10», так как не существует треугольников, имеющих такие стороны.)
Составили ли вы тест, который представляет правильный равносторонний треугольник?
Составили ли вы тест, который представляет правильный равнобедренный треугольник? (Тесты со значениями сторон «2, 2, 4» принимать в расчёт не следует, т.к., опять же, не бывает таких треугольников.)
Слайд 18

Задача о треугольнике (3/5) Составили ли вы по крайней мере три

Задача о треугольнике (3/5)

Составили ли вы по крайней мере три теста,

которые представляют правильные равнобедренные треугольники, полученные как перестановки двух равных сторон треугольника (например, «3, 3, 4», «3, 4, 3», «4, 3, 3»)?
Составили ли вы тест, в котором длина одной из сторон треугольника принимает нулевое значение?
Составили ли вы тест, в котором длина одной из сторон треугольника принимает отрицательное значение?
Составили ли вы тест, включающий три положительных целых числа, сумма двух из которых равна третьему? (Другими словами, если программа выдала сообщение о том, что числа «1, 2, 3» представляют собой стороны неравностороннего треугольника, то такая программа содержит ошибку.)
Составили ли вы по крайней мере три теста с заданными значениями всех трёх перестановок, в которых длина одной стороны равна сумме длин двух других сторон (например, «1, 2, 3», «1, 3, 2», «3, 1, 2»)?
Слайд 19

Задача о треугольнике (4/5) Составили ли вы тест из трёх целых

Задача о треугольнике (4/5)

Составили ли вы тест из трёх целых положительных

чисел, таких, что сумма двух из них меньше третьего числа (т. е. «1, 2, 4» или «12, 15, 30»)?
Составили ли вы по крайней мере три теста из категории 9, в которых вами испытаны все три перестановки (например, «1, 2, 4», «1, 4, 2», «4, 1, 2»)?
Составили ли вы тест, в котором все стороны треугольника имеют длину, равную нулю (т. е. «0, 0, 0»)?
Составили ли вы по крайней мере один тест, содержащий нецелые значения?
Составили ли вы хотя бы один тест, содержащий неправильное число значений (например, два, а не три целых числа)?
Специфицировали ли вы в каждом тесте не только входные значения, но и выходные данные программы?
Слайд 20

Задача о треугольнике (5/5) Конечно, нет гарантий, что с помощью набора

Задача о треугольнике (5/5)

Конечно, нет гарантий, что с помощью набора тестов,

который удовлетворяет вышеперечисленным условиям, будут найдены все возможные ошибки. Но поскольку вопросы 1+13 представляют ошибки, имевшие место в различных версиях данной программы, адекватный тест для неё должен их обнаруживать.
Отметим, что опытные профессиональные программисты набирают в среднем только 7-8 очков из 14 возможных.
Выполненное упражнение показывает нам, что тестирование даже тривиальных программ, подобных приведенной, – непростая задача.
И коль скоро это так, представьте трудности тестирования программ размером, например, в 1’000’000 и более операторов. А если это программа по управлению реактором АЭС?
Слайд 21

Классы эквивалентности (1/14) На только что рассмотренных примерах с ручкой и

Классы эквивалентности (1/14)

На только что рассмотренных примерах с ручкой и треугольником

вы могли убедиться, что набор тестов у вас получается неидеальным. А как его сделать лучше? Как убедиться, что тестов достаточно, и в то же время их не слишком много?
Для этого есть прекрасная техника – продумывание классов эквивалентности и граничных условий.
Слайд 22

Классы эквивалентности (2/14) Если мы ожидаем одинакового результата от выполнения двух

Классы эквивалентности (2/14)

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

более тестов, эти тесты эквивалентны. Такие множества тестов называются классами эквивалентности.
Признаки эквивалентности (несколько тесто эквивалентны, если):
Она направлены на поиск одной и той же ошибки.
Если один из тестов обнаруживает ошибку, другие её тоже, скорее всего, обнаружат.
Если один из тестов НЕ обнаруживает ошибку, другие её тоже, скорее всего, НЕ обнаружат.
Тесты используют одни и те же наборы входных данных.
Для выполнения тестов мы совершаем одни и те же операции.
Тесты генерируют одинаковые выходные данные или приводят приложение в одно и то же состояние.
Все тесты приводят к срабатыванию одного и того же блока обработки ошибок («error handling block»).
Ни один из тестов не приводит к срабатыванию блока обработки ошибок («error handling block»).
Слайд 23

Классы эквивалентности (3/14) Граничные условия (или просто – границы) – это

Классы эквивалентности (3/14)

Граничные условия (или просто – границы) – это те

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

Классы эквивалентности (4/14) Необходимо проверить, как работает поле, в которое можно

Классы эквивалентности (4/14)

Необходимо проверить, как работает поле, в которое можно ввести

целое число в диапазоне от 1 до 99.
Классы эквивалентности здесь:
Любое целое в диапазоне от 1 до 99. Как правило, это будет середина числового отрезка. Позитивный тест.
Любое число меньше 1. Негативный тест.
Любое число больше 99. Негативный тест.
Дробь и «не число» (буквы, спецсимволы). Негативный тест.
Тесты, которые мы выполним:
Ввести 1, 99, 50
Ввести 0
Ввести 100
Ввести 50.5, букву, спецсимвол: ~`!”@’#$;%:^&?*()[]{},.\/+=-_
Слайд 25

Классы эквивалентности (5/14) Рассмотрим ещё один пример. Программа предназначена для сложения

Классы эквивалентности (5/14)

Рассмотрим ещё один пример.
Программа предназначена для сложения двух целых

чисел.
Каждое из слагаемых – не более чем двузначное целое число.
Программа запрашивает у пользователя два числа, после чего выводит результат.
Ваши соображения?
Слайд 26

Классы эквивалентности (6/14) Допустим, мы написали первый тест: Первое слагаемое: 3 Второе слагаемое: 7 Сумма: 10

Классы эквивалентности (6/14)

Допустим, мы написали первый тест:
Первое слагаемое:
3
Второе слагаемое:
7
Сумма:
10

Слайд 27

Классы эквивалентности (7/14) Нужно ли проверять такие комбинации? 2 + 7

Классы эквивалентности (7/14)

Нужно ли проверять такие комбинации?
2 + 7 4 + 7 5

+ 7
3 + 8 3 + 6 3 + 5
3 + 3 7 + 3 7 + 7
2 + 2 6 + 4 2 + 5
(-3) + 7 (-3) + (-7) 3 + (-7)
0 + 7 3 + 0 0 + 0
99 + 7 3 + (-99) (-99) + 0
99 + 99 99 + (-99) (-99) + 99
100 + 3 100 + 100 100 + (-100)
Слайд 28

Классы эквивалентности (8/14) Выделим классы эквивалентности.

Классы эквивалентности (8/14)

Выделим классы эквивалентности.

Слайд 29

Классы эквивалентности (9/14) Выделим классы эквивалентности.

Классы эквивалентности (9/14)

Выделим классы эквивалентности.

Слайд 30

Классы эквивалентности (10/14) Выделим классы эквивалентности.

Классы эквивалентности (10/14)

Выделим классы эквивалентности.

Слайд 31

Классы эквивалентности (11/14) Порядок действий для выделения классов эквивалентности: В таблице

Классы эквивалентности (11/14)

Порядок действий для выделения классов эквивалентности:
В таблице перечисляются все

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

Классы эквивалентности (12/14) Что можно отразить на числовую прямую? Числа. Символы.

Классы эквивалентности (12/14)

Что можно отразить на числовую прямую?
Числа.
Символы.
Количество (например, количество разрешённых

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

Классы эквивалентности (13/14) Что можно отразить на числовую прямую? (продолжение) Размер

Классы эквивалентности (13/14)

Что можно отразить на числовую прямую? (продолжение)
Размер файла (особенно

кратный чему-либо).
Объём памяти (особенно кратный чему-либо).
Размер экрана, разрешение экрана.
Размер окна.
Количество цветов. Цветовую гамму.
Версии операционной системы.
Версии библиотек.
Время (в т.ч. между событиями).
Скорость передачи данных.
Объём передаваемых данных.
Интенсивность передачи данных.
Переключение между разными алгоритмами (количество, время, скорость).
Слайд 34

Классы эквивалентности (14/14) Ещё один пример. «Чтобы открыть файл, пользователь должен

Классы эквивалентности (14/14)

Ещё один пример.
«Чтобы открыть файл, пользователь должен кликнуть по

кнопке Открыть, выбрать файл и кликнуть по кнопке OK». Давайте абстрагируемся от пользовательского интерфейса и подумаем о файле. Какие случаи нам надо будет проверить?
«Корректный» файл
Заблокированный файл
Очень большой файл
Несуществующий файл
«Файл по сети»
Уже открытый файл (нашим приложением и другим приложением)
Файл неверного формата (по расширению и реальному содержимому)
Пустой файл
Повреждённый файл
Выводы:
Классы эквивалентности не всегда очевидны.
Как правило, негативных тестов получается больше, чем позитивных.
Принадлежность теста к позитивным или негативным зависит от требований.
Слайд 35

Выводы Рекомендации: Начинайте с простых очевидных тестов. Используйте простые и очевидные

Выводы

Рекомендации:
Начинайте с простых очевидных тестов. Используйте простые и очевидные значения для

передачи в программу. Если она завалится даже на таких значениях, это будет очевидным показателем того, что существуют проблемы.
Затем переходите к более сложным тестам. Если программа хорошо справляется с очевидными задачами, поставьте перед ней неочевидную.
Помните о граничных условиях. На граничных значениях можно построить много хороших тестов.
Если остаётся время, занимайтесь исследовательским тестированием.
Учитесь на своём и чужом опыте.
Последовательность выполнения (и разработки) тестов:
Просты позитивные.
Простые негативные.
Сложные позитивные.
Сложные негативные.
Слайд 36

Документирование тестов (1/3) Тесты документируются в виде т.н. «тестовых случаев» («test

Документирование тестов (1/3)

Тесты документируются в виде т.н. «тестовых случаев» («test cases»).
Что

же такое тест-кейс?
IEEE Std 610-1990:
«A set of test inputs, execution conditions, and expected results developed for a particular objective, such as to exercise a particular program path or to verify compliance with a specific requirement.»
(«Набор тестовых входных данных, условий выполнения и ожидаемых результатов, разработанных с конкретной целью, такой как проверка некоторого пути выполнения программы или проверка соответствия некоторому требованию.»)
IEEE Std 829-1983:
«Documentation specifying inputs, predicted results, and a set of execution conditions for a test item.»
(«Документ, определяющий набор входных данных, ожидаемых результатов и условий выполнения теста.»)
Далее в нашем курсе мы будем рассматривать слова «тест-кейс» и «тест» как синонимы (в случаях, если не оговорено обратное).
Слайд 37

Документирование тестов (2/3) Документируя тест, мы должны указать: Идентификатор теста (id).

Документирование тестов (2/3)

Документируя тест, мы должны указать:
Идентификатор теста (id).
Связанное с тестом

требование (related requirement).
Краткое заглавие теста (title).
Модуль и подмодуль приложения, к которым относится тест (module, submodule).
Приоритет теста (priority: smoke, critical, extended; A, B, C, D).
Исходные данные, необходимые для теста (initial data).
Шаги для выполнения теста (steps).
Ожидаемые результаты (expected results).
Отвести поле для пометки, прошёл тест или нет (passed or failed).
Указать автора теста (author), время последнего выполнения теста (last time run), последний полученный актуальный результат (actual result), связанный с тестом баг (если есть) (related bug).
В общем случае некоторые поля могут опускаться, и шаблон для оформления теста будет выглядеть вот так (см. рисунок)
Слайд 38

Документирование тестов (3/3) Иденти-фикатор Прио-ритет Связанное с тестом требование Модуль и

Документирование тестов (3/3)

Иденти-фикатор

Прио-ритет

Связанное с тестом требование

Модуль и подмодуль

Заглавие (суть) теста

Исходные данные,

необходимые для выполнения теста

Шаги

Ожидаемый результат по каждому шагу

Слайд 39

Зачем нужны тест-кейсы «Планирование, и только потом – выполнение!» Тест-кейсы дают

Зачем нужны тест-кейсы

«Планирование, и только потом – выполнение!» Тест-кейсы дают нам

структурированный системный подход, что снижает вероятность пропуска ошибки.
Тест-кейсы – хороший способ хранения части проектной информации.
Написание тест-кейсов – один из способов протестировать проектную документацию ещё до выхода первого билда.
Наличие тест-кейсов значительно ускоряет регрессионное тестирование.
Тест-кейсы – прекрасный способ быстро ввести в курс дела новичка или сотрудника, только что подключившегося к проекту.
Имея тест-кейсы, мы можем в любой момент «вспомнить», что мы делали месяц, полгода, год назад.
Мы можем обмениваться тест-кейсами (и «чек-листами») между проектами.
Тест-кейсы позволяют легко отслеживать прогресс (X% тестов выполнено, Y% тестов прошло (завалилось), Z% требований покрыто тестами).
Слайд 40

Хороший тест-кейс – каков он? Тест-кейсы могут быть: Специфичными или общими.

Хороший тест-кейс – каков он?

Тест-кейсы могут быть:
Специфичными или общими.
Простыми или сложными.
Независимыми

или связанными друг с другом.
Позитивными или негативными.
Слайд 41

Специфичность или общность? Оба тест-кейса делают одну и ту же проверку.

Специфичность или общность?

Оба тест-кейса делают одну и ту же проверку. Какой

из них лучше?

Оказывается, оба варианта – плохие. Почему?

Слайд 42

Специфичность или общность? Когда все детали прописаны до мелочей, при повторных

Специфичность или общность?

Когда все детали прописаны до мелочей, при повторных выполнениях

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

Специфичность или общность? Здесь мы не привязаны к конкретным значениям. Мы

Специфичность или общность?

Здесь мы не привязаны к конкретным значениям.
Мы знаем, как

проверить результат.
Мы сокращаем время написания и поддержки теста ссылкой на шаги 1-4.
Мы перечислили значения, представляющие для нас особый интерес.
Слайд 44

Простота или сложность? Где в ниже перечисленном простые тест-кейсы, а где

Простота или сложность?

Где в ниже перечисленном простые тест-кейсы, а где –

сложные?
Набор 1:
1. Откройте файл «1.txt». Файл открыт.
2. Введите слово «Дом». Появляется слово «Дом.
3. Сохраните файл. Кнопка «Сохранить» становится неактивной.
Набор 2:
1. В документе размером более 100 Мб создайте таблицу 100x100, в ячейку 50x50 вставьте картинку размером 30 Мб, применив к ней функцию «Авторасположение». Проверьте результат.
Простые тесты оперируют за раз одним объектом.
Слайд 45

Простота или сложность? Каковы преимущества простых тест-кейсов? Их легко выполнять. Они

Простота или сложность?

Каковы преимущества простых тест-кейсов?
Их легко выполнять.
Они понятны новичкам.
Они упрощают

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

Независимость или связанность? Каковы преимущества независимого самостоятельного тест-кейса? Его легко и

Независимость или связанность?

Каковы преимущества независимого самостоятельного тест-кейса?
Его легко и просто выполнить.
Такие

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

Позитивность или негативность? Позитивные тесты проверяют, что приложение делает то, на

Позитивность или негативность?

Позитивные тесты проверяют, что приложение делает то, на что

оно рассчитано (т.е. такие тесты используют корректные данные и условия выполнения).
Негативные тесты проверяют работу приложения в нестандартных условиях (при получении некорректных данных или команд или в при работе в некорректных условиях).
Обе разновидности тестов важны и нужны, однако следует помнить последовательность их разработки и выполнения:
1. Простые позитивные.
2. Простые негативные.
3. Сложные позитивные.
4. Сложные негативные.
Слайд 48

Язык написания тестов Одним из важных правил оформления теста является язык

Язык написания тестов

Одним из важных правил оформления теста является язык написания.
Рекомендации:
Используйте

активный залог: («open», «paste», «click»). В русском языке используйте безличную форму: «открыть» (вместо «откройте»).
Описывайте поведение системы: «появляется окно…», «приложение закрывается».
Используйте простой технический стиль.
ОБЯЗАТЕЛЬНО указывайте ТОЧНЫЕ названия всех элементов приложения.
Не объясняйте базовые понятия работы с ОС.
Слайд 49

Заключение: хороший тест-кейс Хороший тест-кейс удовлетворяет следующим критериям: Обладает высокой вероятностью

Заключение: хороший тест-кейс

Хороший тест-кейс удовлетворяет следующим критериям:
Обладает высокой вероятностью обнаружения ошибки.
Исследует

соответствующую («ту, которую надо») область приложения.
Выполняет какие-то интересные действия.
Не выполняет ненужных действий.
Является не слишком простым, но и не слишком сложным.
Не является избыточным по отношению к другим тестам.
Делает обнаруженную ошибку очевидной.
Позволяет легко диагностировать ошибку.
Слайд 50

Тестовые сценарии Тестовый сценарий – набор тестов (тест-кейсов), собранных в последовательность

Тестовые сценарии

Тестовый сценарий – набор тестов (тест-кейсов), собранных в последовательность для

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

Тестовые сценарии: рекомендации Пишите сценарий для отдельной части приложения. Пишите отдельно

Тестовые сценарии: рекомендации

Пишите сценарий для отдельной части приложения.
Пишите отдельно сценарии для

Smoke и Critical Path тестов.
Постепенно повышайте сложность тестов.
Организуйте сценарий логично.
Слайд 52

Тестовые сценарии: рекомендации Используйте группировку Используйте фильтры Используйте отдельные листы

Тестовые сценарии: рекомендации

Используйте группировку

Используйте фильтры

Используйте отдельные листы

Слайд 53

Тестовые сценарии: рекомендации Используйте один тест для ОДНОЙ проверки. Помните, что

Тестовые сценарии: рекомендации

Используйте один тест для ОДНОЙ проверки.
Помните, что заголовки тестов

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

Техники ускорения написания тестов Copy-paste. Если по ходу разработки тестов возникают

Техники ускорения написания тестов

Copy-paste.
Если по ходу разработки тестов возникают вопросы, пишите

их прямо в документ с тестами, помечая красным цветом.
Используйте т.н. «косметику» (жирный, подчёркнутый, наклонный шрифт, разные цвета т.д.) Это значительно повышает читаемость документа.
По-максимуму используйте возможности ПО, в котором вы разрабатываете тесты (группировки, фильтры, ссылки и т.д.)
Если вы пишете тесты в файле, обязательно прописывайте в самом файле историю его изменения.
Слайд 55

Шаги разработки тестов 1. Начинайте как можно раньше, ещё до выхода

Шаги разработки тестов

1. Начинайте как можно раньше, ещё до выхода первого

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

Шаги разработки тестов 2. Разбивайте приложение на отдельные части/модули.

Шаги разработки тестов

2. Разбивайте приложение на отдельные части/модули.

Слайд 57

Шаги разработки тестов 3. Для каждой области/модуля пишите чек-лист. Так проще

Шаги разработки тестов

3. Для каждой области/модуля пишите чек-лист.
Так проще проверить, всё

ли нужное предусмотрено, нет ли чего лишнего.
Удобно реорганизовывать наборы тестов.
Легко увидеть, где можно использовать copy-paste.
Так можно разделять интеллектуальную и рутинную работу.
Внимание!
Просто скопированное требование – ЭТО НЕ ТЕСТ!
Если пишете в Excel/Word – начинайте каждый новый тест в новой строке таблицы.
Если что-то непонятно – СРАЗУ ЖЕ записывайте вопрос.
Слайд 58

Шаги разработки тестов 4. Пишите вопросы, уточняйте детали, добавляйте «косметику», используйте copy-paste.

Шаги разработки тестов

4. Пишите вопросы, уточняйте детали, добавляйте «косметику», используйте copy-paste.

Слайд 59

Шаги разработки тестов 5. Получите рецензию коллег-тестировщиков, разработчиков, заказчиков. Так вы

Шаги разработки тестов

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

ответы на вопросы:
Пропущено ли что-то?
Есть ли избыточные тесты?
Легко ли ваши тесты понять?
Этого ли ожидает заказчик?
Есть ли в тестах ошибки?
Вы получаете ещё одну точку зрения на ситуацию.
Коллеги могут заметить те ошибки, которые вы пропустили.
У коллег может оказаться та информация, которой не было у вас.
У разработчиков может быть своё мнение по поводу той или иной функциональности.
Рецензирование (перепросмотр) хорошо стимулирует повышение качества разработки тестов.
Слайд 60

Шаги разработки тестов 6. Обновляйте тесты, как только обнаружили ошибку или

Шаги разработки тестов

6. Обновляйте тесты, как только обнаружили ошибку или изменилась

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

Пример разработки тестов

Пример разработки тестов

Слайд 62

Пример разработки тестов

Пример разработки тестов

Слайд 63

Пример разработки тестов

Пример разработки тестов

Слайд 64

Пример разработки тестов

Пример разработки тестов

Слайд 65

Пример разработки тестов

Пример разработки тестов

Слайд 66

Пример разработки тестов

Пример разработки тестов

Слайд 67

Пример разработки тестов

Пример разработки тестов

- Предыдущая
Годы учебы в Кумакской школе. Выпуск 1976
Следующая -
Общая физиология желёз внутренней секреции. Гипоталамо-гипофизарная система

Похожие презентации

Основы классификации (объектов)
AppSec - хакерский путь. Анализ защищённости приложений
Презентация "Создание школьного сайта" - скачать презентации по Информатике
Логические элементы
Администрирование Alfresco Community Edition
Программирование. Введение в Java и С# (Тема 1)
Эффективная работа с информационной системой
Разработка урока в условиях дистанционного обучения
Создание виртуальных экскурсий по библиотеке
Sissejuhatus informaatikasse. 11. Loeng
Мультимедийные среды и цифровые инструменты в междисциплинарной проектной деятельности в предметной области
Аппаратное и программное обеспечение ЭВМ и сетей
Облачные хранилища
Структура персонального компьютера
Моделирование как метод познания
Статья в научное издание. Структура статьи. Этапы работы
Создание базы данных
Работа с файлами в Паскале
Презентация "Блок схемы" - скачать презентации по Информатике
Электронные ресурсы библиотеки
Информационная безопасность Основные понятия Законодательство в сфере защиты информации
Обработка графической информации формирование изображения на экране монитора
Дистанційне навчання
Емпірична інженерія програмного забезпечення. (Лекція 2)
Основные этапы решения задач на компьютере
Основы языка программирования JAVA. Циклы
Всероссийский конкурс прорывных проектов в области IT-технологий IT-прорыв
Обработка графической информации. § 28. Векторная графика
Вы можете прислать нам Вашу презентацию и мы опубликуем ее на сайте.
Обратная связь
Для правообладателей
Email: Нажмите что бы посмотреть