OSI7层模型
TCP/IP五层模型
OSI7层模型的特点
- 下层为上层提供服务
- 同层次之间使用相同的协议
应用层有哪些协议？
http、https
传输层有哪些协议？
TCP、UDP
TCP与UDP的区别与联系
面向连接的服务(TCP)
- 先建立连接再传输数据
- 数据传输过程中，数据包不需要携带目的地址
- 保证数据传输的可靠性
无连接的服务(UDP)
- 不需要事先建立连接，直接发送数据
- 每个报文都带有完整的目的地址
- 不保证报文传输的可靠性
TCP如何建立连接
通过三次握手建立连接
A 发送连接请求 B
B 回复确认连接 A
A 收到回复后，建立连接 B
启动/关闭/ tomcat服务
'''cd 到tomcat目录下的bin目录'''
./startup.sh #启动tomcat服务
./shutdown.sh #关闭tomcat服务
'''使用catalina.sh同样也可以启动或者关闭tomcat服务'''
'''cd 到tomcat目录下的bin目录'''
./catalina.sh stop #关闭tomcat服务
./catalina.sh start #启动tomcat服务
bin用来存放tomcat的命令的地方
webapps用来存放软件包的目录
启动/关闭/重启 http服务
service httpd start
service httpd stop
service httpd restart
启动/关闭/重启 mysql服务
service mysqld start
service mysqld stop
service mysqld restart
B/S架构和C/S架构
- B/S架构需要重点考虑系统在不同的浏览器中的兼容性问题(浏览器的内核不同)
- C/S 架构需要考虑系统在不同平台的安装、卸载、升级
HTTP协议
HTTP协议,超文本传输协议,应用层协议，由请求和响应构成
常见的请求方式（get，post）
post请求与get请求的区别
- get请求，发送的数据跟随网址(URL),一起传输。
- post请求，发送的数据，在请求体里单独传输。
Cookie和Session的区别与联系
- cookie数据存放在客户的浏览器上，session数据放在服务器上。
- cookie不是很安全，别人可以分析存放在本地的COOKIE并进行COOKIE欺骗考虑到安全应当使用session。
- session会在一定时间内保存在服务器上，当访问增多，会比较占用你服务器的资源。
HTTP状态码
| 状态码 | 含义 |
|---|---|
| 200 | ok |
| 301 | 永久移动 |
| 302 | 临时移动 |
| 404 | 找不到资源 |
| 500 | 服务器内部错误 |
常见默认端口
| 软件 | 默认端口 |
|---|---|
| oracle | 1521 |
| mysql | 3306 |
| http | 80 |
| https | 443 |
| tomcat | 8080 |
| ssh | 22 |
| ftp | 21 |
瀑布模型
V模型
软件测试流程/生命周期
测试需求分析
测试需求评审
编写测试计划
设计测试用例
测试用例评审
搭建测试环境
测试执行
回归测试
测试报告
软件测试的定义
在规定的条件下对程序进行操作，以发现程序的错误，并对软件质量进行评估。
测试的目的
不仅仅是为了发现软件缺陷与错误，而且也是对软件质量进行度量和评估，以提高软件的质量。
软件测试原则
所有的软件测试都应追溯到用户需求。
应当尽早地和不断地进行软件测试。
完全测试是不可能的，测试需要终止。
充分注意测试中的群集现象。
程序员应避免检查自己的程序。
尽量避免测试的随意性
软件测试风险
进度风险、质量风险、人员风险、需求变更、成本风险等
按阶段划分
单元测试
集成测试
系统测试
验收测试
单元测试关注点
对软件中的最小可测试单元进行检查和验证
集成测试关注点
在把各个模块连接起来时，穿越模块接口的数据是否会丢失
集成测试级别
- 子系统间的数据集成测试。
- 不同系统间的数据集成测试。
什么是系统测试
系统测试是针对整个产品系统进行的测试
系统测试的范围
功能测试、用户体验测试、性能测试、UI测试、兼容性测试、安装测试、文档测试、稳定性测试等
验收测试
主要确认软件是否满足软件需求规格说明书中的要求。
alpha测试、beta测试的区别
alpha测试：公司内部员工组织的测试
beta测试：由典型客户进行的测试
白盒测试、黑盒测试、灰盒测试
白盒：对程序内部结构和算法进行测试
黑盒：在完全不考虑程序内部逻辑的情况下，检查程序是否满足用户需求
灰盒：关注系统接口所实现的功能，是否和需求一致
回归测试
全量回归：对软件的新版本测试时，重复执行上一个版本测试时使用的测试用例，防止出现以前应用没有的问题现在出问题了
部分回归：当在测试过程中，发现某个模块存在缺陷，开发修复后，测试人员重新验证该缺陷是否被修复，以及验证相关联的模块是否受影响
冒烟测试/预测试
目的是确认软件基本功能正常，可以进行后续的正式测试工作
质量六大特性
需求分析的目的
澄清需求，提取测试点
需求评审的目的
- 完整性审查
- 准确性审查
需求评审那些人会参与
开发人员、开发经理、测试人员、测试经理、产品经理
测试计划的目的/为什么要编写测试计划
为了规范软件测试内容、方法和过程，在对软件进行测试之前，必须创建测试计划。
什么时间开始编写测试计划？
需求分析后编写测试计划，在整个测试工作过程中，不断修改
由谁来编写测试计划
一般来说都是测试经理、测试组长来编写,经验丰富的测试人员
测试的结束条件
需求覆盖率、用例执行率、缺陷遗留率达到预定质量目标。
测试计划的内容
测试项目的背景、测试范围、测试方式/策略、测试资源、测试开始和结束条件、进度安排、测试组织，以及与测试有关的风险方面
常见web服务器
apache、tomcat、nginx、weblogic
常见DB服务器
mysql、oracle
常见编程语言
Java、PHP、Python
常见linux系统
redhat、centos、ubuntu、aix
测试用例的要素/元素
用例编号/id，用例标题，用例的级别，预置条件，操作步骤，预期结果，实际结果
如何划分/确定用例的级别
- 依据用户使用该场景的频率
- 该功能对系统的影响程度来确定
写好测试用例的关键 /写好用例要关注的维度
- 覆盖用户的需求；
- 考虑用户的各种正常和异常的使用场景；
- 用例的颗粒大小要均匀。通常，一个测试用例对应一个场景；
- 用例各个要素要齐全，步骤应该足够详细，操作应该明确，容易被其它测试工程师读懂，并能顺利执行；
- 做好用例评审，及时更新测试用例
测试用例的状态
- No Test未执行状态
- Pass通过状态
- Fail失败状态
- Block阻碍状态。
- Investigate观察中状态。
测试环境怎么搭建的？
参考答案：搭建环境前，开发都会给到我们一份系统发布手册，我们会根据这个手册来搭建。比如，我这个xx系统，是搭建在Unix系统下的，web服务器用的是Tomcat8，MySQL版本是5.7，程序是JAVA编写的，首先我们向开发拿到编译好的安装包，然后用xshell(或CRT)远程连接上Unix系统，把tomcat服务器停掉，把程序包放到webapps目录下，然后再启动tomcat服务器就可以了。
偶然性问题的处理
- 确定是偶然性的bug之后，收集相关的日志，连同截图一起提单给开发定位；
- 如果没有日志记录，缺陷在当前版本无法复现，且缺陷的影响程度比较低，可以提交问题单进行跟踪，跟踪三个版本，如果后三个版本都无法复现，就可以关闭该缺陷；
- 如果这些不可复现的Bug是很严重的Bug，比如导致系统崩溃等，并且，实在没有再次出现，除了要及时反馈给上级之外，最后还要写到测试报告中，说明出现了什么现象，但无法再现！
当我们认为某个地方是bug，但开发认为不是bug，怎么处理？
- 先跟开发沟通，确认系统的实际结果是不是和需求有不一致的地方；有些地方可能需求没提及，但是用户体检不好，我们也可以认为是bug。
- 如果开发以不影响用户使用为理由，拒绝修改，我们可以和产品经理，测试经理等人员进行讨论，确定是否要修改，如果大家都一致认为不用改，就不改。
产品在上线后用户发现bug，这时测试人员应做哪些工作？
- 测试人员复现问题后，提交问题单进行跟踪；
- 评估该问题的严重程度，以及修复问题时的影响范围，回归测试需要测试哪些功能；
- 问题修复后，先在测试环境上回归，通过后再在生产环境上打补丁，然后再进行回归测试；
- 总结经验，分析问题发生的原因，避免下次出现同样问题。
二八定理:80%的缺陷出现在 20%的模块。
bug的等级
致命，严重，一般，轻微
缺陷的状态
激活，确认，已解决，关闭
如何跟踪缺陷
当发现缺陷后，我们要在禅道上提交问题单给开发，并每隔一段时间(间隔一个小时，或两个小时都可以)去检查缺陷是否被处理，如果没及时处理，就要提示开发，让开发及时修复问题，问题修复后，要及时进行回归测试。
缺陷单应该包含这些要素
缺陷标题，严重级别，问题所属模块，复现步骤，预期结果，实际结果，有关的日志和截图。
测试报告的主要内容
数据统计
遗留bug情况
测试风险
测试对象评估
测试结论