梦见很大的老鼠好不好:软件测试常见面试题目

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) 对于该项目的用途而言，哪种功能最重要?j

2) 哪种功能对用户最明显?

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.单元测试、集成测试、系统测试的侧重点是什么？

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

集成测试，也叫组装测试或联合测试。在单元测试的基础上，将所有模块按照设计要求，组装成为子系统或系统，进行集成测试。实践表明，一些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作。程序在某些局部反映不出来的问题，在全局上很可能暴露出来，影响功能的实现。测试重点是模块间的衔接(combinationbetween modules)以及参数的传递(parameter passing)等。

系统测试是将经过测试的子系统装配成一个完整系统来测试。它是检验系统是否确实能提供系统方案说明书中指定功能的有效方法。测试重点是整个系统的运行以及与其他软件的兼容性。

12 设计用例的方法、依据有那些？  

白盒测试用例设计有如下方法:基本路径测试\等价类划分\边界值分析\覆盖测试\循环测试\数据流测试\程序插桩测试\变异测试.这时候依据就是详细设计说明书及其代码结构

黑盒测试用例设计方法:基于用户需求的测试\功能图分析方法\等价类划分方法\边界值分析方法\错误推测方法\因果图方法\判定表驱动分析方法\正交实验设计方法.依据是用户需求规格说明书,详细设计说明书。

13.软件的缺陷等级应如何划分？

   1．致命错误，可能导致本模块以及其他相关模块异常，死机等问题；
   2．严重错误，问题局限在本模块，导致模块功能失效或异常退出
   3．一般错误，模块功能部分失效；
   4．建议问题，由问题提出人对测试对象的改进意见；

测试退出标准

    测试退出标准为完成测试需求中列出的所有功能及测试过程中发现缺陷的回归测试。

    1. 单元测试退出标准

    1) 单元测试用例设计已经通过评审 
    2) 核心代码100％ 经过Code Review 
    3) 单元测试功能覆盖率达到100％ 
    4) 单元测试代码行覆盖率不低于80％ 
    5) 所有发现缺陷至少60％都纳入缺陷追踪系统且各级缺陷修复率达到标准
    6) 不存在A、B类缺陷 
    7) C、D、E类缺陷允许存在 
    8) 按照单元测试用例完成了所有规定单元的测试 
    9) 软件单元功能与设计一致

    2. 集成测试退出标准

    1) 集成测试用例设计已经通过评审 
    2) 所有源代码和可执行代码已经建立受控基线，纳入配置管理受控库，不经过审批不能随意更改 
    3) 按照集成构件计划及增量集成策略完成了整个系统的集成测试 
    4) 达到了测试计划中关于集成测试所规定的覆盖率的要求 
    5) 集成工作版本满足设计定义的各项功能、性能要求 
    6) 在集成测试中发现的错误已经得到修改，各级缺陷修复率达到标准 
    7) A、B类BUG不能存在 
    8) C、D类BUG允许存在,但不能超过单元测试总BUG的50％ 
    9) E类BUG允许存在

    3. 系统测试退出标准

    1) 系统测试用例设计已经通过评审 
    2) 按照系统测试计划完成了系统测试 
    3) 系统测试的功能覆盖率达100％ 
    4) 系统的功能和性能满足产品需求规格说明书的要求 
    5) 在系统测试中发现的错误已经得到修改并且各级缺陷修复率达到标准 
    6) 系统测试后不存在A、B、C类缺陷 
    7) D类缺陷允许存在，不超过总缺陷的5％ 
    8) E类缺陷允许存在，不超过总缺陷的10％

   1. 要更好的管理缺陷，必须引入缺陷管理工具，商用的或者开源的都可。
   2. 根据缺陷的生命周期，考虑缺陷提交的管理、缺陷状态的管理和缺陷分析的管理。
   3. 所有发现的缺陷（不管是测试发现的还是走读代码发现的）都必须全部即时的、准确的提交 到缺陷管理工具中，这是缺陷提交的管理。
   4. 缺陷提交后，需要即时的指派给相应的开发人员，提交缺陷的人需要密切注意缺陷的状态， 帮助缺 陷的尽快解决。缺陷解决后需要即时对缺陷的修复进行验证。这样的目的有两个：一个是让缺陷尽快解决；二是方便后面缺陷的分析（保证缺陷相关的信息准确，如龄期等），这是缺陷状态的管理。
   5. 为了更好的改进开发过程和测试过程，需要对缺陷进行分析，总结如缺陷的类别、缺陷的龄期分布等信息，这是缺陷分析的管理。