今天学习有关务实入门套件的内容，先看提示：
提示89 使用版本控制来驱动构建、测试和发布。
提示90 尽早测试，经常测试，自动测试。
提示91 直到所有的测试都已运行，编码才算完成。
提示92 使用破坏者检测你的测试。
提示93 测试状态覆盖率，而非代码覆盖率。
提示94 每个 Bug 只找一次。
提示95 不要使用手动程序。
作者在这里提出了项目的基础三件套：版本控制、无情的测试和完全自动化。下面的7点提示也都是围绕这三件套来展开的。版本控制这里比较简单，但是作者强调构建、测试和部署通过提交或推送给版本控制来触发，并在云容器中完成创建。我们的代码也是通过版本控制来构建的，但是我记得以前一些和构建关系不大的文件，比如nginx的配置文件等没有放进git里面来管理，还是造成了一些不便，不过现在基本都已经都能找到了。
接着讲测试，作者足足用了五个提示来强调了无情测试的重要性。首先要尽早、经常、自动测试。之前也说过，如果说先开发，后补测试，那大概率会变成永不测试，所以测试一定要和开发同步进行，甚至早于开发完成。接下来的提示中，作者把测试简单分成了单元测试、集成测试、性能测试已经检测测试。回顾我们系统的各种TT，什么样的错误都犯过，确实有一些是靠补上单元测试，有一些则需要添加集成测试来保证，还有一些则和特定数据和数据量有关系，又需要性能测试。接着，作者认为测试的时候不要盲目追求代码覆盖率，而是要去保证测试状态覆盖率。覆盖了每一行代码并不能保证测试了所有状态，特别当状态特别多、组合特别复杂的时候，首先保证特定状态的正确性才是我们要去追求的。至于最后的每个bug只测试一次则是强调了知错能改，每次发现了bug都要补充对应的测试来防止它以后再次出现。我们也是这样做的，每次bug以后qa都会针对性地去补充一些测试。我们的时间，必须用于编写新的代码——以及新的 Bug。
最后作者说不要使用手动程序，人一定会犯错，所以能够自动化的步骤还是尽量要自动化。这一点我就想到了我们项目的部署，本来我们本地的部署需要等待代码编译，在手动上传ear包，比较麻烦，后来我就参考一些同事的做法，用脚本把编译打包代码，启动jboss，启动本地queue，部署代码都继承在一起，这样只要一键就能实现本地的部署。什么时候我们产品的迭代也能想这样一键部署就太好了，还要继续努力啊。
网友评论