测试难题 （转帖/收藏）

(转帖)难题可以分为这么些类别：

1. 质量衡量标准 (标尺)

1.1 可清晰量化的衡量产品质量
1.2 测试覆盖率-代码块覆盖,功能覆盖,用例覆盖.... 这么多覆盖率,每个覆盖率,合理的目标是多少? 50%? 80% 100%
1.3 按照找到的缺陷数目,多少是被用户找到的,多少是被内部非测试团队找到的,多少是被测试团队找到的,以此为衡量质量的标尺之一?
1.4 重复发生的回归性缺陷数目 
1.5 补丁和Service package数量,来衡量质量 
1.6 我们有这么多可以用来衡量质量的标准,那么,哪些应该是核心的标准,最重要的普遍标准.怎么把各个标准和质量关联上?
1.7 制定发布的质量指标,怎样才是正确的指标,可以指导我们决定发布还是延迟发布产品直到我们达到该指标.
1.8 怎么定义测试效率?包括怎么衡量s变化对测试的影响..
1.9 怎么定义测试"完成"了?

 

2.复杂领域产品测试:

2.1 音频和视频质量测试
2.2 各种主观类型的测试判断 "看起来效果对吗?" "听起来效果对吗?" 效果"好"吗?

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

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

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

2.6 测试要素组合, 覆盖各种可能组合,将变得庞大: 操作系统 vs. 调试/发布 vs. 硬件配置 vs. 各种语言 vs. etc. vs. etc.
2.7 无穷无尽的用户可能输入.
2.8 有时间相关性的产品的测试.各种时间可能的穷举是无限的.

 

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

3.1 整个产品的压力测试 
3.2 这个产品性能测试 vs. 各个开发组对自己模块所作的性能测试
3.3 集成测试.

 

4. 测试集优选:

4.1 由时间和进度影响决定?
4.2 由用户影响决定?
4.3 由平均测试用例所找到的缺陷数决定? (或者考虑其他投资回报因素而决定)
4.4 挑选测试用例覆盖了所更改的代码,依此决定?
4.5 由所要测试的代码复杂度决定?

 

5. 项目计划安排:

5.1 准确估计测试所需要的时间.
5.2 测试团队如何参与决定项目整体进度计划.
5.3 敏捷快速迭代测试的计划安排.

 

6. 测试对项目的影响:

6.1 争取修复缺陷– i.e. 比如要求开发组修复缺陷,而他们回答"没人会这么做!", 这个时候怎么有理有据的坚持要求修复缺陷.
6.2 设计阶段的测试团队参与 – 可测试性的分析/设计.
6.3 是否该拥有对发布/不发布的决策的影响.

 

7. 测试自动化:

7.1 自动化测试用例的后期维护梦魇.
7.2 怎么模拟人眼人耳来做自动化测试(音频/视频测试)
7.3 产品代码中缺乏足够的接口来支持自动化测试(比如开发人员自己画出来的控件)
7.4 模拟N用户操作的自动化测试(N非常大)
7.5 模拟真实的用户-- [随机的用户行为]

 

8. 集成测试:

8.1 集成测试中的自动化测试
8.2 调试的责任,谁做集成测试,谁负责调试整个产品中的问题?
8.3 集成测试应该包含哪些测试用例?

 

9. 其他普遍的难题:

9.1 几个版本发布之后,积累的测试代码变得臃肿和难以维护.
9.2 设计不好的测试代码,重复的测试代码,各个测试自动化队伍之间缺乏总体的设计和架构避免冗余工作
9.3 冗余的测试用例
9.4 留住有经验的测试人才