《应用程序性能测试的艺术 第2版》第七章 终端用户体验监控与性能 摘录
终端用户体验不是从数据中心对性能指标的简单监控，而是决定了公司对于应用的投入是否成功。
书中一再强调没有绝对的性能评判标准，关键性能指标的确定需要依照用户的期望而定，而且可以肯定的是用户的期望肯定随着时间的发展而越来越高。
用户体验是应用性能的重要一部分，值得格外关注。
由于互联网浏览器应用的大行其道，本章重点关注与此相关的外部监控。
什么是外部监控？在应用部署架构边缘设施之外使用各种工具和技术对IT应用的响应时间进行监控和解读。
为什么要从外部进行监控？面向服务的架构，分布式与计算托管以及无处不在的第三方组件依赖。这些依赖都和应用性能密切相关，同时也和业务价值紧密相关。所有这些核心应用之外通过外部组件提供的功能都需要更好地管理，而外部监控很好地满足了这个需求。外部监控的关键优点：
- 影响分析：可以帮助运营团队更有效地对性能问题进行优先级排期。
- 可预测性： 外部监控可以在没有基础流量的情况下对应用进行性能测试。
- 主动获取特定功能和过程的性能数据的能力。
- 合理的测试设计可以获得交易、页面、独立对象以及子对象层面的客观数据。
- 主动监控可以更好地理解上下文和进行目标设定。
- 获得对外部因素更加全面的理解：第三方服务等级管理；网络服务提供商的等级效应；对关键用户性能指标的验证和保证。
在外部监控过程中，如果出现的问题超出了运营团队能够处理的范围，能够获得一手数据也可以帮他们更好地向第三方公司提出质询。外部监控就好像“煤矿中的金丝雀”。使用恰当的话，可以提供一些影响层面的分析并且可以定位造成问题的大致区域。对基于上下文的应用性能相关性管理来说非常重要。
外部监控分类
主动监控
主动监控也被叫做综合监控，主动监控会定期安排，使用一些测试节点重复执行自动化的测试脚本。使用了和性能测试自动化类似的技术，即用工具来回放一些用例脚本，不同的地方在于这种回放一般只会在一台设备上使用一个虚拟用户来执行，而且通常会涉及完整的UI和浏览器操作。（这么说这是一个完整的用户操作模拟？）这种类型的工具通常会提供基于WEB管理终端来控制和管理多个远程代理。
可以在故障发生之前对于一些即将发生的错误进行告警（这应该是外部监控策略的一个目标）。
主动监控提供以下关键指标：可用性和总体响应时间（和真实用户体验到的响应时间还是有差别）
被动监控
被动监控也叫做真实用户监控（RUM）或者用户体验监控（UEM），被动外部监控依赖于注入在页面里面的代码片段，或者是应用服务器动态注入到客户浏览器的一些代码片段所提供的数据。
被动监控通常是基于对终端用户的浏览数据进行抓取的，当然对于一些其他客户端而言，一些定制的插件也可以达到同样的效果。和主动监控不一样，被动监控依赖用户流量。被动监控原理： 对于浏览器客户端而言，最常用的被动监控技术就是在web页面的头部加入JavaScript代码或者标签。在大多数情况下，这些标签会一直保存在被植入的页面当中，程序员可以使简单的备份或者全局Include指令来实现。EUE工具供应商现在越来越多地使用动态植入技术，通过网站的应用服务器在用户请求页面动态植入JavaScript来实现这个功能。
被动监控工具的实现都差不多，大多数被动监控工具都是基于标准的W3C导航指标实现的，本质的区别主要在：
主动和被动监控的优缺点
互联网应用的外部监控工具选择
考虑因素：
- 被监控的应用所使用的技术
- 用户特征：地点，浏览器，无线设备
- 应用特征以及组件：第三方内容，多媒体，SMS
- 性能增强措施：比如CDN，ADC（浏览筛选，A/B测试）
- 公司内部技术资源：外包还是自己实施
- 应用开发策略和目标
- 性能管理策略（自研还是外包）
- 考虑机会和风险之后的可用预算
- 技术和工具带来的假设条件
尽可能使用最少的工具组合实现以下功能：
选择标准
技术覆盖点：检测和隔离问题的能力，支持不断进化的网站组件，脚本过滤和自定义编码功能，对登录，消息系统的验证，以及流好媒体的监控。对于关键性能因素和页面模块的自动分析和评分功能。能和第三方告警系统集成。截屏以及对于失败或成功的路径跟踪功能。分析和跟踪个体对象性能的能力。测试复杂交易的能力。
- 工具在脚本、执行以及报告方面的使用难易程度，供应商的支持力度。
- API
- 报告灵活性
- 成本
- 灵活性/测试场景范围
主动监控工具选择余地比较小。
被动监控工具选择考虑以下几点：
- 独立的还是集成的
- 实时报表
- 全流量还是流量采样
- 可用API以及API粒度
- 告警功能
- 浏览器和设备的覆盖率
- 手工植入还是动态注入
- 页面还是对象层面的监控
- 用户时间抓取
- 完整的用例还是单页面支持
- 可扩展性
- 业务指标
- 报表功能
- 商业许可模型以及经济性
创建外部监控的测试框架
考虑因素
- 应用的用户分布在哪里：现在和未来
- 不同的用户群体行为有何不同？
- 流量的每日、每周、每月分布模型是怎样的？
- 浏览器版本和无线设备有哪些？
- 对于新兴市场，公司的业务发展策略是怎样的？
- 公司在无线设备使用以及开发iOS和Android原生应用方面的发展策略是怎样的？
- 在所有关键市场，目标用户的国内外的主要竞争对手有哪些？
- 世界不是一成不变的，需要考虑文化/行为习惯对于设备、购买行为以及使用上面的影响。
- 监控类型要考虑的因素：多维度，APM集成，集成，全过程的测试负载报告。
主动监控的特有设计
- 多维度：多个地点发起测试，尽量避免二级区域（如本地数据中心）
- 频率：覆盖率，输出数据的的需求本身以及成本管理。
- 代理： 浏览器在不同工作模式下会很不一样，因此在测试的时候需要考量网站的设计，考虑到不同浏览器和版本带来的影响。
被动监控的特有设计
被动监控的关键意义在于发现那些盲点，并做出响应的补偿措施。
对性能结果进行解读
在选择工具的时候必须特别注意，将应用的特性、技术细节特征、用户流量特征、关键市场的地理位置（已经存在的及计划拓展的）等多种因素考虑在内。在根据已有的最佳实践为外部监控搭建好测试框架之后，你需要对至少一个业务整月的数据据进行收集和分析。这些数据可以作为通常情况下的业务参考基线。
通常一个应用在性能表面上会按照一周的周期重复发生。这种重复模式为应用的整体性能特征提供了一个宏观的指示，比如容量问题或者是应用服务某个特定用户群体存在的大致问题。这些最初的发现可以为后续的性能策略提供很好的方向指引。
假设应用的整体性能表现稳定，我们就可以为应用设定恰当的关键性能指标(KPIs)以及相关的SLAs.
基于web的电子商务应用的关键性能指标
KPI的制定需要参考很多因素：
- 在相关业务领域内获取的性能排名最前 的应用最佳实践值，参考那些行业领头羊的性能数据，还有业界专家的建议。
- 主要竞争对手的性能。
- 网站的历史性能。
- 关键用例，也就是那些和业务价值关系最大的用例(直接营收来源，减轻业务开销的行为，带来潜在价值，对于品牌感知很重要的功能，关键页面，子页面性能）
- 必须保证对所有KPI进行周期性、系统性的评审。评审过程中需要考虑以下几点：
- 历史性能数据和存在值的比较。
- 所有定义的指标和业务流程的发展趋势。
- 关键竞争对手和行业领头羊的站点性能和发展趋势。
- 硬指标
- 外部：对不同类型的终端设置响应目标，包括ISP环境（最优）、使用不同带宽的PC和无线设备终端用户、缓存和非缓存用户，整体页面响应时间和浏览器渲染时间。外部的KPI和SLA应该包括关键用例，关键页面，第三方对象和组件。
- 内部： 设置并管理内部KPI指标（基于基础设施的）
- 软指标：关键浏览器版本、操作系统、屏幕分辨率组合以及关键无线设备类型等因素的可视化用户分布。页面链接（内/外部）的用户热度。
应用性能指数：是根据度量应用响应从而来比较终端用户的满意度的方法。
管理信息
在对主体KPI设定以及信息发布模式（信处同步看板、每日邮件、短信告警）取得共识之后，你就需要考虑怎样将最原始的性能数据处理成最具相关性的汇报信息:
- 数据准备
- 统计分析注意点：可用性，响应时间，一致性，
- 关联度
有效的报告：相关，及时，易理解
竞品分析：要理解网站性能和关键竞争对手的对比情况，有一些因素要考虑到：数据维度，设备和传输模式，地理位置，选择条件。
告警: 工具产生的告警是否能够指导实际工作。