软件测试的一些专业词汇，及其简单理解

HTTP 传输协议

RPC 远程过程调用； 当然也有本地过程调用；

DNS 域名系统；将域名和IP地址相互映射的一个分布式数据库；

DSF 分布式服务框架；

单体应用（单体架构）的缺点：

　　1.系统耦合性高；

　　2.语言单一；如只能用java，不能用java+python；

　　3.系统不易于拓展部署，比如系统中有一个功能流量很大，顶不住了就要加机器，那么在新机器上还是部署整个应用，不能单独的部署这个大流量的服务，会造成一定的资源浪费；

分布式的缺点：

　　1.多个应用的交互，调用链路变长，带来了网络开销，同时也给定位问题增加了难度；

　　2.为了你的应用更可靠，因某些问题导致的高频调用，对此还的做些限流、熔断之类的措施；

　　3.环境变复杂了，增加了测试的复杂度；

客户端：用户端；

　　客户端包括：WEB客户端、移动客户端。。。

cookie、session、token都是围绕了一个点：身份认证；https://mp.weixin.qq.com/s/_V0cbcbO9w9SS2J2csd-MA

为什么要认证？

　　如购物网站需要登录，输入账号、密码，点击登录成功后，对服务器就产生一次会话session；

　　但是，由于http协议是无状态的，已经登录过的用户没法通过协议层把状态保存下来，所以下次再请求的时候，服务器还是不知道你是谁，有什么办法呢？session

session：当服务器收到登录请求之后，生成一个session id一起返回给客户端，客户端下次再请求的时候把session id一起带上。这时候每个客户端请求对应各自的session id，服务就知道怎么区分了。

cookie：客户端与服务器之间的会话，一般会使用cookie来管理；

　　客户端接收到从服务器端发来的session id后，会将其作为cookie保存在本地；

　　比如，我登录博客园，浏览器F12就可以看到保存在本地的cookie；

 cookie、session使用过程中的问题；

　　1.由于服务器也要保存这 session 信息用户跟客户端传过来的进行比对，数量小了还好，太多用户登录，服务器要保存的内容就越多，会吃不消；

　　2.对于集群的服务器，A、B服务器要同步session 信息；

　　3.对于非浏览器的客户端、手机移动端等不适用，因为session依赖于cookie，而移动端经常没有cookie；

　　4.cookie无法跨域，所以session的认证也无法跨域，对单点登录不适用；

 token

　　其实token核心在于身份认证，想个办法既能解决认证，又不用服务器保存不就好了；

1. 客户端使用用户名和密码请求登录
2. 服务端收到请求，验证用户名和密码
3. 验证成功后，服务端会签发一个 token 令牌，再把这个token返回给客户端
4. 客户端收到 token 后可以把它存储起来，比如放到cookie中
5. 客户端每次向服务端请求资源时需要携带服务端签发的 token，可以在 cookie 或者 header 中携带
6. 服务端收到请求，然后去验证客户端请求里面带着的 token，如果验证成功，就向客户端返回请求数据

重点就是在于服务端可以不用保存 token。

比如，当第一次收到客户端传过来的用户名和密码时，服务器认证通过后，通过加密算法生成一个字符串当做 token。当拿到后续请求中的 token，服务器再解析这个token，可以从中获取关键的信息，从而判断该token的有效性。

目前接触到的大多数系统，都是基于token验证来的，因为它的优点更适合当下的系统应用环境：

• 无状态，可以更方便扩展
• 更安全，可以防止跨站请求伪造 CSRF
• 方便多平台跨域
• 可以标准化，比如基于JWT Json web token (JWT)

单点登录（Single sign on），简称SSO，SSO的定义是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统；

 

左移、右移；

左移，提测前的测试，如需求评审等；

右移，发布到生产环境后的验证；

 

质量内建

1.质量没法通过测试在短时间内进行一个本质的提高，

  软件开发出来质量已经在哪儿了。如果已加公司有一定的时间成本去从根本上提高质量，并不是说让测试不停的测而是选择重构；

 

TPS、并发数、线程数

TPS:单位时间（每秒）处理的事务数；

并发数：同一时刻系统同时处理的请求数（相对并发，绝对并发）；

线程数：一般情况下，指的是虚拟用户数；

　　登录接口能够承受秒级1000并发，TPS 1000；

　　TPS=Vu（总请求数）/Time

　　描述系统的性能能力时，只说TPS是不够的，还需要考虑响应时间和系统资源使用率；如TPS都是1000，A系统的响应时间0.5S，B系统的响应时间2S；对于A系统，应该继续往上压，找出更好的TPS；对于B系统，差不多要进行调优了；

　　一般情况下，单接口的TPS，也可以是QPS（每秒查询事务数）。但是在实际的工作场景中，某一个T（Transactions）都会有若干个接口共同完成。很多性能测试工具（如jmeter），都提供了自定义（Transactions）的功能；因为这个（Transactions）才是描述客户行为的真实场景；不同的定义方法，TPS会有较大差异。不能为了追求数值上的好看，而忽略了真实场景；

　　通过TPS结合响应时间，才能更好地反馈系统的性能问题；