selenium2⾃动化测试实战--基于Python语⾔
⾃动化测试基础
⼀、软件测试分类
1.1 根据项⽬流程阶段划分软件测试
1.1.1 单元测试
  单元测试（或模块测试）是对程序中的单个⼦程序或具有独⽴功能的代码段进⾏测试的过程。
1.1.2 集成测试
  集成测试是在单元测试的基础上，先通过单元模块组装成系统或⼦系统，再进⾏测试。重点是检查模块之间的接⼝是否正确。
1.1.3 系统测试
  系统测试是针对整个产品系统进⾏的测试，验证系统是否满⾜需求规格的定义，以及软件系统的正确性和性能等是否满⾜其需求规格的要求。
1.1.4 验收测试
  验收测试是部署软件之前的最后⼀个测试阶段。验收测试的⽬的是确保软件准备就绪，向软件购买者展⽰该软件系统能够满⾜⽤户的需求。
1.2 ⽩盒测试、⿊盒测试、灰盒测试
  ⽩盒测试与⿊盒测试，主要是根据软件测试⼯作中对软件代码的可见程度进⾏的划分。这也是软件测试领域中最基本的概念之⼀。
1.2.1 ⿊盒测试
  ⿊盒测试，指的是把被测的软件看做⼀个⿊盒⼦，我们不去关⼼盒⼦⾥⾯的结构是什么样⼦的，只关⼼软件的输⼊数据和输出结果。
  它只检查程序呈现给⽤户的功能是否按照需求规格说明书的规定正常使⽤、程序是否能接受输⼊数据并产⽣正确的输出信息。⿊盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界⾯和软件功能进⾏测试。
1.2.2 ⽩盒测试
  ⽩盒测试，指的是把盒⼦打开，去研究⾥⾯的源代码和程序执⾏结果。
  它是按照程序内部的结构测试程序，通过测试来检验产品内部动作是否按照设计规格说明书的规定正常进⾏，检验程序中的每条逻辑路径是否都能按预定要求正确⼯作。
1.2.3 灰盒测试
  灰盒测试介于⿊盒测试和⽩盒测试之间。
  可以这样理解，灰盒测试既关注输出对于输⼊的正确性，同时也关注内部表现。但这种关注不像⽩盒测试那样详细、完整，它只是通过⼀些表征性的现象、事件、标志来判断内部的运⾏状态。有时候输
出是正确的，但内部其实已经错误了，这种情况⾮常多。如果每次都通过⽩盒测试来操作，效率会很低，因此需要采取灰盒测试的⽅法。
1.3 功能测试与性能测试
  从软件的不同测试⾯可以划分为功能测试与性能测试
1.3.1 功能测试
  功能测试主要检查世纪功能是否符合⽤户的需求，因此测试的⼤部分⼯作也是围绕软件的功能进⾏。设计软件的⽬的就是满⾜⽤户对其功能的需求，如果偏离了这个⽬的，则任何测试⼯作都是没有意义的。
功能测试⼜可以细分为很多种：逻辑功能测试，界⾯测试、易⽤性测试、安装测试、兼容性测试等。
1.3.2 性能测试
  性能测试是通过⾃动化的测试⼯具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进⾏的测试。
  软件的性能包括很多⽅⾯，主要有时间性能和空间性能两种。
时间性能：主要是指软件的⼀个具体的响应时间。例如⼀个登陆所需要的时间，⼀个商品交易所需要的时间等。当然，抛开具体的测试环境，来分析⼀次事务的响应时间是没有任何意义的，它需要在搭建好的⼀个具体且独⽴的测试环境下进⾏。
空间性能：主要指软件运⾏时所消耗的系统资源，例如硬件资源，CPU、内存、⽹络宽带消耗等。
1.4 ⼿⼯测试与⾃动化测试
从对软件测试⼯作的⾃动化程度可以划分为⼿⼯测试与⾃动化测试。
1.4.1 ⼿⼯测试
⼿⼯测试就是由测试⼈员⼀个⼀个地去执⾏测试⽤例，通过键盘⿏标等输⼊⼀些参数，并查看返回结果是否符合预期结果。
⼿⼯测试并⾮专业术语，⼿⼯测试通常是指我们在系统测试阶段所进⾏的功能测试，为了更明显地与⾃动化测试进⾏区分，这⾥使⽤了⼿⼯测试这种说法。
1.4.2 ⾃动化测试
  ⾃动化测试是把以⼈为驱动的测试⾏为转化为机器执⾏的⼀种过程。通常，在设计测试⽤例并通过评审之后，由测试⼈员根据测试⽤例中描述的规则流程⼀步步执⾏测试，把得到的世纪结果与期望结果进⾏⽐较。在此过程中，为了节省⼈⼒、时间和硬件资源，提⾼测试效率，便引⼊了⾃动化测试的概念。
⾃动化测试⼜可分为：功能⾃动化测试与性能⾃动化测试。
功能⾃动化测试：是把以⼈为驱动的测试⾏为转化为机器执⾏的⼀种过程。通过测试⼯具（或框架）录制/编写测试脚本，对软件的功能进⾏测试，并验证测试结果是否正确，从⽽代替部分的⼿⼯测试⼯作，达到节约⼈⼒成本和时间成本的⽬的。
性能⾃动化测试：通过性能功能来模拟成千上万的虚拟⽤户向系统发送请求，从⽽验证系统的处理能⼒。
1.5 冒烟测试、回归测试、随机测试、探索性测试和安全测试
这⼏种测试出现在软件测试的周期中，既不算具体明确的测试阶段，也不是具体的测试⽅法。
1.5.1 冒烟测试
  是指在对⼀个新版本进⾏⼤规模的系统测试之前，先验证⼀下软件的基本功能是否实现，是否具备可测性。
  引⼊到软件测试中，就是指测试⼩组在正是测试⼀个新版本之前，先投⼊较少的⼈⼒和时间验证⼀个软件的主要功能，如果主要功能都没有运⾏通过，则打回开发组重新开发。这样做的好处是可以节省时间和⼈⼒投⼊到不可测的项⽬中。
1.5.2 回归测试
  回归测试是指修改了旧代码后，重新进⾏测试以确认修改后没有引⼊新的错误或导致其他代码产⽣错误。
  回归测试⼀般是在进⾏第⼆轮软件测试时开始的，验证第⼀轮软件测试中发现的问题是否得到修复。当然，回归也是⼀个循环的过程，如果回归的问题通不过，则需要开发⼈员修改后再次进⾏回归，直到所有问题回归通过为⽌。
1.5.3 随机测试
  是指测试中的所有输⼊数据都是随机⽣成的，其⽬的是模拟⽤户的真实操作，并发现⼀些边缘性的错误。
  随机测试可以发现⼀些隐蔽的错误，但是也有很多缺点，例如测试不系统，⽆法统计代码覆盖率和需求覆盖率、发现的问题难以重现等。⼀般是放在测试的最后执⾏。随机测试更专业的升级版叫做探索性测试。
1.5.4 探索性测试
  探索性测试可以说是⼀种测试思维技术，它没有很多实际的测试⽅法、技术和⼯具，但却是所有测试⼈员多应该掌握的⼀种测试思维⽅式。探索性测试强调测试⼈员的主观能动性，抛弃繁杂的测试计划和测试⽤例设计过程，强调在碰到问题时及时改变测试策略。
1.5.5 安全测试
  安全测试在IT软件产品的⽣命周期中，特别是产品开发基本完成⾄发布阶段，对产品进⾏检验以验证产品符合安全需求定义和产品质量标准的过程。
  安全测试现在越来越受到企业的关注和重视，因为由于安全性问题造成的后果是不可估量的，尤其是互联⽹产品，最容易遭受各种安全攻击。
⼆、分层的⾃动化测试
  我们应该有更多的低级别的单元测试，⽽不仅仅是通过⽤户界⾯运⾏的⾼层的端到端的测试。
  传统的⾃动化测试我们可以理解为基于产品UI层的⾃动化测试，它是将⿊盒功能测试转化为由程序或⼯具执⾏的⼀种⾃动化测试。
  但是在⽬前的⼤多数研发组织当中，都存在开发与测试团队割裂（部门墙）、质量职责错配（测试主要对质量负责）的问题，在这种状态下，测试团队的⼀个“正常”反应就是试图在测试团队能够掌握的⿊盒测试环节进⾏尽可能全⾯的覆盖，甚⾄是尽可能全⾯的  UI ⾃动化测试。
  这可能会导致两个恶果：⼀是测试团队规模的急剧膨胀；⼆是所谓的全⾯UI⾃动化测试运动。因为UI是⾮常易变得，所以UI⾃动化测试维护成本相对⾼昂。
  分层⾃动化测试倡导的是从⿊盒（UI）单层到⿊⽩盒多层的⾃动化测试体系，从全⾯⿊盒⾃动化测试到对系统的不同层次进⾏⾃动化测试。
2.1 单元⾃动化测试
  单元⾃动化测试是指对软件中的最⼩可测试单元进⾏检查和验证。对于单元测试中单元的含义，⼀般来说，要根据实际情况去判断其具体含义，如C语⾔中单元是指⼀个函数，Java中单元是指⼀个类，图形化的软件中单元是指⼀个窗⼝或⼀个菜单等。总的来说，单元就是⼈为规定的最⼩的被测功能模块。规范的进⾏单元测试需要借助单元测试框架，如Java语⾔的Junit、TextNG，C#语⾔的NUnit，以及Python语⾔的unittest、pytest等，⽬前⼏乎所有的主流语⾔都有其相应的单元测试框架。
  Code Review中⽂翻译为代码评审或diamante审查，是指在软件开发过程中，通过对源代码进⾏系统
性检查的过程。通常的⽬的是查系统缺陷、保证软件总体质量以及提⾼开发者⾃⾝⽔平。与Code Review 相关的插件和⼯具有很多，例如Java语⾔中基于Eclipse的ReviewClipse和Jupiter、主要针对Python语⾔的Review Board等。
2.2 接⼝⾃动化测试
  Web应⽤的接⼝⾃动化测试⼤体分为两类：模块接⼝测试和Web接⼝测试。
2.2.1 模块接⼝测试
  主要测试模块之间的调⽤与返回。当然，我们也可以将其看做是单元测试的基础。它主要强调对⼀个类⽅法或函数的调⽤，并对返回结果的验证，所⽤到的测试⼯具与单元⾃动化测试相同。
2.2.2 Web接⼝测试
postman的中文翻译
  Web接⼝测试⼜可以分为两类：服务器接⼝测试和外部接⼝测试。
服务器接⼝测试：指测试浏览器与服务器的接⼝。我们知道Web开发⼀般分前端和后端，前端开发⼈员⽤HTML/CSS/JavaScript等技术，后端开发⼈员⽤PHP/Java/C#/Python/Ruby等各种语⾔。⽤户的操作是在前端页⾯上，需要后端提供服务器接⼝，前端通过调⽤这些接⼝来获取需要的数据，通过HTTP协议实现前后端的数据传递。
外部接⼝测试：指调⽤的接⼝由第三⽅系统提供。典型的例⼦就是第三⽅登录，例如新上线的产品为了免于新⽤户注册账号的⿇烦会提供第三⽅登录，纳闷⽤户在登录的时候调⽤的就是第三⽅登录的接⼝，⽤户登录信息的验证由第三⽅完成，并返回给当前系统是否验证通过。
当然，接⼝测试也有相应的类库或⼯具，例如测试HTTP的有HttpUnit、Postman等
2.3 UI⾃动化测试
  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. ⽐较频繁的回归测试。
4. 软件系统界⾯稳定，变动少。
5. 需要在多平台上运⾏的相同测试案例、组合遍历型的测试，⼤量的重复任务。
6. 软件维护周期长。
7. 项⽬进度压⼒不太⼤。
8. 被测软件系统开发较为规范，能够保证系统的可测试性。
9. 具备⼤量的⾃动化测试平台。
10. 测试⼈员具备较强的编程能⼒。
在我们普遍的⾃动化测试经验中，⼀般满⾜以下三个条件就可以对项⽬开展⾃动化测试。
1. 软件需求变动不频繁
  ⾃动化测试脚本变化的⼤⼩与频率决定了⾃动化测试的维护成本。如果软件需求变动过于频繁，那么
测试⼈员就需要根据变动的需求来不断地更新⾃动化测试⽤例，从⽽适应新的功能。⽽脚本的维护本⾝就是⼀个开发代码的过程，需要扩展、修改、调试，有时还需要对架构做出调整。如果所花费的维护成本⾼于利⽤其节省的测试成本，那么⾃动化测试就失去了它的价值与意义。
  ⼀种折中的做法是先对系统中相对稳定的模块与功能进⾏⾃动化测试，⽽变动较⼤的部分⽤⽤⼯进⾏测试。
2. 项⽬周期较长
  由于⾃动化测试需求的确定，⾃动化测试框架的设计、脚本的开发与调试均需要时间来完成，⽽这个过程本⾝就是⼀个软件的开发过程，如果项⽬的周期较短，没有⾜够的时间去⽀持这样⼀个过程的话，那么就不需要进⾏⾃动化测试了。
3. ⾃动化测试脚本可重复使⽤
  ⾃动化测试脚本的重复使⽤要从三个⽅⾯来考量：⼀是所测试的项⽬之间是否存在很⼤的差异性（如C/S系统架构与B/S系统架构的差异）；⼆是所选择的测试技术和⼯具是否适应这种差异；三是测试⼈员是否有能⼒设计开发出适应这种差异的⾃动化测试框架。
四、⾃动化测试及⼯具简述
  ⾃动化测试的概念有⼴义与侠义之分：⼴义上来讲，所有借助⼯具来辅助进⾏软件测试的⽅法都可以称为⾃动化测试；狭义上来讲，主要指基于UI层的功能⾃动化测试。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。