多任务自适应云测试方法与流程

本发明涉及云计算测试技术，确切地说是多任务自适应云测试方法。

背景技术：

云计算是当前信息技术领域的热点之一，已在工业界和学术界内备受关注。它是一种全新的计算模式，通过互联网以服务的方式向用户提供动态可伸缩的虚拟化计算资源。用户在使用计算资源的过程中，仅需与服务供应商进行少量的交互，可以更好地专注于自身的上层业务逻辑，不必关心复杂的底层硬件逻辑、网络协议、软件架构等细节。云计算带来的以服务方式将虚拟化的计算资源供给用户使用的模式，给传统信息技术产业带来巨大影响，改变了传统软件生产组织和软件架构设计方式。这也对传统的软件测试方法与技术形成了新的挑战，如何开展云计算环境下的软件测试是国内外业界与学界面临的热点问题。云测试是上述背景下出现的软件测试新模式。目前，该领域的研究主要集中在如何将测试迁移到云中，利用云计算技术整合和部署大量的计算资源开展测试活动。研发基于云计算的软件测试平台，助力传统测试活动,以少量的资源,在紧张的开发与测试时间间隔内，高效地完成测试任务，对企业的信息化建设具有深远的战略意义。中国发明专利申请CN103312823A公开了一种云计算系统，包括：云计算端，其包括基础单元、应用程序单元、第一解密单元、第三标识码单元和第一通讯单元；子云计算组，其包括：第一子云计算端和第二子云计算端，第一子云计算端包括数据存储单元、第一标识码单元、第一加密单元、第二通讯单元和第一加密单元，第二子云计算端包括第二副本单元、第二标识码单元、第二解密单元、第二加密单元和第三通讯单元；客户端，其包含有：第四标识码单元，其中第二通讯单元与客户端和第三通讯单元通过网络通信连接。中国发明专利申请CN105866569A智能设备云测试系统，包括：客户端；云后台端，其包括数据库、设备管理模块以及任务调度模块；测试端，其包括运行状态检测模块、运行状态指示模块；以及多个目标设备；其中，数据库接收并储存客户端上传的待执行测试任务；任务调度模块，其与数据库通讯连接，检查数据库是否存在待执行测试任务，如果有，则任务调度模块按照优先级顺序将该待执行测试任务分配给目标设备，目标设备接收该测试任务并执行；本发明集服务与硬件于一体，为智能设备的自动化测试提供一个开放平台，用户无需自己投入巨大的研发成本便可构建自己专业的测试系统，极大的简化了目标设备的接入、管理和后期维护。现有技术云测试存在只适用于单一的测试类型技术问题，对不同类型的测试任务不能灵活调整资源配置，并且外网测试服务器难以测试处于局域网内部的待测设备。

技术实现要素：

本发明要解决的技术问题是云测试存在只适用于单一的测试类型技术问题，对不同类型的测试任务不能灵活调整资源配置，并且外网测试服务器难以测试处于局域网内部的待测设备。

为解决上述技术问题，本发明采用如下技术手段：

多任务自适应云测试方法，包括如下测试步骤；

1)步骤一：测试任务接收，接收用户上传的测试任务；

2)步骤二：测试任务预处理，预处理包括对步骤一所接收的测试任务进行测试任务分析、判断测试任务类别，根据判断测试任务类别将预处理任务分别分配至单元测试、集成测试、系统测试和性能测试；

3)步骤三：测试任务执行，执行测试任务前需要根据预处理结果分配虚拟机，装载测试环境，执行测试任务，产生测试任务数据；

4)步骤四：测试任务结果输出，根据步骤三产生的测试任务数据，保存至数据库，反馈测试结果至上传用户。

作为优选，本发明更进一步的技术方案是：

所述的测试任务接收包括测试用例、测试配置文件。

所述的测试任务预处理为根据步骤一接收测试任务，解析配置文件，获取测试任务类别、网络环境等信息，多个测试任务时循环执行，判断测试任务是否是在内网执行，如果是则向内网客户端分发驻留模块，否则根据测试类别执行后续步骤。

所述的测试任务预处理包括单元测试、集成测试、系统测试和性能测试，其测试的具体内容分别为：

1)单元测试：编译桩模块；

2)集成测试，按照配置文件中的测试序列编译各模块；

3)系统测试，按照模块列表编译所有模块；

4)性能测试，按照配置文件批量生成测试负载数据。

所述的测试任务结果输出，包括网页、邮件形式反馈测试结果。

所述的测试方法测试平台由硬件设备和软件系统组成，硬件设备包括服务器主机、网络设备交换机和防火墙，软件系统包括OpenStack、Zabbix和ELK，所述的ELK由ElasticSearch、Logstash、Kibana以及Nigix组成。

云测试的研究在国内外仍处于初级阶段，比较有代表性的定义是“云测试是在云环境和基础设施中利用云计算技术解决方案进行的测试活动”。根据该定义，云测试是具有以下特征的测试活动，即将软件测试活动迁移到了云端，利用云计算技术按需提供与测试相关的软硬件资源，以服务的方式向用户提供按使用付费的测试业务、云测试的研究包括两个方面：如何有效利用云环境中的资源测试其他软件，2)如何测试部署在“云”中的软件。第一方面的研究主要涉及与云测试密切相关的资源调度、优化、建模等方面的问题，以便为其他软件搭建廉价、便捷、高效的测试环境，加快整个软件测试的进程。在这一类型的测试中，其他的软件可以是传统意义上的地软件，也可以是“云”应用软件服务；第二方面的研究涉及到云平台内部结构、功能扩展和资源配置等多方面的测试问题，测试部署在云平台中的各种云软件。

云测试在基础设施、测试环境部署、测试过程管理、付费方式等诸多方面颠覆了传统软件测试。具体体现在以下5个方面。

1)基础设施。传统软件测试需要用户自行购买各种测试基础设施,包括服务器硬件、网络设备、系统软件与测试软件等，云测试则由云服务提供商通过云计算平台提供测试基础设施服务,用户无需自行购买。

2)测试环境部署。传统软件测试需要手工配置和部署测试环境，人工分配测试资源等，既有硬件上架、调试等复杂过程，又涉及操作系统、软件的费时费力安装；云测试支持测试资源按需分配，测试环境按需搭建和一键式回收。

3)测试过程管理。传统软件测试采用分散管理模式，项目管理、软件质里保证水平参差不齐，不方便集中管控，云测试便于集中管理，对测试资源进行统一整合，动态分配，减少重复性工作，提高测试效率。

4)付费方式。传统软件测试需要一次性付费，软硬件投入巨大，对于中小型用户是个很高的门槛；云测试则仅按需购买，按照测试项目规模、测试目标、测试时间等租赁付费，降低了软件测试的入围门槛。

5)商业扩展。传统软件测试资源利用率低，易产生资源闲置，可扩展性较差；云测试以服务的形式共享测试资源与测试工具，通过云端对外开放，可扩展性强。

本发明支持单元测试、集成测试、系统测试、性能测试等多种类测试任务的并发执行，可根据任务类别的不同自动选择合适的虚拟机配置方案，针对内网设备自动使用驻留模块调度测试任务并收集测试数据。

附图说明

图1为本发明的一种具体实施方式的结构框图。

图2为本发明的一种具体实施方式的软件测试系统结构。

图3为本发明的一种具体实施方式的软件测试系统结构相依性图。

图4为本发明的一种具体实施方式的多个实体间的多级信任推荐实验场景实体间推荐关系。

图5为本发明的一种具体实施方式的多个实体间的多级信任推荐实验场景贝叶斯网络结构。

图6为本发明的一种具体实施方式的系统实验结果。

图7为本发明的一种具体实施方式的可信性保障性能测试结果。

具体实施方式

下面结合实施例，进一步说明本发明。

具体实施例1：

参见图1可知，本发明多任务自适应云测试方法，包括如下测试步骤；步骤一：测试任务接收，接收用户上传的测试任务；测试任务接收包括测试用例、测试配置文件；步骤二：测试任务预处理，预处理包括对步骤一所接收的测试任务进行测试任务分析、判断测试任务类别，根据判断测试任务类别将预处理任务分别分配至单元测试、集成测试、系统测试和性能测试；测试任务预处理为根据步骤一接收测试任务，解析配置文件，获取测试任务类别、网络环境等信息，多个测试任务时循环执行，判断测试任务是否是在内网执行，如果是则向内网客户端分发驻留模块，否则根据测试类别执行后续步骤；测试任务预处理单元测试、集成测试、系统测试和性能测试分别为：单元测试：编译桩模块；集成测试，按照配置文件中的测试序列编译各模块；系统测试，按照模块列表编译所有模块；性能测试，按照配置文件批量生成测试负载数据。步骤三：测试任务执行，执行测试任务前需要根据预处理结果分配虚拟机，装载测试环境，执行测试任务，产生测试任务数据；步骤四：测试任务结果输出，根据步骤三产生的测试任务数据，保存至数据库，反馈测试结果至上传用户，测试任务结果输出，包括网页、邮件形式反馈测试结果。测试方法测试平台由硬件设备和软件系统组成，硬件设备包括服务器主机、网络设备交换机和防火墙，软件系统包括OpenStack、Zabbix和ELK，ELK由ElasticSearch、Logstash、Kibana以及Nigix组成。

具体实施例2：

以软件评测实验场景为基础，模拟了一个实际的软件测试系统进行实验。

参见图2可知，系统总体可分为三部分，业务逻辑模块、系统内部构件和测试服务构件。业务逻辑模块即评测中心为完成特定的管理功能而开发的系统模块，使用常见的编程语言开发；系统内部构件是评测中心为提高系统的复用度降低开发成本，而将部分通用的功能封装成可直接调用的构件，通常为本地构件或网络服务形式；测试服务构件用于执行实际的测试服务，包括对本地测试软件封装后的测试服务、由第三方提供的外部服务、与测试用户系统进行交互的用户方服务。本文中系统内部构件采用网络服务形式，通过标准WebService接口同业务逻辑模块进行交互。外部服务及用户服务以服务或分布式对象的形式通过互联网与本地系统进行交互，一般为较为成熟且封装良好的实体单元，是云软件系统的主要组成元素。

系统结构分析：采用自底向上的方式对软件系统各模块进行结构分析，以便得到系统的结构相依性图。测试服务模块是对外部服务的组合，需要与第三方实体进行交互，故首先进行分析。该模块主要用于执行实际的测试功能，共组合了四类服务接口。

(1)用户服务：组合各测试用户所提供的其企业内部信息系统接口。通过接口调用获取测试用户信息及待测系统的列表、描述信息等，供测试服务随时调用。

(2)外部服务：调用第三方测试服务提供商提供的服务，例如评测中心与测试工具提供商进行合作，由该提供商建立外部服务以代替在本地安装测试软件。

(3)测试服务：执行具体的测试服务，如单元测试、压力测试、安全性测试等，由测试控制构件根据当前待测系统的测试需求调用执行。

(4)基础服务：评测中心在进行测试时可能会需要与其它评测中心或服务提供商进行协同，以便获取基础数据或具体业务的支持。例如，在功能测试或性能测试中需要大量的测试数据，而专业的数据生成工具或大量的真实数据往往只被少数机构拥有，因此需要在测试过程中进行服务间的协同以获取这些数据。

在服务交互与远程对象调用方面，目前存在着多种技术协议，如WebService、CORBA、Java-RMI等。而这些协议之间又不能很好地兼容，因此采用不同协议的服务实体间就产生了结构相依性及语义相依性的差异。

外部服务构件中还包括了外部服务和用户服务，其中也涉及到由于接口协议不兼容而引起的结构相依性及语义相依性问题，可按上述方法进行分析。

对于系统中的本地模块，测试业务管理、测试资源管理、用户管理等，由于是采用同一开发环境开发并集成在一起使用，相互关系较为紧密，且不存在接口兼容性问题，因此在结构分析时可作为同一实体对待。系统内部的通用构件可作为单独的服务实体，由于是自行开发，与其他模块完全兼容，因此也不涉及到结构相依性问题，只是作为系统可信性计算的一部分存在。

参见图3可知，Retional Robot、LoadRunner、JMeter都是使用测试工具封装成的测试服务。其中Retional Robot、LoadRunner只支持WebService，而JMeter只支持Java-RMI协议。数据生成服务1、数据生成服务2只支持WebService，数据生成服务3只支持Java-RMI协议。这样，当选用Retional Robot和LoadRunner作为测试服务时，可选用数据生成服务1和数据生成服务2作为基础服务，而选用JMeter时，基础服务只能选用数据生成服务3。后面的工作就是根据各服务的多方面属性计算组合后的可信性，以便采用最好的组合。

系统可信性计算：采用自底向上的方法逐层计算系统的可信性，首先计算最下层的节点。单个节点的可信性是由其先验指标汇总后在经过评估指标修正而得的，即计算先验概率并通过事实证据进行修正。以实体数据生成服务1为例，获取到的先验指标为功能性0.98、可靠性0.96、易用性0.96、效率0.95、可维护性0.92、可移植性0.90、可复用性0.94。通过评估其开发及管理情况获得事实证据对先验概率进行修正。

评估指标条件概率

所示为对软件开发中各条件的不同满足情况而带来的可信性差异，也即不同条件下使软件可信的概率。表中值为1的项表示满足该情况，值为0的项表示不满足。例如：第一条数据表示软件在具有良好测试、规范编程、详细文档、熟练员工、过程管理的情况下其可信性可以得到保证。此表汇总软件开发过程中出现的各种情况而得，也可在软件使用过程中根据软件的具体演化过程逐步修改完善。该表没有全部列出，仅列出几条代表性数据。根据下面公式对实体数据生成服务1可信性进行计算：

等式左边即为修正后的节点可信性；等式右边P(M_e)为评估指标满足给定条件的联合分布概率；P(M_e|D)为软件可信条件下各评估指标满足给定条件的联合分布概率；P(M_p)为各先验指标综合所得的可信性值，由于各先验指标相互独立，所以

M_pi分别为前文所列出的7种先验指标。此处根据评估指标满足情况的不同分别进行计算，后面的结果分析中将会对各计算结果进行具体讨论。

情况1：前文所述的5种评估指标都满足时。根据评估指标条件概率表计算5种评估指标联合概率可得P(M_e)＝0.33，软件可信条件下满足5种评估指标联合概率P(M_e|D)＝0.24，将数据代入公式可得：

情况2：前文所述的5种评估指标中满足良好测试、规范编程、详细文档、过程管理时。根据评估指标条件概率表计算5种评估指标联合概率可得P(M_e)＝0.39，软件可信条件下满足5种评估指标联合概率P(M_e|D)＝0.31，将数据代入式5.3可得：

情况3：前文所述的5种评估指标中满足良好测试、规范编程、熟练员工时。根据评估指标条件概率表计算5种评估指标联合概率可得P(M_e)＝0.43，软件可信条件下满足5种评估指标联合概率P(M_e|D)＝0.37，将数据代入式5.3可得：

情况4：前文所述的5种评估指标都不满足时。根据评估指标条件概率表计算5种评估指标联合概率可得P(M_e)＝0.09，软件可信条件下满足5种评估指标联合概率P(M_e|D)＝0.13，将数据代入式5.3可得：

依上述方法完成全部基础实体的计算后，开始进行中间结点可信性的计算。计算中间结点可信性时，除了要考虑该节点自身的实体可信性外，还应通过其基础节点的可信性进行修正。以实体LoadRunner为例，计算得出该节点可信性为0.94，其子节点的可信性分别为0.918和0.928，则修正后的实体可信性为：

其中D'为其基础节点数据生成服务1与数据生成服务2种较高的可信性值，P(D|D')也即基础节点可信时当前计算节点的可信性。系统投入运行前P(D|D')的值可设为某一初值，例如P(D')，当系统运行一段时间后，可根据具体运行情况统计出证据数据进行修正。

另外，当一个节点可同时使用多个基础节点时，通常采用冗余备份的方式同时与多个基础节点建立连接，当其中一个失效时，立即切换至备用节点，可大大增强整个系统的可信性。此时该节点的可信性采用所有基础节点都失效的概率进行修正：

按照此方法沿结构相依性图自底向上进行计算，最终得到整个系统的可信性为0.909。当选择的实体不同时，或其满足的评估指标不同时，计算整个系统可信性所得的结果也不相同。

结果分析：对前述计算过程可进行如下分析：

(1)评估指标满足情况的差异性：在单个节点可信性计算的过程中，节点对评估指标的满足情况不同时，根据条件概率表计算所得的联合分布概率也不同。节点所满足的评估指标越多，即节点实体设计、开发、管理过程越符合标准规范，其软件质量水平也就越高，则实体的可信性也就越高，完全符合软件质量保证理论的思想。而计算结果也正确体现了这一点，对于先验指标完全相同的实体，根据其评估指标满足情况的不同，所得修正后的可信性也不同。也就是说，对评估指标满足程度越高的实体修正后的可信性值越高，反之，评估指标满足程度越低的实体修正后的可信性值越低。

(2)节点间可信性的修正效果：中间节点可信性除根据该节点自身的先验指标和评估指标计算外，还受到其基础节点可信性的影响。这反映出真实情况下云软件实体间的相互关系及一组相互协作的实体所具有的集成可信性。而通过节点冗余备份的方法，减少实体停止服务的可能，提高实体的可信性，也完全符合云软件系统设计与开发的理论常识。

(3)最终可信性值的客观性：最终的可信性值将多个对实体可信性不同侧面的评价综合成唯一的结果，并加以修正。这样可以清晰地反映云软件实体的可信性，同时也不单独依赖于服务提供商所给出的数据，而是可由用户根据服务实体的实际情况做出客观的评估。

综上所述，本计算方法涵盖了从云软件实体到系统整体的可信性计算过程；反映出云软件各实体开发过程规范性不同所造成的可信性差异，以及云软件系统的自主性、协同性、多态性等特征；能够正确、客观、全面地评价系统及其各组成实体的可信性。

参见图4和图5可知，实验流程

依据前述实验场景，按照从个体到整体、先功能后性能的原则，设计实验流程如下：

(1)系统初始状态：测试用户向评测中心申请服务，评测中心为其提供正常服务，此时系统处于正常服务状态，可信性保障功能正常。

(2)单个实体内部行为：对于强可信智能实体，在正常的服务请求中加入可能导致服务实体可信性下降的行为，例如：可能会导致安全性下降的SQL语句注入攻击、拒绝服务攻击等。此时，服务实体中应启动适当的可信性保障机制，以应对外界行为的变化。

(3)两个实体间的交互行为：对于基于信任契约的信任约束机制，服务提供实体设定契约的前置条件，如：服务请求实体访问服务提供实体的频率应小于每分钟10次，客户端应具有对输入参数中非法字符的检测机制等。服务请求实体设定契约的后置条件，如：测试方对测试结果的最短响应时间等。某服务请求实体不符合前置条件时，服务提供实体可拒绝服务。服务请求实体在选择服务提供实体对其契约满足情况进行评估，优先选择与后置条件符合度高的服务实体。

(4)多个实体间的多级信任推荐：基于评估的信任传递，服务请求者与最终服务提供者没有直接交互的历史信息，但可以通过多个中间实体建立间接信任关系。这些实体之间就形成了多层信任传递关系，根据各实体间的信任关系与网络环境状况计算服务请求这对最终服务提供者的信任度。

实体S需要获取实体T提供的服务，可根据实体A、B、C的推荐信息计算实体T的信任值。而实体B综合实体D、E对实体T的推荐信息后向实体A提供信息。图中所有推荐实体在提供推荐信息的同时，都可通过可信交互接口将对自身与目标实体的交互情况发送给评估实体，为信任值的计算提供了依据。根据图4、图5中的实体间推荐关系建立贝叶斯网络：

1)选择随机变量{S,A,B,C,D,E,T,B’,S’}，其中T代表实体T自身的可信性情况，A,B,C,D,E分别代表各实体对实体T的推荐信任信息，B’,S’分别代表实体B,S对自身与实体T间实际传输可信性情况的评估，S代表实体S对T的最终信任度。

2)由于实体T的可信性通过实体D,E,A,B,C向实体T传播，因此选择变量顺序＝<T,D,E,B’,B,A,C,S’,S>。

3)从一个空图G出发，按照顺序逐个将变量加入G中。

4)最后形成如上图(b)所示的贝叶斯网络。

参见图6可知，实验结果及分析

实验系统运行多台服务器组成的网络上。设置用户仅请求最简单的单元测试功能，以减少业务逻辑复杂度差异给可信性保障性能所带来的误差。实验结果及分析如下：

单个实体及两实体间交互行为实验，系统执行结果如图6所示，对比图6(a)和图6(b)，通过框1中的信息可以看出，当服务请求正常时，系统按照规定的业务逻辑进行了服务，并提供了所需结果。框2中的信息说明系统发现SQL注入攻击行为，此时外部事件处理机制启动，根据既定策略调用相应行为，则外部请求需经过防SQL注入攻击处理后再进行业务逻辑处理。同时系统自主修改可信级别，并向外界发送通知。由此可见，强可信智能实体的设计可以保证其自省性、自明性、自主性的实现。

如图6(c)和图6(d)所示，服务请求实体选择可信性高的服务提供实体进行交互，符合云软件实体间交互的一般机制。服务提供实体设置前置条件访问服务实体最短间隔时间为2秒，而对于服务请求实体，由于其需要实时监控服务执行状况，需要每秒访问服务实体，不满足信任契约的前置条件。因此，通过框3中信息可以看出，服务实体首先判断服务请求实体是否满足信任契约前置条件的要求，结果是不满足，则服务实体拒绝提供服务。框4中显示了服务请求实体的信息，服务请求被服务提供实体拒绝，服务请求者转向其他服务提供实体。由此可见，通过对信任契约的评估，可以在服务交互前获得实体可信性情况，同时，服务提供实体也拥有了预先对服务请求者进行信任评估的能力。

参见图7可知，可信性保障性能测试，在自主可信性保障行为、启用全部可信性保障行为、停用全部可信性保障行为三种方式下，分别模拟了300个用户的随机测试服务请求。其中契约协商请求与业务服务请求的比例为3:7，所有请求行为中有危险的攻击行为占30％。

图7(a)是在自主可信性保障行为下各用户请求的响应时间，从图中可以看出各请求响应时间的分布情况。其中有30％左右的请求响应时间在100ms以下，这是由于这些请求都是单纯的契约协商，并未执行实际的测试业务。请求响应时间在100ms与300ms之间的数据约占10％左右，是由业务请求中的恶意行为被可信性保障机制拦截而造成的。另外契约协商中也有部分恶意行为被拦截。以上数据很好地反映了业务执行过程中各种交互行为的实际情况，表明自主可信性保障行为可以为云软件实体提供正常的可信性保障。

图7(b)是不同可信性保障行为方式下请求相应总时间的对比。启用全部可信性保障行为时会对所有请求都执行所有的可信性保障处理操作，而不考虑系统目前的自身及环境状况，因而进行了许多不必要的操作，造成响应总时间最长。启用自主可信性保障行为后，系统会根据当前自身及环境的可信性情况对可信性保障机制进行动态演化，仅执行有针对性的行为，提高了保障效率，减少了请求响应时间。停用全部可信性保障行为后，所有请求都直接进入核心的业务逻辑，虽然请求响应时间有所减少，但可信性方面没有任何保障。而且所减少的响应时间中有大部分是系统出错返回而没进行后续处理造成的，这种情况对实际应用中可信性的不利影响是显而易见的。另外，启用自主可信性保障行为后所增加的响应时间并不多，但可以有效保障系统的可信性，充分说明我们提出的可信性保障机制是合理有效的。

多级信任推荐中信任值的计算：按照逐级综合计算的方法，先综合实体D、E对T的信任值来计算实体B对T的信任值。

首先，获取各实体对目标实体的信任值，从图7(a)中可以得出，即T_DT＝0.97,T_ET＝0.85。

然后，根据实体D、E与T的交互情况建立如下表所示的条件概率，

实体交互情况条件概率表

所示为对传输可信性相关属性的不同满足情况而带来的交互结果差异。表中值为1的项表示满足该情况，值为0的项表示不满足。例如：第一条数据表示通信链路质量、信息传递安全性、网络时延都满足标准的情况下交互成功。最后一条数据表示仅有通信链路质量满足标准的情况下交互失败。由此可计算出各推荐实体与目标实体的传输可信性值，即不同传输条件下交互的概率。在图7(a)中表示C_DT＝0.98,C_ET＝0.8。此表汇总各推荐实体的交互历史而得，内容没有全部列出，仅列出几条代表性数据。

最后，结合实体B自身的传输可信性观测证据，即C_BT＝0.98，根据公式计算出实体B对T的信任值：

得到实体B对T的信任值后，综合实体A、B、C对T的信任值来计算实体S对T的信任值。

结果分析1：上述计算过程可以看出，间接信任的计算可以通过推荐信任的逐级综合而来。在计算当前级别的信任度前，首先计算前一级别实体对目标实体的信任度。所有间接信任度都是通过推荐信任度与传输可信性计算得来，所有实体在计算间接信任前都需要通过评估获取自身到目标实体的传输可信性，反映了主观推荐与客观评估相结合的特点。

结果分析2：由T_ST的计算过程可以看出，在实体S到T的网络环境与A到T、B到T、C到T相差不大的情况下，实体S对信任度最高的实体A的推荐信任采信度最高，即T_ST与T_AT最接近。这反映了间接信任是在对推荐实体信任度的基础上由推荐信息综合而来。

结果分析3：由T_BT的计算过程可以看出，在实体B对实体D、E的信任度相同的情况下，虽然实体E所提供关于实体T的推荐信任值较低，但由于实体E到T的网络环境较差，由网络环境造成服务失败的可能性较大，因此采信度不高。而实体B到T的网络环境与D到T最相近，因而对D的推荐信息采信度最高，即T_BT与T_DT最接近。这反映了传输可信度对推荐信任的修正作用。

结果分析4：T_BT的计算结果比所有推荐者的推荐信任值T_DT、T_ET都高，体现了传输可信性对信任传递衰减参数的反向修正作用。推荐实体的网络环境越差，则造成目标实体服务失败的概率越高，因此当推荐实体与评估实体的网络环境状况有差别时，特别是评估实体的网络环境较好时，需通过修正参数提高目标实体当前环境下的可信度，以反映评估实体的真实网络状况。

由于以上所述仅为本发明的具体实施方式，但本发明的保护不限于此，任何本技术领域的技术人员所能想到本技术方案技术特征的等同的变化或替代，都涵盖在本发明的保护范围之内。