QTP自动化测试实践.docx

QTP自动化测试实践 第8章 数据驱动测试 测试脚本的开发和维护是自动化测试的重要环节，适当地调整和增强测试脚本，能提高测试脚本的灵活性，增加测试覆盖面，以及提高应对测试对象变更的能力。数据驱动方式的测试脚本开发是解决这类问题的重要手段。 本章介绍如何在自动化测试过程中使用数据驱动的测试脚本开发方式，对测试脚本进行参数化，包括如何使用QTP的Data Table参数化、Action参数化、环境变量参数化等脚本参数化的方法。 8.1 数据驱动测试方法 数据驱动的测试方法要解决的核心问题是把数据从测试脚本中分离出来，从而实现测试脚本的参数化。 8.1.1 什么时候使用数据驱动测试方法 自动化测试对录制和编辑好的测试步骤进行回放，这种是线性的自动化测试方式，其缺点是明显的，就是其测试覆盖面比较低。测试回放的只是录制时做出的界面操作，以及输入的测试数据，或者是脚本编辑时指定的界面操作和测试数据。 如何让测试脚本执行时，不仅仅局限于测试录制或编辑时的测试数据呢数据驱动的测试方式是解决这个问题的最佳方案。数据驱动测试把测试脚本中的测试数据提取出来，存储到外部文件或数据库中，在测试过程中，从文件动态读入测试数据。 注意如果希望测试的覆盖面更广，或者让测试脚本能适应不同的变化情况，则需要进行测试脚本的参数化，采用数据驱动的测试脚本开发方式。 8.1.2 数据驱动测试的一般步骤 通常，数据驱动测试按以下步骤进行 （1）参数化测试步骤的数据，绑定到数据表格中的某个字段。 （2）编辑数据表格，在表格中编辑多行测试数据（取决于测试用例以及测试覆盖率的需要）。 （3）设置迭代次数，选择数据行，运行测试脚本每次迭代从中选择一行数据。 QTP提供了一些功能特性，让这些步骤的实现过程得以简化。例如，使用“Data Table”视图来编辑和存储参数，如图8.1所示。 图8.1 Data Table视图 另外，还提供“Data Driver向导”，用于协助测试员快速查找和定位需要进行参数化的对象，并使用向导进行一步一步的参数化过程。 8.2 参数化测试 在QTP中，可以通过把测试脚本中固定的值替换成参数的方式来扩展测试脚本，这个过程也叫参数化测试，能有效地提高测试的灵活性。 8.2.1 通过参数化测试来提高测试的灵活性 可以通过参数化的方式，从外部数据源或数据产生器读取测试数据，从而扩大测试的覆盖面，提高测试的灵活性。在QTP中，可以使用多种方式来对测试脚本进行参数化，数据表参数化（Data Table Parameters）是其中一种重要的方式，还有环境变量参数化（Environment Variable Parameters）、随机数参数化（Random Number Parameters）等。 下面以QTP自带的“Flight”程序为例，介绍如何对测试脚本进行参数化。假设在名为“Flight Reservation”的订票界面中，输入航班信息后，插入订票记录，然后，希望重新打开该记录，检查航班信息中的终点的设置是否正确，录制的测试脚本如图8.2所示。 图8.2 录制的测试脚本 提示对于这样一个测试脚本，仅能检查特定的航班订票记录的正确性，如果希望测试脚本对多个航班订票记录的正确性都能检查，则需要进行必要的参数化。 8.2.2 参数化测试步骤 首先，把测试步骤中的输入数据进行参数化，例如航班日期、航班始点和终点等信息。下面，以“输入终点”的测试步骤的参数化过程为例，介绍如何在关键字视图中对测试脚本进行参数化。 （1）选择“Fly To ”所在的测试步骤行，单击“Value”列所在的单元格，如图8.3所示。 图8.3 设置参数值 （2）单击单元格旁边的“”按钮，或按快捷键“CTRLF11”，则出现如图8.4所示的界面。 图8.4 选择参数从Data Table读取 提示在这个界面中，选择“Parameter”，在旁边的下拉框中选择“Data Table”，在“Name”中输入参数名，也可接受默认名，在“Location in Data Table”中可以选择“Global sheet”，也可以选择“Current action sheet（local）”，它们的区别是参数存储的位置不同。 （3）单击“OK”按钮，在关键字视图中可看到，“Value”值已经被参数化，替换成了如图8.5所示。 图8.5 参数化后的值 （4）这时，选择菜单“View | Data Table”，则可看到如图8.6所示的界面。 图8.6 Data Table中的参数数据 可看到，在“p_Item”列中有一个默认数据“Frankfurt”，这是参数化之前录制的脚本中的常量，可以在“p_Item”列中继续添加更多的测试数据。 提示可以双击修改“p_Item”列名，让其可读性更强，例如，改成“FlyTo”。 （5）把其他几个数据也参数化后，如图8.7所示。 图8.7 参数化后的测试步骤 QTP运行时，就会从如图8.8所示的数据表格中提取数据来对测试过程中的各项输入进行参数化。 图8.8 Data Table存储的参数值 8.2.3 使用随机数来进行参数化 对于选择航班这个测试步骤的参数化来说会有所不同，因为航班会跟随所选择的起点和终点而变化，因此，需要做特殊的处理。如下代码所示 取得航班列表的行数 ItemCount Window“Flight Reservation“.Dialog“Flights Table“.WinList“From“.GetItemsCount 随机选取其中一项 SelectItem RandomNumber0, ItemCount 选择航班 Window“Flight Reservation“.Dialog“Flights Table“.WinList“From“.Select SelectItem 先通过访问GetItemsCount属性，获取航班列表的行数，然后使用RandomNumber随机选取其中一项，最后，再通过Select方法选择航班。参数化后的测试步骤如图8.9所示。 图8.9 参数化后的测试步骤 提示使用随机数也是测试脚本参数化的一种重要方法，在QTP的测试代码中，可用RandomNumber来实现，在关键字视图编辑的界面如图8.10所示，其效果与在脚本中直接编辑是一样的。 图8.10 选择参数化方式为“Random Number” 8.2.4 参数化检查点 测试脚本的最后一个测试步骤是检查订票记录中的航班终点是否正确，同样需要进行适当的参数化，方法如下 （1）单击检查点所在测试步骤的“Value”列中的单元格，如图8.11所示。 图8.11 设置检查点参数 （2）单击旁边的按钮，则出现如图8.12所示的界面。 图8.12 检查点属性编辑界面 （3）在“Configure value”中选择“Parameter”后，可单击“OK”按钮接收默认的设置，也可单击旁边的编辑按钮，在如图8.13所示的界面中，进行参数化的详细设置。 图8.13 参数化的详细设置 在“Parameter types”中，选择“Data Table”；可在“Name”修改参数名，或接受默认的命名，产生如图8.14所示的数据列，也可以选择“FlyTo”，因为检查点所指的航班终点得到的预期值应该与测试步骤中选择航班终点时的输入数据一致，否则认为错误。 图8.14 Data Table中存储的参数值 8.2.5 设置数据表格迭代方式 把测试步骤和检查点的参数化工作都完成后，可得到如图8.15所示的测试步骤。 图8.15 参数化后的测试步骤 切换到专家视图，可看到如图8.16所示的测试脚本。 图8.16 参数化后的测试脚本 运行这个测试脚本之前，还要做一些必要的设置，选择菜单“File | Settings”，出现如图8.17所示的测试设置界面，切换到“Run”页，在“Data Table iterations”中，可设置数据表格的迭代方式。 图8.17 设置运行迭代方式 提示“Run one iteration only”是指仅运行一次迭代，也就是说，即使Data Table中有多条测试数据，也仅执行一次；“Run on all rows”则是指按数据表格中的所有数据都运行一次；选择“Run from rowto row”则可进一步设置运行的测试数据范围。 选择“Run on all rows”，得到如图8.18所示的测试结果。 图8.18 测试结果 8.3 Action测试输入的参数化 对于重复使用的测试用例，可以转换成公共用例，适当参数化后，可被其他测试用例调用。在QTP中，可以把Action的输入适当参数化，转换成可重用的测试步骤。 8.3.1 编辑Action的属性 QTP的“Flight”程序中的登录模块的测试步骤是在执行其他测试步骤之前都要经过的测试步骤，因此有“潜力”成为一个可重用的Action。对于如图8.19所示的测试步骤，可以进一步参数化后，成为可重用的测试步骤，被其他Action调用。 图8.19 可重用的测试步骤 选择“Action1”所在的行，然后单击鼠标右键，选择菜单“Action Properties”，则出现如图8.20所示的界面。 图8.20 Action属性编辑窗口 在“Name”中输入新的Action名称，例如“Login_Action”，在“Description”中输入对Action的描述信息，如图8.21所示。 图8.21 编辑Action属性 注意把“Reusable action”勾选上，表示该Action为可重用的测试步骤，是可被其他Action调用的测试步骤。 8.3.2 添加Action的输入参数 切换到“Parameters”页，如图8.22所示。单击“”按钮，添加调用Action需要输入的参数名和类型。 图8.22 添加输入参数 提示在这里，“Login_Action”需要两个参数，其中，“AgentName”表示代理机构登录名，“Password”表示登录密码。 添加完参数后，回到关键字视图，选择“输入代理机构名”所在的测试步骤，单击“Value”列的单元格旁边的“”按钮，出现如图8.23所示的界面。 图8.23 设置参数 在“Parameter”中，选择“Test/action parameter”，然后，选择刚才编辑好的参数“AgentName”，单击“OK”按钮。重复这个步骤，为“输入登录密码”的测试步骤设置参数，得到如图8.24所示的测试步骤。 图8.24 完成测试步骤 8.3.3 调用Action 完成Login_Action的参数化后，就可以在其他Action中调用这个Action，方法是在Action的测试步骤中，选择菜单“Insert | Call To Existing Action”插入现有的Action，如图8.25所示。 图8.25 选择Action 在这个界面的“From test” 中选择“”，在“Action”中选择“Login_Action”，单击“OK”按钮后，即可插入对“Login_Action”测试步骤的引用，如图8.26所示。 图8.26 插入对Action的引用 选中“Login_Action”所在的行，单击鼠标右键，选择菜单“Action Call Properties”，出现如图8.27所示的界面。 图8.27 设置参数值 在“Parameter Value”页中，为每一个参数设置输入的参数值，也可以单击“Value”列旁边的“”按钮，为输入绑定到Data Table中的数据。单击“确定”后，可在专家视图看到如图8.28所示的测试代码 图8.28 使用RunAction方法来调用Action 该测试代码使用了RunAction方法来调用“Login_Action”，输入的第一个参数值和第二个参数值都为“MERCURY”。测试脚本的运行结果如图8.29所示，可看到，“Login_Action”被成功地调用，测试结果中也列出了调用“Login_Action”所输入的参数值。 图8.29 测试结果 8.４ 使用环境变量的参数化 在QTP中，除了前面所讲的几种参数化测试的方式外，还可以使用环境变量来进行测试的参数化。下面介绍如何使用环境变量来参数化如图8.30所示的测试步骤，将其中的“Agent Name”和“Password”的值从定义好的环境变量读入。 图8.30 待参数化的测试步骤 8.4.1 定义和设置环境变量 在使用环境变量之前，需要定义好环境变量，方法如下 （1）选择菜单“File | Settings”，出现如图8.31所示的界面。 图8.31 环境变量设置 （2）在这个界面中，切换到“Environment”页，在“Variable type”中选择“User-defined”，然后，单击旁边的“”按钮，在如图8.32所示的界面中，定义环境变量名和输入的值。 图8.32 添加环境变量 （3）重复这个步骤，定义“Password”的环境变量，得到如图8.33所示的结果。 图8.33 成功添加自定义环境变量 8.4.2 在测试步骤中绑定环境变量值 定义好环境变量并设置好其值之后，就可以在测试步骤中使用该环境变量。方法如下 （1）在关键字视图中，定位到测试步骤的“Value”列，如图8.34所示。 图8.34 定位到测试步骤的“Value”列 （2）单击旁边的“”按钮，出现如图8.35所示的界面。 图8.35 参数化选定的值 提示在界面中，选择“Parameter”，并在下拉框中选择“Environment”，在“Name”中选择“AgentName”，在“Value”中输入对应的值。 （3）重复这个步骤，设置“输入登录密码”的测试步骤所对应的环境变量，如图8.36所示。 图8.36 设置“输入登录密码”的测试步骤所对应的环境变量 设置完后，可得到如图8.37所示的测试步骤。 图8.37 参数化后的测试步骤 这样，QTP在运行测试脚本时，就会读取测试步骤所绑定的环境变量值，来执行相应的数据输入动作。 8.4.3 导出环境变量到XML文件 选择菜单“File | Settings”，在如图所示的界面中，单击“Export”按钮，可把当前定义的环境变量导出到XML文件中，如图8.38所示。 图8.38 导出环境变量 导出后的XML文件如图8.39所示。可看到，和之间是一个个定义好的环境变量，包括变量名和变量值。 图8.39 导出的XML文件 8.4.4 导入外部环境变量文件 对于导出的XML文件，可以再次导入，如图8.40所示。 图8.40 导入环境变量 也可以在测试脚本中编写代码来加载，例如，下面的脚本在执行界面的测试步骤之前，先加载D\QTP\C8\ParameterizingTest3\Env目录中的某个环境变量文件。 SystemUtil.Run “D\Program Files\Mercury Interactive\QuickTest Professional\samples\flight\app\flight4a.“ 启动Flight程序 Environment.LoadFromFile“D\QTP\C8\ParameterizingTest3\Env\Login2.xml“ 加载外部环境变量文件 Dialog“Login“.Activate Dialog“Login“.WinEdit“Agent Name“.Set Environment“AgentName“ 输入代理机构名 Dialog“Login“.WinEdit“Password“.Type Environment“Password“ 输入登录密码 Dialog“Login“.WinButton“OK“.Click 确认登录 8.5 使用数据驱动器来参数化测试 为了简化测试脚本参数化的过程，QTP还提供了名为“Data Driver”的功能，可自动检测脚本中可能需要进行参数化的变量。 8.5.1 数据驱动器的使用方法 “Data Driver”可以帮助测试人员快速找到需要参数化的测试对象、检查点的数据。例如，对于如图8.41所示的录制脚本，选择菜单“Tools | Data Driver”，出现如图8.42所示的界面。 图8.41 待参数化的测试步骤 图8.42 数据驱动器 在这个界面中，列出了测试步骤中所有可能需要进行参数化的变量。 8.5.2 数据驱动向导 单击“Parameterize”按钮，出现如图8.43所示的数据驱动向导。 图8.43 数据驱动向导 单击“下一步”按钮，则出现如图8.44所示的界面。 图8.44 参数化选定的测试步骤 在这个界面中的左边窗口，定位到测试步骤所操作的界面控件，在右边显示参数化的名称和数据，单击“编辑”按钮，可在如图8.45所示的界面中进一步设置参数。 图8.45 参数化设置 单击“OK”按钮，回到向导界面，单击“下一步”按钮，则出现如图8.46所示的界面，表明测试步骤的参数设置完成。其他测试步骤也可按类似的方式一步步地完成参数化。 图8.46 完成参数化 第3章软件自动化测试工具 软件自动化测试工具是实现软件自动化测试必不可少的关键，因此，选择一个优秀的、适合自己的测试项目实际情况的测试工具是实现成功自动化测试的第一步。本章介绍自动化测试工具的分类，以及如何选择一个合适的自动化测试工具，并且介绍自动化测试工具的基本原理。 3.1 自动化测试工具类型 测试工具的种类很多，有用于管理测试的，有帮助实现测试自动化的，有开源的，有免费共享的。软件测试工具按照其用途，可大致分成以下几大类 测试管理工具q 自动化q功能测试工具 性能测试工具q 单元测试工具。q 白盒测试工具。q 测试用例设计工具。q 如果按测试工具的收费方式，又可分为以下几类。 商业测试工具。q 开源测试工具。q 免费测试工具。q 3.1.1 商业测试工具 商业测试工具的特点是需要花钱购买，但是会相对成熟和稳定，并且有一定的售后服务和技术支持。但是，由于其价格昂贵，并不是每一个企业都能负担得起。 商业测试工具主要集中在GUI功能测试和性能测试方面，目前流行的基于GUI的功能自动化测试工具有Robot、QTP、TestComplete等。各种自动化测试工具实现的功能基本相同，但是在IDE、脚本开发语言、支持的脚本开发方式、支持的控件等方面则有很多不同之处。 3.1.2 开源测试工具 开源软件是指软件的源代码是公开发布的，通常是由自愿者开发和维护的软件。开源测试工具是测试工具的一个重要分支。越来越多的软件企业开始使用开源测试工具。但是开源并不意味着完全的免费，开源测试工具同样需要考虑使用的成本，并且在某些方面可能要比商业测试工具的成本还要高。 商业工具的价格在不断地提高。图3.1为WinRunner近几年的价格变化图。 图3.1 WinRunner近几年的价格变化 可以看到，价格在不断地增长。这对于那些中小型软件企业而言，无疑加大了测试的成本。开源测试工具相对于商业测试工具拥有以下优势 相对低的成本大部分开源测试工具可免费使用，只要不做商业用途即可。q 更大的选择余地可以打破商业测试工具的垄断地位，给测试人员更多的选择空间。q 可自己改造源代码开放，意味着可对其进行修改、补充和完善，可对其进行个性化改造。q 虽然开源测试工具拥有一定的优势，但是，同时也存在很多不足之处，包括以下几方面。 安装和部署相对困难大部分开源测试工具的安装配置过程比较烦琐，需要测试人员付出一定的努力。q 易用性开源测试工具在易用性、用户体验方面做得不够完善。q 稳定性部分开源测试工具的稳定性不够强。q 学习和获取技术支持的难度大部分开源测试工具不提供培训指导和技术支持服务，联机帮助和用户手册不够完善，增加了测试人员的q学习难度。 3.1.3 自主开发测试工具 目前，很多软件测试组织其实已经具备了自己动手开发测试工具的条件 市场对于测试工具的接受程度在不断提高，人们对测试工具的认识不断加强和深入，对测试工具原理的理解不断提高。从脚本化到数据驱动，再到关键字驱动等，很多新的测试工具理念被引入并被广泛接受。q 由于技术的成熟，测试工具变得容易构建。软件系统现在变得更容易测试，可测试性更强，COM、XML、HTTP、HTML等标准化的接口使得测试更加容易进行。托管程序（例如qJava、.NET）的反射机制使得查找定位对象，以及捕捉对象和操作对象更加容易。 一些开源的框架可以被利用。利用开源框架平台来组合、搭建适合自己测试项目使用的测试平台和测试框架。 自己动手开发测试工具的优势有以下方面。 购买成本为零。q 简便只需要开发自己需要的那部分功能。q 个性化可自己定制需要的功能，随时修改，配置项目组成员的使用习惯。q 可扩展性可随时增加新的功能。q 可充分利用项目组熟悉的语言开发，利用自己的技术优势。q 可使用自己熟悉的脚本语言，不需要使用商业工具提供的“厂商脚本语言”。q 然而，虽然自己动手设计和开发测试工具有很多好处，但是必须考虑随之而来的成本问题。自己开发测试工具的成本只是开发时间和人员投入的成本，以及维护的成本。当然，如果把测试工具推广到其他项目组，则也会有学习和培训成本。另外，需要考虑测试工具的实用性，不要做一个大而全的、面面俱到的、很多功能基本上不会被用到的测试工具。 3.2 自动化测试工具选型 为了保证在一个测试团队中成功地应用某款测试工具，尤其是对于大型商业工具的应用，应该首先进行工具的选型，通过分析实际情况，确定选用范围。对选用范围内的几款测试工具进行试用。根据试用的反馈效果决定最终采用哪款测试工具。在大规模使用工具之前，还应该对测试人员进行全面的工具培训。培训后，正式在项目中应用测试工具，制定相应的测试工具使用策略，并把工具融入测试工作中。 3.2.1 测试工具评估 测试工具的选型是成功应用测试工具的第一步，测试工具的选型应该注意以下几点 （1）首先，分析项目的特点，软件系统采用的开发工具、语言、技术、平台等。还要结合测试的类型、测试的要求。 （2）同时还要了解目前存在的各种测试工具的情况，包括工具的生产厂家、价格、产品特性、技术支持和售后服务情况，还要了解该工具的市场占有率、使用人群等情况，如果是国外厂商生产的测试工具，最好再了解清楚国内的代理机构的情况等。 （3）选型的最后一步是编写选型报告。通过综合分析所有收集回来的材料，横向比较测试工具的优势和劣势。 3.2.2 测试工具试用 在初步选型后，可定出几个满足要求的测试工具，然后进行深入的试用工作，应该尽可能尝试测试工具的所有功能，并且可能的话，要尽量在项目的软件系统中尝试。 需要制定一份详细的测试工具的试用计划，因为这可能是一项长时间的、需要谨慎进行的工作，尤其是对于那些商业的测试工具，动辄上百万的购置费用。很多公司由于没有谨慎进行前期的选型和试用工作，导致购买的测试工具不适用，或者使用效果不理想，最后被测试人员扔在角落里。 注意不要仅仅听信测试工具销售人员的介绍就轻易购买，一定要自己组织一次详细的试用活动，确认适合在项目中使用，才能购买。 3.2.3 自动化测试工具的培训 确定了选用的测试工具后，正式在测试项目中使用该测试工具之前，还需要组织相关测试人员进行测试工具的培训。测试工具的培训可包括以下内容。 （1）测试工具的总体介绍主要给测试人员讲解测试工具包括哪些主要的功能和特性，可用于哪些方面的测试。 （2）测试工具操作方法介绍主要给测试人员讲解测试工具的每一项功能的使用方法、操作步骤、注意事项等方面的内容。一般可由工具厂商派遣的技术支持人员进行，也可由熟悉该工具的测试人员来介绍，例如，负责前期测试工具试用的测试人员。 （3）测试工具使用实践，则是结合某个具体的例子给测试人员演示测试工具的使用方法和使用经验等。一般可由负责该测试工具试用的测试人员进行。 （4）对测试工具相关的测试理论进行讲解的目的是为了让测试人员了解该测试工具的原理，以及工具所应用的领域的相关理论知识，让测试人员在理论知识的指导下能更好、更恰当、更充分、更正确地使用测试工具。 技巧测试工具的培训是成功引入测试工具的关键环节，在正式使用测试工具之前，应该确保测试人员充分掌握测试工具的基本使用方法，避免在使用过程中碰到很多工具操作和使用上的问题，导致测试进度缓慢 3.3 自动化测试工具的原理 测试工具的优势在于可部分地替代人工的测试过程，能重复不断地执行，能精确判断数值和字符对象。自动化测试工具把测试用例用自动的方式执行，例如，自动地产生数据，自动地打开应用程序，自动地查找控件，自动地输入数据，自动地操作控件，自动地收集测试结果，自动地与预期结果进行比较等。 自动化功能测试工具可基于GUI层面进行测试，也可基于代码层面进行测试。只要实现了自动化执行测试用例，自动化地检查测试数据的测试工具，替代人工进行测试步骤的执行，从而验证应用程序是否满足了特定功能的测试工具，都可以称为自动化功能测试工具。 3.3.1 基于代码层面的功能自动化测试工具 基于代码层面的功能自动化测试工具主要是一些单元测试工具，例如JUnit、NUnit、MSTest等，这些工具直接访问被测试的应用程序的代码，对其中的类和函数进行调用，输入各种测试数据，检查函数的返回值，通过比较返回值与期待的值是否一致来判断测试是否通过。图3.2所示的是Visual Studio.NET 2005中的单元测试管理界面。 图3.2 Visual Studio.NET 2005中的单元测试管理界面 这种类型的工具主要实现了测试代码框架产生的自动化，例如，下面代码是Visual Studio.NET 2005中的单元测试框架MSTest为某个类的方法自动产生的单元测试代码框架 // 以下代码由 Microsoft Visual Studio 2005 生成。 // 测试所有者应该检查每个测试的有效性。 using Microsoft.VisualStudio.TestTools.UnitTesting; using System; using System.Text; using System.Collections.Generic; using AUT; namespace TestProject1 { /// ///这是 AUT.1 的测试类，旨在包含所有 AUT.1 单元测试 /// [TestClass] public class 1Test { private TestContext testContextInstance; /// ///获取或设置测试上下文，上下文提供有关当前测试运行及其功能的信息。 /// public TestContext TestContext { get { return testContextInstance; } set { testContextInstance value; } } region 附加测试属性 // //编写测试时，可使用以下附加属性 // //使用 ClassInitialize 在运行类中的第一个测试前先运行代码 // //[ClassInitialize] //public static void MyClassInitializeTestContext testContext //{ //} // //使用 ClassCleanup 在运行完类中的所有测试后再运行代码 // //[ClassCleanup] //public static void MyClassCleanup //{ //} // //使用 TestInitialize 在运行每个测试前先运行代码 // //[TestInitialize] //public void MyTestInitialize //{ //} // //使用 TestCleanup 在运行完每个测试后运行代码 // //[TestCleanup] //public void MyTestCleanup //{ //} // endregion /// ///Add int, int 的测试 /// [DeploymentItem“AUT.“] [Test] public void AddTest { 1 target new 1; TestProject1.AUT_1Accessor accessor new TestProject1.AUT_1Accessortarget; int i 0; // TODO 初始化为适当的值 int j 0; // TODO 初始化为适当的值 int expected 0; int actual; actual accessor.Addi, j; Assert.AreEqualexpected, actual, “AUT.1.Add 未返回所需的值。“; Assert.Inconclusive“验证此测试方法的正确性。“; } } } 在代码框架的背后，单元测试框架负责查找和调用被测试的类和方法，通过代码反射机制可以访问到被测试代码中的所有方法和属性。另外，单元测试框架会提供一系列的Assert类，使用这些Assert类可以简化测试结果检查、判断的工具。 提示在执行单元测试时，单元测试框架负责加载包含测试类的程序集文件，通过查找里面的测试类和测试方法标识来加载测试方法，例如，上面代码中的“[Test]”就是用于标识其中的测试方法。 3.3.2基于浏览器和DOM对象模型的功能自动化测试工具 另外一种自动化的功能测试工具是基于浏览器和DOM对象模型开发的，例如Selenium、Watir等，这些测试工具直接访问Web浏览器，利用脚本语言操纵浏览器和Web页面中包含的DOM对象，从而达到模拟用户控制浏览导航、页面元素的操纵等效果，并且直接获取DOM对象的属性，从而获得Web页面元素的各种属性，通过这些属性可判断测试步骤的结果是否正确。图3.3所示的是可作为插件嵌入到MozillaFirefox浏览器中的SeleniumIDE的测试界面。 图3.3SeleniumIDE的测试界面 HTMLDOM（DocumentObjectModel）是一个HTML文档的编程接口，它定义了HTML的标准对象集合，并且定义了标准的访问和操纵HTML对象的方式。HTMLDOM接口让测试人员可以访问和操纵HTML文档的内容。图3.4所示的界面是使用了一个名为“IEDOMInspector”的工具查看到的Web页面中的DOM对象。 图3.4IEDOMInspector的界面 如果熟悉和了解DOM的原理，那么完全可以自己动手编写一个基于浏览器和DOM的Web页面自动化测试工具，例如，下面的C代码就是一个简单的例子 using System; using System.Colle