Сообщений в теме: 19

[Case]

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

Автор: Екатерина Курач

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

Но, как известно, полностью протестировать программу невозможно по следующим причинам:

Количество всех возможных комбинаций входных данных слишком велико, чтоб его можно было проверить полностью.
Количество всех возможных последовательностей выполнения кода программы также слишком велико, чтобы его можно было протестировать полностью.
Пользовательский интерфейс программы (включающий все возможные комбинации действий пользователя и его перемещений по программе) обычно слишком сложен для полного тестирования.
Т.е. написать тест кейсы для «полного» тестирования продукта — просто невозможно. Мы можем разработать миллионы тестов, но будет ли время у нас их выполнить? Вероятнее всего — нет. Поэтому приходится тщательно выбирать тест кейсы, которые мы будем проводить.

---------------------------------
Читать полностью
Материалы на тему Тестирование

[barancev]

Объясните, пожалуйста, а какой скрытый смысл имеет ссылка на "Официальный сайт Chillarege Inc." в конце статьи?

[Clauster]

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

Характеристики хорошего теста:
  Существует обоснованная вероятность выявления тестом ошибки 
...

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

[SALar]

Оформление.
1. Одинаковые вступления у двух статей. Метод copy paste в журналистике? Нехорошо. Либо объедините две статьи в одну, либо уберите из одной статьи вступление.

2. "Случай использования" режет глаз. "Вариант использования" или "Прецедент" будет лучше.

3. Картинки из статьи "Методология построения тестовых случаев на основе ортогональной классификации дефектов" лучше сделать заново. Перевести на русский язык. Я не против английского, но если статья на русском, то и... Есть такая фраза "Не заставляйте меня думать". Да и четкость текста повысится.

4. Фраза:
"Случай использования состоит из некоторого множества сценариев: нормальный случай, расширения и исключительные ситуации."
построена неудачно. Я знаю, что такое прецеденты и как их писать, но мне понять эту фразу тяжело. Почитайте книгу Алистера Коберна.

5. "нужно определить, сколько необходимо использовать тестовых случаев из каждого случая использования, после чего построить эти случаи."
Несколько раз перечитывал. Очень тяжело.

6 "Но интерес представляют и пользу приносят случаи"
Перевод английской статьи при помощи lingvo? По русски так не говорят.

7. "частоты использования в случаях использования."

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

[SALar]

Теперь по существу.

1. В статье смешиваются два процесса: выработка стратегии тестирования и создание сценариев. Явно разнесите эти две стадии.

2. "Количество тестовых случаев, приходящихся на один случай использования, выбирается в зависимости от положения этого случая использования в рейтинговой таблице (чем чаще используется данный случай использования и чем критичней его неверное выполнение для системы — там больше тест кейсов должно быть разработано)."
Не согласен. В первую очередь число сценариев определяется числом сценариев прецедента, пусть даже не написанных. Вообще, при хорошей документации сценарии тестирования могут выглядеть так:
1. Прецедент 1, основной сценарий.
2. Прецедент 1, сценарий 1а.
3. Прецедент 1, сценарий 3а.
...
А вот полнота покрытия требований тестами и очередность их создания определяется в стратегии тестирования и, действительно зафисит от профилей важности и частоты использования.

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

[SALar]

4. "Но интерес представляют и пользу приносят случаи, в которых участие принимают несколько действующих субъектов."
Не понял. Да и весь абзац тоже не понял.
Давайте начнем с простого. Откроем книгу Алистера Коберна. Посмотрим, что такое "действующее лицо", "основное действующее лицо" и т.д. Потом перепишем этот абзац.
Выясним, что не прецеденты с двумя ОДЛ не пишутся. И удалим этот абзац. Ну сами подумайте какой вариант использования может быть с двумя операторами? Разве что запуск ракеты. Так это же исключение.
А то что вы хотели сказать, но не сказали - это конкурентное использование системы двумя пользователями. И пишутся эти сценарии исходя из требований к многопользовательскому режиму и целостности данных. Это в другую статью.

[SALar]

"Очень редко все эти действующие субъекты используют систему одним и тем же способом."
Согласен. Но к юзкейсам это отношение не имеет. Юскейс он на то и юзкейс, что для всех акторов (ОДЛ / пользователь системы) он одинаков.

[SALar]

"Этот подход весьма полезен для систем, которые ни разу не устанавливались. Он дает более точную оценку того, как действующий субъект будет использовать систему, по сравнению с простым угадыванием того, каким окажется совокупный результат отдельных случаев использования. "
Пока система не прошла опытную эксплуатацию все попытки сказать как действующий субъект будет использовать систему - это немного (иногда очень много) попытки угадать.
Совокупный результат отдельных случаев использования - это уже к бизнесциклу. Такие сценарии не пишутся "на основе сценариев использования".
В другую статью.

[SALar]

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

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

[SALar]

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

Пример, который вы приводите - неудачен. Напишите сам юзкей. Вернее группу юзкейсов. И вставьте их в статью. После этого продолжим.

[SALar]

"Если известно количество случаев использования, то можно получить оценку трудозатрат, необходимых для реализации проекта в полном объеме."
Это к планированию. Выделите планирование в раздел статьи и поставьте на нужное место. До раздела "создание тесткейсов"

[Clauster]

Вах! Только я нашёл время и хотел тут развернуться... Снимаю шляпу!

[SALar]

"Итак, при разработке тест кейсов на основе случаев использования процедура в общем-то ясна"

Но не из статьи. Приведите пример юзкейса. Хотя бы одного. И покажите процесс создания тесткейсов.

[SALar]

Вах!  Только я нашёл время и хотел тут развернуться... Снимаю шляпу!

А вы присоединяйтесь. А то я скоро руки обобью.

[Clauster]

А вы присоединяйтесь. А то я скоро руки обобью.

Ну теперь уж стоит подождать следующей версии

[SALar]

Еще вторая статья есть.

[Case]

Оформление.
1. Одинаковые вступления у двух статей. Метод copy paste в журналистике? Нехорошо. Либо объедините две статьи в одну, либо уберите из одной статьи вступление.

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

Остальное к автору, вроде.

[barancev]

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

Автору -- читать Коберна, обязательно! С учетом того, что русский перевод сделан весьма хорошо, эта книга должна стать законодателем терминологии.

[barancev]

Вопрос к автору: Екатерина, а какую технику написания вариантов использования Вы имели в виду в статье? Вот этот способ написания вариантов использования -- "вариант использования состоит из некоторого множества сценариев: нормальный случай, расширения и исключительные ситуации" -- он где описан? Можно ознакомиться с первоисточником? Я не очень хорошо уловил принцип из одного абзаца статьи, посвященного этому вопросу. Может, ссылку добавить?