Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
бИЛЕТЫ_GOSam.doc
Скачиваний:
2
Добавлен:
01.04.2025
Размер:
1 Мб
Скачать
☆

3) Критерии, используемые при тестировании требований.

Полнота. Набор требований считается полным, если все его составные части представлены и каждая такая часть выполнена в полном объеме. При тестировании набора требований на полноту необходимо обратить особое внимание на следующие моменты:

• Требования не должны содержать выражений типа "подлежит определению", "и так далее", "и прочие" и им подобных.

• Требования не должны ссылаться на несуществующую справочную информацию, такую как, например, несуществующая спецификация.

• Требование не должно ссылаться на функциональные средства, которые еще не определены.

Однозначность. Каждое требование должно быть точно и ясно сформулировано; оно должно допускать единственное толкование. Требование должно быть удобочитаемым и понятным. Если требование отличается особой сложностью, для облегчения понимания может быть привлечен вспомогательный материал, такой как, диаграммы или таблицы. Непротиворечивость. Требования не должны противоречить друг другу или действующим стандартам. Если требования конфликтуют друг с другом, то нужно вводить приоритеты с целью разрешения таких конфликтов

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

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

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

4)Теги списков, абзаца, заголовков, ссылок. Назначение, примеры.

Ненумерованные списки

<UL>

<LI>Первый элемент списка</LI> <LI>Последний элемент списка</LI>

</UL>

Теги <UL> и </UL> являются своеобразным обрамлением списка. Он позволяет отделить один список от другого. Тег <LI> обозначает каждый из пунктов списка. Конечный тег </LI> не является обязательным.

Для тега <UL> предусмотрен атрибут type, определяющий вид маркера, который браузер помещает перед каждым элементом списка. Этот атрибут может отсутствовать или принимать одно из трех значений: circle, disc, square.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]