软件测试面试题

面试题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)在对应用软件进行自动测试时，要把注意力集中在看来不大会改变的部分。

12)对变更进行适当的风险分析，以减少回归测试的要求。

13)在设计测试案例时要有一定的灵活性。

做到这一点并不容易，所以要降低测试案例的详细程度，或者只建立高级的通用型的测试计划。

14)少注意详细的测试计划和测试案例，要把重点放在专门的测试(ad hoc testing) 上。

5. 集成测试通常都有那些策略？1、在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失；2、各个子功能组合起来，能否达到预期要求的父功能；3、一个模块的功能是否会对另一个模块的功能产生不利的影响；4、全局数据结构是否有问题；5、单个模块的误差积累起来，是否会放大，从而达到不可接受的程度。

6. 一个缺陷测试报告的组成测试软件项目名称,每个要测试软件项目都有唯一的名称，有的公司对项目还有特定的编号。

测试软件版本号,测试周期内，一般需要测试多个软件版本，报告错误时，一定要正确填写产生错误的软件版本号。

测试者名称,便于分清责任，便于管理。

测试日期与时间,便于分析和统计错误报告信息。

测试软件环境,包括操作系统和其他必要的软件程序。

测试硬件环境,包括测试计算机和其他测试设备的配置信息。

错误描述,简明的描述错误的特征，便于查询和快速浏览。

错误标识编号(ID#) ,每个错误都有一个唯一的标识编号，方便查询。

错误类型,根据错误类型，分配给适当的人员处理错误。

错误级别,错误的严重程度和处理的优先级，优先处理高级别的错误。

错误状态,错误状态表明错误是否已经处理和将怎样处理，根据错误状态，采用适当的处理方法。

错误处理者名称,便于分清责任，便于管理。

重现错误的操作步骤,便于重现错误，修复错误和验证错误。

期望的结果,描述满足设计要求的结果。

实际测试结果,描述实际测试后得到的结果。

必要的附图,便于确认错误的表现形式和错误位置。

测试者的建议等注释,便于错误处理者快速和正确处理错误7. 基于WEB信息管理系统测试时应考虑的因素有哪些？一、功能测试1、链接测试2、表单测试3、Cookies测试4、设计语言测试5、数据库测试二、性能测试1、连接速度测试2、负载测试3、压力测试三、可用性测试1、导航测试2、图形测试3、内容测试4、整体界面测试四、客户端兼容性测试1、平台测试2、浏览器测试五、安全性测试8. 需求测试注意事项有哪些？一个良好的需求应当具有一下特点：完整性：每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息。

正确性：每一项需求都必须准确地陈述其要开发的功能。

一致性：一致性是指与其它软件需求或高层（系统，业务）需求不相矛盾。

可行性：每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。

无二义性：对所有需求说明的读者都只能有一个明确统一的解释，由于自然语言极易导致二义性，所以尽量把每项需求用简洁明了的用户性的语言表达出来。

健壮性：需求的说明中是否对可能出现的异常进行了分析，并且对这些异常进行了容错处理。

必要性：“必要性”可以理解为每项需求都是用来授权你编写文档的“根源”。

要使每项需求都能回溯至某项客户的输入，如Use Case或别的来源。

可测试性：每项需求都能通过设计测试用例或其它的验证方法来进行测试。

可修改性：每项需求只应在S R S 中出现一次。

这样更改时易于保持一致性。

另外，使用目录表、索引和相互参照列表方法将使软件需求规格说明书更容易修改。

可跟踪性：应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接链，这种可跟踪性要求每项需求以一种结构化的，粒度好（f i n e - g r a i n e d ）的方式编写并单独标明，而不是大段大段的叙述。

9.简述一下缺陷的生命周期软件缺陷的生命周期指的是一个软件缺陷被发现、报告到这个缺陷被修复、验证直至最后关闭的完整过程。

简单的软件缺陷生命周期：1、发现——打开：测试人员找到软件缺陷并将软件缺陷提交给开发人员；2、打开——修复：开发人员再现、修复缺陷，然后提交测试人员去验证；3、修复——关闭：测试人员验证修复过的软件，关闭已不存在的缺陷。

但是这是一种理想的状态，在实际的工作中是很难有这样的顺利的，需要考虑的各种情况都还是非常多的。

复杂的软件缺陷生命周期：1、新建一个软件缺陷，这个软件缺陷是（open）状态，进行bug审查，不是代码问题，就是设计需要修改；2、新建一个软件缺陷，这个软件缺陷是（open）状态，进行bug审查，以后修改的，就可以延期；3、新建一个软件缺陷，这个软件缺陷是（open）状态，进行bug审查，实际没有这个bug，可以将其关闭；4、新建一个软件缺陷，这个软件缺陷是（open）状态，看是否清楚可重现，如果不能重现，就是缺少信息，需要返回到（open）状态；如果能够重现，就进行修正，修正后关闭，进行回归测试。

10.驱动模块:驱动模块在大多数场合称为"主程序"，它接收测试数据并将这些数据传递到被测试模块.单元测试一个函数单元时，被测单元本身是不能独立运行的，需要为其传送数据，为此写驱动驱动模块主要完成以下事情：1、接受测试输入；2、对输入进行判断；3、将输入传给被测单元，驱动被测单元执行；4、接受被测单元执行结果，并对结果进行判断；5、将判断结果作为用例执行结果输出测试报告。

桩模块比如对函数A做单元测试时，被测的函数单元下还包括了一个函数B，为了更好的错误，定位错误，就要为函数B写桩，来模拟函数B的功能，保证其正确。

11.单元测试、集成测试、系统测试的侧重点是什么？单元测试是在软件开发过程中要进行的最低级别的测试活动，在单元测试活动中，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试，测试重点是系统的模块，包括子程序的正确性验证等。

集成测试，也叫组装测试或联合测试。

在单元测试的基础上，将所有模块按照设计要求，组装成为子系统或系统，进行集成测试。

实践表明，一些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作。