软件测试的分类——按测试模式来分类

安测试模式来分类：

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

常用的测试模型

1、传统的瀑布模型——最早出现的软件开发模型

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

每一个阶段都是以上个阶段的输出作为下个阶段的输入。

项目计划：制定项目总体的研发计划，确定主要的里程碑节点。输出项目的技术书。

需求分析：明确用户需求定义，并对定义进行清晰描述。是充分理解客户需求，描述产品功能的重要阶段。输出产品的需求规格说明。

软件设计：根据需求的定义来确定产品实现方案。输出概要设计、详细设计等。

程序开发：开发团队具体实现。

软件测试：通过独立测试团队评估产品是否满足需求的定义。输出测试结果、测试报告。

集成维护：根据用户使用对产品进行必要的需改升级。

优点：

强调需求、设计的作用

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

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

文档规范

缺点：

难以适应需求的频繁变化

项目周期后段才能看到成果

强制的里程碑、完成时间点

文档工作量大

2、V模型——目前使用最广泛的模型（瀑布模型的变种）

表明了测试过程的不同阶段和开发各个阶段的对应关系

需求分析                                                             验收测试（确定软件是否满足用户的最终需求和合同的有关规定）

      概要设计                                              系统测试（软件在功能、性能这些质量特性上是否满足系统要求）

               详细设计                              集成测试（检测程序是否满足设计程序的要求）

                      软件编码           单元测试（检测程序是否满足设计程序的要求）

V模型强调了软件开发的协作和速度，反映测试活动和分析设计的关系，将软件的实现和验证有机结合起来

局限性：将需求分析放在了最后

3、W模型——测试伴随着开发周期进行

有利于尽早发现问题，改进了V模型

用户需求            验收测试设计                                           交付             验收测试

       需求分析             系统测试设计                              实施          系统测试

             概要设计                 集成测试设计                集成        集成测试

                    详细设计                  单元测试设计

                                                 编码                    单元测试

局限性：不能很好的支持迭代开发

4、X模型——针对V模型的改进

程序片段1                                                    封版

       测试设计                                         执行测试

              工具配置                             测试设计

                    执行测试                 工具配置

                           编码完整    迭代1....n

                    执行测试                   探索式测试

               工具配置

         测试设计                                        执行测试

程序片段n

左边：针对单独的片段进行的测试和编码，此后进行频繁的交接、集成

探索式测试：不进行事先计划的特殊测试，在测试计划之外发现更多错误

5、H模型——贯穿在整个软件生命周期

测试准备   测试就绪点   测试执行

                                                        测试流程

                                                        其他流程

其他测试模型

1、敏捷测试

Agile Testing——遵循敏捷宣言的一种测试实践

敏捷宣言

个体与交互  重于  过程和工具

可用的软件  重于  完备的文档

客户协作      重于  合同谈判

响应变化      重于  遵循计划

在每对比较重，后者并非全无价值，但我们更看重前者

敏捷测试

强调从客户角度进行测试；

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

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

强调持续反馈

预防缺陷重于发现缺陷

敏捷测试VS传统测试

传统测试：测试是质量的最后保护者；严格的变更管理；预先的计划和细节的准备；重量级文档；各阶段测试严格的入口和出口标准；

                    更多在回归测试时进行重量级的自动化测试；严格依赖流程进行；测试团队和开发团队是相对独立的

敏捷测试：开发和测试人员是紧密合作，大家都有责任对软件负责；变更是可接受的，拥抱变更；计划随时随着仅占市场调整；只需要绝对必要的文档；

                   各迭代之间已经没有明显的入口和出口标准；所有阶段都需要自动测试，每个人都需要做，是项目集成的一部分；流程不在需要严格执行；团队合作是无缝隙合作

2、基于脚本的测试——SBT

script-based Testing

Scripted Testing(ST)

Exploratory Testing(ET)探索式测试：完全抛开测试脚本的测试

          是一种测试风格、思维而不是一种测试技术

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

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

探索式测试优点：

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

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

在较短时间内找到更多Bug以及对SUT做一个快速的评估（SUT：soft ware and test）

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

更加适用于敏捷项目

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

缺点：

测试管理上有局限性，较难协调和控制

对于BUg的重复利用和重现上作用有限

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

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

ET的生产率很难定义

ET本身较难进行自动化

测试方法上分为：局部探索式测试和全局探索式测试（漫游测试法）

局部探索式测试五大要素：输入、状态、代码路径、用户数据、执行环境

全局探索式测试六大区

执行探索式测试：Know you Mession ——learning Session——Coverage Session——Deep Session——Close Session 

3、基于风险的测试——RBT（Risk-based Testing）

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

哪些是风险？

质量风险、管理风险

风险级别=风险可能性*风险严重度

识别风险

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

严重程度：使用频率、失效可视性、商业损失、组织负面影响和损害、社会损失和法律责任

风险要素风=sum（单项权重*得分）

4、基于模型的测试-MBT