《如何编写有效测试用例(word)》由会员分享，可在线阅读，更多相关《如何编写有效测试用例(word)（10页珍藏版）》请在金锄头文库上搜索。
1、由安博测试空间技术中心 http:/ 测试用例的设计应包括各种类型的测试用例。在设计测试用例的时候，除了满足系统基本功能需求外，还应该考虑各种异常情况、边界情况和承受压力的能力等。4、 测试用例的管理。使用测试用例管理系统对测试用例进行管理。一个好的测试用例应该具有较高的发现某个尚未发现的错误的可能性，而一个成功的测试案例能够发现某个尚未发现的错误，通常一个好的测试案例有以下特性：1、 具有高的发现错误的概率2、 没有冗余测试和冗余的步骤3、 测试是“最佳类别”4、 既不太简单也不太复杂5、 案例是可重用和易于跟踪的.6、 确保系统能够满足功能需求测试用例不可能设计得天衣无缝，也不可能完全满足
2、软件需求的覆盖率，测试执行过程里肯定会发现有些测试路径或数据在用例里没有体现，那么事后该将其补充到用例库里，以方便他人和后续版本的测试。二、如何编写测试用例测试用例的信息有很多，可以根据实际的情况进行增删，一般来说一个优秀的测试用例应该包含以下信息：1、产品相关信息（1） 软件产品或项目的名称（2） 软件产品或项目的版本（3） 功能模块名（4） 功能描述（5） 测试平台这些信息建议可以在测试案例手工选择。2、基本记录信息（1） 测试用例入库者（2） 测试用例入库时间（3） 测试用例更新者（4） 测试用例更新时间这些信息建议可以由测试案例自动生成。3、测试用例的属性（1） 测试用例 ID：测试用
3、例的 ID（由案例管理系统自动生成，方便跟踪管理）（2） 测试用例名称：测试用例的名称（3） 测试功能点：测试的功能检查点（4） 测试目的：该测试功能点的测试目的（5） 测试级别：主路径测试、烟雾测试、基本功能测试、详细功能测试。 下面对这几个测试级别进行说明： A、 主路径测试：对照需求中重要模块和功能的最主要功能路径，主路径测试为设计探针模块，快速检查程序的可测试性（可测试性还包括安装测试是否成功）的主要依据的测试案例B、 烟雾测试：对照需求中所有模块的主要功能路径，主路径测试案例为烟雾测试案例的子集，烟雾测试为做回归测试的主要依据的测试案例。C、 基本功能测试：对照需求和总体设计中所有模
4、块和功能的基本功能路径，基本功能测试为测试软件产品的非重要级别模块，书写完全的自动测试脚本的主要依据。D、 详细功能测试：对照总体设计中所有模块和功能的功能路径，测试各个模块及功能各个层次，各种类型。详细功能测试案例为对重点模块，易发生错误的模块的主要依据。（6） 测试类型：功能测试、边界测试、异常测试、性能测试、压力测试、兼容测试、安全测试、恢复测试、安装测试、界面测试、启动/停止测试、文档测试、配置测试、可靠性测试、易用性测试、多语言测试。（7） 预置条件：对测试的特殊条件或配置进行说明（8） 测试步骤：详细描述测试过程，案例的操作步骤建议少于 15 个。（9） 预期结果：预期的测试结果例
5、如：假设目前测试中国移动互联短信网关是否能正确发送短信给中国联通互联网关，测试用例的设计如下：（1） 测试用例 ID：TC000001（2） 测试用例名称：中国移动全球通手机用户成功发送短信给中国联通手机用户（3） 测试功能点：中国移动全球通手机用户成功短信给中国联通手机用户，中国联通网关返回成功的状态报告（4） 测试目的：A、 中国移动互联短信网关能否正确处理全球通用户发送给中国联通用户的短信；B、 中国移动互联短信网关能否正确处理中国联通互联短信网关返回成功的状态报告的情况。（5） 测试级别：基本功能测试（6） 测试类型：功能测试（7） 预置条件：各网关实体按照组网图中的关系连接好，各实体
6、之间的连接和通信正常。（8） 测试步骤：A、 中国移动全球通手机用户（ 13901000001）给中国联通手机用户（13001000001 ）发送 MO短信，内容为“测试” ，目的号码填为中国联通手机号码；B、 中国联通互联短信网关把短信下发给中国联通用户成功后，给中国移动互联短信网关返回一个标识成功的状态报告。（9） 预期结果：A、 中国联通手机用户（ 13001000001）接收到了短信，内容为“测试” ，源号码为中国移动全球通的用户号码（13901000001）；B、 在中国移动互联短信网关上产生 SMO 话单，其中“短消息发送状态” 填 0（表示成功），“ 源手机号码”为 130010
7、00001，“目的手机号码”为 13001000001。三、测试案例的模版下面是一个完整的测试用例的模版：测试用例 ID TC000002测试用例名称 非法用户登录管理网页产品名称 互联互通网关 产品版本 V3.3.2功能模块名 管理网页 测试平台 所有用例入库者 smilings 用例更新者 smilings用例入库时间 2006-5-30 用例更新时间 2006-5-30测试功能点 输入错误的用户名和密码测试目的 阻止非法用户登录系统测试级别 详细功能测试测试类型 功能测试预置条件 登录用户名和密码为 admin/test测试步骤 1、输入用户名称为 admin，密码为 test%2、按“
8、登录”按扭登录管理页面预期结果 1、系统拒绝该用户登录2、提示错误信息：“对不起，您的用户密码不正确，请重新确认再登录！”三、测试用例设计过程对一个全新的产品来说，首先需要了解的是产品需求文档和产品模块之间的关系。然后需要从需求文档中书写与所有需求相对应的主路径测试案例和烟雾测试案例，这个时候也同时会包括一定的基本路径测试案例甚至是详细测试案例。在这个时候，因为对产品没有直接的使用感受，书写测试案例要考虑面广而不要太过精细。继续阅读产品功能定义文档，将所有的功能定义直接对应写相关的测试案例，这个时候，最好能够对程序的本身有一定的接触，加深对程序的了解，以便写出更好，更全面的测试案例。最后，在实
9、际测试中，还需要不断扩充，修改以前的测试案例，得到完整的基本功能测试案例和详细测试案例。如果对于一个已有一定或大部分案例的产品来说，不管测试者是否本身熟悉这个产品，其主要的任务就是阅读，检查需求及相关的变更，然后对原有的案例进行理解，扩充和修改。这就是案例的重用/复用。设计测试案例的时候，需要有清晰的测试思路，对要测试什么，按照什么顺序测试，覆盖哪些需求做到心中有数。测试用例编写者不仅要掌握软件测试的技术和流程，而且要对被测软件的设计、功能规格说明、用户试用场景以及程序/模块的结构都有比较透彻的理解。测试用例设计一般包括以下几个步骤：1、测试需求分析从软件需求文档中，找出待测试软件/模块的需求
10、，通过自己的分析、理解，整理成为测试需求，清楚被测试对象具有哪些功能。测试需求的特点是：包含软件需求，具有可测试性。测试需求应该在软件需求基础上进行归纳、分类或细分，方便测试用例设计。测试用例中的测试集与测试需求的关系是多对一的关系，即一个或多个测试用例集对应一个测试需求。2、业务流程分析软件测试，不单纯是基于功能的黑盒测试，还需要对软件的内部处理逻辑进行测试。为了不遗漏测试点，需要清楚的了解软件产品的业务流程。建议在做复杂的测试用例设计前，先画出软件的业务流程。如果设计文档中已经有业务流程设计，可以从测试角度对现有流程进行补充。如果无法从设计中得到业务流程，测试工程师应通过阅读设计文档，与开
11、发人员交流，最终画出业务流程图。业务流程图可以帮助理解软件的处理逻辑和数据流向，从而指导测试用例的设计。从业务流程上，应得到以下信息：A、 主流程是什么B、 条件备选流程是什么C、 数据流向是什么D、 关键的判断条件是什么3、测试用例设计完成了测试需求分析和软件流程分析后，开始着手设计测试用例。测试用例设计的类型包括功能测试，边界测试，异常测试，性能测试，压力测试等。在用例设计中，除了功能测试用例外，应尽量考虑边界、异常、性能的情况，以便发现更多的隐藏问题。黑盒测试的测试用例设计方法有：等价类划分、边界值划分、因果图分析和错误猜测，白盒测试的测试用例设计方法有：语句覆盖、判定覆盖、条件覆盖、判
12、定/条件覆盖、多重条件覆盖。在这里主要讨论黑盒测试。在设计测试用例的时候可以使用软件测试用例设计方法，结合前面的需求分析和软件流程分析进行设计：功能测试：测试某个功能是否满足需求的定义，功能是否正确，完备。适合的技术：由业务需求和设计说明导出的功能测试、等价类划分边界测试：对某个功能的边界情况进行测试。适合的技术：边界值划分异常测试：对某些功能来说，其边界情况无法简单的了解或某些操作不完全是正确的但又是可能发生的，类似这样的情况需要书写相关的异常测试。适合的技术：由业务需求和设计说明导出的特殊业务流程、错误猜测法、边界值分析、内部边界值测试、性能测试：检查系统是否满足在需求中所规定达到的性能，
13、性能主要包括了解程序的内外部性能因素。内部性能因素包括测试环境的配置，系统资源使用状况；外部因素包括响应时间，吞吐量等。适合的技术：业务需求和设计说明导出的测试压力测试：压力测试又称强度测试，主要是检查系统运行环境在极限情况下软件运行的能力，比如说给一个相当大的负荷或网络流量给应用软件兼容测试：测试软件产品在不同的平台，不同的工具，相同工具的不同版本下功能的兼容性。4、测试用例评审测试用例设计完成后，为了确认测试过程和方法是否正确，是否有遗漏的测试点，需要进行测试用例的评审。测试用例评审一般是由测试 leader 安排，参加的人员包括：测试用例设计者、测试 leader、项目经理、开发工程师、
14、其它相关开发测试工程师。测试用例评审完毕，测试工程师根据评审结果，对测试用例进行修改，并记录修改日志。5、测试用例更新完善测试用例编写完成之后需要不断完善，软件产品新增功能或更新需求后，测试用例必须配套修改更新；在测试过程中发现设计测试用例时考虑不周，需要对测试用例进行修改完善；在软件交付使用后客户反馈的软件缺陷，而缺陷又是因测试用例存在漏洞造成，也需要对测试用例进行完善。一般小的修改完善可在原测试用例文档上修改，但文档要有更改记录。软件的版本升级更新，测试用例一般也应随之编制升级更新版本。测试用例是“活” 的，在软件的生命周期中不断更新与完善。一、测试用例是软件测试的核心 软件测试的重要性是毋庸置疑的。但如何以最少的人力、资源投入，在最短的时间内完成测试，发现软件系统的缺陷，保证软件的优良品质，则是软件公司探索和追求的目标。每
