1. web端和移动端优秀的自动化测试工具有哪些
QTP 全名HP QuickTest Professional software ，2012年12月6日发布11.5版本，并更名为Unified Functional TestingQTP是quicktest Professional的简称，是一种自动测试工具。使用QTP的目的是想用它来执行重复的手动测试，主要是用于回归测试和测试同一软件的新版本。因此你在测试前要考虑好如何对应用程序进行测试，例如要测试那些功能、操作步骤、输入数据和期望的输出数据等 QuickTest针对的是GUI应用程序，包括传统的Windows应用程序，以越来越流行的Web应用。它可以覆盖绝大多数的软件开发技术，简单高效，并具备测试用例可重用的特点。其中包括:创建测试、插入检查点、检验数据、增强测试、运行测试、分析结果和维护测试等方面。 WinRunner Mercury Interactive公司的WinRunner是一种企业级的功能测试工具，用于检测应用程序是否能够达到预期的功能及正常运行。通过自动录制、检测和回放用户的应用操作，WinRunner能够有效地帮助测试人员对复杂的企业级应用的不同发布版进行测试，提高测试人员的工作效率和质量，确保跨平台的、复杂的企业级应用无故障发布及长期稳定运行。企业级应用可能包括Web应用系统，ERP系统，CRM系统等等。这些系统在发布之前，升级之后都... QTP 全名HP QuickTest Professional software ，2012年12月6日发布11.5版本，并更名为Unified Functional TestingQTP是quicktest Professional的简称，是一种自动测试工具。使用QTP的目的是想用它来执行重复的手动测试，主要是用于回归测试和测试同一软件的新版本。因此你在测试前要考虑好如何对应用程序进行测试，例如要测试那些功能、操作步骤、输入数据和期望的输出数据等 QuickTest针对的是GUI应用程序，包括传统的Windows应用程序，以越来越流行的Web应用。它可以覆盖绝大多数的软件开发技术，简单高效，并具备测试用例可重用的特点。其中包括:创建测试、插入检查点、检验数据、增强测试、运行测试、分析结果和维护测试等方面。 WinRunner Mercury Interactive公司的WinRunner是一种企业级的功能测试工具，用于检测应用程序是否能够达到预期的功能及正常运行。通过自动录制、检测和回放用户的应用操作，WinRunner能够有效地帮助测试人员对复杂的企业级应用的不同发布版进行测试，提高测试人员的工作效率和质量，确保跨平台的、复杂的企业级应用无故障发布及长期稳定运行。企业级应用可能包括Web应用系统，ERP系统，CRM系统等等。这些系统在发布之前，升级之后都要经过测试，确保所有功能都能正常运行，没有任何错误。如何有效地测试不断升级更新且不同环境的应用系统，是每个公司都会面临的问题。 RationalRobot 是业界最顶尖的功能测试工具，它甚至可以在测试人员学习高级脚本技术之前帮助其进行成功的测试。它集成在测试人员的桌面IBM Rational Test Manager上，在这里测试人员可以计划、组织、执行、管理和报告所有测试活动，包括手动测试报告。这种测试和管理的双重功能是自动化测试的理想开始。 AdventNetQEngine AdventNet QEngine是一个应用广泛且独立于平台的自动化软件测试工具，可用于Web功能测试、web性能测试、Java应用功能测试、Java API测试、SOAP测试、回归测试和Java应用性能测试。支持对于使用HTML、JSP、ASP、.NET、PHP、JavaScript/VBScript、XML、SOAP、WSDL、e-commerce、传统客户端/服务器等开发的应用程序进行测试。此工具以Java开发，因此便于移植和提供多平台支持。 SilkTest 是业界领先的、用于对企业级应用进行功能测试的产品，可用于测试Web、Java或是传统的C/S结构。SilkTest提供了许多功能，使用户能够高效率地进行软件自动化测试。这些功能包括:测试的计划和管理;直接的数据库访问及校验;灵活、强大的4Test脚本语言，内置的恢复系统(Recovery System);以及具有使用同一套脚本进行跨平台、跨浏览器和技术进行测试的能力。 QARun QARun的测试实现方式是通过鼠标移动、键盘点击操作被测应用，即而得到相应的测试脚本，对该脚本可以进行编辑和调试。在记录的过程中可针对被测应用中所包含的功能点进行基线值的建立，换句话说就是在插入检查点的同时建立期望值。在这里检查点是目标系统的一个特殊方面在一特定点的期望状态。通常，检查点在QARun提示目标系统执行一系列事件之后被执行。检查点用于确定实际结果与期望结果是否相同 TestPartner 是一个自动化的功能测试工具，它专为测试基于微软、Java和Web技术的复杂应用而设计。它使测试人员和开发人员都可以使用可视的脚本编制和自动向导来生成可重复的测试，用户可以调用VBA的所有功能，并进行任何水平层次和细节的测试。TestPartner的脚本开发采用通用的、分层的方式来进行。没有编程知识的测试人员也可以通过TestPartner的可视化导航器来快速创建测试并执行。通过可视的导航器录制并回放测试，每一个测试都将被展示为树状结构，以清楚地显现测试通过应用的路径。 Holodeck-强大的故障植入软件测试工具 TelelogicTAU TAU第二代包含三个最新的、最强大的技术用来加速大规模软件开发和测试:统一建模语言(UML)及它的许多最新修订版本中的特性，UML2.0;功能强大的测试语言TTCN-3和新的构造系统的方法:Model Driven Architecture(模型驱动构架)。这三个新的业界标准结合成TAU的已经过认可的软件开发平台，形成了一个系统，一个一流的稳定可靠的工具解决方案。TAU第二代是系统与软件开发解决方案的一个突破，它把业界从使用了太长时间的手工、易出错、以代码为中心的方法中释放出来，自然而然地迈向下一步，一个更加可视化、自动化及可靠的开发方法。Telelogic TAU/Tester是基于通用测试语言TTCN-3,用于自动化的系统和集成测试的强大工具。TAU/Tester以现代化的开发工具为基础，提供高层测试功能，支持整个测试生命周期，加速自动化测试。TAU/Tester可使用户特别关注于测试的开发，因为TTCN-3语言是独立于开发语言或测试设备的，且是抽象和可移植的。 试工具。最新版本是1.1.8，该工具支持无脚本执行模式，无人值守执行模式，自由定制模式。不仅执行模式可以定制，功能模块也支持定制。使用该工具的界面创建用例，组装脚本，启动执行。使用该工具其他开放的接口，可手动创建脚本，组装并执行。它支持两种部署模式，第一种是Server-Client方式，Server与Client均为EXE程序，通信协议是Socket;另一种是WEB版部署，方便与现有系统集成，支持Linux，将Server与Client放到Tomcat或Weblogic服务器下部署，通信协议为Http，通过WEB页面控制并监控Client端的执行
2. Web测试的主要内容和测试方法有哪些
1功能测试 2 1.1链接测试 2 1.2表单测试 2 1.3数据校验 3 1.4 cookies测试 3
1功能测试 2
1.1链接测试 2
1.2表单测试 2
1.3数据校验 3
1.4 cookies测试 3
1.5数据库测试 3
1.6应用程序特定的功能需求 4
1.7设计语言测试 4
2性能测试 4
2.1连接速度测试 4
2.2负载测试 4
2.3压力测试 5
3用户界面测试 6
3.1导航测试 6
3.2图形测试 6
3.3内容测试 7
3.4表格测试 7
3.5整体界面测试 7
4兼容性测试 8
4.1平台测试 8
4.2浏览器测试 8
4.3分辨率测试 8
4.4 Modem/连接速率 9
4.5打印机 9
4.6组合测试 9
5安全测试 9
5.1目录设置 9
5.2登录 10
5.3日志文件 10
5.4脚本语言 10
6接口测试 10
6.1服务器接口 10
6.2外部接口 11
6.3错误处理 11
7结论 11
在Web工程过程中，基于Web系统的测试、确认和验收是一项重要而富有挑战性的工作。基于Web的系统测试与传统的软件测试不同，它不但需要检查和验证是否按照设计的要求运行，而且还要测试系统在不同用户的浏览器端的显示是否合适。重要的是，还要从最终用户的角度进行安全性和可用性测试。然而，Internet和Web媒体的不可预见性使测试基于Web的系统变得困难。因此，我们必须为测试和评估复杂的基于Web的系统研究新的方法和技术
3. web应用软件的测试环境怎么写
定义测试策略 目前止您肯定参加议客户倚靠宽议桌问您:系统能处理千用户传统负载测试要求您编写脚本并执行测试试图给问题精确答案于种测试您需要定义处理含义及 1000 名典型用户站点情形您需要定义测试用例代表各种用户:例购买股票或注册新帐户接您必须估计用户些测试用例布数据进行假设即模拟真实用户与应用程序交互需要思考间(或等待间)负载测试期间某面致反映同数量真实用户站点情形 种几足处首先其结比您做假设更显确假设使结现偏差 其估计真实用户需要量客户端硬件每名虚拟用户给定需要处理能力内存量则典型客户端计算机处理约 200 名虚拟用户 2000 名用户并发处理级别测试需要 10 台客户端计算机 - 笔重投资测试使用 HTTPS 站点需要客户端硬件 终难向您发团队提供操作导向信息某处现故障难再现该问题 作备选案我建议您围绕些关键问题设计测试用例: ?? 系统瓶颈哪系统能同步处理少并发请求 ?? 响应间变接受前台机器能处理少名同步超级用户 ?? 添加额外硬件结线形增 ?? 任何稳定性问题妨碍站点运行于产环境 使用发团队(发团队参与能现问题领域)提供附加信息请关注些领域于示例其瓶颈能定单提交领域您派更具体问题例提交流程同处理少请求攻击些特定领域快且本用向发团队提供操作导向信息便能改进系统使用种同我推荐您记住遵循建议 关注负载测试我已提首先要做构建导致潜瓶颈稳定性问题脚本种数据第假设第二使您能够应用程序收集原始数据根据假设确定更高级别结用担识别低风险站点脚本编写问题例站点帮助领域或读文档领域编写脚本能现系统瓶颈 同步请求使用同步请求攻击瓶颈处主意模拟坏情况:即站点用户精确同间攻击瓶颈通使用户同步您重复进行测试同步结则难再现故障情况使用同步点做点同步点数较健壮(本较高)测试工具提供项功能同步点迫使每名虚拟用户直等剩余用户达脚本定义点才能始请求允许您精确并重复确定站点潜瓶颈区域能处理并发用户数例限 7 名并发同步用户 创建循环测试用例脚本使测试用例循环另种每测试用例迭代前站点应处于相同状态允许您间重复运行测试用例 使用超级用户使用我所称超级用户前面所提超级用户运行思考间设置零请记住思考间假设用于规测试使虚拟用户模拟真实用户虚拟用户思考间减半则服务器实际负载加倍另种服务器真关与负载关变量每秒请求数虚拟用户数量及其思考间结合起该负载 让我进行些数运算使概念更清晰面公式计算访问站点真实用户负载(请求数/秒): 例某站点 100 名并发用户假设载间 10 秒思考间 30 秒则每秒 2.5 页我假设每页 3 请求则 Web 服务器转化每秒 7.5 请求 超级用户运行测试观察每秒请求数并与刚刚计算值比较根据我经验真实用户数与超级用户数比例通约 15:1于同示例意味着 (100/15) 名超级用户与 100 名普通用户相同负载再举例假设 10 名超级用户响应间变接受请注意转换真实用户数该点每秒请求数现您进行任何希望思考间假设甚至更改需重新运行测试几测试您能根据直觉超级用户数转换真实用户数允许您保持用户数控减少所需客户端硬件数量并包含负载测试软件本 些超级用户测试用例于机测试用要测试站点伸缩性添加第二台 Web 服务器负载平衡器并重复超级用户测试理想情况看见相同相应数前您能加倍超级用户数量 要答稳定性问题运行测试延间段内维持合理数量并发且未同步超级用户我项目熬通宵甚至 24 昼夜停持续间与应用程序关我称内置测试旦您已采取步骤识别并潜解决找瓶颈则重复同步点测试看限否所增用所支持新并发用户数重新运行内置测试努力提高数字目标重复该循环直达质量条 少用户呢 尽管向发团队提供价值信息使您更难于答议室问题您近似估计答案例假设站点坏情况瓶颈显示每台计算机于 20 名超级用户情况响应间超 10 秒根据您我建议公式计算结近似估计 300 名真实用户(20 名超级用户 × 15 名真实用户)您做与规用例相同假设通情况百少用户使用站点领域假设预期 50% 用户使用领域其领域例文档或数据库读取用户比例则没意味着具台 Web 服务器系统处理约 600 名用户 目前止我已讨论能明确指向站点瓶颈领域情况该何做影响性能领域止您应何做呢答案创建单独查看各领域测试脚本首先孤立运行些脚本起运行再比较结看站点领域另领域影响
4. app测试和web测试的区别， web测试和app测试的区别
一、测试方式不同
1、app测试：指对移动应用进行测试，包括自动化测试和人工测试等。
2、web测试：是软件测试的一部分，是针对Web应用的一类测试。
二、测试内容不同
1、app测试：模拟用户操作对应用程序进行黑盒测试，并使用Cucumber作为自然语言来编写测试用例。还会对应用测试操作进行记录，以帮助开发者进行测试回顾。
2、web测试：包括内容测试、界面测试、功能测试、性能测试、兼容性测试、安全性测试等。
三、特点不同
1、app测试：可通过增加预先测试环节来确认环境已经测试就绪，同时还能知道哪些错误是环境不稳定引起的，哪些是一般的测试用例错误。
2、web测试：通过测试可以尽可能地多发现浏览器端和服务器端程序中的错误并及时加以修正，以保证应用的质量。
5. Web测试的测试分类
界面测试、功能测试、性能测试、可用性测试(接口测试）、客户端兼容性、安全性
web 的性能测试工具
随着Web 2.0技术的迅速发展，许多公司都开发了一些基于Web的网站服务，通常在设计开发Web应用系统的时候很难模拟出大量用户同时访问系统的实际情况，因此，当Web网站遇到访问高峰时，容易发生服务器响应速度变慢甚至服务中断。为了避免这种情况，需要一种能够真实模拟大量用户访问Web应用系统的性能测试工具进行压力测试，来测试静态HTML页面的响应时间，甚至测试动态网页（包括ASP、PHP、JSP等）的响应时间，为服务器的性能优化和调整提供数据依据。
另外，CSDN也总结了一些其他的测试工具，包括性能测试工具和功能测试工具，前十大测试工具排名如下：
企业级自动化测试工具WinRunner
Mercury Interactive公司的WinRunner是一种企业级的功能测试工具，用于检测应用程序是否能够达到预期的功能及正常运行。
工业标准级负载测试工具Loadrunner
LoadRunner 是一种预测系统行为和性能的负载测试工具。
全球测试管理系统testdirector
TestDirector 是业界第一个基于Web的测试管理系统，它可以在您公司内部或外部进行全球范围内测试的管理。
功能测试工具Rational Robot
IBM Rational Robot 是业界最顶尖的功能测试工具，它甚至可以在测试人员学习高级脚本技术之前帮助其进行成功的测试。它集成在测试人员的桌面IBM Rational TestManager 上，在这里测试人员可以计划、组织、执行、管理和报告所有测试活动，包括手动测试报告。这种测试和管理的双重功能是自动化测试的理想开始。
单元测试工具xUnit系列
目前的最流行的单元测试工具是xUnit系列框架，常用的根据语言不同分为JUnit（java），CppUnit（C++），DUnit （Delphi ），NUnit（.net），PhpUnit（Php ）等等。该测试框架的第一个和最杰出的应用就是由Erich Gamma （《设计模式》的作者）和Kent Beck（XP（Extreme Programming）的创始人 ）提供的开放源代码的JUnit.
功能测试工具SilkTest
Borland SilkTest 2006属于软件功能测试工具，是Borland公司所提出软件质量管理解决方案的套件之一。这个工具采用精灵设定与自动化执行测试，无论是程序设计新手或资深的专家都能快速建立功能测试，并分析功能错误。
性能测试工具WAS
Microsoft Web Application Stress Tool 是由微软的网站测试人员所开发，专门用来进行实际网站压力测试的一套工具。透过这套功能强大的压力测试工具，您可以使用少量的Client端计算机仿真大量用户上线对网站服务所可能造成的影响。
自动化白盒测试工具Jtest
Jtest是parasoft公司推出的一款针对java语言的自动化白盒测试工具，它通过自动实现java的单元测试和代码标准校验，来提高代码的可靠性。parasoft同时出品的还有C++ test，是一款C/C++白盒测试工具。
功能和性能测试的工具JMeter
JMeter是Apache组织的开放源代码项目，它是功能和性能测试的工具，100%的用java实现。
性能测试和分析工具WEBLOAD
webload 是RadView公司推出的一个性能测试和分析工具，它让web应用程序开发者自动执行压力测试；webload通过模拟真实用户的操作，生成压力负载来测试web的性能。
6. 如何对J2EE的WEB应用系统进行性能测试
用loadrunner 这个软件
hp的产品，可以模拟 多个用户同时操作你的软件。
7. Web应用的测试内容都包括哪些方面
1、通用指标
指Web应用服务器、数据库服务器必需测试项，包括：处理器时间：指服务器CPU占用率，一般平均达到70%时，服务就接近饱和。可用内存数：如果测试时发现内存有变化情况也要注意，如果是内存泄露则比较严重。物理磁盘读写时间。
2、Web服务器指标
平均每秒响应次数为总请求时间与秒数之比。平均每秒业务脚本的迭代次数。成功的请求和失败的请求。成功的点击次数和失败的点击次数。每秒点击次数、每秒成功的点击次数和每秒失败的点击次数。尝试连接数。
3、数据库服务器指标
用户连接数，也就是数据库的连接数量。数据库死锁量。数据库缓存的命中情况。
(7)web应用程序做软件产品测试扩展阅读
对被测的Web应用程序进行需求分析，即对所做的测试作一个简要的介绍，包括描述测试的目标和范围，所测试的目标要实现一个什么样的功能，总结基本文档、主要活动。
写出测试策略和方法，这里包括测试开始的条件、测试的类型、测试开始的标准以及所测试的功能、测试通过或失败的标准、结束测试的条件、测试过程中遇到什么样的情况终止和怎么处理后恢复等。
一个Web应用程序由完成特定任务的各种Web组件（web components)构成的并通过Web将服务展示给外界。在实际应用中，Web应用程序由多个Servlet、JSP页面、HTML文件以及图像文件等组成。所有这些组件相互协调为用户提供一组完整的服务。
8. 如何对Web应用程序进行负载测试
定义测试策略 到目前为止，您肯定参加过这样的会议，客户倚靠在宽大的会议桌上，问您：“这个系统能处理上千个用户吗？”传统的负载测试方法要求您编写脚本并执行测试，以试图给出此问题的精确答案。对于这种测试，您需要定义“处理”的含义以及 1000 名典型用户在站点活动时的情形。您需要定义测试用例以代表各种用户活动：例如，购买股票或注册新的帐户。接下来，您必须估计用户在这些测试用例上的分布。对以下数据进行假设，即模拟真实用户与应用程序交互时，需要多长的思考时间（或等待时间）。因此，负载测试期间活动的可从某个方面大致反映出同样数量的真实用户在站点活动时的情形。 这种方法有几个不足之处。首先，其结果不会比您做的假设更好。显然，不正确的假设将使结果出现偏差。 其次，估计真实用户需要大量客户端硬件。如果对每名虚拟用户给定需要的处理能力和内存量，则典型的客户端计算机可以处理大约 200 名虚拟用户。因此，对 2000 名用户并发处理级别的测试需要 10 台客户端计算机 — 这是一笔重大投资。测试使用 HTTPS 的站点将需要多得多的客户端硬件。 最终，此方法难以向您的开发团队提供以操作为导向的信息。当某处出现故障时，常常难以再现该问题。 作为备选方案，我们建议您围绕以下这些关键问题设计测试用例： �6�1 系统瓶颈在哪里？系统能同步处理多少个并发请求？ �6�1 在响应时间变得不可接受之前，一台机器能处理多少名不同步的超级用户？ �6�1 添加额外的硬件时，结果是线形增长的吗？ �6�1 有任何稳定性问题会妨碍站点运行于生产环境中吗？ 此方法将使用开发团队（此开发团队参与可能出现问题的领域）提供的附加信息。请关注这些领域。对于上一个示例，其瓶颈可能出在定单提交领域。从这里您可以派生出更具体的问题，例如“提交流程可以同时处理多少个请求？”攻击这些特定领域是最快且成本最小的方法，用来向开发团队提供以操作为导向的信息，以便他们能改进系统。在使用这种方法的同时，我们推荐您记住遵循以下建议。 关注负载测试正如我们已提到的那样，首先要做的是构建导致潜在瓶颈和稳定性问题的脚本。这种“数据第一，假设第二”的方法使您能够从应用程序收集原始数据，然后根据假设确定更高级别的结果。不用担心为识别低风险站点的脚本编写问题。例如，为站点的帮助领域或只读文档领域编写脚本不大可能出现系统瓶颈。 同步请求使用同步请求攻击瓶颈。此处的这个主意是模拟最坏的情况：即，站点上的用户精确地在同一时间攻击瓶颈。通过使用户同步，您可以重复进行此测试。如果不同步结果，则难以再现故障情况。可以使用同步点做到这一点，同步点是大多数较健壮（成本也较高）的测试工具中提供的一项功能。同步点迫使每名虚拟用户一直等到剩余的用户到达脚本中定义的点后，才能开始下一请求。它允许您精确并重复地确定站点的潜在瓶颈区域能处理的并发用户数。例如，下限可以是 7 名并发同步用户。 创建循环测试用例脚本使测试用例循环。在另一种方法中，每次测试用例迭代前后，站点应处于相同状态。这允许您长时间地重复运行测试用例。 使用超级用户最后，使用我们所称的超级用户。正如前面所提到的，超级用户运行时思考时间设置为零。请记住，思考时间假设是用于常规测试中，以使虚拟用户模拟真实用户。但是，如果将虚拟用户思考时间减半，则服务器的实际负载将加倍。在另一种方法中，服务器真正关心的与负载有关的变量是每秒的请求数。虚拟用户的数量及其思考时间结合起来生成该负载。 让我们进行一些数学运算以使此概念更清晰。下面的公式计算访问站点的真实用户生成的负载（请求数/秒）： 例如，某个站点有 100 名并发用户，假设下载时间为 10 秒，思考时间为 30 秒，则每秒将生成 2.5 页。如果我们假设每页 3 个请求，则在 Web 服务器上将转化为每秒 7.5 个请求。 以超级用户运行测试时，观察每秒请求数，并与刚刚计算的值比较。根据我们的经验，真实用户数与超级用户数的比例通常约为 15:1。对于同一个示例，这意味着 (100/15) 名超级用户将生成与 100 名普通用户相同的负载。再举一个例子，假设在 10 名超级用户之后响应时间变得不可接受。请注意转换回真实用户数的该点每秒请求数。现在您可以进行任何希望的思考时间假设，甚至可以更改它而无需重新运行测试。在几天的测试之后，您将能根据直觉从超级用户数转换成真实用户数。此方法允许您保持用户数可控，减少所需的客户端硬件数量，并包含负载测试软件的成本。 这些超级用户测试用例对于多机测试很有用。要测试站点的可伸缩性，可添加第二台 Web 服务器和一个负载平衡器，并重复超级用户测试。理想情况下，在看见相同的相应次数之前，您将能加倍超级用户数量。 要回答稳定性问题，可运行测试，以在延长的时间段内维持合理数量的并发且未同步超级用户。我们在上一个项目中熬了很多个通宵，甚至 24 小时昼夜不停，但持续时间与应用程序有关。我们称之为“内置”测试。一旦您已采取步骤识别并潜在地解决了找到的瓶颈，则重复同步点测试，看下限是否有所增长。然后用所支持的新的并发用户数重新运行“内置”测试。以努力提高此数字为目标重复该循环，直到达到质量条。 但是有多少用户呢？ 尽管此方法向开发团队提供了有价值的信息，但它使得您更难于回答会议室的问题。不过，您可以近似地估计答案。例如，假设站点的最坏情况瓶颈显示，每台计算机多于 20 名超级用户的情况下，响应时间超过 10 秒。根据您从我们建议的公式计算的结果，近似地估计有 300 名真实用户（20 名超级用户 × 15 名真实用户）。此时，您可以做出与常规用例中相同的假设。通常情况下，有百分之多少的用户正在使用站点的此领域？假设预期 50% 的用户正在使用此领域，而其他领域，例如文档或数据库读取，用户比例则没有这么大。这意味着具有一台 Web 服务器的系统将处理大约 600 名用户。 到目前为止，我们已讨论了在能明确地指向站点的一个瓶颈领域的情况下该如何做，但如果影响性能的领域不止一个时您又应如何做呢？答案是创建单独查看各个领域的测试脚本。首先孤立地运行这些脚本，然后一起运行。再比较结果，看站点的一个领域对另一个领域的影响有多大。