测试基础知识

理论基础

Web测试是软件测试的一部分，是针对Web应用的一类测试。Web测试主要从以下几个方面入手：功能测试、UI/易用性测试、兼容性测试、性能测试、安全测试、浏览器功能。同时还要关注，后端数据的存储，查询下拉选的数据来源等

1.测试理论和方法

内容：软件测试的对象不仅仅是程序测试，软件测试应该包括整个软件开发期间各个阶段产生的文档，如需求文档，UI/交互稿/原型图，技术方案

目的：运行软件找出软件中存在的问题和缺陷，通过修复这些缺陷来提高软件的质量，避免因上线后因缺陷造成商业风险

原则：
测试标准是用户的需求
事先定义好产品的质量标准
尽早的不间断的进行测试
制定测试计划，排除随意性
不可脱离用例测试
避免自己测试自己的程序
完全测试不可能的，测试需要终止
妥善保存一切测试过程文档

软件测试过程：

经过需求分析之后，制定测试计划、设计测试用例、准备测试数据、执行测试、测试分析及缺陷跟踪、线上验证

测试阶段划分：

单元测试：模块测试，是针对软件设计的最小单位程序模块进行正确性检查
集成测试：组装测试或联合测试，在单元测试的基础之上，按概要设计和详细设计进行组装，目的，测试模块连接接口处可能存在的错误
系统测试：在真实或模拟环境下运行，验证程序是否满足设计需求
验收测试：在用户环境中测试，验证系统是否满足客户要求

测试技术划分：

1.白盒测试：又称结构测试或者逻辑驱动测试，是通过对程序内部结构的分析、检查来寻找问题，检查程序的结构及路径是否正确，检查程序的内部动作是否按照设计说明的规定来进行。
方法：
代码检查：review代码
静态结构分析：用测试工具生成函数调用关系图、模块控制流程图、内部文件调用关系图等。主要包括：控制流分析、数据流分析、接口分析、表达式分析
代码质量度量：白盒测试的动态测试包括功能确认与接口测试、覆盖率分析、性能分析、内存分析等
2.黑盒测试：1.等价类划分；2.边界值分析；3.错误推断；4.因果图；5.判定表驱动；6.正交试验；7.场景法

自动化测试：

把人为驱动的测试行为转为机器执行的一种过程。通常，在设计了测试用例并评审后，由测试人员按照测试用例一步步执行后，得到期望结果与实际结果的比较。为了节省人力、时间等资源

用例设计的原则：

单个用例覆盖最小化原则：1.覆盖边界定义要清晰，指向性强；2.用例间耦合度要低
测试用例代替产品文档功能的原则：1.多版本迭代；2.需求变动，文档更新不及时
单次投入成本和多次投入成本原则：1.开始编写，少量改动
测试结果分析和调试最简单化原则：主要针对的是自动化，调式分析要简单

功能测试用例执行窍门：

1.不离开测试用例，但不依赖
用例是经过设计、思考的，力图涵盖所有功能点，所以用例是测试执行的依据，但深度不够，难覆盖所有路径，再有需求变动，盲目机械的执行测试用例，测试效果一定不好。用例是一个参考，不依赖，测试过程中发散测试，不断思考，完善用例，效果更好
2.测试执行时，学会从测试用例中生成测试用例
测试用例的描述，有一个基本原则不要太复杂，功能交叉也不要太复杂。要特别注意多种条件的组合以及逻辑的先后顺序，要学会从单一的测试用例中，从整体考虑，生成更多的用例。

查找遗漏问题的方法：

1.Spec是基础和标准
测试用例的设计依赖产品文档、技术文档，难免有考虑不到的地方，反复阅读文档可能会有新的思路和启示。项目后期，回归阶段容易产生思维定式、疲惫，阅读文档，确认一下功能是否覆盖，测试结果是否一致，没有偏差。
2.相关变动邮件和讨论记录
3.不定期阅读别人的缺陷
4.多和开发人员沟通
5.有选择的重新验证以前的缺陷
6.关注变化
7.简单思维，以主线为主，避免重大遗漏

如何有效开展测试

周期性进行头脑风暴，促成知识交流、共享、升值
项目中创造好的测试条件
根据具体项目、测试人员经验决策测试的展开

web测试

接口测试

接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部系统各个子系统之间的交互点。测试的重点是检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系。

APP测试

HTTP和HTTPS

1、HTTPS 协议需要到 CA （Certificate Authority，证书颁发机构）申请证书，一般免费证书较少，因而需要一定费用。
2、HTTP 是超文本传输协议，信息是明文传输，HTTPS 则是具有安全性的 SSL 加密传输协议。
3、HTTP 和 HTTPS 使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
4、HTTP 的连接很简单，是无状态的。HTTPS 协议是由 SSL+HTTP 协议构建的可进行加密传输、身份认证的网络协议，比 HTTP 协议安全。(无状态的意思是其数据包的发送、传输和接收都是相互独立的。无连接的意思是指通信双方都不长久的维持对方的任何信息。)

TCP和UDP

三次握手：

第一次：Client发起请求；
第二次：Server响应请求；
第三次：Client确认收到发给Server；
连接建立。

四次挥手

第一次：Client发送断开请求；
第二次：Server响应数据发送完毕；
第三次：Server断开响应；
第四次：Client确认断开给Server；
连接断开。

TCP协议和UDP协议特性区别总结：
1. TCP协议在传送数据段的时候要给段标号；UDP协议不
2. TCP协议可靠；UDP协议不可靠
3. TCP协议是面向连接；UDP协议采用无连接
4. TCP协议负载较高，采用虚电路；UDP采用无连接
5. TCP协议的发送方要确认接收方是否收到数据段（3次握手协议）
6. TCP协议采用窗口技术和流控制

网络协议

OSI模型

划分

物理层

作用：定义一些电器，机械，过程和规范，如集线器；
PDU(协议数据单元)：bit/比特
设备：集线器HUB;
注意：没有寻址的概念；

==========================================

数据链路层
作用：定义如何格式化数据，支持错误检测；
典型协议：以太网，帧中继（古董级VPN）
PDU：frame（帧）设备：以太网交换机；
备注：交换机通过MAC地址转发数据，逻辑链路控制；

===========================================

网络层
作用：定义一个逻辑的寻址，选择最佳路径传输，路由数据包；
典型协议：IP，IPX，ICMP,ARP(IP->MAC),IARP;
PDU:packet/数据包；
设备：路由器
备注：实现寻址

============================================

传输层：
作用：提供可靠和尽力而为的传输；
典型协议：TCP,UDP,SPX,port(65535个端口),EIGRP,OSPF,
PDU:fragment 段；
无典型设备；
备注：负责网络传输和会话建立；

=============================================
会话层：
作用：控制会话，建立管理终止应用程序会话；
典型协议：NFS, SQL, ASP, PHP, JSP, RSVP(资源源预留协议), windows，
备注：负责会话建立；

==============================================
表示层：
作用：格式化数据；
典型协议：ASCII, JPEG. PNG, MP3. WAV, AVI,
备注：可以提供加密服务；

应用层：
作用：控制应用程序；
典型协议：telnet, ssh, http, ftp, smtp, rip, BGP, (未完待续)
备注：为应用程序提供网络服务；

TCP/IP

TCP/IP协议是一大堆协议的集合，TCP/IP协议分为四层（也就是数据传输一次主要经历以下4个步骤），分别是从上到下为：应用层，传输层，网络层，数据链路层。
TCP/IP传输协议，即传输控制/网络协议，也叫作网络通讯协议。它是在网络的使用中的最基本的通信协议。TCP/IP传输协议对互联网中各部分进行通信的标准和方法进行了规定。并且，TCP/IP传输协议是保证网络数据信息及时、完整传输的两个重要的协议。TCP/IP传输协议是严格来说是一个四层的体系结构，应用层、传输层、网络层和数据链路层都包含其中。

HTTP状态码

https://www.runoob.com/http/http-status-codes.html

分类	分类描述
1**	信息，服务器收到请求，需要请求者继续执行操作
2**	成功，操作被成功接收并处理
3**	重定向，需要进一步的操作以完成请求
4**	客户端错误，请求包含语法错误或无法完成请求
5**	服务器错误，服务器在处理请求的过程中发生了错误

状态码	状态码英文名称	中文描述我是蓝色
100	Continue 继续	客户端应继续其请求
101	Switching Protocols 切换协议。	服务器根据客户端的请求切换协议。只能切换到更高级的协议，例如，切换到HTTP的新版本协议
100	Continue 继续。	客户端应继续其请求
101	Switching Protocols 切换协议。	服务器根据客户端的请求切换协议。只能切换到更高级的协议，例如，切换到HTTP的新版本协议
200	OK 请求成功。	一般用于GET与POST请求
201	Created 已创建。	成功请求并创建了新的资源
202	Accepted 已接受。	已经接受请求，但未处理完成
203	Non-Authoritative Information 非授权信息。	请求成功。但返回的meta信息不在原始的服务器，而是一个副本
204	No Content 无内容。	服务器成功处理，但未返回内容。在未更新网页的情况下，可确保浏览器继续显示当前文档
205	Reset Content 重置内容。	服务器处理成功，用户终端（例如：浏览器）应重置文档视图。可通过此返回码清除浏览器的表单域
206	Partial Content 部分内容。	服务器成功处理了部分GET请求
300	Multiple Choices 多种选择。	请求的资源可包括多个位置，相应可返回一个资源特征与地址的列表用于用户终端（例如：浏览器）选择
301	Moved Permanently 永久移动。	请求的资源已被永久的移动到新URI，返回信息会包括新的URI，浏览器会自动定向到新URI。今后任何新的请求都应使用新的URI代替
302	Found 临时移动。与301类似。但资源只是临时被移动。	客户端应继续使用原有URI
303	See Other 查看其它地址。与301类似。	使用GET和POST请求查看
304	Not Modified 未修改。	所请求的资源未修改，服务器返回此状态码时，不会返回任何资源。客户端通常会缓存访问过的资源，通过提供一个头信息指出客户端希望只返回在指定日期之后修改的资源
305	Use Proxy 使用代理。	所请求的资源必须通过代理访问
306	Unused	已经被废弃的HTTP状态码
307	Temporary Redirect	临时重定向。与302类似。
400	Bad Request	客户端请求的语法错误，服务器无法理解
401	Unauthorized	请求要求用户的身份认证
402	Payment Required	保留，将来使用
403	Forbidden	服务器理解请求客户端的请求，但是拒绝执行此请求
404	Not Found	服务器无法根据客户端的请求找到资源（网页）。通过此代码，网站设计人员可设置"您所请求的资源无法找到"的个性页面
405	Method Not Allowed	客户端请求中的方法被禁止
406	Not Acceptable	服务器无法根据客户端请求的内容特性完成请求
407	Proxy Authentication Required	请求要求代理的身份认证，与401类似，但请求者应当使用代理进行授权
408	Request Time-out	服务器等待客户端发送的请求时间过长，超时
409	Conflict	服务器完成客户端的 PUT 请求时可能返回此代码，服务器处理请求时发生了冲突
410	Gone	客户端请求的资源已经不存在。410不同于404，如果资源以前有现在被永久删除了可使用410代码，网站设计人员可通过301代码指定资源的新位置
411	Length Required	服务器无法处理客户端发送的不带Content-Length的请求信息
412	Precondition Failed	客户端请求信息的先决条件错误
413	Request Entity Too Large	由于请求的实体过大，服务器无法处理，因此拒绝请求。为防止客户端的连续请求，服务器可能会关闭连接。如果只是服务器暂时无法处理，则会包含一个Retry-After的响应信息
414	Request-URI Too Large	请求的URI过长（URI通常为网址），服务器无法处理
415	Unsupported Media Type	服务器无法处理请求附带的媒体格式
416	Requested range not satisfiable	客户端请求的范围无效
417	Expectation Failed	服务器无法满足Expect的请求头信息
500	Internal Server Error	服务器内部错误，无法完成请求
501	Not Implemented	服务器不支持请求的功能，无法完成请求
502	Bad Gateway	作为网关或者代理工作的服务器尝试执行请求时，从远程服务器接收到了一个无效的响应
503	Service Unavailable	由于超载或系统维护，服务器暂时的无法处理客户端的请求。延时的长度可包含在服务器的Retry-After头信息中
504	Gateway Time-out	充当网关或代理的服务器，未及时从远端服务器获取请求
505	HTTP Version not supported	服务器不支持请求

HTTP请求、响应报文格式

请求报文格式

HTTP请求报文主要由请求行、请求头、（空行）、报文3部分组成

1.请求行

由3部分组成，分别为：请求方法、以及协议版本，之间由空格分隔
请求方法：常用：GET、POST
协议版本的格式为：HTTP/主版本号.次版本号，常用的有HTTP/1.0和HTTP/1.1
例如：GET www.baidu.com HTTP/1.0

2.请求头

请求头部为请求报文添加了一些附加信息，由“名/值”对组成，每行一对，名和值之间使用冒号分隔

请求头	说明
Host	接受请求的服务器地址，可以是IP:端口号，也可以是域名
User-Agent	发送请求的应用程序名称
Connection	指定与连接相关的属性，如Connection:Keep-Alive
Accept-Charset	通知服务端可以发送的编码格式
Accept-Encoding	通知服务端可以发送的数据压缩格式
Accept-Language	通知服务端可以发送的语言

空行

请求头部的最后会有一个空行，表示请求头部结束，接下来为请求正文，这一行非常重要，必不可少

3.报文

请求参数，GET请求一般没有，POST请求一般是JsonString格式

响应报文

HTTP响应报文主要由状态行、响应头部、响应正文3部分组成

1，状态行

由3部分组成，分别为：协议版本，状态码，状态码描述，之间由空格分隔

2.响应头部

与请求头部类似，为响应报文添加了一些附加信息

响应头	说明
Server	服务器应用程序软件的名称和版本
Content-Type	响应正文的类型（是图片还是二进制字符串）
Content-Length	响应正文长度
Content-Charset	响应正文使用的编码
Content-Encoding	响应正文使用的数据压缩格式
Content-Language	响应正文使用的语言

3.响应正文

服务器返回的数据

GET和POST 本质没有区别

应用层面的区别：http规定了浏览器/服务器的限制
GET在浏览器回退时是无害的，而POST会再次提交请求。
GET产生的URL地址可以被Bookmark(标记)，而POST不可以。
GET请求会被浏览器主动cache，而POST不会，除非手动设置。
GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留。
GET请求只能进行url编码，而POST支持多种编码方式。
GET请求在URL中传送的参数是有长度限制的，而POST没有。
对参数的数据类型，GET只接受ASCII字符，而POST没有限制。
GET参数通过URL传递，POST放在Request body中。
GET比POST更不安全，因为参数直接暴露在URL上，所以不能用来传递敏感信息。
重大区别:
GET产生一个TCP数据包；POST产生两个TCP数据包。
对于GET方式的请求，浏览器会把http header和data一并发送出去，服务器响应200（返回数据）；
而对于POST，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok（返回数据）

cookie和session的区别

区别

	链接：https://www.cnblogs.com/l199616j/p/11195667.html
	https://blog.csdn.net/weixin_40521823/article/details/79837162

Cookie和Session：常用的会话跟踪技术，用于确认用户身份。cookie在客户端记录信息，session在服务端记录信息。Session的实现是基于Cookie，Session需要借助于Cookie存储 户的唯一性标识JSESSIONID。
原因：http是无状态的协议，一旦数据交换完毕，客户端和服务端的链接就会断开，再次交换数据时，要重新建立连接，这就意味着服务器无法从连接上跟踪会话
1、cookie数据存放在客户的浏览器上，session数据放在服务器上.
2、cookie不是很安全，别人可以分析存放在本地的COOKIE并进行COOKIE欺骗考虑到安全应当使用session。
3、设置cookie时间可以使cookie过期。但是使用session-destory（），我们将会销毁会话。
4、session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能考虑到减轻服务器性能方面，应当使用cookie。
5、单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie。(Session对象没有对存储的数据量的限制，其中可以保存更为复杂的数据类型)
6、cookie不可跨域名，即百度的cookie文件，google不能访问
7、生命周期
浏览器一旦关闭，session即消失；cookie，预先设置生命周期，或永久保存在本地（记住密码）

预防cookie欺骗

Cookie加密
Cookie+IP加密
Cookie+ip+动态

HttpClient

https://blog.csdn.net/justry_deng/article/details/81042379
https://www.cnblogs.com/luchangyou/p/6375166.html
HTTP 协议可能是现在 Internet 上使用得最多、最重要的协议了，越来越多的 Java 应用程序需要直接通过 HTTP 协议来访问网络资源。虽然在 JDK 的 java net包中已经提供了访问 HTTP 协议的基本功能，但是对于大部分应用程序来说，JDK 库本身提供的功能还不够丰富和灵活。HttpClient 是 Apache Jakarta Common 下的子项目，用来提供高效的、最新的、功能丰富的支持 HTTP 协议的客户端编程工具包，并且它支持 HTTP 协议最新的版本和建议。

HTTP和浏览器有点像，但却不是浏览器。很多人觉得既然HttpClient是一个HTTP客户端编程工具，很多人把他当做浏览器来理解，但是其实HttpClient不是浏览器，它是一个HTTP通信库，因此它只提供一个通用浏览器应用程序所期望的功能子集，最根本的区别是HttpClient中没有用户界面，浏览器需要一个渲染引擎来显示页面，并解释用户输入，例如鼠标点击显示页面上的某处，有一个布局引擎，计算如何显示HTML页面，包括级联样式表和图像。javascript解释器运行嵌入HTML页面或从HTML页面引用的javascript代码。来自用户界面的事件被传递到javascript解释器进行处理。除此之外，还有用于插件的接口，可以处理Applet，嵌入式媒体对象（如pdf文件，Quicktime电影和Flash动画）或ActiveX控件（可以执行任何操作）。HttpClient只能以编程的方式通过其API用于传输和接受HTTP消息。

HttpClient的主要功能：
实现了所有 HTTP 的方法（GET、POST、PUT、HEAD、DELETE、HEAD、OPTIONS 等）
支持 HTTPS 协议
支持代理服务器（Nginx等）等
支持自动（跳转）转向
……

Dubbo分布式服务框架

Dubbo是一款高性能、轻量级的开源Java RPC框架，它提供了三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。
dubbo是一个分布式框架，提供⾼性能和透明化的RPC远程服务调⽤⽅案，以及SOA服务治理方案。说白了其实dubbo就是一个远程调用的分布式框架。
Provider
暴露服务方称之为“服务提供者”。
Consumer
调用远程服务方称之为“服务消费者”。
Registry
服务注册与发现的中心目录服务称之为“服务注册中心”。
Monitor
统计服务的调用次数和调用时间的日志服务称之为“服务监控中心”。

RocketMQ

https://www.cnblogs.com/crazymakercircle/p/14367425.html
RocketMQ是一款分布式消息中间件，最初是由阿里巴巴消息中间件团队研发并大规模应用于生产系统，满足线上海量消息堆积的需求， 在2016年底捐赠给Apache开源基金会成为孵化项目，经过不到一年时间正式成为了Apache顶级项目；早期阿里曾经基于ActiveMQ研发消息系统， 随着业务消息的规模增大，瓶颈逐渐显现，后来也考虑过Kafka，但因为在低延迟和高可靠性方面没有选择，最后才自主研发了RocketMQ， 各方面的性能都比目前已有的消息队列要好，RocketMQ和Kafka在概念和原理上都非常相似，所以也经常被拿来对比；RocketMQ默认采用长轮询的拉模式， 单机支持千万级别的消息堆积，可以非常好的应用在海量消息系统中。
作用：异步、解耦、流量削峰
缺点：系统可用性降低；系统复杂度提高；数据一致性；

RocketMQ的组成：

生产者（Producer）：负责产生消息，生产者向消息服务器发送由业务应用程序系统生成的消息。
消费者（Consumer）：负责消费消息，消费者从消息服务器拉取信息并将其输入用户应用程序。
消息服务器（Broker）：是消息存储中心，主要作用是接收来自 Producer 的消息并存储， Consumer 从这里取得消息。
名称服务器（NameServer）：用来保存 Broker 相关 Topic 等元信息并给 Producer ，提供 Consumer 查找 Broker 信息。

自动化测试框架

JUnit

学习链接：https://www.w3cschool.cn/junit/

可以让您为Java代码编写出相应的单元测试程序。主流集成开发环境（IDE），如Eclipse，NetBeans和IntelliJ都提供了对Junit的集成，这就意味着您可以在这些IDE环境中写入并运行单元测试。可以将JUnit用于单元与集成测试，它还能够支持Java 8的各种功能。

REST Assured

在Java中测试和验证各种REST服务，要比诸如Groovy之类的动态语言难得多。REST Assured则给Java领域带来了语言上的简便性。它是一种十分优秀的REST API集成测试工具。

Selenium

Selenium应该是Java UI测试中最为普遍的工具了，它允许您测试JSP页面，而无需在浏览器中启动这些页面。您可以使用JUnit和Selenium来测试自己的Web应用程序的UI。它甚至允许您去编写Web应用，以验收各种测试。

JBehave

作为测试人员，您一定听说过行为驱动开发(Behavior Driven Development，BDD)。它能够以一种透明的方式，向业务用户描述验收测试。而JBehave正是一种通过Selenium WebDriver来针对BDD开展Java测试的框架。它可以让新手轻松地理解BDD概念，进而基于行为开展应用测试。

Serenity

Serenity同样是一种能被用于行为驱动测试的开源库。该框架可帮助您编写出各种结构良好、且易于维护的验收标准。它在一定程度上扩展了JUnit和WebDriver的功能。

TestNG

TestNG是一种由JUnit和NUnit发展而来的测试框架，不过它引入了许多新的功能，而且更为易用。例如：annotations可以让您在任意大的线程池中，运行各种可用策略的测试(将所有方法都放在自己的线程之中，每个线程对应一个测试类)。通过使用JUnit 4中的annotations，可以弥补JUnit和TestNG之间的差距。另外只要您愿意，还可以去整合Hamcrest的匹配器。

Mockito

在Java的类库中，有着许多诸如PowerMock和JMock的mocking(模拟)框架。我个人比较喜欢Mockito，因为它有着简单的API，完善的文档和大量的示例。Mocking是如今单元测试的一种关键技术，它允许您在没有任何依赖性的情况下，独立地测试自己的代码，这也就是为什么我鼓励每个Java开发人员在学习Junit时一并掌握mocking框架的原因。虽然我力推Mockito，这一mocking框架。当然如果您有兴趣，也可以去试试PowerMock或JMock。

https://www.it1352.com/OnLineTutorial/mockito/mockito_ordered_verification.html

Cucumber

Cucumber是自动化集成测试的另一种常用工具，它与其他同类工具的不同之处是其规范能力。Cucumber将规范和测试文档合并为一个可被Cucumber自动测试的整体，从而保证了您的规范文档一直是最新的。

Spring Test

Spring MVC是一种非常有用的测试框架，它可以在不涉及Web容器的情况下，进行深层次的测试。对于编写针对Spring应用的自动化测试来说，它是一种非常有用的库。如果您想对包括MVC控制器在内的基于Spring的应用，进行单元与集成测试的话，它能够提供一流的支持。还有一种Spring Test DbUnit，它是将具有DbUnit的Spring Test框架和具有HtmlUnit的Spring Test MVC集成在了一起。通过使用上述这些工具，您可以轻松地以自动化的方式去测试各种Spring MVC应用程序。

测试风险评估

软件测试风险评估分析

众所周知，软件测试是把控软件质量的重要防线，但软件测试过程中也会存在潜在的风险。

软件测试的风险是指软件测试过程出现的或潜在的问题。

造成的原因主要是：

测试计划不充分
测试方法有误
测试过程偏离，造成测试的补充以及结果不准确
测试的不成功导致产品交付潜藏着问题，一旦在运行时爆发就会带来巨大的商业风险。

软件测试风险管理主要是对测试计划执行的风险分析与制定要采取的应急措施，防止软件测试产生的风险造成危害。

测试计划的风险一般指测试进度滞后或出现非计划事件，就是针对计划好的测试工作造成消极影响的所有因素。

对于计划风险分析的工作是制定计划风险发生时应采取的应急措施。

在软件测试过程中常见的计划风险主要有7类：

1、测试时间进度风险

用户需求发生重大变更或设计计划的大幅调整压缩了测试时间，测试人员，测试环境，测试资源的不能准时到位也会对测试计划造成影响
2、测试质量目标风险

测试的质量目标不清晰，如易用性测试，用户文档的测试目标存在见仁见智的问题
3、测试范围认知风险

对产品质量需求或产品特性理解不准确，造成测试范围分析误差，出现测试盲区或验证标准错误
4、测试人员风险

测试开始后，测试人员，技术支持人员因故不能及时到位
5、测试充分性风险

部分测试用例设计时忽视了边界条件和深层次的逻辑关系，部分测试用例被测试人员有意无意的忽略执行
6、测试环境风险

测试环境无法与生产环境一致，致使性能测试的结果存在误差
7、测试工具风险

能否及时准备相关测试工具，测试人员对新工具无法熟练运用等

典型测试风险及解决办法如下表：

风险类型	风险表现	控制措施
测试时间进度风险	开发需求增加	增加测试时间，人员，资源 与客户协商，顺延交付日期 将已有的低优先级功能或者特性推迟 降低对低优先级的功能和特性的测试质量
测试人员风险	测试人员突然离开	测试人员加班 推迟软件发布 降低对低优先级的功能和特性的测试质量 删除某些风险级别较低的功能或特性 抽调测试人员
测试环境风险	测试环境不到位或测试环境与生产环境不一致	通过事先列出要检查的所有条目，在测试环境设置好后，按已列出条目逐条检查 增加测试资源，如请求用户团队对测试工作提供更多支持