软件测试教程 第八节 管理提升篇
在上述的课程中，我们已经讲述了完成一次完整测试需要进行的活动。
在这里我们将补充一些提升的内容，而这些提升的内容也是一个资深的测试管理者与初级测试管理者的区别。
把握测试过程的方法
测试度量
风险分析
测试过程改进
把握测试过程的方法
1、测试人员何时投入合适？
- 从熟悉项目的角度来说，越来投入越好，如果测试人员能全程参与项目，那么对项目的理解，对测试目标的理解也强很多。
测试计划、测试方案在项目计划和需求初稿出现时就可以开始了，后期可以微调
测试人员可以先与开发人员开始需求测试，在需求基线化之前尽可能的找到需求的缺陷并跟踪修改。
测试人员可以在开发人员开发代码的时候，开始测试用例的设计
如果开发是先有设计再有开发，那么自动化测试的案例在这个时候就可以开始了
性能测试、安全测试等测试一般在功能比较稳定的时候进行测试，但是脚本的编写可以和功能测试同步
2、测试版本的控制
思考以下场景：
1、开发负责人在自己电脑中合并了一个版本提交送测，而没有在远程配置库上建立tag
2、冒烟测试有问题，开发人员给了一个补丁，要求继续测试
3、测试一直在送测--有bug--送测--有bug--送测中循环，如何减少送测的版本数
推荐做法：
1、自动构建（CI、CD）
2、测试人员自行从配置库获取基线，进行构建、部署
3、某些公司会有专门的配置管理员进行该操作
4、减少送测版本数，一是测试人员要尽可能在一轮测试中完成尽可能多的测试工作，二是将bug分优先级，要求bug修改到某种比例时才能送测。
3、测试人员何时退出合适？
对于一个项目来说，项目不停止，测试就不会退出。但是对于一次具体的测试来说，什么时候可以结束测试呢？
1、事先确定版本发布的标准，比如bug数目等，那么bug必须解决
2、多召开bug的评审会议
3、做好测试度量，清楚测试是否到位
4、漏测分析
漏测，对于测试人员来说，是一个非常敏感的问题。相信每一位测试人员，都不希望自己负责测试过的模块存在漏测的bug，但是在现实中，我们测试过的模块常会存在这样那样的漏测问题。
漏测：测试中没有发现而在其他环节中发现。
收集漏测：缺陷库或者用户反馈
漏测分析：分析范围、严重程度、原因
措施跟进：确认改进措施，并跟进，如更新用例库等
对于漏测问题应该在回归测试中进行测试，并且分析修改波及范围，进行针对测试
测试度量
测试度量对于测试管理的目的不仅仅在于考核，而在于测试质量差的人所测试的模块的质量需要重新度量，这是一种风险
测试人员每时每刻都在度量别人的工作成果，而测试人员的工作成果又由谁来度量呢？度量的标准和依据是什么呢？软件测试的度量是测试管理必须仔细思考的问题。缺乏尺度会让测试失去平衡，缺乏标准会让测试工作难以衡量。
软件测试是用于度量软件质量的一种手段，通过测试发现产品缺陷，从而评估软件的整体质量。那么测试本身的质量如何度量呢？开发人员开发产品、测试人员测试产品，真实可见的是产品的质量，软件产品的质量可直接反映开发人员的工作效果。但是能否反映测试人员的工作效果呢？
A项目：
开发人员充足，能力强。测试人员兢兢业业的测试。上线后没有重大问题暴露。
B项目：
B项目需求变更频繁，业务复杂，开发人员不足，能力弱。测试人员兢兢业业的测试。上线后有重大问题暴露。
B项目比A项目测试人员发现的bug数目多，执行的用例多。
那么能说B比A好么？能说A比B好么？
(1)测试不能提高质量，软件的质量是固有特性，测试人员只能通过测试来评估产品的质量，产品质量的提高有赖于开发人员的努力。
(2)测试人员的工作效果不能从软件的产品质量或软件的最终结果得到科学的评估。不能用最终产品来决定一个测试是否成功，或者测试人员是否优秀，而要考虑测试过程的更多因素。
度量bug数量
bug数量是一个直观的参考。在同一个项目，同一个复杂度下比较才有意义，但是也会受到开发人员水平的影响。因此这种度量只能做为参考。
注意：这种度量除了考虑数量，还应该考虑bug的发现难度、严重程度等。
更进一步的方法是：进行交叉测试。同一个模块如果在两个不同人的测试中，bug数量差距较大，则要考虑bug发现少的人的工作质量。
测试覆盖率
统计测试覆盖率一般依赖于用例的执行覆盖率。在日常工作中，如果有用例分配，基本都会执行完成，达到100%。所以这个问题就转换为：测试用例的需求覆盖率以及测试用例是否执行到位？
1、测试用例的需求覆盖率
可以从需求的难易程度，需求的页数，用例的数量来进行横向对比。同样难度，页数差不多的需求转化成为的用例数目应该差不多。
加强测试用例的评审，保证测试用例的覆盖率
2、测试用例是否执行到位
对于测试用例已经包含，测试中标记为测试通过，但是实际产生漏测这种现象：零容忍
从漏测分析
在上面的测试用例是否执行到位的分辨中，已经用到了漏测分析。那么对明显的漏测，比如UI错乱，基本功能未实现。如果不是在测试方案中明确注明不能关注，那么该测试人员可以进入黑名单了。
从bug分析
测试人员提交的bug经常被拒绝，或者偏向于同一类bug，例如界面方面的。那么可以考虑测试人员和开发人员需求理解的不一致，或者文字能力欠缺，或者思维模式有局限性。
风险分析
良好的管理是能在问题发生之前，就可以进行预警
分析风险的目的是及时的调整测试内容和测试方案
软件项目风险是指在软件开发过程中遇到的预算和进度等方面的问题以及这些问题对软件项目的影响。
软件项目的风险主要来源于需求、技术、成本和进度。
需求风险
- 已经纳入基线的需求在继续变更
- 需求定义不准确,进一步的定义会扩展项目范畴
- 增加额外的需求
- 产品定义含混的部分比预期需要更多的时间
- 在做需求中客户参与不够
- 缺少有效的需求变化管理过程
计划编制风险
- 计划、资源和产品定义全凭客户或上层领导口头指令,并且不完全一致
- 计划是优化的,是"最佳状态",但计划不现实,只能算是"期望状态"
- 计划基于使用特定的小组成员,而那个特定的小组成员其实指望不上
- 产品规模(代码行数、功能点、与前一产品规模的百分比)比估计的要大
- 完成目标日期提前,但没有相应地调整产品范围或可用资源
- 涉足不熟悉的产品领域,花费在设计和实现上的时间比预期的要多
组织和管理风险
- 仅由管理层或市场人员进行技术决策,导致计划进度缓慢,计划时间延长
- 低效的项目组结构降低生产率
- 管理层审查决策的周期比预期的时间长
- 预算削减,打乱项目计划
- 管理层作出了打击项目组织积极性的决定
- 缺乏必要的规范,导至工作失误与重复工作
- 非技术的第三方的工作(预算批准、设备采购批准、法律方面的审查、安全保证等)时间比预期的延长
人员风险
- 作为先决条件的任务(如培训及其他项目)不能按时完成
- 开发人员和管理层之间关系不佳,导致决策缓慢,影响全局
- 缺乏激励措施,士气低下,降低了生产能力
- 某些人员需要更多的时间适应还不熟悉的软件工具和环境
- 项目后期加入新的开发人员,需进行培训并逐渐与现有成员沟通,从而使现有成员的工作效率降低
- 由于项目组成员之间发生冲突,导致沟通不畅、设计欠佳、接口出现错误和额外的重复工作
- 不适应工作的成员没有调离项目组,影响了项目组其他成员的积极性
- 没有找到项目急需的具有特定技能的人
开发环境风险
- 设施未及时到位;
- 设施虽到位,但不配套,如没有电话、网线、办公用品等
- 设施拥挤、杂乱或者破损
- 开发工具未及时到位
- 开发工具不如期望的那样有效,开发人员需要时间创建工作环境或者切换新的工具
- 新的开发工具的学习期比预期的长,内容繁多
客户风险
- 客户对于最后交付的产品不满意,要求重新设计和重做
- 客户的意见未被采纳,造成产品最终无法满足用户要求,因而必须重做
- 客户对规划、原型和规格的审核决策周期比预期的要长
- 客户没有或不能参与规划、原型和规格阶段的审核,导致需求不稳定和产品生产周期的变更
- 客户答复的时间(如回答或澄清与需求相关问题的时间)比预期长
- 客户提供的组件质量欠佳,导致额外的测试、设计和集成工作,以及额外的客户关系管理工作
产品风险
- 矫正质量低下的不可接受的产品,需要比预期更多的测试、设计和实现工作
- 开发额外的不需要的功能(镀金),延长了计划进度
- 严格要求与现有系统兼容,需要进行比预期更多的测试、设计和实现工作
- 要求与其他系统或不受本项目组控制的系统相连,导致无法预料的设计、实现和测试工作
- 在不熟悉或未经检验的软件和硬件环境中运行所产生的未预料到的问题
- 开发一种全新的模块将比预期花费更长的时间
- 依赖正在开发中的技术将延长计划进度
设计和实现风险
- 设计质量低下,导致重复设计;
- 一些必要的功能无法使用现有的代码和库实现,开发人员必须使用新的库或者自行开发新的功能
- 代码和库质量低下,导致需要进行额外的测试,修正错误,或重新制作
- 过高估计了增强型工具对计划进度的节省
- 分别开发的模块无法有效集成,需要重新设计或制作
过程风险
- 大量的纸面工作导致进程比预期的慢;
- 前期的质量保证行为不真实,导致后期的重复工作
- 太不正规(缺乏对软件开发策略和标准的遵循),导致沟通不足,质量欠佳,甚至需重新开发
- 过于正规(教条地坚持软件开发策略和标准),导致过多耗时于无用的工作
- 向管理层撰写进程报告占用开发人员的时间比预期的多
- 风险管理粗心,导致未能发现重大的项目风险
测试过程改进
软件测试过程等级(TMM/TCMM)
TCMM Level 1：Initial（初始级）
测试处于一个混乱的状态，测试与调试还没有分开，在编码完成后才进行测试工作，测试和调试交叉在一起，目的就是发现软件中的bug。软件产品发布后没有质量保证。缺乏测试相应的测试资源、例如专职测试人员和测试工具，测试人员没有经过培训。这种类型的公司属于这个阶段，处于这个阶段的公司在测试中缺乏成熟的测试目标，测试处于可无可有的地位。
TCMM Level 2：Phase Definition（阶段定义级）
测试同调试分开且把测试作做为编码后的一个阶段。尽管测试被看做是一个有计划的行为，但是由于测试的不成熟仅在编码后制定测试计划，因为测试完全是针对于源代码的。处于这个级别的公司测试的首要目的就是验证软件符合需求，会采用基本的测试技术和方法，由于测试处于软件生命周期的末尾环节，导致出现很多无法弥补的质量问题。另外，在需求和设计阶段产生的很多问题被引入到编码中，但基于源代码的测试导致产生了很多的问题无法解决。
TCMM Level 3：Integration（集成级）
测试不再是编码后的一个阶段，而是把测试贯穿在整个软件生命周期中。在需求阶段软件测试就介入了，测试是建立在满足用户或客户的需求上，根据需求设计测试用例和作为测试的依据。处于这个级别的公司测试工作由具有独立的部门负责，测试部门与开发部门分开，独立开展工作。测试部门有自己的技术培训并且有测试工具辅助进行测试工作。尽管处于这个阶段的公司认识到了评审在质量控制中的重要性，但是并没有建立起有效的评审制度，还不能在软件生命周期的各个阶段实施评审制度。没有建立起质量控制和质量度量标准。
TCMM Level 4：Management and Measurement（管理和度量级）
测试是一个度量和质量控制过程。在软件生命周期中评审作为测试和软件质量控制的一部分，被测试的软件产品标准包括可靠性、可用性和可维护性等。在测试项目中设计的测试用例被保存在测试用例数据库中便于重用和回归测试。使用缺陷管理系统管理软件缺陷并划分缺陷的级别。但是处于这个阶段的公司还没有建立起缺陷预防机制，且缺乏自动地对测试中产生的数据进行收集和分析的手段。
TCMM Level 5：Optimization（优化级）
具有缺陷预防和质量控制的能力。建立TCMM4基础上的测试公司已经建立起测试规范和流程，测试是受控的和被管理的。而达到TCMM5的公司，则坚决贯彻落实测试规范和流程且不断地进行测试过程改进，在实践中运用缺陷预防和质量控制措施。整个测试过程是被以往经验所驱动的，且是可信任和可靠的。选择和评估测试工具存在一个既定的流程。测试工具支持测试用例的运行和管理，辅助设计用例和维护测试相关资料，缺陷收集和分析，为缺陷预防和质量控制提供支持。
软件测试过程改进
- 调整测试活动的时序关系
- 优化测试活动资源配置
- 提高测试计划的指导性
- 确立合理的度量模型和标准
- 提高覆盖率
- 减少漏测
软件企业良好的软件测试过程
- 测试流程与测试规范
- 测试尽早介入
- 自动化测试流程引入
- 质量控制机制
- 提高测试效率
- 引入白盒测试
- 测试数据记录与度量
头脑风暴：
回顾测试理论课程
以购物app为例，模拟一次从需求到上线的完整过程
前提:该项目以迭代方式开发，分三次开发送测。需求已明确。
1、需求文档的检查，明确测试点
2、制定测试方案
确认测试范围
确认测试方法：功能、性能、自动化、安全性、兼容性、安装卸载....
确认测试工具和方法：自动化工具、测试管理工具？兼容性如何测试？模拟器？CI/CD是否执行
确认测试计划：
需要多少人？什么时候需要？做什么？
确认测试资源：需要什么环境？云测试环境还是自购机？
确认进入退出测试准则
3、编写测试用例
4、评审测试用例
5、测试执行：
准备工作：配置库，CI/CD脚本，测试环境和资源
收到第一个测试版本：冒烟测试，全面测试
收到第二个测试版本：冒烟测试，新功能测试，bug验证
收到第三个测试版本：冒烟测试，新功能测试，bug验证，自动化测试开发完毕
收到第四个测试版本：冒烟测试，自动化回归测试，bug验证，性能测试，安全性测试，探索性测试
收到第五个测试版本：冒烟测试，自动化回归测试，交叉测试，bug验证，性能测试，漏测分析，探索性测试
收到第六个测试版本：冒烟测试，bug验证，兼容性测试，安装卸载测试，回归测试，自动化测试，探索性测试
收到第七个测试版本：冒烟测试，bug验证，自动化回归测试
全程进行风险分析和测试度量
6、出测试报告，发布realease版本
7、测试过程改进