sdk测试总结

       从1月份开始至4月底，在跟进一个SDK项目，主要负责iOS端的SDK测试，研发过程曲折，延期上线，测试工作量巨大。收获挺大的，在此总结下。

       整个项目的进程大致是：

①  技术背景宣讲->②技术方案确定->③开发编码（测试准备并行）->④部分方案变更->⑤测试开始测试->⑥开发bugfix->重复③④⑤⑥步骤n次（这次的n有点多）->⑦提供framework包给业务方，配合测试、bugfix->⑧上线。

在这里不吐槽项目过程的一些问题，仅分析测试在这里做了些什么、做的方法、做得好的、做得不好的、个人成长、后续学习改进的建议。

一、做了些什么

1.       半路进入这个项目（项目已在进程③），负责iOS SDK的测试，快速找pm了解大致的技术方案，根据模块快速的划分测试分工（iOS全职算2个人，实际是3个人部分投入）；

2.       根据sdk的特点，对单测框架选型，最终定了xctest；

3.       根据技术方案制定tc，评审tc;

4.       编写测试demo，画UI，调用sdk的方法，从功能和方法级别对sdk进行测试；

5.       编写性能测试demo，对db性能进行测试；

6.       配合业务测试一起排查问题、解决问题，上线。

二、做的方法

测试框架选型：

详细查看了xctest的说明，结合之前了解的GHUnit、ocMock，再根据项目的特点，纯数据的处理、DB文件的读、写，所以选择了轻量式的跟xcode结合紧密的xctest，基本满足项目的测试需要。

sdk测试方法：

在开发已搭建iOS Application demo的基础下，就直接在demo里编写代码调用framework里的方法，将方法的实际返回显示到界面上。

在测试顺序上，基本从底部->上层->模拟业务方调用的顺序进行测试，首先测试db的功能（C层），满足正常功能（读、写、多线程读写等），再测试oc层dataBase(oc上对C层的方法进行封装，方便上层调用)，再测试OC manager层（有部分业务含义，主要是各种业务表的增、删、改、查方法），最后测试对外暴露的公共接口（读、写）的各种逻辑。利用分层测试的策略，sdk的各个剖面基本都覆盖到了。最后通过模拟业务方调用sdk公共接口，简单的校验了sdk的初始化逻辑和读写逻辑。

三、做得好的：

测试用例对功能级别和方法级别的覆盖率较高，codeReview几乎达到了100%，从方法层面和功能层面保障了sdk的质量，达到之前的预期。

提bug时尽量debug出问题的原因，提供可能的解决方案，帮助提升开发解决bug的效率。

四、做得不好的：

1、          花在方法级别的单测时间过长，提供给业务方的时间延后，有些问题在业务接入后才暴露

2、          整体面上和细节的考虑不平衡，sdk测试不仅是要保障各个方法、接口正确，还要保障业务复杂场景下的数据正确

3、          忙于sdk的测试，未从业务测试角度出发，提供相应的环境切换工具、快速查日志、快速定位问题方法

五、个人成长：

1、          在项目中实战了sdk的测试，sdk要测到什么粒度，各个模块如何平衡，测试主要编写sdk暴露的公共接口的测试，辅助开发进行私有方法和内部方法的单测。

2、          业务测试代码review时更多的是各种UI的绘制，数据model的构造、解析，sdk代码review时看到的实现更底层，比如多线程的调度，提升了代码的深度理解

六、后续学习改进的建议

1、          遵守单测的规范，利用xctest框架，将单测的脚本移植到sdk的工程，引入XcodeCoverage(目前已引入)统计单测覆盖率，并作为开发提测交付物之一，最好是加入到持续集成（目前已引入）

2、          提供帮助业务测试快速查日志、定位问题的方法或工具

3、          后续测试sdk时，不仅要从方法级别、功能级别保障质量，要更多的思考业务场景，尽可能的模拟业务的使用场景，构造复杂的条件（比如多线程、弱网、网络切换）

4、          在技术方案评审阶段，多多思考，否掉不合理的方案，减少开发推倒重新编码的情况，相应的减少测试重复测试。

希望下次在做sdk项目测试时，能汲取此次的经验和教训，更进一步的提升技术能力。