目录
[1、先检查自身，是否 bug 描述不清楚](#1、先检查自身，是否 bug 描述不清楚)
[3、BUG 定级要有理有据](#3、BUG 定级要有理有据)
4、提高自身的技术和业务水平。不光要提出问题，最好也能提出解决方案
[5、Bug 审批](#5、Bug 审批)
[（1）决定如何处理 Bug](#（1）决定如何处理 Bug)
[（1）常规思考 + 逆向思维 + 发散性思维](#（1）常规思考 + 逆向思维 + 发散性思维)
[A. 功能测试](#A. 功能测试)
[B. 界面测试](#B. 界面测试)
[C. 性能测试](#C. 性能测试)
[D. 兼容性测试](#D. 兼容性测试)
[E. 易用性测试](#E. 易用性测试)
[F. 安全测试](#F. 安全测试)
[G. 弱网测试](#G. 弱网测试)
[H. 安装卸载测试](#H. 安装卸载测试)
一、与开发产生争执怎么办（处理人际关系）（ 重点 ）
能让开发人员解决最多 Bug 的测试人员是最优秀的测试人员。
在测试工作中，最常遇到的是和开发人员的 PK
作为测试经理还会和项目经理、产品经理的 PK 进度、质量。
作为一名测试人员，一般会遇到以下几种情况：
- 这不是 bug。
- 这个 bug 的级别太高了。
- bug 影响不大，暂不修改。
遇到争执不要怕，记住批判性思维：
- 清楚 ------ 准确
- 切题 ------ 深刻
- 有意义，有逻辑性 ------ 公正、全面
1 、先检查自身，是否 bug 描述不清楚
如果能正确地、高质量地录入一个 Bug ，那么基本上已经成功地与开发人员沟通了一大半的关于 Bug 的信息。
- 但是总有" 书难达意 " 的耐候，这时就需要测试人员主动与开发人员进行沟通了。
- 如果测试人员发现在写完一个缺陷后，好像还有很多关于 Bug 的信息没有表达出来
- 或者很难用书面语言表达出来时，就应该在提交 Bug 后，马上找相关的程序员解释刚才录入的 Bug
- 确保程序员明白 Bug 描述的意思，而不要等待开发人员找自己了解更多的信息。
2 、站在用户角度考虑并抛出问题
站在用户角度考虑问题，应该让开发人员了解到 Bug 对用户可能造成的困扰，这样才能促使开发人员更加积极地、高质量地修改 Bug。
在争执时，可以问一句：如果你是用户，你可以接受吗？
例如：需求要求可以上传图片作为头像，但是没有定义格式。
- 开发人员在上传时限制为只能传 png 格式的。
- 站在用户角度考虑一下：png，jpg 哪种格式更多？是否要用户自己进行格式转换再上传？
- 发散一下：如下图，当选择了 1.png，2.png，2-2.png 时，任意点击一个删除按钮，所选的三个都被删除。
3 、 BUG 定级要有理有据
- BUG 定级时，不仅要参考 BUG 级别，还要考虑 BUG 是否会影响到流程
- 往往用户的 BUG 级别和我们的是有区别的，需站在用户的角度定考虑定位级别。
4、提高自身的技术和业务水平。不光要提出问题，最好也能提出 解决方案
提高自身的业务和技术水平，不但要做到能提出问题，还能够提出解决问题的思路。
- 这样才能更让人信服。
- 在工作中，你会发现同一个 bug，资深测试工程师提出和初级测试工程师提出，两者的结果完全不同，两者最大的差别是资深测试工程师往往会提出解决方案。
- 而长此以往，权威性逐渐的建立起来，那么开发人员看到 bug 的第一反应，就是这是一个 bug，而不是这是一个 bug 吗？
注意：可以给出解决方案，但是不能喧宾夺主，命令式让开发人员按照自己的想法来修改。
【案例】
某网站经常隔几天访问时会出现 500 错误，但是之后就不会复现。
- 测试人员会提出问题：网站偶发性出现 500 错误。
- 开发人员回答：不常见，不影响使用，暂不修改。
- 资深测试人员提出问题：网站偶发性 500 错误，查看日志，是由于 MySQL 数据库 8 小时超时问题造成。需要修改连接池配置定期校验连接。
- 开发人员处理：修改 xml ，增加校验配置项。
5 、Bug 审批
如果确实是 Bug，友好沟通不能解决问题，那么就召开 Bug 评审。
可能你已经经过了多轮沟通，但是开发人员仍然拒不接受。
此时可以发起 Bug 评审。Bug 评审要注意的问题，缺陷的评审应该包括以下两个层面：
- 决定如何处理 Bug。
- 分析缺陷产生的原因，找出预防的对策。
（1） 决定如何处理 Bug
这一方面评审需要项目组各个方面的代表参加，通常不可缺少的是测试代表、开发代表、产品代表。
- 测试代表主要从 Bug 的具体表现、严重程度等方面提供信息，并提出自己对 Bug 的处理意见。
- 需要注意的是，测试人员不应该一味地要求对 Bug 进行修改，因为修改可能带来回归的风险，同时带来的是回归测试的工作量
- 如果时间比较紧迫，修改后剩余的时间若不足以做一次有效的回归测试，可能不修改是个明智的选择。
- 开发代表主要从修改缺陷的难度和风险出发，考虑缺陷修改需要付出的代价，以及可能影响的范围、可能引发的风险等，如果决定要修改，还要讨论出修改的初步方案。
产品代表主要从产品的整体计划、用户的要求等方面对缺陷的修改必要性、缺陷修改的时间和版本提出自己的意见。
这在微软的做法叫 **"Bug三方讨论会"，**参加者一般是测试人员、开发人员和项目经理。
（2）分析缺陷产生的原因，找出预防的对策
缺陷评审还应该包括原因分析，找出 Bug 出现的原因，尤其是那些重复出现的 Bug。
- 应该找出出现错误的根源，并且制定出相应的预防措施，确保同类型的 Bug 不再出现。
- 例如：有些 Bug 出现的原因不是简单的 "引用为空" 之类，而是开发人员的编码不规范或者编程习惯不好而导致
- 所以必须建立起正确的编程方式才能预防这些错误的出现，否则只是在玩无聊地重复发现相同的 Bug 的游戏。
Bug 评审至少需要项目组以下各个方面的代表参加：
- 测试代表
测试代表主要从 Bug 的具体表现、严重程度等方面提供信息，并提出自己对 Bug 的处理意见。需要注意的是，测试人员不应该⼀味地要求对 Bug 进⾏修改，因为修改可能带来回归的风险，同时带来的是回归测试的工作量，如果时间比较紧迫，修改后剩余的时间若不足以做⼀次有效的回归测试，可能不修改是个明智的选择。
- 开发代表
开发代表主要从修改缺陷的难度和风险出发，考虑缺陷修改需要付出的代价，以及可能影响的范围、可能引发的风险等，如果决定要修改，还要讨论出修改的初步方案。
- 产品代表
产品代表主要从产品的整体计划、用户的要求等方面对缺陷的修改必要性、缺陷修改的时间和版本提出自己的意见。
二、测试用例的概念
测试用例**（Test Case）是为了实施测试而向被测试的系统提供的一组集合**
这组集合包含：测试环境、操作步骤、测试数据、预期结果****等要素。
（注意：不需要执行结果，因为执行结果需要执行完测试用例才知道，没有测试用例自然就没有执行结果）
测试用例原则一：测试用例中一个必需部分是对预期输出或结果进行定义。
好的测试用例是一个不熟悉业务的人也能依据用例来很快的进行测试。
评价测试用例的标准：对比好坏用例的评价标准。
- 用例表达清楚，无二义性。
- 用例可操作性强。
- 用例的输入与输出明确。一条用例只有一个预期结果。
- 用例的可维护性好。
- 用例对需求的覆盖率高。
什么是要素？
在编写测试⽤例的时候，每个用例需要给出这些要素对应的信息。
|------|---------------------------------------------------------------------------------------------------------------------------------------------------------|
| 项目 | 内容 |
| 用例编号 | test-01 |
| 标题 | 成功注册网易邮箱 |
| 测试方式 | 手工测试 |
| 功能模块 | 注册登陆 |
| 重要性 | 重要 |
| 测试前提 | 系统运行正常，邮件服务器已开启 |
| 测试环境 | Windows 10, Chrome 版本 103.0.5060.66（正式版本）（64位） |
| 测试数据 | 邮箱地址：[email protected]; 密码：123456; 手机号：12312341234 |
| 测试步骤 | 1. 打开谷歌浏览器，输入网易注册地址：注册网易免费邮箱 - 你的专业电子邮局 2. 输入邮箱地址，密码，手机号，获取验证码并输入正确的验证码，勾选协议 3. 点击注册按钮 |
| 期望结果 | 展示注册成功的结果页，并且使用刚注册的账号可以正常登录并进入邮箱首页 |
笔试的时候编写测试用例题，按照 excel 表格的方式来答题（会涉及到测试用例的要素）
面试的时候回答测试用例题，按照思维导图的方式一一道来即可（不会涉及到测试用例的要素）
为什么需要测试用例呢，不写测试用例可以进行测试吗？
测试中可能会遇到很多问题（能解决的问题），诸如：
- 不知道是否较全面的测试了所有功能。
- 测试的覆盖率无法衡量。
- 对新版本的重复测试很难实施（即回归测试无法仅通过人工测试的方式进行历史功能的回归）。
- 存在大量冗余测试影响测试效率。
测试用例的出现就是解决以上这些问题。
另外，测试用例的作用还可以避免测试人员被迫背锅。
实际中产品出现问题，第一责任人首先想到的是测试为什么没有测到？
上面展示的是传统的编写测试用例的方式，
在学习敏捷模型的时候了解到，如今大多数企业采用的都是 思维导图的方式来编写测试用例，后面的内容包括用例练习都是用思维导图 / 脑图进行编写。
1、测试用例的给我们带来的好处
- 测试执行者的依据。
- 使得工作可重复，自动化测试的基础。
- 评估需求覆盖率。
- 用例的复用。
- 积累测试的方法思路以供后续借鉴。
2、测试用例的使用带来的困扰
- 测试用例的设计是费时费力的工作
- 往往设计测试用例所花费的时间比执行所花费的时间还多。
二、测试用例的设计方法
1、 设计测试用例的万能公式
现在有一款产品，要求我们对 "门锁" 设计测试用例，假如我们是测试人员，该如何设计呢？
用例的设计最重要的一点是保证功能是正确的。
上图给出的案例，在互联网企业中，这样去设计测试用例的非常少，缺乏经验的同学往往以上面的思路去设计。
（1）常规思考 + 逆向思维 + 发散性思维
正确设计测试用例的思想：常规思维 + 逆向思维 + 发散性思维
设计测试用例的原则二：
- 测试用例的编写不仅应当根据有效和预料到的输入情况，而且也应该根无效和未预料到的输入情况。
- 检查程序是否 "未做其应该做的" 仅是成功的⼀半，测试的另⼀半是检查程序是否 "做了其不应该做的" 。（是上⼀条原则的必然结果）
- 计划测试工作时不应默许假定不会发现错误。
明白了设计测试用例是思维的正确还往往不够。
若仅仅通过头脑风暴去设计测试用例，那么当我们面对面试官时，能够想出来的用例是寥寥无几的，所以在设计测试用例的时候需要有思路的去设计。
（2）万能公式
设计测试用例的万能公式： 功能测试 + 界面测试 + 性能测试 + 兼容性测试 + 易用性测试 + 安全测试
A. 功能测试
从产品功能角度出发，验证功能是否是正确的。
- 物体：这个物体是用来干什么的
- 软件：软件实现功能
功能测试是一个试图发现程序与其外部规格说明之间存在不一致的过程。
- 外部规格说明是一份从最终用户的角度对程序行为的精确描述。
- 功能测试通常是一项黑盒操作。在进行功能测试时，需要对规格说明进行分析以提炼测试用例，本课程中讨论的具体设计测试用例的方法尤其适用于功能测试。
⭕然而，不仅是工作中还是面试中，可能会存在需求不明确的功能？这种情况下该如何进行功能测试？
- 查找其他相关⽂档，来帮助理解所要测试的产品需要完成的目标。
- 尽量多参加项⽬组内的会议，比如需求讨论、设计讨论、计划讨论等，能够加深对产品的理解。
- 召集相关⼈员，对你整理的结果进行讨论，通过评审后，这份文档就可以作为依据来设计你的 case 了。
- 如果是⼀款已经上线的产品，可以多使⽤产品，有不懂的问产品经理。
- 也可以去看历史 Bug，可以了解到⼀些需要已关注的东西。
B. 界面测试
- 物体：外表、材质、大小、容量...
- 软件：界面、字体大小、字体颜色、页面布局...
肉眼可以看到的部分都称为界面，界面所有的元素都需要测试。
界面涉及到的内容：元素（大小、颜色、形状、性质（可以触摸到的））
对软件界面上所有的内容都需要进行测试。
要求：
- 整体界面测试界面的实现与设计图要求⼀致。
- 界面元素测试（控件操作验证）。
C. 性能测试
通常为一些极端的情况。
- 物体：使用寿命
- 软件：响应时间、吞吐量、并发数、CPU占用率
性能测试和功能测试的区别是：功能测试检查软件是否做了 ，而性能测试测试软件做的好不好。
D. 兼容性测试
不同版本（软件、系统），浏览器的兼容性（不同的浏览器）
- 物体：物体除了本质的功能外，是否还有其它功能
- 软件：操作系统（电脑windows、mac、linux、手机ios、Android）、设备、浏览器版本
软件是部署在硬件系统之上，并依赖所需要的软件环境。如 QQ 可以在 PC 端打开，也可以在移动端打开；
移动端⼜分为 IOS 系统和 Android 系统，且市面上手机又有不同的品牌、不同的机型、不同的版本。
软件是否能够在不同的环境下正确运行需要测试人员进行验证。
既然市面上有众多版本的机器，那么在执行兼容性测试时难道所有的机型都需要全面覆盖吗？
选取标准：
- 优先选择使用当前产品 top 级别的机型进行测试
实际在企业中，后台是可以获取到使用产品的机型，并以报表的形式统计在后台，供产品人员或其他人员制定策略参考。
- 选择主流的浏览器 / 机型进行测试
E. 易用性测试
具备简单易上手的属性。
- 易用性：经验（操作简单、操作流程）、人性化（符合人体工学）、见名知意
易用性测试的标准是检查产品是否具备简单易上手的属性。
假如测试人员从来没有安装或使用过该产品，作为一个新用户，对当前产品是否能够快速适用产品的使用流程。
F. 安全测试
- 物体：物体材质是否有毒，物体是否会对人体健康造成伤害
- 软件：**sql 注入、**xxs 漏洞、输入有毒脚本、密码加密保存、权限控制
安全测试和性能测试⼀样都是比较大的领域。常见的安全问题如：
- 隐私数据明文显示。
- 参数未强校验导致 SQL 注入。
- 越权：普通用户也可以执行管理员权限的操作。
除了万能公式之外，还有⼀个比较常用的测试类型：弱网测试、安装卸载测试。
网络：
- 软件：2G~5G、弱网、Wifi
中断：
- 物体：闹钟、短信、电话
- 软件：切换到桌面
G. 弱网测试
弱网测试的目的就是为了覆盖更多的网络场景，尽可能保证用户体验，已关注的关键点包括：
- 页面响应时间是否可以接受，已关注包括热启动、冷启动时间、页面切换、前后台切换、首字时间，首屏时间等。
- 页面呈现是否完成⼀致。
- 超时⽂案是否符合定义，异常信息是否显示正常。
- 是否有超时重连。
- 安全角度：是否会发生 DNS 劫持、登陆 IP 更换频繁、单点登陆异常等。
- 大流量事件风险：是否会在弱网下进⾏更新 Apk 包、下载文件等大流量动作。
弱网需要借助工具来构造弱网，这里推荐荐使用fiddler
- fiddler 配置代理
- fiddler 进行抓包（桌面 / 移动端）
- fiddler 如何构造弱网条件
我们在 后面的文章中，会进行 实操感受
H. 安装卸载测试
- 安装包是否可以安装，卸载之后是否可以继续安装、重复安装，软件更新后是否安装成功。
- 安装完成后卸载，安装一半后卸载，卸载一次后继续安装继续卸载，卸载一半停止后是否还可以继续卸载。
针对需要进行部署的软件，除了软件功能外，我们还需要已关注软件的能够成功安装和卸载。