技术领域
[0001] 本发明涉及测试技术领域，具体涉及一种测试模型的构建方法和构建系统。
相关背景技术
[0002] 互联网公司在支撑访问量大、并发量高、海量数据以及用户量不断增长情况下，处理着越来越多的交互业务。一般的交互业务过程为：用户向业务服务器发送业务请求，业务服务器响应该业务请求，进行相应的业务处理，然后将业务处理结果返回给客户。
[0003] 很多情况下，交互业务成倍增长所需的机器资源并不是简单的线性增加，更可能会成几何倍数飙涨，因而，一方面，难以预知的用户负载和愈来愈复杂的应用环境使公司不定时地发生用户响应速度过慢和系统崩溃等问题，性能测试人员经常需复现交互问题，直到开发人员将问题彻底解决；另一方面，面对用户量不断增长的形势，需要预估业务服务器各系统是否能够支撑交互业务需求。无论是复现交互问题，还是预估业务服务器各系统性能，都需要依据测试模型设计测试场景，测试场景中包含的交互业务作用于业务服务器进行相应交互性能测试。
[0004] 目前，测试模型中的交互业务类型和数量通常是开发人员根据对业务服务器的熟悉程度选取的，因而，测试模型依赖于开发人员对业务服务器熟悉程度等主观因素，依据测试模型得到的测试场景难以真实测试业务服务器对交互业务的性能表现，测试模型实用性较差。
具体实施方式
[0088] 以下基于实施例对本发明进行描述，但是本发明并不仅仅限于这些实施例。在下文对本发明的细节描述中，详尽描述了一些特定的细节部分。对本领域技术人员来说没有这些细节部分的描述也可以完全理解本发明。为了避免混淆本发明的实质，公知的方法、过程、流程没有详细叙述。另外附图不一定是按比例绘制的。
[0089] 图1所示是本发明实施例的测试模型的构建方法流程图。参照图1，测试模型的构建方法包括：
[0090] 步骤S101，获取被测试响应性能时间段内的交互日志。
[0091] 需要说明的是，被测试响应性能时间段，即，业务服务器被测试响应性能的时间段，通过测试可以得知，业务服务器在该段时间内对交互业务的响应性能如何，因而，被测试响应性能时间段，是根据测试需求确定的。被测试响应性能时间段，例如有：双十一当天、618秒杀30分钟、上班早高峰10分钟、一般日场景8小时、特殊日场景4小时等。
[0092] 步骤S102，通过交互日志中各类交互业务的名称和数量之间的关联关系，构建生产模型。
[0093] 上述交互业务包括但不限于电商平台常处理的交易类的交互业务。交互业务的数量，即，交互业务在被测试响应性能时间段内被调用的次数，可以使用shell脚本通过分析业务服务器后端接口调用的各类交互业务次数得到。
[0094] 步骤S103，从生产模型中提取测试所需交互业务的关联关系以构建测试模型，其中，测试模型作为设计测试场景的参考模型，测试场景中交互业务的类别以及各类交互业务的数量参考测试模型设置。
[0095] 具体地，上述测试所需交互业务是根据测试需求而定的交互业务，测试需求为复现或预测交互故障，因而，测试所需交互业务和交互故障相关，若没有该测试所需交互业务，则交互故障不会出现。例如，在网购服务的秒杀活动中若出现了重复付款的交互故障，则在测试模型中需要选取请求付款的交互业务为测试所需交互业务。
[0096] 本发明实施例中，生产模型是依据被测试响应性能时间段内的交互日志得到的，生产模型中包括了交互业务的类型和数量之间的关联关系，因而，从生产模型中直接提取测试所需交互业务的关联关系构建测试模型并设计测试场景，且由于测试所需交互业务的种类少于生产模型，即不仅使得测试场景真实地还原了被测试响应性能时间段内被测交互业务的类型和对应数量，且通过较少种类交互业务提高了测试的可实现性，从而提高了测试模型在测试中的实用性，有效地解决了现有技术中测试模型实用性较差的技术问题。
[0097] 在可选的实施例中，如图2所示，步骤S102，通过交互日志中各类交互业务的名称和数量之间的关联关系，构建生产模型，包括：
[0098] 步骤S201，根据交互日志中各类交互业务的数量，对交互日志中各类交互业务的占比进行计算，得到业务占比。
[0099] 步骤S202，将交互日志中各类交互业务的业务占比与名称、数量进行关联，得到关联关系。
[0100] 需要说明的是，交互业务的名称包括但不限于业务序号、业务名字、业务代码。
[0101] 步骤S203，根据业务占比大小，将关联关系进行排序，得到生产模型。
[0102] 具体地，生产模型可以采用表格的形式进行保存，表格的每行存储一条关联关系，关联关系在表格中可以按业务占比从大到小的顺序进行排序，从而业务占比较大的关联关系位于表格中靠近表头的位置。
[0103] 需要强调的是，生产模型是一个包括交互日志中各类交互业务对应关联关系的模型，因而，生产模型中所有关联关系占比之和为100％。图3所示为生产模型的一个示例，该示例中，表格末尾用省略号表示占比小于0.50％的多个关联关系。
[0104] 本发明实施例，通过引入业务占比这一参量，将多个关联关系全面而条理地整理成了生产模型，从而为测试模型的构建提供了系统且条理的可用数据，便于测试模型的快速构建。
[0105] 然而，发明人发现，交互日志中会存在部分交互业务不具备可测试性(下文称为废弃业务)，具体原因很多，比如交互业务的数据不具备重复利用性。对于这种情况，在可选的实施例中，在得到生产模型之后，还包括：
[0106] 判断生产模型中是否存在废弃业务的关联关系，得到第一判断结果；
[0107] 在第一判断结果为生产模型中存在废弃业务关联关系的情况下，从生产模型中删除废弃业务的关联关系，得到更新后的生产模型。
[0108] 需要说明的是，在第一判断结果为生产模型中不存在废弃业务关联关系的情况下，不需要对生产模型进行上述更新。
[0109] 具体地，从生产模型中删除废弃业务的关联关系，得到更新后的生产模型，可以采用如下步骤实现：
[0110] A)从生产模型中将废弃业务的关联关系删除，得到过渡模型。过渡模型，即删除废弃业务关联关系后的生产模型；
[0111] B)对过渡模型中关联关系包括的各类交互业务对应的业务占比进行计算，得到第一调整占比；
[0112] C)通过第一调整占比更新过渡模型中各关联关系中的业务占比，得到更新后的生产模型。
[0113] 上述生产模型，是根据某一被测试响应性能时间段的交互日志得到的，考虑到被测试响应性能时间段内交互业务具有变动性，因而，上述生产模型并不包括所有在被测试响应性能时间段内存在的交互业务，为了使生产模型对被测试响应性能时间段更具备实时性和普适性，需要向生产模型中添加个别交互业务的关联关系。对于此种情况，在可选的实施例中，在得到生产模型之后，还包括：
[0114] 判断是否存在新增业务，得到第二判断结果，其中，新增业务是向生产模型中添加关联关系的交互业务；
[0115] 在第二判断结果为存在新增业务的情况下，将生产模型添加新增业务对应的关联关系，得到更新后的生产模型。
[0116] 需要说明的是，在第一判断结果为生产模型中不存在新增业务的情况下，不需要对生产模型进行上述更新。
[0117] 具体地，将生产模型添加新增业务对应的关联关系，得到更新后的生产模型，可以采用如下步骤实现：
[0118] A)对交互业务集中各类交互业务的占比进行计算，得到第二调整占比，其中，交互业务集由新增业务和生产模型中关联关系所包括的交互业务组成；
[0119] B)通过第二调整占比更新生产模型中各关联关系中的业务占比，并建立新增业务的第二调整占比与名称、数量之间的关联关系；
[0120] C)根据第二调整占比的大小排列顺序，确定新增业务的关联关系添加到生产模型中的位置，并依据确定出的位置将新增业务的关联关系添加到生产模型中，得到更新后的生产模型。
[0121] 上述两个可选实施例从不同角度提供了对生产模型的调整方法，调整后的生产模型更具备实时性和普适性，提高了数据对测试模型构建的利用性，提高了测试模型的实用性。
[0122] 在可选的实施例中，如图4所示，步骤S103，从生产模型中提取测试所需交互业务的关联关系以构建测试模型，包括：
[0123] 步骤S301，将生产模型中预设数量个业务占比较大的关联关系，组成第一关联关系组。
[0124] 具体地，预设数量可以根据第一关联关系组各业务占比之和确定，例如，提取出业务占比较大的预设数量个关联关系，使第一关联关系组各业务占比之和刚达到80％，以图3的示例性生产模型进行说明，则预设数量为11，第一关联关系组由序号1-11的交互业务组成。
[0125] 步骤S302，将生产模型中高优先级交易的关联关系，组成第二关联关系组，其中，高优先级交易包括易引起交互故障的交互业务。
[0126] 应当理解的是，测试模型用于交互故障的复现或预测，易引起交互故障的交互业务属于测试所需的交互业务，即，上述高优先级交易属于测试所需的交互业务。具体地，交互故障的种类包括多种，例如有交互业务收到错误响应，又如有交互业务引起业务服务器的性能变差而降低响应速度甚至无法响应，因而，上述高优先级交易包括易报错交互业务或易引起业务服务器性能问题的交互业务。并且，一些重要交互业务要严格避免交互故障，可以说是不允许任何交互故障的出现，因而，基于这些重要交互业务对交互故障的严格控制程度，这些重要交互业务的任何故障都特别明显，在此意义上重要交互业务也可以被划在易引起交互故障的交互业务中以严格控制交互故障的出现，因而，高优先级交易还可以包括各重要交互业务。例如，在网购服务的秒杀活动中，被抢购商品的后期结账是网购的一个重要交互业务，在保证秒杀活动顺利进行的同时还要确保后期关联的结账不出错误，因而，将秒杀各交互业务作为当前易报错交互业务或易引起业务服务器性能问题的交互业务，高优先级交易还可以包括秒杀后期结账的交互业务。
[0127] 以图3的示例性生产模型进行说明，假设，序号14的关联关系和序号18的关联关系中交互业务为高优先级交易，则第二关联关系组由序号14的关联关系和序号18的关联关系组成。
[0128] 步骤S303，通过第一关联关系组和第二关联关系组构建测试模型。
[0129] 例如，从图3的示例性生产模型中提取上述第一关联关系组和第二关联关系组后，则得到图5所示的测试模型。
[0130] 本发明实施例中，第一关联关系组中的交互业务为占比较大的交互业务，该关联关系组中的交互业务在数量上对压力、负载等交互性能具有较大影响，因而从业务服务器一端会引起交互故障；第二关联关系组中的交互业务为易引起交互故障的交互业务，即在类别上对交互性能具有较大影响，其自身一端会收到错误响应而出现交互故障，因而这两组关联关系组中的交互业务较全面地将引起交互故障的各种测试所需交互业务包括在内，且生产模型中这两个关联关系组的交互业务类别较少，从而，在生产模型提取第一关联关系组和第二关联关系组构建测试模型，则利于通过较少种类的交互业务较真实反映业务服务器的响应性能，提高了测试模型的测试实用性。
[0131] 一些情况下，第一关联关系组和第二关联关系组构建的测试模型，会出现废弃业务。对于此种情况，在可选的实例中，还包括：
[0132] 判断测试模型中是否存在废弃业务的关联关系，得到第三判断结果，其中，废弃业务为不具备测试性的交互业务；
[0133] 在第三判断结果为测试模型中存在废弃业务的的关联关系情况下，对测试模型进行调整，以使测试模型中不包括废弃业务的关联关系。
[0134] 调整方法很多，下面针对两种不同情况提出了对应的调整方法：
[0135] 1)若废弃业务的关联关系属于第一关联关系组，那么，从生产模型中提取第一交互业务的关联关系替代废弃业务的关联关系，其中，第一交互业务为目标模型中较大业务占比对应的可测试性交互业务，目标模型为生产模型剔除测试模型后的剩余模型。
[0136] 进一步，第一交互业务的数量可以为一个，此情况下第一交互业务可以为目标模型关联关系中业务占比最大的可测试性交互业务。第一交互业务的数量也可以为多个，此情况下第一交互业务可以为目标模型关联关系中业务占比较大的多个可测试性交互业务，多个第一交互业务的业务占比之和约等于废弃交易的业务占比。
[0137] 例如，在图5的测试模型中，如果序号9的关联关系所包括的交互业务属于废弃业务，则通过图3所示生产模型中序号12的关联关系替代序号9的关联关系。
[0138] 本发明实施例中，从目标模型中提取业务占比较大的可测试性交互业务作为第一交互业务，有利于通过较少数量的第一交互业务，达到废弃业务的业务占比，从而替代废弃业务在数量上对交互性能的影响。
[0139] 2)若废弃业务的关联关系属于第二关联关系，那么获取第二交互业务，并通过第二交互业务的关联关系替代废弃业务的关联关系，其中，第二交互业务具备测试性，且第二交互业务与废弃业务引起同样的交互故障。
[0140] 进一步，第二交互业务可以选取与废弃业务在引起交互故障程度方面相同的交互业务。交互故障程度，例如，交互故障的范围和速度等。
[0141] 需要说明的是，由于第二交互业务侧重于对交互性能影响的性质，第二交互业务可以从生产模型各关联关系中选取，也可以从生产模型以外的数据库中选取。在第二交互业务从生产模型以外的数据库中选取时，第二交互业务关联关系中的数量可以设置为废弃业务关联关系中的数量。
[0142] 通过上述两种调整方法，对测试模型数据的可测试性进行了核查，确保了测试模型中不再包括废弃业务，提高测试模型的实用性。
[0143] 通过上述方法得到的测试模型包括图5所示的数据，很明显，图5所示测试模型中各关联关系中占比之和不为100％，在可选的实例中，步骤S303，通过第一关联关系组和第二关联关系组构建测试模型，包括：
[0144] 计算第一关联关系组和第二关联关系组中，各类交互业务的占比，得到更新后的业务占比；
[0145] 对于第一关联关系组和第二关联关系组中的关联关系，通过更新后的业务占比替换对应类别交互业务的业务占比，得到更新后的关联关系；
[0146] 通过更新后的关联关系，构建测试模型。
[0147] 进一步，测试模型中，各更新后的关联关系，也可以按照更新后的业务占比大小进行排序。
[0148] 例如，从图3的示例性生产模型中提取上述第一关联关系组和第二关联关系组后，通过本发明实施例提供的方法，则得到了图6所示的测试模型。
[0149] 本发明实施例通过更新后的业务占比，使得测试模型中各更新后的关联关系所包含更新后的业务占比之和等于100％，测试模型中增加的更新后的业务占比这一参数，给出了测试模型作为一个整体情况下，各类交互业务的占比。对于用户量不断增长而需要预估业务服务器交互性能时，则可以根据更新后的业务占比，将测试模型中各类交互业务的数量进行增大，得到一个进行预估测试的测试模型。
[0150] 假如，图6所示是通过去年双十一的交互日志得到的测试模型，如果需要预估今年交互业务总量在2000万情况下，业务服务器是否能够支撑，则只需要通过更新后的业务占比，计算图6所示测试模型在交互业务总量2000万情况下，各类交互业务的数量，然后就可以进行业务量增加时的压力、负载等交互性能测试。
[0151] 以上实施例提供了一种高实用性测试模型的交互业务获取、确定，以及模型构建的方法，通过上述方法构建的测试模型，即可进行业务服务器压力、负载等交互性能的测试。
[0152] 基于上述测试模型的构建方法构建实用性较好的测试模型后，则可以参照该测试模型设计符合实际的测试场景，使得测试场景能够真实有效的模拟生产情况进行性能测试，从而在压力测试时得到符合实际生产环境的压测性能数据，可见测试模型的设计是非常关键的。
[0153] 图7所示是本发明实施例的测试模型的构建系统结构框图。参照图7，测试模型的构建系统包括：
[0154] 获取模块100，用于获取被测试响应性能时间段内的交互日志；
[0155] 第一构建模块200，用于通过交互日志中各类交互业务的名称和数量之间的关联关系，构建生产模型；
[0156] 第二构建模块300，用于从生产模型中提取测试所需交互业务的关联关系以构建测试模型；
[0157] 其中，测试模型作为设计测试场景的参考模型，测试场景中交互业务的类别以及各类交互业务的数量参考测试模型设置。
[0158] 本发明实施例提供的测试模型的构建系统，构建的测试模型是从生产模型转化来的，生产模型是依据被测试响应性能时间段内的交互日志得到的，生产模型中包括了交互业务的类型和数量之间的关联关系，因而，从生产模型中提取测试所需交互业务的关联关系构建的测试模型，是基于被测试响应性能时间段内的交互情况，即使得测试场景以较少种类的交互业务真实地还原了被测试响应性能时间段内交互业务的类型和对应数量，从而解决了现有技术中测试模型实用性较差的技术问题。
[0159] 在可选地实施例中，第一构建模块，包括：
[0160] 计算单元，用于根据交互日志中各类交互业务的数量，对交互日志中各类交互业务的占比进行计算，得到业务占比；
[0161] 关联单元，用于将交互日志中各类交互业务的业务占比与名称、数量进行关联，得到关联关系；
[0162] 排序构建单元，用于根据业务占比大小，将关联关系进行排序，得到生产模型。
[0163] 在可选的实例中，第一构建模块还包括第一更新单元，第一更新单元用于：
[0164] 在得到生产模型之后，判断生产模型中是否存在废弃业务的关联关系，得到第一判断结果，其中，废弃业务为不具备测试性的交互业务；
[0165] 在第一判断结果为生产模型中存在废弃业务关联关系的情况下，从生产模型中删除废弃业务的关联关系，得到更新后的生产模型。
[0166] 在可选的实施例中，第一构建模块还包括第二更新单元，第二更新单元用于：
[0167] 在得到生产模型之后，判断是否存在新增业务，得到第二判断结果，其中，新增业务是向生产模型中添加关联关系的交互业务；
[0168] 在第二判断结果为存在新增业务的情况下，将生产模型添加新增业务对应的关联关系，得到更新后的生产模型。
[0169] 在可选的实例中，第二构建模块包括：
[0170] 第一提取单元，用于将生产模型中预设数量个业务占比较大的关联关系，组成第一关联关系组；
[0171] 第二提取单元，用于将生产模型中高优先级交易的关联关系，组成第二关联关系组，其中，高优先级交易包括易引起交互故障的交互业务；
[0172] 组合构建单元，用于通过第一关联关系组和第二关联关系组构建测试模型。
[0173] 在可选的实施例中，第二构建模块还包括：
[0174] 判断单元，用于判断测试模型中是否存在废弃业务的关联关系，得到第三判断结果，其中，废弃业务为不具备测试性的交互业务；
[0175] 调整单元，用于在第三判断结果为测试模型中存在废弃业务关联关系的情况下，对测试模型进行调整，以使测试模型中不包括废弃业务的关联关系。
[0176] 在可选的实施例中，调整单元用于：
[0177] 判断废弃业务的关联关系是否属于第一关联关系组，得到第一子判断结果；
[0178] 在第一子判断结果为废弃业务的关联关系属于第一关联关系组的情况下，从生产模型中提取第一交互业务的关联关系替代废弃业务的关联关系，其中，
[0179] 第一交互业务为目标模型中较大业务占比对应的可测试性交互业务，目标模型为生产模型剔除测试模型后的剩余模型。
[0180] 在可选的实施例中，调整单元用于：
[0181] 判断废弃业务的关联关系是否属于第二关联关系组，得到第二子判断结果；
[0182] 在第二子判断结果为废弃业务的关联关系属于第二关联关系组的情况下，获取第二交互业务，并通过第二交互业务的关联关系替代废弃业务的关联关系，其中，[0183] 第二交互业务具备测试性，且第二交互业务与废弃业务引起同样的交互故障。
[0184] 在可选的实施例中，组合构建单元用于：
[0185] 计算第一关联关系组和第二关联关系组中，各类交互业务的占比，得到更新后的业务；
[0186] 对于第一关联关系组和第二关联关系组中的关联关系，通过更新后的业务占比替换对应类别交互业务的业务占比，得到更新后的关联关系；
[0187] 通过更新后的关联关系，构建测试模型。
[0188] 本发明一实施例的测试模型的构建装置，包括：
[0189] 存储器，用于存储计算机指令；
[0190] 处理器，耦合到存储器，处理器被配置为基于存储器存储的计算机指令执行上述的测试模型的构建方法。
[0191] 图8示出的设备仅仅是测试模型的构建装置一个示例，不应对本发明实施例的功能和使用范围构成任何限制。参考图8，该测试模型的构建装置包括通过总线连接的处理器801、存储器802和输入输出设备803。存储器802包括只读存储器(ROM)和随机访问存储器(RAM)，存储器802内存储有执行系统功能所需的各种计算机指令和数据，处理器801从存储器802中读取各种计算机指令以执行各种适当的动作和处理。输入输出设备803，包括键盘、鼠标等的输入部分；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分；包括硬盘等的存储部分；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分。存储器802还存储有以下的计算机指令以完成本发明实施例的音色选择方法规定的操作：获取被测试响应性能时间段内的交互日志；通过交互日志中各类交互业务的名称和数量之间的关联关系，构建生产模型；从生产模型中提取测试所需交互业务的关联关系以构建测试模型；其中，测试模型作为设计测试场景的参考模型，测试场景中交互业务的类别以及各类交互业务的数量参考测试模型设置。
[0192] 相应地，本发明实施例提供一种计算机可读存储介质，该计算机可读存储介质存储有计算机指令，所述计算机指令被执行时实现上述测试模型的构建方法所规定的操作。
[0193] 附图中的流程图、框图图示了本发明实施例的系统、方法、装置的可能的体系框架、功能和操作，流程图和框图上的方框可以代表一个模块、程序段或仅仅是一段代码，所述模块、程序段和代码都是用来实现规定逻辑功能的可执行指令。也应当注意，所述实现规定逻辑功能的可执行指令可以重新组合，从而构建新的模块和程序段。因此附图的方框以及方框顺序只是用来更好的图示实施例的过程和步骤，而不应以此作为对发明本身的限制。
[0194] 系统的各个模块或单元可以通过硬件、固件或软件实现。软件例如包括采用JAVA、C/C++/C#、SQL等各种编程语言形成的编码程序。虽然在方法以及方法图例中给出本发明实施例的步骤以及步骤的顺序，但是所述步骤实现规定的逻辑功能的可执行指令可以重新组合，从而构建新的步骤。所述步骤的顺序也不应该仅仅局限于所述方法以及方法图例中的步骤顺序，可以根据功能的需要随时进行调整。例如将其中的某些步骤并行或按照相反顺序执行。
[0195] 根据本发明的系统和方法可以部署在单个或多个服务器上。例如，可以将不同的模块分别部署在不同的服务器上，形成专用服务器。或者，可以在多个服务器上分布式部署相同的功能单元、模块或系统，以减轻负载压力。所述服务器包括但不限于在同一个局域网以及通过Internet连接的多个PC机、PC服务器、刀片机、超级计算机等。
[0196] 以上所述仅为本发明的优选实施例，并不用于限制本发明，对于本领域技术人员而言，本发明可以有各种改动和变化。凡在本发明的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。
