软件测试的疑惑（四）

基本知识掌握

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

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

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

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

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

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

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

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

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

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

Good-enough原则就是一种权衡投入/产出比的原则：不充分的测试是不负责任的；过分的测试是一种资源的浪费，同样也是一种不负责任的表现。

 

执行测试工作的关键在于：如何界定什么样的测试是不充分的，什么样的测试是过分的。解决这一问题的通常方法是制定最低测试通过标准和测试内容，然后具体问题具体分析。

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

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

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

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

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

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

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

6、代码会审是如何进行的？

在研发小组将所开发的程序经验证后，提交测试组后，测试实施工作基本开始了。这个时候，测试人员要仔细阅读有关资料，包括规格说明、设计文档、使用说明书及在设计过程中形成的测试大纲、测试内容及测试的通过准则，全面熟悉系统，编写测试计划，设计测试用例，作好测试前的准备工作。为了保证测试的质量，我们一般测试过程分成几个阶段，即：代码审查、单元测试、集成测试和验收测试。

代码会审是由一组人通过阅读、讨论和争议对程序进行静态分析的过程。会审小组由组长，2～3名程序设计和测试人员及程序员组成。会审小组在充分阅读待审程序文本、控制流程图及有关要求、规范等文件基础上，召开代码会审会，程序员逐句讲解程序的逻辑，并展开热烈的讨论甚至争议，以揭示错误的关键所在。实践表明，程序员在讲解过程中能发现许多自己原来没有发现的错误，而讨论和争议则进一步促使了问题的暴露。例如，对某个局部性小问题修改方法的讨论，可能发现与之有牵连的甚至能涉及到模块的功说明、模块间接口和系统总结构的大问题，导致对需求定义的重定义、重设计验证，大大改善了软件的质量。

代码会审尽管需要一定的成本，但是在大型软件中，是必不可少的。

7、产品测试完成后产品谁来发布？

很多时候产品经过最后一次测试后由开发人员来发布，或者由质量管理部来发布，这样做都是不合适的。

开发人员发布产品常常会导致缺陷解决不彻底。一种较常见的现象是最后一次回归测试后，开发人员修改完成最后几个缺陷直接从开发环境发布产品，13.1.3节中的案例就是这样的一种情况，这种条件下实际是缺陷一次测试，因为修改缺陷通常会引入新的缺陷，甚至是严重的缺陷。

测试人员发布缺陷也是不和流程的，测试人员的职责是报告软件质量情况。而且测试人员发布缺陷容易带来版本管理混乱。

正确的做法是产品经过最后一次测试后，把产品和缺陷修改情况存入产品基线库，形成一个可以发布的版本。这样发布产品的一个前提是每次产品提交测试前都要有一个预备发布版本，测试或者回归测试后如果有问题需要修改解决，开发人员对该预备版本进行修改。如此反复多次后，直到最后一次测试，所有缺陷都得到修改或者审核，同时开发人员此次测试后没有对产品经过任何修改，我们就可以把这个最后一个预备发布版本存入基线库。

进行了上面正确的版本控制后，我们可以通过配置管理库进行产品发布管理。对外部发布产品时，直接从配置管理库中提取就可以了。详细的内容，读者可以参考配置管理方面的书籍。

 

文章为准备面试时，朋友分享的问题，添加自己的理解和体会，希望可以帮助到大家。