系统测试流程

1、系统测试控制程序1 目的本程序描述了产品的系统测试流程。2 适用范围本程序适用于公司立项产品的系统测试过程的控制。3 职责产品市场部：下达任务项目书。产品研发部：完成项目的研发和集成，修改软件问题。系统测试部：系统测试包括设计的验证测试和模拟客户环境进行的产品确认测试。了 解产品需求，制定测试计划，编写测试用例，完成测试，记录测试结果，提交测试报告； 提交产品问题，跟踪问题直至问题关闭；为发布后的产品提供后续测试服务。技术支持部：在产品的维护阶段，反馈客户对产品的测试新需求。Bugzilla 维护人员：负责管理公司的 bugzilla 服务器。4 工作程序对于由系统测试部执行验收测试的项目，执

2、行后面的工作程序。4.1 收到项目任务书4.1.1 指派项目测试组成员系统测试部经理收到产品市场部发出的项目任务书后，指派项目测试组成员。项目测试组由leader和成员组成。系统测试部经理将项目系统测试leader及其职责/权限用电子邮件的形式通知，被通知人包括：项目的产品经理、项目的研发组leader、项目研发组成员、项目组测试成员、项目组其他成员、技术支持部经理，并抄送给开发部经理，产品市 场部经理。项目系统测试leader的职责如下：a. 根据本测试流程的描述，组织项目测试组成员完成测试；b. 制定测试计划，组织编写测试用例，执行项目测试；c. 负责维护项目系统测试任务计划；d. 监督和

3、控制项目的测试质量；组织成员完成维护阶段的产品测试任务4.1.2 建立项目测试目录项目测试组 leader 收到项目测试职责的指派后，马上为该项目建立测试目录，并参考 项 目 测试 目录 结构 和文 件命 名规 范 创建目录结构，并搜集相关文件。所有与该 项目测试相关的文档要求保存到该目录下。4.1.3 Bug 跟踪计划项目测试组 leader 收到项目测试职责的指派后，开始编写 Bug 跟踪计划。 Bug 跟踪计 划的编写和批准应该在项目测试计划完成前完成。项目产品经理把参与本项目的相关人员及其邮件帐号提供给项目测试组leader。项目研发组leader把本项目研发组成员及其邮件帐号提供给项

4、目测试组leader，包括项目子模块名和研发人员的对应关系。技术支持部经理把参与本项目的技术支持成员及其邮件帐号提供给项目测试组leader。项目测试组 leader 根据模板 Bug 跟踪计划模板编写 bug 跟踪计划。如果需要，可 以重新定义模板中 bug 严重等级和优先级的定义。项目测试组 leader 将编写完的 Bug 跟踪计划发给本项目的产品、研发、测试、技术支 持成员确认，并将确认后的最终版本抄送各自部门经理和 bugzilla 管理人员。Bugzilla 管理人员根据“ Bug 跟踪计划”在 bugzilla 服务器上建立本项目，并将 Bug 跟踪计划中描述的角色和人员加入该项

5、目。4.2 制定测试计划4.2.1 编写测试计划项目测试组leader参考系统测试计划模板编写测试计划。测试计划用于描述测试 目的、质量目标即测试通过的准则、人员构成、测试资源、测试范围、测试活动及其进 度。项目测试组leader应该在项目策划阶段完成测试计划的编写。项目系统测试组根据项目任务书中的原始需求、产品的主要应用目的和SRS,确定本项目系统测试的范围，并识别项目的测试重点；项目中将进行功能重建/加强/改善的地方要作为测试重点。有关功能重建等信息可以从项目整体概要设计书或者SDP 对重点开发任务的计划中获得。项目系统测试组 leader 根据测试范围，估计需要的测试资源、测试工作量。根

6、据估计 的工作量、项目任务书中的时间计划、以及研发的 SDP 草案制定系统测试活动的时间计 划。产品的硬件兼容测试应计划在最初两个 Beta版完成。4.2.2 评审测试计划在原始需求、SRS、项目研发计划均评审完后，项目测试组leader组织下列人员参与测试计划的评审：项目的产品经理、项目研发组leader、项目测试组成员、以及产品市场部经理、系统测试部经理、研发经理。测试计划中的测试质量目标不得低于公司定义的测试质量目标，产品质量目标不得低 于公司定义的产品质量目标。测试计划通过评审的标准：A. 规定参与的所有人员均参与了评审；B. 测试质量目标和产品质量目标不低于公司目标，如果低于，需要由

7、公司的管理者 代表批准；C. 识别的测试范围、测试重点能够达到制定的质量目标，估计的测试资源合理、时 间进度符合项目总体进度要求；D. 识别了可能发生的风险，以及应对措施； 评审结果记录在评审报告中。通过评审后，测试计划由系统测试部经理批准。4.3 实施测试计划4.3.1 测试计划的跟踪维护项目系统测试Leader跟踪测试计划的实施情况，识别与计划的不符合程度、并估计不 符合对项目产品质量、测试质量、发布时间计划产生的影响。当估计会产生严重影响时， 发起会议讨论应对措施。会议参与人包括：项目的产品经理、项目研发组leader、以及产品市场部经理、系统测试部经理、研发经理。当需要变更STP时，项

8、目系统测试Leader执行变更，并组织人员评审变更后的测试计 划，评审标准见本文档中“制定测试计划”段的描述，并由系统测试部经理批准。项目系 统测试Leader将变更后的测试计划发给应该参与评审的所有成员。4.3.2 编写 TestCase和 CheckList“TestCasW和“ CheckList 是指导项目系统测试如何进行的工具，它描述了被测试 的内容、 测试的方法、 应用的测试工具名称和版本、 允收的标准。 项目系统测试组 leader 按 照测试计划组织项目测试成员参考CheckList模板和TestCase模板编写项目的CheckList 和 TestCase。编写完成后，项目系

9、统测试组leader组织项目测试组成员交叉评审后，组织项目的产品经理、项目研发组leader、项目研发组成员、项目测试组成员初步评审。在产品研发的a阶段，研发提交a版本给系统测试组，系统测试组根据该版本完善TestCase和CheckList。如果发现文档和 a版本有差异时，应先向测试组leader说明差异情况，在测试组leader认可后可更新 TestCase和CheckList。项目测试组leader在产品第一个 卩版送测前组织TestCase和CheckListt的正式评审。 评审参与人包括：项目的产品经理、项目研发组leader、项目研发组成员、项目系统测试组成员。通过评审的标准： C

10、hecklist 要覆盖所有测试范围即所有需求，对于测试重点，TestCase和CheckList要覆盖基本功能，扩展功能；对于非测试重点TestCase和CheckList要覆盖重要功能和路径； TestCase 和 CheckList 覆盖率能达到部门要求。评审结果填写在 评审报告中。评审后的TestCase和CheckList是项目测试方法和允收标准的基线，进入配置库，并 按配置管理程序实施变更的控制。4.3.3 测试版本的测试项目研发组leader提交测试版本的产品发布报告。项目测试 leader将产品发布 报告保留到项目测试目录下。项目测试组leader根据版本产品发布报告中的Cha

11、ngelog，核查原有的测试用例,根据需要更新测试用例，并按配置管理程序实施变更的控制。项目测试组leader组织测试成员根据 TestCase和CheckList执行测试，并在测试过程 中记录测试结果。发现问题后，根据 Bug 跟踪计划和 Bug 跟踪规程，使用专用的 bug 报告系统向项目研发组报告问题，报告内容包括：问题的严重程度、发生的位置、重 现的方法等。研发组对 bug 的修改记录、以及修改后测试人员验证的结果，均记录在 bug 报告系统中。版本测试完成后，a) 项目测试组成员提交自己执行测试部分的：完成情况报告、测试结果详细记 录。b) 项目测试组 leader 搜集下列数据：产

12、品目前的质量：各个严重等级 Bug 的数量，与目标的差距；测试质量：i. 测试 Checklist 对需求的覆盖率；ii. 测试 Checklist 被执行的比例；iii. 测试进展和计划进度的差距；研发、测试质量iv. 新 Bug 占当前所有 bug 的比例；v. Bug 未跟踪比率 = 未跟踪的 bug 占当前所有 bug 的百分比；(未跟踪的 bug 指的是在以前版本被置为 NEW 、 REOPENED 、 NEEDINFO 、 WANTHOLD、WANTNOTBUG 的bug，其状态在本版本测试结束时仍未 得到更新) 。研发质量：vi. 已关闭 bug 占当前所有 bug 的比例；vi

13、i.当前 REOPENED bug 占当前所有 bug 的比例；c) 项目测试组 leader 用 E-mail 形式向相关人员报告测试情况，报告内容包括： 报告人名字、 报告时间、 版本测试完成情况、 测试结果记录、 bug 统计结果、 产品质量与目标的差距，同时说明被测版本的质量是否合格、 是否可以放行， 并提请研发确定 Review bug 的时间。d) 对于质量合格的版本，项目的配置管理人员将对配置库中该版本做合格品标识。项目研发组Leader组织研发成员了解bug,根据Bug跟踪规程修改bug状态，确定 review bug 时间。项目研发组Leader根据Bug跟踪规程组织 bug

14、 review meeting。项目测试组leader将所有与该版本相关的测试文档保留到测试目录下。4.3.4 项目测试版本的管理系统测试部只对项目的产品经理提供本项目产品的版本,包括测试版本和最终版,不 对公司其他部门提供,也不对任何个人提供。4.3.5 测试结束项目测试结束后，项目系统测试 Leader组织测试人员完成项目测试总结文档。包括：产品功能测试报告、软件兼容报告、硬件兼容报告、性能测试报告、稳定性测试报告、测 试活动总结、产品实施手册。测试活动总结报告总结下列内容：项目系统测试覆盖的内容是否达到计划的预期,覆盖比率是否达到质量目标？成功/失败的原因；Bug 跟踪比率是否达到目标？

15、未达到原因是什么？测试完成时间、投入人力是否符合计划,不符合情况的描述,原因；测试活动的管理存在的问题,以及经验。产品实施手册不同于用户手册,其从具体内容和证据角度描述下列内容： 产品的物理构成,功能构成,相对以前版本的改进,与以前版本的不同； 产品各部分质量的描述,强点,弱点； 与竞争产品的不同：功能特性不同,竞争产品的强点,弱点； 产品的兼容列表地址,推荐的搭配方案； 对软/硬件产品的安装、配置、使用方法,存在的问题,需要注意的点,性能调优方法；产品所有已知问题的解决办法4.4 项目中止在产品的最终版本发布前，如果项目被中止，则中止本项目的系统测试。对于中止的项目，系统测试人员完成项目测试活动总结报告，在报告中明确说明项目 中途终止。被中止的产品应提交给项目的产品经理封存。4.5 产品最终版的发行项目的产品经理根据客户实际使用环境下测试/确认的结果或模拟客户实际