怎么做一个合格的测试

试着表述一下自己的测试思路：我期望的测试时怎样来做的。

首先给一个概念，Smart Test。何为聪明的做测试，从以下几个方面来描述：

A.重视投入产出比

首先，需要明确测试实际上是一种服务，一种技术手段，它通过一些方法、手段、工具来发现产品中的缺陷，通过及时暴露缺陷推动开发去修改来提高质量。而质量本身是与测试无关的，测或者不测，质量是在生产完成的那一刻确定的。

因此在投入一定量的测试工作量的情况下，如何让测试的收益更大？答案很容易想到，尽量找出多的缺陷，找出风险高的缺陷。那么如何做到这些？业内有人提出基于风险的测试，实际上这就是一个测试策略问题，放在我们面前一个系统，明确每个功能点应该投入多少的工作量、使用怎样的测试方法、怎样的过程、使用怎样的工具去测试，而制定策略的标准则是基于：

1.功能点的风险：如在支付宝很明显的涉及资金流的功能点，投入再多的工作量和分析也是合理的；如站在支付宝整体系统架构的角度，对支付链路上的系统，花费大量的人力去做测试评估和稳定性压测，都是合理的；另外对风险的理解上，可能技术同学与业务同学是理解不一致的，同样的业务功能，对技术同学来说可能觉得不重要但业务同学却可能认为不允许出问题，而测试同学是站在最终用户的角度来看问题，需要更多的站在业务角度来思考；

2.功能点的复杂度：复杂的功能点通常对应着大量的开发工作量，容易出现遗漏，容易隐藏更多的缺陷，对这样的功能点从过程上、测试分析方法上都可以有一些要求。

如过程上可与开发同学做好约定，对这样的功能点多一些自测，做一些ut/it，code review，自测能够杜绝一些低级缺陷，因为在进入测试阶段后，出现低级缺陷可能会导致测试阻塞，影响测试进度，也会降低大家对系统的质量信心；而ut/it code review除了能够减少后期修复缺陷的成本之外，也能发现一些功能测试无法发现的问题，如有次就在代码中看到有同学写一行查询数据库方法然后不用变量保存返回值，然后再写一行同样的代码用变量保存返回值…这种蛋疼的问题在功能测试是不会发现的，只有可能在性能测试的时候发现数据库访问时间有问题；

对于复杂的功能点，采用不同的测试方法，怎样测试“性价比”高一些，是从页面上测？从接口上测？与其他的功能点一起来测？还需要思考什么时候介入测试？如已经确定对这个功能点做接口测试，但是由开发同学写完一个就测呢？还是写完10个一起测？

3.对于不同的功能点，可以制订采用不同的测试设计方法，边界值/等价类/判定树/功能交互分析/测试类型分析，这些方法看看书都能懂，但不是对一个功能点所有方法一起上的（当然可以一起上，但是一起上的结果是更多的测试设计的投入时间，更多的测试用例，却不一定有更多的产出）。如对一个底层核心服务，需要做功能交互分析，弄清外围是如何调用的，需要做性能测试分析；而对一个有几个输入框的页面，通常要做边界值、等价类分析，找出所有的用户的输入场景，要做安全测试分析，对外用户访问可能引入安全攻击。



B. Don’t repeat your self

DRY原则是软件设计的概念，而放到测试行业中，则是大部分测试同学无法绕开的事情。对开发同学而言，今天写了一段代码，明天又copy了一把，被指责设计不够优雅，可以想办法重构设计来达到DRY的效果。而测试呢，今天咱执行了这100个测试用例，下次可以不执行么？君不见，收银台的测试每出现外围配合修改和每周sit时苦逼的测试执行么？这个问题通常的答案是：test automation。但是谈到测试自动化又伤感情了，君又不见，有多少团队投入成本去做测试自动化，却最终草草收场。测试自动化除去技术的部分，还需要领导的理解/认知正确，需要团队配合/协同，需要对业务和测试足够熟悉。

但是咱真不想每次都点同样的页面，查同样的数据库，查同样的日志。个人的思路是：谨慎自动化，尽量工具化。能用工具的地方，坚决不用人肉，比如之前有要求所有的sit环境的报错日志必须有测试同学去分析，难道我们每天sit的时候都让测试同学去捞一次服务器错误？写个简单的工具，捞一下日志自动发送一个邮件给大家不就好了；写接口自动化用例每次都要按照方法名来命名测试方法，要新增数据驱动文件等等，也可以写个eclipse插件来生成框架代码。另外，对自动化测试来说，应该把每次的测试自动化活动作为一个项目来看，分析清楚投入多少，可能收获多少，写自动化case之前分析清楚哪些业务用例是被反复执行最多的，而写自动化的投入又是相对较少的。

所以，对测试过程中一点点的重复活动进行优化，都是可以提高测试效率的，这些重复的活动不仅仅浪费的是测试同学的工作量，更是对测试同学的创新的扼杀，可以想象一个每天都习惯做同样事情的人能够有多大动力来做工作创新呢？

这个话题，再延伸一些是如何提高我们的测试效率。影响我们测试效率的点，无非就是这几方面，测试数据准备、测试环境、重复/机械的活动，解决这些问题除了上面提到的工具化、自动化，另外的手段就是通过合理的提出可测试性需求，在软件开发中就避免一些问题，如google的一个测试角色（软件测试开发工程师）的职责：“负责软件的可测试性”，“参与设计评审，近距离地关注代码质量和风险，对代码做重构为了系统有更好的可测试性”。

另外，重复的工作这件事情不仅仅存在于测试执行活动中，测试设计中，各位工作几年的测试同学没有觉得有部分的测试思路和方法是完全一样的么？为啥这些思路没有考虑过固化下来？比如对一些专用技术和业务的测试：在支付宝的幂等性测试、分布式事务的测试、消息收发的测试、某某类型的页面的测试关注点，这些都可以形成通用的测试分析，写一次，下次我们就复制过来好么，别每次都敲了。甚至业内还有将测试设计自动化的思路，如MBT（Model Based Test），根据业务的状态迁移模型使用随机过程的算法生成测试路径来达成测试覆盖。



C.不断的学习和发现被测对象

学习和发现被测对象的过程贯穿在整个测试活动中，或许有同学认为测试应该在需求、设计阶段就把被测对象弄的很清楚，实际上也有一种测试思路是把测试设计同学和测试执行同学完全分离开，认为测试执行是没有技术含量或者技术含量较低的。某种角度来说，测试执行也是一个学习和发现被测对象的过程，测试执行才是我们真正接触这个被测系统的过程。

期望的测试执行不是完全依赖测试用例来机械化的执行，而期望这个过程更类似于一个探索性测试的过程，通过测试来了解被测系统的业务关联性，发现系统的运作方式，进而来找出之前测试设计未涉及到的测试点。比如对有系统状态迁移的业务，某个业务场景是销售订单从已下单到已创建交易到完成付款，测试发现系统状态直接迁移到了完成付款，而实际资金调用是发生了问题的，问题是由于事务问题引起，但也暴露了系统状态迁移的接口没有做严格的约束，如A->B的状态迁移接口应该先判断当前状态是否为A，若不为A则不能做状态迁移，而不是无论前置状态就做状态迁移。从发现这个问题到了解到系统的运作，可以发现该系统的开发同学对状态的迁移约束是做的不够的，因此可以再去测试另外一个涉及到状态迁移和事务一致性的场景，就很可能立刻发现新的缺陷。



D.过程改进/实践

一位蛋疼人士说过，一个合格的tester应该是名业余QA，表示赞同。

用过程来解决问题，来保证质量，通常是最简单最有效的方法，虽然我们付出的是更多的工作量。比如通过缺陷回溯，发现这缺陷是因为发布的时候少了一个配置造成的，那么很简单，咱加一个工作，每次发布之前把发布测试一次就好了；比如发现有的开发同学质量意识不高，多次交付测试的版本质量很差，我们得想办法制定度量标准，把交付通过率作为一个度量指标来衡量；…

曾经的一位测试主管说过，不要把流程看做是一个工作的枷锁或者形式，它指导了我们在某个阶段应该做的事情。或许我们在某些时候因为进度压力，把部分流程裁剪了，或者部分交付件简化了，但实际上该做的事情不能省，省了一定会出问题。比如在传统瀑布模型中，概要设计要做、详细设计要做，各需要产出文档，现在咱们做个系分全部搞定，有的系分细致的就是一份概要+详设，而有的系分大概只是一个需求分析，但无论这个系分做成啥样，概要设计和详细设计的事情在实际开发工作中还是要做的，如果不做就直接进入编码，可以想象会出现质量和进度问题。

而做过程改进，则是作为项目的一员能够明白哪些流程对当前项目是必须，哪些是可以裁剪的，这些通常是对不同的人员、业务要求、进度要求采用不同的策略。如团队内都是刚刚入职不久开发、测试同学，对流程没有啥感觉，那就别谈啥流程裁剪或者喊可运行的软件胜过面面俱到的文档的口号，不妨就采用最严格的流程，能做的都做，该写的文档就写，避免遗漏，也便于新人学习和理解流程的重要性。而对质量意识较好的团队，对有明显进度压力的项目，过程目标则应该是找到一个比较合适的互相配合的方式，比如大家觉得串讲比写详设文档更容易沟通，或者测试用例比需求文档更容易理解，均可这样操作。

过程改进是一个渐进的过程，不是一蹴而就的，需要多次的研发项目过程后，根据对研发过程的度量来找优化的点（这里又会引入研发度量，这又是QA领域的东东，不展开了）。比如我们在某次产品开发完成之后度量研发过程中的生产率，质量，各种成本和产出，发现在模块联调的时候消耗的工作量比较大，而且产生的缺陷也比较多，那么我们下一次研发过程中可以对这个点做一些事情，如提前联调或者放宽联调时间等。

实践，实际上对研发团队来说应该是一件有意思的事情，曾经研发人员就是一个形象，头发乱糟糟，沉闷的坐在小格子里，戴着眼镜玩命的敲键盘，做事方式也是大家都文档、邮件发过来发过去。最初玩敏捷的那帮老外做出那些实践估计只是想让研发过程更有趣一些，让过程更高效一些，比如把每天写的代码持续集成一下，在一个大看板上展示出来，让大家都能看到自己的工作成果，自己鼓励下自己，影响持续集成成功的戴个帽子做个小惩罚，多有意思；每天搞个站立会议，贴几个小便签，把不善于沟通的程序猿都拉出来说说话；TDD，谁不得做测试，有能力的人在前面做显得更高档一点，又能搞一个概念，何乐而不为？XP，如果咱觉得xx是好的，咱就把它做到极致，纯概念，谁不想把事情做好呢，但是提出一个概念多高级…

站在tester/QA的角度，实践应该是可以帮助到质量的一个活动，无论以啥名义和概念提出来。因此测试同学要能够明白每个实践是解决什么问题的，在项目中最适合推行啥实践才可以帮助到团队而非弄成形式，如srum的站立会议、燃尽图、白板等等减少了沟通成本，但弄得不好反而信息更加不透明；如持续集成、TDD是期望更快的得到反馈，但会增加研发成本…需思考利弊。另外，实践改变的人的行为，而人的行为是比较难改变的，所以更应该分析出合适的实践。