测试用例组织谈#一

一直很纠结测试用例的编写，总结下来是某IT大厂的测试用例五宗罪：

1、纠结度☆☆☆☆☆，测试用例冗余，特别是电子商务网站的测试用例，和测试分析、需求文档严重重复！

加之质量管理人员以传统质量管理的观念为尚方宝剑给测试用例施加种种限制，导致测试用例写成了纪实文学，冗长，累赘，可复用程度极低。

2、纠结度☆☆☆，用例编写缺少形式化规范，表意模糊，风格多样。编写随意，理解麻烦，维护艰难。

3、纠结度☆☆☆☆，重造车轮。新项目和升级包的用例基本上都要重头编写，没有完整的用例复用机制。产品用例库形同虚设。

4、纠结度☆☆☆☆☆，不以发现缺陷未目的编写测试用例，大篇幅的测试用例用在描述“程序应该做什么事情”，重复需求文档的描述。而没有把重点放在程序不能做什么事情，怎么尽可能多的覆盖隐含需求和条件分支，怎么尽可能多的关注程序可能出现问题的地方。

5、纠结度☆☆☆，没有划分测试用例优先级，回归难度大。

针对测试用例复用难的解决办法：

1、使用用户故事管理产品需求的完整描述。重点描述来自需求方的原始需求，并说明需求背景和优先级。用户故事必须经过各方评审（需求方、产品设计、交互设计、开发、测试）并持续更新。测试用例编写时，以用户故事作为第一优先级测试用例，重点说明产品必须做什么，并定义第一优先级测试用例为产品级别回归测试用例。需要注意的是，用户故事是产品测试用例的一部分，但完成没有必要再次写入测试用例中。

2、建设和维护通用测试CHECKLIST和测试METHODLIST，CHECKLIST说明常见场景的测试关注点，如表单提交需要关注防重复提交、表单防篡改。METHODLIST用来说明通用的测试方法，如测试表单防篡改需要使用抓包工具，如TAMPER IE。针对某种产品的测试方法也可以写入METHODLIST，如去除两个账户之间的关联管理应该如何操作。

3、增量测试。对底层模块进行模块测试，保证底层基础模块的功能可靠性，减少上层功能测试的测试关注点。

4、总体思路是：由于需求多样，测试过程又太艺术，要达到测试用例像软件开发中的组件一样可复用几乎无解。所以设法抽象出现有用例中可复用部分：用户故事、CHECKLIST、METHODLIST和基础（通用）模块测试。项目的测试用例可以在最大程度上复用上述职能模块，使项目测试用例的组织更加清爽，关注点更加明确。

 

关于项目测试用例如何编写，下回再聊。