自动化测试研究

本文共有3963字，快速阅读需要大约5分钟，赏味期限持久。随着软件测试技术的发展，人们已经从最初的纯粹的手工测试转变为手工与自动化测试技术相结合的测试方法。近年来，自动化测试越来越受到人们的重视，对于自动化测试的研究也越来越多。背景项目版本功能日趋增加，系统模块越来越多，功能趋于完善，此外系统经常更新，测试人员无法满足多模块的测试需求，测试压力日渐增大，尤其在做回归测试时，无法确保每次更新后系统都得到完整的回归测试。一、自动化测试基础知识什么是自动化测试1、把人为驱动的测试行为改成机器执行，通过设计的测试用例，由机器按照测试用例的执行步骤对其进行自动操作，输出结果，由测试人员进行比较。2、自动化测试往往通过一些测试工具或框架，编写自动化测试用例，来模拟手工测试。3、自动化测试能极大的节省人力、时间和硬件资源，提高测试效率。自动化测试的优势1、自动化测试工具可以根据需要，准备大量的测试数据。2、可以使用相关脚本技术准备大量的测试用例。3、测试结果有时需要再进行相应的数据处理。4、可以对大量数据或数据格式进行快速比对。自动化测试的劣势1、相对手工测试，自动化测试对测试人员的能力要求相对较高。2、自动化测试用例需要根据版本迭代进行更新，有一定维护成本。3、不能指望自动化测试去发现更多新的BUG，自动化测试能发现的缺陷远远比手工测试的少。4、自动化测试的产出价值往往在于长期的回归测试，短期内发挥的作用可能不明显。5、自动化测试不能提高测试的有效性，只能用于提高测试的效率。对于自动化测试的误解1、有了自动化测试不再需要手工测试。2、自动化测试对有些测试比如：本地化测试、用户体验测试、探索性测试，测试环境搭建方面并不能完全代替手工测试。3、自动化测试是对产品的运行，对测试点要有一定的手工测试基础，自动化测试和手动测试相辅相成。4、自动化测试并不仅指自动化运行测试产品，数据处理也是非常重要的一个环节。自动化测试前提条件及原则1、项目周期长，需求稳定近期未变动。2、前端开发无需多次修改的页面，无缺陷遗留的模块。3、自动化测试脚本可重复使用，比较频繁的回归测试（由于模块较多，暂时回归测试范围限定为模块主流程）。4、手工测试难以实现，需要在多平台上运行相同的测试案例及大量重复任务。5、前期自动化实施应避开复杂度极高的模块如何实施自动化测试1、获取信息和测试需求分析：总体把握系统架构和设计，分析出系统的测试需求。2、设计：设计测试用例，并且挑选出需要自动化实现的测试用例。3、实现：编写、调试和实现测试脚本。4、执行：执行脚本的过程，需要不断分析执行过程中的异常。5、测试结果分析：分析哪些是Bug，哪些是测试框架本身的问题。6、维护：自动化测试脚本维护是一个难以解决又必须要解决的问题。7、总结：在自动化测试过程中总结自动化实践的投入产出比。自动化测试的层次划分1、越往上，越接近QA、业务/最终用户，越往下，越接近开发。2、越往上，测试执行越慢；越往下，测试执行越快。3、越往上，测试成本越高（越耗时，失败时的信息越模糊，越难跟踪），越往下，测试成本越低。二、自动化测试工具和框架常见的自动化测试的工具自动化测试工具开发语言：Java、Python等基础测试工具（1）单元测试：junit（java）、unittest（python）（2）接口测试：httpclient（java）、restassure（java）、request（python）（3）UI测试：selenium webdriver（ web ）、appium（app）3、常见自动化测试工具（1）接口测试：Jmeter、soapui、postman（2）UI测试：katalon、Robotframework、Android自动化测试脚本技术1、线性脚本：录制、回放2、结构化脚本：含有控制脚本执行的指令，支持顺序、选择和循环3、共享脚本：可以被多个测试用例使用，脚本之间可以互相调用4、数据驱动脚本： 数据驱动脚本是将测试输入存储在独立的文件中，脚本中只存放控制信息5、关键字驱动脚本：关键字驱动脚本实际上是较重复的数据驱动技术的逻辑扩展 ，即测试用例的执行步骤（操作，操作对象，操作值）存放在文件中，直接执行自动化测试操作的基本原理1、接口自动化测试操作（1）模拟请求 url和报文，准备测试数据（）抓包获取接口信息，对接口的一个分析，有文档或无文档（2）模拟客户端发送 HTTP请求（get、post）（3）模拟客户端从服务器接收返回报文（4）验证返回结果是否符合预期2、UI自动化测试的操作（1）通过id、name、xpath、cssSelector等方法定位页面元素（findelement、findelements）（2）对定位到的页面元素执行相应的操作（ click、input等）（3）对操作后出现的结果和预期结果做一个比较（ assert ）自动化测试基础工具原理1、Selenium（解析前端代码与控制浏览器）自动化测试的PO模式1、在PO模式中抽象封装成一个BasePage类，该基类拥有一个只实现webdriver实例的属性2、每一个page都继承BasePage，通过driver来管理本page中元素，将page中的操作封装成一个个的方法TestCase依赖page类，实现相应的测试步骤自动化测试框架1、关键字驱动（1）将测试用例分成四个不同的部分。首先是测试步骤（Test Step），二是测试步骤中的对象（Test Object），三是测试对象执行的动作(Action)，四是测试对象需要的数据（Test Data）。（2）将数据与关键字结合来描述如何执行测试。也就是将测试用例脚本中的步骤提取出来，放在独立的数据文件中，变成简单编写的方式。这种方法具备数据驱动的优势，同时非编程人员也能建立测试。（3）关键字驱动的模式是建立在数据驱动手段之上，关键字驱动文件包含指令 (关键词)，而不只是数据。（4）这个测试框架可以通过很少的代码来产生大量的测试用例。同样的代码在用数据表来产生各个测试用例的同时被复用。2、数据驱动（1）从某个数据文件(例如Excel文件、Xml文件、Json文件、数据库等)中读取输入测试数据，然后通过变量传入编写的测试脚本中。（2）数据文件的读取、测试状态和所有测试步骤都被编写进测试脚本里；测试数据只包含在数据文件中，而不是脚本里，测试脚本只是一个“驱动”，或者说是一个传送数据的机制。（3）数据驱动的方法主要用于需要通过不同数据来保证测试覆盖率的场景，比如被测系统业务逻辑固定不变或变动较小，即测试用例步骤是固定的，但是所需要的测试数据是变化的情况，通常来说，数据都是保存在外面文件或数据库中，运行时自动获取。即测试框架中要支持数，据与脚本分离，一个测试脚本可以驱动执行多个相似测试场景。（4）这个框架意图减少需要执行所有测试用例所需要的总的测试脚本数，数据驱动需要很少的代码来产生大量的测试用例。三、自动化测试框架的选择与搭建1、技术方案Selenium（Webdriver） + Python（unittest）+ cx_Oracle + HTMLTestRunnerSelenium的WebDriver是一款开源工具。利用比较简洁的Python语言进行自动化测试，对于人员的学习成本来讲比较实用，学习时间短，有优势。Python自带的unittest单元测试框架可以很方便的实现自动化用例的设计和执行以及自动化用例套件的管理等任务。Python是纯面向对象的语言，后续也可以过渡到Java + Selenium进行更加丰富的自动化测试；此外，可以选择Jenkins作为持续集成服务器，配合Python+Selenium的方案进行自动化冒烟测试。此方案采用了Page Object设计模式，将页面、用例、数据三者分离。这样可以使测试案例可以更关注与业务而非界面细节，提高测试案例的可读性；降低代码冗余，增加方法的复用性。2、环境选择根据测试组自动化测试需求讨论结果，在uat、stage环境下使用自动化测试技术做回归测试。（执行前需确保该环境可正常使用）由于uat、stage环境频繁发版，影响自动化测试框架调试及脚本编写，申请一个稳定环境做调试及编写工作。3、自动化测试流程（1）选取模块（2）选择用例（主流程用例）（3）按页面编写操作方法（4）按用例编写用例流程脚本（5）按用例编写数据查询方法（6）执行用例（7）输出报告（后期扩展，增加执行日志和异常截图以便跟踪缺陷）。综上，当脚本内容编写结束并且业务需求和测试需求均无更改的时候，执行后两步操作即可。查看报告内容，如发现缺陷，需按用例内容重现缺陷并提交至禅道管理系统。4、后续维护（1）业务需求变更当业务需求变更时，应在执行用例时越过变更内容用例，变更内容上线后按需求变更内容对脚本及用例进行相应调整。调整结束，需再次执行确保用例稳定。（2）被测模块重构当被测模块重构完成时，需执行该模块自动化测试用例，查看是否正常执行，若无问题出现则不需调整，若出现问题需及时调试解决。（3）技术变更随着自动化测试框架的不断调优、扩展功能，基础模块和封装的页面等也会随之变化。进而，自动化测试需要定期执行，以保证调优、扩展后框架的稳定性，从而达到保障回归测试的正常进行。5、资源调配（1）环境：a、项目环境与线上项目近似，独立发版，版本内容相对稳定，数据库独立，不受其它环境影响。b、本机环境，win7&win10 Chrome 72 32bit。（2）用户：独立用户，权限尽量调高，以免由用户权限影响访问某些功能点，减少用例遗漏。（3）人员：建立自动化测试的组，理想状态下3-4个人员，测试开发、中高级自动化测试工程师、初级自动化工程师。（4）培训：对初级自动化工程师培训，设计的框架以及封装的驱动等。四、自动化测试分阶段实现1、搭建基础版框架，完成一个模块的自动化测试demo采用Page Object设计模式，对页面元素，用例流程，数据进行封装隔离，在通用模块或基础模块中对webdriver进行二次封装，自动生成测试报告以便分析自动化测试执行结果。2、按基础版框架，扩展测试范围选取适合做自动化测试的功能模块，按基础框架思路编写脚本、用例等，然后对框架做扩展，实现数据驱动、定时执行测试，发送报告邮件等便于使用的非核心功能。3、覆盖大多数模块的回归测试根据人员等资源的协调情况，将自动化测试用例扩展至覆盖大部分模块回归测试的程度。由执行自动化测试完成回归测试，以达到提高回归测试的效率，降低回归测试人力要求的目的。小结自动化测试技术在现代测试技术中是有一定优势的，但是自动化测试不是在任何情况下都必须的，适当的、或者是有效成本投入，需要我们在合适的时机引入自动化测试，使手工测试和自动化测试实现完美结合。

1、自动化的软件测试与手工的软件测试过程一样自动化测试所需要的技巧与手工测试所需要的技巧是不一样的。通常，你的项目经理会被那些测试工具销售们迷惑，认为自动化的软件测试就是简单地按一个录制的按钮，产生测试脚本。而事实上并没有那么简单。区分自动化测试所需要的技巧与手工测试所需要的技巧是非常重要的。最重要的是，自动化测试工程师需要掌握软件开发技巧，没有接受任何培训的手工测试人员，或者没有编程背景的手工测试人员，在实施自动化测试时会碰到很多困难。2、自动化测试一定会马上大量减少测试人员数量自动化测试不会马上大量减少测试人员数量。因为开展自动化测试初期需要投入一定的人力进行自动化测试脚本开发，并逐渐将自动化测试脚本用于日常的测试中，逐步减少手工测试人员从事重复劳动的时间和人数。为了缩短自动化测试脚本的开发时间，可以考虑将自动化测试脚本的开发工作借助外包的力量来早日实现大规模的自动化测试。3、测试自动化就是录制和回放仅仅录制得到的不是有效的自动化脚本。很多项目经理仍然把测试自动化等同于使用录制回放工具。而事实上，录制得到的脚本通常是不可重用的脚本，脚本中充满了硬编码的值，这些值应该被参数化，否则脚本仅仅适用于一个测试情况，脚本还应该加入条件判断、循环等结构，以便增强测试脚本的灵活性。4、自动化测试找不到bug自动化测试不直接找bug，而是通过解放有经验的测试工程师的生产力，让其从重复的回归测试中解放出来，从事新的测试方法和测试手段的研究。通过自动化测试解放出测试人员的时间和精力来间接地找到更多、更深层次的新bug，将产品质量再提高一个档次。5、自动化测试工具是“万能”的很多人一听到自动化测试，就认为自动化测试工具可以完成一切测试工作，从测试计划到测试执行再到测试结果分析，都不需要任何人工干预。显然，这是一种理想状态，现实中还没有哪个测试工具有这个能力，并且将来也不会有。在现实中有关的测试设计、测试案例，以及一些关键的测试任务还是需要人工参与的，即自动化测试是对手工测试的辅助和补充，它永远也不可能完全取代手工测试。6、自动化测试工具容易使用对于这一点，很多测试工程师有同样的错误观点，认为测试工具可以简单地通过捕获（录制）客户端操作生成脚本，且脚本不加编辑就可用于回放使用。事实上，自动化测试不是那么简单的，捕获的操作是否正确，以及脚本编辑是否合理都会影响测试结果。因此，自动化测试需要更多的技能，也需要更多的培训。7、自动化能提供百分百的测试覆盖率并非所有内容都可以被自动化地测试到。不可能覆盖所有可能的输入，所有可能的组合和路径。自动化测试可以增加测试的广度和深度，但是仍然无法达到100%的测试覆盖率，因为没有足够的时间或资源。8、忘记了测试的最终目标：找到BUG通常在自动化测试过程中，我们都忙着搭建自动化框架和编写测试脚本，但是我们往往忘记了测试的本来目的：找bug。项目经理可能雇佣了最好的自动化开发人员来搭建框架，使用了最新最好的自动化开发技术，创建了成千上万的自动化测试脚本。但是如果BUG仍然被遗漏了，那些本该被自动化测试脚本捕捉到的BUG，结果没有被捕捉到，那么你的自动化测试仍然会被认为是失败的。9、所有测试用例都可以自动化不是所有的测试用例和测试步骤都可以转化为自动化测试。在自动化测试投入较多的行业，领先企业的自动化测试率有的能达到80%左右，但仍有20%左右的测试用例需要手工来进行。在国外，通常从开发第一版测试用例时，就同步进行自动化测试脚本的开发，所以自动化测试率普遍比中国企业高。10、只有性能测试才需要自动化自动化测试不光进行性能测试，更被大量应用于功能测试验证，在国外超过半数的自动化测试脚本都是用于功能验证测试的。11、测试工具可适用于所有的测试在很多情况下，需要利用多种测试工具或者开发自动化测试框架才能达到自动化测试的目的。商业和开源的测试工具能够用来进行自动化测试，但是我们需要根据自身产品的特点，开发自动化测试框架，在框架中提供常用的测试用例，加快测试速度，达到测试用例复用。12、自动化测试能发现大量新缺陷发现更多的新缺陷应该是手工测试的主要目的，不能期望自动化测试去发现更多新缺陷。事实上，自动化测试主要用于发现原来的缺陷。自动化测试用于回归测试，而大量的新业务测试更多地还是依赖手工测试。

奋斗De奶爸，混迹IT圈十余载，产品管理、解决方案专家，有趣、有料、有温度，坐标北京。今日栏目：干货分享这是奶爸第97篇推文工作这么多年，测试是我没有太多研究的一个专业，最近随着devops的流行，自动化测试逐渐热了起来。我的一个客官，希望能看到有关测试的文章，这个确实不是我的强项，找人推荐一篇自动化测试的科普文，希望对想往自动化测试方向发展的朋友有些帮助。本文版权，归原作者所有什么是自动化测？　　做测试好几年了，真正学习和实践自动化测试一年，自我感觉这一个年中收获许多。一直想动笔写一篇文章分享自动化测试实践中的一些经验。终于决定花点时间来做这件事儿。　　首先理清自动化测试的概念，广义上来讲，自动化包括一切通过工具（程序）的方式来代替或辅助手工测试的行为都可以看做自动化，包括性能测试工具（loadrunner、jmeter）,或自己所写的一段程序，用于生成1到100个测试数据。狭义上来讲，通工具记录或编写脚本的方式模拟手工测试的过程，通过回放或运行脚本来执行测试用例，从而代替人工对系统的功能进行验证。　　当然，我们更普遍的认识把“自动化测试”看做“ 基于产品或项目UI层的自动化测试”。分层的自动化测试　　这个概念最近曝光度比较高，传统的自动化测试更关注的产品UI层的自动化测试，而分层的自动化测试倡导产品的不同阶段（层次）都需要自动化测试。　　相信测试同学对上面的金字塔并不陌生，这不就是对产品开发不同阶段所对应的测试么！我们需要规范的来做单元测试同样需要相应的单元测试框架，如java的Junit、testNG，C#的NUnit ，python 的unittest、pytest 等，几乎所有的主流语言，都会有其对应的单元测试框架。　　集成、接口测试对于不少测试新手来说不太容易理解，单元测试关注代码的实现逻辑，例如一个if 分支或一个for循环的实现；那么集成、接口测试关注的一是个函数、类（方法）所提供的接口是否可靠。例如，我定义一个add()函数用于计算两个参数的结果并返回，那么我需要调用add()并传参，并比较返回值是否两个参数相加。当然，接口测试也可以是url的形式进行传递。例如，我们通过get方式向服务器发送请求，那么我们发送的内容做为URL的一部分传递到服务器端。但比如 Web service 技术对外提供的一个公共接口，需要通过soapUI 等工具对其进行测试。 　　UI层的自动化测试，这个大家应该再熟悉不过了，大部分测试人员的大部分工作都是对UI层的功能进行测试。例如，我们不断重复的对一个表单提交，结果查询等功能进行测试，我们可以通过相应的自动化测试工具来模拟这些操作，从而解放重复的劳动。UI层的自动化测试工具非常多，比较主流的是QTP，Robot Framework、watir、selenium 等。　　为什么要画成一个金字塔形，则不是长方形 或倒三角形呢？ 这是为了表示不同阶段所投入自动化测试的比例。如果一个产品从没有做单元测试与接口测试，只做UI层的自动化测试是不科学的，从而很难从本质上保证产品的质量。如果你妄图实现全面的UI层的自动化测试，那更是一个劳民伤财的举动，投入了大量人力时间，最终获得的收益可能会远远低于所支付的成本。因为越往上层，其维护成本越高。尤其是UI层的元素会时常的发生改变。所以，我们应该把更多的自动化测试放在单元测试与接口测试阶段进行。　　既然UI层的自动化测试这么劳民伤财，那我们只做单元测试与接口测试好了。NO! 因为不管什么样的产品，最终呈现给用户的是UI层。所以，测试人员应该更多的精力放在UI层。那么也正是因为测试人员在UI层投入大量的精力，所以，我们有必要通过自动化的方式帮助我们“部分解放”重复的劳动。　　在自动化测试中最怕的是变化，因为变化的直接结果就是导致测试用例的运行失败，那么就需要对自动化脚本进行维护；如何控制失败，降低维护成本对自化的成败至关重要。反过来讲，一份永远都运行成功的自动化测试用例是没有价值。 　　至于在金字塔中三种测试的比例要根据实际的项目需求来划分。在《google 测试之道》一书，对于google产品，70%的投入为单元测试，20%为集成、接口测试，10% 为UI层的自动化测试。我为什么要做自动化测试？　　根据51testing的《中国软件测试从业人员调查报告》，手工测试占到的89% ，相对开发来说，测试的门槛底，薪资普遍较底，所要求的知识面虽然有一定广度，但缺乏深度。这是测试的普遍现状。　　正因为手功测试人门槛不高，使大量的毕业生，甚至是非专业人员涌入这个行业。从而增加了这个行业的激烈竞争。对于工作几年扔处于手工测试的人员来说都会有强列的危机感。由于工作的技术含量不高，薪资的涨幅遇到瓶颈，另一方面受到新进入者的威胁，同样的工作公司花5K招来的人就可以做，那么就不会花8K 的招。　　好吧，这个问题不应该出现讨论技术的话题中，但他的确是大多测试人员不得不面对的一个问题。所以，从测试人员自身的发展来说，我其实非常需要通过自动化技术来增加自己有竞争力。当然，做到一定年限测试人员会选择转管理或其它岗位，这又是另一个话题了。　　从测试行业的发展来说，国内产品由于产品特点，世界级的产品不多，技术含量相对不高，质量要求相对要求不高，外包国外项目，测试人力成本低廉，所以需要大量的手工测试人员。　　所以，在不远的未来，我认为纯的工手测试人员的需求是递减，公司更需要更高技术能力的测试。质量需要测试，测试行为永远不会消失，但纯的手工测试人员是否消失是有可能的。　　好吧，你可以说测试多朝阳的行业，我纯属在危言耸听。不管未来如何，我们都需要提升自身的技能对吧！什么项目适合做自动化测试？　　假如你已经决定要学习自动化测试了，如何学习是要面临的下一个问题？这个问题以被测试产品为出发点进行分析，假如你所学的技术不能得到应用（验证），将会使你的学习过程寸步难行。　　首先考考虑产品是否适合做自动化测试。这方法比较普遍的共识是从三个方面进行权衡。　　软件需求变动不频繁　　测试脚本的稳定性决定了自动化测试的维护成本。如果软件需求变动过于频繁，测试人员需要根据变动的需求来更新测试用例以及相关的测试脚本，而脚本的维护本身就是一个代码开发的过程，需要修改、调试，必要的时候还要修改自动化测试的框架，如果所花费的成本不低于利用其节省的测试成本，那么自动化测试便是失败的。　　项目中的某些模块相对稳定，而某些模块需求变动性很大。我们便可对相对稳定的模块进行自动化测试，而变动较大的仍是用手工测试。　　项目周期较长由于自动化测试需求的确定、自动化测试框架的设计、测试脚本的编写与调试均需要相当长的时间来完成。这样的过程本身就是一个测试软件的开发过程，需要较长的时间来完成。如果项目的周期比较短，没有足够的时间去支持这样一个过程，那么自动化测试便成为笑谈。　　自动化测试脚本可重复使用　　自动化测试脚本的重复使用要从三个方面来考量，一方面所测试的项目之间是否很大的差异性（如C/S系统和B/S系统的差异）；所选择的测试工具是否适应这种差异；最后，测试人员是否有能力开发出适应这种差异的自动化测试框架。选择什么工具进行自动化测试　　假如你已经确认了XX 项目适合做自动化测试，那么接下来你要做的就是选测试工具了。　　首先要先确认你所测试的产品是桌面程序（C/S）还是web应用（B/S）。　　桌面程序的工具有：QTP、 AutoRunner　　web应用的工具有：QTP、AutoRunner、Robot Framework、watir、selenium　　由于B/S架构的诸多优势，早几年前大量C/S架构的应用转为B/S结构。从而也推动了web开发与测试技术的发展。假如，被测试有产品是C/S架构的，那么推荐QTP ，QTP在UI自动化测试领域占到了一半的试用率。所以，足以说明QTP在自动化领域强大，易用性等。学习主流的工具也可以使你获得更多的机会。市面上关于QTP的书籍也非常丰富。当然，要想学好QTP ，你必须要掌握VBS脚本语言。　　如果，被测产品是B/S 结构，那么推荐selenium ，为什么不是QTP 或其它工具？因为selenium 对B/S应用支持很好，更重要的一点，它支持多语言的开发，真正的试用selenium ，你所要掌握的不仅仅是一个工具而已，你还需要学习一门语言。我为什么要选择selenium？还要学一门语言，这无疑增加了我的学习成本。增加成本的同时，也增加的你的竞争力，而且，在这个过程中你不单单只是学会了一个自动化工具而已，你完全可以使用所学的语言去做更多的事情。　　好吧！假如你决定试用selenium 了之后，你又面临了一个新的问题，选择一门语言。selenium 是支持java、python、ruby、php、C#、JavaScript 。　　从语言易学性来讲，首选ruby ，python　　从语言应用广度来讲，首选java、C#、php、　　从语言相关测试技术成度（及 资料）来讲：ruby ,python ,java　　或者你可以考虑整个技术团队主流用什么语言，然后选择相应的语言。selenium 用前须知　　OK！经过上的过程，我相信你一定做出的相应的选择，如果你选择的是selenium 工具，那么接着往下阅读。首选你在开始selenium之前，需要花一到两个月时间去学一门语言，这里是根据没有语言基础的同学而定的。我推荐ruby ,python ,java 任意一门语言来进行学习。　　当然，已经如果有很好的语言基础略过这个环节，或者你的丰富的java编程能力，那么学习python 可能只需要几天时间或更短。　　假如，你已经搞定了一门语言的基础，接下来你需要先了解selenium ，selenium 并不是单纯的一个工具，他是一组工具的集合，而且，他还有1.0与2.0之分，当然3.0也已经到来。　　selenium 也不是简单一个工具，而是由几个工具组成，每个工具都有其特点和应用场景。selenium IDE　　selenium IDE 是嵌入到Firefox浏览器中的一个插件，实现简单的浏览器操作的录制与回放功能。那么什么情况下用到它呢？　　快速的创建bug重现脚本，在测试人员的测试过程中，发现了bug之后可以通过IDE将重现的步骤录制下来，以帮助开发人员更容易的重现bug。　　IDE录制的脚本可以可以转换成多种语言，从而帮助我们快速的开发脚本，关于这个功能后而用到时再详细介绍。selenium Grid　　Selenium Grid是一种自动化的测试辅助工具，Grid通过利用现有的计算机基础设施，能加快Web-app的功能测试。利用Grid，可以很方便地同时在多台机器上和异构环境中并行运行多个测试事例。其特点为：· 并行执行· 通过一个主机统一控制用例在不同环境、不同浏览器下运行。· 灵活添加变动测试机selenium RC　　selenium RC 是selenium 家族的核心工具，selenium RC 支持多种不同的语言编写自动化测试脚本，通过selenium RC 的服务器作为代理服务器去访问应用从而达到测试的目的。　　selenium RC 使用分Client Libraries和selenium Server，Client Libraries库主要主要用于编写测试脚本，用来控制selenium Server的库。　　Selenium Server负责控制浏览器行为，总的来说，Selenium Server主要包括3个部分：Launcher、Http Proxy、Core。其中Selenium Core是被Selenium Server嵌入到浏览器页面中的。其实Selenium Core就是一堆JS函数的集合，就是通过这些JS函数，我们才可以实现用程序对浏览器进行操作。Launcher用于启动浏览器，把selnium Core加载到浏览器页面当中，并把浏览器的代理设置为Selenium Server 的Http Proxy。selenium 2.0　　搞清了selenium 1.0 的家族关系，selenium 2.0 是把WebDriver 加入到了这个家族中；简单用公式表示为：　　selenium 2.0 = selenium 1.0 + WebDriver 　　需要强调的是，在selenium 2.0 中主推的是WebDriver ，WebDriver 是selenium RC 的替代品，因为 selenium 为了向下兼容性，所以selenium RC 并没有彻底抛弃，如果你使用selenium开发一个新自动化测试项目，强列推荐使用WebDriver 。那么selenium RC 与webdriver 主要有什么区别呢？　　selenium RC 在浏览器中运行JavaScript应用，使用浏览器内置的JavaScript 翻译器来翻译和执行selenese命令（selenese 是selenium命令集合）。　　WebDriver通过原生浏览器支持或者浏览器扩展直接控制浏览器。WebDriver针对各个浏览器而开发，取代了嵌入到被测Web应用中的JavaScript。与浏览器的紧密集成支持创建更高级的测试，避免了JavaScript安全模型导致的限制。除了来自浏览器厂商的支持，WebDriver还利用操作系统级的调用模拟用户输入。　　如果是新项目直接学习webdriver 就OK了，RC是过时技术。selenium学习路线　　配置你的测试环境，真对你所学习语言，来配置你相应的selenium 测试环境。selenium 好比定义的语义---“问好”，假如你使用的是中文，为了表术问好，你的写法是“你好”，假如你使用的是英语，你的写法是“hello”。 所以，同样有语义在不同的语言下会有不同的写法（语法）。 　　接着你需要熟悉webdriver API ，API就是selenium 所定义一方法，用于定位，操作页面上的各种元素。　　先学习元素的定位，selenium 提供了id、name、class name、 tag name、link text、partial link text、 xpath、css、等定位方法。xpath和css 功能强大语法稍微复杂，在这其间你可能还需要了解更多的前端知识。xml ,javascript 等。　　定位元素的目的是为了操作元素，接就要学习各种元素有操作，输入框，下拉框，按钮点击，文件上传、下载，分页，对话框，警告框...等等。　　经过一段时间的学习，你可以游刃有余的模拟手工测试来操作页面上的各种元素了。接着你需要做的就是把这些“用例”组织起来，统一来跑。　　那么你需要做的就是学习并使用单元测试框架，单元测试框架本身就解决了用例的组织与运行。　　当你写了一些“测试用例” 之后，你会发现用例中有大量重复的操作，能不能写到一个单独的文件中，需要的时候调用这些操作？当然可以，运用你的编程能力来实现这一点将非常简单。然后，你又发现每个用例中都有一些数据，这些数据也是一样的，但如果变化了修改起来非常麻烦，你也可以把他写到一个单独的文件中进行读取。　　接着你又遇到了新的疑问，我写的脚本（用例）都是流水式的，我怎么知道用例运行失败还是成功。那么就需要在脚本中加一些验证与断言。　　接着你又有了更多的想法，单元测试框架的log太简陋了，能不能生成一张漂亮的测试报告出来。我能不能定时的来跑这个脚本。能不能把每一次跑脚本的测试结果直接发到我的邮箱。能不能......　　为解决这些问题，你不得不学习更多的编程技术，然后你的“测试结构”会功能越来越强大，越来越灵活。产生了一定的通用性和移植性。一个有模有样的自动化测试框架诞生了。 　　假如，有一天你不再做UI的自动化测试了，你会发现你去做单元测试 或接口测试基本没什么难度。开发个测试工具之类的也不在话下，感谢selenium 吧！顺便也感谢一下我吧！2、IT职场：升值、加薪、与领导相处、跳槽面试等经验分享，每周三推送3、大话IT人：程序猿、产品汪、运营喵的业余生活，每周五推送4、成长日记：奶爸的一点小感悟、小灵感、亦或是读书笔记、工作总结，每周日推送5、奶爸知不道：你问我答，后台给我留言，我会根据情况，通过推文的方式回答你的问题，不定期推送奶爸的小客栈出品【公众号】naiba2000【新浪微博】@奋斗e奶爸

很多团队都倾向于认为自动化是一种加速软件交付的方式，因为这是团队内部经常能够感知到的瓶颈。但是，如果他们将自己的开发实践过程当作一个整体来深入研究的话，那么他们会得到更好的结果。一、如何预防 BUGS？测试，尤其是 UI 层面的自动化测试，通常会被安排在软件交付周期的最末端，通常会试图发现一些可能进入生产环境并给最终用户造成不良影响的 bug（这些 bug 就如同细菌一般）。在这种情况下进行的测试可以探测出 bug 的症状，开发人员进行的修复就是治疗。这就如同我们在等待我们的系统生病并为此采取一些措施。这种方法对于团队来说是有一定的效果，但是，现在的工作环境迫使我们用更少的人做更多的事并且要比以往更快地完成任务。因此，这种方法并不能长期可持续地运转。这时基于预防的方法而非治疗的方法就横空出世了。通过对如何构建系统作出调整，我们就可以在故障发生之前探测出问题，或者更好的是，让他们从一开始就不那么容易产生 bug(这就是所谓的“预防”)。这就意味着我们在 bug 产生前就预防它的发生而非试图在 bug 产生后再治疗它。古语有云：预防胜于治疗！二、我们的测试自动化之旅在我刚开始加入移动团队（该团队负责创建并管理公司的点播产品）时，我们所有的测试都是手工执行的，平均每年我们只在每个平台上发布 2 到 3 次。我们知道如果想要加快速度，最明显的瓶颈就是测试。在没有发现新 bug 的情况下，每个回归测试周期要花费将近两周的时间。如果发现了新 bug，那么开发团队需要时间理解并确认 bug，确定一个修复方案，然后再应用这个方案。这会导致已经执行的任何测试都变得无效，因此需要重新启动测试过程，最终导致测试周期花费两倍以上的时间。因此，我们开始着眼于将更多的 UI 测试进行自动化处理。我们总是从小的方面开始改变看看这样的尝试能否将我们引入我们想要的正确的方向上，并且我们只选择对新功能进行自动化测试。这种尝试一旦被证实是有效的，我们就会将自动化测试引入到现存系统的其他领域或者已知的问题领域。我们组织 3 个朋友作为一个团队来理解我们想要构建什么，以及该特性的关键接受标准应该是什么。这为我们提供了一个起点，让我们了解如何分解该特性以及哪些用户场景需要自动化。在此基础上，我们确定了可以用来自动化测试的工具(Calabash 和 Appium)，并在实际环境中应用它们。对我们来说，这是在真实的手机上进行测试，而不是模拟器，为此我们建立了自己的设备测试场以更好地利用我们的移动设备，同时也允许它扩大规模以期能够在整个组织中得到应用。三、自动化测试带给我们的好处起初，自动化给我们带来了很大的帮助：通过自动化我们可以快速可靠地运行简单场景的测试用例并迅速得到我们想要的反馈结果。但是随着时间的推移，在最初的一批bug 被捕获之后，自动化测试很难再发现新的 bug 了，除非我们手动地修改自动化用例代码。同时，我们也注意到由于某些场景我们无法自动化导致一些 bug 依然存在于系统之中：比如，任何与可用性相关的功能都不得不进行手工测试。因此，我们最终采取了一种混合的解决方案---自动化用来快速跑一些关键场景，让团队知道自动化测试没有明显地破坏任何东西，以及如果合适的话对任何新功能进行的探索性测试也可以自动化处理。因此，尝试自动化测试的过程是曲折的，我们在尝试测试时很容易出错，又或者手工测试花费的时间太长。带给我们自动化之旅的一个意料之外的好处就是我们开始更快地发布产品，自动化让我们更加专注于我们正在尝试完成的工作事项。这就让我们可以将每一个新特性新功能拆分成更加细小的分支（可以独立运行的分支）并将这些分支进行自动化测试。这使得我们可以更快地将各个分支发布到生产环境中并从最终用户处得到实时的反馈。起初这一好处并不明显，因为我们仍在尝试着识别自动化场景。只有在事后，团队才能看到这是他们无意中所做的事情带来的价值。简单地说，我们开始将工作分解为一小批最终用户价值。四、研究我们的开发模式我们开始意识到 UI 自动化测试并没有真正带给我们想要的回报。正因为如此，我们开始研究开发过程中的其他领域，看看是否可以做出些许改进。但作为一个团队，我们的问题之一是，我们太过接近流程，以至于无法客观地看到哪些是有效的，哪些是无效的。为了克服这个问题，我们请来了一位敏捷教练来帮助我们的团队。事实上，我们引入了两位教练：一个是帮助团队理解他们正在使用的流程，另一个是帮助我们更好地理解我们实际上是如何构建我们的系统的。敏捷教练都来自于团队外部，因而他们可以质疑我们系统的任一部分，而不用担心冒犯任何人。他们会问一些简单的问题，让我们了解我们工作方法背后的原因，并将我们从“我们一直都是这样做的”循环中解脱出来。例如，用于管理我们工作的 stand upboard 通常有 backlog、next、dev、wait - For -test、in test and done 等列，但是我们从来没有想过要问为什么我们有 next 和 wait - For -test 列。我们的教练能够提供帮助的是：我们为什么要将软件开发工作分解成这些小项，为什么开发和测试被视为两个不同的活动。教练的方法并不是简单地改变我们的开发过程，但他们能帮助我们明白问题的根源在哪(未发布的功能卡放在任务看板的 next 和 wait-for-test 列)，让团队看到通过消除开发和测试列（next 和 wait-for-test），取而代之的是一个简单的正在进行（in-progress）的列，很多工作依然可以顺利进行。您可以在我的文章 In test colum 中找到更多关于使用这种方法的好处.五、我们学到了什么我们发现的最大问题是：就敏捷开发实践而言，我们的团队中存在“形式主义”。仅仅因为我们有 stanps（站会），以小团队的形式工作，并在 sprint 结束时发布东西，但并不意味着我们实际上是敏捷的。这只是意味着我们有一些仪式，让我们看起来像“敏捷”。事实证明，并不是每个人都很清楚我们为什么要这么做，甚至不清楚我们这样做的好处是什么。我们所做的第一件事就是澄清什么是敏捷：它更多的是基于客观反馈的可持续软件交付过程，而不是试图尽可能快地发布你所能发布的任何东西并期望最好的结果。我们通过读书俱乐部促进团队讨论来实现团队内部对于“敏捷”一词达成一致的理解。这有助于团队成员更好地掌握敏捷实践背后的原则，并在他们的工作中做出更好的决策。我们还开始研究我们实际上是如何在代码级别构建系统的，并试图将开发人员在如何提交代码、提交的频率和提交的大小这些内容可视化。这并不是试图让开发人员难堪，而是帮助他们理解作为一个团队，他们是如何影响代码库的，并试图鼓励开发人员养成更高效的习惯；比如对于较小的、有重点的任务进行提交，而不是在一天结束时的一次性提交大量的代码。如果他们确实做了大量的提交，那也可以，但是要让其他开发人员知道他们为什么这样做，来促进团队成员间相互学习。我们对团队最大的改变之一是鼓励结对编程，因此没有一个开发人员单独开发一个特性。这加快了代码评审的速度，但他们也不太可能相互推卸责任。比起在某些项目中仅由资深成员来审查代码而言，结对编程还有助于更快地提高我们团队中较年轻成员的技能和知识，使他们能快速地提高生产力。六、为了拥有更加高效健康的开发模式，我的一些建议在团队工作中，需要在这个团队中确定一个高效、健康的开发流程。一个行之有效的方法是建立一个团队视频俱乐部。这允许成员从日常活动中抽出一些时间来学习构建软件的新工具或新方法。在每次会议结束时，团队讨论都由会议负责人(项目经理、技术负责人或将想法带给团队的人)推动，来探索如何使用这些概念来帮助团队尝试新事物。然后选择一个概念，并对结果应该是什么有一个清晰的想法。我们以更好的单元测试为例，单元测试对团队意味着什么?更好的单元测试会给团队带来什么？一旦你有了这些答案，你就可以想出多种方法来达到这个目的，这样你就可以选择一个可以让你快速而客观地见证结果的方法。你需要弄清楚，你所使用的新过程或新技术是否真的帮助你在规定的时间内实现了你的目标。如果是这样，那就太好了。如果没有，你需要停止吗？做更多调整吗？您还需要决定谁将实际进行这一尝试，以及他们将如何与团队的其他成员进行沟通。记住，如果你想让任何新流程或想法在团队中站稳脚跟，那么团队中每个人都需要参与其中；否则，遇到的第一个困难就是，这个想法将停止或缓慢执行，因为只有参与尝试的人才能从中有所收获。

转载本文需注明出处：微信公众号EAWorld，违者必究。Devops作为技术中台的重要组成部分之一，其下“自动化测试”功能也是不可或缺的一环，如何结合DevOps自身提供的自动化测试功能，做好DevOps的接口自动化呢？首先要先了解DevOps为自动化测试提供了哪些功能，如何使用该功能进行自动化测试，以及如何设计测试框架等等，本文将会为大家一一解答。DevOps作为技术中台的“效率&精益“平台，集成了多方测试工具供使用。目前集成的自动化测试工具有：robot-framework 、Jmeter。目录：1.为什么采用RobotFramework?2.什么是RobotFramework?3.RF如何做接口测试？4.如何在DevOps中执行rf脚本并生成测试报告一、为什么采用RobotFramework?针对接口、web网页、app自动化测试的工具有很多：selenium、jmeter、soapui、robotFramework、postman等，如何选择适合自己的自动化测试工具？此时便要看具体需求和业务。应需求：为DevOps产品做自动化接口测试，那DevOps自身集成了jmeter和rf框架，且采用jmeter或者rf工具，能使自动化测试过程在DevOps中“数据可视化”，每次执行后的各项测试数据指标（包括测试结果、测试报告、成功率、失败率等）直接在DevOps中进行展示、更是省略了自行配置jenkins进行自动化执行部署等操作，对于管理人员以及测试人员而言，均有受益。又考虑到测试人员技术水平，相对而言，rf简单易上手，所以rf突出重围，成为此次自动化工具角逐的“冠首”。二、什么是RobotFramework?Robot Framework是一款python编写的功能自动化测试框架，可导入各第三方测试库（例如：Selenium2Library、RequestsLibrary、DatabaseLibrary、HttpLibrary.HTTP），通过关键字进行web或接口自动化测试。RF特性：1、rf测试用例支持文本文件保存，使用制表符分隔数据，可方便使用任何文本编辑器，或者excel编辑测试用例，也可使用HTML格式创建用例；2、测试用例支持变量使用，可使用IF、ELSE以及For循环语句；3、支持关键字驱动、数据驱动和行为驱动；4、利用已有关键字，测试人员可进一步“封装”，形成更高级别的行为；5、测试人员可使用Python编写自己所需的关键字；6、测试报告和日志为HTML格式，便于阅读；7、使用简单，更好理解以及上手等三、RF如何做接口测试？1、RF脚本编辑工具：可通过RED工具（该工具百度文献参考多，这里不做介绍）或者eclipse来编辑Robot FrameWork测试用例；个人用的eclipse，更方便进行关键字的查看，具体可参考文献：https://www.cnblogs.com/Simple-Small/p/9229397.html。2、准备好rf环境【python环境、robotframework安装、JDK1.8+Eclipse+RED插件】；3、安装第三方库，提供接口测试的关键字：RequestsLibrary（在rf中，python语言的接口测试库名称为RequestsLibrary）、DatabaseLibrary、HttpLibrary.HTTP等；若导入httplibrary库出错，可参考以下文献进行调试：4、在robot脚本中引入所需各库：5、认识RequestLibrary以及DatabaseLibrary中的关键字。掌握各关键字含义以及用法，是利用RF做自动化测试的核心。在.robot文件中，鼠标悬浮在关键字上，会显示该关键字用法，或者按住CTRL键，鼠标点击可进入到py文件中，直接查看该关键字的实现和描述，RF接口测试主要用到以下红框关键字，还有其他语法例如FOR循环、json数据格式转换等需要掌握。RF基本语法以及关键字用法此处不做详细解析，对此有兴趣者可通过各学习网站搜索关键字：robotframework，查看对应视频学习即可；接下来主要以笔者实践rf接口自动化框架的二次封装为主线展开（为笔者个人实践，多处还有待后期改善，不完善处请谅解）。6、下图为笔者根据使用场景和需求，设计的RF接口自动化的基本框架：这里将rf框架封装为5层：工具类层、关键字层、基础数据层、测试数据层和用例层。工具类层：若rf已存的关键字不满足需求，可自行编写py函数实现；关键字层：将复用率高的代码块进行提取封装，成为新关键字。例如：connectDatabase -连接数据库;initDocData -执行数据库脚本；点击“Test cases”Tab页，可以表格形式展示rf测试用例；也可切换到“source”Tab页，直接以源码形式展示，看个人习惯选择视图编写脚本即可；测试数据层：分为“sql脚本” 和“ py文件”两类。sql脚本中存储insert语句，为“删改查”接口准备基础数据，在测试用例执行之前进行数据库脚本初始化操作（使用Suite Setup）；Py文件 : LIST__addIDoc为新增接口的测试数据，其校验数据对应为：LIST__assertAddIDoc。.py文件中存储list类型数据，作为“增”[post]接口的测试数据以及各接口的校验数据；如图所示，其中“删改查”[delete/put/get]接口的校验数据需根据sql中的数据进行设计，一条测试数据对应一条校验数据，其List下标相同，保证进行数据遍历时测试数据和校验数据能一一对应。测试用例层：使用关键字，编写测试用例脚本。获取测试数据组，利用FOR循环，根据测试数据的List长度【即测试数据组数】遍历请求参数：发送相应请求，获取返回值，同时校验返回值是否与预期相符：关键字assertResult：为自定义关键字，参数有三个：接口返回值response、当前接口校验数据List、测试数据下标，若返回值状态码与预期状态码一致，则继续通过testcase关键字校验responseContent值是否与预期值相等，若状态码不相等，则直接跳过进入下一循环【这里校验和测试数据需严格按照“下标一一对应”规则 ，否则在校验时则无法正确匹配，且测试数据有几组，则校验数据也应有几组，否则将报错】。关键字testcase：有两个参数：response返回值和对应的校验数据，主要用作responseContent内容与校验数据的比对，若校验数据中所有key对应的value值，都与responseContent里同一key的value值相同【responseContent包含校验数据】，则校验通过。总结：1、预置测试数据和校验数据（通过sql脚本和Py文件中存储List类型数据） ；2、通过testcase前置条件，连接数据库并执行sql脚本初始化数据，且进行登录操作，将“认证”值设置为全局变量，供后续接口使用；3、编写测试用例，利用for循环遍历测试数据，发送请求，并获取同List下标的校验数据，进行返回值的校验；至此整个测试流程结束。小伙伴们get到我的整个框架设计了吗？四、如何在DevOps中执行RF脚本并生成测试报告到这里可能会有人问：测试报告和日志如何处理？这时候就要结合我们的DevOps产品，前言讲过DevOps为自动化测试做了哪些工作，是的，就是利用DevOps集成的rf任务，和拉取代码库代码任务，进行rf脚本的执行，执行完毕后，会将生成的测试报告存储在:与发布到nexus的工件路径一致。1）添加Robotframework任务，输入测试用例路径以及介质仓库，选择测试执行机（测试执行机需提前安装好robotframework运行环境），点击执行。2）robotframework任务执行完毕后，点击进入“自动化测试”tab页，显示本次运行相关信息（包括测试环境、运行开始结束以及持续时间）和测试报告、日志链接。查看每次运行后的测试报告。这就让我们的自动化工作变得更加简单，只考虑如何将测试用例写好即可，无需考虑CICD工作。题外话：普元devops产品，以自身提供的RF自动化测试功能为基础，极大程度的简化了自动化测试的CICD工作，让测试工程师更专注于维护测试用例和框架的编写，且提供自动化测试报表，让自动化过程透明化。整个rf框架历时两个月，中间不断修正，在这个过程中又接触到其他的自动化测试方案，还有很多需要完善和更改的地方，期待后面的框架订正吧【测试数据将更改为写在excel中，从excel中读取测试数据，并将每条测试用例的测试结果写在excel中】。欢迎各位小伙伴来沟通RF或者其他自动化测试方案~关于作者：冰糖糯米，普元测试工程师，目前参与Devops项目的功能测试以及接口自动化测试工作。致力于测试技术的研究和开发。

现如今，无论是软件测试人员，还是利益相关者，都已经认识到：实现测试自动化框架对于软件项目的成功是至关重要的。它不但能够提高测试的效率，而且可以减少人工干预的工作量。在本文中，我们将深入探讨什么是真正的测试自动化框架，自动化脚本是如何工作的，以及此类框架是如何在测试过程中给团队提供竞争优势的。定义测试自动化在任何行业中，自动化通常被解释为通过智能算法，来自动处理各种流程，而且几乎不需要人工的干预。在软件行业中，测试自动化意味着：使用受许可版本或开源版本的自动化工具，对软件应用程序执行各项测试。从技术角度来说，测试自动化框架是一组定制的交互式组件，它可以协助执行脚本化的测试，并全面地报告测试结果。为了成功地构建自动化框架，软件质量保证专家必须通过全面考虑与设计，来控制和监视整个测试过程，并提高结果的准确性。与此同时，那些经过精心设计的自动化框架也能够让测试人员以实用、简化的方式，来执行各项自动化的测试。通常，根据自动化需求目标的不同，我们可以选择并创建如下不同的框架：以工具为中心的框架无论是商业版工具还是开源的自动化工具，它们都拥有自己的系统框架，可以在各种测试环境中提供测试套件，实施分布式测试，并最终生成报告。最典型的示例当属Selenium自动化框架。该框架的主要组件是WebDriver。作为基于Web的浏览器插件，该组件可被用于控制和操作Web浏览器中应用程序的DOM模型。此外，Selenium自动化框架还带有各种实用的编码库，以及支持记录回放的工具。Serenity是另一个自动化工具的框架。它围绕着Selenium Web驱动构建了一个加速器。为加快测试自动化实施过程的速度，Serenity还能够将特定的组件与社区内的其他工具相组合。除了上述两种工具，业界还有TestComplete、以及Ranorex HP QTP等工具。作为已部署的预构建框架，它们都带有用户行为模拟器、报告和脚本IDE等功能。面向项目的框架定制此类框架主要是用于实现特定应用项目的自动化。特定项目的框架既可以支持某些目标应用的测试自动化需求，又能够被开源库构建的组件所驱动。此类框架围绕着被测系统(System Under Test，SUT)创建了一个友好的测试环境，以运行和覆盖各种基本功能。其中包括：对已开发的应用进行部署，运行，并且通过包装器(Wrapper)的控制以简化编码，执行测试用例，以及输出测试结果报告。面向特定项目的框架还应该通过组件，以支持在不同的操作系统和浏览器上，进行跨多种云端环境的测试。关键字驱动的框架这是一些旨在给开发人员和测试人员带来较少代码体验的框架。那些被应用于代码之中的关键字集(如：Login、NavigateToPage、Click、以及TypeText)会被安装到代码库中，作为一个关键字的存储库。根据给定的关键字，测试人员可以参考编写处对应的脚本，并以电子表格的形式，传递到关键字解释器中，予以执行和测试。因此，对于技能不足的人员来说，他们能够据此轻松地编写和理解各种自动化脚本。理想的测试自动化框架的主要组件如果您想实现功能强大、且性能卓越的测试自动化框架，那么无论采用开源的、还是商用的框架，都必须包括一些核心的构成组件。它们分别是：1.测试库a)单元测试您需要将单元测试库用于：通过特定的形式注解(例如@Test或[Test])，来定义正在使用的测试方法。执行能够影响自动化测试最终结果的断言(assertion)。运行简单明了的测试。无论您是通过命令行、IDE、专用工具、还是CI(持续集成)系统，来运行测试，都需要确保单元测试能够以直观的方式得到运行，并能够提供相应的单元测试库。通常，单元测试库可以支持几乎每一种编程语言。其中包括：针对Java的JUnit和TestNG。针对.Net的NUnit和MSTest。适用于Python的unittest(以前叫做PyUnit)。b)集成和端到端测试在执行集成和端到端测试自动化时，我们往往需要检验现有测试库所提供的各项功能。为了消除不必要的编码负担，那些由应用UI驱动的API级别的测试，需要通过组件，轻松地与被测应用进行交互。因此，我们不能仅专注于如下方面的编码工作：连接到应用程序。发送各种请求。接收各种结果回应。此环节涉及到的重要测试库有：Selenium(主流语言都可使用)。Protractor(特定于JavaScript)。Karate DSL(特定于Java的API级集成测试。)c)行为驱动开发(Behavior-Driven Development，BDD)专门针对BDD的测试库往往以行为规范为目标，以可执行代码的形式创建各种可执行的规范。尽管它们不能像测试工具那样直接与被测应用进行交互，但是我们可以将不同的功能和预期的行为场景转换为代码。通过对BDD流程的支持，我们可以创建与自动测试范围和意图相一致的实时文档。如下是典型的BDD库：Cucumber(主流语言都可使用)。Jasmine(特定于JavaScript)。SpecFlow(特定于.Net)。2.测试数据管理在软件测试自动化、以及测试的创建过程中，我们面临的最大挑战是如何利用好测试数据的管理系统。因此，随着自动化测试数量的增加，我们需要能够为特定测试的开展，提供可用的测试数据。而且，我们的自动化框架需要提供必要的措施，来输入、创建、以及最终按需清除测试数据。通常的做法是：采用一套合适的仿真工具，以使数据更加简化、清晰且易于处置。3.模拟、存根(Stub)和虚拟化在研究自动化测试的方案时，您可能会遇到如下情况：需要将模块与在单元测试中连接的组件隔离开来。需要处理应用程序集成、或端到端测试中常见的繁琐依赖项关系。无论上述哪种情况，在开发自动化测试框架的过程中，您都需要创建模拟已连接的组件行为模式、存根，以及选择实用的虚拟化工具。实施模型的通用机制除了上面讨论的自动化框架组件之外，还有一些实用的机制可以帮助我们创建，使用和维护各种自动化的测试，其中包括：包装器方法：在使用Selenium WebDriver组件时，我们可以通过创建自定义包装器来处理各种错误。因此，在创建了可用于Selenium API调用的自定义包装器后，您将能够更好地处理各种超时、异常、以及故障报告，从而更加关注于自动化测试的本身。抽象方法：抽象机制代表了提高可读性，淡化了多余的实现细节。例如：在创建Selenium WebDriver测试时，我们可以使用页面对象(Page Objects)在页面上发现用户输入的凭据或单击某处等操作。同时，我们通过跳过页面上某个特定元素之类的方法，来达到高级测试的目标。而且，此类方法适用于许多相似的应用程序和自动化测试场景。测试结果报告在为“如何将测试结果报告到自动化框架中”，这一问题选择相应的库或机制时，您应该着眼于阅读与查看此类报告的目标受众。在此，您需要注意如下方面：那些Junit和TestNG之类的单元测试框架所生成的报告，主要针对的是诸如CI(持续集成)服务器之类的接收系统。这些系统最终会对结果进行解释，并以其他软件可使用的XML格式进行呈现。如果您需要产生可读性较强的报告，那么可以考虑诸如Junit的UFT Pro、NUnit、以及TestNG类，与单元测试框架相兼容的商业工具。当然，您也可以利用诸如ExtentReports之类的第三方库，输出包括饼图、图表、图像之类带有直观说明的报告格式。CI平台为了以更快、更一致的方式进行应用程序的测试，持续集成(CI)平台可以帮助您定期构建软件，并为新的版本运行各项测试。当开发和部署新的功能，以及更新现有功能的时候，CI方法可以让开发人员和利益相关者有机会就应用程序的质量，获得定期的反馈和更快的响应。目前，TeamCity、CircleCI、Jenkins、Atlassian Bamboo等都属于高品质的CI平台。源代码管理与手动测试相似，自动化测试也涉及到编写和存储源代码的版本。各个开发公司都会运用一套源代码和版本控制系统，来保存与保护自己的源代码。目前，以Git、Mercurial、Subversion和TFS为代表的源代码管理系统，不但能够便捷地管理系统在生产环境中的代码，而且能够进一步完善自动化测试。创建依赖项管理器依赖项管理器的主要目的是：协助收集和管理在自动化软件方案的功能中，所使用的现有依赖性和库的过程。其中Maven和Gradle之类的工具，能够起到依赖项管理，协助从源代码和支持库中开发自动化软件，以及运行测试等作用。此外，业界其他常见的依赖项管理工具还有：Ant、npm和NuGet。建立和实施框架的过程我们通常可以通过如下方法，来计划与实现自动化测试的方案。从客户的角度来探究自动化的实际适用性，也就是说：从产品的界面和外观上建立测试，以发现使用上的不足。密切关注被测系统所用到的技术，通过模拟用户的真实行为，来采用合适的测试自动化工具。建议采用基于阶段的实现方法。其中，每个阶段都具有交付自动化测试脚本的优先级。同时，我们也可以通过添加各种框架功能，让各种脚本能够按期执行。在启动软件测试自动化之前，我们需要事先计算和估计实施后的投资回报率(ROI)，概念证明(concept proof)，运行手动回归或冒烟测试的时间，以及每个版本的发布周期。如果我们能够认真地规划和执行上述测试自动化框架的过程，那么整个软件的开发和测试环境会得到如下方面的收益：最少的时间与最大的收益：通过构建某种可行的测试自动化框架和脚本，我们将能够最大程度地减少在编写与运行测试用例上所花费的时间，进而在更短的时间内获得更大的输出。可以说，有了出色的自动化框架，我们可以解决诸如：同步问题、错误管理、本地配置、报告生成与解释等方面的难点。可重用和可读性的自动化代码：各种既有的组件库代码不但能够在一段时间内保持可读性和可重用性，并且能够让诸如：报告、同步和故障排除等相关任务变得更加易于访问和实现。资源优化：自动化系统的灵活性，很大程度上决定了自动化测试的效率，各个组件团队的协同能力，以及企业是否能够在资源优化和知识共享方面受益。总结在如今快节奏的软件开发生态系统中，自动化的测试和脚本在软件测试周期的效率和覆盖面上都起着不可或缺的作用。当然，这些都离不开精心设计的框架和基础性的组件策略。我们可以从最小处入手，通过反复测试和改进，来避免在测试自动化的后期阶段产生冲突或被迫妥协的状况。希望上述有关测试自动化框架的讨论，能够让软件测试人员在执行测试项目中有所受益。

“丧”这个词最近可是大火，比如大家追的“丧文化”“丧茶”“丧脸”。我不是不高兴，我只是一张不高兴的脸啊早在几年前，时尚圈还流行着“仙女系”“精灵系”超模，那人畜无害的楚楚动人模样，可最近仙女脸却渐渐失去它往日的光彩。由于一股在青年中很流行的“丧文化”的兴起“丧脸”慢慢成为主流在网络流行文化和广告作品中就可见一斑，从《感觉身体被掏空》的流行，到葛优躺的颓废满屏，再到丧茶的席卷网络，我们一直被“丧”所包围着，广告只管怎么扎你的心，却不管包扎。混血超模“水原希子”工作中，自动化测试就堪称是软件测试圈的一张“丧脸”。二十多年来，各家企业挤破脑袋为了实现测试自动化，然而，事实上大多数公司从来没有能够实现他们的自动化计划所期望的业务成果。最近的研究报告显示，测试自动化率平均为20％左右，敏捷采用者为26-30％。哪几个因素导致自动化的“丧”？01、传统的软件测试平台是旧时代的产物目前最常用的软件测试工具是基于老的技术而构建的，但企业架构多年来一直在不断演化与发展。开发不再按季度发布周期来构建C/S桌面应用程序——每次发布之前都有一个月的测试窗口。有了测试自动化工具（如Mercury，HP，Micro Focus，Segue，Borland和IBM）之后，几乎一切都已经发生了变化。将新功能装入已有的旧平台中，与那些基于新需求的原生解决方案是迥然不同的。02、传统的基于脚本的测试很难维护当开发人员正在积极地开发应用程序时，脚本很难维护。应用程序迭代演化的频率越来越快，脚本保持同步就越来越困难。团队经常处在“创建新测试（脚本）速度比更新已有测试（脚本）更快”的境界。这导致一个更加笨重的测试套件，最终产生令人沮丧的、大量的错误，因为应用程序不可避免地继续改变。误报率、脚本错误和膨胀的测试套件等一同造成的负担，很少有QA小组可以克服。这是一个永远不能完成的任务——只有巨石不断增长、且越来越大。03、软件架构已经改变软件架构发生了巨大变化，与现代企业应用相关的技术组合已经迅速扩展。随着转向云计算、云服务和微服务，我们正在努力迁移，远离大型机和C/S架构。这产生了两个明显的挑战：测试这些技术需要高度的技术专长/专业化或高水平的业务抽象，允许测试人员在不涉及底层技术细节的情况下进行测试。应用程序的不同部分正在以不同的速度发展，从而导致开发节奏不匹配。04、软件开发流程发生了变化虽然今天大多数企业仍然拥有一些瀑布流程，但是，“交付的东西越来越小、迭代越来越快”是不可抗拒的发展趋势。我们已经从季度发布转为每周一次或每日一次——甚至像这种特别的实例：亚马逊每11.6秒发布一次新的代码。05、质量的责任发生了变化为了响应更快的发布周期的需求，人们推崇“测试左移”。创建代码的开发人员对质量承担更多的责任，因为他们的任务及时达到“完成的标准”变得非常迫切。然而，对于从事复杂应用的大型企业，开发人员主导的测试主要集中在非常窄的、一小部分代码和组件上。开发人员通常缺乏测试能力和时间，完成现实中端到端业务交易的测试。虽然质量的职责已经向左移动，但是植根于瀑布过程的遗留依旧有明显的“朝右”偏见。这使得难以混合这两种方法。那么现在怎么办？软件测试必须改变！随着扩展到所有行业领域的DevOps、持续交付和敏捷等突破性的创新，软件测试成为数据驱动软件发布决策的核心。这意味着组织必须拥有能够进行持续测试的技术，否则创新的想法只会止步于昨天的重量级测试工具。

一个软件系统从0到1，大致步骤是需求分析->系统框架设计->系统代码编写->进行单元测试->然后集成测试->紧接着系统测试->最后验收测试，因此可以看出，测试环节占了很重要的一部分.目前市面上的自动化测试工具非常多，下面几款是比较常见的自动化测试工具。其实这么多测试的知识，对于大型系统来说非常有必要的，但对于小型系统来说反而会增加更多的成本。重点在下面↓↓↓↓↓↓0) SeleniumSelenium是Web应用程序测试的工具，支持多平台、多浏览器、多语言去实现自动化测试。目前在Web自动化领域非常的流行。1) UFT( Unified Functional Testing )是HP公司研发的一款产品。它的出发点是作为一个企业级的自动测试工具标兵，他有个特点就是提供了强大易用的录制回放功能，并且兼容了对象识别模式与图像识别模式两种识别方式，支持B/S与C/S两种软件架构的测试，也算是目前主流的自动化测试工具之一。2) Robot FrameworkRobot Framework是一款用Python开发语言研发的自动化测试架构，拥有良好的可扩展性，可以同时测试多种类型的客户端或者接口，也可以进行分布式服务的测试。3) WatirWatir( Web Application Testing in Ruby )是一个以Web模式的自动化功能测试工具。Watir是一个Ruby语言库，使用Ruby语言进行脚本开发。当然，除上面所列的自动化测试工具外，根据不同的应用还有很多商业的或开源的以及公司自己开发的自动化测试工具。从自动化程度的软件测试工作可分为手工测试和自动化测试。1)手工测试通俗说就是测试人员一个一个地去手动执行测试用例，通过键盘鼠标等手工输入一些需要的参数，然后分析返回的结果是否是按照设想的结果返回。手工测试这种说法并不是专业术语，手工测试一般是指我们在系统测试阶段所进行的功能测试，为了更明显地与自动化测试进行区分，所以使用了手工测试这种民间说法。2)自动化测试是把以手工为输入的测试行为转化为机器自动化执行的一种方式。通常，在设计测试用例并通过评审之后，由测试人员根据测试用例中描述的规则流程一步步执行测试，把得到的实际结果与期望结果进行比较。在此过程中，为了节省人力、时间和硬件资源，提高测试效率，便引入了自动化测试的概念。自动化测试又可分为：功能自动化测试与性能自动化测试。测试一般完整的阶段有四个阶段1)单元测试(或模块测试)是对单个接口代码段进行测试的过程。2)集成测试是在单元测试的基础上，通过多个单元模块集合成的系统或子系统，然后统一进行测试。重点是检查模块之间的接口是否正确。3)系统测试是针对整个产品系统进行的测试4)验收测试是部署软件之前的最后一个测试阶段。验收测试的目的是确保软件准备就绪，向软件购买者展示该软件系统能够满足用户的需求。测试从方法上又有不同的区分1)黑盒测试指的是把被测的软件看作一个黑盒子，我们不去关心盒子里面的结构是什么样子的，只关心软件的输入数据和输出结果。它只检查程序呈现给用户的功能是否按照需求规格说明书的规定正常使用、程序是否能接收输入数据并产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。2)白盒测试，指的是把盒子打开，去研究里面的源代码和程序执行结果。它是按照程序内部的结构测试程序，通过测试来检测产品内部动作是否按照设计规格说明书的规定正常进行，检验程序中的每条逻辑路径是否都能按预定要求正确工作。3)灰盒测试介于黑盒测试与白盒测试之间。可以这样理解，灰盒测试既关注输出对于输入的正确性，同时也关注内部表现。但这种关注不像白盒测试那样详细、完整，它只是通过一些表征性的现象、事件、标志来判断内部的运行状态。有时候输出是正确的，但内部其实已经错误了，这种情况非常多。如果每次都通过白盒测试来操作，效率会很低，因此需要采取灰盒测试的方法。从测试的目的上区分又分为下面两方面1)功能测试主要检查实际功能是否符合用户的需求，因此测试的大部分工作也是围绕软件的功能进行。设计软件的目的就是满足用户对其功能的需求，如果偏离了这个目的，则任何测试工作都是没有意义的。功能测试又可以细分为很多种：逻辑功能测试、界面测试、易用性测试、安装测试、兼容性测试等。2)性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行的测试。软件的性能包括很多方面，主要有时间性能和空间性能两种。

近日,2019年度 TOP100全球软件案例研究峰会(TOP100 Summit)在北京国际会议中心举办。 Top100 Summit是科技界一年一度的案例研究峰会,秉承“从用户角度出发,挑选年度最值得学习案例”的价值理念,每年甄选本年度最值得研究和参考的行业100+顶级案例。平安普惠自动化测试云平台与微软、谷歌、Facebook、百度、阿里、腾讯、华为、京东等国内外知名互联网企业的重要科技成果一同入选2019年度TOP100全球软件案例。本届峰会围绕“数字化转型与指数组织创新战略”主题,覆盖产品、管理、架构、AI、DevOps、数字化转型、前沿技术等十八个主题方向,通过100件国内外优秀的技术创新案例,意在向参会者解读2020年的技术趋势和新风向。在大会上,平安普惠测试管理部测试开发专家进行了题为“平安普惠自动化测试平台建设之路”的精彩分享。平安普惠自动化测试云平台入选第八届TOP 100全球软件案例金融科技由爆发增长期进入精耕细作期,针对用户体验的专项质量保证对于产品生命力具有重要价值。人工智能潮起,针对新的算法和硬件产品形态如何做好质量保证也有待探索。金融服务行业软件系统具有集中度高、规模大、数量多、系统耦合度强、业务复杂、需求变化快等特点。随着新兴技术和金融互联网化的发展,对传统金融服务行业的软件开发和测试都带来了较大的考验,如何在新的形势下提升自动化测试效率及质量,缩短交付周期,是各大公司软件测试面临的主要挑战。智能自动化测试研究已经成为业界趋势,平安普惠率先取得突破,自主研发的自动化测试云平台上线应用已经产生实用价值。平安普惠测试管理部测试开发专家在大会分享中指出,传统开源自动化测试工具存在难实施、难管理、难集成、难分析等四大痛点,外部采购商业自动化测试平台存在成本高、定制化需求和技术支持难以保证等问题,加上普惠信贷业务流程功能场景复杂、变化快、质量要求高等难点,促使平安普惠从0到1自主研发建设自动化测试云平台。平安普惠自动化测试云平台主要提供无人值守自动化测试、一键自动化造数、日志精准分析、自动化效率质量分析等一站式测试服务,助力提升测试效率和产品质量。平台集成数据驱动、关键字驱动、行为驱动等多种测试框架;平台实现可视化和配置化,无需代码基础也能做好自动化;平台包含断点续跑、日志精准分析、单接口自检、智能重试、公共函数、无人值守等多处科技亮点。通过平安普惠自动化测试云平台的研发应用,将大量繁杂、机械性、重复性的测试工作利用自动化代替,同时测试人员的自动化测试思维能力得到极大提升,实现测试价值最大化。截至目前,该平台成功应用对效能提升效果显著,SIT自动化覆盖率达48%,回归自动化覆盖率达62%,节省人力占比达20%,自动化测试人员占比达80%,最终实现测试效率和产品质量提升。平安普惠相关负责人表示,历时两年精心打磨的自动化测试平台逐步改变技术思维与工作习惯,成为研发工作中离不开的必备工具,帮助提升研发效能。融合技术、产品、思维、流程、业务、管理、模式和理念打造公司级Paas平台,为用户提供一站式专业服务、为团队产生变革价值、为管理展示决策数据,助力公司业务发展。未来将继续向精细化、体系化、数字化、智能化等方向进行平台升级应用,并研发更多更好的技术平台且推动成功应用实践。平安普惠自动化测试云平台的成功研发应用,正是平安普惠以“科技助力+模式创新” 思路解决普惠信贷问题的缩影。平安普惠提倡以科技助力,从场景无感接入、大数据建模、人工智能、增信引擎、资金引擎等方面入手,致力于以信贷科技为驱动力,促使金融服务效率的提升。在2015年,平安普惠就在小额信贷业务产品设计中,创新地应用人脸识别等先进技术,实现对小额信贷客户的身份识别及客户初步画像。目前,平安普惠又在自身优势领域的小额信贷业务中,创新的运用了新的金融科技,包括高准确率的人脸识别技术、微表情、AI面审机器人、智能客服为代表的人工智能、远程面谈与欺诈电网的业务应用、多维度视角的信用认证体系,以及大数据和反欺诈风控模型等,借助科技运营成本降低了58%,力图将成本更低、价格更可被接受,效率更高、体验更好的小额信贷金融业务产品提供给广泛的普惠人群。