豆瓣
扫码直接下载
读过 持续交付
部署流水线的目标有三个。首先,它让软件构建、部署、测试和发布过程对所有人可见,促进了合作。其次,它改善了反馈,以便在整个过程中,我们能够更早地发现并解决问题。最后,它使团队能够通过一个完全自动化的过程在任意环境上部署和发布软件的任意版本。引自 软件交付问题
整个团队应该定期地坐在一起,召开回顾会议,反思一下在过去一段时间里哪些方面做的比较好,应该继续保持,哪些方面做的不太好,需要改进,并讨论一下如何改进。每个改进点都应该有一个人负责跟踪,确保相应的改进活动能够被执行。当下一次团队坐在一起时,他们应该向大家汇报这些活动的结果。这就是众所周知的戴明环:计划、执行、检查、处理。 关键在于组织中的每个人都要参与到这个过程中。如果只在自己所在角色的内部进行反馈循环,而不是在整个团队范围内进行的话,就必将产生一种“顽疾”:以整体优化为代价的局部优化,最终导致相互指责。引自 持续改进
在不同环境之间管理配置信息的一种方法是,把预期的生产环境中的配置信息作为默认配置,而在其他环境中,通过适当的方式覆盖这些默认值(确保你有预防措施,以防生产环境受到配置失误的影响)。也就是说,尽量减少配置项,最好只保留那些与应用软件具体运行环境密切相关的配置项。 与应用程序一样,配置设置也需要测试。对于系统配置测试来说,包括以下两个部分。 一是要保证配置设置中对外部服务的引用是良好的。 二是当应用程序一旦安装好,就要在其上运行一些冒烟测试,以验证它运行正常。引自 应用程序的配置管理
他根据两个维度对测试进行了分类。一个维度是根据它是业务导向,还是技术导向。另一个维度是依据它是为了支持开发过程,还是为了对项目进行评价。引自 测试的分类
我们倾向于将自动化验收测试限于完全覆盖 happy path 的行为,并仅覆盖其他一些极其重要的部分。 一个好的自动化测试套件应该给你足够的信心执行重构,甚至对应用程序架构进行重构。 你需要监控到底花了多长时间做重复性的手工测试,以便决定什么时候把它自动化。一个很好的经验法则就是,一旦对同一个测试重复做过多次手工操作,并且你确信不会花太多时间来维护这个测试时,就把它自动化。引自 业务导向且支持开发过程的测试
mock 是一种被格外滥用的测试替身。人们很容易错误地使用 mock 写出不找边际且脆弱的测试,因为大家很容易通过它们来判断代码的具体工作细节而不是代码与其协作者的交互动作。这样的做法使测试很脆弱,因为假如实现细节变了,测试就会失败。引自 测试替身
首先,要抵制使用生产数据的备份作为验收测试的测试数据库的诱惑。相反,我们要维护一个受控的数据最小集。如果想在测试环境中跟踪生产系统的状态,你花在让该数据能够运行起来的时间远远要多于用它来真正做测试的时间。毕竟测试的关注点在于系统的行为,而非数据本身。 验收测试最有效的方法是:利用应用程序自身的功能来隔离测试的范围。引自 实现验收测试
当快要发布时,你会试图让验收测试通过,以便使你自己对软件质量感到一些自信。然而看过一遍验收测试后,你会发现,很难确定哪些验收测试是因为测试条件的变化而失败的,哪些测试是由于测试与代码紧耦合,而该代码被重构才导致的失败,或者真的是由于应用程序的行为不正确而导致的失败。 尽早修复失败的验收测试是至关重要的,否则测试套件就没有贡献真正的价值。引自 确保验收测试一直处于通过状态
“吞吐量” 是系统在一定时间内处理事务的数量,通常它受限于系统中的某个瓶颈。在一定工作负载下,当每个单独请求的响应时间维持在可接受的范围内时,该系统所能承担的最大吞吐量被称为它的 "容量"。引自 非功能需求的测试
很多非功能需求的横切本质(crosscutting nature)意味着,很难管理它们给项目中带来的风险。结果,这也经常导致两种不恰当的做法:从项目一开始就没有足够注意它们,或者是另一个极端,预防性架构和过分设计。 技术人员常常被其诱惑,倾向于完整、封闭的解决方案,即把自己能够想到的所有用例全部自动化。... 比如,运维人员希望不用关闭系统就可以重新部署或重新配置,而开发人员希望一劳永逸,无论是否有人提出过这样的需求,都要考虑应用程序在未来可能发生的任意一种演进。 作为技术人员,我们必须警惕自己更倾向于首先出现在脑海中的那种技术解决方案。我们必须和客户及用户紧密合作,共同确定应用程序中的敏感问题,并根据真实的业务价值定义详细的功能需求。引自 非功能需求的测试