Как эффективно устранять неполадки или тестировать новый код, когда сложно или невозможно получить настройку оборудования для воспроизведения ошибок?

Я работаю в компании среднего размера (150 человек, команда инженеров ~ 10), и большинство моих проектов включают взаимодействие с лабораторным оборудованием (осциллографы, анализаторы оптического спектра и т. Д.) Для целей полуавтоматических тестовых приложений. Я столкнулся с несколькими различными сценариями, в которых я не могу эффективно устранять неполадки или тестировать новый код, потому что у меня больше нет или никогда не было доступной настройки оборудования для меня.

Пример 1: установка, в которой 10-20 процессов «прожигания» выполняются независимо с использованием настольного датчика - я смог получить один такой датчик для тестирования и иногда мог украсть секунду для моделирования всех аспектов сопряжения с несколько устройств (поиск, подключение, потоковая передача и т. д.).

В конце концов обнаружилась ошибка (и в конечном итоге оказалась в микропрограмме и драйверах устройства), которую было очень трудно точно воспроизвести только с одним устройством, но она достигла уровня «покажите стопор», когда 10-20 из этих устройств использовались одновременно. Это все еще не решено и продолжается.

Пример 2. Тест, требующий использования дорогостоящего оптического анализатора спектра в качестве основного компонента. Устройство довольно старое, по словам производителя, которое было приобретено более крупной компанией и в основном распущено, и его единственная документация была длинным (и неинформативным) документом, который кажется плохо переведенным. Во время первоначальной разработки я мог держать устройство на своем рабочем столе, но теперь оно было привязано как физически, так и по графику во время его многонедельных тестов 24/7.

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

Я думаю, мой вопрос, как я должен подойти к этому? Потенциально я мог бы потратить время на разработку симуляторов устройств, но подсчитав, что в оценке развития это будет больше, чем многие, вероятно, оценят. Он также может точно не воспроизводить все проблемы, и довольно редко можно увидеть такое же оборудование, которое используется здесь дважды. Я мог бы стать лучше в модульном тестировании ... и т.д. ... Я также мог бы громко рассказать об этой проблеме и дать понять другим, что потребуются временные задержки, не намного больше, чем головная боль для исследований и разработок, но обычно воспринимаемая как шутка когда передано в производство.

Руководство понимает, что разработка и поддержка программного обеспечения займет больше времени, если у вас нет полного доступа к тестовому оборудованию. Вы должны принять это во внимание, делая ваши оценки. Частью критериев приемлемости для запуска вашего программного обеспечения в производство должно быть то, что у вас есть способ поддерживать программное обеспечение в большинстве случаев без остановки производства. Если вы практикуете TDD, это должно произойти довольно естественно.

Я писал программное обеспечение для самолета за 60 миллионов долларов. Очевидно, что требуется высокая степень надежности, и они неохотно дают каждому разработчику по одному на свой рабочий стол. В основном у нас было 5 уровней тестовой среды, с большим количеством реального оборудования на каждом уровне, вплоть до полноценного самолета. Я считаю, что 95% нашего программного обеспечения может быть разработано и отлажено только с помощью эмуляторов и модульных тестов. 95% оставшихся функций могут быть обработаны на следующем уровне, и так далее.

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

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

Например, возможно, у вас есть ошибка, и вы можете подумать о 10 возможных причинах. Если единственное время, которое вы можете получить на машине, это 15 минут, пока оператор находится на перерыве, напишите короткий, автономный, корректный (компилируемый) пример, который вызывает ошибку, и напишите 10 автоматических тестов с использованием этого SSCCE для проверки ваших теорий. и зарегистрировать кучу данных. После возвращения за свой рабочий стол вы можете потратить столько времени, сколько вам нужно, чтобы просмотреть данные для следующей попытки. Идея состоит в том, чтобы максимально использовать ваше ограниченное время на оборудовании.

Вы пытаетесь решить проблему, которая не ваша.

Руководство должно установить приоритетность доступа к оборудованию. Это может означать, что у вас больше доступа, но может и меньше.

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

Оттуда компания (руководство) должна расставить приоритеты, кто и когда получает доступ. Это бизнес-решение, которое они должны принять, поскольку (отсутствие) наличия ресурсов влияет на развитие бизнеса.

Вы эффективно кодируете слепого.

Если руководство не будет платить за тестовые устройства, тогда высока вероятность ошибок или даже разработка займет больше времени, чем если бы у вас были реальные устройства для использования.

Стоимость устройств не должна быть полностью отнесена к циклу «разработки». Может быть, они могут быть превращены в производственное использование или в качестве резервной копии. Могут ли они быть перепроданы в другом месте в другом месте?

Попробуйте и заплатите фазы исправления ошибок, как по времени, так и по деньгам, и покажите общую стоимость вашей команде / компании.

Спорить со своими боссами гораздо проще, когда у вас есть какие-то цифры, или, по крайней мере, есть какие-то плюсы и минусы, поэтому мое предложение - попытаться провести анализ затрат и выгод. Грубая идея выглядит так:

• сколько усилий по разработке вы ожидаете для написания симулятора устройства? (Обратите внимание, что имитатор устройства не может заменить оригинальное оборудование на 100%, особенно если у оборудования есть некоторые неожиданные причуды).

• сколько усилий по тестированию / отладке вы ожидаете без такого инструмента? Включите расходы на сотрудников вашей лаборатории, потому что вы должны заблокировать оборудование для тестирования. Включите также стоимость времени, в течение которого система не может быть использована из-за ошибок, и у вас возникли проблемы с поиском основной причины.

• сколько будет стоить дополнительное оборудование для тестирования?

• сколько времени вы ожидаете, что вам понадобится заблокировать оборудование для тестирования?

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

Представьте результаты своему руководству, обсудите альтернативы, а затем дайте им решение.