Test Case
#1
Отправлено 28 февраля 2005 - 10:07
В целом я попытался собственными силами познакомится с материалом касательно тестирования. Для чего нужно тестирование ПО ? Цели тестирования ПО. Основные понятия и т.д.
Но вот скажем так, в разделе Процесс тестирования я столкнулся с такими понятиями как план тестирования, тестовый сценарий (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
Заранее благодарю за помощь.
#2
Отправлено 28 февраля 2005 - 10:26
Определений, что такое test case полным-полно, но все более или менее сходятся в одном: test case -- это отдельный тест, предназначенный для проверки определённого свойства тестируемой систмы.
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
#3
Отправлено 28 февраля 2005 - 11:08
Допустим в плане (тест план) описан пункт проверки корректной установки (инсталляции) ПО.
И в test case'е имеется пункт проверки корректной установки ПО. Какая между ними разница?
Или я чушь порю ?
#4
Отправлено 28 февраля 2005 - 11:21
В тест-плане не будет описывается то, как конкретно проводить тестирование, а в test-case будет детальное описание того, каким образом проверять инсталляцию (по шагам). Можно считать, что test-case - это более детализированный кусок тест-плана.Допустим в плане (тест план) описан пункт проверки корректной установки (инсталляции) ПО.
И в test case'е имеется пункт проверки корректной установки ПО. Какая между ними разница?
#5
Отправлено 28 февраля 2005 - 11:35
И повторюсь учитывая тот пример.
Если все эти пункты проведены успешно то test case успешно прошёл. Значит в пункт 3 ставим +.
Правильно ли я все понял насчет test case ? его определение и создание.
PS. Если уж выражаюсь не грамотно прошу прошения :) такой я человек что для осознания дела мне нужны не только слова, а еще и пример что бы твердо затвердить что я понял.
#6
Отправлено 28 февраля 2005 - 13:01
— план тестирования (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 включает некоторые дополнительные элемены, но эти четыре -- основные.
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
#7
Отправлено 28 февраля 2005 - 13:17
Спасибо еще раз.
Вопросы думаю еще возникнут и буду надеется что вы поможете мне на них ответить.
ЗЫ. Вопрос не могли бы вы обращаться ко мне на ТЫ, а то от ВЫ я не очень хорошо себя чувствую, или у вас такие не гласные правила на форуме ? )
#8
Отправлено 28 февраля 2005 - 13:32
#9
Отправлено 28 февраля 2005 - 13:34
Для старта достаточно использовать вот это: http://www.coleycons....uk/IEEE829.htm
Не пытайтесь сразу сделать всё, полный набор документации, никакого здоровья не хватит, да и выгоды от этого большой не будет. Полный набор -- для больших организаций с поставленным процессом, а начинать нужно с малого, выбирая то, что действительно полезно в каждом конкретном случае индивидуально. (набор документов, скорее всего будет практически полностью совпадать с предлагаемым в IEEE 829, в том или ином виде, но вот содержание там описано с большой избыточностью)
С вопросами -- милости просим, на то и форум.
Что касается правил -- официальных правил обращения на форуме нет (насколько мне известно). Это моё личное убеждение, что в публичных местах лучше обращаться с максимальной вежливостью, хотя к личной переписке это не относится.
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
#10
Отправлено 28 февраля 2005 - 13:35
Ушло. Спасибо - только пинать лучше почтой или аськой ;)Case, чем не вопрос-ответ FAQ? ;)
Редактор портала www.it4business.ru
#11
Отправлено 03 марта 2005 - 08:25
У меня опять вопросы насчёт 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 ?
То есть по пункту перечисление что нужно сделать ? без объяснений, или с объяснением (как сделал я )... так же какой формулировкой должны обладать объяснения (если они нужны)... по-простому ? или как то более по умному и техническими словами ?
#12
Отправлено 03 марта 2005 - 08:44
Тесты пишутся так, как бог на душу положит :)
Автоматизированные тесты пишутся на любом языке программирования, который душа пожелает.
Или не пишутся явно, а создаются при помощи каких-нибудь инструментов.
Канонов нет.
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
#13
Отправлено 03 марта 2005 - 12:25
имеется в виду набор значений для проверки, который может включать в себя как позитивные (должно все работать) так и негативные (система должна воспротивиться такому дикому надруганию над святая-святых - данными) наборы.
Шаблоны для тесткейсов можно поискать на qaforums.com
#14
Отправлено 22 марта 2005 - 14:55
#15
Отправлено 22 марта 2005 - 15:02
А таких понятий, как test scenario и test suitе стандарт IEEE 829 вообще не определяет, поэтому каждый волен дать им такую трактовку, какая ему нравится. В том числе и Вы. :) А после этого мы сравним -- чем же они отличаются от айтрипэлышных.Вы пишете что каждый test design состоит из нескольких test cases. А что тогда test scenario и test suit? я что то запуталась. причём рекомендуется чтоби test case состоял из 10-15 шагом, а если не выходить настолько упростить? обясните что же такое test design? и чем он отличается от test scenario. и что же такое test suit? спасибо
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
#16
Отправлено 22 марта 2005 - 15:18
#17 Гость_adnis_*
Отправлено 11 мая 2005 - 14:35
IMHO Test suit и Test scenario применимы больше к автоматическим тестам. По крайней мере такое у меня впечатления после работы с автоматическими тестами в организации где эти понятия используются.А таких понятий, как test scenario и test suitе стандарт IEEE 829 вообще не определяет, поэтому каждый волен дать им такую трактовку, какая ему нравится. В том числе и Вы. :) А после этого мы сравним -- чем же они отличаются от айтрипэлышных.Вы пишете что каждый test design состоит из нескольких test cases. А что тогда test scenario и test suit? я что то запуталась. причём рекомендуется чтоби test case состоял из 10-15 шагом, а если не выходить настолько упростить? обясните что же такое test design? и чем он отличается от test scenario. и что же такое test suit? спасибо
#18
Отправлено 12 мая 2005 - 08:27
Здраствуейте.
У меня опять вопросы насчёт test case, для примера я решил написать test case по Базе Данных.
Вот что у меня получилось...
Алексей отлично расписал все документы. Я хочу лишь добавить ясное (почти визуальное) представление о Тест Кейсе.
Нарисуйте таблицу из 6 столбцов. Каждая строка - определенное действие.
1-й столбец - ваше местоположение в системе. Например, страница Логин.
2-й - объект над которым вы совершаете действие. Например, элемент ввода Edit.
3-й - действие, которое вы совершаете. Например, ввести имя пользователя.
4-й - пример данных, которые вы вводите.
5-й - реакция системы. Например, (при вводе пароля) пароль отображается в виде звездочек, или (при клике) загружется следующая страница
6-й - результат выполнения описанного шага тест кейса. Прошел/не прошел.
Детализация шагов может быть разной. Для системы с типовым поведением операция логин может быть описана как один шаг тест кейса, но тогда нужно указывать данные для всех элементов ввода (имя пользователя, пароль, домен и пр.).
Вместо конкретных тестовых данных в 4-й столбик можно помещать их описание (паттерн). Например, строка не менее 4-х знаков и не более 38-ми.
#19
Отправлено 13 января 2006 - 20:42
Приношу свои извинения, если здесь это не принято.
Я тоже начинающий тестировщик и был очень удивлён, что такие вещи как поля ввода данных в БД нужно проверять на ошибку.
Как мне кажется не один уважающий себя программер не допускает таких простых ошибок, как проверка шаблона ввода данных.
Мой вопрос заключается в том, должен ли тестировщик при составление Тест-плана стараться проверить логические ошибки в тестируемом приложение?
Для примера возьмём базу данных, в которой хотят удалить пользователя. Естественно, по логике вещей, перед тем как уничтожить данные, нужно вывести предупреждающее сообщение. А что делать, если при написание Тест-плана, тестировщик не посвящён во все тонкости данного приложения? Кто должен предвидеть все ошибки или это всё ложится на плечи тестировщика?
Спасибо заранее,
Марк.
Количество пользователей, читающих эту тему: 1
0 пользователей, 1 гостей, 0 анонимных