Comments 9
Я хоть и не тестировщик/разработчик, но очень понравилась статья, лайк 🥰
Привет, Иван) С системой Sandbox знаком не понаслышке, испытал приступ ностальгии от созерцания интерфейсов. Тестирование баз и модулей дело важно и система мегаполезная, но не без недостатков, попила немало крови.
Жаль, не успел добить автоматизацию через библиотеку. Кто-нибудь ее завершил в итоге? Если что, мои контакты должны быть, выходи на связь)
Привет!
Продуктовые команды сейчас используют автоматизации при встраивании в Sandbox и уверен, что твой опыт они переиспользовали.
Sandbox как среда тоже активно развивается, добавляются новые проверки которые улучшают весь процесс в целом.
Наверное надо будет написать отдельные статьи про каждую из сред, на что они заточены и для чего.
А как же тестирование на non-intel? 😔 Не расписал.
Денис, привет!
Первая статья "ознакомительная", надеюсь, что будет время и смогу раскрыть разные аспекты в следующих статьях или может кто-то из ОПВО напишет про разные базы отдельно и про non-intel и про SSII и другие.
А также отдельный пост нужен про "как мы тестировали, тестируем и будем тестировать базы для мобильных девайсов" - рассказать про первый стенд, затем dev-борды, виртуализацию мобилок...
Рассказывая про white box testing, Норберт Винер и Гленфорд Майерс описывали много нужных параметров. А один из главных пунктов — это необходимость анализа кода.
В black-box testing, согласно Уильяму Эшби, нужно действовать как пользователь — менять только входящие параметры в широких пределах.
Упоминая Гленфорда Майерса вы скорее всего имели ввиду книгу "The Art of Software Testing". Упоминая Уильяма Эшби, это вероятнее всего "Introduction to Cybernetics". Но на какую работу Норберта Винера вы ссылаетесь в этом контексте, я не смог расшифровать. Может подскажете?
По запуску тестов: не рассматривали инфраструктуру по запуску Azure DevOps? (Pipeline \ Releases)
У нас наладить Azure на первом этапе оказалось непросто. Но после перехода с самописной системы мы получили богатое API, интеграцию с дашбордами под каждую команду, нормальную документацию от MS и возможность гибкой настройки предварительных действий перед запусками.
В 2012 году, когда проводили анализ перед началом создания распределенной системы тестирования сравнение было с MS TFS 2010 (и возможно даже с TFS 2012) - на тот момент функционал от TFS не мог дать нам гибкости и удобства для тестирования, основные минусы как я помни тогда были - это не возможность в TFS использования фасада тестирования, не возможность подключения всех видов ОС и всех видов гипервизоров.
Предположу, что в текущей версии Azure DevOps 2022 уже много по другому, но и наша система не стояла на месте за 8+ лет появилось много бизнес-функционала который состоит из "In House" решений со своей спецификой для тестирования баз.
Пока переход в Azure DevOps не рассматриваем, продолжаем развивать свою систему.
P.S. но для разработки самой системы мы конечно используем Azure DevOps как я писал выше в статье :)
Тестировало тестирование тестировщика, или Как мы используем и тестируем распределенную систему тестирования