测试用例中用例标题前置条件怎么写

测试用例中用例标题的写法：1、功能点；2、功能-流程；3、某种状态或条件-结果。测试用例中前置条件的写法：1、确认测试点；2、列出步骤和预期；3、留下证明性的关键性步骤和预期。功能点是指能够单独完成的某个具体业务流程。

一、测试用例中用例标题的写法

1、功能点

功能点是指能够单独完成的某个具体业务流程。要根据需求说明书或者原型图提取功能点，功能点是和需求点相对应的。例如：网络正常时点击购买按钮弹出支付弹框。

2、功能-流程

功能-流程是指从功能点出发完成一个需求流程的过程。例如：会员购买页面-成功购买流程。

3、某种状态或条件-结果

某种状态或条件-结果是指在不同状态下得到的运行结果是不一样的。例如：无网状态-点击购买-提示无网。

二、测试用例中前置条件的写法

1、确认测试点

测试用例中使用的所有测试点，应该在测试用例执行前被确认。

2、列出步骤和预期

列出所有需要达到这个测试点的步骤和预期。

3、留下证明性的关键性步骤和预期

然后仅留下证明此条测试点的关键性步骤和预期。

三、写测试用例的好处

1、理清思路，避免遗漏

这里是我们认为最重要的一点，假如我们测试的项目大而复杂，我们可以把项目功能细分，根据每一个功能通过编写用例的方式来整理我们测试系统的思路，避免遗漏掉要测试的功能点。

2、跟踪测试进展

通过编写测试用例，执行测试用例，我们可以很清楚的知道我们的测试进度。

3、历史参考

在我们所做的项目中，也许会有很多功能是相同或相近的，我们对这类功能设计了测试用例，便于以后我们遇到类似功能的时候可以做参考依据。

4、重复性

我们测试一个系统不是一个人测一遍就算测完的，需要多人反复的进行测试，那么我们就需要测试用例来规范和指导我们的测试行为。

四、测试用例的编写方法

1、等价类划分

在某个输入域的子集合，在该子集合中，各个输入数据对于揭露程序中的错误都是等价的。假如有一个输入框要求输入1-10000个数，我们不可能用每一个数去试，我们输入5 和输入6去验证和揭露输入框的错误可以看做是等价的。那么这个时候我们就可以随机的抽取一些数据来进行验证。如：10 、99、7777。

• 等价类分：有效等价类和无效等价类，输入框要求输入1-10000的数。
• 有效等价类：可以输入1-10000之间的数来验证，如：2、5、99、8495。
• 无效等价类：可以输入1-10000之外的任意字符验证，如：20000、字母、下划线、特殊符号、空格、回车。

2、边界值

有效数据和无效数据的分界点，往往作为程序员编写程序的判断点，是程序员容易犯错的地方，也是测试人员重点测试的内容。我们把这些分界点的值找到，并进行测试的方法，称为边界值法。边界值是对等价类的补充，测试工作经验告诉我们，大量的错误是出在输入输出的边界价上。我们还拿上面的例子，一个输入框要求输入1-10000之间的数。我们要测它有没有超出这个范围，如：0、-1、-2、1000、10001…..等等，来判定是否超出了我们的范围。边界值数据本质上属于等价类数据的范畴，但是在测试的时候应该单独考虑，这种情况其实是一种冗余，但是这种冗余在工程中是必须的。

3、因果图

因果图方法最终生成的就是判定表，它适合于检查程序输入条件的各种组合情况。举个例子：原因：A=0，B=0，结果我就可以判定：A=B。确切的说他是一种因果关系思想。它会无形中指导这我们的测试。当然了，我们为了以免遗漏，可以把系统中的因果关系用图画出。不过系统大而复杂的话就是个体力活了。

4、错误猜测法

基于经验和直觉推测出系统可能存在的错误，从而有针对性的设计测试用例的方法。错误猜测主要是一项依赖直觉的非正规的工程方法，其基本思想是列举程序可能出现的错误或者容易产生错误的测试点，然后根据测试点来编写测试用例。另一个思想是，在阅读规格说明时联想开发可能做的假设来确定测试用例，比如规格说明中的可能被忽略的内容。

错误猜测法并非是一项有章可循的工程设计方法，而是很大程度上依赖于测试人员的经验、能力以及态度。从个人测试经验角度来看，在考虑使用错误猜测法补充测试用例时，可以从如下维度考虑：

• 极限值设计：考虑数值最大、最小、为空、为0等情况。
• 特殊取值设计：年、月、日情况，必须考虑平年、闰年，2月，每月包含28天、29天、31天等情况。同时考虑跨年、跨月等情况。
• 特殊组网考虑：测试场景的考虑必须考虑版本使用局点的组网情况，特别是一些特殊的组网，比如网元主备、容灾等。曾经出现过某token使用未考虑同步到备机，导致业务出现故障后切换备机，业务运行失败的问题。
• 端到端用例考虑：通常测试用例都是以特性为维度进行设计，或者测试人员在用例执行时都是分功能进行测试用例设计和执行，并未进行端到端测试用例设计。而端到端的测试用例更容易发现问题。以充值转账功能为例。端到端的用例场景包括：用户开户（用户模型）->用户转账（不同用户层级间，所有的转账接口转账） -> 用户充值（预付费、后付费，所有的充值接口） -> 交易记录查询（所有的查询接口）。当然，如果有必要。这里还需要考虑用户的类型、交易渠道等。
• 性能角度考虑：测试场景补充设计时必须要考虑性能情况，特别是未针对核心特性进行性能场景验证的情况。最经常出现的性能问题是报表查询（功能测试时未考虑交易记录数），包括充值交易记录查询、转账记录查询等涉及大业务量数据的测试。类似的功能包括报表测试或者核心交易逻辑的测试。业务数据量（交易记录数）一定需要与现网数据量保持一致。
• 安全角度考虑：是否考虑不同用户权限功能使用情况、日志中是否有明文显示用户隐私信息、用户登录是否安全校验机制（如密码连续3次输入错误锁账户、验证码）、是否允许越权、前后台校验是否一致等等。

5、其它

设计测试用例的方法有很多，我们常用就上面几种，其它的方法还有：状态迁移图、流程分析法、正交验证法等等。

延伸阅读

测试用例中预期结果的编写要求

• 同测试步骤一样，预期的测试点也要围绕着测试标题或此条用例的测试点描述。
• 尽量不要有多余的检查点，更不要遗漏测试点
• 预期结果中不能含有测试步骤（分清预期和步骤这很重要）
• 每条用例都需要有至少一个预期结果
• 检查点不仅仅只是界面上的表现，也可以是数据库的数据、保存下来的文件、或是其他可以验证测试点的表现。