测试应当关注些什么【转】

     新员工入职的时候，主管都会介绍岗位职责。作为测试，通常的说法是保障质量（当然也有一些其他的观点，比如测试是为了暴露风险等等。不过对于新员工，一般不会探讨这么形而上的问题）那么好，什么是质量呢？按我们朴素的理解，质量就是没有问题。问题是什么？实际与预期不符我们就认为出问题了。ISO 9000 2008中关于质量的定义是：一组固有特性满足要求的程度。按照这个定义，测试人员做得无可厚非啊，为什么得不到开发的认可呢？

     近年来软件互联网行业发展迅速，一个明显的转变是以产品为中心转向以客户为中心。因此关于质量的定义可以更加精确一点：质量即用户可感知的需求的满足程度。在之前的定义之上，首先它突出了用户需求。如果产品提供了一个功能，但是用户却从来用不到，那么这个功能即使有问题，用户也不会抱怨质量不好。另一个关键词是可感知。说到这想起不久前看到的一个帖子，分析苹果的iOS和微软的Windows哪个质量更好。大意是iOS的问题并不见得比Windows的少，但是它不像Windows那样，一出错就提示用户，还经常采用一些专业术语，让用户紧张而又无法解决。iOS通常会尝试自动修复，即使修复不了，也会采取温和的、不引人注意的方式来提示，甚至不主动提示用户。这样给用户带来的体验就很好，大家普遍认为iOS的问题比Windows少。

     说到这，测试的同学们是不是又开始认同开发了呢？

     如果质量仅仅是从客户的角度来看，似乎的确如此。让我们再看几个例子吧：

     程序员小A几年前开发了一个网站。在1024*768分辨率的显示器上看起来非常完美。后来大屏显示器普及，网站在1920*1080分辨率下看起来就不那么好了。小A花了两周的时间调整页面布局，却花了一个月的时间解决适配过程中引入的问题，终于再次发布。刚想喘口气，小屏的智能手机一夜成为主流，这回屏幕变成了竖的。小A发现之前写死的大量代码在新的分辨率下很难修改，更要命的是bug越来越多，最后只好全部重新开发。

     程序员小B负责开发安装卸载模块。小B考虑问题很周到，卸载的时候会把用户数据都删掉。但是有一次，在一个偶然的情况下，用户卸载的时候，数据文件被锁定了，无法删除。后来又有一个新的用户在这台电脑上重新安装这个程序，结果一运行，看到的都是前一个用户的个人数据。

     程序员小C开发了一个电子交易平台，通过严格的测试，在各种场景下均能正常处理，上线后也一直很稳定。突然有一天，一个用户反馈说有一笔交易异常，要求提供相关信息到银行去核对。小C平时不习惯在代码中记日志，而从银行侧的记录看又一切正常，完全没有办法分析定位，只好给用户赔偿。

     假设一下这几个案例是由测试人员在内部通过一些故障注入的手段发现的，并提交给开发，结果会怎样？案例1：“对用户无影响”；案例2：“不可能发生”，“操作不当”；案例3：“（记日志）对用户无影响”。看似都与用户无关，但一旦在实际使用过程中出现了，又确实会产生严重的影响。用更专业的术语来说，这些问题属于可扩展性、可维可测领域，或者可以把它们统一归结为设计问题。

     熟悉软件开发过程的人都知道，软件开发分为：计划、需求、设计、编码、测试、发布、维护几个主要环节，其中会引入质量问题的集中在需求、设计和编码环节。尤其在设计环节，引入的问题不容易发现，也不容易得到开发的认可。而一个资深测试人员和普通测试人员的区别也体现在这里：资深测试人员会根据自己的经验，分析问题发生的场景和影响，引导开发接受自己的建议，从而避免一些小概率大影响问题的发生。

     总结一下：

     如此测试人员既能保持自己的独立性，又能得到开发的认可，在与开发共同提升产品的质量的同时，自己也成为了专家。