搜狗浏览器单元测试流程规划

一、模块选取

由于浏览器代码涉及到UI相关的比较多，在我们的评估之下认为这些模块不值得去做单元测试，因为涉及UI相关的单元测试不好写且相对黑盒测试来说性价比低。

所以目前我们选取的都是些底层逻辑模块，或者数据库相关的进行单元测试。

二、单元测试用例构造与编写

先说下目前的情况，目前我们单元测试框架大多数有研发部门的同事搭好，我们只需要模仿着去搭框架或者直接在现有的框架下写测试用例。

对于用例构造这方面我们要求白盒测试同学先去熟悉产品代码，画出流程图，然后根据代码逻辑有取舍地设计出逻辑层面的用例，之后再根据黑盒相关设计一些合理性用例。

对于以后的规划，我们目前正在探索开发代码自动分析的一系列工具，愿景是以后逻辑层用例能够自动生成。

三、单元测试的执行

目前我们的做法是写个自动化的脚本，定期跑单元测试，一旦出了问题再去分析，然后判断是产品代码问题还是单元测试的问题，最后再把问题抛给相关负责人。

后面的规划是，能够分析出每块代码和哪些单元测试相关，一旦这部分的代码发生变动就自动去跑相关的单元测试Case，如果出现了问题直接反馈给提这笔代码的同事就好了。

四、单元测试结果报告形式

目前我们的做法就是解析Gtest生成的XML报告，将结果以更加可视化的报表发出来。

后期规划是要在Gtest的报告中再加入些我们自己的分析出来的因素，比如这条用例的相关模块、如果跑失败了失败的点在哪等等，以增加报告的可读性。

原文链接

如需转载该篇文章，请注明来自“搜狗测试”