软件测试概念（二）

四、测试手段

按测试手段来分类：

        测试对象的可见度：黑盒测试、白盒测试

        状态：静态测试、动态测试

       测试执行的方式：手工测试、自动化测试

黑盒测试：在事件驱动与用户需求的指引下，关注输入的内容，会产生什么样的输出

优点：1.容易实施，不需要关注内部的实现

            2.更贴近用户的使用角度

缺点：1.测试覆盖率较低，一般只能覆盖到代码量的不到40%

            2.针对黑盒的自动化测试，复用率较低，维护成本较高。

黑盒测试：关注功能、测试接口，对内部逻辑不考虑

主要测试内容：

          1.是否有不正确或遗漏的功能？

          2.在接口上，输入是否能正确的接受？能否输出正确的结果？

          3.是否有数据结构错误或外部信息（例如数据文件）访问错误？

          4.性能上是否能够满足要求？

系统测试更多的使用黑盒测试来实现。

主要设计方法：等价类划分法、边界值分析法、错误推测法、因果图法、正交实验分析法、状态迁移图法、流程分析法

 

白盒测试：针对逻辑结构来测试

主要的逻辑单位：语句、条件、条件组合、分支、路径

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

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

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

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

缺点：1.昂贵（较高的覆盖量）

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

              3.不能直接验证需求的正确性

主要测试方法：代码检测法、静态结构分析法、静态质量度量法（标准的质量模型）、逻辑覆盖法、基本路径测试法

 

灰盒测试：（系统组件层）介于黑、白盒测试之间的，关注输出对于输入的正确性，同时也关注内部表现

 

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

方式：互审、走查、会议（从不正式取向与正式）

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

 

黑盒测试：偏向于动态测试

白盒测试：静态测试

 

手工测试：由专门的测试人员从用户视角来验证软件是否满足设计要求的行为。更适合针对深度的测试和强调主管判断的测试。如：众包测试、探索室测试等。

 

自动化测试：使用单独的测试工具软件控制测试的自动化执行以及对预期和结果进行自动检查。如：单元测试、接口测试、性能测试等。

手工测试VS自动化测试

手工测试：易发现缺陷；容易实施；创造性、灵活性；覆盖量化难；重复测试率低；不一致性、可靠性低；人力资源依赖；

自动化测试：高效率、速度快；高复用率；覆盖率容易度量；准确、可靠；不知疲劳；机械、发现缺陷率低；一次性投入较大

五、测试模型

按测试模式来分类：瀑布模式、敏捷测试、基于脚本的测试、基于风险的测试、探索式测试等。

 

瀑布模式：

项目计划：按阶段划分的检查点，输出项目计划书

需求分析：输出产品的需求规格说明

软件实现：产品实现方案，输出概要设计等

程序开发：输出程序版本

软件测试：输出测试结果、测试报告

集成维护：交给开发商后的后期维护

 优点：1.强调需求、设计的作用；2.前一阶段完成后，只需关注后续阶段；3.为项目提供了按阶段划分的检查点，里程碑清晰；4.文档规范

 缺点：1.难以适应需求的频繁变化；2.项目周期后段才能看到成果；3.强制的里程碑、完成时间点；4.文档工作量大

V模型：（软件开发的协作）

W模型：（开发与测试同时进行）

X模型：

 

H模型：

 

敏捷测试：（AT）

1.强调从客户角度进行测试

2.重点关注迭代测试新功能，不在强调测试阶段

3.尽早测试，不间断测试，具备条件即测试

4.强调持续反馈

5.预防缺陷重于发现缺陷

传统测试与敏捷测试：

传统测试：1.测试是质量的最后保护者；2.严格的变更管理；3.预先的计划和细节的准备；4.重量级文档

                    5.各阶段测试严格的入口和出口标准

                    6.更多在回归测试时进行重量级的自动化测试

                    7.严格依赖流程执行

                    8.测试团队和开发团队是相对独立的

敏捷测试：1.开发和测试人员是紧密合作，大家都有责任对软件负责； 2.变更是可接受的，拥抱变更

                    3.计划随着进展时常调整；4.只需要绝对必要的文档

                    5.各迭代之间已经没有明显的入口和出口标准；

                    6.所有阶段都需要自动测试，每个人都需要做，是项目集成的一部分

                    7.流程不再需要严格执行

                    8.团队合作是无缝隙合作

基于脚本的测试—SBT（Script-basedTesting或ST）

Exploratory Test（ET）探索式测试：完全抛开测试脚本的测试

ST与ET的比较：

ST：系统性强；容易管理、控制；设计在先、执行在后；主要是验证自己的思路；可预见性

ET：自由灵活；与ST是互补的；执行和设计（思考）并行；不断和系统交互，带着问题测试；学习的过程

ET优点：

1.更能激发测试人员的创造性和工作乐趣

2.增加了发现新的或较深入Bug的可能性

3.在较短时间内找到更多Bug以及对SUT（被测系统）作一个快速的评估

4.有利于更加有效地实施自动化

5.更加适用于敏捷项目

6.减少了在简单、繁复用例上的无谓编写时间

缺点：

1.测试管理上有局限性，较难协调和管理

2.对于bug的重复利用和重现作用上有限

3.对测试人员的测试技能和业务知识深度依赖较大

4.只有在SUT已经完全可用的前提下才更有作用

5.ET的生产率很难定义

6.ET本身较难进行自动化

局部探索式测试：输入（输出）、状态（临时、永久）、代码路径（对代码的覆盖）、用户数据（模拟实际用户数据）、执行环境（操作系统、网络拓扑、硬件设备、其他系统）

全局探索式测试：漫游测试法

执行探索式测试：

（1）测试总体思路

（2）学习被测系统、业务逻辑，具体功能

（3）实施阶段，完成测试点的覆盖

（4）发散式测试，更深入地进行测试

（5）总结过程，分析测试有没有遗漏

 

基于风险的测试（RBT）

一种基于对软件失效的风险评估并以此为指导测试计划、设计、执行、结果评价的软件测试类型

 类型：质量风险（功能、性能）；管理风险（测试环境、被测系统关联的第三方系统安全性不够）

识别风险：

可能性：复杂性，时间压力，高变更率，技能水平，地理分散度

验证程度：使用频率，失效可视性，商业损失，组织负面影响和损赛，社会损失和法律责任

优点：优先测试高风险问题的测试，要准确识别风险

 

基于模型的测试（MBT）

对需求功能点建模

借助工具建模实施

主要的MBT工具：

Spec Explorer（Microsoft）

GraphWalker（OpenSource）

Tcases（OpenSource）

Modeljunit（OpenSource）