测试人员能测的是什么？
他们只能站在系统外部做功能特性的测试，而一个软件是由他内部诸多模块组成的，测试人员只能从外部保障正确性，所能达到的效果是有限的。
打个比方，你做一台机器，每个零部件都不保证正确性，却要让最后的结构正确，这实在是一个可笑的要求，但是
却真实地发生在软件开发的过程中。
在软件开发中有一个重要的概念，软件变更成本，他会随着时间和开发阶段逐步增加，也就是说，我们要尽可能早地发现问题，修正问题，这样所消耗的成本才是最低的。
最理想的情况下
质量保证是贯穿在软件开发全过程中，从需求开始的每一个环节，都将”测试“纳入考量，每个角色交付自己的工作成果时，都多问一句，你怎么保证交付物的质量。
需求人员要确定验收标准，开发人员则要交出自己的开发者测试。这是一个来自于精益原则的重要思想，内建质量（Build Quality In）
对于每个程序员来说，只有在开发阶段把代码和测试都写好，才有资格说，自己交付的是高质量的代码
自动化测试（背景）
程序员这个群体做测试有个天然的优势：会写代码，这个优势足以让我们把测试自动化
关键词：smalltalk
这种测试框架最大的价值，是把自动化测试作为一种最佳实践引入到开发过程中，使得测试动作可以通过标准化的手段固定下来。
测试模型：蛋卷与金字塔
我们把测试分为人工测试和自动化测试。即便我们只关注自动化测试，也可以按照不同的层次进行划分，
将测试分为最小程序模块的单元测试，
将多个模块组合在一起做的集成测试，
将整个系统组合在一起的系统测试。
有一种直觉的做法是，既然越高层的测试覆盖面越广，那就多写高层测试，比如系统测试。
当然，有些情景高层的测试不容易覆盖到的，所以，还要有一些底层的测试，比如单元测试。
在这种情况下，底层的测试只是作为高层测试的补充，而主力就是高层测试。
这样就会形成下面这样一种测试模型：冰淇淋蛋卷。
听说过冰淇凌蛋卷测试模型的人并不多，它是一种费时费力的模型，要准备高层测试实在是太麻烦了。
之所以要在这里提及它，是因为虽然这个概念很多人没听说过，但是有不少团队的测试实际采用的就是这样一种模型，
这也是很多团队觉得测试很麻烦却不明就里的原因。
行业里的最佳实践：测试金字塔
测试金字塔
Mike cohn在自己的著作《succeeding with Agile》提出测试金字塔，但大多数人都是通过Martin Fowler 的文章知道的这个概念。
测试金字塔的重点就是越底层的测试应该写得越多。
想要理解测试金字塔成为行业最佳实践的缘由，我们需要理解不同层次测试的差异。越是底层的测试，牵扯到相关内容越少，而高层测试则涉及面更广。
小事容易做好，而大事难度则大得多。所以，以这个标准来看，底层的测试才更容易写好。
人们会本能地都会倾向于少做复杂的东西，所以，人们肯定不会倾向于多写高层测试，其结果必然是，高层测试的测试量不会太多，测试覆盖率无论如何都上不来。
而且，一旦测试失败，因为牵扯的内容太多，定位起来也是非常麻烦的。
而反过来，将底层测试定义为测试主体，因为牵扯的内容少，更容易写，才有可能让团队得到更多的测试，而且一旦出现问题，也会更容易发现。
核心： 小事反馈周期短，而大事反馈周期长。
当测试金字塔遇到持续集成
测试金字塔是一个重要实践的基础，它就是持续集成。
当测试数量达到一定规模，测试运行的时间就会很长，我们可能无法在本地环境一次性运行所有测试。
一般我们会选择在本地运行所有单元测试和集成测试，而把系统测试放在持续集成服务器上执行。这个时候，底层测试的数量就成了关键，按照测试金字塔模型，底层测试数量会很多，测试可以覆盖主要的场景；
而按照冰淇淋蛋卷模型，底层测试的数量则有限。作为提交代码的防护网，测试数量多寡决定着得到反馈的早晚。
所以，金字塔模型与持续集成天然就有着很好的配合。需要特别注意的是，不是用单元测试框架写的测试就是单元测试。很多人用单元测试框架写的是集成测试或是系统测试。单元测试框架只是一个自动化测试的工具而已，并不是用来定义测试类型的。
在实际工作中，区分不同测试有很多种做法，比如，将不同的测试放到不同的目录下，或是给不同类型的测试一个统一的命名规范。区分不同类型测试主要目的，主要是在不同的场景下，运行不同类型的测试。
就像前面提到的做法是，在本地运行单元测试和集成测试，在持续集成服务器上运行系统测试。
人的时间和精力是有限的，所以，人们开始思考不同的测试如何组合。在这个方面的最佳实践称之为测试金字塔，它强调的重点是，越底层的测试应该写得越多。
只有按照测试金字塔的方式写测试，持续集成才能更好地发挥作用。
网友评论