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: |
版本发布文件评审 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
由测试工程师组织相关人员对本次发布版本的文件进行评审说明,如通过将正常发布,如未通过根据要求进行修改。 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|