软件的测试对象
程序+文档+数据
什么是软件测试
使用人工和自动手段来运行或测试某个系统的过程，其目的在于检验它是否满足规定的需求，并找出被测系统与预期结果之间的差异；
软件测试的目的
尽早尽可能多的发现被测系统中的缺陷和错误，通过不断的修复各种缺陷和错误从而提高被测系统的质量，避免被测系统上线后由于潜在的缺陷和错误造成的商业风险；
软件测试的原则
- 所有测试都应该以用户的需求为主
- 测试人员应该把“尽早地和不断的进行软件测试”当作座右铭
- 不能穷尽测试
- 测试人员只能证明被测软件存在缺陷，不能证明被测软件不存在缺陷；
- 软件开发周期各个阶段都可能产品错误，不应把软件测试当作软件开发中的一个独立的阶段，软件测试应该贯穿 软件开发的各个阶段
- 开发人员应该避免测试自己的程序
软件测试的分类
按照软件是否运行分为：静态测试和动态测试；
1）静态测试
不通过运行程序或者系统的方式去验证被测对象是否存在缺陷，如代码，产品说明书等。
2）动态测试
通过运行程序或者系统的方式去验证被测对象是否存在缺陷。
按照测试技术分为：黑盒测试，白盒测试，灰盒测试；
1）黑盒测试
黑盒测试又称为功能测试又称为数据驱动测试；可以把被测的软件程序当做一个黑盒子，看不见盒子里面的东西（即看不到代码的编写和实现的逻辑）；测试员只有给盒子里输入数据，然后通过查看盒子里出来的结果去验证软件是否存在问题；
1.1）黑盒测试设计测试用例的方法
1.1.1、等价类划分法
- 当有大量的输入数据需要穷举进行测试时，把测试数据按照共同的特征分成一个个小的子集合的方法称为有效等价类划分法；
- 有效等价类：所有数据集合中符合需求，在这个集合中取一个即可，
- 无效等价类：所有数据集合中不符合需求，在这个集合中取一个即可。
- 步骤：
- 1、明确需求
- 2、根据需求明确 参数，长度，类型，规则
- 3、划分有效等价，无效等价
- 4、用例编写
1.1.2、边界法
- 边界值法其实是对等价类划分法的一个补充，主要针对等价类中长度进行边界的测试（重点在边界值）
- 常用词语描述：大小，尺寸，重量，最大，最小，至多，至少
- 典型代表：有边界值范围的输入框类测试
1.1.3、错误推断法
- 定义：通过经验推测系统可能出现的问题
- 适用场景：时间紧任务重，没有时间编写用例
1.1.4、场景法
- 场景法又称为流程图法，
- 分为基本流和备选流，一般一个版本提测后，先测试版本的基本流进行冒烟测试；
1.1.5、判定表法
- 当有多个输入条件，多个输出结果，输入条件之间有组合关系，输入条件和输出结果之间有依赖（制约）关系
- 判定表一般适用于条件组合数量较少的情况（比如4个条件以下）
1.1.6、因果图法
2）白盒测试
白盒测试又称透明盒测试，顾名思义可以把被测的软件程序当作一个透明的盒子，盒子里面的东西能够看的清清楚楚（即能够看到代码里面的编写逻辑）；测试员可以根据代码检查结果判断可能出错的数目，并据此定制测试；
2.1）白盒测试设计测试用例的方法？
2.1.1、条件覆盖
2.1.2、路径覆盖
3.1.3、待定
3）灰盒测试
灰盒测试介于白盒测试和黑盒测试之间的一种测试方法：不仅关注输出、输入的正确性，同时也关注程序内部的情况。
按照软件开发阶段分为：单元测试，集成测试，系统测试，验收测试；
1）单元测试
单元测试又称为模块测试，是针对软件设计中最小单位的程序模块进行验证的测试工作；单元测试主要采用白盒测试的手段，根据详细设计对模块进行测试，需要测试人员编写驱动模块和桩模块
2）集成测试
集成测试又叫组装测试（接口测试），通常在单元测试的基础上，将所有程序模块进行有序的、递增的测试。重点测试不同模块的接口部分。
3）系统测试
指将整个软件系统看为一个整体进行测试，包括对功能、性能、以及软件所运行的软硬件环境进行测试。
4）验收测试
验收测试指按照项目任务书或合同、供需双方约定的验收依据文档进行的对整个系统的测试与评审，决定是否接收或拒 收系统。在系统测试的后期，以用户测试为主或有测试人员等质量保证人员共同参与的测试。
α测试：指的是指的是由用户，测试人员、开发人员等共同参与的内部测试。
β测试：指的是内测后的公测，即完全交给最终用户测试验收测试的重要性：验收签字,收钱。
UTA测试：
按照测试类型不同分为：功能测试，界面测试，性能测试，兼容性测试，安全测试，易用性测试，压力测试，负载测试，重复性测试
1）功能测试：根据需求文档验证程序的功能是否能够正常使用，符合需求文档中的定义；
2）界面测试：根据UI图对程序的页面进行测试，或者发现设计不符合常规给出建议；
3）性能测试：程序处理某一功能时，响应数据的时间，CPU利用率，内存利用率等；
4）兼容测试：程序是否能够在不同的软件+硬件环境下正常使用，界面展示正常；
5）安全性测试：
6）易用性测试：程序的设计是否易于用户的理解，学习和使用；
7）压力测试：使用软件在不够理想的环境下运行--CPU慢，内存小，磁盘空间少，观察软件对外部资源的要求和依赖程序
8）负载测试：通过不断的给软件提供条件任期发挥，找出软件能力的上限
9）重复性测试：不断的重复执行同一操作可查出内存泄露
其他测试
1）问题回归测试：是指将该版本上一轮的问题进行验证，验证问题是否改好；
2）回归测试：将上一轮测试重新再测试一遍，验证修改的代码或者新增的功能是否对原有的功能造成影响；
3）随机测试：没有任何目的的对程序进行操作，一般对在测试结束之后进行的补充操作（如果有空余时间）；
4）冒烟测试：是指在对一个版本进行测试之前，先对版本的主功能进行测试（走一步）
软件的生命周期
是指一个软件从开始研制到最终放弃不用这整个过程成为软件的生命周期
软件生命周期的六个阶段：
- 问题定义及规划阶段--需求是否可行
- 需求分析/评审阶段--针对需求详细设计
- 软件设计阶段
- 概要设计--当前项目基于什么架构，有几个模块，数据库怎么设计，模块之间数据传递；
- 详细设计-具体到每个模块怎么实现，数据怎么存储；
- 软件编码阶段
- 软件测试阶段
- 单元测试
- 集成测试
- 系统测试
- 验证测试
- 软件运行维护阶段
软件开发生命模型
- 瀑布模型：
问题定义及规划--
需求分析--
设计--
编码--
测试--
上线维护
优点：
为项目提供了按阶段划分的检查点
当前阶段完成后，需求关注后续阶段
缺点：
测试人员介入测试的时间较晚，问题在后期才会被暴露出来，回溯成本高；
如要回溯则会导致整个测试周期时间长，增加重复性的工作量
不益于需求频凡变动的项目
- 敏捷开发模型
是一种以人为核心、迭代、循序渐进的开发方式，就是将一个大项目分为多个相互关联，但也可以独立运行的小项目并分别完成，在此过程中软件一致处于可使用状态；
适用于需求的变化，并且能够给出快速的响应
软件测试模型
- V模型：
优点：
测试人员在项目最开始的时候介入测试，降低项目的成本，缩短开发周期；
清楚的标识了开发和测试的各个阶段
缺点：
实际工作中，需求经常变化，导致v模型步骤，反复执行，返工量很大，灵活度较低。
- W模型：
优点：
测试伴随整个产品开发周期，体现了测试对象不仅有程序还有测试文档的设计和验证过程
测试尽早的介入项目，能够较早的发现问题，降低修复的成功
缺点：
开发和测试依然是线性的关系，需求的变更和调整，依然不方便；
如果没有文档，根本无法执行w模型；对于项目组成员的技术要求更高！
软件测试的流程
1、需求评审
2、规划测试计划，测试策略
3、根据需求文档，设计测试用例，编写测试用例
4、用例评审
5、执行测试
6、记录缺陷
7、测试结束，编写测试报告
什么是测试用例
测试用例是根据项目需求而编写的一组包含 测试输入，执行条件以及预期结果的文档；主要用来验证被测软件是否符合需求文档的定义；编写测试用例的唯一标准是用户的需求，具体参考资料为需求文档；
主要包含像用例编号，用例名称，前置条件，测试步骤，测试数据，预期结果，所属模块等；
软件的质量
程序或者系统满足用户明确需求和隐含需求相一致的程度。
软件质量-国家标准：
- 功能性
- 适应性
- 准确性
- 互操作性
- 数据安全性
- 效率性
- 时间特性
- 资源利用率
- 可靠性
- 成熟度
- 容错性
- 易恢复性
- 易用性
- 易学习性
- 易理解性
- 易使用性
- 吸引性
- 可维护性
- 易分析性
- 易改变性
- 稳定性
- 易测试性
- 可移植性
- 易安装性
- 适应性
- 共存性
- 易替换性
8、什么是缺陷
缺陷是指在软件或者系统中存在导致软件或者系统不能正常运行的错误或者问题；
缺陷的定义：
1、软件未实现需求文档中明确指出需要完成的功能；
2、软件中出现需求文档中明确指出不能出现的问题；
3、软件实现了需求文档中没有需要完成的功能；
4、软件未实现需求文档中没有明确指出但却需要实现的功能；
5、软件难以理解，不易使用，运行缓慢或者-从测试员的角度看-最终用户会认为不好；
缺陷的类型：
- 功能错误
- UI错误，兼容
- 数据，易用性，改进建议，架构
一个软件测试缺陷的原因？
1、需求文档没有设计全
2、需求文档中的需求频繁更改
3、整个项目团队沟通不彻底
缺陷不用被全部修复的原因？
1、时间太紧
2、修改此缺陷改动较大
3、不算真正的软件缺陷
4、这个缺陷不值得被修复
9、缺陷的生命周期
一个bug被发现 -- 开放状态；
缺陷被指派到开发人员手里，开发人员已修复 -- 已解决未验证状态；
新一轮测试版本对bug进行回归验证，此缺陷没有问题 -- 已关闭状态；
测试进行回归验证，此缺陷依然存在问题 -- 重新打开状态；
10、一个缺陷包含的属性
1）缺陷名称
2）缺陷的优先级别
3）缺陷的严重级别
4）经办人，报告人
5）缺陷的描述（所在环境，所用版本，出现缺陷的步骤，预期结果，实际结果，日志，截图，录屏）
