软件测试基本理论知识试题汇总
一、判断题
1．软件测试的目的是尽可能多的找出软件的缺陷。( )
2．Beta测试是验收测试的一种。( )
3．验收测试是由最终用户来实施的。( )
4．项目立项前测试人员不需要提交任何工件。( )
5．单元测试能发现约80%的软件缺陷。( )
6．代码评审是检查源代码是否达到模块设计的要求。( )
7．自底向上集成需要测试员编写驱动程序。( )
8．负载测试是验证要检验的系统的能力最高能达到什么程度。( )
9．测试人员要坚持原则，缺陷未修复完坚决不予通过。( )
10．代码评审员一般由测试员担任。( )
11．我们可以人为的使得软件不存在配置问题。( )
12．集成测试计划在需求分析阶段末提交。( )
13、好的测试员不懈追求完美。( )
14、测试程序仅仅按预期方式运行就行了。( )
15、不存在质量很高但可靠性很差的产品。( )
16、软件测试员可以对产品说明书进行白盒测试。()
17、静态白盒测试可以找出遗漏之处和问题。( )
18、总是首先设计白盒测试用例。( )
19、可以发布具有配置缺陷的软件产品。()
20、所有软件必须进行某种程度的兼容性测试。()
21、所有软件都有一个用户界面，因此必须测试易用性。( )
22、测试组负责软件质量。( )
参考答案
1、Y
软件测试的目的就是为了发现软件中的缺陷，从这个意义上面说上面的这个论断是正确的。不少人会认为软件测试可以保证软件的质量，其实这个观点是错误，测试只是软件质量控制中的一个角色，其活动并不能达成软件质量保证的效果。所以不要认为一个公司里面如果有了软件测试人员，产品的质量就会好起来。
2、Y
Beat测试和验收测试是两种不同的测试。验收测试的目的是为了以发现”未实现的需求”为目的，以评估”适合使用”为目标，该类测试的不是以发现缺陷为主要目的。beta测试是一模拟真实的使用环境从而发现缺陷的一种测试。所以两者之间的是非包容关系。
3、N
上面说到了验收测试的目的和目标，所以验收测试也可是是软件生产的企业内部人员来实施。例如产品经理。当软件以项目的形式出现，那么验收测试由最终用户来实施的情况是比较长见的。但是对于产品形式的软件，生产企业内部的验收测试会更多。
4．N
应该说这道题目没有明确的答案，在项目立项前测试人员是不是要把一些准备工作以工件的形式给记录下来是完全取决于该企业的软件开发过程的要求。同时不同企业，立项前要达成的一些必要条件也是大相径庭的。应该说这一题目出的不是很好，如果你是出题人这家企业的测试工程师，那么就应该有一个明确的答案。
5． N
同样这一题目也没有标准答案。因为该数据的来源和其统计的方法，样本都没有一个工业标准。这样出来的数据同样不具有权威性。这里我可以说一个简单的例子，在用ASP,php这类脚本语言开发网页的时候是根本没有复杂的单元测试。那么这样的数字应用在网站开发上面是否有意义，还是值得商榷的。所以这道题目出的不好，没有明确的答案
6．N
代码审查是一种静态技术，从这个意义上说代码复查是需要和其他的一些动态测试技术配合才能检查代码是否符合设计的要求
7． Y
这道题目大家看下top-down 和down-top的集成测试示意图就能得出明确的答案。这里需要了解的是什么是驱动测试程序，什么是桩程序。如果集成组件数量众多，多关系层次，那么不论是什么类型的集成测试。驱动程序和桩程序都是需要开发的。
8． N
关于负载测试和压力测试在论坛中的帖子中有详细的解释，大家可以去看一下就能得出正确的答案
9． N
同样，这一题没有正确的答案。缺陷是否修复是需要听取测试人员的意见，但测试人员的意见非决定性。所以还是要看一个企业赋予测试人员有多大的权力。
10． N
如果测试员有这个水平，那么当然是可以参加的。不过大多数的企业不会让普通的测试人员参与代码的评审。
11． N
首先大家先搞清楚什么是配置管理什么是软件配置，从这道题目中看不出出题人想问的是关键工程中的配置管理还是单纯的软件配置。但是可以肯定的是不论是何种情况，答案均是否定的。
12． N
集成测试计划在开发人员完成软件集成计划之后就可以开始进行了。所以在需求分析阶段之后提交是不现实的事情，应该在软件的设计阶段后，编码前。
13、 N 14、 N
15、 N
软件可靠性是软件系统在规定的时间内及规定的环境条件下，完成规定功能的能力
软件质量就是“软件与明确地和隐含地定义的需求相一致的程度”。具体地说，软件质量是软件符合明确叙述的功能和性能需求、文档中明确描述的开发标准、以及所有专业开发的软件都应具有的隐含特征的程度。
16、 N 17、Y 18、 N 19、 Y 20、 Y 21、 Y
22、 N
软件测试是保障软件质量的手段之一，但不是唯一手段，软件测试是软件产品质量高的必要非充分条件。
二、不定项选择题
1．软件验收测试的合格通过准则是：( )
A． 软件需求分析说明书中定义的所有功能已全部实现，性能指标全部达到要求。
B． 所有测试项没有残余一级、二级和三级错误。
C． 立项审批表、需求分析文档、设计文档和编码实现一致。
D． 验收测试工件齐全。
2．软件测试计划评审会需要哪些人员参加？( )
A．项目经理
B．SQA负责人
C．配置负责人
D．测试组
3．下列关于alpha 测试的描述中正确的是：( )
A．alpha测试需要用户代表参加
B．alpha测试不需要用户代表参加
C．alpha测试是系统测试的一种
D．alpha测试是验收测试的一种
4．测试设计员的职责有：( )
A．制定测试计划
B．设计测试用例
C．设计测试过程、脚本
D．评估测试活动
5．软件实施活动的进入准则是：( )
A．需求工件已经被基线化
B．详细设计工件已经被基线化
C．构架工件已经被基线化
D．项目阶段成果已经被基线化
6.下面哪些属于动态分析( )
A． 代码覆盖率
B． 模块功能检查
C． 系统压力测试
D． 程序数据流分析
7.下面哪些属于静态分析()
A、 代码规则检查
B、 序结构分析
C、 序复杂度分析
D、 内存泄漏
8． 从测试技术角度，正确的选择是( )，给出各自的含义？
A、 静态测试
B、 黑盒测试
C、 动态测试
D、 白盒测试
9． 从测试阶段角度，测试正确的顺序是( )，同时给出所选择的正确策略含义和被测对象是什么？
A、 单元测试
B、 集成测试
C、 系统测试
D、 确认测试
10、 下面角色不属于集成计划评审的是( )
A、 配置经理
B、 项目经理
C、 测试员
D、 编码员
11、软件测试设计活动主要有( )
A、 工作量分析
B、 确定并说明测试用例
C、 确立并结构化测试过程
D、 复审并评估测试覆盖
12、不属于集成测试步骤的是( )
A、 制定集成计划
B、 执行集成测试
C、 记录集成测试结果
D、 回归测试
13、属于软件测试活动的输入工件的是( )
A、 软件工作版本
B、 可测试性报告
C、 软件需求工件
D、 软件项目计划
参考答案
1、ABCD
回答这道题，你必须是这家企业的员工。前面说到了验收测试的目的和目标，一个是需求必须实现，二是证明软件是适合使用的。这样能满足这两个通用标准就可以了。当然有些软件企业会对验收测试标准做一些调整。
2、ABCD
上面的4种角色都需要参与
3、AD
首先大家需要知道alpha测试是系统级别的测试，该测试是在一个受控的环境中进行的。用户需要直接参与进来。所以答案应该是AD
4、BC
合理的答案的是BC，同时要看软件企业对该类人员的职责是如何定义。
5、ABC
先要了解一下什么是基线。这个是软件配置管理中一个重要的概念。工作产品必须纳入到一定的基线里面。所以选择ABC是必定的，至于是否选择D要看这家企业自身的标准了。
6、BC 7、 ABC 8、CD 9、ABCD 10、A 11、ABCD 12、D 13、C
三、填空题
1、 软件实施活动的输出工件有___ 、___、___ 、___ 。
2、 代码评审主要做______工作。
3、 软件实施活动中集成员的职责是___。
4、 验证与确认软件实施活动主要有___、代码评审___、___ 、___ 、___、SQA 验证。
5、__________表明测试已经结束。
6、 软件测试的目的是 _________。
7、 软件测试主要分为_________、_________、_________、_________四类测试。
8、 软件测试活动有_________、_________、_________、_________、_________、_________、_________、_________八个步骤。
9、 软件测试活动的输出工件有_________、_________、_________、_________、_________。
10、软件测试角色有_________、_________、_________、_________。
11．软件验收测试包括_________、_________、_________三种类型。
12．系统测试的策略有_________、_________、_________、_________、_________、_________、_________、_________、_________、_________、_________、_________、_________、_________、_________等15 种方法。
13．设计系统测试计划需要参考的项目文档有_________、_________、和_________。
14．对面向过程的系统采用的集成策略有_________,_________两种。
15．通过画因果图来写测试用例的步骤为①②③④⑤及把因果图转换为状态图共五个步骤。
参考答案
1、 无
2、关于代码和详细设计相一致、在编码阶段没有引入新的错误等方面的保证
3、无
4、验证与确认软件实施活动主要有需求规格说明验证、软件测试团队组织管理、设计规格说明验证、代码验证、软件测试计划管理、交付验证、SQA 验证。
5、测试需求中列出的所有功能及测试过程中发现缺陷的回归测试均已完成表明测试已经结束。
6、 软件测试的目的是 尽可能多的找出软件的缺陷。
7、 软件测试主要分为单元测试、集成测试、系统测试、验收测试四类测试。
8、 软件测试活动有制定测试计划、方案、设计和生成测试用例 、准备测试数据 、执行测试管理缺陷 、生成测试报告 、测试评估、测试结束八个步骤。
9、 软件测试活动的输出工件有测试计划、测试方案、测试用例、测试报告 、缺陷报告 。
测试计划---输出《测试计划》
测试设计---输出《测试方案》
测试实现---输出《测试用例》、《测试规程》、测试脚本
测试执行---输出《测试报告》《测试日志》《缺陷报告》
那实施活动的输出工件是不是有需求规格说明书、用户手册、开发总结、测试总结呢？？？
10、软件测试角色有测试管理人员、测试方案工程师 、测试工程师 、测试员。
11、软件验收测试包括正式验收测试、alpha测试、beta测试三种测试。
12．系统测试的策略有功能测试、性能测试、文档测试、配置测试、安装和卸载的测试、用户界面测试、可用性测试、兼容性测试、易用性测试、安全测试、压力测试、负载测试、回归测试、比较测试、故障恢复测试等15 种方法。
13．设计系统测试计划需要参考的项目文档有软件测试计划、软件需求工件、和迭代计划。
14．对面向过程的系统采用的集成策略有自顶向下,自底向上两种。
15．通过画因果图来写测试用例的步骤为①②③④⑤及把因果图转换为状态图共五个步骤。
①分析软件规格说明描述中的原因和结果，并为每个原因和结果赋予一个标识符。
②根据因果关系画因果图
③在因果图上用一些记号标明约束或限制条件
④把因果图转换成判定表
⑤根据判定表设计测试用例
利用因果图生成测试用例的基本步骤是：
§ 分析软件规格说明描述中，哪些是原因（即输入条件或输入条件的等价类），哪些是结果（即输出条件），并给每个原因和结果赋予一个标识符。
§ 分析软件规格说明描述中的语义，找出原因与结果之间，原因与原因之间对应的是什么关系? 根据这些关系，画出因果图。
§ 由于语法或环境限制，有些原因与原因之间，原因与结果之间的组合情况不可能出现。为表明这些特殊情况，在因果图上用一些记号标明约束或限制条件。
§ 把因果图转换成判定表。
§ 把判定表的每一列拿出来作为依据，设计测试用例
四、名词解释
软件工程、黑盒测试、白盒测试、单元测试、集成测试、系统测试、验收测试、α测试、β测试、 驱动模块、桩模块、静态测试、回归测试、动态测试、等价划分法、边界值分析法
软件工程：
概括的说，软件工程是指导计算机软件开发和维护的工程学科。采用工程的概念、原理、技术和方法来开发与维护软件，把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来，以经济地开发出高质量的软件并有效的维护它，这就是软件工程。
软件测试：
标准定义：使用人工或自动手段，来运行或测试某个系统的过程。其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。最终目的是令客户满意。
针对测试人员的定义：以发现错误为目的，努力发现产品中每个可以想象到的故障或弱点的过程。
综合定义：软件测试是贯穿整个软件开发生命周期、对软件产品（包括阶段性产品）进行验证和确认的活动过程， 其目的是尽快尽早地发现在软件产品中所存在的各种问题——与用户需求、预先定义的不一致性。
黑盒测试（black-boxtesting）：
①在知道产品应该具有的功能的条件下，检验每个功能是否都能正常使用的测试方法。
②又称功能测试，指的是把被测的软件看作是一个黑盒子，完全不考虑程序的内部结构和处理过程，只检查程序功能是否能按照规格说明书的规定正常使用，程序是否能适当地接受输入数据产生正确的输出信息，并且保持外部信息的完整性。黑盒测试是在程序接口进行的测试。
白盒测试（white-boxtesting）：
①在知道产产品内部工作过程的条件下，检验产品内部动作是否按照规格说明书的规定正常进行的测试方法。
②又称结构测试，指的是把程序看成装载一个透明的白盒子里面，也就是完全了解程序的结构和处理过程。按照程序内部的逻辑测试程序，检验程序中的每条通路是否都能按预定要求正确工作。
单元测试（unit-testing）：
指对软件中的最小可测试单元进行检查和验证。
集成测试（integrationtesting）：
指将通过测试的单元模块组装成系统或子系统，再进行测试，重点测试不同模块的接口部分。
系统测试（system-testing）：
指的是将整个软件系统看作一个整体进行测试，包括对功能、性能，以及软件所运行的软硬件环境进行测试。
验收测试（acceptancetesting）：
又称确认测试，指的是在系统测试的后期，以用户测试为主，或有测试人员等质量保障人员共同参与的测试。它的目标是验证软件的有效性。
α（Alpha）测试：
①α测试由用户在开发者的场所进行，并且在开发者对用户的“指导”下进行的测试。开发者负责记录错误和使用中遇到的问题。
②α测试指的是由用户、测试人员、开发人员等共同参与的内部测试。
β(Beta)测试：
①β测试由软件的最终用户在一个或多个客户场所进行。开发者通常不在现场，因此β测试是软件在开发者不能控制的环境中的“真实”应用。
②β测试指的是内测后的公测，即完全交给最终用户测试。
驱动模块（driver）：
模拟被测模块的上级模块，驱动模块用来接收测试数据，启动被测试模块并输出结果。
桩模块（stub）：
是指模拟被测模块所调用的模块。
静态测试（static testing）：
是指不实际运行被测软件，而只是静态地检查程序代码、界面或文档中可能存在的错误的过程。
动态测试（dynamic testing）：
是指实际运行被测程序，输入相应的测试数据，检查实际输出结果和预期结果是否相符的过程。
所以我们判断一个测试属于静态测试还是动态测试，唯一的标准就是看是否运行程序。
回归测试（regressiontesting）：
是指对软件的新的版本测试时，重复执行上一个版本测试时的用例。
等价划分法（Equivalence Class Testing）：
等价类划分法是一种黑盒测试技术，它不考虑程序的内部结构，只是根据软件的需求说明来对输入的范围进行细分，然后再从分出的每一个区域内选取一个有代表性的测试数据。
边界值分析法（Boundary Value Testing）：
边界值分析方法是对等价类划分方法的补充。长期的测试工作经验告诉我们,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误。
五、简答题
请根据您以往的学习和工作经历，结合您的个人经验回答以下问题。您可以尽可能详细和完整的表达出自己的思想，如果书写空间不够，您可以将答案写在题目所在页的背面。如果需要稿纸请同接待人员联系。
1、试述软件的概念和特点？软件复用的含义？构件包括哪些？
软件的概念：
软件是程序、数据结构和相关文档的集合，用于实现所需要的逻辑方法、过程或控制。软件是把知识与技术紧密结合的智力成果，是在研制、开发中被创造出来的一种信息产品。
软件的特点：
①抽象性
软件是一种逻辑实体，而不是具体的物理实体，因而它具有抽象性。
②不会磨损
在软件的运行和使用期间，没有硬件那样的机械磨损、老化问题，但软件维护比硬件维护要负责的多。
③软件开发工作最大、开发效率低、成本高，但复制容易、成本极低。
④对计算机系统的依赖性
⑤软件具有无形性，可以多次使用，但商业寿命较短。
软件复用(SoftWare Reuse)：
软件复用是将已有软件的各种有关知识用于建立新的软件,以缩减软件开发和维护的花费，提高软件生产力和质量的一种重要技术。
构件：
构件是系统中实际存在的可更换部分，它实现特定的功能，符合一套接口标准并实现一组接口。构件代表系统中的一部分物理实施，包括软件代码（源代码、二进制代码或可执行代码）或其等价物（如脚本或命令文件）。
2、瀑布模型和螺旋模型的主要区别是什么？
（1）瀑布模型强调的保证软件的质量,忽略人力,时间,资源等成本因素,以质量为第一目标,每次需求发生变更都要从头再来，适合于一些大型稳定的项目。
螺旋模型是一种增量迭代开发的模型,每一次循环都是一次版本的升级，可提高软件的适应能力。比较适合于前期需求不稳定,后期需求新增变更较多的项目。
（2）瀑布模型是基于质量的, 是由文档驱动的。螺旋模型是风险驱动的，更需要经验丰富的风险评估知识和水平。
3、软件开发模型和软件生命周期的概念是什么？两者有何区别?
软件生命周期是软件从提出开发开始到最终灭亡所经历的时期。大体上分为软件定义、软件开发和软件维护三个阶段。
软件开发模型是软件开发全过程、软件开发活动以及它们之间关系的的结构框架。其作用是为软件项目的管理提供里程碑和进度表，为软件开发提供原则和方法。软件开发模型主要有：①以软件需求可完全确定为前提的瀑布模型②在软件开发初期只能提供基本需求所采用的渐进式开发模型。如原型模型、螺旋模型 ③以形式化开发方法为基础的变换模型。
4、净室软件工程的策略是什么？
净室软件工程是一种在软件开发过程中强调建立正确性的需要的方法,通过在第一次正确地书写代码增量并在测试前验证它们的正确性,从而避免依赖于成本很高的错误消除过程。
净室软件工程可用如下三个关键策略来刻画：置于统计过程控制之下的增量开发,基于函数的规范、设计和验证以及统计测试和软件认证。采用这些策略可改进技术生产过程，可以降低软件开发中的风险,以合理的成本开发出高质量的软件。
5、什么是数据的对立性？有几个层次？
数据独立性是指：应用程序和数据库的数据结构之间相互独立，不受影响。分为物理独立性和逻辑独立性两个层次。
（1） 物理数据独立性：如果数据库的内模式要进行修改，即数据库的存储设备和存储方法有所变化，那么模式/内模式映象也要进行相应的修改，使概念模式尽可能保持不变。也就是对内模式的修改尽量不影响概念模式。
（2） 逻辑数据独立性：如果数据库的概念模式要进行修改，如增加记录类型或增加数据项，那么外模式/模式映象也要进行相应的修改，使外模式尽可能保持不变。也就是概念模式的修改尽量不影响外模式和应用程序。
6、网状、层次数据模型与关系数据模型的最大的区别是什么？
网状、层次数据模型与关系数据模型的最大区别在于表示和实现实体之间的联系的方法：网状、层次数据模型是通过指针链，而关系数据模型是使用二维表。
7、dbms读取一条记录时发生哪些事件？
8、什么是软件质量？软件包是什么？
概括地说，软件质量就是“软件与明确地和隐含地定义的需求相一致的程度”。具体地说，软件质量是软件符合明确叙述的功能和性能需求、文档中明确描述的开发标准、以及所有专业开发的软件都应具有的隐含特征的程度。
软件包(SoftWare Package)是指具有特定的功能，用来完成特定任务的一个程序或一组程序。软件包由一个基本配置和若干可选部件构成，既可以是源代码形式，也可以是目标码形式。用户手册和指南等文档是软件包的重要组成部分。
9、软件产品质量特性是什么？
确保软件质量优良程度的内部因素称为软件质量特性。比较权威的软件质量特性划分应推Boehm提出的十二个基本质量特性。分别为：设备无关性、完整性、精度、一致性、设备效率、可访问性、可通讯性、结构性、自说明性、简明性、易读性、可扩充性。
10、什么是软件质量保证？其主要任务是什么？
软件质量保证：为确保软件开发过程和结果符合预期要求而建立的一系列规程，以及依照规程和计划采取的一系列活动及其结果评价。
主要任务： (1)用户要求定义 (2)力争不重复劳动(3)掌握开发新软件的方法 (4)组织外部力量协作 (5)排除无效劳动(6)发挥每个开发者的能力(7)提高软件开发的工程能力(8)提高计划和管理质量
为了提高软件的质量和软件的生产率，软件质量保证的主要任务大致可归结为8点。
(1)用户要求定义：软件质量保证人员必须熟练掌握正确定义用户要求的技术，包括熟练使用和指导他人使用定义软件需求的支持工具。必须十分重视领导全体开发人员收集和积累有关用户业务领域的各种业务的资料和技术技能。
(2)力争不重复劳动：利用已有软件成果是提高软件质量和软件生产率的重要途径。为此，不要只考虑如何开发新软件，而首先应考虑哪些既有软件可以复用，并在开发过程中，随时考虑所生产软件的复用性。
(3)掌握开发新软件的方法：对开发新软件的方法已经过长期的探索和积累，最普遍公认的成功方法就是软件工程学方法。标准化、设计方法论、工具化等都属此列。应当在开发新软件的过程中大力使用和推行软件工程学中所介绍的开发方法和工具。
(4)组织外部力量协作：一个软件自始至终由同一软件开发单位来开发也许是最理想的。但在现实中常常难以做到。因此需要改善对外部协作部门的开发管理。必须明确规定进度管理、质量管理、交接检查、维护体制等各方面的要求，建立跟踪检查的体制。
(5)排除无效劳动：最大的无效劳动是因需求规格说明有误、设计有误而造成的返工。定量记录返工工作量，收集和分析返工劳动花费的数据非常重要。另一种较大的无效劳动是重复劳动，即相似的软件在几个地方同时开发。这多是因软件开发计划不当，或者开发信息不流畅造成的。为此，要建立互相交流、信息往来通畅、具横向交流特征的信息流通网。
(6)发挥每个开发者的能力：软件生产是人的智能生产活动，它依赖于人的能力和开发组织团队的能力。开发者必须有学习各专业业务知识、生产技术和管理技术的能动性。管理者或产品服务者要制定技术培训计划、技术水平标准，以及适用于将来需要的中长期技术培训计划。
(7)提高软件开发的工程能力：要想生产出高质量的软件产品必须有高水平的软件工程能力。即在软件开发环境或软件工具箱的支持下，运用先进的开发技术、工具和管理方法开发软件的能力。
(8)提高计划和管理质量：对于大型软件项目来说，提高工程项目管理能力极其重要。提高管理能力的方法是重视和强化项目开发初期计划阶段的项目计划评价，计划执行过程中及计划完成报告的评价。将评价、评审工作在工程实施之前就列入整个开发工程的工程计划之中。正确地评价开发计划和实施结果，不仅可以提高软件开发项目管理的精确度，还可以积累项目管理经验资料，提高日后进行项目预算的精确度。所以对“计划”的质量管理非常重要。
11、软件质量保证体系是什么？国家标准中与质量保证管理相关的几个标准是什么？他们的编号和全称是什么？
软件质量保证体系
为满足质量要求和实施质量管理，进行全部有计划和有系统的活动所需的组织结构、程序、过程和资源的总称。
GB／T 19001质量体系设计／开发、生产、安装和服务的质量保证模式（idtISO 9001）
GB／T 19002质量体系生产和安装的质量保证模式（idtISO 9002）
GB／T 19003质量体系最终检验和试验的质量保证模式（idtISO 9003）
GB／T 19004质量管理和质量体系要素指南（idt ISO9004）
12、为什么要进行软件测试?软件测试的目的是什么? 为什么进行单元测试？
任何软件在开发过程中都会留下缺陷，带有缺陷的软件产品如果提交出去，可能会给公司带来不可估量的损失，我们必须在客户之前发现尽可能多的问题，从而保障客户满意。
测试阶段的根本目标是尽可能多地发现并排除软件中潜藏的错误，最终把一个高质量的软件系统交给用户使用。
单元测试一般来说非常必要：
（1）现在强调测试的尽早介入。相对而言，单元测试会在开发比较早的阶段就会进行，发现和修改缺陷的成本比较低，效率比较高。
（2）代码级的很多问题，通过相对后期的系统测试是很难发现的，或者发现问题的成本非常大。
13、什么是软件测试？软件测试的目的与原则、策略以及软件测试的意义?
软件测试：使用人工或自动手段，努力发现产品中每个可以想象到的故障或弱点的过程。其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。最终目的是令客户满意。
软件测试原则：
l 应该在测试开始之前的相当长时间，就制定出测试计划。
l 测试应该从小规模开始，并逐步进行“大规模”测试
l 穷举测试是不可能的。
l 所有的测试都应该能追溯到用户需求。
l 应把“尽早和不断地进行软件测试”作为软件开发者的座右铭。实践证明单元测试能够尽早发现问题，减少后期测试的错误量。可以采用Junit和Jtest来辅助进行单元测试。
l 测试用例应由测试输入数据、测试执行步骤和与之对应的预期输出结果三部分组成。
l 应当避免由程序员检查自己的程序。（指后期系统测试阶段，不包括单元测试）
l 测试用例的设计要确保能覆盖所有可能路径。在设计测试用例时，应当包括合理的输入条件和不合理的输入条件。不合理的输入条件是指异常的，临界的，可能引起问题的输入条件。
l 充分注意测试中的群集现象即缺陷的二八定理。经验表明，测试后程序残存的错误数目与该程序中已发现的错误数目或检错率成正比。应该对错误群集的程序段进行重点测试。
l 严格执行测试计划，排除测试的随意性。
测试计划应包括：所测软件的功能，输入和输出，测试内容，各项测试的进度安排，资源要求，测试资料，测试工具，测试用例的选择，测试的控制方法和过程，系统的配置方式，跟踪规则，调试规则，以及回归测试的规定等等以及评价标准。
l 应当对每一个测试结果做全面的检查。
l 妥善保存测试计划，测试用例，出错统计和最终分析报告，为维护提供方便。
l 对于相对复杂的产品或系统来说，没有Bugs是不可能的，我们只能想办法把软件的Bug数控制在可以忍受的范围内。
l 缺陷具有免疫性，测试人员要根据新版本的特点去修改维护测试用例。
l 为了达到最佳的测试效果，应该由独立的第三方来从事测试工作。
软件测试策略：
①数据完整性测试②功能测试③易用性原则（用户界面的测试、优秀UI的7个组成要素、软件中的辅助特性）④性能测试⑤配置测试⑥兼容性测试⑦本地化测试
软件测试策略是为软件工程过程定义的一个软件测试的模板，也就是把特定的测试用例方法放置进去的一系列步骤。 软件测试的策略、方法和技术是多种多样的。对于软件测试技术，可以从不同的角度加以分类：从是否需要执行被测软件的角度，可分为静态测试和动态测试。从测试是否针对系统的内部结构和具体实现算法的角度来看，可分为白盒测试和黑盒测试。
l 静态测试与动态测试
所谓静态测试是指不运行被测程序本身，仅通过分析或检查源程序的文法、结构、过程、接口等来检查程序的正确性。静态测试包括代码检查、静态结构分析、代码质量度量等。它可以由人工进行，也可以借助软件工具自动进行。
动态测试是指通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率和健壮性等性能。动态测试包括：（1）功能确认与接口测试（2）覆盖率分析（3）性能分析（4）内存分析
l 黑盒测试与白盒测试
若测试规划是基于产品的功能，目的是检查程序各个功能是否能够实现，并检查其中的功能错误，则这种测试方法称为黑盒测试(Black-box Testing)方法。黑盒测试又称为功能测试、数据驱动测试和基于规格说明的测试。它是一种从用户观点出发的测试，一般被用来确认软件功能的正确性和可操作性。黑盒测试的方法有a.等价类划分b.因果图法c.边值分析d.决策表法
若测试规划基于产品的内部结构进行测试，检查内部操作是否按规定执行，软件各个部分功能是否得到充分使用，则这种测试方法称为白盒测试(White-box Testing)方法。其主要方法有逻辑驱动、基路测试等，主要用于软件验证。
l 软件测试过程
单元测试针对每个程序的模块，主要测试5个方面的问题：模块接口、局部数据结构、边界条件、独立的路径和错误处理。
集成测试：自顶向下的测试、自底向上的测试、回归测试、烟雾测试
系统测试：恢复测试、安全测试、压力测试、性能测试
确认测试：a测试、b测试
软件调试：蛮力法、回溯法、原因排除法
软件测试的意义：
a.发现软件错误；
b.有效定义和实现软件成分由低层到高层的组装过程；
c.验证软件是否满足任务书和系统定义文档所规定的技术
d.为软件质量模型的建立提供依据。
14、软件测试项目从什么时候开始？为什么？
软件测试应该在需求分析阶段就介入,因为测试的对象不仅仅是程序编码,应该对软件开发过程中产生的所有产品都测试,并且软件缺陷存在放大趋势.缺陷发现的越晚,修复它所花费的成本就越大.
15、需求分析的任务是什么？有什么作用？需求分析的过程和意义？
需求分析的任务：
• 深入描述软件的功能和性能
• 确定软件设计的约束和软件同其它系统元素的接口细节
• 定义软件的其它有效性需求
需求分析的作用：
确定系统必须完成哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求。
需求分析的过程和意义：
(1) 问题识别
n 从系统的角度来理解软件并评审软件范围是否恰当
n 确定对目标系统的综合要求，即软件的需求
n 提出这些需求实现条件，以及需求应达到的标准
(2) 分析与综合
从信息流和信息结构出发，逐步细化所有的软件功能，找出系统各元素之间的联系、接口特性和设计上的约束，分析它们是否满足功能要求，是否合理。剔除其不合理的部分，增加其需要部分。最终综合成系统的解决方案，给出目标系统的详细逻辑模型。
(3) 编制需求分析阶段的文档
n 软件需求说明书
n 数据要求说明书
n 初步的用户手册
n 修改、完善与确定软件开发实施计划
(4)需求分析评审
n 系统定义的目标是否与用户的要求一致;
n 系统需求分析阶段提供的文档资料是否齐全;
n 文档中的所有描述是否完整、清晰、准确反映用户要求;
n 与所有其它系统成分的重要接口是否都已经描述;
n 被开发项目的数据流与数据结构是否足够，确定;
n 所有图表是否清楚，在不补充说明时能否理解;
n 主要功能是否已包括在规定的软件范围之内，是否都已充分说明;
n 设计的约束条件或限制条件是否符合实际;
n 开发的技术风险是什么;
n 是否考虑过软件需求的其它方案;
n 是否考虑过将来可能会提出的软件需求;
n 是否详细制定了检验标准，它们能否对系统定义是否成功进行确认;
需求分析的意义：
软件工程理论认为，在软件生命周期中，需求分析（Requirements Analysis）是最重要的一个阶段。软件需求分析的质量对软件开发的影响是深远的、全局性的，高质量需求对软件开发往往起到事半功倍的效果，所谓“磨刀不误砍柴功”。在后续阶段改正需求分析阶段产生的错误将付出高昂的代价。
16、请画出软件测试活动的流程图。（8 分）
测试需求->测试计划->测试用例设计->执行测试用例->结果分析->缺陷解决->回归测试
17、试叙述对一个软件项目测试的全过程。（10 分）
(1)项目经理通过和客户的交流，完成需求文档，由开发人员和测试人员共同完成需求文档的评审，评审的内容包括：需求描述不清楚的地方和可能有明显冲突或者无法实现的功能的地方。项目经理通过综合开发人员，测试人员以及客户的意见，完成项目计划。然后SQA进入项目，开始进行统计和跟踪
(2)开发人员根据需求文档完成需求分析文档，测试人员进行评审，评审的主要内容包括是否有遗漏或者双方理解不同的地方。测试人员完成测试计划文档，测试计划包括的内容上面有描述。
(3)测试人员根据修改好的需求分析文档开始写测试用例，同时开发人员完成概要设计文档，详细设计文档。此两份文档成为测试人员撰写测试用例的补充材料。
(4)测试用例完成后，测试和开发需要进行评审。
(5)测试人员搭建环境
(6)开发人员提交第一个版本，可能存在未完成功能，需要说明。测试人员进行测试，发现BUG后提交给BugZilla。
(7)开发提交第二个版本，包括Bug Fix以及增加了部分功能，测试人员进行测试。
(8)重复上面的工作，一般是3-4个版本后BUG数量减少，达到出货的要求。
(9)如果有客户反馈的问题，需要测试人员协助重现以及回归测试。
18、软件测试主要分为哪四类测试？
软件测试主要分为单元测试、集成测试、系统测试、验收测试四类测试。
19、软件测试分为几个阶段？各阶段的测试策略和要求是什么？每个阶段都应用什么测试方法？
从测试实际的前后过程来看，软件测试的过程是由一系列的不同测试阶段所组成，这些软件测试的步骤分为：需求分析审查、设计审查、单元测试、集成测试（组装测试）、功能测试、系统测试、验收测试、回归测试（维护）等。
| 阶 段 | 要求 | 测试方法、策略 |
| 需求分析审查 Requirements Review | 需求定义要准确、完整和一致, 真正理解客户的需求 | 黑盒测试 |
| 设计审查 Design Review | 系统结构的合理性、处理过程的正确性、数据库的规范化、模块的独立性等 清楚定义测试计划的策略、范围、资源和风险，测试用例的有效性和完备性 | 黑盒测试 |
| 单元测试 Unit Testing | 遵守规范、模块的高内聚性、功能实现的一致性和正确性 | 白盒测试 |
| 集成测试 Integration Testing | 接口定义清楚且正确、模块或组件一起工作正常、能集成为完整的系统 | 黑盒测试 白盒测试 |
| 功能验证 Functionality Testing | 模块集成 功能的正确性、适用性 |
|
| 系统测试 System Testing | 系统能正常地、有效的运行，包括性能、可靠性、安全性、兼容性等。 | 黑盒测试 |
| 验收测试 Acceptance Testing | 向用户表明系统能够按照预定要求那样工作，使系统最终可以正式发布或向用户提供服务。用户要参与验收测试，包括α测试(内部用户测试)、β测试(外部用户测试) | 黑盒测试 正式验收测试 α测试 β测试 |
| 版本发布 Release | 软件发布包、软件发布检查表（清单） |
|
| 维护 Maintance | 要求：新的或增强的功能正常、原有的功能正常，不能出现回归缺陷 |
|
20、请描述软件测试活动的生命周期。在测试生命周期，测试过程分为几个阶段，以及各个阶段的含义?
基于软件工程学的思想，测试计划、测试设计、测试开发、测试执行、缺陷跟踪、测试评估6个环节共同构成整个软件测试生命周期。在测试生命周期内，软件测试过程按照测试的先后次序可分为4个步骤进行：单元测试、集成测试、确认测试和系统测试，最后进行验收测试。
（1）单元测试：是指对软件中的最小可测试单元进行检查和验证。
（2）集成测试：是单元测试的下一个阶段，是指将通过测试的单元模块组装成系统或子系统，再进行测试，重点测试不同模块的接口部分。
（3）确认测试：完成集成测试以后，要对开发工作初期制定的确认准则进行检验。确认测试是检验所开发的软件能否满足所有功能和性能需求的最后阶段，通常均采用黑盒测试方法。
（4）系统测试：指的是将整个软件系统看做一个整体进行测试，包括对功能、性能，以及软件所运行的软硬件环境进行的测试。
（5）验收测试：指的是在系统测试的后期，以用户测试为主，或有测试人员等质量保障人员共同参与的测试，他也是软件正式交给用户使用的最后一道工序。
21、在软件测试各个阶段的结果文件是什么？包括什么内容？
测试计划——à《测试计划》，测试设计——à《测试用例》
测试执行——à《缺陷报告》，测试评估——à《测试总结报告》
《测试计划》的内容会因不同的项目以及项目的大小而有所不同，一般而言在测试计划中应该清晰描述以下内容：①测试目标②测试概要③测试范围④重点事项⑤质量目标⑥资源需求⑦人员组织⑧测试策略⑨发布提交⑩测试进度和任务人员安排11测试开始/完成/延迟/继续的标准
《测试用例》指的是在测试执行之前设计的一套详细的测试方案，包括测试环境、测试步骤、测试数据和预期结果。
《缺陷报告》主要包括：①缺陷编号 ②缺陷标题③报告者④创建时间⑤所属版本⑥开发的接口人员⑦缺陷重现过程⑧严重程度（致命、严重、一般、提示）⑨优先级⑩缺陷状态11缺陷简单描述12缺陷详细描述（操作环境、操作步骤、使用数据、简单分析等）13修改记录（修改内容、结果及修改人员签字/日期）14缺陷解决方案，解决人&解决日期15确认内容、结果及确认人员签字/日期16遗留问题17测试总结和改进建议18BUG附件（给出相关的日志和截图）19备注
《测试总结报告》内容包括：
u 引言：编写目的、背景、用户群、 参考资料、测试对象、测试阶段、测试工具
u 测试概要
u 测试环境 软硬件配置、 网络拓扑方案
u 测试结果及发现
功能测试 ：版本走势 、模块分布 、严重程度分布、BUG引入阶段分析、BUG状态分布图、BUG修改人分布图
性能测试
u 测试结论：功能、 易用性、 效率、兼容性
u 分析摘要：能力 、遗留缺陷的影响、建议、评价
u 度量：资源消耗、缺陷密度
22、按照瀑布模型软件开发都分哪几个阶段？对应的测试环节又分哪几个阶段？
随着全面质量管理思想在软件开发领域的应用，软件测试也由最初的只针对软件成品扩展到了针对软件半成品与过程产品的全过程测试。按照瀑布模型软件开发都分为软件需求分析、软件概要设计、软件详细设计、编码、集成、验收等各个工程阶段。相应地，各阶段所开展的测试分别为需求测试、架构测试、详细设计测试、单元测试、集成测试以及验收测试等。这样的软件测试涵盖了软件开发的整个工程过程，对于识别与控制软件缺陷、提高软件质量起到了很明显的成效。
23、测试生命周期、测试过程分为几个阶段，以及各阶段的含义？
测试生命周期：测试计划、测试设计、测试开发、测试执行、缺陷跟踪、测试评估
测试计划：由测试经理或测试组长根据《需求规格说明书》或界面原型来编写测试计划，生成《测试计划》文档。
测试设计：在概要设计和详细设计阶段，由测试设计人员根据《需求规格说明书》或是界面原型来进行测试设计，主要包括编写测试用例、设计测试策略等，主要生成《测试用例》文档。
测试开发：开发桩模块和驱动模块，建立可重用的自动测试，维护测试对于测试需求的可跟踪性。
测试执行：在开发编码后期，有测试执行人员参考《需求规格说明书》和《测试用例》来对系统进行测试实施，这里面又包括了单元测试、集成测试、系统测试，主要生成大量的《缺陷报告》。
缺陷跟踪： 或称Bug管理，是产品开发(尤其是软件开发)和维护过程中重要的辅助工具,用于跟踪记录产品的缺陷、需求变更等,作为沟通开发人员与测试人员、客户的沟通的桥梁,保障产品开发流程更加协调。
测试评估：在项目的后期，由测试经理或测试组长评估一下测试的过程和结果，为下一阶段或是下一个项目的测试积累一些经验和教训，一般生成一个《测试总结报告》。
软件测试过程是软件开发的逆过程。按照测试的先后次序可分为4个步骤进行：
单元测试、集成测试、确认测试和系统测试，最后进行验收测试。
（1）单元测试：是指对软件中的最小可测试单元进行检查和验证。
（2）集成测试：是单元测试的下一个阶段，是指将通过测试的单元模块组装成系统或子系统，再进行测试，重点测试不同模块的接口部分。
（3）确认测试：完成集成测试以后，要对开发工作初期制定的确认准则进行检验。确认测试是检验所开发的软件能否满足所有功能和性能需求的最后阶段，通常均采用黑盒测试方法。
（4）系统测试：指的是将整个软件系统看做一个整体进行测试，包括对功能、性能，以及软件所运行的软硬件环境进行的测试。
（5）验收测试：指的是在系统测试的后期，以用户测试为主，或有测试人员等质量保障人员共同参与的测试，他也是软件正式交给用户使用的最后一道工序。
24、软件测试应该划分几个阶段?简述各个阶段应重点测试的点?各个阶段的含义?
软件测试分为单元测试、集成测试、系统测试、验收测试四个阶段，有时需要进行回归测试。
（1）单元测试：是指对软件中的最小可测试单元进行检查和验证，要注重逻辑的覆盖。
（2）集成测试：是单元测试的下一个阶段，是指将通过测试的单元模块组装成系统或子系统，再进行测试，重点测试不同模块的接口部分，主要注重接口的覆盖。
（3）系统测试：指的是将整个软件系统看做一个整体进行测试，包括对功能、性能，以及软件所运行的软硬件环境进行的测试，主要注重需求的覆盖。
（4）验收测试：指的是在系统测试的后期，以用户测试为主，或有测试人员等质量保障人员共同参与的测试，他也是软件正式交给用户使用的最后一道工序。验收测试是对于项目类的软件而说的。相对的，对于产品类的软件，就不要验收测试。就要进行，Alpha测试以及Beta测试。
回归测试，是指对软件的新的版本测试时，重复执行上一个版本测试时的用例。回归测试可以在上述任何测试阶段进行，既有黑盒测试的回归，也有白盒测试的回归。
25、你认为软件测试最关键的是哪个阶段？使用过的测试方法有哪些？
一般来讲，软件测试分为单元测试、集成测试、系统测试、验收测试四个阶段，其中单元测试是软件测试的基础和关键。软件测试效果会直接影响到软件的后期测试，最终在很大程度上影响到产品的质量。从如下几个方面就可以看出单元测试的重要性在何处。
（1）时间方面：如果认真的做好了单元测试，在系统集成联调时非常顺利，因此会节约很多时间，反之那些由于因为时间原因不做单元测试或随便做做的则在集成时总会遇到那些本应该在单元测试就能发现的问题，而这种问题在集成时遇到往往很难让开发人员预料到，最后在苦苦寻觅中才发现这是个很低级的错误而在悔恨自己时已经浪费了很多时间，这种时间上的浪费一点都不值得，正所谓得不偿失。
（2）测试效果：根据以往的测试经验来看，单元测试的效果是非常明显的，首先它是测试阶段的基础，做好了单元测试，在做后期的集成测试和系统测试时就很顺利。其次在单元测试过程中能发现一些很深层次的问题，同时还会发现一些很容易发现而在集成测试和系统测试很难发现的问题。再次单元测试关注的范围也特殊，它不仅仅是证明这些代码做了什么，最重要的是代码是如何做的，是否做了它该做的事情而没有做不该做的事情。
（3）测试成本：在单元测试时某些问题就很容易发现，如果在后期的测试中发现问题所花的成本将成倍数上升。比如在单元测试时发现1个问题需要1个小时，则在集成测试时发现该问题需要2个小时，在系统测试时发现则需要3个小时，同理还有定位问题和解决问题的费用也是成倍数上升的，这就是我们要尽可能早的排除尽可能多的bug来减少后期成本的因素之一。
（4）产品质量：单元测试的好与坏直接影响到产品的质量，可能就是由于代码中的某一个小错误就导致了整个产品的质量降低一个指标，或者导致更严重的后果，如果我们做好了单元测试这种情况是可以完全避免的。
综上所述，单元测试是构筑产品质量的基石，我们不要因为节约单元测试的时间不做单元测试或随便做而让我们在后期浪费太多的不值得的时间，我们也不愿意因为由于节约那些时间导致开发出来的整个产品失败或重来！
测试方法
软件测试的策略、方法和技术是多种多样的。对于软件测试技术，可以从不同的角度加以分类：从是否需要执行被测软件的角度，可分为静态测试和动态测试。从测试是否针对系统的内部结构和具体实现算法的角度来看，可分为白盒测试和黑盒测试。黑盒测试又包括逻辑功能测试、界面测试、易用性测试、安装测试、兼容性测试、稳定性测试、负载测试、压力测试等。
26、产品测试到什么时候就算是足够了?测试结束的标准是什么？
从微观上来说，在测试计划中定义，比如系统在一定性能下平稳运行72小时，目前Bug TrackingSystem中，本版本中没有一般严重的BUG，普通BUG的数量在3以下，BUG修复率90%以上等等参数，然后由开发经理，测试经理，项目经理共同签字认同版本Release。
如果说宏观的，则是当这个软件彻底的消失以后，测试就结束了。
27、什么是测试评估，测试评估的范围是什么？
测试评估：是指对测试过程中的各种测试现象和结果进行记录、分析和评价的活动。在项目的后期，由测试经理或测试组长评估一下测试的过程和结果，为下一阶段或是下一个项目的测试积累一些经验和教训，一般生成一个《测试总结报告》。
评估的范围：测试执行过程中发生的情况、测试执行期间发生并需要进一步调查的一切事件、与测试设计、说明等有关的测试活动。
28、阐述工作版本的定义。
工作版本由一个或多个构件（通常为可执行构件）构成，一般都是通过编译和链接源代码的处理过程从其他构件中构建的，其目在于交付一个运行时功能和系统性能的可测试子集。
工作版本是迭代生命周期不可缺少的组成部分。它们代表正在进行的尝试活动，目的是展示最新开发的功能。由于在新增功能引发破坏作用时需要返回到以前的版本，因此对每一工作版本都需要采取配置控制的措施，否则将影响工作版本的完整性。
工作版本既可以是系统的可操作版本，也可以是具有最终产品部分功能的系统组成部分。
在迭代式软件开发过程中将产生许多工作版本。每一工作版本一经推出，它们都可以用来对产品进行先期检查，帮助发现集成问题。
29、测试计划的目的是什么?
软件测试计划是指导测试过程的纲领性文件。包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。借助软件测试计划，参与测试的项目成员，尤其是测试管理人员，可以明确测试任务和测试方法，保持测试实施过程的顺畅沟通，跟踪和控制测试进度，应对测试过程中的各种变更。
30、什么是测试用例？什么是测试脚本？两者的关系是什么？
测试用例：指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略的文档；内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等。
测试脚本：测试脚本是自动执行测试过程（或部分测试过程）的计算机可读指令。
在软件测试过程中，测试脚本通常以文本形式存在，由测试脚本组织用户所施加的一系列软件执行动作，即一个测试脚本可以实现一个或多个测试用例的操作。测试用例的执行过程，也是测试脚本的生成过程。
31、测试用例包括哪些内容？
《测试用例》指的是在测试执行之前设计的一套详细的测试方案，包括测试环境、测试步骤、测试数据和预期结果。
32、写测试计划、测试用例的依据是什么？
编写测试计划的依据：系统分析师或项目经理根据项目计划、项目计划的评估状态以及业务的理解编写《需求规格说明书》，测试经理或测试组长根据《需求规格说明书》或界面原型来编写测试计划，生成《测试计划》文档。
编写测试用例的依据：软件需求即用户对软件的实际操作和业务流程无疑是派生测试用例重要来源，测试人员根据《需求规格说明书》或是界面原型来设计《测试用例》，但许多情形下这还不够，项目风险、有关约束、特定技术、变更请求（发现的缺陷或错误）等都可能是开发测试用例的参考依据。
33、面向对象的测试用例设计有几种方法？如何实现？
面向对象的测试用例设计主要有等价类划分、边界值分析法、错误推测法、因果图方法、路径覆盖、功能图、正交试验设计法、场景设计方法。
u 等价类划分是一种典型的黑盒测试方法。这一方法完全不考虑程序的内部结构，只依据程序的规格说明，把所有可能的输入数据,即程序的输入域划分成若干部分（子集）,然后从每一个子集中选取少数具有代表性的数据作为测试用例。
u 边界值分析方法是对等价类划分方法的补充，也是一种黑盒测试方法，长期的测试工作经验得知，大量的错误是发生在输入或输出的边界上。因此针对各种边界情况设计测试用例，可以查出更多的错误。
u 错误推测法基于经验和直觉列举出程序中所有可能有的错误和容易发生错误的特殊情况，从而有针对性的设计测试用例。
u 利用因果图生成测试用例的基本步骤:
(1) 分析软件规格说明描述中, 那些是原因(即输入条件或输入条件的等价类),那些是结果(即输出条件), 并给每个原因和结果赋予一个标识符。
(2) 分析软件规格说明描述中的语义.找出原因与结果之间, 原因与原因之间对应的关系. 根据这些关系,画出因果图。
(3) 由于语法或环境限制, 有些原因与原因之间,原因与结果之间的组合情况不不可能出现. 为表明这些特殊情况, 在因果图上用一些记号表明约束或限制条件。
(4) 把因果图转换为判定表。
(5) 把判定表的每一列拿出来作为依据,设计测试用例。
u 路径分析法
①将系统运行过程中所涉及到的各种流程图表化，完成所有路径的设定。
②给每条路径设定优先级，根据优先级的排序有针对性的进行测试。
③为每条路径选取测试数据，构造测试用例。
u 功能图
①在每个状态中，从因果图生成局部测试用例。
②生成从初始状态到最后状态的测试路径。
③采用合成构造树合成测试路径与功能图中每个状态的局部测试用例。
u 正交表
①分析变量和变量的取值
②选择一个合适的正交表，并把变量的值映射到表中
③把每一行的各因素水平的组合做为一个测试用例
u 场景设计方法
对于每一个场景，采用矩阵或决策表来确定和管理测试用例，其中各行代表各个测试用例，而各列则代表测试用例的信息。
34、测试用例的设计方法有哪些？
(1)等价类划分
划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类.
(2)边界值分析法
边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.
使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据.
(3)错误推测法
基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法.
错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结. 还有, 输入数据和输出数据为0的情况. 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况. 可选择这些情况下的例子作为测试用例.
(4)因果图方法
前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图（逻辑模型）. 因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况.
(5)正交表分析法
有时候，可能因为大量的参数的组合而引起测试用例数量上的激增，同时，这些测试用例并没有明显的优先级上的差距，而测试人员又无法完成这么多数量的测试，就可以通过正交表来进行缩减一些用例，从而达到尽量少的用例覆盖尽量大的范围的可能性。
(6)场景分析方法
指根据用户场景来模拟用户的操作步骤，这个比较类似因果图，但是可能执行的深度和可行性更好。
35、您认为做好测试用例设计工作的关键是什么？
关键是对系统的熟悉程度，需求的理解，设计文档的了解情况。
白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果
黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。不可能做到完全测试，以最少的用例在合理的时间内发现最多的问题
36、测试用例设计的原则是什么？
u 测试用例的代表性：能够代表并覆盖各种合理的和不合理、合法的和非法的、边界的和越界的、以及极限的输入数据、操作和环境设置等。
u 测试结果的可判定性：即测试执行结果的正确性是可判定的，每一个测试用例都应有相应的期望结果。
u 测试结果的可再现性：即对同样的测试用例，系统的执行结果应当是相同的。
37、测试分析测试用例注意（事项）？==编写测试用例的注意事项
①为什么要写用例：
编写测试用例可以便于团队交流、便于重复测试 、便于跟踪统计和用户自测
②什么时候写用例：
测试用例要尽早编写，通常，我们都会在测试设计阶段来写用例，即《需求规格说明书》和《测试计划》都已完成之后。
③由谁来写测试用例
一般测试用例是由测试设计人员来编写，由测试执行人员来执行，这就要求测试设计人员有一定的用例设计经验，并对被测试的系统有深入的了解。
④根据什么写测试用例
我们编写测试用例的唯一标准就是用户需求，具体的参考资料就是《系统需求规格说明书》和软件原型，其中软件原型指的是没有嵌入全部源代码的软件界面，用户需求也不是一成不变的，而是在一直变化的。这就需要我们根据不断调整变化的用户需求，来修改和维护我们已经写好的测试用例。
38、需求测试注意事项有哪些？
一个良好的需求应当具有一下特点：①完整性②正确性③一致性④可行性⑤无二义性⑥健壮性⑦必要性⑧可测试性⑨可修改性⑩可跟踪性
①完整性：每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息。
②正确性：每一项需求都必须准确地陈述其要开发的功能。
③一致性：一致性是指与其它软件需求或高层（系统，业务）需求不相矛盾。
④可行性：每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。
⑤无二义性：对所有需求说明的读者都只能有一个明确统一的解释，由于自然语言极易导致二义性，所以尽量把每项需求用简洁明了的用户性的语言表达出来。
⑥健壮性：需求的说明中是否对可能出现的异常进行了分析，并且对这些异常进行了容错处理。
⑦必要性：“必要性”可以理解为每项需求都是用来授权你编写文档的“根源”。要使每项需求都能回溯至某项客户的输入，如Use Case或别的来源。
⑧可测试性：每项需求都能通过设计测试用例或其它的验证方法来进行测试。
⑨可修改性：每项需求只应在S R S 中出现一次。这样更改时易于保持一致性。另外，使用目录表、索引和相互参照列表方法将使软件需求规格说明书更容易修改。
⑩可跟踪性：应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接链，这种可跟踪性要求每项需求以一种结构化的、粒度好（f i n e - g r a i n e d ）的方式编写并单独标明，而不是大段大段的叙述。
39、请以您以往的实际工作为例，详细的描述一次测试用例设计的完整的过程。
(1)根据需求文档、概要设计、测试计划、测试方案 细分出各功能模块的测试项
(2)根据测试项，按照概要设计、详细设计以及测试方案中测试的覆盖率细分出测试子项
(3)按照测试子项、根据测试用例的设计方法（因果图、边界值、等价类等的设计方法）书写测试用例
40、比较负载测试、容量测试和强度测试的区别与关系。
区别方面：
负载测试是性能测试的一种，通常是指让被测系统在其能忍受的压力的极限范围之内连续运行，来测试系统的稳定性。
强度测试又称压力测试，是性能测试的一种，通常是指持续不断地给被测系统增加压力，直到将被测系统压垮为止，用来测试系统所能承受的最大压力。
容量测试：容量测试目的是通过测试预先分析出反映软件系统应用特征的某项指标的极限值（如最大并发用户数、数据库记录数等），系统在其极限值状态下没有出现任何软件故障或还能保持主要功能正常运行。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。容量测试的目的是使系统承受超额的数据容量来发现它是否能够正确处理。容量测试是面向数据的，并且它的目的是显示系统可以处理目标内确定的数据容量。
压力测试、容量测试和性能测试的关系：压力测试可以看作是容量测试、性能测试和可靠性测试的一种手段，不是直接的测试目标。压力测试的重点在于发现功能性测试所不易发现的系统方面的缺陷。而容量测试和性能测试是系统测试的主要目标内容，也就是确定软件产品或系统的非功能性方面的质量特征，包括具体的特征值。容量测试和性能测试更着力于提供性能与容量方面的数据，为软件系统部署、维护、质量改进服务，并可以帮助市场定位、销售人员对客户的解释、广告宣传等服务。压力测试、容量测试、性能测试，测试的方法相似、相通，在实际测试工作中，往往结合起来进行，以提高测试效率。
41、单元测试、集成测试、系统测试的侧重点是什么？
单元测试是在软件开发过程中要进行的最低级别的测试活动，在单元测试活动中，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。
集成测试，也叫组装测试或联合测试。在单元测试的基础上，将所有模块按照设计要求，组装成为子系统或系统，进行集成测试。实践表明，一些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作。程序在某些局部反映不出来的问题，在全局上很可能暴露出来，影响功能的实现。
系统测试是将经过测试的子系统装配成一个完整系统来测试。它是检验系统是否确实能提供系统方案说明书中指定功能的有效方法。
42、什么是软件测试静态分析？
静态测试是指不实际运行被测软件，而只是静态地检查程序代码、界面或文档中可能存在的错误的过程。
43、述静态测试和动态测试的区别？
所谓的静态测试，是指不实际运行被测软件，而只是静态地检查程序代码、界面或文档中可能存在的错误的过程。动态测试，是指实际运行被测程序，输入相应的测试数据，检查实际输出结果和预期结果是否相符的过程。所以判断一个测试属于动态测试还是静态测试，唯一的标准就是看是否运行程序。这也是两者的根本区别。
44、简述集成测试的过程。
根据IEEE标准，集成测试划分为4个阶段：计划阶段，设计阶段，实现阶段，执行阶段（实施阶段）
u 计划阶段
1）时间安排 概要设计完成评审后大约一个星期
2）输入 需求规格说明书 概要设计文档 产品开发计划路标
3）入口条件 概要设计文档已经通过评审
4）活动步骤
1.定被测试对象和测试范围 2.评估集成测试被测试对象的数量及难度，即工作量3.确定角色分工和作任务4.标识出测试各阶段的时间，任务，约束等条件5.考虑一定的风险分析及应急计划6.考虑和准备集成测试需要的测试工具，测试仪器，环境等资源7.考虑外部技术支援的力度和深度，以及相关培训安排8.定义测试完成标准
5）输出 集成测试计划
6）出口条件 集成测试计划通过概要设计阶段基线评审
u 设计阶段
1）时间安排 详细设计阶段开始
2）输入 需求规格说明书 概要设计 集成测试计划
3）入口条件 概要设计基线通过评审
4）活动步骤
1.被测对象结构分析 2.集成测试模块分析3.集成测试接口分析4.集成测试策略分析5.集成测试工具分析6.集成测试环境分析7.集成测试工作量估计和安排。
5）输出 集成测试设计（方案）
6）出口条件 集成测试设计通过详细设计基线评审。
u 实现阶段
1）时间安排 在编码阶段开始后进行
2）输入 需求规格说明书 概要设计 集成测试计划集成测试设计
3）入口条件 详细设计阶段
4）活动步骤
集成测试用例设计 集成测试程设计 集成测试代码设计（如果需要） 集成测试脚本（如果需要） 集成测试工具（如果需要）
5）输出 集成测试用例 集成测试规程 集成测试代码 集成测试脚本 集成测试工具
6）出口条件 测试用例和测试规程通过编码阶段基线评审
u 执行阶段
1）时间安排 单元测试已经完成后就可以开始执行集成测试了
2）输入 需求规格说明书 概要设计 集成测试计划 集成高度设计 集成测试例 集成测试规程 集成测试代码（如果有） 集成测试脚本 集成测试工具 详细设计 代码 单元测试报告
3）入口条件 单元测试阶段已经通过基线化评审
4）活动步骤 执行集成测试用例 回归集成测试用例 撰写集成测试报告
5）输出 集成测试报告
6）出口条件 集成测试报告通过集成测试阶段基线评审
45、单元测试和集成测试,描述工作实际开展的情况
单元测试：制定单元测试计划->设计->实施->执行->评估
①设计员制定单元测试计划②设计员设计单元测试用例，设计驱动程序和桩③编码员负责编写测试驱动程序和稳定性④编码员执行测试并记录测试结果⑤设计员评估此次测试，并生成测试评估摘要
集成测试：制定集成测试计划->设计->实施->执行->评估
①测试设计员负责制定集成测试计划②测试设计员负责设计集成测试用例和测试过程③测试设计员负责编制测试脚本（可选），更新测试过程④设计员负责设计驱动程序和桩，实施员负责实施驱动程序和桩⑤测试员负责执行测试并记录测试结果⑥测试设计员负责会同集成员、编码员、设计员等有关人员（具体化）评估此次测试，并生成测试评估摘要
46、集成测试通常都有那些策略？
1）大爆炸集成2）自顶向下集成3）自底向上集成4）三明治集成5）基干集成6）分层集成7）基于功能的集成8）基于消息的集成9）基于风险的集成10）基于进度的集成11）基于分解的集成策略12）基于调用图的集成13）基于路径的集成14） 高频集成15）基于使用的集成16）客户/服务器的集成17）分布式集成
47、白盒测试有那几种方法？
白盒测试是根据被测程序的内部结构设计测试用例的一种测试方法，具体的白盒测试方法有程序控制流分析、数据流分析、逻辑覆盖、域测试、符号测试、路径分析、程序插装及程序变异等。
48、如果能够执行完美的黑盒测试，还需要进行白盒测试吗？为什么？
如果黑盒测试是足够完美的，那么白盒测试就没有必要，可惜“足够充分”只是一种理想状态，程序的功能点是人为的定义，常常是不全面的；各个输入数据之间，有些组合可能会产生问题，怎样保证这些组合都经过了测试？难于衡量测试的完整性是黑盒测试的主要缺陷，而白盒测试恰恰具有易于衡量测试完整性的优点，两者之间具有极好的互补性，例如：完成功能测试后统计语句覆盖率，如果语句覆盖未完成，很可能是未覆盖的语句所对应的功能点未测试。
49、系统测试计划是否需要同行评审，为什么？
系统测试计划属于项目阶段性关键文档，因此需要根据同行评审规范对测试计划进行同行评审。
50、Alpha 测试与beta 测试的区别。
α测试是由一个用户在开发环境下进行的测试,也可以是公司内部的用户在模拟实际操作环境下进行的测试。α测试的目的是评价软件产品的FLURPS(即功能,局域化,可使用性,可靠性,性能和支持)。尤其注重产品的界面和特色。
β测试是由软件的多个用户在实际使用环境下进行的测试，是在开发者无法控制的环境下进行的软件现场应用。β测试主要衡量产品的FLURPS.着重于产品的支持性,包括文档,客户培训和支持产品生产能力。只有当α测试达到一定的可靠程度时，才能开始β测试。
51、图书（图书号，图书名，作者编号，出版社，出版日期）
作者（作者姓名，作者编号，年龄，性别）
用SQL语句查询年龄小于平均年龄的作者姓名、图书名，出版社。
SELECT 作者.作者姓名，图书.图书名，图书.出版社
FROM 作者，图书
WHERE 作者.年龄<AVG(作者.年龄)AND 图书.作者编号=作者.作者编号
52、lordrunner分哪三部分？
脚本编辑工具，测试执行工具，结果分析工具
53、软件的缺陷等级应如何划分？
按照严重程度由高到低的顺序划分为：
A类—系统崩溃，包括以下各种错误： 1． 由于程序所引起的死机,非法退出 2． 死循环 3． 数据库发生死锁 4． 因错误操作导致的程序中断 5． 功能错误 6． 与数据库连接错误 7． 数据通讯错误
B类—严重，包括以下各种错误： 1． 程序错误 2． 程序接口错误 3． 数据库的表、业务规则、缺省值未加完整性等约束条件
C类—一般，包括以下各种错误： 1． 操作界面错误（包括数据窗口内列名定义、含义是否一致） 2． 打印内容、格式错误 3． 简单的输入限制未放在前台进行控制 4． 删除操作未给出提示 5． 数据库表中有过多的空字段
D类—次要，包括以下各种错误： 1． 界面不规范 2． 辅助说明描述不清楚 3． 输入输出不规范 4． 长操作未给用户提示 5． 提示窗口文字未采用行业术语 6． 可输入区域和只读区域没有明显的区分标志
E类—建议
按照优先级由高到底分为：
高优先级：应该立即修复的错误
中优先级：应该在产品发布之前修复的错误
低优先级：如果时间允许应该修复的错误或是可以暂时存在的错误
54、针对缺陷采取怎样的管理措施?
（1）软件缺陷管理应该和软件过程的各个环节有效地结合起来，对整个项目团队实施持续改进的过程管理。
u 为了更好的管理缺陷，必须引入商用的或开源的缺陷管理工具。
u .根据缺陷的生命周期，考虑缺陷提交的管理、缺陷状态的管理和缺陷分析的管理。
u 所有发现的缺陷（不管是测试发现的还是走读代码发现的）都必须全部即时的、准确的提交到缺陷管理工具中，对每一个软件缺陷按类型，优先级等各种属性进行分类，这是缺陷提交的管理。
u 缺陷提交后，需要即时的指派给相应的开发人员，提交缺陷的人需要密切注意缺陷的状态，帮助缺陷的尽快解决。缺陷解决后需要即时对缺陷的修复进行验证。这样的目的有两个：一个是让缺陷尽快解决；二是方便后面缺陷的分析（保证缺陷相关的信息准确，如龄期等），这是缺陷状态的管理。
u 为了更好的改进开发过程和测试过程，需要对缺陷进行分析，总结如缺陷的类别、缺陷的龄期分布等信息，这是缺陷分析的管理。
（2）对软件缺陷的改正应该进行验证，以确保缺陷确实被解决，不利的影响已经被消除，并且解决该缺陷所引起的变化尽量不会带来新的缺陷。
（3）缺陷处理过程应该是闭合的，即确保每一个被发现的缺陷在过程中都能得以解决；在这个过程中追踪缺陷的状态；缺陷数据表在这个处理过程中都得到相应的修改和维护。
55、一个缺陷测试报告由哪几部分组成？
缺陷报告是测试人员主要的工作成果。不同的项目和测试机构会依据不同的标准和规范来编制缺陷测试报告，目的是为缺陷报告阅读者识别缺陷提供足够的信息，一般情况下，缺陷报告应包含下列内容：
（1）问题报告编号：为了便于对缺陷的管理，每个缺陷必须赋予一个唯一性的编号，编号规则可根据需要和管理要求制定。
（2）标题：标题用简明的方式传达缺陷的基本信息，标题应该简短并尽量做到唯一，以便在观察缺陷列表时，可以很容易的注意到。
（3）报告人：缺陷报告的原始作者，必要时，也包括缺陷报告的校订者。当负责修复该缺陷的开发人员对报告有疑问时，可以与报告人联系。
（4）报告日期：首次报告的日期。让开发人员知道创建缺陷报告的日期是重要的，有可能这是一个在前一个版本曾经修复过的缺陷。
（5）程序（或组件）名称：可分辨的被测试对象。
（6）版本号：测试可能跨越多个软件版本，提供版本信息以便对缺陷进行管理。
（7）配置：发现缺陷的软件和硬件配置。如：操作系统的类型、是否有游览器载入、处理器速度、RAM多大、可用的RAM、正在运行的其他程序等等。
（8）缺陷类型：如，代码错误、设计问题、文档不匹配等。
（9）严重性：描述所报告的缺陷是一个导致系统垮台、任务挂起或数据丢失的错误，还是一个无关紧要的易用性问题。可以利用标准的要求或机构内部规定进行等级划分。可由测试人员先分配一个严重等级，然后由开发人员或管理人员根据进一步的分析进行修改。
（10）优先级：由开发人员或管理人员进行确定，依据修复这个缺陷的重要性而定。优先级有时与严重性相关，但是一个不太严重但是频繁出现的缺陷也应该拥有较高的修改优先级。
（11）关键词：以便分类查找缺陷报告，关键词可在任何时候添加。
（12）缺陷描述：对发现的问题进行详细说明，尽管描述必须深入，但简明依然是重要的。缺陷描述的主要目的是说服开发人员决定去修复这个缺陷。
（13）重现步骤：这些步骤必须是有限的，并且描述的信息足够使读者知道正确的执行就可以重现这个缺陷。
（14）结果对比：在执行力重现缺陷的步骤之后，期望发生什么，实际上又发生什么。
为了管理这些缺陷，除了缺陷报告中包含的这些内容之外，还会包含一些其他的信息，包括：缺陷的状况、修改人员等。
56、简述一下缺陷的生命周期
缺陷的生命周期包括从发现缺陷，到汇报缺陷、缺陷分级与分配、制定解决方案、跟踪缺陷状态，重复测试直至缺陷解决的整个过程。
u 发现缺陷
测试人员根据测试需求，利用各种测试工具，规划、设计、安排和执行全面测试，期间被确认的所有和项目有关的缺陷和差异都将汇报到缺陷管理工具中。一个缺陷被发现和确认并开始登记到缺陷管理工具的那一刻，标志着一个缺陷的管理生命周期的开始，之后经历一系列过程直至问题得到正常/非正常解决为止。
u 汇报缺陷
测试人员将发现的缺陷提交到缺陷管理工具中，并将其状态设置为“NEW”。
u 缺陷分级与分配
测试主管将缺陷状态从“NEW”改为“OPEN”,并在一定的时间内（根据缺陷严重程度）更新描述信息，接着指派给适合的小组。
u 制定解决方案
由来自开发、项目管理、产品管理和项目相关的业务团队代表及测试主管共同召开缺陷解决会议，制定解决方案，确保所有缺陷都能设计并得到有效解决。
u 跟踪缺陷状态
在缺陷管理工具中，每个缺陷都有一个状态显示，会在整个测试周期中得到随时更新。每次当缺陷状态有了更新，实现的过程信息就会追加到缺陷历史记录中。
u 重复测试直至缺陷关闭
被修复缺陷如果没有代码变更，将马上展开重复测试，并立即关闭。需要代码变更的缺陷修复会汇总在一个版本BUILD中，之后展开重复测试，接着将根据测试结果或者关闭缺陷，或者将缺陷重新开放，继续修复直至所有缺陷全部关闭。
57、测试问题的严重性分为几级？如何区分？
测试问题按照严重程度由高到低的顺序划分为：
A类—系统崩溃，包括以下各种错误： 1． 由于程序所引起的死机,非法退出 2． 死循环 3． 数据库发生死锁 4． 因错误操作导致的程序中断 5． 功能错误 6． 与数据库连接错误 7． 数据通讯错误
B类—严重，包括以下各种错误： 1． 程序错误 2． 程序接口错误 3． 数据库的表、业务规则、缺省值未加完整性等约束条件
C类—一般，包括以下各种错误： 1． 操作界面错误（包括数据窗口内列名定义、含义是否一致） 2． 打印内容、格式错误 3． 简单的输入限制未放在前台进行控制 4． 删除操作未给出提示 5． 数据库表中有过多的空字段
D类—次要，包括以下各种错误： 1． 界面不规范 2． 辅助说明描述不清楚 3． 输入输出不规范 4． 长操作未给用户提示 5． 提示窗口文字未采用行业术语 6． 可输入区域和只读区域没有明显的区分标志
E类—建议
58、阶段评审与同行评审的区别。
|
| 同行评审 | 阶段评审 |
| 定义 | 同行评审是指对由一个或多个拥有与产品创建者类似专长的人对其产品作出评价。 | 由项目总体小组成员或特邀专家、项目委托单位或用户的代表、质量保证人员、软件开发单位和上级主管部门的代表及其他与评审内容相关的人员等共同对软件生存周期各个阶段的产出物进行评审 |
| 评审目的 | 发现小规模工作产品的错误，只要是找错误。 检验工作产品是否正确的满足了以往的工作产品中建立的规范，如需求或设计文档 | 评审模块、阶段作品的正确性可行性及完整性 确保在软件开发工作的各个阶段和各个方面都认真采取各项措施来保证与提高软件的质量。
|
| 参评人数/人员 | 3-7人人员必须经过同行评审会议的培训,由SQA指导 架构或概要设计——架构师，需求分析师，设计师，项目经理，集成测试工程师 详细设计——设计师，架构师，程序员，集成测试工程师 过程文档——过程改进组负责人，过程改进工作组成员，管理级的过程拥有者，使用过程的实践者的代表 项目计划——项目经理，产品经理，需求提出者，市场或销售代表，技术负责人，质量保证工程师 需求规格说明书——需求分析师，项目经理，架构师，设计师，系统测试工程师，质量保证经理，用户或市场代表，文档编写者，业务专家，技术支持代表 源代码——程序员，设计师，单元测试工程师，维护者，需求分析师，编码标准专家 系统技术文档——创建者，项目经理，维护者，程序员 测试文档——测试工程师，程序员（单元测试）或架构师（集成测试）或需求分析师（系统测试），质量保证代表 用户界面设计——用户界面设计师，需求分析师，用户，应用领域专家，可用性或人体专家，系统测试工程师 用户手册——文档编写者，需求分析师，用户或市场代表，系统测试工程师，维护人员，设计师，用户教育设计师，培训师，技术支持代表 | 5人左右评审人必须是专家具有系统评审资格 原则上由项目总体小组成员或特邀专家担任评审组长，评审小组成员应该包括项目委托单位或用户的代表、质量保证人员、软件开发单位和上级主管部门的代表及其他与评审内容相关的人员等 |
| 评审内容 | 内容小一般文档 < 40页, 代码 < 500行 架构或概要设计、详细设计、过程文档、项目计划、需求规格说明书、源代码、系统技术文档、测试文档、用户界面设计、用户手册 | 内容多,主要看重点 第一次评审软件需求、概要设计、验证与确认方法； 第二次评审详细设计、功能测试与演示，并对第一次评审结果复核；第三次是功能检查、物理检查和综合检查。 |
| 评审时间 | 一小部分工作产品完成 | 通常是设置在关键路径的时间点上! |
| 优点 | 1、 1、最重要的是让软件变得更易读和维护2、 作为保证普遍的编程标准的机制3、 作为保证指定语言的编码标准的机制4、 提早发现bug5、 满足顾客对这方面行为的明确要求 | 1可以尽可能早和高效地消除软件工作产品中的缺陷，从而提高软件产品的质量，获得较低的生命周期成本，增加软件测试过程的有效性，保证软件产品的可维护性。 2还可以提供从需求到设计的可跟踪性，为后续阶段的开发提供正确的技术基础。 |
| 缺点 | 1、 1、需要其他项目组提供资源2、可能会流于仅仅指出个人编程风格和倾向的形式主义3、 需要后续的跟踪确保软件按同行的建议进行了修改 |
|
59、软件本地化测试比功能测试都有哪些方面需要注意？
软件本地化测试的目的：查找并修复被测系统的缺陷，满足不同国家、不同地域的客户需求,使国际化的优秀软件能够跨越语言和文化的障碍,为世界所共享。
软件本地化测试的测试策略（注意事项）：1.本地化软件要在各种本地化操作系统上安装并测试。2.源语言软件安装在另一台相同源语言操作系统上，作为对比测试。3.重点测试因本地化引起的软件的功能和软件界面的错误。4.测试本地化软件的翻译质量。5.手工测试和自动测试相结合。
60、结构化系统测试和功能性系统测试分别采用了哪些方法和技术？
结构化系统测试方法和技术：
系统测试时管理信息系统开发周期中一个十分重要而漫长的阶段。其重要性体现在它是保证系统质量与可靠的最后关口，是对整个系统开发过程包括系统分析、系统设计和系统实现的最终审查。结构化系统测试的方法包括：
u 模块测试（单调）：模块测试是独立地对单个模块进行测试，是整个系统测试的基础。模块测试主要从模块接口、模块内部之数据结构、逻辑路径、出错处理、边界条件等5个方面去检查模块。
u 子系统测试（分调）：子系统是在模块测试的基础上，解决模块间相互调用的问题。子系统测试，通常可以采用自顶向下测试和自底向上测试两种方法。
u 系统测试（总调）：所有子系统都测试成功后，就可以进行系统整体测试。它主要解决各子系统之间的数据通信和数据共享（公用数据库）问题以及满足用户要求的程度。系统测试的依据是系统分析报告，要全面考核系统是否达到了系统分析的目标。
u 验收测试：是用户在实际应用环境中所进行的真实数据测试。主要使用原手工系统所用过的历史数据，将运行结果和手工所得结果相核对，以考察系统的可靠性和运行效率。
功能性测试的方法和技术
u 功能分解： 把软件分解为相对独立的功能单元。通过功能分解可以明确软件功能性测试的内容，使软件功能性测试可度量，有利于测试监督和管理
u 等价类划分： 是将程序的输入域或输出域的不同区间划分为不同的数据类，以便导出测试用例。每个等价类所揭示的程序错误都是等价的，要求此方法的测试用例能各自发现一类错误，从而减少必须开发的测试用例数 。等价类划分法又分为有效等价类和无效等价类。前者是对于程序的需求说明来说是合理的，有意义的输入数据所构成的集合，利用它可以检验程序是否实现了预期的功能和性能。后者是对于程序的需求说明来说是不合理的，没有意义的输入数据所构成的集合 。利用它可以检验程序对于无效数据的处理能力。
u 边界值分析法：是一种补充等价类划分的测试用例设计技术。不是对某个等价类随便挑一个数据做测试数据，而是选一个或多个边界数据，使得该等价类的每个边界都被测试到 。不仅考虑输入数据，而且考虑输出数据。
u 因果图法：考虑输入条件之间的相互联系、相互组合 ，最终生成的是判定表，它适用于检查程序输入条件的各种组合情况。
分析软件规格说明描述中的因果关系（输入与输出的因果关系）
找出原因与结果、原因与原因之间的对应关系，画出因果图
在因果图上标记约束或限制条件
把因果图转化为判定表
将判定表中的每一列拿出来设计测试用例
u 在一些数据处理问题中，某些操作依赖多个逻辑条件的取值。处理这类问题的一个非常有力的分析和表达工具是判定表。一些软件的功能需求可用判定表表达得非常清楚，在检验程序的功能时判定表也就成为一个非常有力的工具。
u 随机测试 使用随机数生成器选取测试用例值。
u 错误推测法：是基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性地设计测试用例。
61、软件的安全性应从哪几个方面去测试？
软件安全性测试可分为功能测试和安全漏洞测试两个方面。
安全功能测试基于软件的安全功能需求说明，测试软件的安全功能实现是否与安全需求一致，需求实现是否正确完备。软件主要的安全功能需求包括数据机密性、完整性、可用性、不可否认性、身份认证、授权、访问控制、审计跟踪、委托、隐私保护、安全管理等。
安全漏洞测试从攻击者的角度，以发现软件的安全漏洞为目的。安全漏洞是指系统在设计、实现、操作、管理上存在的可被利用的缺陷或弱点。漏洞被利用可能造成软件受到攻击，使软件进入不安全的状态，安全漏洞测试就是识别软件的安全漏洞。
62、怎样做好文档测试？
文档的测试着手点定在两个方面：格式和内容
格式：CMMI模型使软件工程规范化，文档同样需要制定固定的规范，确保撰写格式符合标准。
内容：仔细阅读，跟随每个步骤，检查每个图形，尝试每个示例。保证文档的内容正确、完善，达到文档制定的预期目的。
63、开发部提交给你一个系统进行测试，你如何展开工作？
l 成立测试组，确定测试经理或测试组长（通常安排测试设计员担任）一名，测试设计员和测试员若干。
l 要求开发部或项目的组系统分析员负责生成需求工件集，提供系统测试所需要的输入，管理需求。
l 由配置管理员建立测试环境，以及对测试工作进行配置管理。
l 测试设计员根据需求工件和《软件项目计划》制定系统测试计划，生成《系统测试计划》文档
l 测试设计员根据《软件需求说明书》和《系统测试计划》设计系统测试用例和系统测试过程。
l 测试设计员根据《系统测试计划》和工作版本实施系统测试，生成系统测试脚本
l 由测试员按照《系统测试计划》和系统测试用例、测试过程、测试脚本执行系统测试。
l 最后由测试经理或测试设计核心人员评估系统测试结果，撰写《测试分析报告》。
64、项目的集中管理在软件公司的哪一个层面？
65、使用什么工具进行软件测试的跟踪管理,描述管理的过程。
目前已有的缺陷跟踪管理软件包括Compuware公司的TrackRecord软件（商业软件）、Mozilla公司的Buzilla软件（免费软件），以及国内的微创公司的BMS软件，这些软件在功能上各有特点，可以根据实际情况选用。当然，也可以自己开发缺陷跟踪软件，例如基于Notes或是ClearQuese开发缺陷跟踪管理软件。 用BugZilla为例子，,描述管理的过程
u 测试人员发现了BUG，提交到Bugzilla中，状态为new，BUG的接受者为开发接口人员
u 开发接口将BUG分配给相关的模块的开发人员，状态修改为已分配
u 开发人员和测试确认BUG，如果是本人的BUG，则设置为接收；如果是别的开发人员的问题，则转发出去，由下一个开发人员来进行此行为；如果认为不是问题，则需要大家讨论并确认后，拒绝这个BUG，然后测试人员关闭此问题。
u 如果开发人员接受了BUG，并修改好以后，将BUG状态修改为已修复，并告知测试在哪个版本中可以测试。
u 测试人员在新版本中测试，如果发现问题依然存在，则拒绝修改；如果已经修复，则关闭BUG。
66、简要写出自己在理解的基础之上所认为引入测试管理的意义？
软件测试管理是一种活动，可以对各阶段的测试计划、测试用例、测试流程、测试文档等进行跟踪、管理并记录其结果。采用软件测试管理可以为软件开发提供一个多阶段、逐步递进的实施方案。通过对测试的管理，可以用有限的时间和成本完成软件开发，确保产品的质量，进一步提高计算机软件在市场上的竞争能力。
67、写出你对软件测试的认识，尽量详细。（就是能写多少写多少！）
软件测试定义、目的、特点、原则、重要性、过程或基本步骤、对象、生命周期、方法与策略、类型或分类、工具、过程管理、缺陷跟踪、配置管理、
68、工作中哪些需要改进,期望的工作环境？
期望的工作环境：
领导：深矜用人之道，有人格魅力、魄力，英明，有敏锐的市场洞察力和开拓能力，有亲和力，对员工注重人文关怀，能为员工创造紧张但融洽的工作氛围，给员工归属感。
公司管理：建立和健全完善的管理机制、保障公司运作务实、高效。责任分明、公平、公正、公开，适度的奖惩机制，以人为本，相信员工，力争打造一个学习型和创新型团队。
员工之间：平等、友好，互相尊重，互相帮助，以雄厚的实力服人，以高尚的道德感化人。
硬件建设：良好、齐全的硬件设施和先进的科研设备
69、测试人员具备的素质,你认为如何做好一名优秀的软件测试工程师？
（1）计算机专业技能
基本常识
l 计算机基础知识
l 软件测试基本知识
软件质量，软件质量管理基础知识，软件测试概念，软件测试标准，软件测试项目管理，测试流程管理、缺陷管理、软件测试技术及方法，自动化测试概念、框架、流程，自动化测试技术等知识。
好多人觉得自动化测试就是使用自动化测试工具，其实各种工具只是自动化测试实施的一个有效利器，如何建立一个脱离工具的自动化测试框架远远比研究如何使用测试工具复杂，困难的多。
l 软件开发基本知识（软件工程知识，理解软件开发方法及过程）
编程能力
C/C++，VB，VC，Java，.net，ASP，Javascript等。具体要求要视公司的具体项目或产品来定。但一般以C为基本要求。具备一定的算法设计能力，测试工程师至少应该掌握Java、C#、C++之类的一门语言以及相应的开发工具。
数据库知识
SQL Server，Oracle，Mysql，Sybase等。一般对测试人员的要求就是要求会使用，然后熟练使用SQL语句进行查询，修改，添加，删除数据操作。
数据库知识则是更应该掌握技能，现在的应用系统几乎离不开数据库。因此不但要掌握基本的安装、配置，还要掌握SQL。测试人员至少应该掌握Mysql、MS Sqlserver、Oracle等常见数据库的使用。
操作系统
Windows，Linux（常用的RedHat，SUSE，Debian）/Unix（FreeBSD，Solaris，HP-UX，AIX，Mac）系统。
操作系统和中间件方面，应该掌握基本的使用以及安装、配置等。例如很多应用系统都是基于Unix、linux来运行的，这就要求测试人员掌握基本的操作命令以及相关的工具软件。而WebLogic、Websphere等中间件的安装、配置很多时候也需要掌握一些。
网络知识
在网络方面，测试人员应该掌握基本的网络协议以及网络工作原理，尤其要掌握一些网络环境的配置，这些都是测试工作中经常遇到的知识。
自动化测试工具
功能测试工具：Quick Test Pro, Win Runner, Robot, QARun
性能测试工具：LoadRunner, Robot, QALoad, WebLoad, Was
白盒测试工具：Purify, DevParter, Logiscope, C++Test,JTest
测试管理工具：Test Director, Test Manager, QACenter, Test View Manager
缺陷管理工具：ClearQuest,TrackRecord, Bugzilla
实战能力（工作经验）
u 公司的测试流程
u 公司的具体缺陷管理流程（提交bug报告，追踪bug状态）
u 测试环境的搭建及管理
u 测试计划，测试用例，测试报告等相关文档的编写
外语
u 英语
u 日语
（2）行业知识
行业主要指测试人员所在企业涉及的行业领域，例如很多IT企业从事石油、电信、银行、电子政务、电子商务等行业领域的产品开发。行业知识即业务知识，是测试人员做好测试工作的又一个前提条件，只有深入地了解了产品的业务流程，才可以判断出开发人员实现的产品功能是否正确。
很多时候，软件运行起来没有异常，但是功能不一定正确。只有掌握了相关的行业知识，才可以判断出用户的业务需求是否得到了实现。
行业知识与工作经验有一定关系，通过时间即可以完成积累。
（3）个人素养
通过30分钟至1个小时的面试，试着了解面试者的性格是否适合软件测试的工作。
u 热爱测试工作，对测试感兴趣
u 敢于面对新事物，对新事物敏感
u 善于发现问题、解决问题
u 专心、细心、耐心 、责任心、自信心
u 良好的沟通能力和技巧以及团队合作精神
u 学习、工作积极主动，优秀的学习能力和记忆力
u 时间观念和逻辑思维能力强
u 上进性强，永远不满足现状
u 头脑灵活、善于变通、富有创造性
u 逆向思维、发散思维
u 能够承受压力并排遣压力
u 善于怀疑，目光敏锐，有准确判断的能力
u 保持一个良好的心情
u 有大局观、考虑问题要全面
u 追求完美
u 幽默感
u 要学会放松自己
u 学会自我总结
70、简述你对测试工作的认识过程、在以后的工作的一些建议。
我曾给过自己许多职业定位，但由于种种原因，这些目标都被搁浅。在研二下学期，就业问题被提上日程。由于我本科和研究生阶段都是在学计算机专业，所以我肯定要找与计算机技术类的工作。计算机技术包括硬件和软件两个大的方面，过去我对计算机的学习主要侧重于软件方面，所以我打算向软件方向发展。而软件方面又分为软件开发和软件测试两大类。个人认为，软件开发的从业人员年龄大都在30岁左右，随着年龄的增长，软件开发人员一部分走向管理层，而另一部分就要面临重新择业的问题，要么转向软件测试，要么转向其他行业。但是相对来讲，软件测试从业人员的职业寿命要长的多，而且年龄越大，经验越丰富，身价也就越高，这是从职业发展的角度来说的。从市场需求的角度来说，国内中型、大型软件公司都开始认识到软件测试对于软件质量和开发成本的重要性，软件测试人员需求量大，软件测试属于朝阳职业，于是我决心从事软件测试职业。
2008年3月份，我购买并开始自学赵斌老师编写的《软件测试技术经典教程》（高级软件测试工程师专用）。另外，我在网上下载了一些自动化测试软件和软件测试学习资料，通过对软件测试基本理论和自动化测试工具的学习，我发现自己当初的选择是正确的，我也越来越喜欢软件测试工作。
在国内，特别是一些小型软件企业，开发与测试管理还不够规范，并没有完全按照软件工程的思想去管理软件开发流程，这就使得软件产品的质量大打折扣，软件开发成本也难以控制。所以，我建议软件开发与测试都应该遵照科学的开发方法，强化质量管理和过程改进，正确认识软件测试对于软件质量的重要性。
六、问答题
1、您是否了解以往所工作的企业的软件测试过程？如果了解，请试述在这个过程中都有哪些工作要做？分别由哪些不同的角色来完成这些工作？
l 成立测试组，确定测试经理或测试组长（通常安排测试设计员担任）一名，测试设计员和测试员若干。
l 要求开发部或项目的组系统分析员负责生成需求工件集，提供系统测试所需要的输入，管理需求。
l 由配置管理员建立测试环境，以及对测试工作进行配置管理。
l 测试设计员根据需求工件和《软件项目计划》制定系统测试计划，生成《系统测试计划》文档
l 测试设计员根据《软件需求说明书》和《系统测试计划》设计系统测试用例和系统测试过程。
l 测试设计员根据《系统测试计划》和工作版本实施系统测试，生成系统测试脚本
l 由测试员按照《系统测试计划》和系统测试用例、测试过程、测试脚本执行系统测试。
l 最后由测试经理或测试设计核心人员评估系统测试结果，撰写《测试分析报告》。
2、您是否了解以往所工作的企业的软件开发过程？如果了解，请试述一个完整的开发过程需要完成哪些工作？分别由哪些不同的角色来完成这些工作？（对于软件测试部分，可以简述）
一个完整的开发过程至少需要完成项目计划、需求分析、软件开发、测试以及过程管理等方面的工作。
u 项目计划阶段
项目计划草案和风险管理计划作为第一步，当有一个商业机会后，根据公司高层负责制定的初步商业计划书来完成项目的计划草案，确定、分析项目风险并确定其优先级，还要制定风险解决方案。本阶段的目的是确立产品开发的经济理由。
当确定开发之后则制定软件开发计划、人员组织结构定义及配备、过程控制计划。
u 需求分析阶段
需求分析阶段的工作是根据用户界面原型及客户需求描述，详细说明系统将要实现的所有功能，在系统工作方面与用户达成一致。
u 软件开发阶段
本阶段采用面向对象方法，主要完成软件架构、类设计、数据库设计、编码和单元测试、集成系统等方面的工作，从物理上实现目标系统。
u 测试阶段
在测试阶段，首先收集和组织测试信息，制定测试计划，为测试工作提供指导。然后使用真实数据执行测试并记录测试结果，撰写测试报告以及帮助文件和用户操作手册。
u 管理软件开发过程
为了保证软件开发质量、降低开发成本，必须做好会议组织、程序评审、人员协调、环境配置等方面的管理工作。
各参与角色的具体职责描述
（1） 项目经理
u 制定产品的目标。
u 制定各个工作的详细任务表，跟踪这些任务的执行情况，进行控制。
u 组织会议对程序进行评审。
u 综合具体情况，对各种不同方案进行取舍并做出决定。
u 协调各项目参与人员之间的关系。
（2）系统分析员
u 了解用户需求，写出《软件需求规约》。
u 建立用户界面原型。
（3）设计员
u 定义类的方法和属性以及各个类之间的关联，画出类图。
u 进行数据库设计。
（4）程序员
u 按项目的要求进行编码和单元测试。
（5）测试员
u 执行测试，描述测试结果，提出问题解决方案。
3、您以往的工作中是否曾开展过测试用例的评审工作？如果有，请描述测试用例评审的过程和评审的内容。
测试用例是软件测试的准则，但它并不是一经编制完成就成为准则。测试用例在设计编制过程中要组织同级互查。测试用例在设计之后需要经过评审，评审时需要参加的人员：项目经理，系统分析员，测试设计员，测试员，也可邀请客户代表参加。需要评审的内容如下：
¨ 用例是否完整？是否每一个需求都有其对应的测试用例来验证？
¨ 是否每一个设计元素都有其对应的测试用例来验证？
¨ 事件顺序，能否产生唯一的测试目标行为？
¨ 是否每隔测试用例都阐述了预期结果？
¨ 是否每个测试用例（或每组相关的测试用例）都确定了初始的测试目标状态和测试数据状态？
¨ 测试用例是否包含了所有单一的边界？
¨ 测试用例是否包含了所有的业务数据流？
¨ 是否所有的测试用例名称，ID都与测试工件命名约定一致？
4、您以往是否曾经从事过单元测试和集成测试？如果有，请谈一下这些工作的实际开展情况。
单元测试的内容及流程
集成测试内容及流程
5、您如何看待软件过程改进？在您曾经工作过的企业中，是否有一些需要改进的东西呢？您期望的理想的测试人员的工作环境是怎样的？
¨ 淡泊名利，练好内功。我们是要进行实实在在的过程改进，最后使得通过CMM/CMMI.评估成为我们成功地进行过程改进活动的顺带结果。提高企业竞争力，练好内功才是真正的解决之道——我们输给别人，大都不是输在技术上，而是我们能否为客户生产高质量的产品，能否以最快的速度占领市场，能否花费最少的成本开发出最有用的产品。
¨ 过程改进贵在坚持。在进行过程改进之前，首先识别出许多待改进问题——项目计划编制不合理、缺少配置管理过程、项目进展情况不透明等等，将这些待改进项逐一列出，然后根据其优先级别（此级别可以根据待改进项的紧急程度或待改进项可以增加的工作价值等等来进行定义）制定出改进计划并坚持逐步实施。
¨ 过程改进困难重重，做好团队及个人激励，减少改进阻力。为了有效的完成过程改进，企业的领导者应该使高级管理层理解改变的必要性，并通过说服去赢得大多数员工的支持。另外，企业在过程定义的时候一定要做到过程的简单及可行性。
¨ 过程改进要面向目标，用数据说话。找出自己所期望的特定结果，用以指出那些为了实现这些目标而必须进行的变更。
¨ 如果企业不想让过程改进失败，那就为其分配足够的资源。对于软件企业来说，过程改进是为实现长期成功和生存而进行的投资。然而仅需把5%的精力投入到提高质量和生产力的活动中，软件组就能够得到数倍的投资回报。
6、您以往工作过的企业中，是否开展了软件配置管理工作？您能否描述一下这项工作的开展情况和您对这项工作的认识？软件配置管理的作用？软件配置包括什么？
软件配置管理的作用：
软件配置管理是为了系统地控制配置的变更和维护配置在整个系统的生命周期中的完整性和可追踪性，而标识软件在时间上不同点的配置的学科。软件配置管理是一套技术上和管理上的指导和监督的方法，用来：①识别和记录配置项的功能特征和物理特征；②控制这些特征的变更；③记录和报告变更的处理和执行的状态；④以及验证其符合特定的需求。在软件的生存周期内软件变更是不可避免的，而变更加剧了项目中软件开发者之间的混乱。软件配置管理能协调软件开发过程，使得混乱减少到最小，并可最有效地提高软件的生产效率。
软件配置管理的内容
软件配置管理的基本工作内容是标识软件配置项、建立软件配置数据库、对配置项的修改加以系统的控制和管理（用完善、有效的审签制度体现控制；用规范、规程、监督体现管理）。具体包括以下几个方面：
¨ SCM过程管理，包括：SCM的组织结构上下文、SCM的约束和指导、SCM计划、SCM计划本身和SCM的监督。
¨ 软件配置标识，识别要控制的项目，为各个项目及其版本建立标识方案，确定在获取和管理被控制项目中要使用的工具和技术。
¨ 软件配置控制，它管理软件生命周期中的变更，包括：①软件变更的请求、评价和批准；②实现软件变更；③偏离和放弃。
¨ 软件配置状态薄记，其主题有软件配置状态信息和软件配置状态报告生成。
¨ 软件配置审计，包括：软件功能配置审计、软件物理配置审计、软件基线的过程内部审计。
¨ 软件发布管理和交付，覆盖软件建造和软件发布管理。
实施软件配置管理的基本任务是：
¨ 制订软件配置管理计划
¨ 进行软件版本管理和发行管理
¨ 软件更改管理
¨ 软件文档管理
¨ 配置审计和配置报告
7、您是否熟悉一些主流的软件工程方法论和思想，如RUP、CMM、CMMI、XP、PSP、TSP。如果熟悉，您是否可以谈一下对这些方法论和思想的认识？
CMM:SW Capability Maturity Model 软件能力成熟度模型,其作用是用于软件过程的改进、评估及软件能力的评鉴
CMMI:Capability Maturity Model Integration 能力成熟度模型集成 CMMI融入了大部分最新的软件管理实践，同时弥补了SW-CMM模型中的缺陷
RUP:rational unified process 是软件工程化过程。它提供了在开发机构中分派任务和责任的纪律化方法.它的目标是在可预见的日程和预算前提下确保满足最终用户需求的高质量产品,个人认为：它的核心观念是开发的迭代，每个公司可以根据自身的软件开发的流程和待开发项目的特点对RUP进行适当的剪裁，制定出符合自己的软件开发流程。
ＸＰ：extreme program，即极限编程的意思，适用于小型团队的软件开发，想上面第三个问题就可以结合原型法采用这样的开发流程。要明白测试对于xp开发的重要性，强调测试（重点是单元测试）先行的理念。编程可以明显提高代码的质量，持续集成对于快速定位问题很有好处。
PSP ,TSP 分别是个体软件过程（Personal Software Process），群组软件过程（Team Software Process）大家都知道，CMM只是告诉你怎么做但并没有告诉你如何做，所以PSP/TSP就是告诉你企业在实施CMM的过程中如何做，PSP强调建立个人技能（如何制定计划、控制质量及如何与其他人相互协作等等）而TSP着重于生产并交付高质量的软件产品（如何有效地规划和管理所面临的项目开发任务等等）
总之，单纯实施CMM，永远不能真正做到能力成熟度的升级，只有将实施CMM与实施PSP和TSP有机地结合起来，才能发挥最大的效力。因此，软件过程框架应该是CMM/PSP/TSP的有机集成。
8、比较黑盒测试,白盒测试,单元测试,集成测试,系统测试,验收测试的区别与联系
黑盒测试：已知产品的功能设计规格，可以进行测试证明每个实现了的功能是否符合要求。
白盒测试：已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规格要求，所有内部成分是否以经过检查。
软件的黑盒测试意味着测试要在软件的接口处进行。这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试或数据驱动测试。黑盒测试主要是为了发现以下几类错误：
①是否有不正确或遗漏的功能？
②在接口上，输入是否能正确的接受？能否输出正确的结果？
③是否有数据结构错误或外部信息（例如数据文件）访问错误？
④性能上是否能够满足要求？
⑤是否有初始化或终止性错误？
软件的白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看做一个打开的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序状态，确定实际状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。白盒测试主要是想对程序模块进行如下检查：
①对程序模块的所有独立的执行路径至少测试一遍。
②对所有的逻辑判定，取“真”与取“假”的两种情况都能至少测一遍。
③在循环的边界和运行的界限内执行循环体。
④测试内部数据结构的有效性，等等。
单元测试（模块测试）是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为。
单元测试是由程序员自己来完成，最终受益的也是程序员自己。可以这么说，程序员有责任编写功能代码，同时也就有责任为自己的代码编写单元测试。执行单元测试，就是为了证明这段代码的行为和我们期望的一致。
集成测试（也叫组装测试，联合测试）是单元测试的逻辑扩展。它的最简单的形式是：两个已经测试过的单元组合成一个组件，并且测试它们之间的接口。从这一层意义上讲，组件是指多个单元的集成聚合。在现实方案中，许多单元组合成组件，而这些组件又聚合成程序的更大部分。方法是测试片段的组合，并最终扩展进程，将您的模块与其他组的模块一起测试。最后，将构成进程的所有模块一起测试。
系统测试是将经过测试的子系统装配成一个完整系统来测试。它是检验系统是否确实能提供系统方案说明书中指定功能的有效方法。（常见的联调测试）
系统测试的目的是对最终软件系统进行全面的测试，确保最终软件系统满足产品需求并且遵循系统设计。
验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。
验收测试是向未来的用户表明系统能够像预定要求那样工作。经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是验收测试的任务，即软件的功能和性能如同用户所合理期待的那样。
9、软件测试的评审过程和内容
白盒测试->静态分析
代码走查： 开发组织内部进行的，采用讲解、讨论和模拟运行的方式进行的查找错误的活动。
代码审查：在开发组内部进行的，采用讲解、提问并使用编码模板进行的查找错误的活动。一般有正式的计划、流程和结果报告。
技术评审：开发组、测试组合相关人员（QA、产品经理等）联合进行的，采用讲解、提问并使用编码模板进行的查找错误的活动，一般有正式的计划、流程和结果报告。
内部评审：组长组织测试小组对测试过程进行内部评审
外部评审：组长组织测试管理部和业务方参与评审
10、怎么评价软件工程师？
¨ 软件工程师一般指从事软件开发职业的人，其工作主要在于规划。
¨ 软件工程师分软件技术员、助理软件工程师、软件工程师、高级软件工程师4级
¨ 软件工程师社会需求大、工作压力大、待遇高、职业寿命短、需求不断的学习新工具，新方法、善于分析和解决问题，主要是靠做项目来积累自己的知识和经验
¨ 团合作精神和良好的沟通能力
11、怎么看待软件测试？软件测试是一个什么样的行业？希望以后的软件测试是怎么样的一个行业？
主观上由于开发人员思维的局限性，客观上由于目前开发的软件系统都由相当的复杂性，决定了在开发过程中出现软件错误是不可避免的。若能及早排除开发中的错误，就可以排除给后期工作带来的麻烦，也就避免了付出高昂的代价，从而大大地提高了系统开发过程的效率，因此，软件测试在整个软件开发生命周期各个环节中都是不可缺少的。
软件测试行业是软件行业中的新兴行业，由于高校没有设置相关专业，也由于软件企业以前普遍对测试重视不够，缺乏人才储备，因此格外抢手。
首先，从目前市场需求来看，一方面软件测试业的重要性日趋突显，一方面却存在着巨大的人才缺口，其严重的人才供需失衡的尴尬局面促使我国软件测试工程师在职场中基本上处于一个“双高”地位，即地位高、待遇高，在一些企业中，高级软件测试工程师的年薪都明显的高于其它职位。
其次，软件测试工程师对性别没有具体的要求，不像许多IT职位那样，更加偏好于男性。在IT业，竞争异常激烈，人们每天要面对大量不同工作压力， 尤其是软件开发工作， 在高强度的工作压力下，更是对人们脑力、体力的双项考验，因此，许多用人单位对于这一职位的招聘更偏向于男性，而软件测试工程师相比之下，工作的压力不是太大，更需要的是责任心和自信心，所以，对人才的性别也就没有什么特别的要求。
第三，也是最重要的一点，软件测试工程师的职业生涯将更为长久。质量是产品的灵魂，这也就充分说明了软件测试工作的重要作用，其工作在软件产业中无论何时都将是不可能被取代的。再有，在软件企业中，软件开发工作是业务的环节，而软件测试工作却包含了技术及管理的各个方面，而且，其对年龄的要求也没有一定的限制，所以，作为一名软件测试工程师免去了在竞争越来越激烈的IT职场不断打拼的动荡之苦，其工作相对将更加稳定。
一方面随着自身项目开发和管理水平的提高，软件企业能提供更多的软件测试岗位需求,另一方面,软件测试外包业务的蓬勃发展进一步拉升对软件测试工程师岗位的强劲需求，最后，希望在强调软件测试对提高产品质量重要性、提供测试人员地位的大环境下，软件测试行业发展始终保持强劲势头。
12、你的职业生涯规划或测试职业发展目标是什么？
研究生毕业之前找到一份软件测试方面的工作。
入职后首先从基层如测试员做起，把我所学的理论知识特别是软件测试理论应用于项目实践，提高实际动手能力，积累实战经验。
工作一到两年后，对整个测试流程有清晰的了解，达到中级软件测试工程师水平。
工作三年后，掌握软件测试流程的各个环节，能够独当一面，达到高级软件测试工程师水平。
工作五年以后，在大型国内企业或外企担当软件测试技术顾问或测试经理，在技术和管理等方面形成自己的风格。
将来我有可能一直从事软件测试行业，也有可能在条件成熟后，转向电子商务或外贸行业。
13、为什么要在一个团队中开展软件测试工作？
任何软件在开发过程中都会留下缺陷，带有缺陷的软件产品如果提交出去，可能会给公司带来不可估量的损失，我们必须在客户之前发现尽可能多的问题，从而保障客户满意。而发现问题的这个过程称之为测试。
14、简述你在以前的工作中做过哪些事情，比较熟悉什么？最擅长那些工作？
此问题每个人都不一样。我自己的答案如下。
我主要的工作是系统测试和自动化测试，也曾少量涉及性能测试。在系统测试中，主要是对BOSS系统的业务逻辑功能，以及软交换系统的Class5特性进行测试。性能测试中，主要是进行的压力测试，在各个不同数量请求的情况下，获取系统响应时间以及系统资源消耗情况。自动化测试主要是通过自己写脚本以及一些第三方工具的结合来测试软交换的特性测试。
15、您所熟悉的软件测试类型都有哪些？请试着分别比较这些不同的测试类型的区别与联系（如功能测试、性能测试……）
答案一：
测试类型有：功能测试，性能测试，界面测试。
功能测试在测试工作中占的比例最大，功能测试也叫黑盒测试。是把测试对象看作一个黑盒子。利用黑盒测试法进行动态测试时，需要测试软件产品的功能，不需测试软件产品的内部结构和处理过程。采用黑盒技术设计测试用例的方法有：等价类划分、边界值分析、错误推测、因果图和综合策略。
性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。
界面测试，界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作，起到向导的作用。同时界面如同人的面孔，具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉，相反由于界面设计的失败，让用户有挫败感，再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。
区别在于，功能测试关注产品的所有功能上，要考虑到每个细节功能，每个可能存在的功能问题。性能测试主要关注于产品整体的多用户并发下的稳定性和健壮性。界面测试更关注于用户体验上，用户使用该产品的时候是否易用，是否易懂，是否规范（快捷键之类的），是否美观（能否吸引用户的注意力），是否安全（尽量在前台避免用户无意输入无效的数据，当然考虑到体验性，不能太粗鲁的弹出警告）？做某个性能测试的时候，首先它可能是个功能点，首先要保证它的功能是没问题的，然后再考虑该功能点的性能测试。
答案二：
(1)基本功能验证。主要是对发布的版本进行一些最主要功能的测试。英文常见叫法是Smoking Test, Basic Verification Test或者SanityCheck。
(2)功能测试。主要是依据需求或者需求分析文档，对所发布的版本进行测试，看看是否满足需求，是否出现了不必要的功能。
(3)单元测试。是开发人员进行的测试之一，一般是开发人员对很小的模块，比如函数进行测试，一般来说，开发人员还需要开发相应的测试桩来进行此类测试。
(4)集成测试。在大型的开发过程中，软件是模块化进行开发的，将不同的模块揉合在一起的话，需要进行的测试就是集成测试。
(5)系统测试。当软件提交给测试组后，是对整个系统的所有功能进行测试，一般来说，功能测试是系统测试的一个部分。
(6)压力测试。主要是在很大性能的情况下，这个性能已经接近了系统的极限，看看系统运转的情况。
(7)负载测试。主要是用各种不同的性能去检测系统，采集各个数据在这些性能情况下的数据。
(8)黑盒测试。指系统对你来说是完全不透明的，只给你留下了输入和最终输出，这个是功能测试的方法之一。
(9)灰盒测试。指在了解部分系统内部工作机制的情况下，对于系统进行的覆盖性测试。
(10)白盒测试。主要是在单元测试和集成测试的情况下，开发人员已知代码，对这一段的代码进行全路径的覆盖测试。
(11)界面测试。主要是看用户界面的友好性和易用性，是否有文字或者排版错误，是否有输入限制等等。
(12)回归测试。一般是系统发现BUG，开发人员修改后，和BUG直接相关以及可能相关的功能进行的测试。
(13)安装和卸载的测试。
(14)恢复测试。主要是一个系统在发生了灾难的情况下，从错误中是否容易恢复。
(15)兼容性测试。一个系统在不同的语言，操作系统下的系统测试。
(16)安全测试。系统在遇到攻击或者类似情况下的表现。
(17)Alpha测试。系统在给最终用户前，测试人员在实验室中模拟最终用户的测试。
(18) Beta测试。由部分最终用户通过使用来进行的测试。
(19)比较测试。和其他具有相同或者类似功能的系统进行对比的测试。
(20)验收测试。一般是最终用户在接受产品前，依据自己所提出的要求进行的测试，很多情况下，验收测试可能委托第三方机构完成。
16、测试计划工作的目的是什么？测试计划文档的内容应该包括什么？其中哪些是最重要的？
软件测试计划是指导测试过程的纲领性文件。包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。借助软件测试计划，参与测试的项目成员，尤其是测试管理人员，可以明确测试任务和测试方法，保持测试实施过程的顺畅沟通，跟踪和控制测试进度，应对测试过程中的各种变更。
测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。所以其中最重要的是测试测试策略和测试方法（最好是能先评审）。
17、你认为做好测试计划工作的关键是什么？
(1)明确测试的目标，增强测试计划的实用性
编写软件测试计划得重要目的就是使测试过程能够发现更多的软件缺陷，因此软件测试计划的价值取决于它对帮助管理测试项目，并且找出软件潜在的缺陷。因此，软件测试计划中的测试范围必须高度覆盖功能需求，测试方法必须切实可行，测试工具并且具有较高的实用性，便于使用，生成的测试结果直观、准确
(2)坚持“5W”规则，明确内容与过程
“5W”规则指的是“What（做什么）”、“Why（为什么做）”、“When（何时做）”、“Where（在哪里）”、“How（如何做）”。利用“5W”规则创建软件测试计划，可以帮助测试团队理解测试的目的（Why），明确测试的范围和内容（What），确定测试的开始和结束日期（When），指出测试的方法和工具（How），给出测试文档和软件的存放位置（Where）。
(3)采用评审和更新机制，保证测试计划满足实际需求
测试计划写作完成后，如果没有经过评审，直接发送给测试团队，测试计划内容的可能不准确或遗漏测试内容，或者软件需求变更引起测试范围的增减，而测试计划的内容没有及时更新，误导测试执行人员。
(4)分别创建测试计划与测试详细规格、测试用例
应把详细的测试技术指标包含到独立创建的测试详细规格文档，把用于指导测试小组执行测试过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中。测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。
18、黑盒测试的测试用例设计方法有哪些？
等价类划分
等价类划分是把所有可能的输入数据,即程序的输入域划分成若干部分（子集）,然后从每一个子集中选取少数具有代表性的数据作为测试用例.该方法是一种重要的,常用的黑盒测试用例设计方法.
1) 划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类.
有效等价类:是指对于程序的规格说明来说是合理的,有意义的输入数据构成的集合.利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能.
无效等价类:与有效等价类的定义恰巧相反.
设计测试用例时,要同时考虑这两种等价类.因为,软件不仅要能接收合理的数据,也要能经受意外的考验.这样的测试才能确保软件具有更高的可靠性.
2)划分等价类的方法:下面给出六条确定等价类的原则.
①在输入条件规定了取值范围或值的个数的情况下,则可以确立一个有效等价类和两个无效等价类.
②在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下,可确立一个有效等价类和一个无效等价类.
③在输入条件是一个布尔量的情况下,可确定一个有效等价类和一个无效等价类.
④在规定了输入数据的一组值（假定n个）,并且程序要对每一个输入值分别处理的情况下,可确立n个有效等价类和一个无效等价类.
⑤在规定了输入数据必须遵守的规则的情况下,可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）.
⑥在确知已划分的等价类中各元素在程序处理中的方式不同的情况下,则应再将该等价类进一步的划分为更小的等价类.
3）设计测试用例:在确立了等价类后,可建立等价类表,列出所有划分出的等价类:
输入条件 有效等价类 无效等价类
... ... ...
... ... ...
然后从划分出的等价类中按以下三个原则设计测试用例:
①为每一个等价类规定一个唯一的编号.
②设计一个新的测试用例,使其尽可能多地覆盖尚未被覆盖地有效等价类,重复这一步.直到所有的有效等价类都被覆盖为止.
③设计一个新的测试用例,使其仅覆盖一个尚未被覆盖的无效等价类,重复这一步.直到所有的无效等价类都被覆盖为止.
边界值分析法
边界值分析方法是对等价类划分方法的补充.
（1）边界值分析方法的考虑:
长期的测试工作经验告诉我们,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.
使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据.
（2）基于边界值分析方法选择测试用例的原则:
1）如果输入条件规定了值的范围,则应取刚达到这个范围的边界的值,以及刚刚超越这个范围边界的值作为测试输入数据.
2）如果输入条件规定了值的个数,则用最大个数,最小个数,比最小个数少一,比最大个数多一的数作为测试数据.
3）根据规格说明的每个输出条件,使用前面的原则1）.
4）根据规格说明的每个输出条件,应用前面的原则2）.
5）如果程序的规格说明给出的输入域或输出域是有序集合,则应选取集合的第一个元素和最后一个元素作为测试用例.
6）如果程序中使用了一个内部数据结构,则应当选择这个内部数据结构的边界上的值作为测试用例.
19、详细的描述一个测试活动完整的过程。
(测试工作的哪些步骤?在哪个阶段因该做什么由谁来完成?)
(1)项目经理通过和客户的交流，完成需求文档，由开发人员和测试人员共同完成需求文档的评审，评审的内容包括：需求描述不清楚的地方和可能有明显冲突或者无法实现的功能的地方。项目经理通过综合开发人员，测试人员以及客户的意见，完成项目计划。然后SQA进入项目，开始进行统计和跟踪
(2)开发人员根据需求文档完成需求分析文档，测试人员进行评审，评审的主要内容包括是否有遗漏或者双方理解不同的地方。测试人员完成测试计划文档，测试计划包括的内容上面有描述。
(3)测试人员根据修改好的需求分析文档开始写测试用例，同时开发人员完成概要设计文档，详细设计文档。此两份文档成为测试人员撰写测试用例的补充材料。
(4)测试用例完成后，测试和开发需要进行评审。
(5)测试人员搭建环境
(6)开发人员提交第一个版本，可能存在未完成功能，需要说明。测试人员进行测试，发现BUG后提交给BugZilla。
(7)开发提交第二个版本，包括Bug Fix以及增加了部分功能，测试人员进行测试。
(8)重复上面的工作，一般是3-4个版本后BUG数量减少，达到出货的要求。
(9)如果有客户反馈的问题，需要测试人员协助重现以及回归测试。
20、你了解哪些自动化测试工具？都有什么功能、性能及其他特点？
| 工具名称 | 来源 | 类型 | 费用 | 功能概要 |
| LoadRunner | Mercury公司 | 性能与负载压力 | 收费昂贵 | LoadRunner® 是一种预测系统行为和性能的工业标准级负载测试工具。通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题，LoadRunner 能够对整个企业架构进行测试。通过使用LoadRunner ，企业能最大限度地缩短测试时间，优化性能和加速应用系统的发布周期。LoadRunner 是一种适用于各种体系架构的自动负载测试工具，它能预测系统行为并优化系统性能。LoadRunner 的测试对象是整个企业的系统，它通过模拟实际用户的操作行为和实行实时性能监测，来帮助您更快的查找和发现问题。此外，还能支持广范的协议和技术，为您的特殊环境提供特殊的解决方案。 |
QuickTest Pro | Mercury公司 | 功能测试和回归测试 | 收费昂贵 | QTP是一个B/S系统的自动化功能测试的利器,软件程序测试工具。Mercury的自动化功能测试软件QuickTest Professional ，可以覆盖绝大多数的软件开发技术，简单高效，并具备测试用例可重用的特点。Mercury QuickTest Pro 是一款先进的自动化测试解决方案，用于创建功能和回归测试。它自动捕获、验证和重放用户的交互行为。 Mercury QuickTest Pro为每一个重要软件应用和环境提供功能和回归测试自动化的行业最佳解决方案。 |
TestDirector | Mercury公司 | 测试管理 | 收费昂贵 | 基于WEB的测试管理工具，他能够让你系统地控制整个测试过程，并创建整个测试工作流的框架和基础，使整个测试管理过程变得更为简单和有组织。他能够帮助你维护一个测试工程数据库，并且能够覆盖你的应用程序功能性的各个方面。T并且还为你提供了直观和有效的方式来计划和执行测试集、收集测试结果并分析数据。还专门提供了一个完善的缺陷跟踪系统。并可以同Mercury公司的测试工具、第三方或者自主开发的测试工具、需求和配置管理工具、建模工具的整合功能。你可以通过他进行需求定义、测试计划、测试执行和缺陷跟踪，即整个测试过程的各个阶段。 |
JUnit | 开源组织 | 单元测试，回归测试 | 开源 免费 | JUnit是由 Erich Gamma 和 Kent Beck 编写的一个单元测试框架（regression testing framework）。Junit测试是程序员测试，即所谓白盒测试，因为程序员知道被测试的软件如何（How）完成功能和完成什么样（What）的功能。Junit是一套框架，继承TestCase类，就可以用Junit进行自动测试了。 | |
Bugzilla | 开源组织 | 缺陷跟踪管理 | 开源免费 | Buzilla是一个BUG管理工具。作为一个产品缺陷的记录及跟踪工具，它能够为你建立一个完善的Bug跟踪体系，包括报告Bug、查询Bug记录并产生报表、处理解决、管理员系统初始化和设置四部分。并具有如下特点： 1。基于Web方式，安装简单、运行方便快捷、管理安全。 2。有利于缺陷的清楚传达。本系统使用数据库进行管理，提供全面详尽的报告输入项，产生标准化的Bug报告。 提供大量的分析选项和强大的查询匹配能力，能根据各种条件组合进行Bug统计。当错误在它的生命周期中变化时，开发人员、测试人员、及管理人员将及时获得动态的变化信息，允许你获取历史纪录，并在检查错误的状态时参考这一记录。 3。系统灵活，强大的可配置能力。Buzilla工具可以对软件产品设定不同的模块，并针对不同的模块设定制定的开发人员和测试人员；这样可以实现提交报告时自动发给指定的责任人；并可设定不同的小组，权限也可划分。设定不同的用户对Bug记录的操作权限不同，可有效控制进行管理。允许设定不同的严重程度和优先级可以在错误的生命其中管理错误，从最初的报告到最后的解决，确保了错误不会被忽略，同时可以使注意力集中在优先级和严重程度高的错误上。4。自动发送Email,通知相关人员。根据设定的不同责任人，自动发送最新的动态信息，有效的帮助测试人员和开发人员进行沟通。 | |
21、写出你用过的测试工具，并描述它的使用方法及功能。
测试工具主要分为黑盒测试工具、白盒测试工具、测试管理和缺陷管理工具，而黑盒测试工具又分为功能测试工具和性能测试工具。
我所了解到测试工具包括性能测试工具Loadrunner、功能测试工具Quick Test Pro、白盒测试工具C++ Test、测试管理工具Test Director，另外对Bugzilla 也有所了解。
¨ Loadrunner：是一种适用于各种体系架构的自动负载测试工具，它能预测系统行为并优化系统性能。Load runner的测试对象是整个企业的系统，它通过模拟实际用户的操作行为和实行实时性能监测，来帮助用户更快地查找和发现问题。此外，Load runner能支持广泛的协议和技术，为用户的特殊环境提供特殊的解决方案。
Loadrunner的性能测试流程：
①制定性能测试计划②录制测试脚本③创建运行场景④运行测试⑤监视场景⑥分析测试结果
¨ QuickTest Pro： 能够测试Windows标准应用程序、各种Web对象、Active控件、VisualBasic应用程序等。QTP会将应用程序的所有操作记录都记录下来，比如点击一个链接、选择一个复选框、提交一份表单等操作都会被QTP 所捕获，并自动将窗体中的各种控件对象记录下来，存储在对象仓库中。录制完毕或还可以对脚本进行编辑整理使其功能更加强大。QTP测试的流程是：编写测试计划、录制测试脚本、编辑脚本、运行测试、结果分析。
¨ C++ Test：是法国Parasoft公司开发的一款专门测试C/C++程序的白盒测试工具，它可以为开发人员和白盒测试工程师提供一个灵活、方便的方式来进行单元测试，它具有以下强大的功能：
①它可以对代码进行自动的静态分析，检查其是否符合相应的语法规范。C++ Test内置了许多业界权威的C/C++编程规范，会自动完成校验。
②它可以对代码进行自动的动态测试，包括自动创建测试桩模块和测试用例，当然它也允许手动添加自定义的测试用例。
③它可以对代码进行自动的回归测试和各种覆盖率的统计（如语句覆盖、分支覆盖等）。
¨ TestDirector：Test Director是MI公司开发的一款知名度测试管理工具，可以进行测试需求管理、计划管理、实例管理、缺陷管理。Test Director可以与QTP 、LoadRunner进行很好的集成，并且具有强大的图表统计功能，会自动生成丰富的统计图表。
TestDirector作为经典的测试管理工具，可以很方便地管理测试过程，包括搭建测试框架，制定测试流程等工作。Test Director还具有很强大的数据管理功能，在后台的数据库中集中管理测试需求、测试步骤、测试实例等资源。
¨ Bugzilla：是一种专门免费提供缺陷管理功能的工具。它的功能主要表现在：
强大的检索功能、用户可配置的通过Emai 公布Bug变更、历史变更记录、通过跟踪和描述处理Bug、附件管理、完备的产品分类方案和细致的安全策略、安全的审核机制、强大的后端数据库支持、Web、XML、Email和控制界面、友好的网络用户界面、丰富多样的配置设定、版本间向下兼容。
22、您在从事性能测试工作时，是否使用过一些测试工具？如果有，请试述该工具的工作原理，并以一个具体的工作中的例子描述该工具是如何在实际工作中应用的。
测试网管系统中，使用的Mimic来模拟终端，能够大量的节省成本。
测试软交换系统的时候，使用的Prolab来模拟终端并发送呼叫软交换，他完成了同时数百人才能完成的摘机拨号工作，主要工作原理是产生一些符合要求的IP包并发送给软交换系统，同时对软交换系统的回应进行处理，决定下一步动作。
23、性能测试工作的完整过程,目的,最关键的是什么？
性能测试是指在正常，峰值以及异常负载条件下，测试系统的各项性能指标；通过自动化的测试工具模拟进行。性能测试主要是测试软件运行中的各项指标是否符合需求；
性能测试完整过程：组建性能测试小组、确定性能测试策略、性能测试需求分析、性能测试计划设计、性能测试过程设计、压力点设计、性能测试实现、性能测试执行、性能测试结果分析等主要活动。
性能测试的目的：主要是保障在大量用户的情况下，服务能正常使用
1） 评估系统的能力
测试中得到的负荷和响应时间数据可被用于验证所计划的模型的能力，并帮助作出决策。
2） 识别体系中的弱点
受控的负荷被增加到一个极端水平，并突破它，从而修复体系的瓶颈或薄弱的地方。
3） 系统调优
重复运行测试，验证调整系统的活动得到了预期的结果，从而改进性能。检测软件中的问题，长时间的测试执行可导致程序发生由于内存泄漏引起的失败，揭示程序中的隐含问题或冲突。
4） 验证稳定性与可靠性
在一个生产负荷下执行测试一定的时间是评估系统稳定性和可靠性是否满足要求的唯一方法。
性能测试分为一般性能测试、稳定性或可靠性测试、负责测试、压力测试四种，其中压力测试是性能测试的重点，压力测试是通过工具产生并运行并发事务来模拟软件系统的实际运行状态，从而获得各种性能指标。
24、在您以往的工作中，一条软件缺陷（或者叫Bug）记录都包含了哪些内容？如何提交高质量的软件缺陷（Bug）记录？
在传统的BugZilla中，BUG描述应该包括以下的信息
(1)BUG产生对应的软件版本
(2)开发的接口人员
(3)BUG的优先级
(4)BUG的严重程度
(5)BUG可能属于的模块，如果不能确认，可以用开发人员来判断
(6)BUG标题，需要清晰的描述现象
(7)BUG描述，需要尽量给出重新Bug的步骤
(8)BUG附件中能给出相关的日志和截图。
高质量的BUG记录就是指很容易理解的BUG记录，所以，对于描述的要求高，能提供的信息多且准确，很好的帮助开发人员定位。
25、您以往所从事的软件测试工作中，是否使用了一些工具来进行软件缺陷（Bug）的管理？如果有，请结合该工具描述软件缺陷（Bug）跟踪管理的流程。
用BugZilla为例子
¨ 测试人员发现了BUG，提交到Bugzilla中，状态为new，BUG的接受者为开发接口人员
¨ 开发接口将BUG分配给相关的模块的开发人员，状态修改为已分配
¨ 开发人员和测试确认BUG，如果是本人的BUG，则设置为接收；如果是别的开发人员的问题，则转发出去，由下一个开发人员来进行此行为；如果认为不是问题，则需要大家讨论并确认后，拒绝这个BUG，然后测试人员关闭此问题。
¨ 如果开发人员接受了BUG，并修改好以后，将BUG状态修改为已修复，并告知测试在哪个版本中可以测试。
¨ 测试人员在新版本中测试，如果发现问题依然存在，则拒绝修改；如果已经修复，则关闭BUG。
26、你对测试最大的兴趣在哪里？为什么？
最大的兴趣就是测试有难度，有挑战性！做测试越久越能感觉到做好测试有多难。曾经在无忧测试网上看到一篇文章，是关于如何做好一名测试工程师。一共罗列了11，12点，有部分是和人的性格有关，有部分需要后天的努力。但除了性格有关的1，2点我没有把握，其他点我都很有信心做好它。
刚开始进入测试行业时，对测试的认识是从无忧测试网上了解到的一些资料，当时是冲着做测试需要很多技能才能做的好，虽然入门容易，但做好很难，比开发更难，虽然当时我很想做开发（学校专业课我基本上不缺席，因为我喜欢我的专业），但看到测试比开发更难更有挑战性，想做好测试的意志就更坚定了。
我觉得做测试整个过程中有2点让我觉得很有难度（对我来说，有难度的东西我就非常感兴趣），第一是测试用例的设计，因为测试的精华就在测试用例的设计上了，要在版本出来之前，把用例写好，用什么测试方法写？（也就是测试计划或测试策略），如果你刚测试一个新任务时，你得花一定的时间去消化业务需求和技术基础，业务需求很好理解（多和产品经理和开发人员沟通就能达到目的），而技术基础可就没那么简单了，这需要你自觉的学习能力，比如说网站吧，最基本的技术知识你要知道网站内部是怎么运作的的，后台是怎么响应用户请求的？测试环境如何搭建？这些都需要最早的学好。至少在开始测试之前能做好基本的准备，可能会遇到什么难题？需求细节是不是没有确定好？这些问题都能在设计用例的时候发现。
第二是发现BUG的时候了，这应该是测试人员最基本的任务了，一般按测试用例开始测试就能发现大部分的bug，还有一部分bug需要测试的过程中更了解所测版本的情况获得更多信息，补充测试用例，测试出bug。还有如何发现bug？这就需要在测试用例有效的情况下，通过细心和耐心去发现bug了，每个用例都有可能发现bug，每个地方都有可能出错，所以测试过程中思维要清晰（测试过程数据流及结果都得看仔细了，bug都在里面发现的）。如何描述bug也很有讲究，bug在什么情况下会产生，如果条件变化一点点，就不会有这个bug，以哪些最少的操作步骤就能重现这个bug，这个bug产生的规律是什么？如果你够厉害的话，可以帮开发人员初步定位问题。
27、你自认为测试的优势在哪里？
根据我自己以及周围的人对我的评价， 我认为我的优势主要表现在以下几个方面：
第一：工作认真、踏实、勤快、务实
第二，文笔较好，有一定的文案功底，这为撰写测试文档有很大帮助
第三，细心，不放过任何细节
第四，有耐心，能胜任重复性工作
第五， 责任心强，有集体观念，从不喜欢因个人原因而影响大局
28、当开发人员说不是BUG时，你如何应付？
如果确实是自己理解错误，则承认错误，没什么大不了
如果是需求不明，请项目经理补充清楚
如果双方理解不一致，且都不能互相说服，则请项目经理判断。
29、你为什么想离开目前的职务？
30、你对我们公司了解有多少？
31、你找工作时，最重要的考虑因素为何？
最重要的是公司的企业文化和管理机制能否给我提供一种归属感
其次是公司有没有发展前景，其业务和实力是否处于上升时期
再次是公司提供的职位是否与我对自己的职业定位是否一致
32、为什么我们应该录取你？为什么值得他们公司雇用？
因为年轻的我不仅可以为公司的发展带来新的活力，而且我的品质和素质都会为公司创造价值
33、请谈谈你个人的最大特色。
个人认为，我最大的特点或特色就是勤快。我不喜欢偷懒，更不喜欢耍滑头、推卸责任，我一向坚持实实在在做人、踏踏实实做事的原则，尽职尽责的完成任务，做自己该做的事情。从少年到青年，忙碌的生活让我过的很充实，我喜欢，我选择！
34、软件验收测试除了alpha,beta测试以外,还有哪一种?
第三方验收测试
35、为什么选择测试这行？
首先，这与我的专业有关。我本科和研究生阶段学的都是计算机专业，而且大部分时间都是侧重于软件知识的学习，这为我进入测试行业奠定了基础。
其次，与测试人员的职业寿命有关。软件测试从业人员的职业寿命比开发人员要长，不会像开发人员一样，到了一定年龄如果不转向管理层就会面临重新择业的尴尬境地。而且随着工作经验的积累，测试人员的身价有增无减，这是我投身测试行业的关键所在。
再次，与软件行业发展环境和社会需求有关。软件测试行业方兴未艾，软件测试在软件产品开发过程中得到重视，测试人员地位得到提高，这为我进入测试行业提供了动力。
36、如果我雇用你，你能给部门带来什么贡献？
软件测试对于提高软件产品的质量、缩短软件开发周期、降低产品开发成本低作用至关重要，如果我能加入贵公司测试团队，不仅能更加凸显软件测试的作用，而且在给公司带来新的活力的同时，我的品质和素质也都将是贵公司无形的财富。
37、您认为在测试人员同开发人员的沟通过程中，如何提高沟通的效率和改善沟通的效果？维持测试人员同开发团队中其他成员良好的人际关系的关键是什么？
(与开发人员如何进行有效的沟通的)
尽量能有面对面的沟通，如果做不到，那么尽量能直接通过电话沟通，如果只能通过Email等非及时沟通工具的话，强调必须对特性的理解深刻以及能表达清楚。
一是真诚，二是团队精神，三是在专业上有共同语言，当然也可以通过直接指出一些小问题，而不是进入BUG Tracking System来增加对方的好感。
38、在您以往的测试工作中，最让您感到不满意或者不堪回首的事情是什么？您是如何来对待这些事情的？
某次性能测试覆盖不足，造成系统崩溃。
39、在即将完成这次笔试前，您是否愿意谈一些自己在以往的学习和工作中获得的工作经验和心得体会？（可以包括软件测试、过程改进、软件开发或者与此无关的其他方面）
不管是在校学习还是在社会上参加工作，我们都应该对自己有一个清醒的认识，然后给自己确定一个符合现实的、切实可行的目标，然后严格要求自己，有计划、有步骤的实现自己的理想。三百六十行，行行出状元。给自己一个正确的定位，脚踏实地，坚持到底，我们就能成功。总结为十六个字：认识自我、挑战自我、成就自我、超越自我！
七、设计题
1、对下面给出的程序控制图，分别以各种不同的测试方法写出最少的测试用例
考官从办公室（面试现场）随意选取一个简单物品，假定是一个喝水的带广告图案的花纸杯，让应聘人对它设计出尽可能多的测试用例。
测试项目：杯子
需求测试:查看杯子使用说明书
界面测试:查看杯子外观
功能度：用水杯装水看漏不漏；水能不能被喝到
安全性：杯子有没有毒或细菌
可*性：杯子从不同高度落下的损坏程度
可移植性：杯子再不同的地方、温度等环境下是否都可以正常使用
兼容性：杯子是否能够容纳果汁、白水、酒精、汽油等
易用性：杯子是否烫手、是否有防滑措施、是否方便饮用
用户文档：使用手册是否对杯子的用法、限制、使用条件等有详细描述
疲劳测试：将杯子盛上水（案例一）放24小时检查泄漏时间和情况；盛上汽油（案例二）放24小时检查泄漏时间和情况等
压力测试：用根针并在针上面不断加重量，看压强多大时会穿透
跌落测试: 杯子加包装(有填充物),在多高的情况摔下不破损
震动测试: 杯子加包装(有填充物),六面震动,检查产品是否能应对恶劣的铁路\公路\航空运输
测试数据：
测试数据具体编写此处略（最讨厌写测试数据了）。其中应用到：场景法、等价类划分法、因果图法、错误推测法、边界值法等方法
期望输出：
该期望输出需查阅国标、行标以及使用用户的需求
说明书测试: 检查说明书书写准确性
给大家提三个产品:1.手机 2.电饭锅3.电梯
有兴趣的同学可以把答案写出来
2、在三角形计算中，要求三角型的三个边长：A、B和C。当三边不可能构成三角形时提示错误，可构成三角形时计算三角形周长。若是等腰三角形打印“等腰三角形”，若是等边三角形，则提示“等边三角形”。画出程序流程图、控制流程图、计算圈复杂度V(g)，找出基本测试路径。对此设计一个测试用例。
3、测试notepad的文件保存功能，就是file/save弹出对话框的功能，从那几个方面写测试用例，
4、用户输入一个整数.系统判断,并输出是负数还是非负数,请设计测试用例.
5、怎么测试ATM？
6、基于WEB信息管理系统测试时应考虑的因素有哪些？
7、写出完整的程序，求大于1且小于参数n的偶数的和，输出结果
八、补充题
常见的测试用例设计方法都有哪些？请分别以具体的例子来说明这些方法在测试用例设计工作中的应用。
等价类划分、边界值分析法、错误推测法、因果图方法、路径覆盖、功能图、正交试验设计法、场景设计方法
1 等价类划分
1.1 理论知识
等价类划分是一种典型的黑盒测试方法。这一方法完全不考虑程序的内部结构，只依据程序的规格说明来设计测试用例。
等价类是指某个输入域的子集合。在该子集合中，各个输入数据对于揭示程序中的错误都是等效的。
等价类合理地假设：某个等价类的代表值，与该等价类的其他值，对于测试来说是等价的。
因此，可以把全部的输入数据划分成若干的等价类，在每一个等价类中取一个数据来进行测试。这样就能以较少的具有代表性的数据进行测试，而取得较好的测试效果。
等价类划分是把所有可能的输入数据,即程序的输入域划分成若干部分（子集）,然后从每一个子集中选取少数具有代表性的数据作为测试用例.该方法是一种重要的,常用的黑盒测试用例设计方法.
1) 分类：
划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类.
有效等价类:是指对于程序的规格说明来说是合理的,有意义的输入数据构成的集合.利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能.
无效等价类:与有效等价类的定义恰巧相反.
设计测试用例时,要同时考虑这两种等价类.因为,软件不仅要能接收合理的数据,也要能经受意外的考验.这样的测试才能确保软件具有更高的可靠性.
2）划分等价类的方法:
下面给出六条确定等价类的原则：
①在输入条件规定了取值范围或值的个数的情况下,则可以确立一个有效等价类和两个无效等价类.
②在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下,可确立一个有效等价类和一个无效等价类.
③在输入条件是一个布尔量的情况下,可确定一个有效等价类和一个无效等价类.
④在规定了输入数据的一组值（假定n个）,并且程序要对每一个输入值分别处理的情况下,可确立n个有效等价类和一个无效等价类.
⑤在规定了输入数据必须遵守的规则的情况下,可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）.
⑥在确知已划分的等价类中各元素在程序处理中的方式不同的情况下,则应再将该等价类进一步的划分为更小的等价类.
3）原则：
设计测试用例:在确立了等价类后,可建立等价类表,列出所有划分出的等价类:
输入条件 有效等价类 无效等价类
... ... ...
... ... ...
然后从划分出的等价类中按以下三个原则设计测试用例:
① 为每一个等价类规定一个唯一的编号.
② 设计一个新的测试用例,使其尽可能多地覆盖尚未被覆盖地有效等价类,重复这一步.直到所有的有效等价类都被覆盖为止.
③ 设计一个新的测试用例,使其仅覆盖一个尚未被覆盖的无效等价类,重复这一步.直到所有的无效等价类都被覆盖为止.
之所以这么做，是因为程序中对于某一个错误输入的检查，往往会屏蔽对于其他错误输入的检查。因此，必须针对每一个无效等价类分别设计测试用例
1.2 实例
1、保险费率计算
人 人 保 险 公 司 承 担 人 寿 保 险 已 有 多 年 历 史 ， 该 公 司 保 费 计 算 方 式 为 投 保 额 ＊ 保 险 率 ， 保 险 率 又 依 点 数 不 同 而 有 别 ， 10 点 以 上 费 率 为 0.6 % ，10 点 以 下 费 率 为 0.1 % ：
输入数据说明
年龄 20～39岁6点
40～59岁4点
60岁以上20岁以下2点
性别 MALE 5点
FEMALE 3点
婚姻 已婚 3点
未婚 5点
扶养人数 一 人 扣 0.5 点 最 多 扣 3 点 （ 四 舍 五 入 取 整 数 ）
一、分 析 输 入 数 据 型 式 。
年 龄 ： 一 或 两 位 数 字 。
性 别 ： 以 英 文 「 Male 」 、 Female 」、「M 」 、 「F 」 表 示 。
婚 姻 ： 「 已 婚 」 、 「 未 婚 」 。
扶 养 人 数 ： 空 白 或 一 位 数 字 。
保 险 费 率 ：10 点 以 上 ， 10 点 以 下 。
二、 划 分 输 入 数 据
1.年龄 数字范围 1～99
等价类 20～39岁
40～59岁
60岁以上20岁以下
2.性别 类型 英文字之集合
等价类 类型：英文字
集合：「Male」、「M」
集合：「Female」、「F」
3.婚姻 等价类 已婚
未婚
4.扶养人数 选择项 扶养人数可以有，也可没有
范围 1～9
等价类 空白
1～6人
6人以上
5.保险费率 等价类 10点以上
10点以下
三、 设 计 输 入 数 据 。
有效等价类 无效等价类 无效等价类
1.年龄20 ～ 39 任 选 一 个
2.年龄40 ～ 59 任 选 一 个
3.年龄60 岁 以 上 、 20 岁 以 下 任 选 一 个 小 於1 ， 选 一 个 大 於 99 ， 选 一 个
4.性别 英 文Male, M, F, Female 任 选 一 个 非 英 文 字 如 「 男 」
5.性别 英 文Male, M 任 选 一 个 非Male, M, Female, F 之 任 意 字 元 ， 如 「 Child 」
6.性别 英 文Female, F 任 选 一 个 非Male, M, Female, F 之 任 意 字 符 ， 如 「 Child 」
7.婚姻 「 已 婚 」 非 「 已 婚 」 或 「 未 婚 」 之 任 意 字 符 ， 如 「 离 婚 」
8.婚姻 「 未 婚 」 非 「 已 婚 」 或 「 未 婚 」 之 任 意 字 符 ， 如 「 离 婚 」
9.扶养人数 空 白
10.扶养人数 1 ～ 6 小 於1 ， 选 一 个
11.扶养人数 7 ～ 9 大 於9 ， 选 一 个
12.保险费率 10 点 以 上(0.6 %)
13.保险费率 10 点 以 下(0.6 %)
四、 根据以上分析设计测试用例：
用例编号 年龄 性别 婚姻 扶养人数 保险费率 备注
1. 27 Female 未婚 空白 0.6% 有 效n 年 龄 ：20 ～ 39 岁 n 性 别 ： 集 合 「 Female, F 」n 婚 姻 ： 集 合 「 未 婚 」n 扶 养 人 数 ： 空 白n 保 险 费 率 ：0.6 %
2. 50 Male 已婚2 0.6% 有 效n 年 龄 ：40 ～ 59 岁 n 性 别 ： 集 合 「 Male, M 」n 婚 姻 ： 集 合 「 已 婚 」n 扶 养 人 数 ：1 ～ 6人
3. 70 F 未婚 7 0.1% 有 效n 年 龄 ：60 岁 以 上 或 20 岁 以 下n 性 别 ： 集 合 「 Female, F 」n 婚 姻 ： 集 合 「 未 婚 」n 扶 养 人 数 ：6 人 以 上
4. 0 M 已婚 4 无法推算 年 龄 类 无 效 ， 因 此 无 法 推 算 保 险 费 率
5. 100 Female 未婚5 无法推算 年 龄 类 无 效 ， 因 此 无 法 推 算 保 险 费 率
6. 1 男 已婚 6 无法推算 性 别 类 无 效 ， 因 此 无 法 推 算 保 险 费 率
7. 99 Child 未婚1 无法推算 性 别 类 无 效 ， 因 此 无 法 推 算 保 险 费 率
8. 30 Male 离婚3 无法推算 婚 姻 类 无 效 ， 因 此 无 法 推 算 保 险 费 率.
9. 75 Female 未婚0 无法推算 扶 养 人 数 类 无 效 ， 因 此 无 法 推 算 保 险 费 率
10. 17 Male 已婚10 无法推算 扶 养 人 数 类 无 效 ， 因 此 无 法 推 算 保 险 费 率
2 边界值分析法
2.1 理论知识
边界值分析方法是对等价类划分方法的补充，也是一种黑盒测试方法，适度等价类分析方法的一种补充,由长期的测试工作经验得知，大量的错误是发生在输入或输出的边界上。因此针对各种边界情况设计测试用例，可以查出更多的错误。
（1）边界值分析方法的考虑:
长期的测试工作经验告诉我们,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.
使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据.
（2）基于边界值分析方法选择测试用例的原则:
1）如果输入条件规定了值的范围,则应取刚达到这个范围的边界的值,以及刚刚超越这个范围边界的值作为测试输入数据.
2）如果输入条件规定了值的个数,则用最大个数,最小个数,比最小个数少一,比最大个数多一的数作为测试数据.
3）根据规格说明的每个输出条件,使用前面的原则1）.
4）根据规格说明的每个输出条件,应用前面的原则2）.
5）如果程序的规格说明给出的输入域或输出域是有序集合,则应选取集合的第一个元素和最后一个元素作为测试用例.
6）如果程序中使用了一个内部数据结构,则应当选择这个内部数据结构的边界上的值作为测试用例.
7）分析规格说明,找出其它可能的边界条件.
2.2 实例
找零钱最佳组合
假 设 商 店 货 品 价 格 (R) 皆 不 大 于 100 元 （ 且 为 整 数 ） ， 若 顾 客 付 款 在 100 元 内 (P) ， 求 找 给 顾 客 之 最 少 货币 个（张） 数 ？ （ 货 币 面 值 50 元(N50) ， 10 元 (N10) ，5 元 (N5) ， 1 元(N1) 四 种 ）
一、 分 析 输 入 的 情 形 。
R > 100
0 < R < = 100
R <= 0
P > 100
R<= P <= 100
P < R
二、 分 析 输 出 情 形 。
N50 = 1
N50 = 0
4 > N10 >= 1
N10 = 0
N5 = 1
N5 = 0
4 > N1 >= 1
N1 = 0
三、 分 析 规 格 中 每 一 决 策 点 之 情 形 ， 以 RR1, RR2, RR3 表 示 计 算 要 找 50, 10, 5 元 货 币 数 时 之 剩 余 金 额 。R > 100R <= 0
P > 100
P < R
RR1 >= 50
RR2 >= 10
RR3 >= 5
四、 由 上 述 之 输 入 ／ 输 出 条 件 组 合 出 可 能 的 情 形 。
R > 100
R <= 0
0 < R <= 100, P > 100
0 < R <= 100, P < R
0 < R <= 100, R <= P<= 100, RR = 50
0 < R <= 100, R <= P<= 100, RR = 49
0 < R <= 100, R <= P<= 100, RR = 10
0 < R <= 100, R <= P<= 100, RR = 9
0 < R <= 100, R <= P<= 100, RR = 5
0 < R <= 100, R <= P<= 100, RR = 4
0 < R <= 100, R <= P<= 100, RR = 1
0 < R <= 100, R <= P<= 100, RR = 0
五、 为 满 足 以 上 之 各 种 情 形 ， 测 试 资 料 设 计 如 下 ：
1. 货品价格 = 101
2. 货品价格 = 0
3.货品价格 = -1
4. 货品价格 = 100, 付款金额 = 101
5. 货品价格 = 100, 付款金额 = 99
6. 货品价格 = 50, 付款金额 = 100
7. 货品价格 = 51, 付款金额 = 100
8. 货品价格 = 90, 付款金额 = 100
9. 货品价格 = 91, 付款金额 = 100
10. 货品价格 = 95, 付款金额 = 100
11. 货品价格 = 96, 付款金额 = 100
12. 货品价格 = 99, 付款金额 = 100
13. 货品价格 = 100, 付款金额 = 100
3 错误推测法
1、定义：基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法.
2、错误推测方法的基本思想：列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例。
1) 例如,输入数据和输出数据为0的情况；输入表格为空格或输入表格只有一行。 这些都是容易发生错误的情况。可选择这些情况下的例子作为测试用例。
2) 例如，前面例子中成绩报告的程序，采用错误推测法还可补充设计一些测试用例：
I. 程序是否把空格作为回答
II. 在回答记录中混有标准答案记录
III. 除了标题记录外，还有一些的记录最后一个字符即不是2也不是3
IV. 有两个学生的学号相同
V. 试题数是负数。
3) 再如，测试一个对线性表（比如数组）进行排序的程序，可推测列出以下几项需要特别测试的情况：
I. 输入的线性表为空表；
II. 表中只含有一个元素；
III. 输入表中所有元素已排好序；
IV. 输入表已按逆序排好；
V. 输入表中部分或全部元素相同。
4 因果图方法
4.1 理论知识
前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图（逻辑模型）.
因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况.
利用因果图生成测试用例的基本步骤:
(1) 分析软件规格说明描述中, 那些是原因(即输入条件或输入条件的等价类),那些是结果(即输出条件), 并给每个原因和结果赋予一个标识符.
(2) 分析软件规格说明描述中的语义.找出原因与结果之间, 原因与原因之间对应的关系. 根据这些关系,画出因果图.
(3) 由于语法或环境限制, 有些原因与原因之间,原因与结果之间的组合情况不不可能出现. 为表明这些特殊情况, 在因果图上用一些记号表明约束或限制条件.
(4) 把因果图转换为判定表.
(5) 把判定表的每一列拿出来作为依据,设计测试用例.
从因果图生成的测试用例（局部,组合关系下的）包括了所有输入数据的取TRUE与取FALSE的情况,构成的测试用例数目达到最少,且测试用例数目随输入数据数目的增加而线性地增加.
前面因果图方法中已经用到了判定表.判定表（Decision Table）是分析和表达多逻辑条件下执行不同操作的情况下的工具.在程序设计发展的初期,判定表就已被当作编写程序的辅助工具了.由于它可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确.
判定表通常由四个部分组成.
条件桩（Condition Stub）:列出了问题得所有条件.通常认为列出得条件的次序无关紧要.
动作桩（Action Stub）:列出了问题规定可能采取的操作.这些操作的排列顺序没有约束.
条件项（Condition Entry）:列出针对它左列条件的取值.在所有可能情况下的真假值.
动作项（Action Entry）:列出在条件项的各种取值情况下应该采取的动作.
规则:任何一个条件组合的特定取值及其相应要执行的操作.在判定表中贯穿条件项和动作项的一列就是一条规则.显然,判定表中列出多少组条件取值,也就有多少条规则,既条件项和动作项有多少列.
判定表的建立步骤:（根据软件规格说明）
① 确定规则的个数.假如有n个条件.每个条件有两个取值（0,1）,故有 种规则.
② 列出所有的条件桩和动作桩.
③ ③填入条件项.
④ ④填入动作项.等到初始判定表.
⑤ ⑤简化.合并相似规则（相同动作）.
B. Beizer 指出了适合使用判定表设计测试用例的条件:
①规格说明以判定表形式给出,或很容易转换成判定表.
②条件的排列顺序不会也不影响执行哪些操作.
③规则的排列顺序不会也不影响执行哪些操作.
④每当某一规则的条件已经满足,并确定要执行的操作后,不必检验别的规则.
⑤如果某一规则得到满足要执行多个操作,这些操作的执行顺序无关紧要.
4.2 符号
4.3 实例
4.3.1 实例一
某软件规格说明中包含这样的要求：
第一列字符必须是A或B，第二列字符必须是一个数字，在此情况下进行文件的修改。但如果第一列字符不正确，则给出信息L;如果第二列字符不是数字，则给出信息M。
分开原因和结果
原因：1----第一列字符是A;
2----第一列字符是B;
3----第二列字符是一数字。
结果：21----修改文件;
22----给出信息L;
23----给出信息M。
4.3.2 实例二
此例子是讲解利用因果图设计测试用例的一个小例子。以中国象棋中走马的测试用例设计为例学习因果图的使用方法。
一、 分析中国象棋中走马的实际情况（下面未注明的均指的是对马的说明）
1、如果落点在棋盘外，则不移动棋子；2、如果落点与起点不构成日字型，则不移动棋子；3、如果落点处有自己方棋子，则不移动棋子；4、如果在落点方向的邻近交叉点有棋子（绊马腿），则不移动棋子；5、如果不属于1-4条，且落点处无棋子，则移动棋子；6、如果不属于1-4条，且落点处为对方棋子(非老将)，则移动棋子并除去对方棋子；7如果不属于1-4条，且落点处为对方老将，则移动棋子，并提示战胜对方，游戏结束。
二、 根据分析明确原因和结果
原因：
1、 落点在棋盘上；
2、 落点与起点构成日字；
3、 落点处为自己方棋子；
4、 落点方向的邻近交叉点无棋子；
5、 落点处无棋子；
6、 落点处为对方棋子（非老将）；
7、 落点处为对方老将。
结果：
21、不移动棋子；
22、移动棋子；
23、移动棋子，并除去对方棋子；
24、移动棋子，并提示战胜对方，结束游戏。
添加中间节点11，目的是作为导出结果的进一步原因，简化因果图导出的判定表
考虑结果不能同时发生，所以对其施加唯一约束O。原因5、6、7不能同时发生，所以对其施加异约束E.
三、 根据因果图建立判定表：(分为两表)
1 2 3 4 5 6 7 8 9 10 11 12 1314 15 16
原因 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1
2 0 0 1 1 0 0 1 1 0 0 1 1 0 01 1
3 0 0 0 0 1 1 1 1 0 0 0 0 1 11 1
4 0 0 0 0 0 0 0 0 1 1 1 1 1 11 1
结果 11 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0
21 1 1 1 1 1 1 1 0 1 1 1 1 1 11 1
用例
1 2 3 4 5 6 7 8 9 `0 11 12 1314 15 16
原因 11 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1
5 0 0 1 1 0 0 1 1 0 0 1 1 0 01 1
6 0 0 0 0 1 1 1 1 0 0 0 0 1 11 1
7 0 0 0 0 0 0 0 0 1 1 1 1 1 11 1
结果 22 0 0 1 00 0 0
23 0 0 0 0 1 0 0
24 0 0 0 0 0 0 1
用例
注：1、以上判定表中由于表格大小限制没有列出最后所选的测试用例；2、第2表中部分列被合并表示不可能发生的现象；3、通过中间节点将用例的判定表简化为两个小表。减少工作量。
四、根据判定表写测试用例表（略）
5 路径覆盖
熟悉测试理论的人都知道，路径覆盖是白盒测试中一种很重要的方法，广泛应用于单元测试。那么基于路径覆盖的分析方法是不是只能应用于单元测试呢，能不能将其推而广之呢。一般而言，在单元测试中，路径就是指函数代码的某个分支，而实际上如果我们将软件系统的某个流程也看成路径的话，我们将可以尝试着用路径分析的方法来设计测试用例。采用路径分析的方法设计测试用例有两点好处：一是降低了测试用例设计的难度，只要搞清了各种流程，就可以设计出高质量的测试用例来，而不用太多测试方面的经验；二是在测试时间较紧的情况下，可以有的放矢的选择测试用例，而不用完全根据经验来取舍。下面就具体的介绍一下如何用路径分析的方法编写测试用例。
首先是将系统运行过程中所涉及到的各种流程图表化，可以先从最基本的流程入手，将流程抽象成为不同功能的顺序执行。在最基本流程的基础上再去考虑次要或者异常的流程，这样将各种流程逐渐细化，这样既可以逐渐加深对流程的理解，还可以将各个看似孤立的流程关联起来。完成所有流程的图表化后就完成了所有路径的设定。
找出了所有的路径，下面的工作就是给每条路径设定优先级，这样在测试时就可以先测优先级高的，再测优先级低的，在时间紧迫的情况下甚至可以考虑忽略一些低优先级的路径。优先级根据两个原则来选取：一是路径使用的频率，使用越频繁的优先级越高；二是路径的重要程度，如果失败对系统影响越大的优先级越高。将根据两个原则所分别得到的优先级相加就得到了整个路径的优先级。根据优先级的排序就可以更有针对性的进行测试。
为每条路径设定好优先级后，接下来的工作就是为每条路径选取测试数据，构造测试用例。一条路径可以对应多个测试用例
，在选取测试数据时，可以充分利用边界值选取等方法，通过表格将各种测试数据的输入输出对应起来，这样就完成了测试用例的设计。
对于测试人员而言，测试用例的设计是一件非常困难的工作，而同时测试用例的设计好坏又直接关系到整个系统的设计质量。本文介绍了一种更理论化的设计方法来尽量简化这种工作，将一般应用于单元测试的路径分析方法推广到集成测试、系统测试等后续测试过程中，希望能给大家一点启示。
6 功能图
功能图方法是一种黑盒、白盒混合用例设计方法，是功能图FD形式化地表示程序的功能说明，并机器地生成功能图的测试用例。功能图模型由状态迁移图和逻辑功能模型构成。
状态迁移图用于表示输入数据序列以及相应的输出数据。在状态迁移图中，由输入数据和当前状态决定输出数据和后续状态。
逻辑功能模型用于表示在状态输入条件和输出条件之间的对应关系。逻辑功能模型只适合于描述静态说明，输出数据仅由输入数据决定。测试用例则由测试中的一系列状态和在每个状态中必须依靠输入/输出数据满足的一对条件组成。
（1）功能图：功能图由状态迁移图和布尔函数组成。状态迁移图用状态和迁移来描述。一个状态指出数据输入的位置（或时间），而迁移则指明状态的改变，同时要依靠判定表或是因果图表示的逻辑功能。例如，一个简化的自动出纳ATM机的功能图。
（2）测试用例生成方法：从功能图生成测试用例，得到的测试用例数是可以接受的。问题的关键是如何从状态迁移图中选取测试用例。若用节点代替状态，用弧线代替迁移，则状态迁移图就可转化成一个程序的控制流程图形式。问题就转化为程序的路径测试问题了。
（3）测试用例生成规则： 为了把状态迁移的测试用例与逻辑模型的测试用例相组合起来，从功能图生成生成实用的测试用例，需定义下面的规则。在一个结构化的迁移（SST）中，定义三种形式的循环：顺序、选择和重复。但分辨一个状态迁移中的所有循环是有困难的。
（4）从功能图生成测试用例的过程。
A、生成局部测试用例：在每个状态中，从因果图生成局部测试用例。局部测试用例由原因值（输入数据）组合与对应的结果值（输出数据或状态）构成。
B、测试路径生成：利用上面的规则（3种）生成从初始状态到最后状态的测试路径。
C、测试用例合成： 合成测试路径与功能图中每个状态的局部测试用例。结果是初始状态到最后状态的一个状态序列，以及每个状态中输入数据与对应输出数据的组合。
D、测试用例的合成算法：采用合成构造树。
7 正交试验设计法
7.1 理论知识
1、什么是因素（Factor在一项试验中，凡欲考察的变量称为因素（变量）
2、什么是水平（位级Level在试验范围内，因素被考察的值称为水平（变量的取值）
3、什么是正交试验设计
是研究多因素多水平的一种设计方法，它是根据正交性从全面试验中挑选出部分有代表性的点进行试验，这些有代表性的点具备了均匀分散，齐整可比的特点，正交试验
设计是一种基于正交表的、高效率、快速、经济的试验设计方法
4、正交表的构成 正交表的构成
行数(Runs)：正交表中的行的个数，即试验的次数
因素数(Factors)：正交表中列的个数。
水平数：任何单个因素能够取得的值的最大个数。
正交表中的包含的值为从最大个数。正交表中的包含的值为从0到数 到数“水平 水平数-1”或从 或从1到“水平数 水平数”。
正交表的表示形式： L行数 (水平数因素数)
正交表的正交性
整齐可比性
在同一张正交表中，每个因素的每个水平出现次数是完全相同的。由于在试验中每个因素的每个水平与其它因素的每个水平参与试验的机率是完全相同的，这就保证在各个水平中最大程度的排除了其它因素水平的干扰。因而，能最有效地进行比较和作出展望，容易找到好的试验条件进行。
均衡分散性
在同一张正交表中，任意两列（两个因素）的水平搭配（横向形成的数字对）是完全相同的。这样就保证了试验条件均衡地分散在因素水平的完全组合之中，因而具有很强的代表性，容易得到好的试验条件。
三、用正交表设计测试用例
用正交表设计测试用例的步骤
1 有哪些因素（变量）
2 每个因素有哪几个水平（变量的取值）
3 选择一个合适的正交表
4 把变量的值映射到表中
5 把每一行的各因素水平的组合做为一个测试用例
6 加上你认为可疑且没有在表中出现的组
如何选择正交表
考虑因素（变量）的个数
考虑因素水平（变量的取值）的个数
考虑正交表的行数
取行数最少的一个
设计测试用例时的三种情况
1 因素数（变量）、水平数（变量值）相符
2 因素数不相同
3 水平数不相同
因素数、水平数相符 因素数、水平数相符
水平数（变量的取值）相同、因素数（变量）刚好符合正交表。
7.2 实例
一、对某人进行查询
1、假设查询某个人时有三个查询条件：
根据“姓名”进行查询
根据“身份证号码”查询
根据“手机号码”查询
考虑查询条件要么不填写，要么填写，此时可用正交表进行设计
2、因素数和水平数
有三个因素：
姓名、身份证号、手机号码
每个因素有两个水平
姓名：填、不填
身份证号：填、不填
手机号码：填、不填
3、选择正交表
表中的因素数＞＝3
表中至少有三个因素的水平数＞＝2
行数取最少的一个结果：
4、变量映射
姓名：0....填写，1....不填写
身份证号：0....填写，1....不填写
手机号码：0....填写，1....不填写
5、用L4(23)设计的测试用例
测试用例如下：
1：填写姓名、填写身份证号、填写手机号
2：填写姓名、不填身份证号、不填手机号
3：不填姓名、填写身份证号、不填手机号
4：不填姓名、不填身份证号、填写手机号
增补测试用例
5：不填姓名、不填身份证号、不填手机号
测试用例减少数：8 5
6、因素数不相同
水平数（变量的取值）相同但在正交表中找不到相同的因素数（变量）（取因素数 （取因素数
最接近但略大的实际值的表）
8 场景设计方法
8.1 理论知识：
现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。这种在软件设计方面的思想也可以引入到软件测试中，可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，同时使测试用例更容易理解和执行。
基本流和备选流：如下图所示，图中经过用例的每条路径都用基本流和备选流来表示，直黑线表示基本流，是经过用例的最简单的路径。备选流用不同的色彩表示，一个备选流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中（如备选流1和3）；也可能起源于另一个备选流（如备选流2），或者终止用例而不再重新加入到某个流（如备选流2和4）。
8.2 实例
1. 例子描述
下图所示是ATM例子的流程示意图。
2.场景设计：下表所示是生成的场景。
表3-8 场景设计
场景1——成功提款 基本流
场景2——ATM内没有现金 基本流 备选流2
场景3——ATM内现金不足 基本流 备选流3
场景4——PIN有误（还有输入机会） 基本流 备选流4
场景5——PIN有误（不再有输入机会） 基本流 备选流4
场景6——账户不存在/账户类型有误 基本流 备选流5
场景7——账户余额不足 基本流 备选流6
注：为方便起见，备选流3和6（场景3和7）内的循环以及循环组合未纳入上表。
3.用例设计
对于这7个场景中的每一个场景都需要确定测试用例。可以采用矩阵或决策表来确定和管理测试用例。下面显示了一种通用格式，其中各行代表各个测试用例，而各列则代表测试用例的信息。本示例中，对于每个测试用例，存在一个测试用例ID、条件（或说明）、测试用例中涉及的所有数据元素（作为输入或已经存在于数据库中）以及预期结果。
表3-9 测试用例表
TC（测试用例）ID号 场景/条件PIN 账号 输入（或选择）的金额 账面金额 ATM内的金额 预期结果
CW1 场景1：成功提款 V V V V V 成功提款
CW2 场景2：ATM内没有现金 V V V V I 提款选项不可用，用例结束
CW3 场景3：ATM内现金不足 V V V V I 警告消息，返回基本流步骤6，输入金额
CW4 场景4：PIN有误（还有不止一次输入机会） I V n/a V V 警告消息，返回基本流步骤 4，输入PIN
CW5 场景4：PIN有误（还有一次输入机会） I V n/a V V 警告消息，返回基本流步骤 4，输入 PIN
CW6 场景4：PIN有误（不再有输入机会） I V n/a V V 警告消息，卡予保留，用例结束
4.数据设计
一旦确定了所有的测试用例，则应对这些用例进行复审和验证以确保其准确且适度，并取消多余或等效的测试用例。
测试用例一经认可，就可以确定实际数据值（在测试用例实施矩阵中）并且设定测试数据，如表3-10所示。
表3-10 测试用例表
TC（测试用例）ID号 场景/条件PIN 账号 输入（或选择）的金额（元）账面金额（元） ATM内的金额（元） 预期结果
CW1 场景1：成功提款 4987 809-498 50.00 500.00 2 000 成功提款。账户余额被更新为450.00
CW2 场景2：ATM内没有现金 4987 809-498 100.00 500.00 0.00 提款选项不可用，用例结束
CW3 场景3：ATM内现金不足 4987 809-498 100.00 500.00 70.00 警告消息，返回基本流步骤6，输入金额
CW4 场景4：PIN有误（还有不止一次输入机会） 4978 809-498 n/a 500.00 2 000 警告消息，返回基本流步骤4，输入PIN
CW5 场景4：PIN有误（还有一次输入机会） 4978 809-498 n/a 500.00 2 000 警告消息，返回基本流步骤4，输入PIN
CW6 场景4：PIN有误（不再有输入机会） 4978 809-498 n/a 500.00 2 000 警告消息，卡予保留，用例结束取行数最少的一个
附：测试生命周期，测试流程，测试过程，测试框架，测试策略的区别与联系
测试生命周期：
测试计划、测试设计、测试开发、测试执行、缺陷跟踪、测试评估
测试过程：
软件测试过程是软件开发的逆过程。按照测试的先后次序可分为4个步骤进行：
单元测试、集成测试、确认测试和系统测试，最后进行验收测试。
（1）单元测试：分别完成每个单元的测试任务，以确保每个模块能正常工作。单元测试大量地采用了白盒测试方法，尽可能发现模块内部的程序差错。
（2）集成测试：把已测试过的模块组装起来，进行集成测试。其目的在于检验与软件设计相关的程序结构问题。这时较多地采用黑盒测试方法来设计测试用例。
（3）确认测试：完成集成测试以后，要对开发工作初期制定的确认准则进行检验。确认测试是检验所开发的软件能否满足所有功能和性能需求的最后阶段，通常均采用黑盒测试方法。
（4）系统测试：完成确认测试以后，给出的应该是合格的软件产品，但为检验它能否与系统的其他部分（如硬件，数据库及操作人员）协调工作，需要进行系统测试。严格地说，系统测试已超出了软件工程的范围。
（5）验收测试：检验软件产品质量的最后一道工序是验收测试。与前面的各种测试活动的不同之处主要在于它突出了客户的作用，同时软件开发人员也应有一定程度的参与。
软件测试流程
需求调研 、 制定测试计划 、 需求Review 、 设计Review 、 测试设计 、开发测试工具和准备测试数据 、测试执行 、回归测试 、测试分析报告
测试框架：
测试框架是一个针对包含测试策略、测试管理、测试计划、测试方法等在内的总体性指导思想，也称之为方法论，用于指导项目测试和文档管理。它指明了如何开展测试活动 ，项目的测试流程，测试任务的分配，各项测试工作间的关联，应采用的测试方法和技术等。
框架中的测试策略指出在测试项目中所采用的测试方法，而测试计划的测试策略，则是根据这个项目制订的、要在这个项目中实施的测试方法
测试框架不是单纯的集合，而是一个指导思想
测试框架只有和一系列流程、标准、规范等搭配在一起，才能成为一个真正的测试体系策略是针对各个项目的，但是框架有更高的指导意义
测试策略
软件测试策略是为软件工程过程定义的一个软件测试的模板，也就是把特定的测试用例方法放置进去的一系列步骤。软件测试的策略、方法和技术是多种多样的。对于软件测试技术，可以从不同的角度加以分类：从是否需要执行被测软件的角度，可分为静态测试和动态测试。从测试是否针对系统的内部结构和具体实现算法的角度来看，可分为白盒测试和黑盒测试。其中主要的测试策略包括：①数据完整性测试②功能测试③易用性原则（用户界面的测试、优秀UI的7个组成要素、软件中的辅助特性）④性能测试⑤配置测试⑥兼容性测试⑦本地化测试
软件测试按照过程主要分为单元测试、集成测试、系统测试、验收测试四个阶段。
单元测试：主要用白盒测试方法，一般先静态地检查代码是否符合规范，然后动态地运行代码，检查其实际运行结果。对于单元测试，一般要求程序通过所有单元测试的用例，语句的覆盖率达到100%，分支的覆盖率达到85%。
集成测试：测试策略包括非渐增式测试和渐增式测试两种，前者是先分别测试每个模块，再把所有模块按设计要求放在一起结合成所要的程序；后者是把下一个要测试的模块同已经测试好的模块结合起来进行测试。其中渐增式测试又分为自顶向下集成和自底向上集成。集成测试重点测试不同模块的接口部分，采用黑盒和白盒相结合的测试方法。
系统测试：系统测试前期主要测试系统的功能是否满足要求，后期主要测试系统运行的性能是否满足需求。具体策略包括逻辑功能测试、界面测试、易用性测试、安装测试、兼容性测试、稳定性测试、负载测试和压力测试等。系统测试主要采用黑盒测试方法。
验收测试：测试策略主要包括正式验收测试、a测试和b测试。正式验收测试是一项管理严格的过程，它通常是系统测试的延续。α测试指的是由用户、测试人员、开发人员等共同参与的内部测试。β测试指的是内测后的公测，即完全交给最终用户测试。系统测试也主要采用黑盒测试方法。
从测试实际的前后过程来看，软件测试的过程是由一系列的不同测试阶段所组成，这些软件测试的步骤分为：需求分析审查、设计审查、单元测试、集成测试（组装测试）、功能测试、系统测试、验收测试、回归测试（维护）等。
总体来讲，在测试生命周期内，测试过程分测试计划、测试设计、测试执行、测试评估四个阶段：
测试计划：由测试经理或测试组长根据《需求规格说明书》或界面原型来编写测试计划，生成《测试计划》文档。
测试设计：在概要设计和详细设计阶段，由测试设计人员根据《需求规格说明书》或是界面原型来进行测试设计，主要包括编写测试用例、设计测试策略等，主要生成《测试用例》文档。
测试执行：在开发编码后期，有测试执行人员参考《需求规格说明书》和《测试用例》来对系统进行测试实施，这里面又包括了单元测试、集成测试、系统测试，主要生成大量的《缺陷报告》。
测试评估：在项目的后期，由测试经理或测试组长评估一下测试的过程和结果，为下一阶段或是下一个项目的测试积累一些经验和教训，一般生成一个《测试总结报告》。
22万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
