测试用例设计编写和写作要点.ppt

目录 测试用例的基础知识 测试用例写作要点 常用测试用例设计方法 测试用例编写思路 测试用例的定义 测试用例（Test Spec or Test Case）：目前没有经典的定义，比较通常的说法是：指对一项特定的软件产品测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。 测试用例举例： 单个测试用例测试执行 系统测试用例的要点 对象：整个软件产品及其环境等要素。 目的：验证软件产品的所有需求功能 方法：黑盒测试 测试范围：软件质量模型（6大特性，27个子特性，见后文） 软件质量的验证：测试用例对需求说明书SRS的覆盖程度 影响系统测试的因素：组织、流程、技术、成本、进度、风险等 什么样的测试用例是好的测试用例？ 能够覆盖需求的用例 根据软件质量模型，从不同角度对需求进行测试 用不同的测试用例设计方法从不同的角度来验证需求 测试用例编写规范 测试用例设计生成的基本准则 测试用例的代表性：能够代表并覆盖各种合理的和不合理、合法的和非法的、边界的和越界的、以及极限的输入数据、操作和环境设置等 测试结果的可判定性：即测试执行结果的正确性是可判定的，每一个测试用例都应有相应的期望结果 测试结果的可再现性：即对同样的测试用例，系统的执行结果应当是相同的 测试用例的特征 最有可能抓住错误的 不是重复的、多余的 一组相似测试用例中最有效的 不要太简单，也不要太复杂 测试用例的意义 使用测试用例的好处主要体现在以下几个方面： 在开始实施测试之前设计好测试用例，可以避免盲目测试并提高测试效率 测试用例的使用令软件测试的实施重点突出、目的明确 在软件版本更新后只需修正少部分的测试用例便可展开测试工作，降低工作强度、缩短项目周期 功能模块的通用化和复用化使软件易于开发，而相对于功能模块的测试用例的通用化和复用化则会使软件测试易于开展，并随着测试用例的不断精化其效率也不断攀升 测试用例的特点 组织性－有利于测试的组织 功能覆盖－确保功能不被遗漏 重复性－有利于测试的重复 跟踪－有利于测试的跟踪 测试确认－在少数高风险的测试中，必须证明确实执行了计划执行的测试 测试用例的写作要点 测试用例编号(ID) 测试标题（Title） 测试用例的优先级(Priority) 测试用例的客观条件(Objective) 测试用例的预置条件（Precondition） 测试用例的操作步骤(Step and Description) 测试用例预期结果(Expected result) 测试用例的写作要点 测试用例编号(ID)：根据项目的情况、需求说明书等决定，一般是由字符和数字组合车改的字符串，具有唯一性、易识别性 测试标题（Title）：测试用例的简单描述，需要用概括的语言描述该用例的出发点和关注点，原则上每个用例的标题不能重复。 例如： Nspace on PC－log in \ log out Nspace registration on PC- change password Nspace friends—friends management 测试用例的优先级(Priority)：根据测试用例的重要程度来定义级别，级别越高越先执行并测试 例如：Major Minor Showstopper 测试用例的写作要点 测试用例的客观条件(Objective)：在测试进行之前需要准备的东西或满足的条件 例如：To verify that user can log in and log out the Nspace on PC. 测试用例的预置条件（Precondition）：执行当前测试用例需要的前提条件，如果这些前提条件不满足，则后面的测试步骤无法进行或者无法得到预期结果。 例如： User has registered in the Nspace and does not log in the Nspace. The Browser (IE) has already opened. 测试用例的写作要点 例如： 测试用例预期结果(Expected result)：当前测试用例的预期输出结果，包括界面的响应结果，输出结果的规则符合度等等 测试用例的写作要点 例如： 测试用例的写作检查规则 测试用例标识是否按照测试方案的规则来编写 每个测试用例的预置条件和客观条件十分都被描述清楚 每个测试用例的预期结果是否完整而清晰 是否明确说明了每个测试用例的优先级 是否明确说明了测试用例的执行顺序 常用系统测试用例设计方法 等价类划分法* 边值分析法* 流程分析法* 判定表法 因果图法 状态迁移图法 正交试验法 输入域测试法 输出域覆盖法 异常分析法 错误猜