教你如何写测试用例

测试用例的主要来源有：
1） 需求说明”及相关文档
2）相关的设计说明（概要设计，详细设计等）
3）与开发组交流对需求理解的记录（可以是开发人员的一个解释）
4）已经基本成型的UI（可以有针对性地补充一些用例）
简而言之，所有你能得到的项目文档，都尽量拿到。
从所得到的资料中，分解出若干小的“功能点”，理解“功能点”，编写相应的测试用例。
1.2用例的组织方式
不同的公司有不同的做法，原则上，只要方便管理和跟踪，怎么组织都可以的。
用例可以按大的功能块组织，如查询功能模块的用例，可以组织在一起，打印模块的测试用例，可以另外组织在一起。在没有专门的测试用例管理工具的情况下，用例执行后会产生2种状态：“通过”、“失败”——这样加上“未执行”的用例的状态，共3种状态。即从“未执行”用例中执行一个用例后，该用例状态应为“失败”或“通过”。将同一状态的用例组织在一起。至于用例文件格式，可以是.DOC或.XLS（如果有专门的测试用例管理工具另当别论）。
1.3用例与其他材料的关联方式
测试用例面临的比较大的风险有：需求的变更、设计的修改、需求的错误和遗漏等等。
由于用例的主要来源是需求和设计的说明，所以对用例的跟踪其实就是对需求和设计的跟踪，需求和设计的变更势必引起测试用例的变更。如前所说，将分解的功能点编号，与相应的用例联系起来。例如，你可以列一个表格，列出各个（编号的）功能点和测试用例间的关联关系。这样，当需求和设计发生变化时，你只需要跟踪“功能点”是否变化，是否增加了新的功能点。
重要和困难的是，不手头的资料和信息一定要是最新的。
1.4用例应包含的信息
一个优秀的测试用例，应该包含以下信息：
1） 软件或项目的名称
2） 软件或项目的版本（内部版本号）
3） 功能模块名
4） 测试用例的简单描述，即该用例执行的目的或方法
5） 测试用例的参考信息（便于跟踪和参考）
6） 本测试用例与其他测试用例间的依赖关系
7） 本用例的前置条件，即执行本用例必须要满足的条件，如对数据库的访问权限
8） 用例的编号（ID），如可以是 软件名称简写-功能块简写-NO.。
9） 步骤号、操作步骤描述、测试数据描述
10）预期结果（这是最重要的）和实际结果（如果有BUG管理工具，这条可以省略）
11）开发人员（必须有）和测试人员（可有可无）
12）测试执行日期
2、测试用例模板和例子
该范例已经包含一个测试用例的模板。
项目/软件 技术出口合同网络申领系统 （企业端） 程序版本 1.0.25     
功能模块名 Login  编制人 　 xxx     
用例编号- TC-TEP_Login_1  编制时间 　 2002.10.12     
相关的用例 无         
功能特性 用户身份验证         
测试目的 验证是否输入合法的信息，允许合法登陆，阻止非法登陆         
预置条件 无  特殊规程说明  如数据库访问权限     
参考信息 需求说明中关于“登陆”的说明         
测试数据 用户名=yiyh 密码=1
操作步骤 操作描述  数 据 期望结果 实际结果 实际结果  测试状态（P/F）
1  输入用户名称，按“登陆”按钮。  用户名=yiyh，密码为空  显示警告信息“请输入用户名和密码！”     
2  输入密码，按“登陆”按钮。  用户名为空，密码=1 显示警告信息“请输入用户名和密码！”     
3 输入用户名和密码，按“登陆”按钮。 用户名=yiyh，密码=2 显示警告信息“请输入用户名和密码！”     
4 输入用户名和密码，按“登陆”按钮。 用户名=xxx，密码=1 显示警告信息“请输入用户名和密码！”     
5 输入用户名和密码，按“登陆”按钮。 用户名=xxx，密码=2 显示警告信息“请输入用户名和密码！”     
6 输入用户名和密码，按“登陆”按钮。 用户名=空，密码=空 显示警告信息“请输入用户名和密码！”     
7 输入用户名和密码，按“登陆”按钮。 用户名=yiyh，密码=1 进入系统页面。     
8 输入用户名和密码，按“登陆”按钮。 用户名=Admin，密码=admin 进入系统维护页面。     
9 输入用户名和密码，按“登陆”按钮。 用户名=yiyh'',密码=1 显示警告信息“请输入用户名和密码！”     
10 输入用户名和密码，按“登陆”按钮。 用户名=yiyh，密码=1'' 显示警告信息“请输入用户名和密码！”     
11 输入用户名和密码，按“重置”按钮。 用户名=yiyh，密码=1 清空输入信息     
测试人员    开发人员     项目负责人 
3、测试用例设计的误区
1、能发现到目前为止没有发现的缺陷的用例是好的用例：
首先要申明，其实这句话是十分有道理的，但我发现很多人都曲解了这句话的原意，一心要设计出发现“难于发现的缺陷”而陷入盲目的片面中去，忘记了测试的目的所在，这是十分可怕的。我倾向于将测试用例当作一个集合来认识，对它的评价也只能对测试用例的集合来进行，测试本身是一种“V&V”的活动，测试需要保证以下两点：
 程序做了它应该做的事情
 程序没有做它不该做的事情
因此，作为测试实施依据的测试用例，必须要能完整覆盖测试需求，而不应该针对单个的测试用例去评判好坏。

2、测试用例应该详细记录所有的操作信息，使一个没有接触过系统的人员也能进行测试；
不知道国内有没有公司真正做到这点，或者说，不知道有国内没有公司能够将每个测试用例都写得如此详细。在我的测试经历中，对测试用例描述的详细和复杂程度也曾有过很多的彷徨。写得太简单吧，除了自己没人能够执行，写得太详细吧，消耗在测试用例维护（别忘了，测试用例是动态的，一旦测试环境、需求、设计、实现发生了变化，测试用例都需要相应发生变化）上的时间实在是太惊人，在目前国内大部分软件公司的测试资源都不足的情况下，恐怕很难实现。但我偏偏就能遇到一些这样的老总或者是项目负责人，甚至是测试工程师本身，全然不顾实际的资源情况，一定要写出“没有接触过系统的人员也能进行测试”的用例。
在讨论这个问题之前，我们可以先考虑一下测试的目的。测试的目的是尽可能发现程序中存在的缺陷，测试活动本身也可以被看作是一个Project，也需要在给定的资源条件下尽可能达成目标，根据我个人的经验，大部分的国内软件公司在测试方面配备的资源都是不足够的，因此我们必须在测试计划阶段明确测试的目标，一切围绕测试的目标进行。
除了资源上的约束外，测试用例的详细程度也需要根据需要确定。如果测试用例的执行者、测试用例设计者、测试活动相关人对系统了解都很深刻，那测试用例就没有必要太详细了，文档的作用本来就在于沟通，只要能达到沟通的目的就OK。
在我担任测试经理的项目中，在测试计划阶段，一般给予测试设计30% - 40%左右的时间，测试设计工程师能够根据项目的需要自行确定用例的详细程度，在测试用例的评审阶段由参与评审的相关人对其把关。

3、测试用例设计是一劳永逸的事情；
这句话摆在这里，我想没有一个人会认可，但在实际情况中，却经常能发现这种想法的影子。我曾经参与过一个项目，软件需求和设计已经变更了多次，但测试用例却没有任何修改。导致的直接结果是新加入的测试工程师在执行测试用例时不知所措，间接的后果是测试用例成了废纸一堆，开发人员在多次被无效的缺陷报告打扰后，对测试人员不屑一顾。
这个例子可能有些极端，但测试用例与需求和设计不同步的情况在实际开发过程中确是屡见不鲜的，测试用例文档是“活的”文档，这一点应该被测试工程师牢记。

4、测试用例不应该包含实际的数据；
测试用例是“一组输入、执行条件、预期结果”、毫无疑问地应该包括清晰的输入数据和预期输出，没有测试数据的用例最多只具有指导性的意义，不具有可执行性。当然，测试用例中包含输入数据会带来维护、与测试环境同步之类的问题，关于这一点，《Effective Software Test》一书中提供了详细的测试用例、测试数据的维护方法，可以参考。

5、测试用例中不需要明显的验证手段；
我见过很多测试工程师编写的测试用例中，“预期输出”仅描述为程序的可见行为，其实，“预期结果”的含义并不只是程序的可见行为。例如，对一个订货系统，输入订货数据，点击“确定”按钮后，系统提示“订货成功”，这样是不是一个完整的用例呢？是不是系统输出的“订货成功”就应该作为我们唯一的验证手段呢？显然不是。订货是否成功还需要查看相应的数据记录是否更新，因此，在这样的一个用例中，还应该包含对测试结果的显式的验证手段：在数据库中执行查询语句进行查询，看查询结果是否与预期的一致。
4、测试用例在软件测试中的作用
    1、指导测试的实施
    测试用例主要适用于集成测试、系统测试和回归测试。在实施测试时测试用例作为测试的标准，测试人员一定要按照测试用例严格按用例项目和测试步骤逐一实施测试。并对测试情况记录在测试用例管理软件中，以便自动生成测试结果文档。
    根据测试用例的测试等级，集成测试应测试那些用例，系统测试和回归测试又该测试那些用例，在设计测试用例时都已作明确规定，实施测试时测试人员不能随意作变动。
    2、规划测试数据的准备
在我们的实践中测试数据是与测试用例分离的。按照测试用例配套准备一组或若干组测试原始数据，以及标准测试结果。尤其象测试报表之类数据集的正确性，按照测试用例规划准备测试数据是十分必须的。
除正常数据之外，还必须根据测试用例设计大量边缘数据和错误数据。
    3、编写测试脚本的"设计规格说明书"
    为提高测试效率，软件测试已大力发展自动测试。自动测试的中心任务是编写测试脚本。如果说软件工程中软件编程必须有设计规格说明书，那么测试脚本的设计规格说明书就是测试用例。
    4、评估测试结果的度量基准
    完成测试实施后需要对测试结果进行评估，并且编制测试报告。判断软件测试是否完成、衡量测试质量需要一些量化的结果。例：测试覆盖率是多少、测试合格率是多少、重要测试合格率是多少，等等。以前统计基准是软件模块或功能点，显得过于粗糙。采用测试用例作度量基准更加准确、有效。
    5、分析缺陷的标准
    通过收集缺陷，对比测试用例和缺陷数据库，分析确证是漏测还是缺陷复现。漏测反映了测试用例的不完善，应立即补充相应测试用例，最终达到逐步完善软件质量。而已有相应测试用例，则反映实施测试或变更处理存在问题。
5、试用例编号规则
目的：好的测试用例编号，可以更好的去了解此项用例所针对的模块，也有助于记忆和新用例的增加。
规则：测试用例编号采用“版本+细类+编号”的形式。
备注：其中“版本”为设计此测试用例的软件版本。
“细类”为小模块中的汉字头一个字母，以最多5个字母为标准。
“编号”为BUG用例的编号，以4位为标准，依次递增。
例如：引导系统V2.01版本中，候车点设置，用例编号可以书写为：
          2.01_HCDSZ_0001