功能测试
1、软件测试的流程¶
首先进行需求分析 分析需求中的功能能不能实现 新版本对老版本有没有影响，有问题的及时沟通 及时解决，开发拿到分配到的任务编写代码 我们开始编写测试计划和测试用例 之后会进行用例评审 先小组评审 看有没有错误的 遗漏的 冗余的 做好记录 完成后查漏补缺 发给全组邮件进行确认 等开发提测后 我们会先进行一个冒烟测试 看主功能能不能实现 主流程能不能走通 通过后按照编写的测试用例开始执行测试 有bug 使用禅道提交bug 开发进行修复 修复完成后 我们进行复测 复测通过关闭bug 不通过继续提交bug 直到bug修复完成 上线前我们还会进行生产验证 最后编写测试总结和测试报告。
2、编写测试用例的方法¶
1、等价类：按照需求分为 有效等价类（满足需求的）和无效等价类（不满足需求的）
2、边界值：处于边界两边的值
3、因果图：等价类和边界值的组合使用
4、场景分析法：根据真实的使用情况编写的测试用例
5、错误推断法：根据以往的工作经验写出的测试用例
3、测试用例包含哪些内容（格式）¶
用例编号 用例标题 项目名称 模块名称 用力级别 功能 测试点 前置条件 操作步骤 测试数据 预期结果 测试时间 测试人员 备注
4、测试计划¶
测试目标（哪一个项目） 测试范围 （哪一个模块） 测试人员（参与人员） 人员分配（任务分配） 环境配置（搭建环境） 里程碑（起止时间）测试周期（每一个迭代都是一个周期）测试策略（功能，性能测试，自动化测试）风险分析（如新版本会不会对老版本造成影响）
5、需求评审的产物¶
1、工作量的评级 2、计划的制定 3、人物与资源的分配 4、风险的评估
6、bug单内容¶
产品名称 项目名称 影响版本 模块名称 指定处理人 严重级别 优先级 bug类型 bug标题 bug截图 复现步骤 预期结果
7、bug的严重等级¶
致命级别：1、严重的数值计算错误 2、系统容易崩溃死机、冻结3、功能和需求严重不符合4、系统无法登录5、模块无法启动或者异常退出
严重级别：1、功能没有实现2、功能存在报错3、轻微的计算错误4、系统刷新错误5、影响功能和界面的错别字或拼写错误
一般级别：1、格式校验（边界值类型）2、加载过慢响应慢3、提示信息4、光标跳转设置不好，鼠标定位错误
建议级别：1、界面问题：颜色搭配不合理2、字段不整齐3、出现错别字不影响功能的使用4、没有提示文案5、提示文案不容易理解
8、测试用例需要关注的方向¶
9、功能测试从哪方面考虑¶
1、正常功能2、异常功能3、边界测试4、接口测试5、界面测试6、错误处理测试
10、经典bug（印象深刻的bug）¶
1、数据显示为null 2、查询功能第二页与第一页完全相同3、支付和状态没有同步4、数据显示不正确5、订单查询不到 实际是存在的
11、测试报告¶
用例执行了多少 遗留了多少 遗留的原因 新增了多少bug 发现了多少 解决了多少 遗留了多少 遗留的原因 有多少阻碍的bug 重复打开的bug
12、测试总结¶
用例执行了多少 bug解决了多少 遗留了多少 遗留的原因 bug的总数量 发出了多少经典bug 测试中好的测试方法
13、定位问题¶
先看是不是页面问题 在关注数据问题 进行抓包 定位问题 先看http code码
如果是4开头的大概是前端问题 5开头的一般是后端问题 200请求成功的话 看一下接口的出参和入参 出参需要4个字段 前端上传了3个字段那就是前端问题 出参是要4个字段 后端返回了3个字段那就是后端问题 接口的出参入参都没有问题 再看一下是不是数据正确性的问题，打开数据库验证数据 还没有找到看一下日志 再不行找开发帮我们定位一下
14、上线之后出现了bug¶
先看我们的测试环境有没有问题 如果有问题那就定位一下赶紧更改，没有问题的话 可能是兼容性问题 测试环境和线上环境不一样 或者开发在导入测试环境的数据库到线上环境时漏导 同时考虑一下bug的严重级别 通知开发修复 bug能够及时修复 修复完成打个补丁上去 开发不能及时修复 bug的严重级别太高 影响了主功能主流程 一般要回滚到上一个版本
15、测试的项目bug比较多¶
1、环境的问题2、开发对需求理解不透彻3、需求不完善4、人与人沟通交流不够5、程序的逻辑比较复杂6、需求频繁变动7、时间紧任务重
16、验收测试¶
1、α测试：把用户请到公司来，用户使用测试环境进行测试 测试 产品 开发参加 发现问题 现场解决
2、β测试：一个或者多个用户场所进行的测试 使用真实的环境 发现问题现场解决
17、bug开发不认同¶
1、找需求文档 如果需求文档定义了这个功能但是开发遗漏了这个功能 开发必须改
2、没有定义这个功能 找需求/产品人员沟通 需求人员说改 开发也要改 需求人员说下个版本在改 做好记录方便后期工作开展。
18、需求排期要考虑的问题¶
1、需求的实现方案 所耗成本和资源预期结果是否有实现相同的低成本替代方案
2、根据需求的重要程度和紧急程度来决定先后顺序比较着急的项目或功能需求往前排
3、迭代开发的需求
4、需求成本和可能出现的风险方面
19、保证测试用例覆盖了所有点、怎么保证工作中测试更全面¶
1、首先把需求了解清楚，用思维导图画出我所想到的测试点 然后编写详细的测试用例，写完用例之后 我会通过评审的机制跟产品开发确认一下是否有遗漏的让我们的测试用例覆盖的更全面
2、在测试过程中可以先进行冒烟测试 通过后按照测试用例执行测试 然后进行回归测试 回归测试时选择交叉测试 这样会更加全面 回归测试完成之后我会进行随机测试
20、敏捷测试¶
之前有个项目我们采取就是敏捷开发 相对于迭代开发来说：1、敏捷开发会在短时间快速上线 2、敏捷开发的时候一般不写测试用例 或者就是大概的测试 3、尽量减少文档的产生 有问题 产品 开发 测试直接开会解决 经常的开会 4、及时反馈给客服 有更改需求的话及时沟通。
21、版本发布的流程¶
测试经理会先写一份测试邮件，包括：上线的需求点 上线的功能点 用例用例执行情况 bug回归情况 设备资源的申请 测试的结论 完成后发给整个项目组的人和运维 进行审批 审批通过后 继续发布 发布完成后 我们先进行一个主功能 主流程的测试 测试通过上线成功。
22、高质量的测试用例¶
以最少的用例覆盖最全面的功能点 用例标题 前置条件要明确 操作步骤 预期结果要准确 使人一目了然 能准确操作。
23、在浏览器输入网址/域名 到出现在页面上的流程¶
操作系统会先检查自己本地的hosts文件是否含有这个网址映射关系 有的话就直接调用这个ip地址映射 完成云解析 没有的话将域名进行DNS解析成ip 然后进行客户端 服务器的连接 其中连接为三次握手。
24、测试类型¶
1、冒烟测试：主功能主流程进行测试 看功能能不能实现 流程能不能走通。
2、单元测试：对软件设计中的单元模块进行测试
3、集成测试：在单元测试基础上，对单元模块之间的连接和组装进行测试
4、系统测试：全面的测试 在所有都考虑的情况下对系统进行测试
5、回归测试：对之前的功能再次进行测试或者新加入的功能测试完毕后 把相关联的功能在测一遍
6、验收测试：在第三方进行的确认软件满足需求的测试
7、黑盒测试：测试人员完全不考虑逻辑 只关注输入和输出的关系
8、白盒测试：考虑程序内部逻辑结构及相关信息 对程序所有逻辑路径进行测试。
9、灰盒测试：主要用于集成测试阶段 不仅关注输入和输出的正确性同时关注程序内部的情况
25、bug的生命周期¶
发现问题先进行先进行多次验证 确定这是一个bug 定位一下问题 通过禅道提交bug 开发解决问题 我们进行复测 复测通过 关闭bug 不通过 重新激活知道复测通过。
26、测试准入和准出¶
1、从需求进入 进入的越早对项目理解的越详细 2、开发人员的编码已经完成 需求规定的功能都实现了 被测试的系统基本走通 表面上功能都能实现的情况下准入
1、到达指定的日期 2、测试用例执行完毕 3、bug控制在一定范围 4、通过特定小组验收
27、网络状态码（http码/code码）¶
1开头的：指示信息 接受的请求正在处理
2开头的：成功请求 请求已被成功接受 处理成功
3开头的：重定向 需求必须更近一步操作（客户端采取进一步操作才能完成请求）
4开头的：客户端错误 请求有语法错误或者请求无法实现（前端错误）
5开头的：服务器错误 服务器未能实现合法请求（后端错误）
28、常见的网络状态码¶
100:客户端继续发送请求
200：请求成功
301：被请求的资源已永久移动到了新的位置
302：被请求的资源临时移动到了新的位置
303：采用get的方式去获取资源 并且重定向
304状态码表示客户端发送的请求资源未被修改，服务器端无需返回资源内容，直接返回“Not Modified”（未修改）的状态码
305：被请求的资源通过代理才能被访问
400：客户端请求有语法错误 不能被服务器理解
401：请求未授权（这个状态码和请求头有关系）
403：服务器收到请求 但拒绝服务
404：请求资源不存在
500：服务器的程序码出错
502：服务器收到无效的响应
503：服务器因超负荷或正在停机维护 无法处理请求
29、用例管理工具¶
Svn主要是对文件的上传和下载，上次用的是commit，下载checkout，更新update，可以换取最新版本也可以拉取指定版本。
30、版本发布的流程¶
首先我们测试经理编写一份测试邮件，包括了上线的需求，上线的功能点，用例执行情况，bug的回归情况，设备资源的申请，测试的结论，完成后发给整个项目组的人和运维，进行审批，审批通过继续发布，发布完成后，我们会进行一个主功能主流程的冒烟测试，测试通过上线成功，这就是我们发布发版的流程。
31、高质量的测试用例¶
以最少的用例，覆盖最全面的功能点，用例标题，前置条件要明确，操作步骤，预期结果要准确，使人一目了然，能准确操作，这样的用例就是好的测试用例。
32、线上发现的bug以及解决方案（生产问题）¶
1、订单的状态不改变：我们做活动的时候，突然用户量剧增，导致我们的异常消息处理接口堵塞，因为我们的平台有策略，30分钟订单未支付会把订单取消掉，这时候出现了用户支付成功，订单的状态是取消的状态。最后是我们增加了一个对账的策略和性能测试。
2、超卖现象：用户并发太高，导致的库存为负数。我们增加了一个redis的incr锁防止超卖，当key不存在的时候，那么key的值会被初始化为0，然后在执行incr操作进行加一，其他用户在执行incr操作时，返回的数大于1，说明这个锁正在被使用。
3、在查询页面：显示的第二页和第一页是同样的内容，后来发现是开发在回调接口是使用的相同的接口导致的。
33、对账的策略¶
1、每分钟对前30分钟失败的订单
2、第二天凌晨对前一天所以的订单
3、通过调用接口的方式来实现对账
4、后台下载账单来对账