平台功能测试规范3823.pdf

《平台功能测试规范3823.pdf》由会员分享，可在线阅读，更多相关《平台功能测试规范3823.pdf（48页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、1 平台功能测试规范 2 目录 目的.4 范围.4 对象.4 1.冒烟测试规范.4 冒烟测试目的.4 冒烟测试定义.5 冒烟测试方法.5 测试实施.6 测试实现过程.6 测试要点.7 测试准入准出.7 冒烟测试自动化.8 冒烟测试进阶.8 2.SIT测试规范.9 测试的定义.9 测试主要内容.10 功能测试.10 非功能测试.10 测试方法介绍.10 测试过程.14 项目周期中的SIT测试阶段划分.14 测试计划阶段主要活动.14 测试设计阶段主要活动.15 测试执行和评估阶段主要活动.16 准入准出标准.17 3.UAT测试规范.18 测试目的.18 测试参与人员.18 测试用例.19 测试

2、范围.19 测试前提.19 测试策略.19 测试通过条件.20 的测试难点以及建议.20 4.预发布环境测试规范.21 预发布定义.21 角色与职责.21 版本预发布工作流程图.22 预发布流程描述.23 预发布流程进入条件.23 预发布流程结束条件.23 预发布流程步骤.24 3 版本配套文件清单.25 版本测试记录表.25 预发布环境小结.26 5.生产环境测试规范.27 系统上线标准流程规范.27 基本流程.28 详细流程.28 完整上线流程.30 补丁上线流程.32 6.回归测试规范.33 回归测试原因&意义.33 回归测试定义.33 回归测试核心思想.33 回归测试的策略.34 策略

3、.34 执行过程.34 执行的时机.35 基于晶链通的策略.35 现状.35 基于现状的策略.36 晶链通实例.36 晶链通的功能点.36 定义范围和深度.38 执行过程及结果跟踪.42 7.线上问题处理与反馈.42 线上问题的定义.42 线上故障管理的目标.43 故障处理流程介绍.43 确认故障与通知协调人.44 定位/处理故障.44 故障恢复.44 组织故障Review.44 同步故障报告.47 建立每个Action 禅道子任务.47 故障与故障Actions跟进.47 故障数据分析.47 线上问题总结.48 4 目的 本文档的目的在于指导测试人员如何进行冒烟测试，SIT 测试，UAT 测

4、试，预发布环境测试，生产环境测试以及线上问题处理。规范测试活动。以及一些测试活动中常见的问题。范围 包含的测试活动有冒烟测试，SIT 测试，UAT 测试，预发布环境测试，生产环境测试，回归测试以及线上问题处理与反馈，可以根据项目或者平台的实际情况对活动进行裁剪。对象 本文档面向对象为测试人员，实施人员等 1.冒烟测试规范 冒烟测试目的 冒烟测试（Smoke Testing）可以说是一种预测试，软件代码正式编译并交付测试之前，先尽量消除其“表面的”错误，确保软件基本功能符合需求规格说明书要求，减少后期测试开发的负担。在软件开发过程中，一直有高内聚，低耦合这样的说法，各个功能模块之间的耦合还是存在

5、的，因此一个功能的改动，还是会影响到其他功能模块。因此在开发人员修复了先前测试中发现的 bug 后，想知道这个 bug 的修复是否会影响到其他功能模块，需要做的就是冒烟测试。v1.0 可编辑可修改 5 冒烟测试定义 冒烟测试是这样的一种测试，不要求覆盖面有多广，但至少要保证覆盖待测产品的绝大部分功能；不要求每个功能都测的很详细，但至少要保证被修复了的 bug 所属的功能和系统其他骨干功能都是可用的（即这个版本能拿去做系统功能测试了）。覆盖骨干功能和 bug 所属功能，却不是简简单单在页面中点几下就行了的。任何一个项目或者产品，骨干功能都有它的使用场景。冒烟测试就是要保证这些骨干功能的使用场景都

6、能跑通，如果没跑通，后续的系统测试就没必要了。冒烟测试方法 1.基于每日构建的冒烟测试 冒烟测试就是在每日 build 建立后，对系统的基本功能进行简单的测试。这种测试强调功能的覆盖率，而不对功能的正确性进行验证。冒烟测试一般用于每日构建(Nightly build)，构建服务器首先从 VSS 服务器上，下载最新的源代码，然后编译单元测试，运行单元测试通过后，编译可执行文件，可执行文件若可运行，并能执行最基本的功能，则认为通过了冒烟测试。基于每日构建的冒烟测试的优点主要有：a)进度可见并可以控制到 1-2 天的细粒度，很容易看到进度的偏差；b)及早的发现开发 BUG 和缺陷并分析解决，对开发人

7、员的一种监督和促进，提高软件质量 c)由于将大集成分解到每日构建中的小集成，避免了传统产品集成或集成测试时候出现的严重问题的可能。d)在项目中宣贯质量意识，强调第一次就把事情做好，而不是等测试来帮你发现问题 基于每日构建的冒烟测试也存在一些风险和缺陷，具体主要有：a)给开发人员太大压力，开发每天都在较紧张环境中工作 b)需要额外的测试人力资源和每日构建硬件环境的投入 c)开发人员不能专注，既要分心去修改 BUG，又要开发新的功能点 v1.0 可编辑可修改 6 d)对开发负责人要求更好，需要将功能细化到 1-2 天的有明确输出的功能点 e)发需要投入额外的精力来保证每日构建顺畅 基于每日构建的冒

8、烟测试适用场景 a)对进度偏差控制和要求很高的项目 b)开发检查点和里程碑制定的很细致的项目 c)采用增量和迭代开发的项目,快速和敏捷开发的项目 2.基于送测版本的冒烟测试 此种方法来源于每日构建和冒烟测试，只是把粒度放大了。不是做每日 build，而是根据版本计划，开发组定期发布送测版本，测试组拿到新的版本先做冒烟测试，测试通过则开始正式测试，不通过就返给开发组。这种做法的优点可以避免微软的每日 build 和冒烟测试做法的一些缺陷，同时也会因粒度粗而有自身的缺点，在此就不做详述。测试实施 测试实现过程 1.测试规划阶段：冒烟测试用例的编写，以及测试执行，都是需要时间成本的，故在最初制作项目

9、计划时，就应该识别该任务，并充分考虑其工作量。根据项目实际，确定在单元测试，集成测试，系统测试的哪个或哪几个阶段开展冒烟测试，明确准入准出标准。2.冒烟测试用例设计：分析系统主要功能和业务流程，编写覆盖这些功能的正向测试用例，推荐使用正交表，运用正交法制定一套测试用例。如果没有用例就无法跟踪和掌握整个冒烟测试的重点，以及各个版本之间的冒烟对比。冒烟测试用例应该随着系统的不断扩展而不断扩展，它不应该是一成不变的。3.冒烟测试执行：每个版本发布时，根据版本包含的功能特性，评估需要执行的冒烟测试用例 4.冒烟测试结果输出：冒烟测试执行情况，通过的测试用例数，不通过的测试用例数，据v1.0 可编辑可修

10、改 7 此判断是否开始正式的测试。5.冒烟测试清单整理 A.整理冒烟测试功能点，根据需求清单，发布清单整理本次版本所有的功能点，作为冒烟功能测试点 B.整理冒烟流程测试用例，根据系统流程，筛选能够覆盖大部分功能的流程作为冒烟测试场景 6.冒烟测试规则 A.冒烟测试时发现冒烟功能不通过，将缺陷提入缺陷管理工具跟踪管理。B.冒烟测试功能点通过率低于 60%时，召开干系人会议，发起退测流程，发起版本申请。C.冒烟流程测试通过率低于 70%时，召开干系人会议，发起退测流程，发起版本申请。D.开发人员修复完冒烟测试所产生的问题后，重新发起版本送测申请，测试人员对送测版本重新进行冒烟测试 E.冒烟测试时间

11、不得超过 2-4 个小时。测试要点 1.业务流的测试，保证正常业务链路的通畅 2.工作流的测试，主要是测试流程流转是否正常，至于流程步骤的内容是否正确则不关注。3.关键功能的测试，至少要保证系统运转，以及一些正常功能实现。4.重要基本功能的测试，比如对核心业务有影响的一些增删改等 测试准入准出 冒烟测试的入口准则 a)软件版本已经发布 b)冒烟测试计划和测试变更需求和用例通过评审 v1.0 可编辑可修改 8 c)测试环境准备完毕 冒烟测试的出口准则 a)发现的致命和严重类缺陷为 0 b)所有必选测试场景的通过率=100%c)随即抽取的可选测试场景通过率80%冒烟测试自动化 冒烟测试可以手动执行

12、，可以考虑自动化执行。稳定的系统适合自动化冒烟测试，集成过程中的系统适合手工冒烟测试，因为冒烟测试内容在动态变化，变化中的自动化脚本维护工作量比较大。自动化冒烟测试脚本应当遵循的原则 1.覆盖主要功能；2.测试脚本要简单、易用和详细说明 3.测试脚本要独立 4.每个测试脚本要尽可能的独立 5.每个测试脚本覆盖的测试点要尽可能的单一 6.测试结果收集：留存每一次的测试结果，对比一段时间内的测试结果，可以知道产品那些功能点质量不稳定，如果同一个测试点在一段时间内经常不能够测试通过，那么这一部分的代码十分有必要进行 review，有可能存在更大的隐患。冒烟测试进阶 与开发人员协同工作 由于冒烟测试特

13、别关注更改过的代码，因此必须与编写代码的开发人员协同工作。必须了解以下内容：1、代码中进行了什么更改。若要理解该更改，必须理解使用的技术；开发人员可以提供相关说明。2、更改对功能有何影响。9 3、更改对各组件的依存关系有何影响。在进行冒烟测试前检查代码 在运行冒烟测试前，进行侧重于代码中的所有更改的代码检查。代码检查是验证代码质量并确保代码无缺陷和错误的最有效、最经济的方法。冒烟测试确保通过代码检查或风险评估标识的主要的关键区域或薄弱区域已通过验证，因为如果失败，测试就无法继续。在干净的调试版本中安装私有二进制文件 由于冒烟测试必须侧重于仅对更新后的二进制文件中的功能更改进行验证，所以必须通过

14、使用被测试文件的调试二进制文件来使测试在干净的测试环境中运行。注意：在冒烟测试中，使用不匹配的二进制文件进行测试是一个常见错误。为了避免此错误，当两个或多个更新后的二进制文件之间存在依赖项时，请在测试版本中包括所有更新后的二进制文件。否则，测试的结果可能无效。2.SIT 测试规范 测试的定义 System Integrate Test 的缩写，即系统整合测试 系统整合测试就是评估产品在其规格范围内的环境下工作，能否完成产品设计规格所需要的功能及与周边设备、应用软件的兼容性。大致可以分为硬、软件兼容性测试，认证测试。安装 Win/Linux/Unix 这些只是系统整合测试的一小部分硬件测试：所有

15、产品的周边设备，例如 CPU、DIMM、storage、NIC、USB 等软件测试：操作系统的安装，驱动的安装，以及配套应用软件的安装及使用等认证测试：Windows、Red Hat、VMWare 等。10 测试主要内容 功能测试 需求验证，恢复性测试（灾难测试，容错测试），接口测试，安装/升级测试，配置测试/兼容性测试，国际化测试，用户文档测试等等 非功能测试 性能测试，安全测试，易用性测试，冒烟测试，回归测试，随机测试，硬件系统专有测试（可靠性测试，可生产性测试，可维护性测试）测试方法介绍 配置测试/兼容性测试 主要包括组网测试和软硬件平台配置测试 组网测试的目的是测试系统是否满足其需求中

16、所支持的所有组网类型和组网规模 软硬件平台配置测试的目的是测试系统是否满足其需求中所支持的不同软硬件平台配置 兼容性测试是指系统适应能力测试，可分为环境兼容性测试和版本兼容性测试 性能测试 为了验证系统是否达到用户提出的性能指标，同时发现系统中存在的性能瓶颈，起到优化系统的目的 在正常，峰值以及异常负载条件下，测试系统的各项性能指标 11 安全性测试 安全测试就是检查系统对外部的非法侵入的抵御能力。系统安全测试的准则是，测试非法侵入的代价是否超过被保护信息的价值 信息安全与保密不同于人身安全和重大财产损失 在公司的产品研发中，需要重点考虑的是信息安全方面 随着 ISO14000/18000 的

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

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

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

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

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

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

23、可编辑可修改 15 系统测试总体计划纳入配置管理 测试设计阶段主要活动 SIT 测试设计阶段与执行阶段常见的风险 不做测试设计，或者测试过程并未按照 SIT 测试总体计划的要求来做 测试设计不详细，不是基于可度量的测试策略，例如测试计划覆盖一个集合或者测试需求的一个子集 测试过程没有检验测试需求 测试总体计划中测试策略没有对应性 测试过程不可重复或者不可重用 SIT 测试设计和执行阶段度量 需求覆盖率（百分比）=测试覆盖的需求/所有需求*100%测试用例的数量（条）自动化测试在 SIT 测试中的比例（百分比）=采用自动化测试的 SIT 测试用例数目/全部的测试用例数目*100%测试用例设计和开

24、发的工作量（人时）SIT 测试文档评审工作量（人时）v1.0 可编辑可修改 16 测试执行和评估阶段主要活动 SIT 测试执行阶段与评估阶段常见风险 没有制定系统测试详细计划，测试开始之前测试人员不能明确本次 SIT 测试活动应测试的测试用例 测试执行不按照 SIT 测试详细计划的要求来做，不能确保计划要求的测试用例都能的到执行 未对测试的原始数据进行记录 本次 SIT 测试新的有效测试规程和测试用例并未及时的给予记录和管理 项目组和产品组的压力有可能导致测试人员的测试评估不够客观准确 没有有效利用各种自动化测试手段，手工测试太多。SIT 测试执行和评估阶段常用度量 测试用例通过率（百分比）=

25、本次测试中通过的用例数/实际执行的用例数 测试用例覆盖率（百分比）=本次测试中实际执行的用例数/计划执行的用例数 本次测试中测试通过的 SIT 测试用例数目 本次测试中测试不通过的 SIT 测试用例数目 已发现的缺陷数目以及缺陷严重级别 已经解决的缺陷数目以及缺陷等级 17 遗留的缺陷数目以及缺陷等级 缺陷密度（分布图）测试工时 SIT 测试的需求覆盖率 SIT 测试的若干原则 应尽早地开始 SIT 测试工作 充分注意测试中的缺陷密集现象，即对缺陷比较密集的部分进行重点测试 严格执行测试计划，排除测试的随意性 对测试过程和测试结果进行评价，确保测试过程的有效性 妥善保存测试计划，测试用例，故障

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

27、是可以正常运行的。提供 SIT 相关测试数据。在保证系统的单元测试和功能测试已经通过后，再进入系统集成测试（SIT）阶段。18 SIT 准出标准 最后测试的系统版本沒有严重級別较高的缺陷出現 最后发布的几个测试版本，发现的功能缺陷数量沒有上升趋势 最后测试的系统版本的缺陷数量控制在一定的范围內。新增功能缺陷少于已有缺陷的千分之二，reopen 率少于百分之五（建议）所有严重級別为 Falat、High 的缺陷都已经关闭，95%的功能缺陷已经关闭。最后测试的系统版本发现的缺陷是经過业务（实施）部门确认容许存在 3.UAT 测试规范 UAT（User Acceptance Test），用户验收测试

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

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

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

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

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

33、据得到的测试结果最真实可靠；同时也能有效的避免研发和测试人员在前期形成的定式思维。从而能更有效的发现潜在问题。3.UAT 测试一般来讲是上线前最后一次需求确认的机会，一旦系统推广上线后再 发现某些需求不满足或者实现出现了偏差，修改和维护的成本大幅提高，造成时间和费用的双重消耗 4.预发布环境测试规范 预发布定义 预发布指 SIT 测试,UAT 测试通过后，版本发布上线前，在指定环境上，进行冒烟测试，通过后预发布流程结束，这个过程中所要遵循的流程规范。其中涉及项目经理（版本负责人）、开发主管、测试主管以及配置管理员、QA 这 5 个角色。角色与职责 项目经理 1启动版本预发布流程的决策者。2版本

34、配套文档清单的检查者。3分支打包的执行者。配置管理员 1 版本控制和发布环节的协调人。2 获取发布版本，负责项目版本配套文件的收集及归档。22 3 测试版本的提供者。开发主管 1 与版本相关的输出物清单的提供者；2 安装配置手册、迭代版本说明的提供者；测试主管 1与开发主管配合执行冒烟测试并使之通过 QA 1检查项目版本控制及发布流程的规范性。2检查项目版本配套文件清单的完整性。版本预发布工作流程图 23 预发布版本控制流程开发主管项目经理（版本负责人）配置管理员测试主管QA阶段开始开发功能/修改BUG执行SIT/UAT测试任务SIT/UAT是否通过提供安装配置手册，发布部署脚本，版本配置清单

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

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

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

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

39、管理员归档并以此作为填写预发布记录表的依据，同时邮件通知测试主管针对此版本开展测试工作。版本文件清单主要包括：部署包/升级包、数据库脚本、版本说明、安装配置手册。版本测试记录表 版本测试记录表由配置管理员填写并维护。配置管理员根据每次提交测试的版本信息进 26 行记录，以版本测试记录表的形式存档。预发布环境小结 1.预发布环境，就是线上环境、正式生产环境，为避免因为测试环境和线上环境的差异性等带来的缺陷漏测而设立的一套环境，其配置等基本和线上一致，只是预发布环境web 服务器不在线上集成服务器范围之内，为单独的一台机器；2.预发布环境不能被线上用户访问 通常这里的技术实现是这样的：把预发布环境

40、的访问域名设置成和线上环境的不一样，通过配置 host 来访问预发布环境 3.预发布环境和线上环境公用数据库，即预发布环境使用的是线上的数据库 问题：如果新版本程序需要更改表结构等，比如加个表字段，那么，部署到预发布环境时也需要更改表字段，这个可能会影响线上环境程序代码的运行，如何解决 解决办法：1.先把预发布环境使用的数据库切换为测试环境使用的数据库 2.根据实际部署过程，如果有必要，接着，可有针对性的测试下数据库的变更是否会影响线上当前代码程序的运行 3.把新代码部署到预发布环境，测试程序是否正常运行 4.预发布测试完毕，如果没问题，先上线数据库，即在正式环境执行对应的数据库变更操作 5.

41、紧接着，把预发布环境连接的数据库切换为线上环境使用的数据库，再次进行预发布环境的测试 6.最后，如果预发布环境测试通过，则把预发布环境的代码部署到线上生产环境。27 注：1.如果不需要更改数据库表结构等，则无需切换预发布环境环境使用的数据库，即预发布使用线上的数据库。2.这里，因为预发布环境本身就是线上环境，测试完预发布，也基本代表线上环境测试完成。这样还可以避免发布到正式环境还得再测一遍的情况 5.生产环境测试规范 系统上线标准流程规范 为规范分公司系统上线管理，明确系统上线管理的工作要求，合理配置资源，确保上线能够正常完成，特制订本规范。在已开发完毕的各系统正式部署生产环境前要严格按照以下

42、流程进行上线前检查 28 基本流程 系统上线准备用户测试并验收系统上线用户生产验证系统上线结束 1)在系统开发完毕后首先模拟配置生产环境，并将系统部署至模拟/准生产环境。2)开发人员对各自开发模块功能文档化并制定测试方案，特别注意临界点测试方案。3)内测完毕后交由相关业务及需求人员进行集成测试，并请测试人员记录测试结果及问题，交由相关开发人员进行再次迭代。完成后测试方须交付测试结果报告。4)由技术人员进行系统上线，系统上线成功并且相关业务及需求人员进行生产验证后需提交系统验收报告 详细流程 根据系统上线的类型可分为完整上线及补丁上线两种，流程规范如下 29 30 完整上线流程 31 完整系统线

43、上准备是否有验收报告是否具备数据，程序，日志等备份机制是是否具备系统日常维护及应急方案是否具有完整的上线方案系统上线的硬件以及操作系统环境是否准备妥当系统上线资料检查核对是否无误系统上线验证系统上线是否成功指定系统维护负责人并指定应急演练计划回退，确认原因并指定后续计划完整系统上线结束是是是是是是是否否针对不同的项目需求方，验收报告可以由市场、业务、技术提供。包含备份说明文档及相应程序或脚本等包含日常维护文档、应急方案文档等。上线方案必须在测试环境或准生产环境经过验证。硬件环境包括服务器硬件及网络环境等。上线资料包含安装包、数据库脚本、配置文件等。上线后的生产验证结果是判断是否成功的唯一标准

44、32 补丁上线流程 补丁上线准备是否有验收报告是否具有完整的上线方案系统上线资料检查核对是否无误备份旧程序，数据等相关原系统的所有信息副本系统上线验证系统上线是否成功指定系统维护负责人并指定应急演练计划回退，确认原因并指定后续计划完整系统上线结束是否是是是是上线后的生产验证结果是判断是否成功的唯一标准否除BUG外的补丁必须有验收报告。上线方案必须在测试环境或准生产环境经过验证。上线方案中必须有回退步骤。上线资料包含安装包、数据库脚本、配置文件等。33 6.回归测试规范 回归测试原因&意义 在软件生命周期中的任何一个阶段，只要软件发生了改变，就可能给该软件带来问题。因此，每当软件发生变化时，我们

45、就必须重新测试现有的功能，以便确定修改是否达到了预期的目的，检查修改是否损害了原有的正常功能。1）发现了错误并做了修改：当软件中所含错误被发现时，如果错误跟踪与管理系统不够完善，就可能会遗漏对这些错误的修改；开发者对错误理解得不够透彻，也可能导致所做的修改只修正了错误的外在表现，而没有修复错误本身，从而造成修改失败。修改还有可能产生副作用从而导致软件未被修改的部分产生新的问题，使本来工作正常的功能产生错误。2）增加或者修改软件原有逻辑的时候：除了新加入的代码中有可能含有错误外，新代码还有可能对原有的代码带来影响。新的代码没有问题，但是新加入的或者受到修改的流程或者逻辑对原有逻辑产生影响，从而导

46、致问题。回归测试定义 回归测试是指修改了代码后，对系统进行一定程度的全面测试以确认修改没有引入新的错误或导致其他代码产生错误。回归测试核心思想 检验软件原有功能在修改后是否保持正确。34 回归测试的策略 策略 1）全部用例 使用测试用例库中的全部测试用例组成回归测试用例库。最低的遗漏回归错误的风险，但测试成本最高。2）基于用例优先级选择测试 可以基于用例优先级来选择回归测试用例。制定一定的挑选标准，如 T0 级别的 bug 需要在回归的时候全部运行，T1 的运行 30%。再根据本版本的功能，适当的加大新功能模块的回归力度。3）基于风险选择测试 可以基于一定的风险标准来选择回归测试用例。首先运行

47、最重要的、关键的和可疑的测试，而跳过那些非关键的、优先级别低的或者高稳定的测试用例。4）基于操作剖面选择测试 可以优先选择那些针对最重要或最频繁使用的业务流程，释放和缓解最高级别的风险，有助于尽早发现那些对流程有最大影响的故障。5）再测试修改的部分 回归测试局限于被改变的模块和它的接口上。通常，一个回归错误一定涉及一个新的、修改的或删除的代码段。在允许的条件下，回归测试尽可能覆盖受到影响的部分。执行过程 1）建立基线测试用例库 根据以往的积累，收集本系统测试用例。梳理用例架构，使得用例的管理有序 梳理用例级别，提高执行时的选择灵活性 35 梳理用例版本，定期维护用例库 2）根据策略选择用例，生

48、成回归测试用例集 每个版本的回归测试，根据所拥有的资源（人员，时间），来决定回归测试的策略。根据所选择的策略，从测试用例库中挑选本次版本需要进行回归测试的用例。3）执行回归测试 根据回归测试用例集，执行回归测试 执行的时机 1）在每一轮测试阶段完成，要进入下一阶段时 2）测试阶段的 bug 已经修复到一定程度 3）基于一个稳定的系统版本进行 基于晶链通的策略 现状 1）暂无完整的测试用例，且没有进行等级定义 之前的测试用例，是基于测试点的，粒度太大。没有进行级别的定义，挑选效率可能会比较低 2）流程变更频繁 无法针对回归测试，专门准备一套回归测试用例。由于流程变更较为频繁，导致如果要为回归测试

49、专门准备用例，需要较大的维护资源。3）实际业务复杂 晶链通的每个大客户从不同的角度使用系统。不同的第三方系统的接入，导致不同的数据风格。36 基于现状的策略 1）脱离用例，从功能出发 收集整理系统现有的功能点，精确到每个页面具体的功能，如增删改查。对核心模块的功能，深化功能点，如物流订单的五种类型，装车的 N 种方式。2）脱离业务，从系统流程出发 不考虑实际的业务，梳理系统流程，根据流程增加所需要涉及的功能模块。对步骤 1 所选择的测试点进行串联。步骤 1、2 所确定的范围，可以作为每次回归测试用例集的基础文档，每个版本根据实际情况进行更新和维护。3）结合业务，补充覆盖 考虑几个大客户的使用场

50、景，对 1、2 点所挑选的回归测试点，进行补充。4）基于版本功能，增加深度 本次版本新增或者修改的功能点，以及这些模块会涉及影响的其余模块，需要加大回归测试的粒度。晶链通实例 晶链通的功能点 1）功能清单 根据菜单，列出功能的具体框架 收集每个页面的功能点，一般可以以按钮为关键点展开 细化每个功能点的隐藏逻辑，考虑核心信息的覆盖，如下：二级菜单 三级菜单 大块功能点 细化功能点 首页 首页 dashboard 货主首页 订单状态累计 订单类型统计 37 在途订单分布图 物流商订单统计及排名 物流商 KPI 考核统计及排名 订单预警分布图 供应商首页 物流订单汇总 承运订单汇总 转出订单统计 每