软件测试常见问题——（一）基础知识部分

基础知识常见问题

1、 如何描述一个缺陷？

看到这个问题，也许有些读者会觉得可笑：哪个测试人员不会描述缺陷？但是现实中却真的存在很多测试人员提交的缺陷需要向开发人员进行解释或者演示后，才能让人明白他真正要表达的意思。实际上，是否能够清晰地描述软件缺陷，绝对体现着一个测试人员的能力水平高低。

除了极个别的不能重现的缺陷外，一个软件缺陷至少应该描述清楚三方面的内容：缺陷概述、详细内容、重新步骤。

缺陷概述——用一到两句话详细地描述缺陷的症状，使管理人员一下子就能看明白大概是什么问题。

详细内容——详细地描述缺陷的症状，可以发表自己对该缺陷的一些意见。详细内容主要供程序员进行分析。

重新步骤——详细描述如何在系统中重新缺陷，这是非常重要的一项内容，如果重新步骤描述的非常清晰，将大大加快开发人员修改缺陷的速度。

通常情况下，很多缺陷管理软件把“详细内容”与“重新步骤”进行了合并，即只有一个文本输入框供测试人员录入信息，这就导致很多测试人员疏忽了去描述“重新步骤”。

此外其他诸如测试版本、测试环境、发现日期等辅助信息也应该认真录入。

2、 缺陷是谁“生产”的？

这是一个“老生常谈”的问题。尤其在追究一些质量问题责任的时候。常常听测试人员抱怨：“这些模块简直是垃圾！不值得测试！浪费我的时间！”，开发人员则抱怨：“重要的问题发现不了，却成天盯着那些无关痛痒的小问题，还不如自己去测试！”。

不符合用户要求的都可以称之为缺陷，因此缺陷的来源主要有两类：一类是没有正确理解用户需求，由系统需求或者分析人员设计出来的缺陷，这类缺陷主要由设计人员“生产”；另外一类是程序开发人员没有按照设计要求进行开发或者编写的代码存在错误而引起的缺陷，这类缺陷由程序开发人员“生产”。

对于那些开发流程不规范的组织，通常开发人员会包办测试前的大部分工作。在这种环境下，几乎没有什么设计文档，软件开发主要按照程序设计人员的想像来进行，这个时候的缺陷则主要由开发人员“生产”。

图14-1详细的描述了软件设计与用户需求的巨大差异，通过图14-1也很容易想到为什么现实中会有大量的应用软件不能更好地帮助用户实现预期目标的真正原因。

测试人员不是缺陷的“生产”者，因为测试人员没有写过一行代码，这是否意味着测试人员可以在一旁“幸灾乐祸呢”？事实恰好相反，测试人员与缺陷关系更加密切，他们是“缺陷的缺陷”的制造者。所谓“缺陷的缺陷”，主要指测试人员提交的“不是缺陷”的缺陷，即测试人员没有正确理解需求，从而提交了根本“不是缺陷”的缺陷，这种缺陷也是测试人员经常受到指责的重要原因。

关于上面的抱怨，测试和开发双方都需要摆正心态：因为实际双方都在不停的“生产”着缺陷，只是创造的方式不同罢了。

<shapetype id="_x0000_t75" stroked="f" filled="f" path="m@4@5l@4@11@9@11@9@5xe" o:preferrelative="t" o:spt="75" coordsize="21600,21600"><stroke joinstyle="miter"></stroke><formulas><f eqn="if lineDrawn pixelLineWidth 0"></f><f eqn="sum @0 1 0"></f><f eqn="sum 0 0 @1"></f><f eqn="prod @2 1 2"></f><f eqn="prod @3 21600 pixelWidth"></f><f eqn="prod @3 21600 pixelHeight"></f><f eqn="sum @0 0 1"></f><f eqn="prod @6 1 2"></f><f eqn="prod @7 21600 pixelWidth"></f><f eqn="sum @8 21600 0"></f><f eqn="prod @7 21600 pixelHeight"></f><f eqn="sum @10 21600 0"></f></formulas><path o:connecttype="rect" gradientshapeok="t" o:extrusionok="f"></path><lock aspectratio="t" v:ext="edit"></lock></shapetype><shape id="_x0000_i1025" style="WIDTH: 423pt; HEIGHT: 325.5pt" type="#_x0000_t75"><imagedata o:title="14-1" src="file:///D:/DOCUME~1/CHENSH~1.CHE/LOCALS~1/Temp/msoclip1/01/clip_image001.jpg"></imagedata></shape>

图 14-1开发出的软件与用户实际需求的差异

3、 缺陷产生的原因是什么？

在上个问题中，已经介绍了设计人员、开发人员、测试人员都会“生产”软件缺陷。在实际工作中，缺陷产生的方式更是层出不穷，原因也是多种多样。例如开发人员去接杯水，碰巧和另外一个接水的同事聊了几句，结果回到工位时忘记了要在某个判断语句追加此前已经想好的一个判断条件，这无疑会产生一个缺陷。因此很难一下子把缺陷产生的原因全部陈列出来，下面只是一些引起缺陷的典型原因：

（1）开发人员不太了解需求，不清楚应该“做什么”和“不做什么”，常常做不合需求的事情，因此产生了缺陷；

（2）软件系统越来越复杂，开发人员不太可能精通所有的技术。如果不能正确地掌握新的技术或者知识，可能会产生缺陷；

（3）技术文档普遍编写的很差，甚至文档本身就有缺陷，导致使用者产生更多的缺陷；

（4）软件需求、设计报告、程序经常发生变更，每次变更都可能产生新的缺陷；

（5）任何人在编程时都可能犯错误，导致程序中有缺陷；

（6）技术人员常处于进度的压力之下，不能静心思考也很容易产生缺陷，尤其是在Deadline临近之际，频繁的加班是开发人员疲于应付进度；

（7）很多开发人员过于自信，喜欢说“没问题”，因此对于一些代码不进行认真的调试，这也是一些缺陷产生的原因；

（8）频繁的拷贝代码也会把缺陷随之复制到新的程序中，尤其是复制其它团队成员的代码更容易使一些缺陷隐藏在程序中。

4、 软件的质量应该由什么人来负责？

对于一些开发管理混乱或者测试刚刚起步的组织，产品质量一发生问题，习惯上会归咎于测试小组，认为测试人员没有测试好产品，所以才产生了那么多的缺陷。

对于开发管理规范一些或者测试体系已经建立一定时间的组织，如果客户投诉产品质量问题，则往往开发人员与测试人员会一起接受处罚。这种处理方式多少会让测试人员心理稍稍平衡一些。

追根溯源，软件发生质量问题实际是项目管理不规范引起的。因此，如果要追究责任的话，软件质量问题的责任应该由整个团队来承担。只有提高整个团队的开发水平，才能提高质量。

此外，也应该认识到软件发现问题是正常的现象，很少有软件实现了零缺陷。做为公司领导者，应该具体问题具体分析，不要老是考虑如何惩罚自己的成员。

5、 测试能保证质量吗？

在软件质量方面，目前多数IT企业主要采取三种措施：技术评审、过程检查、软件测试。

技术评审：技术评审最初是由IBM公司为了提高软件质量和提高程序员工作效率而采用的，主要指对项目计划、软件需求、系统设计等文档进行有效评审的过程。技术评审可以由专家团队组成，也可以由组织内部人员组成，它可以尽量避免设计人员在某些方面发生“闭门造车”的情形。

通过技术评审，可以尽早地发现工作成果中的缺陷，并帮助开发人员及时消除缺陷，从而有效地提高产品的质量。

过程检查：属于质量工程师（QA）的工作范畴，主要检查软件项目的“工作过程和工作成果”是否符合已经制定的相关规范。在项目执行过程中，质量保证人员要不断的按照项目计划对项目进行有效的监督和检查。

通过过程检查，可以找出明显不符合规范的工作过程或者工作成果，及时纠正开发中的错误。

因此，软件测试只是保证质量的最常用手段，仅仅通过测试是不能够保证质量的，还要辅以技术评审、过程检查等手段。

6、 测试人员是否需要开发技能？

在很多测试网站的论坛上，这个问题都是津津乐道的热门话题。而究其根源，主要是因为很多测试人员做不了开发才来做测试，于是其中的很多人便怀着一些“胆怯”心理，与同行反复探讨这个问题，期望其他人能够肯定 “即使不会开发也能做好测试”的观点，以便在心理上得到一些安慰。

是否需要开发技能与测试人员从事的测试工作种类有极大关系，相信很多人都听过微软曾经聘用一名家庭主妇来测试Windows操作系统的故事。实际上，如果从事单元测试、集成测试等较接近程序代码的工作，无疑需要开发技能，这类工作对测试人员开发技能的要求甚至会超过程序员；而从事基本的界面测试、用户功能测试，不会开发不会有大的影响。

但是，原则上还是建议测试人员最好具备一定的开发能力，而且是开发能力越强越好，开发技能对测试工作可以说是“百利而无一害”，例如可以更容易避免报告重复的缺陷、对缺陷原因进行更准确的定位等等。同时，由于国内多数公司对测试人员没有分类，要想得到更多的发展机会，也应该学会开发，便于从事各种类型的测试工作，除非只从事那些远离代码的测试工作。

此外，掌握一门开发语言后，进行测试的时候可以站在程序开发的角度进行思考，而且知道程序如何编写，就更容易发现问题。

7、 测试的目的是什么？

测试的目的是为了发现尽可能多的缺陷，这个观念很容易让人接受，但是却很难落实到实际工作中，因为测试的目的常常被定位为“证明软件没有问题”。软件质量是否优良在投产后才能有所体现。

正确理解测试的目的十分重要。如果认为测试的目的是为了说明程序中没有缺陷，那么测试人员就会向这个目标靠拢，因而下意识地设计很多不易暴露错误的测试示例，这些测试用例恰恰证明软件实现了预期功能，这样的测试是不真实的。成功的测试在于发现了迄今尚未发现的缺陷，测试人员的职责是设计这样的测试用例——它能有效地揭示潜伏在软件里的缺陷。

8、 一个软件产品测试结束时没有发现任何新的缺陷，这样的软件质量一定好吗？

测试只能证明缺陷存在，不能证明缺陷不存在。而彻底的、全面的测试又难以成为现实，现实中要考虑时间、费用等限制，不允许无休止地测试。通常的测试结束，只是满足一定条件下的测试结束，最后的“测试”还是交给了用户。

因此，即使测试结束了，质量也不一定好。例如测试小组在时间紧迫的情况下，只测试了核心模块，这样的软件系统质量一般不会好。

9、 测试中的80-20原则是什么？

测试中的80-20原则是说一般情况下，在分析、设计、实现阶段的复审和测试工作能够发现和避免80%的Bug，而系统测试又能找出其余Bug中的80%，最后的5%的Bug可能只有在用户的大范围、长时间使用后才会暴露出来。因为测试只能够保证尽可能多地发现错误，无法保证能够发现所有的错误。还有就是一般情况下80％的缺陷聚集在20％的关键核心业务模块中。

10、 测试到Zero-bug是测试工作的目标和原则吗？

通常对于相对复杂的产品或系统来说，Zero-bug是一种理想，Good-enough是我们的原则。

Good-enough原则就是一种权衡投入/产出比的原则：不充分的测试是不负责任的；过分的测试是一种资源的浪费，同样也是一种不负责任的表现。执行测试工作的关键在于：如何界定什么样的测试是不充分的，什么样的测试是过分的。解决这一问题的通常方法是制定最低测试通过标准和测试内容，然后具体问题具体分析。

11、 通常测试工作要达到什么目标？

通常情况下，测试至少要达到下列目标：

（1）确保产品完成了它所承诺或公布的功能。这一目标就是软件要符合需求，开发出的软件应该达到所有功能都有明确的书面说明------在某种意义上与ISO9001是同一种思想，测试的首要目的就是保证所有预定功能是存在并且经过规范的测试。

当然书面文档的不健全甚至不正确会导致测试效率低下、测试目标不明确和测试范围不充分，进而导致最终测试的作用不能充分发挥、测试效果不理想。因此具体问题一定要具体分析，一个好的测试负责人尽量来弥补这些文档缺陷。

（2）确保产品满足性能和效率的要求。现在的用户对软件的性能方面的要求越来越高，使用起来系统运行效率低(性能低)、或用户界面不友好、用户操作不方便(效率低)的产品市场空间肯定会越来越小。因此通过测试改善性能也是测试工作一个目标。

实际上用户最关心的不是软件的技术有多先进、功能有多强大，而是能从这些技术、这些功能中得到多少好处。也就是说，用户关心的是他能从中取出多少，而不是你已经放进去多少。

（3）确保产品是健壮的、适应用户环境的。健壮性即稳定性，是产品质量的基本要求，尤其对于一个用于事务关键或时间关键的工作环境中的应用系统。软件只有稳定的运行，才会不致于中断用户的工作，因此通过健壮性测试是软件测试工作的又一个目标。