Создание тестовых случаев в Excel

Обновлено: 21.11.2024

Использование Excel для тестовых данных

Доктор. Джеймс Маккефри

Код доступен для загрузки по адресу: TestRun2006_11.exe(171 КБ)

Содержание

Тестируемая библиотека
Файл данных тестового набора
Создание тестового набора
Сохранение результатов
Подведение итогов

Если вы пишете средства автоматизации тестирования, вы можете выбрать четыре взаимодополняющих подхода: купить и использовать коммерческую тестовую среду (включая Visual Studio® 2005 Team System, в которой есть несколько интересных новых функций), использовать тестовую среду с открытым исходным кодом, напишите собственную тяжелую автоматизацию (обычно более четырех страниц кода) или напишите облегченную автоматизацию (обычно менее четырех страниц кода). Большинство моих статей «Тестовый прогон» посвящены методам упрощенной автоматизации. При написании упрощенной автоматизации тестирования одним из лучших вариантов хранения данных тестовых наборов и результатов тестов является использование Microsoft® Excel®.

Предположим, вы пишете игру в криббедж, подобную той, что показана на рис. 1. В криббедже ваша рука состоит из пяти карт: четыре в вашей руке и одна общая для вас и вашего оппонента. Ваш балл определяется рядом факторов, таких как количество пар в вашей руке и количество комбинаций карт, которые вы держите в сумме до 15. Каждая пара приносит 2 очка, а каждый набор карт, сумма которых равна 15, стоит 2 балла. Карты с картинками считаются за 10, тузы засчитываются за 1, а все остальные карты засчитываются как их очки. Для руки, показанной на Рисунке 1, значение пары равно 2, потому что существует единственная пара семерок. Значение 15s равно 6, потому что есть три комбинации карт, сумма которых равна 15: 7 бубнов и 8 треф; 7 треф и 8 треф; бубновая 7, трефовая 7 и червовый туз.

Рис. 1** Тестируемое приложение**

Незаметно пользовательский интерфейс игры обращается к написанной вами библиотеке классов CribbageLib. Эта библиотека содержит классы для представления объектов Card и Hand, а также методы и свойства, такие как Hand.ValueOfPairs и Hand.ValueOf15s.

В этой колонке я представлю методы использования Excel для хранения данных тестовых случаев и сохранения результатов тестов, как это показано в программе, показанной на рис. 2. Облегченная тестовая система начинается с проверки того, данные дела есть. (Кратко я объясню, как настроить электронную таблицу Excel, чтобы вы могли читать ее программным способом.) Затем программа исследует данные Excel, чтобы определить количество тестовых случаев, а затем считывает все данные Excel в объект памяти DataTable. (Альтернативный подход чтения по одному тестовому набору за раз я буду обсуждать в последнем разделе этой колонки.) Обвязка создает новую электронную таблицу Excel для хранения результатов тестового набора, а затем выполняет каждый тестовый пример. Обвязка определяет результат прохождения/непрохождения для каждого теста, распечатывает результат на консоли и сохраняет результат в электронной таблице Excel. Полный исходный код тестового комплекта и тестируемой библиотеки находится в пакете кода, который прилагается к этой колонке.

В следующих разделах я кратко опишу тестируемую библиотеку классов, чтобы вы поняли, как настроить соответствующие электронные таблицы Excel для хранения. Я представлю код простой тестовой программы, которая дала результаты, показанные на рис. 2. Я подробно объясню код, чтобы вы могли изменять и расширять код для использования Excel в соответствии с вашими потребностями. И закончу очень кратким обсуждением того, как и когда использовать Excel для тестового хранилища, рассматривая плюсы и минусы этого подхода по сравнению с другими типами тестового хранилища (базы данных SQL Server™, текстовые файлы и XML-файлы в особый). Я полагаю, что возможность использовать Excel в качестве упрощенного хранилища тестов станет для вас полезным дополнением к вашему набору инструментов для тестирования, разработки и управления программным обеспечением.

Рис. 2** Использование Excel для хранения тестовых данных **(Щелкните изображение, чтобы увеличить его)

Тестируемая библиотека

Рис. 3. Структура библиотеки CribbageLib

Библиотека CribbageLib содержит класс Card для представления одной карты. Я использую поля int ранг, масть и значение для представления ранга (например, туз, двойка, тройка), масти (трефа, бубна, черва, пика) и значения в криббидже (тузы дают 1 очко, двойки 2, лицевые карты — 10 очков). Конструктор Card принимает строку (например, «Ac» для туз треф), анализирует два входных символа и сохраняет значения для трех соответствующих полей-членов. Для удобства при написании метода ToString() я также сохраняю строковое поле с именем image, которое является просто входным аргументом. Класс Hand представляет собой массив из пяти объектов Card, представляющих четыре карты, которые держит игрок, плюс одна общая карта, которую используют оба игрока. Конструктор Hand принимает пять объектов Card.

Основой моей тестируемой библиотеки классов CribbageLib являются свойства Hand.ValueOf15s и Hand.ValueOfPairs.Эти свойства возвращают количество очков для количества 15 в руке криббеджа и количество очков для количества пар в руке. Хотя цель моей библиотеки CribbageLib — просто предоставить образец для тестирования, свойства ValueOf15s и ValueOfPairs сами по себе представляют собой довольно интересные небольшие проблемы. Я действительно видел, как они использовались в качестве вопросов для собеседования. Однако, что касается этого столбца, если вы хотите использовать Excel для облегченного тестового хранилища, вам не нужно знать подробности реализации свойств. Вы можете обращаться с этими свойствами как с черными ящиками, у которых есть ожидаемые результаты для определенного ввода.

Файл данных тестового примера

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

Для этого примера я хочу сохранить идентификационный номер тестового примера (например, "00001"), ввод тестового примера (например, "Ah7d7c8cJs") для представления руки криббеджа, значение, указывающее, какое свойство класса я отправляю ввод (например, «ValueOf15s») и ожидаемый результат (например, «6»). Итак, я запускаю Excel, вручную ввожу соответствующие имена столбцов («caseID», «ввод», «метод» и «ожидаемый») и вручную ввожу данные своего тестового примера. Чтобы присвоить электронной таблице имя виртуальной таблицы, я выбираю ячейки заголовка столбца (в данном случае ячейки от A1 до D1), а затем ввожу имя таблицы в поле имени Excel в верхнем левом углу электронной таблицы. В данном случае я назвал свою таблицу tblTestCases, как показано на рисунке 4.

Рис. 4** Данные тестового примера в Excel **(Щелкните изображение, чтобы увеличить его)

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

Создание тестового набора

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

Рис. 5. Структура тестового набора

Я начинаю свой тест с добавления ссылки на проект к компоненту CribbageLib.dll, в котором находится тестируемая библиотека. Затем я добавляю оператор using для пространств имен в библиотеке, чтобы иметь возможность ссылаться на классы Card и Hand, не уточняя их имена полностью. Кроме того, я добавляю оператор using в пространство имен System.Data.OleDb, содержащее классы, которые можно использовать для подключения, доступа и управления источниками данных OLE DB, включая электронные таблицы Excel. Я также добавляю оператор using в пространство имен System.Data, чтобы можно было легко создать экземпляр объекта DataTable и использовать его в качестве хранилища данных в памяти для данных тестового примера из Excel. Поскольку эта колонка по сути является учебным пособием, для простоты я организую свои тестовые наборы в один метод Main — однако вы можете подумать о том, чтобы сделать свои наборы инструментов более модульными.

Здесь я создаю строку подключения, в которой указывается соответствующий поставщик OLE DB, расположение и дополнительная информация. Вы должны быть осторожны с синтаксисом. Обратите внимание, что в свойстве «Расширенные атрибуты» я использую последовательность «\», чтобы вставить символ двойной кавычки в строку подключения. Атрибут HDR=YES указывает, что мой рабочий лист Excel имеет начальную строку заголовка. Часть «Excel 8.0» напрямую не ссылается к версии программы Excel на моем компьютере — это относится к установленному формату базы данных Jet ISAM (Indexed Sequential Access Method).Вы можете проверить версию ISAM на своем компьютере, просмотрев параметр системного реестра HKEY_LOCAL_MACHINE\Software\Microsoft\ Jet\4.0\ISAM Formats. Затем я создаю объект OleDbConnection, передавая строку подключения в конструктор. Я вызываю метод Open, чтобы установить соединение с моей электронной таблицей Excel. Затем я создаю строку выбора, которая вернет количество не- Строки NULL в моей электронной таблице, которые будут количеством тестовых случаев, поскольку строка заголовка не влияет на возвращаемое значение.Это, конечно, предполагает, что у меня нет пустых строк в данных тестового примера Excel. Обратите внимание на несколько необычный синтаксис оператора SELECT, который ссылается на мои данные Excel. Я заключаю свою виртуальную таблицу в квадратные скобки и добавляю символ $ к имени виртуальной таблицы. Я указываю диапазон A1:A65536, потому что 65536 — это максимальное количество строк, поддерживаемое на листе Excel. Наконец, я использую метод ExecuteScalar класса OleDbCommand, чтобы я мог зафиксировать возвращаемое значение числа тестовых случаев в переменную с именем count. И я завершаю тестовый код, закрывая OleDbConnection.

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

В этом фрагменте я создаю новую строку подключения. Я мог бы использовать ту же строковую переменную, что и для проверки количества тестовых случаев; Я использую другую строковую переменную только для ясности и для того, чтобы вам было проще разбить мой код на модули, если хотите. Затем я создаю новый объект OleDbConnection. Опять же, я мог бы повторно использовать объект подключения, который я использовал для зонда подсчета тестовых случаев. После открытия соединения я вычисляю последнюю строку данных тестового примера, добавляя 1 к количеству фактических тестовых случаев в электронной таблице Excel — дополнительная 1 приходится на строку заголовка. Затем я создаю строку SELECT, объединяя первую часть выборки с переменной, содержащей номер последней строки, содержащей данные тестового примера.

Чтобы заполнить объект DataTable в памяти данными тестового примера, я создаю OleDbDataAdapter. Затем я создаю новый объект DataTable для хранения всех данных тестового примера. Я использую метод FillSchema OleDbDataAdapter для настройки атрибутов DataTable в соответствии с моим источником данных Excel. Затем я вызываю метод Fill, который фактически передает данные тестового примера из Excel в память. И я заканчиваю, закрывая OleDbConnection. Очень чисто и просто.

Теперь, когда все данные моего тестового примера сохранены в памяти, я готов создать новую электронную таблицу Excel для хранения результатов моего тестового набора. Код аналогичен другим моим задачам Excel, за исключением того, что на этот раз я использую объект OleDbCommand (см. рис. 6).

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

Я начинаю с получения системной даты и времени, чтобы создать имя файла результатов с отметкой времени. Я передаю аргумент "s" методу ToString(), чтобы получить строку даты и времени в сортируемом формате (например, 2006-07-23T16:56:44). Но поскольку символ : недопустим в имени файла, я использую метод String.Replace для замены всех символов : дефисами.

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

Затем я создаю строку CREATE в стиле SQL, указывающую имя виртуальной таблицы tblResults. Обратите внимание, что я могу указать тип данных для каждого столбца. Вы должны быть немного осторожны здесь, потому что многие типы данных SQL не сопоставляются точно с типами данных Excel. Альтернативный подход состоит в том, чтобы просто спроектировать файл результатов таким образом, чтобы все столбцы были данными типа varchar. Затем, если вам нужно выполнить некоторый числовой анализ результатов теста в Excel (например, вычислить среднее или максимальное значение), вы можете вручную отформатировать анализируемые столбцы в соответствующий тип Excel (например, число или процент).

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

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

Затем я устанавливаю переменные тестового набора и печатаю простой заголовок вывода. Я объявляю строковые переменные для хранения идентификатора моего тестового примера, ввода моего тестового примера, тестируемого метода (или свойства в этом примере) и индикатора результата ("пройдено" или "не пройдено"). Я объявляю ожидаемые и фактические переменные int для хранения ожидаемого возвращаемого значения из тестируемого метода (которое хранится в моей DataTable в памяти) и фактического результата, возвращаемого при вызове тестируемого метода тестовой обвязкой. Делается это так:

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

Я использую метод String.Substring для анализа каждой пары символов, например 7c, которые представляют объект Card. Первый целочисленный аргумент Substring — это отсчитываемое от нуля значение индекса того места в строке, с которого начинается извлечение подстроки. Второй целочисленный аргумент — это количество символов для извлечения (в отличие от конечного индекса, как вы могли подумать). Я разветвляюсь по значению метода переменной и вызываю тестируемый метод, фиксируя фактическое возвращаемое значение. Наконец, чтобы завершить основной тестовый цикл, я определяю дату и время выполнения своего тестового примера, определяю результат теста, создаю строку INSERT, вывожу результат на консоль и вставляю результат в таблицу результатов Excel:

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

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

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

Новая система Microsoft Office 2007 расширит ваши возможности использования Excel для хранения тестовых данных. Новые форматы Office XML для Excel, Word и PowerPoint® привносят несколько улучшений программной совместимости в разработку и тестирование программного обеспечения. Поскольку новый формат файлов Excel .xlsx основан на XML, он обеспечит улучшенные возможности управления файлами и улучшенную способность восстанавливать поврежденные файлы. А поскольку форматы Office XML используют технологию сжатия ZIP, файлы тестовых данных будут значительно меньше.

Дополнительную информацию о новых форматах файлов Microsoft Office 2007 см. в колонке Теда Паттисона «Основные инстинкты» в этом выпуске журнала MSDN®Magazine.

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

Большинство компаний используют инструменты управления тестовыми сценариями, такие как Quality Center (HP QC), JIRA и т. д., а некоторые компании до сих пор используют таблицы Excel для написания тестовых сценариев.

Посмотрите видео ниже, чтобы посмотреть «Как писать тестовые случаи вручную»

В чем разница между тестовым сценарием и тестовым набором?

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

Например: проверьте возможность входа в учетную запись Gmail.

Предположим, что нам нужно написать тестовые примеры для сценария (подтвердите вход в учетную запись Gmail).

Вот несколько тестовых примеров.

<р>1. Введите действительное имя пользователя и действительный пароль
2. Введите действительное имя пользователя и неверный пароль
3.Введите неверное имя пользователя и действующий пароль
4. Введите неверное имя пользователя и неверный пароль

Кто пишет тестовые случаи?

  • Разработчики пишут модульные тесты
  • Разработчики и тестировщики пишут интеграционные тесты
  • Тестировщики пишут приемочные тесты

Общий формат шаблона тестового случая

Найдите скриншот шаблона тестового примера ниже:

Как писать тестовые случаи в ручном тестировании

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

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

Правильно выберите тестовые случаи из тестовых сценариев

Пример:

Тестовый сценарий: подтвердите вход в Gmail
Тестовый пример: введите правильное имя пользователя и пароль

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

Пример: для входа в систему требуется действующая учетная запись Gmail

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

  • Введите имя пользователя
  • Введите пароль
  • Нажмите кнопку входа.

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

Пример:

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

Пример: успешный вход

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

Пример: отображается почтовый ящик Gmail

Результат, который показывает система после выполнения тестового примера. Зафиксируйте результат после выполнения. На основе этого результата и ожидаемого результата мы устанавливаем статус тестового примера.

Пример: перенаправление в папку "Входящие" Gmail

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

Пример:

Другие важные поля шаблона тестового примера:

Имя проекта: название проекта, которому принадлежат тестовые примеры

Имя модуля: имя модуля, которому принадлежат тестовые примеры

Справочный документ: укажите путь к справочным документам (если таковые имеются, например, документ с требованиями, план тестирования, сценарии тестирования и т. д.)

Кто создал: имя тестировщика, создавшего тестовые наборы

Дата создания: когда были созданы тестовые случаи

Проверил: имя тестировщика, создавшего тестовые наборы

Дата проверки: время проверки тестовых случаев

Кто выполнил: имя тестировщика, выполнившего тестовый набор

Дата выполнения: когда был выполнен тестовый пример

Комментарии: включите ценную информацию, которая поможет команде

Рекомендации по написанию хороших тестов

Характеристики хорошего тестового примера

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

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

Легко понять и выполнить:

Чтобы сделать тестовые примеры простыми для понимания и выполнять их быстрее, нам нужно использовать простой и понятный язык, такой как «Перейти на страницу входа», «ввести имя пользователя», «ввести пароль», «нажать кнопку входа» и т. д. вкл.

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

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

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

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

Подготовьте четкое описание:

Описание вашего тестового примера должно быть достаточно четким, чтобы понять, что тестировщик собирается делать с этим тестовым набором.

Добавьте правильные предварительные и постусловия:

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

Укажите точный ожидаемый результат:

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

Тестовые наборы должны быть пригодны для повторного использования и сопровождения:

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

Используйте методы тестирования:

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

Получите экспертную оценку:

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

Популярные инструменты управления тестовыми наборами

  1. Практитест
  2. Проверить рельсы
  3. Тестовая панель
  4. Кейс
  5. Кларос
  6. Тестовая совместная работа
  7. Кметри
  8. Мелиора Тестлаб
  9. Тестовая ложа
  10. ТестКейсЛаб

Не пропустите эту подробную статью о лучших инструментах управления тестовыми наборами на рынке.

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

Мы начнем с процедуры написания тестового примера в листе Excel. Это первый тестовый пример, где мы начнем с основ.

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

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

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

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

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

Согласно стандартным параметрам тестового примера:

Описание тестового случая

Действительные и недействительные тестовые данные

Статус — Пройдено или Не пройдено

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

В организации регулярно или практически используются инструменты выполнения тестовых сценариев, такие как Quality Center, Microsoft Test Manager (MTM), для написания тестовых случаев. Каждый инструмент определяет собственную структуру шаблона тестового примера.

Как будто я работаю с Microsoft Test Manager (MTM) и пишу тестовые примеры следующим образом.

Прежде чем приступить к написанию тестового примера в листе Excel, мы увидим некоторые параметры тестового примера:

Следующие разделы отображаются как: Главная Поиск контента Поиск документов Календарь Профиль пользователя Справка

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

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

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

Управление тестовым набором

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

  • Тестовая лаборатория
  • QTest
  • Тестовая ссылка
  • Центр качества
  • Практитест
  • ТФС

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

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

Электронная почта/номер телефона/имя пользователя — текстовое поле

Запомнить меня — флажок

Оставаться в системе — флажок

Забыли пароль – ссылка

Зарегистрироваться/Создать учетную запись-кнопка

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

Мы также сосредоточимся на примере тестового примера для ручного тестирования и примере тестового набора для веб-приложения.

Шаблон плана тестирования:

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

(Название продукта)

(Имена составителей)

СОДЕРЖАНИЕ

2.0 ЦЕЛИ И ЗАДАЧИ

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

4.1 Альфа-тестирование (модульное тестирование)

4.2 Системное и интеграционное тестирование

4.3 Производительность и стресс-тестирование

4.4 Приемочное тестирование пользователей

4.5 Пакетное тестирование

4.6 Автоматическое регрессионное тестирование

4.7 Бета-тестирование

5.0 Требования к оборудованию

6.0 Требования к среде

Расписание тестирования 7.0

8.0 Процедуры контроля

Функции 9.0 для тестирования

Функции 10.0, которые нельзя тестировать

11.0 Ресурсы/Роли и обязанности

13.0 Значительно затронутые отделы (SID)

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

Жизненный цикл тестирования:

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

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

  • Анализ требований
  • Планирование тестирования
  • Дизайн тестового набора
  • Выполнение тестового набора
  • Конец цикла тестирования

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

Сценарий тестирования:

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

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

Шаблон тестового сценария:

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

Нам нужно сослаться на Excel на следующие пункты, такие как:

  • Идентификатор тестового сценария
  • Справочный документ по требованиям
  • Описание тестового сценария
  • Важность — другими словами, приоритет
  • тестовых случаев

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

Как писать тестовые сценарии:

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

Идентификатор тестового сценария — 1

Справочный документ по требованиям – вход в приложение (xxxx)

Описание тестового сценария —

Чтобы успешно войти в приложение с действительными учетными данными

Укажите действительное имя пользователя в текстовом поле Имя пользователя

Укажите действительный пароль в текстовом поле "Пароль"

Убедитесь, что пользователь успешно вошел в приложение.

Важность – высокая

Количество тестов — 1

«Написание тестового сценария» — это практическая вещь, для которой вам необходимо иметь четкое представление о тестовом сценарии, как описано выше.

Пример теста:

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

Описание тестового случая — проверка успешного входа в систему с действительным пользователем

Фактические результаты — укажите действительные данные пользователя с паролем

Ожидается — пользователь успешно вошел в приложение

Тестовые данные — имя пользователя и пароль

Тестовые примеры для пера:

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

Есть некоторые предварительные условия для написания тестовых случаев для ручки: ручка должна иметь стержень, а стержень должен иметь чернила.

  1. Убедитесь, что пользователь может удобно держать перо.
  2. Убедитесь, что пользователь может писать плавно.
  3. Проверьте поток чернил. Он не должен переливаться
  4. Убедитесь, что качество материала пера хорошее, но не твердое.
  5. Убедитесь, что название бренда или компании должно быть указано на ручке.
  6. Убедитесь, что другие стержни подходят или не подходят к той же ручке.
  7. Убедитесь, что пользователь может писать на бумаге любого типа, включая гладкую, шероховатую, толстую, тонкую, глянцевую и т. д.
  8. Убедитесь, что колпачок пера открывается плавно.
  9. Убедитесь, что захват пера гладкий.
  10. Проверьте цвет чернил: черный, синий, зеленый.

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

Шаблон тестовых случаев

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

  • Нет
  • Описание тестового набора
  • Фактический результат
  • Ожидаемый результат
  • Тестовые данные

Как писать тестовые примеры с помощью инструментов

Мы можем написать тестовые примеры в Excel, а также в инструментах управления тестированием, таких как JIRA, qtest, MTM, и они следуют аналогичному формату для написания тестовых случаев.

Написание тестов

Основная цель состоит в том, чтобы написать тестовые примеры, чтобы определить, «что» и «как». Это часть процесса стратегии тестирования.

Для написания тестовых случаев необходимы как знания, так и опыт.

Типы тестов

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

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

Функциональное тестирование

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

Тестирование пользовательского интерфейса

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

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

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

Заключение статьи:

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

Если у вас есть какие-либо сомнения, не стесняйтесь спрашивать в разделе комментариев. Я отвечу на все.

Добавьте логин на свой сайт за 5 минут совершенно бесплатно!

Бесплатная регистрация Никаких скрытых платежей. Кредитная карта не требуется.

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

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

Преимущества использования тестовых наборов в таблицах Excel

  1. Легко обрабатывать тестовые наборы на листе.
  2. Легко прикреплять ссылки.
  3. Легко обмениваться таблицами с членами команды.
  4. Легко использовать несколько цветов на листе.

Идентификатор тестового случая: это поле определяется типом тестируемой системы. Ниже приведены стандартные правила:

  • Если мы создаем тестовый пример для любого приложения, которое не принадлежит какому-либо конкретному модулю, идентификатор будет начинаться как TEST_ID 1.
  • Если мы создаем тестовые примеры для какого-либо конкретного модуля, ID будет использоваться как MOD_ID 1.
  • Если тестовый пример имеет более одного ожидаемого результата, мы можем использовать тестовые наборы как TEST_ID 1.1, TEST_ID 1.2 и т. д. Все эти тестовые наборы являются частью TEST_ID 1.

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

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

  1. Feature Of Product: это поле определяет характеристику продукта для того типа продукта, который мы используем. Основное преимущество сохранения этого поля заключается в том, что в будущем, если какие-либо требования изменятся, мы сможем легко подсчитать, сколько тестовых случаев затронуты этим, и мы изменим или удалим тестовые случаи.**
  2. Описание функции. В этом поле указывается, какой тип функции мы будем тестировать при каких условиях.**
  3. Выполняемые шаги. Это шаги, которые необходимо выполнить в тестируемой системе, чтобы получить ожидаемые результаты. Шаги должны быть понятными и правильными. Они записываются и выполняются в соответствии с последовательностью.**
  4. Ожидаемый результат. Это желаемые результаты выполненных шагов выполнения. Результаты должны быть четко определены для каждого шага. Он указывает, какие спецификации и что мы получим от конкретной спецификации.
  5. Фактический результат: в этом поле отображается реальный результат после выполнения шагов выполнения в тестируемой системе. Если результат совпадает с ожидаемым, то мы можем писать так, как ожидалось.
  6. Пройдено/не пройдено: если результат соответствует ожидаемому, отметьте его как пройденный, а если результат не соответствует ожидаемому, отметьте результат как неудовлетворительный. Вы используете цвет для статуса. Используйте зеленый цвет для Pass и красный цвет для Fail.
  7. Комментарий. Этот столбец предназначен для дополнительной информации, например, для если статус установлен на «невозможно проверить», то тестер может указать причину в этом столбце.**

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

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

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

Сводка. В этом разделе содержится сводка требований, таких как

1.1 Элемент: это поле содержит краткие описания элементов, которые будут протестированы.
1.2 Название продукта: содержит название продукта, который вы хотите протестировать.
1.3 Версия продукта: содержит версию продукта, которую вы хотите протестировать.
1.4 Предварительные условия: Предварительные требования — это требования к системе, которые
необходимы, прежде чем мы начнем тестирование. Предпосылками могут быть:

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

Предварительные требования должны быть выполнены до начала выполнения тестового примера.

1.5 Предпосылки для изменения: изменения, которые не были необходимы раньше, но теперь необходимы для системы.
1.6 Критерии выхода: Это поле содержит требования, которые должны быть выполнены
для того, чтобы объявить о завершении тестирования.
1.7 Сводка тестов. Это поле содержит статус продукта: сколько тестовых случаев
пройдено, сколько неудачно, сколько приостановлено, сколько недействительно и т. д.

Матрица отслеживания:

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

2.1 Идентификатор требования: в этом поле указаны все тестируемые требования.
2.2 Описание требования: Это поле содержит краткое
описание требований.
2.3 Идентификатор тестового примера: Согласно описанию требований, какой идентификатор тестового примера
покрывается.
2.4 Статус. Укажите здесь статус тестовых случаев, например, пройден, не пройден, приостановлен или
недействителен.

Как показано на изображении ниже:


Идентификатор требования REQ_ID 1, охватываемый тестовым набором с идентификатором TEST_ID 1 и TEST_ID 2
Требование с идентификатором REQ_ID 2, охватываемым тестовым набором с идентификатором TEST_ID 3, TEST_ID 4, TEST_ID 5

Преимущества использования матрицы прослеживаемости

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

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

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