测试面试总结（三）：测试基础知识相关

1.常用的测试用例设计方法：
一般听的比较多的是等价类划分、边界值分析法、错误推测法、因果图法、判定表驱动分析法、正交实验设计法、场景设计法等，但对大多数的软件测试而言，综合使用等价类划分、边界值分析和错误推测这三大类方法就足够了。
等价类划分：
学生信息系统中有一个考试成绩的输入项，成绩的取值范围是0-100之间的整数，考试成绩及格的分数线是60。
设计用例：
有效等价类1:：0-59之间的任意整数
有效等价类2：60~100之间的任意整数
无效等价类1：小于0的负数
无效等价类2：大于100的整数
无效等价类3：0-100之间的任何浮点数
无效等价类4：其它任何非数字字符
边界值分析方法：
设计用例：
选取的边界值应该包括：-1,0,1,59,60,61,99,100,101
错误推测法：
错误推测方法是指基于对被测试软件系统设计的理解、过往经验以及个人直觉，推测出软件可能存在的缺陷，从而有针对性地设计测试用例的方法。这个方法强调的是对被测试软件的需求理解以及设计实现的细节把握，当然还有个人的能力。
比如，Web界面的GUI功能测试，需要考虑浏览器在有缓存和没有缓存下的表现；Web serveice的API测试，需要考虑呗测API锁依赖的第三方API出错下的处理逻辑。

2.Bug定位、分析、类型
Bug一般存在以下三个模块：
1、前台界面，包括界面的显示，兼容性，数据提交的判断，页面的跳转等等，这些bug基本都是一眼可见的，不太需要定位，当然也不排除一些特殊情况，本身数据传过来的时候就有问题，所以显示会出问题的情况。
2、后台程序，包括前台调用的接口，中间层缓存和转发数据，定时任务脚本异步处理数据，程序之间的相互调用等等，而这些bug往往都是不可见的，有可能在功能上体现，也有可能隐藏的深处不易发现，这时候就要通过一些辅助工具以及人工定位代码去判断了。
3、数据库，包括表中缺少字段，字段定义错误，字段长度限制，数据重复等等，这些bug需要通过数据库工具以及一些基本的数据库查询语句来定位，当然前提是要对每个表，每个字段甚至每一个值代表什么意思有一定的了解（一些常用的重要的表，字段，值就可以了）。比如Sql Server可以用Sql Profile追踪sql语句，定位数据库错误。
3.Fiddler定位bug
fiddler 是我们在测试中常用的抓包工具。那我们一般使用fiddler 工具来抓取请求信息来进行分析，一般有以下几种情况：

第一种情况：fiddler 在没有设置过过滤器的情况下面没有抓到请求信息，可能是前端页面元素没有绑定事件，也有可能是前端发生了JS 错误，这就是前端的bug 。

第二种情况：若抓取到的请求返回的结果错误，我们要确认一下，是否是前端传输的数据是错的，是的话就是前端的bug ，如果确定传值是正确的话，那就是后端的bug 。

第三种情况：若抓取到的请求返回值中间的http 的状态码是500的话，说明是后端服务器一般的内部错误，那这就是后端的bug 。

第四种情况：若抓取到的请求返回值中间的http 的状态码是404的话，说明可能后端服务器根本就没有对应地址的服务，当然还有可能是前端JS 提交请求的时候提交了错误的地址。

4.测试计划、测试策略、测试方案的区别。
测试计划要包括：测试范围、测试策略、测试资源、测试进度和测试风险评估这五大方面，并且每一部分都要给出应对可能出现问题的解决办法。

• 测试范围：描述的是被测对象以及主要的测试内容。测试范围的确定通常是在测试需求分析完成后进行，由于不可能进行穷尽测试，而且测试的时间和资源都是有限的，所以**测试范围需要明确“测什么”和“不测什么”。

• 测试策略：测试策略简单来讲就是需要明确“先测什么后测什么”和“如何来测”这两个问题。
  需要说明，采用什么样的测试类型和测试方法。不仅需要说明为什么要选用这个测试类型，还要详细说明具体的实施方法。
  第一，功能测试（考虑自动化的话，通常应该先实现主干业务流程的测试自动化） 第二，兼容性测试
  第三，性能测试，对应性能测试，需要在明确了性能需求（并发用户数、响应时间、食物吞吐量等）的前提下，结合被测系统的特点，设计性能测试场景并确定性能测试框架。

• 测试资源：通常包括人和测试环境。测试计划的目的就是，保证在有限资源下的产出最大化，所以，测试资源就是需要明确“谁来测”和“在哪里测”这两个问题。

• 测试进度：测试进度主要描述各类测试的开始时间，所需工作量，预计完成时间，并以此为依据来建议最终产品的上线发布时间。

• 测试风险预估：在制定测试计划时，要预估整个测试过程中可能存在的潜在风险，以及当这些防线发生时的应对策略。（常见的风险：需求变更、开发延期、发现重大缺陷和人员变动等）

总结：测试范围需要明确“测什么”和“不测什么”；测试策略需要明确“先测什么后测什么”和“如何来测”；测试资源需要明确“谁来测”和“在哪里测”；测试进度是需要明确各类测试的开始时间，所需工作量和预计完成时间；测试风险评估是需要明确如何有效应对各种潜在的变化。

5.说一下你对软件测试的深刻心得。

• 测试需要掌握的技能：测试人员需要掌握的技能除了学习软件测试的通用技术与针对某类软件的测试技术之类，还有一个重要的与技术无关的方面：业务知识。我们在测试过程中如果没有具体的业务知识很难发现软件中潜在的逻辑错误甚至是需求上的错误，软件测试人员对需求的深入程度不应该低于软件开发人员，并且识别需求后还必须转化为测试上的需求。
• 工作感受：(1)重视软件测试在整个软件生命周期中的重要性。需求分析后就应该开始展开测试，保证测试贯穿在整个软件开发过程中，确保整个软件开发过程是高质量的
  (2)软件测试的真正意义在于发现错误，而不是验证软件是正确的
• 工作tip：(1).标准文档的指定 (2)测试资料及时归档

6.如果编写bug，提交的bug包括哪些内容？

• bug标题： 对“什么问题”的描述不仅要做到清晰简洁，要足够具体，不能采用过于笼统的描述；要尽可能的描述问题的本质且不易过长。
• 缺陷概述： 是缺陷标题的细化，清晰简洁地描述缺陷，使开发工程师能够聚焦缺陷的本质。
• 环境版本： 为缺陷的重现提供必要的版本信息。
• 重现步骤：
  [前置条件]：测试步骤开始前系统应该处在的状态，其目的是减少缺陷重现步骤的描述。
  [缺陷重现步骤]：操作步骤通常是从用户角度出发来描述的，每个步骤都应该是可操作并且是连贯的。 [期望结果]：来自对需求的理解
  [实际结果]：来自于测试执行的结果
• 优先级和严重程度：依据bug的影响和该模块用户使用的频率，综合考虑制定bug的严重程度，通常定义三种级别：Low（低级）、Major（主要）、Critical（严重）
• bug原因分析：可选，如果在发现缺陷的同时，定位出问题的根原因，清楚地描述缺陷产生的原因并反馈给开发工程师，那么开发工程师修复缺陷的效率就会大幅提升，而且你的技术影响力也会被开发认可。
• 附件： 界面截图、测试用例日志、服务器日志等
• 指派给（开发） ：负责该问题修复的开发，或者指派给该项目的开发负责人再有其指派。

7.bug的状态：

• New：新建bug
• Ongoing：修复中，通常开发开始处理bug，把状态从new改为ongoing，或者开发修复完成后，测试验证还有问题，把状态从fixed改为ongoing
• Fixed：开发已修复
• Verified：测试已验证，bug关闭
• Pending：暂时不处理该bug
• Won’t fix：已知是bug，但不处理该bug
• Invalid：bug无效

8.测试报告应该包括哪些内容：
偷懒，懒得整理了，放一个网上跟我们公司差不多的模板链接，谢谢博主：https://www.cnblogs.com/dashu123/p/11722154.html

9.什么是冒烟测试？
冒烟测试是在软件开发过程中的一种针对软件版本包的快速基本功能验证策略，是对软件基本功能进行确认验证的手段，并非对软件版本包的深入测试，一般都是最基础的一些功能，如果能做到自动化，可以集成到持续集成中，版本构建结束后，立即去执行冒烟测试，根据持续集成以及冒烟脚本的执行结果，判断版本是不是可用，是不是继续开展测试。