测试面试宝典

目录 1.B/S架构和C/S架构区别 c是客户端 b是浏览器2.HTTP协议3.POST与GET区别4.Cookie和Session的区别与联系5.测试的目的6.软件测试原则7.软件测试分为哪几个阶段？8.单元测试与集成测试的侧重点9.系统测试范围10.a测试与ß测试的区别11.验收测试怎么做？12.白盒、黑盒和灰盒测试区别13.冒烟测试的目的14.回归测试怎么做？15.全部回归与部分回归的区别？16.需求分析的目的17.测试计划的目的18.什么时候开始写测试计划19.由谁来编写测试计划20.测试计划的内容21.结束条件(项目上线的条件)22.常见的测试风险23.测试用例的要素24.测试用例级别的划分25.怎样保证覆盖用户需求？26.写好测试用例的关键 /写好用例要关注的维度27.测试用例的状态28.常见的测试用例设计方法29.判定表用在哪些时候/哪些功能30.什么时候用到场景法31.测试环境怎么搭建的？32.偶然性问题的处理33.当我们认为某个地方是bug，但开发认为不是bug，怎么处理？34.产品在上线后用户发现bug，这时测试人员应做哪些工作？35.二八定理36.如何跟踪缺陷37.缺陷的状态38.缺陷的等级39.缺陷单应该包含这些要素40.测试报告的主要内容41.如何定位bug：42.开发没时间修复，如何推进bug的修复：43.软件测试流程44.项目介绍45.对一支圆珠笔进行测试，要从哪些方面进行测试？三角形测试用例设计46.在项目中发现哪些经典bug？什么原因导致的？47.一个项目完成时，有多个重要的缺陷没有被修复，但是项目负责人说可以不修改，你认为测试是不通过的，请简述你的理由。48.在需求文档不太详细的情况下，如何开展测试？49.如何尽快找到软件中的bug?50.什么是bug？51.ATM机吞卡的吞卡现象是不是BUG?52.如何减少非问题单的提交？53.有个程序，在windows上运行很慢，怎么判断是程序存在问题，还是软硬件系统存在问题？54.你们发现bug会怎么处理。

---

1.B/S架构和C/S架构区别 c是客户端 b是浏览器

CS响应速度快，安全性强，用户体验好，一般应用于局域网中，但是开发维护成本高，；BS可以实现跨平台，客户端零维护，但是个性化能力低，响应速度较慢。所以有些单位日常办公应用BS，在实际生产中使用CS结构

2.HTTP协议

HTTP协议定义Web客户端如何从Web服务器请求Web页面，以及服务器如何把Web页面传送给客户端。HTTP协议采用了请求/响应模型。客户端向服务器发送一个请求报文，请求报文包含请求的方法、URL、协议版本、请求头部和请求数据。服务器以一个状态行作为响应，响应的内容包括协议的版本、成功或者错误代码、服务器信息、响应头部和响应数据

3.POST与GET区别

1、GET使用URL或Cookie传参。而POST将数据放在BODY中。
2、GET的URL会有长度上的限制，2kb，则POST的数据则可以非常大。
3、POST比GET安全，因为数据在地址栏上不可见。
4、一般get请求用来获取数据，post请求用来发送数据

4.Cookie和Session的区别与联系

Session和Cookie的主要区别在于：
Cookie是把数据保存在浏览器端的内存中
Session把数据保存在服务器端的内存中
cookie与session的联系：
当服务器端生成一个session时就会向客户端发送一个cookie保存在客户端，这个cookie保存的是session的sessionId。。这样才能保证客户端发起请求后客户端已经登录的用户能够与服务器端成千上万的session中准确匹配到已经保存了该用户信息的session，同时也能够确保不同页面之间传值时的正确匹配。

5.测试的目的

1.软件测试的目的是为了保证软件产品的最终质量，在软件开发的过程中，对软件产品进行质量控制。一般来说软件测试应由独立的产品评测中心负责，严格按照软件测试流程，制定测试计划、测试方案、测试规范，实施测试，对测试记录进行分析，并根据回归测试情况撰写测试报告。测试是为了证明程序有错，而不能保证程序没有错误。

6.软件测试原则

所有测试bai的标准du都是建立在用户需求之上zhi的，测试的目的在于dao发现系统是否满足规定的需zhuan求；

“尽早地和不断地测试”，越早进行测试，缺陷的修复成本就会越低；

程序员应避免检查自己的程序，由第三方进行测试更客观有效；

穷举测试是不可能的；

充分注意测试中的群集现象，一段程序中一发现的错误数越多，其中存在的错误概率越大，因此对发现错误较多的程序段，应进行更深入的测试；

设计测试用例时应包括合理输入和不合理输入，以及各种边界条件、特殊情况下要制造极端状态和意外状态；

注意回归测试的关联性，往往修改一个错误会引起更多错误；

测试应从“小规模”开始，逐步转向“大规模”；

测试用例式设计出来，不是写出来的，应根据测试的目的，采用相应的方法设计测试用例，从而提高测试的效率，更多的发现错误，提高程序的可靠性；

重视并妥善保存一切测试过程文档（测试计划，测试用例，测试报告等）；
对测试错误结果一定要有一个确认的过程

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

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

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

单元测试是在软件bai开发过程du中要进行的最低级别的zhi测试活动，在单元dao测试活动中，软件zhuan的独立单元将在与shu程序的其他部分相隔离的情况下进行测试，测试重点是系统的模块，包括子程序的正确性验证等。

集成测试，也叫组装测试或联合测试。在单元测试的基础上，将所有模块按照设计要求，组装成为子系统或系统，进行集成测试。实践表明，一些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作。程序在某些局部反映不出来的问题，在全局上很可能暴露出来，影响功能的实现。测试重点是模块间的衔接以及参数的传递等。

9.系统测试范围

黑盒测试。不接触代码，只对整个系统做功能的测试和性能的测试。

10.a测试与ß测试的区别

11.验收测试怎么做？

用户验收测试是软件开发结束后，用户对软件产品投入实际应用以前进行的最后一次质量检验活动。它要回答开发的软件产品是否符合预期的各项要求，以及用户能否接受的问题。

用户验收测试可以分为两个大的部分：软件配置审核和可执行程序测试，其大致顺序可分为：文档审核、源代码审核、配置脚本审核、测试程序或脚本审核、可执行程序测试。

由于验收测试不只是检验软件某个方面的质量，而是要进行全面的质量检验，并且要决定软件是否合格，因此验收测试是一项严格的正式测试活动。需要根据事先制订的计划，进行软件配置评审、功能测试、性能测试等多方面检测

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

白箱测试或白盒测试(White-box testing 或glass-box testing)是通过程序的源代码进行测试而不使用用户界面。这种类型的测试需要从代码句法发现内部代码在算法，溢出，路径，条件等等中的缺点或者错误，进而加以修正。

　　黑箱测试或黑盒测试(Black-box testing)是通过使用整个软件或某种软件功能来严格地测试, 而并没有通过检查程序的源代码或者很清楚地了解该软件或某种软件功能的源代码程序具体是怎样设计的。测试人员通过输入他们的数据然后看输出的结果从而了解软件怎样工作。通常测试人员在进行测试时不仅使用肯定出正确结果的输入数据，而且还会使用有挑战性的输入数据以及可能结果会出错的输入数据以便了解软件怎样处理各种类型的数据。

　　灰箱测试或灰盒测试(Gray-box testing):灰箱测试就像黑箱测试一样是通过用户界面测试，但是测试人员已经有所了解该软件或某种软件功能的源代码程序具体是怎样设计的。甚至于还读过部分源代码。 因此测试人员可以有的放矢地进行某种确定的条件/功能的测试。这样做的意义在于:如果你知道产品内部的设计和对产品有透过用户界面的深入了解，你就能够更有效和深入地从用户界面来测试它的各项性能。

13.冒烟测试的目的

冒烟测试是为了在运行性能测试或压力测试之前，确保一切都已正确配置并可按预期运行

14.回归测试怎么做？

1、在测试策略制定阶段，制定回归测试策略
2、确定需要回归测试的版本
3、回归测试版本发布,按照回归测试策略执行回归测试
4、回归测试通过，关闭缺陷跟踪单（问题单）
5、回归测试不通过，缺陷跟踪单返回开发人员，开发人员重新修改问题，再次提交测试人员回归测试

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

16.需求分析的目的

第一、把用户需求转化为功能需求：
	1）对测试范围进度量    
	2）对处理分支进行度量   
	3）对需求业务的场景进行度量  
    4）明确其功能对应的输入、处理和输出   
    5）把隐式需求转变为明确。

第二、明确测试活动的五个要素：测试需求是什么、决定怎么测试、明确测试时间、确定测试人员、确定测试环境：测试中需要的技能，工具以及相应的背景知识，测试过程中可能遇到的风险等等。测试需求需要做到尽可能的详细明确，以避免测试遗漏和误解。

17.测试计划的目的

1、测试的目的是为bai了发现尽可能多的缺陷，不是du为了说明软件中没有缺陷。
2、成功的测试在于发现了迄今尚未发现的缺陷。所以测试人员的职责是设计这样的测试用例，它能有效地揭示潜伏在软件里的缺陷。

18.什么时候开始写测试计划

有了详细的产品需求说明书后，在系统设计阶段就应该写系统测试方案，系统测试计划并开始详细设计测试用例了。

19.由谁来编写测试计划

1.项目经理
项目经理当然是从整个项目角度出发，编写整体项目计划，那么其中就包括测试的计划了，他依赖于对应的开发计划，也就是首先要有开发计划、提测计划，再评估测试计划，最终得出上线时间

2.测试经理
测试经理主要是从测试组角度出发，编写项目的测试计划，重点就是项目的任务拆分、合理的安排人力资源、预估时间和风险等

3.测试人员
测试同学本人收到测试经理同步过来的具体分工后，也需要编写自己的测试计划，重点就是详细的说明自己的时间规划、每一个测试任务的前期准备以及开始和结束测试的时间等

20.测试计划的内容

	测试背景
	测试目的
	确定测试范围
	制定测试策略（功能测试/业务测试..）
	测试资源安排
	测试时间安排
	测试人员分配
	风险评估

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

22.常见的测试风险

1、需求风险

产品需求的不明确，对产品需求理解不准确，导致测试范围存在误差，遗漏部分需求或者执行了错误的测试方式；另外需求变更导致测试用例变更，测试用例维护成本增加，实时更新时存在误差。

2、测试用例风险

测试用例设计不完整，忽视了边界条件、异常输入等情况，用例覆盖率没有做到足够覆盖，测试用例没有得到全部执行，有些用例被有意或者无意的漏测，需求变更导致的测试时间被压缩等情况。

3、缺陷风险

某些缺陷偶发，难以重现，容易被遗漏；缺陷跟踪不够积极主动，没做好缺陷记录和及时更新，同样的缺陷，导致的原因可能不同，对这点没意识到导致的线上生产问题等。

4、代码质量风险

代码质量差，可读性差，重构性差，没做好注释等原因导致缺陷较多，修改难度增大；另外还有系统架构设计的不足，导致的扩展性不足，性能兼容差等问题。

5、测试环境风险

测试环境和生产环境配置不同，测试环境交叉影响较大，测试环境数据量不足导致的测试结果误差等问题。

6、测试技术风险

某些项目存在技术难度，测试能力和经验所限，技术水平相对较差导致测试进展缓慢，测试结果准确性不够，项目发布日期延期等问题。

7、回归测试风险

回归测试，一般时间相对来说较少，且大多只回归主要的功能点用例，可能造成漏测；另外还有回归验证缺陷时业务流走不通导致的打回修复再验证造成的时间延后问题。

8、沟通协调风险
项目进行过程中需要多方沟通协调，不同部门，岗位之间的沟通、协作，难免存在误解、沟通不畅的情况，比如需求变更没有及时沟通，开发代码提交没有及时告知，测试结果的反馈不及时等问题。

9、研发流程风险

其中包括从产品需求评审、研发设计、代码提交、测试发布等一些列流程，流程的不规范不协调很可能导致很多问题；比如开发在不告知其他成员的情况下提交代码，发布没有预生产环境，生产出现

问题无法及时回滚等很多说烂了的情况。流程没必要一板一眼的执行，但没有流程是万万不行的。 

10、其它不可预计风险
一些突发状况、不可抗力等也构成风险因素，且难以预估和避免。对于这种情况，往往一时无法解决，建议做好备份方案和容灾机制，或者采用灰度发布等措施。

PS:以上是测试过程中可能发生的风险及原因，其中有的风险是难以避免的，如缺陷风险；有的风险从理论上可以避免，如需求风险，沟通风险等；还有些风险在实际操作过程中出于时间和成本的考虑，

也难以完全回避，如回归测试风险等。
对于这些风险的存在，要尽量避免，也要做好备份方案和容灾机制，规范流程，明确职责，尽可能将风险降到可接受范围内。。。

23.测试用例的要素

用例编号，所属模块，用例描述，前置条件，优先级，输入数据，操作步骤，预期结果，实际结果，测试人员，测试时间

24.测试用例级别的划分

高（Highs）：保证功能性是稳定的，是按照需求的正常使用和实现点进行用例设计的，重要的错误和边界测试的测试用例的集合。

中（Mediums）：更全面的验证功能的各方面，包括流程中的各个节点出错情况、异常情况测试、中断、UI展示、用户体验等方面的测试用例设计

低（Lows）：不常被执行的测试用例。比如压力和性能测试用例设计，接口测试用例设计随着时间的推移已经从低级别变化到了中级别。

25.怎样保证覆盖用户需求？

首先，确认需求

面试官简单描述这道题后，你是否真的已经了解了他的需求呢，如上描述，需求范围过于笼统，也就是要明确用户故事。请问这个需求是怎样的项目背景或基于什么前提下而做的；会涉及到哪些支撑平台；具体需要怎样的权限可以上传操作；该功能的迭代会影响到哪些其他的存量功能等，是否有明确的性能需求等

第二，梳理需求，确认测试范围
是否需要考虑历史数据，数据来源，用户角色，支持哪些操作系统，兼容性要求（考虑平台兼容性、浏览器兼容性、手机型号 版本等），是否提供接口文档，DB设计文档等等

第三，制订测试计划
通过测试需求与测试范围，制订测试计划，我需要运用到的测试方法，工作量预估，测试资源，每个节点的测试类型，以及结束测试标准等等（可以针对此面试题来描述）
测试计划需要经过项目组干系人评审通过后才可以进行下一步

第四，根据测试计划设计测试用例
当然，此步会根据个人习惯和经验来适当增减，如先使用思维导图理出测试想法， 然后再扩展。可以按可接受性测试用例、系统测试用例（接口、功能、性能、安全、UI、DB...）来开始设计用例。这样就可以按照所学的N+测试方法来充分设计Case了，而有了测试计划中的相关策略来指导 ，也不会疏漏其他的需求点了。

第五，后续的执行测试步骤（可以依情况来作描述）我们暂且就此面试题展开分析 ，故不作深入探讨 。

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

做好测试用例工作的关du键是要充分考虑测试计划zhi的实用性，坚持5W1H的原则，dao采用评审和更新机制以及测试策略。要充分考虑测试计划的实用性，即测试计划与实际之间的接近程度和可操作性。要坚持“5W1H”的原则，明确测试内容与过程。采用评审和更新机制，确保测试计划满足实际需求。因为软件项目是一个渐进的过程，中间不可避免地会发生需求变化，为满足需求变化，测试计划也需要及时地进行变更。测试策略要作为测试的重点进行描述。测试策略是测试计划中的重要组成部分，测试计划是从宏观上说明一个项目的测试需求、测试方法、测试人员安排等因素

27.测试用例的状态

通过，失败，未执行，无效，阻塞，不适用

28.常见的测试用例设计方法

等价类划分，边界值，错误推测，因果图，场景法，正交表

应用的场景
	等价类划分
		多用于输入框：注册/登录
	边界值（掌握上点和离点的取值）
		多和等价类划分结合使用，有边界限制的:注册的密码长度，，
	场景法	
		从基本流开始，再将基本流和备选流结合起来，可以确定用例场景   银行取钱
	正交表	
		用于多个下拉框之间的组合，可以通过正交助手生成测试用例
	错误推测
		错误猜测法是测试经验丰富的人喜欢使用的一种测试用例设计方法。
		一般这种方法是基于经验和直觉推测程序中可能发送的各种错误，有针对性地设计。只能作为一种补充
	因果图
		因果图法比较适合输条件比较多的情况，测试所有的输入条件的排列组合。所谓的原因就是输入，所谓的结果就是输出
        自动贩卖机  

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

判定表方法是黑盒测试方法的一种，主要用于输入和输出比较多，功能逻辑比zhuan较复杂的情况，通过画出判定表缕清需求中的功能逻辑，

30.什么时候用到场景法

 案例1：ATM取款

   步骤1：熟悉需求，整理业务过程，列出基本流和备选流。

    基本流：成功取款的流程

  识别卡-->输入正确密码-->选“取款”功能-->选择正确的取款金额-->点击“确定”，给出提示，出钞，更新账户和ATM余额

   备选流：取款失败的各个场景

      1）识别卡失败

      2）输入错误密码：

       3次以内--给出提示，重新输入

       3次--锁卡并吞卡

      3）账户余额不足

      4）每次取款上限5000元

      5）每天取款上限20000元

      6）ATM机余额不足

 步骤2：生成场景，填写《场景表》

 步骤3：根据场景，设计测试用例。

   说明：场景和用例不一定是1:1的比例

    有可能1个场景需要多条用例

    也有可能1条用例能测试多个场景

31.测试环境怎么搭建的？

测试环境=软件+硬件+网络+数据准备+测试工具

32.偶然性问题的处理

　　一、一定要提交!!

　　1. 记得有这么个缺陷，以后再遇到的时候可能就会了解发生的原因。

　　2. 尽力去查找出错的原因，比如有什么特别的操作，或者一些操作环境等。

　　3. 程序员对程序比测试人员熟悉的多，也许你提交了，即使无法重新，程序员也会了解问题所在。

　　4. 无法重现的问题再次出现后，可以直接叫程序员来看看问题。

　　5. 对于测试人员来说，没有操作错误这条.既然遇到，就是问题。即使真的操作错了，也要推到程序员那里，既然测试人员犯错误，用户也可能会犯同样的错误。错误发生的时候，Tester最大。

　　二、程序不是测试人员写的，出问题也不是测试人员的原因。

　　至于无法重现，可能的原因很多，因为测试人员看到的只是程序的外部，无法深入程序内部，所以把责任推给测试人员是不对的。

　　测试人员的任务只是尽力重现问题，而不是必须重现!!

　　三、下次再遇到的时候，拉他们来看就可以了。

　　因为问题如果无论如何无法重现，程序员确实也没有什么好的解决方法。

　　而且此类问题即使程序员说修改了，测试员也没有好的方法去验证是不是。 : )

　　四、你可以告诉程序员，测试过程是没有错误的。

　　测试人员只是检查程序中可能存在的问题，虽然测试人员使用一定的手段方法努力去覆盖所有的情况，但这些都是理论的推测。在实际中，可能因为人员、环境、配置等种种原因出现各种各样的问题，在测试人员这里发现问题是公司内部的事情，程序发到外面可就是公司的形象问题了。

　　需要让程序员理解，测试人员是帮助他们的，不是害他们的。

　　客户那里发现问题比测试员发现问题结果要严重的多。

　　五、测试部门是独立与开发部门的呀，真的打交道，也是经理对经理。

　　在我们这里，工作上面的事情，和程序员相互只能商议解决，并没有谁高谁低。

　　问题无法重现，也要提出，程序员那里可以回复无法再现。问题放在那里，等到再次出现的时候，就立刻叫程序员过来查看。

　　实在没有再次出现，最后可以写到报告中，说出现了什么现象，但无法再现(比较严重的问题才如此处理，小问题经理之间商量商量可能就算了)。

　　至于测试人员必须重现bug，你杀了我好了，我每次测试项目都有无法重现的问题，很多我能找到大概的原因，有些根本无法重现(仅仅出现一次)。

　　这种事情是无法避免的，并不能说测试人员无法重现问题，就是工作不到位(哼，程序有bug，是否可以说程序员工作不到位的呀)。

　　六、测试部门要独立，最好不受开发的制约。其实真正要重视，就应该有否决的权利。

　　我们公司就是项目承包，要拿最后的项目尾款，就要测试部签字通过，这样就避免了很多的问题。

　　其实只要自己尽到心就可以了，管别人怎么说呢。

　　七、我们使用的状态有：

　　程序员处理的状态(由测试员提交的Action)：等待处理的，再次出现的。

　　测试员处理的状态(由程序员提交的Action)：已经修改的，暂不修改的，系统限制的，使用错误的，无法再现的。测试员可以修改记录。

　　经理处理的状态(由测试员提交Action)：管理员处理的。经理还可以删除记录。

　　按照比较标准的说法，其实对于缺陷还应该有“等待确认的”、“已经确认的”和“重复提交的”的状态，我们为了省事，统一使用了“等待处理的”。

　　最后结项的时候，缺陷的状态对我们来说有两种，“已经关闭的”(由测试员或经理确认)和“暂不修改的”(比如下一个版本处理等)。

　　呵呵，状态多，有些烦琐，特别是程序员很多的时候都不清楚应该回复什么状态，但我个人觉得对测试人员来说，这些状态比较清晰明了，容易处理。

　　八、一个叫doer_ljy(可战)的网友回复了一些内容，我个人认为不很妥当，就回复了一些内容，绿颜色的是doer_ljy(可战)的内容：

　　关于“无法重现”我看是有这么个问题存在。

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

1.首先我会从自身去经过多次的测试发现BUG出现的次数和频率 记录复现BUG的方式  然后发送给开发人员
2.再根据需求文档来确认是否为BUG
3.如果开发不认为是BUG的将复现BUG的记录和需求文档找产品经理和项目经理来确定是否BUG
4.如果项目经理和产品经理都不认为是BUG  我会将BUG记录在测试文档中  方便在下次评审会上将问题再次抛出

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

首先要做的是重现这个问题并反馈给研发人员，尽快出patch或者解决方案。

当BUG解决且上线没有问题之后，我们再看后续的处理。

追查原因及处理方法：这个BUG出现的原因是什么。这有分为几种情况：

1）测试环境无法重现：可能是线上的环境造成的BUG或者是测试环境无法模拟的情况。

解决方法：尽量完善测试方法、尽量模拟测试环境、增加线上测试。

2）漏测：

a.测试用例裁剪过度：错误预估优先级或者时间过于紧迫裁剪了用例

解决方法：在后续版本或者其他项目启动时重新评估测试时间，要求专家介入对优先级进行评估，避免此类事件再次发生。

b.测试用例执行期间遗漏：由于测试人员疏忽造成测试用例执行遗漏。

解决方法：调查该名测试人员的整个测试过程的工作情况，并随机抽测其他模块，对该名测试人员进行综合评估，给出结论，是因为偷懒漏测，还是因为负责模块过多漏测，还是有其他原因，对该名测试人员发出警告，对相关测试主管，项目经理，产品经理发出警告。

c.测试用例覆盖不全：由于用例评审的不严格造成的；中途需求变更造成的；由于某些其他因素造成的。

35.二八定理

80%的缺陷出现在20%的代码中；80%的BUG发现在20%的时间中；80%的花费在20%的错误代码上。

36.如何跟踪缺陷

1.过程描述
测试人员按照测试用例依次进行，并针对缺陷整个生命周期进行跟踪
2.角色的定义
测试人员:负责具体测试执行及跟踪人员
测试组长:负责测试执行机跟踪包括bug单的一次审阅
项目经理:对测试人员的bug进行审核及分配
开发人员:对分配到个人的bug进行解决
3.状态的定义
新建，确认，解决，重新验证，关闭，重新打开

37.缺陷的状态

一个Bug由测试人员发现并提交,我们将状态标注为新建;开发人员接收了该
Bug,将Bug的状态修改为已分配(Assigned),表示已经认可;开发人员解决了该
Bug后,就将Bug的状态修改为解决,并发给测试人员回归测试;测试人员对Bug
进行回归测试，如果确实已经解决,就将Bug的状态修改为关闭,否则的话则发给
开发人员重新修改。还要说明的是,Bug是可以“死而复生”的,以前版本已经关闭
的Bug,如果新版本中重新出现,我们就需要将其状态修改为重新打开。

38.缺陷的等级

1.轻微缺陷
轻微缺陷是指对产品外观和下道工序可能会有轻微影响的缺陷
2.一般缺陷
一般缺陷是指不影响产品的运转和运行、不会成为故障起因，但对产品外观和下道工序影响较大的缺陷
3.严重缺陷
严重缺陷是指可以引起易于纠正的异常情况、可能引起易于修复的故障或对产品外观造成难以接受的缺陷。
4.致命缺陷
致命缺陷是指会造成安全问题的各类缺陷

39.缺陷单应该包含这些要素

所属产品，所属模块，当前指派（重要），bug类型，操作系统，重现步骤(重要)，验证程度(重要),优先级(重要)，附件等

40.测试报告的主要内容

测试目标，测试的范围，测试环境，测试结果分析(多少轮测试，测试多少，失败多少，成功占比)，遗留缺陷，测试结论（本次测试涉及xxx个功能点，发现xx个缺陷，其中，xx个已修复，xx个遗留。）测试过程完整有效，系统测试通过

41.如何定位bug：

1、发现bug，首先要查看bug的详细信息，根据描述初步分析是哪个模块哪段代码的问题

　　2、检查引发bug的测试环境、测试代码段和测试数据，排除测试人员的误操作导致的程序异常

　　3、确认测试代码、测试环境和数据都正确后，再进一步分析bug根源。这里就需要看具体的测试业务了，可借助相关的工具进行分析，比如firebug插件等

　　4、如果产品或业务有相关的日志记录，可通过分析日志来确认bug

　　5、当测试人员经过一系列的分析，可以基本确认bug产生的原因后，就可以直接找开发提bug了（注意沟通技巧）

　　6、如果各方面都分析完还不能确认bug的原因，可以找开发一起定位（注意保留bug现场或者可以复现bug场景）

　　7、确认bug后，提单给开发进行bug跟踪。

　　　 问题单上要描述清楚以下信息： 

　　　 具体的测试时间、测试环境、测试场景、测试的具体业务和功能、使用的测试代码和测试数据、测试执行步骤、测试结果、bug现象（最好截图）、日志记录、预期结果、bug确认相关人员等

　　8、跟踪bug，等开发人员修复bug后进行回归测试。（关注bug是否完全修复、有没有对其他功能造成影响、有没有引入新的问题）

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

1、 开发与测试对bug的定义理解不一致产生的问题，例如暴力操作、非常规操作出现的问题、问题路径深、服务器返回的数据不规范、竞品同样有的问题、个别机型问题等情况，开发可能会不愿意修改。

2、 工作流程方面的原因，例如开发有更高优先级的任务没有时间修改、上线时间紧急，来不及修改、开发不关注名下的bug、开发认为目前的实现比产品需求好等情况

3、 当然还有个人能力原因，例如找不到好的解决方案、影响范围大、找不到bug原因，没有解决方案、技术实现难，不知道怎么修改等等原因

4、 另外还有一些不可抗力的客观因素，例如系统问题，第三方应用问题等等

43.软件测试流程

1.需求分析
2.制订测试用例
3.评审测试用例
4.执行测试
5.提交Bug并推动Bug解决
6.回归测试
7.编写并提交测试报告

44.项目介绍

45.对一支圆珠笔进行测试，要从哪些方面进行测试？三角形测试用例设计

1.功能测试：
圆珠笔按下是否能正常书写。

2.性能测试：
笔芯弹出弹回的快慢。

3.负载测试：
连续按，看弹簧能经受多少次伸缩。

4.兼容性测试：
看是否可以使用其他笔芯。

5.强度测试：
用力过度会有什么影响

6.可恢复性测试：
长时间按住弹簧，松开后看弹簧是否可以恢复

7.界面测试：
笔的外观，舒适度

8.安全性测试：
是否会对使用者造成伤害

三角形

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

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

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

 1. 解决用户问题或达到用户目标需要具备的条件或能力
 2. 遵守合同、协议、规范或其他要求

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

1.尽快熟悉软件的需求和业务，只有熟悉了产品的业务流程、你才能迅速找出软件中存在的一些重要的缺陷
2.把自己当成用户，把自己当成是用户去使用该系统，比如在使用该系统过程中是这样操作的吗？
3.善于怀疑，不要开发人员的能力
4.不要让程序开发人员的观点：“用户不会进行这样的操作”而说服自己
5.使用完整的流程去测试软件系统，有些子流程在单独测试时没有问题，但按流程走的时候问题就可能出来了。

50.什么是bug？

和预期不一致的软件行为。

一个软件行为既可能是bug也可能不是bug，那是因为预期的主体千姿百态。

和测试员预期不一致的软件行为。
和程序员预期不一致的软件行为。
和文档预期不一致的软件行为。
和管理者预期不一致的软件行为。
和客户预期不一致的软件行为

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

不是
是特意设置的安全措施
防止有人马虎，操作后忘记取走银行卡而被人冒领卡中的钱款
所以特意设置了倒计时，限时内没有取走银行卡就会吞卡

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

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

1、检查系统是否有中度的特征，如：浏览器窗口连续打开，系统中文件图标改成统一图标，CPU使用率保存90%以上等
2、检查软件/硬件的配置是否符合软件的推荐标准
3、确认当前的系统是否是独立，即没有对外提供什么消耗CPU资源的服务，如：虚拟机运行
4、如果是C/S或者B/S结构的软件，需要检查是不是因为与服务器的连接有问题，或者访问有问题造成的；
5、在系统没有任何负载的情况下，查看性能监视器，确认应用程序对CPU/内存的访问情况，

54.你们发现bug会怎么处理。