版权声明：本文由李兰非整理撰写，任何团体或个人不得擅自更改。如需引用请保留版权说明并注明出处，谢谢！
微软不是一家软件开发公司，而是一家软件测试公司。
—— 比尔•盖茨 |
测试有什么用？花那么多的人力物力和金钱做的测试到底是为了什么？很多所谓的专业书籍对此讲了很多让人眼花缭乱的理论。
其实很简单，测试就是为了让产品在交付给最终用户以后，在产品生存周期（或提供有效服务的期限以内），不让最终用户发现其所不能接受的现象。
良好的测试，可以有效的降低维护的成本。用户如果满意你的产品，就不会一而再、再而三的要求改进，维护的成本自然会下降。
当然，测试本身的成本也是不低的，所以为了让我们为测试付出的代价物有所值（大概还没有人会说自己的产品从未经过测试吧），我们很有必要去认真的了解一下关于测试的一些东西。
软件测试是在有限的时间内提供高质量软件的保证，是一个完整正规的软件开发过程中非常重要的一个部分。（《微软是怎样做测试的》——ATC ( Advanced Technology Center，微软亚洲工程院 ) 测试组相关负责人）
Any activities aimed at evaluating an attribute or capability of a program or system. ( Bill Hetzel 1983年对测试的定义 )
The process of executing a program or system with the intent of finding errors. ( Glenford J. Myers 对测试的定义 )
使用人工或自动的手段来运行或测定某个软件系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。( IEEE 1983年对测试的定义 )
测试是以评价一个程序或者系统属性为目标的任何一种活动。测试是对软件质量的度量。( Bill Hetzel 《软件测试完全指南》)
我个人对测试的理解是，我们编写的代码应该通过全部的测试，使之完成所有需求。即测试就是让我们的产品符合客户要求的过程。这里的理解有些狭隘，的确。客户并不专业，客户未必能了解我们的产品中存在的Bug，而且客户并不关心这些，只要他们看到了他们想要的东西，他们就愿意付钱。所以，以商业为目的的软件产品，大多时候没有必要深究一些无法带来经济利益的问题，例如为一个运行时间为2秒的任务提高50%的效率，数字上很诱人，但这几乎毫无意义，而且会浪费很多资源。
l 测试是为了证明程序有错，而不是证明程序无错误。
l 一个好的测试用例是在于它能发现至今未发现的错误。
l 一个成功的测试是发现了至今未发现的错误的测试。
（Grenford J. Myers《The Art of Software Testing》）
上面的定义是一个关于测试目的的经典说明，但是容易让人产生误解——测试 = 发现Bug。我并不赞同这样的观点。
通常，测试作为一种质量保证的手段，作为项目后期自我检查的一部分。既是说，大量的缺陷和Bug等堆积到一定数量后，我们才开始去发现他们。
让我们来看看编译器报错的目的，很容易我们就可以看出它是用来保证我们编出正确的代码的，当然这仅仅是正确的语法。它并不保证代码的功能。编译器对代码的测试，就很有效的提高了我们的工作效率。
我们也许应该尝试考虑这样的一个测试计划，用它来保证生产出正确的软件，而非仅仅是查找Bug。Bug或者说缺陷，通常的理解就是干扰程序正常运行的因素。很显然，如果程序正确，那么，Bug就不应该存在。这是一个理想状态，一个合理的测试过程，应该让我们更加接近这个状态。
合理的测试，会使软件产品趋于正确和完善。同时，测试也是验证这一结果的过程。对于用户而言，他期望的是符合他需求的产品，测试的目的就是使产品不会偏离用户需求，并且达到一个合理的质量水平。并且当场品对于客户的标准有所偏离时，测试能够为我们指明改正的方向。
怎样评价一个测试的好坏呢？
最直接的看法是，是否找到了足够多的缺陷。假如我们有50个缺陷，几次测试中，分别找到了1、20、0、50、13……也许我们会说，找到50个的那次最好，于是，大家学习他怎么测试的，答案也很简单，认真。于是大家一起认真的测试，但还是没有几个能重复的找出全部缺陷。也许这个例子并不是很准确（里面描述的情况比较理想化）。但是至少有一点我们可以肯定，认真是不可量化的，于是依赖于认真的结果也就无法有效的进行评价。同时，这样的测试，我们绝对不敢拍着胸脯说：“放心，一周内，我们会满足您的要求!” 因为每次测试的结果是不固定的，我们没有办法确定的评估产品目前的状况。
好的测试也许不能发现所有的缺陷，但是可以让我们准确的知道经过测试，我们的程序能够在什么样的条件下正确，每次测试我们都能够提前的预知完全通过测试后的结果。
测试不是为了发现缺陷，而是让我们更加了解我们的软件产品。能够让我们有效的评估产品的测试，就是好的测试。
另外，对于Bug、缺陷等词汇最好有自己严格的定义，同时对于严重等级以及Bug分配规则等，也要有不易产生误解的定义，才会使测试的效果得到保证。
我们通常在程序接近完成的时候开始测试。或者在程序有了雏形后开始测试。使雏形在不断的迭代中完善。
从软件的生存周期看，测试往往指对程序的测试，这样做的优点是被测对象明确，测试的可操作性相对较强。但是，由于测试的依据是规格说明书、设计文档和使用说明书，如果设计有错误，测试的质量就难以保证。即使测试后发现是设计的错误，这时，修改的代价是相当昂贵的。因此，较理想的做法应该是对软件的开发过程，按软件工程各阶段形成的结果，分别进行严格的审查。（《软件测试的组织与管理》）
测试不是为了我们编出正确的代码，而是制造出正确的产品，这是有很大不同的。软件产品的制造周期不只是编码。我们完全有理由相信，在其他的过程中，同样会产生很多缺陷和Bug。一个好的测试方案，应该贯穿整个软件生命周期，而不是将测试排在编码之后（如经典的瀑布开发）。
同样，测试前置也是XP( XProgramming )和RUP（Rational Unified Process)的重要思想之一。
我们为何不尽早的发现缺陷呢？（在我参与的几个项目中，我们都有一套比较完整的评审机制去完成这些提前的测试工作。起到了很好的效果。）如果你问我什么时候需要测试，我会说：“随时！”
自动测试，通常是利用专用的工具软件或专门为测试编写的代码进行的测试。特点是速度快，测试结果准确，对于批量化的测试尤为明显。同时，测试的过程能够不断的重复。测试的流程清晰，每一个步骤都在控制之内，我们清楚的知道测试过程中发生了什么。
缺点是，前期投入较大，为了建立起一个测试架构，必须在前期准备很多工作。且对于部分问题，机器是无法代替人的。
手动测试，恐怕是最直接简单的测试了。人与机器相比，有更好的逻辑思维能力，对于很多问题，只有人才能给出正确的答案。所以手动测试是不可替代的。
但是对于批量化的测试用例，输入输出检查，压力测试，算法逻辑检查等等，人力就显得过于单薄了。对于大批量的工作，人是十分容易疲倦和出现意外错误的。这会使测试过程效率低下且充满不确定因素。
对需要测试的软件选择人工测试还是自动测试就要看工作对于时间、人力、技术以及对稳定性的要求来平衡两者的比例了。这种情况下，不仅是努力工作就能完成工作的唯一方法了。 “Work Smartly”就显得非常重要。在ATC的测试组，每个人都不断地被来自Work Smartly的成就感所激励，测试工作成为他们展示创造性和智慧的舞台。（《微软是怎样做测试的》——ATC ( Advanced Technology Center，微软亚洲工程院 ) 测试组相关负责人）
扫一扫
5035
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
