关于软件测试

关于软件测试
测试的目的应该是验证需求
测试的目的是什么呢？这是一个看起来很简单、不太值得讨论的问题，但往往这样的问题其实是很难回答的，比如人生的意义是什么？好，现在我们就来，列举一下我们经常听到的对这个问题的回答：

“软件测试的目的是尽可能发现并改正被测试软件中的错误，提高软件的可靠性。”，这个定义听起来很正确，但用它来指导测试会带来很多问题。比如有的组织用发现的bug数来衡量测试人员的业绩，其实这就是这种测试目的论在后面作祟，其结果如何呢：其一，有一些不够敬业的测试人员会找来一些无关痛痒的bug来充数，结果许多时间会被浪费在这些无关痛痒的bug上（其实应该修复，何时修复，严重程度是什么，优先级是什么，等等）；其二，测试人员会花很大力气设计一些复杂的测试用例去发现一些迄今尚未发现的缺陷，而不关心这些缺陷是否在实际用户的使用过程当中是否会发生，从而浪费了大量的宝贵时间。究其根源，就是因为对测试目的的这种错误理解造成的，为什么这么说呢？因为软件里bug的数量是无从估计的，那么如果测试的目的是为了找bug，那么测试工作将变成一项无法完成也无法衡量进度而且部分无效的工作（因为有些bug在实际的运行过程当中根本不会发生）。

“测试的目的就是为了保证软件质量”，这个定义也是看似正确，但实际上，混淆了测试和质量保证工作的边界。软件质量要素有很多，包括：Understandability、 Conciseness、Portability、Consistency、Maintainability、Testability、 Usability、Structures、Efficiency、Security等等，所以，软件质量保证和测试其实关注的方向是不同的。

那么测试的目的应该是什么呢？IEEE在1983年提出了软件测试的定义：
“使用人工或自动手段来运行或测定某个系统的过程，其目的在于检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别。”

所以，简言之，测试的目的应该是验证需求，bug（预期结果与实际结果之间的差别）是这个过程中的产品而非目标。测试人员应该象工兵一样，在大部队（客户）预期前进的方向上探雷、扫雷（bug），而不需要去关心那些根本没有人会去碰的地雷。衡量一个测试人员应该去衡量他/她测试了多少需求（测试工作量），漏过了多少bug（测试有效性）。（在后面的博文里我们会进一步谈测试后评估的重要性）

因此，我们可以看到有好的需求文档/体系对测试工作的必要性，我们看到许多测试团队在业务需求/软件需求不完备的情况下，往往或重新编写测试需求。在未来的博文里，我们会在介绍为什么用例（Use Case）技术会有助于开发人员和测试人员的沟通。




物理实验与软件测试
读理工科的人多多少少做过物理实验，从中学到大学有数不清的机会。对照书本的步骤一项一项做下来，看到预期的结果就收工走人，不然就找原因直到得到正确结果为止。
这就是物理实验吗？
从事科研工作的人对这种“实验”嗤之以鼻。这样做除了应付一下教育部一点价值都没有。
科学研究是要探索未知的世界，并没有一个先知可以断言某件事情，而我们不经证实就奉为真理。出发点不同，行为的效果便大相径庭。要探索未知的世界，除了试验既定的路线外，还须广历不同的路线，获得大量的信息来了解世界的真相；反之仅仅是重复的话，只需要走固定的步骤，如果结果不同还要想方设法为预期结果辩护，实在是南辕北辙。
有人会问，科学家重复同行的实验又作何论？那时实验结论尚未成为公论，需要重复已有实验，并辅以新的实验来证实怀疑；也有挑战现有理论，改变条件试图证明新的理论。这些都是为了探索证实未知的世界，出发点大不一样。
那么，软件测试是为了探索世界还是重复检验呢？
有人认为，程序员写的代码，设计目的是明确的，所用技术是清晰的。只要有领域内的专家，所有软件行为都是可预期的，软件测试就是例行公事再确认一下。
早期的计算机工作者的确是这样的，他们都是领域内的专家，根据代码能够准确指出程序的行为。如果说他们是上帝，程序就是他们完美的伊甸园，什么都在计划之内。
然而时过境迁，现在的软件团队里面不可能所有人都是专家，也不是所有领域都有专家。除了火箭控制之类要求高可靠性的系统，大多数的软件都是由非专家编写出来的。所以程序员不一定知道哪里有死锁和饿死，不一定知道哪里有资源泄漏，不一定知道哪里有兼容性问题。他们可能还是上帝，只是做出来的不再是伊甸园了。以今天软件系统的复杂度而言，每个团队都维护一大堆上帝成本太高。
因此，程序员很多对他们作品的假设，未经证实之前不一定正确：
“这个列表会列出所有结果” -- 没有或者很多结果的时候呢？
“这个列表不会有重复的对象” -- 删除A之后添加A，且异步的删除失败的时候呢？
“这个列表的输出不会错的“ -- 多个数据源同时对其输入大量的数据呢？
这个结论会导致软件测试的一个可怕悖论：测试用例不少是来自程序员的假设，不正确的假设使得这些用例可能是不正确或无意义的。
这正是很多测试书籍介绍的边界、性能、压力、可扩展和安全测试的由来：正是需要检验那些假设的真实性。
但是事情还没完。
测试员也不是上帝，他们做出来的也不是伊甸园。
如果程序员的产出是代码和bug修复，测试员的产出就是测试用例和bug报告。
我们刚才忽略了bug报告。
bug报告有两个最重要的部分，重现步骤和错误细节。而其中出现的不正确的假设和推理主要有三种：

   1.  如果A在B之前出现，A是B的原因
   2. 如果A和B同时出现，A与B有因果关系
   3. 如果A被证实是B的原因，A是B的唯一原因

我用一个几周前碰到的例子来说明不正确的假设和推理的影响。

   1. 用户报告说产品弹出了空白的窗口，于是登记一个bug，还没有重现步骤
   2. 到用户的机器（繁体中文Vista）上证实了某个插件开启和关闭后，这个bug出现和消失（事情很顺利吧），于是添加重现步骤：“繁体中文Vista，安装某插件，出现空白窗口；卸载或关闭插件后症状消失“
   3. 程序员说肯定是浏览器插件改变了某处打开窗口的行为，代码没有料到这一点，测试员觉得有道理
   4. 回到办公室在自己的Vista和XP上试图重现，失败，更坚定是繁体中文Vista的问题
   5. 于是在繁体中文Vista上试图重现，失败，傻眼，只好修改重现步骤，暂时去掉繁体中文Vista的字样
   6. 呼吁大家帮忙重现
   7. 好消息传来，在一台Vista Business Edition上得以重现，于是添加到重现步骤中
   8. 在另外两台Business Edition上尝试，一个能重现，另一个不能，又傻眼了
   9. 怀疑是CPU或内存负荷造成的竞争条件，发现不能重现的机器和第一台能重现的一样，继续傻眼
  10. 连Windows 2003 Server都能重现，无限傻眼
  11. 可能是插件版本的问题，发现所有地方都是安装最新的版本
  12. 程序员修复之后，所有地方都不重现了，不过被告知离发布时间太短，这个修复不添加到发布版本里了，改为写在已知问题里面
  13. 开始仔细检查系统、浏览器和插件的设置

好了，到现在为止13还在进行中。但是请留意几个细节：
12证实了3，如果到此为止，从4到11都不做，那么在用户数不清的平台组合下重现步骤就是个大笑话。错误假设3是一个危险的诱惑。
4、7、10都是有可能停止实验的地方，那样13就永远不会启动，离真正原因更是遥不可及。错误假设1和2都是危险的诱惑。
程序员不一定能做到3，那么在13之前得到的重现步骤都是在把程序员引入歧途。即使修复了，由于不了解真正原因，13所发现的特殊设置可能使这个bug沉渣泛起。
可见，反映真相的全部是重现步骤的灵魂，因为程序员构建出来的世界是未知的，我们需要知道哪些假设还是正确的，哪些已经不正确了。
那么反映全部真相就是测试员要做的全部吗？
请注意还有错误细节。这通常是帮助程序员定位错误的数据，一般是反映出错时系统各方面的状态。
很多软件系统在开发阶段都会输出log，测试员也被要求在bug报告里面提供log。
只是我见过的一个bug报告，把几乎所有东西，包括几百MB的log和crash dump都放进去。程序员看了半天愣是找不着北。后来的事实证明，只要再多做一个改变了条件的实验，问题根源就马上出现在一行log里面了（也就是说，程序员也知道这里要检验一些假设，关键是测试员要接触到）。未经筛选的大量信息等于没有信息。运用逻辑推理定位根本原因是探索未知世界的重要工作。测试员的懒惰浪费了程序员的大量时间。这如同罗列大量的数据，却不告诉读者要反映的意思蕴含在哪里一样。
所以，你会发现，软件测试其实和科研实验，不仅仅是物理，甚至与化学、生物、医学实验，有着高度的相似性。
有人会问，如果每个假设都要验证，测试工作量岂不是很大？
其实，这正是计算机工业发展的标志，从汇编语言、操作系统、高级程序语言到各种框架、架构，都是在使软件开发更专注于有价值的部分，而不用关注早已验证的部分。你不用关心内核/用户态转换的假设，因为有system API的承诺；你不用关心其他模块的实现假设，因为有对接口协议的承诺。但是很多来源于这个软件本身的假设，并没有经过验证，这些才是我们需要关注的假设。
而正是这些假设来源于软件本身，测试员需要从外到内全面了解整个软件，才能找到全部假设并一一加以验证。这同时也是白箱测试和黑箱测试并存的原因：只观察软件外部，不能检验内部实现的假设；只观察软件实现，不能检验用户交互的假设。
最后，有一个相通的问题，如果现有高考制度的弊端看成是一个bug，你又可以改变不同条件检验你的设想，你将通过哪些实验找出根源所在？
我在《读者》2007年第12期看到一篇文章，它所列出来的高考制度相关因素之多，会令你觉得需要做的实验实在是一个天文数字。这会令你觉得，从事计算机行业比起从事行政管理，实在是要简单不少。



通往测试架构师之路(1)：那些家伙在干什么？ 
    Omomo在公司呆了有几个年头了。在测试技术方面的技能长进了不少，又能享受写代码的乐趣，同事们经常交流对软件测试技术的见解，也在项目中实现一些创新的测试技术和基于自己的想法设计好的测试框架，每天过的很开心。随着对测试这个职业的了解越来越深，对微软测试技术的掌握越来越多，慢慢地，人就开始对那些测试“大牛”在做什么感兴趣了。他们就是那些在公司内部挂着“测试架构师”头衔的一小撮人。They are Test Architects。
什么？你的公司还有测试架构师这么一说？呵呵，好像很多人都会这么问吧。大家听架构师听多了。比如我们头比尔的头衔就是“微软首席软件架构师”。一般来说，说到架构师，人们想到的都是“软件设计架构师”，那些设计整个产品架构，决定各模块如何协调工作，决定采用何开发平台的大师（对不起，可能每个人对大师的定义不同，如果你心目里只有Lippman, Stroustrup, Anders这样的人才能称为大师，那么原谅我的定义，我的大师就是那些杰迪武士里的Master，他们中有些人是Yoda/Anakin这样实力超人的，但也有一些普通的我们每天都可以从他们身上学到不少东西的人，我愿意把后者也叫大师。）。那么“测试架构师”，他们是些什么人?他们凭什么拿着和设计架构师一样的薪水?我们怎样成长为测试架构师呢？我也是带着这样的一个个问题，在雷德蒙总部有幸遇到一个测试架构师艾德的。那天，大晴，有利西方。
测试架构师，这里我更多的是讨论这个角色的职责，而不是这个头衔本身。所以也许你已经扮演了这个角色，但没有这个头衔。但这不妨碍我们讨论测试架构师在做什么。
如果你是一名测试架构师，那意味着你有很多事情可以做，虽然你不一定都做：开发和设计测试框架测试库；纵横全局的考虑产品的功能，设计复杂的测试系统；负责研发某一项特定的测试技术；为你的公司考虑如何提高测试效率；但总的来说，我们可以这样描述：测试架构师领导公司测试技术的发展和测试策略上的方向。区别一个测试架构师和普通测试工程师的特质是：他关注的是一个功能模块，一条产品线，还是整个公司的测试部门的问题。甚至对于一些更加资深的测试架构师，他们已经不再局限于产品当前版本的测试，他们可以前瞻性的考虑未来的版本的测试策略和技术。
测试架构师的角色可以和设计架构师的角色互相比较着看，设计架构师，计划/设计一个产品，关注着产品的研发过程。同样的，测试架构师他们计划/设计测试平台，关注着产品的测试过程。（废话而且拗口是吗？：））但他们倒是有一个让我们IT民工羡慕的共同特点，他们更多的是提供咨询服务，并不亲身去帮你写完每一行代码。他们的工资不由他们敲多少字决定。呵呵。测试架构师具备测试技术测试方法学上雄厚的知识，不仅仅是公司内部的知识，也包括公司外部的知识。所以他们具备实力给那些测试经理们提供“咨询”服务，告诉他们，什么样的测试技术什么样的测试平台会符合公司要测得产品，什么样的软件流程可以更好的保证软件质量。那有人会自然想到，这不是测试经理的事情吗？不然，测试经理，我们都是知道，人一到了“经理”这个位置，杂事就多了，员工加薪，员工福利，办公室装修，测试实验室购买新机器。什么事情都可能找到测试经理头上。测试经理的主要责任，应该是领导和培养一个优秀的测试团队。所以领导和培养是他的重点。对于剩下得测试技术测试策略上的任务，这时候他身边的测试架构师就起到了辅佐的作用。我觉得，这样的一个解释可以让很多测试经理如释重负，把技术和管理的重担全部依赖在测试经理的身上，有点不近人情了。呵呵。
测试架构师不仅仅是需要影响到公司内的测试机构测试社区，还需要影响开发机构甚至市场部门，好的测试架构师，可以从保证质量的角度，对产品的研发销售各个方面施加深远而正确的影响，也吸收来自各个部门的建议，最终提高整体软件质量。所以说一个优秀的测试架构师，也可以是一个不错的设计架构师，不错的用户需求分析师。因为软件质量保证是一个贯穿需求分析、设计、测试整个软件项目的过程。做好测试架构师，就要求你能够驾驭软件项目各个阶段。所以对开发和其他部门的熟悉是必不可少的
前面说了这么多软件测试架构师“做”什么，最后我们谈谈哪些是他们“不做”的：
1，           他们不是项目经理，虽然前面说了很多软件测试架构师对项目的各个方面施加影响，但是他们不是项目经理。一个纯粹的项目经理要考虑的事情还有很多很多，如果一个测试架构师最后扮演了项目经理的角色，那么对项目还是对测试架构师，都是不益的。
2，           测试架构师不是一个水到渠成的头衔，不是你做了很多年测试，对产品很了解，就自然成为了测试架构师。你需要有足够的技术前瞻能力和对公司内的影响力以达到对产品测试策略和技术方向提供咨询。
3，           不只是一个纯粹的软件测试技术编程高手，一个测试架构师的存在是为了解决实际项目产品中的测试问题，并不是一个纯粹的测试技术编程爱好者。一个热衷于单元测试开发框架的人，可以是一个编程好手，但未必是公司需要的测试架构师。一个架构师，对技术和测试策略测试方法学都能在解决实际问题上运用娴熟。
 
Over Today！
文中我有提到我遇到一个测试架构师艾德，我和他面对面谈了很多有关测试架构师的有趣话题。我打算在接下来的连载中告诉你，未来我们还要谈测试架构师有哪些素质，测试架构师怎样通过影响他人达成他的目标等等，请继续关注-通往测试架构师之路。:)



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

质量衡量标准 (标尺)

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

复杂领域产品测试:

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

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

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

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

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

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

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

测试集优选:

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

项目计划安排:

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

测试对项目的影响:

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

测试自动化:

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

集成测试:

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

其他普遍的难题:

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



行百里者半九十：浅谈发布测试 
　　你知道哥德堡号是怎样沉没的吗？07年第8期的《读者》上有篇文章引起了我的兴趣。哥德堡号是18世纪瑞典人的希望：他们需要从海上贸易来充实因为战争而濒临枯竭的国库。建造哥德堡号动用了瑞典当时15%的国内生产总值，船坚炮利不在话下。然而在最后一次返航途中离码头900米的地方撞上了当地人再熟悉不过的一块暗礁，在欢迎人群的注视下满载着从中国运来的瓷器、茶叶和丝绸沉入海底。

你的开发工作中也会有平时再熟悉不过的暗礁：

你不会在工作目录少放一两个文件，特别是开发了半年后；

你不会在调试上个星期的版本的时候，心里以为是最新的版本；

你不会把产品的名字都写错...

是的，谁都不会撞上这样的暗礁。不过考虑一下临交货前一天可能发生的事情：

发现一个小bug，顺手改了一把；

bug都改完了，开始兴冲冲的写下一个版本；

客户发个email来说某些显眼处的标题要改，他们也很抱歉，说是上头今天异想天开...

如果这时候就打包刻盘，明天交货时会发生哪些事情呢？

出现了一些以前出现过的bug，但是dev说早就改好了；

有些问题在自己的环境里面总没法复现出来，客户那边100%出现，直到有一天发现少了个文件；

被问到“为什么这里说的和那里不一致呢？”...

在把发布测试当一回事来抓之前，客户拿到手的产品可能会有这些问题：

产品安装/上线之后不是多了就是少了些东西；

好像是调试版本；

文档和产品不一致；

有些承诺修改过的bug还在...

所有这一切，都源于开发人员和客户关注角度的差别。作为测试人员，应该站在客户的位置上，可惜他们还是开发团队的一部分，往往还是以开发人员的眼光去看bug。发布阶段的bug，拥有许多不一样的地方：

这不是/这里没有客户需要的东西；

这不影响使用，但影响客户的生意（比如把人家的logo都搞错了）；

你会用，但客户不会用；

在你的环境好用，但和客户环境不太兼容；

触了客户的霉头（别笑，你见过主版本号是13的产品吗？）...

成熟的软件工业会进行一系列的发布阶段测试：

安全漏洞测试；

各个语言版本的界面内容（文本，图片，多媒体资源等），用户文档，发布说明的复核，确保没有违反法律和地缘政治文化（想想十字军东征的画面被放在阿拉伯文版里面）；

数字签名校验；

病毒扫描（想想熊猫烧香是怎样传播的）；

再一次基本功能测试。

噢，忘了说为什么哥德堡号撞上暗礁的根本原因：航海多年的水手看见陆地和欢迎人群，兴奋起来所以提早在船上开庆祝party；舵手的位置在二楼，需要甲板上的人指示方向；本来每条船上都有当地向导作为领航员，但是他去参加party了。




什么时候开始测试？

很久以前看到的一则笑话，有个小bug，不过意思我倒是弄懂了。大意是爱迪生耳朵不好使（实际上是一只耳朵不好使而不是两只），听不到电话铃声；好钻研的朋友为他发明了一套闪光装置，来电话的时候除了铃响还有闪光；问题是就算爱迪生知道有来电，拿起话筒的时候还是什么都听不到。

人们时常会犯类似的错误，付出的代价还不小，事实上在动手之前就应该找到这些问题。软件测试也是一样。千里之行，始于足下。计划和设计阶段的测试，才是测试工作的第一步。人们通常认为的编码结束才开始的测试，已经太晚了。

计划和设计阶段程序员和项目经理分别会非常关心两件事情：技术上如何实现，能否引起客户的使用意欲。那么测试人员会关心什么事情呢？

我的答案是：假设上述事情都能按计划完成，还有什么事情会让产品失败？

你可能会想，还能有什么事情？

我先讲一个别人告诉我的故事：

有个产品是识别纸上指定图案的，技术上没法100％场合都能识别，但还在客户容许范围之内，而且客户也的确相当欢迎这项技术。不过原型出来之后客户反馈相当差，很多人试了几下就不用了。究其原因，一旦识别算法觉得无法识别，比如因为光线、角度等原因，就会弹出一个对话框说识别失败。想象客户被弹了两次之后，还会充满信心的认为这个产品一定能用吗？没有这么自虐的吧？

就是有这么自虐的。想想是谁说没问题啦可以见人的

解决方案也挺简单，只要改用一个温和一点的方式表达“难以识别”，而不是用弹对话框这种方式来打断用户调整光线角度的过程就可以了。

现在你同意还是有一些事情会让产品失败的吧。我们来看看都有哪些。

客户表达的需求，开发团队所理解的需求，以及客户真正使用时的需求，有重大的差别；

完成产品所依赖的条件中，有些现在就知道无法或难以具备；

有导致无法或难以按计划完成的因素。

测试人员在计划和设计阶段的任务之一，就是尽可能找到这些问题。

你可能想，明显的问题谁都看得到，还用得着专人检查吗？事实上大问题不一定明显。我下面要讲的例子就是一个设计阶段成功避免的大问题。

有个设备用于拍摄参加小型会议的所有人，放在桌子中间。用户普遍使用笔记本电脑并通过与设备相连的软件看到网络另一端的与会者的视频。在进行用户场景（user scenario）讨论时测试人员发现了一个问题：笔记本电脑的屏幕把用户的脸挡住了。所以最终定型的设备比最初调高了5厘米。

面对一堆文字描述的测试人员如果不能发现这个问题，后果将会是：大量设备召回，或者流传一个笑话“开会时记得带本厚书”。

你不会愿意成为这种笑话的主角的。






如何对软件质量进行评估？
一、软件质量的有关概念

　　软件质量是“软件产品具有满足规定的或隐含要求能力要求有关的特征与特征总和”。根据软件质量国家标准GB-T8566--2001G，软件质量评估通常从对软件质量框架的分析开始。

　　1.1 软件质量框架模型

　　软件质量框架是一个“质量特征—质量子特征—度量因子”的三层结构模型。

　　在这个框架模型中，上层是面向管理的质量特征，每一个质量特征是用以描述和评价软件质量的一组属性，代表软件质量的一个方面。软件质量不仅从该软件外部表现出来的特征来确定，而且必须从其内部所具有的特征来确定。

　　第二层的质量子特征是上层质量特征的细化，一个特定的子特征可以对应若干个质量特征。软件质量子特征是管理人员和技术人员关于软件质量问题的通讯渠道。

　　最下面一层是软件质量度量因子（包括各种参数），用来度量质量特征。定量化的度量因子可以直接测量或统计得到，为最终得到软件质量子特征值和特征值提供依据。

　　1.2 软件质量特征

　　按照软件质量国家标准GB-T8566--2001G，软件质量可以用下列特征来评价：

　　a. 功能特征：与一组功能及其指定性质有关的一组属性，这里的功能是满足明确或隐含的需求的那些功能。

　　b. 可靠特征：在规定的一段时间和条件下，与软件维持其性能水平的能力有关的一组属性。

　　c. 易用特征：由一组规定或潜在的用户为使用软件所需作的努力和所作的评价有关的一组属性。

　　d. 效率特征：与在规定条件下软件的性能水平与所使用资源量之间关系有关的一组属性。

　　e. 可维护特征：与进行指定的修改所需的努力有关的一组属性。

　　f. 可移植特征：与软件从一个环境转移到另一个环境的能力有关的一组属性。

　　其中每一个质量特征都分别与若干子特征相对应。

　　二、评估指标的选取原则

　　选择合适的指标体系并使其量化是软件测试与评估的关键。评估指标可以分为定性指标和定量指标两种。理论上讲，为了能够科学客观地反映软件的质量特征，应该尽量选择定量指标。但是对于大多数软件来说，并不是所有的质量特征都可以用定量指标进行描述，所以不可避免地要采用一定的定性指标。

　　在选取评估指标时，应该把握如下原则：

　　a. 针对性

　　即不同于一般软件系统，能够反映评估软件的本质特征，具体表现就是功能性与高可靠性。

　　b. 可测性

　　即能够定量表示，可以通过数学计算、平台测试、经验统计等方法得到具体数据。

　　c. 简明性

　　即易于被各方理解和接受。

　　d. 完备性

　　即选择的指标应覆盖分析目标所涉及的范围。

　　e. 客观性

　　即客观反映软件本质特征，不能因人而异。

　　应该注意的是，选择的评估指标不是越多越好，关键在于指标在评估中所起的作用的大小。如果评估时指标太多，不仅增加结果的复杂性，有时甚至会影响评估的客观性。指标的确定一般是采用自顶向下的方法，逐层分解，并且需要在动态过程中反复综合平衡。

　　三、软件质量评估指标体系

　　通常，我们在软件的测试与评估时，主要侧重于功能特征、可靠特征、易用特征和效率特征等几个方面。在评价活动的具体实施中，应该把被评估软件的研制任务书作为主要依据，采用自顶向下逐层分解的方法，并参照有关国家软件质量标准。

　　3.1 功能性指标

　　功能性是软件最重要的质量特征之一，可以细化成完备性和正确性。目前对软件的功能性评价主要采用定性评价方法。

　　a. 完备性

　　完备性是与软件功能完整、齐全有关的软件属性。如果软件实际完成的功能少于或不符合研制任务书所规定的明确或隐含的那些功能，则不能说该软件的功能是完备的。

　　b. 正确性

　　正确性是与能否得到正确或相符的结果或效果有关的软件属性。软件的正确性在很大程度上与软件模块的工程模型（直接影响辅助计算的精度与辅助决策方案的优劣）和软件编制人员的编程水平有关。

　　对这两个子特征的评价依据主要是软件功能性测试的结果，评价标准则是软件实际运行中所表现的功能与规定功能的符合程度。在软件的研制任务书中，明确规定了该软件应该完成的功能，如信息管理、提供辅助决策方案、辅助办公和资源更新等。那么即将进行验收测试的软件就应该具备这些明确或隐含的功能。

　　目前，对于软件的功能性测试主要针对每种功能设计若干典型测试用例，软件测试过程中运行测试用例，然后将得到的结果与已知标准答案进行比较。所以，测试用例集的全面性、典型性和权威性是功能性评价的关键。



3.2 可靠性指标

　　根据相关的软件测试与评估要求，可靠性可以细化为成熟性、稳定性、易恢复性等。对于软件的可靠性评价主要采用定量评价方法。即选择合适的可靠性度量因子（可靠性参数），然后分析可靠性数据而得到参数具体值，最后进行评价。

　　经过对软件可靠性细化分解并参照研制任务书，可以得到软件的可靠性度量因子（可靠性参数）。

　　a. 可用度

　　可用度指软件运行后在任一随机时刻需要执行规定任务或完成规定功能时，软件处于可使用状态的概率。可用度是对应用软件可靠性的综合（即综合各种运行环境以及完成各种任务和功能）度量。

　　b. 初期故障率

　　初期故障率指软件在初期故障期（一般以软件交付给用户后的三个月内为初期故障期）内单位时间的故障数。一般以每100小时的故障数为单位。可以用它来评价交付使用的软件质量与预测什么时候软件可靠性基本稳定。初期故障率的大小取决于软件设计水平、检查项目数、软件规模、软件调试彻底与否等因素。

　　c. 偶然故障率

　　指软件在偶然故障期（一般以软件交付给用户后的四个月以后为偶然故障期）内单位时间的故障数。一般以每1000小时的故障数为单位，它反映了软件处于稳定状态下的质量。

　　d. 平均失效前时间（MTTF）

　　指软件在失效前正常工作的平均统计时间。

　　e. 平均失效间隔时间（MTBF）

　　指软件在相继两次失效之间正常工作的平均统计时间。在实际使用时，MTBF通常是指当n很大时，系统第n次失效与第n+1次失效之间的平均统计时间。对于失效率为常数和系统恢复正常时间很短的情况下，MTBF与MTTF几乎是相等的。

　　国外一般民用软件的MTBF大体在1000小时左右。对于可靠性要求高的软件，则要求在1000~10000小时之间。

　　f. 缺陷密度（FD）

　　指软件单位源代码中隐藏的缺陷数量。通常以每千行无注解源代码为一个单位。一般情况下，可以根据同类软件系统的早期版本估计FD的具体值。如果没有早期版本信息，也可以按照通常的统计结果来估计。“典型的统计表明，在开发阶段，平均每千行源代码有50~60个缺陷，交付后平均每千行源代码有 15~18个缺陷”。

　　g. 平均失效恢复时间（MTTR）

　　指软件失效后恢复正常工作所需的平均统计时间。对于软件，其失效恢复时间为排除故障或系统重新启动所用的时间，而不是对软件本身进行修改的时间（因软件已经固化在机器内，修改软件势必涉及重新固化问题，而这个过程的时间是无法确定的）。

　　3.3 易用性指标

　　易用性可以细化为易理解性、易学习性和易操作性等。这三个特征主要是针对用户而言的。对软件的易用性评价主要采用定性评价方法。

　　a. 易理解性

　　易理解性是与用户认识软件的逻辑概念及其应用范围所花的努力有关的软件属性。该特征要求软件研制过程中形成的所有文档语言简练、前后一致、易于理解以及语句无歧义。

　　b. 易学习性

　　易学习性是与用户为学习软件应用（例如运行控制、输入、输出）所花的努力有关的软件属性。该特征要求研制方提供的用户文档（主要是《计算机系统操作员手册》、《软件用户手册》和《软件程序员手册》）内容详细、结构清晰以及语言准确。

　　c. 易操作性

　　易操作性是与用户为操作和运行控制所花的努力有关的软件属性。该特征要求软件的人机界面友好、界面设计科学合理以及操作简单等。

　　3.4 效率特征指标

　　效率特征可以细化成时间特征和资源特征。对软件的效率特征评价采用定量方法。效率特征分解如图2所示。

　　a. 输出结果更新周期

　　输出结果更新周期是软件相邻两次输出结果的间隔时间。为了整个系统能够协调工作，软件的输出结果更新周期应该与系统的信息更新周期相同。

　　b. 处理时间

　　处理时间是软件完成某项功能（辅助计算或辅助决策）所用的处理时间（注意：不应包含人机交互的时间）。

　　c. 吞吐率

　　吞吐率是单位时间软件的信息处理能力（即各种目标的处理批数）。未来的社会情况复杂、信息众多，软件必须具有处理海量数据的能力。吞吐率就是体现该能力的参数。随着信息的泛滥，要求软件的吞吐率应该达到数百批。

　　d. 代码规模

　　代码规模是软件源程序的行数（不包括注释），属于软件的静态属性。软件的代码规模过大不仅要占用过多的硬盘存储空间，而且显得程序不简洁、结构不清晰，容易存在缺陷。

　　因为这些参数属于软件的内部表现，所以需要用专门的测试工具和特殊的途径才可以获得。将测试数据与研制任务书中的指标进行比较，得到的结果可以作为效率特征评价的依据。

　　四、结束语

　　随着计算机技术、数据融合技术、网络技术和通信技术的飞速发展，对软件功能提出的要求也越来越高，如何评估软件质量已成为一个迫切需要解决的课题。选择合适的指标体系并使其量化是做好软件质量评估的关键。当然，由于软件的评估具有其特有的规范和要求，其评估指标涉及面广、不确定性因素较多、量化困难，至今还没有统一的标准。

　　我们相信，通过建立科学合理的软件质量评估指标体系，充分考虑到软件的特殊性，借鉴其他学科的质量评估理论，是可以全面真实客观地评估软件质量的。