程序员的职业素养 读书笔记 - 第7章 验收测试

需求的沟通

开发方与业务方之间最常见的沟通是关于需求的。业务方描述他们认为自己需要的东西，程序员按照自己理解的业务方表达的需求来开发。

在现实里，关于需求的沟通是极其困难的，其中会出现各种问题。

过早精细化

    做业务的人和写程序的人都容易陷入一个陷阱，即过早进行精细化。

    1、不确定原则

        每次向业务方展示一项功能，他们就获得了比之前更多的信息，这些新信息反过来又会影响他们对整个系统的看法，这种现象也叫观察者效应。

    2、预估焦虑

        开发人员会掉进精确化的陷阱。他们知道必须评估整个系统，而且通常认为需要精确评估。

        评估可以而且必须基于不那么精确的需求，这些评估只是评估而已。开发人员通常会在评估中使用误差棒，这样业务方就能理解不确定性。

迟来的模糊性

    避免过早精细化的办法是尽可能地推迟精细化。但是，这可能造成另一个问题：迟来的模糊性。

    在具体的语境中看来，意思可能是非常清楚的，但是对阅读文档的程序员来说，意思可能截然不同。

验收测试

业务方与开发方合作编写的测试，其目的在于确定需求已经完成。

“完成”的定义

    完成意味着所有的代码都写完了，所有的测试都通过了，QA和需求方已经认可。这才是完成。

沟通

    验收测试的目的是沟通、澄清、精确化。

自动化

    验收测试都应当自动进行。原因很简单：要考虑成本。

额外工作

    验收测试是为了确定系统的各项指标符合要求。确定系统的指标；程序员才能确知“完成”；业务方才能确认开发的系统确定满足了需求；做到自动化测试。

验收测试什么时候写，由谁来写

    在理想状态下，业务方和QA会协作编写验收测试，程序员来检查测试之间是否有冲突或矛盾。

    但实际上，业务方通常没有时间，或者有时间也难以达到所需要的细致程序，所以他们通常会把测试交给业务分析员、QA甚至是开发人员。

    业务分析员测试“正确路径”，以证明功能的业务价值。

    QA测试“错误路径”、边界条件、异常、例外情况，因为QA的职责是考虑哪些部分可能出问题。

开发人员的角色

    实现某项功能的代码，应该在对应的验收测试完成后开始。

测试的协商与被动推进

    专业开发人员，与编写测试的人协商并改进测试是你的职责。每个人都需要关心错误和疏忽，并协力改正。

验收测试和单元测试

    单元测试是程序员写给程序员的，是正式的设计文档，描述了底层结构及代码的行为。关心单元测试结果的是程序员而不是业务人员。

    验收测试是业务方写给业务方的（可能会由开发者来写），是正式的需求文档，描述了业务方认为系统应该如何运行。关心验收测试结果的是业务方和程序员。

图形界面及其他复杂因素

    测试系统功能时，应当调用真实的API， 而不是GUI。

持续集成

    务必确保在持续集成系统中，单元测试和验收测试每天都能运行好几次。

    在持续集成系统里，失败的集成应该视为紧急情况，也就是“立刻中止”型事件。