平台功能测试规范目录目的 (6)范围 (6)对象 (6)1. 冒烟测试规范 (6)1.1冒烟测试目的 (6)1.2冒烟测试定义 (7)1.3冒烟测试方法 (7)1.4测试实施 (8)1.4.1测试实现过程 (8)1.4.2测试要点 (10)1.4.3测试准入准出 (10)1.4.4冒烟测试自动化 (10)1.5冒烟测试进阶 (11)2. SIT测试规范 (12)2.1SIT测试的定义 (12)2.2SIT测试主要内容 (12)2.2.1功能测试 (12)2.2.2非功能测试 (13)2.2.3测试方法介绍 (13)2.3SIT测试过程 (17)2.3.1项目周期中的SIT测试阶段划分 (17)2.3.2SIT测试计划阶段主要活动 (18)2.3.3SIT测试设计阶段主要活动 (18)2.3.4SIT测试执行和评估阶段主要活动 (20)2.4SIT准入准出标准 (21)3. UAT测试规范 (22)3.1UAT测试目的 (23)3.2UAT测试参与人员 (23)3.3UAT测试用例 (23)3.4UAT测试范围 (23)3.5UAT测试前提 (24)3.6UAT测试策略 (24)3.7UAT测试通过条件 (24)3.8UAT的测试难点以及建议 (24)4. 预发布环境测试规范 (26)4.1预发布定义 (26)4.2角色与职责 (26)4.3版本预发布工作流程图 (27)4.4预发布流程描述 (28)4.4.1预发布流程进入条件 (28)4.4.2预发布流程结束条件 (28)4.4.3预发布流程步骤 (29)4.5版本配套文件清单 (30)4.6版本测试记录表 (31)4.7预发布环境小结 (31)5. 生产环境测试规范 (32)5.1系统上线标准流程规范 (32)5.2基本流程 (33)5.3详细流程 (34)5.3.1完整上线流程 (35)5.3.2补丁上线流程 (37)6. 回归测试规范 (38)6.1回归测试原因&意义 (38)6.2回归测试定义 (38)6.3回归测试核心思想 (39)6.4回归测试的策略 (39)6.4.1策略 (39)6.4.2执行过程 (40)6.4.3执行的时机 (40)6.5基于晶链通的策略 (40)6.5.1现状 (40)6.5.2基于现状的策略 (41)6.6晶链通实例 (42)6.6.1晶链通的功能点 (42)6.6.2定义范围和深度 (43)6.6.3执行过程及结果跟踪 (46)7. 线上问题处理与反馈 (46)7.1线上问题的定义 (46)7.2线上故障管理的目标 (47)7.3故障处理流程介绍 (47)7.4确认故障与通知协调人 (48)7.5定位/处理故障 (48)7.6故障恢复 (49)7.7组织故障Review (49)7.8同步故障报告 (51)7.9建立每个Action 禅道子任务 (51)7.10故障与故障Actions跟进 (51)7.11故障数据分析 (51)7.12线上问题总结 (52)目的本文档的目的在于指导测试人员如何进行冒烟测试，SIT测试，UAT测试，预发布环境测试，生产环境测试以及线上问题处理。
规范测试活动。
以及一些测试活动中常见的问题。
范围包含的测试活动有冒烟测试，SIT测试，UAT测试，预发布环境测试，生产环境测试，回归测试以及线上问题处理与反馈，可以根据项目或者平台的实际情况对活动进行裁剪。
对象本文档面向对象为测试人员，实施人员等1. 冒烟测试规范1.1冒烟测试目的冒烟测试（Smoke Testing）可以说是一种预测试，软件代码正式编译并交付测试之前，先尽量消除其“表面的”错误，确保软件基本功能符合需求规格说明书要求，减少后期测试开发的负担。
在软件开发过程中，一直有高内聚，低耦合这样的说法，各个功能模块之间的耦合还是存在的，因此一个功能的改动，还是会影响到其他功能模块。
因此在开发人员修复了先前测试中发现的bug后，想知道这个bug的修复是否会影响到其他功能模块，需要做的就是冒烟测试。
1.2冒烟测试定义冒烟测试是这样的一种测试，不要求覆盖面有多广，但至少要保证覆盖待测产品的绝大部分功能；不要求每个功能都测的很详细，但至少要保证被修复了的bug所属的功能和系统其他骨干功能都是可用的（即这个版本能拿去做系统功能测试了）。
覆盖骨干功能和bug所属功能，却不是简简单单在页面中点几下就行了的。
任何一个项目或者产品，骨干功能都有它的使用场景。
冒烟测试就是要保证这些骨干功能的使用场景都能跑通，如果没跑通，后续的系统测试就没必要了。
1.3冒烟测试方法1.基于每日构建的冒烟测试冒烟测试就是在每日build建立后，对系统的基本功能进行简单的测试。
这种测试强调功能的覆盖率，而不对功能的正确性进行验证。
冒烟测试一般用于每日构建(Nightly build)，构建服务器首先从VSS服务器上，下载最新的源代码，然后编译单元测试，运行单元测试通过后，编译可执行文件，可执行文件若可运行，并能执行最基本的功能，则认为通过了冒烟测试。
基于每日构建的冒烟测试的优点主要有：a)进度可见并可以控制到1-2天的细粒度，很容易看到进度的偏差；b)及早的发现开发BUG和缺陷并分析解决，对开发人员的一种监督和促进，提高软件质量c)由于将大集成分解到每日构建中的小集成，避免了传统产品集成或集成测试时候出现的严重问题的可能。
d)在项目中宣贯质量意识，强调第一次就把事情做好，而不是等测试来帮你发现问题●基于每日构建的冒烟测试也存在一些风险和缺陷，具体主要有：a)给开发人员太大压力，开发每天都在较紧张环境中工作b)需要额外的测试人力资源和每日构建硬件环境的投入c)开发人员不能专注，既要分心去修改BUG，又要开发新的功能点d)对开发负责人要求更好，需要将功能细化到1-2天的有明确输出的功能点e)发需要投入额外的精力来保证每日构建顺畅●基于每日构建的冒烟测试适用场景a)对进度偏差控制和要求很高的项目b)开发检查点和里程碑制定的很细致的项目c)采用增量和迭代开发的项目,快速和敏捷开发的项目2.基于送测版本的冒烟测试此种方法来源于每日构建和冒烟测试，只是把粒度放大了。
不是做每日build，而是根据版本计划，开发组定期发布送测版本，测试组拿到新的版本先做冒烟测试，测试通过则开始正式测试，不通过就返给开发组。
这种做法的优点可以避免微软的每日build和冒烟测试做法的一些缺陷，同时也会因粒度粗而有自身的缺点，在此就不做详述。
1.4测试实施1.4.1测试实现过程1.测试规划阶段：冒烟测试用例的编写，以及测试执行，都是需要时间成本的，故在最初制作项目计划时，就应该识别该任务，并充分考虑其工作量。
根据项目实际，确定在单元测试，集成测试，系统测试的哪个或哪几个阶段开展冒烟测试，明确准入准出标准。
2.冒烟测试用例设计：分析系统主要功能和业务流程，编写覆盖这些功能的正向测试用例，推荐使用正交表，运用正交法制定一套测试用例。
如果没有用例就无法跟踪和掌握整个冒烟测试的重点，以及各个版本之间的冒烟对比。
冒烟测试用例应该随着系统的不断扩展而不断扩展，它不应该是一成不变的。
3.冒烟测试执行：每个版本发布时，根据版本包含的功能特性，评估需要执行的冒烟测试用例4.冒烟测试结果输出：冒烟测试执行情况，通过的测试用例数，不通过的测试用例数，据此判断是否开始正式的测试。
5.冒烟测试清单整理A.整理冒烟测试功能点，根据需求清单，发布清单整理本次版本所有的功能点，作为冒烟功能测试点B.整理冒烟流程测试用例，根据系统流程，筛选能够覆盖大部分功能的流程作为冒烟测试场景6.冒烟测试规则A.冒烟测试时发现冒烟功能不通过，将缺陷提入缺陷管理工具跟踪管理。
B.冒烟测试功能点通过率低于60%时，召开干系人会议，发起退测流程，发起版本申请。
C.冒烟流程测试通过率低于70%时，召开干系人会议，发起退测流程，发起版本申请。
D.开发人员修复完冒烟测试所产生的问题后，重新发起版本送测申请，测试人员对送测版本重新进行冒烟测试E.冒烟测试时间不得超过2-4个小时。
1.4.2测试要点1.业务流的测试，保证正常业务链路的通畅2.工作流的测试，主要是测试流程流转是否正常，至于流程步骤的内容是否正确则不关注。
3.关键功能的测试，至少要保证系统运转，以及一些正常功能实现。
4.重要基本功能的测试，比如对核心业务有影响的一些增删改等1.4.3测试准入准出●冒烟测试的入口准则a)软件版本已经发布b)冒烟测试计划和测试变更需求和用例通过评审c)测试环境准备完毕●冒烟测试的出口准则a)发现的致命和严重类缺陷为0b)所有必选测试场景的通过率=100%c)随即抽取的可选测试场景通过率>80%1.4.4冒烟测试自动化冒烟测试可以手动执行，可以考虑自动化执行。
稳定的系统适合自动化冒烟测试，集成过程中的系统适合手工冒烟测试，因为冒烟测试内容在动态变化，变化中的自动化脚本维护工作量比较大。
自动化冒烟测试脚本应当遵循的原则1.覆盖主要功能；2.测试脚本要简单、易用和详细说明3.测试脚本要独立4.每个测试脚本要尽可能的独立5.每个测试脚本覆盖的测试点要尽可能的单一6.测试结果收集：留存每一次的测试结果，对比一段时间内的测试结果，可以知道产品那些功能点质量不稳定，如果同一个测试点在一段时间内经常不能够测试通过，那么这一部分的代码十分有必要进行review，有可能存在更大的隐患。
1.5冒烟测试进阶与开发人员协同工作由于冒烟测试特别关注更改过的代码，因此必须与编写代码的开发人员协同工作。
必须了解以下内容：1、代码中进行了什么更改。
若要理解该更改，必须理解使用的技术；开发人员可以提供相关说明。
2、更改对功能有何影响。
3、更改对各组件的依存关系有何影响。
在进行冒烟测试前检查代码在运行冒烟测试前，进行侧重于代码中的所有更改的代码检查。
代码检查是验证代码质量并确保代码无缺陷和错误的最有效、最经济的方法。
冒烟测试确保通过代码检查或风险评估标识的主要的关键区域或薄弱区域已通过验证，因为如果失败，测试就无法继续。
在干净的调试版本中安装私有二进制文件由于冒烟测试必须侧重于仅对更新后的二进制文件中的功能更改进行验证，所以必须通过使用被测试文件的调试二进制文件来使测试在干净的测试环境中运行。
注意：在冒烟测试中，使用不匹配的二进制文件进行测试是一个常见错误。
为了避免此错误，当两个或多个更新后的二进制文件之间存在依赖项时，请在测试版本中包括所有更新后的二进制文件。
否则，测试的结果可能无效。
2. SIT测试规范2.1SIT测试的定义System Integrate Test的缩写，即系统整合测试系统整合测试就是评估产品在其规格范围内的环境下工作，能否完成产品设计规格所需要的功能及与周边设备、应用软件的兼容性。