软件测试常见问题

1、1、哪个阶段引入的bug最多？哪个最少？需求分析阶段引入的bug最多（大概占bug总数的55%左右）其次是设计阶段（大概占bug总数的25%左右）引入bug最少的是编码阶段（大概占bug总数的15%左右）最后还有5%左右的bug是由兼容性问题或配置原因造成的。由此总结：（1）测试不能只测程序，文档也必须要测。测试应符合“尽早测试原则”和“不断测试原则”。2、如何识别缺陷？1、参考需求相关文档-与需求不符就是bug2、参考缺陷的5条定义说明：定义与顺序无关，只要满足其中任何一条就是bug。（1）需求要求的功能没有实现。（2）实现了需求没有要求的功能。（画蛇添足）（3）软件中出现了指明不应该出现的

2、错误。（4）需求虽未明确说明，但是应该实现的功能没有实现。（5）软件不易使用，难以理解，运行缓慢等，站在用户角度上，一切不好的地方。3、参考测试用例中的预期结果-实际结果与预期结果不一致就是bug4、通过与同事、开发人员、产品经理、客户等沟通讨论来确定bug。3、OS的作用？操作系统可以对计算机的软件和硬件进行统一管理。4、裸机中有软件吗？裸机中有软件。BIOS （basic input output system基础输入输出系统）程序被安装在 计算机主板的CMOS芯片中。计算机通电后，“BIOS”程序首先获得控制权。对计算机进行“上电自检”-BIOS首先获 得计算机的控制权，检查硬件设备的连

3、接情况是否完好，如果检查没有问题，就将控制 权转交给OS;如果硬件连接有问题，就启动蜂鸣器，发出报警音，同时阻止OS启动。5、c/s和b/s的区别？c/s :客户端需要安装专门的客户端程序，才能享受服务器提供的服务。例如：QQ、 滴滴打车等B/S :客户端无需安装专门的客户端程序，只需要有公共的浏览器，在浏览器中输入 不同的网址就可以享受不同服务器提供的服务。例如：百度网站等6、软件项目的测试流程？步骤1：需求分析步骤2 :制定测试计划（问题：测试计划的主要组成）步骤3 :设计测试的过程（分析设计测试用例）步骤4：执行测试，记录测试的结果（通过pass，失败failed）步骤5 :记录缺陷，跟

4、踪和管理缺陷（缺陷报告）步骤6 :测试总结（提交测试报告测试总结报告）要求：必须熟练掌握，并且有项目经验后，要能够结合项目说明。7、你们公司缺陷报告都包含什么？1）缺陷编号（defect ID）记录发现bug的顺序号在工具中缺陷编号是自动生成的，可以唯一标识每条缺陷。说明：在企业中项目的缺陷是统一管理的，所以编号是统一生成，不是只生成自己的。2）缺陷标题（summary）简明扼要的将缺陷描述出来（概括）说明：没有标准答案，老师给的也只是参考。3）缺陷发现者/创建者（detected by）测试人员发现bug，填写自己的工作账号4）提交缺陷的日期（detected on date）注意：发现缺陷

5、后应及时提交缺陷。说明：1、发现缺陷应确认审核，尽量避免提交“假bug2.缺陷“审核”后，不要人为 延误应及时提交。5）指派给谁（assigned to）指派过程：首先：测试人员一开发方负责人接下来：开发方负责人一具体负责的开发人员6）功能模块（subject）定位在哪个模块中发现的该bug说明：开发方负责人可以通过功能模块，明确解决该bug的对应开发人员。7）版本（detected in release）说明：在软件研发过程中出现的若干临时版本，和软件最终发布的版本都是版本， 都需要测试。8）状态（status）表明该缺陷处于怎样的处理情况。缺陷的状态：新的（new）激活的（open）已解决

6、的（fixed）关闭的（closed）被拒绝的（rejected）重新激活的（reopen）9）缺陷的严重程度（severity）表明缺陷有多糟糕，对程序的影响有多坏。严重级别：（1,2,3,4）致命的（urgent）严重的（high）中等的（medium）-最多建议性的小问题（low）发现问题：严重级别的定义过于笼统，容易在实际工作中引起争议，所以公司通常会编 写级别的详细说明，进一步规范级别的划分。注意：严重级别定义应专业、准确，不应为了引起开发方重视而故意夸大。不同公司、项目组严重级别详细说明可能不同，工作中要注意参考。10）缺陷的优先级（priority）表明的是希望或者建议开发方在什

7、么时候，什么版本解决该bug。优先级的级别：立即解决（urgent）下一个版本解决（high）-常用软件产品发布之前解决（medium）尽量在软件发布之前解决（low）注意：对于优先级不同公司的详细说明可能不同，要注意参考。11）缺陷描述（description）通过将发现的过程和数据记录下来，使开发人员能够重现该bug。（开发人员能看明 白）要求：逻辑要清晰，用语应专业、准确，描述应易读、易懂，在描述中不要出现任何 评价性的语言。如实记录缺陷。8、什么是回归测试？为什么要进行回归测试？回归测试就是在当前版本中，对上一个版本中测过的所有功能点，再重新测试一遍。回归测试的必要性：通过回归测试验证

8、当前版本中:新增加的功能对原有功能是否有 影响，带来bug ；修复的bug是否同时带来了新的问题。回归测试存在重复，建议使用自动化的方式进行，可以大大提高回归测试效率。Rejected |9、缺陷的跟踪管理过程（生命周期、一生、流程、步骤）？1、渺试人员提交缺路New5、测试人员返测映陷 通过开发人员和测 善人炭共同淡 不是Rejected |9、缺陷的跟踪管理过程（生命周期、一生、流程、步骤）？1、渺试人员提交缺路New5、测试人员返测映陷 通过开发人员和测 善人炭共同淡 不是3、开发人员修改此缺陷4、抵陷修改完毕2、开苴统理睑还此缺陷Closed步骤1：测试人员提交新的bug给开发方负责人

9、。步骤2 :开发方负责人审核bug，情况1 : bug审核通过，开发方负责人将会激活bug，并指派给相应的开发人员。情况2 : bug审核未通过，开发方将拒绝bug。步骤3：开发人员解决bug，解决后将缺陷设置为“已解决”状态。（待返测的bug）步骤4 :测试人员对已解决的bug进行返测，情况1：返测通过，测试人员将bug关闭。情况2：返测未通过，测试人员将缺陷重新激活，并指派回开发人员继续解决，直 到返测通过，bug关闭为止。10、关于严重程度和优先级的面试题。Q1:影响优先级的因素有哪些？（1）缺陷的严重程度，一般越严重，优先级越高。（2）开发人员的开发压力，开发压力越小，解决bug的优先

10、级越高。（3）缺陷的影响范围，影响范围越大，bug的优先级越高。（4）解决bug的成本（时间），成本越小，优先级越高。Q2 :缺陷的严重程度和优先级一定是严格成正比关系吗？缺陷的严重程度和优先级不是严格成正比的，例如：界面的错别字，就是严重级别低, 但是优先级高的情况。Q3 :优先级和严重程度一旦确定后能改吗？严重程度一旦确定不能修改；优先级一般能改，而且经常延后处理。Q4 :是否存在发布的软件中，有bug是发现了但是没有解决的情况？在发布的软件中可能存在发现但是没有解决的bug。此类bug应通过“bug讨论”，在 权衡解决的成本，和不解决是否给用户带来严重后果，以及是否会造成法律纠纷后才能

11、决定。关于此类bug，软件企业通常通过后期升级版本或者打补丁的方式给予解决。11、随机缺陷（随机bug或不可重现bug）概念：随机缺陷就是按照相同的操作过程操作，时有时无的bug。（always 一直/sometime 有时）12、测试人员如何处理随机bug ?（1）随机bug也必须要报告（2）测试人员在提交随机bug时应该说明该bug为随机缺陷。测试人员应尽量详细的记录发现随机bug的过程（步骤，数据），并且尽量能够 提供证迹（截图或视频）。测试人员应尽量配合开发人员对随机bug进行缺陷调查，例如：配合保留测试环 境；配合提供随机bug的出现频率等。可以加入白盒测试，参与到测试调查中。13、

12、测试用例/案例？主要组成：用例编号、测试目的、测试步骤（过程、数据）、预期结果等 编写用例的注意事项:（1 ）在编写用例之前，应明确用例编号的格式要求，还有如果用例带有附件，附件的 命名，提交位置等。（2）用例必须要评审互评互审、测试评审会（小组）、甲方参与的评审会（3）编写测试用例的要求基本要求：就是先能写好一条用例。其他测试人员能够顺利执行你写的用例。高级要求：测试人员要能够独立完成测试的分析和设计，形成较为完善的测试方案 （思路）。标准：测试的覆盖率高，遗漏bug少，效率高。14、测试用例的参考资料有？（如何没有需求文档应该怎么测试？）1、用户的需求（需求相关文档）2、核心的技术文档（测

13、试方不一定拿到，例如：开发与测试不是同一家公司）3、已开发的被测系统（工作中经常参考被测系统测试，只参考需求大概只能完成20%-40%的测试设计）4、测试人员要与开发、产品经理、客户等淘通讨论。另外要利用好网络资源，查找资料，参考同类软件产品等（说明：参考资源可能不齐全，测试人员应利用一切可利用资源，尽自己所能测试）15、测试用例的作用？（理解）（1）编写用例会提高测试的覆盖率（测的更全）。（2）测试用例可以提高测试效率。（3）面对重复性的测试工作时，测试用例可以重复执行。（例如：回归测试）（4）利用测试用例可以监督测试过程，评估测试质量。（5）利用测试用例，可以缩短测试周期-如果项目升级或二

14、次开发时，保留原有 用例，只需对修改部分设计测试即可，大大缩短测试周期。16、黑盒/功能测试的方法有？1、等价类划分法场合：软件中有数据输入的地方名词：有效等价类（正向测试:对程序来说，正确的、合理的输入数据集合。-验证功能是否正确实现无效等价类（反向测试）：对程序来说，错误的、不合理的输入数据集合。-验证 软件的异常处理能力（健壮性）方法：将大量数据划分成若干范虱 再从每个范围中挑选少量代表数据进行测试。（抽样测，效率高）*数轴*2、边界值法场合：有数据输入的地方；多个选项的下拉列表名词:最大值，最小值，次边界（临近边界值）方法：和等价类边界值一块使用 侑效，无效，最大，最小（临近）例子：（

15、等价类边界值）最小值min最大值mwx3场景法（基于业务的测试方法）场合：界面填写项较少，业务逻辑较复杂名词：基本流（正确流）备选流（错误流）步骤：根据业务列出场景（测试点、测试需求点）根据场景编写用例4、因果图法判定表场合：（梳理关系比较复杂场景和业务）控件组合（组合数量少于20种）。名词：因：输入条件果：输出结果因果图：用画图的方式表示输入条件和输出结果之间的关系。（1）基本图形符号表示因-果之间的关系真：1或true假：0 或 false1）恒等如果a=1，那么b=1如果a=0，那么如果a=0，那么b=01SW2）与全1为1，有0为03）或（了解）含义：全0为0,有1为14）非（了解）取

16、反如果a = 1那么b=0如果a=0那么b=1（2）限制图形符号表示的是要么因之间，要么果之间相互的制约限制（单方面的限制）1）互斥（E-Exclude）可以不选，但是如果选只能选1个。互斥2）唯一（O-only）只能选1个（不能不选，不能多选，只能选择1个）问题：唯一和互斥有什么区别？唯一必须要选1个，而互斥可以不选。3）包含（I-include）了解要求至少选1个（允许多选，但是不能不选）包舍4）要求（R-require）如果a=1，要求b必须=1如果a=0, b无所谓因5）屏蔽（M-masked）了解如果a=1，那么b必须二0如果a=0,那么b可能是1也可能是0 （无所谓，1或0都有可能

17、）因a屏蔽b判定表组成L*观则加规则2，规则3 规则4 1规则54规则aL1TTuT 口F 口FPFtC21TzAFpTpTpFe至口 -王口 -l食谜。(矛I 必11X】X !A2 11X】条件桩动作机-一37条件项动作项判定表特点（了解）1）输入条件的顺序无关紧要2）输出结果的顺序也无关紧要3）先测哪个组合后测哪个组合无关紧要4）每个组合都是相互独立的，所以先测哪个组合，后测哪个组合无所谓。方法：（因果图与判定表）根据业务的之前的因果关系进行画图，然后用进行判定表进行情况和结果表达。例子：被测系统：交通一卡通充值分析需求，列出输入条件（因）投币：50元、100元充值金额：50元、100元分

18、析，列出输出结果（果1）充值成功和退卡2）找零3）错误提示和退卡12345678输 入 条 件1、投币50元1112,投币100元3,充值50元14,充值1001日、充值成功和退卡1b、找零11c.错误提示和退卡11限制1 + 23+41 2. 3. 限制1 + 23+41 2. 3. 45、测试大纲法场合：程序中有多个界面（例如安装、卸载测试）步骤：列大纲（窗口和操作）写用例正交排列法场合：控件组合（组合数量大）步骤：列出控件和控件的取值选择合适的正交表Ln（mk ）n:行数in:展中每列最大值-由控件取值个数确定k:列数-控件个数确定映射：控件名称和取值填到正交表中根据正交表填写测试用例1

19、7、正交排列法和判定表的异同？1、都可以用来测试控件之间的组合情况。2、判定表常用来测试组合少的情况。-测的全，但是效率低。3、正交排列法适合测试组合数量多的情况。-抽样测，效率高4、判定表法测试时考虑控件之间的组合和限制情况，而正交排列法只是考虑控件 之间的组合。18、场景法的测试思路在接到一个测试任务时，通常先使用场景法将整体业务流程、逻辑进行测试，当整 体流程，核心业务没有问题时，再通过等价类、边界值、判定表等方法对细节进行测试。（思路：先整体后细节）V模型用需求验收测试需求分析系统删试概要设计集成洲试 .,I详细设讣爪元.测试编码A:优点：开发阶段和测试阶段划分清晰，对应关系清晰B：缺

20、点：容易理解成测试是在开发完成后才开始的；也没有体现出文档测试C :深入理解：开发每个阶段产生了相关的文档，测试人员应该参与文档测试；根据相 关的开发文档，应该编写测试对应阶段的测试计划和测试用例-测试和开发是并行展 开工作的模型展开：一、软件开发阶段需求分析（1）需求分析师或产品经理，了解客户需求（2）编写需求设计说明书概要设计 （1）系统架构师/系统分析师（2）编写概要设计手册详细设计（1）系统架构师（2）编写详细设计手册4编码（1）程序员（2）程序 二、软件测试阶段划分单元测试（unit testing ）（1）是最小的测试单位，一般是一个子模块、函数（方法、类等（2）依据是详细设计说明

21、书（3）主要使用黑盒（功能）测试方法，核心模块结合白盒测试方法（看代码）（4）目前实际工作中，单元测试工作主要由开发人员自己完成-节约成本，但不严格（5）可能需要测试人员编写驱动模块或桩模块驱动模块：模拟被测模块的上一级模块（调用被测模块的当前模块）桩模块：模拟被测模块的下一级模块（被被测模块调用的模块）集成测试（integrated testing）（1）也叫组装测试，把开发好的新功能逐步向主程序添加后，进行测试的过程（2）会形成很多临时版本（内部版本）（3）测试以黑盒为主，核心功能结合白盒测试，更关注模块之间的调用关系是否正确（4）主要参考概要设计说明书（5）拿到新版本先做冒烟测试：用较少

22、人员（1-5人，经验丰富），较少时间（0.5-2天）对软件核心的功能模块 进行大致测试，主要验证该软件是否可以进行全面测试（一般不会逐条执行用例，而是有选择性）（6）软件集成的方式人:自顶向下深度优先：把相关功能的所有子模块集成起来，便于测试一个完整的业务功能广度优先：把同一级的模块同时优先进行集成，不便于看到软件的完整子功能B：自底向上。：混合系统测试（system testing）（1）整个软件系统集成完毕，形成安装文档或部署文档，在较为真实的软硬件环境中（尽量是实际生产环境），进 行全面测试的过程（2 ）系统测试的依据是需求规格说明书（3）全面的黑盒测试方法，再结合兼容性测试、性能测试、

23、安装测试等（4）在系统测试之前，一般做一个确认测试”，主要确认：A:确认开发组发布的版本，可以进行全面的系统测试（冒烟测试）B:确认相关的文档齐全、正确（尤其给用户的文档）说明：确认测试一般时间较短，不要把它单独当做体格测试阶段验收测试（user acceptance testing，UAT用户接受度测试）（1）主要由用户参与的测试（2）一般分为alpha测试和beta测试Alpha测试：开发方完成整个系统后，经过了系统测试后，再组织用户（一般也是开发方充当）在开发方的环境 中，对软件进行检查Beta测试：在用户的实际使用环境中，由最终用户完成对软件的检查对于公共类的软件（操作系统、办公软件、

24、游戏.），一般发布公测版，让用户下载使用，收集问题反馈（3）验收测试不需要写测试用例，完全站在用户使用角度、体验度角度20.W模型（双V模型）（1）第一个V表示开发阶段（2）第二个V表示测试阶段（3）体现出了文档测试（4）但没有体现出测试计划和测试用例 其他模型：X模型、H模型21、软件测试的分类（软件测试方法、测试策略）按测试技术分类（1）黑盒测试（功能测试）也叫功能测试，是不考虑程序的内部结构，只知道程序的输入和输出的情况下， 进行的功能验证的测试方式。单元测试、集成测试、系统测试必须采用的方法（2）白盒测试（结构测试、逻辑结构测试）也叫结构测试，是只考虑程序的内部结构， 而不考虑外部功能的测试方式。A :通过检查程序代码发现bugB:要求测试人员懂得代码C:白盒测试是降低软件风险的补充测试，是在黑盒测试基础上补充的，一个模 块不能只做白盒测试而不做黑盒测试D :白盒测试的成本较高（时间成本、人力成本）E：白盒测试有专门的方法，需要写白盒测试用例F：单元测试用的最多，集成测试也可能会用，系统测试完全不用（3）灰盒测试=黑盒+白盒在集成测试中经常采用，以黑盒测试为主，对于模块之间的调用关系或者出现 错误的情况下，检查代码按是否需要运行代码分类（1）静态测试A:不运行程序的测试过程B :主要包括：代码测试，界面测试，文档测试C：静态测试中的代码测试主要检