测试领域中有待解决的难题们
来源:互联网 发布:佳能相机软件 编辑:程序博客网 时间:2024/05/16 17:40
最近人们谈到测试,常常会听到:测试其实很复杂,所以很有前途。但具体怎么复杂却不尽其详。我觉得这篇我在微软内部测试架构师站点里读到的,Jim Moore 关于测试领域中有待解决的难题的文章很有启发。读过之后,静心想想,技术含量如何?好像蛮高的?呵呵,也许吧。这其中有些在微软已经解决了,有些却也是没有解决的。 突然发现,测试技术对一个公司来说好像还蛮秘密的,微软很多内部测试工具测试框架都不产品化,虽然那些工具看起来是可以普遍运用到业界的。
<<翻译开始了>>
难题可以分为这么些类别:
质量衡量标准 (标尺)
可清晰量化的衡量产品质量
测试覆盖率-代码块覆盖,功能覆盖,用例覆盖.... 这么多覆盖率,每个覆盖率,合理的目标是多少? 50%? 80% 100%
按照找到的缺陷数目,多少是被用户找到的,多少是被内部非测试团队找到的,多少是被测试团队找到的,以此为衡量质量的标尺之一?
重复发生的回归性缺陷数目
补丁和Service package数量,来衡量质量
我们有这么多可以用来衡量质量的标准,那么,哪些应该是核心的标准,最重要的普遍标准.怎么把各个标准和质量关联上?
制定发布的质量指标,怎样才是正确的指标,可以指导我们决定发布还是延迟发布产品直到我们达到该指标.
怎么定义测试效率?包括怎么衡量s变化对测试的影响..
怎么定义测试"完成"了?
复杂领域产品测试:
音频和视频质量测试
"看起来效果对吗?"
"听起来效果对吗?"
效果"好"吗?
各种主观类型的测试判断
测试工具对系统本身的影响(测不准原理?):
性能测试工具本身对机器性能的影响所导致的测不准效果.
测试要素的各种组合(测试范围庞大):
测试要素组合, 覆盖各种可能组合,将变得庞大: 操作系统 vs. 调试/发布 vs. 硬件配置 vs. 各种语言 vs. etc. vs. etc.
无穷无尽的用户可能输入.
有时间相关性的产品的测试.各种时间可能的穷举是无限的.
整个产品范围测试中的问题
整个产品的压力测试
这个产品性能测试 vs. 各个开发组对自己模块所作的性能测试
集成测试.
测试集优选:
由时间和进度影响决定?
由用户影响决定?
由平均测试用例所找到的缺陷数决定? (或者考虑其他投资回报因素而决定)
挑选测试用例覆盖了所更改的代码,依此决定?
由所要测试的代码复杂度决定?
项目计划安排:
准确估计测试所需要的时间.
测试团队如何参与决定项目整体进度计划.
敏捷快速迭代测试的计划安排.
测试对项目的影响:
争取修复缺陷– i.e. 比如要求开发组修复缺陷,而他们回答"没人会这么做!", 这个时候怎么有理有据的坚持要求修复缺陷.
设计阶段的测试团队参与 – 可测试性的分析/设计.
是否该拥有对发布/不发布的决策的影响.
测试自动化:
自动化测试用例的后期维护梦魇.
怎么模拟人眼人耳来做自动化测试(音频/视频测试)
产品代码中缺乏足够的接口来支持自动化测试(比如开发人员自己画出来的控件)
模拟N用户操作的自动化测试(N非常大)
模拟真实的用户-- [随机的用户行为]
集成测试:
集成测试中的自动化测试
调试的责任,谁做集成测试,谁负责调试整个产品中的问题?
集成测试应该包含哪些测试用例?
其他普遍的难题:
几个版本发布之后,积累的测试代码变得臃肿和难以维护.
设计不好的测试代码,重复的测试代码,各个测试自动化队伍之间缺乏总体的设计和架构避免冗余工作
冗余的测试用例
留住有经验的测试人才
- 测试领域中有待解决的难题们
- 测试领域中有待解决的难题们
- [转]测试领域中有待解决的难题们
- 测试领域中有待解决的难题们
- 测试领域中有待解决的难题们
- 有待解决的问题。
- 有待解决
- Linux系统内核有待提高的七个领域
- 关于List<?>集合的排序--有待测试
- 有待解决的编程问题...请达人明示.
- 几个不懂的函数,有待解决
- 一些有待解决的技术问题
- 工作中效率有待提高的点
- 一劳永逸解决PPT中声音视频的路径难题
- 测试领域的出路
- 11 有待测试
- 问题有待解决!!!!!!!!!!!!!
- 21世纪有关计算机领域的十二个重大难题
- 常用正则表达式
- C#.NET中管理文件(磁盘和目录的管理)
- C++中string类的用法概述
- SOA概述
- 盖茨语录
- 测试领域中有待解决的难题们
- 我对开源运动的看法
- 觉得在VS2005下最好的功能就是代码自动完成了
- 管理者小训练:如何增强你的自信
- 文件操作C(文件过滤)
- 深入认识javascript中的eval函数
- 文化.性格.年龄.赞扬
- 去QQ空间标题栏的方法
- 如何做成事