本主要介绍以Java为基础，搭建Selenium自动化测试环境，并且实现代码编写的过程。1.Selenium介绍Selenium1.0包含core、IDE、RC、grid四部分，selenium2.0则是在两位大牛偶遇相互沟通决定把面向对象结构化（OOPP）和便于编写代码的各自思想予以整合后形成的新工具，也就是我们所指的WebDriver。Core是selenium的核心，在后期虽然被封装，但只是减少了可视性，它依旧是驱动selenium的核心；IDE是一款firefox浏览器插件，主要用于新手或对编码还不熟悉的人员入门时使用，这个插件允许在firefox中录制一段web操作代码，导出后在ec

前言今年已经过去大半了，前面所分享的知识也是很多，但是有的小伙伴还是私信我说：技术现在基本掌握，但是先在求职连HR消息都不回复我，因此你的简历应该是被沉如茫茫大海。对此我个人看法有如下四点：一、写出醒目的简历让HR一目了然，在众目睽睽的简历之下让HR有一丝丝对你的影响深刻。二、简历的包装是必不可少，毕竟人靠衣装马靠鞍,三分长相七分打扮。简历也是如此装饰一份漂亮的简历。三、简历的项目是重中之重，企业招聘也是看中你的技术前面所说的是微优化，体现个人技术发光的地方就是在这个项目上展示你的技术个人魅力。四、就是面试技巧，其实面试是有很多的技巧，当然也是少不了的面试攻略，和刷题、背题、高频题，毕竟有前车

1、开发能力的帮助（1）提高编程能力，缺陷定位到更底层，通过Exception或者error日志能够初步判断哪里出了问题，跟开发的沟通更方便。（2）写脚本过程中，让脚本可复用，可维护，有封装和复用的思想。比如引入做UI自动化测试框架的时候，做关键字驱动。（3）测试用例和测试计划评审，站在开发的角度提出一些更专业的建议，更好的推动测试工作。2、测试框架封装的优点在没有框架的时候是通过工具让人工去运行的，有了框架之后就只需要去维护测试用例，通过跟Jenkins的配置，就能够在迭代的一个周期里面自动的运行测试脚本，自动发现问题，自动生成测试报告，能够省去大量执行回归测试的一个工作。3、发现问题处理的

本来想把这部分标题写成“数据库自动化测试平台构建”的，但想想还是算了，因为这次的构建目标比较简单，只是为了做数据库基本语法自动化测试、数据库基准测试（包含tpch，ssb，tpcds）。涉及到的开发内容可能不多，就只当一个自动化测试流程的构建吧，接下来数落数落这次的需求：一、统一测试执行服务简言之，统一测试执行服务（TestExecutionService,TES）就是用来发起测试执行的入口。TES提供GUI界面和RESTfulAPI两种形式，对外提供执行测试的服务，同时兼具测试版本管理、Jenkins测试Job管理和测试执行结果的管理。其中GUI界面主要用于人工场景按需发起测试的执行，而RE

Selenium是一种常用的Web自动化测试工具，支持多种编程语言和多种浏览器，可以模拟用户的交互行为，自动化地执行测试用例和生成测试报告。Selenium基于浏览器驱动实现，结合多种定位元素的方法，可以实现各种复杂的Web应用程序的测试1、自动化测试自动化测试指软件测试的自动化，在预设状态下运行应用程序或者系统，预设条件包括正常和异常，最后评估运行结果。将人为驱动的测试行为转化为机器执行的过程。自动化测试包括UI自动化，接口自动化，单元测试自动化。按照这个金字塔模型来进行自动化测试规划，可以产生最佳的自动化测试产出投入比（ROI），可以用较少的投入获得很好的收益。1.1单元测试最大的投入应该

一个软件系统的配置具有多个层面，可以是系统级别的配置，也可以是功能级别的配置。很多开发人员有这样的经历——当一个功能某个变量需要通过配置来提供时，就会将这个变量放在配置文件中，并存放到一个特定目录下。如果没有一个统一的流程去规划这个过程，那么每个测试工程师都会按照自己喜欢的模式去定义配置文件格式，比如XML、Properties、JSON等，并且都存放在自己认为合适的地方，导致配置文件混乱，不方便使用且难以管理。所以配置模块的目的就是让其他模块通过配置模块来统一管理配置项因此，我们需要实现如下功能：一、配置的保存和读取配置文件的保存和读取是配置模块的基本功能之一，所有配置都被保存在文件或数据库

策略简介本章我们将使用迄今为止你所学到的关于pytest的所有知识，为Cards项目创建测试策略--软件测试中"写什么测试"的部分。我们将从定义我们的测试套件的目标开始。然后，我们将看看Cards的软件架构是如何影响我们的测试策略的，并受到测试需求的影响。然后，我们可以开始选择和优先考虑哪些功能需要测试。一旦我们知道哪些功能需要测试，我们就可以生个所需的测试案例列表。所有这些有条不紊的计划真的不需要很长时间，并将有助于产生体面的初始测试套件。确定测试范围安全性能负载输入验证卡片项目是为个人或小团队使用的。即便如此，在现实中，上述所有的担忧都适用于这个项目，尤其是随着项目的发展。那么对于一个初始

昨天的这篇580.【自动化测试】测试引擎的职责是对测试引擎的职责的摘要，这篇继续剖析一下一个测试引擎的职责细节。测试引擎需要支持测试用例的输入，这里说的输入应当有一个抽象层.首先，比如说对开发语言的抽象的处理——支持java、python、go等；其次，对执行的抽象，不同的测试用例，执行测试用例的方法不一样，比如加载配置的方式不一样，启动的命令不一样等等；紧接着，对测试资源的抽象，测试用例大多建立在一个特定的测试环境，拿数据库测试为例，这个环境可以是“A主机上B端口上的单机版的数据库”、也可以是“C主机上D端口上的集群版数据库”。再次是，对测试日志的抽象，不同的测试用例，尤其不同语言的测试用例

前期回顾：基于Appium+WDA+Python搭建IOS自动化测试全纪录(二):模拟器demo运行基于Appium+WDA+Python搭建IOS自动化测试全纪录(一):环境搭建在模拟器将demo跑通之后，就要在真机上测试啦，模拟器总是要为真机服务的。证书问题在真机上主要是涉及到签名及证书的问题,一下blog写的特别好，然而其实我也没有看懂，RSA算法神马的早在密码学课程上还给老师了。iOSApp签名的原理主要在此简单记录一下证书的配置吧。在xcode中找到buildSetting配置部分（之所以把这张图放出来是因为我最开始找不到这个配置，萌新啥都找不到）：WX20180115-203847

实践中，功能测试常见的问题功能文档表述不规范，造成测试工程师理解偏差，导致设计的测试用例变成了无效测试用例。当然在大多数情况下，开发和测试人员会针对文档进行审阅（review），尽可能避免这类问题的发生，但是一切都是在之上谈兵的阶段，没有实际的操作，很难保证设计的测试用例能够真正适配和覆盖到相应的功能的测试。需求变更，导致功能特性更新，直接影响原先的测试用例。对于一些以客户为导向的项目团队，这个情况特别容易出现。比如，原本客户的下单功能只需要填写收货地址和收货要求，但是由于想提供更好的服务，于是增加了填写收货时间的选项。这样一来，在提交订单的功能点上，就需要加入对收货时间的验证，这就导致了测试