Test Case

Доброе всем время суток. Дело в том, что тестированием я начал заниматься совсем недавно, на это меня спровоцировала жизненная ситуация, и само понятие как тестирование ПО меня очень заинтересовало. Поэтому, как человек, имеющий очень маленький опыт в подобных вещах, решил задать несколько вопросов касательно тестирования.
В целом я попытался собственными силами познакомится с материалом касательно тестирования. Для чего нужно тестирование ПО ? Цели тестирования ПО. Основные понятия и т.д.
Но вот скажем так, в разделе Процесс тестирования я столкнулся с такими понятиями как план тестирования, тестовый сценарий (test case). И мне не совсем понятно стало, что такое test case?
Дело в том, что как я понял в плане тестирования задаются объекты тестирования, указываются, на каком уровне они должны быть протестированы и в какой последовательности. А test case определяет, как должна быть проведена реализация каждого конкретного требования. Test case представляется набором точных инструкций по выполнению отдельных шагов.
То есть как я понял, допустим у нас есть допотопный план тестирования:
1.Инстоляция программы
2.Запуск.
3.Создание текстового документа.
4.Закрытие программы.
5.Удаление программы.
А test case рассматривает каждый из этих пунктов более подробно то есть. Для примера берем пункт 3. Создание текстового документа. И более детально его анализируем.
3. Создание текстового документа.
3.1 Открытие
3.2 Редактирование текстового документа.
3.3 Проверка на сохранение информации.
3.4 Удаление текстового документа.
Если все эти пункты проведены успешно то test case успешно прошёл. Значит в пункт 3 ставим +.
Правильно ли я все понял насчет test case ? его определение и создание.
PS. Хотя я в этом сам сомневаюсь что все может быть на стока просто.
Дело в том что я сейчас пытаюсь написать хоть чуть – чуть похожий на правду test case. Но у меня что то не очень получается… У меня просьба, если у каво имеется примерный план написания test case'ов могли бы вы выслать эту информацию мне в личку или на мыло. Так же в будущем не могли бы вы посмотреть мой test case (если я все таки пойму и смогу его написать ) на предмет “усё пучком или лажа”
В целом вопросов скопилось много надеюсь вы поможете такому юзеру в области тестирования как я и поможете ответить, на довольно таки глупые вопросы, как я считаю.
PS. Поиск юзал, первые 2 дня на форме провер переворачивая информацию… Не чего интересующего меня в данный момент не нашел. А что нашел не совсем понял J
Заранее благодарю за помощь.

http://www.google.co...efine:Test case

Определений, что такое test case полным-полно, но все более или менее сходятся в одном: test case -- это отдельный тест, предназначенный для проверки определённого свойства тестируемой систмы.

Не могли бы ответить более подробно. То есть чем отличается пункт плана тестирования, от test case который содержит такой же смысл тестирования данного пункта.
Допустим в плане (тест план) описан пункт проверки корректной установки (инсталляции) ПО.
И в test case'е имеется пункт проверки корректной установки ПО. Какая между ними разница?
Или я чушь порю ?

Допустим в плане (тест план) описан пункт проверки корректной установки (инсталляции) ПО.
И в test case'е имеется пункт проверки корректной установки ПО. Какая между ними разница?

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

Дык, тот пример что я приводил в первом посте "Создания текстового документа" можно ли отнести (приблизительно/округленно) к test case'у ?
И повторюсь учитывая тот пример.
Если все эти пункты проведены успешно то test case успешно прошёл. Значит в пункт 3 ставим +.
Правильно ли я все понял насчет test case ? его определение и создание.
PS. Если уж выражаюсь не грамотно прошу прошения :) такой я человек что для осознания дела мне нужны не только слова, а еще и пример что бы твердо затвердить что я понял.

Давайте, чтобы не изобретать велосипед, посмотрим, скажем, на стандарт IEEE 829 Software Test Documentation and Test Plans. Там предлагается трёхуровневая организация артефактов:
— план тестирования (test plan)
— дизайн тестов (test design)
— тестовый вариант (test case)

То есть, test plan включает несколько test design, каждый их которых в свою очередь состоит из нескольких test case.

При этом test plan отностится к организационной документации (кто, что, когда), а test design и test case -- это техническая документация (как).

Кроме того, IEEE 829 водит также понятие test procedure, это как правило не самостоятельный артефакт, а детальные инструкции, прилагаемые к ручному test case, объясняющие, как его выполнить. Для автоматически вполняемых test case такие инструкции, естественно, не нужны.

В соответствии с этим стандартом то, что Вы написали, представляет собой нечто среднее между test plan и test desing.

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

Для test desing маловато технической информации -- как предполагается тестировать каждую посдсистему, на каком уровне (UI, API и т.п.), в каком окружении (OS, тип файловой системы, hardware и т.п.), насколько глубоко, какие метрики использовать для оценки качества проведённого тестирования (когда можно считать, что протестировали "достаточно хорошо") и прочее такое.

А вот то, что расписано детально по пунктам 3.1-3.5 -- это действительно можно считать test case, потому что это "отдельный тест, нацеленный на тестирование определённого свойства системы", а именно -- что правильно выполняется сохранение изменённого файла.

При этом в test case попали следующие элементы:
-- предварительные действия, приводящие систему в состяние, в котором выполняется test case (открыть документ и поредактировать, таким образом мы попадаем в состояние "документ открыт и изменён")
-- собственно выполнение того, что тестируется (сохранить файл)
-- тестовый оракул или верификация (проверяем, что действительно изменения сохранились)
-- "зачистка", приведение системы в "чистое состояние", чтобы исключить влияние на последующие тесты (удаляем документ)

Иногда test case включает некоторые дополнительные элемены, но эти четыре -- основные.

barancev спасибо большое за отличный ответ. Я практически все понял, что не понял буду разбираться дальше сам и искать этот IEEE 829 Software Test Documentation and Test Plans о котором я даже понятия не имел. Насчет test case понял все ! Буду стараться попробовать написать таковой.
Спасибо еще раз.

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

ЗЫ. Вопрос не могли бы вы обращаться ко мне на ТЫ, а то от ВЫ я не очень хорошо себя чувствую, или у вас такие не гласные правила на форуме ? )

Case, чем не вопрос-ответ FAQ? ;)

Стандарт большой и заморочный (как, впрочем, большинство стандартов).
Для старта достаточно использовать вот это: http://www.coleycons....uk/IEEE829.htm

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

С вопросами -- милости просим, на то и форум.

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

Case, чем не вопрос-ответ FAQ? ;)

Ушло. Спасибо - только пинать лучше почтой или аськой ;)

Здраствуейте.
У меня опять вопросы насчёт test case, для примера я решил написать test case по Базе Данных.
Вот что у меня получилось...

1.  Чтение из БД  
1.1	Читаем данные	>>Заполнить поля базы вручную и запустить программу	Смотри, появились ли эти записи в списке пациентов
2.  Запись в БД  
2.1	Ввод спец. символов	>>Создаем нового пациента и в некоторые поля пытаемся ввести спец. символы (F12, Alt+1+5 и т.д.)	При записи в базу могут произойти искажения
2.2	Ввод данных о пациенте	>>Создаем нового пациента и заполняем все поля его карточки	
2.3	Допустимые значения	>>При создании пациента в поле ФИО указываем 200 символов	Смотрим, записывает ли ПО в БД действительно то количество символов, которое мы ввели. Если нет, то ошибка либо в БД (стоит ограничение) либо в БД(не стоит ограничение)
2.4	Цифровой ввод	>>В поле, где предполагается текст, вводим цифры	
2.5	Символьный  ввод	>>В поле, где предполагаются цифры, вводим текст	
2.6	Начинаем ввод данных с пробела	>>В поле ФИО пишем, начиная с пробела	
2.7	Ввод символов *,/,: …	>>Создаем нового пациента и заполняем символами *,/,: …	
3.  Сортировка записей в БД  
3.1	Проверить всю возможную сортировку	Просто выставляем соответствующую радио кнопку и смотрим на ее проявление	>>Интересно, узнаем ли мы при помощи программы о том, что в алфавите сначала идут цифры
4.  Поиск в БД	>>Производим поиск записей посредством поля поиск. В качестве вводимых символов используем: /,;,’,*,%,$, ,+,abc…,99.

Можно ли это считать как test case, похож ли он на настоящий ? или может добавить еще пару пунктов... хотя я ума не преложу что еще можно в БД протестировать :)
И далее еще вопрос, как пишется test case ?
То есть по пункту перечисление что нужно сделать ? без объяснений, или с объяснением (как сделал я )... так же какой формулировкой должны обладать объяснения (если они нужны)... по-простому ? или как то более по умному и техническими словами ?

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

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

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

Шаблоны для тесткейсов можно поискать на qaforums.com

Вы пишете что каждый test design состоит из нескольких test cases. А что тогда test scenario и test suit? я что то запуталась. причём рекомендуется чтоби test case состоял из 10-15 шагом, а если не выходить настолько упростить? обясните что же такое test design? и чем он отличается от test scenario. и что же такое test suit? спасибо

Вы пишете что каждый test design состоит из нескольких test cases. А что тогда test scenario и test suit? я что то запуталась. причём рекомендуется чтоби test case состоял из 10-15 шагом, а если не выходить настолько упростить? обясните что же такое test design? и чем он отличается от test scenario. и что же такое test suit? спасибо

А таких понятий, как test scenario и test suitе стандарт IEEE 829 вообще не определяет, поэтому каждый волен дать им такую трактовку, какая ему нравится. В том числе и Вы. :) А после этого мы сравним -- чем же они отличаются от айтрипэлышных.

:) Спасибо, наконец у меня всё стало на свои места, а то я тут всего начиталась и никак не могла уложить по полочкам .........

Вы пишете что каждый test design состоит из нескольких test cases. А что тогда test scenario  и test suit? я что то запуталась. причём рекомендуется чтоби test case состоял из 10-15 шагом, а если не выходить настолько упростить? обясните что же такое test design? и чем он отличается от test scenario. и что же такое test suit? спасибо

А таких понятий, как test scenario и test suitе стандарт IEEE 829 вообще не определяет, поэтому каждый волен дать им такую трактовку, какая ему нравится. В том числе и Вы. :) А после этого мы сравним -- чем же они отличаются от айтрипэлышных.

IMHO Test suit и Test scenario применимы больше к автоматическим тестам. По крайней мере такое у меня впечатления после работы с автоматическими тестами в организации где эти понятия используются.

Здраствуейте.
У меня опять вопросы насчёт test case, для примера я решил написать test case по Базе Данных.
Вот что у меня получилось...

Алексей отлично расписал все документы. Я хочу лишь добавить ясное (почти визуальное) представление о Тест Кейсе.

Нарисуйте таблицу из 6 столбцов. Каждая строка - определенное действие.

1-й столбец - ваше местоположение в системе. Например, страница Логин.
2-й - объект над которым вы совершаете действие. Например, элемент ввода Edit.
3-й - действие, которое вы совершаете. Например, ввести имя пользователя.
4-й - пример данных, которые вы вводите.
5-й - реакция системы. Например, (при вводе пароля) пароль отображается в виде звездочек, или (при клике) загружется следующая страница
6-й - результат выполнения описанного шага тест кейса. Прошел/не прошел.

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

Вместо конкретных тестовых данных в 4-й столбик можно помещать их описание (паттерн). Например, строка не менее 4-х знаков и не более 38-ми.

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

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

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

Спасибо заранее,

Марк.

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