软件测试的理论基础1

软件的生命周期

可行性研究和计划（立项）
需求分析
概要设计（测试计划）
详细设计（测试方案）
实现（开发阶段；包含单元测试）
组装测试（集成测试）
确认测试（系统测试，验收回归测试）
使用和维护（上线使用及日常更新维护）

什么是软件测试

定义：在规定条件下对程序进行操作，从而发现问题，对软件质量进行评估的过程

软件测试的目的：

以最少的人力、物力、时间找到软件中的缺陷并修改，从而回避商业风险。

软件测试的定义：

使用人工和自动手段来运行程序，目的在于检验是否满足了需求

软件测试的原则

1. 所有测试追溯到用户需求
2. 把尽早和不断的测试，最为座右铭
3. 测试工作要由专业人员来执行
4. 80%的错误出现在20%的模块中
5. 设计测试用例（测什么？怎么测？）时，要考虑各种情况
6. 一定要写缺陷报告
7. 制定严格的测试计划
8. 完全测试是不可能的，测试需要终止
9. 注意回归测试（修改了旧代码后，要确认没有引入新的问题）
10. 妥善保存一切测试文档

软件质量模型（iso9126）

1、 功能性
2、 可靠性（1、尽量不出问题；2、出了问题不能影响主体功能；3、如果影响了主体功能，要能尽快修复）
3、 易用性（用户体验要好）
4、 效率
5、 可维持性（更新）
6、 可移植性（跨越不同系统平台）

软件质量模型保证（SQA）

目的：使软件制作的过程对于领导层是可见的。
定义：它是一套计划和方法来向领导层保证。
五个基本目标：
1、 保证有计划地进行，
2、 保证遵循了步骤和需求
3、 及时通知给对应人员
4、 高管可以接触到项目内部
5、 软件质量需要测试工作来保证

qc和qa

qc：检验产品的质量
qa：审计过程的质量
工作关系：qc进行质量控制，qa是确保qc按照步骤执行。

软件测试流程

1、 需求分析
2、 编写测试用例（测什么 怎么测）
3、 评审测试用例
4、 搭建测试环境
5、 等待程序的开发包
6、 部署测试包
7、 冒烟测试（测试主体功能是否有问题）
8、 执行测试用例
9、 Bug跟踪处理（回归测试）
10、N轮之后符合要求
11、 测试结束

软件测试工作流程图

立项阶段
需求阶段
设计阶段
编码&单元测试阶段
集成测试阶段
系统测试阶段
验收测试阶段
结项总结阶段

2、软件测试的分类

软件开发阶段划分：

1. 单元测试
   测试阶段：编码后或者编码前；
   测试对象：最小模块；
   测试方法：白盒测试；
   测试内容：模块接口测试，局部数据结构测试，路径测试，错误处理测试，边界测试；
2. 集成测试
   测试阶段：单元测试以后；
   测试对象：模块间的接口；
   测试方法：黑盒测试+白盒测试；
   测试内容：模块之间的数据传输，模块之间的冲突，模块组装功能正确性，全局数据结构；
3. 系统测试
   测试阶段：集成测试以后；
   测试对象：整个系统（软、硬件）；
   测试方法：黑盒测试；
   测试内容：功能、界面、可靠性、易用性、性能、兼容性、安全性等
4. 回归测试
   回归测试指修复bug后，重新进行测试以确认修改后没有引入新的错误；
5. 冒烟测试
   一般在开发人员开发完毕后给测试人员进行测试时，测试人员会先进性冒烟测试；
   冒烟测试就是给产品加电，测试能否正常启动；
   验证基本的流程是否能正常启动，不用关心细节。
6. 验收测试
   最后一个阶段的测试，确保产品准备就绪。
   测试阶段：系统测试之后；
   测试对象：整个系统；
   测试方法：黑盒测试；
   测试内容：功能、界面、可靠性、易用性、性能、兼容性、安全性等

按测试实施分

1. α测试
   α测试是由用户在开发环境下进行的测试；（开发和测试人员不能参加）
2. β测试
   β测试是由软件的最终用户在一个或者多个场所进行测试；

α测试和β测试的区别：

1. 测试场所不同：Alpha测试指把用户请到开发方的场地来测试，β测试时一个或多个用户在不同场所进行测试；
2. alpha测试的环境是受开发方控制的，用户数量较少，时间比较集中；beta测试的环境是不受开发方控制的；alpha测试先于beta测试；
3. 第三方测试
   介于开发方和用户之间的第三方的测试；

按是否运行分

1. 静态测试
   指不运行被测程序本身，通过分析源程序的语法，结构，过程等检查程序的正确性；
   代码静态分析和文档测试都属于静态测试；
2. 动态测试
   指通过运行程序，检查运行结果和预期结果的差异，并分析运行效率，正确性等；

按是否手工分

1. 手工测试
   由手工一个一个去输入测试用例，然后观察结果；
   优点：思维发散；
   缺点：执行效率慢，量大易错；
2. 自动化测试
   简单的说自动化测试就是以人为驱动的测试行为转化为机器执行的一个过程；
   通常所说的自动化测试是指功能测试自动化；

自动化测试的步骤：

1. 完成功能测试，版本基本稳定；
2. 根据项目特性，选择合适项目的自动化测试工具，并搭建环境；
3. 提取手工测试的测试用例转化为自动化测试的用例；
4. 通过工具、代码实现自动化的构造输入，自动检测输出结果是否符合预期；
5. 生成自动化测试报告；
6. 持续改进，脚本优化；

按是否查看代码分

1. 黑盒测试
   黑盒测试也叫功能测试，把被测试软件当成一个黑盒子，不关心内部结构是什么，只关心软件的输入与输出数据；
2. 白盒测试
   白盒测试是基于代码的测试，需要打开盒子，去研究里面的代码和执行结果；
3. 灰盒测试
   灰盒测试是介于白盒测试和黑盒测试之间的一种测试，多用于集成测试阶段，不仅关心输入输出的正确性、同时也要关注程序内部的情况；

其他测试

随机测试

针对软件中的重要功能进行复测

探索性测试

一遍了解和学习项目，一遍测试项目

测试过程模型

V模型在这里插入图片描述

优点：
既包含了底层测试，又包含了高层测试
每个步骤都是文档驱动的
缺点：
当需求变更时将会导致阶段反复，返工量非常大，模型灵活性比较低

W 模型

优点：
1.测试伴随软件的整个生命周期，在需求分析结束后就可进行需求分析测试。
2.测试与开发是并行的便于发现问题（可同时进行，提高效率）
缺点：
1.对于有些项目，开发过程中根本没有文档产生，所以W模型无法使用。
2.对于需求和设计的测试技术要求很高，实践起来很困难。

测试用例

测试用例是为了实施测试而向被测试的系统提供的一组集合
集合包括（八大要素）：用例编号，用例标题，测试项目，用例级别，预置条件，测试输入，操作步骤，预期结果等；

测试用例的设计方法？

等价类：依照需求将输入划分为若干个等价类；

超市买水果
有效等价类：苹果、桃子、梨
无效等价类：青菜、米、饮料，…

边界值：对输入输出的边界值进行测试；

1. 输入框长度为1-11，取边界值为：0、1、11、12
2. 运动员的参赛项目为1-3项，取边界值为：0项、1项、3项、4项
3. 查询面页面有999行，每50行为一页，取边界值为：输出0行、1行、
   50行、51行、999行

因果图：表明程序输入条件和输出动作之间的相互关系；（对于复杂的输入和输出关系，会耗费大量的时间）

因果图设计测试用例的步骤：

1. 分析所有可能的输入与输出；
2. 找出输入与输出之间的对应关系；
3. 画出因果图；
4. 把因果图转换成判定表；
5. 把判定表对应到每一个测试用例；

因果图中的对应关系：
恒等：如果输入为真，那么输出就为真。

与：如果两个输入都为真，那么输出就是真。

或：如果输入中有一个为真，那么输出就为真。

非：只有输入为假，输出才为真。

案例一： 假设业务单据的处理规则为：“淘宝618活动，提单已提交，订单合计 金额大于300元或有红包，则进优惠”。

1. 对于这条业务规则，首先通过分析所有可能的输入和可能的输出， 可以得到如下结果： ● 输入：订单已提交、金额大于300、有红包。 ● 输出：优惠、不优惠。

2. 然后，进行第二步，找出输入与输出之间的对应关系。通过分析， 可以看出有以下的对应关系。 (1)订单已提交，订单金额大于300元，则优惠。(2)订单已提交，订单金额小于等于300元，无红包，不优惠
   (3)订单已提交，有红包，则优惠。 (4)订单已提交，订单金额大于300元，有红包，则优惠。 (5)订单未提交，不优惠。

3. 为了方便画出因果图和判定表，需要对所有输入和输出编号，现在 编号如下。 1：订单已提交。 2：订单金额大于300元。 3：有红包 21：优惠 22：不优惠

4. 画因果图

5. 画判定表：有3个条件,输出有2个取值，所以表的列数为2x2x2=8

6. 最终的测试用例 1，2，3，4，5（包含6，7，8）。

正交排列法：

场景设计法： 想象需求的场景来设计测试用例;

错误猜测法：根据直觉找出有可能出现的错误，有针对性的设计测试用例

软件测试的生命周期?

需求分析 —> 测试计划 — 测试设计、测试开发 — 测试执行 — 测试评估

bug定义

软件或者程序中存在的各种问题

bug判定标准

软件没有达到需求说明书标明的功能
软件出现了需求说明书指明不会出现错误的地方。
软件超出了需求说明书指明的范围A
软件出现了需求说明书虽未指明,但应该达到的目标
软件难以使用,效率低下

bug产生的根源

需求变更
交流不充分
软件的复杂性
进度压力

缺陷(bug)分析需要注意的点

哪个模块问题最多
哪个测试工程师测试的缺陷最多
各类缺陷数量占比
开发是否可以及时修复缺陷
开发人员一次修复缺陷占比
软件是否可以正常发布

bug的级别

1. Blocker（崩溃）
   造成系统崩溃、死机、死循环、导致数据库丢失、与数据库连接错误等问题
   （一单出现，立即中止当前版本的测试）
2. Critical（严重）
   系统主要功能丧失，数据库保存调用错误，用户数据丢失等但是不影响其他功
   能的测试。
3. Major（一般）功能没有完全实现但是不影响使用，如操作时间长、查询时间长等
4. Minor（次要）
   界面、性能缺陷，建议性问题

bug的生命周期

从open到closed

New：新发现的bug，未经评审决定是否要指派给开发人员进行修改。
Open：确认是bug，并且认为需要修改，指派给相关开发人员。
Rejected：如果认为不是bug，则拒绝修改。
Delay：如果认为暂时不需要修改或者暂时不能修改，则延迟修改。