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

难题可以分为这么些类别：

质量衡量标准 (标尺)

可清晰量化的衡量产品质量

测试覆盖率-代码块覆盖，功能覆盖，用例覆盖.... 这么多覆盖率，每个覆盖率，合理的目标是多少? 50%? 80%

按照找到的缺陷数目，多少是被用户找到的，多少是被内部非测试团队找到的，多少是被测试团队找到的，以此为衡量质量的标尺之一?

重复发生的回归性缺陷数目 

补丁和Service package数量，来衡量质量 

我们有这么多可以用来衡量质量的标准，那么，哪些应该是核心的标准，重要的普遍标准.怎么把各个标准和质量关联上?

制定发布的质量指标，怎样才是正确的指标，可以指导我们决定发布还是延迟发布产品直到我们达到该指标.

怎么定义测试效率?包括怎么衡量s变化对测试的影响..

怎么定义测试"完成"了?

复杂领域产品测试:

音频和视频质量测试

"看起来效果对吗?"

"听起来效果对吗?"

效果"好"吗?

各种主观类型的测试判断

测试工具对系统本身的影响(测不准原理?):

性能测试工具本身对机器性能的影响所导致的测不准效果.

测试要素的各种组合(测试范围庞大):

测试要素组合， 覆盖各种可能组合，将变得庞大: 操作系统 vs. 调试/发布 vs. 硬件配置 vs. 各种语言 vs. etc. vs. etc.

无穷无尽的用户可能输入.

有时间相关性的产品的测试.各种时间可能的穷举是无限的.

整个产品范围测试中的问题

整个产品的压力测试 

这个产品性能测试 vs. 各个开发组对自己模块所作的性能测试

集成测试.

测试集优选:

由时间和进度影响决定?

由用户影响决定?

由平均测试用例所找到的缺陷数决定? (或者考虑其他投资回报因素而决定)

挑选测试用例覆盖了所更改的代码，依此决定?

由所要测试的代码复杂度决定?

项目计划安排:

准确估计测试所需要的时间.

测试团队如何参与决定项目整体进度计划.

敏捷快速迭代测试的计划安排.

测试对项目的影响:

争取修复缺陷? i.e. 比如要求开发组修复缺陷，而他们回答"没人会这么做!"， 这个时候怎么有理有据
的坚持要求修复缺陷.

设计阶段的测试团队参与 ? 可测试性的分析/设计.

是否该拥有对发布/不发布的决策的影响.

测试自动化:

自动化测试用例的后期维护梦魇.

怎么模拟人眼人耳来做自动化测试(音频/视频测试)

产品代码中缺乏足够的接口来支持自动化测试(比如开发人员自己画出来的控件)

模拟N用户操作的自动化测试(N非常大)

模拟真实的用户-- [随机的用户行为]

集成测试:

集成测试中的自动化测试

调试的责任，谁做集成测试，谁负责调试整个产品中的问题?

集成测试应该包含哪些测试用例?

其他普遍的难题:

几个版本发布之后，积累的测试代码变得臃肿和难以维护.

设计不好的测试代码，重复的测试代码，各个测试自动化队伍之间缺乏总体的设计和架构避免冗余工作
冗余的测试用例

留住有经验的测试人才