Разработка тест кейсов на основе use case
#1
Отправлено 10 февраля 2006 - 00:18
Автор: Екатерина Курач
В последние несколько лет наметилась тенденция, когда усилия фирм-разработчиков программного обеспечения направлены на повышение качества своих программных продуктов. Постепенно производители отказываются от «интуитивного» тестирования программ и переходят к формальному тестированию, с написанием тест кейсов.
Но, как известно, полностью протестировать программу невозможно по следующим причинам:
Количество всех возможных комбинаций входных данных слишком велико, чтоб его можно было проверить полностью.
Количество всех возможных последовательностей выполнения кода программы также слишком велико, чтобы его можно было протестировать полностью.
Пользовательский интерфейс программы (включающий все возможные комбинации действий пользователя и его перемещений по программе) обычно слишком сложен для полного тестирования.
Т.е. написать тест кейсы для «полного» тестирования продукта — просто невозможно. Мы можем разработать миллионы тестов, но будет ли время у нас их выполнить? Вероятнее всего — нет. Поэтому приходится тщательно выбирать тест кейсы, которые мы будем проводить.
---------------------------------
Читать полностью
Материалы на тему Тестирование
#2
Отправлено 10 февраля 2006 - 06:05
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
#4
Отправлено 10 февраля 2006 - 14:44
1. Одинаковые вступления у двух статей. Метод copy paste в журналистике? Нехорошо. Либо объедините две статьи в одну, либо уберите из одной статьи вступление.
2. "Случай использования" режет глаз. "Вариант использования" или "Прецедент" будет лучше.
3. Картинки из статьи "Методология построения тестовых случаев на основе ортогональной классификации дефектов" лучше сделать заново. Перевести на русский язык. Я не против английского, но если статья на русском, то и... Есть такая фраза "Не заставляйте меня думать". Да и четкость текста повысится.
4. Фраза:
"Случай использования состоит из некоторого множества сценариев: нормальный случай, расширения и исключительные ситуации."
построена неудачно. Я знаю, что такое прецеденты и как их писать, но мне понять эту фразу тяжело. Почитайте книгу Алистера Коберна.
5. "нужно определить, сколько необходимо использовать тестовых случаев из каждого случая использования, после чего построить эти случаи."
Несколько раз перечитывал. Очень тяжело.
6 "Но интерес представляют и пользу приносят случаи"
Перевод английской статьи при помощи lingvo? По русски так не говорят.
7. "частоты использования в случаях использования."
Все, дальше не буду. Отредактируйте сами и пришлите мне вариант. Займусь вычиткой.
----------------------------------------------------------------
Говорить о сложных вещах сложно - легко,
говорить о сложных вещах просто - сложно.
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#5
Отправлено 10 февраля 2006 - 15:03
1. В статье смешиваются два процесса: выработка стратегии тестирования и создание сценариев. Явно разнесите эти две стадии.
2. "Количество тестовых случаев, приходящихся на один случай использования, выбирается в зависимости от положения этого случая использования в рейтинговой таблице (чем чаще используется данный случай использования и чем критичней его неверное выполнение для системы — там больше тест кейсов должно быть разработано)."
Не согласен. В первую очередь число сценариев определяется числом сценариев прецедента, пусть даже не написанных. Вообще, при хорошей документации сценарии тестирования могут выглядеть так:
1. Прецедент 1, основной сценарий.
2. Прецедент 1, сценарий 1а.
3. Прецедент 1, сценарий 3а.
...
А вот полнота покрытия требований тестами и очередность их создания определяется в стратегии тестирования и, действительно зафисит от профилей важности и частоты использования.
3. "В системе управления базами данных можно начать с базы данных, содержащей 50 записей, и постепенно увеличивать это число до нескольких тысяч."
Это, скорее, объемное тестирование. Эти тесты пишутся на основании требований к масштабируемости. В другую статью.
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#6
Отправлено 10 февраля 2006 - 15:12
Не понял. Да и весь абзац тоже не понял.
Давайте начнем с простого. Откроем книгу Алистера Коберна. Посмотрим, что такое "действующее лицо", "основное действующее лицо" и т.д. Потом перепишем этот абзац.
Выясним, что не прецеденты с двумя ОДЛ не пишутся. И удалим этот абзац. Ну сами подумайте какой вариант использования может быть с двумя операторами? Разве что запуск ракеты. Так это же исключение.
А то что вы хотели сказать, но не сказали - это конкурентное использование системы двумя пользователями. И пишутся эти сценарии исходя из требований к многопользовательскому режиму и целостности данных. Это в другую статью.
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#7
Отправлено 10 февраля 2006 - 15:15
Согласен. Но к юзкейсам это отношение не имеет. Юскейс он на то и юзкейс, что для всех акторов (ОДЛ / пользователь системы) он одинаков.
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#8
Отправлено 10 февраля 2006 - 15:20
Пока система не прошла опытную эксплуатацию все попытки сказать как действующий субъект будет использовать систему - это немного (иногда очень много) попытки угадать.
Совокупный результат отдельных случаев использования - это уже к бизнесциклу. Такие сценарии не пишутся "на основе сценариев использования".
В другую статью.
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#9
Отправлено 10 февраля 2006 - 15:23
Идентификация всех значений, которые вводятся действующими субъектами, содержащимися в модели случая использования
Выделение классов эквивалентности значений каждого типа входных данных "
По хорошему, это надо делать на этапе написания требований. И в требованиях прописывать эти сами классы эквивалентности.
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#10
Отправлено 10 февраля 2006 - 15:28
Пример, который вы приводите - неудачен. Напишите сам юзкей. Вернее группу юзкейсов. И вставьте их в статью. После этого продолжим.
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#11
Отправлено 10 февраля 2006 - 15:29
Это к планированию. Выделите планирование в раздел статьи и поставьте на нужное место. До раздела "создание тесткейсов"
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#13
Отправлено 10 февраля 2006 - 16:04
Но не из статьи. Приведите пример юзкейса. Хотя бы одного. И покажите процесс создания тесткейсов.
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#14
Отправлено 10 февраля 2006 - 16:07
А вы присоединяйтесь. А то я скоро руки обобью.Вах! Только я нашёл время и хотел тут развернуться... Снимаю шляпу!
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#16
Отправлено 10 февраля 2006 - 19:58
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#17
Отправлено 11 февраля 2006 - 17:13
Это ко мне :) Статья была одна - оба метода сразу, но мне показалось, что так сложновато, а разделил оставив одно вступление.Оформление.
1. Одинаковые вступления у двух статей. Метод copy paste в журналистике? Нехорошо. Либо объедините две статьи в одну, либо уберите из одной статьи вступление.
Остальное к автору, вроде.
Редактор портала www.it4business.ru
#18
Отправлено 13 февраля 2006 - 07:16
Автору -- читать Коберна, обязательно! С учетом того, что русский перевод сделан весьма хорошо, эта книга должна стать законодателем терминологии.
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
#19
Отправлено 13 февраля 2006 - 07:23
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
#20 Гость__Kate__*
Отправлено 14 февраля 2006 - 09:04
Вопрос к автору: Екатерина, а какую технику написания вариантов использования Вы имели в виду в статье? Вот этот способ написания вариантов использования -- "вариант использования состоит из некоторого множества сценариев: нормальный случай, расширения и исключительные ситуации" -- он где описан? Можно ознакомиться с первоисточником? Я не очень хорошо уловил принцип из одного абзаца статьи, посвященного этому вопросу. Может, ссылку добавить?
Алексей, спасибо за комментарии и вопрос.
В статье взята классификация, предложенная Джоном Макгрегором и Девидом Сайксом в книге "Тестирование объектно-ориентированного программного обеспечения". Они используют общепринятое в описании UML разделение атрибутов юз-кейсов на Главный успешный сценарий и Расширения, однако считают целесообразным ввести еще третий атрибут: раздел Исключительные ситуации, в который попадают те сценарии, которые приводят к возникновению ошибки. Тест кейсы предлагается разрабатывать на основе сценариев всех трех типов.
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных