2023年6月21日发(作者：)

测试⾯试题1.B/S架构和C/S架构区别 c是客户端 b是浏览器CS响应速度快，安全性强，⽤户体验好，⼀般应⽤于局域⽹中，但是开发维护成本⾼，；BS可以实现跨平台，客户端零维护，但是个性化能⼒低，响应速度较慢。所以有些单位⽇常办公应⽤BS，在实际⽣产中使⽤CS结构协议HTTP协议定义Web客户端如何从Web服务器请求Web页⾯，以及服务器如何把Web页⾯传送给客户端。HTTP协议采⽤了请求/响应模型。客户端向服务器发送⼀个请求报⽂，请求报⽂包含请求的⽅法、URL、协议版本、请求头部和请求数据。服务器以⼀个状态⾏作为响应，响应的内容包括协议的版本、成功或者错误代码、服务器信息、响应头部和响应数据与GET区别1、GET使⽤URL或Cookie传参。⽽POST将数据放在BODY中。2、GET的URL会有长度上的限制，2kb，则POST的数据则可以⾮常⼤。3、POST⽐GET安全，因为数据在地址栏上不可见。4、⼀般get请求⽤来获取数据，post请求⽤来发送数据和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.再根据需求⽂档来确认是否为BUG3.如果开发不认为是BUG的将复现BUG的记录和需求⽂档找产品经理和项⽬经理来确定是否BUG4.如果项⽬经理和产品经理都不认为是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，那是因为预期的主体千姿百态。和测试员预期不⼀致的软件⾏为。和程序员预期不⼀致的软件⾏为。和⽂档预期不⼀致的软件⾏为。和管理者预期不⼀致的软件⾏为。和客户预期不⼀致的软件⾏为机吞卡的吞卡现象是不是BUG?不是是特意设置的安全措施防⽌有⼈马虎，操作后忘记取⾛银⾏卡⽽被⼈冒领卡中的钱款所以特意设置了倒计时，限时内没有取⾛银⾏卡就会吞卡52.如何减少⾮问题单的提交？53.有个程序，在windows上运⾏很慢，怎么判断是程序存在问题，还是软硬件系统存在问题？1、检查系统是否有中度的特征，如：浏览器窗⼝连续打开，系统中⽂件图标改成统⼀图标，CPU使⽤率保存90%以上等2、检查软件/硬件的配置是否符合软件的推荐标准3、确认当前的系统是否是独⽴，即没有对外提供什么消耗CPU资源的服务，如：虚拟机运⾏4、如果是C/S或者B/S结构的软件，需要检查是不是因为与服务器的连接有问题，或者访问有问题造成的；5、在系统没有任何负载的情况下，查看性能监视器，确认应⽤程序对CPU/内存的访问情况，54.你们发现bug会怎么处理。

2023年6月21日发(作者：)

测试⾯试题1.B/S架构和C/S架构区别 c是客户端 b是浏览器CS响应速度快，安全性强，⽤户体验好，⼀般应⽤于局域⽹中，但是开发维护成本⾼，；BS可以实现跨平台，客户端零维护，但是个性化能⼒低，响应速度较慢。所以有些单位⽇常办公应⽤BS，在实际⽣产中使⽤CS结构协议HTTP协议定义Web客户端如何从Web服务器请求Web页⾯，以及服务器如何把Web页⾯传送给客户端。HTTP协议采⽤了请求/响应模型。客户端向服务器发送⼀个请求报⽂，请求报⽂包含请求的⽅法、URL、协议版本、请求头部和请求数据。服务器以⼀个状态⾏作为响应，响应的内容包括协议的版本、成功或者错误代码、服务器信息、响应头部和响应数据与GET区别1、GET使⽤URL或Cookie传参。⽽POST将数据放在BODY中。2、GET的URL会有长度上的限制，2kb，则POST的数据则可以⾮常⼤。3、POST⽐GET安全，因为数据在地址栏上不可见。4、⼀般get请求⽤来获取数据，post请求⽤来发送数据和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.再根据需求⽂档来确认是否为BUG3.如果开发不认为是BUG的将复现BUG的记录和需求⽂档找产品经理和项⽬经理来确定是否BUG4.如果项⽬经理和产品经理都不认为是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，那是因为预期的主体千姿百态。和测试员预期不⼀致的软件⾏为。和程序员预期不⼀致的软件⾏为。和⽂档预期不⼀致的软件⾏为。和管理者预期不⼀致的软件⾏为。和客户预期不⼀致的软件⾏为机吞卡的吞卡现象是不是BUG?不是是特意设置的安全措施防⽌有⼈马虎，操作后忘记取⾛银⾏卡⽽被⼈冒领卡中的钱款所以特意设置了倒计时，限时内没有取⾛银⾏卡就会吞卡52.如何减少⾮问题单的提交？53.有个程序，在windows上运⾏很慢，怎么判断是程序存在问题，还是软硬件系统存在问题？1、检查系统是否有中度的特征，如：浏览器窗⼝连续打开，系统中⽂件图标改成统⼀图标，CPU使⽤率保存90%以上等2、检查软件/硬件的配置是否符合软件的推荐标准3、确认当前的系统是否是独⽴，即没有对外提供什么消耗CPU资源的服务，如：虚拟机运⾏4、如果是C/S或者B/S结构的软件，需要检查是不是因为与服务器的连接有问题，或者访问有问题造成的；5、在系统没有任何负载的情况下，查看性能监视器，确认应⽤程序对CPU/内存的访问情况，54.你们发现bug会怎么处理。