我们需要观察客户并把每次失败当成一个吸取教训的机会来积极学习，适当地依靠像QA这样的组织，预期系统失败，并针对这些失败做好充分的准备。
从失败中学习
我们要不断地从错误和成功中学习。观察客户或用A/B测试验证。建立事后分析过程，在低故障率环境下采用假设失败的方法。
错误不可避免，但是不能犯同样的错误。如果找不到性能差的查询，结果直到进入生产环境并导致网站中断才发现，那么就必须要找到真正的根本原因并修复。
使用QA降低成本
我们应该利用QA降低产品交付成本，提高技术吞吐量，发现质量趋势，减少缺陷，但不提高质量。在任何可能机会下，通过专人聚焦测试而不是写代码以提高效率。利用QA从过去的错误中学习。
每当测试活动获得超过一个工程师的价值输出时，就应该雇佣一个QA人员。通常，QA人员的成本比工程师要低。
因为系统质量无法测试，所以QA并不会提高质量，但是可以避免缺陷率的增长速度超过快速雇佣期间的组织增长率。
QA的主要作用是以较低的成本帮助发现产品中的问题，从中提高工程速度好增加缺陷检出率。
不能回滚注定失败
必须具备代码回滚能力。确保所有版本的代码都有回滚能力，在准生产或者QA环境演练，必要时在生产环境用它来解决客户的问题。
在软件变更之前，通过修改数据库模式，从而验证向后兼容。
- 数据库结构的变更尽可以增加——只应该增加而不删除列或者表，知道下一版本代码发布，它明确不再依赖于这些列。
- 数据库变更脚本化并经过测试——代码发布涉及的数据库变更必须提前写好脚本，不能采用手工操作。这应该包括回滚脚本。
- 团队需要在QA或者准生产环境中测试回滚过程，以验证没有漏掉什么将阻止回滚的内容。
- 需要在一定的负载条件下测试脚本，确保当应用使用数据库时仍然可以执行脚本。
- 限制应用中SQL查询的使用——开发团队需要纠正所有模糊不清的SQL查询，去除所有的SELECT * 查询，并且为所有的UPDATE语句添加列名。
- 数据语义变化——开发团队不能改变版本中数据的定义。例如，新版本的应用中不能添加数据库中没有的状态，直到先发布了代码来处理新状态为止。
- 上线/下线——应用应该有一个基于外部配置的框架，该框架允许特定用户可以访问代码路径和功能。该设置可以在配置文件或数据库表，允许基于角色和随机百分比的方式控制访问。这个框架允许针对一组有限的用户进行beta测试功能，并允许在某功能出现重大错误的情况下，快速删除该功能的代码路径，而不必回滚整个代码库。
确保任何变更可以向后兼容所带来的额外研发和测试投入，是投资回报率最大的工作。
扫一扫
439
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
