测试基础---复习

不管你是想做软件功能测试、软件安全测试、软件测试开发等，只要跟软件测试或软件质量沾边，那么工作中都必须具备一定的软件测试理论知识；并且求职测试或质量保证相关岗位的面试过程，可能必问一两个的软件测试理论的问题，来考察对应聘者的软件测试思维或是对软件测试的认识。

文本内容主要来源于拉勾自动化测试训练营的学习内容，以问答形式记录软件测试理论可能问到的高频面试题。欢迎点赞评论！或许值得你在面试前可以翻出来看看哦！

一.软件测试基础理论

1.0.软件测试的定义与意义是什么？

软件测试的定义：在规定的条件下对程序进行操作，以发现错误，对软件质量进行评估的一个过程；

软件测试的意义：提前发现潜在的安全隐患，避免出现损失，降低风险。为了发现软件存在的问题，为了保障软件的质量，还是为了给市场业务价值保障？作为软件测试从业者，我也经常问自己类似这样的问题，我们软件测试/软件质量保障做的一切工作活动，一定是为了保障业务交付。软件测试工程师要打造发现问题的能力，同样也需要有打造高稳定性的能力。我们需要对每次发现的问题都剖析如何能避免问题再次发生或更早阶段识别，同时对遗漏的问题都深入思考，以及剖析为什么没能提前发现，如何在下次避免此类问题的发生。

1.1.软件测试的基本原则有哪些？

• 基于用户角度去发现问题
• 测试左移：越早介入测试越好
• 不可能穷举测试
• 二八原则：出现BUG的模块，出现更多BUG的可能性更高
• 不仅要设计正向的用例，还需要设计反向的用例
• 测试依赖于上下文：测试不能只关注需求本身，还要考虑关联的上下游等诸多因素

1.2.软件测试的状态有哪些？

• 静态测试
  不用运行程序的测试，就是静态测试。
  主要是指代码走读：按照需求逻辑，阅读源代码，阅读SQL语句。
  在测试人员经验充足的情况下，进行静态测试可以发现很深入的问题。
• 动态测试
  需要运行程序时才能进行的测试就是动态测试。

1.3.软件测试一般要做哪些方面的测试？

• 功能测试

只需考虑需要测试的各个功能，不需要考虑整个软件的内部结构及代码.一般从软件产品的界面、架构出发，按照需求输入数据，然后对结果进行测试。功能测试也包括了对产品功能的稳定性、兼容性、可靠性测试等；

• 性能测试

通过自动化技术，对软件的各项性能指标进行测试评估的过程。一般必须功能稳定后才能进行性能测试。

• 安全测试

站在防御者的角度，尽可能的发现软件安全隐患的过程。安全测试的知识点很分散，互联网任何技术领域的问题，都有可能导致安全问题出现，所以安全测试是最难精通，也是最容易应用的。

1.4.自动化测试比例与优缺点是什么？

• 理论比例
  10%UI自动化
  20%接口自动化
  70%单元测试
• 自动化测试优缺点
  优点
  • 可以解决难以测试的场景
  • 可以快速回归测试

缺点

• • 不能完全替代手工
  • 脚本维护困难
  • 技术要求高，难以推广

1.5.什么是白盒、黑盒、灰盒测试？

或者问“软件测试的类型有哪些？”

• 白盒测试

完全清楚代码逻辑，针对代码进行的测试。

测试方法主要包括：路径覆盖、语句覆盖、条件覆盖、判定覆盖（分支）

在软件测试中，白盒测试一般由开发自己完成，测试不介入。

• 黑盒测试

完全不清楚代码逻辑，只按照需求设计输入数据，然后对输出进行验证的过程。

• 灰盒测试

介于白盒和黑盒之间的测试。

1.6.白盒测试和黑盒测试有哪些区别？

答：1、白盒测试可以更早介入测试，而黑盒测试需要等系统开发完成才能进行测试；

2、黑盒测试对测试人员技术要求较低，甚至普通人也可以进行黑盒测试，但往往只能检查到系统功能使用层面的bug；而白盒测试需要的技术水平较高，对代码测试的更加全面、具体，能发现深入的隐藏问题；

3、黑盒测试从用户角度去测试系统，更加直接找到用户在使用时系统可能产生的问题；白盒测试不能从用户角度去寻找BUG，且无法穷举程序中所有可能的逻辑路径（特别是有循环的场景）；

1.7.软件测试常用策略有哪些？

用尽可能少的时间，发现更多的BUG。

执行测试：

• 冒烟测试
• 探索性测试策略
• 回归测试重点针对新增功能和BUG进行测试

1.8.什么是流程化测试和精准化测试？

流程化测试是在路径覆盖的基础上提出的概念，主要是基于控制流来覆盖代码的测试方法；流程覆盖强调的是操作业务流程时，运行的代码流路径。这样，就能够把业务流程和代码中的路径流整合起来。流程化测试的度量标准是流程覆盖率=进行白盒测试时经过的路径 / 业务子集路径；

精准化测试是在流程覆盖的基础上，进一步升级的概念；精准化测试强调代码调用链与黑盒测试用例的关联；精准化测试通过记录执行用例时影响的代码，来标注出每一条测试用例，对应的代码；精准化测试的优点是可以统计代码覆盖率、缩减测试范围、指导探索性测试、利用线上数据推导有效测试用例；

1.9一个完整的测试流程会经历哪些过程或阶段？

开发提测

开发把代码写好，并且自测通过后，就会把发起提测

发起方式： QQ、微信、邮件、公司内部通讯公司和口头通知等方式来告知测试提测了，常见的是发邮件；

测试环境搭建

开发提测后，必须进行环境搭建才能执行测试。

测试环境的搭建方式根据公司的规模和流程，主要分为三种

• 开发或者运维帮助搭建，测试只需要按照要求执行测试即可；
• 开发提测时后，上传代码到指定位置，测试只需要使用公司提供的持续集成平台，点击部署即可；
• 开发提测时，以附属方式，附上环境搭建的核心代码，然后测试搭建；

（一般中大型公司都是第二种）

准入测试

环境搭建完成后，测试在执行正式的测试之前，需要进行一次“冒烟测试”，也就是准入测试。

主要目的是为了判断产品是不是处于“可测试”的状态。

准入测试时，主要是执行核心功能的测试，而不关注细节。

例如：电商中，能不能注册、登陆、下单、支付；物流中，能不能发货、取货、退货；

执行测试

• 执行方式
  • 优先执行优先级高的用例
  • 优先执行重要的功能模块
  • 优先执行影响范围广的功能
• 执行过程
  • 查看和收集执行过程中产生的日志，记录执行过程日志
  • 执行用例时，每执行一条，都标记执行结果，记录执行过程用例
  • 执行发现的问题，都需要提单记录，在测试过程中，记忆不靠谱
• 执行结果
  • 高优先级BUG，大力推进修复，时刻关注。
  • 中优先级BUG，周期性关注
  • 低优先级BUG，如果事情很多，可以先存着，找空闲的时间一起提

缺陷跟踪和管理

执行测试时，或多或少都会发现一些问题，这时候就需要进行缺陷跟踪和管理了，

在这里，我们需要使用缺陷管理工具记录和管理缺陷，同时，也需要对缺陷的来源有一个初步的分析。

缺陷管理工具

• 禅道、Jira、TestLink等；

缺陷来源

缺陷来源有很多，一般可以分成这6个部分

• 开发新增功能的BUG
• 开发修复BUG引发的BUG
• 需求变更引发的BUG
• 第三方模块的BUG
• 历史遗留BUG
• 兼容性BUG

执行测试过程的经验总结

• 测试人员一般都是一边熟悉项目需求、一边进行测试，在此过程中，为了保证效率，主要进行探索性测试。项目没有完全了解透彻时就开展测试是“测试工作日常”。
• 执行时，发现BUG后一定要记录

结果阶段

执行完成后，一般就需要输出测试报告了

输出测试报告的前提条件 ：

测试用例执行率达到100%，没有普通级别以上的BUG，剩余BUG经过项目组评估之后，确认可以遗留后，那么才能够发布测试通过的报告

• 测试输出测试报告
• 运维根据输出的测试报告准备发布上线
• 发布上线

二.项目管理相关

2.1.描述项目流程包含哪些阶段？

答：项目流程包含立项阶段、需求阶段、开发阶段、测试阶段、项目发布阶段；

①立项阶段，可分为有用户时的立项和没有用户时的立项：有用户的立项是用户指定要开发某某产品，有明确的功能；无用户的立项， 一般基于人类自身兴趣、市场分析等来源进行立项；

②立项后，到了需求阶段，由产品经理角色来分析用户需求，设计产品内容；

③需求确定后，进入开发阶段，首先进行项目排期，包括开发、测试、上线排期；接着开发在开发排期内完成编码与单元测试，测试撰写测试用例并召开测试用例评审会议；

④进入测试阶段，测试根据测试用例执行测试，发现并跟踪回归测试bug，测试完成后输出测试报告；

⑤项目上线前开发封版，测试进行整体回归测试，开发发布与执行上线流程，产品经理进行线上效果验证；

2.2.软件测试左移/右移定义、作用及实施方法；

答：测试左移的定义是：向开发移动；作用是可以让提测的代码质量更高；实施方法是测试进行单元测试，代码走读，代码审计；

测试右移的定义是向运维移动；作用是可以监控代码质量，为快速发现问题，解决问题进行保障；测试右移的实施方法是利用自动化技术，部署监控环境稳定性的脚本；

2.3.软件开发模型有哪些？

传统的软件开发模型有：边做边改型、瀑布模型、快速原型、螺旋模型；还有 近些年流行的敏捷开发模型、DevOps；

2.3.1.你了解什么是敏捷开发模型吗？

敏捷模型是现在非常流行的开发模型，主要是因为现在项目的度量方式是用产品数量来度量，所以管理人员偏向于“先有产品，再优化迭代”的开发思想。

而敏捷开发具备快速开发、快速迭代的特点，所以目前市场上敏捷开发特别火；

2.3.2.敏捷开发开展方式是怎样的？

1、首先确定一个产品需求列表;

2、然后根据产品需求列表，通过冲刺任务计划会议，来从中挑选出一个故事作为本次迭代完成的目标，这个目标的时间周期是1~4个星期，然后把这个故事进行细化，形成一个冲刺任务列表

3、冲刺任务列表是由敏捷管理团队去完成的，每个成员根据冲刺任务列表再细化成更小的任务（细到每个任务的工作量在2天内能完成）；

4、敏捷管理团队完成计划会议上选出的冲刺任务列表过程中，需要进行每日站立会议，每次会议控制在15分钟左右，每个人都必须发言，并且要向所有成员当面汇报你昨天完成了什么，并且向所有成员承诺你今天要完成什么，同时遇到不能解决的问题也可以提出，每个人回答完成后，在看板前更新自己的 燃尽图（任务完成情况图）

5、做到每日集成，也就是每天都要有一个可以成功编译、并且可以演示的版本。

6、当一个故事完成，也就是冲刺任务被完成，也就表示一次冲刺完成，这时，我们要进行演示会议，也称为评审会议，产品负责人和客户都要参加（最好本公司老板也参加），每一个敏捷管理团队的成员都要向他们演示自己完成的软件产品。

7、最后就是回顾会议，也称为总结会议，以轮流发言方式进行，每个人都要发言，总结并讨论改进的地方，放入下一轮冲刺的产品需求中；

2.3.3.你知道什么是DevOps吗？有什么优点？

DevOps看作开发（软件工程）、技术运营和质量保障（QA）三者的交集；

DevOps在项目流程中的位置：

DevOps实施过程：

• 持续开发
  通过敏捷模型来推动持续开发
• 持续测试
  通过持续集成的技术，通过自动化的技术进行自动持续的测试
• 持续集成
  每天周期性的提交代码到平台，并自动构建，打包，单元测试，还反馈测试结果
• 持续交付
  自动搭建测试环境，自动运行自动化测试代码，自动发布
• 持续监控
  部署持续监控服务器相关资源的工具，来监控软件运行是否稳定。

优点：

• 减少变更范围
• 加强协调
  有的开发模型中，有项目经理来协调运维、测试、开发角色来管理发布
• 自动化

2.4.软件测试模型有哪些，分别有什么优缺点？

V模型、W模型、H模型；

V模型的优点：测试过程非常清楚；缺点：测试最后才介入；

W模型的优点：能够让测试更早的介入；缺点：因为实用W模型时，会产生更多的文档，所以会带来维护困难的问题；

H模型的优点：

• 软件测试完全独立
• 软件测试活动可以尽可能早的准备，灵活性很强

H模型的缺点：

• 测试就绪点很难分析
• 对项目组人员技术要求较高

2.5.软件质量模型有哪些？

国际标准：ISO9126

国标标准：GBT25000.10-2016；

2.5.1.软件质量是什么？

软件质量是指在特定的使用条件下产品满足明示的和隐含的需求所明确具备能力的全部固有特性（内在特性），体现了产品满足产品要求的程度（外部表现），是产品的质量属性。 从概念分析对应到我们实际的测试工作，包括了三个要素：产品（我们的被测对象）、特性集合（需要采用哪些测试类型）、需求（覆盖的测试场景）。

2.5.2说说你了解的 ISO9126

ISO9126主要从6个特性和27个子特性去测试和评价软件的功能：

①功能性：

1、适合性：提供了相应的功能

2、准确性：正确（用户需要的）

3、互操作性：产品与产品之间交互数据的能力

4、保密安全性：允许经过授权的用户和系统能够正常的访问相应的数据和信息，禁止未授权的用户访问.......

5、功能性的依从性：国际/国家/行业/企业 标准规范一致性

②可靠性：

产品在规定的条件下，在规定的时间内完成规定功能的能力

1、成熟性：防止内部错误导致软件失效的能力

2、容错性：软件出现故障，自我处理能力

3、易恢复性：失效情况下的恢复能力

4、可靠性的依从性

③易用性：

在指定使用条件下，产品被理解、 学习、使用和吸引用户的能力

1、易理解性：

2、易学性：

3、易操作性：

4、吸引性：

5、易用性的依从性：

④效率性：

在规定台条件下，相对于所用资源的数量，软件产品可提供适当性能的能力

1、时间特性：平均事务响应时间，吞吐率，TPS（每秒事务数）

2、资源利用性：CPU 内存 磁盘 IO 网络带宽 队列 共享内存

3、效率依从性：

⑤软件维护性："四规"，

在规定条件下，规定的时间内，使用规定的工具或方法修复规定功能的能力

1、易分析性：分析定位问题的难易程度

2、易改变性：软件产品使指定的修改可以被实现的能力

3、稳定性：防止意外修改导致程序失效

4、易用测试性：使已修改软件能被确认的能力

5、维护性的依从性

⑥软件可移植性：

从一种环境迁移到另一种环境的能力

1、适应性：适应不同平台

2、易安装性：被安装的能力

3、共存性：

4、易替换性

5、可移植性的依从性：

三.软件测试方法（黑盒与白盒）

3.1.黑盒测试

3.1.1.黑盒测试的测试用例设计方法有哪些？

1、等价类：把所有可能的输入数据（字母、数字、特殊字符）,即程序的输入域划分成若干部分（子集）,然后从每一个部分中选取少数具有代表性的数据作为测试用例；等价类划分输出的数据时，需要根据需求的规定来划分，规则按照软件体系的结构可以分为6条。

2、边界值法：边界值法就是对输入或输出的边界值进行测试，是作为对等价类划分法的补充，其测试用例来自等价类的边界。使用边界值法设计测试用例时，需要覆盖上点（边界上的点）、离点（离边界最近的点）、内点（范围内的点）；

3、判定表：判定表一种表达逻辑判断的方式，由条件、动作组成；在设计业务时，任何业务都有条件和满足条件的动作，所以实现时，我们需要先列出所有的条件，然后列出满足不同的条件时的动作，最后根据选择的条件，来填写满足的动作

4、状态迁移图：状态迁移图是对特定系统需求设计测试用例的方法之一，适合用在状态特别多的测试场景；

状态迁移图的实现步骤有4步：1.根据需求画出状态迁移图；2.通过状态迁移图画出状态转换树；3.从状态转换树推导出测试路径；4.根据测试路径编写合法测试用例；

5、场景分析法：从用户的角度来设计测试用例；实现的步骤有3步：1、根据需求画出基本流（核心流程）和备选流（分支流程）；2、根据基本流和备选流画出场景；3、将场景转化为测试用例；

6、正交分析法：是研究多因子多状态组合的一种设计方法，使用正交分析法，可以完美解决多因子的两两组合场景，并对更高维度的混合场景也能有一定的覆盖；使用正交法时，要先分析出因子和状态，再选择对应的正交表，得出实验次数。应用场景一般是浏览器兼容性测试、多条件多状态的查询功能测试等有多因子、多状态的场景测试；正交分析法是一种面向用户的测试用例设计方法

常用的主要有等价类、边界值法、场景分析法；

3.1.2.了解等价类法测试用例设计吗？

主要从定义、规则、应用场景回答；

定义

是把所有可能的输入数据,即程序的输入域划分成若干部分（子集）,然后从每一个部分中选取少数具有代表性的数据作为测试用例.

规则

输入数据包括：字母、数字、特殊字符

等价类划分输出的数据时，需要根据需求的规定来划分，规则按照软件体系的结构可以分为6条。

• 当规则中有数值范围 时，可以确定一个有效等价类和2个无效等价类
  例如用户名长度4-20，那么小于4和大于20是无效等价类，4-20任取一个是有效等价类
• 当规定了取值的内容为N个时，那么可以确定N个有效等价类和1个无效等价类。
  例如：订单状态有：未付款、已付款、已结束3种状态，那么我们可以确定可以测试未付款、已付款、已结束3个有效等价类和1个无效等价类。无效等价类得状态名可以是任何无效的名字。如：aaa
• 当规定了输入的数据是必须输入的，那么可以确定1个有效等价类和1个无效等价类。
  例如：注册用户时，规定只能用手机号码注册，那么我们使用手机号码注册是有效等价类，使用非手机号码注册，是无效等价类。
• 当规定了输入数据的规则时，可以确定1个有效等价类和若干个无效等价类。
  例如：购物车中，可以买同一个商品1-99个。那么1-99中任选一种是有效等价类。选择0、-1、100、a等是无效等价类。
• 当输入的数据是布尔类型时，可以确定一个有效等价类和一个无效等价类。
• 在确知已划分的等价类中各元素在程序处理中的方式不同的情况下,则应再将该等价类进一步的划分为更小的等价类。
  例如：支付时，有支付宝支付、微信支付、银联支付等不同的支付方式。但是银联支付时，又可能选择农业银行、中国银行等不同的银行，支付宝支付内部也可以选择银联支付。那么这个时候，我们需要划分得更细。

应用场景：

有输入框的界面可以采用等价类法来进行用例设计；

3.1.3.了解边界值法测试用例设计吗？

定义

定义：边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，其测试用例来自等价类的边界。

规则

• 对于有范围的数据，对数据边界上的边界值进行测试。
• 边界中，主要有闭区间、开区间、半开半闭区间
  使用边界值法设计测试用例时，需要覆盖上点、离点、内点
  闭区间： [1，10] 包括两端的值 也可以表示为： 1≥X≤10
  设计闭区间案例时，需要覆盖两端和两端向外的里端点最近的值
  覆盖X=1 X=10的两个上点 X=0 X=11两个离点的值，覆盖内点X=5
  开区间 ：(1, 10) 不包括两端的值 也可以表示为： 1>X<10
  设计闭区间案例时，需要覆盖两端和两端向内的值最近的值
  覆盖X=1 X=10上点 X=2 X=9 离点 的值，以及覆盖X=5的内点
  半开半闭区间：(1, 10] , [1, 10) 一半包括一半不包括
  如果是 1>X≤10 那么覆盖 X =1 X=10 X=2 X=11的值

应用场景：

有关于数值的输入都可以采用边界值法来进行用例设计，比如用户注册登录功能、购物车结算功能；

3.1.4.了解场景分析法测试用例设计吗？

可以从定义、实现步骤、应用场景来作答；

定义

场景：用户实际使用的情景。

从用户的角度来设计测试用例，是一种面向用户的测试用例设计方法。

优点：设计出来的用例价值大

缺点：不能覆盖全面

实现步骤

第一步：根据需求画出基本流和备选流

基本流：核心流程

备选流：分支流程

第二步：根据基本流和备选流画出场景

第三步：将场景转化为测试用例

应用场景：

关于业务流程的测试可以采用场景分析法来进行用例设计；

3.2.白盒测试方法

3.2.1.白盒测试的作用于优缺点？

作用：一般通过白盒测试，能发现80%的BUG。

优点

• 测试能够更早介入测试
• 对代码测试的更加全面、具体，能发现深入的隐藏问题

缺点

• 需要的技术水平较高
• 不能从用户角度去寻找BUG
• 无法穷举程序中所有可能的逻辑路径（特别是有循环的场景）

3.2.2.白盒测试常见代码覆盖率有哪些？

白盒测试常见代码覆盖率包括：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖、路径覆盖；

语句覆盖：覆盖每一行代码

判定覆盖：使得程序中的每一个判断至少获得一次“真”和一次“假”，每一个真假分支至少被执行一次；

条件覆盖：每个判定表达式中的每个条件都取到各种可能的结果；

判定/条件覆盖：既满足判定覆盖，又满足条件覆盖；

条件组合覆盖：不仅覆盖所有条件，还需要把条件的组合场景也考虑到；

路径覆盖：覆盖所有的路径；

四.设计测试用例与缺陷管理

4.1测试用例

4.1.1测试用例的必要要素有哪些？

答：设计测试用例时，元素非常多，但一般8个元素是必须要有的

• 用例编号
• 用例标题
• 所属项目/模块
• 优先级
• 测试数据
• 前提条件
• 执行步骤
• 预期结果

4.1.2这些用例要素有什么作用？

答：用例编号：用来记录用例的序号；

用例标题：标记用例干什么，一般不超过15个字；

所属项目/模块：描述该条用例所属的项目和项目中的模块；

优先级：越高意味者越需要优先执行。在之前我司工作中，划分优先级的方式是P0、P1、P2、P3；

P0：核心功能：主流程的业务功能（冒烟测试）

P1：高，核心功能上的分支功能

P2：中，普通级别功能，出现问题不会让程序崩溃，但是会影响程序小部分功能的使用

P3：低，易用性功能，出现问题完全不影响使用，但是会影响用户的细节的感受。

测试数据：根据需求规定来设计的，测试时要输入的数据；

前提条件：执行用例之前，必须达到的条件；

执行步骤：执行用例的操作步骤，这个步骤最繁琐，也很耗时间，之前我司是空缺或列个大概；

预期结果：执行用例后预期的结果，实际与预期不一样时，证明有BUG。

4.1.3你觉得写测试点或测试用例有什么好处？

1、 理清测试思路

通过编写用例，清楚该如何进行测试；

2、 明确测试工作量

通过测试用例，我们可以评估测试的时间，就能知道测试任务的工作量了；

3、 用于推广，引导新人

对于不熟悉软件的新人，可以让他们从测试用例执行开始熟悉工作。

4.1.4.你设计测试用例数据的方法是什么？

根据个人实际工作经验，总结了一个套设计测试用例设计的实用工作技巧。

• 用思维导图代替EXCEL编写用例
• 用例设计无非就是对输入数据进行测试，先忽视需求，我们可以知道输入任何数据，都会有
  • 为空
  • 为null
  • 长度范围（低于最小长度、最小长度、最小最大之间的有效长度、最大长度、超过最大、超过最大到不科学的长度）
  • 数据类型（整形、字符串、浮点数、列表等）
  • 业务特定的数据（订单状态：1，2，3分别表示不同的订单状态

这5类测试点。
也有一些特殊数据，如日期、金额等

• • 日期：闰年、润月、大小月、时分秒（24小时，60分，60秒）
  • 金额：负数，0，小数精度，上限等

按照需求设计用例内容即可。

4.1.5.做功能测试，从哪些维度思考，用例设计？

• 对于需求规定的功能，100%全部覆盖
• 界面测试
• 字体、颜色、背景、布局、超链接、页面跳转
• 兼容性测试
• 浏览器本身不同版本的兼容性
• 代码不同版本的兼容性
• 接口测试
• 安全测试
• 性能测试

4.2.缺陷管理

4.2.1.缺陷的生命周期是怎样的？

• 测试人员发现缺陷后，在缺陷管理平台创建一个缺陷，指派给开发负责人，这时候缺陷处于激活状态；
• 然后，开发负责人把BUG指派给开发，开发解决后，BUG处于解决状态
• 接着，测试验证”解决“状态的BUG，验证通过就关闭。不通过则重新打开指派给开发。
• 在此期间，如果BUG有争议，那么可以让测试经理和开发经理来协商解决。

4.2.1.常见的BUG类型主要有哪些？

• 代码错误
• 设计缺陷
• 界面优化
• 性能问题
• 配置问题
• 新增功能
• 历史遗留
• 第三方BUG等

4.2.3.如果遇到不容易复现的bug要如何处理？

答：1、对bug进行详细记录，包括详细的操作步骤与bug现象，并尽量保存截图与操作日志；

2、尽快将bug提交给开发人员定位问题；

3、此外，测试人员若有一定的技术基础可以尝试直接定位该模块代码去追踪bug;

4.2.4.如果遇到研发对bug有异议如何解决？

当与开发出现分歧时，测试应该首先分析与评估问题，分析该bug到底属于设计需求文档的缺陷、安全性问题、界面缺陷，有兼容性错误或影响用户体验等哪类问题；

其次，测试要明确开发认为不是bug的原因：比如bug偶发、难以复现，或者存在技术难点，还是设计逻辑有问题，代码逻辑正确等原因；

再次，给bug问题归类、找出开发不愿修改的原因后，具体问题具体分析；分析什么bug让开发觉得不是bug;

比如是bug难以修复、测试人员描述不清晰、功能性bug等等；

最后，测试与开发交涉过程中注意沟通方式，若实在无法达成一致，则向上反馈，找项目经理、产品经理或其他领导一起开会讨论，并将解决方法形成备忘录，以防下次出现同样的问题；

4.2.5.你怎么定位一个bug是前端的问题还是后端的问题？

可以通过开发者工具分析和服务器日志来完成；

• 打开开发者工具
• 按照用例执行操作
• 分析前端控制台提示和接口请求，可以初步确认前后端BUG；
• 查看服务器产生的日志，二次确认前后端bug
  新人进入公司时，一般都不知道日志文件在哪里，可以问下开发日志文件的位置；
  最后分析日志，确认是前端问题还是后端问题。
  • 如果服务器没有日志，那么一般都是前端问题；
  • 如果服务器有日志，可以根据日志报错，具体分析是前端问题还是后端问题；

五.工作场景题

5.1.你是如何开展软件测试的？

答：以之前测试工作流程为例：

1.项目立项并召开需求评审会议，测试大致了解产品需求后，根据需求文档与产品原型进行制定测试计划与测试方案；

2.使用Xmind或Excel撰写测试点和测试用例，并邀请产品经理与开发同事进行测试用例评审，查缺补漏；

3.部署测试环境，配置测试环境各参数，根据测试用例执行测试；

4.使用JIRA记录并提交bug给开发同事修改，阻塞性bug督促当天尽快修复，普通bug隔天或统一时间修复，待开发修复bug后进行回归测试；

5.测试完成后，撰写测试总结报告，并提前1天向部门总监发送项目申请邮件，上线前的半天对项目进行整体/主流程/修改处进行回归测试，确保上限代码没问题；

5.2请结合你测试过的xxx项目，详细描述测试流程。

答:以智慧物业商城项目为例，1.首先根据需求文档与需求评审会议，使用Xmind撰写系统每个模块的测试点；

2，进行测试左移-单元测试，使用Junit或Jacoco工具对项目的主要接口进行单元测试；

3，执行接口测试，根据智慧物业商城项目的接口文档，使用Jmeter或Postman工具设置相应的入参，查看返回数据是否正确；

4.进行功能测试，根据每个系统模块的测试点，分别执行功能测试，首先执行冒烟测试，确保每个（子）模块的核心业务流程是通过的，比如小区管理模块中，对于我的小区这个子模块的核心流程是：运营添加小区→运营审核添加小区→物业申请入驻小区→运营审核申请入驻→物业管理小区；在确保这个核心流程通过无误后，“所见即所测”，对模块的其他所有功能点进行一一测试；

5.进行性能测试，编写性能测试脚本，添加智慧物业商城项目的接口，设置运行时间后，查看性能指标，比如吞吐量；

6.进行安全测试，借助安全测试工具，如BurnSuite；对智慧物业商城项目的代码进行常见的安全测试，比如漏洞扫描、SQL注入（可使用SQLMap工具）、XSS攻击、敏感信息泄露分析；

5.3.你设计了多少条测试用例，发现了多少个Bug，严重的有多少、普通的有多少？

在过去的工作中，我已经不记得设计了多少条测试用例了。但是我有经验，知道为什么要统计这些用例数据，

主要是为了分析Bug的分布，从而进行缺陷分析，进而达到优化代码、优化流程、优化组织结构的目的。

PS：如果你刚好从一个项目抽身出来，恰好记得，那么直接说即可。

5.4.如果我选择了你，你能为我们公司带来什么价值？

快速上手工作，保障产品质量，融入测试团队，搭建测试环境，努力成为团队的技术核心；

5.5.如果没有需求文档，如何测试，如何设计测试用例？

1.对比行业竞品，根据竞品分析需求

2.根据经验设计或根据已有界面，基于用户使用角度进行设计

5.6.如何测试一杯水（谷歌经典面试题）？

按照ISO质量标准，描述如何进行测试一定不会错。

用质量标准展开测试：6大特性（功能性、可靠性、易用性、可移植性、效率、维护性)

功能：水能不能喝 水杯花纹，水杯的重量、体积等等

可靠性：水杯从不同高度扔下来，会不会摔碎

易用性：水杯是不是很容易使用

可以移植性：水是不是可以从一个水杯导入另一个水杯

效率：性能：沸点、冰点、溶解度、比热容、PH值、放着不动多久会渗透（纸杯）、温度

维护性：查看水杯会不会显示这个水的一些特性，相关的测试方法

安全性：水杯会不会伤手，是否有毒

5.7.有“查询文章中，重复单词出现次数“的功能，如何对其进行功能测试例设计？

需求如下：

• 统计文章中出现的单词总数
• 统计每个单词出现的次数，如果只出现一次，则显示该单词出现次数为1，两次为2，依次类推
• 只能统计英文单词
• 以空格做分隔符

可以从一下方面作答：

测试是否为英文

测试是否为英文空格

设计一篇文章，文章用特殊字符@分割，查看这个筛选功能是否只能统计出一个大单词；

文章中，包含中文，测试筛选功能是否能够正常统计单词数量；

文章中，设计只出现一次的单词，查看是否能够正常统计，统计结果应该是每个单词只出现一次

文章中，设计出现多次的单词，查看是否能够正常统计；

文章中，单词数目是100个，每个单词只出现1次，那么单词总数应该是100，每个单词出现1次；

文章中，单词数目是100个，每个单词只出现2次，那么单词总数应该是100，每个单词出现2次；

文章中，单词数目是3个Hello，World，zhangsan，其中Hello出现3次，World出现4次，zhangsan出现5次那么单词总数应该是3，每个单词,Hello出现3次，World出现4次，zhangsan5次；

设计单词最大长度：设计一个长度达到1M的大单词，查看是否能够统计

设计单词最小长度：a a a 查看是否只统计到了a，出现3次

文章为空，查看筛选功能是否正常；

可支持最大的文件（文章）大小：设计一个100M的文章，查看是否能够被解析；