Я обычно делаю это:
1) Добавьте новые функциональные тестовые наборы в автоматизированную систему регрессионных тестов. Обычно я запускаю программный проект с собственной системой регрессионного тестирования с
- Библиотека Excel VBA + C для управления интерфейсом / устройством SCSI / IDE (13 лет назад), протокол испытаний - таблица Excel.
- TCL Ожидается комплексное тестирование системы сетевого маршрутизатора. Протокол испытаний - это веб-страница. (6 лет назад)
- Сегодня я использую Python / Expect. Протокол испытаний представляет собой XML + python base XML анализатор.
Эта цель для всех этих работ состоит в том, чтобы удостовериться, что, как только обнаружена какая-либо ошибка, она больше не должна появляться в коде регистрации или в производственной системе. Также легче воспроизвести случайные и долгосрочные проблемы.
Не проверяйте ни один код, если он не прошел ночной автоматизированный регрессионный тест .
Я обычно пишу соотношение 1: 1 между кодом продукта и кодом тестирования. 20 000 строк эксперта TCL для 20 000 строк кода C ++. (5 лет назад.) Например:
- C-код реализует прокси-сервер переадресации TCP-соединения для туннеля установки.
- Контрольные примеры TCL: (a) Настройте соединения, убедитесь, что данные передаются через. (b) Настройте соединения с различными сетевыми элементами. (c) Сделайте это 10, 100, 1000 раз и проверьте на утечку памяти и проблемы с системными ресурсами и т. д.
- Сделайте это для всех функций в системе, чтобы понять, почему соотношение 1: 1 в тестовой программе кодируется.
Я не хочу, чтобы команда QA проводила автоматическое тестирование с моей тестовой системой, поскольку весь мой код проверки должен пройти тесты. Обычно я провожу двухнедельный долгосрочный регрессионный тест, прежде чем передать код команде QA.
Команда QA, выполняющая тестовые сценарии вручную, также должна убедиться, что в моей программе достаточно встроенной диагностической информации для обнаружения любых будущих ошибок. Цель состоит в том, чтобы иметь достаточно диагностической информации для устранения 95% ошибок за <2 часа. Я смог сделать это в моем последнем проекте. (Видео сетевое оборудование в RBG Networks.) </p>
2) Добавить диагностическую программу (в настоящее время веб-база) , чтобы получить всю внутреннюю информацию. (Текущее состояние, журналы и т. Д.). > 50% моего кода (особенно c / c ++) - это диагностический код.
3) Добавьте подробный журнал проблемной области, которую я не понимаю.
4) Анализ информации.
5) Попробуйте исправить ошибку.
6) Выполнение регрессионных тестов в течение ночи / в выходные дни. Когда я занимался исследованиями и разработками, я обычно запрашиваю в аренду 5-10 тестовых систем для непрерывного проведения регрессионных тестов 24x7. Обычно это помогает идентифицировать и решить проблему с памятью, ресурсами и долговременной производительностью до того, как код достигнет SQA.
После сбоя встроенной системы время от времени загружается в приглашение Linux. Я добавил тестовый пример, который снова и снова включал и выключал систему с программируемой розеткой, чтобы убедиться, что он «видит» командную строку и запускает тест в течение ночи. Мы смогли быстро идентифицировать проблему с кодом FPGA и убедиться, что система всегда работает после 5000 циклов питания. Был добавлен контрольный пример, и все новые коды Verilog проверки кода / FPGA построен. Этот тест был выполнен. Это никогда не было проблемой снова.