搜索
测试用例设计方法培训2014.02.14目录测试设计开展流程如何多方面考虑测试一个系统常用测试设计方法12345测试用例更新及维护漏测分析5测试设计开展流程：需求文档学习输出问题确认列表需求文档评审制定测试设计计划思维导图评审，汇总意见问题确认与汇总《需求确认问题汇总》开发讲解，测试提问输出评审结论，归档制定设计任务分配表启动设计输出思维导图输出修改后思维导图《测试设计思维导图》评审通过后启动设计输出测试用例初稿启动测试用例评审汇总评审意见，启动更新第一次更新完成，再评审汇总形成测试用例归档，设计完成123测试设计相关文档：1、需求确认阶段：2、需求评审阶段：需求评审阶段的评审文档由项目管理部出具，组织评审，留存评审结论。3、用例设计阶段：测试需求文档.xlsx如何多方面考虑测试一个系统：【用例设计原则】：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跟踪，执行结果处要附上对应的BugID2、测试负责人在一轮版本测试完成后，要组织进行测试用例的非pass分析的活动，根据分析结果修改用例，保持用例的最新。测试用例更新及维护：用例维护的必要性：1、根据需求输出的测试用例，一般在软件功能交付后，就会存在需求变更导致用例与系统功能实现对不上的情况，需要刷新用例。2、测试用例执行一遍以后，发现问题的能力降低，缺陷有了免疫性，需要重新新的内容。3、客观承认测试设计的不全面性，即只要是设计，就会存在遗漏，通过一段时间的测试加深理解后，可以更好的完善用例。4、对每个版本发现的问题进行分析，将之前的测试设计遗漏点补充进测试用例里面。用例维护的方式：1、根据刷新后的需求说明书，更新用例。2、根据提交给测试的软件版本的具体实现，刷新用例。3、根据非pass用例的执行结果，进行分析后，刷新用例。4、对每个版本发现的问题进行分析，找到测试设计遗漏点，刷新用例。5、软件功能转测试后，出现变更，追加或删除，刷新用例。6、需求掌握程度加深后，发现测试设计遗漏点，刷新用例。测试用例更新及维护：用例维护的时间：1、一般在全面用例执行后，进行用例的第一次刷新。2、每轮执行后，进行缺陷分析后的用例补充及刷新。3、测试执行完成后，规范化刷新后归档。用例维护的方式：由项目测试负责人进行用例的刷新的组织，组内人员协助刷新。漏测分析定义：一种质量改进活动，一般发生在第二轮以及之后的版本测试后，由测试负责人发起，其他人员配合开展的一个问题回溯，借以调查每轮问题出现的原因，是新引入，还是测试遗漏，然后根据分析结果，进行相应改进的一种质量提升活动。漏测分析发起人：由项目测试负责人进行漏测分析。漏测分析流程：由项目测试负责人汇总输出当前版本发现问题列表---由本轮提单人员去上个版本复验---填写复验结果---如果是测试人员漏测，需对应上一轮的测试人员撰写漏测分析报告，如果是新问题引入，则由对应开发人员撰写问题引入原因报告。---由QA组织回溯会议，对相关问题进行回溯，输出会议结论，形成改进意见。---周知相关领域，相关改进意见的落实。谢谢！