软件测试复习简答文档格式.docx

软件测试复习简答文档格式.docx

《软件测试复习简答文档格式.docx》由会员分享，可在线阅读，更多相关《软件测试复习简答文档格式.docx（11页珍藏版）》请在冰豆网上搜索。

——依据测试计划和测试大纲、测试用例，逐一测试大大小小的功能、方方面面的特性、性能、用户界面、兼容性、可用性等等；

预期可发现大量不同性质、不同严重程度的错误和问题。

（3）回归测试期

——系统已达到稳定，在一轮测试中发现的错误已十分有限；

复查已知错误的纠正情况，确认未引发任何新的错误时，终结回归测试。

2.集成测试过程中的两个重要里程碑

在集成测试过程中的两个重要的里程碑是功能冻结和代码冻结的确定。

这两个里程碑界定出回归测试期的起止界限。

2.软件测试的目的，原则

目的：

测试是想以最少的时间和人力，系统地找出软件中潜在的各种缺陷，通过修正缺陷提高软件质量，回避软件发布后由于潜在缺陷造成的隐患所带来的商业风险；

测试的附带收获是，它能够证明软件的功能和性能是否与需求说明书相符合；

实施测试收集到的测试结果数据为可靠性分析提供了依据；

测试不能表明软件中不存在错误，它只能说明软件中存在错误。

原则：

尽早地和不断地进行软件测试

不可能完全的测试：

一、不可能测试程序对所有可能输入的响应。

二、不可能测试到程序每一条可能的执行路径

三、无法找出所有的设计错误

四、不能采用逻辑来证明程序的正确性

增量测试，由小到大

避免测试自己的程序

设计周密的测试用例

3.对软件复杂性进行归纳分析

1、无法对程序进行完全测试

（1）测试所需要的输入量太大

（2）测试的输出结果太多

（3）软件实现的途径太多

（4）软件规格说明没有一个客观标准

2、测试无法显示潜在的软件缺陷和故障

——通过软件测试只能报告软件已被发现的缺陷和故障，无法报告隐藏的软件故障。

3、存在的故障现象与发现的故障数量成正比

——结论：

应当对故障集中的程序段进行重点测试

4、不能修复所有的软件故障

——原因：

没有足够的能力进行修复；

修复的风险较大；

不值得修复；

可不算做故障的一些缺陷；

“杀虫剂现象”。

关键是要进行正确的判断、合理的取舍，根据风险分析决定哪些故障必须修复，哪些故障可以不修复。

5、软件测试的代价

——工作原则：

就是如何将无边无际的可能性减小到一个可以控制的范围，以及如何针对软件风险做出恰当选择，去粗存精，找到最佳的测试量，使得测试工作量不多也不少，既能达到测试的目的，又能较为经济。

4.各种测试

各种测试的说明：

单元测试：

单元测试是基于程序模块进行正确性验证的测试。

集成测试：

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

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

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

程序在某些局部反映不出来的问题，在全局上很可能暴露出来，影响功能的实现。

确认测试：

确认测试是检验所开发的软件是否能按顾客提出的要求运行。

系统测试：

系统测试是将被测的软件作为整个基于计算机系统的一个元素，与计算机硬件、外设、支持软件、数据和人员等其他系统元素结合在一起，在实际的环境中，对计算机系统进行一系列的测试。

系统测试的目的在于通过与系统的需求定义作比较，发现软件与系统定义不符合或与之矛盾的地方。

系统测试的测试用例应根据需求分析说明书来设计，并在实际使用环境下来运行。

系统测试主要包括：

恢复测试（恢复测试是要采取各种人工干预方式使软件出错，而不能正常工作，进而检验系统的恢复能力）、安全测试、强度测试（压力测试）、性能测试，强度和性能测试往往结合起来进行。

验收（用户）测试：

检验软件产品质量的最后一道工序。

主要突出用户的作用，同时软件开发人员也应有一定程度的参与。

5.归纳集成测试的两种不同测试方法

非增量式测试

非增量式测试是采用一步到位的方法来构造测试：

——对所有模块进行个别的单元测试后，按照程序结构图将各模块连接起来，把连接后的程序当作一个整体进行测试。

实例采用非增量式测试方法进行集成测试

非增量式测试的缺点：

——当一次集成的模块较多时，非增量式测试容易出现混乱，因为测试时可能发现了许多故障，为每一个故障定位和纠正非常困难，并且在修正一个故障的同时，可能又引入了新的故障，新旧故障混杂，很难判定出错的具体原因和位置。

增量式测试

增量式测试的集成是逐步实现的：

——逐次将未曾集成测试的模块和已经集成测试的模块（或子系统）结合成程序包，再将这些模块集成为较大系统，在集成的过程中边连接边测试，以发现连接过程中产生的问题。

按照不同的实施次序，增量式集成测试又可以分为三种不同的方法：

（1）自顶向下增量式测试

（2）自底向上增量式测试

（3）混合增量式测试

6.归纳确认测试的准则

确认测试的准则

确认测试也称为合格性测试，是检验所开发的软件是否能按用户提出的要求进行。

软件确认要通过一系列证明软件功能和要求一致的黑盒测试来完成。

经过确认测试，应该为已开发的软件给出结论性评价：

（1）经过检验的软件的功能、性能及其他要求均已满足需求规格说明书的规定，则可被认为是合格的软件。

（2）经过检验发现与需求说明书有相当的偏离，得到一个各项缺陷清单。

7.系统测试的内容包含哪些？

写出每一种测试的要点

常见测试方法：

（1）恢复测试-检查系统的容错能力。

（2）安全测试-检查系统对外界非法入侵的防范能力。

（3）强度测试，也称压力测试、负载测试。

检测非正常的情况下系统的负载能力。

（4）性能测试：

用来测试系统在运行时的表现。

（5）容量测试：

是指在系统正常运行的范围内确定系统能够处理的数据容量。

（6）正确性测试：

是为了检测软件的各项功能是否符合产品规格说明的要求。

（7）可靠性测试：

检验系统的可靠性。

（8）兼容性测试：

8.软件测试策略包含哪些特征

软件测试策略包含的特征：

※※※

（1）测试从模块层开始，然后扩大延伸到整个基于计算机的系统集合中。

（2）不同的测试技术适用于不同的时间点。

（3）测试是由软件的开发人员和（对于大型系统而言）独立的测试组来管理的。

（4）测试和调试是不同的活动，但是调试必须能够适应任何的测试策略。

9.软件测试包含哪些阶段，侧重点，含义（不确定）

针对每个单元的测试，以确保每个模块能正常工作为目标。

对已测试过的模块进行组装，进行集成测试。

目的在于检验与软件设计相关的程序结构问题。

确认（有效性）测试：

是检验所开发的软件能否满足所有功能和性能需求的最后手段。

检验软件产品能否与系统的其他部分（比如，硬件、数据库及操作人员）协调工作。

10.正确理解黑盒测试方法的概念，并进行总结归纳

黑盒测试被称为功能测试或数据驱动测试。

在测试时，把被测程序视为一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下进行。

采用黑盒测试的目的主要是在已知软件产品所应具有的功能的基础上，进行：

（1）检查程序功能能否按需求规格说明书的规定正常使用，测试各个功能是否有遗漏，检测性能等特性要求是否满足。

（2）检测人机交互是否错误，检测数据结构或外部数据库访问是否错误，程序是否能适当地接收输入数据而产生正确的输出结果，并保持外部信息（如数据库或文件）的完整性。

（3）检测程序初始化和终止方面的错误。

11.简述白盒测试用例的设计方法，并进行分析总结

白盒测试主要是检查程序的内部结构、逻辑、循环和路径。

常用测试用例设计方法有：

逻辑覆盖法（逻辑驱动测试）：

是以程序内部的逻辑结构为基础设计测试用例的方法。

根据对程序内部的逻辑结构的覆盖程度，逻辑覆盖法具有不同的覆盖标准：

语句覆盖、判定覆盖、条件覆盖、判定—条件覆盖、条件组合覆盖等

基本路径测试方法:

如果把覆盖的路径数压缩到一定限度内，例如程序中的循环体只执行零次和一次，就称为基路径测试。

12.简述客户/服务器体系结构应用系统的测试特点及主要内容

C/S体系结构的软件测试通常是从单个客户端开始，然后再逐步集成客户端、服务器和网络系统进行集成测试，最后进行系统的整体测试。

（1）客户端的独立测试

对客户端的测试主要是属于功能性测试。

用户客户端应用以“分离的”模式被测试，即这层测试不考虑服务器和底层网络的运行。

通常包括：

客户端的测试——检测客户端的业务逻辑流程的应用

（2）客户端与服务器端的集成测试

客户端软件和关联的服务器端应用作一体测试，但并不过多考虑网络运行的关联因素。

对服务器的测试——主要是性能的测试。

测试包含服务器的协调和数据管理功能以及服务器的性能（整体响应时间和数据的吞吐量）的表现。

数据库测试-一致性错误，输出的错误

连接速度测试-速度太慢，引起数据丢失。

负载测试-为了测量C/S系统在某一负载级别上的性能，以保证系统在需求范围内能够正常工作。

压力测试-通常是指对Web应用系统负载能力极限的测试。

系统限制和故障恢复信息页面的传输能力。

对应用服务器（中间件）的测试

（3）整体测试

对完整的C/S体系结构整体测试，在上述功能测试和性能测试的基础上，还包括网络运行及其性能的测试。

整体测试通常包括以下测试项目：

事务测试——创建一系列的测试以保证每类事务被按照需求处理。

事务测试着重于处理的正确性，同时也关注性能问题。

网络通信测试——用于验证网络节点间的通信是否正常的发生，并且消息传递、事务和相关的网络通信有无错误的发生。

13.简述WEB网站测试的测试范围及采用的方法

基于Web的系统测试不但需要检查和验证是否按照设计的要求运行，而且还要评价系统在不同用户的浏览器端的显示是否合适。

重要的是，还要从最终用户的角度进行安全性和可用性测试，从功能、性能、可用性、客户端兼容性、安全性等方面讨论基于Web的系统测试方法。

对Web网站测试所采用的测试方法与策略有哪些？

——黑盒测试、白盒测试、静态测试和动态测试都有可能用到，还会包括面向对象测试技术的运用。

14.面向对象的开发模式与传统软件的开发模式有何不同，因此而引发的测试方法有何不同

面向对象的程序结构不再是传统的功能模块结构，作为一个整体，原有集成测试所要求的逐步将开发的模块搭建在一起进行测试的方法已变得不可行。

而且，面向对象软件抛弃了传统的开发模式，对每个开发阶段都有不同以往的要求和结果，已经不可能用功能细化的观点来检测面向对象分析和设计的结果。

因此，传统的测试模型对面向对象软件已经不再适用。

测试方法

面向对象软件抛弃了传统的开发模式，对每个开发阶段都有不同于传统软件测试的要求和结果,已经不可能用功能细化的观点来检测面向对象分析和设计的结果。

a）测试的对象不同：

传统软件测试的对象是面向过程的软件，一般用结构化方法构建；

面向对象测试的对象是面向对象软件，采用面向对象的概念和原则，用面向对象的方法构建。

b）测试的基本单位不同：

前者是模块；

面向对象测试的基本单元是类和对象。

c）测试的方法和策略不同：

传统软件测试采用白盒测试，黑盒测试，路径覆盖等方法；

面向对象测试不仅吸纳了传统测试方法，也采用各种类测试等方法，而且集成测试和系统测试的方法和策略也很不相同。

15.简述面向对象的单元测试与集成测试的思路策略

分别以方法和类作为单元的测试进行简单的比较。

以方法为单元

可以将面向对象单元测试归结为传统的单元测试。

可以使用所有传统功能性测试和结构性测试技术。

前期工作相对容易，但后续测试工作重。

以类为单元

面向对象测试的层次，取决于单元的构成，一般采用三层或四层方式。

如果把单个操作或方法看作单元，则有四层测试，即操作/方法、类、集成和系统测试。

面向对象测试的主要问题是集成测试，可以看作是第三层，即在通过测试的类之间的交互测试。

面向对象的集成测试通常需要进行两级集成：

一是将成员函数集成到完整类中；

二是将类与其它类集成。

面向对象的集成测试能够检测出相对独立的单元测试无法检测出的那些类相互作用时才会产生的错误。

单元测试可以保证成员函数行为的正确性，集成测试则只关注于系统的结构和内部的相互作用。

面向对象集成测试可以分成两步进行：

先进行静态测试，再进行动态测试。

16.概况总结类的功能和性能测试

功能性测试以类的规格说明为基础，主要检查类是否符合其规格说明的要求。

功能性测试包括两个层次：

类的规格说明和方法的规格说明。

结构性测试则是从程序出发，对类中方法进行测试，需要考虑其中的代码是否正确。

测试分为两层：

第一层考虑类中各独立方法的代码，即方法要做单独测试；

第二层考虑方法之间的相互作用，即方法需要进行综合测试。

17.对WEB进行压力测试时有哪些条件，如何使用

条件

重复：

就是一遍又一遍地执行某个操作或功能。

这将确定一个操作能否正常执行，并且能否继续在每次执行时都表现正常。

并发：

就是在同一时间内执行多个操作。

由并发引起的错误只能通过执行多个代码示例才能测出来，测试时要同时遍历多条代码路径。

量级：

要考虑到每个操作中的负载量，操作自身应尽可能给被测软件系统增加压力，即：

尽量使单独的操作进行高强度的使用，增加操作的量级。

随机变化：

随机使用前面条件中的无数变化形式，就能够在每次测试运行时应用许多不同的代码路径。

如何使用：

重复调用一个Web服务。

在同一个服务器上同时调用许多Web服务。

您可以通过模拟输入超长消息的客户机来使这个单独的操作进行高强度的使用。

换句话说就是，您增加了这个操作的量级。

如果您随机使用前面的压力原则中介绍的无数变化形式，您就能够在每次测试运行时应用许多不同的代码路径。

18.以面向对象技术给软件测试带来哪些表现

面向对象技术的特点给测试带来的新问题具体表现为：

（1）封装把数据及对数据的操作封装在一起，限制了对象属性对外的透明性和外界对它的操作权限，在某种程度上避免了对数据的非法操作，有效防止了故障的扩散。

但同时，封装机制也给测试数据的生成、测试路径的选取以及测试结构的分析带来了困难。

（2）继承实现了共享父类中定义的数据和操作，同时也可定义新的特征。

子类是在新的环境中存在，所以父类的正确性不能保证子类的正确性。

继承使代码的重用率得到了提高，但同时也使故障的传播几率增加。

（3）多态和动态绑定增加了系统运行中可能的执行路径，而且给面向对象软件带来了严重的不确定性，给测试覆盖率的活动带来新的困难。

19.描述面向对象测试与传统测试有哪些不同

20.如何转向基于状态转移图的软件测试

基于状态的测试是通过检查对象的状态在执行某个方法后是否会转移到预期状态的一种测试技术。

使用该技术能够检验类中的方法是否能正确地交互。

基于状态测试的主要步骤：

（1）依据设计文档，或者通过分析对象数据成员的取值情况空间，得到被测试类的状态转移图。

（2）给被测试的类加入用于设置和检查对象状态的新方法,导出对象的逻辑状态。

（3）对于状态转移图中每个状态，确定该状态是哪些方法的合法起始状态，即在该状态时对象允许执行哪些操作。

（4）在每个状态，从类中方法的调用关系图最下层开始，逐一测试类中的方法；

测试每个方法时，根据对象当前状态确定出对方法的执行路径有特殊影响的参数值，将各种可能组合作为参数进行测试。