测试过程把控

测试过程遇到：
1、如何定义合理测试目标？
2、测试风险管理及监控？
3、测试质量度量？
4、如何在工作中落地？
5、上线后用户提出一些严重的缺陷怎么办？
6、如何控制风险？
7、团队协作困难？需求粗糙？提测延期？时间紧？需求变更？

一、如何定义合理测试目标
1、影响因素有人员、任务、质量目标、项目进度、资源、部门协作、部门内外风险
2、以终为始，不同阶段，目标侧重点不同
a)研发阶段：奖励机制+测试分析是核心
b)测试准备阶段：测试优先级+开发质量是难点
c)测试执行：稳定修复是重点
d)验收环节：风险应对+协同高效是考验
e)上线/出厂：快速响应+审核考核是关键
3、内心有一个最低的测试标准，不能突破60分
4、当前项目应定义的测试标准
a)产品成熟度
i.高、中、低
ii.影响因素：
1.需求业务成熟度–以前是否有相关的成熟经验–高
2.产品需求文档的完备性–中
3.产品经理的成熟度
4.产品需求研发时间是否充分
5.客户或用户的成熟度
iii.对测试标准的影响
1.产品成熟度低
a)测试优先级非常非常重要
i.哪些功能是必须要进行充分测试的
ii.哪些功能复杂的高，一定要先测试的
iii.哪些功能是新增的，一定要充分讨论，理解需求
b)是否可以协调支持的资源
i.产品经理调整？
ii.成熟经理带着新来的
iii.客户/用户风险
1.变更流程培训
2.培训业务
3.类似产品
c)是否可以借鉴历史的资料
i.需求、设计、测试用例、bug库
ii.降低工作量+测试是指导
b)开发成熟度
i.项目经理成熟度，项目管理能力+质量情况，开发进度、开发质量、bug回归质量、测试配合度
ii.开发团队人员稳定性，新来的开发、bug比较多的开发
iii.开发团队人员技术能力，复杂度、bug率、修复bug能力
iv.项目经理交流，测试标准项目经理先交流；优先级：新增功能（原因、是否合理），是否换人：测试先测试，bug多且严重，配合一个成熟开发（静态代码走读、bug修复）
c)项目研发周期
i.合理、紧、非常紧
ii.非常紧的情况下应对策略
1.区分测试优先级
a)提升冒烟测试，可提前把冒烟测试用例提交给开发自测，正常输入+正常操作，一个功能不超过3个
b)测试来复测
c)客户/产品交流，项目太紧，正常操作正常用；前期就要和客户/产品沟通
2.测试质量不要定义得太高，优先级高，测试标准高，优先级低，测试标准低
3.测试时间，争取时间和资源
a)稳定模块先测试
b)不要打包成整体再测试
c)开发要提升待测试的标准
d)提前和产品/客户交流
e)其他可借用得测试执行资源
d)测试团队成熟度
i.测试工程师分析和设计的能力，有效发现bug – 早期、中期、晚期
ii.测试人员充分度
iii.测试工作时间充分度
iv.测试人员稳定性
v.测试人员沟通能力 – 与开发沟通bug的效率
e)管理层的重视支持程度
i.管理层需要支持什么
ii.协调哪些资源
iii.协调哪些会议
iv.权责要去申请哪些
v.人员招聘培训
5、测试标准分级定义
a)最低标准、正常标准、较高标准（团队成熟度高、项目成熟度高）
b)最低标准，成熟度不高
i.测试范围，不能有遗漏：子系统、平台、业务、模块、功能、子功能
ii.先调研，再确定测试优先级，高优先级的不超过10%
iii.根据不同的优先级定义不同的测试标准，优先级高的，测试标准高，最低的测试标准，用户可接受（用户角色、必须使用的功能、必须操作的流程、不能有bug的–最最低，正常可用）
iv.测试类型有
1.功能（必须），非功能：易用性、可移植性、可靠性、可维护性、性能、安全
2.测试广度：独立功能/接口（必须），业务测试流程（正常流程、异常流程）
3.外部支持，提升异常业务扩展能力（用户调用）：用户角色，每个角色的工作内容、工作流程，每个角色如何使用系统产品完成相关工作，处理过程，角色交互有哪些，工作流程异常有哪些，文档-角色-工作-流程-软件操作步骤
4.测试粒度：代码级、模块级、接口级、数据库级、功能级、系统级
5.测试手段：静态测试（评审、代码走读）、动态测试（手工、自动化）
二、测试风险管理及监控
a)影响产品质量的因素：需求问题、设计问题、代码问题、测试问题、版本管理问题、变更问题、资源不足问题
b)什么决定产品质量？团队高度合作，测试能力+研发能力+协作
三、测试质量度量
a)提测延误率（计划工作日总和+延误工作日总和/计划工作日总和），评估测试进度的风险（以往项目评估数据：同一个团队、类似项目、平均值），调用延期风险高低
i.提前介入稳定功能的测试
ii.项目经理按测试优先级进行开发的版本提交
iii.高优先级是否可以单独提测
iv.保证充分的重要的测试用例集合–优先级
v.提前申请后续测试执行资源
vi.保证提测质量
b)冒烟测试用例通过率，已执行通过的冒烟测试用例数/全部冒烟测试用例数
i.价值：提测标准–分项目，根据项目成熟度进行定义，成熟度越高的项目，资源越充分的项目，冒烟测试的标准越高，冒烟用例的决定标准
1.最低：正常数据+正常处理，独立功能
2.中：加入边界值数据，基本业务流
3.高：加入异常数据，加入异常流程，开发提前预知的
4.测试来进行设计，建议开发来执行，测试再复测
5.分模块来决定，优先级高，标准高，优先级低，标准低
ii.注意点：不要一刀切，也不要忙了不做，标准事先达成共识，测试用例集的选取需要开发认可
iii.什么算合格，根据项目情况，测试经理先提出比例，80%以上（同样80%，但是质量完全不同，测试用例集粗细粒度不一样）
c)需求覆盖率，测试用例中测试到的需求总数/全部需求总数
d)测试用例通过率，测试用例通过数/测试用例总数
e)测试用例命中率，测试用例发现的缺陷总数/缺陷总数，评估测试工程师的用例设计能力
f)缺陷有效率，有效缺陷总数/缺陷总数
g)测试依据稳定性，需求变更引起的需求新增、修改、删除的用例总数/测试用例总数，评估测试返工率的高低，容易变更的模块尽量进行低耦合的设计
h)二次故障率，缺陷二次重开数量/缺陷总数，如何确保bug二次修复都关闭–bug为什么多次关闭不了的原因，设计的耦合度，设计要去进行修改，今后设计要如何改进
i)缺陷生命周期，缺陷生存总时长/缺陷总数
j)缺陷修复率，已修复/缺陷总数
k)缺陷收敛率，缺陷遗留数量/时间周期
l)缺陷严重级别分布
m)缺陷类型分布
n)缺陷模块分布
四、如何在工作中落地
a)散点的思想、方法如何落实？质量目标、任务管理、风险控制、团队协作、质量指标、技术提升
b)转变为文档
i.定义测试目标
ii.确定测试负责人
iii.工作计划（测试优先级、进度、质量指标）
iv.风险分析（风险识别+备选方案）
v.协作前期沟通（提测标准+回归策略+测试改进）
vi.测试前期准备（测试分析+用例设计+环境准备）
vii.测试执行（冒烟+正式+回归）
viii.验收及上线（快速响应+遗留+改进）
五、出现线上问题怎么办（我已经尽力了）
a)问题描述：上线后用户提出一些严重缺陷（老板觉得测试需要改进、但测试又觉得自己尽力了）
b)问题定位：版本迭代发布速度快，测试周期短、测试人力严重不足、开发质量差及修复bug不稳定
c)解决方案：增加人力？
i.能看到的一般都不是根本原因，不愿意接纳必须接纳的，不愿意放弃该放弃的
ii.找到平衡点，放弃不合理的目标，就能看到正确的目标
iii.定义合理的质量目标，质量目标分级定义：1级、2级、3级，质量目标分类定义：1验收标准、2回归测试标准、3测试标准、4提测标准
iv.快速响应，尽快定位问题，快速修复；测试需要提供问题复测说明；追溯测试/研发/其他相关环节，提出风险预防及改进措施
v.审核考核：前提-问题定位明确，目的-不是考核，是改进，方法-先试运行，然后逐步完善，实施-确定后，严格执行

d)上线之后有缺陷是正常，关键提前组织å好快速响应的团队：精兵干将、开发核心、测试核心、运维核心，24小时职守
e)解决问题后，残留风险必须进行讨论
i.当前出问题的模块是否还隐藏其他的问题，该模块是否所有的用例跑一遍，是否所有bug都跑一遍
ii.雷同问题在其他模块是否存在
六、如何控制风险
a)明确目标：只能控制风险，无法消除风险
b)风险控制策略：早期-风险识别+备选方案， 中期-风险度量+预警+控制， 后期-风险总结+优化改进
c)根本原因：表层原因（时间紧、测试很难充分）， 深层原因（是否做了调研、最低标准达成的可能、当前项目测试质量的高低）
d)确定项目的确存在风险
i.客观真实向上汇报，抄送给项目经理，越早越好，请教大家有没有什么风险的降低方案，备选策略
ii.快速明确测试标准，并提交审核
iii.协调相关资源，与最终用户负责人确认，高优先级定义是否合理
iv.组织风险识别会议，提出风险可能性，备选方案，缓解措施
e)成果：识别出需要关注的风险以及相关解决方案
f)测试执行如何保证完整性
i.测试周期太短
ii.前期协调相关资源，资源的申请要在前期取得支持，如果我们有比较详细的测试用例能执行，测试执行的辅助资源：用户、实习生、其他岗位、其他部门的测试、开发
iii.每个版本测试重点：
1.初期版本：测独立功能，正常数据+正常操作，测正常业务流，另外高优先级的一定要充分首先测试，剩余时间补充高优先级测试点/测试用例
2.中期版本：补充测试数据，补充业务流程
3.后期版本：大规模详细测试，补充人员，用例全部执行，bug要全部回归
iv.是否要在每个版本回归所有的bug，包括已关闭的？
1.根据是否影响最低测试标准决定
2.Bug的优先级、严重程度、影响范围
七、团队协作困难？
a)问题描述
i.产品需求太粗糙，有很多不明确的地方，我们管不了——》测试需求、测试分析、测试设计很难准确——》直接导致有些缺陷发现不了
ii.前面的工作延期，总是压缩测试时间，我们管不了——》测试时间不够——》测试不充分
iii.上线时间太紧，资源不足，我们管不了——》管理层不支持
iv.用户/产品总是变更，我们管不了——》外部风险
b)必然发生的问题，如何应对
i.分出全局、局部，高优先级、重要的问题，不希求完美
ii.产品需求粗糙，产品经理没有时间写，产品经理自己较明确，可根据测试范围，区分出高优先级、复杂度高、新的业务，测试可跟产品经理一对一交流，针对界面，拿着纸，写出输入数据的规则、关系、正确、异常的，处理过程正确、异常的，预期输出角色、操作流程、关键点，画流程图。
iii.延期，默认都是要压缩测试时间周期的，前期尽早介入测试，保证提测质量，回归稳定性，bug修复的效率，且跟客户/产品提前沟通，
iv.资源不足，客观资源不足，尽早协调管理层+人力，加班/优化，如是技术+管理不足导致，可增加培训+改进
v.需求变更，与测试目标直接相关，多与用户多次反复多交流，让用户尽快确认，大概做，改，测，改，开发，测；不是直接和测试目标相关，可暂时放一放，稳定之后，再测试，开发、产品催测试，在有测试资源的前提下，可以简单配合测试