1.B/S架构和C/S架构区别
B/S 又称浏览器/服务器模式
1.客户端无需安装，有Web浏览器即可。
2.BS架构可以直接放在广域 上, 交互性较强。
3.BS架构无需升级多个客户端，升级服务器即可
C/S 又称客户/服务器模式
1. C/S架构的界面和操作可以很丰富。
2. 安全性能可以很容易保证，实现多层认证也不难。
3. 由于只有一层交互，因此响应速度较快。
4. 维护成本高，发生一次升级，则所有客户端的程序都需要改变。
2.HTTP协议
http是超文本传输协议，
1.用于服务器传输超文本到本地浏览器的传送协议
2.它基于TCP/IP通信协议来传递数据 (HTML 文件,图片文件,查询结果等)
3.浏览器作为客户端，通过URL向web服务器发送请求，再响应客户端（传输方式）
4.http通过统一的资源标识符使用URL来传输数据和建立连接
3.POST与GET区别
get没有请求体通过URL携带数据大小有限制不安全
post有请求体通过请求体传输数据大小没有限制比get请求安全
4.Cookie和Session的区别与联系
Cookie是客户端技术 把数据保存在浏览器端的内存中。
Session是服务端技术 把数据存储在服务端的内存中。
区别：
(1)cookie数据存放在客户的浏览器上，session数据放在服务器上
(2)cookie不是很安全，别人可以分析存放在本地的COOKIE并进行COOKIE欺骗,如果主要考虑到安全应当使用session
(3)session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能，如果主要考虑到减轻服务器性能方面，应当使用COOKIE
5.测试的目的
1.尽量能多地发现软件产品中的缺陷，并对软件产品的质量水平做出尽可能准确的评估
2.进而保证产品质量，降低上线后的风险。
3.软件测试是为了发现错误而执行程序的过程
4.测试是为了证明程序有错，而不是证明程序无错
5.可以帮助项目管理者发现当前所采用的软件过程的缺陷，以便改进。
6.软件测试原则
1. 测试显示软件存在缺陷 2. 穷尽测试是不可能的 3.测试尽早介入
4. 缺陷集群性（2/8原则） 5.杀虫剂悖论 6.测试活动依赖于测试内容
7. 没有错误是好是谬论
7.软件测试分为哪几个阶段r> 单元测试 集成测试 系统测试，验收测试，
8.单元测试与集成测试的侧重点
单元测试阶段、针对每个单元的测试， 以确保每个模块能正常工作为目标。
集成测试阶段，对已测试过的模块进行组装，进行集成测试题。
9.系统测试范围
需求规格说明 测试人员 黑盒测试
10.a测试与?测试的区别
а测试 软件开发公司组织内部人员模拟各类用户行为对即将上市的产品进行测试。
?测试 软件开发公司组织各方面的的典型客户在日常工作中实际使用，并要求用户 告异常情况、提出改进意见，然后公司再进行完善。
11.验收测试怎么做r> 检验软件产品质量的最后一道工序。主要突出用户的作用，同时软件开发人员也应有一定程度的参与。
验收测试：针对的对象是用户需求方，如某某公司的一个管理系统，用户必然是这个公司的成员！所以人员架构是从该公司选择！一般采用：叫客户到软件开发公司提供的场所进行软件的讲解，然后使用验收！
12.白盒、黑盒和灰盒测试区别
1黑盒测试
黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用。在测试中，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。
黑盒测试是以用户的角度，从输入数据与输出数据的对应关系出发进行测试的。很明显，如果外部特性本身设计有问题或规格说明的规定有误，用黑盒测试方法是发现不了的。
2白盒测试
白盒测试又称结构测试、透明盒测试、逻辑驱动测试或基于代码的测试。白盒测试是一种测试用例设计方法，盒子指的是被测试的软件，白盒指的是盒子是可视的，你清楚盒子内部的东西以及里面是如何运作的。”白盒”法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。”白盒”法是穷举路径测试。在使用这一方案时，测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。贯穿程序的独立路径数是天文数字。
采用什么方法对软件进行测试呢的软件测试方法有两大类：静态测试方法和动态测试方法。其中软件的静态测试不要求在计算机上实际执行所测程序，主要以一些人工的模拟技术对软件进行分析和测试；而软件的动态测试是通过输入一组预先按照一定的测试准则构造的实例数据来动态运行程序，而达到发现程序错误的过程。在动态分析技术中,最重要的技术是路径和分支测试。下面要介绍的六种覆盖测试方法属于动态分析方法。
3灰盒测试
灰盒测试是介于白盒测试与黑盒测试之间的一种测试，灰盒测试多用于集成测试阶段，不仅关注输出、输入的正确性，同时也关注程序内部的情况。灰盒测试不像白盒那样详细、完整，但又比黑盒测试更关注程序的内部逻辑，常常是通过一些表征性的现象、事件、标志来判断内部的运行状态。
13.冒烟测试的目的
1.冒烟测试是在软件开发过程中的一种针对软件版本包的快速基本功能验证策略，是对软件基本功能进行确认验证的手段，并非对软件版本包的深入测试。
2.冒烟测试也是针对软件版本包进行详细测试之前的预测试，执行冒烟测试的主要目的是快速验证软件基本功能是否有缺陷。如果冒烟测试的测试例不能通过，则不必做进一步的测试。
3.进行冒烟测试之前需要确定冒烟测试的用例集，对用例集要求覆盖软件的基本功能
14.回归测试怎么做r> 1. 依据一定的策略从测试用例库中选择测试用例测试被修改的软件。
2.如果必要，生成新的测试用例集，用于测试无法充分测试到的软件部分
3.新加入测试的模块，可能对其他模块产生副作用，因此要进行某些程度的回归测试
4.bug修改，关联功能，新增加功能，修改功能。
15.全量回归与部分回归的区别r> 全量回归：对软件的新版本测试时，重复执行上一个版本测试使用的测试用例，防止以前没有的问题现在出问题了。
部分回归：当开发修复某个bug时，我们需要去检查该bug是否被修复，还需要检查与之相关联的模块是否受到影响。
16.需求分析的目的
澄清需求提取测试点
产品需求也不等于是测试需求。没有测试需求分析，会导致我们的信息不完整、不准确，无法对所测产品有一个清晰全面的认识。所以，我们要先进行测试需求分析，在这个基础上，再进行后面的测试设计，测试计划等工作
17.测试计划的目的
规范软件测试内容，方法和过程
编写软件测试计划的目的是指导测试组成员进行工作和让测试组以外的项目成员了解测试工作的
18.什么时候开始写测试计划
一般来说，在产品需求确认，做过测试需求分析之后我们就要开始编写测试计划。当然测试计划编写的工作要根据工作实际来决定，也就是具体情况具体分析
19.由谁来编写测试计划
：项目经理、测试经理、测试人员
1.项目经理
项目经理当然是从整个项目角度出发，编写整体项目计划，那么其中就包括测试的计划了，他依赖于对应的开发计划，也就是首先要有开发计划、提测计划，再评估测试计划，最终得出上线时间
2.测试经理
测试经理主要是从测试组角度出发，编写项目的测试计划，重点就是项目的任务拆分、合理的安排人力资源、预估时间和风险等
3.测试人员
测试同学本人收到测试经理同步过来的具体分工后，也需要编写自己的测试计划，重点就是详细的说明自己的时间规划、每一个测试任务的前期准备以及开始和结束测试的时间等
20.测试计划的内容①简介
②参考文档和提交文件
③进度安排
④测试资源
⑤严重程度和优先级
⑥风险分析
⑦测试策略
———————————
1.测试范围 明确测什么：产品的具体业务需求有哪些是web端的还是移动端的，还是两者都有
2.测试策略 明确怎么测。对不同业务需求，具体要有哪些测试类型、测试场景、测试方法。
3.资源安排 包括测试人员的安排，测试环境是怎样的，测试工具的选择等。
4.进度安排 在明确测试范围、方法和人员之后，我们要考虑什么时候开始测试，预计要测试多久和开发计划、上线计划衔接。
5.发布标准 发布标准是测试完成和产品上线需要满足的条件，以便项目内所有角色都有一致认可的目标。怎样才算是测完了怎样的标准才可以上线r> 6.风险预防 最后，我们需要对整个测试过程中可能存在的风险，以及当这些风险发生时的应对措施提前进行一些考虑和准备，并在测试计划中体现出来。
21.结束条件(项目上线的条件)
1.测试用例执行完毕，用例通过率>98%；
2.测试遗留缺陷不存在级别为严重的bug，且遗留bug不影响版本发布。例如一些界面显示排版问题可以遗留我们公司项目结束的标准是：
第一，测试用例回归测试已经全部执行，
第二，bug都已被确认，暂缓的bug也有详尽的解释，
第三，测试 告、测试总结完成，
第四，项目处于试运行或者上线阶段。但是，测试是没有止境的，只能说是相对完成，毕竟就算是上线了，也会出现多多少少的bug出现。
22.常见的测试风险
需求风险
1. 需求变更：需求变更导致开发、测试部分工作失效，维护成本增加
缺陷风险
1.偶现缺陷，较难重现，容易被遗漏；
2.缺陷跟踪不够积极主动，没有做好缺陷记录和跟踪，导致上线遗漏
代码质量风险
1.人员经验不够丰富
2. 人员对业务理解不够
3.系统架构设计不足，导致扩展性不足，性能兼容差等问题
测试环境风险
1.测试环境同线上环境配置并别较大，测试环境问题在线上重不了
测试技术风险
1. 人员能力不足
2. 人员技术能力差，效率低，该用自动化替代的工作，没有时间和能力
研发流程风险
1.必须经过测试无问题后再提交线上等
23.测试用例的要素
1.用例标题 2.用例操作步骤 3.用例编 4.用例描述
5.用例功能模块 6.用例条件 7.用力的请求方式 8.用例的数据
24.测试用例级别的划分
高等级， 中等级，低等级
25.怎样保证覆盖用户需求r> 1.首先测试需求分析要全面 、测试需求的获取，需求说明书，需求的分析 ，产生测试需求文档
2.当测试需求分析完成，并且形成文档后，要进行测试需求评审，保证需求的准确性以及完整性。
3.测试需求完成以后，可以根据测试需求设计测试用例。要保证测试用例能够全面覆盖测试需求，要包含所有的情况
4.测试用例编写完成后，就是测试执行测试用例执行100%覆盖。在测试执行过程中，要继续对测试用例补充完善，确保提高测试覆盖率
5.、通过技术手段监控覆盖率,覆盖了具体百分之多少，然后再重新弥补测试用例设计的不足，保障测试覆盖率。
26.写好测试用例的关键 /写好用例要关注的维度
1.提前介入同时在完成需求分析阶段后测试团队就成为了除了BA外对需求最熟悉的团队。
2..避免开发人员的影响。测试团队要尽量避免因为开发过程中的原因修改case
3.明确测试用例的目标。
27.测试用例的状态
排队（In Queue）：测试用例已经指定给某个测试人，不准备在这一个测试阶段运行。
进行中（IP）：该测试正在进行，并且会持续一段时间。
阻塞（Block）：一些因素会导致测试不能进行到底 某个功能欠缺或者测试环境的某个部分欠缺。
跳过（Skip）：你决定在当前测试阶段跳过某个测试，可能是因为它的优先权相对较低。
通过（Pass）：测试运行结束，测试人得到了预料中的测试结果状态和测试行为。
失败（Fail）：测试人得到预料之外的测试结果，状态或行为，这些结果与测试目标相差甚远。
警告（Warn）：警告意味着当前的错误是无关紧要的，或者对正在测试的特征是没有意义的。系统 出了更多的错》
关闭（Close）：一个测试在第一个循环中被标为失败或警告，第二个测试发布中将第一个测试循环出现的错误修改了。重新运行了整个测试用例后，没有错误出现。将这类测试标记为关闭而不是通过
28.常见的测试用例设计方法
等价类划分法 边界值分析法 错误推测法 因果图法 正交实验法 场景分析法
29.（1）判定表用在哪些时候/（2）哪些功能
判定法 是用在不同的数入组合 可能会产生不同的输出这种情况，比如一个有多个查询条件的查询功能
输入不同的查询条件组合输出的结果是不一样的这样的功能就要用到判定表
（1）
在解决比较复杂的决策问题时使用使用后可以简洁、明确、一目了然地描述出来它是描述条件比较多的决策问题的有效工具。判定表它结构简单，易懂易读。尤其遇到组合条件的判定，利用判定表或判定树可以使问题的描述清晰，而且便于直接映射到程序代码。在表达一个加工逻辑时，判定数、判定表都是好的描述工具，根据需要可以交叉使用。
（2）那些功能：
①表示的部分，判定标的左上部称为基本条件项，列出各种可能的条件。第二部分即②表示的部分，判定标的右上部称为条件项，它列出了各种可能的条件组合。第三部分即③表示的部分，判定标的左下部称为基本动作项，它列出了所有的操作。第四部分即④表示的部分，判定标的右下部称为动作项，它列出在对条件组合下所选的操作。
30.什么时候用到场景法
场景法适用于解决业务流程清晰和业务比较复杂的系统或功能，场景法是一种基于软件业务的测试方法。
使用场景法，目的是用业务流把各个孤立的功能点串起来，为测试人员建立整体业务感觉，从而避免陷入功能细节忽视业务流程要点的错误倾向。例：语音通话典型业务流程就把语音通话、同振顺振、语音留言、呼叫保持、呼叫转移这些功能都串到一起来。
基本上每个软件都会用到场景法，因为每个软件背后都有业务的支撑。
场景法主要用来测试软件的业务逻辑和业务流程。当拿到一个测试任务时，我们并不是先关注某个控件的细节测试（等价类+边界值+判定表等），而是要先关注主要业务流程和主要功能是否正确实现，这就需要使用场景法。当业务流程和主要功能没有问题，我们再从等价类、边界值、判定表等方面对控件细节进行测试（先整体后细节）。
Note：场景法测试用例设计的重点是测试业务流程是否正确，测试时需要注意的是，业务流程测试没有问题并不代表系统的功能都正确，还必须对单个功能进行详细的测试，这样才能保证测试的充分性。
31.测试环境怎么搭建的r> 搭建环境前，开发都会给到我们一份系统发布手册，我们会根据这个手册来搭建。比如，我这个xx系统，是搭建在Unix系统下的，web服务器用的是Tomcat8，MySQL版本是5.7，程序是JAVA编写的，首先我们向开发拿到编译好的安装包，然后用xshell(或CRT)远程连接上Unix系统，把tomcat服务器停掉，把程序包放到webapps目录下，然后再启动tomcat服务器就可以了。
32.偶然性问题的处理
1.一定要提交bug、
1． 记得有这么个缺陷，以后再遇到的时候可能就会了解发生的原因。
2． 尽力去查找出错的原因，比如有什么特别的操作，或者一些操作环境等。
3． 程序员对程序比测试人员熟悉的多，也许你提交了，即使无法重现，程序员也会了解问题所在。
4． 无法重现的问题再次出现后，可以直接叫程序员来看看问题。
5． 记录bug要尽量描述清楚发生问题时的测试步骤、测试环境、测试数据。
2.尽量重现bug、
33.当我们认为某个地方是bug，但开发认为不是bug，怎么处理r> 1.告知开发bug的判断依据，同时明确开发说不是bug的理由。
2.对开发的理由进行校验，校验依据1.参照需求文档，2.跟产品经理进行沟通确认。
3.校验结果不是bug，关闭bug，如果是bug提交给开发进行处理，确保产品质量
34.产品在上线后用户发现bug，这时测试人员应做哪些工作bsp;
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原因导致的r> 编码的问题
接口限流防刷的时候，通过计数器限流，如果超过某个阈值，向前端返回一个codeMsg对象用于显示的时候，显示的是String是乱码的问题，之前由于一直返回都是json 格式，都是封装好在data里。
这次返回是直接通过输出流直接写到response直接返回字节数组的，而不是spring controller 返回数据（springboot 默认utf-8），出现乱码问题，用utf-8编码，解决。
比较难解决的bug无非就两种，一种就是程序的逻辑出现问题，导致得不到正确的结果，第二种就是一些中间件，开发环境的问题。
（1）如果是逻辑出现了问题，你项目比较大的话，那只能是通过单步调试，或者用System.out.println()打印出来想要得到的数据看看是哪步出了问题。
（2）如果是开发环境或者是中间件的问题，那只能是通过 上查阅资料来解决问题。如果你英语阅读能力还可以的话，我推荐使用Stack Overflow来查阅资料。
47.一个项目完成时，有多个重要的缺陷没有被修复，但是项目负责人说可以不修改，你认为测试是不通过的，请简述你的理由。
48.在需求文档不太详细的情况下，如何开展测试r> 1、主动了解做这个功能的背景，意图，要去解决一个什么样的问题， 这个可以找产品或者开发要，或者谁要求做这个功能的人要，知道这些后，测试的时候才心中有数，知道功能实现对不对
2、尽量让熟悉这块的业务的人去测试，这样功能的一些业务问题就可以测试出来
3因为没有需求说明书，测试这边只有在功能做好了，转测试了，才知道功能是什么样子，所以这个时候写测试用例来不及，就采取这样思路操作 ，测试的时候边测试边记录测试的点，然后组内把这些测试点评审下，看看是否还有遗漏的地方
49.如何尽快找到软件中的bugr> 优先解决可重现的bug、对于某些没有头绪的bug，可以找有经验的同事商讨、bug放大、二分定位法、模拟现场、等
50.什么是bugr> bug是计算机领域专业术语，bug原意是“臭虫”，现在用来指代计算机上存在的漏洞，原因是系统安全策略上存在的缺陷，有攻击者能够在未授权的情况下访问的危害。
51.ATM机吞卡的吞卡现象是不是BUGr> 不是，是特意设置的安全措施，防止有人马虎，操作后忘记取走银行卡而被人冒领卡中的钱款，所以特意设置了倒计时，限时内没有取走银行卡就会吞卡
52.如何减少非问题单的提交r> 1、 缺陷的概要描述要清晰准确，要使相关开发负责人员能够一目了然问题是什么。
2、 一个完整的缺陷 告单，必须包含其必要的元素信息，例如：概要描述，缺陷发现人，测试环境，浏览器，缺陷重现步骤，严重等级，指派人，所属功能模块等等，必要元素信息必须描述全面清楚。
3、 缺陷的重现步奏必须描写清晰明了，使相关开发负责人能够根据重现步骤准确的重现所提交的缺陷，使其定位缺陷的原因所在。
4、 指派给人一定要明确，如知道缺陷是所属具体的某一个开发人员时，应该直接指派给对应的负责人，这样就能减少中间分配环节的时间。
5、 测试数据，测试的数据作为重现缺陷的一个重要元素信息，一定要将测试时所使用的信息给描写清楚准确。让开发人员根据测试所提供的测试数据准确重现缺陷。
6、 附件截图信息，附件或截图信息能让开发人员能够一目了然的清楚问题的所在，所以必要的时候提供附件或者截图信息也非常的重要。
7、描述缺陷内容的语气，在进行缺陷单书写时，尽量使用专业术语（体现测试的专业性），其次注意书写缺陷 告单时不要带有个人客观的语气内容，以免影响开发和测试人员之间的关系。
53.有个程序，在windows上运行很慢，怎么判断是程序存在问题，还是软硬件系统存在问题r> 1、检查系统是否有中度的特征，如：浏览器窗口连续打开，系统中文件图标改成统一图标，CPU使用率保存90%以上等
2、检查软件/硬件的配置是否符合软件的推荐标准
3、确认当前的系统是否是独立，即没有对外提供什么消耗CPU资源的服务，如：虚拟机运行
4、如果是C/S或者B/S结构的软件，需要检查是不是因为与服务器的连接有问题，或者访问有问题造成的；
5、在系统没有任何负载的情况下，查看性能监视器，确认应用程序对CPU/内存的访问情况，
54.你们发现bug会怎么处理。
提交bug、指派bug、确认bug、解决bug、重测bug、关闭bug、bug存档
新建（指派）–已解决（待验）–关闭
如果待验的BUG在验证时没有解决好，我们需要重新打开（激活）–指派—已解决—待验，循环这个过程。
中间其他状态：拒绝、延期等
BUG的处理流程图（生命周期图）
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！