接口自动化测试
2024-05-11 12:47
1. 接口自动化测试
接口 ：外部系统与本系统之间以及系统内部的各个子系统间，以约定标准提供的服务，包括对外提供的接口/对内提供的接口。
在这块我们举一个比较生活化的例子，我们平常使用的笔记本，在笔记本的两端有很多小插口，最常见的就是USB插口，我们可以把鼠标连接在USB插口上，也可以把键盘、U盘连接在USB插口上，为什么同一个USB接口可以连接这么多设备呢，其实这个接口，他就有一个统一对外的连接标准。 在我们开发当中，也有一个对外暴露的接口，因为他们服务的协议都是统一的，最常见的就是hhtp协议，我们规定好一种格式，让客户端来调用我们。 这里面键盘鼠标属于调用方，插到笔记本的USB上，就可以连接设备，就可以进行操作了。对外暴露的一个统一的一个规范，这样去理解接口，更形象一些。
在了解完什么是接口之后，我们来说一下什么是接口测试。 接口测试 测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等，保证对外提供接口的正确性和健壮性。 我们在具体测试过程中，我们不用关心接口调用方和接收方的实现逻辑，我们只需要知道传入什么数据，返回什么的结果是否达到我们的预期。接口测试其实也是黑盒测试，他与UI测试的区别就是没有界面交互，是不可视化的。
测试前置 ：我们不能等到整个系统全部开发完成才能进行测试，我们可以通过调用接口来进行测试，把问题拦截在前期，降低问题修复成本。 Bug更容易定位 ：因为我们按接口进行测试，出现问题后在被测接口中排查就可以了，它比系统集成之后，发现问题更容易定位，系统集成之后有各种模块的调用，出现bug之后再排查，排查的链路非常的长。另外从机制上更接近出问题的地方更容易命中问题。 前后端分离结构 ：现在很多系统都采用前后端分离架构，各服务之间更多的是通过接口来实现信息互通，对接口进行直接测试，可以更全面的覆盖各类测试场景。 自动化测试落地性价比高 ：比UI自动化测试更稳定，我们上面已经说了UI层的元素时常发生变化，有时改一个简单的元素，都有可能导致我们的自动化测试走不下去，写一套自动化测试脚本比较容易的，但是维护起来，会耗费很大的时间精力，相对来说，接口就比较稳定，一个项目没有大的改造，入参和出参就是固定的，变化的概率比较小，这样维护起来也比较方便。 减少安全隐患 ：比如我们在平常的测试过程中，测试用户名和密码，密码格式要求不能输入特殊字符，前端做了校验，而后端没有处理，这样我们只测试页面，这条case就默认通过了，但一些黑客可能通过抓包的方式进行登录，这样安全隐患就比较大了。我们对接口进行安全测试，可以避免安全隐患。
借助工具 ： Postman、Jmeter、jsf平台、jsf测试工具、easytest 编写测试脚本 ：Java+TestNG
请关注下一篇如何使用Java+TestNG进行接口自动化测试
2. 接口自动化测试工具有哪些？
接口自动化工具有以下： 1、QTP。是quicktest Professional的简称，是一种自动测试工具。使用QTP的目的是想用它来执行重复的手动测试，主要是用于回归测试和测试同一软件的新版本。因此你在测试前要考虑好如何对应用程序进行测试，例如要测试那些功能、操作步骤、输入数据和期望的输出数据等。 2、WinRunner。是一种企业级的功能测试工具，用于检测应用程序是否能够达到预期的功能及正常运行。通过自动录制、检测和回放用户的应用操作，WinRunner能够有效地帮助测试人员对复杂的企业级应用的不同发布版进行测试，提高测试人员的工作效率和质量，确保跨平台的、复杂的企业级应用无故障发布及长期稳定运行。 3、AdventNetQEngine。是一个应用广泛且独立于平台的自动化软件测试工具，可用于Web功能测试、web性能测试、Java应用功能测试、Java API测试、SOAP测试、回归测试和Java应用性能测试。 自动化（Automation）是指机器设备、系统或过程（生产、管理过程）在没有人或较少人的直接参与下，按照人的要求，经过自动检测、信息处理、分析判断、操纵控制，实现预期的目标的过程。 自动化技术广泛用于工业、农业、军事、科学研究、交通运输、商业、医疗、服务和家庭等方面。采用自动化技术不仅可以把人从繁重的体力劳动、部分脑力劳动以及恶劣、危险的工作环境中解放出来，而且能扩展人的器官功能，极大地提高劳动生产率，增强人类认识世界和改造世界的能力。
3. 接口自动化测试测试用例设计
浅谈接口自动化测试测试用例设计 一、 前言 很多中台项目，大部分为接口测试。为了使新入职的测试同事尽快融入项目，以及迭代开发中方便管理测试用例。完成该总结。 二、 测试用例设计思路 1、 接口类型概述及优先级 1） 提供给第三方调用的接口 2） 内部系统使用，核心功能接口 3） 内部系统使用，非核心功能接口 基本按照1）2）3）的顺序进行测试，特别情况除外 2、 单接口测试优先级 1） 优先测试正向测试用例，保证基本功能实现 2） 设计逆向测试用例，确保接口的健壮性 3） 满足前提条件的测试用例 4） 默认参数是否满足 5） 参数校验 6） 参数间联动关系 7）多参数错误处理的优先顺序校验 三、 设计分析 1、 满足前提条件的测试用例 测试目标接口需要满足前置条件才能成功获取数据。 例如：需要登录token，通过传入参数获取下游接口数据 2、 携带默认参数的测试用例 携带默认参数的测试用例仅需要设计一条，所有默认参数的字段都不填写，其他字段输入正常。 [if !supportLists]3、 [endif]参数校验 参数校验包含如下几方面： [if !supportLists]1）[endif]输入参数是否为必须输入项 [if !supportLists]2）[endif]输入参数的类型 [if !supportLists]3）[endif]输入参数的枚举值校验 [if !supportLists]4）[endif]输入参数长度校验 以上测试用例最好根据字段一一校验，排除互相干扰 [if !supportLists]4、 [endif]参数间联动 有些参数见存在彼此制约的关系，根据实际情况设计测试用例 例如:A字段为1时，B字段一定为空。否则报错。 那么测试用例设计时应为：A字段为1时，B字段为空；A字段为1时，B字段不为空；A字段不为1时，B字段为空；A字段不为1时，B字段不为空；四条测试用例 这样基本覆盖所有分支流程。 [if !supportLists]四、 [endif] 测试用例实践操作 接口测试用例样例: 多条件查询接口 测试方法：使用robotFramework测试doubbo接口 协议请求方式：post 接口协议：JSON 消息请求列表 字段名数据类型默认值必须项备注 IDint 是长度为2 Tokenstring 是设备令牌 Statusstring 是1：正常 2：异常 typeint Status为1时，为必须输入项 sizestring 默认值 消息返回列表 字段名数据类型必须项备注 Codeint是正常：20000 异常：20001 Messagestring是 typeMessageint Status=1的所有ID 用例设计 NO. 测试内容 前置条件 输入参数 输出参数 用例属性 1目标数据为一条预置一条符合条件的数据Status=1，其他参数输入正常返回code=20000 typeMessage中返回的ID与预置数据一致 正向测试用例 2目标数据为多条预置多条符合条件的数据Status=1，其他参数输入正常返回code=20000 typeMessage中返回的ID与预置数据一致 正向测试用例 3 Token必须项检查 预置多条符合条件的数据Status=1，token输入为空，其他参数输入正常返回code=20001 typeMessage中返回为空 满足前提条件 4 Token正确性检查 预置多条符合条件的数据Status=1，token输入错误，其他参数输入正常返回code=20001 typeMessage中返回为空 满足前提条件 5 Status 必须项检查 预置多条符合条件的数据Status为空，其他参数输入正常返回code=20001 typeMessage中返回为空 参数校验 6 Status枚举预置多条符合条件的数据Status为1，其他参数输入正常返回code=20000 typeMessage中返回的ID与预置数据一致 参数校验 7 Status枚举预置多条符合条件的数据Status为2，其他参数输入正常返回code=20000 typeMessage中返回的ID与预置数据一致 参数校验 8 Status枚举预置多条符合条件的数据Status为3，其他参数输入正常返回code=20001 typeMessage中返回null 参数校验 9 Status=1，时联动校验预置多条符合条件的数据Status为1，type为空；其他参数输入正常返回code=20001 typeMessage中返回null 联动校验 10 Status！=1，时联动校验预置多条符合条件的数据Status！=1，type为空；其他参数输入正常返回code=20000 typeMessage中返回对应ID 联动校验 11 Status！=1，时联动校验预置多条符合条件的数据Status！=1，type不为空；其他参数输入正常返回code=20000 typeMessage中返回对应ID 联动校验 12 Size默认值输入校验预置多条符合条件的数据Size输入为空，其他参数输入正常返回code=20000 typeMessage中返回对应ID 默认值校验 13 Size默认值输入校验预置多条符合条件的数据Size输入不为空，其他参数输入正常返回code=20000 typeMessage中返回对应ID 默认值校验 14 ID 必须项检查 预置多条符合条件的数据ID为空，其他参数输入正常返回code=20001 typeMessage中返回为空 参数校验 15 ID 长度检查 预置多条符合条件的数据ID长度大于2，其他参数输入正常返回code=20001 typeMessage中返回为空 参数校验 16 破坏性测试预置多条符合条件的数据输入的参数类型错误请求未接收，返回404 稳定性测试 17 破坏性测试预置多条符合条件的数据输入的参数与提供的参数名称不一致请求未接收，返回404 稳定性测试 18 破坏性测试预置多条符合条件的数据输入的参数与提供的参数数量不一致请求未接收，返回404 稳定性测试 19 破坏性测试预置多条符合条件的数据输入的参数与提供的参数格式不一致请求未接收，返回404 稳定性测试 总结：自动化测试过程中会有一条自动化测试用例覆盖多种情况的可能（例如：正向测试用例与联动性验证的 Status=1，type输入不为空的测试用例重复，所以选择一条用例验证 。 ），以上的测试用例满足自动化的要求，手动测试过程中需要增加部分验证性的测试用例。且由于使用的测试工具特殊性，无需检查输入参数的类型。
4. 我眼中的接口测试和接口自动化测试
接口测试的目的是为了增加测试覆盖度、深入度 ，对接口的各个参数做实际场景中很难遇到的异常场景的测试，保证接口的稳定性。如果在这个前提下接口测试还是没有发现 bug，那么可以 review 下历次迭代中是不是业务测试发现的所有 bug 都是前端的。如果是，那么说明你们的后端开发工程师能力实在很强，应该恭喜你们遇到了这么给力的队友。在测试压力很大的情况下就可以酌情考虑不做接口测试，前端测试完成就上线了。
如果不是那就应该 review 你们的接口测试用例了。是不是用例设计的还不如业务测试全面？是不是用例设计的时候默认按照正常的取值范围？按照正常的业务逻辑进行的用例设计导致用例的覆盖还不如业务直接黑盒测出来的覆盖全。
自动化测试的主要目的不是发现多少 bug ，而是为了快速对接口做回归、做线上监控等，避免接口出现了低级问题、阻碍问题但是大家不能第一时间知道，等过了很长时间线上出了强反馈或者在错误接口的基础上又做了很多开发才被大家发现。当然，在接口自动化的基础上再做压力测试、稳定性测试等也会更方便。在这个前提下再评估接口自动化测试是否有必要，思路就会清楚一些。
整体上测试是为了保证业务中的 bug 能够在有限的资源下最大量、最快速的发现，业务实际情况不同、测试团队规模不同、测试与业务的合作模式、测试团队成员的技术能力等等都会影响测试方案的制定。
个人觉得如果团队有专人做接口测试，这种情况下接口测试定位到用来发现更多 bug 是没有问题的，如果没有发现 bug 那就需要仔细找找接口测试用例设计的问题。接口测试的目的不是取代业务测试，而是减少业务测试遇到阻碍问题的概率以及减轻业务测试模拟异常场景的工作量。接口自动化测试的目的是在回归场景节约业务测试的工作量，在新业务测试中实际反倒会占用更多的测试资源。
以上是作者拉拉肥对接口测试以及接口自动化测试的理解。你怎么看？欢迎点击 原文链接 在原帖共同讨论。
5. 常用的自动化测试工具及流程？
做自动化测试，怎么会不知道常用的自动化测试工具，还有相关的测试流程。以下是我为你整理推荐，希望你喜欢。 常用的自动化测试工具 常用的测试工具一般是：QTP+LoadRunner+QC 测试中还需的工具如下： 功能测试工具：QTP***HP***，WinRunner***MI***，Robort***IBM***，QARun***puware*** 效能测试工具：LoadRunner***HP***，WAS***MS***，Robort***IBM***【必须相应的外挂才支援效能方面的测试】，QALoad***puware*** 测试管理工具：TestDirector/Quarlity Center【这两个工具一个横版一个竖版，功能完全一样】，Rational TestManager 缺陷跟踪工具：Bugzilla、Mantis 其他：Rational Purify、Rational PureCoverager 自动化测试流程 需求分析阶段：只要就是对业务的学习，分析需求点。 测试计划阶段：测试组长就要根据SOW开始编写《测试计划》，其中包括人员，硬体资源，测试点，整合顺序，进度安排和风险识别等内容。 测试设计阶段：测试方案一般由对需求很熟的高资深的测试工程师设计，测试方案要求根据《SRS》上的每个需求点设计出包括需求点简介，测试思路和详细测试方法三部分的方案。《测试方案》编写完成后也需要进行评审。 测试方案阶段：主要是对测试用例和规程的设计。测试用例是根据《测试方案》来编写的，通过《测试方案》阶段，测试人员对整个系统需求有了详细的理解。这时开始编写用例才能保证用例的可执行和对需求的覆盖。测试用例需要包括测试项，用例级别，预置条件，操作步骤和预期结果。其中操作步骤和预期结果需要编写详细和明确。测试用例应该覆盖测试方案，而测试方案又覆盖了测试需求点，这样才能保证客户需求不遗漏。同样，测试用例也需要评审。 测试执行阶段：执行测试用例，及时提交有质量的Bug和测试日报，测试报告等相关文件 常用的9种自动化测试工具 1、RunnerMercury Interactive公司的WinRunner是一种企业级的功能测试工具，用于检测应用程式是否能够达到预期的功能及正常执行。通过自动录制、检测和回放使用者的应用操作，WinRunner能够有效地帮助测试人员对复杂的企业级应用的不同释出版进行测试，提高测试人员的工作效率和质量，确保跨平台的、复杂的企业级应用无故障释出及长期稳定执行。企业级应用可能包括web应用系统，ERP系统，CRM系统等等。这些系统在释出之前，升级之后都要经过测试，确保所有功能都能正常执行，没有任何错误。如何有效地测试不断升级更新且不同环境的应用系统，是每个公司都会面临的问题。 2、Rational Robot是业界最顶尖的功能测试工具，它甚至可以在测试人员学习高阶指令码技术之前帮助其进行成功的测试。它整合在测试人员的桌面IBM Rational Test Manager上，在这里测试人员可以计划、组织、执行、管理和报告所有测试活动，包括手动测试报告。这种测试和管理的双重功能是自动化测试的理想开始。 3、AdventNet QEngineAdventNet QEngine是一个应用广泛且独立于平台的自动化软体测试工具，可用于Web功能测试、web效能测试、Java应用功能测试、Java 、API测试、SOAP测试、回归测试和Java应用效能测试。支援对于使用HTML、JSP、ASP、.NET、PHP、JavaScript/VBScript、XML、SOAP、WSDL、e-merce、传统客户端/伺服器等开发的应用程式进行测试。此工具以Java开发，因此便于移植和提供多平台支援。 4、SilkTest 是业界领先的、用于对企业级应用进行功能测试的产品，可用于测试Web、Java或是传统的C/S结构。SilkTest提供了许多功能，使使用者能够高效率地进行软体自动化测试。这些功能包括：测试的计划和管理;直接的资料库访问及校验;灵活、强大的4Test指令码语言，内建的恢复系统***Recovery System***;以及具有使用同一套指令码进行跨平台、跨浏览器和技术进行测试的能力。 5、QA RunQARun的测试实现方式是通过滑鼠移动、键盘点选操作被测应用，即而得到相应的测试指令码，对该指令码可以进行编辑和除错。在记录的过程中可针对被测应用中所包含的功能点进行基线值的建立，换句话说就是在插入检查点的同时建立期望值。在这里检查点是目标系统的一个特殊方面在一特定点的期望状态。通常，检查点在QARun提示目标系统执行一系列事件之后被执行。检查点用于确定实际结果与期望结果是否相同。 6、Test Partner是一个自动化的功能测试工具，它专为测试基于微软、Java和Web技术的复杂应用而设计。它使测试人员和开发人员都可以使用可视的指令码编制和自动向导来生成可重复的测试，使用者可以呼叫VBA的所有功能，并进行任何水平层次和细节的测试。TestPartner的指令码开发采用通用的、分层的方式来进行。没有程式设计知识的测试人员也可以通过TestPartner的视觉化导航器来快速建立测试并执行。通过可视的导航器录制并回放测试，每一个测试都将被展示为树状结构，以清楚地显现测试通过应用的路径。 7、Holodeck 强大的故障植入软体测试工具Holodeck is an advanced fault-injection tool that gives you the power to attack an application while it monitors and logs everything your application does - every function call, registry entry, piece of data read or written. 8、Telelogic TAUTAU第二代包含三个最新的、最强大的技术用来加速大规模软体开发和测试：统一建模语言***UML***及它的许多最新修订版本中的特性，UML2.0;功能强大的测试语言TTCN-3和新的构造系统的方法：Model Driven Architecture***模型驱动构架***。这三个新的业界标准结合成TAU的已经过认可的软体开发平台，形成了一个系统，一个一流的稳定可靠的工具解决方案。TAU第二代是系统与软体开发解决方案的一个突破，它把业界从使用了太长时间的手工、易出错、以程式码为中心的方法中释放出来，自然而然地迈向下一步，一个更加视觉化、自动化及可靠的开发方法。 9、TelelogicTAU/Tester 是基于通用测试语言TTCN-3,用于自动化的系统和整合测试的强大工具。TAU/Tester以现代化的开发工具为基础，提供高层测试功能，支援整个测试生命周期，加速自动化测试。TAU/Tester可使使用者特别关注于测试的开发，因为TTCN-3语言是独立于开发语言或测试装置的，且是抽象和可移植的。
6. 接口测试流程是什么？
接口测试的测试流程 了解了接口测试是什么之后，怎么做接口测试呢？接口测试的流程其实和功能测试流程类似：接口测试计划-接口测试用例-接口测试执行-接口测试报告。测试用例设计的依赖对象主要是需求说明书和接口文档。 接口测试因其不是针对普通用户，而是针对的另外一个系统组件，所以不能直接测试，需要使用工具测试，比如服务端http接口测试，常用的工具有jmeter、postman、httpclient等。用工具测试，所以目标就是准备要测试数据测试脚本后直接执行即可， 在进行测试执行编写时，有如下的原则： 1.不同的接口参数覆盖不同的业务场景； 2.在后台构造合适的数据来满足接口的测试用例； 3.根据接口的返回值，断言其是否返回期望结果，并查看数据库验证； 4.测试用例涉及多个步骤的，应对涉及的步骤都验证； 5.删除测试过程中产生的结果，确保每个用例执行前都是一个清洁的环境。
7. 如何判断一个接口有必要做自动化
个人认为是定时跑时，能监控接口，当接口功能失常时，可以及时发现，即发现 Bug。因此，可以使用代码覆盖率来评估接口自动化的完整性，但更重要的是发现问题【摘要】 如何判断一个接口有必要做自动化【提问】 个人认为是定时跑时，能监控接口，当接口功能失常时，可以及时发现，即发现 Bug。因此，可以使用代码覆盖率来评估接口自动化的完整性，但更重要的是发现问题【回答】 如何判断一个http接口是有必要做自动化测试【提问】 1、是不是反复执行，是的话，自动化吧； 2、能不能或者好不好手工执行，否的话，自动化吧； 3、工作不饱满，有kpi要求，想自我提升，是的话，自动化吧。 说正经的，按优先级： 单元测试 - 接口测试 - UI测试 单元和接口，尽量100%；UI覆盖业务主流程即可。【回答】
8. 软件接口用什么自动化测试工具测
曾经有一段时间，人们习惯于在MS Excel里面编写单元测试用例，然后开发人员就按照单元测试用例一步一步的来实现用例。这通常是很耗时的漫长的过程，尤其是如果应用很大或者UI很复杂的话。 这一套单元测试的执行过程常常成为瓶颈，因为任何代码修改都会带来手工执行大量单元测试，以确保新的修改没有破坏原有功能。 如今是个快节奏时代，人们希望工作能够无需人工介入、自动化的快速完成。每个人都喜欢执行一个命令就能把工作搞定，而且在执行期间不需要人工介入。需要做的仅仅是检查一下最终的输出结果。 当这个世界正在迈向自动化时，自动化测试也不甘落后，不论是在功能测试方面还是UI测试方面。每天我们都能听说自动化测试方面涌现出的新软件。 本文提供了一些信息给那些想用Coded UI自动测试框架来进行应用界面自动化的.Net开发者。 什么是Coded UI? 最近我一直在寻找一个自动化的用户接口测试的解决方案。用户接口测试需要用户多次进行手工输入操作，这是一个既枯燥又费时的过程。因此，我想寻找一种更智能的自动化UI测试的方案，这种UI测试在不需要人工干预下，能够被保存，记录并提供支持 ，快速测试代码的改变。 Coded UI 采用用户接口来驱动应用的进行自动化测试。这些测试包括UI控制的功能性测试。他们使你可以验证整个应用的功能是否正确，其中包括了用户接口。Coded UI尤其适合用于用户接口中存在校验或者其它的登录方式的测试，比如网页。Coded UI也可以用于人工测试用例的自动化。 Coded UI 测试帮助用户测试应用程序的用户接口。这些测试允许用户验证应用程序的功能。Coded UI 多数时间用于帮助验证在UI层本身的有效逻辑。它能够验证值对用户接口的控制的正确性。 其它方案 市场有许多自动化用户接口的方案，比如HP的QuickTest Professional, IBM Rational Functional Tester. 其它著名的，易于使用的开源工具解决用户接口自动化问题的有Selenium，也能够记录测试，需要的时候回放。市场上还有来自Microsoft的也能不需要太多努力做同样的事。用Visual Studio Microsoft还有Coded UI的方案用于单元测试。 Coded UI适合在哪儿用? 大多数安装了Visual Studio的开发者都喜欢在Visual Studio的环境里进行单元测试，而不是使用第三方工具。由微软提供的Coded UI，在Visual Studio环境里可谓上手即用。在开发者的机器上无需另外安装任何东西。一旦你安装了Visual Studio的Premium版或者Ultimate版，你就同时也安装好了Coded UI。 Coded UI可用性 为了使用Coded UI，需要安装Visual Studio 2010/2012/2013的Premium版或者Ultimate版。 Coded UI 测试的组成 Coded UI 测试的组成容易理解。它可分成下列文件： UIMap.uitest 这个文件是UIMap类的XML表示。UIMap类包括视窗，控件，属性，方法，断言和动作。 UIMap.cs 对UIMap的自定义部分都存在这文件里。如果修改直接存在UIMap.designer.vb文件的话，那些修改都会在记录结束后丢失，因为这个文件重新创建了。 给每个在测应用程序中的每个模块创建一个独立的UIMap文件。 UIMap.Designer.cs 这是部分类表达各种类。这各种类是给多样的控件和他们的范围，属性，方法的类。 提示：不要直接修改 UIMap.Designer.cs。加入你这样做，这个修改会被覆盖掉。 CodedUITest.cs 这类表示的实际的CodeUI测试类，方法调用，和断言调用，所有的方法和断言默认都是从UIMap.Designer.cs文件调用的。这类有具有【codedUITest]属性TestClass和包含具有【TestMethod]属性的多种方法。 Coded UI的特性/好处 进行用户界面测试的同时进行校验. 生成VB.Net/C#代码. 测试用例可以被记录和重放. 集成了ALM Story 能够作为每日构建的一部分来运行. 根据需要进行高级扩展. 和Visual Studio集成在一起，所以无需单独购买许可. Coded UI对Web和Windows应用同样适用. 著名的Microsoft支持. 创建Coded UI测试 Coded UI测试可以用下列方式创建 使用MTM进行快速自动构建 从现有的记录(从手动测试中记录下来的操作)中创建Coded UI 在Coded UI Test Builder创建的底稿的基础上创建一个新的Coded UI测试. 自己写Coded UI. 这个白皮书的范围仅限于“在Coded UI Test Builder创建的底稿之上创建一个新的Coded UI测试”。 小贴士: 尽量使用Coded UI Test Builder。 Coded UI Test Builder 每一个Coded UI测试的生成都需要遵从下列步骤. 记录/停止/暂停 编辑记录下来的步骤 添加断言 生成代码 创建Coded UI 测试 创建新的Coded UI 项目 要开始使用Coded UI，首先我们需要创建一个测试项目，用来保存所有Coded UI测试。创建一个新的Coded UI项目包含下列步骤 打开Visual Studio 2012 选择 File > New > Project 选择需要的语言模板 (C# or VB.Net). 我们选择了C#. 选择Coded UI Project 输入一个名字 点击 OK 按钮 添加 Coded UI 测试 Visual Studio默认配置为创建Coded UI 测试使用 "Generate a new Coded UI Test from scratch using Coded UI Test Builder" 提示：在测试的应用程序中，当你创建UI控件时尽量使用有意义的名称，从而对于自动生成的控件显得更加有意义和可用。 一旦 Coded UI 测试工程创建完成，将会自动打开生成Coded UI 测试代码的对话框，请给出以下选项的设置。 记录操作，编辑UI地图或添加断言 使用一个已经存在的操作记录 默认情况下 选择记录操作,编辑UI地图或添加断言，无需做任何操作，然后点击 "ok" Coded UI Test Builder 选择了上述选项后，Coded UI Test Builder就会被打开，同时Visual Studio窗口被最小化。这意味着我们已经为记录操作做好了准备。 正如之前描述的，Coded UI Test Builder基于下列4个操作来做记录 Record Steps Update or Delete Steps Verify Results (Add Assertions) Generate Code 小贴士: 如果用户界面(UI)变化了，就重新记录测试方法或断言方法，或者重新记录一个既有测试方法中受影响的部分。 记录一个序列的操作. 记录一个操作主要需要下列几步. Start Recording, 通过选择Record按钮即可. Pause Recording, 用来处理记录过程中的其它操作，即Generate Code. Edit/Delete 操作, 以防错误的操作被记录。 Generate code为记录下来的操作创建编号。会给每一个记录下来的操作都生成编号。 Add Assertions 用来校验结果。 小贴士: 创建断言最好使用Coded UI Test Builder，因为它会在UIMap.Designer.cs文件中自动添加一个断言方法。 为记录动作做计划 任何事情的成功都取决于它计划得有多好。较好地计划最大限度保证了任务成功完成。这样总是比较好，在开始记录动作之前，我们计划好所有的所有要计划的步骤。 这里我们将要使用应用程序Windows计算器来记录步骤。我们要自动地加和减两个数字。在记录加和减两个数字的时候，下面的步骤将会用到。 。点击“开始记录”控件 。到开始，点击执行 。在执行窗口，输入”calc" 。停止记录，看记录的步骤 。删除错误的步骤（存在的话） 。产生代码；提供和动作相匹配的名字。比如，打开计算器。 提示：当你产生一个方法时候，使用一个有意义的方法的名字，代替默认名字。 有意义的名字帮助识别方法的木的。 。重新记录，提供第一个数字，暂停记录产生代码 。重新记录，提供操作（加或者减），暂停记录，产生代码 。重新记录，提供第二个数字，暂停记录，产生代码。 。加断言 提示： 产生你的测试作为一系列记录的方法 提示： 可以的时候，限制每个方法小于10个动作。这模块化的方法让UI改变时候容易替换方法。 我们已经看到了Coded UI可以使开发者的生活变得多么轻松，尤其是遇到每次都需要进行很多输入的复杂页面的时候。这时，测试用例只需要被记录一次，就可以按照需要执行任意多次。使用Coded UI比使用其它工具的好处是，它能自动适配Web页面和Windows窗口应用。Coded UI测试可以用Visual Studio 2010来运行，也可以用任何版本的VS来运行，它们的功能正变得越来越强大。无需多说，Coded UI是一个由技术领导者提供的强大工具，想要体验Coded UI测试的强大，我们应该开始在项目中使用它看看它能带来多少ROI，我确信Coded UI不会让你失望。
最新文章
热门文章
推荐阅读