软件测试技术

软件测试技术

软件的概念：信息处理系统的所有或部分程序、规程、规则和任何相关的文档的集合。

程序：源程序+目标程序

源程序：高级语言、汇编语言编写的程序

目标程序：源程序经编译或解释加工以后可以由计算机直接执行的程序

文档：用自然语言或形式化语言所编写的文字资料和图表，用来描述程序的内容、组成、设计、功能规格、开发情况、测试结果以及使用方法。

软件测试包括：源程序+目标程序+文档

软件测试的定义：使用人工或者自动手段，来运行或测试某个系统的过程。其目的在于检测它是否满足规定的需求或弄清预期结果与实际结果之间的差别。

测试过程（了解） 每一阶段都要从头来一次

需求测试：需求文档的测试

测试的计划：对测试过程的整体设计，确定测试范围，制定测试策略，安排测试资源，进度制定，风险评估，应对策略

测试设计及用例：测试设计，用例设计，用例评估

测试的执行：用例的选择（难得?复杂的？优先级高的？），测试环境的搭建，每日构建

测试的记录和跟踪：Bug记录，Bug管理，Bug的报告（沟通，评审，提交），Bug的跟踪

回归测试：再测一次

测试总结和报告：缺陷的分类报告，客观全面的报告生成，经验总结

测试的分类

按测试的方法分类：

静态测试和动态测试，白盒测试，黑盒测试，灰盒测试，冒烟测试，回归测试，功能测试与性能测试，压力测试和负载测试，配置测试，文档测试，兼容性测试，安全测试，恢复测试，可移植性测试，引导测试，随机测试，手动和自动测试，通过/失败测试，错误猜测，易用性，安装性，界面性。

按测试的阶段分类：单元测试，集成测试，（确认测试），系统测试，（验收测试 a测试，b测试）

测试的原则：

投入和产出平衡（当有两次bug趋于0，当第三次出现就停止测试继续开发）

二八原则

尽早的和不断开展测试

错误的地方多投入

同化问题：交叉测试，利用不同人的观点

需求的测试

需求占缺陷比例高达56%

需求可能存在的问题

需求文档编写有问题、功能不明确，流程不清晰，不正确占50%，余下50%是需求的遗漏造成的。

拿着一线文档（需求卡片），需求规格说明书和卡片进行对比，所有规格都已经有了，再使用检查列表对需求说明书进行优化，看有没有歧义，语法上的错误，再结合所有的项目组人员进行讨论，评审，修订，看看需求规格说明书上有没有什么不能实现，需不需要再找客户。

检查列表

第一步：对比需求

第二步：检查列表检查需求

第三步：根据定稿的需求规格说明书来分析我们测试用例，以备测试

测试计划

测试计划的内容（了解）：

确定测试范围

制定测试策略

测试资源安排

进度及安排

风险及对策

测试范围:功能，性能

策略：测试方法

资源进度安排：人，物，时间。细化到最小颗粒逐渐反推相加

测试用例设计

基于需求的测试用例设计：

验证需求是否正确，完整性，无二义性，并且逻辑一致性

从黑盒角度设计出充分并且必要的测试集

基于需求的测试需要工具支持，比如QC

测试用例设计：

等价类划分法

边界值分析法

因果图法

基本路径分析法

场景设计法

错误猜测试

正交分解法

……..

黑盒测试的基本概念:
穷举输入测试是不实现的。这就需要我们认真研究测试方法，以便能开发出尽可能少的测试用例，发现尽可能多的软件故障。

常用的黑盒测试方法有等价类划分，边界值分析，决策表测试等，每种方法各有所长，我们应针对软件开发项目的具体特点，选择合适的测试方法，有效地解决软件开发中的测试问题。

 

 

等价类划分：

等价类划分是一种典型的黑盒测试方法，它完全不考虑程序的内部结构，只根据程序规格说明书对输入范围进行划分，把所有可能的输入数据，即程序输入域划分为若干个互不相交的子集，称为等价类，然后从每个等价类中选取少数具有代表性的数据作为测试用例，进行测试。

在确立了等价类之后，可按下表的形式列出所有划分出的等价类表

等价类表

同样，也可按照输出条件，将输出域划分为若干个等价类

在设计测试用例时应同时考虑有效等价类和无效等价类测试用例的设计。根据等价类表设计测试用例，具体步骤如下：

1. 为每个等价类规定一个唯一的编号
2. 设计一个新的测试用例，尽可能多的覆盖尚未被覆盖的有效等价类，重复这一步，直到测试用例覆盖了所有的有效等价类。
3. 设计一个新的测试用例，使其覆盖并且只覆盖一个还没有被覆盖的无效等价类。重复这一步，直至测试用例覆盖了所有的无效等价类。

 

边界值分析法

健壮性边界值测试将会产生4n+1个测试用例

健壮性测试最有意义的部分不是输入，而是预期的输出，观察例外情况如何处理

等价类划分+边界值法

 

因果图法

 

因果图法的原理

因果图法测试用例的设计步骤

1. 确定软件规格中的原因和结果。分析规格说明中哪些是原因（即输入条件或输出条件的等价类），哪些是结果(即输出条件)，并给每个原因和结果赋予一个标识符。
2. 确定原因和结果之间的逻辑关系。分析软件规格说明书中的语义，找出原因与结果之间，原因与原因之间对应的关系，根据这些关系画出因果图。
3. 确定因果中的各个约束。由于语法或环境的限制，有些原因与原因之间，原因与结果之间的组合情况不可能出现。为表明这些特殊情况，在因果图上用一些记号表明约束或限制条件。
4. 把因果图转化为决策表
5. 根据决策表设计测试用例

 

决策表法（不会考）

决策表通常由条件桩，条件项，动作桩和动作项4部分组成。

 

因果图+决策表

动作项和条件项紧密相关，指出在条件项的各组取值情况下应采取的动作。

 

生成的决策表

练习：见测试方法.doc 和 PPT上的例子，实验报告中的例子

 

 

场景设计法    

大部分软件是由事件触发来控制流程的，事件触发时的情景就是所谓的场景

根据需求规格说明书中的用例规约来设计，正常的流程，异常分支应该怎么做。主要是测流程，没有测细节，还是要用等价类划分来测试。

 

错误猜测法

是基于经验的直觉推测程序中可能发生的各种错误，有针对性设计测试用例。

优点：充分发挥个人的经验和潜能，命中率高

缺点：覆盖率难以保证；过多的依赖个人的经验。

注意：最重要的是要思考和分析测试对象的各个方面，多参考以前发现的Bug的相关数据，总结的经验，个人多考虑异常的情况，反面的情况，特殊的输入，以一个攻击者的态度对待程序，那么就能设计出比较完善的测试用例。

 

正交分解法

正交表法是一种有效减少测试用例个数的设计方法。

有效减少测试用例个数的测试用例方法。单因素覆盖，成对覆盖，三三组合覆盖

PICT工具

 

测试的执行，测试的管理工具

BUGFREE的工作流程

在这个平台上提交你的需求，比如说提交你发现的BUG，指派给某一个开发人员来完成，基本上指这个功能的开发人员，他在这个平台上接到通知之后，对其进行修复，修复完成之后就会提醒测试人员，我已经修复好了请再测试一次，如果通过就把这个Bug关闭掉，如果没有通过，就再次发给开发人员来进行修复。

BUG的状态

 

 

 

测试执行中的关键

测试环境的准备

构建测试运行的平台和安装需要的软硬件系统。

人员的安排

不仅包括指定哪些人参加功能测试，哪些人参加系统测试和谁负责测试环境的维护等，还要包括人员的培训，知识的传递。

 

测试用例包括哪些内容：测试功能（目标），测试环境，测试要录入的数据，测试的具体操作，预期结果，不包括实际结果。

 

 

测试执行的准备

培训和知识传递

测试任务安排

测试环境的建立

测试环境的设置

测试自动化运行平台

 

白盒测试

静态白盒测试和动态白盒测试

静态白盒测试：主要测三个方面软件的设计，体系结构和代码。从而找出软件缺陷的过程，有时也称为结构化分析

原因：尽早发现软件错误；为黑盒测试人员提供建议

方式：1.确定问题2.遵守规则3.准备期间4.编写报告

方法：互查，走查，会议评审。

 

互查：小组之间成员之间交流互相交流源代码，怎么去调用源代码，对方如何调用处理，增进感情。

走查：每个项目会派出代表，或者项目主的每个成员都会出来陈述代码第一步怎么做，第二部怎么做……，或者用什么样的算法去提高底层的效率。

好处：检查代码的注释是否写好，效率是否有问题。把控整个小组的代码风格（如命名风格，申明变量的风格）。

 

会议评审:公司的高层会派一个专家组进驻你的项目，然后看看你的项目设定或者编码情况。但是成本高。因为专家进来之前对这个项目不是很熟悉，专家组需要一定的时间来了解这个项目。

 

动态白盒测试

检查代码并观察运行状况

利用查看代码（做什么）和实现方法（怎么做）得到的信息来确定哪些需要测试，哪些不要测试，如和开展测试

又称为结构化测试

 

动态白盒测试期望达到的目的

所有独立路径至少都能测试一遍

所有逻辑判断都能测试True和False两条路径；

所有循环结构都能测试到边界和循环域内的情况；

确保内部数据结构的有效性。

 

 

白盒测试主要的方法

逻辑覆盖测试法

基本路径测试法

循环路径覆盖法

 

逻辑覆盖测试法

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

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

条件覆盖：每种条件下的语句都应该被执行

判定/条件覆盖：同时满足判定覆盖和条件覆盖

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

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

 

基本路径测试法（阅读代码->画出流程图->圈复杂度->设计测试用例->进行相关测试）

基本路径测试法是在程序控制流图的基础上，通过分析控制构造的环路复杂性，导出基本可执行路径集合，从而设计测试用例的方法。

 

路径是控制流程图中节点的顺序，始于入口节点，止于出口节点

 

 

程序可能通过的路径是：

路径 1：1 – 11

路径 2：1 – 2 – 3 – 4 – 5 – 10 – 1 – 11

路径 3：1 – 2 – 3 – 6 – 8 – 9 – 10 – 1 – 11

路径 4：1 – 2 – 3 – 6 – 7 – 9 – 10 – 1 – 11

 

圈复杂度的计算：

1. 边-节点+2
2. 封闭+1
3. 矩阵模型（可以不用掌握）

 

循环路径覆盖法

五种测试用例

1. 整个跳过循环
2. 只有一次通过循环
3. 两次通过循环
4. m次通过循环,m<循环最大次数
5. n-1,n,n+1次通过循环

 

实际运用中，基本路径+循环使用的最多

 

将测试进行分段

测试越早发生越好

代码分段构件和测试，最后合在一起形成更大的部分

单元测试：接口，数据边界，路径，异常，局部变量（数据）

可测可不测:条件组合，性能，功能

 

单元测试概念

定义:单元测试时对软件基本组成单元进行的测试

时机：在代码完成后由开发人员完成，QA人员辅助

意义：尽早发现错误，发现的越早成本越低

 

单元测试内容

运行单元程序有时需要基于被测单元的接口，开发相应的驱动模块和桩模块

驱动模块

 

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

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

 

 

集成测试

对于传统软件来说，按集成粒度不同，可以把集成测试分为3个层次，即:

1. 模块间集成测试
2. 子系统内集成测试
3. 子系统间集成测试

 

集成测试的模块

渐增式测试模块与非渐增式测试模块

非渐增式测试模式：先分别测试每个模块，再把所有模块按设计要求放在一起结合成所要的程序，如大棒法(先测试最小模块，再测试最大的模块)

大棒方式的优缺点

好处：非常快捷

坏处：容易出错，一旦出现错误，不知道是哪个模块出现的错误

 

 

渐增式测试模式：把下一个要测试的模块同已经测试好的模块结合起来进行测试，测试完以后再把下一个应该测试的模块结合进来测试。当使用渐增方式把模块结合到程序中去时，有自顶向下和自底向上两种集成策略和混合

自顶向下的优缺点

优点：可以纵观全局，很快的发现软件测试文档出现的问题

 

自底向上的优缺点：

效率高，但是需要大量的驱动

 

 

自顶向下和自底向上集成策略

驱动程序/驱动模块(driver)，用以模拟被测模块的上级模块。驱动模块在集成测试中接收测试数据，把相关的数据传送给被测模块，启动被测模块，并打印出相应的结果。

桩程序/桩模块(stub)，也有人称为存根程序，用以测试被测模块工作过程中所调用的模块。桩模块由被测模块调用，它们一般只进行很少的数据处理，例如打印入口和返回，以便于检测被测模块与其下级模块的接口。

 

 

 

系统测试

需求分析阶段：测试需求规格说明书，是否与用户要求一致

概要设计阶段：测试概要设计说明中是否覆盖了所有已确定的需求，是否考虑了后期维护

详细设计阶段：数据结构，算法是否正确，编码规范

编码阶段： 单元测试，集成测试

系统验收阶段：测试系统是否完成了需求规格说明书中的所有内容

 

 

 

 

 

系统测试概念

使用人工或自动手段来运行或测试某个系统的过程，其目的在于检验它是否满足规定的系统需求或是弄清预期结果与实际结果之间的差别。系统测试在真实环境下进行

验证(Verificaiton)

    验证确定工作产品正确反应了它们的规定需求。换言之，验证保证"你正确地构件了它"

确认(Validation)

    确认确定提供的产品将满足其预期使用。换言之，确认保证"你构建了正确的产品"

 

为了发现发现却缺陷并度量产品质量，按照系统的功能和性能需求进行的测试

一般使用黑盒测试技术

一般由独立的测试人员完成

 

对于模块之间交互性比较强的软件，还会有单独的集成测试，用来发现模块接口之间的错误。

 

系统测试的内容(了解哪个是那个)

功能测试

恢复性测试（灾难测试，容错测试）

可用性测试

安全性测试

接口测试

GUI测试

安装/升级测试

配置测试/兼容性测试

国际化（语言）测试

用户文档测试

……

 

 

性能测试

压力测试

容量测试

可靠性测试

边界测试

……….

 

冒烟测试

 

回归测试

 

随机测试

 

硬件系统专有测试

可靠性试验

可产生性测试

可维护性测试

 

 

自动化测试

 

性能测试包括以下几个方面

评估系统的能力。测试中得到的符合和相应时间等数据可以被用于验证所计划的模型的能力，并帮助做出决策。

识别系统中的弱点。受控的负荷可以被增加到一个极端的水平并突破它，从而修复系统的瓶颈或薄弱的地方。

系统调优。重复运行测试，验证调整系统的活动得到了预期的结果，从而改进性能，检测软件中的问题。

 

 

性能测试的概念

性能测试主要验证软件是否达到需求规格说明书中规定的各类性能指标，并满足一些行性能相关的约束和限制条件。

主要有：响应时间，并发用户，吞吐量，服务器性能，点击率，响应成功率

 

性能测试的分类（谁是谁，有什么区别）

压力测试

负载测试

并发测试

配置测试

 

负载测试

负载测试是通过逐步增加系统工作量，测试系统能力的变化，并最终确定在满足功能指标的情况下，系统所承受的最大工作量的测试。

压力测试实质上就是一种特定类型的负载测试

并发测试是一种测试手段，在压力测试中可以利用并发测试来进行压力测试

负载测试是模拟实际软件系统所承受的负载条件的系统负荷，通过不断加载（如逐渐增加模拟用户的数量）或其它加载方式来观察不同负载下系统的响应时间和数据吞吐量、系统占用的资源（如CPU、内存）等，以检验系统的行为和特性，以发现系统可能存在的性能瓶颈、内存泄漏、不能实时同步等问题。负载测试更多地体现了一种方法或一种技术。

 

压力测试是在强负载（大数据量、大量并发用户等）下的测试，查看应用系统在峰值使用情况下操作行为，从而有效地发现系统的某项功能隐患、系统是否具有良好的容错能力和可恢复能力。压力测试分为高负载下的长时间（如24小时以上）的稳定性压力测试和极限负载情况下导致系统崩溃的破坏性压力测试。

 

压力测试可以被看作是负载测试的一种，即高负载下的负载测试，或者说压力测试采用负载测试技术。通过压力测试，可以更快地发现内存泄漏问题，还可以更快地发现影响系统稳定性的问题。

 

 

 

 

性能测试的流程

 

 

自动化性能测试原理

首先保证一个用户能正常访问，记录访问过程，记录通讯包

通过测试工具模拟更多用户同时发通讯包，后台无法区分是人或工具

通过测试工具模拟大量用户同时向后台发出请求，来达到产生压力和指定压力的目的，在产生指定压力的同时监控后台系统的资源消耗情况，监控客户端的请求处理时间

 

 

复制出客户端发往服务端的请求，模拟用户

关注的是通讯包，协议，不关心客户端形式

 

 

关于LoadRunner

LoadRunner是Mercury Interaction公司开发一款成熟的性能测试工具，LoardRunner作为性能测试的实现者，涉及性能测试流程，性能测试技术和软件系统架构等众多方面的知识点。

LoardRunner提供的解决方案

 

 

LoadRunner的过程

脚本生成器Virtual User Generator

VuGen提供了基于录制的可视化图形开发环境，可以方面简洁地生成用于负载的性能脚本。

压力调度和监控系统Controller

负责对整个负载的过程进行设置，制定负载的方式和周期，同时提供了系统监控的功能。

压力生成器Load Generator

负责将VuGen脚本复制成大量虚拟用户对系统生成负载。

结果分析工具Analysis

通过Analysis我们可以对负载生成后的相关数据进行整理分析。

 

 

自动化测试的步骤：

录制一个操作的过程，称为脚本

回放一下，验证脚本是否正确

脚本增强(参数化如密码，用户名。在脚本中设置检查点，检查运行过程中是否执行成功，如果成功了就会出现字符串或图片。)

设置自动化测试执行的策略

事务，设定我们的场景（一开始多少线程启动，做什么样的事情，到达某一时刻线程，其他一些零界点做什么事情，线程在什么时候停止，在什么时候再启动）在测试过程中观察参数的变化（相应时间，等）

分析报告，在报告中我们查看某个功能运行时间效率是否达到我们之前的设定，或者方差是我们期望的，否则进行调优。