一篇文章带你入门软件测试
由于计算机就业形式所迫，针对开发的要求逐渐严苛，因此在此场景下测试开发就变成了一条相对比较容易的道路
所以今天这篇文章我们会从以下角度去学习软件测试，带你了解软件测试的基本工作：
- 软件测试概念
- 软件测试方法
- 软件测试缺陷
- 真实测试场景
软件测试概念
我们首先需要去学习软件测试的相关概念
软件测试基本概念
首先我们需要知道软件测试是什么：
- 软件测试是针对已开发的项目进行多方位的检测来使项目可以满足用户的基本需求
- 软件测试通常是为了找到Bug并提出进行修改，使项目满足用户的基本需求不受影响的同时优化用户的使用体验
此外我们需要一个很重要的概念：
- 软件测试是为了以尽可能少的时间对软件整体功能进行检测，保证不出现重大问题
- 软件测试只能以找寻Bug并修改Bug为目标，软件测试是无法找到所有的Bug的，在保证基本功能不出现问题的基础上去发掘深处Bug
软件测试主流技术
一般在公司项目中主要分为以下五个步骤（并不是很专业的分类，但项目开发主要是以下流程）：
- 需求分析
- 前端/后端开发 + 测试书写测试用例
- 前端/后端联调
- 测试并修改Bug
- 产品经理验收项目
而这过程中，留给测试人员去测试的时间通常是很短的，大概只有一或两天的时间
所以我们需要去书写最为全面的测试用例以及熟悉项目的整个操作流程，以便于我们在实操时效率的提升
现在我们就需要知道测试所需要的主要技术：
- 快速上手项目：在小公司中通常一个人会去管理多个项目的测试，因此快速去熟悉项目流程是测试人员所必须的
- 测试用例书写：一般测试用例会在XMind上去书写，具体的书写方法和书写技巧我们在后面会讲到
- 功能测试：基础测试人员必须的技能，需要我们按照测试用例去“点点点”，保证项目功能的基本实现，需要涉及项目所有情况
- 自动化测试：采用自己所书写的小工具使人工操作转化为机器操作（进阶内容，目前不需要掌握）
- 接口测试：接口测试实际上只是功能测试的一个模块，一般使用PostMan或者Charles抓包工具
- 性能测试：性能测试通常是为了测试项目的执行速度，设置多线程执行多次的方式来进行测试以及弱网环境测试等
软件测试主流分类
软件测试分类主要从两方面进行分类，下面我们从两方面进行讲解
阶段测试
我们首先讲解一下阶段测试是什么意思：
- 阶段测试通常是以我们需要测试的模块大小来进行分类
我们通常把阶段测试分为四种：
- 单元测试：单元测试是指针对于某个功能进行测试，这一点通常是前后端进行联调时进行测试
- 集成测试：针对接口和接口之间进行测试，也被称为接口测试
- 系统测试：根据需求文档对整个项目所开发内容的完整性和兼容性进行测试，也就是测试人员的测试环节
- 验收测试：公司内部人员对项目进行测试或者说实际使用，也就是产品经理验收测试
方法测试
我们可以根据对代码的可见度将其划分为以下三种测试：
我们来简单介绍一下：
- 黑盒测试：主要针对功能（阶段划分->系统测试）
- 灰盒测试：针对接口测试（阶段划分->集成测试）
- 白盒测试：针对程序源代码进行测试（阶段划分->单元测试）
软件测试角度
我们在进行软件测试时需要从多角度去进行考虑：
- 功能性：是否能满足需求所需功能
- 兼容性：是否能在多平台（PC，Android，IOS）下均可以运行
- 易用性：是否简单易操作，是否引导/流程清晰
- 可靠性：软件寿命是否长久
- 性能性：是否高效，执行速度是否快
- 安全性：软件是否安全，是否可能暴漏用户信息
- 可维护性：在后续版本中是否便于维护
- 可移植性：该项目在后续是否便于移植至其他服务器
软件测试流程
在公司开发中，测试组需要进行以下步骤：
- 需求分析：由项目经理发放需求并进行统一讲解，保证各方面都完全理解需求
- 计划编写：由主管来指定本次测试由谁来负责
- 用例设计：由测试人员来书写测试用例
- 用例执行：待开发结束提测后，由测试人员根据测试用例执行来找寻Bug
- 缺陷管理：由测试人员找寻Bug并提出Bug，再不断修改并进行测试
- 测试报告：书写测试报告文档
软件测试方法
在这一章节我们会介绍书写测试用例的方法
测试用例书写
我们一般采用Xmind并根据需求表来进行测试用例书写：
- 我们首先根据需求表将其划分为多个模块进行测试
- 根据每个模块所需要验证的功能再次进行划分
- 针对具体功能我们需要去书写前置条件+执行流程+执行结果
针对最后一步我们给出一个简单示例：
- 假设我们需要给一个页面做登录需求
我通常会采用下面两种类型来设计登录所需数据：
而根据流程的长短还会有不同的测试用例设计方法，我们这里就不举例说明了
穷举场景用例
我们在进行测试时，我们一般会需要测试所有的场景数据,但针对于穷举场景我们肯定是无法全部穷举测试的
例如我们注册账号时需要5~12位数字当作账号，但是我们肯定无法全部测试
所以我们就需要一种新的方法——“等价类划分法”来帮助我们完成这种测试：
因此我们可以将同一种情况的有效值和无效值划分为一种类型去进行测试，拿我们上述的账号注册来举例：
上述情况是针对单个条件时的穷举场景展示，但是针对多情况时我们就需要控制变量：
- 正向用例：一条尽可能覆盖多条
- 逆向用例：每一条数据，都是一条单独用例
例如我们有一个新的案例：
-
我们需要验证某个城市的手机号是否正确
-
手机号由以下三部分所组成
-
区号：空/3位数字
-
前缀码：非“0”且非“1”开头的3位数字
-
后缀码：4位数字
我们就可以写出以下的测试用例：
边界场景用例
我们在测试时，通常需要去检测边界，因为边界是最容易出现问题的地方也是我们需要去详细区分的地方
例如我们以下两个场景的使用：
- 用户名称长度要求在5~12字符：那么我们就需要去判断5-12之间是否满足条件，这是等价类划分
- 但是我们需要注意的是：我们还需要去确认5和12是否满足条件，以及4和13是否不满足条件
因此我们如果采用这个特性，假设我们需要去判断一个6~10位的qq号是否满足条件，我们就需要兼顾更多情况：
最后我们可以注意到边界值法其实是可以和穷举场景法进行组合使用的，我们可以将所有情况划分为5种：
- 不满足条件前置点：4位
- 满足条件前置点：5位
- 满足条件测试点：8位
- 满足条件后置位：12位
- 不满足条件后置位：13位
多条件场景用例
最后我们来介绍一下多条件下如何去书写测试用例
首先我们通常将条件称为“条件桩”，将结果称为“状态桩”
我们仍旧给出一个简单的例子：
- 假设我们给出一个订单信息，订单包含“金额”和“状态”两个属性
- 当金额>500且未过期时，我们允许发送批准单和提货单
- 当金额>500但过期时，我们不允许发送批准单和提货单
- 当金额<500时无论是否过期，我们允许发送批准单和提货单
- 当订单过期时无论金额大小，我们允许发送通知单
针对多条件情况，首先我们需要将所有情况都罗列出来，然后在最后给出对应的结果展示（当然可以在Xmind也可以在Excel）：
错误推测法
最后我们给出一个我们在正常测试中经常使用到的方法：
- 当项目用例都执行完毕，且BUG修复完成，离上线还有一段时间，这段时间中可使用错误推荐法复测主要业务或测试未覆盖的功能。
软件测试缺陷
最后我们讲一下缺陷，也就是我们经常提及的Bug
软件测试缺陷定义
首先我们需要了解什么是缺陷：
- 软件中存在的各种问题，都为缺陷，简称bug
我们如何去判断该缺点是否为缺陷：
- 在我们的测试用例执行过程中出现执行结果与用例的期望结果不一致的情况为缺陷
- 在我们测试过程中所有出现不符合正常功能的情况以及不便于我们测试的情况统称为缺陷
缺陷通常会划分为以下几种：
- 功能使用缺陷：需求功能无法实现
- 功能个数缺陷：当出现功能多于或少于需求功能
- 隐性功能缺陷：软件需求中所隐性存在的需求如果没有实现也被称为缺陷
- 易用性缺陷：当出现不便于用户直接操作或需要一系列前置操作的功能也被称为缺陷
而缺陷产生原因也具有多种情况：
- 需求文档未标识
- 架构设计存在问题
- 前后端开发编码存在问题
- PC，IOS，Android等适配性问题
软件测试缺陷提交
我们身为测试人员，主要负责发现Bug并且判断问题产生原因交给对应的前后端人员进行处理：
因此我们在缺陷提交时，通常需要注意以下几点：
- 缺陷名称：模块 + 问题
- 缺陷来源：采用F12或Charles抓包工具判断前端问题还是后端问题并发送给对应开发人员
- 缺陷的预置条件：缺陷产生的前置条件，我们需要完全说明
- 缺陷的复现场景：由于缺陷的出现具有概率性，可能是必现bug也可能是有几率出现的bug，我们需要将复现操作书写出来
- 缺陷的实际结果：我们需要将对应产生的错误结果书写出来以及缺陷应该出现的正确结果
- 缺陷的必要附件：例如出现缺陷时的截图，出现缺陷的日志信息等
缺陷运行的具体流程我们可以参考下述流程图来理解：
真实测试场景
下面我们借助这一章节来讲解企业中真实的开发场景以及测试人员需要去做什么
企业运行流程
企业中一般会划分为以下几个角色：
- 产品经理：负责和用户沟通，收集用户信息需求
- 前端开发：负责前端页面的开发，基本联调
- 后端开发：负责后端功能的开发，基本联调
- 测试开发：负责软件测试以及自动化测试工具的开发
企业运行流程：
- 产品经理收集用户需求，制作需求页+基本展示图，制作结束后分给前端后端测试人员查看
- 组内小会，由产品经理和前端后端测试人员一同开会，讲解用户需求，让三方明白其项目的所有需求信息
- 前端后端进行开发，同时测试人员进行测试用例的书写并且熟悉项目内容以及操作，便于后续测试时加快效率
- 前后端均开发完毕后，双方进行联调，查看功能是否出错，联调结束后提测，由测试人员进行测试
- 测试人员将会测试多次，测试过程中出现问题在公司对应平台上发送缺陷修改请求，前后端修复后需要进行回归测试
- 测试人员大概会重复三次大版本测试，并不断针对已修改缺陷进行回归测试，并测试与该回归测试相关的功能
- 最后测试人员测试结束，由产品经理进行验收测试，判断项目是否可以上线
企业测试注意点
我们在工作中通常测试时间是被压缩的很紧的，因为开发时间通常会占用项目的大部分时间，导致测试需求非常紧急
因此我们必须掌握对应技巧，才能又快又好的满足企业需求，我下面罗列几点我认为很重要的地方
测试用例
测试用例的书写我认为有以下几点需求：
- 首先我们需要充分理解需求，针对不确定的需求及时和产品沟通，否则可能出现漏测，误测等情况
- 针对测试用例的书写我们首先需要划分为几个大模块，然后针对各个模块分开书写，以大化小，方便书写
- 针对新开发的功能页面等，我们首先需要确定页面的按钮有什么作用，针对每个按钮（功能）书写对应的测试用例
- 针对数据测试时，我通常将类型划分为数字（123），字符（ABC），特殊字符（！@#）来进行判断
- 针对数据测试时，我通常将数值划分为不满足条件前置位，满足条件前置位，满足条件后置位，不满足条件后置位来进行判断
- 针对流程测试时，首先罗列第一个条件的所有情况，然后在第一条件下去继续罗列后面的n个情况，注意去除重复情况来减少工作量
- 针对需要操作的项目，我们可以直接在测试用例上写出我们所需要创建的数值，我们所需要进行的操作，直接完全按照测试用例操作
- 针对复杂的项目，我们可以将一些较为复杂的操作单独列出一条逻辑线来记录具体操作
测试过程
测试过程中我认为需要注意的有以下几点：
- 积极和前端后端人员沟通，积极的沟通有利于你们快速定位Bug并修改Bug
- 注意测试时的重点部分，工作毕竟是令人烦躁的，我们应该首先去着重处理较为复杂的部分
- 注意缺陷的重要程度，因为有些缺陷可能会导致我们后续的测试无法进行，我们应该和前后端沟通让他们优先修改这些缺陷
- 针对已修复的缺陷，我们首先需要去做回归测试，在回归测试的同时我们需要注意去测试与之相关的功能，查看是否受到影响
- 测试是最后一环节，关系到项目能否顺利上线，因此时间分配上需要注意，针对难以修改但影响不大的缺陷我们应沟通在下版本修复
结束语
这篇文章主要介绍了测试所需要的一些基本信息，希望能为你带来帮助！