Тут можно обсудить поднятые вопросы:
Очно на встрече я не успел поднять следующую тематику:
Выход автоматизированного тестирования на новые рынки под давлением маркетологов.
Суть дела такая. Количество хост систем (OS, HardWare, InteractiveWare) неуклонно возрастает, в результате сфера потенциального применения автоматизации скачет семимильными прыжками. Автоматизация тестов требуется больше и больше благодаря обилию однотипных моделей и апгрейд юнитов рожденных умами дотошных маркетологов для поддержания динамики рынка. Тоесть предприятия впаривают одно и то же, только другой формы и "новее". А тестирование идет ручками каждый раз не смотря на схожесть задач (((. К сожалению для осуществления комплексной автоматизации тестов потребительской электроники отсутствует инструментарий не только как проект но и как концепция единого инструмента для тестирования приложений с динамическим маркетингом. Более того, очень часто тестирование и исправление ошибок и доведение функционала отнимает время которое маркетологами отведено на жизнь продукту. Сделай сегодня посудомойку с функцией заказа моющих средств и пока протестируешь - маркетинговая ценность умрет не успев достичь прилавков потому что уже выпустят посудомойки которые заказывают недостающие чашки к чайному сервизу =)).
Уже почти завтра-послезавтра каждый миксер получит собственную ОС а некоторые приборы типа пылесоса ROOMBA давно катают на борту спец софт, развиваемый активным комьюнити. Бурное развитие интеграции в целом порождает уйму непокрытых операционных ситуаций. С которыми мы можем столкнуться, к примеру, в стиральных машинах. Когда интерфейс последовательного выбора режимов стирки в ручном программировании может завести в логический тупик. И эти ошибки перекатывают из серии в серию на Аристонах и Индезитах. Несомненно тестирование потребительской электроники по соответствию функционала идет, но на основе базы знаний и долгого методичного подбора параметров ручками.А часто просто копированием блоков кода в новые микроконтроллеры без попытки перепроверить обширную комбинаторику автоматом. Проще и дешевле поставить заглушку чем разрабатывать код так долго что планируемая модель с этим кодом устареет по маркетологическим меркам.
Но что если система не имеет базы знаний? Как тестировать систему которая была рождена промышленностью и маркетологами ориентируясь только на тенденцию рынка а не на существующую потребительскую инфраструктуру. Примером может быть любой интерфейс введенный в обычную вещь. Котел который использует прогноз погоды для того чтобы сэкономить энергию отключившись на час или 2 раньше так как день обещает быть теплее.
Казалось бы все просто - дергайте RSS ленту из интегрированной ОS, получайте данные и выставляйте программу. Пять шесть Exception ситуаций для теста и можно пускать в серию. Эти котлы как инновация будут продаваться год успешно и еще три с учетом конкуренции от китайцев (тоесть уже хуже). Дальше маркетологи введут новые требования для привлечения клиентов с сохранением устоявшейся функции погоды. Тоесть в новой системе регрессионные тесты можно было бы уже автоматизировать. Но нет инструмента для подобного мероприятия. Все снова придется гонять руками или не подходящими для комплексного тестирования инструментами.
Есть симуляторы схем
Есть компиляторы и эмуляторы ОС
Есть системы автоматического тестирования
Все отдельно есть но нет совмещения функций в единую связанную: Спроектируй схему, Скомпилируй под эмуляцию ОС, Скорми эмулируемой ОС даннные из скрипта тестирования.
Так вот к чему я все это вел. Как только предприятия дойдут до создания IDE для проектирования и автоматизированного тестирования потребительской электроники работающей под ОС. Появится невероятная по своему размеру ниша. Отнюдь не связанная с электроникой на уровне "умей паять и читать схемы". А ниша автоматизации тестов для потребительского уровня. И чем сложнее система тем большая вероятность обязательного автоматизированного тестирования в виду сокращенных сроков относительно старта разработки и момента появления на прилавках. Маркетинг и рынок выведут авто тестирование из уровня IT в Потребительскую электронику.
Соответственно изменятся многие принципы авто тестов. Но об этом мы узнаем только столкнувшись непосредственно с камнями на пути к новым вехам технологического прогресса.
Да, Саша, ты явно затронул тему оперережающую текущею технологическое развитие. Как только устройство + компьютер + интерент будет обыденным делом, так сразу и будет такая автоматизация. Ведь кто движет инновацией, государства, а конкретно военная промышленность или большие корпорации. Посмотри, на iRobot (Roomba, который ты упоминал), а ведь они больше всего делают роботов для американской армии. Я конечно не знаю, но очень сильно убежден, что есть какая нидудь автмоатизация в таком роде для их роботов. Просто еще не пришло время. А время придет, когда каждое устройсво в доме будет с бортовым компьютером.
Так вот, будущее, будущим, а я учу Robot Framework :)
Да вообщето на борту у всех бытовых приборов производства после 2001го года уже есть компьютер способный ломиться в интернет и обмениваться данными. Нехватает только софта и маленькой деталюхи именуемой WiFi-USART интерфейс.
Вот только все еще есть разница между application уровнем устройства этих набортных компьютеров и consumer уровнем. Если первый это "три кнопки и 2 светодиодика" то второй это полноценный программируемый интерфейс, позволяющий расширять функционал без участия компании разработчика (или спеца с правильным программатором).
Robot Framweork к моменту появления массовых ботов себя исживет. Это же софт-затычка для технологии а не про инструмент. Как только "все начнется" в VS20xx уверен будет уже мощнейший набор инструментов. Учим студию )))))
testomat.io управление авто тестами