测试基础
OSI7层模型
- 应用层
- 表示层
- 会话层
- 传输层
- 网络层
- 数据链路层
- 物理层
tcp/ip 5层模型
- 应用层
- 传输层
- 网络层
- 数据链路层
- 物理层
传输层有哪些协议?
TCP/UDP
应用层有哪些协议？
http/https
TCP协议与UDP协议的区别
TCP协议
- 先建立连接，再传输数据
- 数据在传输过程中不携带目的地址
- 保证数据传输的可靠性
UDP协议
- 不需要事先建立连接，直接发送数据
- 数据在传输的过程中，具有详细的目的地址
- 不确保数据传输的可靠性
TCP如何建立连接
TCP通过三次握手建立连接
- 主机A 发送连接请求 主机B
- 主机B 同意连接 主机A
- 主机A 建立连接 主机B
常见的web服务器
apache/tomcat/nginx/iis
B/S架构和C/S架构比较
- B/S架构需要重点考虑系统在不同的浏览器中的兼容性问题
- C/S架构需要考虑在不同平台的安装卸载升级
什么是http协议？
超文本传输协议，HTTP是一个应用层协议，由请求和响应构成
常见头部信息含义
accept-encoding:gzip 告诉服务器，接受的是你压缩后的内容
user-agent 标识用户身份，是pc端的，还是手机端的
get/post的区别
get请求，发送的数据，跟随网址(URL)一起发送
post请求，发送的数据，在请求体里，单独发送
http状态码
|
状态码 |
含义 |
|
200 |
成功OK |
|
301 |
永久移动 |
|
302 |
临时移动 |
|
404 |
找不到资源 |
|
500 |
服务器内部错误 |
常见软件默认端口号
|
软件 |
默认端口 |
|
oracle |
1521 |
|
mysql |
3306 |
|
http |
80 |
|
https |
443 |
|
tomcat |
8080 |
|
Fiddler |
8888 |
|
ssl |
22 |
cookie与session的区别
- cookie保存在浏览器上,session保存在服务器上
- cookie不太安全，涉及到用户隐私的信息，尽可能保存在session中
- 当访问量增多时，session会比较占用服务器的资源
瀑布模型的组成
计划-需求分析-设计-编码-测试-运维
V模型的组成(非必记内容)
用户需求-需求分析-概要设计-详细设计-编码-单元测试-集成测试-系统测试-验收测试
软件测试流程/软件测试的生命周期
- 需求分析
- 需求评审
- 编写测试计划
- 设计测试用例
- 测试用例评审
- 搭建测试环境
- 执行测试
- 回归测试
- 测试报告
什么是软件测试
在规定的条件下对程序进行操作，以发现程序的错误，并对软件质量进行评估
软件测试的目的
发现软件缺陷与错误，对软件质量进行度量和评估，以提高软件的质量。
软件测试的原则
- 所有的软件测试都应追溯到用户需求。
- 应当尽早地和不断地进行软件测试
- 完全测试是不可能的，测试需要终止。
- 充分注意测试中的群集现象。
- 程序员应避免检查自己的程序。
- 尽量避免测试的随意性
软件测试风险
进度风险、质量风险、人员风险、需求变更、成本风险
软件测试按阶段划分/软件测试分为哪几个阶段
- 单元测试
- 集成测试
- 系统测试
- 验收测试
单元测试的关注点
单元测试是指对软件中的最小可测试单元进行检查和验证
集成测试的关注点
在把各个模块连接起来时，穿越模块接口的数据是否会丢失
系统测试范围/策略/类型
功能测试、用户体验测试、性能测试、UI测试、兼容性测试、安装测试、文档测试、稳定性测试等
а测试与ß测试的区别
а测试是由公司内部人员进行的
ß测试是由公司组织的典型客户在日常工作中实际使用
白盒、黑盒、灰盒测试的区别
- 白盒测试：针对程序的内部结构与算法进行的测试
- 黑盒测试：不考虑程序的内部结构，只看软件是否满足需求
- 灰盒测试：系统的接口实现的功能是否满足需求
回归测试怎么做？
回归测试分为全量回归和部分回归
全量回归指软件在新版本测试时，重复执行上一版本的测试用例，防止以前没有出现的问题，现在出现了
部分回归当开发修复了某一模块的缺陷时，需要验证该缺陷是否被修复，还需要验证与之相关联的模块是否受影响。
冒烟测试/预测试的目的
确认软件基本功能正常
质量的六大特性
功能性、可靠性、易用性、效率、维护性、可移植性
需求分析的目的
澄清需求，提取测试点
什么时候编写测试计划
需求分析之后
由谁编写测试计划
测试经理/测试组长/测试经验丰富的测试人员
测试计划的内容
测试项目的背景、
试资源、测试开始和结束条件、进度安排、测试组织，以及与测试有关的风险方面
软件测试结束的条件
需求的覆盖率、用例的执行率、缺陷的遗留率达到预定指标
通常来说
- 需求的覆盖率、用例的执行率 需要达到100%
- 严重级别的缺陷必须当天解决，一般、轻微级别的缺陷，遗留率不能超过30%
测试用例元素有哪些？
用例的ID，用例的标题，级别，预置条件，操作步骤，预期结果
如何确定用例的级别
- 根据用户使用该场景的频率
- 该功能对于系统的影响程度
写好测试用例的关键 /写好用例要关注的维度
- 覆盖用户的需求；
- 考虑用户的各种正常和异常的使用场景；
- 用例的颗粒大小要均匀。通常，一个测试用例对应一个场景；
- 用例各个要素要齐全，步骤应该足够详细，操作应该明确，容易被其它测试工程师读懂，并能顺利执行；
- 做好用例评审，及时更新测试用例。
测试用例的状态
|
英文 |
中文 |
|
No Test |
尚未执行 |
|
Pass |
通过 |
|
Fail |
失败 |
|
Block |
阻碍 |
|
Investigate |
观察中 |
测试环境怎么搭建的？
搭建环境前，开发都会给到我们一份系统发布手册，我们会根据这个手册来搭建。比如，我这个xx系统，是搭建在Unix系统下的，web服务器用的是Tomcat8，MySQL版本是5.7，程序是 JAVA编写的，首先我们向开发拿到编译好的安装包，然后用xshell(或CRT)远程连接上Unix系统，把tomcat服务器停掉，把程序包放到webapps目录下，然后再启动tomcat服务器就可以了。
偶然性问题的处理
- 如果没有日志记录，缺陷在当前版本无法复现，且缺陷的影响程度比较低，可以提交问题单进行跟踪，跟踪三个版本，如果后三个版本都无法复现，就可以关闭该缺陷；
- 如果这些不可复现的Bug是很严重的Bug，比如导致系统崩溃等，并且，实在没有再次出现，除了要及时反馈给上级之外，最后还要写到测试报告中，说明出现了什么现象，但无法再现！
1、在测试执行过程中，一旦系统出现异常信息，我们第一时间要做的是截图，保存证据；
2、确定是偶然性的bug之后，收集相关的日志，连同截图一起提单给开发定位；
3、如果没有日志记录，缺陷在当前版本无法复现，且缺陷的影响程度比较低，可以提交问题单进行跟踪，跟踪三个版本，如果后三个版本都无法复现，就可以关闭该缺陷；
4、如果这些不可复现的Bug是很严重的Bug，比如导致系统崩溃等，并且，实在没有再次出现，除了要及时反馈给上级之外，最后还要写到测试报告中，说明出现了什么现象，但无法再现
当我们认为某个地方是bug，但开发认为不是bug，怎么处理？
- 先跟开发沟通，确认系统的实际结果是不是和需求有不一致的地方；有些地方可能需求没提及，但是用户体检不好，我们也可以认为是bug。
- 如果开发以不影响用户使用为理由，拒绝修改，我们可以和产品经理，测试经理等人员进行讨论，确定是否要修改，如果大家都一致认为不用改，就不改。
产品在上线后用户发现bug，这时测试人员应做哪些工作？
- 测试人员复现问题后，提交问题单进行跟踪；
- 评估该问题的严重程度，以及修复问题时的影响范围，回归测试需要测试哪些功能；
- 问题修复后，先在测试环境上回归，通过后再在生产环境上打补丁，然后再进行回归测试；
- 总结经验，分析问题发生的原因，避免下次出现同样问题。
如何跟踪缺陷
当发现缺陷后，我们要在禅道上提交问题单给开发，并每隔一段时间(间隔一个小时，或两个小时都可以)去检查缺陷是否被处理，如果没及时处理，就要提示开发，让开发及时修复问题，问题修复后，要及时进行回归测试。
缺陷的状态
激活、确认、已解决、关闭
缺陷的等级
致命、严重、一般、轻微
缺陷单的要素
缺陷标题，严重级别，问题所属模块，复现步骤，预期结果，实际结果，有关的日志和截图。
用例评审有哪些人参与？
产品、开发、测试、测试经理
测试报告的主要内容
数据统计、遗留bug情况、测试风险、测试对象评估、测试结论
