[综合]QA用例-设计原则+组成要素+版本管理

做软件质量保障的过程，贯穿于整个软件产品生命周期，这里是干货之——QA用例设计原则+组成要素+版本管理。

I、QA测试用例设计原则

QA用例设计原则可以划分为：基于需求 (具体结合了实际业务功能)、场景化(结合功能实现场景)、描述精准 (基于自己所管理的一些不同成员的范例做了详细阐释)、可判定、原子化 (包含了如何设计明晰的大纲)、可回归、独立、正交。

1.基于需求

用例是为了验证需求而设计的，也要避免过度设计。

• 从需求出发，设计能有效验证需求的测试用例
• 明确不在需求范围内的功能，不设计测试用例
• 在需求范围内的功能，不过度设计
• 一些没有明确提出、但属于共识或隐含的需求，应设计测试用例

设计用例首要原则：参考需求文档，同时考虑系统的设计和实现逻辑，全面涵盖对系统交互、异常和分支的各种情况。

【举例】

例1:

以Galaxybase的接口/api/buildGraph/defineSchema为例来说,假如需求里规定该图库的接口只允许单独调用,如果设计了并发量的测试,就属于过度设计。 就算并发量测试出了问题，也不能作为软件缺陷，因为并发调用是需求范围。

例2:

单次调用图库的api/buildGraph/loadFile这个接口,等了超过十几分钟或更长时间没响应。 这种情况,就算没有明确提出关于接口超时设置的需求,也可以设计用例并提交缺陷,因为接口的响应表现已经远超出了正常响应的时长范围。 可作为隐含的需求进行用例设计。 当然最好的方式是需求分析和细化时,可以包含这类情况，就可以对应明确需求设计全面的用例。

2.场景化

测试用例设计尽可能贴近真实的受众或端到端的使用场景。(受众包括：终端用户、面向系统或服务的任何使用者/消费者，所谓用户可以是人、机器、系统、接口等) 比如服务端后台功能、接口、算法等的受众群体并不是终端用户,如果这些在明确的需求范围内,也需要根据其功能设计出场景化可执行的用例。

• 应全覆盖真实用户的使用场景
• 围绕场景进行更多的探索
• 以第一人称的主观视角描述用例，从客户使用的角度构建思维导图
• 按照用户使用的自然顺序设计用例

3.描述精准

1)描述测试用例的语言要尽量精准,避免歧义,避免模糊或含糊不清的描述,保证不同的人对用例都有一致的理解,以确保所有执行人员能理解并能够正确执行测试用例。

2)确保每个测试用例都有清晰明确的描述,包括:用例标题、前置条件、输入、操作步骤、预期结果(关键校验点)。

3)用例标题的描述：关注测试场景的设计和给用户带来的价值,而非某个模块功能名称、或详细的操作步骤。

4)用例操作步骤的描述：按照对该功能用户操作的自然顺序，描述条理清晰的操作步骤。

5)预期结果的描述：尽量具体、条理化、可测量,避免使用模糊的词语或术语,尽量减少误解,要校验的点应列举全面。

• 语言准确，没有歧义，尽量具体不空泛
• 描述精练，保留必要信息，去掉无关信息
• 避免大段描述，对大量信息进行分层和结构化设计

【举例】

例1-用例标题：

我们部分用例的不足:用例标题是以界面的按钮为用例名称,没有体现用例的测试出发点,不能通过用例标题描述知道该用例是为了什么测试场景和目的。

例2-用例步骤：

在以下测试用例中，把该功能模块下的不同测试场景，作为了一个测试用例下的不