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