测试基础

OSI7层模型

1. 应用层
2. 表示层
3. 会话层
4. 传输层                    
5. 网络层
6. 数据链路层
7. 物理层

tcp/ip 5层模型

1. 应用层
2. 传输层
3. 网络层
4. 数据链路层
5. 物理层

传输层有哪些协议?

TCP/UDP

应用层有哪些协议？

http/https

TCP协议与UDP协议的区别

TCP协议

1. 先建立连接，再传输数据
2. 数据在传输过程中不携带目的地址
3. 保证数据传输的可靠性

UDP协议

1. 不需要事先建立连接，直接发送数据
2. 数据在传输的过程中，具有详细的目的地址
3. 不确保数据传输的可靠性

TCP如何建立连接

TCP通过三次握手建立连接

1. 主机A 发送连接请求 主机B
2. 主机B 同意连接 主机A
3. 主机A 建立连接 主机B

常见的web服务器

apache/tomcat/nginx/iis

B/S架构和C/S架构比较

1. B/S架构需要重点考虑系统在不同的浏览器中的兼容性问题
2. C/S架构需要考虑在不同平台的安装卸载升级

什么是http协议？

超文本传输协议，HTTP是一个应用层协议，由请求和响应构成

常见头部信息含义

accept-encoding:gzip 告诉服务器，接受的是你压缩后的内容

user-agent 标识用户身份，是pc端的，还是手机端的

get/post的区别

get请求，发送的数据，跟随网址(URL)一起发送

post请求，发送的数据，在请求体里，单独发送

http状态码

常见软件默认端口号

cookie与session的区别

1. cookie保存在浏览器上,session保存在服务器上
2. cookie不太安全，涉及到用户隐私的信息，尽可能保存在session中
3. 当访问量增多时，session会比较占用服务器的资源

瀑布模型的组成

计划-需求分析-设计-编码-测试-运维

V模型的组成(非必记内容)

用户需求-需求分析-概要设计-详细设计-编码-单元测试-集成测试-系统测试-验收测试

软件测试流程/软件测试的生命周期

1. 需求分析
2. 需求评审
3. 编写测试计划
4. 设计测试用例
5. 测试用例评审
6. 搭建测试环境
7. 执行测试
8. 回归测试
9. 测试报告

什么是软件测试

在规定的条件下对程序进行操作，以发现程序的错误，并对软件质量进行评估

软件测试的目的

发现软件缺陷与错误，对软件质量进行度量和评估，以提高软件的质量。

软件测试的原则

1. 所有的软件测试都应追溯到用户需求。
2. 应当尽早地和不断地进行软件测试
3. 完全测试是不可能的，测试需要终止。
4. 充分注意测试中的群集现象。
5. 程序员应避免检查自己的程序。
6. 尽量避免测试的随意性

软件测试风险

进度风险、质量风险、人员风险、需求变更、成本风险

软件测试按阶段划分/软件测试分为哪几个阶段

1. 单元测试
2. 集成测试
3. 系统测试
4. 验收测试

单元测试的关注点

单元测试是指对软件中的最小可测试单元进行检查和验证

集成测试的关注点

在把各个模块连接起来时，穿越模块接口的数据是否会丢失

系统测试范围/策略/类型

功能测试、用户体验测试、性能测试、UI测试、兼容性测试、安装测试、文档测试、稳定性测试等

а测试与ß测试的区别

а测试是由公司内部人员进行的

ß测试是由公司组织的典型客户在日常工作中实际使用

白盒、黑盒、灰盒测试的区别

1. 白盒测试：针对程序的内部结构与算法进行的测试
2. 黑盒测试：不考虑程序的内部结构，只看软件是否满足需求
3. 灰盒测试：系统的接口实现的功能是否满足需求

回归测试怎么做？

回归测试分为全量回归和部分回归

全量回归指软件在新版本测试时，重复执行上一版本的测试用例，防止以前没有出现的问题，现在出现了

部分回归当开发修复了某一模块的缺陷时，需要验证该缺陷是否被修复，还需要验证与之相关联的模块是否受影响。

冒烟测试/预测试的目的

确认软件基本功能正常

质量的六大特性

功能性、可靠性、易用性、效率、维护性、可移植性

需求分析的目的

澄清需求，提取测试点

什么时候编写测试计划

需求分析之后

由谁编写测试计划

测试经理/测试组长/测试经验丰富的测试人员

测试计划的内容

测试项目的背景、

试资源、测试开始和结束条件、进度安排、测试组织，以及与测试有关的风险方面

软件测试结束的条件

需求的覆盖率、用例的执行率、缺陷的遗留率达到预定指标

通常来说

1. 需求的覆盖率、用例的执行率 需要达到100%
2. 严重级别的缺陷必须当天解决，一般、轻微级别的缺陷，遗留率不能超过30%

测试用例元素有哪些？

用例的ID，用例的标题，级别，预置条件，操作步骤，预期结果

如何确定用例的级别

1. 根据用户使用该场景的频率
2. 该功能对于系统的影响程度

写好测试用例的关键 /写好用例要关注的维度

1. 覆盖用户的需求；
2. 考虑用户的各种正常和异常的使用场景；
3. 用例的颗粒大小要均匀。通常，一个测试用例对应一个场景；
4. 用例各个要素要齐全，步骤应该足够详细，操作应该明确，容易被其它测试工程师读懂，并能顺利执行；
5. 做好用例评审，及时更新测试用例。

测试用例的状态

测试环境怎么搭建的？

搭建环境前，开发都会给到我们一份系统发布手册，我们会根据这个手册来搭建。比如，我这个xx系统，是搭建在Unix系统下的，web服务器用的是Tomcat8，MySQL版本是5.7，程序是 JAVA编写的，首先我们向开发拿到编译好的安装包，然后用xshell(或CRT)远程连接上Unix系统，把tomcat服务器停掉，把程序包放到webapps目录下，然后再启动tomcat服务器就可以了。

偶然性问题的处理

1. 如果没有日志记录，缺陷在当前版本无法复现，且缺陷的影响程度比较低，可以提交问题单进行跟踪，跟踪三个版本，如果后三个版本都无法复现，就可以关闭该缺陷；
2. 如果这些不可复现的Bug是很严重的Bug，比如导致系统崩溃等，并且，实在没有再次出现，除了要及时反馈给上级之外，最后还要写到测试报告中，说明出现了什么现象，但无法再现！
3.  

1、在测试执行过程中，一旦系统出现异常信息，我们第一时间要做的是截图，保存证据；

2、确定是偶然性的bug之后，收集相关的日志，连同截图一起提单给开发定位；

3、如果没有日志记录，缺陷在当前版本无法复现，且缺陷的影响程度比较低，可以提交问题单进行跟踪，跟踪三个版本，如果后三个版本都无法复现，就可以关闭该缺陷；

4、如果这些不可复现的Bug是很严重的Bug，比如导致系统崩溃等，并且，实在没有再次出现，除了要及时反馈给上级之外，最后还要写到测试报告中，说明出现了什么现象，但无法再现

当我们认为某个地方是bug，但开发认为不是bug，怎么处理？

1. 先跟开发沟通，确认系统的实际结果是不是和需求有不一致的地方；有些地方可能需求没提及，但是用户体检不好，我们也可以认为是bug。
2. 如果开发以不影响用户使用为理由，拒绝修改，我们可以和产品经理，测试经理等人员进行讨论，确定是否要修改，如果大家都一致认为不用改，就不改。

产品在上线后用户发现bug，这时测试人员应做哪些工作？

1. 测试人员复现问题后，提交问题单进行跟踪；
2. 评估该问题的严重程度，以及修复问题时的影响范围，回归测试需要测试哪些功能；
3. 问题修复后，先在测试环境上回归，通过后再在生产环境上打补丁，然后再进行回归测试；
4. 总结经验，分析问题发生的原因，避免下次出现同样问题。

如何跟踪缺陷

当发现缺陷后，我们要在禅道上提交问题单给开发，并每隔一段时间(间隔一个小时，或两个小时都可以)去检查缺陷是否被处理，如果没及时处理，就要提示开发，让开发及时修复问题，问题修复后，要及时进行回归测试。

缺陷的状态

激活、确认、已解决、关闭

缺陷的等级

致命、严重、一般、轻微

缺陷单的要素

缺陷标题，严重级别，问题所属模块，复现步骤，预期结果，实际结果，有关的日志和截图。

用例评审有哪些人参与？

产品、开发、测试、测试经理

测试报告的主要内容

数据统计、遗留bug情况、测试风险、测试对象评估、测试结论

测试基础

原文：https://www.cnblogs.com/zhu520/p/12112326.html