回归测试: (regression   testing): 回归测试有两类：用例回归和错误回归；用例回归是过一段时间以后再回头对以前使用过的用例在重新进行测试，看看会重新发现问题。错误回归，就是在新版本中，对以前版本中出现并修复的缺陷进行再次验证，并以缺陷为核心，对相关修改的部分进行测试的方法。

已知产品的功能设计规格，可以进行测试证明每个实现了的功能是否符合要求。 　也叫功能测试，是把测试对象看作一个黑盒子。利用黑盒测试法进行动态测试时，需要测试软件产品的功能，不需测试软件产品的内部结构和处理过程。采用黑盒技术设计测试用例的方法有：等价类划分、边界值分析、错误推测、因果图和综合策略。 

已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规格要求，所有内部成分是否以经过检查。　　黑盒测试又叫功能测试或数据驱动测试。黑盒测试主要是为了发现以下几类错误： 　　1、是否有不正确或遗漏的功能？ 　　2、在接口上，输入是否能正确的接受？能否输出正确的结果？ 　　3、是否有数据结构错误或外部信息（例如数据文件）访问错误？ 　　4、性能上是否能够满足要求？ 　　5、是否有初始化或终止性错误？ 　　白盒测试又称为结构测试或逻辑驱动测试。白盒测试主要是想对程序模块进行如下检查： 　　1、对程序模块的所有独立的执行路径至少测试一遍。 　　2、对所有的逻辑判定，取“真”与取“假”的两种情况都能至少测一遍。 　　3、在循环的边界和运行的界限内执行循环体。 　　4、测试内部数据结构的有效性，等等。

黑盒测试的优点有：比较简单，不需要了解程序内部的代码及实现；与软件的内部实现无关；  从用户角度出发，能很容易的知道用户会用到哪些功能，会遇到哪些问题；基于软件开发文档，所以也能知道软件实现了文档中的哪些功能；在做软件自动化测试时较为方便。

黑盒测试的缺点有：不可能覆盖所有的代码，覆盖率较低，大概只能达到总代码量的30%；自动化测试的复用性较低。

白盒测试的优点有：帮助软件测试人员增大代码的覆盖率，提高代码的质量，发现代码中隐    藏的问题。

白盒测试的缺点有：程序运行会有很多不同的路径，不可能测试所有的运行路径；测试基于代码，只能测试开发人员做的对不对，而不能知道设计的正确与否，可能会漏掉一些功能需求；系统庞大时，测试开销会非常大。

是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为。　　单元测试是由程序员自己来完成，最终受益的也是程序员自己。可以这么说，程序员有责任编写功能代码，同时也就有责任为自己的代码编写单元测试。执行单元测试，就是为了证明这段代码的行为和我们期望的一致。 　内容包括 模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试

  策略包括逻辑覆盖、循环覆盖、同行评审、桌前检查、代码走查、代码评审、景泰数据流分析

　　单元测试策略主要有三种方式：

1) 自顶向下的单元测试策略：从顶层调用的单元做成桩模块; 对第二层测试，使用上面已测试的单元做驱动模块; 依次类推，直到全部单元测试结束。(比孤立单元测试的成本高很多)

2) 自底向上的单元测试策略：先对模块调用的最底层模块进行测试，模拟调用该模块的模块为驱动模块; 其次，对上一层模块进行单元测试，用已经被测试过的模块做桩模块，依次类推，直到全部单元测试结束。(比较合理的单元测试策略，但测试周期较长)

3) 孤立测试的单元测试策略：无需考虑每个模块与其他模块之间的关系，分别为每个模块单独设计桩模块和驱动模块，逐一完成所有单元模块的测试。(最好的单元测试策略)

单元测试大多数由开发人员来完成，测试人员技术背景较好或者开发系统软件时可能会安排测试人员进行单元测试，大多数进行的单元测试都是开发人员调试程序或者开发组系统联合调试的过程。讨论这个问题主要是扩充一下读者的视野。

单元测试一般包括五个方面的测试：

模块接口测试

模块接口测试是单元测试的基础。只有在数据能正确流入、流出模块的前提下，其他测试才有意义。模块接口测试也是集成测试的重点，这里进行的测试主要是为后面打好基础。测试接口正确与否应该考虑下列因素：

-输入的实际参数与形式参数的个数是否相同；

-输入的实际参数与形式参数的属性是否匹配；

-输入的实际参数与形式参数的量纲是否一致；

-调用其他模块时所给实际参数的个数是否与被调模块的形参个数相同；

-调用其他模块时所给实际参数的属性是否与被调模块的形参属性匹配；

-调用其他模块时所给实际参数的量纲是否与被调模块的形参量纲一致；

-调用预定义函数时所用参数的个数、属性和次序是否正确；

-是否存在与当前入口点无关的参数引用；

-是否修改了只读型参数；

-对全程变量的定义各模块是否一致；

-是否把某些约束作为参数传递。

如果模块功能包括外部输入输出，还应该考虑下列因素：

-文件属性是否正确；

-OPEN/CLOSE语句是否正确；

-格式说明与输入输出语句是否匹配；

-缓冲区大小与记录长度是否匹配；

-文件使用前是否已经打开；

-是否处理了文件尾；

-是否处理了输入/输出错误；

-输出信息中是否有文字性错误。

-局部数据结构测试；

-边界条件测试；

-模块中所有独立执行通路测试；

局部数据结构测试

检查局部数据结构是为了保证临时存储在模块内的数据在程序执行过程中完整、正确，局部功能是整个功能运行的基础。重点是一些函数是否正确执行，内部是否运行正确。局部数据结构往往是错误的根源，应仔细设计测试用例，力求发现下面几类错误：

-不合适或不相容的类型说明；

-变量无初值；

-变量初始化或省缺值有错；

-不正确的变量名（拼错或不正确地截断）；

-出现上溢、下溢和地址异常。

边界条件测试

边界条件测试是单元测试中最重要的一项任务。众所周知，软件经常在边界上失效，采用边界值分析技术，针对边界值及其左、右设计测试用例，很有可能发现新的错误。边界条件测试是一项基础测试，也是后面系统测试中的功能测试的重点，边界测试执行的较好，可以大大提高程序健壮性。

模块中所有独立路径测试

在模块中应对每一条独立执行路径进行测试，单元测试的基本任务是保证模块中每条语句至少执行一次。测试目的主要是为了发现因错误计算、不正确的比较和不适当的控制流造成的错误。具体做法就是程序员逐条调试语句。常见的错误包括：

-误解或用错了算符优先级；

-混合类型运算；

-变量初值错；

-精度不够；

-表达式符号错。

比较判断与控制流常常紧密相关，测试时注意下列错误：

-不同数据类型的对象之间进行比较；

-错误地使用逻辑运算符或优先级；

-因计算机表示的局限性，期望理论上相等而实际上不相等的两个量相等；

-比较运算或变量出错；

-循环终止条件或不可能出现；

-迭代发散时不能退出；

-错误地修改了循环变量。

模块的各条错误处理通路测试：程序在遇到异常情况时不应该退出，好的程序应能预见各种出错条件，并预设各种出错处理通路。如果用户不按照正常操作，程序就退出或者停止工作，实际上也是一种缺陷，因此单元测试要测试各种错误处理路径。一般这种测试着重检查下列问题：

-输出的出错信息难以理解；

-记录的错误与实际遇到的错误不相符；

-在程序自定义的出错处理段运行之前，系统已介入；

-异常处理不当；

-错误陈述中未能提供足够的定位出错信息。

是单元测试的逻辑扩展。它的最简单的形式是：两个已经测试过的单元组合成一个组件，并且测试它们之间的接口。从这一层意义上讲，组件是指多个单元的集成聚合。在现实方案中，许多单元组合成组件，而这些组件又聚合成程序的更大部分。方法是测试片段的组合，并最终扩展进程，将您的模块与其他组的模块一起测试。最后，将构成进程的所有模块一起测试。

 （1）在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失；

　（2）一个模块的功能是否会对另一个模块的功能产生不利的影响；

　（3）各个子功能组合起来，能否达到预期要求的父功能；

　（4）全局数据结构是否有问题；

　（5）单个模块的误差累积起来，是否会放大，从而达到不能接受的程度。

1、大爆炸集成：属于非增值式集成的一种方法，也称为一次性组装或整体拼装。这种集成策略的做法就是把所有通过单元测试的模块一次性集成到一起进行测试，不考虑组件之间的互相依赖性及可能存在的风险。（适应于一个维护型项目或被测试系统较小)

2、三明治集成：一种混合增量式测试策略，综合了自顶向下和自底向上两种集成方法的优点，因此也属于基于功能分解的集成。这种方法桩和开发工作都比较小，但增加了定位缺陷的难度。

3、自顶向下集成：就是按照系统层次结构图，以主程序模块为中心，自上而下按照深度优先或者广度优先策略，对各个模块一边组装一边进行测试。又可分为深度优先集成和广度优先集成两种方式。

(适应于产品控制结构比较清晰和稳定；高层接口变化较小；底层接口未定义或经常可能被修改；产口控制组件具有较大的技术风险，需要尽早被验证；希望尽早能看到产品的系统功能行为。)

4、自底向上集成：从依赖性最小的底层模块开始，按照层次结构图，逐层向上集成，验证系统的稳定性。

(适应于底层接口比较稳定；高层接口变化比较频繁；底层组件较早被完成。)

5、高频集成：高频集成测试是指同步于软件开发过程，每隔一段时间对开发团队的现有代码进行一次集成测试。

6、分层集成、分布式集成、基于路径、功能、进度、风险、事件、使用等的集成等13种。

基于进度的集成     优点：具有较高的并行度；能够有效缩短项目的开发进度。     缺点：桩和驱动工作量较大；有些接口测试不充分；有些测试重复和浪费。

是将经过测试的子系统装配成一个完整系统来测试。它是检验系统是否确实能提供系统方案说明书中指定功能的有效方法。（常见的联调测试） 系统测试的目的是对最终软件系统进行全面的测试，确保最终软件系统满足产品需求并且遵循系统设计。  

6.1) 安全性测试

属于软件测试的哪个阶段?并试阐述安全测试的概念和用以评判系统安全性性能的主要指标。

　　是系统测试的一种类型，测试系统是否存在安全隐患和漏洞。

　　安全性测试就是要验证系统内的保护机制能否抵御入侵者的攻击。安全性测试的测试人员需要在测试活动中，撒气不同的入侵方式来攻击系统的安全机制，想尽一切办法来获取系统内的保密信息。

　　系统安全性性能的指标：

有效性：启动严格的安全性性能所花费的时间占启动整个系统所花费时间的比例。

生存性：当错误发生时，系统对紧急操作的支持，对错误的补救措施以及恢复到正常操作的能力，即抗挫能力。

精确性：衡量系统安全性控制的精度指标，围绕所出现的错误数量、发生频率及其严重性判断。

反应时间：出错时系统响应速度的快慢，一个安全性较强的系统要具备快速的反应速度。

吞吐量：用户和服务请求的峰值和平均值。

Q: 软件的安全性应从哪几个方面去测试？

(1) 用户认证机制：如数据证书、智能卡、双重认证、安全电子交易协议

(2) 加密机制

(3) 安全防护策略：如安全日志、入侵检测、隔离防护、漏洞扫描

(4) 数据备份与恢复手段：存储设备、存储优化、存储保护、存储管理

(5) 防病毒系统

6.2) 恢复性测试

属于软件测试的哪个阶段?并试阐述恢复性测试的概念和进行恢复性测试分析时主要应考虑的问题。

恢复性测试使系统测试阶段的一种方法，也叫容错测试，用来检查系统的容错能力。通常若计算机系统出现错误，就必须在一定时间内从错误中恢复过来，修正错误并重新启动系统。在进行恢复性测试时，要考虑的主要问题有：恢复期间的安全性过程。恢复处理日志方面的能力。当出现供电问题时的恢复能力。恢复操作后系统性能是否下降。　　常用的恢复测试用例的设计方法：规范导出法、错误猜测法、基于故障的测试。

（2）集成测试是系统模块的测试，系统测试是对整个系统的测试，包括相关的软硬件平台、网络以及相关外设的测试。

是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。验收测试是向未来的用户表明系统能够像预定要求那样工作。经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是验收测试的任务，即软件的功能和性能如同用户所合理期待的那样。

  包括正式验收测试、alpha测试、beta测试三种测试。

7.1) Beta testing (β测试)

测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场  

7.2)Alpha testing (α测试)

是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试

也称“Configuration testing（配置测试）”，测试软件是否和系统的其它与之交互的元素之间兼容，如：浏览器、操作系统、硬件等。验证测试对象在不同的软件和硬件配置中的运行情况。兼容测试主要是检查软件在不同的硬件平台、软件平台上是否可以正常的运行，即是通常说的软件的可移植性。

兼容的类型，如果细分的话，有平台的兼容，网络兼容，数据库兼容，以及数据格式的兼容。

包括向下兼容和交错兼容，向下兼容是测试软件新版本保留它早期版本功能的情况，交错兼容是验证共同存在的两个相关但不相同的产品之间的兼容性。

配置测试的目的是保证软件在其相关的硬件上能够正常运行，而兼容性测试主要是测试软件能否与不同的软件正确协作。

配置测试的核心内容就是使用各种硬件来测试软件的运行情况，一般包括：

（1）软件在不同的主机上的运行情况，例如Dell和Apple；

（2）软件在不同的组件上的运行情况，例如开发的拨号程序要测试在不同厂商生产的Modem上的运行情况；

（3）不同的外设；

（4）不同的接口；

（5）不同的可选项，例如不同的内存大小；

兼容性测试的核心内容：

（1）测试软件是否能在不同的操作系统平台上兼容；

（2）测试软件是否能在同一操作系统平台的不同版本上兼容；

（3）软件本身能否向前或者向后兼容；

（4）测试软件能否与其它相关的软件兼容；

（5）数据兼容性测试，主要是指数据能否共享；

配置和兼容性测试通称对开发系统类软件比较重要，例如驱动程序、操作系统、数据库管理系统等。具体进行时仍然按照测试用例来执行。

系统在大并发下的响应速度和健壮性

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

界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作，起到向导的作用。同时界面如同人的面孔，具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉，相反由于界面设计的失败，让用户有挫败感，再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。　　区别在于，功能测试关注产品的所有功能上，要考虑到每个细节功能，每个可能存在的功能问题。性能测试主要关注于产品整体的多用户并发下的稳定性和健壮性。界面测试更关注于用户体验上，用户使用该产品的时候是否易用，是否易懂，是否规范（快捷键之类的），是否美观（能否吸引用户的注意力），是否安全（尽量在前台避免用户无意输入无效的数据，当然考虑到体验性，不能太粗鲁的弹出警告）？做某个性能测试的时候，首先它可能是个功能点，首先要保证它的功能是没问题的，然后再考虑该功能点的性能测试

界面的友好性，操作方便性等。

是否使用了公司的模板、

文档内容是否符合规范、

所有的需求是分级是否清析适当、

所有的需求是否具有一致性、

需求是否可行（即，该需求组合有解决方案）、

需求可否用己知的约束来实现、

需求是否足够（即，可以把它送到一个规范的开发组织，并有一个生产出所需要产品的合理的可能性）、

所有的其它需求是交叉引用是否正确、

用户描述是否清楚、

是否用客户的语言来描述需求、

每个需求描述是否清楚没有岐义，可以移交给一个独立的组去实现时也能理解、

是否所有的需求都是可验证的、

是否每条需求都具有独立性，即使发生了变化也不会影响其它需求、

性能指标是否明确、

非功能性需求是否得到充分表现、

是否完整列出适用的标准或协议、

标准和协议之间是否存在冲突