软件测评能力提升方案.docx
《软件测评能力提升方案.docx》由会员分享，可在线阅读，更多相关《软件测评能力提升方案.docx（31页珍藏版）》请在冰豆网上搜索。
软件测评能力提升方案
软件测评工程能力提升方案
咨询方将在上述调研报告基础上，提出详细的测评工程能力建设方案。
方案的主要包括以下方面：
1软件测试实用规程
1.1软件测试的认识
如前所述，目前软件测试领域的理论体系仍然不算成熟，软件测评专业能力建设本身是一个复杂的系统工程，牵涉的人员和环节众多，从调研结果来看，部分研发人员对测试的认识存在一些偏差，这将给软件测评专业建设带来风险。
软件测评工程能力，首先是测试意识的提升。
技术保障，观念先行，一个研发项目涉及的人员尤其是大多数的开发人员的测试意识是决定性的，只有将软件测试放到软件全生命周期的大背景下来考察，使全体人员对软件质量全程保证的角度来重新认识测试，具体的测试方法、测试技能提升才有普遍意义。
基础理论和方法论的普及，软件测试的本质、含义、定位和作用的深入认识，将是项目能否顺利开展的前提。
软件测试本质上是一个证伪而不是证明的过程。
因此，从广义上来说，只要是对软件本身质量保证相关的，都可以纳入软件测试的范围。
无论是在软件研发的需求分析、架构设计、详细设计、代码实现还是后面的测试阶段，都可以开展测试活动；无论是系统设计人员、软件编程人员或者验证人员、服务人员、市场人员，都可以成为测试人员；也无论是文档评审、代码审查、功能调试、系统验证等等活动，都可以是一种测试活动；无论是人工验证、形式证明、代码静态分析工具、单元测试工具还是自动化测试工具等手段，都可以成为有效的测试手段。
只要有确定的人员，采用某种确定的方法手段，按照确定的项目内容，对影响软件质量的相关文档、代码、程序、数据等进行验证，都是执行了有意义的测试。
经过这些验证活动之后，我们得出有条件的结论，这个条件是在这些项目内容验证之下，我们判断软件通过或者不通过测试。
不通过（证伪）的时候，我们是可以很肯定地说这个有问题；但通过的时候，这种通过是有条件的。
从软件全程质量保证的角度来看待软件测试，测试活动包含以下几层要求：
1.软件质量是满足规定或潜在的用户需求的能力，因此软件开发过程中，从用户显式或隐含的意思表达到形成用户规格书、再到设计文档、变成代码并调试运行的过程，最重要的就是保证在这样一个复杂的转换过程中，需求的不被异化。
2.软件作为一个产品，是用来满足用户需求的，从这个角度来说，需要测量的是在特定环境下运行达到其任务目标的程度，但软件本身是一组文档、数据和代码的总和，其中最直接的是代码，从这个角度来说，作为一个产品本身，也需要从机械的符号角度对其内生的质量进行度量和评价。
3.软件的生产过程是一个工程，对应的测试活动有其工程属性，既然测试活动本身不能证明，只能证伪，测试活动则更需要明确测试界限，给出工程上合理的进度、资源、方法和结束条件。
采用的测试方法就必须回答如何保证需求不被异化，如何从动态和静态两个角度来评估软件质量，以及如何明确测试界限的问题，而这又必然需要通过一定的技术手段才能得到有效地支撑。
在这种广义的软件质量保证的含义下，我们来重新审视软件全生命周期尤其是研发周期，就会发现，专门的软件测试人员承担的软件质量保证职责是有限的，一个研发项目中占大多数的研发人员，他们的测试意识，对测试活动、测试方法的认识是很关键的。
因此，测评工程能力的提升，首先要通过培训、宣传、会议等各种手段，让项目涉及的相关人员尤其是软件开发人员，重新认识软件研发过程，重新认识软件测试，包括测试本质、测试含义、测试定位、测试方法等等。
1.2软件测试方法
对应上述测试活动的理解，测试方法也首先是一套逻辑严密的需求覆盖体系和分析设计方法，具体表现为测试阶段覆盖的完整性、每个阶段测试分析的完整性、每个阶段测试分析的过程完整性保证，然后才是在此之上的一些操作手段和工具应用技能，同时在管理层面，需要有明确测试界限的一系列手段。
一、测试阶段划分
如前所述，一个明确的软件测试项目包括前期的文档测试，按照软件开发过程包含软件需求分析说明书验证、软件设计文档验证；另外一个是后期动态的单元测试、集成测试、系统测试、验收测试，这时主要的测试对象是程序和数据，当然也涉及到文档。
对于这些测试阶段，应制定规范，对其测试类型、测试技术要求等明确要求。
这方面，在军方、航空航天等领域有许多规范就可供参考。
实际实施时，规范应根据不同软件类型的重要性、安全性关键等级提供剪裁。
对应每一阶段的要求分别说明如下：
1、文档测试
文档测试的主要测试对象是软件需求规格说明书和软件设计文档。
文档通常使用文字进行说明，因此不可避免地具有而二义性和不明确性。
软件测试中的文档测试主要是对相关的设计报告和用户使用说明等文档进行测试，一般应符合以下的技术要求：
●对于设计报告主要是测试程序与设计报告中的设计思想是否一致；
●对于用户使用说明进行测试时，主要是测试用户使用说明书中对程序操作方法的描述是否正确，重点是用户使用说明中提到的操作例子要进行测试，保证采用的例子能够在程序中正确完成操作。
●对于其他文档，一般检查其有效性和无误性。
2、单元测试
单元测试的对象是软件单元。
软件单元测试应根据软件单元的重要性、安全性关键等级等对如下技术要求内容进行剪裁，但必须说明理由。
单元测试一般应符合以下的技术要求：
●在对软件单元进行动态测试之前，应对软件单元的源代码进行静态测试；
●应建立测试软件单元的环境，其测试环境应通过评审；
●对软件设计文档规定的软件单元的功能、性能、接口等应逐项进行测试；
●软件单元的每个特性应至少被一个正常测试用例和一个被认可的异常测试用例覆盖；
●测试用例的输入应至少包括有效等价类值、无效等价类值和边界数据值；
●语句覆盖率要达到100%；
●分支覆盖率要达到100%；
●对输出数据及其格式进行测试。
3、集成测试
集成测试的对象是软件组件，软件组件由软件单元组成。
软件集成测试可根据软件组件的重要性、安全性关键等级、重用情况等对如下技术要求内容进行剪裁，但必须说明理由。
集成测试一般应符合以下技术要求：
●应对构成软件组件的每个软件单元的单元测试情况进行检查；
●若对软件组件进行必要的静态测试，应先于动态测试；
●组装过程是动态进行的，应标明组装策略；
●应建立组件测试环境，其测试环境应通过评审；
●应逐项测试软件设计文档规定的软件组件的功能、性能等特性；
●软件组件的每个特性应至少被一个正常的测试用例和一个被认可的异常测试用例覆盖；
●测试用例的输入应至少包括有效等价类值、无效等价类值和边界数据值；
●应测试软件单元和软件组件之间的所有调用，达到要求的测试覆盖率；
●应测试软件组件的输出数据及其格式；
●应测试软件组件之间、软件组件和硬件之间的所有接口；
●应测试运行条件在边界状态下，进而在人为设定的状态下，软件组件的功能和性能；
●应按设计文档要求，对软件组件的功能、性能进行强度测试；
●对安全性关键的软件组件，应对其进行安全性分析，明确每一个危险状态和导致危险的可能原因，并对此进行针对性的测试。
●发现有否多余的软件单元。
4、系统测试
系统测试的对象是完整的、集成的计算机系统（ComputerSystem），重点是新开发的配置项的集合。
系统测试是组成系统的多个配置项的测试，组成一个系统的多个相关的软件可以同时进行系统测试。
系统测试一般应符合以下技术要求：
●应按系统/子系统设计说明的规定，逐项测试系统的功能、性能等特性；
●系统的每个特性应至少被一个正常测试用例和一个被认可的异常测试用例所覆盖；
●测试用例的输入应至少包括有效等价类值、无效等价类值和边界数据值；
●应测试系统的输出及其格式；
●应测试配置项之间及配置项与硬件之间的所有接口；
●应在边界状态、异常状态或在人为设定的状态的运行条件下，测试系统的功能和性能；
●应测试系统的安全性和数据访问的安全保密性；
●应测试系统的全部存储量、输入/输出通道的吞吐能力和处理时间的余量；
●应按系统或子系统设计文档的要求，对系统的功能、性能进行强度测试；
●应测试人机交互界面提供的操作和显示界面，包括测试界面的可靠性；
●应测试设计中用于提高系统安全性和可靠性的方案；
●对安全性关键的系统，应对其进行安全性分析，明确每一个危险状态和导致危险的可能原因，并对此进行针对性的测试。
●对有恢复或重置功能需求的系统，应测试其恢复或重置功能和平均恢复时间，且对每一类导致恢复或重置的情况进行测试。
●对软件系统的安装性进行测试；
●对不同的实际问题应外加相应的专项测试。
5、验收测试
验收测试是按照项目任务书或合同、供需双方约定的测试依据文档进行的对整个系统的测试，以决定是否接收或拒收系统。
其基本要求和系统测试类似。
二、测试类型分析
测试活动的每个阶段，都有不同的特点和要求，但至关重要的是保证测试分析方法的完整性，需要理解测试对象、测试的基本特点，确定测试的基本特征，提取共性。
例如，在军用测试领域就有一套已经形成完整的测试分析方法体系，包括22种测试类型，在测试设计时应首先对照其要求进行分析，分别简要介绍如下。
●文档审查：
是对提交的文档的完整性、一致性和准确性所进行的检查。
文档审查应确定审查所用的检查单，而且为适应不同的文档审查，需要用不同的检查单，检查单的设计或采用应经过评审并得到委托方的确认。
●可测试性审查：
主要是对开发的软件文档、软件设计的可测试性进行审核，包括软件文档是否符合可测性、软件设计是否具有可测试性、代码是否符合可测性等方面的审查。
●代码审查：
是检查代码和设计的一致性、代码执行标准的情况、代码逻辑表达的正确性、代码结构的合理性以及代码的可读性。
代码审查应根据所使用的语言和编码规范确定审查所用的检查单，检查单的设计或采用应经过评审并得到委托方的确认。
●静态分析：
是一种对代码的机械性和程序化的特性分析方法。
●代码走查：
由测试人员组成小组，准备一批有代表性的测试用例，集体扮演计算机的角色，沿程序的逻辑，逐步运行测试用例，查找被测软件缺陷。
●逻辑测试：
主要测试程序逻辑结构的合理性、实现的正确性。
逻辑测试应由测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试，通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致。
●功能测试：
主要对软件需求规格说明或设计文档中的功能需求逐项进行的测试，验证其功能是否满足要求。
功能测试一般需进行：
●性能测试：
对软件需求规格说明或设计文档中的性能需求逐项进行的测试，验证其性能是否满足要求。
●接口测试：
对软件需求规格说明或设计文档中的接口需求逐项进行的测试。
●人机交互界面测试：
是指对所有人机交互界面提供的操作和显示界面进行的测试，检验是否满足用户的要求。
●强度测试：
强制软件运行在不正常到发生故障的情况下检验软件可以运行到何种程度的测试。
●可靠性测试：
在真实的或仿真的环境中，为做出软件可靠性估计而对软件进行的功能测试。
可靠性测试中必须按照运行剖面和使用的概率分布随机地选择测试用例。
●安全性测试：
检验软件中已存在的安全性、安全保密性措施是否有效的测试，测试应尽可能在符合实际使用的条件下进行。
●恢复性测试：
对有恢复或重置功能的软件的每一类导致恢复或重置的情况逐一进行的测试，验证其恢复或重置功能。
恢复性测试是要证实在克服硬件故障后系统能否正常地继续进行工作，且不对系统造成任何损害。
●边界测试：
对软件处在边界或端点情况下运行状态的测试。
●数据处理测试：
对完成专门数据处理功能所进行的测试。
●安装性测试：
对安装过程是否符合安装规程的测试，以发现安装过程中的错误。
●互操作性测试：
是为验证不同软件之间的互操作能力而进行的测试。
●敏感性测试：
是为发现在有效输入类中，可能引起某种不稳定性或不正常处理的某些数据的组合而进行的测试。
●标准符合性测试：
验证软件与相关国家标准或规范（如国家标准、行业标准以及国际标准）一致性的测试。
●兼容性测试：
主要是验证被测软件在不同版本之间的兼容性。
有两类基本的兼容性测试：
一类是向下兼容测试，向下兼容是测试软件新版本保留它早期版本的功能的情况；另一类是交错兼容测试，交错兼容测试是要验证共同存在的两个相关但不同的产品之间的兼容性，即验证软件在规定条件下共同使用若干个实体或实现数据格式转换时能满足有关要求能力的测试。
●国际化测试：
验证软件在不降低软件原有能力的条件下，处理当地语言能力的测试。
三、测试分析过程
和软件开发过程类似，一个完整的测试阶段其软件测试过程也应包括：
测试需求分析、测试策划、测试设计与实现、测试执行、测试总结（包括评价过程和总结）等。
只有对测试分析过程从管理上和技术上提出明确的界限，才能真正判定测试用例设计是否达到设定目的，完全覆盖了测试需求，测试需求是否真正完全覆盖了软件需求、潜在的各类隐含需求。
在设计分析完整的基础上，按照严格的测试过程执行，就能有足够的信息来给出整个项目测试是否达到预期目标的结论。
下面对测试设计过程的技术要求加以描述。
1.测试需求分析
测试人员应根据被测软件的需求规格说明书、软件设计文档等，对被测软件进行测试需求分析。
通常，测试需求分析一般要求：
●确定需要的测试类型及其测试要求并进行标识（编号），标识应清晰、便于识别。
测试类型包括功能测试、性能测试等类型；测试要求包括状态、接口、数据结构、设计约束等要求。
确定的测试类型和测试要求均应与要求的测试阶段、测试类型匹配；
●确定测试类型中的各个测试项及其优先级；
●确定每个测试项的测试充分性要求。
根据被测软件的重要性、测试目标和约束条件，确定应覆盖的范围及范围所要求的覆盖程度；
●确定每个测试项测试终止的要求，包括测试过程正常终止的条件（如测试充分性是否达到要求）和导致测试过程异常终止的可能情况。
测试人员应建立测试类型中的测试项与软件测评任务书、被测软件的需求规格说明、设计文档或其他依据文件的追踪关系。
2.测试策划
测试人员应根据被测软件的需求规格说明书、软件设计文档等进行测试策划，策划一般要求包括：
●确定测试策略；
●确定测试需要的技术或方法，如：
测试数据生成与验证技术、测试数据输入技术、测试结果获取技术等；
●确定受控的测试工作产品，并列出清单；
●确定用于测试的资源要求，包括：
软硬件设备、环境条件、人员数量和技能等要求；
●进行测试风险分析，如：
技术风险、人员风险、资源风险和进度风险等；
●根据被测软件的需求规格说明书、软件设计文档和被测软件的特点，确定测试任务的结束条件；
●确定被测软件的评价准则和方法；
●应根据测试资源和测试项，确定测试活动的进度；
●应根据测试的要求，确定需采集的度量及采集要求，特别是用例度量、风险度量、缺陷度量等，并应明确相应的数据库测试需求度量。
3.测试设计和实现
测试人员应根据测试需求规格说明和测试计划进行测试的设计和实现，应完成以下工作：
●按需要分解测试项。
将需测试的测试项进行层次化的分解并进行标识，若有接口测试，还应有高层次的接口图说明所有的接口和要测试的接口；
●说明最终分解后的每个测试项。
说明测试用例设计方法的具体应用、测试数据的选择依据等；
●设计测试用例；
●确定测试用例的执行顺序；
●准备和验证所有的测试用数据。
针对测试输入要求，设计测试用的数据，如数据类型、输入方法等；
●准备并获取测试资源，如测试环境所必须的软、硬件资源等；
●必要时，编写测试执行需要的程序，如开发部件测试的驱动模块、桩模块以及测试支持软件等；
●建立和校核测试环境，记录校核结果，说明测试环境的偏差。
测试人员应将以上测试设计的工作结果，按照所确定的文档要求编写测试说明，测试说明由测试用例组成，测试用例一般技术要求如下：
●测试名称和项目标识；
●测试用例的追踪。
说明测试所依据的内容来源，并跟踪到相应的测试项标识（编号）；
●测试用例说明。
简要描述测试的对象、目的和所采用的测试方法；
●测试用例的初始化要求，包括硬件配置、软件配置（包括测试的初始条件）、测试配置（如用于测试的模拟系统和测试工具）、参数设置（如测试开始前对断点、指针、控制参数和初始化数据的设置）的那个的初始化要求；
●测试用例的输入。
每个测试用例输入的描述中包括：
Ø每个测试输入的名称、用途和具体内容（如确定的数值、状态或信号等）及其性质（如有效值、无效值、边界值等）
Ø测试输入的来源（如测试程序产生、磁盘文件、通过网络接收、人工键盘输入等），以及选择输入所使用的方法（如等价类划分、边界值分析、猜错法、因果图以及功能图等）；
Ø测试输入是真实的还是模拟的；
Ø测试输入的时间顺序或事件顺序。
●测试用例的期望测试结果。
期望测试结果应有具体内容（如确定的数值、状态或信号等），不应是不确切的概念或笼统的描述。
必要时，应提供中间的期望结果；
●测试用例的测试结果评估准则。
评估准则用以判断测试用例执行中产生的中间或最后结果是否正确。
评估准则应根据不同情况提供相关信息，如：
Ø实际测试结果所需的精确度；
Ø允许的实际测试结果与期望结果之间差异的上、下限；
Ø时间的最大或最小间隔；
Ø事件数目的最大或最小值；
Ø实际测试结果不确定时，重新测试的条件；
Ø与产生测试结果有关的出错处理；
Ø其它有关准则。
●实施测试用例的执行步骤。
编写按照执行顺序排列的一系列相对独立的步骤，执行步骤应包括：
Ø每一步所需的测试操作动作、测试程序输入或设备操作等；
Ø每一步期望的测试结果；
Ø每一步的评估准则；
Ø导致被测程序执行终止伴随的动作或指示信息；
Ø需要时，获取和分析中间结果的方法。
●测试用例的前提和约束。
再测试用例中还应说明实施测试用例的前提条件和约束条件，如特别限制、参数偏差或异常处理等，并要说明它们对测试用例的影响；
●测试终止条件。
说明测试用例的测试正常终止和异常终止的条件。
确定测试说明与测试计划或测试需求规格说明的追踪关系，给出清晰、明确的追踪表。
2开发环境统型
目前公司产品研发中用到的开发环境、开发工具比较繁杂，应予以一定程度的统一。
这项工作考虑应结合调研情况分析，根据公司主型软件工作硬件平台、操作系统等发展趋势，确定一个合理的统型方式和过渡方案。
方案影响深远，因此制定时需要通盘考虑：
●统型方案既要考虑到现有在研产品开发，更要关注未来产品预研，同时还要照顾已定型产品的维护。
●统型方案既要考虑到公司未来产品发展趋势，体现出一定的前瞻性和先进性，又要从现状出发，考虑广大研发人员的实际使用需要和技术能力。
●统型方案应考虑到实施的平稳过渡，逐步推进而非强行划断，尽量避免震荡。
●统型方案和测试工具选型结合，通过与统型目标的软硬件开发平台结合紧密的商购测试工具、二次开发工具和自行开发的实用小工具，自然引导。
开发环境统型方案将从以下方面加以阐述：
●现状分析：
环境分布、使用情况、发展趋势、人员技术能力分布等
●统型建议：
统型的原则及据此提出的平台统型建议
●统型机制：
提出结合项目立项、配置管理、缺陷管理等软件研发流程的统型管理机制
●工作计划：
提出具体的进度表
3软件开发语言编码规范
编码规范是研发团队的统一语言，在提高研发团队整体效率方面，编码规范与秦始皇的“车同轨、书同文”具有一样重要的意义。
编码的规范统一，也是建设更高层次的软件构件库的坚实基础。
目前公司涉及的编程语言有很多种，主要的是嵌入式平台下的C/C++语言，其他还包括PC环境下的Java、Delphi、C++Builder等。
这些目前都有一些工程上比较公认的编码规则，其实主要是根据经验和实际结合，权衡利弊，筛选出合理的规则集。
我们将根据经验，在充分了解目前的代码风格的基础上，提出公司内部针对各种开发语言的编码规范，原则上新的编码规范将尽量吸收当前的普遍的代码风格，以减少程序员编码习惯过大改变可能带来的不适应。
编码规范实际推广的关键首先在于有一个有效合理的检查机制。
如果纯粹通过人工走查或者同行评审的会议方式，推行的工作量太大，在目前的人员配比条件下，是不现实的。
业界已经有一套非常成熟的做法：
选择合适的代码规范检查工具，将编码规则嵌入到工具中，每个开发工程师在提交代码前必需提交对应的检查结果。
经过一段时间的运作，编码规范的普及和推广效果就会自然显现。
根据我们的实际推广经验，这对测试工具的规则定制能力有一定要求，也是测试工具选型必须考虑的内容。
在实际中，每个项目应根据自身实际情况，在统一的编码规范基础上进一步明确规则，哪些是本项目不需要的，哪些是需要进一步统一的，例如命名规则就有必要做进一步的细化要求。
因此，制定软件开发语言编码规范方案包含：
1.形成符合公司实际的编码规范：
根据公司的实际，我们建议分布实施，首先针对有一定基础且需求迫切的嵌入式平台C/C++语言，然后针对其他语言推出规范和相应控制措施；
2.配合规范实施的指导书：
将规范应用推广形成规范，并固化到RDP体系和PLM中；
3.结合选定的代码规则测试工具，定制代码规则检查集。
4软件需求分析
软件需求由用户需求转化而来，是软件设计和测试的源头。
软件需求的一般都通过软件需求规格说明书文档来体现。
公司现已在应用需求跟踪矩阵对需求进行管理，但目前管理到的只是在项目的立项和结项这两个头和尾上，研发过程中对需求的跟踪基本处于无人监控状态，需求的变更亦不能全方位有效的控制，测试部门也会因需求的不明确导致测试针对性不足。
一份好的软件需求规格说明书一般具有以下七大特性：
完整性、正确性、可行性、必要性、按优先级管理、无二义性、可验证性等。
因此，软件需求分析的工作也应该从这七个方面来推进，并进行质量评价。
软件需求分析是软件工程业界多年来的研究热点，形成多种的方法体系如RUP等，涉及面非常广，但在工程上最关键的，也尤为测评人员关心的，就是软件需求分析得到的需求质量如何，是否可验证。
软件需求规格说明书的质量，通常都通过制定详细的文档检查单，由各方人员预先审查，然后组织相关人员进行会议评审。
这些都是非常有效地方法，但由于文字说明的二义性和不明确性特点，不可避免地存在一些缺陷。
另一个更致命的问题是，软件需求主要从用户角度阐述，而软件设计文件则主要从软件的系统结构、实现方法等角度描述，导致软件需求难以进一步追踪，只有到系统测试的时候，才能得到验证，这就给系统引入了许多与需求相关的缺陷。
而且由于公司面对的是机构客户，具有需求变更频繁的特征，这就带来更多的管理困难、验证难度和软件隐患。
传统的文档检查单和会议评审仍然是最有效地方法。
但如何去设计文档检查单是关键，一般通用的检查单其本身就基于含糊的表述，只能保证模板格式，对实际内容是难以把关的。
基于多年来的实践经验，我们形成了一套借用敏捷开发（XP）的测试驱动设计（TDD）理念的检查方法，要求需求本身的有清楚的验证方法和通过标准，由验收方法的清晰来保证需求的清晰。
在这个阶段，就可以综合应用软件测试中的各种测试类型和方法，按照测试的要求和理念形成独到的检查项，这样的检查思路一旦形成一致的思维方法，将极大的提升需求分析水平。
另一方面，软件设计文档与软件需求文档之间应建立起需求追踪的关系，避免原有的需求跟踪只管两头的弊端，这方面可以参考GJB-438B标准中相关要求。
通过对设计文档的控制，将需求追踪的工作进一步细化，这样才更容易实现管理和验证。
需求变更的控制也是调研中很多人员提到的问题。
软件需求规格说明书编制是控制变更的一个开始，需求分析时应识别容易发生变更的部分，并在软件设计中对此加以体现。
咨询通信与公司类似，面对的是机构客户，生产的产品属于单品价值高，小批量多批次，多年的摸爬滚打提供了一个最好的实践案例。
例如，咨询公司的无线电台和通信控制器等产品在验收时，通常都会由于不同部队首长、军代表的个人偏好而容易被要求更改，这类需求由于军队的特殊体制，难以在需求调研阶段得到充分确认，经过摸索咨询形成一
升级会员 