测试用例理论

测试用例的定义

什么是测试用例：

它是每个业务目标，用编制的一组由测试输入，执行条件以及预期结果的案例

测试用例的好处及作用：

在开始实施测试之前设计好测试用例，可以避免盲目测试并提高测试效率。

测试用例的使用令软件测试的实施重点突出、目的明确。

在软件版本更新后只需修正少部分的测试用例便可展开测试工作，降低工作强度、缩短项目周期。

检验软件是否满足客户需求、体现一个测试人员的工作量、展现测试用例的设计思路.

测试用例的4个特性

代表性：能够代表并覆盖各种合理的和不合理、合法的和不合法、边界和越界以及极限的输入数据、操作等。

针对性：对程序中的可能存在错误有针对性的测试

可判定性：测试执行结果的正确性是可判定性，每一个测试用例都应有相应的结果

可重现性：对同样的测试用例，系统的执行结果应当是相同的。

测试用例通常包括以下几个组成元素：

测试用例模板

用例编号、测试模块、用例标题、用例级别、前置条件、测试输入、执行输入、预期结果、实际结果、测试人员、结束时间

测试报告模板

测试目标、测试依据、测试范围、测试环境、测试进度、执行结果、缺陷分布、遗留缺陷、测试结论、建议、附录…

测试用例设计原则

测试用例设计的基本原则包括：有效性、清晰性、可复用性、可维护性、完整性、兼容性、易操作性、可管理性、可评估性

1. 有效性：测试用例步骤必须描述清晰，不能出现模棱两可的以及重复的话语，测试用例应该按照一定的顺序进行编写，这样执行的时候效率比较高。

2. 清晰性：用例的操作步骤要描述清晰，包含清晰的输入数据以及预期输出，验证点必须明确清晰，并能突出重点，对于流程性的用例建议按照流程顺序进行用例安排，从第一个验证点到最后一个验证点，组成流程的开始到结束，方便测试执行。测试用例包含前置条件的必须将前置条件描述清楚，包括入口等。

3. 可复用性：可重复使用，并尽量将具有相似功能的测试用例抽象并归类。

4. 可维护性：测试用例因为业务需求发生变更的时候，需要及时更新维护测试用例，做到测试用例的实时性与有效性，测试用例需要细化和不断的完善，是个循序渐进的过程。

5. 完整性：用例是否完成并覆盖所有需求点，做到对需求的完全理解。

6. 兼容性：测试用例要包含新老版本的兼容、新老数据兼容、浏览器兼容等测试点。

7. 可管理性：能够检测测试人员的测试进度、工作量等。

8. 可评估性：测试用例的通过率和缺陷的数目是评估软件质量的好坏的标准。

测试用例的生命周期

软件测试用例的设计阶段包含：需求分析、测试用例设计、测试用例实现、测试用例执行、测试用例管理

需求分析

测试用例过程的第一步是确定测什么，标识出测试点，并且对测试点进行优先级的划分。

测试用例设计

测试用例设计确定了如何来测试已经分析出的测试点。

测试设计的主要点是确定测试预期结果。为了确定测试预期结果，测试人员不仅需要关注测试输出，同时也需要注意测试数据和测试环境的前后置条件。假如测试用例没有测试的预期结果，则测试用例对于测试结果的对错判断是毫无意义的。

测试预期结果可以是各种各样的，包括需要创建或者输出的结果，也可以是需要更新或者变更的结果，也可以是删除的结果。每个测试用例都应该清楚的描述测试的预期结果。这样，就需要测试人员具有被测系统相关的丰富的知识和经验，才可能对软件系统的测试输出作出正确的评估。假如测试输出结果评估认为是正确的，那么就可以作为测试用例的期望输出结果。

测试用例实现

测试用例实现的过程包括准备测试脚本、测试输入、测试数据以及预期结果等。测试脚本指的是按照标准的语法组织数据或者指令。测试执行之前，首先必须满足测试前置条件，比如一个测试用例需要用到配置好的一些数据，那么这个数据就必须提前创建等。

测试用例执行

通过运行测试用例来对被测系统进行测试。对于手动测试来说，主要参照测试用例的步骤来进行测试执行，比较预期结果和实际结果、并记录测试过程中发现的问题。

对于自动化测试过程，执行时需要借助测试工具，运行测试用例脚本等，记录测试结果。

执行测试时如实际结果和预期结果是一样的，则认为是通过的，如果不一样，那用例执行失败，或存在问题，对于用例执行失败，需要进一步的检查，确定是软件问题还是用例的预期结果有问题，或者是数据问题，环境问题引起的，需要从不同的方面进行问题分析。

测试用例管理

1. 测试用例组织

每一个项目，其测试用例的数目都非常多。如何来组织、跟踪和维护测试用例是一件非常重要的事情。如何来组织测试用例，是测试成功与否的一个重要因素，也是提高测试效率的一个重要步骤。

测试用例的组织，可以用不同的方法来进行组织或者分类：

• 按照软件功能模块组织：软件系统一般是根据软件的功能模块来进行工作任务分配的。因此，根据软件功能模块进行测试用例设计和执行等是很常用的一种方法。根据模块来组织测试用例，可以保证测试用例能够覆盖每个系统模块，达到较好的模块测试覆盖率。

• 按照测试用例优先级组织：测试用例是有优先级的。对于任何软件，实现穷尽测试是不现实的。在有限的资源和时间内，首先应该执行优先级高的测试用例。

按照功能模块进行划分是最常用的，我们也可以结合起来使用，比如在按照功能模块划分的基础上，再进行不同优先级的划分。

2. 测试用例跟踪

测试用例的跟踪主要是针对测试执行过程中测试用例的状态来进行的，通过测试状态的跟踪和管理，从而实现测试过程和测试有效性的管理和评估。

• 测试用例执行的跟踪：在测试执行的过程中，对测试用例的状态进行跟踪，可以有效的将测试过程量化。比如，执行一轮测试过程中，测试的测试用例数目是多少，测试用例中通过、未通过、未测试的比例各是多少。这些数据可以提供一些信息来判断软件项目执行的质量和执行进度，并对测试进度、状态提供明确的数据，有利于测试进度和测试重点的控制。

3. 测试用例维护

测试用例并不是一成不变的，当一个阶段测试过程结束后，会发现一些测试用例编写的不合理，或者需求发生了变化，这都需要对当前的一些测试用例进行修改和更新，从而使测试用例具有可复用性。

测试用例编写要素

• 用例编号：用例的唯一标识

• 测试模块：测试用例所属模块

• 用例标题：测试用例的简要说明

• 前提条件：用例执行的前提

• 测试步骤：执行用例步骤

• 预期结果：应该得到的结果

• 优先级：用例重要程度

常见黑盒测试用例设计方法

等价类

方法：根据需求列出输入，并对每一个输入的规则进行分析，然后对每一条规则进行正确和错误的罗列，最后将的所有的输入进行正确和错误用例的组合，一条正确的用例尽可能多的覆盖每个输入的不同有效数据，一条错误的用例只能含有一个无效数据（控制变量）。 对于一个输入应考虑它的：数据类型、长度、取值范围、是否可重复，是否为空（为空可分为不输入和输入空格），组成规则等内容 。

优点：简单高效，能快速评估测试用例数量；

缺点：只考虑了输入的有效和无效，对数据的组合比较随机，边界缺陷不容易发现 ；

适用范围：只在存在输入的需求都适用。

等价类划分法

等价类是指输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的错误都是等效，并合理地假设：测试某等价类的代表值就等于对这类其他值的测试。

等价类划分的办法是把程序的输入域划分成若干部分，然后从每个部分中选取少数代表性数据作为测试用例。

等价类划分有两种不同的情况：有效等价类和无效等价类。

• 有效等价类：指对于程序的规格说明书来说是合理的、有意义的输入数据构成的集合。利用有效等价类可以检验程序是否实现了规格说明书中所规定的功能和性能。

• 无效等价类：与有效等价类的定义恰巧相反。
  设计测试用例时，要同时考虑这两种等价类。因为，软件不仅要能接收合理的数据， 也能经受意外的考验。这样的测试才能确保软件具有更高的可靠性。

确定等价类的原则

1. 在输入条件规定了取值范围或者值个数的情况下，可以确定一个有效等价类和两个无效等价类。

2. 在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下，可以确定一个有效等价类和一个无效等价类。

3. 在输入条件是一个布尔量的情况下，可以确定一个有效的等价类和一个无效的等价类

4. 在规定了输入数据的一组值（假定n个），并且程序要对每一个输入值分别处理的情况下，可以确定n个有效的等价类和一个无效的等价类。

5. 在规定了输入数据必须遵守的规则的情况下，可以确定一个有效等价类类（符合规则）和若干个无效等价类（从不同角度违反规则）。

6. 在确知已划分的等价类中，各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步地划分为更小的等价类。

确定测试用例步骤

1. 划分等价类

2. 为每一个有效等价类和无效等价类规定一个唯一的编号

3. 设计一个测试用例，使其尽可能多地覆盖尚未覆盖的有效等价类， 重复这一步直到所有有效等价类均被测试用例所覆盖

4. 设计一个测试用例，使其只覆盖一个无效等价类，重复这一步，直到所有无效等价类均被覆盖

等价类实例

三角形：

一个程序输入3个整数，三个数看作三角形的三条边，这个程序要打印出信息，说明这个三角形是不等边的，是等腰的，还是等边的。
先假设三条边为A，B，C。
判断三条边是否组成三角形必须满足两条边相加大于第三边，所以：
A>0,B>0,C>0且A+B>C,A+C>B,B+C>A
等腰三角形必须满足：A=B或A=C或B=C
等边三角形必须满足:A=B=C

qq号进行注册：

需求：QQ号注册用户，账号必须6-10位⾃然数, 同⼀QQ号不能重复注册

边界值

边界值分析方法的理论基础是假定大多数的错误是发生在各种输入条件的边界上，如果在边界附近的取值不会导致程序出错，那么其他取值导致程序错误的可能性也很小。

方法：对于存在边界的输入取边界的上点、内点、离点进行测试。

上点：边界上的点

内点：边界内的点

离点：闭区间间靠近上点但在区间外的一点，开区间则是在区间内的一点 主要是用于对等价类的补充

优点：能更容易发现边界，更全面系统的测试边界上可能存在的问题；

缺点：只能做为一个对其他设计方法的补充；

适用范围：有输入参数且存在取值边界或长度边界时。

判定表法

适用条件

• 判定表表示的是有多个输入和多个输出，而且输入与输入之间相互的组合关系，输入和输出之间有相互的制约和依赖关系

组成部分

• 条件桩：题目条件中的所有的测试输入

• 动作桩：题目条件中的所有输出

• 条件项：测试输入的取值

• 动作项：测试输出的取值

步骤

1. 明确条件桩

2. 明确动作桩

3. 对条件桩进行全组合

4. 明确每个组合对应的动作桩

5. 设计测试用例

因果图

因果图提供了一个把规格转化为判定表的系统方法，且它最终生成的就是判定表。

方法：把大的系统规格划分成可以测试的规格片段；分析哪些是原因、哪些是结果；画出因为图；把因果图转换成判定表；简化判定表；

优点：能帮助我们按照一定步骤，高效的选择测试用例，设计多个输入条件组合用例；能考虑到多个条件组合起来可能出错的情况；

缺点：输入条件与输出条件的因果关系有时很难从SRS中得到，即便得到了也会因为因果关系复杂导致因果图非常庞大，从而使测试用例数目非常多；

正交排列

• 正交法又叫正交试验法，又叫正交排列法，使用最小的测试过程集合获得最大的测试覆盖率，（测试用例的条数写的少一点，而测出的 bug 多一点），正交试验设计法，是从大量的试验点中挑选出适量的，有代表性的点，应用依据伽罗瓦理论导出的 “正交表”，合理安排试验的一种科学的试验设计方法。

正交表的概念：一种特制的表，一般的正交表标记为 Ln（mk）

• n 表示行数，也就是需要测试组合的次数

• k 表示的列数，表示控件的个数（因素的个数，或是因子的个数）

• m 是每个控件包含的取值个数（各因素的水平数，即各因素的状态数）

如：L9 (34)
有 4 个控件
每个控件有 3 个取值
9 为需要测试的组合个数、有 9 条测试用例
叫 4 因素 3 水平

步骤

1. 根据需求形成因子状态表 —- 因子：控件名称 状态：每个控件对应的取值

2. 确定所采用的正交表

3. 将正交表中的数字用文字代替

4. 一行就是一条测试用例

orthogonal_array = [
    [0, 0, 0, 0],
    [0, 1, 2, 1],
    [0, 2, 1, 2],
    [1, 0, 2, 2],
    [1, 1, 1, 0],
    [1, 2, 0, 1],
    [2, 0, 1, 1],
    [2, 1, 0, 2],
    [2, 2, 2, 0]
]

factors = {
    '时效产品': ['特快运', '特惠运', '生鲜特快'],
    '托运物品': ['文件', '家电', '数码产品'],
    '结算方式': ['寄付月结', '到付现结', '寄付现结'],
    '增值服务': ['使用京尊达', '签单返还', '不签返']
}

test_cases = []
for row in orthogonal_array:
    test_case = []
    for i, value in enumerate(row):
        factor_name = list(factors.keys())[i]
        factor_values = factors[factor_name]
        test_case.append(factor_values[value])
    test_cases.append(test_case)

# 打印生成的测试用例
for i, test_case in enumerate(test_cases):
    print(f'Test Case {i+1}: {test_case}')

# 输出
Test Case 1: ['特快运', '文件', '寄付月结', '使用京尊达']
Test Case 2: ['特快运', '家电', '寄付现结', '签单返还']
Test Case 3: ['特快运', '数码产品', '到付现结', '不签返']
Test Case 4: ['特惠运', '文件', '寄付现结', '不签返']
Test Case 5: ['特惠运', '家电', '到付现结', '使用京尊达']
Test Case 6: ['特惠运', '数码产品', '寄付月结', '签单返还']
Test Case 7: ['生鲜特快', '文件', '到付现结', '签单返还']
Test Case 8: ['生鲜特快', '家电', '寄付月结', '不签返']
Test Case 9: ['生鲜特快', '数码产品', '寄付现结', '使用京尊达']

Process finished with exit code 0

注意：如果各个因子的状态数是不统一的，几乎不可能出现均匀的情况时，选择正交表为 等于或略大于因子数，状态数，且试验次数最少

• 正交试验的实例表可套用到用例中

• 正交试验的实例表可套用到用例中 

也可以使用：正交法设计测试用例的小工具：Allpairs

https://www.softpedia.com/dyn-search.php?search_term=allpairs

jdtest.xls

复制到记事本jdtest.txt中

打开cmd命令行工具,进入Allpairs解压后所在的路径

E:\software-fan\pairs>allpairs.exe jdtest.txt>jdtest2.txt

输出：

错误猜测法

基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的 方法.

错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况, 根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前 产品测试中曾经发现的错误等, 这些就是经验的总结. 还有, 输入数据和输出数据为 0 的情况. 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况. 可选择 这些情况下的例子作为测试用例.

场景法：

通过场景描述的业务流程（业务逻辑），也包括代码实现逻辑。设计用例来遍历场景（路径），验证软件系统功能的正确性。

1、为什么用场景法设计测试用例？

大多数业务软件由后台管理（比如：用户管理、角色管理、权限管理等等各种管理）和工作流等几个部分组成。终端用户，期望软件能够实现业务需求，而不是简单的功能的组合。对于单点功能利用等价类、边界值、判定表用例设计方法能够解决大部分问题。涉及业务流程的软件系统，采用场景法比较合适。

2、什么是场景法？

场景业务流通常分为基本流、备选流、异常流程

基本流：基本流表示通过业务流程时输入都正确，能达到目标的流程。(插卡–》输入正确密码–》输入金额–》取款–》取卡)

备选流：备选流表示通过业务流程时输入错误（或者操作错误）导致流程存在反复，但是经过纠正后仍能达到能达到目标的流程.（插卡–>输入错误密码–》输入正确密码–》输入金额–》取款–》取卡）

异常流：异常流表示通过业务流程时输入错误（或者操作错误）产生异常终止流程 （插卡–>输入3次错误密码–》吞卡） .

3、场景法设计测试用例的步骤？

步骤一:理解需求，确定业务流程（基本流程、备选流程、异常流程）

步骤二：绘制流程图，再次确认流程路径

步骤三：根据业务流程图，抽取测试路径（每一路径需含一个未走过得路径）

步骤四：细化路径，利用等价类边界值方法细化路径，抽取测试用例

4、场景法设计测试用例的优缺点？

优点：涉及到业务流程的业务需求适合用场景法

缺点：只验证业务流程，不验证单点功能，一般先采用先用等价类，边界值，错误推断，判定表等方法对单点功能进行验证，验证通过后再采用场景法进行业务流程的验证。

用例场景例子

用户登录到网站后，进行书籍的选择，当选好自己心仪的书籍后进行订购，这时把所需图书放进购物车，等进行结帐的时候，用户需要登录自己注册的帐号，登录成功后，进行付款交易，交易成功后，生成订购单，整个购物过程结束。

第一步：画出流程图，确定基本流和备选流；

基本流：登录在线网站→选择书籍→放入购物车→登录账号→付款→生成订单

备选流１：用户不存在→注册用户

备选流２：密码不正确

备选流３：账户余额不足→充值

第二步：根据基本流和各项备选流确定场景；

场景１（成功购物）：基本流；

场景２（账户不存在）：基本流 备选流１

场景３（账户密码错误）：基本流 备选流２

场景４（账户余额不足）：基本流 备选流3

第三步：对每一个场景生成测试用例；

状态迁移法

状态迁移法主要关注在测试状态转移的正确性上面。对于一个有限状态机，通过测试验证其在给定的条件内是否能够产生需要的状态变化，有没有不可达的状态和非法的状态，是否可能产生非法的状态转移等。通过构造能导致状态迁移的事件，来测试状态之间的转换。

该方法适合功能的状态比较多的情况下，需测试各种状态的转换，且这些状态转换的测试在实际工作中容易被遗漏。比如播放器、遥控按键等。

状态迁移法的步骤

1. 分析需求，整理所有状态；

2. 画出状态迁移图；

3. 列出状态-事件表；

4. 得到状态转换树(测试路径)；

5. 根据状态转换树得到测试用例

案例

得到测试路径：

1. 未支付–> 已取消

2. 未支付–> 已支付–> 已出票–> 改签成功–> 退票成功

3. 未支付–> 已支付–> 已出票–> 改签成功–> 已使用

4. 未支付–> 已支付–> 已出票–> 退票成功

5. 未支付–> 已支付–> 已出票–> 已使用

6. 未支付–> 已支付–> 改签成功–> 退票成功

7. 未支付–> 已支付–> 改签成功–> 已使用

8. 未支付–> 已支付–> 退票成功

9. 未支付–> 已支付–> 已使用

详细的描述一次测试用例设计的完整的过程。

就说最近的这次网站功能的测试吧

首先：得到相关文档（需求文档和设计文档），理解需求和设计思想后，想好测试 策略（测试计划简单点就 OK 了），考虑到测试环境，测试用例，测试时间等问题。

第二步：设计测试用例，测试策略是：把网站部分的功能点测试完，然后在进行系统测 试（另外个模块呢有另一个测试人员负责，可以进行联调测试），网站模块的测试基本 是功能测试和界面测试（用户并发的可能性很小，所以不考虑）：这次的网站的输入数 据呢是使用数据库中的某张表记录，如果表中某一数据记录中新加进来的（还没有被处 理的，有个标志位），网站启动后会立刻去刷那张表，得到多条数据，然后在进行处理。 处理过程中，会经历 3 个步骤，网站才算完成了它的任务。有 3 个步骤呢，就可以分别 对 这 3 个步骤进行测试用例的设计,尽量覆盖到各种输入情况（包括数据库中的数据， 用户的输入等），得出了差不多 50 个用例。界面测试，也就是用户看的到的地方，包括 发送的邮件和用户填写资料的页面展示。

第三步：搭建测试环境（为什么这个时候考虑测试环境呢?因为我对网站环境已经很熟 了，只有有机器能空于下来做该功能测试就可以做了），因为网站本身的环境搭建和其 他的系统有点不同，它需要的测试环境比较麻烦，需要 web 服务器（Apache,tomcat）， 不过这次需求呢，网站部分只用到了 tomcat，所以只要有 tomcat 即可

第四步：执行测试

总结

测试案例

1. 用例设计：根据下面需求，进行测试用例设计，请注意对测试点的表达。（网页端）

需求描述：

某项目的营养素配置页面，供用户用来配置营养素的相关信息，其中：

• 项目可供用户选择一种或多种营养素；

• 点击每行尾部的“+”可以增加一行输入框，点击每行尾部的“-”会删除当前行；

• 每种营养素都包括默认推荐量；

• 推荐量分为单值和范围两种形式，其中，单值为单一输入框，范围则填写推荐量的推荐范围；

• 点击确认按钮保存配置中信息。

答案参考：

• 用例1：配置1种营养素。营养素名称选择第1个，单位选择第1个，默认推荐量选择单值，自动显示默认推荐量；点击确认，查看营养素配置信息:正确显示

• 用例2：配置2种营养素。营养素名称分别选择中间1个、最后1个；营养素单位分别选择中间1个、最后1个；默认推荐量分别选择单值(输入数值-整数)、选择范围(输入小数)；点击确认，查看营养素配置信息:正确显示

• 用例3：点击+，配置多种营养素，多种营养素有无上限；超过上限有无提示

• 用例4：点击+，配置多种营养素；然后点击-，正常删除当行；点击确认后，正常显示营养素配置

• 用例5：配置多种营养素后，点击-，减的下限验证

• 用例6：配置多种营养素，营养素名称重复，点击确定，给予不予重复提示

• 用例7：配置营养素，默认推荐量输入超出范围、非数字；点击确定，给予异常提示

• 用例8：配置营养素，必填信息为空，点击确定，给予不能为空提示

• 用例9：配置营养素，营养配比失调，是否给予提醒

2. 用例设计：根据下面的需求，进行测试用例设计，请注意对测试点的表达。（APP端）

需求描述：

APP心率显示页显示当前用户的心率信息（数据来源不需要考虑），具体包括：

• 心率信息按日、周、月、年形式下的心率数据，默认展示日的形式，点击周、日、年可切换到其他展示形式；

• 日的形式下，显示单日0-24时以每半小时为单位的心率数据；

• 显示各半小时的最大、最小值，以柱状图形式展示；

• 点击任意半小时的柱状图，显示该柱状图对应的时间和心率信息，并在图下方的表格中显示对应数据；

• 左右滑动可查看其它日期的相关信息。

答案参考：

• 用例1：当前系统时间0:10分，进入心率页面-默认日形式。查看心率数据，是否实时显示1条柱状形；若无显示，是否给予用户友好提示

• 用例2：当前系统时间x点，例9:10点，进入心率页面-默认日形式。心率数据是否每半小时显示1个柱状形（假设心率数据从0-x小时是完整的，显示若不完整，需对比查看系统数据库存储的心率数据）；选择第1个柱状形、中间选择1个、最后1个柱状形：时间区间是否正确、心率最小值-最大值是否正确（与查询的数据库心率数据一致）

• 用例3：当前系统时间23:59分，进入心率数据-日形式，查看当日心率数据，是否每半小时总共显示24条柱状形(假设心率数据从0-24小时是完整的，显示若不完整，需对比查看系统数据库存储的心率数据)；点击第1个、最后1个柱状形：时间区间是否正确、心率最小值-最大值是否正确（与查询的数据库心率数据一致）

• 用例4：左右滑动，查看上一日、下一日心率数据，正常显示当天心率数据，包括柱状形数量、选择第1个/最后1个单个柱状形日期、心率范围正确性（对比数据库验证一致性）

• 用例5：切换周形式(当前周/上一周/下一周)，查看心率柱状形数量、第1个/最后1个单一柱状形的日期、心率范围是否正确（对比数据库验证一致性）

• 用例6：切换月形式(当前月/上一月/下一月)，查看心率柱状形数量、第1个/最后1个单一柱状形的日期、心率范围是否正确（对比数据库验证一致性）

• 用例7：切换年形式(当前年/上一年/下一年)，查看心率柱状形数量、第1个/最后1个单一柱状形的日期、心率范围是否正确（对比数据库验证一致性）

• 用例8：切换日/周/月/年，点击右上角”i“，正常显示心率查看帮助说明

• 用例9：点击左上角”←“，正常返回上一级

参考文档