测试做了这么多年，相信大家也接触过不少形形色色的项目，除了按平台产品划分有这些项目类型：移动端的App应用、Web应用程序、Windows桌面应用程序……我们还有一种基础应用/架构服务项目，这种项目一般提供基础应用库或平台给公司内部或外部其他业务接入使用，一般的表现形式有Java的jar包、Android SDK有aar包、C#有DLL库、Python库、JS库等（maven等远程依赖的方式其实质也是远程下载jar、aar包到本地）。那么对于这样的Library API形式的发布包，说直白点，这就是一个代码框架+小许文档，我们该如何测试呢？
一、思路
已目前的技术水平我能想到的验证方式包括：
1、demo接入，自己写测试demo模拟用户接入Library包或者库，模拟或构造用户的使用场景在demo中调用对应的API，并可以考虑基于demo实现自动化测试；
2、单元测试，这一般是开发人员自己在做，不过看过一些开发写的单测，大都只是浅尝辄止，方法调通就行了，要是真从测试角度来写的话，一般得针对源码做路径、条件、组合等逻辑覆盖、链路调用等等；
3、静态代码扫描，一般研发流程规范的公司代码在入库之前都会进行静态代码扫描，目的很明确：不求发现bug，只求没有格式和规范错误。常见的静态代码扫描工具一般有sonar、findbugs、Lint、PMD等（后续考虑出一篇这方面的文章，敬请期待）。
4、其他，这本身就是一个依项目而异的议题，肯定还存在其他思路的，只是我暂时还未涉及，其他同学若有好的思路欢迎留言。
二、现实
对于上面的三种思路，其实从测试的角度来说，一般优先考虑第一种，自己写测试demo模拟用户接入，这样可以不必依赖源码，知道API的使用即可，另外从可测性的角度考虑，覆盖的场景可以更多，但对测试人员的技术要求相对较高，至少得熟练一门编程语言吧。此外demo易于使用和共享，因此即使组内或部门整体技术能力有限，但只要有部分人可以开发即可，写好的demo可以项目组内共享。
第一种方式在我接触过的类似项目中都取得了比较好的效果，而第三种静态代码扫描的方式发现bug的能力实在有限，我更推崇的是第二种，将单元测试发光发热（看看国外就知道了），可是单元测试的难度还是挺高的，首先得有download源码权限，其次差不多得像开发那样熟悉代码，不然作用不大~可考虑到国内的情况，测试要是代码水平跟开发接近了还会继续做测试么？！除非到了某一天对测试重视度、技能要求和待遇与开发一样时，我想那就是测试开发合并的时候（希望那天真的到来的时候，我们还在做测试）。
更多原创技术好文和资料，请关注公众号：测试开发栈
网友评论