测试面试问题及答案

验以及真是的项目实践流程来编写的，不能说这就是最终的正确答案，但是希望整理出来能给大家一些参考和帮助！如果大家有更好的答案不妨写到帖子当中，我们共同讨论

1、介绍一下整体项目流程

答案：

测试用例；5.测试用例的评审；6.执行测试；7.缺陷管理； 8.测试报告的输出

2、在实际项目中你是如何做测试计划

答案：

1.对客户提供的或需求分析人员编写的用户需求文档或需求规格说明书进行分析，提炼出测试要点；

2.根据测试要点编写测试用例。

3.由评审组对测试用例进行评审--修改--再次评审--初步定稿

4.执行测试

按照测试用例对系统进行功能验证及客户的需求验证

将测试过程中产生的Bug录入缺陷管理系统

新版本发布后，对本次版本新增加的功能以及开发人员修正的Bug进行回归测试

根据项目需要提交测试报告。

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的修复以及新功能的添加都有可能对版本造成一些影响，为了避免，在新版本发布以后，首先会对新版本做一个基础的流程测试也叫做冒烟测试，如果测试基本流程都顺利通过没有任何问题，那么测试人员可以继续进行详细的测试，否则就将冒烟测试中出现的问题以及问题有可能出现的原因反馈给开发人员，由开发人员修正后再次发版，进行测试。这是一个迭代的过程。

10、发现问题后你是如何判断其是否是BUG，你是如何提交的、

答案：测试用例是经过评审组严格的评审，完全按照客户的需求规格说明书作为最终依据来评审的，如果测试过程中，测试结果与实际结果不符就很可能是Bug，如果一些比较明显的问题就直接录入缺陷管理系统，如果是一些边界问题不容易确定的，可以通过和开发人员甚至是设计人员等进行沟通最后得出一个结果究竟是否是Bug，如果是Bug就录入，如果是一个需要增加的新功能等，可以录入缺陷管理系统，类型

为新需求。

11、修复一个BUG而导致其他的BUG出现，该如何处理

答案：帮助开发人员分析问题锁定原因然后进行新Bug的修正。

12、测试总结报告包括那些项

答案：测试用例的通过数，测试用例的未通过数，以及测试用例的通过率，未通过的功能都集中在哪几个功能模块，根据测试经验以及测试结果进行一个缺陷的分析和建议。

13、测试工作进行到一半是，发现时间不够，你如何处理

答案：1.与客户沟通本次发布的版本什么是最重要的，什么是其次，我会安排一个优先级来对整体测试功能进行一个筛选。

2.我会和测试组原体人员一起加班

14、开发与测试的关系

答案：开发和测试是一个整体，也可以说测试驱动着开发，开发配合着测试，相辅相成的，在一个完整的项目组中缺一不可。

15、如果你是测试组长你如何对项目及组员进行管理

答案：首先要从需求开始，充分了解被测系统的功能以及业务需求，并在遇到问题的时候及时有效的与开发人员以及其他项目相关人员进行沟通，做到最被测系统的十分熟悉。并了解整个测试组的成员他们的测试技能以及擅长的工作，做到测试任务的合理分配，得以让测试工作快速，稳定高效的进行！

16、如果你提交的BUG开发人员说这不是缺陷你该怎么办

答：若遇到开发人员说提交BUG不是缺陷则跟项目组的需求人员，设计人员以及该功能的开发人员共同讨论做确认

.软件测试分哪两种方法？分别适合什么情况？

2.一套完整的测试应该由哪些阶段组成？分别阐述一下各个阶段。

3.软件测试的类型有那些？分别比较这些不同的测试类型的区别与联系。

4.测试用例通常包括那些内容？着重阐述编制测试用例的具体做法

5.在分别测试winform的C/S结构与测试WEB结构的软件是，应该采取什么样的方法分别测试？他们存在什么样的区别与联系？

6.在测试winform的C/S结构软件时，发现这个软件的运行速度很慢，您会认为是什么原因？您会采取哪些方法去检查这个原因？

7.描述使用bugzilla缺陷管理工具对软件缺陷（BUG）跟踪的管理的流程8.如果您是测试组长，您会采取什么样的方式管理团队？在测试人员同开发人员的沟通过程中，如何提高沟通的效率和改善沟通的效果？维持测试人员同开发团队中其他成员良好的人际关系的关键是什么？

问题解答：

1.软件测试分哪两种方法？分别适合什么情况？

软件测试方法一般分为两种：白盒测试与黑盒测试。白盒测试又称为结构测试、逻辑驱动测试或基于程序本身的测试，它着重于程序的内部结构及算法，通常不关心功能与性能指标；黑盒测试又被称为功能测试、数据驱动测试或基于规格说明的测试，它实际上是站在最终用户的立场，检验输入输出信息及系统性能指标是否符合规格说明书中有关功能需求及性能需求的规定。

2.一套完整的测试应该由哪些阶段组成？分别阐述一下各个阶段。

计划阶段、设计阶段、白盒单元、白盒集成、黑盒单元、黑盒集成、系统测试、回归测试、验收测试一套完整的测试应该由五个阶段组成：1）。测试计划首先，根据用户需求报告中关于功能要求和性能指标的规格说明书，定义相应的测试需求报告，即制订黑盒测试的最高标准。以后所有的测试工作都将围绕着测试需求来进行，符合测试需求的应用程序即是合格的，反之即是不合格的；同时，还要适当选择测试内容，合理安排测试人员、测试时间及测试资源等。

2）测试设计将测试计划阶段制订的测试需求分解、细化为若干个可执行的测试过程，并为每个测试过

程选择适当的测试用例（测试用例选择的好坏将直接影响测试结果的有效性）。

3）测试开发建立可重复使用的自动测试过程。

4）测试执行执行测试开发阶段建立的自动测试过程，并对所发现的缺陷进行跟踪管理，测试执行一般由单元测试、组合测试、集成测试、系统联调及回归测试等步骤组成，测试人员应本着科学负责的态度，一步一个脚印地进行测试。

5）测试评估结合量化的测试覆盖域及缺陷跟踪报告，对于应用软件的质量和开发团队的工作进度及工作效率进行综合评价。

3.软件测试的类型有那些？分别比较这些不同的测试类型的区别与联系。

BVT （Build Verification Test），主要目的是验证最新生成的软件版本在功能上是否完整，主要的软件特性是否正确Scenario Tests（基于用户实际应用场景的测试），Scenario Tests优点是关注了用户的需求，缺点是有时候难以真正模仿用户真实的使用情况Smoke Test，修复Bug后，针对此次修复是否会对其他模块造成影响而进行的专门测试。Smoke Test优点是节省测试时间，防止build失败。缺点是覆盖率还是比较低此外，还有Application Compatibility Test（兼容性测试），主要目的是为了兼容第三方软件，确保第三方软件能正常运行，用户不受影响。Accessibility Test（软件适用性测试），是确保软件对于某些有残疾的人士也能正常的使用，但优先级比较低。其它的测试还有Functional Test（功能测试）、Security Test（安全性测试）、Stress Test（压力测试）、Performance Test（性能测试）、Regression Test（回归测试）、Setup/Upgrade Test（安装升级测试）等

4. 测试用例通常包括那些内容？着重阐述编制测试用例的具体做法不同结构的用例包括的不一样。（版本、编号、项目、设计人员、设计日期、输入、预期输出……）

软件测试用例的基本要素包括测试用例编号、测试标题、重要级别、测试输入、操作步骤、预期结果。

用例编号：测试用例的编号有一定的规则，比如系统测试用例的编号这样定义规则：

PROJECT1-ST-001 ，命名规则是项目名称＋测试阶段类型（系统测试阶段）＋编号。定义测试用例编号，便于查找测试用例，便于测试用例的跟踪。

测试标题：对测试用例的描述，测试用例标题应该清楚表达测试用例的用途。比如“ 测试用户登录时输入错误密码时，软件的响应情况” .重要级别：定义测试用例的优先级别，可以笼统的分为

“ 高” 和“ 低” 两个级别。一般来说，如果软件需求的优先级为“ 高” ，那么针对该需求的测试用例优先级也为“ 高” ；反之亦然，测试输入：提供测试执行中的各种输入条件。根据需求中的输入条件，确定测试用例的输入。测试用例的输入对软件需求当中的输入有很大的依赖性，如果软件需求中没有很好的定义需求的输入，那么测试用例设计中会遇到很大的障碍。

操作步骤：提供测试执行过程的步骤。对于复杂的测试用例，测试用例的输入需要分为几个步骤完成，这部分内容在操作步骤中详细列出。

预期结果：提供测试执行的预期结果，预期结果应该根据软件需求中的输出得出。如果在实际测试过程中，得到的实际测试结果与预期结果不符，那么测试不通过；反之则测试通过。

7.描述使用bugzilla缺陷管理工具对软件缺陷（BUG）跟踪的管理的流程1、测试人员或开发人员发现bug 后，判断属于哪个模块的问题，填写bug报告后，系统会自动通过Email通知项目组长或直接通知开发者。1）经验证无误后，修改状态为VERIFIED.待整个产品发布后，修改为CLOSED. 2）还有问题，REOPENED，状态重新变为“New"，并发邮件通知。

2）项目组长根据具体情况，重新reassigned分配给bug所属的开发者。

3）若是，进行处理，resolved并给出解决方法。（可创建补丁附件及补充说明） 4）开发者收到Email信息后，判断是否为自己的修改范围。

5）若不是，重新reassigned分配给项目组长或应该分配的开发者。

6）测试人员查询开发者已修改的bug，进行重新测试。（