标签：思维 uft 出现 关于 lock 开发人员 才有 app 研究
单元测试（或模块测试）是对程序中的单个子程序或具有独立功能的代码段进行测试的过程。
集成测试是在单元测试的基础上，先通过单元模块组装成系统或子系统，再进行测试。重点是检查模块之间的接口是否正确。
系统测试是针对整个产品系统进行的测试，验证系统是否满足需求规格的定义，以及软件系统的正确性和性能等是否满足其需求规格的要求。
验收测试是部署软件之前的最后一个测试阶段。验收测试的目的是确保软件准备就绪，向软件购买者展示该软件系统能够满足用户的需求。
白盒测试与黑盒测试，主要是根据软件测试工作中对软件代码的可见程度进行的划分。这也是软件测试领域中最基本的概念之一。
黑盒测试，指的是把被测的软件看做一个黑盒子，我们不去关心盒子里面的结构是什么样子的，只关心软件的输入数据和输出结果。
它只检查程序呈现给用户的功能是否按照需求规格说明书的规定正常使用、程序是否能接受输入数据并产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。
白盒测试，指的是把盒子打开，去研究里面的源代码和程序执行结果。
它是按照程序内部的结构测试程序，通过测试来检验产品内部动作是否按照设计规格说明书的规定正常进行，检验程序中的每条逻辑路径是否都能按预定要求正确工作。
灰盒测试介于黑盒测试和白盒测试之间。
可以这样理解，灰盒测试既关注输出对于输入的正确性，同时也关注内部表现。但这种关注不像白盒测试那样详细、完整，它只是通过一些表征性的现象、事件、标志来判断内部的运行状态。有时候输出是正确的，但内部其实已经错误了，这种情况非常多。如果每次都通过白盒测试来操作，效率会很低，因此需要采取灰盒测试的方法。
从软件的不同测试面可以划分为功能测试与性能测试
功能测试主要检查世纪功能是否符合用户的需求，因此测试的大部分工作也是围绕软件的功能进行。设计软件的目的就是满足用户对其功能的需求，如果偏离了这个目的，则任何测试工作都是没有意义的。
功能测试又可以细分为很多种：逻辑功能测试，界面测试、易用性测试、安装测试、兼容性测试等。
性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行的测试。
软件的性能包括很多方面，主要有时间性能和空间性能两种。
从对软件测试工作的自动化程度可以划分为手工测试与自动化测试。
手工测试就是由测试人员一个一个地去执行测试用例，通过键盘鼠标等输入一些参数，并查看返回结果是否符合预期结果。
手工测试并非专业术语，手工测试通常是指我们在系统测试阶段所进行的功能测试，为了更明显地与自动化测试进行区分，这里使用了手工测试这种说法。
自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。通常，在设计测试用例并通过评审之后，由测试人员根据测试用例中描述的规则流程一步步执行测试，把得到的世纪结果与期望结果进行比较。在此过程中，为了节省人力、时间和硬件资源，提高测试效率，便引入了自动化测试的概念。
自动化测试又可分为：功能自动化测试与性能自动化测试。
这几种测试出现在软件测试的周期中，既不算具体明确的测试阶段，也不是具体的测试方法。
是指在对一个新版本进行大规模的系统测试之前，先验证一下软件的基本功能是否实现，是否具备可测性。
引入到软件测试中，就是指测试小组在正是测试一个新版本之前，先投入较少的人力和时间验证一个软件的主要功能，如果主要功能都没有运行通过，则打回开发组重新开发。这样做的好处是可以节省时间和人力投入到不可测的项目中。
回归测试是指修改了旧代码后，重新进行测试以确认修改后没有引入新的错误或导致其他代码产生错误。
回归测试一般是在进行第二轮软件测试时开始的，验证第一轮软件测试中发现的问题是否得到修复。当然，回归也是一个循环的过程，如果回归的问题通不过，则需要开发人员修改后再次进行回归，直到所有问题回归通过为止。
是指测试中的所有输入数据都是随机生成的，其目的是模拟用户的真实操作，并发现一些边缘性的错误。
随机测试可以发现一些隐蔽的错误，但是也有很多缺点，例如测试不系统，无法统计代码覆盖率和需求覆盖率、发现的问题难以重现等。一般是放在测试的最后执行。随机测试更专业的升级版叫做探索性测试。
探索性测试可以说是一种测试思维技术，它没有很多实际的测试方法、技术和工具，但却是所有测试人员多应该掌握的一种测试思维方式。探索性测试强调测试人员的主观能动性，抛弃繁杂的测试计划和测试用例设计过程，强调在碰到问题时及时改变测试策略。
安全测试在IT软件产品的生命周期中，特别是产品开发基本完成至发布阶段，对产品进行检验以验证产品符合安全需求定义和产品质量标准的过程。
安全测试现在越来越受到企业的关注和重视，因为由于安全性问题造成的后果是不可估量的，尤其是互联网产品，最容易遭受各种安全攻击。
我们应该有更多的低级别的单元测试，而不仅仅是通过用户界面运行的高层的端到端的测试。
传统的自动化测试我们可以理解为基于产品UI层的自动化测试，它是将黑盒功能测试转化为由程序或工具执行的一种自动化测试。
但是在目前的大多数研发组织当中，都存在开发与测试团队割裂（部门墙）、质量职责错配（测试主要对质量负责）的问题，在这种状态下，测试团队的一个“正常”反应就是试图在测试团队能够掌握的黑盒测试环节进行尽可能全面的覆盖，甚至是尽可能全面的 UI 自动化测试。
这可能会导致两个恶果：一是测试团队规模的急剧膨胀；二是所谓的全面UI自动化测试运动。因为UI是非常易变得，所以UI自动化测试维护成本相对高昂。
分层自动化测试倡导的是从黑盒（UI）单层到黑白盒多层的自动化测试体系，从全面黑盒自动化测试到对系统的不同层次进行自动化测试。
单元自动化测试是指对软件中的最小可测试单元进行检查和验证。对于单元测试中单元的含义，一般来说，要根据实际情况去判断其具体含义，如C语言中单元是指一个函数，Java中单元是指一个类，图形化的软件中单元是指一个窗口或一个菜单等。总的来说，单元就是人为规定的最小的被测功能模块。规范的进行单元测试需要借助单元测试框架，如Java语言的Junit、TextNG，C#语言的NUnit，以及Python语言的unittest、pytest等，目前几乎所有的主流语言都有其相应的单元测试框架。
Code Review中文翻译为代码评审或diamante审查，是指在软件开发过程中，通过对源代码进行系统性检查的过程。通常的目的是查找系统缺陷、保证软件总体质量以及提高开发者自身水平。与Code Review 相关的插件和工具有很多，例如Java语言中基于Eclipse的ReviewClipse和Jupiter、主要针对Python语言的Review Board等。
Web应用的接口自动化测试大体分为两类：模块接口测试和Web接口测试。
主要测试模块之间的调用与返回。当然，我们也可以将其看做是单元测试的基础。它主要强调对一个类方法或函数的调用，并对返回结果的验证，所用到的测试工具与单元自动化测试相同。
Web接口测试又可以分为两类：服务器接口测试和外部接口测试。
当然，接口测试也有相应的类库或工具，例如测试HTTP的有HttpUnit、Postman等
UI层是用户使用该产品的入口，所有功能都通过这一层提供并展示给用户，所以测试工作大多集中在这一层进行。为了减轻这一层的测试人力和时间成本，早期的自动化测试工具主要针对该层设计。目前主流的测试工具有UFT、Watie、Robot Framework、Selenium等。
除UI层所展示的功能外，前端代码同样需要进行测试。在前端开发中最主要的莫过于JavaScript脚本语言，而QUnit就是针对JavaScript的一个强大的单元测试框架。
下图中的测试金字塔映射了不同测试阶段所投入的自动化测试的比例，UI层被放到了塔尖，这也说明UI层应该投入较少的自动化测试。如果系统只关注UI层的自动化测试并不是一种明智的做法，因为其很难从本质上保证产品的质量。如果妄图实现全面的UI层的自动化测试，那么需要投入大量的人力和时间，然而， 最终获得的收益可能远低于所投入的成本，因为对于一个系统来讲，越接近用户其越容易变化，为了适应这种变化就必须要投入更多的成本。
既然UI层的自动化测试这么劳民伤财，那么我们是不是只做单元测试与接口测试就可以了呢？答案是否定的，因为不管什么样的产品，最终呈现给用户的都是UI层的功能，所以产品才需要招聘大量的测试人员进行UI层的功能测试。也正是因为测试人员在UI层投入了大量的时间与精力，所以我们才有必要通过自动化的方式帮助测试人员解放部分重复的工作。所以，应该更多的提倡“半自动化”的开展测试工作，把可以自动化测试的工作交给工具或脚本完成，这样测试人员就可以把更多的精力放在更重要的测试工作上，例如探索性测试等。
至于在金字塔中每一层测试的投入比例则要根据实际的产品特征来划分。在《Google测试之道》一书中提到，Google对产品测试类型划分为：小测试、中测试和大测试，采用70%（小），20%（中）、10%（大）的比例，大体对应测试金字塔中的Unit、Service和 UI 层。
在进行自动化测试中最担心的是变化，因为变化会直接导致测试用例的运行失败，所以需要对自动化脚本进行不断调整。如何控制失败、降低维护成本是对自动化测试工具及人员能力的挑战。反过来讲，一份永远都运行通过的自动化测试用例已经失去了它存在的价值。
在我们普遍的自动化测试经验中，一般满足以下三个条件就可以对项目开展自动化测试。
1. 软件需求变动不频繁
自动化测试脚本变化的大小与频率决定了自动化测试的维护成本。如果软件需求变动过于频繁，那么测试人员就需要根据变动的需求来不断地更新自动化测试用例，从而适应新的功能。而脚本的维护本身就是一个开发代码的过程，需要扩展、修改、调试，有时还需要对架构做出调整。如果所花费的维护成本高于利用其节省的测试成本，那么自动化测试就失去了它的价值与意义。
一种折中的做法是先对系统中相对稳定的模块与功能进行自动化测试，而变动较大的部分用用工进行测试。
2. 项目周期较长
由于自动化测试需求的确定，自动化测试框架的设计、脚本的开发与调试均需要时间来完成，而这个过程本身就是一个软件的开发过程，如果项目的周期较短，没有足够的时间去支持这样一个过程的话，那么就不需要进行自动化测试了。
3. 自动化测试脚本可重复使用
自动化测试脚本的重复使用要从三个方面来考量：一是所测试的项目之间是否存在很大的差异性（如C/S系统架构与B/S系统架构的差异）；二是所选择的测试技术和工具是否适应这种差异；三是测试人员是否有能力设计开发出适应这种差异的自动化测试框架。
自动化测试的概念有广义与侠义之分：广义上来讲，所有借助工具来辅助进行软件测试的方法都可以称为自动化测试；狭义上来讲，主要指基于UI层的功能自动化测试。
目前市面上的自动化测试工具非常多，下面几款是比较常见的自动化测试工具。
1.UTF
UTF有QTP和ST合并而来，有HP公司开发。它是一个企业级的自动测试工具，提供了强大易用的录制回放功能，同时兼容对象识别模式与图像识别模式两种识别方式，支持B/S与C/S两种架构的软件测试，是目前主流的自动化测试工具。
2. Robot Framework
Robot Framework 是一款基于Python语言编写的自动化测试框架，具备良好的可扩展性，支持关键字驱动，可以同时测试多种类型的客户端或者接口，可以进行分布式测试。
3. Watir
Watir是一个基于Web模式的自动化功能测试工具。Watir是一个Ruby语言库，使用Ruby语言进行脚本开发。
4. Selenium
Selenium也是一个用于Web应用程序测试的工具，支持多平台、多浏览器、多语言去实现自动化测试。目前在Web自动化领域应用越来越广泛。
当然，除上面所列的自动化测试工具外，根据不同的应用还有很多商业的或开源的以及公司自己开发的自动化测试工具。
Selenium主要用于Web应用程序的自动化测试，但并不局限于此，它还支持所有基于Web的管理任务自动化。
Selenium的特点如下：
Selenium IDE是嵌入到Firefox浏览器中的一个插件，实现简单的浏览器操作的录制与回放功能。官方定位：
快速地创建bug重现脚本，在测试人员测试过程中，发现bug之后可以通过IDE将重现的步骤录制下来，以帮助开发人员更容易地重现BUG。
IDE录制的脚本可以转换成多种语言，从而帮助我们快速地开发脚本。关于这个功能在后面的章节中我们会着重介绍。
Selenium Grid是一种自动化的测试辅助工具，Gird通过利用现有的计算机基础设施，能加快Web-App的功能测试。利用Grid可以很方便地实现在多台机器上和异构环境中运行测试用例。
Selenium RC是Selenium家族的核心部分。Selenium RC支持多种不同语言编写的自动化测试脚本，通过Selenium RC的服务器作为代理服务器去访问应用，从而达到测试的目的。
Selenium RC分为Client Libraries和Selenium Server。Client Libraries库主要用于编写测试脚本，用来控制Selenium Server的库。Selenium Server负责控制浏览器行为。总的来说，Selenium Server主要包括三部分，Launcher/Http Proxy和Core。其中，Selenium Core是被Selenium Server 嵌入到浏览器页面中的。其实Selenium Core就是一堆JavaScript函数的集合，即通过这些JavaScript函数，我们才可以实现用程序对浏览器进行操作。Launcher用于启动浏览器，把Selenium Core加载到浏览器页面当中，并把浏览器的代理设置为Selenium Server的Http Proxy。
搞清了Selenium 1.0的家族关系，再来看看Selenium 2.0。Selenium 2.0就是把 WevDriver 加入到了这个家族中，简单用公式表示为：
Selenium 2.0 = Selenium1.0 + WebDriver
需要强调的是，在Selenium 2.0中主推的是WebDriver，可以将其看做Selenium RC 的替代品。因为Selenium为了保持向下的兼容性，所以在Selenium 2.0中并没有彻底地抛弃Selenium RC。如果是初次使用Selenium开发一个新的自动化测试项目，那么可以直接使用WebDriver。
Selenium RC与WebDriver的区别？
Selenium RC是在浏览器中运行JavaScript应用，使用浏览器内置的JavaScript翻译器来翻译和执行selenese命令（selenese是Selenium命令集合）。
WebDriver是通过原生浏览器支持或者浏览器扩展来直接控制浏览器。WebDriver针对各个浏览器而开发，取代了嵌入到被测Web应用中的JavaScript，与浏览器紧密集成，因此支持创建更高级的测试，避免了JavaScript安全模型导致的限制。除了来自浏览器厂商的支持之外，WebDriver还利用操作系统级的调用，模拟用户输入。
Selenium 与 WebDriver 合并原因？
部分原因是WebDriver 解决了Selenium存在的缺点（例如能够绕过JavaScript沙箱，我们有出色的API）。部分原因是 Selenium 解决了WebDriver存在的问题（例如支持广泛的浏览器），部分原因是因为Selenium的主要贡献者和WebDriver的主要贡献者都觉得合并项目是为用户提供最优秀框架的最佳途径。
标签：思维 uft 出现 关于 lock 开发人员 才有 app 研究
原文地址：https://www.cnblogs.com/dongye95/p/10834639.html
