【2017年整理】软件测试面试题.docx

面试题1.测试用例通常包括那些内容？着重阐述编制测试用例的具体做法不同结构的用例包括的不一样。（版本、编号、项目、设计人员、设计日期、输入、预期输出……）　?????软件测试用例的基本要素包括测试用例编号、测试标题、重要级别、测试输入、操作步骤、预期结果。??用例编号： 测试用例的编号有一定的规则，比如系统测试用例的编号这样定义规则：?PROJECT1-ST-001?，命名规则是项目名称＋测试阶段类型（系统测试阶段）＋编号。定义测试用例编号，便于查找测试用例，便于测试用例的跟踪。??测试标题： 对测试用例的描述，测试用例标题应该清楚表达测试用例的用途。比如?“?测试用户登录时输入错误密码时，软件的响应情况?” .重要级别： 定义测试用例的优先级别，可以笼统的分为?“?高?”?和?“?低?”两个级别。一般来说，如果软件需求的优先级为?“?高?”?，那么针对该需求的测试用例优先级也为?“?高?”?；反之亦然，测试输入： 提供测试执行中的各种输入条件。根据需求中的输入条件，确定测试用例的输入。测试用例的输入对软件需求当中的输入有很大的依赖性，如果软件需求中没有很好的定义需求的输入，那么测试用例设计中会遇到很大的障碍。???操作步骤： 提供测试执行过程的步骤。对于复杂的测试用例，测试用例的输入需要分为几个步骤完成，这部分内容在操作步骤中详细列出。???预期结果： 提供测试执行的预期结果，预期结果应该根据软件需求中的输出得出。如果在实际测试过程中，得到的实际测试结果与预期结果不符，那么测试不通过；反之则测试通过。2.描述使用bugzilla缺陷管理工具对软件缺陷（BUG）跟踪的管理的流程?? 1）首先由QA/TESTER 发现bug后，填写bug 报告，bug 的状态设为NEW,提交给管理人员；?? 2）管理人员会assigned 给对应模块的开发人员，bug 的状态为Assigned；?? 3）开发人员修复bug，并把bug的处理意见设置为fixed/invalid/wonfix/later/remind/duplicate/worksforme，系统会自动发邮件给bug的reporter人；?? 4)申报者接到处理意见后，验证该bug是否被修复，若被修复设置bug的状态为 verified，若问题仍然存在则设置为reopened ,若是其他意见设置为resolved。?? 5）当bug 被verified ，可以由管理人员关闭该bug。3.如果时间不够，无法进行充分的测试怎么办?使用风险分析，确定测试的重点。由于很少有机会对一个应用软件进行所有可能的测试?(包括所有可能的事件组合、所有的相关性、或者一切可能出错的东西)，对大多数软件开发项目来说，利用风险分析是适当的。这需要判断技能、常识、感觉和经验。如果有正当理由，也可采用正式的方法。需要考虑下列因素：1)?对于该项目的用途而言，哪种功能最重要?j2)?哪种功能对用户最明显?3)?哪种功能对安全影响最大?4)?哪种功能对用户最有用?5)对客户来说，该应用软件的哪个部分最重要?6)在开发过程中，该应用软件的哪个部分可以最先测试?7)哪一部分代码最复杂，容易导致出现错误?8)哪一部分的应用程序是在急迫或在惊恐的情况下开发出来的?9)哪一部分程序与过去项目中引起问题的部分相类似/有关?10)哪一部分程序与过去项目中需要大量维护的部分相类似/有关?11)需求和设计的那些部分不清楚或不容易读?12)开发人员认为在应用软件中哪些部分是高风险的?13)哪些问题能造成最差的发行?14)哪些问题最能引起用户抱怨?15)哪些测试可以容易地覆盖多种功能?16)哪些测试在覆盖高风险部分的测试时使用时间最少?4. 如果需求一直在变化怎么办?1)如果可能，尽早与承担该项目风险的人接触，以便了解需求会怎样改变，从而可以尽早地改变测试计划和策略。2)如果在对应用程序进行初始设计时多考虑一些适应性，那么以后在发生需求的改变时，就不需要再为改变做很多事情了。3)好的代码注释和好的文档有助于开发人员作出相应的改变。4)只要有可能，就应使用快速原型?(rapid prototyping)，以帮助用户确认他们的需求，从而减少变更。5)在项目的时间表中应当留出余量，以应付可能出现的变更。6)尽量把新的需求纳入应用软件的“下一版”，而把原始需求作为“第一版”。7)通过谈判，把易于实现的新的变更列入项目，而把难于实现的新需求列入该应用软件的以后的版本。8)要确保让客户和管理人员了解变更对进度表的影响、所带来的风险、以及因变更所引起的大量资金消耗。9)在应付改变时，应在为建立自动测试而作的努力和重新进行测试所做的努力之间取得平衡。10)在设计自动测试剧本时，试图使其有一些灵活性。11)在对应用软件进行自动测试时，要把注意力集中在看