软件测试模式-敏捷测试

软件测试模式-敏捷测试
Agile Testing——遵循敏捷宣言的一种测试实践

一、敏捷宣言

个体交互重于过程和工具
可用的软件重于完备的文档
客户协作重于合同谈判
响应变化重于遵循计划
注：在每对比较中，后者并非全无价值，但我们更看重前者。

二、敏捷测试的特点

强调从客户角度进行测试。
重点关注迭代测试新功能，不在强调测试阶段。
尽早测试，不间断测试，具备条件即测试。
强调持续的反馈。
预防缺陷重于发现缺陷。

三、敏捷测试VS传统测试的区别

1、传统测试：

测试是质量的最后保护者。
严格的变更管理。
预先的计划和细节的准备。
重量级文档。
各个阶段测试严格的入口和出口标准。
更多在回归测试时进行重量级的自动化测试。
严格依赖流程执行。
测试团队和开发团队是相对独立的。
2、敏捷测试：
开发和测试人员是紧密合作，大家都有职责对软件负责。
变更是可接受的，拥抱变更。
计划随着进展时常调整。
只需要绝对必要的文档。
各迭代之间已经没有明显的入口和出口标准。
所有阶段都需要自动测试，每个人都需要做，是项目集成的一部分。
流程不再需要严格执行。
团队是无缝隙合作。

四、基于脚本的测试

1、SBT（Script-based Testing）：
强调的是先做测试设计，然后在做测试。
2、ST（Scripted Testing）：
强调的是先做测试设计，然后在做测试。
3、ET（Exploratory Testing）：
探索式测试

五、探索式测试（ET）

1、定义：
完全抛开测试脚本的测试。它是一种测试风格、思维而不是一种测试技术。

六、ST VS ET的区别：

1、ST（Scripted Testing）:

系统性强；
容易管理、控制；
设计在先，执行在后；
主要是验证自己的思路；
可预见性；
2、ET（Exploratory Testing）：
自由灵活（测试人员的主观性和创制造性）；
ET和ST（Scripted Testing）是互补；
执行和设计（思考）并行；
不断和系统交互，带着问题测试；
学习的过程。

七、探索式测试的优缺点：

1、优点：

更能激发测试人员的创造性和工作乐趣。
增加了发现新的或较深入Bug的可能性。
在较短时间内找到更多Bug以及对SUT（被测系统）作一个快速的评估。
有利于更加有效地实施自动化。
更加适用于敏捷项目。
减少了在简单、繁复上用例的无谓编写时间。
2、缺点：
测试管理上有局限性，较难协调和控制。
对于Bug的重复利用和重现上作用有限。
对测试人员的测试技能和业务知识深度依赖较大。
只有在SUT（被测系统）已完全可用的前提下才更有作用。
ET的生产率很难定义。
ET本身较难进行自动化。

八、探索式测试的分类：

1、局部探索式测试
2、全局探索式测试

九、局部探索式测试的五大要素：

1、输入：
接受输入，产生输出，存储数据，进行运算四种主要任务。输入顺序，输出内容，输出异常几个角度考虑测试要点。
3、状态：
临时状态（运行时有效，阶段性有效）、永久状态（数据库保存、文件保存）；
3、代码路径：对代码的覆盖。
4、用户数据：模拟实际应用的数据。
5、执行环境：软件运行的操作系统、网络拓扑、第三方系统、系统的配置数据、硬件设备

十、全局探索式测试（漫游式测试法）测试要素：

商业区：软件从启动到关闭，用户可能使用到系统部分功能。
旅馆区：软件在未运行状态下的功能，后台任务或者是定时的功能。
历史区：版本遗留代码的功能或者是以前测试中发现更多问题的功能。
旅游区：新用户的使用比较关注的功能，例如新手指引，新用户的注册。
娱乐区：系统主要功能之外的辅助性功能。
破旧区：系统已经废弃的或者隐藏的，用户看不到的功能。

十一、探索式测试的工作流程（Session为例）：

1、Know You Mession：
知道测试的重点，测试方向、测试的环境、总体测试思路。
2、Learing Session：
详细的学习和探索系统，了解系统的业务逻辑，集体的功能，深入学习被测系统。
3、Coverage Session：
主要的探索式测试的实施阶，主要功能点的测试验收，完成测试点的覆盖，尽可能的把需要测试的东西都要测试到。
4、Deep Session：
进一步深入的进行发散性探索式测试，挖掘一些深层次的问题。
5、Close Session：
对前面的测试工作进行总结，总结探索测试的过程，整理测试信息，根据记录和总结分析有没有遗漏，覆盖率的问题。

十二、基于风险的测试

1、RBT（Risk-based Testing）：
基于对软件失效的风险评估并以此指导测试计划、设计、执行、结果评价的软件测试类型。

十三、测试过程中什么算是风险？

1、质量风险：
质量问题，例如软件的功能、应用性、性能、软件功能的缺失、数据的转换等。
2、管理风险：
人员的技能不足，项目的人力不足，测试环境不具备，被测系统的需求不够清晰，系统关联第三方系统有问题。
3、风险级别 = 风险可能性 x 风险严重度

十四、识别风险的角度：

1、可能性：

复杂性：被测系统越复杂，所产生的复杂性就越大。
时间压力：项目的周期越紧张，时间越短，风险就越大。
高变更率：项目中需求变更率非常快。
技能水平：研发人员的技能水平，对系统实现方法的熟练程度。
地理分散度：研发团队分布的地理位置，影响研发效率。太过分散，则存在网络、集成上会出现潜在的问题。项目集中部署或是分布部署存在的风险是不一样的。
2、严重程度：
使用频率：功能的使用频率越高，严重程度就越高。
失效可视性：发生的问题越可见，则风险更加的严重。
商业损失：如果功能失效，产生直接的商业损失，损失越大，问题就越严重。如计费、支付功能。
组织负面影响和损害：功能的失效可能会给组织带来负面影响。
社会损失和法律责任：
3、风险要素分 = Sum（单项权重*得分）

十五、RBT的优点：

正常情况下，测试工作量的增加，风险成下降的趋势。版本的质量能够更加的得到保证。

十六、基于模型的测试

1、MBT（Model-based testing）：
是软件测试的一个类型，它的测试用例是从一个模型当中完整或是部分导出得到的，这个模型描述了被测系统的某些方面，通常是功能方面。
网址：https://blogs.msdn.microsoft.com/sechina/2009/11/18/123/
2、主要的MBT建模工具：