本来计划读《需求实例化》，考虑自己打算写TDD总结文档，还是选一些相关内容，决定先读《持续交付-发布可靠软件的系统方法》（根本原因是没有书^_^）。
《持续交付-发布可靠软件的系统方法》全书51.2万字，15章，384页。在仔细读完序言部分和目录，挑选了三个最有兴趣的主题进行精读，即：测试策略（第四章），容量设计（第九章部分内容），测试数据管理（第十二章部分内容）。
1、测试策略
戴明14条之一就是“停止依赖于大批量的检查来保证质量的做法。改进过程，从一开始就将质量内嵌与产品之中”[9YhQXz]
【对于软件研发的过程改进来说，减少人工测试，尽可能考虑使用自动化的单元测试，并且内嵌到CI中。】
1.1测试象限
系统阐述了Brian Marick提出的测试象限。来为软件进行测试建模。
1.2 Happy Path
在4.2.1业务导向且支持开发过程的测试中：
* 定义：对于每个需求或者用户故事来说，根据用户执行动作，一定会找到应用程序中一个中规中矩的执行路径。
* 描述方式：就是（Gievn-When-Then）书写模型。假如[当测试开始时，系统所处状态的一些重要特征]，当[用户执行某些动作后]，那么[系统新的状态的一些特征]。【以前描述不准确，需改正】
* 引申：执行结果状态不同时，就会出现Alternate Path。引发的错误处理叫Sad Path.
* 工具：定价划分分析和边界值划分析可以帮助我们找到最小的用例集合。【单元测试需要这样的技能】
1.3 自动化测试相关
-自动化验收测试限于Happy Path行为，并仅覆盖其他一些极其重要部分。（这是高效的策略，前提是其他自动化测试很全面）
* 一般将代码覆盖率搞80%测试视为“全面的”测试，测试质量也非常重要。
* 第二条规则包含单元测试，组件测试和验收测试，单独满足，而不是累加满足
* 每个故事至少要有一个Happy Path的自动化验收测试。给开发人员充当冒烟测试，检测“是否破坏已有功能”快速反馈。
【看来我们的测试时万里长征第一步，需要继续努力】
1.4 单元测试和组件测试（集成测试）
单元测试：依赖于测试替身模拟系统其它部分。要求：
* 不应该访问数据库，文件系统与外部系统交互。
* 不应有组件间交互
* 运行非常快
【单元测试现在方向是对的，思路也是对的，时间的玫瑰o(*￣︶￣*)o】
组件测试（集成测试）:更大的测试集，连接真实的数据库
1.5 现实中情况与应对策略
新项目：理想国。1）技术平台&测试工具；2）自动化构建；3）制定INVEST的用户故事并考虑验收条件。
项目进行中：Happy Path自动化，覆盖高价值的场景。逐步补全尽可能多的场景。
遗留系统：测试你修改的代码。以及高价值的场景。
【我们的产品是各种合体，可以针对不同部分选择策略】
迭代前找到高优先级的场景。利用工具或者DSL可以场景变成测试用例。【这块感觉很难，也许是一个很好目标和方向，需关注】
管理待修复缺陷列表。根据严重、阻塞、中、低来管理缺陷。
2、容量设计
2.1 如何容量编程
高德纳的过早优化理论指出早期的预料可能是错的。也不是后期解决所有的问题。正确策略：
--为系统决定一种架构。包括：进程、网络边界和IO
--使用真确的模式，避免影响容量和稳定性的反模式。书《Release it！》
--研发过程中，可读性（清晰简单）优先。在没有测试数据时，避免过早优化。
--选择高性能的算法和数据结构【听过一句更好的描述：数据结构决定性能上限，算法决定性能下限】
--注意线程阻塞。
--自动化测试断言所期望的容量级别。
--修复调测中问题。
--尽可能用真实数据度量性能。
2.2 容量度量
-扩展性测试：扩容能力下，响应时间和并发数用户的指标。
持久性测试：用来检测内存泄露和稳定性问题。
吞吐量测试：每S处理多少事务。
负载测试：在生产环境情况下，系统容量。
完全负载生产环境是不可能的，需要做流量分析，结合经验和直觉来表达尽可能接近真实环境的模拟。
【以前性能测试关注吞吐量和响应时间是不够的】
2.3 自动化容量测试
目标：创建比较现实的类生产环境的负载；选择并实行代表性且现实生产中非正常负载状态的场景。
还有一种有效中方法“识别系统中代价最高的事务，然后在系统中把他变成两三倍的数量”（《Release It！》）。【这个思路棒，可以作为后续的内容】
对于我们来说，有两种方法更为实用：实用录制的交互模板；使用容量测试桩开发测试
2.4 将容量测试加入到部署流水线
避免容量的过度设计；尽早发现容量的问题，进行修复。【这也是个目标】
2.5 容量测试附加价值
把容量测试设计为组合式，基于场景的测试。可以用来诊断问题、预测问题并找到办法解决问题。
3 测试数据管理
主要有两点：测试性能-尽可能快的完成；测试独立性-收入受控，才能评估出他的输出。
3.1 为单元测试进行数据库模拟
单元测试不实用真正的数据库是非常重要的。可以考虑两种策略：
1、测试替身对象来代替访问数据库的代码。【对于C++后来来说，就是gtest+gmock的方式。】
2、使用假的数据库。作者建议内存型数据库例如H2，SQLit，Java。【我们的MOCKDB也是属于这种思路，但比这个开源数据更有优点，看来我们找到最优解了。棒！以后写总结】
3.2 管理测试和数据耦合
有三个方法来做测试设计:
-测试独立性：测试的数据只对该用例可见。【Mockdb的测试框架成功做到这点】
-适应性测试：先检查环境，从环境中获取数据进行测试。
-测试顺序性：按照已知的顺序进行测试，并且具备依赖性。
作者强烈推荐第一种。【看来我们的测试框架是最优选择】
3.3 连贯的测试场景
作者认为这是需要抵制的诱惑。这种耦合会导致设计困难，设计失败后会造成一系列的影响。【这个值得思考和注意】
总结
作为实用主义者，选择自己最有兴趣的三个部分，从泛读，到精读，然后整理并输出笔记。前后耗时5小时，收获颇丰，值！
