测试基础

1.URL和URI

统一资源标志符URI

统一资源定位符URL:所以URL是URI的子集

2. HTTP和HTTPS

HTTP是超文本传输协议，是一个基于请求与响应，无状态的，应用层的协议，常基于TCP/IP协议传输数据

http协议的请求可以分成三部分：request line  headers body

headers,body是可选的，request line则又可细分成三部分：method，uri，version

发展历史：

版本    产生时间    内容    发展现状
HTTP/0.9    1991年    不涉及数据包传输，规定客户端和服务器之间通信格式，只能GET请求    没有作为正式的标准
HTTP/1.0    1996年    传输内容格式不限制，增加PUT、PATCH、HEAD、 OPTIONS、DELETE命令    正式作为标准
HTTP/1.1    1997年    持久连接(长连接)、节约带宽、HOST域、管道机制、分块传输编码    2015年前使用最广泛
HTTP/2    2015年    多路复用、服务器推送、头信息压缩、二进制协议等    逐渐覆盖市场

多路复用：通过单一的HTTP/2连接请求发起多重的请求-响应消息，多个请求stream共享一个TCP连接，实现多留并行而不是依赖建立多个TCP连接

HTTPS是身披SSL外壳的HTTP。HTTPS是一种通过计算机网络进行安全通信的传输协议，经由HTTP进行通信，利用SSL/TLS建立全信道，加密数据包

3. get和post

GET和POST本质上就是TCP链接，并无差别。但是由于HTTP的规定和浏览器/服务器的限制，导致他们在应用过程中体现出一些不同。 GET和POST还有一个重大区别，简单的说：GET产生一个TCP数据包；POST产生两个TCP数据包。

对于GET方式的请求，浏览器会把http header和data一并发送出去，服务器响应200（返回数据）； 而对于POST，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok（返回数据

 

3.TCP与UDP区别总结：
  1、TCP面向连接（如打电话要先拨号建立连接）;UDP是无连接的，即发送数据之前不需要建  立连接
  2、TCP提供可靠的服务。也就是说，通过TCP连接传送的数据，无差错，不丢失，不重复，  且按序到达;UDP尽最大努力交付，即不保证可靠交付
  3、TCP面向字节流，实际上是TCP把数据看成一连串无结构的字节流;UDP是面向报文的
  UDP没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低（对实时应用很有用，  如IP电话，实时视频会议等）
  4、每一条TCP连接只能是点到点的;UDP支持一对一，一对多，多对一和多对多的交互通信
  5、TCP首部开销20字节;UDP的首部开销小，只有8个字节
  6、TCP的逻辑通信信道是全双工的可靠信道，UDP则是不可靠信道

4.响应

5. 软件测试原则

• 只能证明软件存在问题，不能证明不存在问题
• 不能进行穷尽（穷举）测试，应该分类别测试
• 测试工作要尽早的介入，降低修复成本（需求文档--ui、程序、测试）
• 缺陷存在集群现象，二八原则：20%的模块中存在80%的缺陷
• 测试依赖环境（系统、浏览器）
• 杀虫剂现象
• 不存在缺陷谬论

6. 软件开发模型

• 瀑布模型（需求分析》概要设计》详细设计》编码》软件测试》软件维护）

优点：开发的各个阶段比较清晰，当前阶段完成后，只需关注后续阶段

缺点：不适应需求的变化，风险往往延至后期才显著，失去及早纠正的机会

• 快速原型模型
• 螺旋模型

7. 软件测试模型

V模型，W模型

优点: (1)测试V模型即包含了底层测试又包含了高层测试；

缺点: (1)当需求变更时将会导致返工量非常大，模型灵活性比较低。

优点: (1)强调测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，还包括需求和设计。 (2)更早地介入测试，能尽早得发现缺陷进行修复。

缺点: (1)对于测试技术要求高，实践起来困难

 

8. 软件测试分类

8.1 按测试阶段划分

• 单元测试

又称模块测试，针对软件设计中的最小单位-程序模块，进行正确性检查的测试工作。单元测试需要从程序内 部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。

单元定义:C中指一个函数，Java中指一个

• 集成测试

又叫组装测试，通常在单元测试的基础上，将所有程序模块进行有序的、递增的测试。

• 系统测试

指的是将整个软件系统看为一个整体进行测试，测试的依据是软件需求说明书

• 验收测试

检验软件是否符合用户需求的测试

α测试

    Alpha 是内测版本 通常只在软件开发者内部交流 一般而言, 该版本软件的bug较多,普通用户最好不要安装

β测试

   Beta是公测版本，是对所有用户开放的测试版本 这一版本通常由软件公司免费发布, 用户可从相关的站点下载 通过一些专业爱好者的测试, 将结果反馈给开发者, 开发者们再进行有针对性的修改

γ测试

    Gamma版本，指的是软件版本正式发行的候选版。该版本已经相当成熟了, 与即将发行的正式版相差无 几, 成为正式发布的候选版本

8.2 按是否查看源代码

• 黑盒测试

又称数据驱动测试，完全不考虑程序内部结构和内部特性，注重于测试软件的功能需求，只关心软件的输入数据和 输出数据

• 白盒测试

指的是把盒子打开，去研究里面的源代码和程序结构。

• 灰盒测试

灰盒测试，是介于白盒测试与黑盒测试之间的一种测试，不仅关注输出、输入的正确性，同时也关注程序内部 的情况

 

8.3 是否运行分类

• 静态测试

指不实际运行被测软件，而只是静态地检查程序代码、界面或文档中可能存在的错误过程。

• 动态测试

是指实际运行被测程序，输入相应的测试数据，检查实际输出结果和预期结果是否相符的过程。

 

8.4 软件测试的更多分类

• 冒烟测试

冒烟测试就是对系统进行最基本功能的测试，保证基本的功能和流程能走通

• 回归测试

当修复一个BUG后，把之前的测试用例在新的代码下进行再次测试

• 随机测试

随机测试主要是对被测软件的一些重要功能进行复测，也包括测试那些当前的测试用例没有覆盖到的部分

• 探索性测试

探索性测试意味着同时设计测试和执行测试。测试人员通过测试来不断学习被测系统。

9. 软件缺陷

9.1 软件缺陷的判定标准

• 软件未达到需求规格说明书中标明的功能
• 软件出现了需求规格说明书指明不会出现错误的地方
• 软件的功能超出了需求规格说明书指明的范围
• 软件未达到需求规格说明书虽未指明但应该达到的目标
• 软件测试人员认为软件难以理解，不易使用，运行速度慢，或者最终用户体验不好

9.2 软件缺陷产生的原因

• 需求解释、记录或者定义错误
• 设计文档说明存在错误或者拼写错误
• 编码说明、程序代码有误
• 硬件或者软件系统上存在错误

9.3 软件缺陷产生的根源

• 需求的变更
• 交流不充分
• 软件的复杂性
• 进度压力

9.4 软件缺陷的类型

• 功能错误
• 界面错误
• 兼容性缺陷
• 易用性问题
• 改进建议

10 测试用例

10.1 测试用例的八大要素

• 软件测试用例的基本要素包括用例编号、用例标题、测试项目、用例级别、预置条件、测试输入、执行步骤、 预期结果