项目的测试流程
1. 拿到需求文档后，写测试用例
2. 审核测试用例
3. 等待开发包
4. 部署测试环境
5. 冒烟测试（网页架构图）
6. 页面初始化测试（查看数据库中的数据内容和页面展示的内容是否一致，并且是否按照某些顺序排列）
7 .具体执行测试用例（几乎所有的功能测试、流程法、场景法）
8. 发现缺陷就要再填写缺陷表
9. 非功能性测试（sql、js注入、页面效率、绕过js验证直接添加数据到数据库）
10. 书写最终的测试报告
测试用例设计方法
等价类、边界值、正交试验法、状态迁移法、因果图、场景测试法、异常分析法、因果图、错误猜测法、判定
表
测试用例的要素
Id 主题 测试名称 创建日期 设计者 描述 步骤名 步骤描述 预期结果 执行状态
测试的优先级
1. 先测试经过变更的部分，然后测试没有变更的部分
2. 先测试程序的核心功能，然后测试一般功能
3. 先测试逻辑性的功能，然后测试业务性的功能
4. 先测试常规情况，然后测试异常情况
5. 先测试功能，然后测试性能
测试报告包含哪些内容
1.写测试背景
2.测试目标
3.测试范围
4.测试环境
5.测试数据
6.测试标准（重点）
7.测试进度
8.测试结果
9.测试结论
有的公司会采用非标准的测试报告
大致会包含 测试所用时间 测试环境 测试人员 测试发现bug数量 已修复bug数量 遗留bug 遗留bug原因
测试结果等
BUG的生命周期
提交--开发验证--接受--拒绝--开发解决--测试人员验证--关闭--不通过打开
BUG的状态
1. NEW：所有提交到开发对接的问题状态为NEW，表示为未处理
2. OPEN：开发对接人初判为需流转问题，指定测试人员和开发人员，状态为OPEN。
3. REFUSE：开发对接人判断为不需要流转至下环节的问题，状态为REFUSE，并且填写原因
4. FIXED：开发人员完成修复，待测试，状态为FIXED
5. REOPEN：测似人员针对开发人员的修复结果测试部通过，状态为REOPEN
6. CLOSE：测试人员判断问题为需求或其他问题，需填写原因；
缺陷的要素
缺陷标题 缺陷状态 提交人 负责人 优先级 严重程度 缺陷描述 时间 截图
缺陷的级别
致命问题 核心功能不可用或系统崩溃
严重问题 业务主要流程无法使用，业务主要流程中的某个功能存在缺陷导致主要流程无法继续使用
一般问题 一般性问题，非主要流程上的功能缺陷
轻微问题 界面ui问题 提示不规范等
建议性问题 根据自己的经验提一些建议性的问题
WEB测试与APP测试的区别
1. 架构不同。
web端是b/s架构的，b/s架构是基于浏览器地址访问的
app端是c/s架构的，c/s架构是要有客户端作为载体的
2. 版本发布的方式和流程不同。
web发版本，开发部署新的代码到对应服务器地址，就可统一实现web端的更新
app发版本，开发需要打包（apk包和ipa包），打包之后需要发布到对应的渠道
3. 兼容性
web，测试不同浏览器的兼容性（ie、chrome、firefox、360、QQ）
app，测试不同的分辨率、屏幕尺寸、手机品牌、系统版本
4. 性能方面
web，测试响应的时间
app，测试响应时间、流量、耗电量、CPU、GPU、memory
5. 安全性
web，sql注入。xss攻击等
app，https加密、签名、加固、密码加密等
6、app测试特点
适配性测试
网络测试
在线升级测试
中断测试
耗电量测试
弱网测试
安装卸载测试
流量测试
app测试的主要内容
1. 功能测试
业务逻辑正确性的测试
2. 兼容性测试
系统版本
分辨率
网络情况
3. 异常测试
热启动
网络切换
电话信息终端恢复
4. 升级、安装、卸载
5. 健壮性测试
手机资源消耗
流量消耗
电量测试
崩溃恢复
如果一个bug，开发认为不是一个bug，怎么处理
1. 将问题提交到缺陷管理库里面进行备案。
2. 获取判断的依据和标准
根据需求说明书、产品说明、设计文档等，确认实际结果是否与计划有不一致的地方，提供缺陷是否确认的直接依据；
如果没有文档依据，可以根据类似软件的一般特性来说明是否存在不一致的地方，来确认是否是缺陷；
根据用户的一般使用习惯，来确认是否是缺陷；
与设计人员、开发人员和客户代表等相关人员探讨，确认是否是缺陷；
3. 合理的论述，向测试经理说明自己的判断的理由，注意客观、严谨，不参杂个人情绪。
4. 等待测试经理做出最终决定，如果仍然存在争议，可以通过公司政策所提供的渠道，向上级反映，并有上级做出决定。
常用linux命令
1. ifconfig 查看IP地址
2. cat 用于显示指定文件的全部内容
3. more 用分页的形式显示指定文件的内容
4. mkdir 创建目录
5. touch 创建新的文件
6. grep 查找文件里符合条件的字符串
7. find 查找指定的文件
8. tail -f 用于自动刷新显示文件后N行数据内容
9. kill -9 强制结束
10. netstat -anp | grep 端口号 查看端口
11. chmod -R 777 赋予777权限
什么情况下定位不到元素
1. 代码写错
2. 元素未出现（需要元素等待）
3. 元素在iframe中
4. 多窗口
5. 出现弹窗（系统弹窗、JS弹窗）
6. 元素属性值是动态加载的
7. 元素无法确定唯一性
8. 只读属性（元素不可操作）
GET请求和POST请求的区别
1. GET使用URL或Cookies传参，POST将数据放在BODY中
2. GET的URL会有长度上的限制，POST的数据则可以非常大
3. POST比GET安全，因为在地址栏不可见
4. 一般GET用来获取数据，POST用来发送数据
为什么要做接口测试
1. 越底层发现BUG，修复成本越低
2. 前端发生变化时，后端接口可以不用变
3. 检查系统的安全性、稳定性，前端传参不可信
接口测试是怎么做的
–由于我们项目前后端调用主要是基于http协议的接口，所以测试接口时主要是通过工具或代码模拟http请求的发送与接收。工具有很多如：postman、jmeter、soupUI等。
–也可以用 接口自动化来实现，就是用代码实现，框架和UI自动化差不多，发送请求用断言来判断。
接口测试的重点
1. 检查接口返回的数据是否与预期的结果一致
2. 检查接口的容错性，加入传递的类型错误时是否可以处理
3. 接口测试的边界值
4. 接口的性能
5. 接口的安全性
http状态码
1. 1xx：请求正常，但是无响应，只有在实验状态下使用
2. 2xx：2开头的表示发送成功
3. 3xx：3开头的代表重定向，常见302
4. 4xx：400代表客户端发送的语法有错误，401代表访问的页面没有授权，403 无权限访问该网页，404代表没有这个页面，415 格式错误
5. 5xx：5开头的代表服务器异常，500代表服务器内部异常，504代表服务器超时
cookies和session的区别
1. cookies数据存放在客户的浏览器上，session数据放在服务器上
2. cookies不是很安全，别人可以分析存放在本地的cookies并进行cookies欺骗考虑到安全应当使用session
3. session会在一定时间内保存在服务器上，当访问增多，会比较占用，你服务器的性能考虑到减轻服务器性能方面，应当使用cookies
常用的adb命令
1. adb start-server 启动adb服务
2. adb kill-server 关闭adb服务
3. adb devices 查看设备号
4. adb push 电脑 手机
5. adb pull 手机 电脑
6. adb logcat | grep 包名（unix）
7. adb logcat | findstr 包名 （win）
8. adb shell 进入shell命令行
9. adb install 安装app到手机上
10. adb uninstall 卸载app到手机上
11. adb logcat > 文件名 输出log到文件
12. adb shell top 测试app的资源消耗命令
产品的业务流程
解析
问你简历上写的某个项目整体的业务流程
比如电商项目中的注册功能，从开始注册到注册成功的整个过程
版本符合上线的标准是什么
验收标准
(1) 软件需求分析说明书中定义的所有功能已全部实现，性能指标全部达到要求。
(2) 在验收测试中发现的错误已经得到修改，各级缺陷修复率达到标准
(3) 所有测试项没有残余紧急、严重级别错误。
(4) 需求分析文档、设计文档和编码实现一致。
(5) 验收测试工件齐全（测试计划、测试用例、测试日志、测试通知单、测试分析报告，待验收的软件安装程
序。）
缺陷修复率标准
(1) 紧急、严重级别错误修复率应达到100%;
(2) 普通级别错误修复率应达到95%以上;
(3) 优化级别错误修复率应达到60%以上;
注：项目紧急时，普通级别错误修复率达60% 以上；优化级别错误修复率达20% 即可。
服务器运行状态响应指标
(1) cpu% 并发期间最大使用率应不超过70-80%，如有集合点并发可允许短暂接近或到达100& 但大部分不
应查过95%;
(2) memery 测试期间保证内存充足可用内存不少于20%;
(3) disk 监控硬盘是否有读写不超过40%;
(4) cpu load average 不应超过cpu 核心数*2 或者不超过cpu 核心数。
测试用例评审过程及相关参与人员
1:评审的过程
A:开始前做好如下准备
1、确定需要评审的原因
2、确定进行评审的时机
3、确定参与评审人员
4、明确评审的内容
5、确定评审结束标准
6、提前至少一天将需要评审的内容以邮件的形式发送给评审会议相关人员。并注明详审时间、地点及偿参与人员等。
7、 在邮件中提醒评审会议相关人员至少简读一遍评审内容，并记录相关的疑问，以便在评审会议上提出。
8、 会议主持者(一般为用例编写人员)应在会议前整理相关疑问，以便在会议上提出。
B：开始评审
1、 召开评审会议。与会者在设计人员讲解之后给出意见和建议，同时进行详细的评审记录。
2、 通用邮件与相关人员沟通
3、 通用IM工具直接与相关人员交流
4、根据评审内容进行评审
2：评审内容
1、 用例设计的结构安排是否清晰、合理，是否利于高效对需求进行覆盖。
2、 优先极安排是否合理。
3、 是否覆盖测试需求上的所有功能点。
4、 用例是否具有很好可执行性。例如用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确；期待结果是否有明显的验证方法。
5、 是否已经删除了冗余的用例。
6、 是否包含充分的负面测试用例。充分的定义，如果在这里使用2&8法则，那就是4倍于正面用例的数量，毕竟一个健壮的软件，其中80%的代码都是在“保护”20%的功能实现。
7、 是否从用户层面来设计用户使用场景和使用流程的测试用例。
8、 是否简洁，复用性强。例如，可将重复度高的步骤或过程抽取出来定义为一些可复用标准步骤。
3：参与评审人员（这里会分为多个级别进行评审）
1、 部门评审，测试部门全体成员参与的评审。
2、公司评审，这里包括了项目经理、需求分析人员、架构设计人员、开发人员和测试人员。
3、 客户评审，包括了客户方的开发人员和测试人员。这种情况在外包公司比较常见