验收测试
验收测试注意事项
过早精细化
做业务的人和写程序的人都容易陷入一个陷阱，即过早进行精细化。业务方还没有启动项目，就要精确知道最后能得到什么；开发方还没有评估整个项目，就希望精确知道要交付什么。双方都贪求不现实的精确性，而且经常愿意花大价钱来追求这种精确。
不确定原则： 问题在于，东西画在纸上与真正做出来，是不一样的。业务方看到真正的运行情况时就会意识到，自己想要的根本不是这样的——看到已经满足的需求，关于到底要什么，他们就会冒出更好的想法——通常并不是他们当时看到的样子。在工作中，有一种现象叫观察者效应，或者不确定原则。每次你向业务方展示一项功能，他们就获得了比之前更多的信息，这些新信息反过来又会影响他们对整个系统的看法。最终结果就是，霈求完成得越精细，就越容易被忽视，系统因此也谈不上完工。
预估焦虑： 开发人员也会掉进精确化的陷阱。他们知道必须评估整个系统，而且通常认为需要精确评估。但是，事实并非如此。首先，即便拥有全面准确的信息，评估也通常会存在巨大的变数。其次，因为不确定原则的存在，不可能通过反复推敲实现早期的精确性。需求是一定会变化的，所以追求那种精确性是徒劳的。专业开发人员知道，评估可以而且必须基于不那么精确的需求，这些评估只是评估而已。为强调这点，职业开发人员通常会在评估中使用误差棒。这样业务方就能理解不确定性。
迟来的模糊性
避免过早精细化的办法是尽可能地推迟精细化。专业开发人员直到着手开发的前一刻才会把需求具体化。但是，这可能造成另一个问题：迟来的模糊性。
业务方常常会提出不同意见。这时候他们会发现，相比解决分歧，更好的办法是换一种说法，所以会寻找各方都同意的关于需求的表述，而不是去解决争端。
我曾听到说： “需求文档中的每一点模糊之处，都对应着业务方的一点分歧。当然，模棚不只来自于分歧或争论。有时候，业务方会想当然地认为看文档的人懂得自己的意思。”
在具体的语境中看来，意思可能是非常清楚的，但是对阅读文档的程序员来说，意思可能截然不同。即便客户与程序员当面沟通，也可能出现因语境产生的模糊。
沟通
验收测试的目的是沟通、澄清、精确化。开发方、业务方、测试方对验收测试达成共识，大家都能明白系统的行为将会是怎样。各方都应当记录这种准确的共识。在专业开发人员看来，与业务方、测试方协同工作，确保大家都明白要做的是什么，是自己的责任。
验收测试和单元测试
验收测试不是单元测试。单元测试是程序员写给程序员的，它是正式的设计文档，描述了底层结构及代码的行为。关心单元测试结果的是程序员而不是业务人员。
验收测试是业务方写给业务方的（虽然可能最后是身为开发者的你来写) 它们是正式的需求文档，描述了业务方认为系统应该如何运行，关心验收测试结果的是业务方和程序员
有人认为民分两种测试是多此-举，所以要消灭 “重复劳动”。尽管单元测试和验收测试的对象通常是相同的，但绝对谈不上“重复”。
首先，尽管两者测试的可能是同一个对象，其机制和路径却是不同的。单元测试是深人系统内部进行，调用特定类的方法；验收测试则是在系统外部，通常是在API或者是UI级别进行。所以两者的执行路径是截然不同的。
不过，这两种测试并不重复的根本理由在于，它们的主要功能其实不是測试，测试只是它们的附属职能。单元测试和验收测试首先是文档，然后才是测试。它们的主要目的是如实描述系统的设计、结构、行为。它们当然可以验证设计、结构、行为是否达到了具体指标，但是，它们的真正价值不在测试上，而在具体指标上。
图形界面测试
有条设计原则是“单一责任原则”(SRP)。按照这条原则，应该把根据不同原因而变化的元素分开，把根据同一原因变化的元素妇类分组。GUI的设计也应该这样。
布局、格式、工作流，都会因为效率和美观的原因而变化，但是GUI背后的功能却不会因此变化。所以，在编写zgui的验收测试时，必须使用GUI背后相对稳定的抽象元素。
如果一个页面有七个按钮，写测试时，就不应当根据按钮的坐标来点击，而应当根据名字来点击。好一点的办法是，给每个按钮加上唯一ID。更好的办法是赋予ID明确的意义：某个测试选择的是ID为ok_button的按钮，而不是控制区域内第 4行第 3 列的按钮。
更好的办法是，测试系统功能时，应当调用真实的 API，而不是GUI。测试程序应当直接调用GUI使用的API，这并不是什么新鲜事。几十年来，设计专家一直在教导我们，要把GUI和业务逻辑分开。
通过GUI来进行测试是非常容易出问题的，除非你要测试的仅仅是GUI。因为GUI很容易变化，所以针对GUI的测试很不稳定。
如果GUI的每一次变化之后，都会有成百上千的测试通不过，那么最好放弃这些测试，或者不要改动GUI。两者都只是补救，根本的办法还是通过GUI背后的API来测试业务逻辑。
有些验收测试规定了GUI自身的行为。这些测试必须通过GUI但是，这些测试并不是测试业务规则的，所以不需要业务规则关联到GUI。可见，最好把GUI和业务规则解耦合，在测试GUI时，用测试粧替代业务规则。
应当尽可能地减少GUI测试。GUI很容舄变化，所以这类测试是不稳定的。GUI测试越多，维护它们的难度就越大。