什么是软件测试 

软件测试是为了尽快尽早地发现在软件产品中所存在的各种软件缺陷而展开的贯穿整个软件开发生命周期、对软件产品（包括阶段性产品）进行验证和确认的活动过程。

主要有单元测试，集成测试，系统测试，Alpha测试，Beta测试。 

软件测试的分类 

1、  按测试方式分类： 

静态测试、动态测试 

静态测试不实际运行被测软件，直接分析软件的形式和结构查找缺陷，包括对源代码、程序界面和各类文档及中间产品。

动态测试是指需要实际运行被测软件，通过观察程序运行时所表现出来的状态、行为等发现软件缺陷      

2、  按测试方法分类：

白盒测试、黑盒测试 

白盒测试的依据是程序代码，研究源代码和程序内部的逻辑结构。

黑盒测试的依据是各阶段的需求规格说明，只考虑系统的输入和输出，完全不考虑程序内部  

3、  按测试过程分类：

单元测试、集成测试、确认测试、系统测试、验收测试   

4、  按测试目的分类： 

功能测试、健壮性测试、性能测试、强度测试、压力测试、接口测试、用户界面测试、安全测试、可靠性测试、安装/反安装测试、文档测试、恢复测试、兼容性测试

软件缺陷 

概念：

软件在生命周期各个阶段存在的一种不满足给定需求属性的问题 

满足以下条件的问题都叫缺陷： 

软件未达到产品说明书中已标明的功能 

软件出现了产品说明书中指明不会出现的错误 

软件功能超出了产品说明书指明的范围 

软件未达到产品说明书虽未指出但应达到的目标 

软件测试员认为软件难以理解，不易使用，运行速度缓慢，或者最终用户认为该软件使用效果不好。 

软件缺陷生命周期 

指的是一个软件缺陷被发现、报告到这个缺陷被修复、验证直至最后关闭的完整过程 

缺陷描述的基本要求：单一准确；可以再现；完整统一；短小简练；特定条件；补充完善 ；不做评价

测试的正向思维和逆向思维

正向思维－ 验证软件正常工作 ，在设计规定的环境下运行软件的所有功能，直至全部通过。

逆向思维－ 假定软件有错误，寻找容易犯错误的地方和系统的薄弱环节，试图破坏系统，直至找不出问题。 

 

软件测试与软件开发的关系（V模型）

 

软件测试与软件开发的关系（改进的V 模型）

软件测试类型都有哪些？不同的测试类型的区别与联系

  测试类型有：功能测试，性能测试，界面测试。 

  功能测试：在测试工作中占的比例最大，功能测试也叫黑盒测试。是把测试对象看作一个黑盒子。利用黑盒测试法进行动态测试时，需要测试软件产品的功能，不需测试软件产品的内部结构和处理过程。采用黑盒技术设计测试用例的方法有：等价类划分、边界值分析、错误推测、因果图和综合策略。 

  性能测试：是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。 

  界面测试：界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作，起到向导的作用。同时界面如同人的面孔，具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉，相反由于界面设计的失败，让用户有挫败感，再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。 

  区别在于：功能测试关注产品的所有功能上，要考虑到每个细节功能，每个可能存在的功能问题。性能测试主要关注于产品整体的多用户并发下的稳定性和健壮性。界面测试更关注于用户体验上，用户使用该产品的时候是否易用，是否易懂，是否规范（快捷键之类的），是否美观（能否吸引用户的注意力），是否安全（尽量在前台避免用户无意输入无效的数据，当然考虑到体验性，不能太粗鲁的弹出警告）？做某个性能测试的时候，首先它可能是个功能点，首先要保证它的功能是没问题的，然后再考虑该功能点的性能测试。

黑盒测试、白盒测试    

黑盒测试：

又称为功能测试或数据驱动测试，把程序看成一个黑盒子，完全不考虑程序的内部结构和处理程序，只是在程序的接口进行测试，以检查程序功能是否正常，程序是否能适当接收输入数据产生正确的输出数据。已知产品的功能设计规格，可以进行测试证明每个实现了的功能是否符合要求。 

白盒测试：

已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规格要求，所有内部成分是否以经过检查。

	白盒测试	黑盒测试
测试依据	程序内部结构	软件规格说明
优点	能对程序内部的特定部位进行覆盖	能站在用户立场上进行测试
缺点	（1）无法检测程序本身逻辑错误 （2）无法对未实现规格说明的程序部分进行测试	（1）不能测试程序内部特定部位 （2）发现不了规格说明错误或程序超出规格说明的行为

白盒测试方法

总体上分为静态方法和动态方法两大类。 

静态：

关键功能是检查软件的表示和描述是否一致,没有冲突或者没有歧义 

动态： （发现错误的能力呈由弱至强的变化）

语句覆盖

判定覆盖

条件覆盖

判定/条件覆盖

条件组合覆盖

路径覆盖

语句覆盖每条语句至少执行一次。

判定覆盖每个判定的每个分支至少执行一次。

条件覆盖每个判定的每个条件应取到各种可能的值。

判定/条件覆盖同时满足判定覆盖条件覆盖。

条件组合覆盖每个判定中各条件的每一种组合至少出现一次。

路径覆盖使程序中每一条可能的路径至少执行一次。

黑盒测试方法

等价类划分法，边界值法，判定表法: 

·条件桩，列出问题的所有条件 

·动作桩：列出可能针对问题所采取的操作 

·条件项：针对所列条件的具体赋值 

·动作项：列出在条件项（各种取值）组合情况下应该采取的动作。 

·规则：任何一个条件组合的特定取值及其相应要执行的操作。

黑盒测试的测试用例设计方法  

〃等价类划分方法 

〃边界值分析方法 

〃错误推测方法 

〃因果图方法 

〃判定表驱动分析方法 

〃正交实验设计方法 

〃功能图分析方法

等价类划分方法  

含义： 

在很多时候，某些数据输入后得到的输出结果是相同或者相似的，而与其他一些数据输入后的到的结果不相近，从而我们可以把输入数据划分成若干个集合，称之为有效等价类。从每一个集合中选取代表性的数据作为测试用例使用数据，从而减少了输入数据量提高了效率。 

有效等价类

合理的、有意义的输入数据构成的集合。 检验程序是否实现了规格说明中所规定的功能和性能

无效等价类

不合理的或无意义的输入数据所构成的集合。确保软件具有更高的可靠性 

划分集合的方法有： 

1）在限定取值范围或个数时，可以划分一个有效等价类和两个无效等价类； 

2）在规定了输入值集合或必须是“XX类型”时，可以划分一个有效等价类和一个无效等价类； 

3）在输入值为布尔类型时，可以划分一个有效等价类和一个无效等价类； 

4）在输入一组（n个）值且伴有判断情况（m种）时，可划分n或m个有效等价类和一个无效等价类； 

5）在输入规定正则表达式时，可以划分一个有效等价类和若干个无效等价类；  

边界值分析方法  

含义： 

边界值分析方法是等价类划分方法的有力补充。由于在后者输入中，我们选择的是一些代表性的数据而不是全部数据进行输入，所以难免会有些会引起错误的特殊数据未被选择。由于这类数据往往集中在各个划分好的等价类的边界值附近，所以称之为边界值分析法。而且，在这种方法中，不单要考虑输入域也要考虑输出域。  

选值方法： 

一般原则是应当选择刚好等于，稍微大于和小于边界值的值进行测试。 

1）当输入域为一个值的范围时，选择范围的边界值和略微超越边界值的值； 

2）当输入域规定了值的个数时，选择max，max＋1，min，min－1； 

3）当输出域判断为一个值的范围时，使用1）方法； 

4）当输出域判断为限定个数的值时，使用2）方法； 

5）当输入输出域判断依据一个有序列时，选择有序列的第一个和最后一个元素；

6）当输入输出域判断依据一个内部数据结构时，使用改数据结构的边界值； 

7）除了规定的范围，考虑会存在的其他未明示的可能；  

错误推测方法 

含义： 

依靠经验和直觉猜测程序中可能存在的各种错误，从而有针对性地编写检查这些故障的测试用例。

设计测试用例： 

按照会发生错误的情况去书写测试用例，这样就能主动监测那些容易出错的点。  

因果图方法  

含义： 

仅仅将值输入，是不断验证单个数据的情况。有时候，我们需要将各个数据联系在一起考虑，从而引申出多种组合，这时候有些单个数据完好的功能就可能出现错误。组合数据，主要就是根据他们之间的逻辑关系，使用同一组数据搭配不同的线路，来测试不同的路径。  

设计测试用例： 

第一步，分析软件说明，将输入和输出分别列出，并赋予一个唯一的标志符； 

第二步，分析语义和设计，将输入和输出之间的对应关系和各自之间的联系列出来，画出因果图； 

第三步，根据逻辑分析，从因果图中将不可能出现的情况移除；添加约束和限定条件； 

第四步，将因果图转换为判定表； 

第五步，根据判定表的每一列，设计一个新用例。  

说明： 

从因果图生成测试用例，包括了所有输入数据的取false和取true的情况，生成的测试用例数目达到最少。测试用例的数目是随着输入数据量的增加而增加。

  

判定表驱动分析方法  

含义： 

因果图可以生成判定表，但是也可以直接使用判定表。判定表（Decision Table）是列举和分析复合逻辑条件下多个路径的工具。主要是通过一个二维表格一目了然的将负责的逻辑结构和多种条件组合的情况表达出来。  

组成： 

条件桩（Condition Stub），列出所有条件。通常认为条件的次序是无关的。 

动作桩（Action Stub），列出所有可能采取的动作，这些操作是没有次序约束的。 

条件项（Condition Entry），列出针对它左列条件的取值。在所有可能情况下的真假值。 

动作项（Action Entry），列出在条件项的各种取值情况下应该采取的动作。 

什么是测试用例 

测试用例可以独立进行测试执行的最小单元 

良好测试用例的特征 

·可以最大程度地找出软件隐藏的缺陷 

·可以最高效率的找出软件缺陷 

·可以最大程度地满足测试覆盖要求 

·既不过分复杂、也不能过分简单 

·使软件缺陷的表现可以清楚的判定 

·测试用例包含期望的正确的结果 

·待查的输出结果或文件必须尽量简单明了 

·不包含重复的测试用例 

·测试用例内容清晰、格式一致、分类组织 

您认为做好测试用例设计工作的关键是什么？ 

白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果 

黑盒测试用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。不可能做到完全测试，以最少的用例在合理的时间内发现最多的问题 

测试用例5大要素：

测试目标、测试坏境、输入数据、步骤、预期结果 

测试用例设计基本原则：

1）测试用例的代表性   

2）测试结果的可判断性 

3）测试结果的可再现性 

一个好的测试用例，应该包含以下信息：

1） 软件或项目的名称

2） 软件或项目的版本（内部版本号）

3） 功能模块名

4） 测试用例的简单描述，即该用例执行的目的或方法

5） 测试用例的参考信息（便于跟踪和参考）

6） 本测试用例与其他测试用例间的依赖关系

7） 本用例的前置条件，即执行本用例必须要满足的条件，如对数据库的访问权限

8） 用例的编号（ID），如可以是 软件名称简写-功能块简写-NO.。

9） 步骤号、操作步骤描述、测试数据描述

10）预期结果（这是最重要的）和实际结果（如果有BUG管理工具，这条可以省略）

11）开发人员（必须有）和测试人员（可有可无）

12）测试执行日期

什么是单元测试

对软件基本组成单元进行测试，主要是为了发现单元内部可能存在的各种错误和不足

主要工作分为两个步骤：人工静态检查和动态执行跟踪

一般由开发组在开发组组长监督下进行

什么是单元?

一个函数

类或类内成员函数

几个函数的集合

常见的单元测试工具 

a. 在Eclipse中JUnit应用举例 

b. Junit+Ant构建自动的单元测试 

c. CheckStyle/PMD与FindBug的使用 

 

驱动程序和桩程序 

驱动模块（drive）:对底层或子层模块进行测试所编写的调用这些模块的程序。 

桩模块（stub）：对顶层或上层模块进行测试时所编写的替代下层模块的程序。 

什么是集成测试

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

简述集成测试的过程 

系统集成测试主要包括以下过程： 

1.构建的确认过程。

2.补丁的确认过程。

3.系统集成测试测试组提交过程。 

4.测试用例设计过程。 

5.测试代码编写过程。 

6. Bug的报告过程。 

7.每周/每两周的构建过程。 

8.点对点的测试过程。 

9.组内培训过程。

单元测试与集成测试区别

测试对象：      单元测试－实现具体功能的单元。

集成测试－－概要设计所包含的模块以及模块组合

测试方法：      单元测试－基于代码的白盒测试。

　　　　　　   集成测试－－基于功能的黑盒测试。

测试时间：      集成测试要晚于单元测试。

测试内容：      单元测试－－模块内程序的逻辑等方面

　　　            集成测试－－验证各个接口、接口之间的数据传递关系、模块组合后能否达到预期效果。

集成方法

大爆炸集成Big bang integration (all  module together)

大爆炸集成是把所有通过单元测试的模块一次性集成到一起进行测试，不考虑组件之间的互相依赖性及可能存在的风险。

自顶向下集成Top down integration (from higher levels à no test drivers are needed)

自顶向下的集成测试就是按照系统层次结构图，从顶层控制（主控模块）开始，自上而下按照深度优先或者广度优先策略，对各个模块一边组装一边进行测试。

采用同设计顺序一样的思路对被测系统进行测试，来验证系统的稳定性。

自底向上集成Bottom up integration (from lower levelsà No test stubs necessary)

自底向上集成是从系统层次结构图的最底层模块开始按照层次结构图，逐层向上进行组装和集成测试的方式。

三明治集成Sandwich testing (combination of bottom-up and top-down)

三明治集成是一种混合增殖式测试策略，综合了自顶向下和自底向上两种集成方法，把系统划分成三层，中间一层为目标层，目标层上采用自顶向下集成，目标层下采用自底向上集成。

什么是系统测试

在实际运行环境下，对集成好的软件系统进行的一系列测试活动。

系统测试的目的

通过与系统的需求定义比较，检查软件是否存在与系统定义不符合或与之矛盾的地方，以验证软件系统的功能和性能等满足其规约所指定的要求。

系统测试的方法有：

功能测试，性能测试，可靠性测试，负载测试，易用性测试，强度测试，安全测试，配臵测试，安装测试，卸载测试，文挡测试，故障恢复测试，界面测试，容量测试，兼容性测试，分布测试，可用性测试。

性能测试

性能测试类型包括负载测试，强度测试，容量测试等 

负载测试：负载测试是一种性能测试指数据在超负荷环境中运行，程序是否能够承担。   

强度测试： 强度测试是一种性能测试，他在系统资源特别低的情况下软件系统运行情况   

容量测试：确定系统可处理同时在线的最大用户数  

在网站流量逐渐加大的情况下，开始考虑做性能测试了，首先要写好性能测试计划，根据运营数据得出流量最大的页面（如果是第一次的话，一般是首页，下载页，个人帐户页流量最大，而且以某种百分比），  Web服务器指标指标： 

* Avg Rps: 平均每秒钟响应次数＝总请求时间 / 秒数；  

* Successful Rounds：成功的请求；   

* Failed Rounds ：失败的请求； 

* Successful Hits ：成功的点击次数；   

* Failed Hits ：失败的点击次数；   

* Hits Per Second ：每秒点击次数；  

* Successful Hits Per Second ：每秒成功的点击次数；  

* Failed Hits Per Second ：每秒失败的点击次数；   

* Attempted Connections ：尝试链接数；

性能测试的主要类别：

并发性能测试、压力测试、强度测试、负载测试、疲劳测试、大数据量测试、容量测试、破坏性测试 性能测试的加压方式： 

        1）并发（并发用户操作下，不断增加并发用户数量） 

        2）疲劳（系统稳定运行的情况下能够支持的最大并发用户数，持续执行一段时间业务） 

        3）容量（系统可处理同时在线的最大用户数） 

性能测试的监控指标：

响应时间、吞吐量、CPU使用率，内存占用率

软件验收测试包括：

正式验收测试，alpha测试，beta测试。

α测试是指软件开发公司组织内部人员模拟各类用户行对即将面市软件产品（称为α版本）进行测试

β测试是指软件开发公司组织各方面的典型用户在日常工作中实际使用β版本，并要求用户报告异常情况、提出批评意见。然后软件开发公司再对β版本进行改错和完善。

用户界面的7个要素:

 符合标准和规范。

 直观性。

 一致性。

 灵活性。

 舒适性。

 正确性。

 实用性。

UI 检查表

设计系统测试计划需要参考的项目文挡有：

软件测试计划，软件需求工件和迭代计划。

Alpha测试与beta的区别 

Alpha测试在系统开发接近完成时对应用系统的测试；测试后仍然会有少量的设计变更。这种测试一般由最终用户或其它人员完成，不能由程序或测试员完成。 

Beta测试当开发和测试根本完成时所做的测试，最终的错误和问题需要在最终发行前找到。这种测试一般由最终用户或其它人员完成，不能由程序员或测试员完成。

比较负载测试，容量测试和强度测试的区别 

负载测试：在一定的工作负荷下，系统的负荷及响应时间。 

强度测试：在一定的负荷条件下，在较长时间跨度内的系统连续运行给系统性能所造成的影响。 

容量测试：容量测试目的是通过测试预先分 析出反映软件 系统应用特征的某项指标的极限值（如最大并发用户数、数据库记录数等），系统在其极限值状态下没有出现任何软件故障或还能保持主要功能正常运行。容量测试 还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。容量测试的目的是使系统承受超额的数据容量来发现它是否能够正确处理。容量测试是面向数据 的，并且它的目的是显示系统可以处理目标内确定的数据容量。 

测试结束的标准是什么？ 

用例全部测试。 

覆盖率达到标准。

缺陷率达到标准。 

其他指标达到质量标准 

描述软件测试活动的生命周期

测试周期分为计划、设计、实现、执行、总结。其中： 

计划：对整个测试周期中所有活动进行规划，估计工作量、风险，安排人力物力资源，安排进度等； 

设计：完成测试方案，从技术层面上对测试进行规划； 

实现：进行测试用例和测试规程设计； 

执行：根据前期完成的计划、方案、用例、规程等文档，执行测试用例。 

总结：记录测试结果，进行测试分析，完成测试报告。

什么是“测试案例”?  

测试案例是一份文档，它描述了一个输入、反应、或者是与其相应的预期的响应，以便来判断应用软件的工作是否正常。测试案例应当包括测试标识、测试案例的名称、目标、测试条件/设臵、输入数据要求、步骤、以及预期的结果。

测试的规律----木桶原理和二八原则  

（1）木桶原理 

  在软件产品生产方面就是全面质量管理(TQM)的概念。产品质量的关键因素是分析、设计和实现，测试应该是融于其中的补充检查手段，其他管理、支持、甚至文化因素也会影响最终产品的质量。应该说，测试是提高产品质量的必要条件，也是提高产品质量最直接、最快捷的手段，但决不是一种根本手段。反过来说，如果将提高产品质量的砝码全部押在测试上，那将是一个恐怖而漫长的灾难。  

（2）Bug的80-20原则。 

  实践证明。80%的bug往往隐含在20%的软件区域。所以一旦在某处发现了bug，多找找周围。这也是有经验的测试员的一种方式。  

   一般情况下，在分析、设计、实现阶段的复审和测试工作能够发现和避免80%的Bug，而系统测试又能找出其余Bug中的80%，最后的5%的Bug可能只有在用户的大范围、长时间使用后才会曝露出来。因为测试只能够保证尽可能多地发现错误，无法保证能够发现所有的错误。

一条软件缺陷（或者叫Bug）记录都包含了哪些内容？

1. 和BUG产生对应的软件版本   

2. 开发的接口人员   

3. BUG的优先级 

4. BUG的严重程度 

5. BUG可能属于的模块，如果不能确认，可以用开发人员来判断   

6. BUG标题，需要清晰的描述现象 

7. BUG描述，需要尽量给出重新Bug的步骤 

功能测试概念 

功能测试是基于产品功能说明书，已知产品所具有的功能，从用户角度来进行功能验证，以确认每个功能是否都能正常使用  

回归测试概念 

回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。  

概念： 

① 负载测试（Load Testing）一种性能测试，用于在测试的系统保持不变的情况下，核实和评估系统在不同负载下操作极限的可接受性。 评测包括负载和响应时间的特征。如果系统结合了分布式构架或负载平衡方法，将执行特殊的测试以确保分布和负载平衡方法能够正常工作。 

② 压力测试(Stress test)，也称为强度测试、负载测试。压力测试是模拟实际应用的软硬件环境及用户使用过程的系统负荷，长时间或超大负荷地运行测试软件，来测试被测系统的性能、可靠性、稳定性等。 

③ 容量测试，容量测试目的是通过测试预先分析出反映软件系统应用特征的某项指标的极限值（如最大并发用户数、数据库记录数等），系统在其极限值状态下还能保持主要功能正常运行。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。 

④ 可靠性（Reliability），是产品在规定的条件下和规定的时间内完成规定功能的能力，它的概率度量称为可靠度。软件可靠性是软件系统的固有特性之一，它表明了一个软件系统按照用户的要求和设计的目标，执行其功能的可靠程度。软件可靠性与软件缺陷有关，也与系统输入和系统使用有关。理论上说，可靠的软件系统应该是正确、完整、一致和健壮的。  

⑤ 容错性测试，容错测试一般是输入异常数据或进行异常操作，以检验系统的保护性。如果系统的容错性好的话，系统会给出提示或内部消化掉，而不会导致系统出错甚至崩溃。 

Web安全性测试概念 

XSS，指的是恶意攻击者往Web页面里插入恶意html代码，当用户浏览该页之时，嵌入其中Web里面的html代码会被执行，从而达到恶意用户的特殊目的。 

SQL注入，程序员在编写代码的时候，没有对用户输入数据的合法性进行判断，使应用程序存在安全隐患。用户可以提交一段数据库查询代码，根据程序返回的结果，获得某些他想得知的数据，这就是所谓的SQL Injection，即ＳＱＬ注入  

自动化测试 

自动化测试的概念，自动化测试（automated test）是相对手工测试（manual test）而存在的一个概念，由手工逐个地运行测试用例的操作过程被测试工具自动执行的过程所代替。 

自动化和手工测试的区别 

自动运行的速度快，是手工无法相比的。 

测试结果准确，例如搜索用时是0.33秒或0.24秒，系统都会发现问题，不会忽视任何差异。 

高复用性，一旦完成所用的测试脚本，可以一劳永逸运行很多遍。 

永不疲劳  可靠  

独特的能力  

脚本的分类  

线性脚本，是录制手工执行的测试用例得到的脚本，所有录制的测试用例都可以得到完整的回放。 

构化脚本，类似于结构化程序设计，具有各种逻辑结构、函数调用功能。  

关键字驱动脚本：Keyword-Driven   封装各种基本操作，每个操作由函数实现  脚本编写效率高，维护方便 结构简单，易上手

数据驱动脚本： Data Driven 将测试输入存储在独立的（数据）文件中，而不是存储在脚本中  脚本中引入变量使用数据 

 

测试脚本概念

测试工具执行的指令的结合，程序。 

对面向过程的系统采用的集成策略有：

自顶向下，自底向上两种。

自顶向下法的主要优缺点 

优点 

不需要写测试驱动程序 

能在测试阶段的早期发现并验证系统的主要功能，发现上层模块的接口错误 

缺点： 

需要stub程序 

底层关键模块的错误发现较晚 

早期不能充分展开人力 

自底向上法的主要优缺点 

优点 

任意的叶子级构件一准备好，就可以开始自底向上集成和测试 

各子树的集成和测试工作可以并发的进行 

缺点 

需要写测试驱动程序，消耗很大 

不能轻易对先前测试过的构件进行修改 

类测试充分性的三个常用标准是：

基于状态的覆盖率，以测试覆盖了多少个状态转换为依据 。

基于约束的覆盖率，根据有多少对前置条件和后置条件被覆盖来表示充分性。

基于代码的覆盖率。当所有的测试用例都执行结束时，确定实现一个类的每一行代码或代码通过的每一条路径至少执行了一次

您认为做好测试计划工作的关键是什么？  

1. 明确测试的目标，增强测试计划的实用性 

  编写软件测试计划得重要目的就是使测试过程能够发现更多的软件缺陷。因此，软件测试计划中的测试范围必须高度覆盖功能需求，测试方法必须切实可行，测试工具并且具有较高的实用性，便于使用，生成的测试结果直观、准确   

2．坚持“5W”规则，明确内容与过程 

  “5W”规则指的是“What（做什么）”、“Why（为什么做）”、“When（何时做）”、“Where（在哪里）”、“How（如何做）”。

3．采用评审和更新机制，保证测试计划满足实际需求 

    测试计划写作完成后，如果没有经过评审，直接发送给测试团队，测试计划内容的可能不准确或遗漏测试内容，或者软件需求变更引起测试范围的增减，而测试计划的内容没有及时更新，误导测试执行人员。 

4. 分别创建测试计划与测试详细规格、测试用例 

  应把详细的测试技术指标包含到独立创建的测试详细规格文档，把用于指导测试小组执行测试过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中。测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配臵，而测试详细规格、测试用例是完成测试任务的具体战术。 

软件测试常识

测试是不完全的（测试不完全）

测试具有免疫性（软件缺陷免疫性）

测试是 “ 泛型概念 ” （全程测试）

80-20 原则

为效益而测试

缺陷的必然性

软件测试必须有预期结果

软件测试的意义 - 事后分析