项目测试操作过程及方法.docx
《项目测试操作过程及方法.docx》由会员分享，可在线阅读，更多相关《项目测试操作过程及方法.docx（19页珍藏版）》请在冰豆网上搜索。
项目测试操作过程及方法
项目测试操作过程及方法
拟制：
杨冬
日期：
2016-2-16
审核：
日期：
修订记录
日期
修订版本
描述
作者
1概述
本规范是对软件测试的一份指导性文件，对软件测试过程中所涉及到的测试理论、测试类型、测试方法、测试标准、测试流程以及软件产品开发单位所承担的职责进行总体规范，以有效保证软件产品的质量。
2软件测试理论
什么是软件测试
无论怎样强调软件测试的重要性和它对软件可靠性的影响都不过分。
在开发大型软件系统的漫长过程中，面对着极其错综复杂的问题，人的主观认识不可能完全符合客观现实，与工程密切相关的各类人员之间的通信和配合也不可能完美无缺，因此，在软件生命周期的每个阶段都不可避免地会产生差错。
我们力求在每个阶段结束之前通过严格的技术审查，尽可能早地发现并纠正差错；但是，经验表明审查并不能发现所有差错，此外在编码过程中还不可避免地会引入新的错误。
如果在软件投入生产性运行之前，没有发现并纠正软件中的大部分差错，则这些差错迟早会在生产过程中暴露出来，那时不仅改正这些错误的代价更高，而且往往会造成很恶劣的后果。
测试的目的就是在软件投入生产性运行之前，尽可能多地发现软件中的错误。
目前软件测试仍然是保证软件质量的关键步骤，它是对软件规格说明、设计和编码的最后复审。
软件测试在软件生命周期中横跨两个阶段。
通常在编写出每个模块之后就对它做必要的测试（称为单元测试），模块的编写者和测试者是同一个人，编码和单元测试属于软件生命周期的同一个阶段。
在这个阶段结束之后，对软件系统还应该进行各种综合测试，这是软件生命周期中的另一个独立的阶段，通常由专门的测试人员承担这项工作。
大量统计资料表明，软件测试的工作量往往占软件开发总工作量的40％以上，在极端情况，测试那种关系人的生命安全的软件所花费的成本，可能相当于软件工程其他开发步骤总成本的三倍到五倍。
因此，必须高度重视软件测试工作，绝不要以为写出程序之后软件开发工作就接近完成了，实际上，大约还有同样多的开发工作量需要完成。
仅就测试而言，它的目标是发现软件中的错误，但是，发现错误并不是我们的最终日的。
软件工程的根本目标是开发出高质量的完全符合用户需要的软件。
软件测试的目标
下面这些规则也可以看作是测试的目标或定义：
（1）测试是为了发现程序中的错误而执行程序的过程；
（2）好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案；
（3）成功的测试是发现了至今为止尚未发现的错误的测试。
从上述规则可以看出，测试的正确定义是“为了发现程序中的错误而执行程序的过程”。
这和某些人通常想象的“测试是为了表明程序是正确的”，“成功的测试是没有发现错误的测试”等等是完全相反的。
正确认识测试的目标是十分重要的，测试目标决定了测试方案的设计。
如果为了表明程序是正确的而进行测试，就会设计一些不易暴露错误的测试方案；相反，如果测试是为了发现程序中的错误，就会力求设计出最能暴露错误的测试方案。
由于测试的目标是暴露程序中的错误，从心理学角度看，由程序的编写者自己进行测试是不恰当的。
因此，在综合测试阶段通常由其他人员组成测试小组来完成测试工作。
此外，应该认识到测试决不能证明程序是正确的。
即使经过了最严格的测试之后，仍然可能还有没被发现的错误潜藏在程序中。
测试只能查找出程序中的错误，不能证明程序中没有错误。
3软件测试流程
软件测试流程图
软件测试流程细则
需求分析
测试人员和开发人员均应参加需求评审、设计评审。
对《需求说明书》、《系统界面原型》和《软件设计说明书》等进行阅读和审查，与产品经理、项目经理沟通，了解并熟悉系统业务逻辑，同时根据系统功能复杂度，系统业务复杂度估算开发时间和有效测试执行时间，为项目总计划和测试计划的制定提供参考和依据。
通过对文档分析，分解各功能模块，各功能点，为测试用例设计提供数据依据。
测试人员了解项目需求变更。
重点明确需求如下：
1、功能测试需求
2、性能测试需求
3、压力测试需求
4、系统容量需求
5、系统安全性需求
6、安装测试需求
7、数据转换需求
8、兼容性需求
9、项目文档
1）产品沟通邮件
2）客户、售前人员，产品沟通记录
3）项目文档资料
4）业务背景资料
测试计划
根据需求文档和项目计划制定测试计划。
测试计划旨在说明各测试阶段任务、人员分配、时间安排、测试要点、工作规范等。
测试计划在策略和方法方面说明如何计划、组织和管理测试项目。
测试计划完成后应该在项目组内进行评审。
测试人员会同项目主管根据软件需求制定并确认《测试计划》。
测试设计
在设计测试方案时，首先分解测试内容，对于一个复杂系统，通常可以分解成几个互相独立的子系统，正确地划分这些子系统及其逻辑组成部分和相互间的关系，可以降低测试的复杂性，减少重复和遗漏，也便于设计和开发测试用例，有效的组织测试，将系统分析人员的开发分析文档加工成以测试为角度的功能点分析文档，重要的是描述对系统分解后每个功能点逐一的校验描述，包括何种方法测试、何种数据测试、期望测试结果等。
然后以功能点分析文档作为依据进行测试用例的设计，设计测试用例是关系到测试效果以至软件质量的关键性一步，也是一项非常细致的工作，根据对具体的北侧系统的分析和测试要求，逐步细化测试的范围和内容，设计具体的测试过程和数据，同时将结果写成可以按步执行的《测试用例》文档。
每个测试用例必须包括以下几个部分：
（1）编号和模块
（2）测试的任务项和功能点
（3）输入和使用的数据和操作过程
（4）期望的输出结果
（5）其他特殊的环境要求、次序要求、时间要求等
（6）输出《测试用例》文档
测试用例是为实施测试而向被测试系统提供的输入数据、操作或各种环境设置以及期望结果的一个特定的集合。
解决要测什么、怎么测和如何衡量的问题。
依据用户需求分析说明书、测试方案来设计测试用例，发现需求与设计中的问题后，与项目经理及时沟通确认。
1）测试用例设计方法
a）测试用例的设计方法有等价类测试、边界值分析、基于判定表的测试、基于因果图的测试、基于状态图的测试、基于场景的测试。
b）在设计测试用例时常用的设计方法有等价类测试、边界值分析两种方法。
2）测试用例操作步骤
a）在设计编写测试用例时，根据需求文档和开发文档设计用例，评审通过后将使用该测试用例测试被测系统。
b）在测试期间，发现用例描述不清、需求变更或用例设计错误，及时在统一文档中记录，待本轮测试结束后，更新基线用例。
3）测试用例选择准则
a）测试用例的代表性：
能够代表各种合理和不合理的、合法的和非法的、边界和越界的,以及极限的输入数据、操作和环境设置等；
b）测试结果的可判定性：
即测试执行结果的正确性是可判定的或可评估的；
c）测试结果的可再现性：
即对同样的测试用例,系统的执行结果应当是相同的。
测试软/硬件环境搭建
根据需求文档提供的内容，和开发部沟通确定测试项目所需的软硬件环境，完成对测试项目所需软硬件资源的准备工作，使软硬件资源得到满足。
测试数据准备
完成对测试项目基本数据的准备操作，包括数据库连接、用户信息、用户角色权限、单位组织等信息和测试相关的测试数据。
用例执行
a）测试准入条件
项目开发组完成编码后，提交测试所要求的待测软件及各种设计文档、手册（附录一、二）。
同时开发人员经过自测通过，至少保证程序可以正常运行；对应的功能在正常流程下是可以正常使用。
测试进行冒烟测试通过，开始进行正式测试。
b）项目测试阶段
测试人员依据测试计划和测试用例进行测试活动。
测试一般分为两个阶段：
（1）测试执行阶段：
该阶段测试人员测试出bug后将缺陷提交至缺陷管理库JIRA。
在缺陷的描述上，至少要包括以下一些方面内容：
标题、模块、重要程度、优先级、操作描述；
（2）回归问题单：
开发修改完bug之后，测试进行验证回归。
c）测试退出标准
功能需求覆盖100%。
所有用例全部执行
分析缺陷的趋势的收敛的，且遗留问题符合公司定义的度量标准。
测试过程中缺陷率达到公司系统测试质量标准。
测试变更
当需求变更，功能变化，测试人员根据变更情况，评估测试变更所需时间，提出变更风险。
如变更情况被项目组通过，测试人员将按上述流程进行变更测试。
测试汇报
测试结束后，测试人员对测试结果进行汇总；测试主管审核测试结果，得出测试结论；测试组进行测试分析和评估，编写《测试分析报告》。
提交《测试分析报告》。
将所有文件存档。
对测试未通过的待测软件，测试人员汇总并向项目开发组提交测试错误报告。
项目开发组对测试错误报告进行确认，对有争议的问题可由上一级技术负责人确认和仲裁；项目开发组针对测试错误报告进行逐项修改，修改完成后再将待测软件及错误修改情况提交及测试组进行回归测试。
待测软件测试通过后，项目测评结束。
制作《用户操作手册》（帮助文件）。
验收测试
a）项目经理与实施人员沟通验收事项。
b）实施人员在客户指定的环境下参照《安装维护手册》进行产品安装调试，并把合同约定的文档、源程序等交给客户。
c）实施人员对客户进行系统操作方法培训。
d）客户试用系统开展业务，测试人员收集客户反馈的问题；
e）测试人员在验收中发现或收集到用户反馈的缺陷并告知项目经理，并将缺陷记录到JIRA中分派给适合的开发人员。
f）开发人员分析缺陷的原因及解决该缺陷，并将该缺陷的解决方法及解决状态更新JIRA。
并将修改的代码给予实施人员部署，待用户验证，直到交付。
软件测试注意事项
根据《软件开发规范》仔细检查软件的界面是否合乎要求。
（每一个子界面也应如此）其中，应注意提示信息和软件开发商信息是否正确。
小的图标是否合乎要求。
检查菜单当中的各项功能和功能按钮是否能正确使用。
根据《软件开发规范》和《用户需求》及《软件详细设计》设计测试用例。
（以边界值法、等价类划分法为主）。
对功能界面要求注意与功能相关的信息显示及显示位置是否正确。
数据输入界面应注意文字格式及数字和文字的区别。
是否能够正确保存信息。
数据查询（显示）界面应注意显示信息是否正确和完整。
是否能正确查询。
对打印功能要求注意打印出的报表是否正确。
（包括报表各项信息、数据信息和报表字体等）。
这一项测试主要是对软件的错误处理功能进行测试。
就是进行错误的操作或输入错误的数据，检查软件对这些情况是否能做出判断并予以提示。
特殊情况下要制造极端状态和意外状态，比如网络异常中断、电源断电等情况。
一定要注意测试中的错误集中发生现象，这和程序员的编程水平和习惯有很大的关系。
对测试错误结果一定要有一个确认的过程。
一般有A测试出来的错误，一定要有一个B来确认，严重的错误可以召开评审会进行讨论和分析。
制定严格的测试计划，并把测试时间安排得尽量宽松，不要希望在极短的时间内完成一个高水平的测试。
回归测试的关联性一定要引起充分的注意，修改一个错误而引起更多错误出现的现象并不少见。
妥善保存一切测试过程文档，意义是不言而喻的，测试的重现性往往要靠测试文档。
4软件测试分类
除非是测试一个小程序，否则一开始就把整个系统作为一个单独的实体来测试是不现实的。
与开发过程类似，测试过程也必须分步骤进行，每个步骤在逻辑上是前一个步骤的继续。
大型软件系统通常由若干个子系统组成，每个子系统又由许多模块组成。
因此，大型软件系统的测试基本上由下述几个步骤组成：
模块测试
在设计得好的软件系统中，每个模块完成一个清晰定义的子功能，而且这个子功能和同级其他模块的功能之间没有相互依赖关系。
因此，有可能把每个模块作为一个单独的实体来测试，而且通常比较容易设计检验模块正确性的测试方案。
模块测试的目的是保证每个模块作为一个单元能正确运行，所以模块测试通常又称为单元测试。
在这个测试步骤中所发现的往往是编码和详细设计的错误。
子系统测试
子系统测试是把经过单元测试的模块放在一起形成一个子系统来测试。
模块相互间的协调和通信是这个测试过程中的主要问题，因此这个步骤着重测试模块的接口。
.系统测试
系统测试是把经过测试的于系统装配成一个完整的系统来测试。
在这个过程中不仅应该发现设计和编码的错误，还应该验证系统确实能提供需求说明书中指定的功能，而且系统的动态特性也符合预定要求。
在这个测试步骤中发现的往往是软件设计中的错误，也可能发现需求说明中的错误。
不论是子系统测试还是系统测试，都兼有检测和组装两重含义，通常称为集成测试。
验收测试
验收测试把软件系统作为单一的实体进行测试，测试内容与系统测试基本类似，但是它是在用户积极参与下进行的，而且可能主要使用实际数据（系统将来要处理的信息）进行测试。
验收测试的目的是验证系统确实能够满足用户的需要，在这个测试步骤中发现的往往是系统需求说明书中的错误。
回归测试
回归测试是在软件维护阶段，对软件进行修改之后进行的测试。
其目的是检验对软件进行的修改是否正确。
这里，修改的正确性有两重含义：
一是所作的修改达到了预定目的，如错误得到改正，能够适应新的运行环境等等；二是不影响软件的其他功能的正确性。
Alpha测试
在系统开发接近完成时对应用系统的测试；测试后，仍然会有少量的设计变更。
这种测试一般由最终用户或其他人员员完成，不能由程序员或测试员完成。
Beta测试
当开发和测试根本完成时所做的测试，而最终的错误和问题需要在最终发行前找到。
这种测试一般由最终用户或其他人员员完成，不能由程序员或测试员完成。
5黑盒测试方法
黑盒测试（black—boxtesting）又称功能测试、数据驱动测试或基于规范的测试（即ec颠cation—basedtesting）。
用这种方法进行测试时，被测程序被当作看不见内部的黑盒。
在完全不考虑程序内部结构和内部特性的情况下，测试者仅依据程序功能的需求规范考虑确定测试用例和推断测试结果的正确性。
因此黑盒测试是从用户观点出发的测试，黑盒测试直观的想法就是既然程序被规定做某些事，那我们就看看它是不是在任何情况下都做的对。
完整的“任何情况”是无法验证的，为此黑盒测试也有一套产生测试用例的方法，以产生有限的测试用例而覆盖足够多的“任何情况”。
由于黑盒测试不需要了解程序内部结构，所以许多高层的测试如确认测试、系统测试、验收测试都采用黑盒测试。
黑盒测试首先是程序通常的功能性测试。
要求：
每个软件特性必须被一个测试用例或一个被认可的异常所覆盖。
用数据类型和数据值的最小集测试。
用一系列真实的数据类型和数据值运行，测试超负荷、饱和及其他“最坏情况”的结果；
用假想的数据类型和数据值运行，测试排斥不规则输入的能力；
对影响性能的关键模块，如基本算法、应测试单元性能（包括精度、时间、容量等）。
不仅要考核“程序应该做什么”还要考察“程序是否做了不该做的2”同时还要考察程序在其他一些情况下是否正常。
这些情况包括数据类型和数据值的异常等等。
下述几种方法：
（a）等价类划分，（b）因果图方法，（c）边值分析法，（d）猜错法，（e）随机数法，就是从更广泛的角度来进行黑盒测试。
每一个方法都力图能涵盖更多的“任何情况”，但又各有长处，综合使用这些方法，会得到一个较好的测试用例集。
等价类划分
等价类划分是一种典型的黑盒测试方法。
等价类是指某个输入域的集合。
它表示对揭露程序中的错误来说，集合中的每个输入条件是等效的。
因此我们只要在一个集合中选取一个测试数据即可。
等价类划分的办法是把程序的输入域划分成若干等价类，然后从每个部分中选取少数代表性数据当作测试用例。
这样就可使用少数测试用例检验程序在一大类情况下的反映。
在考虑等价类时，应该注意区别以下两种不同的情况：
有效等价类：
有效等价类指的是对程序的规范是有意义的、合理的输入数据所构成的集合。
在具体问题中，有效等价类可以是一个，也可以是多个。
无效等价类：
无效等价类指对程序的规范是不合理的或无意义的输入数据所构成的集合。
对于具体的问题，无效等价类至少应有一个，也可能有多个。
确定等价类有以下几条原则：
如果输入条件规定了取值范围或值的个数，则可确定一个有效等价类和两个无效等价类。
例如，程序的规范中提到的输入条包括“……项数可以从1到999……”，则可取有效等价类为“l考项数＜999”，无效等价类为“项数＜l，，及“项数＞999”。
输入条件规定了输入值的集合，或是规定了“必须如何”的条件，则可确定一个有效等价类和一个无效等价类。
如某程序涉及标识符，其输入条件规定“标识符应以字母开头……”则“以字母开头者”作为有效等价类，“以非字母开头”作为无效等价类。
如果我们确知，已划分的等价类中各元素在程序中的处理方式是不同的，则应将此等价类进一步划分成更小等价类。
输入条件
有效等价类
无效等价类
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
根据已列出的等价类表，按以下步骤确定测试用例：
为每个等价类规定一个唯一的编号；
设计一个测试用例，使其尽可能多地覆盖尚未覆盖的有效等价类。
重复这一步，最后使得所有有效等价类均被测试用例所覆盖；
设计一个新的测试用例，使其只覆盖一个无效等价类。
重复这一步，使所有无效等价类均被覆盖。
这里强调每次只覆盖一个无效等价类。
这是因为一个测试用例中如果含有多个缺陷，有可能在测试中只发现其中的一个，另一些被忽视。
等价类划分法能够全面、系统地考虑黑盒测试的测试用例设计问题，但是没有注意选用一些“高效的”、“有针对性的”测试用例。
后面介绍的边值分析法可以弥补这一缺点。
边值分析法
边值分析法是列出单元功能、输入、状态及控制的合法边界值和非法边界值，设计测试用例，包含全部边界值的方法。
典型地包括IF语句中的判别值，定义域、值域边界，空或畸形输入，末受控状态等。
边值分析法不是一类找一个例子的方法，而是以边界情况的处理作为主要目标专门设计测试用例的方法。
另外，边值分析不仅考查输入的边值，也要考虑输出的边值。
这是从人们的经验得出的一种有效方法。
人们发现许多软件错误只是在下标、数据结构和标量值的边界值及其上、下出现，运行这个区域的测试用例发现错误的概率很高。
用边值分析法设计测试用例时，有以下几条原则：
如果输入条件规定了取值范围，或是规定了值的个数，则应以该范围的边界内及刚刚超出范围的边界外的值，或是分别对最大、最小及稍小于最小、稍大于最大个数作为测试用例。
如有规范“某文件可包含l至255”个记录……“，则测试用例可选1和255及0和256等。
针对规范的每个输出条件使用原则〔a〕。
如果程序规范中提到的输入或输出域是个有序的集合（如顺序文件、表格等）就应注意选取有序集的第一个和最后一个元素作为测试用例。
分析规范，尽可能找出可能的边界条件。
一个典型的边值分析例子是三角形分类程序。
选取a，b，c构成三角形三边，“任意两边之和大于第三边”为边界条件。
边值分析相等价类划分侧重不同，对等价类划分是一个补充。
如上述三角形问题，选取a＝3，b＝4，c＝5，a＝2，b＝4，c＝7则覆盖有效和无效等价类。
如果能在等价类划分中注入边值分析的思想。
在每个等价类中不只选取一个覆盖用例，而是进而选取该等价类的边界值等价类划分法将更有效，最后可以用边值分析法再补充一些测试用例。
因果图
等价类划分法并没有考虑到输入情况的各种组合。
这样虽然各个输入条件单独可能出错的情况已经看到了，但多个输入情况组合起来可能出错的情况却被忽略。
采用因果图方法能帮助我们按一定步骤选择一组高效的测试用例，同时，还能为我们指出程序规范的描述中存在什么问题。
利用因果图导出测试用例需要经过以下几个步骤：
分析程序规范的描述中哪些是原因，哪些是结果。
原因常常是输入条件或是输入条件的等价类。
结果是输出条件。
分析程序规范的描述中语义的内容，并将其表示成连接各个原因与各个结果的“因果图”。
由于语法或环境的限制，有些原因和结果的组合情况是不可能出现的。
为表明这些特定的情况，在因果图上使用持殊的符号标明约束条件。
把因果图转换成判定表。
把判定表的每一列写成一个测试用例。
猜错法
猜错法在很大程度上是凭经验进行的，是凭人们对过去所作的测试工作结果的分析，对所揭示的缺陷的规律性作直觉的推测来发现缺陷的。
一个采用两分法的检索程序，典型地可以列出下面几种测试情况：
被检索的表只有一项或为空表；
表的项数恰好是2的幂次；
表的项数比2的幂次多1等。
猜错法充分发挥人的经验，在一个测试小组中集思广益，方便实用，特别在软件测试基础较差的情况下，很好地组织测试小组（也可以有外来人员）进行错误猜测，是有效的测试方法。
随机数法
即测试用例的参数是随机数。
它可以自动生成，因此自动化程度高。
使用大量随机测试用例测试通过的程序会提高用户对程序的信心。
但其关键在于随机数的规律是否符合使用实际。
6白盒测试方法
白盒法测试，是以程序的内部逻辑为基础，有选择地执行程序中最有代表性的通路。
因此，白盒法也叫逻辑覆盖法（bgicMM阴e）。
最彻底的逻辑覆盖法，是覆盖程序巾的诲一条通路。
但当程序中含有大量循环时，要执行每一条通路是44可能的。
因此，我们只能寄希望于程序的覆盖度尽可能高一些。
目前常用的一些覆盖标准有：
语句覆盖、判定覆盖、条件澄盖、判定涤件覆盖、条件组合覆盖、路径覆盖等。
白盒法考虑的是测试用例对程序内部逻辑的覆盖程度，所以又称为逻辑覆盖法。
最彻底的白盒法是覆盖程序中的每一条路径，但这不可能，我们希望覆盖的路径尽可能多一些。
为了衡量测试的覆盖程度，需要建立一些标准，目前常用的一些覆盖标准是：
（1）语句覆盖；
（2）判定覆盖；
（3）条件覆盖；
（4）判定／条件覆盖；
（5）条件组合覆盖。
语句覆盖
程序的某次运行一般并不能执行到其中的每一个语句，因此，如果某语句含有一个错误，而它在测试中没执行，这个错误就不可能被发现。
为了提高发现错误的可能性，应该在测试时至少要执行程序中的每一个语句。
所谓“语句覆盖”测试标准，它的含义是：
选择足够的测试用例，使得程序中每个语句至少都能执行一次。
例子：
ProcedureExample（VarA,B,C:
real）
begin
if（A>1）and（B=0）
thenx:
=x/A；
if（A=2）or（x>1）
thenx:
=x+l
end;
为了使程序中每个语句至少执行一次，只需设计一个能通过路径ace的例子就可以了。
例如选择输入数据为：
A=2，B=0，x=3
就可达到“语句覆盖”标准。
显然，语句覆盖是一个比较弱的覆盖标准。
如果第一个条件语句中的and错误地写成or，上面的测试用例是不能发现这个错误的，或者是第二个条件语句中x>1误写成x>0，这个测试用例也不能暴露它。
我们还可以举出许多错误情况是上述测试数据不能发现的。
所以，一般认为“语句覆盖”是很不充分的最低的一种覆盖标准。
.判定理盖
比“语句覆盖”稍强的覆盖标准是“判定覆盖”（或称分支覆盖）。
这个标准是：
执行足够的测试用例，使得程序中每个判定至少都获得一次“真”值和“假”值，即使得程序中的每一个分文至少都通过一次。
对上面那个例子，如果设计两个测试用例，就可以达到“判定覆盖”的标难。
为此，我们可以选择输人数据为：
（1）A=3，B=0，x=l
（2）A=2，B=1，x=3
“判定覆盖”比“语句覆盖”严格，因为如果每个分支都执行过了，自然每个语句也就执行了。
.条件覆盖
它的含义是：
执行足够的测试用例，使得判定中每个条件获得各种可能的结果。
对于例子程序,我们只需设计以下两个测试用例就可满足这标准：
（1）A＝2，B＝o，x＝4（沿路径ace执行）
（2）A＝1，B＝l，x＝l（沿路径aN执行）
虽然同样只要两个测试用例，但它比判定覆盖中两个
升级会员 