测试面试题集-1.测试基础理论
Q:
一、进行测试用例设计的时候用到的方法有哪些？
A:
最常使用的测试用例设计方法包括等价类划分法、边界值分析方法、场景法、错误推测法。其中，最容易发现错误的是边界值法，使用最多的是场景法。以注册为例：首先从需求确定用户名和密码的长度类型约束，根据需求写测试点，然后设计测试数据，编写测试用例。
Q:
二、测试计划包括哪些主要步骤和信息？
A:
测试计划包括引言、测试基本内容（测试目的、测试范围、测试环境、测试工具、测试人员）、实施计划（任务分配、进度安排）、风险控制等。
Q:
三、测试报告需要包含哪些内容？测试报告交付文档有哪些？你认为测试报告的侧重点是什么？
A:
测试报告包括：引言、测试基本信息、测试结果及缺陷分析、测试结论和建议，交付文档。
交付文档有测试用例、提交的bug、测试报告。
测试报告的侧重点是测试结果和缺陷分析，测试结论。
Q:
四、bug的生命周期？你是怎么跟进bug的？
A:
bug的生命周期，就是一个bug被发现到这个bug被关闭的过程。生命周期中一般缺陷状态：新建、指派、已解决、待验、关闭。
具体流程如下：1.新建Bug，把bug记录到缺陷管理平台;2.指派给对应的开发人员；3.开发人员对Bug进行确认；4.开发对Bug进行修复；5.开发修改后，等新代码包更新测试环境，然后进行bug验证；6.如果Bug已经修复，测试人员直接关闭 ；7.如果待验的bug在验证时没有解决好，我们需要重新打开>指派>已解决>待验，循环这个过程。中间其他状态：重新打开、拒绝、延期等；8.如果提交bug后，开发一直没有修改状态，我们会提醒开发。延期、不予修改的bug则跟开发沟通，找产品确认是否修改。
Q:
五、Bug记录包含哪些内容？如何提交高质量的bug记录？
A:
一条bug信息至少需要以下几条：
bug标题；bug产生的模块；bug对应的版本；bug严重级别；优先级；bug详细现象描述，包括bug出现的操作步骤，报错日志信息、bug截图等等。
提交高质量的软件缺陷记录需要做到以下几点：
1.严格按照测试流程执行测试：参考需求以及详细设计等前期文档设计出高效的测试用例，然后严格执行测试用例，对发现的问题要充分确认肯定，然后再向外发布。
2.规范提交Bug：注重唯一性，一个bug说明一个问题或者说明一类问题可重现。
3.提交Bug注意准确性：提供这个bug的精确步骤，要让开发人员容易看懂一致；Bug描述及所有信息要前后一致，不可有歧义完整性。
4.明确指明缺陷严重等级和优先级：明确严重等级和优先等级之间的差别，优先解决优先级高的问题。
5.Bug附录：能附带bug现象截图的就带截图，有报错日志的就贴上日志信息客观性。
6.不可重现的缺陷也要记录：首先缺陷报告必须展示重现缺陷的能力。不可重现的缺陷要尽力重现，若尽力之后仍不能重现，仍然要报告此缺陷，但在报告中要注明无法再现，缺陷出现的频率。
7.明确指明缺陷类型：根据缺陷的现象，总结判断缺陷的类型。如，功能缺陷、界面缺陷、数据缺陷，合理化建议这是最常见的缺陷或缺陷类型，其他形式的缺陷或缺陷也从属于其中某种形式。
Q:
六、测试分为哪几个阶段?
A:
按照开发阶段划分，软件测试可以分为单元测试、集成测试、系统测试和验收测试；
1.单元测试：针对每个单元的测试，以及确保每个模块能正常工作为目标；
2.集成测试：对已测试过的模块进行组装，进行集成测试，目的在于检验与软件设计相关的程序结构问题；
3.系统测试：检验软件产品能否与系统的其他部分（比如硬件、数据库及操作人员）协调工作；
4.验收测试：检验软件产品质量的最后一道工序，主要突出用户的作用，同时软件开发人员也应有一定程度的参与。
Q:
七、什么是回归测试？
A:
回归测试有两类：用例回归和错误回归；用例回归是过一段时间以后再回头对以前使用过的用例在重新进行测试，看看会重新发现问题。错误回归，就是在新版本中，对以前版本中出现并修复的缺陷进行再次验证，并以缺陷为核心，对相关修改的部分进行测试的方法。
Q:
八、什么是验收测试？Alpha测试和Beta测试的区别是什么？
A:
验收测试是以用户为主的测试，软件开发和QA人员也应该参加，测试一般在用户所在地进行，由用户验证软件产品是否满足了所有的需求的一系列的验收测试工作。仅限于内部测试稳定后，根据合同中需求由发包商进行验收测试。验收测试的目的是为了以发现”未实现的需求”为目的，以评估”适合使用”为目标，该类测试的不是以发现缺陷为主要目的。
Alpha测试和Beta测试的区别：两者的主要区别是测试的场所不同。Alpha测试是指把用户请到开发方的场所来测试；beta测试是指在一个或多个用户的场所进行的测试。Alpha测试的环境是受开发方控制的,用户的数量相对比较少,时间比较集中。Alpha测试在系统开发接近完成时对应用系统的测试；测试后仍然会有少量的设计变更。这种测试一般由最终用户或其它人员完成，不能由程序或测试员完成。
Beta测试是当开发和测试基本完成时所做的测试，最终的错误和问题需要在最终发行前找到。这种测试一般由最终用户或其它人员完成，不能由程序员或测试员完成。
Q:
九、你提的问题，开发人员说不是BUG时，你如何应付？
A:
开发人员说不是bug，有两种情况，一是需求没有确定，所以可以找产品经理进行确认，评估是否需要改动，三方商量确定好后再看是否要改。二是这种情况开发认为不可能发生，所以不需要修改，这个时候，我可以先尽可能的说出BUG的依据是什么，如果被用户发现或出了问题，会有什么不良结果。如果还是有分歧，可以将这个问题提出来,跟开发经理和测试经理进行确认，确定是bug的话，一定要坚持自己的立场，让问题得到最后的确认。
Q:
十、测试结束的标准是什么？
A:
各个公司可能不同，以下仅供参考，具体根据公司实际情况执行。
1.系统测试用例设计已经通过评审；
2.按照系统测试计划完成了系统测试；
3.核心代码100％ 经过Code Review；
4.系统测试的功能覆盖率达100％；
5.系统的功能和性能满足产品需求规格说明书的要求；
6.在系统测试中发现的错误已经得到修改并且各级缺陷修复率达到标准；
7.严重错误和主要错误的缺陷修复率必须达到100%，不允许存在功能性的错误；次要错误和一般错误的缺陷修复率必须达到85%以上，允许存在少量功能缺陷，后续版本解决；对于较小错误的缺陷修复率最好达到60%~70%以上；对于测试建议性的问题，可调低优先级；
8.由开发经理，测试经理，项目经理共同确认后发布上线。
以上
That‘s all