软件测试方法及应用分析

PAGEPAGEI软件测试方法及应用分析摘要随着计算机行业的快速发展、用户要求的不断提高和大数据等各种技术的不断兴起,软件测试的领域受到了巨大的冲击,系统也变得越来越复杂。如何在现阶段数字经济新时代背景下面对软件测试中所出现的问题,对软件测试的产业发起了挑战,能促进软件测试更好更快更全面地发展成为了我们应该重视的事情。本文分析了数字经济新时代背景下软件测试发展面临的困难和挑战，并根据分析结果提出了一些测试意见和测试方法的改进，期望对软件测试行业的发展能起到一定的作用。

SoftwaretestingmethodandapplicationanalysisAbstractAstherapiddevelopmentofthecomputerindustry,thecontinuousimprovementofuserrequirementsandtheriseofvarioustechnologiessuchasbigdata,thefieldofsoftwaretestinghasbeengreatlyimpactedandthesystemhasbecomemoreandmorecomplex.Howtofacetheproblemsinsoftwaretestingintheneweraofdigitaleconomyhaschallengedthesoftwaretestingindustry,andithasbecomesomethingweshouldpayattentiontotopromotethebetter,fasterandmorecomprehensivedevelopmentofsoftwaretesting.Thispaperanalyzesthedifficultiesandchallengesfacingthedevelopmentofsoftwaretestingintheneweraofdigitaleconomy,andputsforwardsomeSuggestionsandimprovementsoftestingmethodsbasedontheanalysisresults,hopingtoplayacertainroleinthedevelopmentofsoftwaretestingindustry.

目录软件测试方法及应用分析 II1.概述 11.1软件测试的定义 11.2.1测试的目的 11.2.2基本要求 11.2.3测试用例 12.软件测试的方法 22.1软件测试的基本方法 22.1.1黑盒测试 22.1.2白盒测试 22.1.3单元测试的基本方法 32.1.4恢复测试 52.5.2安全测试 52.5.3强度测试 52.5.4性能测试 53.软件测试的误区 63.1误区之一 63.2误区之二 63.3误区之三 73.4误区之四 73.5误区之五 74.软件测试的流程 84.1测试流程说明 84.1.1需求阶段 84.1.2测试计划阶段 84.1.3.测试准备阶段 94.1.4测试执行阶段 94.1.5.测试结果分析阶段 94.1.6.上线准备阶段 94.1.7.上线后测试跟踪阶段 104.1.8.项目总结阶段 104.2需求梳理 104.2.1需求梳理 104.3测试计划 114.3.1测试工具选取 114.3.2测试人员分配 124.3.3测试环境梳理 124.3.4测试数据梳理 124.4测试准备 124.4.1构建代码管理 124.4.2测试环境搭建 124.4.3测试数据脚本编写 134.5测试用例编写(功能测试框架) 134.5.1界面友好性测试 144.5.2功能测试 154.5.3业务流程测试(主要功能测试) 164.5.5容错测试 174.5.6稳定性测试 174.5.7常规性能测试 174.5.8易用性测试 184.5.9兼容性测试 184.6

测试执行 184.6.1接口自动化测试 184.6.3传统测试用例测试 194.6.4Bug跟踪 194.7

测试结果分析 204.7.1结果收集 204.7.2结果分析 204.7.3测试分析报告 204.8上线准备 204.8.1版本发布 204.8.2数据准备 214.9上线测试跟踪 214.9.1跟踪测试 215.项目性能工具测试 215.1用Jmeter进行接口和性能测试 215.1.1ApacheJMeter介绍 215.1.2ApacheJMeter能做什么？ 225.1.3性能测试目标 225.1.4Jmeter元件 225.1.5JMeterhttp接口脚本 245.2用LoadRunner进行性能测试 345.2.1测试步骤与展示 351. 结束语 542. 参考文献 55PAGE2PAGE21.概述1.1软件测试的定义软件测试是软件生存周期中重要的步骤，也是保证软件质量的重要步骤。简言之，软件测试是对软件需求分析、设计标准和软件发布前的最终的分析。1983年IEEE软件工程术语提出的软件测试的定义是与手动或自动手段“测试执行或测量一个软件系统的满足预定的需求，设计成表现出预期的结果和实际结果之间的差异。这一定义明确指出软件测试的目的是验证软件系统是否满足要求。 从用户的立场上看，他们希望通过软件测试暴露程序中存在的问题，因此软件测试应该是“为找出错误的程序执行过程”。换言之，软件进行测试应根据软件系统设计发展阶段的需求规格说明和程序的内部管理架构，精确设计出各功能分析模块的测试用例（即数据的预期的输入、输出结果），并利用我们这些测试用例运行工作程序，从而研究发现应用程序的错误或缺陷。1.2软件测试的目的、原则、基本要求1.2.1测试的目的

1.检验软件的实现是否符合用户的预期需求。2.尽可能找出程序中存在的缺陷和错误。1.2.2基本要求1.对软件体系中总体设计思路和详细设计过程的了解。2.对整个软件系统的数据流程要十分清晰。1.2.3测试用例由编写的测试数据与预期结果的组合。在未执行测试前，得根据设计文档里的功能要求编写测试数据和步骤，以及相应的预期结果。这也是用例编写的基本准则和有效测试覆盖测试场景的最好途径之一。1.2.4测试原则1.根据需求设计文档得出预期输出结果。2.全面复查测试后结果，对测试bug进行归类、认真详细的分析。3.对于达不到预期的输入输出数据，也考虑进去，从而编写测试用例。4.站在用户的角度去验证每个功能的模块，不要总依赖开发人员的技术，也不要误认为软件中不可能出现bug。只要你认为不合理的事情，所以即使是输出正确的，也应该对此提出质疑。5.功能模块测试后，剩余的bug数与提出bug数成比例。对于一个模块中提出的bug数量越多，越需要对其进行严格和彻底的测试。6.保存测试用例。。2.软件测试的方法2.1软件测试的基本方法软件测试的方法和技术有很多种。从软件测试技术的角度看，软件测试技术分为静态和动态测试。从软件业务结构和系统内部算法结构的层面看，也总结为白盒测试和黑盒测试。2.1.1黑盒测试黑盒测试也叫功能测试或数据驱动的测试,是成型的并具有一定操作性的产品，其必须通过测试来验证其功能,具体到每个功能模块是否符合用户要求和是否能正常使用。假如一个测试系统,把它比喻成一个完全不能打开黑盒子,当中也不考虑其内部结构与特性。在测试界面,只根据设计文档和需求说明书验证是否能正常使用？预期的输入和输出结果是否正确？黑盒测试方法主要分为以下几类：等价类的划分法、边界值分析法、因果图法、错误推测法等，其作用用于软件功能验证性测试。黑盒测试侧重于系统的外部结构，从而不去考虑内部逻辑结构，以及对软件接口和功能的测试。黑盒测试是一种穷举输入的测试，它的目的是尽可能的覆盖所有功能场景作为输入测试情况时，从而发现程序中隐藏的问题。但实际上有无穷无尽的测试场景。在这种情况下，测试人员不单单要测试验证所有正确合法的输入条件，还要测试验证那些无效类且不合法的输入条件。2.1.2白盒测试白盒测试也称为逻辑驱动测试。它了解产品的内部工作过程，并且可以使用测试来检测产品的内部逻辑是否按照规范正常执行。根据程序的内部结构测试过程，检查程序中的每个项目。每个通道是否可以根据预定要求正确地工作，而不论其功能如何，白盒测试的主要方法包括逻辑驱动，基础电路测试等，这些方法主要用于软件验证。“白盒”方法全面了解了程序的内部逻辑结构，并测试了所有逻辑路径。“白盒”方法是详尽的路径测试。使用此方案时，测试人员必须检查程序的内部结构，从检查程序的逻辑开始，并获取测试数据。整个程序中独立路径的数量是天文数字。但是，即使每条路径都经过测试，仍然可能会出现错误。首先，详尽的路径测试永远不会发现程序违反了设计规范，也就是说，程序本身是错误的程序。其次，穷举路径测试由于缺少路径而无法检测程序中的错误。第三，详尽的路径测试可能找不到一些与数据相关的错误。2.1.3单元测试的基本方法单元测试针对软件设计模块的最小单元，单元测试的基础是详细的设计说明。单元测试需要为模块内的所有关键控制路径设计测试用例，以便发现模块内的错误。单元测试主要使用白盒测试技术来允许并行测试系统中的多个模块。单元测试任务单元测试任务包括：1模块接口测试；2模块内局部数据结构测试；3模块边界值条件测试；4独立执行路径测试；5模块的每条错误场景路径测试，仅当数据可以正确输入输出模块时，测试才存有意义。测试数据接口的准确性应考虑以下主要因素：1.输入的实际参数和形式参数的数目是否相同，属性是否匹配。2.输入的实际参数和形式参数的尺寸是否相同3.调用以及其他管理模块时指定的实际工作参数数目是否与被调用功能模块的正式参数数目相同。4.调用另一个模块时指定的实际参数属性是否与被调用模块的正式参数属性相匹配。5.调用其他模块时指定的实际参数的尺寸是否与已调整模块的形式参数的尺寸匹配。6.调用预定义函数时使用的参数的数量，属性和顺序是否正确？7.是否有与当前入口点无关的参数引用？8.只读参数是否已更改。9.整个过程变量的定义在每个模块中是否一致。10.是否将特定约束作为参数传递。如果模块包含外部输入和输出，则还应考虑以下因素：1.文件属性问题2.OPEN/CLOSE语句是否匹配3.格式说明是否与输入和输出语句匹配。4.缓冲区大小是否与记录长度匹配。5.是否在使用前打开了文件。6.是否处理文件结尾。7.是否处理输入/输出错误。8.输出信息中是否有文本错误。检查本地进行数据结构设计是为了确保在程序执行工作期间临时存储在模块中的数据是完整且正确的。部分数据结构通常会导致错误。应仔细设计测试用例，以发现以下类型的错误：1.对不适当或不兼容类型的描述。2.变量没有初始值。3.变量初始化或默认值不正确。4.变量名称不正确（拼写错误或被截断）。5.发生溢出，下溢和地址异常。除了本地数据结构外，单元测试还应确定全局数据对模块的影响。每个独立的执行路径都应在模块中进行测试。单元测试的基本任务是确保模块中的每个语句至少执行一次。此时，测试用例旨在发现由于计算不正确，比较不正确以及控制流程不正确而导致的错误。目前，基本的通过测试和循环测试是最常用和最有效的测试技术。计算中的常见错误是：1.误解或使用了错误的操作员优先级。2.混合操作。3.变量的初始值不正确。4.精度不足。5.表达式符号不正确。比较决策和控制流通常紧密相关，并且测试用例还应着重于发现下一个错误：1.比较不同数据类型的对象2.逻辑运算符或优先级的滥用3.由于计算机精度显示的显示，导致两个相差不大的值强制相等。4.比较操作或变量错误。5.循环结束条件可能不会显示。6.当迭代分歧时，它不能结束。7.无意中更改了循环变量。一个好的设计应该能够预期不同的错误情况并预设不同的错误处理路径，错误处理路径也应仔细测试，该测试应针对以下问题：1.输出错误消息难以理解。2.记录错误与实际发生不匹配。3.系统在程序定义的错误处理部分执行之前进行了干预。4.异常处理不当。5.异常捕获的提示不能精确定位。2.1.4恢复测试恢复测试主要检查系统运行时的容错能力。当系统中突然发生错误时，是否可以在指定的时间间隔内自动更正错误？恢复测试必须首先使用各种方法强制系统故障，例如服务运行时突然断电，突然手工关闭执行系统，然后验证系统重启是否可以自行恢复？不会造成执行系统内的文件丢失，这好比数据库的自动回滚操作，对于重启执行服务，后台机制得重新验证文件的一致性和完整性，例如模块重新初始化，图算法的初始化，检查点机制（datarecovery)。还得去记录恢复时长，保证其在一个正常的耗时范围内。2.5.2安全测试安全测试检查系统防止非法入侵的能力。在安全测试中，测试人员假装为非法侵入者，并使用各种方法试图突破防线。2.5.3强度测试强度测试检查程序对异常情况的抵抗力，测试始终会强制系统在异常资源分配下运行。2.5.4性能测试对于那些实时和嵌入式系统，即使软件部分满足功能要求，也可能无法满足性能要求。尽管从单元测试来看，每个测试步骤都包括性能测试，但是只有在系统真正集成之后，它才能在实际环境中按需针对使用场景较高的模块进行全方位的性能测试，其中就包括并发测试和稳定性测试，系统性能测试就是要完成这一任务。性能测试通常需要其他软件和硬件的配套支持，要不然会造成硬件上的瓶颈，从客观因素降低系统的性能值，文章后面会着重介绍这部分。

3.软件测试的误区随着互联网产业规模的不断扩大和软件设计越来越复杂，市场上的产品质量参差不齐，质量高产品优秀的例子少之又少。还有，软件质量和用户体验越来越得到重视，因此，软件测试在项目中的地位越来越举足轻重，把守着软件质量的最后的一到关卡。但现实是，软件测试与软件开发比较，目前国内测试的地位并未得到根本上的重视，常见的开发测试配比都是6:1甚至10:1,。项目组人员仍存在对软件测试的偏见，项目周期的紧张从而压缩测试人员配比和测试时间，从而影响了测试活动的执行。3.1误区之一根据软件开发流程思路，软件项目会经历一下几个阶段：需求分析、概要设计、详细设计、软件编码、软件测试和软件发布。所以人们通俗的认为软件测试的开展是在编码之后才能执行。由于这种理解的偏差不了解软件测试的周期。其实软件测试从项目的初期开展就开始介入，例如需求评审和分析会，测试计划的撰写，测试用例设计及最终的测试执行。因此，软件测试贯穿软件项目的整个生命周期。在软件项目的每个阶段，必须测试不同的功能和内容，以确保每个阶段的正确性。软件测试的对象不仅是软件代码，而且还包括软件需求文档和设计文档。软件开发和软件测试应该是交互式的。正如单元编码则脱离不了单元测试，待单元测试通过后汇集而成的模块则成为集成测试。如果还是保留项目编码结束后才能介入测试，则在整个项目周期内，留给测试人员的时间就会很紧迫，会导致测试覆盖场景不完善，用例设计的效果和质量都不高，并导致测试执行效率大大降低从而导致产品的质量存在问题。如果编码结束后发现需求设计上与实现的不符，则将花费大量的时间成本去修复它。还有更严重的情况，就是当编码结束后发现的是需求和设计的问题，严重的话有可能要去模块重构，这对整个项目来说是灾难的，会严重拖低项目的进度。3.2误区之二产品上线后存在的问题，都会把锅甩给软件测试人员，质疑他们为什么不能测出问题来？这种偏见很容易使测试人员泄气和不满。软件中的错误可能来自软件项目的每个过程，正如测试环境和生产环境，由于代码构件的差异，也会存在两个环境的版本信息不一致，从而导致问题的出现。还有软件测试只能尽自身最大的能力找出软件中隐藏的缺陷，但不能保证系统软件完全没有一个错误，因为从穷举的思维根本无法覆盖所有的测试场景，从而无法找到所有的错误。所以得更多的从项目管理和项目运作过程寻找原因，从而进行改进。3.3误区之三软件测试并不困难，任何人都可以做到。大部分人认为测试人员只需要点下鼠标和键盘就行了，这是由于软件测试的偏差和对测试技术和方法缺乏深入理解造成的。随着软件工程学科的完善和发展和市场上项目流程的优化，软件测试技术可以独当一面了，并对于高端技术人才方面存在严重缺口，对市场需求有很大的冲击。正如目前软件测试技术更新迭代之快，衍生了很多新型的测试工具、测试框架、搭配着新的测试流程和新理念。并且有很多测试知识需要学习和沉淀。软件测试也和软件开发大同小异，主要围绕着技术和团队的管理，当然掌握这两项技能需要积累大量的项目经验、不断进取的学习精神和管理思维能力。3.4误区之四开发人员对测试不重视，认为测试是单纯是测试人员的事。但实际上在团队里，开发和测试是相互补的存在，脱离了谁都不行。还有测试人员，开发人员和设计人员需要保持紧密的沟通确保对产品的认知上不出现任何偏差。其次开发人员应对自己的模块负责，做好单元测试，测试人员可以在必要时根据自身测试经验帮助设计测试单元用例。在软件周期内，越早发现的bug，修复的时间成本就会越低。开发人员有时候会因为测试提多的bug而苦恼，认为测试人员有意而为之，但换个角度想，开发可以根据bug的修复分析软件错误的类型，以找出错误的位置和原因，从而积累开发经验，避免碰到同类问题再次踩坑。3.4误区之五当项目进度紧张时，从而压缩测试的时间，而在时间充裕时，则进行更多的测试。这说明了对软件测试存在很大的偏见和误解，也是整个目前中小型企业管理混乱的通病，以为有产出了就能收到客户的回款，谁不知由于产品质量不过关反而弄巧成拙。对于项目实施中的任何问题，必须进行风险分析和准备相应的对策。不要因为前期需求调研拖延或编码进度滞后而强制缩减测试执行时间、测试的人员分配。由于缩短测试时间会带来不完整的测试。因此，由于项目产品质量严重下降导致系统的不稳定性。例如系统的运维，客户的善后，功能的变更通常会导致更大的浪费，导致客户对整个系统的信心逐步消磨，所以解决的方案是加强对项目的管控，包括计划、进度、产出。

4.软件测试的流程随着互联网产业规模的不断扩大和软件设计的复杂性不断增加，市场上的产品质量参差不齐，质量高产品优秀的例子少之又少。还有，软件质量和用户体验越来越得到重视，因此，软件测试在项目中的地位越来越举足轻重，得指定完整的软件测试流程图，提高软件测试软件的质量和效率4.1测试流程说明4.1.1需求阶段测试人员了解项目需求及需求变更，包括设计文档、业务结构及功能模块划分，根据需求设计梳理测试点。4.1.2测试计划阶段测试工具选取测试人员分配测试环境梳理测试数据梳理4.1.3.测试准备阶段构建代码管理测试环境搭建测试数据脚本编写测试用例编写(功能测试框架)界面友好性测试4.1.4测试执行阶段测试结果分析阶段上线准备阶段上线后测试跟踪阶段项目总结阶段后面会详细讲解这部分4.2需求梳理4.2.1需求梳理根据需求文档、需求四件套来对测试模块功能点进行梳理，而且通过需求文档能够更加清楚项目的业务背景，业务架构，一般情况下，在项目中需求文档有3种现状：1. 有详细的需求文档：严谨且流程管理规范的项目研究团队是有详细的需求分析设计文档的，身为测试技术人员的我们可以详阅需求文档来进行测试点的梳理工作，在需求评审阶段对于需求中你认为功能不明确的地方可以找设计主要负责人或项目经理进行有效沟通，对需求做到整体把握和详尽的理解，利于提高我们通过测试更好的进行。。2.设计不明确或文档不完善：对于我个人处理，如果和开发沟通后明确设计不合理或不明确，我们会共同去拉一个群找到设计人员去确认需求，如果因为设计人员回复不及时或没有下文回应，那么就需要自己去面对面沟通，记录疑问点并抛出问题去咨询设计人员，测试人员切记不要含糊不清的进行测试，要不然后续吃亏的还是自己。3.没有需求文档：根据自身经验，觉得该功能设计效果和系统实现不合理，我会去大群里找到相应设计负责人问，协商沟通，说出自己的讲解，督促设计人员规范流程，补全设计文档及要求。4.3测试计划4.3.1测试工具选取测试工具说明：图中罗列了一些市面上常用的工具，包括UI、接口、性能等工具，可按需选用。4.3.2测试资源分配测试计划制定后，测试经理需要分配好测试单给相应的测试人员。例如：环境搭建负责人、模块测试负责人、模块测试用例编写负责人、业务测试数据脚本负责人、执行测试的负责人。由于测试资源的经常，有可能每个测试人员负责一个或者多个功能模块，但全能型选择也大有人在，即一个人完成的编译环境，准备测试数据，编写测试用例，测试执行的情况下错误收集分析。当然，这对测试工作人员的技能掌握一定程度较高才行，合理的资源进行分配能更好保证企业产品的输出质量。。4.3.3测试环境梳理及搭建根据项目的要求，执行系统清单、服务器数量(应用服务、数据库服务器)，制定测试环境搭建关系图（分离部署系统、分布式服务器，整个系统部署的流程及每个应用、环境监测工具、数据库、辅助性测试工具等）。4.3.4测试数据梳理测试数据包括大量的内容，包括测试制剂和所需的所有数据源，如测试执行阶段如：需求设计文档、测试数据脚本、数据库脚本、测试参数化文件测试账号测试工具让测试工作按预定计划的进行，而不是项目提测后，缺哪样补哪样，严重降低工作效率4.4测试准备4.4.1构建代码管理集中管理，开发人员代码仓库应与测试代码仓库进行分离，互补干扰影响，当开发提测给测试人员进行测试时，开发人员提交构建到测试阶段，测试人员基于测试阶段测试通过后把构建移动到体验阶段做系统测试，系统测试通过后移动到正式阶段发布。4.4.2测试环境搭建参考4.3测试计划的4.3.3测试环境梳理及搭建，按照预先计划，以应用服务器部署策略，以建立一个测试环境，打造环境的未来保存的更清晰的概念也比较方便。市面上听闻很多关于测试环境这块的梳理和管理的工作，有的是专职运维人员来管理环境，但我接触的大部分都是由测试团队自个维护的，所以这对测试人员运维要求也是蛮高的，特别是windows基本及数据库操作，包括数据库的创建，备份与恢复等等。但前提是需要保证的是测试环境应当与开发环境相互独立，也能更好的定位问题所在。这是我工作后发现的现象：开发人员在功能开发完成后质量不保证，很多肉眼可见的bug，还会乱部署到开发环境，而因为开发环境没人去统一的运维人员去管理,从而有可能环境里杂七杂八的报错促使无法进行调试。甚至有的开发人员未经自测直接部署在测试环境上，这样带来一个后果就是，测试环境会变得越来越不稳定，时间一长，测试环境的数据会越来越乱，甚至还会造成测试环境的停摆，测试工作的滞后导致增加测试人员的工作量。4.4.3测试数据脚本编写4.5测试用例编写(功能测试框架)测试用例编写不是随心所欲，得根据对功能背景和实际场景的了解，并按照一定的逻辑思路去编写，一般公司都会存在公共业务用例库和用例模板，掌握基本知识点后对新手测试是很友好的，还有关于项目测试流程图，当然随着自己职业生涯的发展，应当积累一些工作经验，写出复用性强的测试框架，让项目可根据指定测试框架执行测试，从而提升测试效率。4.5.1界面友好性测试1.风格、样式、颜色是否协调2.界面布局是否整齐、协调（保证全部显示出来的，尽量不要使用滚动条3.界面操作、标题描述是否恰当（描述有歧义、注意是否有错别字）4.操作是否符合人们的常规习惯（有没有把相似的功能的控件放在一起，方便操作）5.提示界面是否符合规范（不应该显示英文的cancel、ok，应该显示中文的确定等）6.界面中各个控件是否对齐7.日期控件是否可编辑8.日期控件的长度是否合理，以修改时可以把时间全部显示出来为准9.查询结果列表列宽是否合理、标签描述是否合理10.查询结果列表太宽没有横向滚动提示11.对于信息比较长的文本，文本框有没有提供自动竖直滚动条12.数据录入控件是否方便13.有没有支持Tab键，键的顺序要有条理，不乱跳14.有没有提供相关的热键15.控件的提示语描述是否正确16.模块调用是否统一，相同的模块是否调用同一个界面17.用滚动条移动页面时，页面的控件是否显示正常18.日期的正确格式应该是XXXX-XX-XX或XXXX-XX-XXXX:XX:XX19.页面是否有多余按钮或标签20.窗口标题或图标是否与菜单栏的统一21.窗口的最大化、最小化是否能正确切换22.对于正常的功能，用户可以不必阅读用户手册就能使用23.执行风险操作时，有确认、删除等提示吗24.操作顺序是否合理25.正确性检查：检查页面上的form,button,table,header,footer,提示信息，还有其他文字拼写，句子的语法等是否正确。26. 进行异常操作时，提示报错信息应明确，而不是报一大串代码错误那种，无法识别错误。27.页面分辨率检查，在各种分辨率浏览系统检查系统界面友好性。28.合理性检查：做删除,更新,新增,取消,回退等操作，是否做到友好提示？提示信息是否准确？能否正常触发相应的功能？4.5.2功能测试1.使用所有默认值进行测试2.根据所有需求文档、产品文档中描述的内容要进行场景覆盖测试3.输入判断4.所有界面出现是和否的逻辑？5.异常处理6.敏感词7.根据需求文档的流程图遍历所有流程图路径8.根据程序内容，遍历ifelifelseswitch的逻辑点要遍历9.界面各种控件测试字符型输入框1.字符型输入框：英文全角、英文半角、数字、空或者空格、特殊字符“~！@#￥%……&*？[]{}”特别要注意单引号和&符号。禁止直接输入特殊字符时，使用“粘贴、拷贝”功能尝试输入。2.长度检查：长度检查：最小length、最大length、最小length-1、最大length+1、复制粘贴时，超出文本框也能正常粘贴进去。3.空格检查：输入的字符间有空格、字符前有空格、字符后有空格、字符前后有空格4.多行文本框输入：允许输入换行的回车符，显示保存后可以保存输入的格式，只输入回车换行，并检查是否能正确保存（如果是，则检查保存结果；如果没有，检查是否有正常提示）数值型输入框1.边界值：最大值、最小值、最大值+1、最小值-12.位数：最小位数、最大位数、最小位数-1最大位数+1、输入超长值、输入整数3.异常值、特殊字符：不输入任何值、空格、~!@#$%^&*()_+{}|[]\:"<>?;',./?;:'-=等特殊符号的组合4.5.3业务流程测试(主要功能测试)业务流程，数据通常涉及多个模块，所以当业务流程测试，我们首先要保证各个模块功能的正确性，然后是对各个模块的测试，这往往容易出现问题的地方之间必要的数据传输，一定要测试用于测试不同的设计数据。涉及到增删改的模块，则需要以下案例制定测试用例：1.单项功能测试（增加、修改、查询、删除）2.增加——>增加——>增加（连续增加测试）3.增加——>删除4.增加——>删除——>增加（新增加的内容与删除内容一致）5.增加——>修改——>删除6.修改——>修改——>修改（连续修改测试）7.修改——>增加（新增加的内容与修改前内容一致）8.修改——>删除9.修改——>删除——>增加（新增加的内容与删除内容一致）10.删除——>删除——>删除（连续删除测试）4.5.5容错测试1.输入系统不允许的数据作为输入2.把某个相关模块或者子系统停掉，验证对当前系统的影响3.配置文件删除或者配置错误4.数据库注入错误数据4.5.6稳定性测试1.系统不间断运行（24h*7d），验证内存是否回收？内存是否溢出、泄漏，磁盘容量不足，网络波动，丢包或系统服务器资源是否存在泄露。2.如果项目急着上线，可以根据调研得出的实际性能场景跑一晚上或者利用周末的时间来跑。在强负载的情况下，一般数据连接数问题、内存溢出和泄漏问题会体现的更加明显。4.5.7常规性能测试1.压力测试压力测试安排在系统相对稳定，且模块变更不大后进行，在模拟客户网络环境、硬件环境等进行测试。系统运行性能反馈不是一个测试组或者整个项目人员就能反馈出来的。请求的数量和实际使用人事制度将能够处理远远超出了这个范围，因此，只有在网络上，接受压力测试的结果，以到达最准确的是最真实的。。进行压力测试指的是极强的负载，大并发用户数，大请求和数据量的手段去测试系统，看系统是否具备良好的容错能力和故障恢复能力。黑客常常提到的ddos攻击，就是大量错误的数据请求，执行系统承受不了从而崩溃。压力测试包括列表加载、登录、数据库压测、导入及其他常用核心页面等。4.5.8易用性测试1.系统界面的控件是否可以通过tab键操作，并且顺序合理2.主要功能的入口和操作是否易于理解3.界面是否布局合理，功能是否易于查找和使用4.操作步骤5.操作习惯6.有足够的提示信息，且信息文字描述准确4.5.9兼容性测试兼容性测试不仅是指在不同的操作系统或浏览器中，测试的某些功能，同时也考虑到兼容性，包括操作系统和兼容兼容应用软件兼容的接口，还可以包括硬件兼容性。比如涉及到ajax、jquery、javascrip等技术的，都要考虑到不同浏览器下的兼容性问题。4.6

测试执行4.6.1接口自动化测试目前市面上主流的接口测试工具有：jmeter、robotframework、httprunner、测试框架等。自动化测试的执行可以版本上线后将上线版本的自动化测试的可手动触发由jenkins自动触发规则的任务，或用于自动构建工具来执行，工具目的是要取代的一个部分off手工操作，减少了重复的工作，减少重复性工作，提升测试效率；正如我目前所用的python+httprunner+jenkins组合，版本发生迭代时，Jenkins通过定时任务去运行python+httprunner框架脚本，调整定时任务运行编写好的接口脚本，并生成测试报告并通过邮件方式或者微信公众号的方式接受测试接口异常警告等。这样运维人员能在第一时间清楚目前版本质量情况，有问题发生的话也能马上进行响应处理。报告包含异常的接口，减少人工去一个个检查的时间，更多的时间去处理异常和接口维护。通常项目上线后除非设计变更，要不然接口参数一般不会去进行改动。实际情况是增加接口数，或者针对一些接口进行一些小幅度修改，那样的话接口脚本只需稍微调整就行，复用性及可维护性强。4.6.3传统测试用例测试目前常用的用例的设计方式有：等价类划分法场景法边界值法正交分解法因果图法错误推测法随机测试等根据这些方法可以根据实际情况组合使用，根据需求设计文档编写测试用例，罗列测试要点，覆盖功能测试点，提示测试效率和软件质量的把控。这里给出一个等价类划分法结合边界值方法的测试用例设计例子：这里给出一个日期控件的用例：年日月型在录入框中录入内容为空，进行保存1．保存成功（允许保存空值）2．保存不成功，弹出提示信息，确定后，将焦点定位到当前录入框（不允许保存空值）录入YYYY（年份）的值在【1895，2100】区间内1．系统识别为合法年份，允许进行下一步操作录入YYYY（年份）的值不在【1895，2100】区间内1．系统识别为非法年份，不允许进行下一步操作录入MM（月份）的值在【1，12】区间1．系统识别为合法月份，允许进行下一步操作录入MM（月份）的值不在【1，12】区间1．系统识别为非法月份，不允许进行下一步操作录入年份为闰年的2月，录入的日期为29允许进行保存录入年份不是闰年的2月，录入的日期为29不允许保存，提示相关信息录入的年份、月份、日期中的任何一组数据，带有小数位数。1．不允许进行保存（例如：2.07-01-02、2007-1.-10）或2．系统直接控制不允许录入小数点的内容录入格式为非日期格式。1．系统识别为非法月份。不允许进行下一步操作；（如：2007-01-*1、200H-04-05、2007-0！-01）或2．系统直接控制不允许录入字符内容录入格式为非日期格式。1．系统识别为非法月份。不允许用户进行下一步操作；或系统可以直接控制不允许录入字符内容（如：2007-01-*1、200H-04-05、2007-0！-01）在整型录入框中，使用上箭头调整年份【如：基数=1】1．调整后的数据值=原值+1在整型录入框中，使用下箭头调整年份【如：基数=1】1．调整后的数据值=原值-1在整型录入框中，使用上箭头调整月份【如：基数=1】1．调整后的数据值=原值+1在整型录入框中，使用下箭头调整月份【如：调整基数为1】1．调整后的数据值=原值-1在整型录入框中，使用上箭头调整月份，使其调整到大于【最大值】1．调整数据到最大值后，在使用上箭头调整时，系统不应该在做任何操作在整型录入框中，使用下箭头调整月份，使其调整到小于【最小值】1．调整数据到最小值后，在使用下箭头调整时，系统不应该在做任何操作在整型录入框中，使用上箭头调整日份【如：调整基数为1】1．调整后的数据值=原值+1在整型录入框中，使用下箭头调整日份【如：调整基数为1】1．调整后的数据值=原值-1日月期型：日输入[0日]程序应提示错误日输入[1日]OK日输入[32日]程序应提示错误月输入[1、3、5、7、8、10、12月]、日输入[31日]OK月输入[4、6、9、11月]、日输入[30日]OK月输入[4、6、9、11月]、日输入[31日]程序应提示错误输入非闰年,月输入[2月]、日输入[28日]OK输入非闰年,月输入[2月]、日输入[29日]程序应提示错误(闰年)月输入[2月]、日输入[29日]OK(闰年)月输入[2月]、日输入[30日]程序应提示错误月输入[0月]程序应提示错误月输入[1月]OK月输入[12月]OK月输入[13月]程序应提示错误时间型：时间型合法性检查时输入[30时]允许输入30时制的项目“OK";

不允许输入30时制的项目程序应提示错误时输入[31时]程序应提示错误时输入[00时]程序应提示错误30时制是否允许存在1点~5点？？分输入[59分]OK分输入[60分]程序应提示错误分输入[00分]OK秒输入[59秒]OK秒输入[60秒]程序应提示错误秒输入[00秒]OK异常值、特殊值输入[空白(NULL)]或“~!@#$%^&*()_+-={}[]|\:;”’<>,./?;”等可能导致系统错误的字符程序应提示错误4.6.4Bug跟踪测试人员必须记录和跟踪在测试过程中发现的问题，不要以为小bug口头上对开发人员通知一下。因为bug的记录有利于项目各负责人了解系统的真实的质量情况。目前常用的bug管理工具：禅道、vteam等，从用例的执行到bug记录，通过测试人员指派给开发人员，bug的返工次数，只至bug的解决并关闭。贯穿整个bug的生命周期，当中都能实时看到并进行严格的管控，帮助项目经理、产品经理对当前系统情况有个清楚的认知，并根据实际情况进行产品优化，质量的把控。4.7

测试结果分析4.7.1结果收集测试脚本运行结果，测试用例报告、性能测试报告、数据库性能和监控报告、执行系统服务器资源监控报告、中间件日志报告等。譬如：1、测试用例：用例执行pass或failed总数2、性能测试结果：堡垒机资源监控结果（包括cpu资源、硬盘i/o，内存使用等）。收集上述问题并进行汇集，根据实际情况按需排产解决；4.7.2结果分析汇总各模块的测试结果，在bug管理软件收集得到各迭代版本的bug总数，过滤出严重bug数，得出bug返工率等，找出bug集中在哪些模块？通过组内讨论给出相关改进。通过性能测试结果逐步完善性能指标，与旧版本比较是否较于上次性能有所提升？4.7.3测试分析报告根据分析报告，制定系统的性能指标值，公布于项目组内，提供项目上线后的风险评估，如果对项目技术架构和业务架构熟悉，还可以提供系统的改进计划，提高软件的质量。4.8上线准备4.8.1版本发布经过测试人员测试通过后和项目组的评估，可以进行发版发版内容需给出：代码包、数据库等材料发布文档：用户手册、部署手册、实施手册、测试报告文档、版本说明4.8.2数据准备上线前测试跟踪需要做好准备工作，避免上线后，影响工作效率如模块数据准备回退版本方案测试脚本4.9上线测试跟踪4.9.1跟踪测试1.系统上线并功能稳定后，可以开展接口自动化测试，保证系统间常用接口功能正常；2.每次迭代后要对常用的核心功能进行重点测试；3.做好bug的跟踪记录工作，根据优先级进行排产，bug严重级别高需要开发修改后再进行一轮的复测。对于一般性bug，例如某个界面提示语问题，普通UI问题、错别字问题，需做好优化问题记录4、测试人员需要积累项目的bug经验，或者参考同行的测试用例，提升自身的测试水平，改善缺陷预防体系，完善测试用例库，进行组内分享。5、bug问题做好标签分类，纳入公共用例库，杜绝以后发生类似的问题，提高用户体验同时兼顾项目的实际情况。6、项目成功上线后，要对于项目整体的质量做总结分析，产出总结报告。。。5.项目性能工具测试5.1用Jmeter进行接口和性能测试5.1.1ApacheJMeter介绍5.1.2JMeter能用来做什么？1）能够对HTTP/FTP等协议进行接口和性能测试2）完全Swing的轻量级组件支持3）分布式压力测试4）缓存和离线分析/回放测试结果5）提供测试数据分析6）各种报表数据图形展示7）高可扩展性5.1.3性能测试目标基于系统业务量的要求，评估该系统的软、硬配置能否满足性能需求进行配置测试，找到相对合理的配置对系统进行定容定量，提供规划参考（确定测试场景）验证系统的稳定性，验证系统的容错能力测试并找出系统可能存在的性能问题，分析系统瓶颈风险5.1.4Jmeter元件测试计划：Jmeter性能测试工程计划，属于一个管理单元，本下是各种元件的组成元素，类似编译器中的project取样器：设置测试样本，向服务器发送请求接受及记录服务器的响应信息逻辑控制器：对元件进行执行顺序逻辑的控制，常用的逻辑控制器有18个，但大致分类两类，控制测试计划中sampler执行节点的逻辑执行顺序，常用的就If控制器、循环控制器等。对sampler节点进行分组，便于测试结果的统计和运行控制，常见的有事务控制器、吞吐量控制器。配置元件（ConfigElement）：对静态数据配置的支持。（如，HTTPCookieManager可以用于对HTTPRequestSampler的cookie进行管理）定时器：设置sampler的等待时间，和LR里“思考时间”如出一辙。常用的定时器SynchronizingTimer（与LR集合点作用相似）、常数固定定时器等。前置处理器：对请求发送前做一些特殊处理或者参数准备,例如参数化，数据库JDBC连接等。后置处理器：一般用于提取请求发送后服务器返回值，类似于LR里的关联，譬如说A请求输出，它同时也作为B请求的输入则属于关联。用户登录后获取的token值就是一个很好的例子，我们需要吧token传给服务器通过验证。断言：检查响应数据与预期结果相吻合，断言常用来于设置checkpoint，以确保响应得到的测试数据是否与预期一致。监听器：可视化展示测试结果的数据，常用的元件有：图形结果、察看结果树、聚合报告。

图Jmeter5.0界面5.1.5JMeterhttp接口脚本一个基本的http接口脚本一般分九个步骤：（1）添加线程组，配置线程数（2）添加集合点（SynchronizingTimer）（3）添加HTTPCookie管理（4）添加HTTP信息头管理器（5）添加http请求（6）在http请求中写入接入url、路径、请求方式和参数（7）添加察看结果树（8）添加聚合报告（9）调用接口、查看返回值以下是详细介绍：1）线程组：点击“testplan”——>“add”-——>“Threads(Users)”——->选择“Threadsgroups”并发场景：50Vuser并发进行活动报名，Ramp-Up时间设置0秒（立即生成50个线程数）线程组参数详解线程数：一般指的是虚拟用户数。Ramp-UpPeriod(inseconds)准备时长：在设定的时间内建立线程数。其默认值为0，如果未填写ramp-upperiod，JMeter会瞬间建立所有线程数。打个比方ramp-upperiod设置成S秒，Threads设置成N个，JMeter会每隔S/N秒建立一个线程数。如果线程数为100，准备时长为2，那么需要2秒钟启动50个线程，也就是1秒钟启动25个线程。循环次数：设定单个线程发送请求次数。如果线程数设置为9，循环次数为10，那么每个线程则会发送90次请求。总请求数为90次。如果勾选了“foever”，那么我们所有工作线程会无休止的发送数据请求，直至通过手动进行停止使用脚本或软件奔溃时停止。DelayThreadcreationuntilneeded：延迟线程的创建。调度器：设置线程组启动延迟时间(s)和持续时间(s)(配置调度器时，需要勾选循环次数为永远)2）集合点：右键点击“testplan”>“add”>Timer>“SynchronizingTimer”通过添加SynchronizingTimer定时器来配置集合点。SynchronizingTimer作用仅于同一个JVM中的线程。NumberofSimulatedUserstoGroupby:集合点到达数，通俗来说就是用户达到设定值就出发请求执行。Timeoutinmilliseconds（单位：ms）：虚拟用户超过这个值时但没到集合点算超时，线程会一直等待。Ex：Timeoutinmilliseconds为0时，说明没设置超时时间，线程会一直无限等待。同理，当线程进行数量已经无法满足小于“Number

of

Simultaneous

Users

to

Group

by“中设置的值，线程也会一直都是无限可能等待。3）HTTPCookie管理器如果接口需要权限认证，需要登录用户才可以做操作，则需要添加Cookie”,右键测试计划——>“添加”——>“配置元件”——>“HTTPCookie管理器”；例如：对某一用户进行请求，那么需要验证用户身份，这就需要用到Cookie管理器。Cookie中的“名称(key)”为登录的用户名，如截图中是“JSESSIONID”和Cookie中的“值(value)”可以从登录接口获取，也可以从浏览器RequestHeaders获取；Ex：一个测试计划内最好只建立一个CookieManager，因为多个CookieManager的话Jmeter是无法识别并准确调用的。3．1）获取Cookie方法打开待提取Cookie信息的网页界面并登陆用户，按下F12，打开网页控制台，找到Application一栏，在Storage选择Cookies，选择域名后找到JSESSIONID的值，将它放在Cookie管理器即可通过身份验证； 图Cookie管理器配置成功页面图Cookie管理器配置失败页面4）Http信息头管理器用于配置页面跳转，设定请求头所包含的信息并进行发送。HTTP信息头中包含有“Content-Type””User-Agent"、“Pragma"、”Referer"等属性。在传参的时候，察看结束树发现返回值异常，应该检查一下Content-Type的值是否设置正确。5）JMeterhttp接口脚本（http请求）5.1）JMeterhttp接口脚本【_Random】函数【_Random】函数介绍作用：生成随机数使用格式：${__Random(1,500,myResult_Random)}，其中第一个参数1，表示希望生成的数字最小的值，必填第二个参数500，表示希望生成的数字最大的值，必填第三个特征参数result，非必填项，脚本进行运行过程中生成的值会保存在这个指定变量里，myResult值在

[1,500]之间关系指的是一个包含1和500两个不同数值。6）察看结果树以下是浙交工模块中活动报名请求结果：请求成功的在左侧察看结果树会提示绿色图标，而请求失败则会显示红色图标；【取样器结果】中可以查看响应头、响应数据大小、时间，返回状态码等信息【request】显示请求接口的url、请求参数、responseheader、Cookies等信息；【响应数据】查看接口的返回值7）聚合报告Label：接口请求名称属性Samples：测试的过程中向客户端总共发出了多少个请求即总线程数，（如果模拟1个用户，每个用户迭代9次，这里就显示9），samples数目指的就是这个。Average：指的是请求平均响应时间，计算公式是总运行时间除以对服务器的总请求数，得出对应图形报表中的平均值结果。Median：响应时间中位数，50%用户响应时间低于该值。90%Line：90%用户响应时间低于该值。Min：请求后服务器返回最短响应时间。Max：请求后服务器返回最长响应时间。Error%：事务错误率，事务请求错误数量除于事务请求总数。Throughput：系统吞吐量（传输数据量综合），也叫tps。指每秒完成的请求数，也能反映出服务器处理能力，当tps数值越高说明服务器处理能力越好KB/Sec（ms）：服务器接收到的数据量，即每秒请求的字节数。7.1）90%Line指标值大部分以为这是90%用户平均响应时间，其实不是。官网是这么说的：“90%的用户请求耗时不超过这个时间，而剩余的请求耗时至少在这个时间之上。”也就是说90%的用户请求响应时间少于这个时间。7.2）90%Line意义它可以使我们的分析结果更加准确！因为在评估一次测试的结果时，仅仅有平均响应时间是不够的，而是从多参数指标中去分析。譬如我举个例子，一个接口有50个请求返回结果，其中Min响应为0.03秒，Max响应为100秒，Average事务响应为8.6秒，有没有觉得Min和Max响应时间差距是不是有点高？计算出来的平均值是不是会存在偏差？如果我们根据每个请求统计响应时间，统计表明响应时间最大值出现的机率微乎其微。除开那1%用户请求的响应时间，其余都是性能需求标准范围内。所以为了得出更精确的请求耗时，不仅得参考Average响应时间指标，还要加入90％、95％Line等其他性能指标来辅助统计，这样的出来的结果才能更全面，更贴近实际场景。8）测试结果当我们作为用户去使用一款软件，我们最直观的感知是系统的快慢，请求响应时间是否及时。因此把响应时间作为分析的重点。在处理过程中，可以把响应时间分为如下：呈现时间（浏览器解析）+数据传输时间（网络瓶颈）+系统处理时间（数据库+服务器）--系统瓶颈9）测试结果不难看出，在150虚拟用户并发时，事务成功率有所下降，也许是事务请求出现了瓶颈，导致无法正常返回正常值而到了200用户并发时，90％用户响应呈现指数型上升，事务成功率也有所下降，所以该接口的瓶颈在150~200之间，得需通过测试人员和开发人员的排查，进一步确认瓶颈点出现在哪里。硬件上的性能瓶颈：通常指的是CPU，内存，磁盘I

/

O区域的问题，分为服务器硬件瓶颈，网络瓶颈（LAN上不能被认为是），服务器操作系统瓶颈（参数配置），中间件瓶颈（参数配置，数据库，网络服务器等），应用瓶颈（SQL查询，数据库设计，业务逻辑，算法等）。。应用软件上的性能瓶颈：通常指web服务器、应用服务器和数据库服务器等。例如：JDBC最小、最大连接的参数设置不合理；；Nginx限流配置，js、图片压缩参数、请求过滤等；应用程序上的性能瓶颈：一般指的是项目的开发人员研发的软件程序。例如，1软件内部架构凌乱，底层代码逻辑处理不规范（没进行并行处理、查询语句不规范且没进行调优、线程数请求不够），从而导致上线后大批量用户在访问系统造成性能不足形成瓶颈。2、执行系统的日志级别没有调整，导致后台一直打印输出日志，一定程度上影响了系统性能；网络设备上的性能瓶颈：行业内通俗指的是通过交换机、动态系统负载均衡器等设备。动态负载均衡器：在动态负载平衡器上建立了动态负载分配机制。当发现某个应用服务器上的资源已达到限制时，动态负载平衡器会将后续的操作单元请求发送给其他负载较轻的应用服务器。

在测试中，发现动态负载均衡器没有起到相应的作用，可以考虑网络瓶颈。交换机：网络的传输量，信息吞吐量，传输速度等，在进行并发操作时对网络吞吐量要求高，特别是导入的并发执行，1s内会存在几百兆的下载上传的数据量，而交换机是百兆网口的情况下，会导致传输速率慢，从而不能正常模拟出系统真实的性能情况；

5.2用LoadRunner进行性能测试测试环境：表5-2-1测试服务器端配置

类型设备参数应用服务器硬件环境数量(台)1CPU类型InterXeonE5-2630v4@2.20Ghz（4处理器）16核物理内存(G)32G本地存储1T网络接口千兆网卡1000Mbp/s软件环境操作系统及版本WindowServer2012R2Standard64bitJVM参数-Xms4096m–Xmx8096m服务名浙江交工综管系统正式环境应用服务文件路径D:\vproject\zjjg_rel表5-2-2数据库服务器端配置数据库服务器类型设备参数硬件环境数量（台）1CPUInterXeonE5-2630v4@2.20Ghz（4处理器）16核物理内存(GB)24G本地存储1THBA卡（块）0网络接口千兆网卡1000Mbp/s软件环境操作系统及版本WindowServer2012R2Standard64bit数据库及版本Oracle11g表5-2-3客户端服务器配置客户端（1台）硬件环境客户端配置CPU：AMDRyzen54600U2.1Ghz内存：16GB硬盘：1T其他：

软件环境操作系统：Win1064bit浏览器：Chrome84测试工具：Loadrunner125.2.1测试步骤与展示Step1：代理服务器准备由于lr12录制本质上是通过捕获请求然后转化成相应请求代码的，所以我们首先得捕获请求，这里就用到Fiddler抓包工具，把它当做一个本机的代理服务器，通过端口指定并转发到lr12进行捕获在StartRecording设置界面点击RecordingOptions，选择Network—>PortMapping添加配置（如图）注：trafficforwarding端口与fiddler监听端口保持一直Step2：录制并发登录脚本 1）启动VirtualUserGenerator——>点击左上角“File”——>选择“NewScriptandSolution”,找到HTTP协议，进入主界面； 2）点击图中圆点录制按钮，然后再URLaddress输入客户端ip地址和存放脚本的文件路径，点击StartRecoding就能开始录制了；3）录制完脚本后，我们还要对脚本进行调优和参数化的设置代码如下：lr_rendezvous("login_rev");//集合点设置

lr_start_transaction("login");//登录事务开始web_submit_data("module-operation!executeMultiOperation_13",

"Action=http://xx.xx.xx:1234/module-operation!executeMultiOperation?randomId=0.825345354521178&_request_validate_token_=53573",

"Method=POST",

"RecContentType=application/json",

"Referer=http://xx.xx.xx:1234/module-operation!executeOperation?componentCode=iems_login&windowCode=index",

"Snapshot=t47.inf",

"Mode=HTML",

ITEMDATA,

"Name=ajaxRequest",

"Value=true",

ENDITEM,

"Name=scopeId",

"Value=880ddac59bba8582ed71719f4be35a9e",

ENDITEM,

"Name=componentCode",

"Value=vbase_prdbizframe",

ENDITEM,

"Name=windowCode",

"Value=TR_BG_Action_FrameWindow",

ENDITEM,

"Name=token",

"Value="

"%5B%7B%22data%22%3A%7B%22operation%22%3A%22WinPerm%22%2C%22componentCode%22%3A%22vbase_prdbizframe%22%2C%22windowCode%22%3A%22TR_BG_Action_FrameWindow%22%2C%22moduleId%22%3A%22TR_BG_Action_FrameWindow%22%2C%22transaction_id%22%3Anull%7D%7D%2C%7B%22data%22%3A%7B%22operation%22%3A%22Permission%22%2C%22componentCode%22%3A%22vbase_prdbizframe%22%2C%22windowCode%22%3A%22TR_BG_Action_FrameWindow%22%2C%22moduleId%22%3A%22TR_BG_Action_FrameWindow%22%2C%22transaction_id%22%3Anull%2C%22isAllWidget%22%3Atrue"

"%7D%7D%5D",

ENDITEM,

EXTRARES,

"Url=/itop/vjs/combo/static/297e51fc73093aae01730e213707381d_f331e19a16ce73818c10a14f2b9514c6.js?vjsRequest=true&packageAliases=fB9,fBV,fBW,fBX,fCa,fCb,fCc,fCd,fCe,fCf,fCl,fCn,fUD,fsO,fsQ,fsR,fsS,fsW,fsX,fsY,fsZ&vjsNames=[{%22perty.vbase_prdbizframe.TR_BG_Action_FrameWindow%22:true}]&condition={%22domain%22:null,%22frameworkComponentCode%22:%22toone_mt_projectin_pc_ie%22,%22frameworkInstanceCode%22:%22main%22}",

"Referer=http://xx.xx.xx:1234/"

"module-operation!executeOperation?componentCode=iems_login&windowCode=index",

ENDITEM,

LAST);

web_submit_data("module-operation!executeMultiOperation_14",

"Action=http://xx.xx.xx:1234/module-operation!executeMultiOperation?randomId=0.8071438635468782&_request_validate_token_=32599",

"Method=POST",

"RecContentType=application/json",

"Referer=http://xx.xx.xx:1234/module-operation!executeOperation?componentCode=iems_login&windowCode=index",

"Snapshot=t48.inf",

"Mode=HTML",

ITEMDATA,

"Name=ajaxRequest",

"Value=true",

ENDITEM,

"Name=scopeId",

"Value=880ddac59bba8582ed71719f4be35a9e",

ENDITEM,

"Name=componentCode",

"Value=vbase_prdbizframe",

ENDITEM,

"Name=windowCode",

"Value=TR_BG_Action_FrameWindow",

ENDITEM,

"Name=token",

"Value=%5B%7B%22data%22%3A%7B%22operation%22%3A%22WaterMark%22%2C%22componentCode%22%3A%22vbase_prdbizframe%22%2C%22windowCode%22%3A%22TR_BG_Action_FrameWindow%22%2C%22moduleId%22%3A%22TR_BG_Action_FrameWindow%22%2C%22transaction_id%22%3Anull%7D%7D%5D",

ENDITEM,

LAST);

web_submit_data("module-operation!executeOperation_28",

"Action=http://xx.xx.xx:1234/module-operation!executeOperation?componentCode=vbase_prdbizframe&randomId=0.5555026771752045&_request_validate_token_=30245",

"Method=POST",

"RecContentType=application/json",

"Referer=http://xx.xx.xx:1234/module-operation!executeOperation?componentCode=iems_login&windowCode=index",

"Snapshot=t49.inf",

"Mode=HTML",

ITEMDATA,

"Name=ajaxRequest",

"Value=true",

ENDITEM,

"Name=operation",

"Value=Transaction",

ENDITEM,

"Name=scopeId",

"Value=880ddac59bba8582ed71719f4be35a9e",

ENDITEM,

"Name=transaction_id",

"Value=a9c27674b65e2{random}",

ENDITEM,

"Name=token",

"Value=%7B%22data%22%3A%7B%22transaction_id%22%3A%22a9c27674b65e2{random}%22%2C%22componentCode%22%3A%22vbase_prdbizframe%22%2C%22transaction_action%22%3A%22transaction_begin%22%7D%7D",

ENDITEM,

LAST);

web_submit_data("module-operation!executeOperation_29",

"Action=http://xx.xx.xx:1234/module-operation!executeOperation?componentCode=vbase_prdbizframe&windowCode=&randomId=0.8668021912773864&_request_validate_token_=387907",

"Method=POST",

"RecContentType=application/json",

"Referer=http://xx.xx.xx:1234/module-operation!executeOperation?componentCode=iems_login&windowCode=index",

"Snapshot=t50.inf",

"Mode=HTML",

ITEMDATA,

"Name=ajaxRequest",

"Value=true",

ENDITEM,

"Name=operation",

"Value=ExecuteRuleSet",

ENDITEM,

"Name=scopeId",

"Value=880ddac59bba8582ed71719f4be35a9e",

ENDITEM,

"Name=sourceWindow",

"Value=vbase_prdbizframe.TR_BG_Action_FrameWindow",

ENDITEM,

"Name=transaction_id",

"Value=a9c27674b65e2{random}",

ENDITEM,

"Na