测试技术深似海，看这一篇你就能明白！

目录

一、定义

二、测试和调试的区别

三、基本概念

1.需求

 2.软件错误（BUG）

3.软件的生命周期

四、开发模型和测试模型

1.开发模型

①瀑布模型

②螺旋模型

③增量模型

④敏捷模型

 2.测试模型

①V模型

②W模型

五、软件测试

1.软件测试生命周期

2.软件测试的分类

①按是否查看代码划分

②按开发阶段划分

六、BUG

1.BUG级别

①Blocker（崩溃）

②Critical（严重）

③Major（一般）

④Minor（次要）

2.BUG生命周期

3.产生争执怎么办

七、测试用例

 1.测试用例基本要素

2.测试用例设计方法

 ①基于需求的设计方法

 ②等价类

 ③边界值

 ④错误猜测法

⑤判定表法

 ⑥正交表法

 ⑦场景设计法

---

一、定义

最简单的理解就是找BUG，发现缺陷。

软件测试是为了验证软件产品特性是否满足用户需求。

软件测试的特点：不可穷尽性

二、测试和调试的区别

测试：为了测试软件特性（功能相关、肺功能相关）是否解决了该解决的问题。贯穿了软件的整个生命周期，主要由测试人员和开发人员共同完成。黑盒测试测试人员来做，单元/测试主要由开发人员来做。

调试：为了完成程序员想做的事。生命周期只是软件开发阶段。主要由开发人员来做。

三、基本概念

1.需求

满足用户期望或正式规定文档（合同、标准、规范）所具有的条件和权能，包含用户需求和软件需求。

用户需求： 可以简单理解为甲方提出的需求，如果没有甲方，那么就是终端用户使用产品时必须要完成的任务。该需求一般比较简略。

软件需求： 或者叫功能需求，该需求会详细描述开发人员必须实现的软件功能。

软件需求是测试人员进行测试工作的基本依据。

测试工程师在需求分析和设计阶段就开始介入 ，因为这个阶段是理解和掌握软件的原始业务需求的最好时机。

 2.软件错误（BUG）

当且仅当规格说明是存在的并且正确，程序与规格说明之间的不匹配就是错误。

当需求规格说明书没有提到的功能，判断标准以最终用户为准： 当程序没有实现其最终用户合理预期的功能要求时，就是软件错误。

3.软件的生命周期

软件生命周期是指从软件产品的设想开始到软件不再使用而结束的时间。

软件的生命周期可以分成 6 个阶段，即需求分析、计划、设计、编码、测试、运行维护。

需求分析：分析需求是否正确、是否完整。

计划：项目上线时间、开发时间、测试时间.....

设计：技术文档、UI设计稿（图片）

编码：开发人员写代码

测试:测试软件是否有BUG。

运行维护：上线、对上线出现的问题进行解决。

四、开发模型和测试模型

1.开发模型

①瀑布模型

在软件开发中具有重要地位，是所有模型的基础框架。

 

特点：每个阶段只执行一次，是线型顺序进行的开发模型。适用于较小的项目。

优点：具有阶段性的特点。

缺点：该模型只依赖于唯一一次的需求调查，不能适应需求的变化。并且风险只会在最后出现，无法纠正，会出现大面积返工的现象。

②螺旋模型

在初期阶段需求不明确时采用的渐进式的开发模型。

比较适合规模庞大、复杂度高、风险大的项目。

 优点：能够不断改进软件性能，可以全过程进行风险管理。

缺点：不允许有独立的测试时间和阶段。当开发迭代产生新的时，我们就要开始新一轮的测试。

③增量模型

把软件系统模块化，每个模块作为增量组件，分批次的分析和设计代码。

 缺点：如果系统很难被模块化，就会给增量带来麻烦。

④敏捷模型

敏捷模型的开发模型有很多种，scrum是最流行的一种。

• 个体与交互重于过程和工具
• 可用的软件重于完备的文档
• 客户协作重于合同谈判
• 响应变化重于遵循计划
• 在每对比对中，后者并非全无价值，但我们更看重前者。
• 轻流程重交互拥抱变化

 scrum有三个角色：

product owner（产品经理）、scrum master（项目经理）、team（研发团队）

 2.测试模型

①V模型

 流程：

用户需求：PM收集用户需求，产出软件需求。

需求分析与系统：分析需求是否正确，需求是否完整。

概要设计：语言、框架、项目结构设计。

详细设计：技术文档（接口、库表、定时任务.....）

编码：开发人员写代码

在前五个阶段测试人员没有加入过

单元测试：测试一个一个的单元

集成测试：测试每一个模块

系统测试：把项目运行起来，进行整体测试。

验收测试：产品、运营、用户/甲方爸爸验收。

特点：线性、左边开发、右边测试、是瀑布模型的变种，每个阶段做什么事情非常清晰，测试被划分为很多类型。但是测试人员介入太晚，造成问题会回溯浪费很多时间；测试和开发是串行的。

②W模型

 特点：开发一个V测试一个V；测试人员尽早介入，测试与开发并行。但是遇到问题也需要回溯并且耗费时间多，不能拥抱变化；相对来说，测试人员的每一步都需要依赖开发人员的步骤，一定程度上还是串行的，不适用敏捷开发流程。

五、软件测试

1.软件测试生命周期

软件测试的生命周期： 需求分析 → 测试计划 → 测试设计、测试开发 → 测试执行 → 测试评估

需求分析与软件生命周期中的需求一致。

测试计划：谁测试、测试开始时间、测试结束时间、上线时间

测试设计：设计测试用例

测试开发：开发测试工具、开发自动化测试用例

测试执行：提交BUG、验收

测试评估：产出测试报告（邮件）

2.软件测试的分类

软件测试的分类有很多种，下面只讲两种。

①按是否查看代码划分

黑盒测试

黑盒测试就是在完全不考虑程序逻辑和内部结构的情况下，检查系统功能是否按照需求规格说明书的规定正常使用、是否能适当的接收输入数据而输出正确的结果，满足规范需求。

• 优点

不需要了解程序内部的代码以及实现，不关注软件内部的实现。

从用户角度出发设计测试用例，很容易的知道用户会用到哪些功能，会遇到哪些问题，锻炼测试人员的产品思维

测试用例是基于软件需求开发文档，不容易遗漏软件需求文档中需要测试的功能。

• 缺点

不可能覆盖所有代码

黑盒测试用到的测试方法有，等价类，边界值，因果图，场景设计法，错误猜测法等。

白盒测试

通过检查软件内部的逻辑结构，对软件中的逻辑路径进行覆盖测试；在程序不同地方设立检查点，检查程序的状态，以确定实际运行状态与预期状态是否一致。

主要包含六种测试方法： 语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖、路径覆盖 。

②按开发阶段划分

单元测试

单元测试是对软件组成单元进行测试。其目的是检验软件基本组成单位的正确性。测试的对象是软件设计的最小单位：模块。又称为模块测试

测试内容：模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试

集成测试

集成测试将程序模块采用适当的集成策略组装起来，对系统的接口及集成后的功能进行正确性检测的测试工作。集成主要目的是检查软件单位之间的接口是否正确。

测试内容：模块之间数据传输、模块之间功能冲突、模块组装功能正确性、全局数据结构、单模块

缺陷对系统的影响

系统测试

将软件系统看成是一个系统的测试。包括对功能、性能以及软件所运行的软硬件环境进行测试。

测试内容：功能、界面、可靠性、易用性、性能、兼容性、安全性等

验收测试

部署软件之前的最后一个测试操作。它是技术测试的最后一个阶段，也称为交付测试。验收测试的目的是确保软件准备就绪，按照项目合同、任务书、双方约定的验收依据文档，向软件购买都展示该软件系统满足原始需求

测试内容：同系统测试 ( 功能 ... 各类文档等 )

六、BUG

1.BUG级别

①Blocker（崩溃）

阻碍开发或测试工作的问题；造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。如：代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用等（该问题在测试中较少出现，一旦出现应立即中止当前版本测试）。

②Critical（严重）

系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试。功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用冲突，安全问题、稳定性等。如：软件中数据保存后数据库中显示错误，用户所要求的功能缺失，程序接口错误，数值计算统计错误等（该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试）。

③Major（一般）

功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。如：操作时间长、查询时间长、格式错误、边界条件错误，删除没有确认框、数据库表中字段过多等( 该问题实际测试中存在最多）

④Minor（次要）

界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。如：错别字、界面格式不规范，页面显示重叠、不该显示的要隐藏，描述不清楚，提示语丢失，文字排列不整齐，光标位置不正确，用户体验感受不好，可以优化性能的方案等（此类问题在测试初期较多，优先程度较低；在测试后期出现较少，应及时处理）

2.BUG生命周期

每个公司对BUG生命周期定义不同，一般是从open到closed的所有状态。

 

● New: 新发现的 Bug， 决定是否指派给开发人员进行修改。

● Open ：确认是 Bug ，并且认为需要进行修改，指派给相应的开发人员。

● Fixed: 开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证。

● Rejected ：如果认为不是 Bug ，则拒绝修改。

● Delay: 如果认为暂时不需要修改或暂时不能修改，则延后修改。

● Closed ：修改状态的 Bug 经测试人员的回归测试验证通过，则关闭 Bug 。

● Reopen ：如果经验证 Bug 仍然存在，则需要重新打开 Bug ，开发人员重新修改。

3.产生争执怎么办

在BUG生命周期阶段，如果测试人员认为问题要修改，但是开发人员rejected了BUG，这种情况应该怎么做？

① 先检查自身，是否 bug 描述不清楚

② 站在用户角度考虑问题 应该让开发人员了解到 Bug 对用户可能造成的困扰，这样才能促使开发人员 更加积极地、高质量地修改 Bug 。

③BUG 定级要有理有据

④ 提高自身的技术和业务水平 . 不光要提出问题 , 最好也能提出解决方案

⑤ 开发人员不接受时，不要争吵

七、测试用例

 1.测试用例基本要素

测试用例 是为了实施测试而向被测试的系统提供的一组集合，这组集合包含：测试环

境、操作步骤、测试数据、预期结果等要素。

像这样：

2.测试用例设计方法

测试用例在不使用方法时也能够设计出来，但是测试用例是没有穷尽性的，所以非常有可能遗漏。

测试用例万能公式：界面-性能-易用性-安全-兼容-功能

 ①基于需求的设计方法

在分析测试需求时，一般分为 功能测试需求 和 非功能测试需求 、

功能需求：

一般使用功能框图来设计

例如对手机日历功能进行设计测试用例

 非功能需求：

例如对百度云盘进行测试用例设计

 ②等价类

依据需求将输入（特殊情况下会考虑输出）划分为若干个等价类，从等价类中选出一个测试用例，如果这个测试用例测试通过，则认为所代表的等价类测试通过。

等价类分为有效等价类（ 合理的、有意义的输入数据构成的集合）和无效等价类（ 不满足需求的集合）

例如：

 ③边界值

边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。

 

例如：

 ④错误猜测法

错误猜测法是对被测试软件设计的理解，过往经验以及个人直觉，推测出软件可能存在的缺陷，从而针对性地设计测试用例的方法。

⑤判定表法

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

 ⑥正交表法

正交法的目的是为了减少用例数目。用尽量少的用例覆盖输入的两两组合。

 

例如： 姓名、邮箱、密码、确认密码、验证码必须全部输入，才能进行注册

步骤（使用allpairs）：

1.分析因素和水平

因素：姓名、邮箱、密码、确认密码、验证码

水平：填写、不填写

2.将因素和水平以表格形式填在excel表格中保存

3.cmd打开将保存的文件放在allpairs安装目录下

 4.自动生成正交表

 ⑦场景设计法

典型的应用是是用业务流把各个孤立的功能点串起来，为测试人员建立整体业务感觉，从而避免陷入功能细节忽视业务流程要点的错误倾向