今天完成的事：

了解了解整个项目和测试的流程

了解关于敏捷测试

明天计划的事：

把任务二的知识点整理出来

学习任务三

遇到的问题：

主要解决在测试流程方面的疑问，

收获：

敏捷测试

特点：

强调从客户角度进行测试

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

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

强调持续反馈

预防缺陷重于发现缺陷

敏捷宣言

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

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

客户协作     重于  合同谈判

响应变化     重于  遵循计划

敏捷测试VS传统测试

传统测试：

测试是质量的最后保护者

严格的变更管理

预先的计划和细节的准备

重量级文档

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

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

严格依赖流程执行

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

敏捷测试：

开发和测试人员是紧密合作，大家都有责任对软件负责

变更是可接受的，拥抱变更

计划随着进展时常调整

只需要绝对必要的文档

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

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

流程不再需要严格执行

团队合作是无缝隙合作

基于脚本的测试-SBT

Script-based Testing

Scripted Testing（ST）

Exploratory Testing（ET）

探索式测试（ET）

完全抛开测试脚本的测试。

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

一般是通过探索我们的被测系统，带着问题来使用我们的被测系统并在探索的过程中发现测试的要点，找出我们被测系统的问题。

在测试的过程中测试执行和测试设计是并行的。

ST  VS  ET

ST：

系统性强

容易管理、控制

设计在先，执行在后

主要是验证自己的思路

可预见性

ET：

自由灵活

和ST是互补的

执行和设计并行

不断和系统交互，带着问题测试

对系统深入学习的过程

探索式测试的优点：

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

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

在较短时间内找到更多Bug以及对SUT作一个快速的评估

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

更加适用于敏捷项目

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

探索式测试的缺点：

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

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

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

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

ET的生产率很难定义

ET本身较难进行自动化

探索式测试从方法上还可以划分为：局部和全局探索式测试

局部探索式测试：

一般从被测系统的五大要素入手：

输入：接受输入、产生输出、存储数据、进行运算主要任务

测试时一般从输入顺序，输出内容，输出异常几个角度考虑测试要点

状态：

从状态看可以分成：临时状态和永久状态

临时状态有：

运行时有效、阶段有效

永久状态：

数据库保存、文件保存

状态的信息可以有效的帮我们判断测试输入和测试输出

代码路径：更多的是指对代码路径的覆盖

用户数据：真实的用户数据

执行环境：系统环境

（全局探索式测试还没了解，明天把全局探索测试了解学习到位）