1.B/S架构和C/S架构区别：
所谓的软件架构我们可以理解为是用来指导我们软件开发的一种思维，目前来说最常见的两种架构模式是B/S 、C/S
b---browser 浏览器
c---clent 客户端
s---server 服务端
两种架构的比较：
1.标准：相对于cs架构来说bs架构的两端都是在使用现成的成熟产品。所以bs会显示的标准一些
2.效率：相对bs架构来说cs中的客户端可以分担一些数据的处理，因此执行的效率会高一些
3.安全：bs架构当中得到数据传输都是以HTTP协议进行的输出，而HTTP协议又是明文输出。可以被抓包，所以相对于cs架构来说bs就显得不那么安全（相对的）
4.升级：bs架构只需要在服务器端将数据进行地更新，前台只需要刷新页面就可以完成升级，而cs架构当中必须要将两端都进行更新
5.开发成本：相对于bs架构来说cs当中的客户端需要自己开发，所以相对于来说成本会高一些
2.HTTP协议
http协议又叫做超文本传输协议，在做网络请求的时候，我们基本上是使用http协议。
http协议包括请求和响应。
请求中包括:请求地址，请求方式，请求方式包括get请求和post请求，get和post的区别是get请求是在地址栏后边跟随请求参数，但是请求参数大小是有限制，不同浏览器是不同的。一般是4KB。post请求主要用于向服务器提交请求参数。post请求的参数是放到请求实体内容中的，相对get请求较为安全一些。
另外，请求中会有各种请求头信息，比如支持的数据类型，请求的来源位置，以及Cookie头等相关头信息。
响应，主要包含响应的状态码，像200(),404(),500(),304(),307()
还有各种响应头信息，比如设置缓存的响应头，Content-Type内容类型，设置cookie头信息。
3.POST与GET区别
GET：获取资源 GET方法一般用来从服务器上获取资源的方法
服务器端接到GET请求后，就会明白客户端是要从服务器端获取相应的资源，然后就会根据请求报文中相应的参数，将需要的资源返回给客户端。使用GET方式的请求，传输的参数是拼接在URL上
POST：数据提交 POST方法一般用于表单提交，将客户端的数据塞到请求体中发送给服务器端
**get和post区别：**
（1）get请求无消息体，只能携带少量数据；post请求有消息体，可以携带大量数据；
（2）get请求将数据放在url地址中；post请求将数据放在消息体中
（3）GET请求请提交的数据放置在HTTP请求协议头中，而POST提交的数据则放在实体数据中；GET方式提交的数据最多只能有1024字节，而POST则没有此限制。
4.Cookie和Session的区别与联系
（1）Cookie和Session都是会话技术，Cookie是运行在客户端，Session是运行在服务器端。
（2）Cookie有大小限制以及浏览器在存cookie的个数也有限制，Session是没有大小限制和服务器的内存大小有关。
（3）Cookie有安全隐患，通过拦截或本地文件找得到你的cookie后可以进行攻击。
（4）Session是保存在服务器端上会存在一段时间才会消失，如果session过多会增加服务器的压力。
5.测试的目的
（1）软件测试是为了发现错误而执行程序的过程。
（2）测试是为了证明程序有错，而不是证明程序无错。（发现错误不是唯一目的）
（3）一个好的测试用例在于它发现至今未发现的错误。
（4）一个成功的测试是发现了至今未发现的错误的测试。
6.软件测试原则
（1） 测试显示软件存在缺陷
（2）穷尽测试是不可能的
（3）测试尽早介入
（4）缺陷集群性（2/8原则）
（5）杀虫剂悖论
（6）测试活动依赖于测试内容
（7）没有错误是好是谬论
7.软件测试分为哪几个阶段？
一般来说分为5个阶段：单元测试、集成测试、确认测试、系统测试、验收测试
8.单元测试与集成测试的侧重点
**集成测试**的被测对象是单元间的组合，这里，不同模块往往是分配给不同的人员开发。集成测试主要关注不同单元模块之间的接口和配合
**单元测试**的测试对象是这些模块下的实现具体功能的单元，一般是对应详细设计中所描述的设计内容。单元测试主要关注每个具体单元模块内部的逻辑结构和功能是否正确
9.系统测试范围
将整个软件看做一个 整体来进行测试，包括功能、性能、兼容性。
10.a测试与ß测试的区别
α测试是指软件开发公司组织内部人员模拟各类用户对即将面市软件产品（称为α版本）进行测试，试图发现错误并修正。α测试的关键在于尽可能逼真地模拟实际运行环境和用户对软件产品的操作并尽最大努力涵盖所有可能的 用户操作方式。经过α测试调整的软件产品称为β版本。
β测试是由软件的多个用户在实际使用环境下进行的测试，这些用户返回有关错误信息给开发者。测试时，开发者通常不在测试现场。因而，β测试是在开发者无法控制的环境下进行的软件现场应用。在β测试中，由用户记下遇到的所有问题，包括真实的以及主观认定的，定期向开发者报告。β测试主要衡量产品的FLURPS，着重于产品的支持性，包括文档，客户培训和支持产品生产能力。 只有当α测试达到一定的可靠程度时，才能开始β测试。它处在整个测试的最后阶段。同时，产品的所有手册文本也应该在此阶段完全定稿。
11.验收测试怎么做？
在软件产品完成了功能测试和系统测试之后、产品发布之前所进行的软件测试活动。它是技术测试的最后一个阶段，也称为交付测试。
验收测试的目的：确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。
验收测试的参与者：用户，还可能有软测工程师等。
12.白盒、黑盒和灰盒测试区别
黑盒和灰盒的区别：
如果某软件包含多个模块，当使用黑盒测试时，你只要关心整个软件系统的边界，无需关心软件系统内部各个模块之间如何协作。而如果使用灰盒测试，则需要关心模块与模块之间的交互。
白盒和灰盒的区别：
在灰盒测试中，你无需关心模块内部的实现细节，对于软件系统的内部模块，灰盒测试依然把它当成一个黑盒来看待。而白盒测试还需要再深入地了解内部模块的实现细节和各个分支。
13.冒烟测试的目的
为正式测试前，验证是否产品或系统的主要需求或预置条件是否存在bug。
14.回归测试怎么做？
（1）重点测试软件中被修改的部分；
（2）从原基线测试用例库中，排除所有不再适用的测试用例，确定那些对新的软件版本依然有效的测试用例，其结果是建立一个新的基线测试用例库。
（3）依据一定的策略从测试用例库中选择测试用例测试被修改的软件。
（4）如果必要，生成新的测试用例集，用于测试无法充分测试到的软件部分。
（5）用新软件测试用例集执行修改后的软件。
15.全部回归与部分回归的区别？
全量回归：对软件的新版本测试时，重复执行上一个版本测试时使用的测试用例，防止以前没有的问题现在出问题了
部分回归：当开发修复某个bug时，我们需要去检查该bug是否被修复，还需要检查与之相关联的模块是否受到影响。
16.需求分析的目的
把用户需求转化为功能需求：
（1）对测试范围进度量
（2）对处理分支进行度量
（3）对需求业务的场景进行度量
（4）明确其功能对应的输入、处理和输出
（5）把隐式需求转变为明确。
明确测试活动的五个要素：
测试需求是什么、决定怎么测试、明确测试时间、确定测试人员、确定测试环境：测试中需要的技能，工具以及相应的背景知识，测试过程中可能遇到的风险等等。测试需求需要做到尽可能的详细明确，以避免测试遗漏和误解。
17.测试计划的目的
（1）尽早地明确测试工作内容（范围）、测试工作的方法以及测试工作所需要的各种资源。
（2）所有涉及到测试工作的人员，尽快将下一步测试工作需要考虑的问题和准备的条件落实。
（3）测试计划工作的重点在于：对当前工作任务的准备和规划以及信息的交流。
18.什么时候开始写测试计划
测试计划时在需求整理完成，和开发计划一起制定的一份计划书，它属于项目计划中其中的一个计划
19.由谁来编写测试计划
项目经理（从项目角度考虑）
测试经理（从测试组角度考虑）
测试人员（编写具体测试计划）
20.测试计划的内容
（1） 测试目标：对测试目标进行简要的描述。
（2） 测试概要：摘要说明所需测试的软件、名词解释、以及提及所参考的相关文档。
（3） 测试范围：测试计划所包含的测试软件需测试的范围和优先级，哪些需要重点测试、哪些无需测试或无法测试或推迟测试。
（4） 重点事项：列出需要测试的软件的所有的主要功能和测试重点，这部分应该能和测试案例设计相对应和互相检查。
（5） 质量目标：制定测试软件的产品质量目标和软件测试目标。
（6） 资源需求：进行测试所需要的软硬件、测试工具、必要的技术资源、培训、文档等。
（7） 人员组织：需要多少人进行测试，各自的角色和责任，他们是否需要进行相关的学习和培训，什么时候他们需要开始，并将持续多长时间。
（8） 测试策略：制定测试整体策略、所使用的测试技术和方法。
（9） 发布提交：在按照测试计划进行测试发布后需要交付的软件产品、测试案例、测试数据及相关文档。
（10） 测试进度和任务人员安排：将测试的计划合理的分配到不同的测试人员，并注意先后顺序.如果开发的Release不确定，可以给出测试的时间段.对于长期大型的测试计划，可以使用里程碑来表示进度的变化。
（11） 测试开始/完成/延迟/继续的标准：制定测试开始和完成的标准；某些时候，测试计划会因某种原因(过多阻塞性的Bug)而导致延迟，问题解决后测试继续。
（12） 风险分析：需要考虑测试计划中可能的风险和解决方法。
21.结束条件(项目上线的条件)
（1）软件经过充分的测试
开发人员测试---〉交叉测试---〉测试人员测试---〉用户的业务专家测试---〉一定数量的用户业务专家集中测试---〉上线前试运行----〉上线。
压力测试是必须的
（2）用户培训
管理员，一定厂或地区必须有一个人经过了培训。
（3）基础数据导入完成
用户、组织机构、业务数据等基础必须数据导入完成。
（4）授权必须完成
（5）新老系统的切换必须提前演练过，各种老数据的导入工作完成。
（6）应急方案必须有。
22.常见的测试风险
（1）需求风险
（2）测试用例风险
（3）缺陷风险
（4）代码质量风险
（5）测试环境风险
（6）测试技术风险
（7）回归测试风险
（8）沟通协调风险
（9）研发流程风险
（10）其他不可预计风险
23.测试用例的要素
（1）用例编号
（2）测试模块
（3）用例的标题
（4）测试级别
（5）测试目的和条件
（6）测试输入
（7）操作步骤
（8）预期结果
24.测试用例级别的划分
测试用例优先级的目的：测试用例优先级可以用来方便地基于测试策略来筛选用例。比如某块功能改动小，就只用测高或中高优先级的用例。 比如冒烟测试的时候我们只需要筛选优先级最高的用例执行即可。
根据我们测试用例优先级目的：那么优先级越高的测试用例覆盖的测试点应该是用户最关心的， 比如一个注册功能， 能够注册成功这个用例的优先级就是最高的（但是不是所有的注册成功的case都是优先级最高，只需要挑选一个即可）， 其他各种异常校验都是次要优先级的， 还有一些场景覆盖的测试点很难出现，或者叫就算有问题影响也不大， 可以放到低优先级
25.怎样保证覆盖用户需求？
（1）确认需求
（2）梳理需求，确认测试范围
（3）制定测试计划
（4）根据测试计划编写测试用例
（5）执行测试步骤
26.写好测试用例的关键 /写好用例要关注的维度
（1）测试前：
对测试目的有一个清晰的认知
熟悉产品的功能测试点
熟悉模块原理，避免“互相影响”问题的产生
关注用户场景问题和上网问题
不可马虎的关键测试用例设计、
（2）编写测试用例时：
构建测试用例框架
测试步骤的设计（一是如果步骤过于粗糙很容易出现漏测问题；二是写的过于细致，可能耗时耗力，并且会限制执行人员的思维。）
（3）测试用例设计方法及思考
切记产品测试的主要目标
注意用词精准问题
27.测试用例的状态
排队（In Queue）、进行中（IP）、阻塞（Block）、跳过（Skip）、通过（Pass）、失败（Fail）、警告（Warn）、关闭（Close）
28.常见的测试用例设计方法
等价类划分、边界值分析、错误推断法、判定法表、正交实验法
29.判定表用在哪些时候/哪些功能
判定法，是用在不同的输入组合，可能会产生不同的输出这种情况，比如，一个有多个查询条件的查询功能，输入不同的查询条件组合，输出的结果是不一样的，这样的功能就要用到判定表
30.什么时候用到场景法
（1）场景法适用于解决业务流程清晰和业务比较复杂的系统或功能，场景法是一种基于软件业务的测试方法。
（2）使用场景法，目的是用业务流把各个孤立的功能点串起来，为测试人员建立整体业务感觉，从而避免陷入功能细节忽视业务流程要点的错误倾向。例：语音通话典型业务流程就把语音通话、同振顺振、语音留言、呼叫保持、呼叫转移这些功能都串到一起来。
（3）基本上每个软件都会用到场景法，因为每个软件背后都有业务的支撑。
（4）场景法主要用来测试软件的业务逻辑和业务流程。当拿到一个测试任务时，我们并不是先关注某个控件的细节测试（等价类+边界值+判定表等），而是要先关注主要业务流程和主要功能是否正确实现，这就需要使用场景法。当业务流程和主要功能没有问题，我们再从等价类、边界值、判定表等方面对控件细节进行测试（先整体后细节）。
（5）Note：场景法测试用例设计的重点是测试业务流程是否正确，测试时需要注意的是，业务流程测试没有问题并不代表系统的功能都正确，还必须对单个功能进行详细的测试，这样才能保证测试的充分性。
31.测试环境怎么搭建的？
搭建环境前，开发都会给到我们一份系统发布手册，我们会根据这个手册来搭建。比如，我这个xx系统，是搭建在Unix系统下的，web服务器用的是Tomcat8，MySQL版本是5.7，程序是JAVA编写的，首先我们向开发拿到编译好的安装包，然后用xshell(或CRT)远程连接上Unix系统，把tomcat服务器停掉，把程序包放到webapps目录下，然后再启动tomcat服务器就可以了。
32.偶然性问题的处理
（1）一定要提交bug：
记得有这么个缺陷，以后再遇到的时候可能就会了解发生的原因。
尽力去查找出错的原因，比如有什么特别的操作，或者一些操作环境等。
程序员对程序比测试人员熟悉的多，也许你提交了，即使无法重现，程序员也会了解问题所在。
无法重现的问题再次出现后，可以直接叫程序员来看看问题。
记录bug要尽量描述清楚发生问题时的测试步骤、测试环境、测试数据。
（2）尽量重现bug
33.当我们认为某个地方是bug，但开发认为不是bug，怎么处理？
（1）告知开发bug的判断依据，同时明确开发说不是bug的理由。
（2）对开发的理由进行校验，校验依据1.参照需求文档，2.跟产品经理进行沟通确认。
（3）校验结果不是bug，关闭bug，如果是bug提交给开发进行处理，确保产品质量
34.产品在上线后用户发现bug，这时测试人员应做哪些工作？
（1）测试人员复现问题后，提交问题单进行跟踪；
（2）评估该问题的严重程度，以及修复问题时的影响范围，回归测试需要测试哪些功能；
（3）问题修复后，先在测试环境上回归，通过后再在生产环境上打补丁，然后再进行回归测试；
（4）总结经验，分析问题发生的原因，避免下次出现同样问题。
35.二八定理
缺陷往往喜欢扎堆，一个模块已经发现的缺陷比别的模块多，通常不是代表这个模块已经把缺陷暴露完了，而是意味着这个模块还存在有同样多的缺陷尚未被发现。这就是著名的二八定理：80%的缺陷出现在 20%的模块。
36.如何跟踪缺陷
当发现缺陷后，我们要在禅道上提交问题单给开发，并每隔一段时间(间隔一个小时，或两个小时都可以)去检查缺陷是否被处理，如果没及时处理，就要提示开发，让开发及时修复问题，问题修复后，要及时进行回归测试。
37.缺陷的状态
（1）初始化：缺陷的初始状态；
（2） 待分配：缺陷等待分配给相关开发人员处理；
（3）待修正：缺陷等待开发人员修正；
（4） 待验证：开发人员已完成修正，等待测试人员验证；
（5） 待评审：开发人员拒绝修改缺陷，需要评审委员会评审；
（6） 关闭：缺陷已被处理完成。
38.缺陷的等级
轻微缺陷、一般缺陷、严重缺陷、致命缺陷
39.缺陷单应该包含这些要素
缺陷标题、缺陷类型、重现步骤、预期结果、实际结果、缺陷优先级、附件备注
40.测试报告的主要内容
测试报告包括哪些内容: 测试模块（每个模块里需要记录测试的开始时间、结束时间、设计多少用例、通过多少、失败多少、有多少BUG、遗留多少BUG、解决多少BUG、追后对这个模块总结一下）
BUG的统计，根据时间轴来统计BUG的数量，例如：XXXX年X月X日，发现BUG多少，关闭BUG多少，剩余BUG多少，高级的BUG有多少，中级的BUG有多少，低级和建议的BUG有多少，一直罗列到项目完结
项目总结，汇报一下测试的大致结果。
遗留和风险，该软件还有什么遗留问题，还有什么风险，都要一一说明
最后评判该软件是否符合上线标准，日期，签字，加盖章等
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，测试在推动开发修复bug时，需要注意以下几点：
a) 从用户的角度分析问题的严重性，分析用户的遇到此问题的概率，引导开发站在用户角度去思考，从而使开发意识到问题的严重性
b) 可以和开发人员列举一个之前的类似问题，为开发提供参考
c) 产品是负责这个软件的人员，当测试与开发意见无法达成一致时，不要因为无法推动开发修改而放弃，一定要找产品确认，最终的决定权交给产品人员。
（2）上线时间紧张，开发来不及修改了，这个时候测试应该分析问题的严重性，和产品人员商议是否需要修改
（3）修改bug改动较大，影响范围广，没有最优的解决方案等情况在项目即将上线的节点比较忌讳这种事情的发生。面对这种情况，建议开发人员做调研工作，请教其他的同事，或者组织一个临时会议，集众人之力研究好的修改方案
（4）第三方应用问题，开发无法修改。确认原因之后需要找相关的工作人员，例如产品，联系第三方的工作人员，反馈问题，尽量推动应用解决问题
**小结**
总之，bug修不修，测试应该有一个自己的原则，同时也要权衡利弊。不能因为推不动开发，就放弃，由着bug上线，也不能揪着一个小bug不放，影响上线时间。
43.软件测试流程
了解用户需求--》参考需求规格说明书--》测试计划（人力物力时间进度的安排）--》编写测试用例--》评审用例--》搭建环境--》测试包安排预测（冒烟测试）-正式测试-bug-测试结束出报告--》版本上线--》面向用户
44.项目介绍
45.对一支圆珠笔进行测试，要从哪些方面进行测试？三角形测试用例设计
用例设计：
性能测试
能否正常书写 是否有笔油泄露 笔帽是否能正常按下弹起来
功能测试
一支笔可以用多少时间、写出的字是否褪色
易用性测试
笔的长短粗细是否顺手 一根笔芯用尽是否方便更换
界面测试
外形是否美观 时尚有趣
安全性测试
笔油是否含有有害物质 笔尖是否容易伤到人 笔油或者墨水保质期多长 过期是否产生有害物质、
兼容性测试
在不同的温度、气压、和重力下能否正常使用 在不同的纸质和力度下书写结果如何
三角形测试用例设计：
1、当三边不可能构成三角形时提示错误，可构成三角形时计算三角形周长。
2、若是等腰三角形打印“等腰三角形”， 若两个等腰的平方和等于第三边平方和，则打印“等腰直角三角形”。
3、若是等边三角形，则打印：“等边三角形”。
4、画出程序流程图并设计一个测试用例。
因果图、等价类划分（推荐测试方法）
46.在项目中发现哪些经典bug？什么原因导致的？
编码的问题
接口限流防刷的时候，通过计数器限流，如果超过某个阈值，向前端返回一个codeMsg对象用于显示的时候，显示的是String是乱码的问题，之前由于一直返回都是json 格式，都是封装好在data里。
这次返回是直接通过输出流直接写到response直接返回字节数组的，而不是spring controller 返回数据（springboot 默认utf-8），出现乱码问题，用utf-8编码，解决。
比较难解决的bug无非就两种，一种就是程序的逻辑出现问题，导致得不到正确的结果，第二种就是一些中间件，开发环境的问题。
（1）如果是逻辑出现了问题，你项目比较大的话，那只能是通过单步调试，或者用System.out.println()打印出来想要得到的数据看看是哪步出了问题。
（2）如果是开发环境或者是中间件的问题，那只能是通过网上查阅资料来解决问题。如果你英语阅读能力还可以的话，我推荐使用Stack Overflow来查阅资料。
47.一个项目完成时，有多个重要的缺陷没有被修复，但是项目负责人说可以不修改，你认为测试是不通过的，请简述你的理由。
测试是对软件的质量进行的把关，如果一个项目仍然有很多的缺陷未被修复，那么从质量的角度上我们会认为这个软件质量是不达标的，一般来说缺陷的遗留，是不允许严重、致命bug的遗留，轻微和一般的bug遗留率不超过30%。
48.在需求文档不太详细的情况下，如何开展测试？
（1）主动了解做这个功能的背景，意图，要去解决一个什么样的问题， 这个可以找产品或者开发要，或者谁要求做这个功能的人要，知道这些后，测试的时候才心中有数，知道功能实现对不对
（2）尽量让熟悉这块的业务的人去测试，这样功能的一些业务问题就可以测试出来
（3） 因为没有需求说明书，测试这边只有在功能做好了，转测试了，才知道功能是什么样子，所以这个时候写测试用例来不及，就采取这样思路操作 ，测试的时候边测试边记录测试的点，然后组内把这些测试点评审下，看看是否还有遗漏的地方，
49.如何尽快找到软件中的bug?
优先解决可重现的bug、对于某些没有头绪的bug，可以找有经验的同事商讨、bug放大、二分定位法、模拟现场、等
50.什么是bug？
bug是计算机领域专业术语，bug原意是“臭虫”，现在用来指代计算机上存在的漏洞，原因是系统安全策略上存在的缺陷，有攻击者能够在未授权的情况下访问的危害。
51.ATM机吞卡的吞卡现象是不是BUG?
不是，是特意设置的安全措施，防止有人马虎，操作后忘记取走银行卡而被人冒领卡中的钱款，所以特意设置了倒计时，限时内没有取走银行卡就会吞卡
52.如何减少非问题单的提交？
（1）缺陷的概要描述要清晰准确，要使相关开发负责人员能够一目了然问题是什么。
（2）一个完整的缺陷报告单，必须包含其必要的元素信息，例如：概要描述，缺陷发现人，测试环境，浏览器，缺陷重现步骤，严重等级，指派人，所属功能模块等等，必要元素信息必须描述全面清楚。
（3） 缺陷的重现步奏必须描写清晰明了，使相关开发负责人能够根据重现步骤准确的重现所提交的缺陷，使其定位缺陷的原因所在。
（4）指派给人一定要明确，如知道缺陷是所属具体的某一个开发人员时，应该直接指派给对应的负责人，这样就能减少中间分配环节的时间。
（5） 测试数据，测试的数据作为重现缺陷的一个重要元素信息，一定要将测试时所使用的信息给描写清楚准确。让开发人员根据测试所提供的测试数据准确重现缺陷。
（6） 附件截图信息，附件或截图信息能让开发人员能够一目了然的清楚问题的所在，所以必要的时候提供附件或者截图信息也非常的重要。
（7）描述缺陷内容的语气，在进行缺陷单书写时，尽量使用专业术语（体现测试的专业性），其次注意书写缺陷报告单时不要带有个人客观的语气内容，以免影响开发和测试人员之间的关系。
53.有个程序，在windows上运行很慢，怎么判断是程序存在问题，还是软硬件系统存在问题？
（1）检查系统是否有中度的特征，如：浏览器窗口连续打开，系统中文件图标改成统一图标，CPU使用率保存90%以上等
（2）检查软件/硬件的配置是否符合软件的推荐标准
（3）确认当前的系统是否是独立，即没有对外提供什么消耗CPU资源的服务，如：虚拟机运行
（4）如果是C/S或者B/S结构的软件，需要检查是不是因为与服务器的连接有问题，或者访问有问题造成的；
（5）在系统没有任何负载的情况下，查看性能监视器，确认应用程序对CPU/内存的访问情况，
54.你们发现bug会怎么处理。
提交bug、指派bug、确认bug、解决bug、重测bug、关闭bug、bug存档
