对于初学者来说学单片机不是最终目标，达到某项功能才是最终目标

前几期了解了一些嵌入式的相关知识，这一期了解界面自动化测试

在没有图形化界面以前，字符方式的界面是比较容易进行自动化测试的。一个编写优秀的脚本就能够达到输写和对输出的检查。但是对于图形化的界面，人的参与似乎变得不可缺少少。有一些界面自动化的测试工具，如WinRunner， 这些工具能够记录下测试人员的操作成为脚本，其次通过回放这些脚本，就能够达到操作的自动化。针对嵌入式设备，有Test Quest能够运用，通过在设备中运行一个类似远程桌面的Agent，PC端的测试工具能够用图像识别的方法识别出不同的组件，并发送相应用户的输写。此类工具的根本工作原理：

文章相对比较长，字数比较多，大家可以先打开头像关注我，之后慢慢看，///插播一条：我自己在今年年初录制了一套还比较系统的入门单片机教程，想要的同学找我拿就行了免費的，私信我就可以哦~点我头像左下角黑色字体加我也能领取哦。最近比较闲，带做毕设，带学生参加省级或以上比赛///

但是这个过程在现实中中存在三个问题：

1.可靠性差，经常中断运行。要写一个可靠的脚本甚至比开发软件还要艰难。假如，按下一个按钮，有时候一个对话框立刻就出现，有时候可能要好几秒，有时候甚至不出现，操作录制工具不能自动达到这些判断，而须要手动修改。

2.对操作结果的判断很艰难，尤其是非规范的控件。

3.当界面修改后，原有代码很容易失效

要应用基于图形界面的自动化测试工具，架构师在架构的时候应该考虑：

1.界面格调怎么样保持一致。应当由架构，而非程序员决定架构的格调。包含布局，控件大小，相对位置，文字，对操作的响应方式，超时时长，等等。

2.怎么样在最适宜测试工具的界面和用户喜爱的界面之中折中。假如，Test Quest是基于图像识别的，那么黑白两色的界面是最有利的，而用户喜爱的渐进色就非常不利。兴许让界面具备自动的切换才能最好。

对于已经完成的产品，假如架构没有为自动化测试做过考虑，所能应用的范围就非常有限，不过还是有一些思维能够供参照：

1.达到小规模的自动化脚本。针对一个详细的操作流程进行测试，而不是试图用一个脚本测试整个软件。一系列的小测试脚本组成了一个汇合，笼罩系统的一局部功能。这些测试脚本能够都以软件启动时的状态作为基准，所以在状态处理上会比较简略

2.”猴子测试”有一定的价值。所谓猴子测试，就是随机操作鼠标和键盘。这种测试完全不了解软件的功能，能够发现一些正常测试没法发现的错误。据微软内部的资料，微软的一些产品15%的错误是由“猴子测试”发现的。

总的来讲，基于界面的自动化测试是不成熟的。对架构师而言一定要避免功能只能通过界面才能访问。要让界面仅仅是界面，而软件大局部的功能是独立于界面并能够通过其他方式访问的。上面框架的例子中的设计就体现了这一点。

思考：怎么样让界面具有自我测试功能？

基于音讯的自动化测试

假如软件对外提供基于音讯的接口，自动化测试就会变得简略的多。上面已经提到了固件的TL1接口。对于界面局部，则应该在设计的时候，将纯粹的“界面”独立出来，让它尽可能的薄，而其他局部依然能够基于音讯提供效劳。

在音讯的根底上，用脚本语言包装成函数的形式，能够很容易的调用，并笼罩音讯的各种参数组合，从而提高测试的笼罩率。关于怎么样将音讯包装为脚本，能够参照SOAP的达到。假如运用的不是XML，也能够自己达到类似的自动代码生成。

这些测试脚本应该由开发人员撰写，每当达到了一个新的接口（也就是一条新的音讯），就应该撰写相应的测试脚本，并作为项目标一局部保存在代码库中。当须要执行回归测试的时候，只有运行一遍测试脚本即可，大大提高了回归测试的效率。

所以，为了达到软件的自动化测试，提供基于音讯的接口是一个很好的办法，这让我们能够在软件之外独立的编写测试脚本。在设计的时候能够考虑这个因素，适当的增加软件音讯的支持。当然，TL1只是一个例子，依据项目标须要，能够选择任何合适的协议，如SOAP。

对单片机感兴趣的朋友可以找我，我录制了一些关于单片机的入门教程，有需要的童鞋找我拿就像，免费的，私信我“林老师”就可以拿～点击打开我的头像就能领取。