51Testing软件测试论坛

标题: 关于嵌入式系统如何进行测试 [打印本页]
作者: 草帽路飞UU    时间: 2017-8-11 10:02
标题: 关于嵌入式系统如何进行测试
转自知乎


问题：
1. 目标系统没有开发PC上的虚拟机，不容易进行自动化测试。
2. 好多问题属于人机操作，如何进行回归测试？
3. 在没有较为完善的单元测试和集成测试之前，系统测试如何安排？
4. 如何准备和实现自动化测试？
5. 与别的行业进行自动化测试相比，有没什么特殊之处? 比如和 ATM 机相比等等。
6. 没有跑操作系统或基于通用 OS，因此没有 shell 可用。




用户 老雕：

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


用户 郭雄飞：

首先，质量是设计出来的，而不是测试出来的。
我先说一些我的一些经验，之后想扩展到“嵌入式系统如何保证软件质量？”的问题。因为测试只是方法，质量才是目的。
解决问题的思路有如下几个
一些嵌入式软件测试的个人经验

用高级语言实现自动化测试
很多时候当手工测试已经占用了很多时间的时候，需要将其转换为自动化脚本。我最常用的就是基于Python的unittest，配合pexpect等工具，在加上强大的各种Python库，来实现自动化测试。
（慢慢补充）
利用好各种工具

谈谈嵌入式软件的质量问题
在像IC设计这样的硬件设计中，对正确性的要求是非常高的，因为一次性的投产费用高达数万美元至百万美元。而软件因为错了可以修改，所以有不同的质量要求。互联网的兴起从一定程度上降低了软件质量的水平，因为只要是非关键系统，有bug你可以随时升级。但是对于嵌入式来说，大部分产品卖出去就很难在升级了，比如电饭煲和家用电器这样的产品。所以对于质量的要求高于互联网，而低于硬件产品。
说了一段废话，其实我想引入IC设计中的一个概念，叫做可测性设计（Design for Test）。意思很简单，设计的时候就要为测试考虑。而不要等编码完了之后在去想怎么去测，这个时候测试的成本就是不可预期的了。









欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/) Powered by Discuz! X3.2