多年前参加过一次研发过程管理，其中测试管理是我不熟悉的，当时做了很详细的笔记，现在觉得还是很有价值
管理的目的: 人员,成本,进度,质量达到最优的配置.
测试工作管理
一. 测试的目标.
质量定义:
1.用户可接受的质量(首先);
2.公司达到的质量(其次)
二者不一致时,分析最低目标,基本目标,较高目标(划分优先级)
二. 技术:覆盖率
工作成效的衡量:
A.发现bug数;
B.发现bug的时间;
C.协助开发人员减少问题的发生.
如何协助开发人员减少问题发生,通过BUG统计分析很重要:
分析其产生的原因:需求变更？设计不详？GUI缺失？代码漏洞？
1. 使用覆盖率而不是BUG数
1)系统测试:
需求覆盖率
覆盖的充分性:
[if !supportLists]l [endif]功能性:单一(输入,处理,有效);业务(功能组合)
[if !supportLists]l [endif]非功能性:性能,安全,易用,可移植,健壮性…
2)单元测试
逻辑覆盖:语句,分支,条件,分支-条件,路径…
2. 对开发成果物的分析
SRS:测试需求分析(业务的分析:
首先要学习业务,可通过对以往系统的学习,数据库文档,其它文档变更,概要设计等; 如果是新业务，也要进行业务学习。
重点关注：HLD:功能模块之间的关系，DB:表的功能,表的记录,字段的变化,表之间的关系，LLD:单元测试(降低BUG修复成本)
针对核心算法,公共模块,用户使用频率较高的核心内容进行单元测试,；
针对对跨技术框架和较为重要的模块之间接口进行集成测试；
普通内容只进行系统测试来获取较高的投入产出比.。
三.时间
测试内部:
A测试工作量?(划分测试阶段,依据总目标制定阶段目标,每阶段人员明确及分工,让人员熟悉任务,确定每个人每个阶段的工作量和时间)
B.测试回归:失控原因:
1.BUG数太多(用例数和BUG数的比例),
2.修复质量差(3次以上)
若BUG数太多:
A.封存BUG,.
B.对已发现的BUG进行统计分析,找到大量缺陷产生的根本原因
,C.与开发协商相关的解决方案,D重新提交版本进行测试.
测试外部:
A. 得到测试回归BUG修复率指标,
B. [endif]分析修复质量低的原因(按模块修复比率进行统计,
C. [endif]根据原因提出解决方案
D. [endif].重新提交版本进行测试)
1.开发进度对测试时间的挤占:
1)调整目标(要取得开发和管理的认可,还可增加人力);
2)调整工作任务的优先级;
3)明确变更后的时间
2.需求变更/设计变更:
A.测试要参与需求变更/设计变更的评审,
B.变更产生的测试工作量,
C.时间的影响:评估未变更部分的测试执行工作是否可采用自动化
四.人员问题:人员的技术,人员的业务水平
1.技术:
开发能力:软件形成的理解程度
数据库:表结构的理解，编写SQL能力
网络:环境搭建,网络协议理解，网络抓包
测试方法: 等价类，边界，判定表，正交试验
性格：结构性，破坏性，创新性.
2.业务水平:低/中/高
低:培养业务(画业务图,分析数据表,数据关系图,了解系统的网络结构)
中:表之间的关系,业务场景图
高:挖掘非功能需求
五.客户:
在测试工作确立目标时:用户最关心的,一般关心的,比较关心的,不关心的.
软件即将完成时,让用户抽查,阶段性沟通很有必要,要确定范围,不要什麽问题都让提.
测试团队管理
一．如何组建测试团队？
目标：团队中的角色分工、职责分派
和其他部门之间的关系：在整个组织结构中的位置，位置不同，沟通渠道不同
二．如何规划测试流程？
1．流程的作用和目标：
A.建立流程的必要性：缺乏统一的目标、方法、成果物；
B.流程花费的成本：建立、实施、实现、改进；
C.产生的效果在短期内很难见效。
对公司现状进行分析：
1）哪些方面是由于流程不规范导致的问题；
2）大多数人的做事习惯；
3）公司打算在流程上花费的成本。
明确改进的目标：
A. 在上次流程实施中要获取一定的度量数据
测试中问题：版本混乱、测试不完备（可加入测试需求分析文档，与需求规格绑定，由需求人员负责）、测试文档更新不及时、测试缺乏评估
B. ]如何进行测试效果评估？
1） 测试目标是评估的依据
2）测试过程中要收集关键数据：覆盖率+充分性、测试工作量（用例分析、编写、执行（第一次、回归））、测试返工量、发现BUG数（产生原因/各模块分布/版本/严重程度/剩余BUG的比例/残留BUG的比例）
C. 评估目标的确定：
1．是否符合整体测试的工作目标
1）覆盖率是否满足
2）测试工作量是否估计准确
2．是否符合用户验收要求
3．有效的测试工作所占比例
4．减少BUG发生的比例
5．减少发现时间的先后状况
三．如何做到高效管理？
A. 影响管理效率的因素
1） 目标不明确：不要多、不要过高、可度量（总体、阶段、个人）、定期检查
2） 风险防范意识：
需求（业务不了解不深入不全面、需求变更）、
人员技术（定义技术细节实现、测试点概括）、
人员流动（对核心骨干，让其多做培训、文档、技术共享的工作）、
进度风险（优先级）
B. 如何制定评审检查规则？
1） 规则的制定是逐步完成的
2） 规则制定要与成果物的质量水平相匹配
3） 检查规则要与评审目标相匹配
C. 测试用例粒度
1． 功能点
2． 输入、处理、预期
3． 输入（有效/无效）、处理（分支）、预期
D. 测试需求分析如何细化
1）功能点
2） 输入（有效/无效）/处理（分支）/输出（各种）
处理比较重要，分支越多，测试越细。
3） 规划：
通过人、时间、成本、质量、技术来获得预期目标
切割目标、目标优先级、目标进行阶段划分
1．首先考虑短缺的因素
2． 分析短缺因素可能会导致的风险
3．风险的预防
4．平衡其它因素为达成目标而服务
5． [短缺因素过多时，先从版本发布计划（V1.0、V2.0、V3.0…）
6． 提高成果物的复用性（分为通用控件测试用例、界面测试用例、通用功能）
7． 使用自动化工具
8． 与管理层沟通，添加资源