软件测试知识概括

软件测试基础
软件测试详解
软件测试拓展
Fiddler抓包工具和Burp_suite渗透工具
Jmeter(压力测试工具)
PostMan(接口测试工具)
CI/CD工具()
单元测试

软件测试基础

什么是软件：

软件是计算机程序、程序所用的数据以及有关文档资料的集合。
软件是计算机的灵魂。软件又可以分为两大类:系统软件和应用软件。
系统软件:系统软件是生成、准备和执行其他程序所需要的一组文件和程序。如操作系统Windows，数据库SQL-Server,驱动程序(网卡，声卡)，java语言系统编译环境等。
应用软件:计算机用户为了解决某些具体问题而购买、开发或研制的各种程序或软件包。如APP. QQ，微信等。

软件的生命周期：

软件生命周期(SDLC，Systems Development Life Cycle)是软件开始研制到最终被废弃不用所经历的各个阶段。—软件开发模型

软件开发模型：

①在1970年人类整理了第一个软件生命周期，即瀑布型生命周期模型也叫瀑布模型。规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落，具有顺序性和依赖性。每个阶段规定文档并需进行评审。
- ①从1990年代开始逐渐引起广泛关注，是一种的开发方法。强调以人为本，专注于交付对客户有价值的软件。是一个用于开发和维持复杂产品的框架。就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
  微信:文字聊天，语音聊天，视频聊天，朋友圈，红包，小程序，零钱通，公众号(需求)=== 3年
  第一次迭代版本:文字聊天，语音聊天=== 3个月–上线，用户量，占领
  第二次迭代:视频聊天，朋友圈==2个月 –用户量，吸引新用户
  第三次迭代:红包，小程序，零钱通=3个月
  …
  产品不选的重复–完善，丰富
  ②项目周期多久代周期多久1个月，2周，1周)
  ③敏捷开发模型特点：
  弱化文档。
  强调人之间沟通：站会–站着开会：10分钟：今天的任务，昨天问题，协调处理。
软件开发过程：
- 一、问题的定义及规划：
  ①主要确定软件的开发目的及其可行性。制定项目总体开发计划。
- 二、需求分析：
  ①在确定软件开发可行的情况下，对软件需要实现的各个功能进行详细分析,明确客户的需求(需求评审–产品，开发，测试)，输出需求规格说明书终版(原型图)。
- 三、设计：
  ①把需求分析得到的结果转换为软件结构和数据结构，形成系统架构。
  ②概要设计:主要是架构的实现，指搭建架构、表述各模块功能、模块接口连接和数据传递的实现等项事务。
  ③详细设计:对概要设计中表述的各模块进行深入分析等，其中需要包含数据库设计说明。
- 四、编码：
  ①按照详细设计好的模块功能表，编程人员编写出计算机可运行的程序代码
- 六、运行维护：
  ①软件维护是软件生命周期中的阶段。在软件开发完成并投入使用后，由于多方面的原因，软件不能继续适应用户的需求。要延续软件的使用寿命，就必须对软件进行维护。软件的维护主要包括和两个方面。
  ①纠错性：bug修复，修改代码—新版本
  ②改进性：优化，完善，改良—新版本(需求–立项–需求分析)
一个软件产品从开发到用户使用都涉及哪些环境/strong>
- 1、开发环境()：
  ①顾名思义，开发同学开发时使用的环境，每位开发同学在自己的dev分支上干活，提测前或者开发到一定程度，各位同学会合并代码，进行联调。
- 2、测试环境()：
  ①也就是我们测试同学干活的环境啦，一般会由测试同学自己来部署，然后在此环境进行测试。bug修复后，需要发版更新测试环境来回归bug。
- 3、回归环境：
  ①回归bug的环境，其实就是我们的测试环境，在测试环境上测试、回归验证bug。
- 4、预发布环境()：
  ①测试环境到生产环境的过渡。测试环境可能会受到一些限制，一些流程或者数据没有测试到，就可以在预发布环境进行验证，从而保证产品上线质量。
  ②预发布环境和生产环境区别：
  预发环境中新功能为最新代码，其他功能代码和生产环境一致。
  预发环境和生产环境的访问域名不同。
  ③注意事项：
  预发布环境一般会连接生产环境的数据库，测试时要注意，以免产生脏数据，影响生产环境的使用。
- 5、生产环境()：
  ①即线上环境，用户使用的环境。由特定人员来维护，一般人没有权限去修改。
  ②
灰度发布版本和灰度环境：
- 灰度发布也叫金丝雀发布，起源是，矿井工人发现，金丝雀对瓦斯气体很敏感，矿工会在下井之前，先放一只金丝雀到井中，如果金丝雀不叫了，就代表瓦斯浓度高。
  ①在灰度发布开始后，先启动一个新版本应用，但是并不直接将流量切过来，而是测试人员对新版本进行线上测试，启动的这个新版本应用，就是我们的金丝雀。如果没有问题，那么可以将少量的用户流量导入到新版本上，然后再对新版本做运行状态观察，收集各种运行时数据，如果此时对新旧版本做各种数据对比，
  ②当确认新版本运行良好后，再逐步将更多的流量导入到新版本上，在此期间，还可以不断地调整新旧两个版本的运行的服务器副本数量，以使得新版本能够承受越来越大的流量压力。直到将100%的流量都切换到新版本上，最后关闭剩下的老版本服务，完成灰度发布。
  ③如果在灰度发布过程中（灰度期）发现了新版本有问题，就应该立即将流量切回老版本上，这样，就会将负面影响控制在最小范围内。
  ④链接：什么是灰度发布/li>
- ：，在上线之前发布到灰度环境，通过后再上线，其实灰度环境的好处挺多的，其中最明显的就是观察用户反馈，即时调整产品的方向，避免因为直接上线导致用户一时半会儿适应不了新系统，导致用户流失。此外还有助于降低上线的成本，如人力成本（一般大版本上线是深更半夜，开发比较疲惫）、降低bug数量等，如果发现灰度环境的问题，可以及时把用户剔除灰度名单，尽可能减少用户的损失
  ①链接：灰度环境搭建笔记
预发布环境和灰度环境：
- 预发布环境：
  ①只是一台服务器
  ②没有真实的流量
  ③连线上数据库
- 灰度环境()：
  ①1台或集群
  ②线上数据库
  ③真实流量
总结：
- 链接：各环境开发流程
- local：自己的开发分支
- dev：前后端联调分支
- test：测试分支
- 复制一份test的镜像：压测
- pre/beta：灰度分支，连接生产数据库，对接生产流量，也可以叫公测。
- stage：预发布分支，连接生产数据库，不对接生产流量。
- produce/master：生产分支。
分支解释：
- master 主分支：对应正式环境的代码。
- develop分支：近期要发布和测试的代码分支，对应开发分支。
- fixbug分支：要发补丁的代码分支，对应bug分支。
- release分支：本周要发布的代码分支，对应发布分支。
应用软件架构C/S与B/S架构：
- c/S: client-server:这种就是我们一定要安装一个客户端才能够用的软件，就叫C/S
  ①缺点:每次更新，都需要更新服务端与客户端，比如说超市收银系统每次更新每台电脑都必须重装客户端，特别是有分店的情况。人力物力财力都很大。–重启业务中断
- B/S: browser-server:只需要一个浏览器，就可以访问服务的，就是B/S.
  ①优点:只需要更新服务器就OK,不需要去更新浏览器。用户主动性比较高。比如说天猫、淘宝。
软件测试是什么：
- 软件测试的定义: 使用人工和自动手段来运行或测试某个系统的过程，其目的在于检验它是否满足规定的需求戎弄清预期结果与实际结果之间的差别。
- 问题:使用QQ的过程,是软件测试么答案：不是。
- 我们为什么要做软件测试，它的目的什么br> ①软件测试为了发现程序(软件)存在的代码或业务逻辑错误
  ②软件测试为了检验产品是否符合用户需求
  ③软件测试为了提高用户的体验
软件测试的分类：
- 按测试技术划分：
  ①黑盒测试：
  产品-黑色盒子–代码实现
  输入输出—数据驱动的测试
  
  ②白盒测试：
  产品—透明盒子—代码逻辑，会代码
  不是测试做的，开发自测—-代码审查
  
  ③灰盒测试：
  大概知道代码逻辑实现,不需要着懂所有的代码
- 被测试对象是否运行划分：
  ①动态测试：程序是运行的
  ②静态测试(文档检查、代码走查)：程序不运行
- 按不同的测试手段划分：
  ①手工测试：(点工)
  ②自动化测试：(代码+工具)
- 按测试包含的内容划分：
  ①测试业务逻辑(手工，自动化)—核心重要
  ②Ul (user interface)–外观美观，设计合理，友好—主观性强=需求文档
  ③高级类型—攻击(工具(扫描–appscan)，代码(脚本–ql注入)）—漏洞，薄弱=账号密码，http协议–https协议
  ④软件＋硬件(windows, Linux ，MAcOS,Android,iOS);软件+软件(浏览器兼容)…调用;软件不同版本之间=APP升级(老功能，数据)
  ⑤主观—人性化，舒适，用户使用习惯，用户体验—提bug=站在用户角度考虑，参考成熟产品
  ⑥高级类型—双十一(访问人数多)–并发（10000)—资源,CPU，内存–正常处理(压力测试，稳定性、负载测试)
- 按测试阶段划分：
  ①单元测试
  ②集成测试
  ③系统测试
  ④验收测试
  ⑤α测试
  ⑥β测试
- 其他测试：
  ①regression test :测试 — bug，开发修复bug(修改代码)=验证bug =其他没被修改的代码模块的测试，影响:上线之前-很多轮(2-4轮)的回归测试(重复)–策略=自动化测试实现
  ②来源—硬件测试:电路板–通电–冒烟–短路被烧了=打回开发重做…软件测试:软件提测–核心业务功能，主流/程-打回开发
  ③发散测试–能力要求非常高:依据，方法=靠经验，积累，直觉—-
软件测试详解

软件测试工作流程图：
拿到项目的基本测试思路:(分析需求)
①明确一下这个项目是做什么的基本业务逻辑流程:淘宝—注册登录商品浏览购物车―提交订单支付。。。。=流程图(主流分支流程)
②细化每一个功能，细化分析提取测试点:注册，登录……
③所有的细化模块的分析组合在一起=完成项目的测试点—-功能
④非功能:界面、易用性、兼容性、安全性、性能压力
场景法：
①
②如何使用场景法
画出流程图–产品需求文档–画好了;–需要测试自己画
1、矩形:表示步骤(操作、输入、输出结果)
2、菱形:判断条件–是、否
3、箭头:流向
③遍历场景，提取测试用例。
1、覆盖正常的路径-取到钱的路径—-判断的地方–Y
2、走每一个分支–判断的地方—找菱形–N
3、出错步骤重新回到主流程，建议多走一步正确的步骤–注意:
④注意：
场景法的重点是测试流程，因此每个流程一个用例验证即可，流程测试没有问题并不能说明系统功能没有问题了，还需要针对单步的功能进行测试，
只有单个功能点和流程测试，才算是充分的测试＋等价类、边界值—-细化测试
⑤案例：
场景一:插入合法银行卡，输入正确的密码，输入正确且充足的金额，ATM足够—取到钱
场景二:插入不合法的卡，退卡提示错误;
场景三:插入合法银行卡，输入密码之后取消，–退卡
场景四:插入合法银行卡，输入错误的密码之后不取消，不超过3次–提示密码错误，重新输入密码
场景五:插入合法银行卡，输入错误的密码之后不取消，出错3次—吞卡
场景六:插入合法银行卡，输入正确的密码之后不取消，输入不合法金额–提示错误，重新输入
场景七:插入合法银行卡，输入正确的密码之后不取消，输入合法金额，账户余额不足–提示错误，重新输入
场景八:插入合法银行卡，输入正确的密码之后不取消，输入合法金额，账户余额充足，ATM不足余额–提示错误，重新输入

④new(新建)—》(提bug者，测试老大)指派(开发，开发老大)︰跟进(3天，push(推进）开发修改)
要求开发备注一下重复bug 的号(ID: 122)，测试确认–是–加备注，关闭;否–重新激活(reopened)–指派开发;
by-design(设计如此)，操作失误，需求的理解不一致–争论:1)分析需求，从用户角度出发没找到证据–尝试说服开发;2)产品(项目经理)–拍板–是bug–开发修复;不是–测试不纠结，留好证据(邮件据图，备注bug) ;
1)开发复现:确认一下测试环境再复现出来–可以–帮助开发复现，测试环境调试定位
2）测试和开发环境都无法复现:尝试眼踪3-5个版本（10次+)—加备注(复现次数，跟踪版本数)–关闭–记录到小本本，研究
bug级别低– Ul,minor，enhancement bug;
1)说服开发
2)产品确认–备注留证据，关闭

1)建议性(feature/enhancement)–下一个版本需求∶
2)上线之前，影响比较大(性价比)”–分析，1)分析这个bug用户影响大小，建议他修复;2)严重级别—产品、项目经理最后确认–不修复，备注(留证据)–不关闭，挂起
测试验证―（ bug步骤，结果检查)
1） verified(已验证)– closed(关闭)
2）仍然存在: reopened(重新激活)

bug的跟踪管理-缺陷管理工具：

常见的缺陷管理平台:
①禅道(entao) ，我们现在做项目用的就是这个
②bugzilla、jira:都还不错，也比较强大。但是搭建起来很困难bugfree:
③Readmine
④easybug:免费开源，在线网站类型的Mantis:这个还可以用
⑤Qc(QualityCenter)、TD
不管是开源还是商业的缺陷管理工具，它们本质都是一样的，用来管理bug的生命周期。掌握其中一款工具，自然就会用其他的，稍微有一点点区别的，别人加以指点，就可以明白了。
①bug标题——标题要清晰简洁，写明bug描述;如果没有选择功能模块，最好在标题中标注功能模块。让查看bug的人员清楚知道你所表达的意思。bug的功能模块+bug的操作+ bug的结果
②重现步骤——详细写下发现bug的测试过程。能指导开发重现这个bug。附上测试数据
③实际结果——出现bug的结果，粘贴bug截图、日志截图—直观，证据（有图有真相)
④预期结果——记得写清楚预期—-来自于预期结果
.⑤bug类型和严重程度——便于后续测试结果分析，bug的统计
⑥bug测试环境——例如:什么系统，哪个版本等。兼容性问题、难以重现问题
⑦附件——日志文件，文件测试数据。图片、崩溃日志文件等

UI自动化测试详解：

在这里，我们可以先学习Web自动化测试，再学习App自动化测试。
，不少学习功能自动化的同学开始首选 selenium ，因为它相比 QTP 有诸多有点：
①免费，也不用再为破解 QTP 而大伤脑筋
②小巧，对于不同的语言它只是一个包而已，而 QTP 需要下载安装1个多 G 的程序。
③这也是最重要的一点，不管你以前更熟悉 C、 java、ruby、python、或都是 C# ，你都可以通过 selenium 完成自动化测试，而 QTP 只支持 VBS
④支持多平台：windows、linux、MAC ，支持多浏览器：ie、ff、safari、opera、chrome
⑤支持分布式测试用例的执行，可以把测试用例分布到不同的测试机器的执行，相当于分发机的功能。
Burp_suite渗透测试工具简介：
- Burp_suite是一个截HTTP/S的代理服务器，作为一个在浏览器和目标应用程序之间的中间人，允许你拦截，查看，修改在两个方向上的原始数据流。
- Burp_suite工具运行需要Java环境。
- proxy代理是burp suite的一个关键工具，所有的工作都是围绕它来展开的，当我们使用burpsuite时最先打开的也是这个界面。下面这张图片是proxy的主界面。
- 链接：Burp_suite安装及使用教程(专业版)
Jmeter(压力测试工具)

工具与测试：
- 压力测试工具：
  ①做压力测试的常用工具做压力测试，一般要使用工具，人工是没办法做的。
  ②最常用的工具是LoadRunner, 但是LoadRunner毕竟是收费软件，而且使用上也比较复杂。
  ③现在越来越多的人开始使用Jmeter来做压力测试。免费，而且使用上非常简单。
  ④链接：
  JMeter下载及使用
  全网最全最细的jmeter接口测试教程以及接口测试流程详解
- 性能测试与负载测试：
  ①
  ②
jmeter详解：
- jmeter简介：
  ①Apache JMeter是Apache组织开发的基于Java的压力测试工具。用于对软件做压力测试，它最初被设计用于Web应用测试，但后来扩展到其他测试领域。它可以用于测试静态和动态资源，例如静态文件、Java 小服务程序、CGI 脚本、Java 对象、数据库、FTP 服务器等等。
  ②JMeter可以用于对服务器、网络或对象模拟巨大的负载，来自不同压力类别下测试它们的强度和分析整体性能。另外，JMeter能够对应用程序做功能/回归测试，通过创建带有断言的脚本来验证你的程序返回了你期望的结果。为了最大限度的灵活性，JMeter允许使用正则表达式创建断言。
  ③Apache jmeter 可以用于对静态的和动态的资源（文件，Servlet，Perl脚本，java对象，数据库和查询，FTP服务器等等）的性能进行测试。
  ④它可以用于对服务器、网络或对象模拟繁重的负载来测试它们的强度或分析不同压力类型下的整体性能。你可以使用它做性能的图形分析或在大并发负载测试你的服务器/脚本/对象。
- jtl文件和jmx文件：
  ①
  在性能测试过程中，我们往往需要将测试结果保存在一个文件当中，这样既可以保存测试结果，也可以为日后的性能测试报告提供更多的素材
  Jmeter中，结果都存放在.jtl文件。这个.jtl文件可以提供多种格式的编写，而一般我们都是将其以csv文件格式记录
  ②
  jmeter生成的测试计划文件。
- jmeter的使用：
  ①线程组：代表一定数量的并发用户，它可以用来模拟并发用户发送请求。线程组是为模拟并发负载而设计。
  ②取样器（Sampler）：模拟各种请求。所有实际的测试任务都由取样器承担，存在很多种请求。如：HTTP 、ftp请求等等。
  ③监听器：负责收集测试结果，同时也被告知了结果显示的方式。功能是对取样器的请求结果显示、统计一些数据（吞吐量、KB/S……）等。
  ④断言：用于来判断请求响应的结果是否如用户所期望，是否正确。它可以用来隔离问题域，即在确保功能正确的前提下执行压力测试。这个限制对于有效的测试是非常有用的。
  ⑤定时器：负责定义请求（线程）之间的延迟间隔，模拟对服务器的连续请求。
  ⑥
  ⑦配置元件维护Sampler需要的配置信息，并根据实际的需要会修改请求的内容。
  ⑧前置处理器和后置处理器负责在生成请求之前和之后完成工作。前置处理器常常用来修改请求的设置，后置处理器则常常用来处理响应的数据。
- jmeter元件的作用域：
  ①
  ②前置处理程序(Per-processors）在其作用范围内的每一个sampler元件之前执行。
  ③定时器（timers )对其作用范围内的每一个sampler有效。
  ④后置处理程序(Post-processors)在其作用范围内的每一个sampler元件之后执行。
  ⑤断言（Assertions ）对其作用范围内的每一个sampler 元件执行后的结果执行校验。
  ⑥监听器(Listeners )收集其作用范围的每一个sampler元件的信息并呈现。
  ⑦
- jmeter元件执行顺序：
  ①
  ②如果在同一作用域范围内有多个同一类型的元件，则这些元件按照它们在测象机试计划中的上下顺序一次执行
jmeter参数化、检查点、集合点、关联、结果、连接：
- 参数化：
  ①里的。
  ②里的。
  ③里的。
  ④里的。
- 集合点：
  ①里的。让所有请求在不满足条件的时候处于等待状态。链接：Jmeter 集合点
- 断言：
  ①里的
  ②里的
  ③里的
- 关联：
  ①的
  ②里的
  ③里的
- 结果：
  ①里的
  ②里的
  ③里的
- 连接：
  ①里的
jmeter图像：
- 扩展插件：
  ①下载插件http://pan.baidu.com/s/1mioVJni
  ②解压下载的安装包，将 jpgc-graphs-basic-2.0.zip 解压缩后只有一个 lib 目录，该目录下有一个 ext 文件夹和一个 jmeter-plugins-cmn-jmeter-0.3.jar 包，ext 文件夹中有 jmeter-plugins-graphs-basic-2.0.jar 和 jmeter-plugins-manager-0.10.jar 包。
  ③将 lib 目录下的 jmeter-plugins-cmn-jmeter-0.3.jar 拷贝到 %JMeter%/lib 目录下；
  ④将 ext 目录下的 jmeter-plugins-graphs-basic-2.0.jar 和 jmeter-plugins-manager-0.10.jar 拷贝到 %JMeter%/lib/ext 目录下。
  ⑤重启 JMeter，发现已经支持 TPS、TRT 等视图了。
- 视图：
  ①
  ②
  ③
jmeter线程：
- 线程(用户) ：一般常用线程组:可以理解成为虚拟用户组
- setup thread group：可用于执行预测试操作。这些线程的行为完全像一个正常的线程组元件。类似Loadrunner中的init
- teardown thread group：可用于执行测试后动作。这些线程的行为完全像一个正常的线程组元件。类似Loadrunner中的end
- 线程组设置：
  ①线程数：虚拟用户数
  ②ramp up period：设置的虚拟用户数需要多长时间全部启动。如果线程数为20，时间为10，也就是每秒钟启动2个线程
  ③循环次数：每个线程发送请求的次数。如果线程数为20，循环次数为100，那么每个线程发送100次请求。总请求数为20*100=2000。如果勾选了“永远”，那么所有线程会一直发送请求，一到选择停止运行脚本。
  ④调度器：可以更灵活的设置运行时间等
脚本语言详解：
- ①BeanShell是一种完全符合Java语法规范的脚本语言,并且又拥有自己的一些语法和方法;
  ②BeanShell是一种松散类型的脚本语言(这点和JS类似);
  ③BeanShell是用Java写成的,一个小型的、免费的、可以下载的、嵌入式的Java源代码解释器,具有对象脚本语言特性,非常精简的解释器jar文件大小为175k。
  ④BeanShell执行标准Java语句和表达式,另外包括一些脚本命令和语法。
  ⑤链接：
  BeanShell用法汇总
- ①JSONPath是xpath在json的应用。
  ②xml最大的优点就有大量的工具可以分析，转换，和选择性的提取文档中的数据。XPath是这些最强大的工具之一。
  ③链接：
  JsonPath —— JSON 解析神器
  jmeter中正则提取元件的使用总结
  JSONPath解析器网站
  使用 JSONPath 解析 JSON 完整内容详解
jmeter结果报告：
- 聚合报告各个参数含义如下：
  ①Samples——本次场景中一共完成了多少个请求
  ②Average——平均响应时间
  ③Median——响应时间的中值
  ④90%Line——所有请求中90%的响应时间
  ⑤Min——最小响应时间
  ⑥Max——最大响应时间
  ⑦Error——出错率
  ⑧Troughput——
  ⑨Received KB/sec——接受数据大小，以流量做权衡的吞吐量
  ⑩Sent KB/sec——响应数据大小，以流量做权衡的吞吐量
- TPS报告：
  ①一般来说压测环境的性能一般会比本地环境好2到4倍。
性能测试专有名词：
- ：
  ①意思是每秒事务数，具体事务的定义，都是人为的，可以一个接口、多个接口、一个业务流程等等。一个事务是指事务内第一个请求发送到接收到最后一个请求的响应的过程，以此来计算使用的时间和完成的事务个数。
- ：
  ①意思是每秒查询率，是一台服务器每秒能够响应的查询次数（数据库中的每秒执行查询sql的次数），显然，这个不够全面，不能描述增删改，所以，不建议用qps来作为系统性能指标。
- QPS和TPS的区别：
  ①
  ②
  ③
- ①RT（Response-time）响应时间：执行一个请求从开始到最后收到响应数据所花费的总体时间，即从客户端发起请求到收到服务器响应结果的时间。该请求可以是任何东西，从内存获取，磁盘IO，复杂的数据库查询或加载完整的网页。
  ②暂时忽略传输时间，响应时间是处理时间和等待时间的总和。处理时间是完成请求要求的工作所需的时间，等待时间是请求在被处理之前必须在队列中等待的时间。
  ③响应时间是一个系统最重要的指标之一，它的数值大小直接反应了系统的快慢。
- ①并发数是指系统同时能处理的请求数量，这个也反应了系统的负载能力。
  ②并发意味着可以同时进行多个处理。并发在现代编程中无处不在，网络中有多台计算机同时存在，一台计算机上同时运行着多个应用程序。
- ①系统的吞吐量（承压能力）和处理对CPU的消耗、外部接口、IO等因素紧密关联。单个处理请求对CPU消耗越高，外部系统接口、IO速度越慢，系统吞吐能力越低，反之越高。
  ②系统吞吐量有几个重要指标参数：QPS（TPS）、并发数、响应时间。
- 吞吐量与TPS：
  ①联系：都是性能指标，都是以秒为单位进行计算
  ②区别：
  吞吐量是数据层的指标，指单位时间内系统成功传输的数据量，以MB、GB等为单位
  TPS是网络协议层的指标，指一秒内成功完成的事务数（transaction）。
- 总结：
  ①QPS（TPS）：（Queries Per Second）每秒钟请求/事务数量。
  ②并发数：系统同时处理的请求/事务数。
  ③响应时间：一般取平均响应时间。
  ④理解了上面三个指标的意义之后，就能推算出它们之间的关系：
- 链接：
  ①系统吞吐量（TPS）、用户并发量、性能测试概念和公式
  ②一文搞懂高并发性能指标：QPS、TPS、RT、并发数、吞吐量
  ③性能测试问产品压力测试指标给多少PS、响应时间、并发量的要求是多少样计算
总结：

软件测试知识概括

软件测试知识概括

软件测试基础

软件测试详解

Jmeter(压力测试工具)

相关推荐