软件测试的基本知识点

软件测试的基本知识点

• 软件的分类
• C/S与B/S架构
• 软件测试的定义
• 软件测试的目的
• 软件测试的分类
• 软件生命周期
• 生命周期模型
• 1.瀑布型生命周期模型
• 2.V模型
• 3.敏捷开发模型
• 软件测试的基本流程
• 测试设计用例设计方法
• 等价类划分法
• 边界值分析法
• 场景法
• 错误推测法
• 测试用例的编写与评审

软件的分类

软件分为两大类：系统软件、应用软件。
软件测试的对象是：程序、数据、文档。（主要为程序）

C/S与B/S架构

C/S：就是我们一定要安装安装一个客户端才能够使用的软件。
缺点：每次更新都要更新服务端和客户端。
B/S：只需一个浏览器就可以访问服务。
优点：只需更新服务器不需要更新浏览器，用户主动性比较高。

软件测试的定义

使用人工和自动的手段来运行或测试某个系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。

软件测试的目的

1.软件测试是为了发现程序存在的代码或业务逻辑错误
2.软件测试是为了检验产品是否符合客户的需求
3.软件测试是为了提高用户的体验

软件测试的分类

• 按测试技术划分：白盒测试、黑盒测试、灰盒测试
• 对象是否运行划分：动态测试、静态测试
• 按不同测试手段划分：手工测试、自动化测试
• 按测试包含的内容划分：功能测试、界面测试、安全测试、兼容性测试、易用性测试、性能测试
• 其他测试：冒烟测试、回归测试、探索性测试/自由测试

冒烟测试–>主干、主流程;
回归测试–>1.发现bug被开发修复后，对这个bug进行验证 2.确认这个bug被修复后，没有影响到其他正常的功能

软件生命周期

软件生命周期是软件开始研制到最终废弃不用所经历的各个阶段。

生命周期模型

1.瀑布型生命周期模型

自上而下，逐级下落，具有顺序性和依赖性。

1）问题的定义及规划—>产品经理、需求人员
主要确定软件的开发目的及可行性，指定项目总体开发计划
2）需求分析（需求评审+需求分析）—>产品经理、开发、测试
在确定软件开发可行的情况下，对软件需要实现的各个功能进行详细分析，明确客户的需求，输出需求规格说明书终版（原型图），提交评审。
3）设计—>开发
把需求分析得到的结果转换为软件结构和数据结构，形成系统架构。
概要设计：主要是架构的实现，指搭建结构，表述各模块功能，模块接口连接和数据传递的实现等项事务。
详细设计：对概要设计中表述的各模块进行深入分析等，其中需要包含数据库设计说明。
4）编码（实现功能）—>开发
按照详细设计好的功能表，编程人员编写出计算机可运行的程序代码。
5）软件测试

• 单元测试：主要是测试程序代码，为的是确保各单元模块被正确的编译，也有具体到类、函数、方法的测试等。（一般开发完成）
• 集成测试：单元测试后，将各单元组合完整的体系，测试软件单位之间的接口是否正确，数据能否正常传递（一般由开发/测试完成）
• 系统测试：把软件系统搭建起来，按照软件规格说明书中所要求，测试软件其性能功能等是否和用户需求相符合，在系统中运行是否存在漏洞等。（根据测试用例，进行完整的系统测试，由测试完成）
• 验收测试（正式验收，alpha，beta）：主要就是用户在拿到软件的时候，在使用现场会根据前面所提到的需求，以及规格说明书来做相应而是，以确定软件达到符合效果的。（用户/客户对软件进行验收）

正式验收：完全由用户完成测试工作，同时也会像系统测试一样，有一个非常详细的测试活动（也就是用户会执行验收测试用例），测试环境。
alpha：开发可控制的环境下完成的测试，模拟正式环境
beta：真正的正式环境完成，所以是不可控的环境
6）运行维护==版本迭代，线上bug修复
软件维护是软件生命周期中持续时间最长的阶段，在开发阶段完成并投入使用后，由于多方面的原因，软件不能继续适应用户的需求。要延续软件的使用寿命，就必须对软件进行维护。软件的维护主要包括纠错性维护和改进型维护两个方面。

2.V模型

通过测试和开发同时进行的方式缩短开发周期，提高开发效率。

3.敏捷开发模型

（产品需求-开发–测试）
从1990年代开始逐渐引起广泛关注，是一种以人为核心、迭代、循序渐进的开发方法。强调以人为本，专注于交付对客户有价值的软件。是一个用于开发和维持复杂产品的框架。就是把一个大项目分为多个相互联系。但也可以独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
特点：迭代速度快、沟通能力、特定文档

软件测试的基本流程

1. 测试需求分析阶段：阅读需求，理解需求，主要就是对业务的学习，分析需求点。参与需求评审会议。
2. 测试计划阶段：主要任务是编写 测试计划 参考软件需求规格说明书、项目总体计划，内容包括测试范围（来自需求文档）、进度的安排、人力物力的分配，整体测试策略的制定，和风险评估与规避措施有一个规定，一般由测试负责人编写，当然我们可以也会参与相关的评审工作。（对测试的一个计划）。
3. 测试设计阶段：主要任务是编写 测试用例，会参考需求文档（原型图）、概要设计、详细设计等文档，有不明确的也会及时和开发、产品经理沟通，用例编写完成后会进行 评审，输出 测试用例评审记录表。（怎么测试）
4. 测试执行阶段：首先搭建测试环境，执行测试用例（冒烟），以判定当前版本可测与否，如果预测通过，正式进入系统测试，遇到问题提交Bug到缺陷管理平台，并对bug进行跟踪，知道被测到软件达到测试需求要求，没有重大Bug，测试结束。（完善测试用例，开始测试，无输出或输出bug表单）
5. 测试评估阶段：出 测试报告，对整个测试的过程和版本质量做一个详细的评估。确认是否可以上线。
   

测试设计用例设计方法

等价类划分法

等价类划分有效等价类和无效等价类。
等价类划分法用例设计原则：

1. 划分有效及无效等价类，为每一个等价类规定一个唯一的编号；
2. 设计一个新的测试用例数据，使其尽可能多的覆盖尚未被覆盖的有效等价类，重复这一步直到所有的有效等价类都被覆盖为止；
3. 设计一个新的测试用例数据，使其仅覆盖一个尚未被覆盖的无效等价类，重复这一步直到所有的无效等价类都被覆盖为止。

例如：
微信红包可以输入金额范围为0.01~200元
有效：0.01~200
无效（按长度范围划分）：小于0.01、大于200、0.01~200小数点后有超过两位的值
无效（按数据类型划分）：非数字

边界值分析法

边界值分析法是对等价类划分法的一个补充，边界值一般都是从等价值边缘去寻找。边界值分析的基本思想是正好等于、刚刚大于、刚刚小于边缘的值作为测试数据。
注意：0是一个特殊值，考虑边缘值的时候要考虑0还要考虑负数。
应用场景：如果需求规定了取值范围或规定了取值的个数时，可以利用边界值进行测试。

例如：

1. 微信红包可以输入金额范围为0.01~200元
   边界值：0、0.01、0.02、199.99、200、200.01
   特殊值：负数
2. 只能输入整数为2~255的输入框
   边界值：1、2、3、254、255、256
   特殊值：0

场景法

通过场景描述的业务逻辑，也包括代码实现逻辑，设计用例来遍历场景（路径），验证软件系统功能的正确性。
注意：场景法的重点是测试流程，因此每个流程用一个用例验证即可，流程测试没有问题并不代表系统功能没问题，还要针对单个的功能进行测试。只有单个功能点和流程测试，才算是充分的测试。

使用场景法方法：
画出流程图
矩形：表示步骤（操作、结果）
菱形：判断（是、否）

错误推测法

基于经验和直觉推测程序中可能存在的各种错误，从而有针对性的设计测试用例的方法，它的要素是：经验、知识、直觉。

测试用例的编写与评审

测试用例是每一个测试点的数据设计和步骤设计。
测试用例的八大要素：

测试编号	测试项目	测试标题	重要级别	预置条件	测试输入	操作步骤	预期结果	实际结果	备注
zc_001	注册	验证注册功能正常	高/中/低	网络正常	手机号xxxxx密码xxx	1. 2. 3.	注册成功	通过/不通过	bugid 461

来源：CSDN

作者：森树白云

链接：https://blog.csdn.net/weixin_45412176/article/details/104251769