平台功能测试规范

66平台功能测试规范目录目的6范围6对象61. 冒烟测试规范61.1冒烟测试目的61.2冒烟测试定义71.3冒烟测试方法71.4测试实施81.4.1测试实现过程81.4.2测试要点101.4.3测试准入准出101.4.4冒烟测试自动化101.5冒烟测试进阶112. SIT测试规范122.1SIT测试的定义122.2SIT测试主要内容122.2.1功能测试122.2.2非功能测试132.2.3测试方法介绍132.3SIT测试过程172.3.1项目周期中的SIT测试阶段划分172.3.2SIT测试计划阶段主要活动182.3.3SIT测试设计阶段主要活动182.3.4SIT测试执行和评估阶段主要活动202.4SIT准入准出标准213. UAT测试规范223.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.5版本配套文件清单304.6版本测试记录表314.7预发布环境小结315. 生产环境测试规范325.1系统上线标准流程规范325.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定义范围和深度436.6.3执行过程及结果跟踪467. 线上问题处理与反馈467.1线上问题的定义467.2线上故障管理的目标477.3故障处理流程介绍477.4确认故障与通知协调人487.5定位/处理故障487.6故障恢复497.7组织故障Review497.8同步故障报告517.9建立每个Action 禅道子任务517.10故障与故障Actions跟进517.11故障数据分析517.12线上问题总结52目的本文档的目的在于指导测试人员如何进行冒烟测试，SIT测试，UAT测试，预发布环境测试，生产环境测试以及线上问题处理。规范测试活动。以及一些测试活动中常见的问题。范围包含的测试活动有冒烟测试，SIT测试，UAT测试，预发布环境测试，生产环境测试，回归测试以及线上问题处理与反馈，可以根据项目或者平台的实际情况对活动进行裁剪。对象本文档面向对象为测试人员，实施人员等1. 冒烟测试规范1.1冒烟测试目的冒烟测试（Smoke Testing）可以说是一种预测试，软件代码正式编译并交付测试之前，先尽量消除其“表面的”错误，确保软件基本功能符合需求规格说明书要求，减少后期测试开发的负担。在软件开发过程中，一直有高内聚，低耦合这样的说法，各个功能模块之间的耦合还是存在的，因此一个功能的改动，还是会影响到其他功能模块。因此在开发人员修复了先前测试中发现的bug后，想知道这个bug的修复是否会影响到其他功能模块，需要做的就是冒烟测试。1.2冒烟测试定义冒烟测试是这样的一种测试，不要求覆盖面有多广，但至少要保证覆盖待测产品的绝大部分功能；不要求每个功能都测的很详细，但至少要保证被修复了的bug所属的功能和系统其他骨干功能都是可用的（即这个版本能拿去做系统功能测试了）。覆盖骨干功能和bug所属功能，却不是简简单单在页面中点几下就行了的。任何一个项目或者产品，骨干功能都有它的使用场景。冒烟测试就是要保证这些骨干功能的使用场景都能跑通，如果没跑通，后续的系统测试就没必要了。1.3冒烟测试方法1. 基于每日构建的冒烟测试冒烟测试就是在每日build建立后，对系统的基本功能进行简单的测试。这种测试强调功能的覆盖率，而不对功能的正确性进行验证。冒烟测试一般用于每日构建(Nightly build)，构建服务器首先从VSS服务器上，下载最新的源代码，然后编译单元测试，运行单元测试通过后，编译可执行文件，可执行文件若可运行，并能执行最基本的功能，则认为通过了冒烟测试。l 基于每日构建的冒烟测试的优点主要有：a) 进度可见并可以控制到1-2天的细粒度，很容易看到进度的偏差；b) 及早的发现开发BUG和缺陷并分析解决，对开发人员的一种监督和促进，提高软件质量c) 由于将大集成分解到每日构建中的小集成，避免了传统产品集成或集成测试时候出现的严重问题的可能。d) 在项目中宣贯质量意识，强调第一次就把事情做好，而不是等测试来帮你发现问题l 基于每日构建的冒烟测试也存在一些风险和缺陷，具体主要有：a) 给开发人员太大压力，开发每天都在较紧张环境中工作b) 需要额外的测试人力资源和每日构建硬件环境的投入c) 开发人员不能专注，既要分心去修改BUG，又要开发新的功能点d) 对开发负责人要求更好，需要将功能细化到1-2天的有明确输出的功能点e) 发需要投入额外的精力来保证每日构建顺畅l 基于每日构建的冒烟测试适用场景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测试准入准出l 冒烟测试的入口准则a) 软件版本已经发布b) 冒烟测试计划和测试变更需求和用例通过评审c) 测试环境准备完毕l 冒烟测试的出口准则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的缩写，即系统整合测试 系统整合测试就是评估产品在其规格范围内的环境下工作，能否完成产品设计规格所需要的功能及与周边设备、应用软件的兼容性。大致可以分为硬、软件兼容性测试，认证测试。安装Win/Linux/Unix这些只是系统整合测试的一小部分硬件测试：所有产品的周边设备，例如CPU、DIMM、storage、NIC、USB等软件测试：操作系统的安装，驱动的安装，以及配套应用软件的安装及使用等认证测试：Windows、Red Hat、VMWare等。2.2SIT测试主要内容2.2.1功能测试需求验证，恢复性测试（灾难测试，容错测试），接口测试，安装/升级测试，配置测试/兼容性测试，国际化测试，用户文档测试等等2.2.2非功能测试性能测试，安全测试，易用性测试，冒烟测试，回归测试，随机测试，硬件系统专有测试（可靠性测试，可生产性测试，可维护性测试）2.2.3测试方法介绍2.2.3.1配置测试/兼容性测试主要包括组网测试和软硬件平台配置测试组网测试的目的是测试系统是否满足其需求中所支持的所有组网类型和组网规模软硬件平台配置测试的目的是测试系统是否满足其需求中所支持的不同软硬件平台配置兼容性测试是指系统适应能力测试，可分为环境兼容性测试和版本兼容性测试2.2.3.2性能测试为了验证系统是否达到用户提出的性能指标，同时发现系统中存在的性能瓶颈，起到优化系统的目的在正常，峰值以及异常负载条件下，测试系统的各项性能指标2.2.3.3安全性测试安全测试就是检查系统对外部的非法侵入的抵御能力。系统安全测试的准则是，测试非法侵入的代价是否超过被保护信息的价值信息安全与保密不同于人身安全和重大财产损失在公司的产品研发中，需要重点考虑的是信息安全方面随着ISO14000/18000的实施，这方面的内容会增多安全测试主要关注点主要方法：1.SQL注入测试2.权限测试3.脚本注入测试4.跨目录测试5.隐通道测试常见故障：1.系统缓冲区溢出，堆栈溢出错误。2.系统存在密码安全，权限管理，数据安全方面的漏洞，可被轻易的进入并进行非法获取和破坏。2.2.3.4恢复性测试检查系统的容错能力，测试系统在遇到系统奔溃，硬件损坏或其他灾难性问题后能否很好的恢复，测试的具体内容包括创建各种可能的灾难状况，测试系统从异常状态恢复到正常状态所需的时间，花费的代价，对周边设备和系统造成的影响，系统恢复的完整性和一致性等常用的方法主要是制造系统异常，按系统恢复功能进行恢复操作，直至系统继续正常运行为了测试系统恢复之后是否运行正常，也可以采用一些自动化测试工具进行回归测试，以提高测试的效率。常见故障：1.系统发生异常后无法恢复，造成系统数据被破坏，即重启系统，恢复备份数据也不可行，2.严重的可能造成系统硬件故障3.系统恢复时间过长，代价过高4.系统不能完全恢复到原来的正常状态，造成一定损失5.系统恢复过程对周边设备和环境造成较大影响，无法消除等2.2.3.5易用性测试对用户体验度的关注度提高，每个系统上线后产生的事件数作为了易用性评判的主要依据以用户的角度来对软件界面的易用性，风格，合理性等方面进行评估和测试，通常包括软件的界面显示测试和界面功能测试而界面功能测试主要结合系统功能进行测试。测试要点和常见的故障易用性与合理性：步骤繁琐的操作，比例不协调，摆放凌乱的窗口和控件，层次过多的子窗口和菜单规范性：不符合Windows规范的控件设计，与常规Windows操作不符的流程与操作等容错性：编辑控件对非法字符，超出边界值的输入处理不当或没有提示，容易造成系统重启，数据删除丢失等的操作没有提示等帮助：无帮助信息提供，或者不提供获取帮助的快捷操作美观与风格：界面颜色不协调，界面风格与公司相关产品风格不符，与业界通用风格不符，图片，图标等不符合公司UI规范资源：界面长时间运行操作造成系统内存耗尽，界面对系统资源独占使用等2.2.3.6安装升级测试安装升级测试是以最终用户的角度测试系统的可安装性以及系统是否具有升级或者卸载功能，安装升级测试，需要重点测试系统的软硬件平台的兼容性主要内容：1.安装升级基本功能测试2.卸载测试（可选）3.平台兼容性测试4.易用性与合理性测试5.健壮性测试常用工具通常手工进行，可借助录制回放工具进行反复的软件安装测试常见故障1.系统的软硬件不能兼容2.系统软件在不同的平台下安装后不能正常工作3.系统版本升级后，无法正常工作，系统无法回退到升级前的版本4.系统的硬件安装不符合用户习惯5.系统的软硬件安装升级过程和用户文档的叙述不一致，甚至错误，误导最终用户2.2.3.7文档/帮助测试各种用户文档和联机帮助系统是软件产品的重要组成部分，保证其正确性也是软件测试工程师的职责，文档/帮助测试的目的在于：1.提高易用性，使软件用户更容易地学习和使用软件产品2.提高可靠性，如果用户阅读文档，然后使用软件，最终得不到预期结果，这就是可靠性差3.降低支持费用，好的文档/帮助通过恰当的解释和引导可以在用户有麻烦或者遇到意外情况时减少请求公司帮助从用户的角度来测试软件文档是非常有效的方法，仔细阅读，跟随每个步骤，检查每个图形，尝试每个示例，利用这个现实的简单方法，可以找出软件和文档中的缺陷，常用的方法有：1.评审和审查，检查文档的编辑清晰性2.动态测试，结合实际程序的使用而使用文档3.让独立的第三方（如用户）或其他人员（如以前没有接触或者使用过本系统的新手）在程序的使用语境测试文档也十分有效的方法2.2.3.8随机测试俗称猴子测试最好由用户代表进行公司内部可结合新员工/工程/客服人员培训进行应该有适当的组织和计划2.3SIT测试过程2.3.1项目周期中的SIT测试阶段划分SIT测试计划阶段SIT测试设计和编码阶段SIT测试执行和评估阶段2.3.2SIT测试计划阶段主要活动制定SIT测试总体计划l 简述项目，明确测试的范围l 定义测试策略（阶段，类型，技术，标准等）l 编制测试需求l 工作分解和估算l 资源分配l 进度表l 风险识别与应对SIT测试总体计划评审批准SIT测试总体计划系统测试总体计划纳入配置管理2.3.3SIT测试设计阶段主要活动SIT测试设计阶段与执行阶段常见的风险不做测试设计，或者测试过程并未按照SIT测试总体计划的要求来做测试设计不详细，不是基于可度量的测试策略，例如测试计划覆盖一个集合或者测试需求的一个子集测试过程没有检验测试需求测试总体计划中测试策略没有对应性测试过程不可重复或者不可重用SIT测试设计和执行阶段度量需求覆盖率（百分比）=测试覆盖的需求/所有需求*100%测试用例的数量（条）自动化测试在SIT测试中的比例（百分比）=采用自动化测试的SIT测试用例数目/全部的测试用例数目*100%测试用例设计和开发的工作量（人时）SIT测试文档评审工作量（人时）2.3.4SIT测试执行和评估阶段主要活动SIT测试执行阶段与评估阶段常见风险没有制定系统测试详细计划，测试开始之前测试人员不能明确本次SIT测试活动应测试的测试用例测试执行不按照SIT测试详细计划的要求来做，不能确保计划要求的测试用例都能的到执行未对测试的原始数据进行记录本次SIT测试新的有效测试规程和测试用例并未及时的给予记录和管理项目组和产品组的压力有可能导致测试人员的测试评估不够客观准确没有有效利用各种自动化测试手段，手工测试太多。SIT测试执行和评估阶段常用度量测试用例通过率（百分比）=本次测试中通过的用例数/实际执行的用例数测试用例覆盖率（百分比）=本次测试中实际执行的用例数/计划执行的用例数本次测试中测试通过的SIT测试用例数目本次测试中测试不通过的SIT测试用例数目已发现的缺陷数目以及缺陷严重级别已经解决的缺陷数目以及缺陷等级遗留的缺陷数目以及缺陷等级缺陷密度（分布图）测试工时SIT测试的需求覆盖率SIT测试的若干原则应尽早地开始SIT测试工作充分注意测试中的缺陷密集现象，即对缺陷比较密集的部分进行重点测试严格执行测试计划，排除测试的随意性对测试过程和测试结果进行评价，确保测试过程的有效性妥善保存测试计划，测试用例，故障统计和最终分析报告，为维护提供方便对于被测系统要进行正常和异常两方面的测试在系统测试计划中，要按照资源和项目的要求清晰的定义一个完整的退出准侧，这是一种权衡投入/产出比的原则，测试即不要不充分，也不要过分2.4SIT准入准出标准SIT准入标准系统功能开发完毕，开发部门完成单元测试，保证系统的功能已经实现。开发部门提供测试版本，并提供相关的版本说明，对发布版本的情况进行概要说明。系统的单元测试已经完成，并提供单元测试报告。系统的功能测试已经完成，并提供功能测试报告。提供独立的SIT测试环境，保证被测版本可以正常运行。测试版本在SIT测试环境进行连通性测试，确保系统的重要模块以及重要功能点是可以正常运行的。提供SIT相关测试数据。在保证系统的单元测试和功能测试已经通过后，再进入系统集成测试（SIT）阶段。SIT准出标准最后测试的系统版本沒有严重級別较高的缺陷出現最后发布的几个测试版本，发现的功能缺陷数量沒有上升趋势最后测试的系统版本的缺陷数量控制在一定的范围內。新增功能缺陷少于已有缺陷的千分之二 ，reopen 率少于百分之五（建议）所有严重級別为 Falat 、 High的缺陷都已经关闭， 95% 的功能缺陷已经关闭。最后测试的系统版本发现的缺陷是经過业务（实施）部门确认容许存在3. UAT测试规范UAT（UserAcceptanceTest），用户验收测试，或用户可接受测试，系统开发生命周期方法论的一个阶段，这时相关的用户或独立测试人员根据测试计划和结果对系统进行测试和接收。它让系统用户决定是否接收系统。它是一项确定产品是否能够满足合同或用户所规定需求的测试。这是管理性和防御性控制。3.1UAT测试目的本阶段测试是为了测试开发出来的产品是否能够满足用户的需求，因为只有用户实际使用了产品，根据实际体验才能知道产品是否能满足要求。同时也是为了找出在实际环境中可能出现的一些Bug，并及时修复3.2UAT测试参与人员UAT测试顾名思义可以知道测试的主体应该是实际客户，本阶段的测试需要客户直接参与，因为研发、测试甚至PM都不能准备的了解客户实际环境下如何使用产品，所有本阶段的测试参与者主要是实际客户3.3UAT测试用例UAT的用例原则上来讲应该是用户自行按照实际使用来设计，但考虑到客户对新系统的不熟悉，可以采用测试人员设计用例，邀请实际客户参与评审的方式来设计用例。3.4UAT测试范围测试应该包含安装、环境部署、各个子模块的基本功能等系统一个完成过程中的所有部分（也包含用户手册），同时应该根据用户实际使用环境着重测试客户使用频率高的模块，尽可能将用户常用模块中可能隐藏着的问题发现出来并修改。3.5UAT测试前提UAT需要满足一定的条件才能开始，进行UAT的产品理论上来说，必须已经全部开发、测试完毕，代码状态处于冻结状态，所有测试出来的bug都已经被妥善处理，重大的bug都被解决，并验证通过。对于一些低级别bug，要么决定被写入发布公告中，要么被设置为不需要修改的问题。在实际项目操作过程中，由于计划进度原因达不到理论状态前提，UAT的效果也达不到应有的效果。3.6UAT测试策略UAT测试理论上是用户按照使用手册进行操作，或者安排组织客户培训后让用户操作。测试过程应该有用户独立完成各个步骤，根据用户要求可以安排研发或测试的人员陪同测试，既能在过程中起到指导帮助作用，也能在测试发现Bug的时候做第一时间的调查分析。3.7UAT测试通过条件l 成功地执行了测试计划中规定的测试用例；修正了所发现的功能性错误；l 用户肯定测试结果，并通过了专门小组的评审，评审人员应该包含客户、产品经理、项目经理、研发负责人、测试负责人等。l 最后用户在确认书上签字认可测试结果，确认产品能够满足客户需求。3.8UAT的测试难点以及建议难点1.用例设计无法有限覆盖实际环境：很多时候UAT测试用例仍然是由测试人员甚至是开发人员设计，他们并不能真正的了解真实客户更多的需求，也无法完全知道用户的真实使用环境，所以设计出来的UAT用例很多时候仍然是系统测试级的用例。2.客户对系统不熟悉：客户在实际测试的时候或多或少还是存在着对系统不熟悉的情况，测试效率不高，进度比较慢；再者很多时候客户不愿意安排人员来进行UAT测试，UAT测试实际上仍然是测试人员完成，由于使用习惯和思维惯性，使得潜在的问题不易发现，造成问题遗漏。3.认为UAT可有可无：因为进入到此阶段本身就意味着开发和测试进入到后期，已经完成了系统测试，认为已经完成了系统测试，系统就没有大的问题，UAT可以不开展了，这样节约系统上线时间，早日带来价值建议1.尝试在开发的过程中邀请客户参与，尤其是当重要功能集成好后，应该立即邀请客户参与到测试中来，即可让用户尽早熟悉系统，对产品有一个初步的认识，又可以在用户体验后及时了解用户的需求更新（如易用性），并落实更改。2.坚持UAT测试，因为用户在使用系统的时候是为了完成真实任务和工作，是最真实的使用环境和真实的数据，真实环境的真实数据得到的测试结果最真实可靠；同时也能有效的避免研发和测试人员在前期形成的定式思维。从而能更有效的发现潜在问题。3.UAT测试一般来讲是上线前最后一次需求确认的机会，一旦系统推广上线后再发现某些需求不满足或者实现出现了偏差，修改和维护的成本大幅提高，造成时间和费用的双重消耗4. 预发布环境测试规范4.1预发布定义预发布指SIT测试,UAT测试通过后，版本发布上线前，在指定环境上，进行冒烟测试，通过后预发布流程结束，这个过程中所要遵循的流程规范。其中涉及项目经理（版本负责人）、开发主管、测试主管以及配置管理员、QA这5个角色。4.2角色与职责项目经理1启动版本预发布流程的决策者。2版本配套文档清单的检查者。3分支打包的执行者。配置管理员1版本控制和发布环节的协调人。2获取发布版本，负责项目版本配套文件的收集及归档。3测试版本的提供者。开发主管1与版本相关的输出物清单的提供者；2安装配置手册、迭代版本说明的提供者；测试主管1与开发主管配合执行冒烟测试并使之通过QA1检查项目版本控制及发布流程的规范性。2检查项目版本配套文件清单的完整性。4.3版本预发布工作流程图4.4预发布流程描述4.4.1预发布流程进入条件测试完成SIT测试以及UAT测试，准备进行版本发布上线的一次测试.4.4.2预发布流程结束条件预发布环境冒烟测试通过4.4.3预发布流程步骤1.预发布环境准备项目通过开发部内部集成测试后，开发主管通知项目经理代码具备提交测试部测试的条件1) 项目在Jenkins上持续测试通过，内部禅道中的Bug清理完毕（项目经理允许保留的除外）2) 开发主管提交输出物清单，并在清单中标注输出物在SVN上的存储路径（配置文件、数据库脚本、部署所需的文件夹（路径结构）、相关工具等等，程序安装包存储路径空白）。3) 开发主管提交版本说明，标明项目本次变更记录、项目当前的版本号等等。4) 开发主管提交安装配置手册（内部版），达到测试人员可以参照安装配置手册和输出物清单完成测试环境的部署2.预发布环境发布清单检查项目经理按照安装配置手册上面的清单对其内容进行逐一检查。检查内容包括:1) 项目经理需要检查配置文件是否是默认通用配置文件，开发主管配合；2) 项目经理与测试部门配合检查部署手册及源码等配套文件的合理性；3) 版本是否正确，是否有更改，是否与版本说明一致。3. 检查通过后，项目经理执行分支打包。更新输出物清单，将程序安装包存储路径修改为下载URL地址（即持续集成上部署包的路径）4. 项目经理通知配置管理员将输出物清单中的输出物上传到SVN的项目测试/测试对象目录中（与配套文挡存放目录一致），然后通知测试部门并抄送相关人员进行测试。并对测试对象编号版本、测试内容、测试轮次进行记录。5.测试人员从SVN的项目测试/测试对象目录中获取安装配置手册，按照安装配置手册中的输出物清单及配置流程进行环境搭建，并开展冒烟测试工作。在测试过程中，项目经理配合测试人员检查部署包及其配套文件的正确性，如有问题，通知开发主管进行修改和更新。6.冒烟测试通过后，测试人员发送冒烟测试通过邮件给相关人员并抄送QA。完成预发布流程中必须的文档和目标条件：（1）输出物清单均已提交svn，并放入指定目录；（2）项目经理已审核通过。预发布流程结束。7.QA对预发布做审核，审核预发布流程的规范性，并按照安装配置手册的文件清单检查配套文件提交的正确性。如有不符合项，QA发出邮件提醒项目经理及时解决。4.5版本配套文件清单版本配套文件清单内容主要由开发主管负责提供并填写。由配置管理员归档并以此作为填写预发布记录表的依据，同时邮件通知测试主管针对此版本开展测试工作。版本文件清单主要包括：部署包/升级包、数据库脚本、版本说明、安装配置手册。4.6版本测试记录表版本测试记录表由配置管理员填写并维护。配置管理员根据每次提交测试的版本信息进行记录，以版本测试记录表的形式存档。4.7预发布环境小结1.预发布环境，就是线上环境、正式生产环境，为避免因为测试环境和线上环境的差异性等带来的缺陷漏测而设立的一套环境，其配置等基本和线上一致，只是预发布环境web服务器不在线上集成服务器范围之内，为单独的一台机器；2.预发布环境不能被线上用户访问通常这里的技术实现是这样的：把预发布环境的访问域名设置成和线上环境的不一样，通过配置host来访问预发布环境3.预发布环境和线上环境公用数据库，即预发布环境使用的是线上的数据库问题：如果新版本程序需要更改表结构等，比如加个表字段，那么，部署到预发布环境时也需要更改表字段，这个可能会影响线上环境程序代码的运行，如何解决？解决办法：1. 先把预发布环境使用的数据库切换为测试环境使用的数据库2. 根据实际部署过程，如果有必要，接着，可有针对性的测试下数据库的变更是否会影响线上当前代码程序的运行3. 把新代码部署到预发布环境，测试程序是否正常运行4. 预发布测试完毕，如果没问题，先上线数据库，即在正式环境执行对应的数据库变更操作5. 紧接着，把预发布环境连接的数据库切换为线上环境使用的数据库，再次进行预发布环境的测试6. 最后，如果预发布环境测试通过，则把预发布环境的代码部署到线上生产环境。注：1. 如果不需要更改数据库表结构等，则无需切换预发布环境环境使用的数据库，即预发布使用线上的数据库。2. 这里，因为预发布环境本身就是线上环境，测试完预发布，也基本代表线上环境测试完成。这样还可以避免发布到正式环境还得再测一遍的情况5. 生产环境测试规范5.1系统上线标准流程规范为规范分公司系统上线管理，明确系统上线管理的工作要求，合理配置资源，确保上线能够正常完成，特制订本规范。在已开发完毕的各系统正式部署生产环境前要严格按照以下流程进行上线前检查5.2基本流程1) 在系统开发完毕后首先模拟配置生产环境，并将系统部署至模拟/准生产环境。2) 开发人员对各自开发模块功能文档化并制定测试方案，特别注意临界点测试方案。3) 内测完毕后交由相关业务及需求人员进行集成测试，并请测试人员记录测试结果及问题，交由相关开发人员进行再次迭代。完成后测试方须交付测试结果报告。4) 由技术人员进行系统上线，系统上线成功并且相关业务及需求人员进行生产验证后需提交系统验收报告5.3详细流程根据系统上线的类型可分为完整上线及补丁上线两种，流程规范如下5.3.1完整上线流程5.3.2补丁上线流程6. 回归测试规范6.1回归测试原因&意义 在软件生命周期中的任何一个阶段，只要软件发生了改变，就可能给该软件带来问题。因此，每当软件发生变化时，我们就必须重新测试现有的功能，以便确定修改是否达到了预期的目的，检查修改是否损害了原有的正常功能。1） 发现了错误并做了修改： 当软件中所含错误被发现时，如果错误跟踪与管理系统不够完善，就可能会遗漏对这些错误的修改； 开发者对错误理解得不够透彻，也可能导致所做的修改只修正了错误的外在表现，而没有修复错误本身，从而造成修改失败。 修改还有可能产生副作用从而导致软件未被修改的部分产生新的问题，使本来工作正常的功能产生错误。2） 增加或者修改软件原有逻辑的时候： 除了新加入的代码中有可能含有错误外，新代码还有可能对原有的代码带来影响。 新的代码没有问题，但是新加入的或者受到修改的流程或者逻辑对原有逻辑产生影响，从而导致问题。6.2回归测试定义 回归测试是指修改了代码后，对系统进行一定程度的全面测试以确认修改没有引入新的错误或导致其他代码产生错误。6.3回归测试核心思想检验软件原有功能在修改后是否保持正确。6.4回归测试的策略6.4.1策略1） 全部用例使用测试用例库中的全部测试用例组成回归测试用例库。最低的遗漏回归错误的风险，但测试成本最高。2） 基于用例优先级选择测试可以基于用例优先级来选择回归测试用例。制定一定的挑选标准，如T0级别的bug需要在回归的时候全部运行，T1的运行30%。再根据本版本的功能，适当的加大新功能模块的回归力度。3） 基于风险选择测试可以基于一定的风险标准来选择回归测试用例。首先运行最重要的、关键的和可疑的测试，而跳过那些非关键的、优先级别低的或者高稳定的测试用例。4） 基于操作剖面选择测试可以优先选择那些针对最重要或最频繁使用的业务流程，释放和缓解最高级别的风险，有助于尽早发现那些对流程有最大影响的故障。5） 再测试修改的部分回归测试局限于被改变的模块和它的接口上。通常，一个回归错误一定涉及一个新的、修改的或删除的代码段。在允许的条件下，回归测试尽可能覆盖受到影响的部分。6.4.2执行过程1） 建立基线测试用例库根据以往的积累，收集本系统测试用例。梳理用例架构，使得用例的管理有序梳理用例级别，提高执行时的选择灵活性梳理用例版本，定期维护用例库2） 根据策略选择用例，生成回归测试用例集每个版本的回归测试，根据所拥有的资源（人员，时间），来决定回归测试的策略。根据所选择的策略，从测试用例库中挑选本次版本需要进行回归测试的用例。3） 执行回归测试根据回归测试用例集，执行回归测试6.4.3执行的时机1）在每一轮测试阶段完成，要进入下一阶段时2）测试阶段的bug已经修复到一定程度3）基于一个稳定的系统版本进行6.5基于晶链通的策略6.5.1现状1） 暂无完整的测试用例，且没有进行等级定义之前的测试用例，是基于测试点的，粒度太大。没有进行级别的定义，挑选效率可能会比较低2） 流程变更频繁无法针对回归测试，专门准备一套回归测试用例。由于流程变更较为频繁，导致如果要为回归测试专门准备用例，需要较大的维护资源。3） 实际业务复杂晶链通的每个大客户从不同的角度使用系统。不同的第三方系统的接入，导致不同的数据风格。6.5.2基于现状的策略1） 脱离用例，从功能出发收集整理系统现有的功能点，精确到每个页面具体的功能，如增删改查。对核心模块的功能，深化功能点，如物流订单的五种类型，装车的N种方式。2） 脱离业务，从系统流程出发不考虑实际的业务，梳理系统流程，根据流程增加所需要涉及的功能模块。对步骤1所选择的测试点进行串联。步骤1、2所确定的范围，可以作为每次回归测试用例集的基础文档，每个版本根据实际情况进行更新和维护。3） 结合业务，补充覆盖考虑几个大客户的使用场景，对1、2点所挑选的回归测试点，进行补充。4） 基于版本功能，增加深度本次版本新增或者修改的功能点，以及这些模块会涉及影响的其余模块，需要加大回归测试的粒度。6.6晶链通实例6.6.1晶链通的功能点1） 功能清单根据菜单，列出功能的具体框架收集每个页面的功能点，一般可以以按钮为关键点展开细化每个功能点的隐藏逻辑，考虑核心信息的覆盖，如下：首页首页dashboard货主首页订单状态累计订单类型统计在途订单分布图物流商订单统计及排名物流商KPI考核统计及排名订单预警分布图供应商首页物流订单汇总承运订单汇总转出订单统计每日订单数据统计资源中心我的伙伴查询数据来源查询结果生成供应商根据货主生成根据供应商生成邀请伙伴我要邀请查询数据来源查询结果发起邀请邀请货主邀请供应商我的邀请查询数据来源查询结果接受成为货主成为供应商拒绝拒绝成为货主拒绝成为供应商订单中心物流订单管理我接收的物流单生效运输订单运输出库运输入库出库订单入库订单拒绝作为仓储商拒绝运输订单作为仓储商拒绝运输出库作为仓储商拒绝运输入库作为仓储商拒绝出库订单作为仓储商拒绝入库订单作为承运商拒绝运输订单作为承运商拒绝运输出库作为承运商拒绝运输入库作为承运商拒绝出库订单作为承运商拒绝入库订单6.6.2定义范围和深度1） 根据功能重要性，添加回归功能点订单中心物流订单管理我接收的物流单生效运输订单Y运输出库运输入库出库订单入库订单拒绝作为仓储商拒绝运输订单Y作为仓储商拒绝运输出库作为仓储商拒绝运输入库作为仓储商拒绝出库订单作为仓储商拒绝入库订单作为承运商拒绝运输订单Y作为承运商拒绝运输出库作为承运商拒绝运输入库作为承运商拒绝出库订单作为承运商拒绝入库订单2） 根据整理的系统流程，添加回归功能点在验证流程时，需要校验至少三个点：生成承运单、出库单、入库单，因此需要增加或者修改对应的功能点，如：订单中心物流订单管理我接收的物流单生效运输订单运输出库Y运输入库Y出库订单入库订单拒绝作为仓储商拒绝运输订单Y作为仓储商拒绝运输出库作为仓储商拒绝运输入库作为仓储商拒绝出库订单作为仓储商拒绝入库订单作为承运商拒绝运输订单Y作为承运商拒绝运输出库作为承运商拒绝运输入库作为承运商拒绝出库订单作为承运商拒绝入库订单到此为止，所获得的用例集可以作为基础用例集合，根据需要进行维护。如果没有较大的流程和逻辑变更，则下一个版本可以根据此用例集，进行后续的添加和删减。3） 根据实际业务的流程，增加回归功能点由于XX公司最经常使用的业务模块，对运输订单有特别的关注点，所以在制定回归测试的流程时，需要进行覆盖，于是：订单中心物流订单管理我接收的物流单生效运输订单Y运输出库Y运输入库Y出库订单入库订单拒绝作为仓储商拒绝运输订单Y作为仓储商拒绝运输出库作为仓储商拒绝运输入库作为仓储商拒绝出库订单作为仓储商拒绝入库订单作为承运商拒绝运输订单Y作为承运商拒绝运输出库作为承运商拒绝运输入库作为承运商拒绝出库订单作为承运商拒绝入库订单4） 根据版本的功能，增加回归功能点本次新版本中，作为仓储商，针对拒绝功能做了优化，例如，订单被拒绝时，需要发送邮件，且邮件是根据类型有不同的内容，那么：订单中心物流订单管理我接收的物流单生效运输订单Y运输出库Y运输入库Y出库订单入库订单拒绝作为仓储商拒绝运输订单Y作为仓储商拒绝运输出库作为仓储商拒绝运输入库作为仓储商拒绝出库订单作为仓储商拒绝入库订单作为承运商拒绝运输订单Y作为承运商拒绝运输出库Y作为承运商拒绝运输入库Y作为承运商拒绝出库订单Y作为承运商拒绝入库订单Y5） 确认回归范围根据所选择的功能点，确定回归测试的范围。如有需要，与开发进行确认，确保所选范围覆盖了她们所确定的代码影响范围。6.6.3执行过程及结果跟踪1） 执行侧重点执行回归测试时，应该把重点放在业务流程的流转，关注关键信息（即和逻辑有关的信息），而不关注非关键信息，提高测试执行的速度。如：新增订单时，关注订单的状态，承运商，仓储商，商品数量等，而订单的其余信息，如收发货人，创建时间等为次要信息。执行回归测试时，关注功能，对于兼容性，易用性等问题，不需要非常关注。2） 执行结果处理策略根据实际情况，对执行结果进行处理阻碍流程：当有阻碍流程时，立即提交给研发进行排查修改，并暂停该流程相关功能的测试，减少介入时间，待该阻碍流程验证通过后再继续执行该流程相关功能的测试。BUG：根据级别，决定修改标准。当bug级别为严重及以上时，须在回归测试结束前修改并验证通过，方可进行下一个流程；当bug级别为中等或微小，或者是建议时，应与测试负责人、研发经理、产品经理和实施进行讨论，在不影响流程的情况下，尽量控制修改范围，酌情考虑是否在本期修改。7. 线上问题处理与反馈7.1线上问题的定义线上故障是指提供给客户使用的IT服务全部或部分不可用，包括服务性能的降低，如：服务延迟导致用户体验变差。在创业前期，为了抢占市场先机，产品新功能的发布速度追求往往优先于其质量，埋下了很多技术债务，部分技术债务的爆发会引起线上故障，造成客户的体验下降或经济损失。7.2线上故障管理的目标“尽快恢复服务到正常运行，并且最小化对业务运营的不利影响，从而尽可能地保证服务质量和可用性的水平”。在故障发生后，故障紧急处理小组会定位、分析和恢复故障，并在故障恢复后对故障进行Review和总结，制定出可执行的Actions，以提高故障处理效率和避免类似故障再次发生。下面将为大家简单介绍有赞的故障管理实践。7.3故障处理流程介绍使用禅道作为跨部门协作工具，线上故障管理也借助于禅道。我们制定了下面的故障处理流程，故障禅道工单遵循该工作流，而故障Acti