项目中对质量的思考

为什么一定要有测试人员

目前公司基本都有专职的测试人员跟进项目，如果没有专职测试，那么也一定会有人员去负责上线前的测试。

关于测试人员存在的必要性，原因很多，但个人认为最重要的是： [虎毒不食子]

开发人员对于自己开发的产品，往往更倾向于看到产品的技术有多么高超，用了某某算法，优化手段，实现了多么强大的功能，而对产品本身的局限性认识不足。开发人员对自己开发的产品（如同自己的孩子一样）越满意，越不想去发现[孩子]的不足之处。

当然，对于某些小的代码改动，或纯粹技术方面的优化而言，开发人员还是很客观的，并且其自测方法往往也很靠谱。 但是一旦涉及大范围的代码改动，或者代码影响牵连的业务很多，开发人员的盲点便出现了。再加上对自己开发的产品爱屋及乌，那么往往产品本身的局限，或者bug，也看成[无伤大雅]了。

接口自动化vs监控

关于接口自动化的目标和难点可以参考http://blog.csdn.net/huazhongkejidaxuezpp/article/details/52267126。其中，接口自动化由于对接口的检查太过详细，不仅依赖于项目需求的变动频率，而且往往跑完一遍所有接口检查耗时较长（ps:接口越多，检查越详细，耗时越长），所以接口自动化检查，往往不太适合作为接口的监控。因为如果要去监控接口，往往因为耗时不满足（例如，要求每分钟检查完所有的接口），功能不稳定（接口的边缘功能失常，便来了大量的重复报警），因此，详细的接口自动化检查往往需要进行一下瘦身，才能变成接口的监控。

接口监控的级别

对负责项目的监控，可以分成以下几个层面来做，确保线上服务的正常（相当于线上服务的多层防护）：

1） 防护第一层：服务层的restful接口简单

服务层这里指：直接和DB打交道，提供服务的项目。服务层的形式可以是thrift，jar报等等。

2） 防护第二层：API层的接口监控

主要对后端提供给前端的接口进行监控。

3）防护第三层：前端接口或服务的监控

这里的前端接口指前端服务器自己封装的接口，如node会自己封装一些对数据二次加工的接口。当然，如果确实有需求，也可以做UI自动化来监控了。

ps : 作为监控来说，有个特别注意点，监控接口时，除了使用域名对接口监控外，还可以直接使用IP直接监控到具体机器上的服务，因为这样可以随时监控到哪台机器挂掉了，防止某一时刻能提供服务的机器过少，而直接扛不住流量的情况。

项目的风险评估

这里的风险专指产品使用的风险。某种产品，往往发现可能被错误使用的功能，或者使用不流畅的点，那么这时是继续保持上线呢，还是专门来做些修改？类似的问题在线下的产品中往往更多。由于线下产品一般会有专门的产品培训，所以产品成型后一般比较“粗糙”。对于使用的风险评估：

1） 开发人员往往倾向于不做修复，让业务方保证；

2） 产品往往会不重视，或者会在产品使用培训中[着重强调]；

3） 测试人员往往发现后，在项目测试总结中一一列出。

对于类似的风险，往往倾向于让使用者来保证[按照正确的方式使用产品，把自己分内的事做好，则产品不会出问题]。但实际，业务使用者往往会在之后的使用中，不能[把自己分内的事做好]，因而会反过来重新找技术人员排查问题。此类问题的解决办法：最好找出类似的例子，讨论技术人员是否会接收后续继续排查原因。

项目中的单元测试

目前为止，接触的项目中，均没有专门的单元测试。无论开发人员或测试人员，均对单元测试上心很少。究其原因：

1）开发人员忙于开发上线，无暇顾及。更重要的是，开发人员的KPI从来没有考虑单元测试这一项，如果做了单元测试， 占用的不少时间，而且对自己也不会有[显而易见]的好处，所以，开发人员极少主动去做单元测试。

2）测试人员来说，还没有接触过专职于做单元测试的，只是听说个别公司会专门招聘人员做单元测试。单元测试相对于功能测试，性能测试，接口测试等等，显得不那么重要，因为bug出现后，基本都可以在后续的测试中发现。即便没有单元测试，测试人员也可以尽可能多的找出bug来。相反，如果非要去做单元测试，一来没有时间，二来是觉得似乎没有什么重要bug非要使用单元测试才能找出来。

撇开谁来做单元测试，就单元测试的效果而言，目前能想到的只是说，单元测试可以保证方法实现的更加完整，对异常情况的处理更加完善。但这相对于为实现单元测试而付出的代价（时间精力）而言，实在不是非常具有吸引力的。