测试人员需把握好项目中的3个关键点

需求阶段

　　淘宝项目的特性，将我再次局限在了“有限的时间当中”，时间与质量虽不是正比关系，但在有限的时间中若未规划好任务和有效利用时间，质量就绝对是牺牲品。如何在有限的时间内，最大限度的保障项目的质量，这是下面要探讨的。

　　我认为，在项目中，测试人员需把握3个关键点：PRD评审环节、UC评审环节、测试执行中的提BUG环节，来循序渐进的节约过程时间。

　　首先谈谈PRD评审环节。这个环节是测试人员对项目内容的最初接触，我们能在这个节点看到项目实现的雏形，大致了解项目需要做什么。但对需求的了解和理解并非我们在这个环节的工作全部，我们还需要做两大部分工作：

　　一、对PRD中的功能点往细里去挖掘，这里的“细”，是功能维度的“细”，而非实现上的“细”，这项工作的目的是在前期挖掘出需求中可能导致开发出现理解偏差的地方，消灭含糊，早早的将矛盾推出台面，将可能出现在UC环节的BUG扼杀在摇篮中，而非等到引入UC后才发现和修改，这从BUG放大率来看，在一定程度上节约了项目时间；

　　二、把自己当作客户，提出建设性意见，该点的意义在于弥补PD的考虑不充分，把未来各环节中的需求变更可能性减到最低。

　　再来看UC评审环节，UC是我们测试人员的直接的需求，在这个环节中，主要目的是分析需求、消化需求和发现BUG。很多同学在这个环节发现的BUG仅限于挑出UC与PRD中的出入、UC书写规范问题和一些细节校验点的含糊问题，而未考虑到还有一点很重要：设计的完善性。

　　为什么会出现这种结果？为什么这种问题往往到测试设计或用例编写时、甚至测试执行阶段才暴露出来？最主要的原因，是在UC评审时，思考逻辑被UC设计牵着走了。那如何摆脱这无形的牵引呢？我的做法是在UC评审阶段对UC有了大致了解后，就开始在头脑中以我作为测试者的身份来构思测试设计，并动手来写写画画业务流程图，功能划分图，甚至系统交互图等等，请记住，一定要动手，光靠脑袋想，想了也白想。最后再用自己的设计与UC进行对比、分析。

　　这种做法有两个好处：一是从测试角度找出UC设计的缺陷，将有原本会在测试设计或执行中才发现的问题暴露在了当下，从而不把设计性问题带入开发人员的代码中，修改代码的代价远远大于修改文档；二是为接下来的测试设计阶段节约了时间，由于设计的轮廓已于胸中，到真正的设计时只需将其丰满、充实，而无需从头开始边看UC边构思。

　　执行阶段

　　最后一个关键环节便是提BUG环节。提BUG是一门艺术，如何提出优质BUG，如何保证提BUG的同时又能保证执行效率。前一个问题咱部门已产出了很好的答案，我这里就不重复了，只把握一点：按答案去做吧，保证会节约你执行过程中的沟通时间。关于第二点， 相信太多的同学都有体会，执行100个用例发现0个BUG和执行100个用例发现10个BUG的时间是不一样的。前者只有执行用例时间，后者除了执行用例时间、还包含了发现BUG重现规律的时间、查找BUG原因的时间和在QC中提BUG的时间。如果我们能把这几个围绕BUG的效率提高，那么我们执行的整体效率也就提高了。那如何做呢？我并未找到一个很完美的方法，这里就分享下我自己的方法：

　　1、对于节约发现BUG重现规律时间的方法：我对自己操作过的每一个步骤均紧记于心，将可重现步骤与未重现步骤作对比，找出不同之处，再针对不同处构造数据，再做测试，来确定其规律，一旦确认，立即对相关用例进行补充，在下一轮测试时就能享受到成果了。

　　2、对于节约查找BUG原因时间的方法：这个无捷径，主要在于积累，可多看BUG库中的历史BUG和本项目中的已有BUG，重点关注BUG的定位及注释，以海量而达到可复用或融会贯通的目的。

　　3、对于节约在QC中提BUG时间的方法：我不太赞同发现一个BUG提一次的方式，这样的效率是低下的，既打断了测试执行的流畅率，又在QC中来回切换，着实浪费时间。我的建议是以时间和发现BUG频率构成一个二维度，若BUG发现频率低则按一定的时间提一次，若BUG发现频率高则按一定的BUG数提一次。发现BUG的当下可先将BUG截图、贴链接、大概描述等工作先做好，待提BUG时只需上传就行了。但需要记住一点，多BUG一并提的间隔不能太大，否则有可能耽误开发同学的修复进度，故可根据不同项目执行情况再具体分析提BUG的间隔粒度。

　　成功往往是留给那些平时有准备的人，质量也是如此哦！把握好过程，就算被时间局限，也能让项目掌握在我们的股掌之间。