2 LeshaL,
не вижу противоречия.
Любая программа любо предоставляет, либо использует внешние сервисы.
Сервисы предоставляются двумя способами:
- посредством пользовательского интерфейса;
- посредством программного интерфейса.
Востребуются сторонние сервисы только посредством использования программного интерфейса сторонней программы или компоненты.
Сергей,
может и нет противоречий, может быть я просто не до конца понимаю вашу точку зрения. Попытаюсь перефразировать свою еще раз.
1. Юз-кейз имеет отношение к функциональным требованиям. Только к функциональным и никаким другим.
2. Юз-кейз != только описание действий пользователя. Например, наша программа это туннель для трассировки сообщений между клиентом и сервером. Поддержка протокола общения между клиентом и сервером, очевидно, будет функциональным требованием и одним из юз-кейзов. Допустим К и С могут общаться по HTTP и TCP/IP. Наш туннель должен понимать оба протокола общения. Дальше из этого следуют другие функциональные требования, например - пользователь должен мочь выбрать требуемый протокол и параметры общения между К и С для настройки туннеля.
3. Не все функциональные требования являются юз-кейзами. Не юз-кейзы те функциональные требования, которые возникают из-за деталей реализации.
Например: программа хранит данные в XML формате. Решено иметь DTD\XSD для этих XML файлов, чтобы валидировать целостность и правильность данных. В этом случае требование - не юз-кейз, т.к. с точки зрения использования программы все-равно есть DTD\XSD или нет. С точки зрения разработчика\тестера - это функциональное требование, которое надо соблюдать и проверять.
4. Если реализация требует от пользователя каких-то дополнительных действий, то это не юз-кейз. Это просто необходимые требования для того, чтобы программа (за)работала. Вернемся к проверке орфографии. Если используется какая-то внешняя программа (e.g. aspell), то пользователь обязан настроить каким-то образом систему так, чтобы тул находил эту внешнюю утилиту (например прописать правильно PATH). Это НЕ юз-кейз. Но! Если у нас задумана возможность использовать разные утилиты (aspell или ispell), то пользователь может настроить тул тем или иным образом, например в командной строке передавать имя используемой утилиты. Это юз-кейз. Разница в том, что первое - зависимость от реализации, второе - задумка при дизайне системы, дающая пользователю разные варианты использования программы.
5. Юз-кейз != User scenario. Пользовательский сценарий включает в себя 1+ юз-кейзов. Например, изменение документа в текстовом редакторе = загрузить существующий документ(юз-кейз#1)->отредактировать(юз-кейз#2)->сохранить(юз-кейз#3).
Далее связь тест-кейзов и юз-кейзов.
1. Один юз-кейз - 1+ тест-кейзов. Т.е. один ко многим.
2. Юз-кейз может порождать как обычные, так и негативные тесты. Зависит от фантазии, времени, важности и технической возможности.
3. Тест-кейз проверяет не сам юз-кейз, а его реализацию. Соотвественно детали имплементации накладывают дополнительные требования\ограничения на тест-кейзы и их кол-во.
4. Тест-кейзы появляются не только из юз-кейзов, но и из других требований, как функциональных, так и нет.
5. Тест-кейзы взаимозависимы. Выполнение тест-кейза для юз-кейза#1, может быть предварительным условием для выполнения тест-кейза для юз-кейза#2. Например, если программа инсталируется криво, и не прописывает необходимые строки в реестр виндов - то ее запустить будет невозможно. Нет возможности проверить кучу тест-кейзов. Но, в тоже время, можно проверить орфографии или документацию, т.к. файлы распаковались и доступны.
6. Проверка пользовательского сценария - это тест-кейз (например, удобно при приемочных испытаниях), но этот тест-кейз следует не из юз-кейза, а из сценария. Поэтому нет связи многие-ко-многим, как тут писали. Т.о. тест-кейз проверки сценария описанного выше в (5) такой: каким-то образом загрузить существующий документ (=один из тест-кейзов для проверки того, что редактор открывает файлы) -> как-нибудь отредактировать текст (один из 1000 тест-кейзов редактора) -> как-нибудь сохранить документ (один из тест-кейзов для Save/Save as). В данном случае, при проверке сценария, совершенно не важно каким образом загружается файл (File->Open, Edit->Recent, параметр в командной строке) итд.
