面向功能的试需求分析和测试用例设计.ppt

* of X QA 缠层哗说蕴唁裹微米调暴糜耳圈丛售给距毒衣铣篙恨耀饰底湘狐裂帕萝绰面向功能的测试需求分析和测试用例设计演示文稿 * of X 谢 谢！ 系慕迁野屉答玉貉承扣括盐似馆窝颖仇靴抵淖牲隐惹持梗狐瓜珍浚瘸汛砍面向功能的测试需求分析和测试用例设计演示文稿 进行此项培训之前，请大家一定要先有以下这个共识 测试与开发两者不分家，可以互通。我们所用的很多方法不仅测试人员在用，开发人员也在用，甚至有些方法是从开发方法中提炼变形过来的。 对于测试人员和开发而言，需求是共同的，只不过表述的方式不同而已 * * * 我们在测试活动中，首先需要明确测试需求(What)，才能决定怎么测(How)，测试时间(When)，需要多少人(Who)，测试的环境是什么(Where)，测试中需要的技能、工具以及相应的背景知识，测试中可能遇到的风险等等，以上所有的内容结合起来就构成了测试计划的基本要素。而测试需求是测试计划的基础与重点。 就像软件的需求一样，测试需求根据不同的公司环境，不同的专业水平，不同的要求，详细程度也是不同的。但是，对于一个全新的项目或者产品，测试需求力求详细明确，以避免测试遗漏与误解。 * 改变我们的思维方式，学会系统化思考，结构化表达。 把复杂的事情简单化； 把简单的事情可操作化； 把可操作的事情度量化、数字化； 把可度量、可数字化的事情可考评化； 把可考评的事情流程化。 * MRD-“市场需求文档”，是产品经理或者产品市场经理编写的一个产品的说明需求的文档。这些文档用于计划一个新产品或修正一个已有的产品，是被工程师团队开发产品时使用。 UC，即Use Case，国内翻译为用例，它描述的是一个操作，而不是一个功能。传统的软件模型设计喜欢在需求分析把业务分解成功能模块，这样的弊端就是混淆了需求和设计的界限，因为功能模块的划分牵涉到系统的概要设计。在RUP里面提倡用Use Case来代替功能模块的划分。与功能模块不同的是，用例不是站在开发者的角度，而是站在用户的角度来分解系统，因为用户并不想了解系统的内部结构和设计，他们关心的是系统的服务，即系统是如何去操作的，这就是用例的基本思想。 * 例子： 业务需求：如ATM能进行取款；每次取款额度在50-2，500之间；取款的金额是50的倍数；从ATM机器上每日取款数量不得超过20，000 测试需求：如取款按钮是可选的；在50-2，500之间的50的倍数是可取的；小于50元是不允许的；大于2，500是不允许的；50的倍数但是大于2,500是不允许的；在50-2,500之间但不是50的倍数是不允许的；收到的金额与请求的金额相当；取款的总额必须是小于等于账户余额等等 * 业务功能级别：关注相互之间的联系，完整性以及系统功能之间的交互性(可选)功能任务级别：把每个功能分解成任务，对于复杂的任务，可以分解成子任务，注意：一些业务功能不能被分解成更细的任务 事务级别/事务数据类型级别：执行这项任务DB要执行的事务，关注系统内部发生的任务，鉴别与DB关联的逻辑事务或者其他与执行任务相关的事务，识别数据处理，计算，数据的格式化处理; 识别将做哪种操作：增加，删除，修改，查询；一个事务完全可能做多种操作 字段校验级别：对各种数据类型的校验，覆盖对所有字段数据的编辑以及交叉编辑，使用校验对象的某某属性，请参考什么附表即可，不要把每个属性都作为一个独立的测试需求 * 1. 验证出租车任务成功（业务功能级别）1.1 检查客户投保情况（任务级别）1.2 查询车是否可取（任务级别）1.3 查询车辆费用（任务级别）1.4 开出租票（任务级别）1.4.1 验证顾客记录能输入（事务级别）1.4.2 验证信用卡信息查询结果有效（事务级别）1.4.2.1 验证在有效日期范围内（字段校验）1.4.2.2 验证字段的有效位数（字段校验）1.4.2.3 验证信用卡余额足够（字段校验）1.4.3 验证车的状态从“等待”变为“已出租” （事务级别） 2. 账务结算功能（业务功能级别）3. 出租车预定功能（业务功能级别） * * * 软件测试的本质就是针对要测试的内容确定一组测试用例 * 使测试更加方便的执行 提高测试效率 节省执行测试的时间 使测试更能按照时间计划进行 使测试过程更方便管理 * 准确性 测试用例的设计确实符合并要求能完全覆盖测试需求，并且必须准确地说明测试的内容 简洁性 测试用例的设计中必须包含完成测试必要的步骤、要素，不需要加入多余的、可有可无的步骤、要素 可重用性 测试用例的设计要求测试是可控的，它能够使任何人在任何时间进行测试都能获得同样的结果。如果出现仅仅设计者能够进行测试并获得结果，或者不同的测试人员获得不同的结果的情况，该测试用例就