关于软件测试的几个经典问题（2）

测试的几个原则

1. 应当把“尽早地和不断地进行软件测试”作为软件开发者的座右铭。
2. 测试用例应由测试输入数据和对应的预期输出结果这两部分组成。
3. 程序员应避免检查自己的程序。
4. 在设计测试用例时，应包括合理的输入条件和不合理的输入条件。
软件测试的原则
5. 充分注意测试中的群集现象。
经验表明，测试后程序中残存的错误数目与该程序中已发现的错误数目成正比。
6. 严格执行测试计划，排除测试的随意性。
7. 应当对每一个测试结果做全面检查。
8. 妥善保存测试计划，测试用例，出错统计和最终分析报告，为维护提供方便。

关于bug

测试的原则---Good Enough

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

　　Good-enough原则就是一种权衡投入/产出比的原则：不充分的测试是不负责任的；过分的测试是一种资源的浪费，同样也是一种不负责任的表现。我们的操作困难在于：如何界定什么样的测试是不充分的，什么样的测试是过分的。目前状况唯一可用的答案是：制定最低测试通过标准和测试内容，然后具体问题具体分析。

测试的规律----木桶原理和80-20原则

（1）木桶原理

　　在软件产品生产方面就是全面质量管理(TQM)的概念。产品质量的关键因素是分析、设计和实现，测试应该是融于其中的补充检查手段，其他管理、支持、甚至文化因素也会影响最终产品的质量。应该说，测试是提高产品质量的必要条件，也是提高产品质量最直接、最快捷的手段，但决不是一种根本手段。反过来说，如果将提高产品质量的砝码全部押在测试上，那将是一个恐怖而漫长的灾难。

（2）Bug的80-20原则。

　　实践证明。80%的bug往往隐含在20%的软件区域。所以一旦在某处发现了bug，多找找周围。这也是有经验的测试员的一种方式。

   一般情况下，在分析、设计、实现阶段的复审和测试工作能够发现和避免80%的Bug，而系统测试又能找出其余Bug中的80%，最后的5%的Bug可能只有在用户的大范围、长时间使用后才会曝露出来。因为测试只能够保证尽可能多地发现错误，无法保证能够发现所有的错误。

推荐给：刚刚入门的新人

推荐语：这是一篇关于测试员角色定位的文章，希望可以给刚入门的人，入门不就感到有些迷茫的人一些启示。

其实我们从小学，到大学，学到的哲理，格言不下亿万句，在人生的某个时刻能真正对你有用的那一句才算真的有用。这篇文章，当初也给了我极大的启发。特推荐至此。

声明：来自testage的《测试员》第一期（节选）

   很多刚进入门的同仁开始慢慢对做测试流露出迷茫的眼神，问其原因，很简单，做测试学不到东西，整天就鼠标点点，键盘敲敲，很难学到真正的东西。

听了之后不由得露出理解的笑容，想当年我也是从这样的境遇走过来的。刚进入公司的时候就让做测试，经历了同样的鼠标点点，键盘敲敲的经历。然而正是这样的一些成长经历让我在平淡中明白了很多道理，并且慢慢从因为工作而做测试转化为因为兴趣爱好而继续做测试工作。

    做测试不仅仅是表面看到的这种敲敲点点现象的延续，还有更深层次的内涵，只

是我们很多人还没到达这个境界而已，所以看起来很枯燥。

   刚开始做测试的朋友很多都在做黑盒测试，而黑盒测试往往对代码编写能力要求不是很高，这样给刚入门的人就造成了一个测试人员不需要太多知识的误解。

    然而，做测试往往需要很广泛的知识。不仅仅只是专业上的，而且要了解很多开发人员不了解的东西，在一个系统里面开发人员可以只了解客户需求，而我们的测试人员需要了解整个全局的东西。呵呵，感觉有点统筹全局的成就感。不过有时候相对于开发人员来说也的确是这样的。开发人员可以不用太多了解用户的需求，而我们却需要能够准确捕获用户的观点，对很多细节需要非常注意。

    往往很多人在初入测试行业的时候非常热衷于测试工具的学习以及使用，其实这并不是一个很系统的认知。知识的学习也是分阶段的。测试这两个字很表面来看很简单，只是给程序挑错误，找出bug来，但是在整个软件开发过程中我们该如何把测试跟开发结合起来有效地进行都需要经过实践来证明。而这些不是工具所能完成的。我们对整个测试流程方面的东西需要了解得很多很多，而工具只是需要了解的其中一部分而且是比较小的一部分知识而已。

    你所了解的不仅仅只是测试的表面，你需要了解测试的流程，你需要了解如何用一个好的测试计划来规划我们的测试时间、测试范围（有些公司把测试范围的设计归纳在测试需求里面，但是很多公司都是在测试计划里面），需要了解如何用一个好的测试用例来覆盖整个测试范围之内的测试实施。了解如何保证所测试出来的bug是开发人员的问题而不是因为自己了解不够导致出现的问题。Bug分析报告之内如何总结问题都是我们需要注意到的知识。对自己的测试时间也需要进行详细规划，尽量多地考虑进去各种可能。这样才可以尽量减少相关的风险。

其实这些问题真的在哪个论坛里都有，不过奇怪的也是，每次面试都会遇到，无论是自己面试还是给别人面试。。

PS:声明一下，这里的问题基本都不是原创的，答案呢，在软件测试“百家争鸣，百花齐放”的时代也是丰富多彩的。但是道理都差不多。仅作为参考，呵呵~~

什么是“软件测试”？

1。出自(IEEE, 1986; IEEE, 1990).

Software testing is the process of analyzing a software item to detect the differences between existing and required conditions (that is, bugs) and to evaluate the features ofthe software item

就是一个通过分析软件和需求之前差异，发现bug,对软件的功能进行评价的过程。

2。软件测试就是在受控制的条件下对系统或应用程序进行操作并评价操作的结果。

3。软件测试是为了发现错误而执行程序的过程。

这一种也是大多数文档和书籍进行的定义，其实和第一个定义没有什么区别。

什么是“测试案例”?

测试案例是一份文档，它描述了一个输入、反应、或者是与其相应的预期的响应，以便来判断应用软件的工作是否正常。测试案例应当包括测试标识、测试案例的名称、目标、测试条件/设置、输入数据要求、步骤、以及预期的结果。

如果时间不够，无法进行充分的测试怎么办?

使用风险分析，确定测试的重点。

由于很少有机会对一个应用软件进行所有可能的测试(包括所有可能的事件组合、所有的相关性、或者一切可能出错的东西)，对大多数软件开发项目来说，利用风险分析是适当的。这需要判断技能、常识、感觉和经验。如果有正当理由，也可采用正式的方法。需要考虑下列因素：

ü 对于该项目的用途而言，哪种功能最重要?

ü 哪种功能对用户最明显?

ü 哪种功能对安全影响最大?

ü 哪种功能对用户最有用?

ü 对客户来说，该应用软件的哪个部分最重要?

ü 在开发过程中，该应用软件的哪个部分可以最先测试?

ü哪一部分代码最复杂，容易导致出现错误?

ü哪一部分的应用程序是在急迫或在惊恐的情况下开发出来的?

ü哪一部分程序与过去项目中引起问题的部分相类似/有关?

ü哪一部分程序与过去项目中需要大量维护的部分相类似/有关?

ü需求和设计的那些部分不清楚或不容易读?

ü开发人员认为在应用软件中哪些部分是高风险的?

ü哪些问题能造成最差的发行?

ü哪些问题最能引起用户抱怨?

ü哪些测试可以容易地覆盖多种功能?

ü哪些测试在覆盖高风险部分的测试时使用时间最少?

如果需求一直在变化怎么办?

这是一个常见的令人头疼的问题。

ü如果可能，尽早与承担该项目风险的人接触，以便了解需求会怎样改变，从而可以尽早地改变测试计划和策略。

ü 如果在对应用程序进行初始设计时多考虑一些适应性，那么以后在发生需求的改变时，就不需要再为改变做很多事情了。

ü 好的代码注释和好的文档有助于开发人员作出相应的改变。

ü只要有可能，就应使用快速原型(rapid prototyping)，以帮助用户确认他们的需求，从而减少变更。

ü在项目的时间表中应当留出余量，以应付可能出现的变更。

ü尽量把新的需求纳入应用软件的“下一版”，而把原始需求作为“第一版”。

ü通过谈判，把易于实现的新的变更列入项目，而把难于实现的新需求列入该应用软件的以后的版本。

ü要确保让客户和管理人员了解变更对进度表的影响、所带来的风险、以及因变更所引起的大量资金消耗。

ü在应付改变时，应在为建立自动测试而作的努力和重新进行测试所做的努力之间取得平衡。

ü在设计自动测试剧本时，试图使其有一些灵活性。

ü在对应用软件进行自动测试时，要把注意力集中在看来不大会改变的部分。

ü对变更进行适当的风险分析，以减少回归测试的要求。

ü在设计测试案例时要有一定的灵活性。做到这一点并不容易，所以要降低测试案例的详细程度，或者只建立高级的通用型的测试计划。

ü 少注意详细的测试计划和测试案例，要把重点放在专门的测试(ad hoc testing)上。