1、介绍一下整体项目流程
答案：
1）搭建缺陷管理的环境和测试环境以及配置管理的环境搭建；2）编写测试计划；3）设计测试用例；4）编写测试用例；5）测试用例的评审；6）执行测试；7）缺陷管理； 8）测试报告的输出
2、在实际项目中你是如何做测试计划
答案：
1）对客户提供的或需求分析人员编写的用户需求文档或需求规格说明书进行分析，提炼出测试要点；
2）根据测试要点编写测试用例。
3）由评审组对测试用例进行评审--修改--再次评审--初步定稿
4）执行测试
（1）按照测试用例对系统进行功能验证及客户的需求验证
（2）将测试过程中产生的Bug 录入缺陷管理系统
（3）新版本发布后，对本次版本新增加的功能以及开发人员修正的Bug 进行回归测试
（4）根据项目需要提交测试报告。
3、你是如何制定测试过程中的时间进度表的
答案:根据项目的需求、开发周期、开发人员的开发进度等时间安排来制定一个测试时间进度初 稿，并将测试时间进度表交与整个项目团队成员大家一起讨论和分析，最终和所有人达成共识制定出一个大家都可以执行的测试时间进度表。
时间表中包括了开发人员提交功能或功能模块的时间，以及为了更好的执行测试，配合测试人员进行功能培训的时间，以及测试执行时间等，都详细的写到WBS 中，并按照这个时间进度表来执行项目的测试任务。
4、测试计划都包括那些项
答案：1. 测试计划目标 2. 测试参考文档 3. 测试术语与定义 4. 测试内容 5. 测试人员的分工 6. 测试进度 7. 测试流程 8. 测试工具 9. 测试缺陷管理 10. 测试的风险分析
5、测试用例如何设计的
答案：在测试用例设计之前首先要熟悉客户的需求文档或需求规格说明书，以做到对被测系统的熟悉，充分了解产品的详细功能，并在熟悉过程中即使与研发人员和客户人员进行有效的沟通。然后从需求中提炼中各个模块的详细功能点编写出一个测试要点的文档。根据测试要点设计测试用例，测试要点与测试用例是一个一对多的关系，一个测试要点可能会需要几个测试用例的验证，有正常的操作和异常的操作，甚至是几个正常与几个异常的操作，这要根据实际功能的要求来具体分析具体实现。
6、测试用例包括那些项
答案：产品名称、功能模块、用例的编号、编写人、被测功能的简述，测试的预置条件，测试步骤，预期结果，实际结果。
7、缺陷处理流程
1）讲缺陷的详细信息录入缺陷管理系统，并分配给对应的开发人员
2）如果遇到一些难以再现的缺陷，在开发人员修正过程中配合开发人员进行Bug 的再现。
3）开发人员修正Bug 后，会在缺陷管理系统中将修正后的Bug 状态更改，通常为Fixed 状态。
4）新版本发布后，测试人员会讲bug 状态已经更改为Fixed 的Bug 进行回归测试。如果测试通过，则将该Bug 关闭，如果仍未通过，则将该Bug 从Fixed 更改为Reopen 状态，继续让开 发人员来修正。并等待下一个新版本发布后的二次回归测试。
8、缺陷报告包括那些项
答案：编写人、被测系统的版本号、测试环境、预期结果、实际结果、对于实际结果如有必要附上截图、测试用例数、测试用例通过 数，测试用例的通过率、对缺陷的一个分析汇总。
9、缺陷报告严重级别的划分
严重级别的错误：影响系统整体基本流程运行的错误，由于某一操作造成系统死循环或服务器崩溃的错误
较严重：功能实现错误、内部计算错误、
一般：UI 错误，一些易用性的错误或建
10、开发人员修复缺陷后，如何保证不影响其他功能
答案：Bug 的修复以及新功能的添加都有可能对版本造成一些影响，为了避免，在新版本发布以后，首先会对新版本做一个基础的流程测试也叫做冒烟测试，如果测试基本流程都顺利通过没有任何问题，那么测试人员可以继续进行详细的测试，否则就将冒烟测试中出现 的问题以及问题有可能出现的原因反馈给开发人员，由开发人员修正后再次发版，进行测试。这是一个迭代的过程。
11、发现问题后你是如何判断其是否是BUG ，你是如何提交的？
答案：测试用例是经过评审组严格的评审，完全按照客户的需求规格说明书作为最终依据来评审的，如果测试过程中，测试结果与实际结果不符就很可能是Bug ，如果一些比较明显的问题就直接录入缺陷管理系统，如果是一些边界问题不容易确定的，可以通过和开发人员甚至是设计人员等进行沟通最后得出一个结果究竟是否是Bug ，如果是Bug 就录入，如果是一个需要增加的新功能等，可以录入缺陷管理系统，类型为新需求。
12、修复一个BUG 而导致其他的BUG 出现，该如何处理
答案：帮助开发人员分析问题锁定原因然后进行新Bug 的修正。
13、测试总结报告包括那些项
答案：测试用例的通过数，测试用例的未通过数，以及测试用例的通过率，未通过的功能都集中在哪几个功能模块 ，根据测试经验以及测试结果进行一个缺陷的分析和建议。
14、测试工作进行到一半是，发现时间不够，你如何处理
答案：1. 与客户沟通本次发布的版本什么是最重要的，什么是其次，我会安排一个优先级来对整体测试功能进行一个筛选。 2. 我会和测试组原体人员一起加班
15、开发与测试的关系
答案：开发和测试是一个整体，也可以说测试驱动着开发，开发配合着测试，相辅相成的，在一个完整的项目组中缺一不可。
16、如果你是测试组长你如何对项目及组员进行管理
答案： 首先要从需求开始，充分了解被测系统的功能以及业务需求，并在遇到问题的时候及时有效的与开发人员以及其他项目相关人员进行沟通，做到最被测系统的十分熟悉。并了解整个测试组的成员他们的测试技能以及擅长的工作，做到测试任务的合理分配，得以让测试工作快速，稳定高效的进行！
17、如果你提交的BUG 开发人员说这不是缺陷你该怎么办
答：若遇到开发人员说提交BUG 不是缺陷则跟项目组的需求人员，设计人员以及该功能的开发人员共同讨论做确认。
1、介绍一下整体项目流程
答案：
1）搭建缺陷管理的环境和测试环境以及配置管理的环境搭建；2）编写测试计划；3）设计测试用例；4）编写测试用例；5）测试用例的评审；6）执行测试；7）缺陷管理； 8）测试报告的输出
2、在实际项目中你是如何做测试计划
答案：
1）对客户提供的或需求分析人员编写的用户需求文档或需求规格说明书进行分析，提炼出测试要点；
2）根据测试要点编写测试用例。
3）由评审组对测试用例进行评审--修改--再次评审--初步定稿
4）执行测试
（1）按照测试用例对系统进行功能验证及客户的需求验证
（2）将测试过程中产生的Bug 录入缺陷管理系统
（3）新版本发布后，对本次版本新增加的功能以及开发人员修正的Bug 进行回归测试
（4）根据项目需要提交测试报告。
3、你是如何制定测试过程中的时间进度表的
答案:根据项目的需求、开发周期、开发人员的开发进度等时间安排来制定一个测试时间进度初 稿，并将测试时间进度表交与整个项目团队成员大家一起讨论和分析，最终和所有人达成共识制定出一个大家都可以执行的测试时间进度表。
时间表中包括了开发人员提交功能或功能模块的时间，以及为了更好的执行测试，配合测试人员进行功能培训的时间，以及测试执行时间等，都详细的写到WBS 中，并按照这个时间进度表来执行项目的测试任务。
4、测试计划都包括那些项
答案：1. 测试计划目标 2. 测试参考文档 3. 测试术语与定义 4. 测试内容 5. 测试人员的分工 6. 测试进度 7. 测试流程 8. 测试工具 9. 测试缺陷管理 10. 测试的风险分析
5、测试用例如何设计的
答案：在测试用例设计之前首先要熟悉客户的需求文档或需求规格说明书，以做到对被测系统的熟悉，充分了解产品的详细功能，并在熟悉过程中即使与研发人员和客户人员进行有效的沟通。然后从需求中提炼中各个模块的详细功能点编写出一个测试要点的文档。根据测试要点设计测试用例，测试要点与测试用例是一个一对多的关系，一个测试要点可能会需要几个测试用例的验证，有正常的操作和异常的操作，甚至是几个正常与几个异常的操作，这要根据实际功能的要求来具体分析具体实现。
6、测试用例包括那些项
答案：产品名称、功能模块、用例的编号、编写人、被测功能的简述，测试的预置条件，测试步骤，预期结果，实际结果。
7、缺陷处理流程
1）讲缺陷的详细信息录入缺陷管理系统，并分配给对应的开发人员
2）如果遇到一些难以再现的缺陷，在开发人员修正过程中配合开发人员进行Bug 的再现。
3）开发人员修正Bug 后，会在缺陷管理系统中将修正后的Bug 状态更改，通常为Fixed 状态。
4）新版本发布后，测试人员会讲bug 状态已经更改为Fixed 的Bug 进行回归测试。如果测试通过，则将该Bug 关闭，如果仍未通过，则将该Bug 从Fixed 更改为Reopen 状态，继续让开 发人员来修正。并等待下一个新版本发布后的二次回归测试。
8、缺陷报告包括那些项
答案：编写人、被测系统的版本号、测试环境、预期结果、实际结果、对于实际结果如有必要附上截图、测试用例数、测试用例通过 数，测试用例的通过率、对缺陷的一个分析汇总。
9、缺陷报告严重级别的划分
严重级别的错误：影响系统整体基本流程运行的错误，由于某一操作造成系统死循环或服务器崩溃的错误
较严重：功能实现错误、内部计算错误、
一般：UI 错误，一些易用性的错误或建
10、开发人员修复缺陷后，如何保证不影响其他功能
答案：Bug 的修复以及新功能的添加都有可能对版本造成一些影响，为了避免，在新版本发布以后，首先会对新版本做一个基础的流程测试也叫做冒烟测试，如果测试基本流程都顺利通过没有任何问题，那么测试人员可以继续进行详细的测试，否则就将冒烟测试中出现 的问题以及问题有可能出现的原因反馈给开发人员，由开发人员修正后再次发版，进行测试。这是一个迭代的过程。
11、发现问题后你是如何判断其是否是BUG ，你是如何提交的？
答案：测试用例是经过评审组严格的评审，完全按照客户的需求规格说明书作为最终依据来评审的，如果测试过程中，测试结果与实际结果不符就很可能是Bug ，如果一些比较明显的问题就直接录入缺陷管理系统，如果是一些边界问题不容易确定的，可以通过和开发人员甚至是设计人员等进行沟通最后得出一个结果究竟是否是Bug ，如果是Bug 就录入，如果是一个需要增加的新功能等，可以录入缺陷管理系统，类型为新需求。
12、修复一个BUG 而导致其他的BUG 出现，该如何处理
答案：帮助开发人员分析问题锁定原因然后进行新Bug 的修正。
13、测试总结报告包括那些项
答案：测试用例的通过数，测试用例的未通过数，以及测试用例的通过率，未通过的功能都集中在哪几个功能模块 ，根据测试经验以及测试结果进行一个缺陷的分析和建议。
14、测试工作进行到一半是，发现时间不够，你如何处理
答案：1. 与客户沟通本次发布的版本什么是最重要的，什么是其次，我会安排一个优先级来对整体测试功能进行一个筛选。 2. 我会和测试组原体人员一起加班
15、开发与测试的关系
答案：开发和测试是一个整体，也可以说测试驱动着开发，开发配合着测试，相辅相成的，在一个完整的项目组中缺一不可。
16、如果你是测试组长你如何对项目及组员进行管理
答案： 首先要从需求开始，充分了解被测系统的功能以及业务需求，并在遇到问题的时候及时有效的与开发人员以及其他项目相关人员进行沟通，做到最被测系统的十分熟悉。并了解整个测试组的成员他们的测试技能以及擅长的工作，做到测试任务的合理分配，得以让测试工作快速，稳定高效的进行！
17、如果你提交的BUG 开发人员说这不是缺陷你该怎么办
答：若遇到开发人员说提交BUG 不是缺陷则跟项目组的需求人员，设计人员以及该功能的开发人员共同讨论做确认。