上周六应邀在天津devops峰会的质量内建专场做了一次分享，主题是《稳定性保障利器：全链路压测》。
其中关于全链路压测对质量内建的意义，我做了一个总结，如下图所示。本文基于下图做了展开描述，仅供参考。
如何理解性能测试的价值？
如标题所示，这个问题也是我大会之后思考的一个问题。
可能按照通用的思路，我们都会说提高请求处理能力，降低时延，提高用户体验，降低硬件成本。
但从质量保障全局来讲，我觉得还有其他方面的价值。
衡量价值，最简单的逻辑就是以最低的成本创造最大的价值，简单的公式就是：价值=收益-成本。
软件测试的本质是一个发现软件设计/研发缺陷的过程，整体追求的目标是更高的交付质量和过程效率。
性能测试作为质量保障范畴的一部分，其价值体现除了降低成本，提升用户体验，还有很重要的一部分就是提升效能。
为什么要这么讲呢？因为技术部门，或者说技术部门里面的测试团队，是无法直接产生可观度量价值的。
所有的技术都是为业务服务的，而业务是可以直接给企业带来商业价值。
抛开交付质量，我们可以换个角度，技术作为支撑业务目标达成的一部分，测试作为软件研发过程的一部分，如果能降低研发过程的耗时，缩短信息反馈链，这样也可以间接的促进业务目标达成，体现自己的价值。
性能测试如何提高测试效能
如上文所述，性能测试对于质量内建及提高效能的方式，在实际工作中可以从不同阶段和不同维度来实践。
现状
业务在发展过程中注定是越来越复杂的，而复杂的业务会加大理解成本，并且复杂业务几乎就等于复杂的系统技术架构。
随着互联网行业的不断发展，原来的瀑布式迭代也逐渐的敏捷化，大家都在追求快速交付可用的系统，这对于项目管理来说是个巨大的挑战，无形中又加大了项目整体的管理和交付难度（相比高质量和稳定迭代来说）。
而传统的性能测试，从需求提出到执行压测、定位分析和性能优化的过程比较长，与我们面临的现状有了巨大的隔阂。
过程
面对业务多样+架构复杂+迭代快速+管控难度大的现状，为了提高效能，我个人认为可以从如下几个方面着手来提效。
PS：仅谈性能测试的角度技术实践。
业务可识别：通过区分核心业务及应用，快速识别不同业务及应用可能存在的性能风险。
链路可追踪：通过链路追踪和监控手段，识别业务链路的变化和核心接口的流量变化情况。
结果可验证：通过性能测试自动化方式，做到核心接口性能常态化巡检，让性能基线成为测试过程的一部分。
过程可量化：通过数据实时对比和通知，让研发运维同学能够更快速的感知到性能变化带来的风险并提前预防。
目标
通过上述的手段，提高整个性能测试过程效率，尽可能覆盖更大的业务范围和应用以及请求链路，达到如下目标。
应用可信：对业务应用的变化快速感知，提高风险评估意识；
链路可信：对请求流量的变化实时跟进，及时响应变化做好预防机制；
容量可信：对系统性能有更清晰的认识，更精准的做好容量规划和成本控制；
SLA可信：对系统整体的可用性有信心，更好的保障线上系统和业务的稳定性；
文末总结
通过自动化手段提高性能测试过程效率（缩短信息反馈链），通过技术手段做到风险提前评估、变更及时响应、容量精准规划，让技术团队对线上系统的稳定性更有信心，提升技术对业务的支撑力度，来体现性能测试的价值。
标签：效能,性能,业务,测试,链路,价值,过程 来源： https://www.cnblogs.com/imyalost/p/16589950.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。