Что некоторые пути состоят в том, чтобы протестировать архитектуру?
Лучший способ никогда никогда не состоит в том, чтобы давать Вашу прямую линию клиенту. Сделайте, чтобы они прошли Техническую поддержку (если она существует), сначала. Мы используем этот метод, и он работает хорошо. Разработчики программного обеспечения являются последним средством - для вещей, которые поддерживают, просто не может сделать, знают, как зафиксировать - такие как DBA, не зная, что серверы инстанцируются. Но это сократит, "это не подключает к Интернету" тип телефонных вызовов.
Вы могли также вынудить все запросы поддержки пройти электронную почту/секретаря. В той точке можно различить, которые очень важны, и которые могут быть решены с простым 'учебным руководством' о том, как решить проблему.
И как указано выше - записывают ВСЕ в обмене с клиентом. Выполнение так предотвращает, 'хорошо он сказал, что она сказала' соглашение, что клиенты могут упасть в.
С другой стороны - если Вы получаете тонну проблем поддержки клиентов, необходимо смотреть на причину ее - является ли это учебной проблемой, или ошибочно ли программное обеспечение законно.
6 ответов
Обычно «тестирование архитектуры» означает тестирование прикладной и технической архитектуры (в отличие от бизнес-функциональной архитектуры, которая не столько «проверяется», сколько «проверяется. ").
И это тоже не «модульное тестирование», не «непрерывная интеграция» или TDD, а, скорее, метод «черного ящика» для тестирования всей системы (состоящей из множества модулей) от начала до конца.
Вы действительно можете начать проектировать не одну. , но несколько политик тестирования: когда они касаются «архитектуры», они часто являются «общесистемными» тестами, подразумевающими выделенную инфраструктуру (сеть, сервер рядом с целью развертывания).
Итак, при проектировании вашей первой «архитектуры» "тесты, вы можете принять во внимание:
- какой тест вы хотите сделать в первую очередь (регрессия, стресс-тесты,uat - пользовательские приемочные тесты -)?
- какую прослеживаемость между этими тестами и начальным набором требований вы хотите?
- какой процесс развертывания вам нужно автоматизировать, чтобы легко и быстро настроить или обновить платформу тестирования (особенно, если в ней задействована база, что вы будете делать с обновлением схемы и данными тестирования?).
Все эти темы могут быть рассмотрены во время доработки архитектуры, чтобы более эффективно поддерживать усилия по развитию, как только они начнутся.
ТЕХНИКА ТЕСТИРОВАНИЯ НА ОСНОВЕ АРХИТЕКТУРЫ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
В этой диссертации представлен практический, эффективный и автоматизированный метод тестирования взаимосвязей архитектуры на уровне архитектуры. Он также представляет собой инструмент проверки концепции для создания требований к тестированию.
Ваша архитектура - это проектный документ, верно?
Осмотр - это то, что вам нужно.
Инспекции могут выявлять ошибки точно так же, как и тестирование. Инспекции быстрее обнаружат «ошибки».
Положите документы перед группой знающих людей. Попросите их прочитать это и рассказать вам, где есть проблемы. Переработайте свой документ и верните его им. Продолжайте этот процесс, пока ваша осведомленная аудитория не станет полностью ясно, что вы делаете, и все не убедятся, что это сработает.
Надеюсь, ваш документ написан таким образом, чтобы ваши читатели могли понимать взаимодействия и видеть работу, даже если они аннотация.
Дизайн Правило № 1: Не думайте, что что-то легко, думать, что система будет простой, обычно означает, что требования или объем того, что должно быть закодировано, еще не продуманы.
Правило проектирования № 2: Не проектируйте что-нибудь, а затем передайте это разработчикам и скажите им, что это легко, если вы еще не написали код или не работали с этой технологией.
Правило дизайна № 3: Новая технология - это не серебряная пуля, которая решит все ваши проблемы . Все новые технологии имеют проблемы интеграции и часто имеют множество ошибок, которые поставщик еще не исправил.
Принимая во внимание эти правила, действуйте следующим образом:
Определите технические допущения, неизвестные и новые технологии, которые вводятся или рассматриваются.
Подтвердите любые недоказанные предположения - то есть то, с чем вы или ваша команда раньше не работали. Чтение официального документа или пресс-релиза поставщика не считается. Убедитесь, что он работает, прежде чем строить на нем свою систему, если это что-то, что не было сделано раньше или используется по-новому.
Создайте жестко запрограммированный одноразовый прототип, чтобы убедиться, что взаимодействия с системой и неизвестные могут быть решены с минимальными затратами. обходных путей. Отбросьте любую часть вашего плана, которая не работает, и найдите другой способ сделать это, пока она не превратилась в черную дыру, поглощающую вашу архитектуру.
и внедряемые или рассматриваемые новые технологии.Подтвердите любые недоказанные предположения - то есть то, с чем вы или ваша команда раньше не работали. Чтение официального документа или пресс-релиза поставщика не считается. Убедитесь, что он работает, прежде чем строить на нем свою систему, если это что-то, что не было сделано раньше или используется по-новому.
Создайте жестко запрограммированный одноразовый прототип, чтобы убедиться, что взаимодействия системы и неизвестные могут быть решены с минимальными затратами времени. обходных путей. Отбросьте любую часть вашего плана, которая не работает, и найдите другой способ сделать это, пока она не превратилась в черную дыру, поглощающую вашу архитектуру.
и внедряемые или рассматриваемые новые технологии.Подтвердите любые недоказанные предположения - то есть то, с чем вы или ваша команда раньше не работали. Чтение официального документа или пресс-релиза поставщика не считается. Убедитесь, что он работает, прежде чем строить на нем свою систему, если это что-то, что не было сделано раньше или используется по-новому.
Создайте жестко запрограммированный одноразовый прототип, чтобы убедиться, что взаимодействия системы и неизвестные могут быть решены с минимальными затратами времени. обходных путей. Отбросьте любую часть вашего плана, которая не работает, и найдите другой способ сделать это, пока она не превратилась в черную дыру, поглощающую вашу архитектуру.
Убедитесь, что он работает, прежде чем строить на нем свою систему, если это что-то, что не было сделано раньше или используется по-новому.Создайте жестко запрограммированный одноразовый прототип, чтобы убедиться, что взаимодействия с системой и неизвестные могут быть решены с минимальными затратами. обходных путей. Отбросьте любую часть вашего плана, которая не работает, и найдите другой способ сделать это, пока она не превратилась в черную дыру, поглощающую вашу архитектуру.
Убедитесь, что он работает, прежде чем строить на нем свою систему, если это что-то, что не было сделано раньше или используется по-новому.Создайте жестко запрограммированный одноразовый прототип, чтобы убедиться, что взаимодействия системы и неизвестные могут быть решены с минимальными затратами времени. обходных путей. Отбросьте любую часть вашего плана, которая не работает, и найдите другой способ сделать это, пока она не превратилась в черную дыру, поглощающую вашу архитектуру.
Если вы хотите повторить итерацию, вы должны спроектировать только то, что вам нужно для итерации. Архитектура обычно рассматривается как один уровень выше, чем проект . Это означает, что я использую многоуровневую архитектуру MVC, чтобы решить, как разработать структуру моего класса.
Если вы строите общую структуру программы для первых итераций без добавления функций и вещей, которые можно протестировать, вы делаете что-то неправильно. Одним из преимуществ продолжения итеративного процесса является то, что вы не слишком переоцениваете дизайн в направлениях, которые вам не нужны.
Возьмите программу, которую вы хотите создать, и воспользуйтесь тремя наиболее важными функциями. Подумайте, как их реализовать и как спроектировать для этого структуру классов. Подумайте о вещах, которые могут измениться, и сделать их изменяемыми в вашем дизайне. Затем начните свою первую итерацию. Перед тем, как начать свою первую итерацию, подумайте об архитектурном выборе, используете ли вы MVC, архитектуру на основе клиент-сервер, есть ли у вас уровень базы данных или что-то подобное. Это выбор, который повлияет на ваш последующий выбор дизайна.
Для дальнейшего изучения я предлагаю http://en.wikipedia.org/wiki/Iterative_and_incremental_development и Planning XP-Programming от Кента Бека
.ATAM - это то, на что вам следует обратить внимание. Это метод оценки архитектур. Ключевым шагом является создание «сценариев», то есть вещей, которые система может потребовать в будущем, изменения или расширения требований. Например, если система работает в другой ОС. Затем вы оцениваете, как архитектура будет учитывать эти сценарии.