目录
方法-测试方法是一切的基础
人员配好之后，就该关注测试方法了。
在工作中看到过很多有趣的现象，比如很多测试岗的员工，其实并不能熟练应用测试方法，造成的后果就是漏bug，神奇的是项目经理每次问测试，得到的回答都是测完了，拿着一点办法没有，你又不能自己再测一遍，后面出现bug也不能嫩死他。有一份比较老的数据，表明“单元测试能找出10%到50%的漏洞，系统测试找出20%到60%的漏洞，剩下的40%要么通过技巧发现，要么最终被用户发现”，可见技巧是多么重要。这种水分比较高的测试，通常都无法提供有数据支持的测试覆盖率；再比如一些企业组建测试部门，先招人，再上缺陷管理工具，然后就开始搞事情，一段时间之后发现，项目质量并没有提高多少，反而进度和成本飙升，如果发生这种情况，多半是测试部门的建设跳过了从人到工具的中间几个阶段，包括方法，规范和流程，此时最好不要拖，认真分析当前到那个阶段了，再一步步做起来。
一座金字塔，下层不依赖上层，但是上层依赖下层。测试体系也是这样，没有测试人员对方法的应用作为基础，后面的规范，流程，工具都是空中楼阁。反过来，如果测试方法打得牢，规范流程工具并不是必须的，只不过到了那个阶段，团队自己就会去做规范找工具，这其实是一个自然而然的过程。
方法-等价类，边界值
纠结了很久应该怎么写这种入门级，却非常重要的测试方法。最终还是放弃了，讲具体方法的文章汗牛充栋，我希望关注在体系的阶段建设上。等价类边界值适合表单输入，常常给人带来惊喜。很多时候漏bug，是因为没有认真思考等价类和边界值，越是基础的东西，越容易大意。
方法-判定表，场景法，正交法
测试人员对方法不熟练，也体现在无法根据自己面对的情况，选择最合适的方法。碰到过很多次，对于多条件判断的情景，测试还是选择用等价类去设计，就造成他自己和别人面对一堆东西手足无措，很不清晰，执行和沟通都有很大问题。判定表在多条件的情况下是非常好的设计，沟通和表现形式。正交法适合多条件时使用。场景法适合在多事件流的情况下用。
方法-探索性测试
之前把探索性测试叫ET。项目后期的常规测试通常又累又无趣，常常一天要上QC跑200条case，而ET只用写8到10条就行了。所以每次到启动ET的时候，我跟孙银曼就赶紧承包下来，偶尔收工的时候我们会交换case看看，而我总能从他那学到一些东西。讲解ET这是一篇比较好的文章。
方法-关于case
首先，测试用例管理，是个很大的事情，投资回报率比较高，但是投资回收期却很长。跟需求工程里的需求跟踪很类似。我倾向于完善测试体系后，再回头处理case管理。
其次，在团队熟练应用测试方法的情况下，是否真的有必要写case，可能是个很有争议的问题。eStation的时候QC的用例库有几十万条case，而CMI的时候我们一条都没写过，这两段时期，质量并没有明显的差异。所以我看到的情况是写case跟产品质量并没有直接关联，最关键的问题还是在人和方法上。所以写不写case，还是看测试团队处于什么阶段，对方法掌握不熟练的时候，写case更多是在教和练，所以前面提到至关重要的第一个高级测试；测试体系后期，写case更多是在为case库做准备；其他阶段我觉得并没有太大必要写。即使要写，也尽量选择用户故事备注的方式，具体可以参考《用户故事与敏捷方法》。
最后，碰到过一些企业，对case采用审核的方式。这本身也是没问题的，有问题的关键就在审核团队，如果是测试写完case，然后拉开发，产品，项目经理一伙人审核，大部分情况都是浪费成本，测试用例的审核必须由高级测试做，这里也涉及到前面提到的至关重要的第一个高级测试。当时我们的QC有一个专门的平台管理团队，三四个人，我想他们就是干这个事的。
在这个阶段，一定不能着急，金字塔能搭多高，依赖于基础有多厚。
网友评论