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项目测试时,能汲取此次的经验和教训,更进一步的提升技术能力。

©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页