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