单例测试总结

最近写了比较多的单测,对测试用例做了一下总结。          

网上也有很多讲如何写单例测试的教程和经验总结,而且都比较系统。但这里还是总结一下自己在写单例测试时总结的经验。

1. 经验总结

1).时间和对象          

只对比较稳定的代码写单测。        
从反面讲,还处于经常修改状态的代码是不稳定的代码,针对其写的单测也必然是不稳定的,随着设计和代码的不断更改,单测也需要不断更改。

2). 去除底层依赖          

对一段代码写单测时,其中提供API、IO和DB数据的类或对象应该mock掉,但对这些类也要单独写单测。        
一方面,这些类对系统环境有很大依赖,当环境出现问题时(比如API的服务、DB宕掉),单例测试将不能进行;另一方面,这些类的效率一般比较低,不mock掉会增加单测运行的时间。

3).写单测的误区        

只为覆盖率而写单测。        

因为单测覆盖率往往成为一个系统质量的考核目标,所以在写单测时,可能只为提高单测覆盖率而写单测,过少地从业务的角度去写单测。单测应该是保证系统在各种业务场景下,系统仍能正常工作的工具。行覆盖率或者分支覆盖率的提高,并不代表不同业务场景的覆盖也会提高。

2. 对以后写单测方式改进

1). 建立自己的测试样本工具,比如可以自动生成的不同角色的用户的工具。这样方便或者更能全面地对系统的业务进行自动化测试。

2). 写单测时更多地站在业务的角度,而不是代码的角度。

4种系统间交互方式比较

4种系统间交互方式比较

指相对独立子系统间的交互
指标\方式 API 数据文件 共享数据库 (web系统)根域名cookie
实效性 高 低 最高 实时
时间效率 高 低 最高 低
实时空间效率 低 高 低 –
实时占用带宽 低 低 低 低
系统设计正交性 高 高 低 低
系统设计耦合度 低 低 高 高
实现方式 同步/异步 异步 异步 异步
协议 http request,socket,… ftp,telnet,http,https,iSCSI,nfs… redis,memcache,mysql,MongoDB… http,https
数据结构 自定义 xml,yaml,csv,excel,txt,binany,… database
适用场景 时效性要求高,请求次数多,请求频率很高 时效性要求低,数据量小或中,请求频率最低 时效性要求最高,系统中,某几个对数据请求次数很高,请求频率最高 需要记录在浏览器中的信息
举例 单点登录中,cas服务器和cas客户端之间的交互 财务系统和银行的对账文件 分布式数据库,共享session,异步api,计费系统的数据库 单点登录系统中的登陆信息(ticket等)