标签：

白盒测试：理论基础

2016-08-23

目录

1 白盒测试的概念
2 白盒测试的主要目的
3 测试覆盖标准
4 白盒测试的主要方法
  4.1 逻辑驱动测试
    4.1.1 语句覆盖
    4.1.2 判定覆盖（分支覆盖）
    4.1.3 条件覆盖
    4.1.4 判定/条件覆盖
    4.1.5 条件组合覆盖
    4.1.6 黑盒法补充测试用例
  4.2 路径测试
    4.2.1 基本路径测试
      1) 控制流图
      2) 独立路径
      3) 基本路径测试
      4) 工具方法：图形矩阵
5 控制结构测试的其他变种
  5.1 条件测试
    5.1.1 条件
    5.1.2 条件测试的目的
    5.1.3 条件测试策略
  5.2 循环测试
6 面向对象的白盒测试
  6.1 类测试方式
    6.1.1 结构性测试
7 白盒测试工具
8 总结

1 白盒测试的概念

 返回

白盒测试也称结构测试或逻辑驱动测试，是一种测试用例设计方法，它从程序的控制结构导出测试用例。（测试用例由测试输入数据以及与之对应的输出结果组成。）

白盒测试使用被测单元内部如何工作的信息，允许测试人员对程序内部逻辑结构及有关信息来设计和选择测试用例，对程序的逻辑路径进行测试。基于一个应用代码的内部逻辑知识，测试是基于覆盖全部代码、分支、路径、条件。

2 白盒测试的主要目的

 返回

• 保证一个模块中的所有独立路径至少被执行一次；
• 对所有的逻辑值均需要测试真、假两个分支；
• 在上下边界及可操作范围内运行所有循环；
• 检查内部数据结构以确保其有效性。

3 测试覆盖标准

 返回

白盒法特点：以程序的内部逻辑为基础设计测试用例，所以又称为逻辑覆盖法。应用白盒法时，手头必须有程序的规格说明以及程序清单。

白盒法考虑的是测试用例对程序内部逻辑的覆盖程度。最彻底的白盒法是覆盖程序中的每一条路径，但是由于程序中一般含有循环，所以路径的数目极大，要执行每一条路径是不可能的，只能希望覆盖的程度尽可能高些。

图1 程序流程图

图1包括了一个执行达20次的循环。那么它所包含的不同执行路径数高达5²⁰（＝10¹³）条，若要对它进行穷举测试，覆盖所有的路径。假使测试程序对每一条路径进行测试需要1毫秒，同
样假定一天工作24小时，一年工作365天， 那么要想把如图所示的小程序的所有路径测试完，则需要3170年。

为了衡量测试的覆盖程度，需要建立一些标准，目前常用的一些覆盖标准从低到高分别是：

• 语句覆盖：是一个比较弱的测试标准，它的含义是：选择足够的测试用例，使得程序中每个语句至少都能被执行一次。它是最弱的逻辑覆盖，效果有限，必须与其它方法交互使用。
• 判定覆盖（也称为分支覆盖）：执行足够的测试用例，使得程序中的每一个分支至少都通过一次。判定覆盖只比语句覆盖稍强一些，但实际效果表明，只是判定覆盖，还不能保证一定能查出在判断的条件中存在的错误。因此，还需要更强的逻辑覆盖准则去检验判断内部条件。
• 条件覆盖：执行足够的测试用例，使程序中每个判断的每个条件的每个可能取值至少执行一次；条件覆盖深入到判定中的每个条件，但可能不能满足判定覆盖的要求。
• 判定/条件覆盖：执行足够的测试用例，使得判定中每个条件取到各种可能的值，并使每个判定取到各种可能的结果。判定/条件覆盖有缺陷。从表面上来看，它测试了所有条件的取值。但是事实并非如此。往往某些条件掩盖了另一些条件。会遗漏某些条件取值错误的情况。为彻底地检查所有条件的取值，需要将判定语句中给出的复合条件表达式进行分解，形成由多个基本判定嵌套的流程图。这样就可以有效地检查所有的条件是否正确了。
• 条件组合覆盖：执行足够的例子，使得每个判定中条件的各种可能组合都至少出现一次。这是一种相当强的覆盖准则，可以有效地检查各种可能的条件取值的组合是否正确。它不但可覆盖所有条件的可能取值的组合，还可覆盖所有判断的可取分支，但可能有的路径会遗漏掉。测试还不完全。

4 白盒测试的主要方法

 返回

1. 逻辑驱动测试
• 语句覆盖
• 判定覆盖（分支覆盖）
• 条件覆盖
• 判定/条件覆盖
• 条件组合覆盖

2. 基本路径测试

• 设计足够多的测试用例，运行所测程序，要覆盖程序中所有可能的路径。这是最强的覆盖准则。但在路径数目很大时，真正做到完全覆盖是很困难的，必须把覆盖路径数目压缩到一定限度。

4.1 逻辑驱动测试

4.1.1 语句覆盖

程序1如下：

PROCEDURE M(VAR A，B，X：REAL)；
BEGIN
IF (A>1) AND (B=0) THEN X:=X/A ；
IF (A=2) OR (X>1) THEN X:=X+1 ；
END

图2 程序流程图

为使程序中每个语句至少执行一次，只需设计一个能通过路径ace的例子就可以了，就可达到“语句覆盖”标准。例如选择输入数据为：

A=2，B=0，X=3

缺点： 从上例可看出，语句覆盖实际上是很弱的

• 如果第一个条件语句中的AND错误地编写成OR，上面的测试用例是不能发现这个错误的；
• 又如第三个条件语句中X＞1误写成X＞0，这个测试用例也不能暴露它；
• 此外，沿着路径abd执行时，X的值应该保持不变，如果这一方面有错误，上述测试数据也不能发现它们。 

4.1.2 判定覆盖（分支覆盖） 

对程序1，如果设计两个用例，使它们能通过路径ace和abd，或者通过路径acd和abe，就可达到“判定覆盖”标准，为此，可以选择输入数据为：

• A=3，B=0，X=1 (沿路径acd执行)；
• A=2，B=1，X=3(沿路径abe执行)

优点：“分支覆盖”比“语句覆盖”严格，因为如果每个分支都执行过了，则每个语句也就执行过了。

缺点：但是，“分支覆盖”还是很不够的

• 两个测试用例未能烤炉到A<=1的情况
• 两个测试用例未能检查沿着路径abd执行时，X的值是否保持不变。

4.1.3 条件覆盖

一个判定中往往包含了若干个条件，如程序中，判定 (A＞1) AND (B=0)包含了两个条件： A＞1以及 B=0，所以可引进一个更强的覆盖标准——“条件覆盖”。

程序1有四个条件：

A＞1 、B=0、A=2、X＞1
为了达到“条件覆盖”标准，需要执行足够的测试用例使得在a点有：
A＞1、A≤1、B=0、B≠0
以及在b点有：
A=2、A≠2、X＞1、X≤1
现在只需设计以下两个测试用例就可满足这一标准：

• A=2，B=1，X=4 (沿路径abe执行)；
• A=1，B=0，X=1 (沿路径abd执行)。

优点：“条件覆盖”通常比“分支覆盖”强，因为它使一个判定中的每一个条件都取到了两个不同的结果，而判定覆盖则不保证这一点。

缺点：“条件覆盖”并不包含“分支覆盖”，如两个用例没有有覆盖判定（A>1 and B=0）为True的情况

4.1.4 判定/条件覆盖

程序1，以下用例是满足判定/条件覆盖：

• A=2，B=0，X=4 (沿ace路径)
• A=1，B=1，X=1 (沿abd路径)

优点：既有“条件覆盖”，又有“判定覆盖”

缺点：分支/条件覆盖从表面来看，它测试了所有条件的取值，但是实际上某些条件掩盖了另一些条件。 

• 对于第一个表达式（A>1 and B=0）如果（A＞1）为假则一般的编译器不在判断是否B=0了。
• 对于第二个表达式（A=2 or X>1）来说，若A=2测试结果为真，就认为表达式的结果为真，这时不再检查（X>1）条件了。

因此，采用分支/条件覆盖，逻辑表达式中的错误不一定能够查出来了。

4.1.5 条件组合覆盖

程序1，以下用例是满足条件组合覆盖：

再看程序1，我们需要选择适当的用例，使得下面 8种条件组合都能够出现：

1) A>1, B=0　　2) A>1, B≠0　　3) A≤1, B=0　　4) A≤1, B≠0

5) A=2, X>1　　6) A=2, X≤1　　7) A≠2, X>1　　8) A≠2, X≤1

5) 、6) 、7)、8)四种情况是第二个 IF语句的条件组合，而X的值在该语句之前是要经过计算的，所以还必须根据程序的逻辑推算出在程序的入口点X的输入值应是什么。

下面设计的四个用例可以使上述 8种条件组合至少出现一次：

• A=2，B=0，X=4 使 1)、5)两种情况出现 (沿ace路径)；
• A=2，B=1，X=1 使 2)、6)两种情况出现 (沿abd路径)；
• A=1，B=0，X=2 使 3)、7)两种情况出现 (沿abe路径)；
• A=1，B=1，X=1 使 4)、8)两种情况出现 (沿abd路径)。

优点：既有“条件覆盖”，又有“判定覆盖”，还有“条件组合覆盖”

缺点：上面四个例子虽然满足条件组合覆盖，但并不能覆盖程序中的每一条路径，例如路径acd就没有执行

4.1.6 黑盒法补充测试用例

通过前面逻辑驱动测试方法，可以得到两点结论：

• “条件组合覆盖”标准比其他标准优越。
• 即使达到任何一种覆盖标准，其测试效果仍然是不彻底的，我们还需要用其他的测试方法作补充。

一个参考的黑盒法补充策略是：

1) 在任何情况下都需使用边界值分析(这个方法应包括对输入和输出的边界值进行分析)。
2) 必要的话，再用等价分类法补充一些测试用例。
3) 再用错误推测法附加测试用例。
4) 检查上述例子的逻辑覆盖程度，如果未能满足某些覆盖标准，则再增加足够的测试用例。
5) 如果功能说明中含有输入条件的组合情况，则一开始就可先用因果图(判定表)法。

4.2 路径测试

路径测试就是设计足够多的测试用例，覆盖被测试对象中的所有可能路径。

4.2.1 基本路径测试

程序1是很简单的程序函数，只有四条路径。但在实践中，一个不太复杂的程序，其路径都是一个庞大的数字，要在测试中覆盖所有的路径是不现实的。为了解决这一难题，只得把覆盖的路径数压缩到一定限度内，例如，程序中的循环体只执行一次。

基本路径测试就是这样一种测试方法，它在程序控制图的基础上，通过分析控制构造的环行复杂性，导出基本可执行路径集合，从而设计测试用例的方法。设计出的测试用例要保证在测试中程序的每一个可执行语句至少执行一次。

在程序控制流图的基础上，通过分析控制构造的环路复杂性，导出基本可执行路径集合，从而设计测试用例。包括以下4个步骤和一个工具方法：

1. 程序的控制流图：描述程序控制流的一种图示方法。
2. 程序圈复杂度：McCabe复杂性度量。从程序的环路复杂性可导出程序基本路径集合中的独立路径条数，这是确定程序中每个可执行语句至少执行一次所必须的测试用例数目的上界。
3. 导出测试用例：根据圈复杂度和程序结构设计用例数据输入和预期结果。
4. 准备测试用例：确保基本路径集中的每一条路径的执行。

工具方法：

1. 图形矩阵：是在基本路径测试中起辅助作用的软件工具，利用它可以实现自动地确定一个基本路径集。

1) 控制流图

在介绍基本路径方法之前，必须先介绍一种简单的控制流表示方法，即流图。流图是对待测试程序过程处理的一种表示。流图使用下面的符号描述逻辑控制流，每一种结构化构成元素有一个相应的流图符号。

图3 流图符号

流图只有二种图形符号

• 图中的每一个圆称为流图的结点，代表一条或多条语句。
• 流图中的箭头称为边或连接，代表控制流。

任何过程设计都要被翻译成控制流图。

在将程序流程图简化成控制流图时，应注意：

• 在选择或多分支结构中，分支的汇聚处应有一个汇聚结点。
• 边和结点圈定的区域叫做区域，当对区域计数时，图形外的区域也应记为一个区域。

图4 控制流图

如果判断中的条件表达式是由一个或多个逻辑运算符 (OR, AND) 连接的复合条件表达式，则需要改为一系列只有单条件的嵌套的判断。

图5 程序结构转化成流图

2) 独立路径

独立路径：至少沿一条新的边移动的路径

图6 独立路径

对以上路径的遍历，就是至少一次地执行了程序中的所有语句

3) 基本路径测试 

第一步：画出控制流图

流程图用来描述程序控制结构。可将流程图映射到一个相应的流图(假设流程图的菱形决定框中不包含复合条件)。

• 流图中圆，称为流图的结点，代表一个或多个语句。一个处理方框序列和一个菱形决测框可被映射为一个结点；
• 流图中的箭头，称为边或连接，代表控制流，类似于流程图中的箭头。一条边必须终止于一个结点，即使该结点并不代表任何语句(例如：if-else-then结构)；
• 由边和结点限定的范围称为区域。计算区域时应包括图外部的范围。

图7 程序流程图

图8 程序流程图和对应的控制流图

第二步：计算圈复杂度

圈复杂度是一种为程序逻辑复杂性提供定量测度的软件度量，将该度量用于计算程序的基本的独立路径数目，为确保所有语句至少执行一次的测试数量的上界。

独立路径必须包含一条在定义之前不曾用到的边。

有以下三种方法计算圈复杂度：

1. 流图中区域的数量对应于环型的复杂性；
2. 给定流图G的圈复杂度V(G)，定义为V(G)=E-N+2，E是流图中边的数量，N是流图中结点的数量；
3. 给定流图G的圈复杂度V(G)，定义为V(G)=P+1，P是流图G中判定结点的数量。

第三步：导出测试用例

根据上面的计算方法，可得出四个独立的路径。(一条独立路径是指，和其他的独立路径相比，至少引入一个新处理语句或一个新判断的程序通路。V(G)值正好等于该程序的独立路径的条数。)

• 路径1：4-14
• 路径2：4-6-7-14
• 路径3：4-6-8-10-13-4-14
• 路径4：4-6-8-11-13-4-14

第四步：准备测试用例

为了确保基本路径集中的每一条路径的执行，根据判断结点给出的条件，选择适当的数据以保证某一条路径可以被测试到，满足上面例子基本路径集的测试用例是：

路径1：4-14
输入数据：iRecordNum＝0，或者取iRecordNum<0的某一个值　　预期结果：x＝0

路径2：4-6-7-14
输入数据：iRecordNum＝1,iType＝0　　预期结果：x＝2

路径3：4-6-8-10-13-4-14
输入数据：iRecordNum＝1,iType＝1　　预期结果：x＝10

路径4：4-6-8-11-13-4-14
输入数据：iRecordNum＝1,iType＝2　　预期结果：x＝20

必须注意，一些独立的路径，往往不是完全孤立的，有时它是程序正常的控制流的一部分，这时，这些路径的测试可以是另一条路径测试的一部分。

4) 工具方法：图形矩阵

导出控制流图和决定基本测试路径的过程均需要机械化，为了开发辅助基本路径测试的软件工具，称为图形矩阵(graph matrix)的数据结构很有用。

利用图形矩阵可以实现自动地确定一个基本路径集。一个图形矩阵是一个方阵

• 其行/列数控制流图中的结点数，每行和每列依次对应到一个被标识的结点，
• 矩阵元素对应到结点间的连接（即边）。

对每个矩阵项加入连接权值(link  weight)，图矩阵就可以用于在测试中评估程序的控制结构，连接权值为控制流提供了另外的信息。最简单情况下，连接权值是 1(存在连接)或0(不存在连接)，但是，连接权值可以赋予更有趣的属性：

• 执行连接(边)的概率。
• 穿越连接的处理时间。
• 穿越连接时所需的内存。
• 穿越连接时所需的资源。

图9 图形矩阵

连接权为“1”表示存在一个连接，在图中如果一行有两个或更多的元素“1”，则这行所代表的结点一定是一个判定结点，通过连接矩阵中有两个以上（包括两个）元素为“1”的个数，就可以得到确定该图圈复杂度的另一种算法。

5 控制结构测试的其他变种

 返回

前面所述的基本路径测试技术是控制结构测试技术之一。尽管基本路径测试简单高效，但是，其本身并不充分。下面讨论控制结构测试的其他变种，这些测试覆盖并提高了白盒测试的质量。包括：

1. 条件测试
2. 数据流测试 （略）
3. 循环测试。

5.1 条件测试

条件测试方法注重于测试程序中的条件。是检查程序模块中所包含逻辑条件的测试用例设计方法。

5.1.1 条件

程序中的条件分为简单条件和复合条件。

简单条件是一个布尔变量或一个可能带有NOT(“！”)操作符的关系表达式。关系表达式的形式如：

E1＜关系操作符＞E2

其中E1和E2是算术表达式，而＜关系操作符＞是下列之一：“＜”、“≤”、“=”、“≠”(“！=”)、“＞”、或“≥”。

复合条件由简单条件通过逻辑运算符（AND、OR、NOT）和括号连接而成，不含关系表达式的条件称为布尔表达式。

所以条件的成分类型包括：布尔操作符、布尔变量、布尔括弧(括住简单或复杂条件)、关系操作符、算术表达式。

5.1.2 条件测试的目的

条件测试是测试程序条件错误和程序的其他错误。如果程序的测试集能够有效地检测程序中的条件错误，则该测试集可能也会有效地检测程序中的其他错误。此外，如果测试策略对检测条件错误有效，则它也可能有效地检测程序错误。

5.1.3 条件测试策略

1) 穷举测试（条件组合）

有n个变量的布尔表达式需要2ⁿ个可能的测试(n＞0)。这种策略可以发现布尔操作符、变量和括弧的错误，但是只有在n很小时实用。

2) 分支测试

分支测试可能是最简单的条件测试策略，它是真假分支必须至少执行一次的路径策略，对于复合条件C，C的真分支和假分支以及C中的每个简单条件都需要至少执行一次。

域测试是对于大于、小于和等于值的测试路径策略。域测试要求从有理表达式中导出三个或四个测试，有理表达式的形式如：

E1＜关系操作符＞E2

需要三个测试分别用于计算E1的值是大于、等于或小于E2的值。如果＜关系操作符＞错误，而E1和E2正确，则这三个测试能够发现关系算子的错误。为了发现E1和E2的错误，计算E1小于或大于E2的测试应使两个值间的差别尽可能小。

3) BRO(branch and relational) 测试

如果在一个判定的复合条件表达式中每个布尔变量和关系运算符最多只出现一次，而且没有公共变量，应用一种称之为BRO（分支与关系运算符）的测试法可以发现多个布尔运算符或关系运算符错，以及其他错误。

BRO策略引入条件约束的概念。设有n个简单条件的复合条件C，其条件约束为D= (D₁，D₂，…，D_n) ，其中D_i(0＜i≤n)是条件C中第i个简单条件的输出约束。如果在C的执行过程中，其每个简单条件的输出都满足D中对应的约束，则称条件C的条件约束D由C的执行所覆盖。对于布尔变量或布尔表达式B，B的输出约束必须是真（t）或假（f）；对于关系表达式，其输出约束为符号>、=、< 。

5.2 循环测试

循环测试是一种白盒测试技术，注重于循环构造的有效性。

有四种循环：简单循环，串接(连锁)循环，嵌套循环、不规则循环。

图10 循环结构

对于简单循环，测试应包括以下几种，其中的n表示循环允许的最大次数。

1. 零次循环：从循环入口直接跳到循环出口。
2. 一次循环：查找循环初始值方面的错误。
3. 二次循环：检查在多次循环时才能暴露的错误。
4. m次循环：此时的m＜n，也是检查在多次循环时才能暴露的错误。
5. n(最大)次数循环、n+1(比最大次数多一)次的循环、n-1(比最大次数少一)次的循环。

对于嵌套循环，不能将简单循环的测试方法简单地扩大到嵌套循环，因为可能的测试数目将随嵌套层次的增加呈几何倍数增长。这可能导致一个天文数字的测试数目。下面是一种有助于减少测试数目的测试方法。
从最内层循环开始，设置所有其他层的循环为最小值；

1. ? 对最内层循环做简单循环的全部测试。测试时保持所有外层循环的循环变量为最小值。另外，对越界值和非法值做类似的测试。
2. ? 逐步外推，对其外面一层循环进行测试。测试时保持所有外层循环的循环变量取最小值，所有其它嵌套内层循环的循环变量取“典型”值。
3. ? 反复进行，直到所有各层循环测试完毕。
4. ? 对全部各层循环同时取最小循环次数，或者同时取最大循环次数。对于后一种测试，由于测试量太大，需人为指定最大循环次数。

对于串接循环，要区别两种情况。

• 如果各个循环互相独立，则串接循环可以用与简单循环相同的方法进行测试。
• 如果有两个循环处于串接状态，而前一个循环的循环变量的值是后一个循环的初值。则这几个循环不是互相独立的，则需要使用测试嵌套循环的办法来处理。

对于非结构循环，不能测试，应重新设计循环结构，使之成为其它循环方式，然后再进行测试。

6 面向对象的白盒测试

 返回

对OO软件的类测试相当于传统软件的单元测试。和传统软件的单元测试不同，他往往关注模块的算法细节和模块接口间流动的数据，OO软件的类测试是由封装在类中的操作和类的状态行为所驱动的。OO软件测试的特点：

• 因为属性和操作是被封装的，对类之外操作的测试通常是徒劳的。封装使对对象的状态快照难于获得。
• 继承也给测试带来了难度，即使是彻底复用的，对每个新的使用语境也需要重新测试。
• 多重继承更增加了需要测试的语境的数量，使测试进一步复杂化。如果从超类导出的测试用例被用于相同的问题域，有可能对超类导出的测试用例集可以用于子类的测试，然而，如果子类被用于完全不同的语境，则超类的测试用例将没有多大用途，必须设计新的测试用例集。

6.1 类测试方式

类测试一般有两种主要的方式：

功能性测试和结构性测试，即对应于传统结构化软件的黑盒测试和白盒测试：

• 功能性测试以类的规格说明为基础，它主要检查类是否符合其规格说明的要求。例如，对于Stack类，即检查它的操作是否满足LIFO规则；
• 结构性测试则从程序出发，它需要考虑其中的代码是否正确，同样是Stack类，就要检查其中代码是否动作正确且至少执行过一次。

6.1.1 结构性测试

结构性测试对类中的方法进行测试，它把类作为一个单元来进行测试。测试分为两层：

• 第一层考虑类中各独立方法的代码；
• 第二层考虑方法之间的相互作用。

每个方法的测试要求能针对其所有的输入情况，但这样还不够，只有对这些方法之间的接口也做同样测试，才能认为测试是完整的。

对于一个类的测试要保证类在其状态的代表集上能够正确工作，构造函数的参数选择以及消息序列的选择都要满足这一准则。因此，在这两个不同的测试层次上应分别做到：

• 方法的单独测试：结构性测试的第一层是考虑各独立的方法，这可以与过程的测试采用同样的方法，两者之间最大的差别在于方法改变了它所在实例的状态，这就要取得隐藏的状态信息来估算测试的结果，传给其它对象的消息被忽略，而以桩来代替，并根据所传的消息返回相应的值，测试数据要求能完全覆盖类中代码，可以用传统的测试技术来获取。
• 方法的综合测试：第二层要考虑一个方法调用本对象类中的其它方法和从一个类向其它类发送信息的情况。单独测试一个方法时，只考虑其本身执行的情况。而没有考虑动作的顺序问题，测试用例中加入了激发这些调用的信息，以检查它们是否正确运行了对于同一类中方法之间的调用，一般只需要极少甚至不用附加数据，因为方法都是对类进行存取，故这一类测试的准则是要求遍历类的所有主要状态。

7 白盒测试工具

 返回

内存资源泄漏检查：Numega中的bouncechecker,Rational的Purify等；

代码覆盖率检查：Numega中的truecoverage,Rational的Purecoverage，Telelogic公司的logiscope,Macabe公司的Macabe等；

开源覆盖率测试软件gCov等。

8 总结

 返回

8.1 白盒测试的主要方法的优缺点 

8.2 白盒测试的局限性

“白盒”法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。“白盒”法是穷举路径测试。在使用这一方案时，测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。贯穿程序的独立路径数是天文数字。但即使每条路径都测试了仍然可能有错误：

• 第一、穷举路径测试决不能查出程序违反了设计规范，即程序本身是个错误的程序；
• 第二、穷举路径测试不可能查出程序中因遗漏路径而出错。
• 第三、穷举路径测试可能发现不了一些与数据相关的错误。

白盒测试：理论基础

标签：

原文地址：http://www.cnblogs.com/Ming8006/p/5798186.html