【读书活动感悟分享】-特较真-《测试工程师全栈技术进阶与实践》
测试工程师为什么要懂大型网站的架构设计？ 电站搜索重构性能测试的案例分享
测试工程师为什么要懂大型网站的架构设计？这是一个很好的问题，之前了解架构知识，只是觉得测试需要了解系统架构，知道这些对测试有帮助，对了解项目和业务有帮助但对为什么要了解，并没有一个很完整的答案 ，在阅读这本书的时候，发现作者在这一方面已经有了全面的总结。
在继续往下看之前，我们可以先自己回答一下这个问题。测试工程师为什么要懂大型网站的架构设计？
对我来说，测试要懂大型网站的架构设计分为两个方面。
从功能测试的角度，了解系统架构，能对自己测试的系统有准确的认知，对发现的问题能够更容易定位，同时对于代码修改的影响范围也有自己的概念。
从性能测试的角度，需要清楚系统的架构设计和其中的技术细节，不然无法解读和分析性能测试报告。 上面的回答，我觉得是比较完善的总结，但是在测试工程师全栈技术进阶与实践这本书中，给出了对这个问题更深层次的理解。并且给出了下一阶段学习的指导方向。
本书从两个角度分析为什么测试要掌握系统架构
一。基于消息队列的分布式系统架构的测试设计
目前的项目都是分布式的系统架构，在分布式的系统架构中，为了减少各个系统的直接耦合，会引入消息队列来实现解耦， 对于这种方式的用例设计，我们可以直接站在黑盒的测试角度，完全不需要知道消息队列的情况，从业务的层面去设计用例。
但如果只这么做。测试明显是不全面的，产品在线上，系统A和系统B（消费者和生产者）之间，消息的处理速度不会完全一致，大量的生产数据又会放大这个差异，从而导致消息队列打满或者其他的情况。 ps：本次电站搜索功能重构也包括了这方面的优化。
如果要实现全面，系统的测试设计，就需要了解消息队列的基本原理，从而可以针对的设计测试用例，本次电站搜素重构性能测试的用例设计，研发和测试针对性的对单个电站大量终端和大量电站的搜索结果的情景进行了针对设计，并在测试过程中发现了问题。也佐证了了解架构的重要性。
二。缓存架构的测试设计
很多时候，我们搭建性能测试的基准厂家并开始执行性能测试的时候，往往发现，系统初期处理业务响应时间都比较长，而性能测试执行一段时间之后，系统指标和事务响应时间才趋于正常。为此，有经验的工程师通常都先用性能场景对系统进行一下“预热”。然后才真正开始测试。（又学到了）
另外，在做前端性能测试的时候，我们对与页面的打开时间通常会统计两个指标，一个是首次打开的时间，另一个是多次打开的时间，这个从缓存的角度就很好理解，结合最近的电站搜索重构，我们最数据做了很多的缓存，本次优化虽然是对缓存的数据进行优化，但是测试过程中的加载时间变化，仍是需要进行关注的，比如页面骨架屏的展示，就是因为在进入电站列表页面时的接口加载时间可能较长，为了让用户首次打开的时候体验比较好，进行了配置。骨架屏的显示时长就是接口请求回数据的时长。 这些知识在功能测试的时候不一定会起作用，但是在遇到问题分析问题的时候，会给我们意想不到的帮助。
再往更广的地方看，在现在的互联网环境下，缓存本身也是分层的，浏览器有本地缓存，网络端有CDN缓存，数据库中心前端有反向代理的缓存，应用服务器端有本地缓存，大规模的应用还有专用的缓存集群。我们要针对性的设计缓存相关的测试场景，就更需要理解缓存的架构。
三。架构知识的学习方向
上面说了架构知识学习必要性，但是架构知识的学习对于测试工程师来说，是一个不小的挑战。因为架构知识都是基于开发框架和系统底层设计的。对于测试来说是一个较难的领域。不过，对于架构知识，不同角色的工程技术人员，需要了解和掌握的知识各不相同。对于测试人员来讲，基本上，只要做到清楚原理，了解被测系统的部署架构，从测试的角度能够调用必要的接口即可。
测试人员的架构学习，应该遵循“由深度到广度”和”自上而下“ 两个基本原则。
广度是平时要多注重全领域架构知识的积累，深度是要通过实际的测试加深对架构的理解。自上而下，是指在实际测试项目中，当需要设计涉及架构的测试用例和场景是，千万不要基于点来设计测试，要首先理解上层架构设计，然后在理解架构设计的初衷和希望达成目的的基础上，再向下设计场景和用例。
本次的性能测试时间比较仓促，但是在测试过程中也接触了系统的redis状态监控和内存缓存的应用。并在开发的帮助下对我们的系统有了更进一步的了解。这些是我继续学习的方向。
总结上面的内容，我们当前的测试工作，不仅需要了解本系统的架构体系。还需要了解这个架构的优势和缺点，为什么选择使用了当前的架构。后续的测试工作也要继续广泛的学习架构知识，做到测试技能和测试知识体系的提升。