软件开发生产线 CODEARTS-如何构建高效的持续交付能力:持续测试
下载软件开发生产线 CODEARTS用户手册完整版
持续测试
第二句话来了：如果测试是好的，那么所有人都应该始终进行测试。这句话，我们今天叫做持续测试。
今天测试人员感觉到前所未有的危机感。
以前，测试人员归属于QA部门。从这个角度来说，只要是归属于质量保障的范围，都可视为测试人员的职责范围。
如今，有几条有关有效质量控制的建议：
- 让听得到炮声的人做出决策，而不是远离一线的管理者。
- Build Quality In，所有人都有责。
- 测试与架构相关，包括技术架构，以及组织架构。
- 测试的过程，是从失败中学习的过程。
- 自动化，自动化，自动化，尽可能的自动化一切该自动化的，但又不要过度的依赖于自动化，不要过度追求自动化。
下图是测试金字塔，核心是从关注测试的数量转向关注测试的质量。尤其是在持续集成之下，测试执行要求是快速闭环的。越往下的，隔离性越高，定位问题就越容易，反馈也会越快，因此应该要发现更多的问题，投入更多的精力；越往上的，反馈周期越长，运行效率越低，修复和维护的成本都很高，复杂性也随之升高，应该做的频度越少。
事实上，我们有双层的金字塔结构，上面是线上环境的测试，包括拨测、捣乱猴子测试，以及各类的性能和安全测试。
刚才说应该测试前移，投入更多的在短周期的活动；同时又说，测试要延展到生产环境，覆盖发布和线上的运行阶段。事实上，测试应该向两端延展，测试活动应该是真正贯穿在整个产品生命周期的。从这点上来讲，测试人员如果还是用原先的方法和手段，是无法处理好问题的。
那么，缺陷成本是越来越大么？我们所有的教育都告诉我们是的，包括说要从源头来保障质量，缺陷随着时间的推移，修复的成本越高；变化的成本随时间的推移而以指数级上升。但同时，敏捷又说要拥抱变化，精益建议要推迟决策，这是不是矛盾呢？
《DevOps软件架构师行动指南》中提出，问题不在于变化，因为变化总是要发生的；问题在于发生变化时，是否有能力来应对。
决定是否易于修改的因素有：
- 简单的设计，这也是极限编程的建议。
- 松耦合的架构，频繁并主动的修改设计。
- 锻炼组织的工程能力。
- 以及构筑快速反馈、快速应对变化的能力。
测试是越多越好么？自动化测试呢？
- 处于探索阶段的产品，不确定性极高，此时投入过多精力去搞测试，一味地追求测试覆盖率等指标，最后发现市场方向不对，要推翻重做，那么前面投入的测试就全是浪费，此时应该以手工测试为主。
- 当发现市场正确，快速投入人力和物力，此刻需要的是产品的快速增长，需要开始引入关键的自动化测试来保障效率和质量。
- 到产品稳定阶段，自动化测试的目的是回归，保障质量的稳定。
那么问题又来了，测试能防范所有的问题么？当然不能，这里有两种安全，一种是试图发现尽可能多的，甚至是消除错误的部分，达到绝对的安全，这过于理想，不可实现；所以我们推荐的是第二种，弹性安全，尤其是适用于云化的场景，即便是发生了错误，我们需要追求的是快速恢复的能力。
