一、关键字测试用例的编写

1.序号

a.简单、少数。

2.测试说明

或称测试点、检查点、测试概述、用例概述、用例说明：用一句话对测试用例进行概述
 a.可以总结测试目的；
b.可以用疑问句表示；
c.可以用“检查、验证、测试”等字眼（如验证QQ默认安装）；
d.较好看到这句话就能知道如何测试；
e.尽量少数（因果图、正交表可能会有重复的测试说明）；
f.用例执行多轮时，越往后执行可能越快，如果用例写得好，直接看概述就行。

3.初始条件（预置条件、前提条件）

a.初始条件要是一个状态，而且是静态的，如管理员已登录后台； b.初始条件是名列前茅步操作步骤之前的状态，不能太远，不用从头写到尾
c.很多项目中不写预置条件。

4.操作步骤

a.若对数据要求高，需要把数据分离出来；
b.步骤要都有序号；
c.每一步用分号分开，最后用一个句号；
d.每一步必须换行；
e.参数前加冒号（如用户名：admin）；
f.涉及按钮界面用【】、“”等成对符号间隔；
g.功能的详细用例步骤4-6步左右；
h.最后一步一定是个动作，不能写结果。

5.预期结果

a.是一个状态；
b.如果参考文档中有描述，原封不动的抄过来；如果文档中没有具体要求，则点要一致，可以有几个点，如QQ默认安装，应能启动、默认选项匹配等。

6.用例状态

a.通过、失败、阻塞、未执行、搁置、无效用例…
b.初始条件达不到时，一般用例状态设置为阻塞。
c.看如何执行用例，执行完关心什么来定。

延伸阅读：

二、用例设计方法总结

通过测试

a.主要用于验证系统和它陈述的需求一致，确认软件至少能做什么，一般通过分析需求说明书来设计测试用例。

失败测试

a.纯粹为了破坏软件而设计和执行的测试案例，也称迫使出错测试。主要用于证明“一个系统不会做不需要它做的事情” 。

随机测试

A、也称即兴测试（ad hoc testing），是指临时准备的、即兴的Bug搜索测试过程。

e.g.如果让一百万只猴子在一百万只键盘上敲一百万年，它们最终就可能写出莎士比亚话剧等巨著。

B、缺点

a.无法度量随机测试的实际覆盖率。
b.许多测试都是冗余的。
c.测试数据因为是随机的，重复测试是不可能的。

应用群集效应

a.找到的软件缺陷越多，说明那里的软件缺陷越多，若在测试中发现大量的上边界条件缺陷，则在测试时应注重上边界。
b.程序员倾向于修复报告出来的问题，要保证除此之外可能存在的其他问题不会出现。

探索性测试

a.可以说是一种测试思维技术。
b.探索性测试是一种精致的、有思想的过程。
c.探索性测试强调测试设计和测试执行的同时性。
d.测试人员通过测试来不断学习被测系统，同时把学习到的关于软件系统的更多信息通过综合的整理和分析，创造出更多关于测试的主意。
e.测试设计，测试执行，测试日志的记录似乎是无关紧要的工作。
f.测试人员必须根据测试章程在规定的时间内完成。
g.适合于：

如何选择测试方法

a.使用大纲法、场景法、因果图设计测试用例。

如果程序的功能说明中含有输入条件的组合情况，则应在一开始就选用因果图法。

b.用等价类划分方法、边界值分析方法、错误猜测法补充测试用例。

c.执行测试时进行探索性测试或随机测试。

d.执行完测试用例后进行随机测试。