目录
软件测试
一.软件生命周期
| 计划 | 需求分析 | 设计 | 编码 | 测试 | 运维 |
|---|---|---|---|---|---|
| 1.确定开发目标 | 1.分析整理项目需求 | 1.概要设计 | 1.代码的编写 | 1.单元测试 | 1.产品部署 |
| 2.可行性分析 | 2.根据需求，编制规格说明书 | 2.详细设计 | 2.集成测试 | 2.运行维护 | |
| 3.对项目进度进行预估和安排 | 3.制定产品原形 | 3.系统测试 | 3.功能升级 | ||
| 4.制定实施计划 | 4.验收测试 | 4.性能提升 |
注：
1. `单元测试：主要是对一个函数或者一个类进行测试` 2. `集成测试：对模块与模块之间的接口进行测试` 3. `系统测试：对编码完成的系统进行功能测试` 4. `验收测试：测试人员与客户一起进行测试`
二.模型
2.1 瀑布模型
按软件的生命周期顺序一个一个进行，但是存在测试后置的问题，导致如果在整个项目的开发完成之后更加难于修改，修改成本巨大。
2.2 V模型
-
测试阶段划分的很清楚
-
每个测试阶段都有对应的文档做支持
-
依然还是在开发编码结束之后再进行测试，开发与测试依然是串行的
-
测试对象依然只有代码，不包含其他需求文档
-
V模型是瀑布模型的变种，瀑布模型存在的问题V模型依然存在
2.3 W模型
1.不同于瀑布模型、V模型，，将开发与测试分离开来，它在进行开发的时候进行了测试，把测试前置，测试与开发并行进行，大大减少了整个项目的风险，并且包含了对需求文档和设计文档的测试。
2.4 敏捷模型
Productor Backlog:产品积压 ，相当于整个项目的模块
Sprint:迭代，从Productor Backlog中挑选出优先级相对高的若干需求安排到Sprint Backlog中，每个Sprint 一般是以一个月作为一个周期的
Productor Owner:产品经理，整理出整个项目的所有需求，并且按照需求的优先级来将需求排列到Sprint Backlog.
Daily meetings:每日会议， 采用站会的形式，小组成员每个人发育一般不超过一分钟，发言的内容一般为：昨天你干了生命，今天准备干什么，有什么风险和问题。
Sprint burn down:迭代燃烧图：记录该迭代剩余的工作量
一个迭代经过一个周期会产出，交由用户验收测试，小组进行Sprint review meeting,回顾本轮迭代的问题，并在后面的迭代中改进
Scrum Master:小组长，管理组员
三.质量模型
用来衡量一个项目的质量标准
质量模型中每个属性与测试类型具有映射关系，所以可以用不同的测试类型来测试不同的质量类型
-
测试类型
黑盒测试：指不知道代码与结构的情况下，站在用户的角度，按照需求规格书对系统功能进行测试
白盒测试：指了解代码与结构的基础上，对被测软件的代码和结构进行测试的过程
灰盒测试：介于黑盒测试和白盒测试之间，对接口进行测试，即知道函数名，参数，参数类型，不知道函数内部结构，对函数功能进行测试。
四.测试流程
-
分析：进行需求评审，测试需求分析，得到测试点
-
计划：测试计划和方案文档的编写
-
设计：测试样例设计
-
实现：编写测试样例（文档），测试脚本
-
执行：执行测试脚本，缺陷报告
4.1 需求的来源
-
合同型项目：
用户需求评审–>产品需求
-
产品型项目：
协议、标准、规范
继承性需求
竞品分析 （参考同类项目或者是竞争对手的产品）
4.2 需求评审
-
需求评审检查表
4.3 测试需求分析
-
为什么需要测试需求分析？
做测试之前，我们应该需要了解
1.测试的系统是干什么的？
2.系统有什么特点？
3.系统有那些功能？
4.系统的业务流程
5.系统这个版本，哪些需要测，哪些不需要测
6.系统对性能、安全性有什么要求？
-
测试需求分析流程
1.根据产品需求提取系统的测试点
2.编写需求跟踪矩阵
3.根据测试点利用适当的测试用例设计方法设计测试用例
-
测试用例的概念
测试用例就是一种用来说明具体如何进行测试操作并验证结果的文档
-
测试用例模板
-
用例编号 ：每个用例的标志，命名规则：TC软件名称模块编号
-
用例标题：标示这个用例是干什么的，那个测试点的
-
优先级：高中低，作用是用人不够或者项目时间不够的情况，我们可以优先测试重点的测试用例
-
预置条件：执行该用例时，系统要达到的条件或者状态
-
所属模块：属于那个模块
-
测试步骤：
-
预期结果：
-
实际结果：
-
测试结果： 有（Fail/Pass/NA）
-
备注：
-
五.测试设计方法
5.1 等价类法
- **定义**：划分输入集合，在同一个输入集合内的有效性是一样，即同一个输入集合内的任何一个输入测试没有问题，则相同输入集合内的输入也不会有问题。 - **有效等价类**：对程序有意义的，正确的输入 - **无效等价类**：对程序无意义的，错误的输入
-
常用的等价类划分法
-
如果输入条件限制了输入值的范围或者个数，则可以划分出1个有效等价类和2个无效等价类
例：登录模块中规定年龄必须是18~20，则输入为（18，20）的为一个有效等价类，输入为小于18或者大于20的就为2个无效等价类
-
如果输入规定了输入的条件或者是输入集，则可以划分出一个有效等价类和一个无效等价类
例：规定了学历必须是专科、本科、硕士，则这三种学历是一个有效等价类，不是这三种学历的是一个无效等价类
例：若规定输入必须为女性，则女性为一个有效等价类，男性为一个无效等价类
-
如果我们确知在已划分的等价类中的各个元素在程序中的处理方式不同，则应该将等价类进行进一步划分
例：若系统对专科、本科、硕士的处理不同，则还应该划分为专科、本科、硕士等价类
-
若规定了输入数据必须遵守的规则，可确立一个有效等价类和若干个无效等价类
例：若规定一个秘密必须由大写字母开头，6个数字组成，则这个为一个有效等价类，还有其他的无效等价类
-
-
如果输入条件是布尔值的情况下，可以划分出一个有效等价类和一个无效等价类