一种无编码型软件系统压力测试方法及系统与流程

1.本发明属于软件测试领域，具体地说是一种软件系统压力测试设计方法及工具。通过充分提炼压力测试中具有共性的控制逻辑与异变的属性，并将异变属性数据化，从而实现使用者在不需要编码的情况下，只通过简单修改测试业务场景excel文件中的各种控制参数以及压力测试数据，就可以完成相对完整的简单、有效、快速、易用、直观的软件系统压力测试。


背景技术：

2.软件性能是软件系统非常重要的非功能特性之一，而压力测试也是发现软件性能相关问题的最有效的手段之一。随着互联网应用、移动应用的普及以及大数据等应用的发展，用户的性能体验问题日益受到各方的重视。但是由于软件迭代周期的缩短，往往同时又受限于技术资源的匮乏，很多应用系统没有经过压力测试就交付使用，轻则导致响应卡顿，重则业务出现错误甚至瘫痪。
3.目前市场上比较普遍使用的压力测试工具包括：qtp、loadrunner、jmeter等，也有很多公司根据自己的应用特征，自行开发专用属性较强的压测工具。这些通用或者专用工具功能强大，尤其通用型工具，能够提供多维度视角和不同颗粒度的测试手段，从而获取丰富的系统性能指标，为技术人员分析系统性能表现，找到系统性能瓶颈和潜在错误，提供了有效的数据分析指引。
4.强大的工具在提供强大的功能的同时，另外一个侧面也意味着操作此类工具的复杂性，使用好这些工具首先需要具有较好的编码训练，这对测试人员提出了很高的入门门槛，尤其当测试人员普遍缺少编码能力的时候，压测工作就不可避免在相当大程度占用了开发资源；此外，丰富的测试结果数据确实提供了多角度深入分析问题的潜在可能，但是这样的工作更需要具有丰富硬件网络知识、充分了解系统软件及应用体系结构设计的人员参与进来，又比照普通编码人员的要求更提高了一个很大的层次；同时还需要指出来，很多系统软件自身也提供比较丰富的资源消耗与性能表现的监测工具，不但与压测工具在一些层面发生功能重叠，而且更加能够体现出来系统本身的个性化特征，也更具有参考价值。因此压测工具为照顾这些可能实现得并不太好的功能，而带来更加复杂的构建逻辑，多数情况下是得不偿失的，面面俱到无法把所有方面都做到最优。
5.我们能够理解一个压测工具做得非常复杂的理由。如果掌握一个工具需要高深的设计和编码技能，但是在面对错综复杂的应用场景时，却无法依靠这样一个工具包打天下，就实在是一件令人沮丧的事情，所以我们拿到的工具通常就一定会被设计成为一个复杂而万能的工具。但是换个思路，假如一个使用相对简单得多的工具，能够用简单得多的方法，实现了尽可能多的业务场景的压测需求，学习的成本收益比反而会大得多。善于取舍之道才是一个工具实用性的表现，这是一种设计简繁关系的哲学。
6.因此说来，虽然众多非常专业的压测工具提供了丰富的可编程的能力空间，但是与其提供得太多，不如提供得正好。压测方法和工具手段需要解决的不但是可能性问题，更
重要是需要解决能行性问题，首先突出的矛盾焦点集中在两点，第一个是技术资源问题，第二个是快速响应问题。
7.所谓技术资源问题说到底就是测试人员普遍缺乏编码能力。这并不奇怪，每个人都有自己的所长与所短。如果说开发设计人员主要关注于技术实现的复杂逻辑，那么测试人员更多的优势是对于业务需求的洞察。虽然现有的压测工具普遍提供了类似脚本录制 参数化的简单途径，但是实际应用效果乏善可陈，可维护性极差，无法应对复杂的应用场景，更无法适应频繁的变更。如果为压测投入太多的开发资源，一方面占用了开发团队的资源与时间，另外在业务洞察方面，开发与测试之间还是存在一定的差距，毕竟压测除了帮助开发寻找性能瓶颈之外，最终目的还是面向用户的体验，性能瓶颈最终其实还是能够转化为用户的体验，测试人员更能够深刻理解用户的关注。
8.快速响应问题也是一个很突出的问题。现在互联网、移动应用如此普遍，系统迭代如此频繁，用户群如此广泛，客观上对压测的需求和响应速度提出了很高的要求。如果太多的变化都需要通过更改编码方式来适应，显然这里面存在的风险是巨大的，不但编码的稳定性成问题，而且编码逻辑是否正确，是否能够快速提供压测服务，都成了项目运行必须考虑的问题，很多时候，就是因为时间紧迫的原因无法进行压测验证。
9.设计一个工具，首先需要设想的就是谁来使用这个工具，这跟多数人的想法不同。一般情况，人们首先想到的是需要实现什么目标，然后为了实现这个目标，需要安排哪些类型的人来参与其中各环节中的活动。这是一个正向的思维习惯，基于这样思维习惯的人，当然就会将压测工具设计成为一个编码人员深度参与的软件系统，从而将普通测试人员基本排除在压力测试活动之外。这种想法建立在开发资源无比丰沛，测试时间也足够的情境之下并不为过，但是骨感的现实却往往相反，这造成了自动化测试领域深深的难以自我化解的矛盾。一方面测试人员由于无法参与其中，造成冗员和浪费，另一方面开发人员比照测试人员缺乏深刻全面的业务洞察，更缺少足够的时间来进行充分的自动化测试活动。
10.压测工作往往放到系统交付的末期来执行，这带来巨大的风险，因为压测发现的问题往往是体系结构设计的问题，解决的成本极其高昂，这跟当前测试前置的理念格格不入。之所以如此，就是因为压测工作本身需要大量的准备工作，技术性要求很高，本身就是一项代价高昂的活动，并不是一两个人能够组织起来的工作。在开发阶段，工作主要集中在编码环节，根本无暇抽出额外的技术力量进行压测方面的编码工作。不同于功能性测试，压测对于自动化有极强的依赖性，没有自动化根本无法开展压测工作，传统的压测工具对于编码要求比较高，无法让测试人员将压测工作前置，只能被动等待交付后期投入技术力量来实施。
11.上述问题造成了当前自动化测试工作流程与实际的迫切需要之间难以协调解决的矛盾，并与敏捷、devops这类新开发测试方法论的思想格格不入。这些困难不能从现有压测工具本身的修修补补中获得改进，而需要在根本的设计思路上重新进行探索，需要用测试人员的眼睛来审视出现的问题，并找到适合测试人员的解决办法。这样的视角在之前的压测工具设计中从来就是被忽略掉的，也因此直接导致了目前的各种困境。
12.本发明的出发点就是在综合分析了当前压测工具种种弊端后，试图把握未来自动化测试行业发展的趋势，为重新发现测试行业的价值探索出一条崭新的道路。这个发明的设计思想，努力将测试人员重新放到包括自动化测试的各个测试环节中，发挥其业务洞察
的优势，并能够与开发团队更好配合。
13.解决了新工具谁使用的问题，剩下的就是实现什么功能和如何实现的问题，相对来说，这反而显得不那么困难。压测活动能够实现与开发环节良性互动，带来的额外收益是与敏捷这类新方法论的有效对接，可以填补其中缺漏的环节，本发明是朝向这个大目标迈出的一小步，但是只要方向正确，今后的发展前景大有可期。


技术实现要素：

14.针对目前自动化压力测试工作普遍存在的问题，本发明总体的设计目标是在满足基本压力测试需求的前提下，提出一种非编码化的压力测试设计思想与方法，从而降低性能测试的技术门槛，将普通测试人员纳入到该项工作领域中。
15.要想实现这样的设计目标，需要做到压测操作的充分数据化，意味着新设计出来的工具就像一个编码固化的驱动器，操作的内容则来自于经过精心准备的数据，数据之间的关系更多表达了业务逻辑的关联，同时兼顾技术耦合性的控制逻辑。
16.本发明的关键之处就在于如何将编码固化，如何将压测的内容及可变操作参量以数据化的形式进行表达，这涉及到对普适性逻辑共性的提取与抽象，让共性的、持久性的、紧耦合的内容抽象化、编码化，让个性的、易变的内容数据化，这需要在众多的实践经验中进行提炼总结。
17.具体来说，采用本发明应用于具体项目时，只需要维护简单的压测控制参数和压测数据，使得压测活动的重点得以集中在分析业务与对象系统的控制流程上，而不是将更多精力耗费在构建与维护压测程序本身，因此能够投入更多资源面对实际的压测问题。
18.由于压测项目的维护工作主要集中在数据环节，无论是在压测行为控制还是压测业务数据维护，都具有极大的便利性、快捷性，大大降低了维护成本，提高了压测的效率和质量，能够在更短的时间、更多的场合为系统提供压测服务。
19.为落实上述的设计思想与目标，在具体的实践过程中，我们的设计方案采纳如下一系列具体的基本要则：
20.1.本发明提出了一个无需编码或者只需要极轻度编码的压力测试设计方法，使得压力测试在很大层面从偏重技术转向偏重业务。
21.2.本发明仔细分析现有压测工具的实现内容，抽取其能力空间中最具有典型意义的一系列功能集合，并将其有效重组，形成一个新的测试操作规程，在此规程范围内，尽可能提供强大而简洁的实现方案，并使得测试活动在易于维护的前提下，具有充分的柔性空间以尽可能适应各种压测的要求。
22.3.本发明通过向服务端发送数据包并接收响应实现最基本的一个压测操作闭环。数据包包括并不限于浏览器数据包，系统面向所有类型的数据包，实现环境无关的普适性压测流程和数据表达，便于将不同环境类型、不同项目类型的数据进行统一一致的管理。
23.4.压测活动按照测试业务划分成为不同的测试场景；每个测试场景的一个并发业务可以包括一个或者多个按照顺序发送的数据包；多个同型业务在一个设定的持续时间内并发，组成一个压测轮次；一个场景完整的压测活动包括多轮次压测活动，每个轮次具有不同的并发数量，形成不同的测试压强；压测结果按照不同轮次、不同并发规模进行统计汇总。
24.5.所有压测场景的运行参数都保存在同一个运行控制excel文件(以下简称运控文件)中，其中规定了场景控制文件、结果文件名称及存放路径，也对各个业务阶段的并发模式，分线程运行参数等做了定义，系统每次只能运行一个压测场景。
25.6.运控文件也能够定义系统级自定义参数和用户级自定义参数，用于系统功能和用户功能的重定制化，增强系统的可扩展能力和项目适应能力。
26.7.每个压测场景都有一个场景控制与压测数据excel文件(以下简称场控文件)，建议场控文件名称形如：ct_xxxx.xls,其中xxxx为场景标识。一个完整的压测过程包括多个独立的压测轮次，用于观测不同压力下的系统性能表现，一个场景的所有压测数据都存放在一个excel文件中，当一个场景包括多个业务步骤时，每个步骤的压测数据都不同，需要用不同的sheet页标识存放不同类型的压测数据。
27.8.并发的事务分成顺序发送的几个数据包时，并发模式提供穿梭(shuttle)和顺序(sequence)两种模式，分别对应服务端独立事务处理和批处理两种类型的处理模式。
28.9.不同数据包的压测数据可以自行定义是否允许复用。
29.10.不同数据包的压测数据可以自行定义采用同步或异步传输模式
30.11.压测可以采用单一进程或者多线程进行。
31.12.提供自启动、定时启动及控制启动三种主要的单机、多机、本地、异地受控同步启动压测的机制。
32.13.压测数据的结果包括发送接收数据包的详细内容及时间戳，由此明细可进行后续的统计分析，系统不提供具体的统计分析计算，每个公司、每个项目可根据需求从结果明细中自行统计，并积累有效的定制化统计模板。
33.本发明实现上述目的所采用的技术方案是：一种无编码型软件压力测试方法，包括以下步骤：
34.1)构建运行控制文件和场景控制文件，进行压力测试时，提取所需压测场景的压力测试数据导入数据交换区；
35.2)触发阶段：向触发服务器端定期以同步传输方式发送轮询请求，根据返回结果进行触发启动；
36.3)主进程向待测试的服务端发送压测前预处理请求，并记录返回结果数据存储至数据交换区；
37.4)多线程方式时，建立多个线程，每个线程独立或者受控向待测试的服务端发送压测前各线程的预处理请求，并记录返回结果数据存储至数据交换区；
38.5)单进程方式时，主进程进入压测轮次处理阶段执行压测操作，并记录压测结果数据存储至数据交换区；主进程向测试的服务端发送压测结束后主进程的后处理请求，并记录返回结果数据存储至数据交换区；
39.多线程方式时，每个线程进入压测轮次处理阶段执行压测操作，并记录压测结果数据存储至数据交换区；每个线程独立或者受控向测试的服务端发送压测结束后各线程的后处理请求，记录返回结果数据存储至数据交换区，并关闭各线程；如果主进程还有后处理请求，则接下来由主进程向测试的服务端发送后处理请求，并记录返回结果数据存储至数据交换区；
40.6)多线程后处理及主进程后处理操作完毕，从数据交换区导出压测结果数据。
41.所述运行控制文件包括运行控制属性以及对应的参数；所述运行控制属性包括：场景标识、场景描述、场景控制文件路径、输出文件模板路径、轮次包并发模式、前处理并发模式、后处理并发模式、线程前处理并发模式、线程后处理并发模式、线程数、线程出入口队列方式；
42.所述场景控制文件有关压测数据包收发控制参数包括阶段标识、阶段中步骤序号、数据包名称、数据页名称、发送页名称、响应页名称、发送端口地址、接收端口地址、响应包特征标识、数据包起始单元、数据包复用标识、同步并发数据包标识；
43.所述场景控制文件有关压测轮次控制参数包括：并发数量、并发持续时间、最大响应时间、最小返回响应数、轮次间隔时间、数据清理标识、数据清理时间。
44.除了触发阶段，其它所有阶段压测机的发送数据包及接收到的服务端响应数据包都保存至数据交换区；保存的两种类型的数据记录格式都包括三个字段：轮次、操作时间、数据包内容；预处理及后处理阶段轮次字段为空；其中响应数据包如果超时响应或者响应错误，则将超时响应或者错误响应的标识附加在响应数据包字符串上，为后续处理提供统计分类依据。
45.所述压力测试数据包括控制数据和业务数据；所述控制数据包括压测场景对应的运行控制属性和参数、以及对应场景的场景控制文件内容；所述业务数据为按照业务逻辑排序的业务步骤数据。
46.所述触发阶段为单压测机或多压测机提供自启动、控制启动及定时启动三种并发启动进入下一阶段的机制；
47.压测机从场景控制文件中提取触发启动的数据包，以轮询方式不断向压控服务器发送数据包，并同步接收响应数据包，通过分析返回数据包的内容与设定的响应包特征标识做比较，符合条件则结束触发轮询阶段，进入正式压测的后续阶段，否则继续轮询等待；
48.自启动：发送数据包与设定的响应包特征标识相同，在接收到第一个返回包后直接进入下一个阶段；
49.控制启动：向压控服务器发送设定的控制命令，并提供与压测机场景控制文件中触发启动设定的响应包特征标识相同的字符串，服务端接收此控制指令，此后所有收到的压控机轮询请求都将返回此响应包特征标识，让所有符合此特征标识的压测机结束轮询触发状态，进入下一个阶段；
50.定时启动：压测机响应包特征标识设置成为具体启动时间，时间格式为系统可识别的格式，压控服务器的每个响应返回都包含服务器的系统时间戳，该时间戳由压测机解析，用来设置本机的系统时钟，使得所有压测机的时钟与压控服务器进行校准；当响应包特征标识判定为时间格式时，需要计算收到的时间戳是否已经达到设定的启动时间，只要达到启动时间，并且没有超过内置的时间范围，压测机结束轮询触发状态，进入下一个阶段；
51.通过命令行开关关闭触发阶段，使得在没有部署压控服务器的情况下，跳过触发阶段，直接进入后续阶段。
52.所述触发阶段结束后进入主线程前处理阶段，用于进行压测轮次之前，进行压测的环境准备工作；
53.所述主线程前处理阶段结束后进入线程前处理阶段，用于为每个独立的线程提供压测前的环境准备工作；
54.所述压测轮次之后进入线程后处理阶段，用于为每个独立的线程提供压测完成后的环境清理退出工作；
55.所述关闭线程后进入主进程后处理阶段，用于为所有线程进行压测环境清理。
56.所述压测轮次处理阶段包含压力逐次提高的多个轮次，每个轮次包括以下步骤：
57.一个完整业务包含m个按照业务逻辑排序的步骤，每个业务步骤在纵向上对应一列数据包，m列数据排序，在横向上组成记录，每一组记录代表一个m步骤对应的完整业务，每一列数据包存放在场景控制文件不同的数据页上，提取一组m步骤数据记录，需要从m个数据页中按顺序依次提取，这样的数据记录共有n组，代表压测所准备的所有压测数据；
58.根据需要设定每个轮次并发业务数k，k每轮次依次递增且k《＝n，每个轮次按照业务步骤的逻辑排序，依次在设定的时间内向服务端发送设定的业务并发数的数据包，并获取响应的结果。
59.所述轮次可设定采用穿梭并发模式，包括以下步骤：
60.依次提取m个业务步骤中每个业务步骤的首条数据并发送，此时完成一组并发操作；然后依次提取m个业务步骤中每个业务步骤的第二条数据并发送，如此不断提取每一步骤下一组数据包中的数据，直至完本轮次k组穿梭并发操作。
61.所述轮次可设定采用顺序并发模式，包括以下步骤：
62.对于第一个业务步骤的数据包，依次提取该数据包内本轮次k条的数据并发送，此时完成一个业务步骤的并发操作；
63.依次遍历所有业务步骤的数据包，直至完成m组业务步骤顺序并发操作。
64.一种无编码型软件压测机，其特征在于，包括存储器，所述存储器存有程序，所述程序被处理器调用时执行权利要求1所述的一种无编码型软件压力测试方法的步骤2)-步骤6)。
65.本发明具有以下有益效果及优点：
66.1.测试活动本应归属于测试人员的职责范畴，但是由于测试人员普遍缺少足够的技术能力，往往需要开发人员主控自动化测试的各项活动，在软件交付周期日益缩短，自动化测试地位越发凸显的时代，测试人员乃至测试行业都面临深刻的生存危机。本发明一方面允许现有的测试技术人员得以深度参与压力测试工作，另一方面大大降低对开发人员的依赖，从而平衡两者之间在压测活动中的工作关系，能够更加充分利用好项目的测试资源，缓解测试危机给行业与个人带来的巨大压力，让测试与开发两种角色得以各司其责，发挥所长。
67.2.采用本发明的设计方案，压测活动的主要工作内容从构建维护压测编码转变成为构建维护压测数据，更加便捷、快速、直观，易于维护，更容易满足不同类型的要求，也更容易满足各种精细化的测试要求。
68.3.本发明能够实现快速压测，允许测试人员以低成本的方式，将压测活动前置到开发的过程中，与开发良性互动，从而提前发现体系架构设计潜在的瓶颈，降低系统重大重构的风险。
69.4.本发明实现压测活动数据化的结果，必然使得压测系统可维护性大大提升，响应也更加迅速，更能够适应敏捷时代的测试要求，毕竟维护代码和维护数据的复杂度和时间消耗可不是在一个等级上，后者更加简单快捷。
70.5.由于简化了压测处理模式，允许单机在单进程或者多线程并发时，充分利用系统处理能力及网络带宽，获得远超普通压测工具的并发量，提高压测效率，从而大大降低压测硬件系统的占用成本。
71.6.采用本发明的设计方案，对于压测数据的操作具有更加灵活多样的使用方法，从而便于进行各种规模和颗粒度的压测实验与分析。
72.7.本发明采用多轮次不同并发规模，提供数据复用机制，加上多线程技术及同步异步传输模式的组合，不但能够提供不同的压测压力，也能够提供更精细调整的压强，从而直观便利地观察系统的瓶颈及性能劣化拐点和性能极限。
73.8.本发明提供多种触发启动模式，能够非常便利地在广域网络环境下部署压测设备，并受控同步并发启动，模拟真实环境下客户端网络承载能力，也能够快速简单地将压测系统临时部署到任何计算机设备上，无需专用的压测设备，从而节省压测硬件的投资。
74.9.本发明弱化技术成份的同时，大大强化了数据的内容，需要充分发挥测试人员有关业务洞察的能力，更需要在复杂数据工程化管理方面进行进一步的探索，制定相关规范，有益于促进测试从艺术化向工程化管理迈进的进程，从而为测试行业的转型提供新的思考基点。
附图说明
75.图1为系统控制流程图；
76.图2为运控文件control页面示意图；
77.图3为运控文件param页面示意图；
78.图4为场控文件package页面示意图；
79.图5为场控文件control页面示意图；
80.图6为场控文件数据包数据集页面示意图；
81.图7为结果文件之发送数据包示意图；
82.图8为结果文件之响应数据包示意图。
具体实施方式
83.复杂的系统都需要进行验证，测试的角色也许会淡化，但是测试的活动却会以各种形式加强。由于目前普遍使用的自动化测试工具都需要使用者掌握大量的编码技能，这限制了缺乏编码能力但是更具业务洞察能力的测试人员参与其中的活动，即便如此，软件自动化测试活动仍然以开发人员客串的方式即开发测试的方式在进行着。无编码型的自动化测试工具为真正的测试人员参与到自动化测试工作提供了一种潜在的巨大可能。
84.本发明的设计思想是通过数据来控制驱动压测活动的不同动作形式，并通过数据来表达业务的洞察。显然的，维护数据形式的操作参数和业务数据无需编码能力，更符合测试人员的能力操作空间，而执行压测活动的编码通过对通常压测功能进行适当取舍，采用比较新颖直观的压测操作序列，将其能力空间相对固化，并在此空间内提供相对充分的可调整自由度，为压测的各种潜在要求提供了简便可控的能力。
85.在具体实现上，与其它压测设计思路不同的是，本发明的压测操作采用了多轮次的方法，每个轮次并发不同的业务量，通过多轮次不同并发量的性能表现差异，以更加直观
和全面的结果统计分析，来发现系统存在的性能瓶颈、当前系统的性能表现以及潜在的最大负载能力，并为系统的扩容提供有效的数据推算依据。下面我们从几个方面，具体解释本发明基本设计思路及实现。
86.压测的几个阶段：
87.本发明中，一个完整的压测过程基本可以划分为6个阶段：
88.·
触发阶段：也可以称为t(trigger)阶段，该阶段发送的数据包也称为t包，主要用于单机或者多机启动时，设置如何进入正式的压测处理过程，包括自启动、控制启动、定时启动。所谓自启动是当压测程序启动时，直接进入压测过程，无需循环等待；控制启动需要受控于一个服务端，当一个或者多个压测机启动后，进入循环等待状态，一旦服务端发送设定的启动标识，对应该启动标识的所有压测机结束t阶段，进入正式的压测处理过程，不同的启动标识可以控制不同类型的压测场景；定时启动则是压测机启动后，进入循环等待状态，直到设定的启动时间与系统时间相一致，则自动离开t阶段，进入正式压测处理过程。
89.该阶段可以在命令行启动时，通过特定启动参数的方式强制跳过。
90.三种启动方式都需要预先部署一个压控服务器；压测机从场景控制文件中提取触发启动的数据包，以轮询方式不断向压控服务器发送数据包，并同步接收响应数据包，通过分析返回数据包的内容与设定的响应包特征标识做比较，符合条件则结束触发轮询阶段，进入正式压测的后续阶段，否则继续轮询等待；
91.压控服务器有两种响应模式，第一种将接收到的数据重新返回到发送端；第二种在特定指令下，在一个系统内置的时间范围内(比如10秒钟，须保证所有在线轮询的压测机在此时间范围内至少访问一次压控服务器)，将该指令附带的字符串转发给所有在此期间请求的发送端，而不管原发送端传过来的是什么数据。
92.压控服务器的每个响应返回都包含服务器的系统时间戳，该时间戳由压测机解析，用来设置本机的系统时钟，使得所有压测机的时钟与压控服务器进行校准。
93.自启动：发送数据包与设定的响应包特征标识相同，因此能够在接收到第一个返回包后直接进入压测下一个阶段。
94.控制启动：第二种压控响应模式下，通过比如浏览器方式，向压控服务器发送特定的控制命令，并提供与压测机场控文件中触发启动设定的响应包特征标识相同的字符串，服务端接收此控制指令，此后所有收到的压控机轮询请求都将返回此响应包特征标识，由此可以让所有符合此特征标识的压测机结束轮询触发状态，进入压测下一个阶段。
95.定时启动：压测机响应包特征标识可以设置成为具体启动时间，时间格式为系统可识别的格式，当响应包特征标识判定为时间格式时，需要计算收到的时间戳是否已经达到设定的启动时间，只要达到启动时间，并且没有超过内置的时间范围(比如10秒，保证压测的并发性)，压测机结束轮询触发状态，进入压测下一个阶段。
96.系统提供命令行开关，用来关闭轮询触发阶段，使得在没有部署压控服务器的情况下，单机也能跳过轮询触发阶段，直接进入后续压测阶段。
97.·
主进程前处理阶段：也可以称为b(before)阶段，该阶段发送的数据包也称为b包，主要用于在正式进入压测轮次之前，进行压测的环境准备工作，比如用户登录等。该阶段是可选阶段。
98.·
线程前处理阶段：也可以称为tb(thread before)阶段，该阶段发送的数据包也
称为tb包。当系统采用多线程方式进行压测的时候，该阶段用于在正式进入压测轮次前，为每个独立的线程提供压测前的环境准备工作，比如用户登录等。该阶段是可选阶段，如果场景中有b阶段，需要在b阶段之后执行。
99.·
压测轮次处理：也可以称之为p(processing)阶段,该阶段发送的数据包也称为p包，是正式的压测过程，可以是主进程执行，也可以由多线程完成。多进程执行相当于多台独立的压测机分别执行各自的压测过程。一个完整的压测场景划分为多个轮次，每个轮次在设定的时间内向服务端发送给定的并发业务组数，并获取响应的结果。压测结果分析就是从这多轮次的发送与接收的结果中入手，经过汇总统计，以图表的方式，将不同并发量下的系统响应情况描绘出来，供系统分析人员做更进一步的分析。该阶段是压测活动的主阶段，也是必不可少的阶段，需要特别注意的是，当系统采用多线程进行压测时，如果存在tb阶段，需要所有线程tb阶段都已经完成，各线程才能统一进入p阶段，同样的，也只有当所有线程p阶段执行完毕后，才能完成p阶段，统一进入后续阶段。
100.·
线程后处理阶段：也可以称为ta(thread after)阶段，该阶段发送的数据包也称为ta包。当系统采用多线程方式进行压测的时候，该阶段用于所有线程压测轮次完成之后，为每个独立的线程提供压测完成后的环境清理退出工作，比如用户退出等。该阶段是可选阶段，紧邻p阶段之后执行。
101.·
主进程后处理阶段：也可以称为a(after)阶段，该阶段发送的数据包也称为a包，主要用于在压测活动最后，进行压测的环境清理等工作，比如用户退出等。该阶段是可选阶段。
102.并发模式：
103.在b/tb/p/ta/a阶段中，每一个阶段的一个完整操作可能需要按照业务逻辑顺序，依次发送多条数据包数据，我们把这些数据包按照发送顺序进行分类，并赋予一个包的序号和包的类型，比如b包中包含两类数据包，我们简便地称其为b包的1号包或者2号包，也可简单记作b(1)或者b(2)，当然也可以称其具体的包类型名称，在进行包顺序定义的时候，我们约定每种类型的包都是从1号包开始按顺序进行排列，中间不要间断。
104.以b(1)和b(2)为例，每一种类型的包都对应一个实际的包数据集合，彼此形成一一对应的关系。那么当执行并发操作的时候，系统提供两种类型的并发：
105.·
穿梭并发(shuttle)：b(1)首先提取一条数据并发送出去，接下来b(2)提取对应的数据并发送出去，此时完成一组并发操作，接下来b(1)按照数据集顺序提取下一个数据并发送出去，紧接着b(2)也同样提取下一条数据并发送出去。从逻辑形式来说，这样的一组一组并发操作从b(1)到b(2)，再回到b(1)，然后再到b(2)，如此反复穿梭，直到完成所规定并发数的并发操作。
106.·
顺序并发(sequence)：b(1)首先提取一条数据发送出去，接下来仍然继续提取b(1)数据并发送，直到所规定并发数的b(1)数据都发送完毕，接下来按照顺序发送b(2)的数据，直到所规定并发数的b(2)数据都发送完毕。
107.采用何种并发模式取决于服务端处理业务的具体方式，通常情况下采用穿梭方式，一些特殊场合，比如批处理模式下，会要求采用顺序模式。各阶段采用何种并发模式在运控文件中进行定义，可参考“图2.运控文件control页面”。
108.进程或者线程：
109.本发明既可以采用单主进程方式，也可以采用多线程方式进行压测。由于本发明采用的设计方法照比一般压测工具具有更简洁的实现模式，因此也在压测效率上具有卓越的表现，更能够充分利用系统的资源与网络带宽提供的潜在能力，简单说就是允许在单位时间内提供远超其它工具的并发数，这就为多线程运行提供了有效的基础保证。多线程说白了就是相当于多台压测机，本发明能够用更少的压测机实现更大的压测压力，从而节约压测的硬件系统成本。
110.在单位时间内，服务端接收到的总的并发请求可以看作系统收到的总的压测压力。如果一个并发业务其实是由多个数据包按照业务逻辑依次执行，成为一个完整性的业务，或者一个完整业务技术实现与发送业务请求在比如单一账号或多账号的情况下，执行效率上存在明显区别(服务端采用负载均衡机制)，这两种情况下，多个线程与单主进程压测在相同压测压力下产生的实际效果就会有很大不同，我们把单主进程或者单线程在单位时间的并发数称之为压测的压强。压测的总压力体现了服务端系统总的性能表现，而压测的压强则更能够揭示出来系统内在的瓶颈。
111.系统采用主进程或者多线程模式进行压测可以在运控文件中设定，可参看“图2.运控文件control页面”，当压测场景的线程数为0时，采用单主进程模式，当线程数大于0时，系统采用设定的线程数进行多线程压测。
112.线程出入口队列：
113.当系统采用多线程进行压测时，如果存在tb/ta阶段，那么在正式进入或者退出压测p阶段之前，需要判断采用何种方式进入或者离开。
114.多线程进入或者离开p阶段，如同进入或者离开出入口，为避免对服务端造成不必要的压力，导致tb/ta阶段出现差错，可能需要针对多线程的进出p阶段进行排队管控。可参看“图2.运控文件control页面”中线程口队列设定，当设定为’y’的时候，需要线程依次排队进出p阶段，否则线程自主乱序进出p阶段。
115.特别需要强调的是，无论采用排队或者乱序方式，进入p阶段之前，需要保证所有线程都已经执行完tb阶段，才能同步进入p阶段；类似的，当离开p阶段时，需要保证所有线程都已经完成p阶段后，才能同步进入ta阶段。
116.传输同步与异步：
117.连续发送数据包的时候，如果发送数据包之后等待服务端响应返回，则是同步传输方式；如果发送数据包不等待服务端响应返回，直接按照设置参数计算出的时间间隔依次发送数据包，则是异步传输方式。
118.在一个压测场景的b/tb/p/ta/a五个阶段中，每个数据包类型都可以分别设定同步或者异步传输方式，但是t阶段不允许设定，系统在t阶段一律采用同步传输方式。
119.传输方式对应于具体压测场景的每一组数据包，需要在场控文件中进行定义，不同的压测场景都各自有一个专属的场控文件。具体设定方式可以参看“图4.场控文件package页面”中同步并发数据包字段，值为
‘
y’则为同步传输，否则为异步传输。
120.在p阶段，当采用同步传输方式进行并发压测时，由于需要等待服务端响应返回，因此这段等待时间可能超出设定的数据包之间发送的时间间隔，导致该轮次并发持续时间的不确定性延长；当采用异步传输方式时，在系统资源和网络带宽允许的情况下，基本能够保证在设定的并发时间范围内，准确地依次将数据包按照固定的时间间隔发送出去，总的
并发时间保持相对恒定。
121.数据包复用：
122.每一个压测阶段可以有多个数据包类型，每个数据包类型都需要专门的sheet页存放对应的数据包数据。压测场景各阶段涉及到的数据包类型以及每一个数据包类型对应的数据都在场控文件中定义。
123.采用多轮次进行压测，在简化了压测操作逻辑的同时，却大大增加了压测数据的构建与维护工作，因此在不同轮次间如果允许数据进行复用，就能降低数据方面的相关工作。
124.每个轮次的压测操作，提取数据时需要从数据所在页面中的该轮次起始位置开始顺序提取。如果采用数据包复用模式，所有轮次的起始位置就是整个数据包数据的最初起始单元；如果采用非复用方式，当前轮次的起始位置是从上一个轮次最后一个数据的下一个数据单元为起始点。
125.需要指出的是，在所有压测6个阶段中，只有p阶段存在多轮次并发操作，所以只有p阶段才会有数据复用的问题，其它阶段不能设置数据复用标识，具体设定方式可以参看“图4.场控文件package页面”中数据包复用字段，值为
‘
y’则为复用，否则为非复用。
126.p阶段压测操作：
127.p阶段是整个压测操作的核心，也是正式向服务端进行发送压测数据包的阶段。
128.我们将p阶段划分成多个轮次，每个轮次都相当于一次完整的压测过程。传统压测工具提供的压测过程，其实基本上就相当于本发明的这样一个轮次的压测。
129.传统压测因为相比较本发明进行的压测操作少得多，缺少同类不同负载之间的横向性能比较，因此更加需要依赖压测前对系统的性能与瓶颈的预估，以及压测结束后对压测结果条析缕分的细致研究，也更需要针对压测细节做更多有针对性的压测操作，因此操作方法模式具有鲜明的个性化，很难做到普适性的统一规划，对技术与业务的洞察其实要求非常高，这是通常压测活动本身具有较高的门槛的根本原因。本发明通过多轮次压测的设计，在简化压测操作的同时，强化了压测频度，通过更多横向数据的统计分析，可以使得潜在的问题得以简明的方式析出，从而大大降低了分析问题的技术能力与业务知识的门槛，使得更多人尤其测试人员能够非常有效地参与到其中的工作。
130.具体到一个轮次的操作，有几个关键的要素需要进行设置：
131.·
并发数量：指该轮次需要完成的完整业务数量，为了获得均匀的并发压力，通常我们按照计算出来的相对固定的时间间隔，依次发送每一组业务数据包，因此来说，从一个主进程或者单个线程角度来看，压测的数据包是按照顺序排队发出的，多个压测机或者多个线程能够实现乱序并发的效果。
132.·
并发时间：指该轮次并发的持续时间，配合并发数量和每组业务所包含的数据包，用来计算发送数据包的时间间隔，保证服务端获得稳定持久的请求服务压力。
133.·
最大响应时间：数据包发送出去后，到从服务端返回响应，这期间有一个间隔时间，当超过设定的最大响应时间时，我们认为该数据包服务响应超时，在做结果统计时，超时响应的数据包能够直观提示性能的劣化及瓶颈的出现。
134.·
最小返回响应数：有效的返回必须同时满足两个条件，第一个是正确返回，可以通过响应包特征标识进行判断(由“图4.场控文件package页面”中响应包特征标识字段进
行设置)；第二个是响应时间不能超过最大响应时间。当有效返回计数小于此参数的设定时，该轮次压测活动失败，表明服务端已经出现明显的响应劣化，无法进行更高压力的压测活动，因此整个压测活动将终止，后续轮次的压测将不再进行。
135.·
轮次间隔时间：轮次间的压测活动需要保证前一轮次的服务已经完全结束，服务端各种压力源已经卸除，已经准备好做下一轮次的压测活动，这就需要在轮次间设定一个间隔的时间，来保证服务端的所有前序轮次的处理都能结束。
136.·
数据清理标识：由于轮次间采用了数据复用，在不同轮次间可能存在重复提交的数据，这会导致后续轮次的操作失败，因此需要对前序轮次的数据环境进行清理，这部分工作需要在服务端进行，在每个轮次间隔期间，由压测机发送p包中的0号包，即p(0)固定为轮次间清理数据包，服务端需要对p(0)做响应，这部分工作需要服务端提供技术支持。
137.·
数据清理时间：当轮次间隔需要进行数据清理以便为后续轮次提供干净的环境时，由压测机发送p(0)，并等待该设定的时间，以便服务端能够完成清理工作。
138.上述有关轮次操作的参数设定可以参看“图5场控文件control页面”。
139.数据准备：
140.数据准备工作是整个压测活动中最重要也最繁重的工作，整个压测活动都围绕这项工作展开，也是测试人员需要重点参与的工作内容，如何做好管好这部分数据有待进一步的探讨。
141.任何一个压测阶段的任何一个数据包类型，都对应一个数据包数据集合，这个数据集合单独存放在场控文件指定的页面上，在每个数据包类型定义中都会指定这个数据集合的页面名称，比如“图4.场控文件package页面”中p(2)定义的数据集名称为data1，则在场控文件的data1页面上存放p(2)实际要发送的数据包记录集合，数据包记录存放的起始位置由“数据包起始单元”来定义，其中为一个逗号分隔的二元数，第一个数为数据包记录所在列，第二个为起始记录行号。具体的data1页面数据可参看“图6.场控文件数据包数据集页面”。
142.需要指出的是，每条数据包记录只有一列才是一个准备发送的完整的数据包，图6.中abcd四列数据都是从数据库中提取出来的原始数据，需要根据这些原始数据通过字符串拼接的方式将完整的待发送数据包加工出来，存放在e列上，发送程序只提取e列上的数据包记录。如此做法能够方便地将参数化的数据包用具体的数据实例化，维护数据只需要更新abcd四个列的原始数据。
143.当p阶段包含多个数据包类时，也需要同时准备多个页面的数据，但是特别要注意的是，由于发送数据是按照顺序从每个页面中依次提取，因此，在准备数据的时候，不同页面的数据需要保持严格的一一对应的顺序关系，因此最好采用相同数据源进行数据包实例化。
144.结果分析：
145.除了t阶段，所有其它阶段所有数据包的发送情况与响应情况都会被详细记录在结果文件中。每个场景都有一个预先定义的结果文件模板，由运控文件的control页面进行定义，可参看图1中“输出文件模板”字段，其中给出了输出文件的模板所在路径及文件名称，建议结果文件名称形如：rst_xxxx.xls,其中xxxx为场景标识。
146.在实际生成结果文件时，需要据此文件模板生成新文件，名称后缀增加年月日标
签，比如结果文件模板名称为rst_vacc_1.xls，实际生成结果文件日期为2020-04-07，则最终结果文件名称应该为：rst_vacc_1_2020-04-07.xls。
147.每个数据包类都会在这个结果文件中生成两个指定的页名称，用来存放结果详细记录，其中一个为发送页记录，另一个为响应页记录，页的名称在场控文件的package页中进行定义。参看“图4.场控文件package页面”之发送页名和响应页名两个字段中的定义。
148.发送页和响应页的详细记录格式相同，都包括三个字段：轮次、操作时间、数据包内容，利用这些信息可以进行更进一步的结果统计分析。有关发送页结果记录参看“图7.结果文件之发送数据包”，有关响应页结果记录参看“图8.结果文件之响应数据包”。
149.系统不提供进一步的结果分析统计模块，这部分可以根据具体项目从原始的结果明细数据中进行定制化的统计分析计算。用户可以从成熟的项目中逐步积累各种适用于自己公司的统计模块，excel也提供了丰富的统计计算方法。这部分工作一旦形成相对的规范，就可以简便地由普通测试人员进行相关的操作，并将结果汇报给压测的技术方和客户方，用来做进一步分析的依据。
150.定制化扩展：
151.不同环境与项目产生复杂的压测需求，在保持非编码化的前提下，允许系统进行一定范围内的定制化扩展，在将定制化的编码固化的同时，提供参数定义机制，配合定制化编码，适应扩展的功能实现。参看“图3.运控文件param页面”中参数类型、参数名、参数值的定义。
152.完整的压测流程：
153.下面结合附图1对本发明做概要的完整流程说明。
154.准备工作包括：运控文件、场控文件及相关的数据，设置当前要运行的压测场景及压测场景各轮次的控制参数。
155.1.启动压测主程序，从运控文件和场控文件中导入当前要进行压测场景的所有相关控制信息及数据；
156.2.判断系统是否需要进入t阶段，如果不需要触发启动，则直接进入下一阶段，如果需要进行触发启动，则需要向触发服务器端定期以同步传输方式发送轮询请求，根据返回结果判断采用何种方式进行触发启动，并判断是否已达到触发条件，如果一直未能满足触发条件，则系统始终处于轮询触发等待状态。当系统满足触发条件，则退出t阶段，进入下一个阶段；
157.3.通常主进程都有一个前处理阶段，即b阶段，用来进行压测前请求服务端进行压测前的准备工作，当完成此阶段处理后进入下一个阶段。此阶段为选用阶段；
158.4.主进程判断压测活动采用单主进程或者多线程方式，如果是单主进程压测，则进入p阶段，如果是多线程方式，则为每个线程设置初始状态为create，并建立线程，所有线程都建立起来后，由主进程控制所有进程进入下一个阶段；
159.5.多线程的情况下，通常每个线程都需要有一个线程前处理阶段，即tb阶段，用来为每个线程向服务端请求压测前的准备工作，比如进行用户登录等。线程开始执行该阶段处理时，需要主动将自己线程状态设置为run，一旦处理执行完毕，将自己的状态设置为finish，并开始轮询等待主进程开放进入下一个阶段的闸门。当各线程忙于tb阶段处理时，主进程需要轮询所有线程的状态，一旦所有线程状态都设置为finish，主进程则首先将每
个线程状态设置为pending，然后打开进入下一个阶段的闸门，也就是允许各个线程开始进入p阶段；tb阶段同样也是选用阶段。
160.6.无论是单主进程还是多线程进行压测，基本的控制逻辑完全相同，只是多线程需要按照线程数将数据进行均匀砍块分割，以便相互之间不会彼此干扰。多线程执行p阶段时，首先将自己的线程状态设置为run，在执行完毕后设置为finish。p阶段是真正执行压测操作，需要执行多个轮次，一旦所有轮次都执行完毕，或者由于性能严重劣化导致压测活动终止，则系统进入下一个阶段；
161.7.对于多线程来说，每个线程执行完p阶段，会将自己的线程状态设置为finish，主进程在此期间轮询所有线程的状态，一旦所有线程状态都为finish，则设置所有线程状态为pending，然后打开进入下一个阶段的闸门；
162.8.如果多线程存在线程后处理阶段，即ta阶段，则线程首先将自己的状态设置为run，然后开始向服务端发送请求，执行ta阶段的处理，一般来说主要做各线程相关的环境清理工作，比如退出登录等。一旦ta处理结束，线程将自己的状态设置为finish。在此期间主进程不断轮询各线程状态，一旦所有线程状态都为finish，则设置所有线程状态为pending，然后打开进入下一个阶段的闸门。tb阶段同样也是选用阶段。
163.9.无论是主进程压测还是多线程压测，最后还有一个选用的主进程后处理阶段，即a阶段，此阶段用来处理压测活动完成后服务端的环境清理工作。a阶段是压测活动最后一个阶段。
164.10.完成压测活动所有阶段的工作后，系统将所有压测过程中进行的操作及获得的结果明细都输出到指定的结果文件中，供后续进行统计分析。
165.根据本发明的设计思想已经完成了相关工具的设计，并在多个具体项目中获得应用。实践表明，根据本发明设计的工具能够非常容易被不具备编码能力的测试人员所理解并掌握，从而获得深度参与其中工作的机会。压测的结果简明直观，能够满足性能测试各方面的要求，尤其在压测的过程中，能够在现场根据需要，随时调整各种压测参数，这些工作完全在excel文件中进行，不需要在编码层次上进行，具有极大的便利性，易于维护，灵活性、稳定性、可靠性都很好。提供的多种触发启动机制允许分布不同地域环境的压测机同步启动，能够在广域网范围内进行压测。此外，整个系统的压测效率极高，大大降低了压测设备的性能要求，也最大限度节省了压测硬件设备的投入。