面试题总结(测试理论)

admin 管理员组

文章数量: 887016

测试理论

B/S架构和C/S架构区别

1. B/S架构需要重点考虑系统在不同的浏览器中的兼容性问题(浏览器的内核不同)
2. C/S 架构需要考虑系统在不同平台的安装、卸载、升级

HTTP协议

超文本传输协议，应用层协议，由请求与响应组成。
常见的请求方式有POST/GET,常见的状态码200ok，301永久移动，302临时移动，404找不到资源，500服务器内部错误。

POST与GET区别

1. get请求常用在获取数据，post常用于发送数据
2. get请求速度比post稍快
3. get请求的数据是跟随请求地址一起发送，而post是在请求体中单独发送。

Cookie和Session的区别与联系

cookie是存放在浏览器上而session是存放在服务器上的。
cookie不是很安全，涉及到用户隐私方面尽量存放在session中。
当访问量增多时，session会更加占用服务器资源。

测试的目的

发现软件的缺陷与漏洞，对软件的质量进行评估，提升软件质量。

软件测试原则

1. 所有的软件测试都应追溯到用户需求。
2. 尽早地和不断地进行软件测试
3. 完全测试是不可能的，测试需要终止。
4. 充分注意测试中的群集现象。
5. 程序员应避免检查自己的程序。
6. 尽量避免测试的随意性

软件测试分为哪几个阶段？

单元测试、集成测试、系统测试、验收测试

单元测试与集成测试的侧重点

单元测试是对程序最小可测试的模块进行测试
集成测试是把各个模块连接起来时，穿越模块接口的数据是否会丢失。

系统测试范围

功能测试、用户体验测试、性能测试、UI测试、兼容性测试、安装测试、文档测试、稳定性测试等

a测试与ß测试的区别

a测试：公司组织的内部人员进行的测试
ß测试：公司组织的典型客户在实际生活中使用。

验收测试怎么做？

在UAT测试之前，我们会制定测试方案，选择基线用例，即级别高的用例，在UAT测试环境上进行测试，如果测试通过，验收测试就通过了。

白盒、黑盒和灰盒测试区别

白盒测试：对程序的内部结构与算法进行的测试
黑盒测试：不考虑程序的内部结果，只检查程序是否实现了需求的功能
灰盒测试：关注系统接口所实现的功能，是否和需求一致。

冒烟测试的目的

检查程序的基本功能是否正常

回归测试怎么做？

首先，把bug单对应的用例执行一遍，还要检查有数据交互的模块会不会受影响，有没有引入新的问题；项目上线前，还要把当前版本的重要功能以及冒烟测试的用例都回归一遍，确保重要功能上线后不出问题。

全部回归与部分回归的区别？

全量回归：对软件的新版本测试时，重复执行上一个版本测试时使用的测试用例，防止以前没有的问题现在出问题了
部分回归：当开发修复某个bug时，我们需要去检查该bug是否被修复，还需要检查与之相关联的模块是否受到影响。

需求分析的目的

澄清需求，提取测试点

测试计划的目的

规范软件测试内容、方法和过程

什么时候开始写测试计划

需求分析之后

由谁来编写测试计划

一般都是由测试经理或者测试组长来编写

测试计划的内容

测试项目的背景、测试范围和测试策略、测试环境、测试开始和结束条件、进度安排，测试组织，以及与测试有关的风险等方面的内容。

结束条件(项目上线的条件)

需求的覆盖率、用例的执行率和缺陷的遗留率达到质量目标。
通常来说：需求覆盖率和用例执行率需要达到100%
致命/严重的缺陷需要当天解决，轻微/一般遗留率不得超过30%

常见的测试风险

进度风险、质量风险和需求变更

测试用例的要素

用例编号,用例名称,级别,预置条件,测试步骤,期望结果

测试用例级别的划分

一般是依据用户使用该场景的频率，和该功能对系统的影响程度来确定

怎样保证覆盖用户需求？

项目开始前，我们会先熟悉需求，画好流程图，保证整个流程都覆盖全面，小组之间每个人都要根据各自的流程图，各个功能点有哪些限制条件，来讲解一下自己对测试点的理解，防止之后编写测试用例时出现遗漏；用例编写完之后，再进行用例的评审，看看测试点有没有用遗漏，对需求理解有没有错误，测试场景是否覆盖完全。

写好测试用例的关键 /写好用例要关注的维度

1. 覆盖用户的需求；
2. 从用户使用场景出发，考虑用户的各种正常和异常的使用场景；
3. 用例的颗粒大小要均匀。通常，一个测试用例对应一个场景；
4. 用例各个要素要齐全，步骤应该足够详细，容易被其它测试工程师读懂，并能顺利执行；
5. 做好用例评审，及时更新测试用例。

测试用例的状态

常见的测试用例设计方法

1. 等价类
2. 边界值
3. 判定表
4. 场景法
5. 错误推测法

判定表用在哪些时候/哪些功能

• 判定法，是用在不同的输入组合，可能会产生不同的输出这种情况，比如，一个有多个查询条件的查询功能，输入不同的查询条件组合，输出的结果是不一样的，这样的功能就要用到判定表

什么时候用到场景法

• 使用场景法通常是在冒烟测试中或者 一些流程性比较强的软件/功能(比如安装，卸载等等)

测试环境怎么搭建的？

参考答案：搭建环境前，开发都会给到我们一份系统发布手册，我们会根据这个手册来搭建。比如，我这个xx系统，是搭建在Unix系统下的，web服务器用的是Tomcat8，MySQL版本是5.7，程序是JAVA编写的，首先我们向开发拿到编译好的安装包，然后用xshell(或CRT)远程连接上Unix系统，把tomcat服务器停掉，把程序包放到webapps目录下，然后再启动tomcat服务器就可以了。

偶然性问题的处理

1. 发现bug之后，我们会先截图，如果确定是偶然性的问题，会将日志和截图一起提单给开发定位；
2. 如果缺陷在当前版本无法复现，且缺陷的影响程度比较低，可以提交问题单进行跟踪，跟踪三个版本，如果后三个版本都无法复现，就可以关闭该缺陷；
3. 如果是很严重的Bug，比如导致系统崩溃等，并且，实在没有再次出现，除了要及时反馈给上级之外，最后还要写到测试报告中，说明出现了什么现象，但无法再现！

当我们认为某个地方是bug，但开发认为不是bug，怎么处理？

1. 先跟开发沟通，确认系统的实际结果是不是和需求有不一致的地方；有些地方可能需求没提及，但是用户体检不好，我们也可以认为是bug。
2. 如果开发以不影响用户使用为理由，拒绝修改，我们可以和产品经理，测试经理等人员进行讨论，确定是否要修改，如果大家都一致认为不用改，就不改。

产品在上线后用户发现bug，这时测试人员应做哪些工作？

1. 测试人员复现问题后，提交问题单进行跟踪；
2. 评估该问题的严重程度，以及修复问题时的影响范围，回归测试需要测试哪些功能；
3. 问题修复后，先在测试环境上回归，通过后再在生产环境上打补丁，然后再进行回归测试；
4. 总结经验，分析问题发生的原因，避免下次出现同样问题。

二八定理

80%的缺陷出现在 20%的模块。

如何跟踪缺陷

当发现缺陷后，我们要在禅道上提交问题单给开发，并每隔一段时间(间隔一个小时，或两个小时都可以)去检查缺陷是否被处理，如果没及时处理，就要提示开发，让开发及时修复问题，问题修复后，要及时进行回归测试。

缺陷的状态

激活,确认,已解决,关闭

缺陷的等级

致命,严重,一般,轻微

缺陷单应该包含这些要素

缺陷标题，严重级别，问题所属模块，复现步骤，预期结果，实际结果，有关的日志和截图。

测试报告的主要内容

人力投入，用例统计，问题单分类统计，遗留bug情况，测试风险，测试对象评估，测试结论

如何定位bug：

1. 检查测试环境配置是否有问题，测试数据是否有问题
2. 用fiddler抓包，分析请求和响应数据是否存在问题
3. 查看应用服务器的日志
4. 然后再查看数据库的数据是否存在问题

开发没时间修复，如何推进bug的修复：

1. 和开发说明该问题的严重性，会怎样影响产品的正常使用，如何还是坚持不改，就上报领导，让领导辅助推进；
2. 确认问题的严重程度，如果影响不大，不是非要改的bug，并且修复风险比较大，和领导商量后，如果认为暂时可以不用修复，也可以不修复。

软件测试流程

我们这个项目是两个人负责测试的，按模块进行分工，我负责xxx模块。项目启动后，我们会到服务器上下载相关的需求文档，熟悉项目的流程，进行需求澄清，提取测试点；然后编写测试用例，再进行组内的评审，修改，定稿；在开发阶段，开发人员写完一个接口，我们就测试一个接口；等开发转测后，我们从svn上获取安装包，搭建测试环境；之后我们开始进行冒烟测试，冒烟通过后，我们就进入SIT测试，之后进行UAT用户验收测试，验收通过后，编写测试报告。

项目介绍

参考思路：项目叫什么名字，什么架构，有哪些模块，用来干什么的，主要的操作流程

参考：我就说一下最近的一个项目，是集书芸管理系统，主要是一款基于B/S架构的电商分销管理系统，前台模块有店铺首页，购物车，会员中心，申请分销等，后台模块有店铺管理，书籍管理，订单管理，分销管理等，在后台可以上架新的商品，设置店铺活动，管理订单等，用户可以在前台注册成为会员，然后登陆系统，搜索上架的商品，将商品加入购物车之后进行结算下单，或者直接进行结算下单，下单后在用户的‘我的订单’能看到该订单信息，订单状态为待付款，在系统后台的订单管理列表也能看到该订单的信息，买家付款后，订单状态为待发货状态 ，卖家就可以进行发货，买家收到产品后进行确认，评论，整个购物的流程就结束了。这就是我这个项目的大概情况。

对一支圆珠笔进行测试，要从哪些方面进行测试？(扩展：还有可能是对一个水杯，一个注册功能，登陆功能，电梯等，进行测试。)

对任何东西测试一定要从质量的各个方面去说

三角形测试用例设计

解题思路
我们可以设三角形的3条边分别为A，B，C。如果它们能够构成三角形的3条边，必须满足：

A B C均是正数且大于0，还需满足

• A>0，B>0，C>0，且A+B>C，B+C>A，A+C>B。
• 如果是等腰的，还要判断A=B，或B=C，或A=C。
• 如果是等边的，则需判断是否A=B，且B=C，且A=C。
  
  

在项目中发现哪些经典bug？什么原因导致的？

1. 注册信息中的错误提示信息：如手机信息栏应填入11位有效电话号码，但提示信息却为“13位电话号码”，这是因开发人员粗心大意造成的
2. 接口bug：传的字段值为空，但是开发没给默认值设个0导致接收不到
3. 数据用fiddler可以抓包拦截篡改数据
4. 弱网环境下订单可以重复提交
5. 验证码可以重复使用
6. 跑性能测试的时候，当前账号下的订单跑到别的账户上去了每次重新登陆都提示重设支付密码，而且设置的密码不能和上次相同
7. 在未登录的情况下添加商品到购物车跳转到登录页面，登录成功后购物车数量不会增加
8. 第一次提现申请未审核，再继续第二次提现申请无法成功
9. 前台发布出租房源，后台通过审核并且成功加入出租列表，前台搜索失败

一个项目完成时，有多个重要的缺陷没有被修复，但是项目负责人说可以不修改，你认为测试是不通过的，请简述你的理由。

测试是对软件的质量进行的把关，如果一个项目仍然有很多的缺陷未被修复，那么从质量的角度上我们会认为这个软件质量是不达标的，一般来说缺陷的遗留，是不允许严重、致命bug的遗留，轻微和一般的bug遗留率不超过30%。

在需求文档不太详细的情况下，如何开展测试？

1. 首先，把需求文档中有异议的部分标识出来，再找产品和开发一起讨论，把需求明确下来；
2. 提取测试点，然后再叫上产品和开发一起对测试点进行讨论，看有没有遗漏，是不是合理的，
   然后再编写测试用例，再评审，评审通过后，再进行后续的测试。

如何尽快找到软件中的bug?

1. 尽快熟悉公司的产品业务，只有熟悉了产品的业务流程、你才能迅速找出软件中存在的一些重要的缺陷；
2. 把自己当成用户，把自己当成是用户去使用该系统
3. 善于怀疑，不要过于相信开发人员的能力；

什么是bug？

1. 软件未实现需求和规格要求的功能 ；
2. 软件未实现需求和规格未明确提及但应该实现的内容 ；
3. 软件难以理解，不易使用，运行缓慢，或者最终用户(估计会)认为不好；
4. 测试用例执行中发现的与预期结果不符的现象

ATM机吞卡的吞卡现象是不是BUG?

不一定，看是什么情况下吞卡。如：输入三次密码错误吞卡是正常的，不属于BUG；若输入一次密码错误吞卡则是不正常的，属于BUG。

如何减少非问题单的提交？

1. 熟悉项目需求，充分了解各个各个功能模块的功能、参数、约束条件，弄清存在数据交互的模块之间的数据来源、数据流向；
2. 跟产品确认该问题是否属于非问题单。

有个程序，在windows上运行很慢，怎么判断是程序存在问题，还是软硬件系统存在问题？

将程序放在其他的windows上运行，如果运行的还是很慢则是程序的问题。

你们发现bug会怎么处理。

答:发现bug后，我们会先自己定位一下，比如，抓个包，看看是前端的问题，还是后端的问题，检查下数据库的数据是不是正确的，尽量把问题发生的原因或者产生的日志找出来，方便开发定位问题，然后就提单给开发，然后开发做出相应的处理，开发修复完后就进行回归测试，回归测试通过后就关闭这个bug，没有通过就继续给回开发修复。如果遇到开发认为这个不是bug的话，那么我们就要和开发沟通，然后我们要坚持自己的立场，通过讨论后一致认为是bug就给开发修复，不是就关闭这个bug。如果开发和我们意见一直不一致，那么就要将问题升级，召集开发经理和测试经理一起讨论，再做决定。

功能模块测试

支付怎么测试

• 从功能方面考虑：

  1. 正常完成支付的流程；
  2. 支付中断后继续支付的流程；
  3. 支付中断后结束支付的流程；
  4. 单订单支付的流程；
  5. 多订单合并支付的流程；
  6. 余额不足；金额的最小值 ：如0.01；金额为0；金额为负数
  7. 未绑定银行卡；
  8. 密码错误；
  9. 密码错误次数过多；
  10. 找人代付；
  11. 弱网状态下，连续点击支付功能功能，会不会支付多次；
  12. 有优惠券、折扣、促销价进行结算是否正确；
  13. 不同终端上支付：包括PC端的支付、笔记本电脑的支付、平板电脑的支付、手机端的支付等；
  14. 不同的支付方式：银行卡网银支付、支付宝支付、微信支付等；
  15. 支付失败后，再次支付。

• 从性能方面考虑：

  1. 多个用户并发支付能否成功；
  2. 支付的响应时间；

• 从安全性方面考虑

  1. 使用Fiddler拦截订单信息，并修改订单金额，或者修改订单号，(下两个订单A,B，付款时拦截订单B，并把订单B的订单号改为A订单的订单号)无法完成支付；

• 从用户体验方面考虑

  1. 是否支持快捷键功能；
  2. 点击付款按钮，是否有提示；
  3. 取消付款，是否有提示；
  4. UI界面是否整洁；
  5. 输入框是否对齐，大小是否适中等。

• 兼容性

  1. BS架构：不同浏览器测试。

购物车怎么测试？

• 功能测试
  1. 未登录时：将商品加入购物车，页面跳转到登录页面，登录成功后购物车数量增加。
  2. 登录后：
     • 所有链接是否跳转正确；
     • 商品是否可以成功加入购物车；
     • 购物车商品总数是否有限制；
     • 商品总数统计是否正确；
     • 全选功能是否可用；
     • 删除功能是否可用；
     • 价格总计是否正确；
     • 商品文字太长时是否显示完整；
     • 购物车中下架的商品是否有标识，是否还能支付；
     • 新加入购物车商品排序（添加购物车中存在的店铺的商品和购物车中不存在的店铺的商品）；
     • 是否支持快TAB、ENTER等快捷键；
     • 商品删除后商品总数是否减少；
     • 收藏功能是否可用；
     • 购物车结算功能是否可用。
• 兼容性测试
  1. BS架构：不同浏览器测试，比如：IE，火狐，谷歌，360这些。
  2. APP：在主流的不同类型，不同分辨率，不同操作系统的手机上测试，华为，vivo，oppo等
• 用户体验测试
  1. 删除商品是否有提示；
  2. 是否支持快捷键功能；
  3. 是否有回到顶部的功能；
  4. 商品过多时结算按钮是否可以浮动显示；
  5. 购物车有多个商品时，能不能只对单个商品结算；
  6. 界面布局、排版是否合理；
  7. 文字是否显示清晰；
  8. 不同卖家的商品是否区分明显。
• 性能测试
  1. 打开购物车页面要多长时间
• 安全性测试
  1. 加入购物车时，抓包拦截数据

搜索功能怎么测试？

• 功能方面的测试：
  1. 搜索单个字，词语，句子，检索到的内容是否准确，链接是否准确
  2. 长度：例如输入框支持100字符， 那需要测试100字符、101字符，最大长度的显示是否正常；
  3. 哪些是支持的字符类型：数字、字母、汉字、字符！@！#、特殊字符；
  4. 是否支持换行；
  5. 字符串前后中带空格，前后的空格是否过滤， 中间的空格是否保留
  6. 全角半角的字母、数字
• 性能方面的测试
  1. 点击搜索按钮后，搜索结果多长时间能够显示
  2. 进入搜索页面需要多久
• 安全性方面的测试
  1. 能否防止SQL注入攻击,否防止XSS攻击
• 用户体验测试：
  1. 页面布局是否合理，输入框和按钮是否对齐
  2. 输入框的大小和按钮的长度，高度是否合理
  3. 快捷键：能不能全选，部分选择，复制剪切粘贴是否可用，粘贴超过最大长度的字符串怎么显示，table键盘是否可用；
• 兼容性测试
  1. BS架构：不同浏览器测试，比如：IE，火狐，谷歌，360这些。
  2. APP：在主流的不同类型，不同分辨率，不同操作系统的手机上测试，华为，vivo，oppo等

文件上传怎么测试？

• 功能测试
  1. 选择符合要求的文件，上传--------上传成功；
  2. 上传成功的文件名称显示----------显示正常（根据需求）
  3. 查看，下载上传成功的文件--------上传的文件可查看或下载
  4. 删除上传成功的文件-------------可删除
  5. 替换上传成功的文件-------------可替换
  6. 上传文件是否支持中文名称--------根据需求而定
  7. 文件路径是否可手动输入----------根据需求而定
  8. 手动输入正确的文件路径，上传-----上传成功
  9. 手动输入错误的文件路径，上传-----提示，不能上传
• 文件大小测试
  1. 符合格式，总大小稍小于限制大小的文件------上传成功
  2. 符合文件，总大小等于限制大小的文件--------上传成功
  3. 符合文件总大小稍大于限制大小的文件--------在上传初提示附件过大
  4. 小为0kb的txt文档-----------------------不能上传
• 文件名称测试
  1. 文件名称过长。Win2000标准：255个字符（指在英文的字符下），如果是中文不超过127个汉字-----提示过长
  2. 文件名称达到最大长度（中文，英文或混在一起）上传后名称显示，页面排版-----------页面显示正常
  3. 文件名称中包含特殊字符-------------根据需求而定
  4. 文件名全为中文--------------------根据需求而定
  5. 文件名全为英文--------------------根据需求而定
  6. 文件名为中、英混合-----------------根据需求而定
• 文件格式测试
  1. 上传正确格式-----------------上传成功
  2. 上传不允许的格式--------------提示不能上传
  3. 上传rar,zip等打包文件（多文件压缩）---------根据需求而定
• 安全性测试
  1. 上传可执行文件（exe文件）-----------------根据需求而定
  2. 上传常见的木马文件------------------------提示不能上传
  3. 上传时服务器空间已满----------------------有提示
• 性能测试
  1. 上传时网速很慢（限速）-----------------当超过一定时间，提示
  2. 上传过程断网--------------------------有提示是否上传成功
  3. 上传过程服务器停止工资------------------有提示是否上传成功
  4. 上传过程服务器的资源利用率---------------在正常范围
• 界面测试
  1. 界面美观性、易用性（键盘和鼠标的操作、tab跳转的顺序是否正确）----------显示正常（根据需求）
  2. 按钮文字是否正确--------------正确
  3. 正确/错误提示的文字是否正确---------------正确
  4. 说明性文字是否正确-----------------------正确
• 其他测试
  1. 有多个上传框时，上传相同名称的文件---------------根据需求而定
  2. 上传一个正在打开的文件-------------------------可以上传
  3. 文件路径是手工输入的是否限制长度----------------限制一定的长度
  4. 上传过程中是否有取消正在上传文件的功能-----------有
  5. 保存时有没有已经选择好，但没有上传的文件-----------提示上传
  6. 选择好但是未上传的文件是否可以取消选择------------可以取消选择

登录功能怎么测试？

• 功能方面的测试：
  1. 输入正确的用户名和密码，点击提交按钮，验证是否能正确登录，能否能跳转到正确的页面
  2. 输入错误的用户名, 验证登录失败，并且提示相应的错误信息
  3. 输入错误的密码, 验证登录失败，并且提示相应的错误信息
  4. 用户名为空, 验证登录失败，并且提示相应的错误信息
  5. 密码为空, 验证登录失败，并且提示相应的错误信息
  6. 用户名和密码都为空，点击登陆
  7. 用户名和密码前后有空格的处理
• 性能方面的测试
  1. 打开登录页面，需要多长时间
  2. 输入正确的用户名和密码后，登录成功跳转到新页面，需要多长时间
• 安全性方面的测试
  1. 密码是否在前端加密，在网络传输的过程中是否加密
  2. 用户名和密码的输入框，能否防止SQL注入攻击
  3. 用户名和密码的输入框，能否防止XSS攻击
  4. 错误登陆的次数限制（防止暴力破解）
  5. 是否支持多用户在同一机器上登录
  6. 一个用户在不同终端上登陆
  7. 用户异地登陆
• 用户体验测试：
  1. 页面布局是否合理，输入框和按钮是否对齐
  2. 输入框的大小和按钮的长度，高度是否合理
  3. 是否可以全用键盘操作，是否有快捷键
  4. 输入用户名，密码后按回车，是否可以登陆
  5. 牵扯到验证码的，还要考虑文字是否扭曲过度导致辨认难度大，考虑颜色（色盲使用者），刷新或换一个按钮是否好用
• 兼容性测试
  1. BS架构：不同浏览器测试，比如：IE，火狐，谷歌，360这些。
  2. APP：在主流的不同类型，不同分辨率，不同操作系统的手机上测试，华为，vivo，oppo等

还款功能怎么测试？

• 功能：

1. 正常还款流程
2. 逾期还款
3. 不同的还款账户
4. 余额不足还款
5. 弱网状态下，连续点击还款按钮
6. 弱网状态，或系统不稳定，支付服务方未把支付结果返回给下单发起方(如果发生这种问题，结果是，钱扣了，还款状态未发生变化)
7. 金额不输，为0，为负数
8. 提前还款
9. 第三方还款

• 性能：

1. 还款的响应时间是否过长

• 用户体检：

1. 系统提示是否容易理解
2. 界面是否友好，输入框是否对齐，按钮大小是否适中，是否有错别字等

• 安全性：

1. 是否能防止SQL注入，防XSS攻击
2. 还款金额是否会被拦截篡改
3. 还款密码等敏感信息是否加密

• 兼容性：

1. BS架构的系统，要考虑不同浏览器的兼容性
2. APP：考虑在不同分辨率，不同操作系统，不同类型的手机的兼容性

订单怎么测试？

订单怎么测试？(主要测试订单的状态变化)

我们系统的订单生成的流程是这样子的，用户下单后，系统会在用户端和卖家端生成一个待付款的订单，同时在数据库也会生成一个待付款的订单；当用户付款之后，用户端显示待发货状态，卖家端显示已付款待发货状态，订单在数据库的状态为待发货，产品相应的库存量会减少，用户的账户金额减少相应的金额；当卖家发货后，用户端和卖家端的订单状态都显示为配送中，数据库中的订单状态也同时发生变化；当用户确认收货后，订单状态会显示为已完成，待评价状态，数据库中的订单状态也同时发生变化，买家支付的款项会打入到卖家的账户；当用户评论完后，订单状态显示为已结束，数据库中的订单状态也同时发生变化。这是一个正常的流程，我们测试的时候，要优先把这个流程测试通过。

然后再考虑用户的其他使用场景，比如：

1. 用户下单后，取消订单；
2. 下单后，一直不付款，检查订单超时不付款的场景下，会不会自动取消订单；
3. 在订单快超时时，付款；
4. 下单后，在不同的终端登录，一端取消订单，同时一端对该订单进行付款；
5. 弱网状态下，多次点击提交订单按钮，检查是否会生成多个订单；
6. 用户付款后，申请退款，买家端的订单状态为退款申请中，卖家端显示为退款审核；申请退款通过后，订单状态为已关闭状态，买家收到退还的金额；卖家拒绝退款，订单状态为待发货状态；卖家超时不处理退款申请，自动退款，订单自动设置为已退款状态，买家收到退还的金额；
7. 当卖家发货后，买家申请退款，买家端的订单状态为退款申请中，卖家端显示为退款审核；申请退款通过后，订单状态为已关闭状态，买家收到退还的金额；卖家拒绝退款，订单状态为待发货状态；卖家超时不处理退款申请，自动退款，订单自动设置为已退款状态，买家收到退还的金额；
8. 买家收货后，买家申请退款/退货，买家端的订单状态为退款申请中，卖家端显示为退款审核；申请退款通过后，订单状态为已关闭状态，买家收到退还的金额；卖家拒绝款/退货，订单状态为已确认收货状态；卖家超时不处理退款/退货申请，自动退款，订单自动设置为已退款状态，买家收到退还的金额；
9. 买家长时间不确认收货，系统自动确认收货，系统自动设为好评，订单状态为已结束，卖家收到买家的货款；
10. 收货后，超时不评论，系统自动设为好评，订单状态为已结束。
    这些是功能测试的场景，每个场景，我们都要检查数据库对应订单的数据变化。

• 用户体验：

1. 订单界面是否整洁，清晰，文字大小是否适中，订单编号是否能复制；
2. 下单，取消订单，申请退款等功能是否有响应的提示，提示是否合理；
3. 超时时长是否有倒计时提示；
4. 只对订单的部分商品进行发货，订单里的商品发货状态是否分开展示；
5. 是否支持Enter，tab等快捷键。

• 安全性：

1. 使用Fiddler，检查是否能拦截篡改修改订单的信息。

• 兼容性：

1. web端，在不同的浏览器，比如：谷歌，IE，火狐，360上测试；
2. app端，在主流的不同的机型，不同的分辨率，不同的操作系统的手机上进行测试，比如：xxx；

• 性能：

1. 多用户并发下单；
2. 提交订单，取消订单，申请退款的响应时间。

• 可靠性：

1. 多用户长时间运行提交订单功能。

自动化测试

举例来说一下你的自动化测试是怎么做的？

参考答案：就拿简历上的xxx项目来说吧，在编写脚本前，我们会对系统进行评估，确认这个系统可不可以实现UI自动化，如果可以的话，就筛选出能实现自动化测试的用例，一般优先把冒烟测试用例的转为成脚本。我们是用selenium工具来实现自动化，采用python脚本语言，基于unittest框架进行用例的编写。比如，下单这个功能的脚本，我们是这样做的：首先，我们会构建一个测试工程，测试工程包含testcase,主要用来存放测试用例，report用来存放测试报告，其次我们会把用例中公共的部分封装到public中，最后用runAllCase的python文件运行项目自动化用例，脚本调试完后，我们会用jenkins持续集成工具，设置脚本每天晚上10点跑一遍脚本，跑完后生成html格式的自动化测试报告。

自动化脚本失败的原因：

1. 可能是测试环境的网络不稳定；
2. 开发修改了代码没通知到测试人员修改脚本；
3. 开发引入了新的问题。

测试脚本用到了哪些技术？

参考答案：元素定位，表单切换，模块调用，JS定位等等，脚本是基于python自带的unittest单元测试框架，采用了模块化方式编写，把复用性高的操作封装到公共模块中，如果脚本需要用到对应的操作，直接调用就可以了，如果元素发生变化，只需要调整元素封装的代码就可以了，提高测试用例的可维护性。

xpath和CSS定位方式的区别：

1、语法不一样；
2、CSS定位比较稳定。

脚本怎么组织的？(编写自动化脚本，你的思路是什么？)

参考答案：构建一个测试工程，测试工程包含testcase,主要用来存放测试用例，report用来存放测试报告，其次我们会把用例中公共的部分封装到public中，最后用runAllCase的python文件运行项目自动化用例。测试脚本使用的是python的unittest单元测试框架组织管理，将所有测试脚本通过单元测试框架组织起来运行，这样做的好处是，维护起来方便，可以生成测试html格式的测试报告，报告包括：测试用例，通过数，失败数。

自动化率多少？

一般是30%到40%，这个没有固定的，我们是优先将优先级高的测试用例，比如，冒烟测试的测试用例转换成自动化脚本的，后面有时间的时候再不断补充，能写多少写多少。

自动化脚本的通过率是多少？（注意这个题目的意思）

参考答案：这个说不准，如果没有什么异常情况，自动化脚本都是100%运行通过；如果异常情况比较多，比如出现测试环境不稳定，或者开发修改了代码没通知到测试人员及时修改脚本，又或者开发引入了新的问题等等，自动化脚本通过率可能80%都不到。

用那个方法判断元素是否显示

is_displayed()

你曾经都写过多少自动化测试用例？

这个具体没有算过。但是只要有时间，模块稳定的功能都会写。就拿上个项目来说，自动化测试用例大概写了将近有100-120条这样子吧。

python3 的数据类型有哪些？

int (整型)
float (浮点型)
str（字符串）
List（列表）
Tuple（元组）
Set（集合）
Dictionary（字典）

不可变数据（四个）：int (整型)、float (浮点型)、str（字符串）、Tuple（元组）、Set（集合）；
可变数据（两个）：List（列表）、Dictionary（字典）。

面：unittest框架了解吗？

参考答案：unittest框架，由setUp()–环境预置，testCase()— 测试用例 tearDown()----环境恢复，三大部分组成，unittest框架可组织执行测试用例，并且提供丰富的断言方法，判断测试用例是否通过，最终生成测试结果。

怎样用python连接mysql数据。

参考答案：我们之前主要是用python语言来写web端的自动化测试脚本，连接数据库的话，我们主要使用pymysql这个模块来进行连接的。一般在进行完自动化测试之后，我们会连接上数据库，将数据进行清除

用python做过接口测试自动化测试吗？

参考答案：我们之前主要是用python语言来写web端的自动化测试脚，接口是用Jmeter来做的，用python写接口的脚本也在网上学习过,主要使用到requests模块，但是工作中没用用过，到时候工作需要的话，再学一下应该没问题。

元素定位失败的原因

1. 页面的元素未加载完成
2. 元素的属性值不唯一
3. 元素的属性值是动态值
4. 元素在另外一个表单
5. 元素在另外一个页面

自动化脚本，如何切换不同的浏览器

参考答案：使用对应的浏览器驱动，然后在脚本中更换不同的浏览器。

你的python水平很一般啊？(遇到这种否定你的问题，一定不能虚！)

参考答案：我现在掌握的python知识，做ui层的自动化测试是可以的，代码的封装，调用这些都没问题；我一般是会做，但不是很会用文字描述出来，我以注意到这点，现在也在加强提升自己的总结能力。
PS—重点强调：凡是遇到被面试官否定的，都要想办法怼回去，输也要输得精彩些，但是，怼回去的时候，要注意语气，要有礼有节，不卑不亢。

python怎么定义一个函数，怎么定义一个类

def 函数名:
		函数体
class 类名:
		属性
		方法

有些元素，在谷歌浏览器上能定位，在火狐浏览器上定位失败，是什么原因呢？

参考答案：因为不同浏览器的内核不一样，他们的CSS样式不一样。

如何提高selenium脚本的执行速度？

1. 提高网速；
2. 少用sleep，多用隐式等待或显式等待。
3. 提升电脑配置

元素定位的方式有哪些

d.find_element_by_id('id的值')
d.find_element_by_name('name的值')
d.find_element_by_class_name('class的值')
d.find_element_by_tag_name('标签名')
d.find_element_by_link_text('完整的文本链接')
d.find_element_by_partial_link_text('部分的文本链接')
d.find_element_by_css_selector('css表达式')
d.find_element_by_xpath('xpath表达式')
js定位

如何切换iframe

switch_to.frame()

如何切换窗口

switch_to.window()

鼠标悬停的方法是什么

鼠标悬停用到ActionChains类提供的move_to_element方法

如何定位下拉框

需要导入Select类，可以使用下标、值和文本定位

如何获取弹出警告框的text

switch_to.alert.text

什么样的项目适合做自动化

项目周期长，版本多，界面元素稳定的项目

selenium如何做兼容性测试

使用对应的浏览器驱动，然后在脚本中更换不同的浏览器。

为什么会生成HTML报告

使用了HTMLTestRunner第三方工具包来实现的

脚本运行出错，应该怎样定位，说出分析过程

运行结束之后我们会得到一个测试报告，我们根据测试报告先定位一下是脚本的原因还是程序的原因，一般来说脚本的原因在报告中都会显示出哪一行代码出错了，如果是程序的原因通常来说都是断言的问题。

如果系统有验证码，怎么做自动化？

1. 去掉验证码。
2. 设置万能验证码。
3. 用python调用OCR模块，自己写代码来识别。这种方法可以识别出简单的验证码。
4. 调用第三方平台提供的接口进行识别。比如：斐斐打码，尖叫数据这些平台接口。

setUp()，tearDown()和setUpClass()，tearDownClass()的区别：

参考答案：当测试用例有多个，setUp()和tearDown()就会被执行多次；不管测试用例有多少个，setUpClass()和tearDownClass()只会被执行一次。

python的第三方模块/标准库有哪些？

time,random,unittest,selenium,HTMLTestRunner

python的pass语句的作用是什么？

参考答案：占位符，当方法没有内容时，防止出现语法错误。

自动化写过哪些模块的脚本？

参考答案：主要是把冒烟测试的用例转化为脚本，比如，我这个xx商城系统，做自动化的模块有后台的上架商品，订单查询，添加团购活动，促销活动，前台的搜索商品，添加商品到购物车，下单等等。

元素的属性值是动态变化的，怎么定位这个元素？

参考答案：如果元素有属性值是动态变化的，我们就不要使用这个属性进行定位；我们可以使用这个元素的非动态变化，并且是唯一的值属性进行定位；也可以使用xpath或者css，使用层次+属性的方式定位。

webdriver的原理是什么？

参考答案：浏览器的驱动，接收客户端发过来的指令(指令就是我们的脚本)，浏览器的驱动根据接收到的指令，驱动浏览器工作。

你们是怎么检查自动化的结果是不是正确的？

参考答案：我们会用unittest单元测试框架提供的断言方式来检查实际结果和预期结果是否一致，常用的断言方式有assertEqual()，assertIn()，还有一些其他的，不常用就没记了。

怎么样提升自动化脚本成功率

1. 在容易失败的地方&#

本文标签： 面试题 理论 测试