谢邀。
可以做,自动化和系统测试都可以。
首先考察下这几个问题:
1. 人机接口有哪些,串口肯定有吧?按键,触摸屏有没有?
2. 每种人机接口输入方式对应地有一个消息吧,底层肯定实现的有消息机制和消息循环吧?
3. 如果消息机制没有,事务处理是在中断服务里做的,可以人为触发中断吗?可以认为中断也是一种消息。
上面几个问题搞清楚了以后,可以这么实现:
1. 录制开机后的所有消息并保存,黑盒测试人员的所有操作会被记录下来,测出 bug 后,通过特殊的按键组合或者其他交互方式保存,即成为一个用例。消息最好能带时间甚至 clock 数值。
这样做避免了测试人员在枯燥的测试中偶尔测出 bug 却记不得自己刚才是怎么操作的,也避免了用文字描述不够准确,或软件人员重现不了时双方的扯皮和矛盾。
2. 在系统中设计用例回放机制,即能解析上面保存的消息并重新 post 出来,这样将大大方便软件人员 bug 定位以及修改后的验证。
3. 如果有精力的话,可以实现一个简单的测试脚本解析模块,比如脚本里写:
repeat 10000:
keydown A
delay 300
keyup A
pendown (x, y)
……
同样地,解析成消息 post 出去。脚本通过串口或者网络发送给系统。
这样可以实现一些更复杂的测试,具体能实现什么,看你们的想象力了。
随着扩展,可以添加你们产品的主要业务对应的高级指令,约定好参数,系统解析并调用内部 api 就可以了。
唉,这些曾经是我们团队实现的很得意的压箱底的东西啊,免费教给你了,快给赞。
搜到一篇论文,跟我说的方法思路相同,表达更完整:
实时嵌入式系统平台自动测试工具