功能用例编写指南v3.0.docxVIP

联友科技 功能用例编写指南 文件类别 。手册?过程文件/程序文件。指南文件/作业指导。其他 文件编号 SZLY-Q-D-VER-01 版本号 2.3.0 发布日期 2007-7-31 密 级 ?普通 O秘密 深圳联友科技有限公司 文档修订 版本 作成/修改日 期 编制/修 改人 批准 日期 批准人 描述（注明修改的条款或页） 1.1.0 2005-5-28 李荣芳 创建 2.3.0 2007-7-31 许聆 讦审后统发布 用例设计思路1 用例设计思路详解1 功能用例模板填写项说明2 模糊项填写说明3 测试项中重要级别如何区分4 6，元素检测指南5 1.文档目的 用来指导测试中心的同事编写功能用例。 适用范围 适用于联友科技综合测试中所需要编写的功能用例。 术语和定义 比较通常的测试用例（Test Case ）概念是指：指对一项特定的软件产品进 行测试任务的描述，体现测试方案、方法、技术和策略。 内容包括测试项、测试步骤、检查点、预期结果等。 角色 测试设计人员 编写测试用例，测试用例的维护（需求变更、设计变更） 测试执行人员 根据测试用例执行测试，测试用例的维护（发布测试） 测试用例检查人员 检查测试用例是否覆盖了业务需求，外设与内设的设计要求 编写指南 用例编写思路： 功能用例说明 功能用例：是一个完整的任务，是为某个特殊目标而编制的一组 测试输入、 执行条件以及预期结果的检验文档，以便测试某个程序路径或核实某个功能是否 满足设计要求，需要从用户和系统之间进行交互的接口的角度， 来观察系统外部 应该具备的表现。 功能用例站在用户的角度上（从系统的外部）来描述如何检验系统的功能。 在编写用例过程中，我们把被编写的用例看作是一个黑箱，我们并不关心系统内 部是如何通过具体的程序语句完成它所提供的功能的。 测试中心用例编写思路 事务流模式：即“事件流” + “业务流”的模式。 事件流：按照程序设计的思路，将功能中的事件（界面控件方法）对应的控 件转换提取为测试项，并按照事件的响应顺序来从上到下排列测试项。 现在的程序基本上是通过触发事件来控制流程， 触发事件的方 式和顺序就形成了事件流 最基本事件有：初始化事件、保存事件、下拉框点击事件、文本框输入等等 对应的测试项为：页面静态检查、页面初始加载，保存 按钮、XX下拉框、xx 文本框。 基本上来说，引起页面或者数据发生变化的都称之为事件。 而对任何功能测试，页面静态检查、页面初始加载是排在最前的。 测试项的提取可参见“模板填写项说明”中相应内容，也可参考样例进行。 业务流：以业务人员或用户操作为指导，对功能界面的操作 实现方式： 采取事件流，加上用户（业务）的操作顺序的方式，具体表现是控件为主导测试 项，操作项中用来描述用户 （业务）的顺序操作。 首先提取该功能中的控件元素作为测试项， 然后再结合业务逻辑先关注业务或用 户的操作步骤和顺序，加上控件的检验点，生成一条测试子用例。 坚持一个大原则。尽量以控件（或者事件）为测试项，测试项的顺序主要按照用 户的操作习惯跟业务顺序 从上到下，从左到右来放置。首先是页面初始化（静态）， 其次是页面初始加载，然后是操作主控件之前所需要的页面数据的元素， 这些元 素写了之后是主控件，最后是一些该功能页面中重要级别较低的控件。 比如：保存功能，首先是界面检查（静态），页面初始化，然后是一些动态关联 下拉框，公共弹出框，然后是保存事件，保存事件之后才是编辑，删除，排序， 翻页。因为必须有保存之后才会有数据。才方便做后面的检查。 比如查询功能，首先是界面检查（静态），页面初始化，然后才是查询控件，其 次才是排序，翻页，清空（重置） 编写用例尽量注意的问题： 测试子用例可以引用公共用例，但是必须明确注明出处，引用方式为: “XXX项目名称（简称：统一项目简称统一）” +公共用例+ “公共用 例名称” 用户界面不要太多，用户界面应属于设计范畴，鼠标、按键等内容不 应出现在用例中； 较低目标层次上的用例不要太多，无法展示系统将会给其最终用户提 供什么功能； 使用用例表示非行为信息，性能需求、业务规则等不要在用例中描述； 目标实现不完整，尤其是错误处理； 句子片断，主、谓、宾尽量完整； 不要使用模糊语言，比如“是否”，应当是就是“是”，否就是“否” 测试数据选取原则： 如果输入了条件规定了取值范围，应以该范围的边界内及刚刚超范围 的边界的值作为测试用例数据，如果以 a和b为边界，测试数据应当 包含a和b及略大于a和略小于b的值。 若规定了值的个数，分别以最大，最小个数及梢小于最小，梢大于最 大的个数作为测试数据 一般采用以上2个原则。 如果输入是个有序集合，注意选择有序集合的第一个和最后一个元素 作为测试数据 5.2.模板填写项说明 模板 元素 分