共计 2185 个字符，预计需要花费 6 分钟才能阅读完成。
1.bug 的发展史
现阶段 bug 根本分类
- 性能逻辑
- 用户体验
总结 bug 是如何产生的
- 程序在开发时考虑不周全导致
- 程序在应用时不合乎用户习惯
2. 软件测试工作的实质
个别的办法和伎俩
- 从需要，性能实现，性能等角度发现软件自身的 bug
- 手动或自动化的形式来实现 bug 的发现
- 长处：只关注软件自身，工作量不大，比拟省心
毛病：没有预防伎俩 发现 bug 时再修补回溯的流程比拟长，耗时
- 技术上要以任何办法和伎俩发现 bug
- 思维上要以多视角的形式察看我的项目 预防 bug
3. 为什么要进行软件测试
任何产品生产进去都是可能存在瑕疵的
起因：惯性思维 自我认同 需要了解偏差
4. 一个我的项目各阶段设计人员及工作内容
需要阶段：产品 负责需要调研 竞品剖析 产品原型设计
- 需要评审：我的项目所有成员加入，产品经理为大家解说产品需要的逻辑
- 设计阶段：交互设计（ui/ue）架构设计（抉择技术栈）
开发阶段:
- 前端开发：负责实现网页业务逻辑局部的编码
- 后端开发：负责实现服务端业务逻辑局部的编码
测试阶段：
- 测试人员：负责软件实现后的质量检查
上线部署 保护
- 运维工程师：负责线上服务器的服务部署与保护
- 数据库管理员：负责线上数据库的服务部署与保护
5. 常见软件开发模型
瀑布
- 这是一个软件生命周期模型，开发过程时通过设计一系列阶段程序开展，从零碎需要剖析开始直到产品公布和保护，我的项目开发过程从一个阶段“流动”到下一个阶段，这也是瀑布模型名称的由来
- 软件打算 -> 需要剖析 -> 软件设计 -> 程序编码 -> 软件测试 -> 运行保护
- 长处：严格规定了每个阶段必须提交的文档，我的项目的推动必须依照肯定的程序来做
- 毛病：重大依赖文档，脱离用户实在需要，在可运行的软件产品交付给用户之前，用户只能通过文档来理解产品时什么样的，很可能导致最终开发进去的软件产品不能真正满足用户的须要，也不适宜需要含糊的零碎
v 模型
- 需要设计（验收测试）-> 概要设计（零碎测试）-> 具体设计（集成测试）-> 编码（单元测试）
- 自上而下 逐步求精
- 毛病：理论工作中 需要常常变动 导致 v 模型步骤重复执行，始终返工
6.bug 的分类
功能型 bug
- 指产品实现过程种 具体逻辑的实现谬误
举例：登陆时 用户名要求应用邮箱登录 但并未验证邮箱格局
bug 分析
前端未验证：频繁且大量的谬误申请发到后端给服务器带来无意义的压力
后端未验证：如果前端验证时有 bug 则谬误数据会间接进入到数据库中
举例：用户浏览商品时，商品增加到购物车失败
bug 分析
前端未实现：点击增加按钮购物车无反馈，并没有发送增加申请到后端
后端未实现：后端代码逻辑有问题，比方数据传输解析失败 或 存储失败需要型 bug
- 指在软件项目管理的过程中，需要阶段就埋下了隐患，如未依照需要实现，需要了解谬误或
需要未形容分明等状况
举例：零碎中用户可应用 微信 手机号 邮箱注册并登录
呈现的问题：当一个用户别离应用了 微信 手机号 邮箱进行了零碎的注册登录
带来的影响：在软件系统中会认为 微信 手机号 邮箱 别离是一个独立的账户（在此等于你注册了三个号）这是显著的谬误
如何解决：在需要阶段定义一个明确的惟一值 比方手机号，无论用什么形式注册，登录胜利后必须绑定手机号性能型 bug
- 指软件在很多人同时应用或长时间运行时呈现了响应慢 甚至解体的场景
举例：春运 12306 双 11 淘宝
多年运行的成熟软件 架构未然成熟，靠的就是减少服务器来晋升性能，大多数事件没有那么多用户，减少太多服务器就是减少老本
但如果 因某个非凡新闻爆出 造成大量用户关注微博 导致微博解体（没有给服务器裁减的筹备工夫 — 降本增笑）
常识型 bug
- 在过来一段时间 用户始终是这样认为的，曾经造成了一种默认的约定，但软件设计或开发人员不依照约定俗成的规定来
7. 发现 bug 的方法论
等价类划分
是指将程序的输出值的汇合划分为若干等价类，等价类又分为无效等价类和有效等价类，从每一类中选取大量数据进行测试- 什么是无效等价类？
是指将程序的输出值的汇合当中合乎输出要求的数据就是无效等价类
- 举例：登录的时候 须要手机号
无效等价类：13506005268 18950365822
有效等价类：123456(位数不对) 66666666666（不正确的手机格局）abcd（字符串）边界值分析法
- 边界值分析法是针对输出数据的边界值测试，个别状况下与等价类划分联合应用，依据各个等价值的边界值设计测试用例
- 举例：登录账号时 要求明码是 6-20 位
谬误揣测法
- 基于教训和直觉，以及参考以往测试后果中呈现比拟频繁及较荫蔽的谬误，从而揣测出程序所有可能呈现的谬误
因果图
- 是一种利用图解法剖析输出的各种组合状况。从而设计测试用例的办法，实用于检查程序输出的各种组合条件
- 举例：自助售货机 只承受 5，10 元两种纸币 一次只能投入一张 售货机发售矿泉水 3 元 饮料 6 元
- 输出条件：1. 售货机有零钱 2. 投 5 元 3. 投 10 元 4. 买矿泉水 5. 买饮料
- 输入条件：a. 售货机无零钱不可购买 b. 提醒购买胜利 c. 找零钱 d. 提醒谬误
- 0 代表无 1 代表 有 / 可选
8. 实战中的 bug 排查
通过这段时间的学习 咱们也大抵晓得 前端其实是提供界面 后端是提供接口的 所以就须要用到 http 申请
从服务端获取须要的信息，而后解析协定和内容，来进行页面渲染或者是信息获取的过程
前景介绍：
登录过程中 须要将用户填写的 账号 明码 通过 http 申请发送到后端，后端解析数据后，将数据放入数据库查问，1. 胜利返回 token 2. 未查问到后果返回错误码
在开发过程中，咱们能够应用浏览器 f12 的 network 来查看接口申请
