【测试】概念篇

---

一 什么是软件测试

1.软件测试的概念

生活中的测试场景：冬天到了我想买一件羽绒服，买之前我要思考这些问题：鸭绒填充量，款式，尺码，价格，颜色...以上这些是购买需求，收到货后与以上需求对比，看这件羽绒服各个方面是否满足我的需求，这个过程也叫做测试。

软件测试的定义：软件测试是一个过程，测试人员针对软件各个方面来验证软件是否符合用户需求。

2.测试与研发的区别

①工作内容的不同：

开发人员：利用编程技能开发软件

测试人员：利用各种技能、测试工具找bug

②技术要求的区别：

开发人员：技能深度的要求

测试人员：技能广度的要求

③发展前景：

开发人员：初级开发工程师->中级开发工程师->高级开发工程师->架构师->CTO

测试人员：初级测试工程师->中级测试工程师->高级测试工程师->架构师->项目经理

3.测试人员应具备的素质

技能方面：编程能力，编写测试用例的能力

非技能方面：沟通能力，快速学习能力，团队合作能力，文字表达能力，抗压力，责任感，耐心细心...

4.软件测试与调试的区别

①目的

调试：发现缺陷并解决

测试：发现缺陷，验收缺陷

②人员

调试：开发人员来完成

测试：测试+开发人员

③阶段

调试：开发阶段完成

测试：贯穿软件的整个生命周期

④方法

调试：debug，打印日志

测试：黑盒测试、白盒测试、UI测试、接口测试、性能测试

二 什么是需求

1.需求的定义

满足用户期望或 规定文档所具有的条件，包含用户需求和软件需求。

用户需求：一句话。可以理解为甲方的需求，一般比较简略。

软件需求：一个文档。会详细描述开发人员必须实现的软件功能，开发人员和测试人员的直接依据。

2.测试人眼里的需求

需求是测试人员开展测试工作的依据。在设计测试用例的时候，具体步骤如下：搞清业务需求->软件功能需求点->测试需求点->测试用例

以“用户登录”为例子：

3.如何深入了解需求

参加需求评审会议，查阅文档（需求文档，技术文档），与项目经理沟通都可以更好的帮助测试人员理解需求。

三 测试用例

1.什么是测试用例

测试用例（Test Case）是为被测试系统提供的一组集合，包括测试环境，操作步骤，测试数据，预测结果。

在进行测试用例的时候，要考虑这几方面因素

测试用例=功能测试+界面测试+性能测试+安全测试+易用性测试+兼容性测试

2.测试用例的设计方法

❤️针对没有需求的案例

❤️针对有需求的案例

需求分析->需求有哪些功能->设计测试点->设计测试用例

❤️等价类

概念：根据需求将输入划分为若干个等价类，从等价类中拿出一个测试用例，如果这个测试用例通过，则所代表的等价类测试通过。

适用的需求：输入数据是无穷且有特点的。

有效等价类：根据需求来说是有效且有意义的数据构成的集合。

无效等价类：根据需求来说是无效且有无意义的数据构成的集合。

例子：

需求：超市买水果

有效等价类：苹果，火龙果，桃子

无效等价类：酸奶，毛巾，水杯

根据等价类划分测试用例步骤：

1.充分理解需求

2.分别划分有效等价类和无效等价类

3.分别细分有效等价类和无效等价类

4.分别对有效等价类和无效等价类进行组合

❤️边界值

概念：边界值分析法就是对等价类划分法的补充。，测试用例来自等价类的边界。设计测试用例的时候通常加上边界值和次边界值。

上点：边界上的点。

离点：边界左右的一个点。如果是闭区间，离点就算范围外的点；如果是开区间，离点就算范围内的点。

内点：边界内的点。

举例：

①【1，11】

上点：1，11

内点：6

离点：0，12

②（1，11】

上点：1，11

内点：6

离点：2，12

③（1，11）

上点：1，11

内点：6

离点：2，10

步骤：

1.充分理解需求

2.找到上点、内点、离点

3.根据上点、内点、离点设计测试用例

❤️判定表

概念：一种表达逻辑判断的工具

步骤：

1.确认输入条件和输出条件

2.找出输入和输出之间的关系

3.画判定表

4.根据判定表编写测试用例

适用场合：需要考虑输入之间的组合关系，不同组合关系对应的输出结果不同

例子：

需求：店铺活动，订单已提交，订单金额大于300或有红包，有优惠。

1.确认输入和输出条件

                    A                B                  C

输入：金额大于300     有红包       订单已提交

                1              2

输出：有优惠     无优惠

2.找出输入条件和输出条件之间的关系

AC     1

BC     1

ABC   1

A        2

B        2

C        2

AB      2

非ABC   2

3.画判定表

4.根据判定表来编写测试用例

1.金额大于300，无红包，订单已提交，有优惠

2.金额不大于300，有红包，订单已提交，有优惠

3.金额大于300，有红包，订单已提交，有优惠

4.金额大于300，无红包，订单没有提交，无优惠

5.金额不大于300，有红包，订单没有已提交，无优惠

6.金额不大于300，无红包，订单已提交，无优惠

7.金额大于300，有红包，订单没已提交，无优惠

8.金额不大于300，无红包，订单没有提交，无优惠

❤️正交排列

概念：能够使用最小的测试过程集合获得最大测试覆盖率，需要用到正交表。

适用场景：配置类软件、组合较多的情况

正交表特性：

1.每一列中不同数字出现的次数想等

2.任意两列数字的排列方式齐全且均衡

正交表表达式：L4（2³）

L：正交表

4：是试验次数（测试用例个数）

2：因素数 （输入的条件）  

3：水平数 （输入的条件的可选项，不是输出条件）

步骤：

需求：用户注册信息，填写姓名，邮箱，密码，确认密码，验证码

1.找到因素数和水平数

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

水平数：填写，不填写

2.使用allpairs工具生成正交表

3.根据正交表来编写测试用例

4.补充测试用例

❤️场景设计法

场景设计法：主要分为主事件流和多个次事件流

步骤：

1.找到主事件流

2.找到次事件流

3.将主次事件流串起来会形成场景，一个场景就是一个测试用例。

❤️错误猜测法

错误猜测法是对被测试软件设计的理解，过往经验以及个人直觉推测出软件可能存在的缺陷，比较依赖个人能力。

😶‍🌫️测试用例的作用

测试用例可以减少大量冗余测试，提高测试人员的工作效率，是建立自动化的基础。

四 测试分类

五 软件错误（BUG）

在规格说明书完全正确的前提下，程序的执行结构与用户预期结果不符的情况就是出现了BUG。

1.如何定义bug的级别

1.Blocker（崩溃）：阻碍开发或测试工作；造成系统崩溃，导致数据库数据丢失等。

2.Critical（严重）：如软件中数据保存后数据库中显示错误，用户所要求功能缺失。

3.Major（一般）：功能菜单存在缺陷但不会影响系统稳定性。

4.Minor（次要）：如错别字，界面格式不规范，页面显示重叠等。

注意：当出现崩溃级别的bug时，需要停止测试并打回。

2.bug的生命周期

bug状态转换图

New : 新发现的Bug，未经评审决定是否指派给开发人员修改。

Open :  确认是Bug，并认为需要修改，指派给开发人员。

Fixed : 开发人员修改后标识为修改状态，有待测试人员重新测试。

Rejected : 认为不是Bug，拒绝修改。

Delay : 认为不需要修改或暂时不能修改，延后修改，不是不修复。

Closed :  经测试Bug已被修复，关闭Bug。

Reopen : 经测试Bug仍存在，需要重新打开Bug。

六 软件的生命周期

软件的生命周期是指软件产品从设计到不再使用的时间，分为6个阶段：需求分析、计划、设计、编码、测试、运行维护

七 软件测试的生命周期

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

需求分析 ：测试人员了解需求，对需求进行分解

测试阶段 ：确定软件由谁测试以及测试周期、测试内容

设计阶段： 测试人员写测试用例，包括手工测试用例和自动化测试用例，编写测试工具

测试执行： 执行测试用例，在此过程中，测试人员记录、管理缺陷

测试评估： 测试完成后写测试报告

八 开发模型

1.瀑布模型（Waterfall Model）

适用的项目：小型项目

特点：线性顺序的开发模式

优点：每个阶段该做什么都非常清晰

缺点：风险在后期测试阶段才暴露，失去及时纠正的机会

2.螺旋模型（Spiral Model）

适用的项目：规模大，复杂度高，风险大的项目

特点：渐进式的开发模式

优点：具有严格的全过程风险管理，强调各开发阶段的质量。

缺点：人员、资金和时间的投入太高

3.增量、迭代

增量迭代是一种软件开发方法，通过分批次、逐步迭代的方式来开发和改进软件。在这个方法中，软件开发项目被分为较小可独立完成的增量，经历需求分析、设计、编码、测试等步骤。在完成一个增量后，根据用户反馈和需求变化，再决定下一个增量的开发内容。这样循环迭代，不断完善和扩展软件功能。

优点：快速交付，及时反馈，降低风险，减少问题积累。

增量和迭代是有区别的：

增量是逐块建造的概念，就像买了一块地，先从打地基一步一步开始盖。

迭代是反复求精的概念，就像直接买了毛坯房慢慢装修。

4.敏捷

特点：轻文档、轻流程、重目标、重产出

敏捷软件开发宣言：Manifesto for Agile Software Development

​

敏捷模型有很多种，其中scrum是比较为人所熟知的一种。

👀scrum

scrum里的角色：

产品经理（product owner）：负责整理用户需求，定义其商业价值，制定发布计划，产品负责。

项目经理（scrum master）：负责召开各种会议，协调项目，为研发团队服务。

研发团队（team）：包括后端开发、前端开发、UI设计师、测试人员。各个成员紧密合作，完成目标迭代与产品交付。

流程：

1. 产品负责人整理好user story，形成产品待办事项。

2. 发布计划会议：产品经理负责讲解user story，制定出这一期迭代要完成的story列表和user story。

3. 迭代计划会议：团队对每一个story进行任务分解 。

4. 每日例会：每日项目经理召开大概10分钟的站立会议，团队成员进行复盘。

5. 演示会议：迭代会议以后，团队负责向大家展示本次迭代成果，大家将反馈记录并形成新的story。

6. 回顾会议：项目团队对本期迭代进行总结，制定改进计划。

九 测试模型

1.V模型

特点：垂直结构，每个开发阶段都有相应的测试阶段与之对应。

优点：明确标注了测试阶段和开发阶段之间的对应关系

缺点：测试人员介入太晚，发现问题时机太晚

2.W模型

特点：测试从需求阶段就介入

优点：测试人员能及早介入发现问题

缺点：缺乏灵活性，不适用于敏捷