关于测试的一些笔记1

这几天，看了一本书：代码整洁之道 程序员的职业素养。深有感触，记录如下。

1 验收测试和单元测试
      单元测试是程序员写给程序员的，它是正式的设计文档，描述验证了底层结构及代码的行为。关心单元测试结果的是程序员而不是业务人员。
      验收测试是正式的需求文档，描述了业务方认为系统应该如何运行，关心验收测试结果的除了程序员外，业务方更在乎这个结果。
      尽管单元测试和验收测试的对象通常是相同的，但是绝对不是“重复劳动”。
      首先，尽管两者测试的对象可能是同一个对象，其机制和路径却是不同的。单元测试是深入系统内部进行，调用特定类的方法，验收测试则是在系统外部，通常是在API或者UI级别进行。所以，两者的执行路径是截然不同的。不过，这两种测试更深层系的不同在于测试本身，它们的主要功能其实不是测试，测试只是它们的附属职能。单元测试和验收测试首先是文档，然后才是测试。他们的主要目的是如实描述系统的设计，结构，行为是否达到了具体指标，所以它们真正的价值不再测试上，而在于具体指标上。

2 图像界面的测试
   预先制定详细的GUI很难，因为美是主观的，会不断变化。所以编写GUI的测试很麻烦。但是如果把gui当成api来处理，而不是看成按钮，滚动条，菜单。。。。那验收测试就简单多了。布局，格式，工作流都会因为效率和美观的原因而变化，但是GUI背后的功能却不会因此变化，所以在编写GUI验收测试的时候，必须使用GUI背后相对稳定的抽象元素。比如页面有多个按钮，写测试的时候，就不应当根据按钮的坐标来点击，而是根据名字，或者给每个按钮加一个ID。更好的办法是赋予ID明确的意义，如某个测试选择的是ID为ok_botton的按钮，而不是控制区域内第四行第三列的按钮。更好的办法是，应当调用真实的API，而不是GUI。要把GUI和业务逻辑分开。测试程序应当调用GUI使用的API。

3 持续集成
      请务必确保在持续集成过程中，单元测试和验收测试每天都能运行好几次，整套持续集成系统由代码管理系统来触发。只要有人提交了代码，持续集成系统会自动开始构建，并运行所有的测试，测试结果会用电子邮件发送给团队所有人。
      请务必确保持续集成系统随时都可以运行，持续集成不应该失败，如果失败了，团队所有人都应该立刻停下手里的活，看如何让测试通过。在持续集成系统里，失败的集成应该视为紧急情况，也就是“立刻中止”型事件。

4 验收测试
      首先，我们把验收测试定义为业务方和开发方合作编写的测试，其目的在于确定需求已经完成。
      交流细节是一件很麻烦的事情。尤其是开发方和业务方交流关于程序的细节时，更是如此。同常，双方坐下握手言欢，以为对方都明白自己的意思，取得了共识，然后带着截然不同的理解和想法离开。眼解决这种开发方和业务方沟通的问题，一个吐血推荐的有效的办法就是编写自动化验收测试。这些测试住够正式，所以结果也足够权威。这些测试不会造成模糊，也不会与真实脱节。这就是无可挑剔的正式的需求文档。