1. Восприятие пользователя
Очень Первое, что я хотел бы сделать, это просто опросить пользователей. Помните, что именно для них мы и делаем это. Как бы ужасно приложение ни заглядывало внутрь, если пользователям оно нравится (или, по крайней мере, оно ему не нравится), вы не хотите сразу же начинать его разрывать.
Я бы хотел задать такие вопросы, как:
- Работает ли он гладко?
- Легко ли пользоваться?
- Когда вы используете его, чувствуете ли вы уверенный , что он делает то, что вы ожидаете?
- Это БМВ, Цивик или Пинто?
Ответы будут субъективными. Это нормально. На данный момент мы просто ищем широкие тренды. Если подавляющее число пользователей говорят, что они все время терпят крах или что они боятся выполнять основные задачи, то у вас проблемы.
Если приложение порождает суеверие , и вы слышите такие вещи, как «кажется, что он выпадает по утрам в четверг» или «Я не знаю, что делает эта кнопка, но она не работает, если я не сначала нажми ", беги за холмы.
2. Документация
Отсутствие документации или документации, которая ужасно устарела, является верным признаком больного приложения. Отсутствие документации означает, что сотрудники по разработке срезали углы или были настолько перегружены постоянным маршем смерти, что просто не могли найти время для такой «ненужной» работы.
Я не говорю о руководствах пользователя - хорошо разработанное приложение не должно нуждаться в них - я имею в виду техническую документацию, как выглядит архитектура, что делают компоненты, зависимости от среды, параметры конфигурации, требования / истории пользователей, контрольные примеры / планы испытаний, форматы файлов, вы поняли. Система отслеживания дефектов также является важной частью документации.
Разработчики в конечном итоге делают (неверные) предположения при отсутствии надлежащей документации. Я говорил с несколькими людьми в отрасли, которые думают, что это необязательно, но каждая система, которую я когда-либо видел или работал, с небольшим количеством документации или вообще без нее, заканчивалась ошибками и недостатками дизайна.
3. Тесты
Нет лучшего способа оценить работоспособность приложения, чем его собственные тесты, если они доступны. Модульные тесты, покрытие кода, интеграционные тесты, даже ручные тесты - все работает здесь. Чем полнее набор тестов, тем выше вероятность исправности системы.
Успешные тесты вовсе не гарантируют , за исключением того, что тестируемые специфические функции работают так, как того ожидают люди, написавшие тесты. Но множество неудачных тестов, тестов, которые не обновлялись годами, или тестов вообще нет - это красные флаги.
Я не могу указать на конкретные инструменты здесь, потому что каждая команда использует различные инструменты для тестирования. Работайте с тем, что уже находится в производстве.
4. Статический анализ
Некоторые из вас, вероятно, сразу подумали "FxCop". Еще нет. Первое, что я сделаю, это прорвусь NDepend .
Просто быстрый взгляд на дерево зависимостей приложения даст вам огромное количества информации о том, как хорошо разработано приложение. Большинство наихудших анти-паттернов дизайна - Большой шарик грязи , Круговые зависимости , Код спагетти , Объекты Бога - будут видно почти сразу с высоты птичьего полета зависимостей.
Далее я запустил бы полную сборку, включив параметр «обрабатывать предупреждения как ошибки». Игнорирование определенных предупреждений с помощью директив или флагов компилятора в большинстве случаев нормально, но буквально игнорирование предупреждений приводит к проблемам. Опять же, это не гарантирует, что все в порядке или что что-то сломано, но это очень полезная эвристика в определении уровня обслуживания, которое вошло в фактическую фазу кодирования .
После Я удовлетворен тем, что общий дизайн / архитектура не является полным мусором, , затем Я бы посмотрел на FxCop .Я не воспринимаю его как евангелие, но меня особенно интересуют Предупреждения о дизайне и Предупреждения об использовании (предупреждения о безопасности также имеют красный флаг, но очень редко).
5.Анализ времени выполнения
На данный момент я уже удовлетворен тем, что приложение на высоком уровне не является огромной кучей отстой.Эта фаза может немного отличаться в зависимости от конкретного приложения под микроскопом, но есть несколько хороших вещей:
Записать все исключения первого шанса при нормальном запуске.Это поможет измерить надежность приложения, чтобы увидеть, глотается ли слишком много исключений или используются ли исключения в качестве управления потоком.Если вы видите много Exception экземпляров верхнего уровня или производных SystemException, опасайтесь.
Запустите его через профилировщик, такой как EQATEC .Это должно помочь вам довольно легко выявить любые серьезные проблемы с производительностью.Если приложение использует серверную часть SQL, используйте инструмент профилирования SQL для просмотра запросов.(Действительно, существуют отдельные этапы для проверки работоспособности базы данных, которая является критической частью тестирования приложения, основанного на ней, но я не хочу слишком зацикливаться на этом).
Наблюдайте за несколькими пользователями - ищите особенно "ритуалы", вещи, которые они делают по-видимому без причины.Это, как правило, признак длительных ошибок и тикающих бомб замедленного действия.Также посмотрите, генерирует ли он много сообщений об ошибках, блокирует ли пользовательский интерфейс на длительные периоды, пока «думает», и так далее.По сути, все, что вы лично не хотели бы видеть в качестве пользователя.
Стресс-тесты.Опять же, конкретные инструменты зависят от приложения, но это особенно применимо к серверным приложениям.Посмотрите, может ли приложение по-прежнему работать под большой нагрузкой.Если он начинает отсчитывать время около предела, это нормально;если он начинает выдавать странное сообщение об ошибке или, что еще хуже, повреждает данные или состояние, это очень плохой признак .
И это все, что я могуподумай пока.Я буду обновлять, если что-нибудь еще придет в голову.