Проверка архитектуры программного обеспечения и его целевой среды
Цель:
|
Понять архитектуру программного обеспечения и способы его взаимодействия с целевой средой.
|
Для выполнения этой задачи в соответствующем контексте необходимо обладать хорошим пониманием разрабатываемого
программного обеспечения, его архитектуры, а также ключевых механизмов и функций, которые оно будет поддерживать.
Ознакомьтесь с доступной документацией архитектуры программного обеспечения, чтобы получить некоторое начальное
представление, и обсудите появившиеся вопросы с архитектором программного обеспечения. Необходимо учитывать влияние
целевой среды развертывания на полученную информацию. Отмечайте все сведения, которые связаны с проведением
тестирования.
|
Определите механизмы, пригодные для выполнения тестирования
Цель:
|
Определите механизмы, с помощью которых можно выполнить поставленную задачу тестирования.
|
Ознакомьтесь с информацией о методе тестирования, учитывая полученные знания о целевой среде и архитектуре программного
обеспечения. Рассмотрите ключевые технические аспекты этого подхода и составьте список механизмов, которые можно
использовать для его осуществления. Ниже приведен список некоторых механизмов, которые, возможно, следует использовать:
устойчивость, параллелизм, распределенность, связь, защита, управление транзакциями, восстановление данных, управление
обнаружением ошибок и создание отчетов, управление процессами и синхронизация.
Эти механизмы часто применимы как к тестированию вручную, так и к автоматическому тестированию, однако степень
соответствия какому-либо типу тестирования для каждого механизма своя. Реализованные решения обычно различаются даже в
том случае, если для автоматического тестирования и для тестирования вручную используется один и тот же механизм.
|
Создайте список доступных механизмов тестирования
Цель:
|
Определить, возможно ли повторное использование реализованных механизмов тестирования и выяснить, какие
дополнительные реализации необходимо разработать.
|
Проверьте доступные механизмы и варианты реализации способов тестирования и создайте список механизмов, для которых
разработано одно или несколько решений. Этот этап наиболее полезен, если используется автоматизированное тестирование,
однако в том случае, если тестирование проводится вручную, также следует выполнить некоторые аналогичные действия.
Подразделы:
Вначале следует составить список доступных инструментов и инструментов, которые планируется приобрести. Помните, что
инструменты автоматизации очень разнообразны, и обычно список включает не только механизмы автоматической реализации и
проведения тестирования. Проверьте механизмы, предоставляемые каждым инструментом. Например, следует выяснить,
использует ли утилита обработки тестовых сценариев собственный механизм хранения данных, и, если это так, можно ли с ее
помощью выполнить задачи тестирования или требуется чем-либо дополнить ее? Другие возможные вопросы: Допускает ли
утилита проведения тестирования одновременное выполнение тестовых сценариев на нескольких клиентских машинах? Допускает
ли утилита передачу сценариев от центральной главной машины нескольким клиентским системам?
Если существующие варианты автоматизации тестирования недоступны, в список потребуется добавить дополнительные
механизмы. Некоторые аспекты этих реализаций способны расширить или дополнить базовые механизмы инструментов, что
делает их более функциональными. Также эти механизмы могут включать реализацию дополнительных механизмов, отсутствующих
в основном инструменте.
На данном этапе следует пересмотреть рекомендации по проведению тестирования, связанные с реализацией и проведением
теста. Требуется найти решения таких вопросов, как параллелизм - как испытатели могут обмениваться данными без прямого
взаимодействия, распределенность - будет ли коллектив испытателей распределенным, и какие решения для координации
коллектива доступны.
|
Определите, какие механизмы тестирования будут использоваться в дальнейшем
Цель:
|
Сделать информацию о принятых решениях, связанных с механизмами тестирования, общедоступной.
|
Теперь, когда механизмы тестирования выбраны, необходимо донести ваши решения до непосредственных испытателей и лиц,
заинтересованных в результате тестирования. Рекомендуется внести решения о механизмах автоматизации тестирования в
документацию по архитектуре автоматизации тестирования, а решения, связанные с проведением тестирования вручную - в
рекомендации по тестированию.
В качестве альтернативы формальной документации можно составить набор заметок с информацией об архитектуре и процессе
тестирования, дополненных поясняющими диаграммами. Такие заметки можно разместить на доске. В ходе реализации и
выполнения тестирования испытатели смогут использовать эту информацию для принятия тактических решений.
После определения требований к специальным тестовым интерфейсам, которые необходимо добавить в разрабатываемую
программу, следует оформить эти требования в виде одной или нескольких спецификаций тестовых интерфейсов. Каждая из них
должна включать имя, краткое описание и требования к интерфейсу (либо его функции). На создание этих документов не
следует тратить много времени; более подробная информация о требованиях и функциях будет добавлена в ходе выполнения
задачи Определить элементы, необходимые для осуществления тестирования.
|
Оцените и проверьте полученные результаты
Цель:
|
Проверить, было ли задание выполнено должным образом и являются ли полученные рабочие продукты пригодными к
использованию.
|
Теперь, когда работа завершена, полезно проверить, принесла ли она результаты, либо вы просто потратили бумагу. Следует
оценить качество выполненной работы, уровень ее завершенности (может ли полученный результат быть использован в
дальнейшем другими участниками коллектива). При возможности используйте для проверки качества и завершенности
соответствующие справочные таблицы RUP.
Попросите людей, которые будут в дальнейшем пользоваться результатами вашей работы, оценивать промежуточные результаты.
Используйте этот метод при возможности учитывать их замечания. Необходимо также оценить полноту представления ключевых
рабочих продуктов. Это может оказаться полезным при оценке вашей работы автором входного продукта.
Помните, что RUP - это итеративный процесс, и во многих случаях рабочие продукты могут измениться через некоторое
время. Таким образом, обычно не требуется - и часто понижает продуктивность - создание рабочего продукта, который будет
использоваться только частично либо вообще не будет использоваться в последующей работе сразу же после его выпуска.
Причина состоит в том, что ситуация по отношению к рабочему продукту может измениться, и предположения, сделанные при
создании рабочего продукта, могут оказаться неверными. Если это произойдет перед фактическим использованием продукта,
результатом будут являться впустую потраченные усилия и затраты средств на повторные работы. Также не следует уделять
слишком много внимания презентациям в ущерб разработке продукта. Если презентации важны для выпуска продукта, то для их
проведения рекомендуется использовать административный ресурс.
|
|