测试用例设计方法培训》.ppt

测试用例设计方法培训,2014.02.14,目录,测试设计开展流程,如何多方面考虑测试一个系统,常用测试设计方法,1,2,3,4,5,测试用例更新及维护,漏测分析,5,测试设计开展流程：,需求文档学习,输出问题确认列表,需求文档评审,制定测试设计计划,思维导图评审，汇总意见,问题确认与汇总,需求确认问题汇总,开发讲解，测试提问,输出评审结论，归档,制定设计任务分配表,启动设计输出思维导图,输出修改后思维导图,测试设计思维导图,评审通过后启动设计,输出测试用例初稿,启动测试用例评审,汇总评审意见，启动更新,第一次更新完成，再评审,汇总形成测试用例,归档，设计完成,1,2,3,测试设计相关文档：,1、需求确认阶段： 2、需求评审阶段： 需求评审阶段的评审文档由项目管理部出具，组织评审，留存评审结论。 3、用例设计阶段：,如何多方面考虑测试一个系统：,【用例设计原则】： 1、按照测试类型分析法，按功能，压力，稳定性，性能，安全性，兼容性进行测试类型划分。 2、针对场景分析法，进行基于流程的功力遍历。 3、针对单个点，进行边界值，等价类相关的测试点的考虑。 4、考虑流程中的异常操作。 5、考虑环境中的可能出现的异常情况，如断开电源，断开网络，网络带宽被占用。 6、考虑其他设备对软件的影响。比如多USB设备。 7、考虑压力的积累，和功能使用的稳定性。 8、考虑性能诉求 9、考虑存储空间即将满，已经满的情况下的数据处理。 10、考虑安装、卸载、升级、重复安装等实际使用场景中遇到的情况。,如何多方面考虑测试一个系统：,【个页面的测试点的考虑】： 基于整个页面： 1、填写区域是否为空的检查： A、只填写一处 B、填写部分、空白部分 C、填写剩一处 D、填写所有。 2、针对单个填写框： A、考虑长度（最长、最短） B、考虑字符（数字、字母、特殊字符、组合） C、考虑全角半角 3、测试点1和测试2的组合。 4、存在关联的不同单元格之间的测试点的考虑： 如单张发票金额不能大于累计发票金额。设计用例时就要考虑验证这点。 5、考虑不同功能模块的入口，如正票开具，可以从菜单选择，也可以直接点击正票开具的按钮。不同入口出口的组合要遍历验证。,如何多方面考虑测试一个系统：,【存在关联业务的测试点的考虑】： 重点关注在当前业务走通的情况下，对其他相关联页面的影响。主要考虑如下几个方面： 1、当前业务正常走通，其他相关模块是否能正常显示对应数据。 2、当前业务执行过程中出现异常情况，对自身及子他模块数据的影响是否正常。 3、考虑积累作用：长时间，重复操作本模块，是否会对其他模块的数据处理造成影响，相关模块数据处理是否正常。 4、几个模块共同作用，都发生数据变更，查看彼此间的影响是否正常，数据处理是否正确。,常用测试设计方法：,整体把握： 【测试类型分析法】 单个功能点： 【测试类型分析法】【测试场景分析法】【模块关联】【等价类边界值分析法】 单个界面： 【测试类型分析法】【模块关联】【表间关联】 【等价类边界值分析法】【不同出入口遍历】 单个输入框、选择框等： 【表间关联】【等价类边界值分析法】,测试类型分析法：,【测试类型分析法】： 即将一个功能点按照不同的测试类型进行划分，针对每一个测试类型都进行测试点设计的分析方法。 举例说明：,功能测试常规测试点：,性能测试&压力测试&稳定性测试：,思维导图设计格式的原则：,1、整体把握： 使用【测试类型分析法】建立第一级目录。 2、单类型测试点： A、首先以小的功能模块进行分级。 B、小的功能模块里面按照“*执行成功”，“*执行失败”，“*关联性测试”，“异常情况测试”等若干模块。 C、举例：“*执行成功”里面再分“一次执行成功”，“多次执行成功（考虑重复执行同一记录，不同记录）”。 3、最后一级描述规则： 【测试点】+【简洁扼要的测试步骤】+隔断符号+【预期结果】，如： “校验客户名称长度：点击进入客户信息新增界面，输入客户名称允许输入的最大长度，其他信息符合规则，点击保存。-对应客户信息能够正常保存，显示正常。” 4、严格控制思维导图横向层级： 为了思维导图转化用例时的方便，横向分级不宜过多。 5、最后一级测试描述颗粒度：一个用例永远只关注一个测试点。比如关注一个输入框的输入内容的时候，就不考虑长度，不考虑其他单元框对他的影响。,测试用例设计说明：,用例设计原则说明： 1、单个功能的用例设计条数需要考虑其重要程度、重要性为高的功能，用例设计就相对完善、相对丰富些，重要性比较低的功能，用例设计的力度就小一些。 2、Level1级别的用例多考虑正常流，少考虑异常流。 3、单条用例执行的步骤和预期结果的条数要控制，步骤太多的话，容易引起测试遗漏，一般不要超过3个步骤 4、一个用例只有一个测试点。,测试用例编号格式： 一级模块_二级模块_000N，比如“编码设置_客户编码_0001”。,测试用例标题命名格式： 测试结果_简短的测试步骤,测试思维导图设计步骤_1：,用例级别定义说明： Level1：最常用操作、测试用例为正向反向的对应用例。 Level2：不太常用操作或者不太常用的比如边界值、冷僻输入的检查、不停点击按钮等类似的操作的对应用例。 Level3：操作方法比较复杂、测试环境比较生僻，且执行起来有较大难度的对应用例。 一般Level1：Level2：Level3的用例设计比例约为4:5:1，或者4:5.5:0.5,用例执行结果标注说明： Pass：按照测试用例的操作步骤执行，实际执行结果与预期结果一致。 Fail：按照测试用例的操作步骤执行，实际执行结果与预期结果不一致。出现界面显示异常、处理异常、死机、功能失效等异常情况。 Block：由于测试环境或者其他外部条件的限制，导致用例无法执行。或者用例不适用，需要更新用例的情况。 Unavailable：软件对应功能未实现，导致对应用例无法执行的情况。 investgest ：不确定测试结果的对错，还需要再确认的情况,测试思维导图设计步骤_1：,用例执行说明： 1、执行结果为Fail的测试用例，一定要有对应的bug跟踪，执行结果处要附上对应的Bug ID 2、测试负责人在一轮版本测试完成后，要组织进行测试用例的非pass分析的活动，根据分析结果修改用例，保持用例的最新。,测试用例更新及维护：,用例维护的必要性： 1、根据需求输出的测试用例，一般在软件功能交付后，就会存在需求变更导致用例与系统功能实现对不上的情况，需要刷新用例。 2、测试用例执行一遍以后，发现问题的能力降低，缺陷有了免疫性，需要重新新的内容。 3、客观承认测试设计的不全面性，即只要是设计，就会存在遗漏，通过一段时间的测试加深理解后，可以更好的完善用例。 4、对每个版本发现的问题进行分析，将之前的测试设计遗漏点补充进测试用例里面。,用例维护的方式： 1、根据刷新后的需求说明书，更新用例。 2、根据提交给测试的软件版本的具体实现，刷新用例。 3、根据非pass用例的执行结果，进行分析后，刷新用例。 4、对每个版本发现的问题进行分析，找到测试设计遗漏点，刷新用例。 5、软件功能转测试后，出现变更，追加或删除，刷新用例。 6、需求掌握程度加深后，发现测试设计遗漏点，刷新用例。,测试用例更新及维护：,用例维护的时间： 1、一般在全面用例执行后，进行用例的第一次刷新。 2、每轮执行后，进行缺陷分析后的用例补充及刷新。 3、测试执行完成后，规范化刷新后归档。,用例维护的方式： 由项目测试负责人进行用例的刷新的组织，组内人员协助刷新。,漏测分析,定义： 一种质量改进活动，一般发生在第二轮以及之后的版本测试后，由测试负责人发起，其他人员配合开展的一个问题回溯，借以调查每轮问题出现的原因，是新引入，还是测试遗漏，然后根据分析结果，进行相应改进的一种质量提升活动。,漏测分析发起人： 由项目测试负责人进行漏测分析