软件

1.软件是什么

程序、文档、数据

2.软件的生命周期

1.基本概念

软件生命周期是指一个计算机软件从功能确定、设计，到开发成功投入使用，并在使用中不断地修改、增补和完善，直到停止该软件的使用的全过程（从酝酿到废弃的过程）。

2.软件分为哪几个阶段

软件的一生：问题定义->可行性分析->需求分析->概要设计->详细设计->编码和单元测试->综合测试->软件维护

软件的开发模型

瀑布模型、原型模型、螺旋模型、敏捷模型

软件的开发文档

需求分析文档、概要设计文档、详细设计文档、测试设计文档、测试用例、测试报告

软件测试

定义：检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别
目的：发现问题、检查系统是否满足需求

1.软件测试分类

2.生命周期各测试方法的对比

3.常见的软件测试模型

• 瀑布模型
• V模型
• W模型
• 敏捷模型
• 螺旋模型
• H模型
• X模型

4.测试流程

①.需求分析、编写测试用例、评审测试用例、搭建环境、等待程序开发包、部署程序开发包、冒烟测试、执行具体的测试用例细节、Bug 跟踪处理回归测试、N 轮之后满足需求，测试结束

②.测试需求或计划–>测试设计（测试计划、测试方案、测试策略、测试用例）–>测试执行（提bug、回归测试）–>测试评估–>测试总结（测试报告）

测试策划

测试需求–>测试计划–>测试控制

测试需求

需求验证：①.审查需求文档；②.以需求为依据编写测试用例；③.确定合格标准

测试需求实战–支付宝新增余额宝

测试策略

5W1H：(what)测什么；(why)为什么这么测；(where)测试环境;(when)测试时间的安排；（who）参与测试的人员；（how）如何展开测试
测试策略要素：1.测试安排发布计划；2.测试范围；3.测试资源（人力和工具）；4.测试环境；5.测试方法；6.用例设计方法；7.文档管理；8.风险管理；9.上线跟踪验证

测试方案&&测试计划&&测试策略

测试计划=测试策略+测试任务分配+时间进度安排
测试方案=测试计划+用例设计方案+工具选择+自动化/性能测试具体方案
例：货币基金消费测试方案分析过程

1. 分析需求（需求文档）；
2. 测试计划（负责人、任务分配以及测试时间安排）；
3. 测试范围、测试重点（哪些部分需要测试，重点放在什么地方，优先级安排）；
4. 测试策略及工具（是否需要进行自动化、性能、安全测试；使用哪些工具）；
5. 测试用例设计方法（等价类？边界值？场景法？因果图？等等）
6. 测试环境（服务器、数据库？配置如何）；
7. 联调测试（是否需要与第三方或其他部门联调）；
8. 测试限制（哪些内容无法测试：如消费到账）；
9. 测试风险

测试方案评审

4.测试用例

测试用例是通过使用在测试计划中确定的测试技术，对于已确定的测试条件进行逐步推敲，精炼而设计出来的重点说明如何具体操作产生何种结果的文档。

关键点

1. 用例编号----唯一的
2. 用例名称----言简意赅，用最少的字描述清楚这个用例做什么
3. 前提条件----执行这个用例前，软件必须满足的条件
4. 优先级-----执行这条用例的时间要求紧急的等级
5. 重要级----这个被测的功能在系统的重要级别
6. 测试步骤
7. 测试数据
8. 预期结果
9. 实际结果

测试用例常见的设计方法

1.等价类划分法：有效等价类和无效等价类
2.边界值法：找到边界值和它两端的值进行测试
3.因果图设计法：“因”——输入条件；“果”——输出结果
适用于输入/输出条件的相互制约关系以及组合关系
4.判定表设计法:根据因果图来制作判定表（因果图可以不画）
5.场景法：主要用来测试业务流程；分为基本流（正确流程）和备选流（错误流程）；冒烟测试主要使用场景法
6.流程分析法：适用于有先后顺序的测试：常用于业务流程、安装流程等
7.错误判断法：凭着直觉和经验设计测试用例，它是根据之前项目相关的bug数据总结出来的
8.正交表：从全面实验中挑选出有代表性的点进行测试（均匀分散，整齐可比）；高效率、快速、经济的方法；使用方法：根据控件和取值选择一个合适的正交表；列举取值并编号，生成取值表；把取值表与正确的正交表进行映射；ps:混合正交表工具（allpairs）

测试用例方法的选择

1. 如果测试功能和流程，选择场景法
2. 需要输入数据的地方，我们使用等价类划分法，要注意配合边界值法来详细测试
3. 如果有条件组合的情况，我们使用因果图制作判定表
4. 配置类软件，组合比较多的，我们使用正交表科学的选择测试用例
5. 依靠经验追加一些测试用例（错误推断法）

5.软件缺陷

定义：缺陷就是软件的问题，最终表现为没有满足用户的需求

1.哪些属于软件缺陷

1. 软件未达到规格说明书表明的功能
2. 软件出现了规格说明书中指明不会出现的错误
3. 软件功能超出了规格说明书指明的范围
4. 软件未达到规格说明书虽未指明但应达到的目标
5. 软件测试人员或用户觉得不好

2.软件缺陷的表现形式

1. 功能、特性没有实现或者部分实现
2. 设计不合理、功能不明确、逻辑不清楚或存在矛盾
3. 实际结果与预期结果不同
4. 没有达到规格说明书要求的性能指标
5. 运行出错、崩溃、中断、界面混乱
6. 数据不正确、精度不够、不完整、或格式不统一
7. 用户不能接受的其他问题，如存取时间过长、界面不美观
8. 硬件或软件存在问题

• 软件缺陷的信息
  缺陷id、缺陷状态、标题、严重程度、优先级、所属模块/分类 、记录者、提交时间、处理人、处理结果描述、处理时间、详细描述（缺陷重现步骤）、环境说明、必要附件

3.软件缺陷的状态

1. 提交–测试人员提交了一个缺陷给程序员
2. 打开–待处理
3. 拒绝–程序员认为不是缺陷或者重复，就可以修改状态为拒绝
4. 修复–程序员修复缺陷后提交的一个状态
5. 关闭–测试人员经过回归测试后，认为此缺陷已解决，将其关闭
6. 推迟–可以放在后续版本解决的问题，但是要详细写出修复的日期或版本

4.软件缺陷的严重程度划分

1. low–表面性错误，例如错别字
2. medium–影响一个相对独立的功能、仅仅发生在特定条件、与需求定义不一致、断断续续出现问题
3. high–功能点没有实现、不符合用户需求、导致数据丢失
4. veryhigh–频繁死机、大部分功能不能使用
5. critical–系统瘫痪、异常退出、死循环、严重的计算错误

5.软件测试的优先级

1. low–时间和资源允许的情况下修复
2. medium–不会延迟发布，会在以后修复
3. high–会制约开发和测试的进行，需要在发布之前修复
4. veryhigh–影响系统，产生严重影响
5. urgent–导致系统几乎不可用

6.软件缺陷的分类

1. 系统缺陷
2. 数据缺陷
3. 数据库缺陷
4. 接口缺陷
5. 功能缺陷
6. 安全性缺陷
7. 兼容性缺陷
8. 性能缺陷
9. 界面缺
10. 建议

7.缺陷报告

注意事项

1. 尽量保证缺陷可以重现
2. 简洁、准确、完整
3. 一个缺陷报告只写一个缺陷

书写规范

1. 标题简洁，提供缺陷的本质信息即可
2. 复现的步骤要详细，用数字编号
3. 实际结果要描述清楚复现后的结果
4. 列出期望结果
5. 提供附件
6. 提供严重性属性和其他公司需要填写的属性

注意：

1. 避免使用情绪化语言和强调标点符号；
2. 避免使用模糊的词语
3. 避免使用自认为幽默的语言，直接描述问题即可
4. 避免提交不确定的缺陷

6.软件测试工具

1.介绍

QC是一款缺陷管理工具，可以管理项目测试的所有阶段（需求、测试用例、测试执行测试用例、提交缺陷、回归测试）
全称：quality center ；之前属于mercury（是一个软件测试工具开发商，QC、QTP、LoadRunner）；之后被HP收购
QC最新版本ALM：Application LifeCycle Management

2.学习QC的目标

1. 可以了解软件测试的基本流程
2. 可以了解其他的缺陷管理工具的使用
3. 可以自己定制缺陷生命周期流程（举例：new新建–>open分配–>fixed修复–>reopen重开–>fixed修复–>close关闭）

由于qc安装环境过老，这里不做学习。

3.禅道的安装

从官网下载安装即可 访问时可以通过：http:ip地址:8080/index.php 进行访问

4.禅道的使用流程

1. 新建角色

步骤：①.使用管理员登录；②.点击组织菜单；③.选择用户，点击添加用户，或者点击“批量添加”

2. 创建产品

步骤：①.由产品经理登录禅道；②.点击产品菜单；③.添加产品
注意：①.产品负责人：可以选择当前产品人员；②.测试负责人：选择产品经理；③.产品代号：内部的一个名称，只要相关人员知晓即可

3. 创建产品计划

步骤：①.由产品经理登录禅道；②.进入产品中，点击计划菜单
好处：①.可以帮助产品人员控制产品的研发过程；②.帮助相关人员了解产品进度，以做好后续工作安排

4. 创建产品模块

步骤：①.由产品经理登录禅道；②.进入产品中，点击模块菜单
好处：可以帮助产品人员对产品有一个宏观认识

5. 需求创建

步骤：①.由产品经理登录禅道；②.进入产品中，点击需求菜单

6. 需求评审

当需求提出以后为草稿状态，需要产品主管对需求进行评审
评审状态：确认通过、有待明确、拒绝
只有进入激活状态的需求才可以进入后续的开发
（需求评审是一个线下会议，由多人决定，评审完后再禅道添加记录即可）

7. 需求变更

跟评审步骤类似

8. 建立项目

召开立项会（产品经理告诉项目人员会议须知，项目组成员估算完成需求的工作量，对需求进行任务分解）；

步骤：①.由项目经理登录禅道；②.进入项目中，点击添加项目菜单
好处：①.可以帮助产品人员控制产品的研发过程；②.帮助相关人员了解产品进度，以做好后续工作安排

添加团队

确定项目中的需求：点击需求–>点击关联需求

分解需求：将需求分解给相应的开发以及测试人员；点击需求–>选择需求–>点击分解任务按钮；（注意：任务类型（事务：可以指派给多个人，主要用来做总结））

9. 开发阶段

1.领取任务以及每天工作量（当剩余时间为0时，自动提示结束任务）；

2.创建版本：步骤：①.由开发人员登录禅道；②.进入项目中，点击版本菜单，创建版本
注意：版本名称 ：产品名_版本号_状态_日期

3.版本关联需求：（注意：默认版本是不可以直接关联需求的，所以需要管理员赋予权限，即通过管理员登录–>进入组织菜单–>选择权限–>找到开发组–>点击权限维护–>找到版本–>选择关联需求）

4.提测

10. 测试阶段

编写测试用例：步骤：①.由测试人员登录禅道；②.进入测试中，点击用例菜单添加用例

用例关联版本:步骤：①.由测试人员登录禅道；②.进入测试中，点击版本/测试单–>选择关联用例即可

用例评审：禅道用例评审默认是关闭的，如果要对用例进行评审，管理员登录–>后台–>自定义–>用例–>评审流程开启即可

执行测试用例：步骤：①.由测试人员登录禅道；②.进入测试中，点击用例点击执行（当在执行过程中如果出现bug，直接转bug）；③.提交bug（可以在用例执行过程中提bug，也可以在bug菜单里提bug）

解决bug：开发人员确认该bug的存在，点击解决

回归测试：回归过程中，测试人员确认bug是否解决，没有则激活；如果不存在则关闭，如果过一段时间又出现，则重新激活

7.测试报告

测试报告的内容：

1. 报告信息
2. 引言
   编写目的以及指出预期的读者范围；
   项目背景–对项目目标和目的进行简要说明
   系统简介–如果设计说明书有此部分，照抄；注意必要的框图和网络拓补图能吸引眼球
   评测产品–对测试对象的描述；包括但不限于文件/程序所在SVN路径，SVN版本号等信息
3. 测试概要

• 包括测试的一些声明、测试范围、测试目的等等，主要是测试情况简介
• 用例设计方法–简要概述
• 测试环境配置–简要介绍（数据库服务器配置、CPU、内存；硬盘：可用空间大小；操作系统、应用软件、局域网地址、服务器配置）
• 测试方法与工具

4. 测试结果与缺陷分析
   主要汇总各种数据并进行度量，度量包括对测试过程的度量和能力评估、对软件产品的质量度量和产品评估
   测试执行情况与记录
   测试组织
   覆盖分析：需求覆盖率（经过的测试的需求/功能和需求规格说明书中所有需求/功能的比值，通常情况下要达到100%的目标）；测试覆盖：需求/功能 用例个数 执行总数 未执行 未/漏测分析和原因
   缺陷分析:对上述缺陷和其他收集数据进行综合分析；用例质量（缺陷总数/测试用例总数*100%）；缺陷密度（缺陷总数/功能点总数）；测试曲线图（描绘被测系统每工作日/周缺陷数情况，得出缺陷走势和趋向）
   残留缺陷和未解决问题
5. 测试结论与建议
   测试执行是否充分（可以增加对安全性、可靠性、可维护性和性能描述）
   是否可以进入下一阶段项目目标
   对测试风险的控制措施和成效
   测试目标是否完成
   测试是否通过
   建议：描述测试所揭露的软件缺陷和不足以及可能给软件实施和运行带来的影响；可能存在的潜在缺陷和后续工作；对缺陷修改和产品设计的建议；对过程改进方面的建议
6. 测试限制

8.验收测试

• α测试（内测）
  用户在开发环境下进行的测试
• β测试（公测）
  软件的多个用户在一个或多个用户的实际使用环境下进行的测试