测试领域中有待解决的10个难题

1、测试领域中有待解决的 10 个难题近人们谈到测试，常常会听到：测试其实很复杂，所以很有前途。但具体 怎么复杂却不尽其详。我觉得这篇我在微软内部测试架构师站点里读到的， JimMoore 关于测试领域中有待解决的难题的文章很有启发。读过之后，静心想 想，技术含量如何？好像蛮高的？呵呵，也许吧。这其中有些在微软已经解决 了，有些却也是没有解决的。突然发现，测试技术对一个公司来说好像还蛮秘 密的，微软很多内部测试工具测试框架都不产品化，虽然那些工具看起来是可 以普遍运用到业界的。难题可以分为这么些类别：质量衡量标准 （标尺 ）可清晰量化的衡量产品质量测试覆盖率 -代码块覆盖 ,功能覆盖 ,用例覆盖

2、这么多覆盖率 ,每个覆盖率 ,合理的目标是多少 ?50%?80%100%按照找到的缺陷数目 ,多少是被用户找到的 ,多少是被内部非测试团队找到的 多少是被测试团队找到的 ,以此为衡量质量的标尺之一 ?重复发生的回归性缺陷数目补丁和Servicepackage数量，来衡量质量我们有这么多可以用来衡量质量的标准 ,那么 ,哪些应该是核心的标准 ,重要的 普遍标准 .怎么把各个标准和质量关联上 ?制定发布的质量指标 ,怎样才是正确的指标 ,可以指导我们决定发布还是延迟发布产品直到我们达到该指标 怎么定义测试效率 ?包括怎么衡量 s 变化对测试的影响论坛 怎么定义测试 完成 了?来源：复杂领域产品测试

3、 : 音频和视频质量测试 看起来效果对吗 ? 听起来效果对吗 ? 效果 好吗?各种主观类型的测试判断测试工具对系统本身的影响 （测不准原理 ?）: 性能测试工具本身对机器性能的影响所导致的测不准效果 . 测试要素的各种组合 （测试范围庞大 ）:测试要素组合，覆盖各种可能组合，将变得庞大：操作系统VS.调试/发布VS.硬 件配置vs.各种语言 vs.etc.vs.etc.无穷无尽的用户可能输入 . 有时间相关性的产品的测试 .各种时间可能的穷举是无限的 . 整个产品范围测试中的问题整个产品的压力测试这个产品性能测试vs.各个开发组对自己模块所作的性能测试集成测试 .测试集优选 :由时间和进度影响

4、决定 ?由用户影响决定 ?由平均测试用例所找到的缺陷数决定 ?（或者考虑其他投资回报因素而决定 ）挑选测试用例覆盖了所更改的代码 ,依此决定 ?由所要测试的代码复杂度决定 ?项目计划安排 :准确估计测试所需要的时间 .测试团队如何参与决定项目整体进度计划 .敏捷快速迭代测试的计划安排 .测试对项目的影响 :争取修复缺陷？Ci.e比如要求开发组修复缺陷，而他们回答没人会这么做!, 这个时候怎么有理有据的坚持要求修复缺陷 .设计阶段的测试团队参与？C可测试性的分析/设计.是否该拥有对发布 /不发布的决策的影响 .测试自动化 :自动化测试用例的后期维护梦魇 .怎么模拟人眼人耳来做自动作测试 （音频/视频测试 ）产品代码中缺乏足够的接口来支持自动化测试（比如开发人员自己画出来的控件）模拟N用户操作的自动化测试（N非常大）模拟真实的用户 -随机的用户行为 集成测试 :集成测试中的自动化测试调试的责任 ,谁做集成测试 ,谁负责调试整个产品中的问题 ?集成测试应该包含哪些测试用例 ?其他普遍的难题 :几个版本发布之后 ,积累的测试代码变得臃肿