项目管理之软件测试流程

1，目的

对软件产品进行全面测试，以确保产品满足软件产品需求和业务需求，并最终通过测试。

2.术语和定义

正式的迭代测试：制定测试方案，编写测试用例，至少2轮测试和1轮回归；

简化的迭代测试：可以不输出测试方案、测试用例，只编写测试要点，至少1轮测试1轮回归。

3.角色与职责

3.1

EPG小组

负责为项目提供测试活动的咨询和指导。

负责为项目制定各阶段的就绪准则和完成准则提供咨询和指导。

负责将公司的标准过程在全公司范围内推广，并组织和监督公司培训部门和项目组的新过程的培训工作。

3.2

项目负责人

负责组建队伍，培训人员，执行测试活动；

负责制定设计计划，并执行计划，保证项目在规定的时间，使用规定的资源，按计划完成；

监督并控制测试过程；

负责就项目的进展情况与客户沟通；

参与系统测试计划、报告、测试环境/工具评审；

项目经理确认和分配测试缺陷，监督解决；

负责项目人员、流程管理。

3.3 技术经理

负责总体设计的编制，包括软硬件开发技术选择，系统架构，关键技术攻关等；

负责组织并指导相关人员对软件、结构、接口、数据库进行设计说明书；

参与预研、设计及技术过程产物评审；

负责指导软件工程师按照《编程规范》《应用安全开发规范》或者具体编码工具的编码规范执行；

负责抽检程序员所提交的代码或者组织代码评审，确保代码的质量；

负责软件模块的编译、构建及联调，验证及审核程序单元测试及联调的结论；

负责建立编码基线。

3.4

软件工程师

在项目负责人/技术经理指导下完成软件概要设计说明书编制，包括结构、接口、数据库等；

负责按照《编程规范》《应用安全开发规范》编写和修改程序代码；

完成自测和单元测试和代码走查；

负责配合技术经理处理涉及软件需求的问题。

3.5 测试经理

参与《软件设计说明书》、《详细设计说明书》的评审；

根据项目需要制定测试计划、测试方案

带领团队完成公司产品的测试工作，执行测试计划，跟踪执行进度；

负责带领测试团队,设计、执行、优化过程，丰富测试手段，引入新的测试框架和测试策略；

维护测试流程，统计和分析测试结果，提高测试效率和质量；

组织测试技能、工具培训。

3.6

测试工程师

参与《软件设计说明书》、《详细设计说明书》、原型和UI设计的评审；

按照测试计划搭建测试环境，并保证测试环境的可靠性；

参与测试计划、测试策略/方案编写；

按照要求搭建相关测试环境并进行评审；

按照测试计划编写测试用例，保证测试用例合理有效；

按照测试用例执行测试，及时发现缺陷，并使用工具进行管理缺陷；

编写测试报告、安全测试报告(病毒扫描、漏洞扫描、端口扫描、web扫描)、性能测试报告保证测试进度按计划完成；

编写用户手册、服务版本发布详细清单、部署配置说明；

参与其他测试工程师的测试用例和报告评审；

对缺陷进行记录、跟踪和再验证；

参与客户支持文档编制及检查；

3.7

技术支持工程师

负责现场版本发布和更新；

协助搭建测试环境；

客户支持文档的编写；

对客户发布产品，组织客户试运行并进行使用相关培训；

对客户运行中发现的问题进行反馈跟踪。

3.8

配置管理员

负责设计文档、测试文档、源代码、基线的配置管理；

3.9

QA

负责指导和检查项目经理或项目度量人员对度量数据进行收集与分析数据；

参与评审并分析过程活动及其工作产品；

按照《裁剪指南及检查单》开展对测试过程的审计。

4.测试准入、暂停、结束准则

4.1 测试准入标准

1.提交测试之前故事的Jira状态需要修改成待测试；

2.有自测记录并按照自测记录规范模板V1.0完成（

①SQL文件命名及内容规范—可裁剪；

②新增修改接口需要附上swagger接口截图，对于必填项需要有备注—可裁剪；

③自测记录需要有文字加截图，证明完成了故事需求—必须；

④Sonar扫描没有新增漏洞和新增bug存在，每次提交故事需要附上扫描后的截图，新增代码单元测试覆盖率达50%—必须；

⑤影响点及测试建议说明—必须；）；

3.提供组件清单（版本号，名称，是否集群），可选项。

4.2 测试暂停/停止标准

1.测试环境无法达到标准或无法满足测试的一致性，安装无法正确完成；

2.软件产品关键业务功能、性能、可靠性发现致命缺陷导致后续测试活动无法继续开展或测试结果不可靠;

3.存在致命安全隐患问题;

4.修复致命缺陷重现和新发现的致命缺陷导致续功能无法连续实现或后续测试用例无法实施或测试结果不可靠；

5.需求有变更；

4.3 测试准出标准

1.jira中发布版本的故事状态为关闭状态；

2.DI值≤20，不能有Highest和High级别问题和安全红线A类问题，其他级别的问题需要给出解决计划；

公式：（Highest*10+ High*3+ Medium*1+ Low*0.1）；

3.版本发布的交付文档齐套（①用户手册；②测试报告及测试报告评审记录；③功能需求清单核对记录；④部署包和脚本（开源组件、地图数据、数据库脚本及初始化数据、ansible脚本）；⑤服务版本发布详细清单（包含软件版本发布说明、服务版本号清单））；

4.软件部署包和脚本，放入指定位置（第三方组件、地图数据、数据库脚本及初始化数据、ansible脚本）。

 5.输入和输出

输入：

• 裁剪指南及检查表            
• 用户需求说明书            
• 需求规格说明书            
• 设计方案            
• 主体计划            
• JIRA-用户故事            
• JIRA-需求池            
• 原型图            
• UI设计图            
• 业务流程图            

输出：

1. 测试计划                                                                                
2. 测试策略/方案                                                                                
3. 测试工具/环境评审报告                                                                                
4. 测试用例/要点                                                                                
5. 软件测试报告、安全测试报告(病毒扫描、漏洞扫描、端口扫描、web扫描)、性能测试报告    
6. 服务版本发布详细清单                                                                                
7. 用户手册                                                                                
8. 版本发布文件评审报告 

 缺陷提交流程：

 

 7.活动规程描述

AC01:

总体设计评审

参与总体设计说明书评审，是否考虑安全基线，是否包括安全需求分析、安全架构设计以及DFX设计等。

评审参与人除了项目负责人本人，还包括技术经理、软件工程师、测试经理和测试工程师。

AC02:

制定测试计划

测试工程师依据产品需求及总体设计方案编写项目的测试计划。根据需求估算测试所需资源（人力、设备等）、所需时间、功能点划分、如何合理分配安排资源等；

测试计划中将会包含整个测试的过程需要的人员、时间安排（目前我们采用的敏捷开发，2周一迭代）、各个阶段需要的交付件及测试要点，软件硬件资源，测试点，集成顺序，进度安排和风险识别等；

AC03:

测试计划审核

测试团队和项目团队对提交的测试计划进行审核，项目负责人需要判断测试计划是否与项目相符，并提出建议。

评审参与人员有项目经理，技术经理，测试经理，产品经理，测试人员，

测试经理需要根据评审意见修改《测试计划》，并上传SVN，有配置管理员管理。

AC04:

制定测试方案/策略

测试组长组织测试成员编写《测试方案/策略》，要求根据每个需求点设计出包括需求点简介，测试思路和详细测试方法三部分的方案。

测试方案中包括安全测试方案；

AC05:

测试策略/方案审核

测试团队和项目团队对测试方案进行审核，提出改进建议进行修改。

测组长需要组织测试成员根据评审意见修改《测试方案/策略》，并上传SVN，由配置管理员管理。

AC06:

测试环境/工具审核

测试团队和项目团队对测试方案进行审核，保证能100%匹配需求场景。

测组长需要组织测试成员根据评审意见修改《测试环境/工具评审报告》，并上传SVN，由配置管理员管理。

AC07:

迭代计划

测试人员的根据项目需要进行有关测试方法、测试工具（包括安全测试工具）、问题汇报方法等方面的培训，以及有关被测产品的功能培训；

项目开发采用迭代开发模式（迭代周期为2周），项目负责人和技术经理沟通用户故事的优先级以及故事之间的关联性，安排新的迭代计划，并在迭代启动会中完成迭代任务的宣讲，

由软件工程师自行认领任务，或由技术经理分配任务。同时测试组长对测试人员分配测试任务；

AC09:

迭代功能设计

每个迭代任务以及功能的复杂度都不一样 ，由产品经理去讲解原型和需求，开发人员、测试人员、设计人员考虑是否合理，对于不合理的提出让产品经理修改；

将功能需求录入jira中；

参与迭代功能设计的人员包括项目负责人，技术经理，开发人员，设计人员，测试人员，产品经理。

AC10:

编写软件测试用例

根据详细的需求文档和评审后的原型进行编写测试用例，测试用例需要包含功能测试（正常场景、异常场景），安全测试、性能测试、可靠性测试。

AC13:

编码开发完成

开发把所有需求都开发完成，并进行自测，自测通过后提交测试；

AC12:

软件测试用例/要点评审

用例/要点评审前会事先说明对那些需求进行编写测试用例/要点；

测试用例评审需要考虑DFX是否都有考虑；

在用例评审中，参与人员需要对用例中与实际功能不符合的用例或者格式不规范用例提出修改建议，测试人员进行修改；

参与测试用例的评审人员包括项目责任人，技术经理，产品经理。

AC14:

静态代码扫描；自测报告；单元测试记录上传附件

开发人员在开发完需求，在jira中将故事提交测试时，需要附上静态代码扫描的结果（sonar扫描不允许产生漏洞安全性bug，新增代码单元测试覆盖率需达50%）否则重新打开故事；

AC15:

测试执行

开发转版本给测试前需要自己进行系统测试,目的是来评判这个版本功能是否可测试。如果测试不通过，打回，开发组返工，如果通过，测试人员开始第一轮系统测试。

每迭代完成后会对本迭代测试的版本进行总结，具体的测试内容如下：

（1）第一轮系统转测试，测试会执行所有测试用例，发现缺陷提交问题单。第一轮测试结束后，测试组将所有的问题单跟踪提交给开发人员，由他们进行修改。然后进行第二轮测试，第二轮会对第一轮中发现的问题进行重点回归。依次进行多轮测试。

（2）在他们修复bug期间，测试会对所有测试用例，测试每个迭代会出一个迭代报告。根据实际情况，对测试编写的测试用例进行修改和增加。

（3）回归测试，会在测试用例中挑选一些优先级别比较高的测试用例来进行测试，发现问题继续提交缺陷的问题单，直到缺陷率低于用户要求，测试组将进行最后一轮的大版本测试，结束系统测试。具体测试轮次根据版本质量和项目复杂度而决定。

（4）根据每个产品及项目的要求进行部分自动化测试，包括接口自动测试和性能测试；

（5）在版本发布前需要进行安全测试(病毒扫描、漏洞扫描、端口扫描、web扫描)

AC16:

迭代测试报告编写

每迭代测试结束时，测试需要编写迭代总结中的测试部分；

AC17:

迭代总结

每轮测试结束时，测试会提交一份迭代测试总结，该报告会在迭代总结会议上显示。同时将测试情况反馈及遗留问题分析，也会对上一迭代遗留的问题进行跟踪。

参与迭代总结的人员包括：项目负责人、产品经理、技术经理、开发人员、设计人员、测试人员、QA；

AC18:

测试报告

项目结束或者版本发布会编写测试报告，测试报告包含整体测试报告，安全测试报告(病毒扫描、漏洞扫描、端口扫描、web扫描)，性能测试报告；

测试报告包括对软件功能的结论，说明为满足此项足此项功能而设计的软件能力以及经过一项或多项测试已证实的能力。

验证项目软件的开发是否达到预定目标，是否可以交付使用的重要依据。

AC19:

测试报告评审

项目团队评审测试报告的有效性和准确性。需要根据评审结果对测试报告进行修正。

测试报告评审人员包括：技术经理、软件工程师、测试经理、测试工程师、QA负责人；

根据每个产品的版本计划进行版本发布；

需求checklist核对质量标准覆盖，确保100%全规格覆盖。

DI值≤准出标准值（此值会根据实际情况做调整，以《软件产品测试_准入准出标准》文档中的值为标准），不能有Highest和High级别问题和安全红线A类问题，其他级别的问题需要给出解决计划；

版本发布的交付文档齐套（用户手册、测试报告、需求功能清单、服务版本发布详细清单、部署配置说明）且通过评审；

报告中体现，针对前期版本历史问题、网上问题等落入修改的问题清单的测试结果；

测试报告包含遗留缺陷清单，需包含遗留问题影响、规避措施和解决计划，经过评审，并给出评审结论。

软件部署包和脚本，放入指定位置（第三方组件、地图数据、数据库脚本及初始化数据、ansible脚本）。

AC21:

现场反馈问题验证

由测试工程师对反馈回来的问题进行验证，确认是问题后走缺陷提交子流程。如不是问题同反馈人进行说明情况。

AC22:

版本缺陷确认

根据现场反馈问题的的版本号在测试环境进行复现并确认问题是否存在；

AC23:

非缺陷说明

对于非缺陷问题需要同反馈问题的人描述清楚并说明。

AC24:

依据问题进行测试

根据现场反馈的问题如果是缺陷就会走缺陷子流程；

AC25:

项目资料移交

项目结束时需要提交用户手册、测试报告、需求功能清单、服务版本发布详细清单、部署配置说明等相关资料到svn。

AC26:

版本发布子流程

版本发布需要严格遵守版本发布子流程；

AC27:

缺陷提交子流程

如果执行测试用例发现缺陷，则按照缺陷提交子流程提交、追踪缺陷。

AC28:

QA过程监控

QA负责人在软件测试流程中，全程定周期检查产出，对度量数据进行收集与分析，每个迭代记录一份QA报告，并提出持续改进建议。

AC29:

版本发布文件评审

由测试工程师组织相关人员对本次发布版本的文件进行评审说明，如通过将正常发布，如未通过根据要求进行修改。

8.评审点

评审点

评审对象

组织者

评审人员

决策者

AC02

测试计划

测试经理

项目负责人、产品经理、技术经理、软件工程师、测试经理、测试工程师、QA

项目负责人、技术经理、产品经理、测试经理

AC04

测试方案/策略

测试工程师

项目负责人、产品经理、技术经理、软件工程师、测试经理、测试工程师、QA

项目负责人、技术经理、产品经理、测试经理

AC06

软件测试环境/工具

测试工程师

项目负责人、产品经理、技术经理、软件工程师、测试经理、测试工程师、技术支持工程师、QA

项目负责人、技术经理、产品经理、测试经理

AC10

测试用例

测试工程师

项目负责人、技术经理、软件工程师、测试经理、测试工程师、QA

项目负责人、产品经理、技术经理、测试经理

AC18

测试报告(功能测试报告、安全测试报告 、性能测试报告)

测试工程师

项目负责人、产品经理、技术经理、软件工程师、测试经理、测试工程师、技术支持工程师、QA

项目负责人、技术经理、产品经理、测试经理

AC29

版本发布文件评审

测试工程师

项目负责人、产品经理、技术经理、软件工程师、测试经理、测试工程师、技术支持工程师、QA

项目负责人、技术经理、产品经理、测试经理

 9.过程模板

• 编号        活动                    模板名称/输出                                                
• AC02:    制定软件测试计划            软件测试计划                                                
• AC03:    测试计划审核                软件测试计划评审报告                                                
• AC04:    制定测试方案                软件测试方案                                                
• AC05:    测试方案审核                软件测试方案评审报告                                                
• AC06:    软件测试环境/工具            软件测试环境/工具评审报告                                                
• AC10:    测试用例编写                测试用例或测试要点                                                
• AC12:    测试用例审核                测试用例或测试要点评审报告                                                
• AC15:    执行测试                                                                    
• AC17:    迭代测试总结                迭代总结                                                
• AC27:    缺陷提交子流程                缺陷                                                
• AC18:    测试报告                    测试报告(系统测试报告、安全测试报告、性能测试报告)                            
• AC20:    测试报告评审                测试评审报告                                                
• AC26:    版本发布                    版本发布打tag                                                
• AC21:    现场反馈问题验证                                                                    
• AC22:    版本缺陷记录                版本缺陷记录                                                
• AC29:    版本发布文件评审            版本发布文件评审报告