人力资源又称劳动力资源或劳動力，是指能够推动整个经济和社会发展、具有劳动能力的人口总和人力资源的最基本方面，包括体力和智力如果从现实的应用形态來看，则包括体质、智力、知识和技能四个方面

人力资源管理，就是指运用现代化的科学方法对与一定物力相结合的人力进行合理的培训、组织和调配，使人力、物力经常保持最佳比例同时对人的思想、心理和行为进行恰当的诱导、控制和协调，充分发挥人的主观能動性使人尽其才，事得其人人事相宜，以实现组织目标

职务分析是一种狭义的工作分析，它是相对某一企事业组织内部各岗位工作嘚分析即分析者采取科学的手段与技术，对每个职务同类岗位工作的结构因素及其相互关系进行分解、比较与综合，确定该职务岗位笁作的要素特点、性质与要求的过程

心理测验是心理测量的一种具体形式，实质上是行为样组的客观的和标准化的测量也有人把心理測验叫心理测评。

人力资源规划所谓人力资源规划是预测未来的组织任务和环境对组织的要求以及为完成这些任务和满足这些要求而提供囚员的过程其目的是为了工作者和组织的利益，最有效地利用短缺人才

人力资源成本是一个企业组织为了实现自己的组织目标，创造朂佳经济和社会效益而获得、开发、使用、保障必要的人力资源及人力资源离职所支出的各项费用的总和。

招聘是指“招募”与“聘用”的总称为企事业组织中空缺的职位寻找到合适人选。实际中间夹着甄选

甄选是招聘的后续工作，也是招聘的延伸所谓甄选就是从夶量的申请人中挑选出最有可能有效胜任工作或组织认为最合适的人员的过程。

劳动关系是指劳动者与劳动者的录用者之间在劳动过程中所发生的劳动权利与劳动义务关系这是狭义的劳动关系，也是劳动立法意义上的劳动关系目前，我国的劳动关系主要包含以下两种基夲情况：即劳动关系和劳资关系所谓一般劳动关系是指建立在社会主义公有制基础上的企、事业单位及其它组织的行政与劳动者个人之間的劳动关系；而劳资关系则是指在中国目前非公有制经济单位及其它组织与劳动者主体之间形成的劳动关系。

劳动合同就是员工与组織确立劳动关系、明确双方权利和义务的协议，是组织和员工之间确立劳动关系的法律凭证

培训目标企业培训目标包括三个方面：增加知识、熟练技能和善于处世。实际上就是要改变员工的行为这种行为的改变包括三个领域，即认知领域、情感领域和技能领域

工作绩效，是指他们那些经过考评的工作行为、表现及其结果

考核标准绩效考核标准是绩效考核时为避免主观随意性而不可缺少的前提条件。績效考核标准必须以职务分析中制定的职务说明与职务规范为依据因为那是对员工所应尽职责的正式要求。

薪酬是企业付给员工的劳动報酬它主要以工资（含奖励工资）和福利两种形式表现出来。社会保障制度是指社会成员因年老、疾病、失业、生育、死亡、灾害等原洇而遇到生活困难时从国家、社会获得一定的经济帮助的社会制度。

职业生涯是指一个人一生中的所有与工作相联系的行为与活动以忣相关的态度、价值观、愿望等的连续性经历的过程。没有成功与失败区别也没有进步快慢之别。

职业生涯管理主要是指对职业生涯的設计与开发虽然职业生涯是指个体的工作行为经历，但职业生涯管理可以从个人和组织两个不同的角度来进行

养老保险制度是国家和社会根据一定的法律和法规，为解决员工在达到国家规定的解除劳

1、在哪个范围内的计算机网络可稱之为局域网：（A）

2、一座大楼内的一个计算机网络系统属于（B ）

3、广域网覆盖的地理范围从几十公里到几千公里。它的通信子网主要使用( B )

4、下列不属于广域网的是：（ A ）

D、X.25分组交换公用数据网

5、LAN是的英文缩写（C）

6、局域网是在小范围内组成的计算机网络，其范围一般昰（D）

7、分布在一座大楼或一集中建筑群中的网络可称为( A ) 。

8、在计算机网络中一般局域网的数据传输速率要比广域网的数据传输速率(

9、分布式计算机系统与计算机网络系统的重要区别是( D)。

D、计算机在不同的操作系统下工作方式

10、计算机网络的主要功能有: ( A )、数据传输和進行分布处理。

B、提高计算机的可靠性

D、使用服务器上的硬盘

11、计算机网络中可以共享的资源包括（A）

A、硬件、软件、数据、通信信道

B、主机、外设、软件、通信信道

C、硬件、程序、数据、通信信道

D、主机、程序、数据、通信信道

12、通信子网为网络源节点与目的节点之间提供了多条传输路径的可能性路由选择是( C )。

A．建立并选择一条物理链路B．建立并选择一条逻辑链路

C．网络节点收到一个分组后确定转发汾组的路径 D．选择通信媒体

13、计算机网络通信的一个显著特点是（B）。

14、计算机网络是计算机技术和通信技术相结合的产物这种结合开始于( A )。

B、20世纪60年代初期

C、20世纪60年代中期

15、计算机网络由通信子网和资源子网组成下列设备中属于资源子网的是

参考高楼的《性能测试实战30讲之問题问答整理》觉得他写的好，但是看原文一问一答的方式比较散乱，我就重新梳理一下简单加点自己的想法，主要是抽取核心的內容方便自己学习和查阅：

一、性能测试的概念到底是什么

性能项目分为如下几类：

1. 新系统性能测试类：这样的项目一般都会要求测试絀系统的最大容量，不然上线心里没底

2. 旧系统新版本性能测试类：这样的项目一般都是和旧版本对比，只要性能不下降就可以根据历史數据推算容量对调优要求一般都不大。

3. 新系统性能测试优化类：这类的系统不仅要测试出最大容量还要求调优到最好。

二、TPS和响应时間之间是什么关系

对于三者关系，可以结合这么个场景进行理解：TPS和响应时间在理想状态下都是额定值（联想运行一个压力测试场景来栲虑）（以上高速的入口为例，每个入口每秒钟只能进1辆车）把入口看成线程池如果有20个入口，并发数只有10的时候TPS就是10，而响应时間始终是1秒说明并发数不够，需要增加并发数达到TPS的峰值

理解了上面三个要素的意义之后，就能推算出它们之间的关系（只是关系而巳不是计算公式）：

QPS（TPS）= 并发数/平均响应时间 一个系统吞吐量通常由QPS（TPS）、并发数两个因素决定，每套系统这两个值都有一个相对极限徝在应用场景访问压力下，只要某一项达到系统最高值系统的吞吐量就上不去了，如果压力继续增大系统的吞吐量反而会下降，原洇是系统超负荷工作上下文切换、内存等等其它消耗导致系统性能下降。

另外原文的图比较形象直接引用过来：

三、怎么理解TPS、QPS、RT、吞吐量这些性能如何将没有指标的工作量化？

尽量不用吞吐量这个词（每个人理解这个词的含义都不一样）我们性能测试尽量用具体量囮的如何将没有指标的工作量化表示吞吐量，比如TPS

这些如何将没有指标的工作量化关系的理解可以结合上面第二条内容，在这里补充一丅QPS、TPS、RPS的区别：

QPS：Queries Per Second意思是“每秒查询率”是一台服务器每秒能够相应的查询次数，是对一个特定的查询服务器在规定时间内所处理流量哆少的衡量标准对应fetches/sec，即每秒的响应请求数也即是最大吞吐能力；一般习惯用在数据库或单指服务器的评估能力方面，平常只用TPS就够叻

TPS：是TransactionsPerSecond的缩写，也就是事务数/秒它是软件测试结果的测量单位。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程客户机在发送请求时开始计时，收到服务器响应后结束计时以此来计算使用的时间和完成的事务个数；

1、Tps即每秒处理事务数，包括叻：
  2）服务器自己的内部处理
  3）服务器返回给用户
  例如：这三个过程每秒能够完成N个这三个过程，Tps也就是N；
2、Qps基本类似于Tps但是不同的昰，对于一个页面的一次访问形成一个Tps；但一次页面请求，可能产生多次对服务器的请求服务器对这些请求，就可计入“Qps”之中

例洳：访问一个页面会请求服务器3次，执行3次select操作即一次“PV”（页面浏览），产生一个“R”产生一个“T”，产生3个“Q”

下面列出各项如哬将没有指标的工作量化的含义：

如何将没有指标的工作量化真的太多了我们最常用的其实就是RT和TPS，一切讲究简单明了过多的如何将沒有指标的工作量化和标准只会把人绕晕，增加沟通成本

四、企业选择性能工具应该考虑哪些方面？以及性能测试工具中是否必须含监控

大概会考虑怎么几个方面：
- 学习成本：对人员的水平要求，培训时间成本等；
- 脚本编写：能否录制测试脚本是否支持GUI操作等；
- 安装蔀署成本：是否支持一键安装，是否支持docker等；
- 是否免费：开源工具一般都是免费的；但是很多收费工具也的确物有所值；
- 是否支持多协议：比如是否支持 HTTP 协议、RPC 协议等等
- 测试场景：是否有链路、场景编排管理支持支持将请求编排成业务场景，即常见的一串联场景；
- 流量控淛：支持纵向的上下游链路的请求量逐渐减少，整体呈现一个漏斗模型；也可以是横向的；
- 压力控制：指压测时并发用户数、 TPS 的控制等；
- 数据驱动：大量的测试数据的参数化；
- 分布式支持：支持压力机集群；
- 测试报告：压测结果是否能够图形化展示提供美观且丰富的测試报告；
- 二次开发的成本：由于时间或人力关系，也需要考虑二次开发成本；
- 性能开销：执行机开销、软件可靠性、执行效率、业务处理能力等

Dashbord插件也能输出完整的报告，或者选用基于Jmeter的压测平台（）如果对业务整体场景流程要求高并且企业预算够（不谈破解版），一般选Loadrunner毕竟图表好看，界面脚本录制方便对局方（有时甲方只认可Loadrunner）有说服力。

云测试平台选择（自建还是购买)：

• 首先权衡场景公司昰否业务需求达到这个量级，不为测试而测试
• 短期长期思考：短期或没成熟测试团队，可购买服务长期推荐自建，完成技术栈积累

順便提供一下我们常用的一些性能监控产品：

我觉得一个好的监控系统大概需要包括以下几个方面：

• 关注于整体应用的 SLA：主要从为用户服務的 API 来监控整个系统；
• 关联如何将没有指标的工作量化聚合：把有关联的系统及其如何将没有指标的工作量化聚合展示。主要是三层系统數据：基础层、平台中间件层和应用层并提供一个全局的系统运行数据大盘，帮助快速找到系统瓶颈
• 快速故障定位：快速定位问题需偠对整个分布式系统做一个用户请求跟踪的 trace。

       只有做到了上述的这些关键点才能是一个好的监控系统而显然目前的测试工具所带的监控昰不能满足的。另外测试工具本身在做监控也有其局限性如 jmeter 在压测量较大的情况下回传测试结果 Master 节点会容易成为瓶颈。专业的事应该由專业的工具或系统来做（目前无论开源还是商用都会有大量成熟的监控产品）性能测试工具应该专注于压测本身，分出资源来做监控得鈈偿失（容易监控与测试互相干扰尤其流量方面）。

五、如何正确理解并发的概念

问题一：如何理解“服务端的并发能力”这一描述？

       首先我们从数据视角来理解可以把服务端程序用一个模型来看待，即由「网络 API 请求」所驱动的服务端的领域特征是大规模的用户请求，以及 24 小时不间断的服务但某种意义上来说更重要的原则是：坚决不能丢失用户的数据，即他认为已经完成的业务状态服务端必须保证其业务状态的可靠性，这时业务状态才持久化写入到外存所以对于服务端来说，存储至关重要它不只是极大地解放了处理效率，吔是服务端的性能瓶颈所在几乎所有服务端程序扛不住压力，往往都是因为存储没有扛住压力

       在衡量服务端的性能，我们还是要服务端视角来看主要以 TPS 为主来衡量系统的吞吐量，如果有必要用并发用户数来衡量的话需要一个前提，即响应时间（RT）因为在系统压力鈈高的情况下，将思考时间（等待时间）加到场景链路中并发用户数基本还可以增加一倍，因此用并发用户数来衡量系统的性能没太大嘚意义也不专业。

       对于web项目而言服务端是整个项目的关键，是咽喉要道因此也是性能测试的重点。其测试目的当然是要摸清这个要噵能同时走多少人（注意这里的人不是在线用户数、并发用户数而是服务器能处理的事务），因此TPS最能描述服务端的并发能力（TPS、响应時间和并发数的关系可以关注上面所提到的公式）

问题二：为什么不提倡使用“绝对并发”和“相对并发”的概念呢？

       这两个概念对于峩们关心的性能并没有太多的帮助反而让人有点无从使用（概念难懂，加重内部沟通难度价值不大）。而在线人数并发数简单明了，很好理解有利于沟通，是性能测试必备如何将没有指标的工作量化之一

问题三：为什么不推荐用 CPU 来计算并发数？

       并发数是业务逻辑層面的而CPU只是众多软硬件环节中的一环，即使可以借鉴肯定也是很粗略的估计，在实践中使用价值不大没有推广使用的必要。

       比如單核CPU情况实际上是只有一个的，在一个特定时刻也只可能有一个程序跑在一个CPU上(因为寄存器只有一组)但是我们在上层观察到的却是系統上好像同时运行着那么多的程序，这实际上是操作系统用进程这个概念对CPU做的抽象

       同时如果你了解「阿姆达尔定律」，就知道多处理器并行加速总体程序受限于程序所需的串行时间百分比，超过一定的并行度后就很难进行进一步的速度提升了。并不符合线性关系吔无法估算的。

       再说服务端程序性能依赖不仅仅是底层的硬件其依赖的基础软件还包括：操作系统、编程语言、负载均衡、中间件、数據库或其他形式的存储等。在第一个问题中提到了几乎所有服务端程序扛不住压力往往都是因为存储没有扛住压力。

六、为什么线程递增过程不能断构建分析决策树的关键是什么？

问题一：为什么线程递增过程不能断

       这里涉及经常提到的性能分析方法 ——「趋势分析」，分析性能数据趋势需要对一个时间序列数据的分析一般采用「线性回归分析」算法。回归分析研究的是多个变量之间的关系它是┅种预测性的建模技术，它研究的是因变量（目标）和自变量（预测器）之间的关系这种技术通常用于预测分析，时间序列模型以及发現变量之间的因果关系
       假设有 N 个样本点，这里我们可以简单理解线性回归算法就是求一条直线 Y=f(X)使得各点到这个曲线的距离的绝对值之囷最小。在这种技术中因变量（TPS）是连续的，自变量（线程数）可以是连续的也可以是离散的回归线的性质是线性的。
       但在性能测试Φ由于系统本身的最大 TPS 上限是固定的，即服务端的处理能力（容量）是固定的如果自变量（线程数）压力过大，那么系统平均处理时間（响应时间）会被拉长不过这个时候其实瓶颈早就出现了。
       所以在场景压测中的自变量（线程数）递增一定需要是连续的并且在递增的过程中要有梯度的，且场景中的线程递增一定要和因变量（TPS） 的递增有比例关系且不是突然达到最上限，这样才能准确找出系统的瓶颈点如果中间断开，数值就会出现偏差（响应时间会在采样中加入了偏离过大的值TPS采样也随着偏离，最后造成整体分析偏差）

问題二：构建分析决策树的关键是什么？

       决策树基本上就是把我们以前的分析经验总结出来在做决策树的时候，一般会经历两个阶段：构慥和剪枝

• 构造的过程就是选择什么属性作为节点的过程构造的过程就是选择什么属性作为节点的过程；
• 剪枝就是给决策树瘦身，这一步想实现的目标就是不需要太多的判断，同样可以得到不错的结果之所以这么做，是为了防止“过拟合”现象的发生

从性能分析角度來理解：

• 构造：需要根据经验是对架构的梳理，是对系统的梳理是对问题的梳理，是对查找证据链过程的梳理是对分析思路的梳理；
• 剪枝：需要对不同时间序列性能数据的相关性分析，其核心就是要理解各个性能如何将没有指标的工作量化的关系同时进行证据链查找，根据数据的变化来推断得出各种结论比如故障判别、根因分析等。

       构建分析决策树的关键好比如何画一棵树先确定主干（主要流程），然后添枝干（组成部分）最后画树叶（定位问题）。从上到下从左到右，拆分......

       从性能瓶颈判断分析的角度入手是性能从业人员該有的逻辑。每次我们分析一个性能问题时逻辑总是这样的：

七、代理录制的逻辑是什么？当访问网页时为什么第一个请求至关重要？

问题一：代理录制的逻辑是什么

你也许听过这样一句至理名言：“计算机科学领域里的任何问题，都可以通过引入一个中间层来解决”TCP/IP 协议栈是这样，而代理也是这样

所谓的代理(Proxy)是 HTTP 协议中请求方和应答方中间的一个环节。既可以转发客户端的请求也可以转发服务器的应答。不管是在本地代理还是远程代理都是通过代理的设置，在客户端和服务端之间插入一个中间件中间件接手客户端的请求并轉发到服务端，说白了就是端口映射（Port mapping端口映射工作在传输层，重定向工作在应用层）

代理常见种类：匿名代理、透明代理、正向代悝、反向代理。

代理可以做的事：负载均衡、内容缓存、安全防护、数据处理

       此处简单理解 JMeter 录制脚本则通过代理是通过转发数据包并拦截上下行的数据解析生成脚本，但录制出来的脚本都是原始的 http 请求并没有经过适当的封装，所以录制功能比较简单普遍Loadrunner也有代理录制。

       在性能测试的过程中有很多新手对录制的逻辑并不清楚。代理录制的这个动作他们也可以很快学会但是很快就忘记了，我曾经给一些人手把手教过如何做代理录制结果第二天就不记得了。其实并不是不记得动作而是出了问题，脑子里没有判断问题的逻辑所以根夲无从下手排查。

       另外你需要注意的是，录制功能并不是性能测试工具必备的功能对性能测试工具来说，关键功能是能实现模拟批量嘚真实请求逻辑至于脚本是如何实现的，怎么做都是可以的所以我们可以用其他的工具，比如说BadBoby、Fiddler、Wireshark 抓到交互请求再放到 JMeter 或Loadrunner中实现腳本，也完全是可以的

       当然没有脚本就无从实现压力，所以脚本的实现是性能测试工程师必备的基础技术理解原理也是必须的。

问题②：当访问网页时为什么第一个请求至关重要？

实际上对浏览器来说，他们做的事情就是把一个URL变成一个屏幕上显示的网页。这个過程是这样的：

1.浏览器首先使用 HTTP 协议或者 HTTPS 协议向服务端请求页面；

2.把请求回来的HTML代码经过解析，构建成 DOM 树；

4.最后根据 CSS 属性对元素逐个进荇渲染得到内存中的位图；

5.一个可选的步骤是对位图进行合成，这会极大地增加后续绘制的速度；

6.合成之后再绘制到界面上。

       简单理解浏览器的工作原理就很容易回答这个问题了第一次请求需要构建 Dom 树（内存中的数据结构），而这棵 DOM 树其实就是前端程序的业务状态沒有第一个请求创建的DOM树，后面的请求就没有地方放了

八、HTTP的GET和POST请求，在后端处理中有什么不同断言的作用及如何使用断言？

问题一：HTTP的GET和POST请求在后端处理中有什么不同？

 get请求一般是向服务器索要数据（理论上是关键看get执行的业务操作是什么），post请求是向服务器传送数据的浏览器限制了get的传送量（HTTP协议规范没有对URL长度进行限制。这个限制是特定的浏览器及服务器对它的限制IE对URL长度的限制是2083字节），post可以大量的把数据传给服务器（理论上讲POST是没有大小限制的，起限制作用的是服务器的处理程序的处理能力【Tomcat默认2M】）一般情况丅get请求，请求体是空的请求只发一次 ，如果是post请求数据会放入请求体中，并且会根据请求头里content-length的长度分两次或多次传给服务器直到與content-length的长度相等时断开传送，get和post请求服务器数据可以说都是不安全的传送和接收都是明文以字符串形式交互数据的，想要安全请求之前需要加密处理。

       一般对数据请求频繁数据不敏感且数据量在普通浏览器最小限定的2k范围内，这样的情况使用GET其他情况使用POST

问题二：断訁的作用是什么？如何使用断言

断言用的是幂等性原理：

一次和多次请求某一个资源应该具有同样的副作用（对资源变更带来连锁反应戓影响）：f(x) = f(f(x))。

系统解耦后系统间服务调用存在三种状态（前两种是明确的）：

- HTTP GET 方法用于获取资源，不应有副作用所以是幂等的。
- HTTP POST 方法鼡于创建资源所对应的 URI 并非创建的资源本身，而是去执行创建动作的操作者有副作用，不满足幂等性
- 只有 POST 需要特殊处理，其他都具囿幂等性
- 前端生成 token后端存（唯一约束）

断言（又称检查点）是为了校验请求的返回值是否符合期望的结果（涉及到业务逻辑的断言需要對响应内容进行检查，包括关键字检查、或者数据处理逻辑结果检查等）只有增加合理的断言，才可以做性能测试如果不加断言就不知道业务请求是否正确，再加没有断言TPS会很平稳对实际压测结果意义不大。 

九、关联和断言的逻辑是什么它们取数据的特点又是什么？

关联：有关有联该数据一定是根据前面的业务获取的，是一个变化动态的从服务器获得的，否则就可以在脚本中直接写好变成一個参数了；同时该数据也一定是后面业务得以进行的必须输入，否则就没有存在的意义了；因此关联数据起了一个承上启下的作用。取數据特点从服务器返回信息中取数据，这个数据是动态的且是后续业务必须的输入数据，需要继续使用的假设一个业务场景由多个請求构成，那么关联可以理解为前一个请求的输出作为后一个请求的输入并且可以将关联的值参数化，例如TokenjobId等；关联示意效果图如下：

断言：断言的逻辑可参考上一问题中的幂等性。一个请求从执行开始到结束之中所经历每个步骤都可以“暂停”，那么暂停的这个动莋即为断言通过断言你可以知道代码的运行逻辑，对应的输出是否合理Debug的好帮手。断言美其名曰一言断分晓明查是对是错矣。提取垺务器返回的可判断业务成功的数据对其进行判断，从而获知业务是否成功取数据特点，也是从服务器返回信息中取数据在业务成功时该数据是一样的，主要用于判断判断结束后一般不会继续使用。

十、为什么参数化数据要符合生产环境的数据分布要关注组合逻輯关系？

问题一：为什么参数化数据要符合生产环境的数据分布

 性能模型中的业务模型是真实场景的抽象，即需要的数据通常都是从生產环境中的数据中统计来的其关键就是「数据必须保证仿真」。那么性能测试的时候我们需要特别注意压测流量以及相关的数据必须保证它们的多样化和代表性，否则会导致测试结果会严重失真压测本身就是服务于生产环境，所以参数化也要依赖业务逻辑故在参数囮之前，需要分析真实业务逻辑中如何使用数据再在工具中选择相对应的组合参数的方式去实现。比如当使用相同的测试数据进行重複测试时，如果压测请求不够大那么各种缓存可能会严重影响测试结果。

参数化的数据分布要考虑顺序、随机、唯一等分布方式作用：

3、符合性能压测价值，测试结果更真实；

问题二：为什么参数化数据要关注组合逻辑关系而不是随意设置组合？

       因为参数化数据的逻輯组合关系会直接影响参数化数据的分布情况即数据是否均匀？数据是否稳定是否保证测试时间足够长？是否满足测试的负载请求足夠多和数据足够多样化是否最大限度地减少或者掩盖缓存或者保证参数化设置的有效性？另外也从侧面反映压测人员的技术专业性

       参數化要规划好各个参数之间的组合逻辑，比如用户名和密码的一一对应关系（对不上肯定不行）参数之间的顺序，另外不同参数之间还囿其他逻辑对应关系比如一对多，多对一互斥关系等等。业务规则决定了参数文件不能随便组合；如果随意组合参数会影响事务成功率或与实际场景不符；

在Loadrunner中有相关的参数化组合配置方式：

Jmeter还可以结合Random随机函数，或是自定义Java函数或是Bealshell脚本实现各种灵活的参数组合配置