大规模视频网站的计费与流量管理
本次分享将会就大规模视频网站的计费与流量管理这个话题，从操作层面细细进行讲解和分析，为系统工程师们揭示平日里我们没有关心的另一些内容。同时也希望本次分享能揭示行业中的一些“潜规则”，让互联网行业的流量与带宽管理更为开放与简洁。
本次演讲视频录制于QCon杭州2011。
新闻
该内容已经被标记书签！
标记书签错误，请重试！
检查，还是测试，你使用哪个？
作者 Vikas Hazrati 译者 金毅 发布于 2009年12月28日
软件测试是一种以观察和实验为依据的调查过程(empirical investigation)，该过程以测试为手段，为干系人提供产品或服务的质量信息。然而，这个定义并没有提到人类智慧的应用，而人类的智慧使得测试（testing）和检查（checking）之间产生微妙区别。Michael Bolton谈了两者的区别及其产生原因。
Michael认为：
检查是指为了证实已经存在的理念而去做的事情。检查是一个证实(confirmation)、验证(verification)和确认(validation)的过程。当我们已经相信某些东西是正确的，我们会通过检查来核实这一点。当我们修改了代码又想确保一切功能照常运行，我们就需要检查。
测试是指我们为了发现新信息而去做的事情。测试是一个探索（exploration）、发现（discovery）、调查（investigation）和学习的过程。当我们想通过配置、操作或者观察来评估一个产品时，或者当我们试图去识别一个没有预计到的问题时，我们就是在测试。
Michael认为：检查要依赖机器完成，因为它们可以给出非此即彼的两个答案：通过或者失败。测试却需要智慧。测试是了解系统和解答问题的探索之旅：“这里有问题吗？”这也引出了测试人员和检查人员的区别。
需要有最新的、清晰、完整而且没有歧义的规范说明才能工作的人是检查人员，不是测试人员。同样，需要有测试脚本才能工作的只是检查人员，而不是测试人员。而仅仅根据参考文档来比较当前程序的人也是检查人员，不是测试人员。
George Dinwiddie认为检查和测试都是需要智慧的。他觉得虽然Michael认为“运行和观察结果”是检查，但是这仅仅是脚本测试的一部分。一旦测试失败了，就需要测试人员的智慧来弄明白到底发生了什么。这可能包括通过查看日志文档来获得信息，让其他人去看看别的系统是不是工作正常，以及很多其他探究性工作。所以这跟探索性测试没有区别，除了发生的时间有点延时而已。
Michael一定程度上也同意这个观点，他认为仅仅检查点（check）本身是很微不足道的。往往检查之前或者检查之后，人类的智慧起到了很大作用。这也就是一个检查点（check）和检查（checking）的区别。
所以核心问题在于我们认为哪一个更有价值，是检查点（我们有50000个自动化测试）还是检查。只有检查点是不重要的，但是检查——涉及到构建、维护和分析每个检查点——却是很重要的。参照艾森豪威尔那句话（译者注：艾森豪威尔，二战欧洲盟军总司令，美国34任总统。他在诺曼底登陆以后有句名言：Plan is nothing, but planning is everything)，就检查而言，检查点什么都不是，与之相比，检查这一系列过程才是王道 （with respect to checking, the checks are nothing; the checking is everything）。然而检查也不是万能的，测试也是如此。
Johanna Rothman 也发表了类似的看法，她认为测试需要技能和智慧并存。
敏捷项目需要真正的多面手来担当测试人员：拥有能读懂需求、设计和代码的技能的人。没有这些技能，他们就不能足够深入地去思考开发中的产品，他们也就有可能无法识别出足够多的各类测试用例。如果他们能够理解需求、设计和代码，他们就可以根据他们的理解设计出巧妙的测试用例。其中的一些测试是探索性的，甚至有些探索性的测试需要以自动化方式实现，以便以后重复运行。我曾经在敏捷项目中见过一些出色的测试人员，他们能够很快地编写出自动测试脚本来做一些探索。
Cem Kaner则不同意敏捷测试人员需要是多面手一说。他认为既然探索性测试既需要测试又需要探索，那么为了能探索得当，还是很有必要运用些特定技能的。他说道：
程序员理解项目中很多的风险。相比非程序员出身的人，他们可能能更好地写出深入的测试来探测那些风险。而其他人可以更加专注于当前环境下的软件集成。相类似地，我们熟知的一些系统性能或者安全评估方面的专家，也能在他们的领域更好地表现。他们中的一些人是程序员，一些则不是。所有这些人和系统级别的软件测试人员（software validator）一起，才能做好自动脚本测试或者探索性测试。
George认为这两种模型都有各自的利弊。检查和测试都能满足Cem Kaner关于测试的定义。关键不在于是不是测试脚本化，而是你做事的流程和方式。
两个都是测试，都在寻找新信息，都需要智慧。如果你不这么想，那么你的测试方式就错了。
前不久，InfoQ也发布了一篇新闻《热衷敏捷测试的十大理由》，有兴趣的同学们请参阅。
查看英文原文：What do you do, Testing or Checking?
译者 金毅 多年来服务于欧美软件外包行业从事管理工作，对软件工程、方法学等在外包业的运用和CMMI实施略有感悟。
软件测试是一个综合活动
发表人
段 念
发表于
Re: 软件测试是一个综合活动
发表人
Chan Jackei
发表于
Re: 软件测试是一个综合活动
发表人
zhu ricky
发表于
让合适的人做合适的事
发表人
Li Darren
发表于
Re: 让合适的人做合适的事
发表人
Mao Gemini
发表于
Plan is nothing, but planning is everything。
发表人
Chan Jackei
发表于
-
从测试本身来说， 我非常同意“测试需要探索，发现和调查”这个观点。其实，在所有的测试过程中，探索，发现和调查都是在自觉和不自觉的应用的。设计测试，通过操作应用发现可能的问题，以及发现缺陷之后的分析和调试─这些都是在应用探索。
但就具体组织成员的工作内容来说，不太可能要求每个人具有所有的能力去完成测试中需要完成的所有任务，例如，建立验收测试标准，建立自动化测试，深入探索应用某个质量属性（性能或者安全性），就具体的分工来说，还是需要一些人专注在“检查”，一些人专注在探索。 -
探索，发现和调查活动可以由资深的测试人员来做。证实，验证等活动可以由脚本或者初级测试人员来做。
-
探索，发现和调查活动可以由资深的测试人员来做。证实，验证等活动可以由脚本或者初级测试人员来做。
的确，大多数的公司应该都是把文中说的检查和测试分配给不同的人员来做，这也是技能要求决定的。 -
敏捷项目需要真正的多面手来担当测试人员：拥有能读懂需求、设计和代码的技能的人。没有这些技能，他们就不能足够深入地去思考开发中的产品，他们也就有可能无法识别出足够多的各类测试用例。
测试人员的智慧体现在：设计测试用例，测试执行前的准备，测试后对现象的分析，提交高质量的缺陷记录。但是在实际中，如果面对一个复杂的项目，或者一些更偏重于技术实现的测试，设计测试用例和执行的人分开是客观存在的。 -
赞同！
-
检查点和检查本身就是两个不同层次，设置检查点和去做检查本身需要不同level的人去做。
6 条回复
关注此讨论 回复