●测试结果分析和评价
缺陷密度:
→ 基本的缺陷测量是以每千行代码的缺陷数(Defects/KLOC)来测量的。称为缺陷密度(Dd)，其测量单位是defects／KLOC。可按照以下步骤来计算一个程序的缺陷密度：
→ 累计开发过程中每个阶段发现的缺陷总数(D)。
→ 统计程序中新开发的和修改的代码行数(N)。
→ 计算每千行的缺陷数Dd=1000*D/N。
→ 例如，一个29.6万行的源程序总共有145个缺陷，则缺陷密度是：
→ Dd＝1000*145/296000=0.49 defects／KLOC。
→ 在计算缺陷密度时，最重要的是要使用正确的规模测量。
输出《测试综合报告》：
→ 测试过程的总结
→ 测试数据分析（按照严重程度等方式分类统计的分析，包括测试密度等）
→ 产品主要问题和总体评价
→ 遗留的问题总结
→ 最终的测试结论
为了了解和控制缺陷带来的费用，很有必要测量缺陷排除的效果测量：
→ 一种测量方法是计算每小时排除缺陷的个数；
→ 一种是计算缺陷排除效益，即测量通过某一排除方法所发现的缺陷的百分比。
缺陷排除效益是45%
测试覆盖率测量
→ 语句覆盖率 测试经历语句数/总语句数
→ 分支覆盖率 测试经历支路数/总支路数
→ 简单路径覆盖率 测试经历简单路径数/总简单路径数
→ 功能覆盖率
→ 界面数
→ 菜单数
→ 输入/输出的数据元数
→ 构件、模块
→ …
● 软件测试经验分享
→ 所有的测试都应追溯到需求。因最严重的错误是导致程序无发满足需求的错误；
→ 软件开发人员和管理人员首先应该尽早地和不断地进行各种软件质量保证活动（如需求和设计阶段同行评审和走查等）;
→ 软件开发人员应避免检查自已的程序，利用同行评审的方式对代码进行审查；(自己检查容易依照原有的程序设计思路进行，往往查不出问题)
→ 在设计测试用例时，必须明确预期的输出结果，否则对实际的输出结果很难有检验的标准，测试失去意义。测试用例应由输入数据和与之对应的期望输出结果这两部分组成，在输入数据中，应当包括合理的输入条件和不合理的输入条件；
→ 在进行各种分析和修复工作中，要充分注意修复工作所产生的影响效果和波及效果。
→ 统计表明大约有60%的错误是在设计阶段之前注入的，并且修正一个软件错误所需的费用将随着软件生存期的进展而上升。错误发现得越晚，修复它的费用就越高，而且呈指数增长的趋势。
→ 测试后程序中残存的错误数目与该程序中已发现的错误数目（即检错率）很可能成正比；(编码规范、需求理解、技术能力、内部耦合性是引起这些现象的原因)
→ 程序中的大部分错误往往是在一小部分模块中发现的，遵循普遍适用的“二八定理”（即80%的错误往往是由20%的模块所造成的），例如，IBM公司的OS/370操作系统中，47% 的错误仅与该系统中的4%的程序模块有关；
→ 要严格执行测试计划，排除测试的随意性，这样才能消除各种无序操作所造成的副作用；测试设计决定了测试的有效性和效率，测试工具只能提高测试效率
→ 应当对每一个测试结果做全面的检查，这样才有可能找到真正的出错原因，为今后的调试工作奠定基础。
● 结束语
→ 产品越复杂，测试花费的时间就越长，费用就越大，测试发现缺陷的效率也就越低。
→ 缺陷会掩盖或加重其它缺陷。也就是说，当一个程序有许多缺陷时，由于缺陷相互作用，使得发现和修复缺陷的过程更加复杂。这使得一些缺陷很难查找和修复。一个缺陷可能掩盖其它缺陷，使得这些被掩盖的缺陷难以发现，增加了它们逃过测试的可能性。
→ 遵照规范化的方法，仔细复查和测试每个小程序模块，这比让任何测试组在你的程序中发现缺陷的效果要好。也就是说，尽早的将缺陷排除掉。测试不能避免缺陷的发生，只能是一种补救。
→ 你是唯一能做到生产出无缺陷程序的人，其他任何人都无法帮你做到这一点。
