测试用例设计流程优化与管理.pdfVIP

测试用例设计的完整过程

一个项目启动后，开发会根据项目的需求文档（RFP：RequestforProposal）编写开发计划（SDP：

SystemDevelopmentn）和系统需求说明书（SRS：SystemRequirementSpecification）;与此

同时，测试根据需求文档，SDP和SRS来提取测试范围（或者测试需求），思考可能使用到

的测试方法和测试工具，测试环境等，这些都会编写在测试计划文档里（STP：SystemTest

n至于测试计划包括的具体内容我们下篇讲）。

根据RFP，SDP，SRS，STP就去详细地写一条一条的测试用例可能并不实际，因为项目初期

RFP这些文档就是粗略型的大纲文章。当然需求越早确定越好，并尽量避免后期的频繁改动。然

而实际项目中你会发现需求在早期就确定下来是一件多么的事情。为了梳理当前测试需

求，并指导后期测试用例编写，在测试用例编写之前需要输出一份测试需求文档或者叫做测

试设计文档（STD：SystemTestDesign，文章最后会附STD具体包含的内容）。文档编写形式

多样，里面可以用思维导图（Xmind，FreeMind）列出每个正常测试点，异常测试点等等，整

理出测试思路。更重要的是从这份文档里测试人员能够有个清楚的测试思路，并找出自己为

了达到测试目的，自己需要做哪些准备。

STD顺利完成，再转换成STC就很容易，且不容易遗漏。STC不是一蹴而成的，它

是个持久性活动。一轮测试后，探索测试，交叉测试使得测试人员又有新的测试思路，都可

以作为补充STC的。

测试用例设计出来以后是需要评审的，评审人员主要有需求方，设计人员，开发人员，其他

测试人员，以及开发主管和测试主管。最后将评审结果记录在文档里或者记录在管理文档的

系统里，比如CC或者管理工具RedMine，以便后期查看和。

做好测试用例的关键

1.多和开发沟通，在项目前期就达到次理解和分析需求，最后经过STD将这份理解分析

转化成后期可执行的测试用例。

2.多和开发沟通，控制需求变更对测试用例的影响。

测试用例编写规范（更新于12.22）

用例编写规范目的

1.统一测试用例编写的规范，为测试设计人员测试用例编写的指导，提高编写的测

试用例的可读性，可执行性、合理性。

2.测试用例，不仅仅用于QA阅读和执行。它们也可能会被开发、PD、PM等阅读

或执行；也更可能被其他测试人员或者新员工作为业务学习、测试执行的参照。

3.编写测试用例的最终目标是：一个对于产品毫无所知的人员，也能够快速的熟悉用例

并执行用例。

例模块划分规范

要求：

1.产品、功能点同一层级的结构按同一个纬度来划分。如应用、同等级产品、同等级功

能点等；

2.产品是指产品线下大的业务模块。如购物车、下单；

3.功能点指业务模块下的子功能点，是最小功能点叶子节点。如01功能_02购物车展

示_01顶部及导航；

4.功能点目前无法再细分层级，后续会扩展功能点层次，在此之前，允许使用功能点名

进行分层用例划分。如06边境仓_03发货单管理_02创建发货单；

5.产品、功能点划分不允许包含冒烟、回归、自动化这类以测试阶段或测试方法名

的名称；

Thecompleteprocessoftestcasedesign

Afteraprojectisstarted,developmentwillwriteadevelopmentn(SDP:SystemDevelopmentn)

andasystemrequirementspecification(SRS:SystemRequirementSpecification)basedontheprojects

requirement