05 功能测试

软件模型：

开发模型（软件生命周期模型）是指软件从开始研制到最终被废弃所经历的各个阶段，在不同的阶段中，由不同的组织和人员执行不同的任务。

常见软件开发模型：

瀑布模型：

特点：线性模型；每个阶段只执行一次；文档驱动
优点：只需要关注当前进行的阶段
缺点：不响应需求变化；风险往往延迟到后期才出现，失去了及早纠正的机会。
应用场景：大型项目，银行、保险、建筑…

敏捷模型（快速原型模型）：

特点： 快速的构建软件的原型；支持用户的参与。
优点： 克服瀑布模型的缺点，减少了由于软件需求不明确带来的开发风险。
缺点： 不适合大型系统的开发。

螺旋模型：

特点： 引入了风险分析活动。
优点： 是一种风险驱动的方法体系。
缺点： 需要丰富的风险评估经验。

常见的软件测试模型：

V模型：

优点： 即包含了底层测试，又包含了高层测试。
缺点： 当需求变更时，返工量大，灵活性低。

W模型：

优点：测试贯穿软件开发的全生命周期；早参与，早发现，早解决。
**缺点：**技术和管理要求比较高。

软件质量模型：

功能性：关注业务功能使用。
可靠性：容错性能（恢复正常的时间、能力），纠错能力
易用性：易读，易懂
效率：时间、性能（响应时间，消耗的资源（CPU,内存））要求
可维护性：软件运维人员去维护公司现有项目，为后续功能的开发与维护提供便利。
可移植性：在不同软件、硬件平台都能正常工作。
ISO：国际标准
GB：中国标准

软件测试用例：

测试用例：一个为了特定目的（验证产品的功能实现能否满足用户需求）而设计的包含（测试输入、执行条件、预期结果）的文档，文档的形式：Excel、xmind等。

标题	测试输入	执行条件	预期结果
验证电脑开机功能	有电	按下开机键	屏幕点亮

软件测试用例的作用：

1. 便于理清测试思路，确保覆盖测测试的功能点无遗漏
2. 便于测试工作量的评估
3. 便于提前准备测试数据
4. 便于把控测试工作进度
5. 便于回归测测试
6. 便于测试工作的组织，提高测试效率，降低测试交接成本

测试用例元素

1. 标识符：测试用例编号
2. 测试标题：对测试用例的简单描述
3. 前置条件：为测试步骤提供执行步骤前的准备环境
4. 输入数据
5. 操作步骤
6. 期望结果
7. 所属模块
8. 优先级
9. 用例性质：正例/反例

等价类用例设计方法：

等价类：在所有测试数据中，具有某种共同特征的数据子集。通过科学的方法找到具有共同特征的测试输入的子集，能够从穷举测试中解放出来。
有效等价类：满足需求的。
无效等价类：不满足需求的。

等价类划分法设计测试用例：

步骤：
1：需求分析
2：划分等价类：有效/无效（规则，长度，类型，是否为空，是否重复）
3：设计测试用例
用例优先级：
P0：一般为保证软件中最主要、重要的功能，最基本的流程能够正常运行而设计。
P1：次要功能，小功能。
P2：UI、边界、错误的设置。
P3：错误信息，较复杂的场景，不常用的场景。

边界值：

等价类划分法的一种补充手段。
测试经验表明错误往往会发生在输入或者输出范围的边界上。
边界值概念：对输入或输出的边界值【有效等价类和无效等价类的界限】进行测试的一种黑盒测试方法。

上点：区分有效和无效的分界点，边界之上的点。
内点：有效等价类里面的任意一点，边界之内的点。
离点：分界点附近的点，离边界最近的左右两点。

判定表：

存在多个输入条件，多个输出结果，输入和输入之间有组合关系，输入和输出之间存在制约关系。

判定表的组成：

条件桩：所有输入条件。
动作桩：所有的可能的输出结果。
条件项：单个条件的取值范围，一般都是有效等价类和无效等价类。
表示方法：字符：真/有效等价类/Y，假/无效等价类/N
数字：真/有效等价类/1，假/无效等价类/0
动作项：基于每一种条件的组合，得到确认的结果。
测试用例的步骤：

1. 明确条件桩（找到所有输入条件）。
2. 明确动作桩（找到所有输出结果）。
3. 对条件桩进行全组合。
4. 明确每个组合对应的动作桩（基于每一种条件的组合情况， 确定本组合下的输入结果）。
5. 设计测试用例，每行数据对应一条测试用例。

使用场景：多条件组合情况。

因果图：

用图解的方法表示输入的各组合关系，写出判定表，进而设计测试用例的一种黑盒测试方法。
适用范围：适用于分析程序输入条件的各种组合情况，以及输入和输出之间的依赖关系。
基本符号：
恒等：- 条件成立，结果成立。
非：～ 条件成立，结果不成立；条件不成立，结果成立。
或：V 只要有一个条件成立，结果就成立。所有条件都不成立时，结果才不成立。
与/且：^ 多个条件必须同时成立，结果成立。只要有一个不成立，结果就不成立。
测试用例的步骤：

1. 需求分析
2. 画出因果图
3. 将因果图转换为判定表
4. 生成测试用例

正交法：

用最小的测试用例获得最大的测试覆盖率
正交表：一种特制的表，一般的正交表标记为：Ln(m^k)
k表示因素（输入参数）
m表示水平（输入参数的取值）
n表示测试用例数
测试用例的步骤：

1. 需求分析
2. 确定因素与水平
3. 确定要采用的正交表
4. 将正交表中的字母用文字代替
5. 设计测试用例（一行就是一条测试用例）

场景法：

概念：模拟用户操作软件时的场景，主要用于测试多个功能之间的组合使用情况。
使用在集成测试、系统测试、验收测试。
测试用例的步骤：

6. 需求分析
7. 绘制流程图
8. 设计测试用例（一条路径流程就是一条测试用例）

错误推测法

利用经验和智慧发现程序中可能犯错的地方。

测试用例设计方法总结：

• 具有输入功能，但输入之间没有组合关系：等价类
• 输入有边界，如长度、类型：边界值
• 多输入，多输出，输入和输入之间存在组合关系，输入和输出之间存在依赖关系：判定表、因果图
• 用最少的测试用例获得最大的测试用例：正交法
• 多个功能的组合测试：场景法、流程图
• 最后推荐使用错误推测法来进一步补充测试用例

缺陷

软件缺陷的定义：软件产品中存在的问题，最终表现为用户所需要的功能没有完全实现，不能满足或者不能全部满足用户的需求。

缺陷的判定标准：

1. 未达到需求说明书指明的功能
2. 出现了需求说明书指明不应该出现的错误
3. 实现了需求说明书之外的功能
4. 未达到需求说明书虽未明确提及但是应该实现的目标
5. 用户角度发现的各种问题与错误

缺陷的产生原因及根本原因：

缺陷产生的原因：需求文档存在错误
设计存在错误：代码错误
缺陷产生的根本原因：需求变更；沟通不畅，信息不同步；软件复杂；进度压力。

软件缺陷的核心内容：

1. ID：唯一的识别缺陷的序号
2. 标题：对缺陷进行概括性的描述
3. 前置条件
4. 环境：缺陷发现时所处的测试环境，包括操作系统、浏览器等
5. 操作步骤
6. 期望结果
7. 实际结果
8. 严重程度
9. 优先级
10. 缺陷类型
11. 缺陷状态
12. 缺陷提交人
13. 缺陷指定解决人
14. 版本信息
15. 模块

缺陷的基本要素：

• 缺陷编号：缺陷的唯一性标志

• 缺陷状态：表示缺陷当前处于哪个阶段

• 常见缺陷状态：
  new：新建，表示缺陷刚创建
  open：打开，表示已经指派或者开发认领了bug
  inprogress：进行中，表示开发正在修改中
  fixed：已修复，表示测试可以验证了
  closed：已关闭，表示测试验证通过
  reopen：重新打开。
  rejected：已拒绝，表示开发拒绝了当前bug
  postpone/delay：已延迟，表示开发延迟修复该bug

• 缺陷所属模块：缺陷属于哪个被测的模块

• 缺陷严重程度(Severity)：该缺陷的破坏性能或影响程度
  常见严重等级：
  Fatal：最严重等级，导致系统的主要功能完全丧失，用户数据受到破坏，系统崩溃，死机等。
  Critical：系统的主要功能部分丧失。
  Major：系统的次要功能没有完全实现，但不影响用户的正常使用。eg：提示信息不正确，操作时间长。
  Minor：操作不方便，但不影响功能的操作和执行。

• 缺陷优先级(Priority)：处理该缺陷的优先程度
  immediate
  urgent
  veryhigh
  high
  medium
  low

• 缺陷类别：用于分类整理缺陷
  功能错误
  界面（UI）错误
  兼容性缺陷
  易用性
  改进建议
  其他

提交缺陷注意事项：

• 核心要素
• 基本要素
• 可重现：缺陷可以复现
• 唯一性：一个缺陷上报一个问题
• 规范性：符号公司或者项目要求
• 准确：描述的信息是争取的
• 具体：有细节且是真实特定的
• 简介易懂：描述简单容易理解
• 次序清晰：描述缺陷过程有条件，有先后顺序

缺陷跟踪管理过程：

缺陷跟踪流程：

场景1:确认bug解决
测试【new】= = 》开发【open】= =〉开发【fix】= =》测试【close】
场景2:验证未通过，缺陷仍存在
测试【new】= =〉开发【open】= =〉开发【fix】= =》测试【reopen】
场景三：开发延期处理
测试【new】= =〉开发【open】= =〉开发【postpone】
场景四：拒绝处理
测试【new】= =〉开发【open】==〉开发【reject】

缺陷管理工具—禅道

他是一个国产开源项目管理软件，整合了BUG管理，测试用例管理，发布管理，文档管理等功能。在禅道软件中，明确的将产品、项目、测试三者概念区分开，产品人员、开发团队、测试人员，三者分立，互相配合、制约。通过需求、任务、BUG来进行互动，最终通过合作使产品达到合格标准。

安装过程

安装方式1（我自己用的）：
一键集成安装包，点击start.exe启动

安装方式2（mac用的这种）：这是tpshop项目用的
解压安装包zentao.zip
解压后的zentao/zentaopms的内容复制到phpstudy的/www目录下。
启动Phpstudy，并在浏览器中输入相关地址localhost/zentaopms/www即可

使用过程

1. 新建部门和用户

   1. 建立部门
   2. 新建用户
      
      

2. 建立产品和需求

   1. 产品经理进入禅道系统，添加产品
      
   2. 产品经理再去提需求
      

3. 新建项目、组建团队、关联需求、分配任务

   1. 项目经理登录禅道，添加项目（这里我登陆错误了，我登陆到产品经理上面了）
      

   2. 组建团队
      
      点击”团队管理“进入页面（这里纠正了）
      

   3. 点击”项目“—”需求“— ”+关联需求“ 来管理该项目的需求并保存
      
      
      

4. 开发人员领取任务，并提交测试版本

   1. 开发人员登录禅达，进入任务页面，可以查看任务
      
   2. 当开发人员完成一项任务后，保存完成的任务.进入”版本“进行测试版本的提交

5. 测试人员跟踪BUG！！！

   1. 测试人员登录禅道，进入“项目”—“任务”，查看任务
      

   2. 提bug，并将bug指派给开发
      
      
      禅道中提交一个bug的都有哪些内容：
      所属产品、所属模块、所属项目、影响版本、当前指派、截止时间、BUG类型、Bug标题、重现步骤、相关需求、相关任务。。
      

   3. 开发人员解决bug
      
      6.测试人员验证Bug

      1. Bug修复完成的情况：
         点击关闭bug即可
         

      2. 如果bug并没有修复好，那么再次编辑bug状态，此时bug状态设置为激活再次指派给开发人员。