目录
一、描述软件测试的生命周期（软件测试的流程）
1.需求分析
分析需求，验证需求的正确性和合理性，细化需求，根据需求提炼测试点
2.测试计划
确定测试范围、测试目的、测试人员、测试工具、测试环境、需要多少时间
3.测试设计/开发——设计测试用例
4.测试执行
开发人员已经提交代码，开始执行测试，提交bug
5.测试报告——将本次迭代的测试情况进行分析和总结
写了多少测试用例，执行了多少，发现了多少bug,修改了多少，剩余多少，剩余Bug的解决方案，测试的覆盖率是多少
二、如何描述一个bug
1.测试的版本（代码提交的版本号）
一般都是多个团队开发，分别提交在不同的分支上（就有不同的版本号），测试人员git checkout,
2.测试环境
在不同的测试环境，问题出现的情况不一样
(1)测试web系统: MAC系统 / Windows系统 + 操作系统 + 不同的浏览器 + 浏览器的版本号
常用浏览器：谷歌、IE、火狐、EDGE、360、搜狗、猎豹、QQ、苹果浏览器Safair
（2）测试APP: 软件环境(IOS系统 / 安卓系统 / 鸿蒙系统 / 塞班系统（诺基亚手机）/ Windows系统 + 安装的系统版本) + 硬件环境(不同的设备：品牌、系列)
3.测试步骤
测试数据和执行测试的详细步骤，为了方便开发人员复现问题
那什么是复现呢？
让问题再次出现，方便开发人员查问题，分析问题怎么出现的
4.实际结果
测试用例的运行结果
5.预期结果（需求期望的结果）
6.bug产生时的log日志，错误截图等附件
三、bug的级别（粗略划分）
1.崩溃
系统崩溃，不能运行。比如死循环、数据库死锁、资源分配不均、黑屏、闪退、阻塞
线上（用户使用的环境）出现了崩溃级别的bug，怎么处理？
回退到上一个可用的历史版本。
2.严重
服务器可以用，但是不稳定，继续使用会产生严重的错误。比如，一级菜单错误，数据库插入用户数据错误，威胁到用户的安全等
3.一般
系统可以稳定的运行，次要的功能没有实现。比如，提示语不完善，弹出框没有关闭按钮，不影响用户的使用。
4.建议 / 次要
建议性的，提示信息重叠（看不清楚），界面排版不符合用户使用习惯、颜色不符合使用场景（根据节日调节背景，过年、南京大屠杀纪念日、中秋）
四、bug的生命周期
一个Bug从无到有的各种状态
问题：发现了一个bug,开发人员修改了，通知测试人员验证，但是测试人员又复现了这个bug，是什么原因？
（1）开发人员修改了代码，但没有提交到远程，测试人员使用的还是之前的代码
（2）开发人员理解不到位，没有修改成功
（3）测试环境不同
五、因为一个bug和开发人员产生争执怎么办
1.检查自己的bug描述，是否描述清楚
2.可以从用户角度考虑，说服开发人员
3.bug顶级要有理有据，符合公司的规范
4.测试人员要不断提升自己的专业技能和业务水平（别人就不敢轻易质疑了）
5.找产品经理讨论相关解决方案
六、如何设置弱网？
Charles（抓包工具）弱网设置