质量衡量标准 (标尺)
可清晰量化的衡量产品质量
测试覆盖率-代码块覆盖,功能覆盖,用例覆盖.... 这么多覆盖率,每个覆盖率,合理的目标是多少? 50%? 80% 100%
按照找到的缺陷数目,多少是被用户找到的,多少是被内部非测试团队找到的,多少是被测试团队找到的,以此为衡量质量的标尺之一?
重复发生的回归性缺陷数目
补丁和Service package数量,来衡量质量
我们有这么多可以用来衡量质量的标准,那么,哪些应该是核心的标准,最重要的普遍标准.怎么把各个标准和质量关联上?
制定发布的质量指标,怎样才是正确的指标,可以指导我们决定发布还是延迟发布产品直到我们达到该指标.
怎么定义测试效率?包括怎么衡量s变化对测试的影响..
怎么定义测试"完成"了?
复杂领域产品测试:
音频和视频质量测试
"看起来效果对吗?"
"听起来效果对吗?"
效果"好"吗?
各种主观类型的测试判断
测试工具对系统本身的影响(测不准原理?):
性能测试工具本身对机器性能的影响所导致的测不准效果.
如何确定一个软件的测试结束点
在软件消亡之前，如果没有测试的结束点，那么软件测试就永无休止，永远不可能结束。软件测试的结束点，要依据自己公司具体情况来制定，不能一概而论！个人认为测试结束点由以下几个条件决定：
1．基于“测试阶段”的原则：
每个软件的测试一般都要经过单元测试、集成测试、系统测试这几个阶段，我们可以分别对单元测试、集成测试和系统测试制定详细的测试结束点。每个测试阶段符合结束标准后，再进行后面一个阶段的测试。举个例子来说：单元测试，我们要求测试结束点必须满足“核心代码100％经过Code Review”、“功能覆盖率达到100％”、“代码行覆盖率不低于80％”、“不存在A、B类缺陷”、“所有发现缺陷至少60％都纳入缺陷追踪系统且各级缺陷修复率达到标准”等等标准。集成测试和系统测试的结束点都制定相关的结束标准，当然也是如此。
2．基于“测试用例”的原则：
测试设计人员设计测试用例，并请项目组成员参与评审，测试用例一旦评审通过，后面测试时，就可以作为测试结束的一个参考标准。比如说在测试过程中，如果发现测试用例通过率太低，可以拒绝继续测试，待开发人员修复后再继续。在功能测试用例通过率达到100%，非功能性测试用例达到95%以上，允许正常结束测试。但是使用该原则作为测试结束点时，把握好测试用例的质量，非常关键。
3．基于“缺陷收敛趋势”的原则：
软件测试的生命周期中随着测试时间的推移，测试发现的缺陷图线，首先成逐渐上升趋
势，然后测试到一定阶段，缺陷又成下降趋势，直到发现的缺陷几乎为零或者很难发现缺陷为止。我们可以通过缺陷的趋势图线的走向，来定测试是否可以结束，这也是一个判定标准。
4．基于“缺陷修复率”的原则：
软件缺陷在测试生命周期中我们分成几个严重等级，它们分别是：严重错误、主要错误、次要错误、一般错误、较小错误和测试建议6种。那我们在确定测试结束点时，严重错误和主要错误的缺陷修复率必须达到100%，不允许存在功能性的错误；次要错误和一般错误的缺陷修复率必须达到85%以上，允许存在少量功能缺陷，后面版本解决；对于较小错误的缺陷修复率最好达到60%~70%以上。对于测试建议的问题，可以暂时不用修改。
5．基于“验收测试”的原则：
很多公司都是做项目软件，如果这种要确定测试结束点，最好测试到一定阶段，达到或接近测试部门指定的标准后，就递交用户做验收测试。如果通过用户的测试验收，就可以立即终止测试部门的测试；如果客户验收测试时，发现了部分缺陷，就可以针对性的修改缺陷后，验证通过后递交客户，相应测试也可以结束。
6．基于“覆盖率”的原则：
对于测试“覆盖率”的原则，个人觉的只要测试用例的“覆盖率”覆盖了客户提出全部的软件需求，包括行业隐性需求、功能需求和性能需求等等，只要测试用例执行的覆盖率达到100%，基本上测试就可以结束。如“单元测试中语句覆盖率最低不能小于80%”、“测试用例执行覆盖率应达到100%”和“测试需求覆盖率应达到100%”都可以作为结束确定点。如果你不放心，非得要看看测试用例的执行效果，检查是否有用例被漏执行的情况，可以对常用的功能进行“抽样测试 ”和“随机测试”。对于覆盖率在单元测试、集成测试和系统测试，每个阶段都不能忽略。
7．基于“项目计划”的原则：
大多数情况下，每个项目从开始就要编写开发和测试的Schedule，相应的在测试计划中也会对应每个里程碑，对测试进度和测试结束点做一个限制，一般来说都要和项目组成员（开发，管理，测试，市场，销售人员）达成共识，团队集体同意后制定一个标准结束点。如果项目的某个环节延迟了，测试时间就相应缩短。大多数情况下是所有规定的测试内容和回归测试都已经运行完成，就可以作为一个结束点。很多不规范的软件公司，都是把项目计划作为一个测试结束点，但是如果把它作为一个结束点，测试风险较大，软件质量很难得到保证。
8．基于“缺陷度量”的原则：
这个原则也许大家用的不是很多，了解比较少。我们可以对
已经发现的缺陷，运用常用的缺陷分析技术和缺陷分析工具，用图表统计出来，方便查阅，分时间段对缺陷进行度量。我记得以前zhuzx在这个论坛上提出过缺陷分析技术这个问题，我不再重复讲述。我们也可以把 “测试期缺陷密度”和 “运行期缺陷密度”作为一个结束点。当然，最合适的测试结束的准则应该是“缺陷数控制在一个可以接受的范围内”。比如说：一万行代码最多允许存在多少个什么严重等级的错误，这样比较好量化，比较好实施，成为测试缺陷度量的主流。
9．基于“质量成本”的原则：
一个软件往往要从“质量/成本/进度”三方面取得平衡后就停止。至于这三方面哪一项占主要地位,就要看是什么软件了。比如说是：人命关天的航天航空软件, 那还是质量重要些,就算多花点钱、推迟一下进度，也要测试能保证较高质量以后才能终止测试，发布版本。如果是一般的常用软件，由于利益和市场的原因，哪怕有bug，也必须得先推出产品，没办法呀。一般来说，最主要的参考依据是：“把找到缺陷耗费的代价和这个缺陷可能导致的损失做一个均衡”。具体操作的时候，可以根据公司实际情况来定义什么样的情况下算是“测试花费的代价最划算、最合理”，同时保证公司利益最大化。如果找到bug的成本比，用户发现bug 的成本还高，也可以终止测试。
10．基于“测试行业经验”的原则：
很多情况下，测试行业的一些经验，也可以为我们的测试提供借鉴。比如说测试人员对行业业务的熟悉程度，测试人员的工作能力，测试的工作效率等等都会影响到整个测试计划的执行。如果一个测试团队中，每个人都没有项目行业经验数据积累，拿到一个新的项目，自然是一头雾水，不知道从何处开始，测试质量自然不会很高。因此通过测试者的经验，对确认测试执行和结束点也会起到关键性的作用。
测试要素的各种组合(测试范围庞大):
测试要素组合, 覆盖各种可能组合,将变得庞大: 操作系统 vs. 调试/发布 vs. 硬件配置 vs. 各种语言 vs. etc. vs. etc.
无穷无尽的用户可能输入.
有时间相关性的产品的测试.各种时间可能的穷举是无限的.
整个产品范围测试中的问题
整个产品的压力测试
这个产品性能测试 vs. 各个开发组对自己模块所作的性能测试
集成测试.
测试集优选:
由时间和进度影响决定?
由用户影响决定?
由平均测试用例所找到的缺陷数决定? (或者考虑其他投资回报因素而决定)
挑选测试用例覆盖了所更改的代码,依此决定?
由所要测试的代码复杂度决定?
项目计划安排:
准确估计测试所需要的时间
.
测试团队如何参与决定项目整体进度计划.
敏捷快速迭代测试的计划安排.
测试对项目的影响:
争取修复缺陷– i.e. 比如要求开发组修复缺陷,而他们回答"没人会这么做!", 这个时候怎么有理有据的坚持要求修复缺陷.
设计阶段的测试团队参与 – 可测试性的分析/设计.
是否该拥有对发布/不发布的决策的影响.
测试自动化:
自动化测试用例的后期维护梦魇.
怎么模拟人眼人耳来做自动化测试(音频/视频测试)
产品代码中缺乏足够的接口来支持自动化测试(比如开发人员自己画出来的控件)
模拟N用户操作的自动化测试(N非常大)
模拟真实的用户-- [随机的用户行为]
集成测试:
集成测试中的自动化测试
调试的责任,谁做集成测试,谁负责调试整个产品中的问题?
集成测试应该包含哪些测试用例?
其他普遍的难题:
几个版本发布之后,积累的测试代码变得臃肿和难以维护.
设计不好的测试代码,重复的测试代码,各个测试自动化队伍之间缺乏总体的设计和架构避免冗余工作
冗余的测试用例
留住有经验的测试人才
软件测试过程的度量
1）测试度量的作用（－）
A:为制定测试计划时提供依据
需要多长时间? 需要什么物质条件？ 需要多少人，什么素质的人？ 在规定的时间内能完成到什么程度？
哪些模块及功能需要重点关注？ 测试工作量占整个项目的比例？ 测试结束后我们能达到什么样的目标 ？等等
( 这些数据是我们在项目启动过程中，制定测试计划，尤其在规划资源的过程中，一些必要的参考值。不同项目可能会有其特殊性，但从总体上看，他们还是有一些规律可寻的，过去的经验数据可以作为一个大概估算，如果项目经验丰富，那么可以从历史数据中找出和新项目 类似的情况，以能更为准确的完成计划。 )
B： 提高测试流程可控性
提高测试效率和质量
提高测试人员的成就感
2)在测试哪个过程做度量
（产品早期的市场评估、测试策略分析、可测试性需求分析、测试工具分析、用例设计阶段、执行阶段和 FOA 阶段）
我们需要在测试的几个关键阶段做度量，它们分别是：用例设计阶段、执行阶段和 FOA 阶段。测试用例设计阶段包括测试方案的最终确定、测试工具的设计、测试用例编写等，测试执行阶段很明显，即我们测试的各个过程，如集成测试、系统测试、性能测试、回归测试等，也包括开发人员完成的单元测试的度量工作。 FOA 阶段是检验测试质量的第一步，通过 FOA 我们可以获得很多为产品质量做贡献的度量，这也是体现测试价值的度量。看起
来几乎包括了测试过程的全部。其实这里包括的只是测试的具体工作阶段。
3）测试度量的内容
两种度量类型：
A： 项目度量：规模、测试工作量、测试进度、测试生产率
B： 质量度量：缺陷率（阶段）、缺陷排除率、可靠性等
四个基本度量项：规模、工作量、进度、缺陷
4) 测试用例设计阶段的度量
A：规模 ：测试方案数量、测试用例数量、测试工具设计数量、测试用例/人月
B： 工作量 ：文档的草稿编写工作量、评审前阅读工作量、评审工作量 、修改工作量
C： 进度 ：每件具体工作的计划开始结束时间、实际开始结束时间、计划工时数、实际工时数、计划完成率
D： 缺陷 ：评审过程中出现的错误数量、缺陷数量，级别
5）测试执行阶段的度量：
? 测试用例执行率 ? 测试用例通过率
? 测试用例问题发现率 ? BUG数量
? BUG级别统计 ? BUG分布统计（模块）
? BUG分布统计（阶段） ? BUG密度
? BUG关闭率 ? 人均BUG发现效率
? 测试用例执行工作量项目 ? 回归测试执行工作量
? 发布文档数量 ? 发布文档缺陷数量、级别
? 现场发现的BUG数量 ? 回归测试现场BUG的工作量
? 版本发布过程中的验证周期 ? 版本发布过程中的验证工作量
? 测试用例覆盖率 ? 功能的用户关注度
? 需求变化程度
6）测试的度量为项目实施做的贡献
度量项 含义 目的与意义
测试生产率 单位时间所测试的代码量、或者单位时间执行测试用例的数量 一个团队的测试能力
工作量变化率 实际花费工作量相对于估计工作量的偏差百分比 提高估计技能、避免过载分配任务
测试进度变化率 项目实际测试进度相对于计划进度的偏差百分比 监控项目以便适时采取纠正措施
工作量 测试所做的工作小时数 测试为整个项目贡献的工作量
缺陷密度 千行代码发现的缺陷数，千个功能发现的缺陷数 用于度量被测试系统的可靠性
测试问题的严重性 测试发现问题的严重性分布 用于确定目前被测试系统的可靠性
测试用例的问题发现效率 单个测试用例发现问题的数量 用于度量测试用例的有效性
测试用例覆盖率 需求覆盖率、功能点覆盖率、代码覆盖率等 度量测试的充分性
问题遗漏率 发布后市场反馈问题数/产品问题总数目 衡量内部测试质量
COQ 为提升测试质量所付出的工作量
COPQ 为不好的质量付出的代价
7)由谁来做度量
8)怎样做度量?
PDCA方法：
第一步：Plan
（ 计划、设置标竿） ( 计划－－制定我们想要达到的目标)
第二步：do （执行）(日报－－记录数据)( 周报－－汇总数据，给出度量结果)
第三步：check （ 检查和标竿有什么差距） (周例会－－针对度量结果，作出下一步工作建议)
第四步：action （改进过程)( 阶段总结－－子系统、集成、系统测试等各测试阶段结束后做度量评估，为后续工
作做出指导)
第五步:return to plan
\
AutoRunner软件测试工具
TestCenter强大测试管理工具
QACenter--软件黑盒测试工具