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传参。URL有长度上的限制，明文传输，用来获取数据
2、POST将数据放在body中，POST的数据没有限制，比GET安全，用来发送数据

4.Cookie和Session的区别与联系

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

5.测试的目的

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

6.软件测试原则

==1.所有测试的标准都是建立在用户需求之上的，测试的目的在于发现系统是否满足规定的需求；
2.“尽早地和不断地测试”，越早进行测试，缺陷的修复成本就会越低；
3.程序员应避免检查自己的程序，由第三方进行测试更客观有效；
4.穷举测试是不可能的；
5.充分注意测试中的群集现象，一段程序中一发现的错误数越多，其中存在的错误概率越大，因此对发现错误较多的程序段，应进行更深入的测试；
6.设计测试用例时应包括合理输入和不合理输入，以及各种边界条件、特殊情况下要制造极端状态和意外状态；
7.注意回归测试的关联性，往往修改一个错误会引起更多错误；
8.测试应从“小规模”开始，逐步转向“大规模”；
9.测试用例式设计出来，不是写出来的，应根据测试的目的，采用相应的方法设计测试用例，从而提高测试的效率，更多的发现错误，提高程序的可靠性；
10.重视并妥善保存一切测试过程文档（测试计划，测试用例，测试报告等）==

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

单元测试：对最小可测试单元进行检查和验证
集成测试：测试不同模块的接口部分。
系统测试：将整个软件系统看做一个整体进行对功能、性能，以及软件所运行的软硬件环境进行测试。
验收测试：以用户为主的测试，软件开发人员和质量保证人员参加
回归测试：指修改了旧代码后，重新在新环境上进行测试以确认修改没有引入新的错误或导致其他代码产生错误。

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

	单元测试：
是指对软件中的最小可测试单元进行检查和验证。
	集成测试：
1. 在把各个模块连接起来时，穿越模块接口的数据是否会丢失。
2. 各个子功能组合起来，能否达到预期的要求。

9.系统测试范围

系统测试是将经过测试的子系统装配成一个完整系统来测试。它是检验系统是否确实能提供系统方案说明书中指定功能的有效方法。测试重点是整个系统的运行以及与其他软件的兼容性。

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

Alpha,Beta测试
а测试 软件开发公司组织内部人员模拟各类用户行为对即将上市的产品进行测试。
ß测试 软件开发公司组织各方面的的典型客户在日常工作中实际使用，并要求用户报告异常情况、提出改进意见，然后公司再进行完善。

11.验收测试怎么做？

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

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

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

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

白盒测试：是对软件的过程性细节做细致的检查。这种方法是把测试对象看做一个打开的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序状态，确定实际状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。

黑盒测试：是把所有东西装到一个盒子里，看不到内部逻辑，只能通过外部的可见的功能模块，对软件进行测试。
比如说一个网站的登陆功能，你不知道它的内部逻辑是怎样的，只能通过网页的注册输入文本框和注册按钮，来测试注册这个功能是否正常。一般黑盒测试也叫数据驱动测试或者功能测试

灰盒测试：是介于白盒测试与黑盒测试之间的，可以这样理解，灰盒测试关注输出对于输入的正确性，同时也关注内部表现，但这种关注不象白盒那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态，有时候输出是正确的，但内部其实已经错误了，这种情况非常多，如果每次都通过白盒测试来操作，效率会很低

13.冒烟测试的目的

冒烟测试是为了在运行性能测试或压力测试之前，确保一切都已正确配置并可按预期运行
在测试中发现问题，找到了一个Bug，然后开发人员会来修复这个Bug。这时想知道这次修复是否真的解决了程序的Bug，或者是否会对其它模块造成影响，就需要针对此问题进行专门测试，

14.回归测试怎么做？

回归测试可以发生在任何一个阶段，包括单元测试、集成测试和系统测试
1、在测试策略制定阶段，制定回归测试策略
2、确定需要回归测试的版本
3、回归测试版本发布,按照回归测试策略执行回归测试
4、回归测试通过，关闭缺陷跟踪单（问题单）
5、回归测试不通过，缺陷跟踪单返回开发人员，开发人员重新修改问题，再次提交测试人员回归测试

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

对软件的新版本测试时，重复执行上一个版本测试时使用的测试用例，防止出现“以前应用没有的问题现在出问题了”，这是全回归；
当在测试过程中，发现某个模块存在缺陷，开发修复后，测试人员重新验证该缺陷是否被修复，以及验证相关联的模块是否受影响，这叫部分回归。

16.需求分析的目的

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

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

17.测试计划的目的

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

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

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

19.由谁来编写测试计划

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

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

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

20.测试计划的内容

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

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

软件测试的结束点，要依据自己公司具体情况来制定，不能一概而论!个人认为测试结束点由以下几个条件决定：
1.基于“测试阶段”的原则
2.基于“测试用例”的原则
3.基于“缺陷收敛趋势”的原则
4.基于“缺陷修复率”的原则
5.基于“验收测试”的原则
6.基于“覆盖率”的原则
7.基于“项目计划”的原则
8.基于“缺陷度量”的原则
9.基于“质量成本”的原则
10.基于“测试业经验”的原则
　

22.常见的测试风险

1、需求风险
2、测试用例风险
3、缺陷风险
4、代码质量风险
5、测试环境风险
6、测试技术风险
7、回归测试风险
8、沟通协调风险
9、研发流程风险
10、其它不可预计风险

23.测试用例的要素

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

24.测试用例级别的划分

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

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

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

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

首先，确认需求
需求范围过于笼统，要明确用户故事。
请问这个需求是怎样的项目背景或基于什么前提下而做的；会涉及到哪些支撑平台；具体需要怎样的权限可以上传操作；该功能的迭代会影响到哪些其他的存量功能等，是否有明确的性能需求等

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

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

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

第五，后续的执行测试步骤（可以依情况来作描述）

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

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

27.测试用例的状态

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

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

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

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

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

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. 记录bug要尽量描述清楚发生问题时的测试步骤、测试环境、测试数据。
二、尽量重现bug
	1、被测对象的版本信息
有两个作用：一是确认我测试的是正式的软件版本，如果不是就先记录下该问题，然后选择正式的版本进行测试；二是可以和其它版本进行对比，如果其它的版本没有类似的问题，就可以去对比这两个版本之间的区别。
	2、环境
这里的环境是指出现不可复现的Bug时所对应的测试环境等，比如测试所用的计算机，如果出现不可复现的Bug，那我换一台机器是不是还会出现类似的问题，也就是说通过环境的改变来进一步搜集不可复现Bug的相关信息。
	3、模式
这里的模式是指我对这个Bug如何出现的一个理解
	4、人
这里提到的人有两个含义：一是测试是由人来进行的，人的操作、人的思维方式会有不同，通过分析这些信息也有可能找到这些不可复现的Bug的蛛丝马迹；二是想复现不可复现的Bug，往往需要多人之间的相互协作，比如测试人员、开发人员等，通过大家的沟通和协作就能更容易去复现了。
	5、测试工具
通过一些bug工具或者log工具等搜集内存等信息，根据这些信息来进行分析，找出不同信息之间的共同点，比如某一块内存始终都会被改写等，通过这种方式来去复现Bug。
三、实在没办法重现
	1.问题无法重现，也要提出，程序员那里可以回复无法再现。问题放在那里，等到再次出现的时候，就立刻叫程序员过来查看。
	2.实在没有再次出现，最后可以写到报告中，说出现了什么现象，但无法再现（比较严重的问题才如此处理，小问题经理之间商量商量可能就算了）。

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的状态修改为已分配,表示已经认可;
开发人员解决了该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.项目介绍

1、对项目进行基本介绍
• 最近测试的项目是一个电商平台系统，运营模式类似于天猫，京东这些网站。
• 项目系统由前台和后台两部分构成。
前台面向购物用户，包括会员、商品展示、购物车、订单、支付、用户中心等系统模块。
后台面向经营商家，包括商品管理，会员管理，订单处理等系统模块。
2、说明自己负责测试的模块
• 我在项目中主要负责订单及后台订单处理相关模块测试。
• 购物车-----
• 订单处理
– 我们项目后台订单处理主体流程是：
用户支付成功--商家确认订单--发货--用户确认物品无误，确认收获--订单结束--后续有售后和评价相关流程。
– 其他：
商家除了确认用订单，还可以对订单进行取消操作
用户如果未确认收货，系统可以设置超时自动收货（7天）
收货异常或其他情况下还可以进行退款操作。

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

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

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

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

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

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

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

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

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

三角形

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

Jmeter连接数据库进行压测的时候 （报错无法创建拒绝用户的访问，密码正确）
解决方法：禅道与mysql数据库端口冲突，服务中关闭mysqlzt，就好了

注册信息中的错误提示信息：如手机信息栏应填入11位有效电话号码，但提示信息却为“13位电话号码”，这是因开发人员粗心大意造成的
接口bug：传的字段值为空，但是开发没给默认值设个0导致接收不到数据

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

首先，将问题提交到缺陷管理库里面进行备案。

然后，要获取判断的依据和标准：

根据需求说明书、产品说明、设计文档等，确认实际结果是否与计划有不一致的地方，提供缺陷是否确认的直接依据；
如果没有文档依据，可以根据类似软件的一般特性来说明是否存在不一致的地方，来确认是否是缺陷；
根据用户的一般使用习惯，来确认是否是缺陷；
与设计人员、开发人员和客户代表等相关人员探讨，确认是否是缺陷；
合理的论述，向测试经理说明自己的判断的理由，注意客观、严谨，不参杂个人情绪。

等待测试经理做出最终决定，如果仍然存在争议，可以通过公司政策所提供的渠道，向上级反映，并有上级做出决定。

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

把app的所有功能都操作一遍，理清项目的数据流，澄清存在异议的地方，提取测试点；
根据提取的测试点编写测试用例，并评审；
执行测试用例，提交问题单并跟踪，直至问题被解决；
测试结束后，收集测试数据，输出测试报告。

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

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

50.什么是bug？

和预期不一致的软件行为。
一个软件行为既可能是bug也可能不是bug，那是因为预期的主体千姿百态。
和测试员预期不一致的软件行为。
和程序员预期不一致的软件行为。
和文档预期不一致的软件行为。
和管理者预期不一致的软件行为。
和客户预期不一致的软件行为

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

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

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

熟悉项目需求，充分了解各个各个功能模块的功能、参数、约束条件，弄清存在数据交互的模块之间的数据来源、数据流向；

跟产品确认该问题是否属于非问题单。

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

同类型软件在你的操作系统硬件环境上运行，如果一慢一块，则是软件问题
同一软件在别人的操作系统上，如果运行速度加快，则是你的操作系统或硬件的问题

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

1.项目经理通过和客户的交流，完成需求文档
2.开发人员根据需求文档完成需求分析文档，测试人员进行评审
3.测试人员根据修改好的需求分析文档开始写测试用例
4.测试用例完成后，测试和开发需要进行评审。
5.测试人员搭建环境
6.开发人员提交第一个版本，可能存在未完成功能，需要说明。测试人员进行测试，发现bug后提 交给bugzilla。
7.开发提交第二个版本，包括bugfix以及增加了部分功能，测试人员进行测试。
8.重复上面的工作，一般是3-4个版本后bug数量减少，达到出货的要求。
9.如果有客户反馈的问题，需要测试人员协助重现以及回归测试。