软件测试质量体系管控

软件测试质量体系管控

迭代发布控制

1.	确认上线时间
开发转测试时间需要在需求文档评审完成后，与测试共同确认转测试时间以及正式上线时间。
2.	迭代周期一次
所有版本在转测试开始之后，根据迭代周期，确认转测试版本时间，不允许额外的bug修改造成的临时发布和打包
3.	超纲发布特批
如果遇到阻塞性问题确实需要重新发布和打包，需要上报研发技术负责人，说明原因之后，经过批准再发版。
4.	固定发版
从每个迭代版本开始，固定时间发布新版本，开发邮件确认已经装备好当天测试的版本以及确认合入修改的bug。

bug修改控制

1.	依据修改状态回归
测试以bug状态改为Resolved为开始回归的前提，未改状态的bug，测试不进行回归。
2.	Bug提前处理
所有bug在发布前都需要解决完成，剩余充足时间给测试进行QA环境bug回归和QA环境回测，以及发布测试报告。
3.	Bug打回升级
开发第一次修改bug未回归测试通过，在打回的同时，可以对bug进行升级处理，升级为严重等级，提高大家对修改bug的重视程度。(根据各公司实际状态跟开发沟通确认方案)
4.	带bug可发布
在预发布环境当天发现的问题或者发布当天发现的问题，可以经过与研发总结确认，讨论是否需要修改发布时间，建议非严重问题不再发布新版本和修改发布时间。

需求合入的控制

转测试后不合入新的需求
1.	在版本转测试之后，不再接受新需求的合入。
2.	如果有特殊情况，需要技术负责人协调。
    同时测试接受在可推迟发布时间的前提下，合入新需求。

产品可提bug
如果在测试过程中发现，产品未考虑清楚的情况或产品设计阶段未充分沟通运营，导致场景遗漏，可以给产品经理提交bug、建议，走bug处理流程。

测试评审

测试方案设计

1.	前期方案设计
在完成需求评审之后，测试进行相关的测试方案设计，利用边界值，等价类加上正交分析等方法，输出完整的测试覆盖内容，用来指导后面的测试设计，同时剔除一些无效的场景和数据覆盖。
2.	完善用例设计
根据测试方案，进行测试用例的设计，用例设计需要步骤清晰，预期结果明确，描述清楚预置条件。
3.	执行测试评审
测试评审要每次进行，确认用例测试的理解与产品和开发同步，同时场景覆盖要和开发确认已经覆盖完全。
4.	知识点梳理
针对当前业务场景，梳理出一套完整的业务内容，汇总出知识点，让团队成员对照，认清自己对当前业务的了解和覆盖度有多少。同时补齐测试经验总结文档，让团队所有人都可以快速熟悉业务，避免重复踩坑。

严格评审制度

1.	开发评审，参与者：开发、测试、产品经理
	SRS 需求规格说明书评审、HLD 概要设计说明书 评审、LLD 详细设计说明说评审、bug修改方案评审
	【完成后】，所有文档归档保存
	单元测试 参照 详细设计说明说（LLD）
	集成测试 参照 概要设计说明书（HLD）
	系统测试 参照 需求规格说明说（SRS）

2.	决策类评审，参与者：资深开发、资深测试、产品经理、测试经理、开发经理
	每个版本迭代需求排期评审、
	版本迭代bug修改时间评审、
	上线前，决策评审当前需要修改的bug和可以不修改的、
	重大线上问题解决方案评审
3.	测试评审，参与者：开发、测试、产品经理
	测试需求分析方案评审、
	测试方案评审、
	测试用例评审、
	bug测试用例评审
	【完成后】，所有文档归档保存

Code-Review

开发需要组织code-review
何时组织：在代码check-in之前
	参与者：
		开发经理， 相关开发，测试
	怎么做？
		开发讲解自己的开发思路
		浏览代码结构和调用关系
		确认代码规范性
		确认代码引用无问题
		确认经常踩的坑可以避免
	
严谨代码对比
	参与者：开发
			适合版本：在研发的版本
			采用方式：自动化工具
			对比目的：查看本次提交内容是或否覆盖版本规划的全部需求和修改项目
			对比时间：转测之后，开始测试之前
	
	参与者:测试
		适合版本：上线版本
		采用方式：自动化工具
		对比目的：查看本体修改是否有其他未涉及的无关代码和异常代码提交
		对比时间：转测之后，开始测试之前

团队效率提升

重视新员工培养
	1.导师责任制：指定技术专家或者业务专家做导师
	2.培养计划：导师负责指定3个月的学习计划，包括业务学习，技术培训，工作具体内容和交付件
	3.团队培养：团队内部个专家每周定期做内部业务和技术培训
	4. 月度答辩：邀请开发和测试相关人员，对员工掌握知识和技能做检视，给员工正确的学习建议和高效的学习方法。
	5. 转正考核：邀请各开发和测试领导，专家，对新员工，利用转正考核的机会，给与后面业务交付和技术提升的指引，帮助他们走正确的路，协助他站在巨人的肩膀上。

团队持续改进

测试过程回顾总结：
	测试工具偶完成后，全体参与项目的测试人员一起来进行整个项目的review，找出产品，开发和测试需要改进的项目，其中产品和开发反馈给他们，测试改进项目，可以找出来top2来改进。

项目典型bug分析

测试过程中每个人都可能发现一些独特的bug，这类bug有独特的价值，可以每个项目都找出一些典型bug来分享，提升全员的质量意识，做到测试经验的团队分享。
做好质量数据度量：
质量数据代表整个业务开发测试过程的质量情况，可通过质量度量来推进开发改进交付质量。质量分，建议可以使用开发bug数除以开发时间来计算单独开发的交付质量。
质量数据度量需要经过与技术负责人沟通，同各端开发leader达成一致数据模型，每个公司情况不一样，做好内部沟通。
尽量做到接近客户：
测试思维就是客户化思维，如果不知道客户需要什么样的产品，那么就不是有价值的交付。建议通过收集客户反馈，或者调研客户需求，参与有价值客户沟通等方式，做到直接面对客户的需求

全员参与知识建设
知识管理，沉淀，积累。

方式：
1.开发一个平台，论坛+社区等，提高用户活跃度
2.平时的经验分享和知识积累，放到社区
3.历史经验文档和总结积累
4. 用例评审，产品评审，会议回顾，开发review等保存到社区
5. 技术性文档的保存

好处：
	新员工培训效率提升
	部门经验持续沉淀
	技术专家培养更容易
	形成人人爱分享，大家爱总结的氛围
	员工业务知识提示，跨屏台和领域的问题较少明显

线上问题责任制

明确责任和相应机制：
1.	测试责任人和开发责任人都是相关问题领域或者模块最熟悉的人。
2.	要树立认识线上问题责任制的规定，要大家第一间响应
3.	先解决问题，在讨论其他业务交付计划和排期。

线上问题必回溯

线上问题回溯关键要点：
发起人：版本\产品经理
参与人：版本经理、开发经理、测试经理、开发专家SE、测试专家TSE、开发负责人、测试负责人
回溯过程：
1.	从问题发现、定位、测试、解决、上线的过程整体路演，确认问题第一时间被定位和解决，找到其中是否有改进和提升的地方。
2.	回溯开发过程线上问题遗漏的点，提出开发改进项，要求可落地的内容
3.	回溯测试过程线上问题漏测的点，提出测试改进项，要求可落地的内容
4.	如果感觉无改进或者改进项目无法落地，则回溯结果为无改进。

回溯报告归档：
回溯报告统一归档，3个月为一个周期，学习之前的经验和总结教训。