平台功能测试规范

1、平台功能测试标准目录目的 6范围 6对象 61. 冒烟测试标准 61.1冒烟测试目的 61.2冒烟测试定义 71.3冒烟测试方法 71.4测试实施 8测试实现过程 8测试要点 10测试准入准出 10冒烟测试自动化 101.5冒烟测试进阶 112. SIT测试标准 122.1SIT测试的定义 122.2SIT测试主要内容 12功能测试 12非功能测试 13测试方法介绍 132.3SIT测试过程 17182.3.2SIT 测试方案阶段主要活动2.3.3SIT 测试设计阶段主要活动 182.3.4SIT 测试执行和评估阶段主要活动 202.4SIT 准入准出标准 213. UAT 测试标准 223.

2、1UAT 测试目的 233.2UAT 测试参与人员 233.3UAT 测试用例 233.4UAT 测试范围 233.5UAT 测试前提 243.6UAT 测试策略 243.7UAT 测试通过条件 243.8UAT 的测试难点以及建议 244. 预发布环境测试标准 264.1 预发布定义 264.2 角色与职责 264.3 版本预发布工作流程图 274.4 预发布流程描述 284.4.1 预发布流程进入条件 284.4.2 预发布流程结束条件 284.4.3 预发布流程步骤 294.6 版本测试记录表 314.7 预发布环境小结 315. 生产环境测试标准 325.1 系统上线标准流程标准 32

3、5.2 根本流程 335.3 详细流程 345.3.1 完整上线流程 355.3.2 补丁上线流程 376. 回归测试标准 386.1 回归测试原因 & 意义 386.2 回归测试定义 386.3 回归测试核心思想 396.4 回归测试的策略 396.4.1 策略 396.4.2 执行过程 406.4.3 执行的时机 406.5 基于晶链通的策略 406.5.1 现状 406.5.2 基于现状的策略 416.6 晶链通实例 426.6.1 晶链通的功能点 426.6.2 定义范围和深度 43466.6.3 执行过程及结果跟踪7. 线上问题处理与反应 467.1 线上问题的定义 467.

4、2 线上故障管理的目标 477.3 故障处理流程介绍 477.4 确认故障与通知协调人 487.5定位 / 处理故障 487.6 故障恢复 497.7 组织故障 Review 497.8 同步故障报告 517.9建立每个 Action 禅道子任务 . 517.10 故障与故障 Actions 跟进 517.11 故障数据分析 . 517.12 线上问题总结 . 52目的本文档的目的在于指导测试人员如何进行冒烟测试，SIT测试，UAT测试，预发布环境测试,生产环境测试以及线上问题处理。标准测试活动。以及一些测试活动中常见的问题。范围包含的测试活动有冒烟测试，SIT测试，UAT测试，预发布环境测试

5、，生产环境测试，回归测试以及线上问题处理与反应，可以根据工程或者平台的实际情况对活动进行裁剪。对象本文档面向对象为测试人员，实施人员等1. 冒烟测试标准1.1冒烟测试目的冒烟测试(Smoke Testing )可以说是一种预测试，软件代码正式编译并交付测试之前，先尽量消除其“外表的错误，确保软件根本功能符合需求规格说明书要求，减少后期测试 开发的负担。在软件开发过程中，一直有高内聚，低耦合这样的说法，各个功能模块之间的耦合还是存在的，因此一个功能的改动，还是会影响到其他功能模块。因此在开发人员修复了先前测试中发现的bug后，想知道这个bug的修复是否会影响到其他功能模块，需要做的就是冒烟测试。

6、1.2冒烟测试定义冒烟测试是这样的一种测试，不要求覆盖面有多广， 但至少要保证覆盖待测产品的绝大局部功能；不要求每个功能都测的很详细，但至少要保证被修复了的bug所属的功能和系统其他骨干功能都是可用的即这个版本能拿去做系统功能测试了。覆盖骨干功能和 bug所属功能，却不是简简单单在页面中点几下就行了的。任何一个工程或者产品，骨干功能都有它的使用场景。冒烟测试就是要保证这些骨干功能的使用场景都能跑通，如果没跑通，后续的系统测试就没必要了。1.3冒烟测试方法1. 基于每日构建的冒烟测试冒烟测试就是在每日build建立后，对系统的根本功能进行简单的测试。这种测试强调功能的覆盖率，而不对功能的正确性进

7、行验证。冒烟测试一般用于每日构建Nightly build，构建效劳器首先从 VSS效劳器上，下载最新的源代码，然后编译单元测试， 运行单元测试通过后，编译可执行文件，可执行文件假设可运 行，并能执行最根本的功能，那么认为通过了冒烟测试。基于每日构建的冒烟测试的优点主要有：a进度可见并可以控制到1-2天的细粒度，很容易看到进度的偏差；b及早的发现开发 BUG和缺陷并分析解决，对开发人员的一种监督和促进，提高软 件质量c由于将大集成分解到每日构建中的小集成，防止了传统产品集成或集成测试时候出现的严重问题的可能。d在工程中宣贯质量意识， 强调第一次就把事情做好，而不是等测试来帮你发现问题基于每日构

8、建的冒烟测试也存在一些风险和缺陷，具体主要有：a) 给开发人员太大压力，开发每天都在较紧张环境中工作b) 需要额外的测试人力资源和每日构建硬件环境的投入c) 开发人员不能专注，既要分心去修改 BUG ，又要开发新的功能点d) 对开发负责人要求更好，需要将功能细化到 1-2 天的有明确输出的功能点e) 发需要投入额外的精力来保证每日构建顺畅基于每日构建的冒烟测试适用场景a) 对进度偏差控制和要求很高的工程b) 开发检查点和里程碑制定的很细致的工程c) 采用增量和迭代开发的工程 ,快速和敏捷开发的工程2. 基于送测版本的冒烟测试build ，而是根据版本方案， 开发组定期发布送测版本，测试组拿到新

9、的版本先做冒烟测试，测试通过那么开始正此种方法来源于每日构建和冒烟测试，只是把粒度放大了。不是做每日式测试，不通过就返给开发组。这种做法的优点可以防止微软的每日build 和冒烟测试做法的一些缺陷，同时也会因粒度粗而有自身的缺点，在此就不做详述。1.4 测试实施1.4.1 测试实现过程1. 测试规划阶段： 冒烟测试用例的编写，以及测试执行，都是需要时间本钱的，故在最初根据工程实际，确定在单制作工程方案时，就应该识别该任务，并充分考虑其工作量。元测试，集成测试，系统测试的哪个或哪几个阶段开展冒烟测试，明确准入准出标准。2. 冒烟测试用例设计： 分析系统主要功能和业务流程， 编写覆盖这些功能的正向

10、测试用例， 推荐使用正交表， 运用正交法制定一套测试用例。 如果没有用例就无法跟踪和掌握整个 冒烟测试的重点， 以及各个版本之间的冒烟比照。 冒烟测试用例应该随着系统的不断扩 展而不断扩展，它不应该是一成不变的。3. 冒烟测试执行： 每个版本发布时， 根据版本包含的功能特性， 评估需要执行的冒烟测试 用例4. 冒烟测试结果输出： 冒烟测试执行情况， 通过的测试用例数， 不通过的测试用例数，据 此判断是否开始正式的测试。5. 冒烟测试清单整理A.整理冒烟测试功能点，根据需求清单，发布清单整理本次版本所有的功能点，作为冒烟功能测试点B整理冒烟流程测试用例，根据系统流程，筛选能够覆盖大局部功能的流程

11、作为冒烟测试场景6. 冒烟测试规那么A. 冒烟测试时发现冒烟功能不通过，将缺陷提入缺陷管理工具跟踪管理。B. 冒烟测试功能点通过率低于 60%时，召开干系人会议，发起退测流程，发起版本申请。C冒烟流程测试通过率低于 70%时，召开干系人会议，发起退测流程，发起版本申请。D.开发人员修复完冒烟测试所产生的问题后，重新发起版本送测申请，测试人员对送测版本重新进行冒烟测试E.冒烟测试时间不得超过2-4个小时。1.4.2 测试要点1. 业务流的测试，保证正常业务链路的通畅2. 工作流的测试， 主要是测试流程流转是否正常， 至于流程步骤的内容是否正确那么不关注。3. 关键功能的测试，至少要保证系统运转，

12、以及一些正常功能实现。4. 重要根本功能的测试，比方对核心业务有影响的一些增删改等1.4.3 测试准入准出冒烟测试的入口准那么a) 软件版本已经发布b) 冒烟测试方案和测试变更需求和用例通过评审c) 测试环境准备完毕冒烟测试的出口准那么a) 发现的致命和严重类缺陷为 0b) 所有必选测试场景的通过率 =100%c) 随即抽取的可选测试场景通过率 >80%1.4.4 冒烟测试自动化冒烟测试可以手动执行， 可以考虑自动化执行。 稳定的系统适合自动化冒烟测试， 集成过程 中的系统适合手工冒烟测试， 因为冒烟测试内容在动态变化， 变化中的自动化脚本维护工作 量比拟大。自动化冒烟测试脚本应当遵循的

13、原那么1. 覆盖主要功能；2. 测试脚本要简单、易用和详细说明3. 测试脚本要独立4. 每个测试脚本要尽可能的独立5. 每个测试脚本覆盖的测试点要尽可能的单一6. 测试结果收集：留存每一次的测试结果，比照一段时间内的测试结果，可以知道产品那些功能点质量不稳定， 如果同一个测试点在一段时间内经常不能够测试通过，那么这一局部的代码十分有必要进行review，有可能存在更大的隐患。1.5冒烟测试进阶与开发人员协同工作由于冒烟测试特别关注更改正的代码，因此必须与编写代码的开发人员协同工作。必须了解以下内容：1、代码中进行了什么更改。假设要理解该更改，必须理解使用的技术；开发人员可以提供相关说明。2、更

14、改对功能有何影响。3、更改对各组件的依存关系有何影响。在进行冒烟测试前检查代码在运行冒烟测试前， 进行侧重于代码中的所有更改的代码检查。代码检查是验证代码质量并确保代码无缺陷和错误的最有效、最经济的方法。冒烟测试确保通过代码检查或风险评估标识的主要的关键区域或薄弱区域已通过验证，因为如果失败，测试就无法继续。在干净的调试版本中安装私有二进制文件由于冒烟测试必须侧重于仅对更新后的二进制文件中的功能更改良行验证，所以必须通过使用被测试文件的调试二进制文件来使测试在干净的测试环境中运行。注意：在冒烟测试中，使用不匹配的二进制文件进行测试是一个常见错误。为了防止此错误，当两个或多个更新后的二进制文件之

15、间存在依赖项时，请在测试版本中包括所有更新后的二进制文件。否那么，测试的结果可能无效。2. SIT测试标准2.1SIT测试的定义System In tegrate Test的缩写，即系统整合测试系统整合测试就是评估产品在其规格范围内的环境下工作，能否完成产品设计规格所需要的功能及与周边设备、 应用软件的兼容性。大致可以分为硬、软件兼容性测试，认证测试。 安装Win/Linux/Unix这些只是系统整合测试的一小局部硬件测试：所有产品的周边设备，例如CPU、DIMM、storage、NIC、USB等软件测试：操作系统的安装，驱动的安装，以 及配套应用软件的安装及使用等认证测试：Windows、R

16、ed Hat、VMWare 等。2.2SIT测试主要内容功能测试需求验证，恢复性测试灾难测试，容错测试，接口测试，安装/升级测试，配置测试/兼容性测试，国际化测试，用户文档测试等等2.2.2 非功能测试性能测试， 平安测试， 易用性测试， 冒烟测试， 回归测试， 随机测试， 硬件系统专有测试 可靠性测试，可生产性测试，可维护性测试2.2.3 测试方法介绍2.2.3.1 配置测试 / 兼容性测试主要包括组网测试和软硬件平台配置测试组网测试的目的是测试系统是否满足其需求中所支持的所有组网类型和组网规模软硬件平台配置测试的目的是测试系统是否满足其需求中所支持的不同软硬件平台配置兼容性测试是指系统适应

17、能力测试，可分为环境兼容性测试和版本兼容性测试2.2.3.2 性能测试为了验证系统是否到达用户提出的性能指标， 同时发现系统中存在的性能瓶颈， 起到优化系统的目的在正常，峰值以及异常负载条件下，测试系统的各项性能指标2.2.3.3 平安性测试平安测试就是检查系统对外部的非法侵入的抵御能力。 系统平安测试的准那么是， 测试非法侵 入的代价是否超过被保护信息的价值 信息平安与保密不同于人身平安和重大财产损失 在公司的产品研发中，需要重点考虑的是信息平安方面 随着 ISO14000/18000 的实施，这方面的内容会增多平安测试主要关注点 主要方法：1.SQL 注入测试2. 权限测试3. 脚本注入测

18、试4. 跨目录测试5. 隐通道测试常见故障：1. 系统缓冲区溢出，堆栈溢出错误。2. 系统存在密码平安，权限管理，数据平安方面的漏洞，可被轻易的进入并进行非法获取和 破坏。2.2.3.4 恢复性测试检查系统的容错能力， 测试系统在遇到系统奔溃， 硬件损坏或其他灾难性问题后能否很好的 恢复，测试的具体内容包括创立各种可能的灾难状况， 测试系统从异常状态恢复到正常状态 所需的时间，花费的代价，对周边设备和系统造成的影响，系统恢复的完整性和一致性等 常用的方法主要是制造系统异常，按系统恢复功能进行恢复操作，直至系统继续正常运行 为了测试系统恢复之后是否运行正常， 也可以采用一些自动化测试工具进行回归

19、测试， 以提 高测试的效率。常见故障：1. 系统发生异常后无法恢复，造成系统数据被破坏，即重启系统，恢复备份数据也不可行，2. 严重的可能造成系统硬件故障3. 系统恢复时间过长，代价过高4. 系统不能完全恢复到原来的正常状态，造成一定损失5. 系统恢复过程对周边设备和环境造成较大影响，无法消除等2.2.3.5 易用性测试 对用户体验度的关注度提高，每个系统上线后产生的事件数作为了易用性评判的主要依据 以用户的角度来对软件界面的易用性， 风格， 合理性等方面进行评估和测试， 通常包括软件 的界面显示测试'和界面功能测试'而界面功能测试主要结合系统功能进行测试。测试要点和常见的故障

20、易用性与合理性：步骤繁琐的操作， 比例不协调， 摆放凌乱的窗口和控件， 层次过多的子窗 口和菜单标准性：不符合 Windows 标准的控件设计，与常规 Windows 操作不符的流程与操作等 容错性： 编辑控件对非法字符， 超出边界值的输入处理不当或没有提示， 容易造成系统重启， 数据删除丧失等的操作没有提示等帮助：无帮助信息提供，或者不提供获取帮助的快捷操作 美观与风格：界面颜色不协调，界面风格与公司相关产品风格不符，与业界通用风格不符， 图片，图标等不符合公司 UI 标准 资源：界面长时间运行操作造成系统内存耗尽，界面对系统资源独占使用等2.2.3.6 安装升级测试安装升级测试是以最终用户

21、的角度测试系统的可安装性以及系统是否具有升级或者卸载功能，安装升级测试，需要重点测试系统的软硬件平台的兼容性主要内容：1. 安装升级根本功能测试2. 卸载测试可选3. 平台兼容性测试4. 易用性与合理性测试5. 健壮性测试常用工具通常手工进行，可借助录制回放工具进行反复的软件安装测试常见故障1. 系统的软硬件不能兼容2. 系统软件在不同的平台下安装后不能正常工作3. 系统版本升级后，无法正常工作，系统无法回退到升级前的版本4. 系统的硬件安装不符合用户习惯5. 系统的软硬件安装升级过程和用户文档的表达不一致，甚至错误，误导最终用户2.2.3.7 文档/ 帮助测试各种用户文档和联机帮助系统是软件

22、产品的重要组成局部， 保证其正确性也是软件测试工程师的职责，文档 / 帮助测试的目的在于：1.提高易用性，使软件用户更容易地学习和使用软件产品2.提高可靠性，如果用户阅读文档，然后使用软件，最终得不到预期结果，这就是可靠性差3. 降低支持费用，好的文档 / 帮助通过恰当的解释和引导可以在用户有麻烦或者遇到意外情 况时减少请求公司帮助从用户的角度来测试软件文档是非常有效的方法， 仔细阅读，跟随每个步骤， 检查每个图形， 尝试每个例如，利用这个现实的简单方法，可以找出软件和文档中的缺陷，常用的方法有： 1.评审和审查，检查文档的编辑清晰性2.动态测试，结合实际程序的使用而使用文档3. 让独立的第三

23、方如用户或其他人员如以前没有接触或者使用过本系统的新手在程 序的使用语境测试文档也十分有效的方法2.2.3.8 随机测试俗称猴子测试最好由用户代表进行公司内部可结合新员工 /工程 /客服人员培训进行应该有适当的组织和方案2.3SIT 测试过程2.3.1 工程周期中的 SIT 测试阶段划分SIT 测试方案阶段SIT 测试设计和编码阶段SIT 测试执行和评估阶段测试方案阶段主要活动制定SIT测试总体方案简述工程，明确测试的范围定义测试策略阶段，类型，技术，标准等编制测试需求工作分解和估算资源分配进度表风险识别与应对SIT测试总体方案评审批准SIT测试总体方案系统测试总体方案纳入配置管理测试设计阶段

24、主要活动SIT测试建立需SIT测试SIT测试方案设求跟踪用例设用例评计矩阵计编写审SIT 测试设计阶段与执行阶段常见的风险 不做测试设计，或者测试过程并未按照 SIT 测试总体方案的要求来做测试设计不详细， 不是基于可度量的测试策略， 例如测试方案覆盖一个集合或者测试需求的 一个子集测试过程没有检验测试需求测试总体方案中测试策略没有对应性测试过程不可重复或者不可重用SIT 测试设计和执行阶段度量需求覆盖率百分比 = 测试覆盖的需求 / 所有需求 *100%测试用例的数量条自动化测试在 SIT 测试中的比例百分比 = 采用自动化测试的 SIT 测试用例数目 /全部的 测试用例数目 *100%测试

25、用例设计和开发的工作量人时SIT 测试文档评审工作量人时测试执行和评估阶段主要活动rrSIT测试执行详 细的SITSIT测试SIT测试SIT测试F耳请测试计准备执行总结L_2J划LJkJLJSIT测试执行阶段与评估阶段常见风险没有制定系统测试详细方案，测试开始之前测试人员不能明确本次SIT测试活动应测试的测试用例测试执行不按照SIT测试详细方案的要求来做，不能确保方案要求的测试用例都能的到执行未对测试的原始数据进行记录本次SIT测试新的有效测试规程和测试用例并未及时的给予记录和管理工程组和产品组的压力有可能导致测试人员的测试评估不够客观准确没有有效利用各种自动化测试手段，手工测试太多。SIT测

26、试执行和评估阶段常用度量测试用例通过率百分比=本次测试中通过的用例数 /实际执行的用例数测试用例覆盖率百分比=本次测试中实际执行的用例数 /方案执行的用例数本次测试中测试通过的SIT测试用例数目已发现的缺陷数目以及缺陷严重级别已经解决的缺陷数目以及缺陷等级遗留的缺陷数目以及缺陷等级缺陷密度分布图测试工时SIT测试的需求覆盖率SIT测试的假设干原那么应尽早地开始SIT测试工作充分注意测试中的缺陷密集现象，即对缺陷比拟密集的局部进行重点测试严格执行测试方案，排除测试的随意性对测试过程和测试结果进行评价，确保测试过程的有效性妥善保存测试方案，测试用例，故障统计和最终分析报告，为维护提供方便对于被测系

27、统要进行正常和异常两方面的测试这是一种权在系统测试方案中，要按照资源和工程的要求清晰的定义一个完整的退出准侧,衡投入/产出比的原那么，测试即不要不充分，也不要过分2.4SIT准入准出标准SIT准入标准系统功能开发完毕，开发部门完成单元测试，保证系统的功能已经实现。开发部门提供测试版本，并提供相关的版本说明，对发布版本的情况进行概要说明。 系统的单元测试已经完成，并提供单元测试报告。系统的功能测试已经完成，并提供功能测试报告。提供独立的SIT测试环境，保证被测版本可以正常运行。测试版本在SIT测试环境进行连通性测试，确保系统的重要模块以及重要功能点是可以正常 运行的。提供SIT相关测试数据。在保

28、证系统的单元测试和功能测试已经通过后，再进入系统集成测试SIT阶段。SIT准出标准最后测试的系统版本沒有严重級別较高的缺陷出現最后发布的几个测试版本，发现的功能缺陷数量沒有上升趋势最后测试的系统版本的缺陷数量控制在一定的范围內。新增功能缺陷少于已有缺陷的千分之二，reopen 率少于百分之五建议所有严重級別为 Falat、 High的缺陷都已经关闭，95%的功能缺陷已经关闭。最后测试的系统版本发现的缺陷是经過业务实施部门确认容许存在3. UAT测试标准UAT User Acceptanee T est，用户验收测试，或用户可接受测试，系统开发生命周期方 法论的一个阶段，这时相关的用户或独立测试

29、人员根据测试方案和结果对系统进行测试和接 收。它让系统用户决定是否接收系统。它是一项确定产品是否能够满足合同或用户所规定需 求的测试。这是管理性和防御性控制。3.1UAT 测试目的本阶段测试是为了测试开发出来的产品是否能够满足用户的需求， 因为只有用户实际使用了 产品，根据实际体验才能知道产品是否能满足要求。 同时也是为了找出在实际环境中可能出 现的一些 Bug ，并及时修复3.2UAT 测试参与人员UAT 测试顾名思义可以知道测试的主体应该是实际客户， 本阶段的测试需要客户直接参与， 因为研发、测试甚至 PM 都不能准备的了解客户实际环境下如何使用产品，所有本阶段的 测试参与者主要是实际客户

30、3.3UAT 测试用例UAT 的用例原那么上来讲应该是用户自行按照实际使用来设计，但考虑到客户对新系统的不 熟悉，可以采用测试人员设计用例，邀请实际客户参与评审的方式来设计用例。3.4UAT 测试范围测试应该包含安装、 环境部署、各个子模块的根本功能等系统一个完成过程中的所有局部 也 包含用户手册 ，同时应该根据用户实际使用环境着重测试客户使用频率高的模块，尽可能 将用户常用模块中可能隐藏着的问题发现出来并修改。3.5UAT 测试前提UAT 需要满足一定的条件才能开始，进行 UAT 的产品理论上来说，必须已经全部开发、测 试完毕，代码状态处于冻结状态， 所有测试出来的 bug 都已经被妥善处理

31、，重大的 bug 都被解决，并验证通过。 对于一些低级别 bug ，要么决定被写入发布公告中，要么被设置 为不需要修改的问题。 在实际工程操作过程中，由于方案进度原因达不到理论状态前提， UAT 的效果也达不到应有的效果。3.6UAT 测试策略UAT 测试理论上是用户按照使用手册进行操作，或者安排组织客户培训后让用户操作。测 试过程应该有用户独立完成各个步骤，根据用户要求可以安排研发或测试的人员陪同测试， 既能在过程中起到指导帮助作用，也能在测试发现 Bug 的时候做第一时间的调查分析。3.7UAT 测试通过条件成功地执行了测试方案中规定的测试用例；修正了所发现的功能性错误； 用户肯定测试结果

32、， 并通过了专门小组的评审，评审人员应该包含客户、产品经理、项 目经理、研发负责人、测试负责人等。最后用户在确认书上签字认可测试结果，确认产品能够满足客户需求。3.8UAT 的测试难点以及建议难点1. 用例设计无法有限覆盖实际环境： 很多时候 UAT 测试用例仍然是由测试人员甚至是开发人员设计，他们并不能真正的了解真 实客户更多的需求，也无法完全知道用户的真实使用环境，所以设计出来的 UAT 用例很多 时候仍然是系统测试级的用例。2. 客户对系统不熟悉：客户在实际测试的时候或多或少还是存在着对系统不熟悉的情况， 测试效率不高， 进度比拟 慢；再者很多时候客户不愿意安排人员来进行 UAT 测试，

33、 UAT 测试实际上仍然是测试人员 完成，由于使用习惯和思维惯性，使得潜在的问题不易发现，造成问题遗漏。3. 认为 UAT 可有可无：因为进入到此阶段本身就意味着开发和测试进入到后期， 已经完成了系统测试， 认为已经完 成了系统测试，系统就没有大的问题， UAT 可以不开展了，这样节约系统上线时间，早日 带来价值建议1. 尝试在开发的过程中邀请客户参与， 尤其是当重要功能集成好后， 应该立即邀请客户参与 到测试中来， 即可让用户尽早熟悉系统， 对产品有一个初步的认识， 又可以在用户体验后及 时了解用户的需求更新如易用性 ，并落实更改。2. 坚持 UAT 测试，因为用户在使用系统的时候是为了完成

34、真实任务和工作，是最真实的使 用环境和真实的数据， 真实环境的真实数据得到的测试结果最真实可靠； 同时也能有效的避 免研发和测试人员在前期形成的定式思维。从而能更有效的发现潜在问题。3. UAT 测试一般来讲是上线前最后一次需求确认的时机，一旦系统推广上线后再 发现某些需求不满足或者实现出现了偏差， 修改和维护的本钱大幅提高， 造成时间和费用的 双重消耗4. 预发布环境测试标准4.1 预发布定义预发布指 SIT 测试 ,UAT 测试通过后， 版本发布上线前， 在指定环境上， 进行冒烟测试， 通过后预发布流程结束， 这个过程中所要遵循的流程标准。 其中涉及工程经理 版本负 责人、开发主管、测试主

35、管以及配置管理员、 QA 这 5 个角色。4.2 角色与职责工程经理1启动版本预发布流程的决策者。2版本配套文档清单的检查者。3分支打包的执行者。配置管理员1 版本控制和发布环节的协调人。2 获取发布版本，负责工程版本配套文件的收集及归档。3 测试版本的提供者。开发主管1 与版本相关的输出物清单的提供者；2 安装配置手册、迭代版本说明的提供者；测试主管1与开发主管配合执行冒烟测试并使之通过QA1检查工程版本控制及发布流程的标准性。2检查工程版本配套文件清单的完整性。4.3 版本预发布工作流程图工程经理版本负责人开发主管配置管理员测试主管QA开始开发功能/修改BUG执行SIT/UAT测试任务提供

36、安装配置手册，发 布部署脚本，版本配置 清单，并通知工程经理版本负责人进行检查测试主管组织展开预发布冒烟测试执行分支打包，更 新安装包存放URL 至安装部署手册按照版本发布文件，下 载安装包并将清单中的 配置文件提交至SVN勺 对应版本中，发布成功后，通知相关干系人冒烟测试通过后 i邮件通知相关人 员，预发布冒烟测 试通过，预发布结 束2允许发布生产环 境QA检查预发布流程以及结果的正确性，如有不符合项，QA发出QA提醒4.4预发布流程描述预发布流程进入条件测试完成SIT测试以及UAT测试，准备进行版本发布上线的一次测试预发布流程结束条件预发布环境冒烟测试通过4.4.3 预发布流程步骤1. 预

37、发布环境准备工程通过开发部内部集成测试后， 开发主管通知工程经理代码具备提交测试部测试的条 件1工程在 Jenkins 上持续测试通过，内部禅道中的 Bug 清理完毕 工程经理允许保存 的除外2开发主管提交输出物清单， 并在清单中标注输出物在 SVN 上的存储路径 配置文件、 数据库脚本、部署所需的文件夹路径结构、相关工具等等，程序安装包存储路 径空白。3开发主管提交版本说明，标明工程本次变更记录、工程当前的版本号等等 。4开发主管提交安装配置手册内部版，到达测试人员可以参照安装配置手册和输 出物清单完成测试环境的部署2. 预发布环境发布清单检查 工程经理按照安装配置手册上面的清单对其内容进行

38、逐一检查。检查内容包括 :1工程经理需要检查配置文件是否是默认通用配置文件，开发主管配合；2工程经理与测试部门配合检查部署手册及源码等配套文件的合理性；3版本是否正确，是否有更改，是否与版本说明一致。3. 检查通过后，工程经理执行分支打包。更新输出物清单，将程序安装包存储路径修 改为下载 URL 地址即持续集成上部署包的路径SVN 的工程测试 / 测试对4. 工程经理通知配置管理员将输出物清单中的输出物上传到象目录中与配套文挡存放目录一致 ，然后通知测试部门并抄送相关人员进行测试。 并对测试对象编号版本、测试内容、测试轮次进行记录。5. 测试人员从 SVN 的工程测试 / 测试对象目录中获取安

39、装配置手册， 按照安装配置手册 中的输出物清单及配置流程进行环境搭建， 并开展冒烟测试工作。 在测试过程中， 工程 经理配合测试人员检查部署包及其配套文件的正确性， 如有问题， 通知开发主管进行修 改和更新。6. 冒烟测试通过后， 测试人员发送冒烟测试通过邮件给相关人员并抄送 QA 。完成预发 布流程中必须的文档和目标条件：1 输出物清单均已提交 svn ，并放入指定目录； 2 工程经理已审核通过。预发布流程结束。7. QA 对预发布做审核，审核预发布流程的标准性，并按照安装配置手册的文件清单检 查配套文件提交的正确性。如有不符合项， QA 发出邮件提醒工程经理及时解决。4.5 版本配套文件清

40、单由配置管理员归档并以此作为版本配套文件清单内容主要由开发主管负责提供并填写。 填写预发布记录表的依据， 同时邮件通知测试主管针对此版本开展测试工作。 版本文件 清单主要包括：部署包 / 升级包、数据库脚本、版本说明、安装配置手册。4.6 版本测试记录表版本测试记录表由配置管理员填写并维护。 配置管理员根据每次提交测试的版本信息进 行记录，以版本测试记录表的形式存档。4.7 预发布环境小结1. 预发布环境，就是线上环境、正式生产环境，为防止因为测试环境和线上环境的差异 性等带来的缺陷漏测而设立的一套环境，其配置等根本和线上一致，只是预发布环境 web 效劳器不在线上集成效劳器范围之内，为单独的

41、一台机器；2. 预发布环境不能被线上用户访问通常这里的技术实现是这样的：把预发布环境的访问域名设置成和线上环境的不一样， 通过配置 host 来访问预发布环境3. 预发布环境和线上环境公用数据库，即预发布环境使用的是线上的数据库问题： 如果新版本程序需要更改表结构等， 比方加个表字段， 那么， 部署到预发布环境时也需 要更改表字段，这个可能会影响线上环境程序代码的运行，如何解决？解决方法：1. 先把预发布环境使用的数据库切换为测试环境使用的数据库2. 根据实际部署过程，如果有必要，接着，可有针对性的测试下数据库的变更是否会 影响线上当前代码程序的运行3. 把新代码部署到预发布环境，测试程序是否

42、正常运行4. 预发布测试完毕，如果没问题，先上线数据库，即在正式环境执行对应的数据库变 更操作5. 紧接着，把预发布环境连接的数据库切换为线上环境使用的数据库，再次进行预发 布环境的测试6. 最后，如果预发布环境测试通过，那么把预发布环境的代码部署到线上生产环境。注：1. 如果不需要更改数据库表结构等，那么无需切换预发布环境环境使用的数据库，即预 发布使用线上的数据库。2. 这里，因为预发布环境本身就是线上环境，测试完预发布，也根本代表线上环境测 试完成。这样还可以防止发布到正式环境还得再测一遍的情况5. 生产环境测试标准5.1 系统上线标准流程标准为标准分公司系统上线管理， 明确系统上线管理

43、的工作要求， 合理配置资源， 确保上线能够 正常完成， 特制订本标准。 在已开发完毕的各系统正式部署生产环境前要严格按照以下流程进行上线前检查5.2根本流程系统上线准备用户测试并验 收系统上线用户生产验证系统上线结束1在系统开发完毕后首先模拟配置生产环境，并将系统部署至模拟/准生产环境。2开发人员对各自开发模块功能文档化并制定测试方案，特别注意临界点测试方案。3内测完毕后交由相关业务及需求人员进行集成测试，并请测试人员记录测试结果及问题，交由相关开发人员进行再次迭代。完成后测试方须交付测试结果报告。4由技术人员进行系统上线，系统上线成功并且相关业务及需求人员进行生产验证后需提交系统验收报告5.

44、3 详细流程根据系统上线的类型可分为完整上线及补丁上线两种，流程标准如下5.3.1 完整上线流程完整系统线上准备指定系统维护负责 人并指定应急演练 方案疋杏是是系统上线否上线方案必须在测试环境 或准生产环境经过验证。上线后的生产验证结果是判 断是否成功的唯一标准.硬件环境包括效劳器硬 件及网络环境等：包含备份说明文档及相 应程序或脚本等回退，确认原因并 指定后续方案包含日常维护文档、应急 方案文档等。针对不K的工程需求 方，验收报告可以由市 场、业务、技术提供。上线资料包含安装包、数据 库脚本、配置文件等。是是否具有完整 的上线方案是是是否有验收报弄统上线的硬 件以及操作系 统环境是否准 备妥

45、当疋证系统上线.是否成功是否具备系统日常维护及应 急方案、曰心完整系统上线结束J n具备数«游，程序，日志等备份机制/卫线资料'检查核对是否无误补丁上线准备除BUG外的补丁必须 有验收报告。是否有验收报告上线方案必须在测试环境或 准生产环境经过验证。上线 方案中必须有回退步骤。是否具有完整的上线方案上线资料包含安装包、数据 库脚本、配置文件等。系统上线资料检查核对是否无误备份旧程序，数据等相关原系统的所有信息副本上线后的生产验证结果是判 断是否成功的唯一标准系统上线验证系统上线是否成功'指定系统维护负责人并指定应急演练方案回退，确认原因并指定后续方案完整系统上线结束5

46、32补丁上线流程6. 回归测试标准6.1回归测试原因&意义在软件生命周期中的任何一个阶段，只要软件发生了改变，就可能给该软件带来问题。因此，每当软件发生变化时， 我们就必须重新测试现有的功能，以便确定修改是否到达了预期的目的，检查修改是否损害了原有的正常功能。1发现了错误并做了修改：当软件中所含错误被发现时， 如果错误跟踪与管理系统不够完善，就可能会遗漏对这些错误的修改；开发者对错误理解得不够透彻，也可能导致所做的修改只修正了错误的外在表现，而没有修复错误本身，从而造成修改失败。修改还有可能产生副作用从而导致软件未被修改的局部产生新的问题，使本来工作正常的功能产生错误。2增加或者修改软

47、件原有逻辑的时候：除了新参加的代码中有可能含有错误外，新代码还有可能对原有的代码带来影响。新的代码没有问题，但是新参加的或者受到修改的流程或者逻辑对原有逻辑产生影响， 从而导致问题。6.2回归测试定义回归测试是指修改了代码后，对系统进行一定程度的全面测试以确认修改没有引入新的 错误或导致其他代码产生错误。6.3回归测试核心思想检验软件原有功能在修改后是否保持正确。6.4回归测试的策略策略1全部用例使用测试用例库中的全部测试用例组成回归测试用例库。最低的遗漏回归错误的风险，但测试本钱最高。2基于用例优先级选择测试可以基于用例优先级来选择回归测试用例。制定一定的挑选标准，如TO级别的bug需要在回

48、归的时候全部运行，T1的运行30%。再根据本版本的功能，适当的加大新功能模块的回归力度。3基于风险选择测试可以基于一定的风险标准来选择回归测试用例。首先运行最重要的、 关键的和可疑的测试，而跳过那些非关键的、优先级别低的或者高稳定的测试用例。4基于操作剖面选择测试可以优先选择那些针对最重要或最频繁使用的业务流程，释放和缓解最高级别的风险， 有助于尽早发现那些对流程有最大影响的故障。5再测试修改的局部回归测试局限于被改变的模块和它的接口上。通常，一个回归错误一定涉及一个新的、 修改的或删除的代码段。在允许的条件下，回归测试尽可能覆盖受到影响的局部。6.4.2 执行过程1建立基线测试用例库根据以往

49、的积累，收集本系统测试用例。 梳理用例架构，使得用例的管理有序 梳理用例级别，提高执行时的选择灵活性 梳理用例版本，定期维护用例库2根据策略选择用例，生成回归测试用例集 每个版本的回归测试，根据所拥有的资源人员，时间 ，来决定回归测试的策略。根 据所选择的策略，从测试用例库中挑选本次版本需要进行回归测试的用例。3执行回归测试 根据回归测试用例集，执行回归测试6.4.3 执行的时机1在每一轮测试阶段完成，要进入下一阶段时2 测试阶段的 bug 已经修复到一定程度3基于一个稳定的系统版本进行6.5 基于晶链通的策略6.5.1 现状1暂无完整的测试用例，且没有进行等级定义 之前的测试用例，是基于测试

50、点的，粒度太大。没有进行级别的定义，挑选效率可能会比拟低2流程变更频繁无法针对回归测试， 专门准备一套回归测试用例。 由于流程变更较为频繁， 导致如果要 为回归测试专门准备用例，需要较大的维护资源。3实际业务复杂 晶链通的每个大客户从不同的角度使用系统。 不同的第三方系统的接入，导致不同的数据风格。6.5.2 基于现状的策略1脱离用例，从功能出发 收集整理系统现有的功能点，精确到每个页面具体的功能，如增删改查。 对核心模块的功能，深化功能点，如物流订单的五种类型，装车的 N 种方式。2脱离业务，从系统流程出发 不考虑实际的业务，梳理系统流程，根据流程增加所需要涉及的功能模块。 对步骤 1 所选

51、择的测试点进行串联。步骤 1 、2 所确定的范围，可以作为每次回归测试用例集的根底文档，每个版本根据实 际情况进行更新和维护。3 结合业务，补充覆盖考虑几个大客户的使用场景，对 1、 2 点所挑选的回归测试点，进行补充。4基于版本功能，增加深度本次版本新增或者修改的功能点， 以及这些模块会涉及影响的其余模块， 需要加大回归 测试的粒度。6.6晶链通实例661晶链通的功能点1功能清单根据菜单，列出功能的具体框架收集每个页面的功能点，一般可以以按钮为关键点展开细化每个功能点的隐藏逻辑，考虑核心信息的覆盖，如下:一级菜单二级菜单三级菜单大块功能点细化功能点首页首页dashboard货主首页订单状态累

52、计订单类型统计在途订单分布图物流商订单统计及排名物流商KPI考核统计及排名订单预警分布图供给商首页物流订单汇总承运订单汇总转岀订单统计每日订单数据统计资源中心我的伙伴查询数据来源查询结果生成供给商根据货主生成根据供给商生成邀请伙伴我要邀请查询数据来源查询结果发起邀请邀请货主邀请供给商我的邀请查询数据来源查询结果接受成为货主成为供给商拒绝拒绝成为货主拒绝成为供给商订单中心物流订单管理我接收的物流单生效运输订单拒绝作为仓储商拒绝运输订单 作为仓储商拒绝运输岀库 作为仓储商拒绝运输入库 作为仓储商拒绝岀库订单 作为仓储商拒绝入库订单 作为承运商拒绝运输订单 作为承运商拒绝运输岀库 作为承运商拒绝运输

53、入库 作为承运商拒绝岀库订单 作为承运商拒绝入库订单662定义范围和深度1根据功能重要性，添加回归功能点一级菜单二级菜单三级菜单大块功能点细化功能点选择订单中心物流订单管理我接收的物流单生效运输订单Y运输岀库运输入库岀库订单入库订单拒绝作为仓储商拒绝运输订单Y作为仓储商拒绝运输岀库作为仓储商拒绝运输入库作为仓储商拒绝岀库订单作为仓储商拒绝入库订单作为承运商拒绝运输订单Y作为承运商拒绝运输岀库作为承运商拒绝运输入库作为承运商拒绝岀库订单作为承运商拒绝入库订单2根据整理的系统流程，添加回归功能点在验证流程时，需要校验至少三个点：生成承运单、出库单、入库单，因此需要增加或者修改对应的功能点，如：一级菜单二级菜单三级菜单大块功能点细化功能点选择订单中心物流订单管理我接收的物流单生效运输订单运输岀库Y运输入库Y岀库订单入库订单拒绝作为仓储商拒绝运输订单Y作为仓储商拒绝运输岀库作为仓储商拒绝运输入库作为仓储商拒绝岀库订单