软件测试基础课程慕课网Word下载.docx

软件测试基础课程慕课网Word下载.docx

《软件测试基础课程慕课网Word下载.docx》由会员分享，可在线阅读，更多相关《软件测试基础课程慕课网Word下载.docx（17页珍藏版）》请在冰豆网上搜索。

四、软件测试所遵循的原则：

1.测试显示缺陷的存在，但不能证明系统不存在缺陷。

2.穷尽测试是不可能的，应设定及时终止的条件。

3.测试应该尽早进行。

4.缺陷具备群集特性。

越是发现问题多的模块，就是我们重点关注的对象。

5.测试的杀虫剂悖论。

在测试当中，我们采用同样的测试用例、同样的测试方法，多次、重复的来测试某一个模块，那最后我们就不能够再发现新的缺陷。

所以我们的测试用例和测试方法应该不定期的评审和修改，并增加不同的测试方法或测试用例来测试软件或系统的不同部分，从而发现更多的缺陷。

6.测试的二八原则。

就是我们应该把80%的时间或资源用在20%的重点模块上，重点测试这款软件中20%的重要模块，来达到我们测试的效率和资源配置最佳的比例。

7.测试活动依赖于测试背景。

第二课时：

软件测试阶段、手段、模式

一、软件测试阶段

软件测试按测试阶段来分类：

单元测试、集成测试、系统测试、验收测试。

（一）单元测试

是各个阶段测试的基础，是对软件中的最小可测试单元进行检查和验证。

单元是人为规定的可测试的最小的模块。

（java面向对象语言来说，最小可测试单元是每一个类）

单元测试是对代码进行测试

测试框架：

junit针对JAVAnunit针对.netphpunit针对PHPCppUnit针对C++

原则：

1.尽可能的保证各个测试用例是互相独立的。

尽量避免使用依赖的方法。

编写一个模拟的方法来取代使用外部依赖。

2.一般由代码的开发人员来实施，用以检验所开发的代码功能符合自己的设计要求。

益处：

1.能尽早发现缺陷。

2.有利于重构。

3.简化集成。

4.文档。

简化文档作用

5.用于设计。

限制：

1.不可能覆盖所有的执行路径，所以不可能保证捕捉到所有路径的错误。

2.每一行代码，一般需要3~5行测试代码才能完成单元测试。

所以存在投入和产出的一个平衡。

（二）集成测试（偏于技术角度验证）

是在单元测试完成的基础上针对已经完成单元测试的那些模块，把他们组成更高一级的模块和子系统，来针对这些子系统进行的集成。

各个最小单元模块之间的接口和子系统的集成。

主要实施方案：

1.BigBang。

也叫一次性集成。

就是把所有的东西组装好，然后再一起进行测试。

2.自顶向下。

是一个递增的组装软件结构的方法。

3.自底向上

4.核心系统集成。

5.高频集成。

高频次的不断地进行集成。

集成测试与单元测试的区别是：

1.测试对象不同

2.测试依据不同单元——主要；

集成——概要

3.测试的方法不同集成测试——关注接口之间的集成；

单元测试——关注单元的内部

（三）系统测试（偏于业务角度验证）

（一般测试岗位，主要集中在系统测试）

把整个系统组装以后置于真实的运行环境对这个系统进行全面的测试。

主要做功能测试、性能测试、稳定性测试等多种测试。

是将经过集成测试的软件，作为计算机系统的一个部分，与系统中其他部分结合起来，在实际运行环境下对计算机系统进行的一系列严格有效的测试，以发现软件潜在的问题，保证系统的正常运行。

关注点

1.关注系统本身的使用

2.关注系统与其他相关系统间的连通

3.关注系统在不同使用压力下的表现

4.关注系统在真实使用环境下的表现

系统测试&

集成测试区别

测试对象

集成测试：

由通过了单元测试的各个模块所集成起来的构件

系统测试：

除了软件之外，还包括计算机硬件及相关的外围设备、数据采集和传输机构、支持软件、系统操作人员等整个系统

测试时间

集成测试介于单元测试和系统测试之间测试

系统测试在集成测试之后

测试内容

各个单元模块之间的接口

整个系统的功能和性能

测试角度

偏于技术角度的验证

偏于业务角度的验证

（四）验收测试

从用户的角度对系统软件的认可验收。

也称交互测试。

针对用户需求、业务流程的正式的测试，确定系统是否满足验收标准，由用户、客户或其他授权结构决定是否接受系统。

定义：

交付测试。

针对用户需求、业务流程的正式的测试、确定是否满足验收标准，由用户、客户或者其他授权机构决定是否接受系统。

验收测试细分可分为

用户验收测试：

开发交付之前

运行验收测试：

运维的层面

合同和规范验收测试：

参照约定的规范验收，还有法律法规

alpha测试：

在开发环境中，由用户进行测试

Beta测试：

脱离开发环境由用户提供的环境下进行测试

二、软件测试手段

软件测试的分类：

按可见度：

黑盒白盒

按状态：

静态、动态

按测试执行方式：

手工、自动化

（一）黑盒测试

在完全不考虑程序内部结构和特性的情况下，通过暴露出来的接口对程序进行测试程序是否能正常接收输入，正确输出，一般针对界面或可见功能

用户视角，通过结果判断

优：

1.容易实施，不需要关注内部实现，操作简单

2.更贴近用户视角，测试场景与正式场景更接近

缺：

1.覆盖率较近，只能覆盖代码量的不足40%（不了解内部实现不知道内部分支）

2.针对黑盒的自动化测试，复用率较低，维护成本较高黑盒针对功能进行测试，变动较大，用例使用率较低

主要测试的地方（关注点）：

1.功能是否正确或遗漏

2.接口上输入、输出是否正确

3.数据结构或外部信息是否有访问错误

4.性能是否满足系统测试阶段主要使用黑盒测试其它各个阶段也会用到

黑盒测试的主要设计方法

1.等价类划分法：

针对程序有很多输入条件，把所有的输入把等价的归为一类，形成若干等价的代表形输入，通过典型数据进行测试用例的设计。

2.边界值分析法：

特殊的等价类划分，更关注各种边界条件，开发时容易出现失误的地方需要重点关注

3.错误推测法：

基于经验或直觉，判断出程序中容易失误的地方，从而制作测试用例例如：

特殊字符、文件不存在，或文件超大等

4.因果图法：

拿到程序的需求规格说明书，针对输入输出在因果图中看作原因和结果根据规划说明生成判断表

5.正交试验分析法：

主要用于筛选输入数据

6.状态迁移图法：

通过处理功能点的状态迁移关系，例如审批流程中的状态变化

7.流程分析法：

通过梳理逻辑程序的路径

（二）白盒测试

黑盒：

内部不可见

白盒：

逻辑结构对测试人员是透明的，又叫结构化测试或透明盒，通过对逻辑结构来设计测试用例。

用逻辑的覆盖率来测试逻辑的完整性。

逻辑的单位：

语句、条件、条件组合、分支、路径

语句覆盖：

保证每条语句至少被执行一次

判定：

条件覆盖：

覆盖表达式

分支是路径的一部分

1.迫使测试人员去仔细思考软件的实现，理解原理

2.可以检测代码中的每条分支和路径

3.揭示隐藏在代码中的错误

4.对代码的测试比较彻底

1.昂贵（较高的覆盖率，工作量大）

2.无法检测代码中遗漏的路径和数据敏感性错误

3.针对代码不是针对需求，不能正确验证需求实现是否正确

白盒测试的方法：

1.代码检测法：

对代码进行检测

2.静态结构分析法：

通过测试工具分析系统结构数据结构、内部控制逻辑来制定测试用例

3.静态质量度量法：

iso标准制作度量模型

4.逻辑覆盖法：

6种主要覆盖测试方法：

语句条件条件组合分支路径条件vs判定覆盖

5.基本路径测试法：

白盒中主要的一种测试方法在程序控制流图的基础上，通过分析控制构造复杂度导出基本可执行的路径的集合进而制作测试用例的方法

6.控制流图：

描述控制流

灰盒：

介于黑、白盒测试之间的，关注输入、输出的正确性、同时也关注内部表现

结合了黑、白的测试要素，主要用于组件的测试

（三）静态测试

静态测试：

无须执行被测程序，通过评审软件文档或代码，度量复杂度，检查软件是否符合编程标准以发现程序的不足之处，减少错误出现的概率

可以通过人工，也可以通过自动化工具

方式：

互审-走查（小组）-会议（记录正式），不正式到正式的集体活动

（四）动态测试

动态测试：

通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率、正确性和健壮性等

主要是动态测试方法

代码检查法和静态代码分析法就是典型的静态方法

（五）手工测试

手工测试：

由专门的测试人员从用户视角来验证软件是否满足设计要求的行为。

更适用针对深度的测试和强调主观判断的测试

手工测试方法：

众包测试、探索式测试

1.易发现缺陷2.容易实施3.更具有创造性、灵性性

1.覆盖量化难2.重复测试效率低3.不一致性、可靠性低（前后不一致）4.人力资源依赖

（六）自动化测试

自动化：

使用单独的测试工具软件控制测试的自动化执行以及对预期和结果进行自动检查

自动化测试方法：

单元测试、接口测试、性能测试等

1.高效率、速度快2.高复用性3.覆盖率容易度量4.准确、可靠5.不知疲劳

1.机械、发现缺陷率低，不具备创造性不灵活

2.一次性投入较大（从实施自动化测试之初、从测试工具的选型、框架的设计到自动化测试脚本的编写、维护都需要投入较大的精力和资源）

手工和自动化各有适用场景

三、软件测试模式

瀑布模型、敏捷测试、基于脚本的测试、基于风险的测试、探索式测试等。

（一）瀑布模型

瀑布模型：

项目计划、需求分析、软件设计、程序开发、软件测试、集成维护

项目计划：

制定总体的研发计划，确定主要的里程碑节点－输出项目计划书）

需求分析：

明确用户需求定义，并对定义进行清晰描述，充分理解需求，描述产品功能－输出产品需求规格说明）

软件设计：

根据需求定义，设计产品的实现方案，包括定义软件硬件的结构、组件、实现方法、接口、界面、数据－输出概要设计、详细设计

程序开发：

根据概要和详细设计具体实现，根据编程规范构建各类组件模块，输出产品版本。

软件测试：

通过独立的测试小组评估产品是否满足需求定义－输出测试报告

集成维护：

交付用户，根据用户使用情况进行维护及升级

优点：

1.强调需求、设计的作用；

2.前一阶段完成后，只需关注后续阶段；

3.为项目提供了按阶段划分的检查点，里程碑清晰；

4.文档规范

缺点：

1.难以适应需求的频繁变；

2.项目周期后段才能看到成果，增加了风险

3.强制的里程碑、完成时间点，适应能力差；

4.文档工作量大

（二）V模型（最广泛）

是瀑布模型的变种明确表明测试过程的不同级别，阶段：

单元测试－集成测试－系统测试－验收测试，并且描述了各个阶段与开发过程各个阶段的对应关系。

强调软件开发的协作和速度，反应测试活动和分析设计的关系，软件的实现和验证有机结合

仅把关系明确对应，忽略了对需求分析的验证，对需求和功能的测试到验收测试才能发现；

没有很好的体现测试的及时性

（三）W模型（双V模型）

开发与测试并行，可以尽早发现问题

1.增加了开发各个阶段的验证，测试的对象不再是对象，对需求和分析都有测试过程