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

目录目录测试设计开展流程如何多方面考虑测试一个系统常用测试设计方法12345测试用例更新及维护漏测分析5测试设计开展流程：需求文档学习输出问题确认列表需求文档评审制定测试设计计划思维导图评审，汇总意见问题确认与汇总需求确认问题汇总开发讲解，测试提问输出评审结论，归档制定设计任务分配表启动设计输出思维导图输出修改后思维导图测试设计思维导图评审通过后启动设计输出测试用例初稿启动测试用例评审汇总评审意见，启动更新第一次更新完成，再评审汇总形成测试用例归档，设计完成归档，设计完成1 12 23 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、考虑不同功能模块的入口，如发布房源，可以从我的Q房首页点击跳转，也可以直接点击发布房源菜单。不同入口出口的组合要遍历验证。如何多方面考虑测试一个系统：【存在关联业务的测试点的考虑】： 重点关注在当前业务走通的情况下，对其他相关联页面的影响。主要考虑如下几个方面： 1、当前业务正常走通，其他相关模块是否能正常显示对应数据。 2、当前业务执行过程中出现异常情况，对自身及子他模块数据的影响是否正常。 3、考虑积累作用：长时间，重复操作本模块，是否会对其他模块的数据处理造成影响，相关模块数据处理是否正常。 4、几个模块共同作用，都发生数据变更，查看彼此间的影响是否正常，数据处理是否正确。 比如，新房也属于小区，但是价格是运营平台人工维护的，在测试小区均价计算的功能时，我们很容易忽略新房的价格是否会发生变动。常用测试设计方法：整体把握：整体把握：【测试类型分析法】单个功能点：单个功能点：【测试类型分析法】【测试场景分析法】【模块关联】【等价类边界值分析法】单个界面：单个界面：【测试类型分析法】【模块关联】【表间关联】【等价类边界值分析法】【不同出入口遍历】单个输入框、选择框等：单个输入框、选择框等：【表间关联】【等价类边界值分析法】 测试类型分析法：【测试类型分析法】： 即将一个功能点按照不同的测试类型进行划分，针对每一个测试类型都进行测试点设计的分析方法。 举例说明：功能测试常规测试点：性能测试&压力测试&稳定性测试：思维导图设计格式的原则：1 1、整体把握：、整体把握： 使用【测试类型分析法】建立第一级目录。2 2、单类型测试点：、单类型测试点： A、首先以小的功能模块进行分级。 B、小的功能模块里面按照“*执行成功”，“*执行失败”，“*关联性测试”，“异常情况测试”等若干模块。 C、举例：“*执行成功”里面再分“一次执行成功”，“多次执行成功（考虑重复执行同一记录，不同记录）”。3 3、最后一级描述规则：、最后一级描述规则： 【测试点】+【简洁扼要的测试步骤】+隔断符号+【预期结果】，如： “校验客户名称长度：点击进入客户信息新增界面，输入客户名称允许输入的最大长度，其他信息符合规则，点击保存。-对应客户信息能够正常保存，显示正常。”4 4、严格控制思维导图横向层级：、严格控制思维导图横向层级： 为了思维导图转化用例时的方便，横向分级不宜过多。为了思维导图转化用例时的方便，横向分级不宜过多。5 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 ID2、测试负责人在一轮版本测试完成后，要组织进行测试用例的非pass分析的活动，根据分析结果修改用例，保持用例的最新。测试用例更新及维护：用例维护的必要性：用例维护的必要性：1、根据需求输出的测试用例，一般在软件功能交付后，就会存在需求变更导致用例与系统功能实现对不上的情况，需要刷新用例。2、测试用例执行一遍以后，发现问题的能力降低，缺陷有了免疫性，需要重新新的内容。3、客观承认测试设计的不全面性，即只要是设计，就会存在遗漏，通过一段时间的测试加深理解后，可以更好的完善用例。4、对每个版本发现的问题进行分析，将之前的测试设计遗漏点补充进测试用例里面。用例维护的方式：用例维护的方式：1、根据刷新后的需求说明书，更新用例。2、根据提交给测试的软件版本的具体实现，刷新用例。3、根据非pass用例的执行结果，进行分析后，刷新用例。4、对每个版本发现的问题进行分析，找到测试设计遗漏点，刷新用例。5、软件功能转测试后，出现变更，追加或删除，刷新用例。6、需求掌握程度加深后，发现测试设计遗漏点，刷新用例。测试用例更新及维护：用例维护的时间：用例维护的时间：1、一般在全面用例执行后，进行用例的第一次刷新。2、每轮执行后，进行缺陷分析后的用例补充及刷新。3、测试执行完成后，规范化刷新后归档。用例维护的方式：用例维护的方式：由项目测试负责人进行用例的刷新的组织，组内人员协助刷新。漏测分析定义：定义：一种质量改进活动，一般发生在第二轮以及之后的版本测试后，由测试负责人发起，其他人员配合开展的一个问题回溯，借以调查每轮问题出现的原因，是新引入，还是测试遗漏，然后根据分析结果，进行相应改进的一种质量提升活动。漏测分析发起人：漏测分析发起人：由项目测试负责人进行漏测分析。漏测分析流程：漏测分析流程：由项目测试负责人汇总输出当前版本发现问题列表-由本轮提单人员去上个版本复验-填写复验结果-如果是测试人员漏测，需对应上一轮的测试人员撰写漏测分析报告，如果是新问题引入，则由对应开发人员撰写问题引入原因报告。-由QA组织回溯会议，对相关问题进行回溯，输出会议结论，形成改进意见。-周知相关领域，相关改进意见的落实。十大负面测试用例1.特殊字符检测。2.必填项验证。3.字段类型测试。4.字段长度测试。5.边界值验证。6.数字的约束测试。7.日期边界测试。8.日期的有效性。9.web会话测试。10.性能的改变。特殊字符检测植入的单引号。大多数基于SQL的数据库系统在用户存储包含一个单引号的信息时会出现问题。每一个可以接受文字数字型数据条目的屏幕都要试试输入包含一个或多个单引号的文本。【补充】其实不只是单引号，基本上测试人员应该测试所有的特殊字符和空/空格（单纯的空格和文本前后的空格）。单引号，逗号，/，（对于web的应用程序）都是很容易引发错误的。例：输入特殊字符!#$%&*()_+|:?.,;=-(注意单引号经常会发现bug)输入html语言，例： onclick=javascript:.输入特殊字符串NULL、null、&nbsp空格的转义字符；输入javascript命令，例如：test.asp?username=MyName必填项验证必需输入的数据条目。功能说明书上应该清楚的指出屏幕上必须输入数据条目的字段。测试屏幕上每一个被说明为必须输入的字段以保证它强制要求你在字段中输入数据。【补充】对于强制输入的字段，在屏幕上最好有些标识以说明其为必须输入的字段。一般在字段前或后用红色的*号表示。测试时必须要检查有标识的字段是否和功能说明书或其他参考文档一致，错误信息提示是否正确，强制输入的字段是否真的必须输入。例：字段类型测试功能说明书上应该清楚的指出要求特定数据输入要求（日期字段，数字字段，电话号码，邮编等等）的字段。测试屏幕上每一个被指出有特定类 型的字段以保证你输入了基于字段类型的符合正确格式的数据（数字型字段应该不允许字符或特殊字符，日期型的字段应该允许输入一个正确的日期等等） 【补充】其实这里还有一个字段格式和字段内容的测试。有些字段对输入的格式有要求，这些字段的格式一般在屏幕上也有相应的提示。所以在测试时需要 测试提示的格式是否合理（和功能说明书或其他参考文档相一致）以及系统是否正确识别输入的格式。有些字段对字段的内容有限制，如常见的用户名，不能包含特 殊字符，首字不能未数字等要求。所以在测试时需要测试提示的格式是否合理（和功能说明书或其他参考文档相一致）还有不符合内容要求的数据输入时系统是否正 确的处理。字段长度测试功能说明书上应该清楚的指出可以在字段中输入的字符数（例如，first name必须是50个或更少的字符）。写测试用例以保证你只可以输入特定的字符数。防止用户输入比允许范围更多的字符比因用户已输入过多的字符而给出的错 误信息更加的文雅些。【补充】一般对于限制长度的字段，现在开发大多采用限制输入的方法（设置字段的长度）来处理。所以测试时需要测试限制的长度是否合理（和功能说明 书或其他参考文档相一致），对于没有限制长度的字段，要测试无穷输入时是否出错，有问题报bug时建议开发人员根据需要限制长度。边界值验证数字型的边界测试。对于数字型的字段，测试上下边界是非常重要的。例如，如果你正在计算某个账户的利息时，你永远不会输入一个负的利息数给应该赢取利 息的账户。因此，你应该尝试用负数测试。同样，如果功能说明书上要求字段在某一个特定的范围（如从1050），你就应该尝试输入9或51，它应该给出一 个得体的信息表示失败。【补充】边界值的测试同时，最好结合等价类以及一些特殊数字进行开展，如这里面的负数，虽然账户利息永远不会出现负数，但是如果系统中一旦输入负数，系统就崩溃，那么这样的系统对于客户来说也是非常危险的。数字的约束测试大多数数据库系统和编程语言允许数字条目被识别为整数或长整数。通常，整数的范围是从-32,76732,767，长整数的范围从 -2,147,483,6482,147,483,647。对于那些没有特定边界限制的数字数据条目，用这些限制测试以确保不会出现数字的溢出错误。 【补充】小数型的数字字段同样也需要格外的测试。一般对于未指出数字类型的字段，尝试输入负整数，负小数，0，正整数，正小数进行测试。不管是哪种数据库系统，对于数字一般都有多种数字类型。所以测试人员一定要测试的全面。日期边界值测试对于日期型的字段，测试上下边界是很重要的。例如，如果你正在检查一个出生日期的字段，很大可能出生日期不能早于150年前。同样，出生日期应该不是将来的某一天。 【补充】一般来说，每种数据库系统的日期都有个范围，如SQL Server最小日期是1753年1月1日，所以如果是输入型的日期字段同样也应该测试早于1753的日期。日期的有效性对于日期字段，确保不允许无效的日期是很重要的（04/31/2007是一个无效的日期）。测试用例也应该检查闰年（每个第4年和第400年是一个闰年）。web会话测试很多的web应用程序依赖浏览器的会话来追踪已登录的用户，应用程序的设置等等。应用程序的大多数屏幕不被设计为没有首次登录就可以被运行。应用程序应该确保在打开应用程序的某一页面之前会话里有一个有效的登录。例如：退出后，直接访问登录状态的URL 或以页面后退的形式进入性能的改变当发布产品的最新版本时，应该有一套运行于识别屏幕（列出信息的屏幕，add/update/delete数据的屏幕等等）速度的性能 测试。测试包里应该包括比较先前版本和现有版本性能统计值的测试用例。这个可以帮助识别那些可以证明是随着对现有版本的代码变更而引起的潜在的性能问题。 【补充】性能的影响，大家在测试中经常会忽略掉，但是实际上这部分的而影响是非常大的，所以对于关键的特性部分一定要在测试的时候，对于性能的影响（是否出现性能突变、性能下降等）进行关注，并重点验证。 谢谢！