软件测试

1.按阶段划分为
单元测试,集成测试 ,系统测试,验收测试

2.按是否运行
	静态测试 动态测试	
    
3.按是否查看源代码
	自盒测试
	黑盒测试
		功能测试 
    		逻辑功能测试 ,界面测试,易用性测试,安装测试,兼容性测试
		性能测试
        	一般性能测试 ,稳定性测试,负载测试,压力测试
4.其他
	回归测试,冒烟测试,随机测试	

测试过程中遇到了不能复现的bug怎么办

1、遇到问题就要提，测试的工作就是不放过任何一个bug，在提交的Bug描述中需要加上一句话，那就是复现概率，尝试20次，出现1次或者尝试10次，出现2次，开发会根据bug的复现概率，调整改bug的优先级。

2、尽量回想发生问题时的复现步骤，不要漏掉任何一个细节，按照步骤的组合尝试复现。

3、保留发生bug时的log，附加到提交的bug中，希望可以通过log中找到一些蛛丝马迹。

4、与开发人员配合，让开发同学对相应地方的代码进行检查，看一下是否可以通过代码层面检查出问题。

5、在接下来的测试中，时刻保持关注，每次执行同样或者相近的步骤的时候，看下是否能够复现之前的bug。

测试过程中遇到开发不认为bug是bug的时候你怎么办

找到需求文档或者是原型图进行匹配
尝试多种测试环境和多种测试方法来确认是否为bug
整理bug的复现的步骤和出现的频率
开发坚持不认为是bug的时候找项目经理测试经理进行沟通来确认是否为bug
将客户经理 测试 测试经理和项目经理进行确认会来判定是否为bug

性能测试的指标 有哪些

1、性能指标分类
系统性能指标
资源性能指标
中间件指标
数据库指标
稳定性指标
可扩展性指标
可靠性指标

2、系统性能指标
响应时间
系统处理能力
吞吐量
并发用户数
错误率

2.1 响应时间
Response Time 简称RT，是指系统对请求作出响应的时间（处理请求的时间）；
不同的功能的响应时间也不尽相同，所以讨论一个系统的响应时间时，通常指该系统所有功能的平均响应时间或者所有功能的最大响应时间

不同行业参考标准：
互联网：500毫秒以下，如淘宝业务10毫秒左右
金融：1秒以下为佳，复杂业务3秒以下
保险：3秒以下为佳
制造业：5秒以下为佳

响应时间的绝对值并不能直接反映软件的性能的高低，软件性能的高低实际上取决于用户对该响应时间的接受程度

2.2 系统处理能力
系统处理能力是指系统在利用系统硬件平台和软件平台进行信息处理的能力。有以下指标来度量：
HPS（Hits Per Second）：每秒点击次数，次/秒
TPS（Transaction per second）：系统每秒处理交易数（事务数），笔/秒
QPS（Query per second）：系统每秒处理查询次数，次/秒

一般情况下用TPS来衡量整个业务流程，用QPS来衡量接口查询次数，用HPS来表示对服务器点击请求(越大越好)

不同行业参考标准：
金融：1000TPS—50000TPS
保险：100TPS----100000TPS
制造：10TPS-----5000TPS
互联网电子商务：10000TPS----1000000TPS
互联网中型网站：1000TPS—50000TPS
互联网小型网站：500TPS–10000TPS

2.3 吞吐量
吞吐量是指系统在单位时间内处理请求的数量
对于单用户系统，响应时间可以很好地度量系统的性能，但对于并发（多用户）系统，通常可以用吞吐量作为性能指标

2.4 并发用户数
并发用户数指在同一时刻内，登录系统并进行业务操作的用户数量

2.5 错误率
错误率 简称FR，指系统在负载情况下，失败交易的概率，错误率=（失败交易数/交易总数）*100%
参考标准：一般成功率不低于99.4%

3.资源性能指标
CPU
内存
磁盘吞吐量
网络吞吐量

3.1 CPU
CPU又称中央处理器，是一块超大规模的集成电路，是一台计算机的运算核心（core）和控制中心（Control Unit）。主要功能时解释计算机指令以及处理计算机软件中的数据。
行业参考标准：
CPU指标主要指的是CPU利用率，包括用户态（user），系统态（sys）,等待态（wait），空闲态（idle）
CPU利用率 <=75%
CPU sys% <=30%
CPU wait% <=5%

3.2 内存
内存是与CPU进行沟通的桥梁，计算机所有程序的运行都是在内存中进行的，内存的性能对系统影响非常大。
行业参考标准：
为了最大利用内存，在内存中存放了缓存，因此内存利用率100%并不代表内存有瓶颈，衡量系统内存是否有瓶颈主要靠SWAP（与虚拟内存交换）交换空间利用率，一般低于70%，太多的交换将引起系统性能低下。

3.3 磁盘吞吐量
磁盘吞吐量简称Disk Throughput，是指在无磁盘故障的情况下单位时间内通过磁盘的数据量
行业参考标准：
磁盘指标有每秒读写多少兆，磁盘繁忙率，磁盘队列数，平均服务时间，平均等待时间，空间利用率。其中磁盘繁忙率是直接反映磁盘是否有瓶颈的重要依据，磁盘繁忙率要低于70%

3.4 网络吞吐量
Network Throughput，是指在无网络故障的情况下单位时间内通过的网络的数据数量。单位：Byte/s. 网络吞吐量指标用于衡量系统对于网络设备或链路传输能力的需求。当网络吞吐量指标接近网络设备或链路最大传输能力时，则需要考虑升级网络设备。一般不超过设备或链路的最大传输能力的70%

4. 中间件指标
常用的中间件例如Tomcat，weblogic等指标主要包括JVM，ThreadPool，JDBC
|GC频率 | 次/s | java虚拟机垃圾部分回收频率
|Full GC频率| 次/h | Java虚拟机垃圾完全回收频率
| Full GC平均时长 | 秒 | 用于垃圾完全回收的平均时长
| Full GC最大时长 | 秒 | 用于垃圾完全回收的最大时长
|GC堆使用率 | 百分比 | 堆使用率
|Active Thread Count| 个 | 活动的线程数
| Pending User Request |个 | 处于排队的用户请求个数
|JDBC Active Connection| 个| JDBC活动连接数

5.数据库指标
常用的数据库如MySQL指标主要包括SQL、吞吐量、缓存命中率、连接数
SQL 耗时 微妙 执行SQL耗时
吞吐量 QPS 个 每秒查询次数
吞吐量 TPS 个 每秒事务次数
命中率 Key Buffer命中率 百分比 索引缓冲区命中率
命中率 InnoDB Buffer命中率 百分比 InnoDB缓冲命中率
命中率 QueryCache命中率 百分比 查询缓存命中率
命中率 TableCache命中率 百分比 表缓存命中率
命中率 ThreadCache命中率 百分比 线程缓存命中率
锁 等待次数 次 锁等待次数
锁 等待时间 微妙 锁等待时间

行业参考标准：
SQL耗时越小越好，一般微秒级别
命中率越高越好，一般不能低于95%
锁等待次数越低越好，锁等待时间越短越好

6.稳定性指标
最短稳定时间：系统按照最大容量的80%或标准压力情况下运行，能够稳定运行的最短时间。
一般来说 对于正常工作日（8小时）运行的系统，至少应该能保证系统稳定运行8小时以上。
对于7*24小时运行的系统，至少保证稳定运行24小时以上
参考标准：
TPS曲线稳定，没有大幅度的波动
各项资源指标没有泄露或异常情况

7.可扩展性指标
是指应用软件或操作系统以群集方式部署，增加的硬件资源与增加的处理能力之间的关系。
计算公式：
（增加性能/原始性能）/(增加资源/ 原始资源) *100%
参考标准：
理想的扩展能力是资源增加几倍，性能就提升几倍。扩展能力至少在70%以上。

8.可靠性指标
对于服务端性能测试，从系统可靠性指标度量分析时，常见从三类来入手：
双机热备
集群
备份和恢复
8.1 双机热备
指标如下：
节点切换是否成功及其消耗时间。
双机切换是否有业务中断。
节点回切是否成功及其耗时。
双机回切是否有业务中断。
节点回切过程中的数据丢失量在进行双机切换的同时，使用压力发生工具模拟实际业务发生情况，对应用保持一定的性能压力，保证测试结果符合生产实际情况。

8.2 集群
对于使用集群方式的系统，主要通过以下方式考量其集群可靠性：

集群中某个节点出现故障时，系统是否有业务中断情况出现
在集群中新增一个节点时，是否需要重启系统
当故障节点恢复后，加入集群，是否需要重启系统
当故障节点恢复后，加入集群，系统是否有业务中断情况出现
节点切换需要多长时间在验证集群可靠性的同时，需根据具体情况使用压力工具模拟实际业务发生相关情况，对应用保持一定的性能压力，确保测试结果符合生产实际情况。

8.3 备份和恢复
本指标为了验证系统的备份/恢复机制是否有效可靠，包括系统的备份和恢复、数据库的备份和恢复、应用的备份和恢复，包括以下测试内容：

备份是否成功及其消耗时间。
备份是否使用脚本自动化完成。
恢复是否成功及其消耗时间。
恢复是否使用脚本自动化完成指标体系的运用原则。
指标项的采用和考察取决于对相应系统的测试目的和测试需求。被测系统不一样，测试目的不一样，测试需求也不一样，考察的指标项也有很大差别。
部分系统涉及额外的前端用户接入能力的，需要考察用户接入并发能力指标。
对于批量处理过程的性能验证，主要考虑批量处理效率并估算批量处理时间窗口。
如测试目标涉及到系统性能容量，测试需求中应根据相关指标项的定义，明确描述性能指标需求。
测试指标获取后，需说明相关的前提条件（如在多少的业务量、系统资源情况等

token cookie session 之间的区别

Cookie
cookie 是一个非常具体的东西，指的就是浏览器里面能永久存储的一种数据，仅仅是浏览器实现的一种数据存储功能。

cookie由服务器生成，发送给浏览器，浏览器把cookie以kv形式保存到某个目录下的文本文件内，下一次请求同一网站时会把该cookie发送给服务器。由于cookie是存在客户端上的，所以浏览器加入了一些限制确保cookie不会被恶意使用，同时不会占据太多磁盘空间，所以每个域的cookie数量是有限的。

Session
session 从字面上讲，就是会话。这个就类似于你和一个人交谈，你怎么知道当前和你交谈的是张三而不是李四呢？对方肯定有某种特征（长相等）表明他就是张三。

session 也是类似的道理，服务器要知道当前发请求给自己的是谁。为了做这种区分，服务器就要给每个客户端分配不同的“身份标识”，然后客户端每次向服务器发请求的时候，都带上这个“身份标识”，服务器就知道这个请求来自于谁了。至于客户端怎么保存这个“身份标识”，可以有很多种方式，对于浏览器客户端，大家都默认采用 cookie 的方式。

服务器使用session把用户的信息临时保存在了服务器上，用户离开网站后session会被销毁。这种用户信息存储方式相对cookie来说更安全，可是session有一个缺陷：如果web服务器做了负载均衡，那么下一个操作请求到了另一台服务器的时候session会丢失。

Token
在Web领域基于Token的身份验证随处可见。在大多数使用Web API的互联网公司中，tokens 是多用户下处理认证的最佳方式。

以下几点特性会让你在程序中使用基于Token的身份验证

无状态、可扩展

支持移动设备

跨程序调用

安全

那些使用基于Token的身份验证的大佬们

大部分你见到过的API和Web应用都使用tokens。例如Facebook, Twitter, Google+, GitHub等。

Token的起源
在介绍基于Token的身份验证的原理与优势之前，不妨先看看之前的认证都是怎么做的。

基于服务器的验证

我们都是知道HTTP协议是无状态的，这种无状态意味着程序需要验证每一次请求，从而辨别客户端的身份。

在这之前，程序都是通过在服务端存储的登录信息来辨别请求的。这种方式一般都是通过存储Session来完成。

下图展示了基于服务器验证的原理

随着Web，应用程序，已经移动端的兴起，这种验证的方式逐渐暴露出了问题。尤其是在可扩展性方面。

基于服务器验证方式暴露的一些问题

Seesion：每次认证用户发起请求时，服务器需要去创建一个记录来存储信息。当越来越多的用户发请求时，内存的开销也会不断增加。

可扩展性：在服务端的内存中使用Seesion存储登录信息，伴随而来的是可扩展性问题。

CORS(跨域资源共享)：当我们需要让数据跨多台移动设备上使用时，跨域资源的共享会是一个让人头疼的问题。在使用Ajax抓取另一个域的资源，就可以会出现禁止请求的情况。

CSRF(跨站请求伪造)：用户在访问银行网站时，他们很容易受到跨站请求伪造的攻击，并且能够被利用其访问其他的网站。

在这些问题中，可扩展行是最突出的。因此我们有必要去寻求一种更有行之有效的方法。

基于Token的验证原理
基于Token的身份验证是无状态的，我们不将用户信息存在服务器或Session中。

这种概念解决了在服务端存储信息时的许多问题

NoSession意味着你的程序可以根据需要去增减机器，而不用去担心用户是否登录。

基于Token的身份验证的过程如下:

用户通过用户名和密码发送请求。

程序验证。

程序返回一个签名的token 给客户端。

客户端储存token,并且每次用于每次发送请求。

服务端验证token并返回数据。

每一次请求都需要token。token应该在HTTP的头部发送从而保证了Http请求无状态。我们同样通过设置服务器属性Access-Control-Allow-Origin:* ，让服务器能接受到来自所有域的请求。需要主要的是，在ACAO头部标明(designating)*时，不得带有像HTTP认证，客户端SSL证书和cookies的证书。

实现思路：
在这里插入图片描述

用户登录校验，校验成功后就返回Token给客户端。

客户端收到数据后保存在客户端

客户端每次访问API是携带Token到服务器端。

服务器端采用filter过滤器校验。校验成功则返回请求数据，校验失败则返回错误码

当我们在程序中认证了信息并取得token之后，我们便能通过这个Token做许多的事情。

我们甚至能基于创建一个基于权限的token传给第三方应用程序，这些第三方程序能够获取到我们的数据（当然只有在我们允许的特定的token）

Tokens的优势
无状态、可扩展
在客户端存储的Tokens是无状态的，并且能够被扩展。基于这种无状态和不存储Session信息，负载负载均衡器能够将用户信息从一个服务传到其他服务器上。

如果我们将已验证的用户的信息保存在Session中，则每次请求都需要用户向已验证的服务器发送验证信息(称为Session亲和性)。用户量大时，可能会造成

一些拥堵。

但是不要着急。使用tokens之后这些问题都迎刃而解，因为tokens自己hold住了用户的验证信息。

安全性
请求中发送token而不再是发送cookie能够防止CSRF(跨站请求伪造)。即使在客户端使用cookie存储token，cookie也仅仅是一个存储机制而不是用于认证。不将信息存储在Session中，让我们少了对session操作。

token是有时效的，一段时间之后用户需要重新验证。我们也不一定需要等到token自动失效，token有撤回的操作，通过token revocataion可以使一个特定的token或是一组有相同认证的token无效。

可扩展性（）
Tokens能够创建与其它程序共享权限的程序。例如，能将一个随便的社交帐号和自己的大号(Fackbook或是Twitter)联系起来。当通过服务登录Twitter(我们将这个过程Buffer)时，我们可以将这些Buffer附到Twitter的数据流上(we are allowing Buffer to post to our Twitter stream)。

使用tokens时，可以提供可选的权限给第三方应用程序。当用户想让另一个应用程序访问它们的数据，我们可以通过建立自己的API，得出特殊权限的tokens。

多平台跨域
我们提前先来谈论一下CORS(跨域资源共享)，对应用程序和服务进行扩展的时候，需要介入各种各种的设备和应用程序。

Having our API just serve data, we can also make the design choice to serve assets from a CDN. This eliminates the issues that CORS brings up after we set a quick header configuration for our application.

只要用户有一个通过了验证的token，数据和资源就能够在任何域上被请求到。

Access-Control-Allow-Origin: *   
1
基于标准
创建token的时候，你可以设定一些选项。我们在后续的文章中会进行更加详尽的描述，但是标准的用法会在JSON Web Tokens体现。

最近的程序和文档是供给JSON Web Tokens的。它支持众多的语言。这意味在未来的使用中你可以真正的转换你的认证机制。

经典用例设计

纸杯

.需求 2.相关背景 3.影响范围
一 需求:测试一个带广告图案的花纸杯
二 相关背景: 
    1.杯子特性: (1)杯子的容量: 能装多少升水,空杯，半杯，满杯
                (2)杯子的型状: 圆型，上面口大，下面小。
                (3)杯子的材料: 纸杯
                (4)杯子的抗摔能力: 风吹是否会倒，摔一次是否会摔坏,摔多次是否会摔坏
                (5)杯子的耐温性: 装冷水，冰水，热水
    2.广告图案: (1)广告内容与图案碰水是否会掉色
                (2)广告内容与图案是否合法
                (3)广告内容与图案是否容易剥落
三 影响范围:
    1.可用性: (1)装入液体多久后会漏水
              (2)装入热水多久后可以变温，装入冰水多久后可以融化
    2.安全性: (1)装入不同液体，是否会有化学反应。比如：可乐，咖啡等饮料
              (2)装入热水杯子是不是会变型和异味
    3.性能:   (1)不同人群是否能适合杯子的型状，包括握杯的感觉和喝水的感觉
              (2)不同人群是否能接受杯子的广告内容与图案
   以上是我从设计用例思想方面考虑到的用例。真正接口测试用例的设计还要通过阅读代码，挖掘更深层次的相关背景来补充测试用例。功能测试人员会从哪几个方面设计呢。请多指教！
   总之，一个好的测试用例具有较高的发现某个尚未发现的错误的可能性，一个成功的测试用例能够发现某个尚未发现的错误。在测试用例的设计上，要不断的学习，提高自已设计用例的水平，提高软件的质量。

购物车

1、界面测试：
（1）打开页面后，页面的布局是否合理，现实是否完整。
（2）不同卖家的商品在不同的table区域显示，区分明显。
（3）页面的功能按钮可以正常显示。
（4）商品最下面显示失效宝贝。
（5）最低端显示“你可能喜欢”。
（6）向下滑动页面，在购物车顶端展示这个中间展示“购物车”。
（7）购物车有商品降价或者库存不足或者限购件数，在商品详情下面，会有对应字体展示。
2、基本功能
（1）购物车页面所有链接正常。
（2）从商品信息页面添加的商品能显示在购物车中。
（3）若未登录，点击购物车中的商品直接进行结算，则提示用户输入用户名和密码，或者提示其他的非注册用户购物方式。
（4）若没有选择任何商品，点击结算，则提示用户“请添加要结算的商品”
（5）勾选商品后，已选商品的总价（和优惠满减活动）会显示。
（6）勾选商品，点击结算按钮后，进入确认订单信息页面。
（7）购物车页面中，可以对添加的商品信息做信息的修改，并自动保存成功。
（8）可以在购物车中重新修改商品规格。
（9）购物车能添加的商品种类是有数量上限的。
（10）结算的时候商品可以全选，选择底部的全选按钮。
（11）可以在购物车页面对宝贝进行管理。
3、性能测试：
（1）打开购物车时间是否在已定的用户可以棘手的时间范围内。
（2）编辑购物车：删除、增加商品需要的时间。
（3）在购物车页面选择需要购买的商品进行结算的时候，结算金额可不可以实时显示。
（4）清空失效商品需要的时间。
（5）商品批量
4、兼容性测试：
（1）ios：不同型号，不同的ios系统。
（2）安卓：不同品牌，不同型号，不同的安卓系统。
5、网络环境：
（1）3G、4G、wifi网络环境下应用的各功能可正常运行。
（2）网络异常时，数据交换是否会有提醒。
（3）有网到无网再到有网，数据是否可以自动恢复，正常加载。
（4）只允许内网访问的APP，在连接到外网时是否会有提醒。
6、异常测试：
（1）没有内存时，APP是否能够正常响应。
（2）横竖屏切换展示。
（3）APP运行时网络中断。
（4）反复操作某一个功能，不断点击和刷新，是否出现闪退。
（5）APP运行时接入电话、短信、微信时，是否正常运行。

电梯

界面测试：查看电梯外观，按键数字清晰、开和关按钮设计的图标是否容易区分

功能测试：

1、电梯门的打开、关闭是否正常

2、按钮是否可以正常使用

3、能否实现正常的上升和下降功能，是否停到相应楼层

4、电梯内是否有灯，灯光是否柔和，电梯运行中灯是否稳定

5、报警装置是否可用

6、通风状况如何，是否有手机信号

7、突然停电的状况

8、上下升途中的响应

      1）先只按17楼上升，那么电梯在上升到5楼的时候，有人按了10楼，这时候是否会在10楼先停下来，下降类似模拟

      2）电梯下降到10层时显示满员，此时若8层有人等待电梯，是否在8层停

可靠性：

1、关门时出现障碍物

2、同时按关门和开门按钮

3、同时按上下键、开关门按钮

4、多次选择同一楼层

压力测试：

1、看电梯的最大承重量，在负载过重时报警装置是否有提醒
2、在一定时间内不断让电梯上升、下降

 

稳定性：

1、升降过程中晃动是否明显

2、有人在电梯里运动，晃动感如何

3、看电梯在最大负载下平稳运行的最长时间

易用性：

1、按钮的设计符合一般人的习惯（高度、文字）

2、高级电梯内层是否有设计小孩和残疾人可以触摸到的按钮

登录框

　　功能测试(Function test)
　　0. 什么都不输入，点击提交按钮，看提示信息。（非空检查）
　　1.输入正确的用户名和密码，点击提交按钮，验证是否能正确登录。（正常输入）
　　2.输入错误的用户名或者密码， 验证登录会失败，并且提示相应的错误信息。（错误校验）
　　3.登录成功后能否能否跳转到正确的页面（低）
　　4.用户名和密码，如果太短或者太长，应该怎么处理（安全性，密码太短时是否有提示）
　　5.用户名和密码，中有特殊字符（比如空格），和其他非英文的情况（是否做了过滤）
　　6.记住用户名的功能
　　7.登陆失败后，不能记录密码的功能
　　8.用户名和密码前后有空格的处理
　　9.密码是否加密显示（星号圆点等）
　　10.牵扯到验证码的，还要考虑文字是否扭曲过度导致辨认难度大，考虑颜色（色盲使用者），刷新或换一个按钮是否好用
　　11.登录页面中的注册、忘记密码，登出用另一帐号登陆等链接是否正确
　　12.输入密码的时候，大写键盘开启的时候要有提示信息。
　　界面测试(UI Test)
　　1.布局是否合理，2个testbox 和一个按钮是否对齐
　　2.testbox和按钮的长度，高度是否复合要求
　　3. 界面的设计风格是否与UI的设计风格统一
　　4. 界面中的文字简洁易懂，没有错别字。
　　性能测试(performance test)
　　1.打开登录页面，需要几秒
　　2.输入正确的用户名和密码后，登录成功跳转到新页面，不超过5秒
　　安全性测试(Security test)
　　1.登录成功后生成的Cookie，是否是httponly (否则容易被脚本盗取)
　　2.用户名和密码是否通过加密的方式，发送给Web服务器
　　3.用户名和密码的验证，应该是用服务器端验证， 而不能单单是在客户端用javascript验证
　　4.用户名和密码的输入框，应该屏蔽SQL注入攻击
　　5.用户名和密码的的输入框，应该禁止输入脚本 （防止XSS攻击）
　　6.错误登陆的次数限制（防止暴力破解）
　　7. 考虑是否支持多用户在同一机器上登录；
　　8. 考虑一用户在多台机器上登录
　　可用性测试(Usability Test)
　　1. 是否可以全用键盘操作，是否有快捷键
　　2. 输入用户名，密码后按回车，是否可以登陆
　　3. 输入框能否可以以Tab键切换
　　兼容性测试（Compatibility Test）
　　1.主流的浏览器下能否显示正常已经功能正常（IE，6，7，8，9， Firefox， Chrome， Safari，等）
　　2.不同的平台是否能正常工作，比如Windows， Mac
　　3.移动设备上是否正常工作，比如Iphone， Andriod
　　4.不同的分辨率
　　本地化测试 （Localization test）
　　1. 不同语言环境下，页面的显示是否正确。
　　软件辅助性测试 （Accessibility test）
　　软件辅助功能测试是指测试软件是否向残疾用户提供足够的辅助功能
　　1. 高对比度下能否显示正常 （视力不好的人使用）

多部电梯联动测试

界面测试：
外观（里面、外面）美观性
电梯空间尺寸是否和设计尺寸一致
按钮是否清晰和易懂
显示楼层的显示屏是否安装
是否联系外界的电话、紧急电话
设备检测说明书
安全规范说明书
灯
标识的承重和人数
扶手
镜子
仅提供可到达楼层的按钮
电梯制作的材料

功能测试：
测试电梯能否实现正常的上升和下降功能，每层是否都可以停靠。
每层停靠楼层是否与所按的楼层一致
电梯按键在按下时是否点亮按键灯
电梯在每个楼层的上行和下行的申请是否可以有效
电梯满负载的时候，是否会忽略其他楼层外部的上行和下行申请
电梯的两边按钮是否都可以使用，三列按钮。
电梯的楼层选择是否可以取消
电梯门的打开，关闭是否正常关闭（自动关闭）。
报警装置是否可用。（满载）
超重时是否能强制关门
超重时重新挪动一下人员是否可以上下行
与另外一部电梯之间是否协作良好。（算法）
电梯的灯光是否满足看书的要求
联系外界的电话是否可用
通风状况如何，人多的时候是否会很热，通风不畅（排气扇）
电梯里面的摄像头是否可用，拍摄是否清晰
门不夹人
伸手的话，应该不会强制关门
管理员可以和内部人通话
在各种场合下，可以强制开门
运行中时，不能按开门键，不会强制开门
在不同情况下（如：有人挡着、马上关门的时候、停电的时候、没有请求的时候…），一直按开门键和关门键
从电梯外部可以强制开门
不同温度下的测试
进入电梯，拨打手机，是否有信号
进入电梯喊话，外面是否能听到
楼层显示屏显示的楼层、以及电梯运行升降状态是否正确
两台电梯能否同时使用（或停用）
其中一台使用，另一台是否可以停用
A电梯按上行，B电梯按上行
A电梯按上行，B电梯按下行
A电梯按上行，B电梯按上下行
A电梯按上行，B电梯按下上行
A电梯按下行，B电梯按下行
A电梯按下行，B电梯按上下行
A电梯按下行，B电梯按下上行
A电梯按上下行，B电梯按上下行
A电梯按上下行，B电梯按下上行
电梯空时如何运转
电梯门开时不进电梯
进入电梯后不做任何操作
电梯门开的时间多长，超过时间后是否自动关门
电梯门开的时间超时后关门到最后2厘米，是否可以撬开门
电梯门关闭后还未上升时，电梯外按下上行（或下行）按钮，电梯门是否会打开
电梯最底层是否有下行按钮
电梯最顶层是否有上行按钮

停靠算法测试：
2部均空闲时，采取就近原则，离乘电梯人最近的电梯优先运行；
有1部运行时，以同行方向且顺路的电梯优先运行，否则安排空闲电梯；
2部均运行时，以方向通行且顺路的电梯优先运行；
每部电梯，在电梯内部每层在上升和下降过程中，再电梯内部均申请每层停靠
每部电梯，在电梯内部每层在上升和下降过程中，再内部没有任何申请的情况下，在电梯外部均申请每层停靠
每部电梯，在电梯内部每层在上升和下降过程中，再电梯内部均申请每层停靠，在电梯外部也申请每层停靠
电梯本来在1楼，如果有人按18楼，那么电梯在上升到5楼的时候，有人按了10楼，这时候是否会在10楼先停下来
电梯下降到10层时显示满员，此时若8层有人等待电梯，是否在8层停。
类似7、8测试步骤地随机测试，在电梯内部和外部均有不同组合申请的情况下，验证楼层停靠是否准确和合理。
电梯的平稳性，是否会上升过快或者下降过快，造成人体不适应反应

可靠性：
无任何申请的时候，可以长时间停留在某层，并且门是关闭的
门关上的一刹那出现障碍物。
长期有障碍物在门口堵住，电梯应该也不会关门或上升和下降
同时按关门和开门按钮。
快速交替按关门开门按钮
点击当前楼层号码。
快速点击不同楼层
上升到顶层后，电梯中的原有下楼请求均会被取消
下降到负楼层后，电梯中的原有上楼请求均会被取消
电梯外部同时按上键和下键会怎样。
长按打开按钮，电梯门是否持续打开
突然停电或超载时的情况，电梯（停靠、正在上升、正在下降）不会坠落，电梯门可以通过外力打开，并且紧急电话可用
电梯运行中，申请马上要经过的楼层停靠，电梯应该不会停靠。
在电梯里面蹦跳，电梯不会出现不稳定的情况。
电压不稳定的情况下的电梯运行情况
电梯不能正常工作的时候是否有监控系统自动报警
电梯不能正常工作的时候，是否有流程可以精确的指定到人进行所有故障解决的高效处理

易用性：
电梯的按钮的设计符合一般人使用的习惯吗．
按钮是否考虑残疾人和小孩儿
楼层显示屏是否处于电梯的上部，方便别人看到
可维护性
是否有方便维修和维护电梯的工作条件（竖井通道、统一断电等）
电梯的常用配件是否容易更换
电梯的维修成本如何
电梯的安装、维护、测试
超过维修年限，是否可以正常运转

视频播放器测试用例

UI测试：
导航栏元素位置、大小、颜色等要素是否一致/是否符合UI效果图；
导航栏视频分类下拉框位置、颜色、按钮是否正确
鼠标滑过、点击时、点击后按钮状态是否有相应颜色、状态变化；
视频列表页面title、视频图片、视频title、是否付费等元素的颜色、大小、位置等是否正确；
视频播放页面：视频title、视频默认加载图、播放按钮、目录、视频列表、视频介绍等元素位置、大小、颜色、鼠标操作时状态是否与预期一致；
视频播放时进度条、快进按钮、快退按钮、播放按钮、暂停按钮位置是否正确
功能测试：

首先判断用户是否登录，未登录不能进入主页（应提示用户先进行登录），已登录状态用户可以进行视频观看；
导航栏下拉框是否可以正确打开和关闭，打开和关闭时的状态是否和预期一致；
鼠标滑过、点击时、点击后相应条目的状态是否和预期一致；
点击相应条目时，页面右边是否同步切换至相应页面，是否有延时、卡退、切换错误等情况；
视频播放页面鼠标滑过、点击时、点击后视频对应条目、标题是否有相应状态变化（具体变化状态根据产品原型进行分析），点击后是否能够正确跳转至相应的视频播放界面；
判断用户点击的视频属于免费还是付费，如果为免费则所有人均可以进行观看，如果为付费则要判断用户是否付费，如果已经付费则可以进行观看，如未支付则提示用户先购买后再进行观看并提供支付入口或者联系客服进行支付的方式；
进入视频播放界面判断当前视频title是否和用户上一步点击的视频title一致；
视频默认加载图是否显示正确或者显示异常等情况；
视频播放按钮是否可以点击，点击后视频是否正常播放；
视频目录是否显示正确，如有子列表是否正常显示，如果没有子列表是否有相应提示（具体效果根据产品原型进行分析）；
视频介绍是否与当前视频一致，讲师是否一致等情况；
点击播放后进度条是否随之变化；
视频快进、快退、暂停、播放是否可以正常使用，是否有卡顿、延时、闪退等情况；
播放完成后是否自动切换下一视频（如有多节视频情况下，如果只有一条子视频的情况下，播放完成后是否关闭当前页面或者给予用户相应提示），如果需要手动切换是否有相应的友好提示；
视频播放时声音、画面是否一致或者是否有异常等情况；
视频最大化、全屏、最小化是否可以正常使用，切换时是否有卡顿、延时等情况；
当前视频与其他视频来回切换时，视频是否有卡顿、延时等情况；
电脑关机或者其他异常情况下，视频是否会保存播放记录，下次进入观看时是否继续上次的播放记录继续播放；
兼容性测试：

平台兼容性：Windows、Mac
系统兼容西：Win7、Win10、Mac
屏幕分辨率：不同电脑显示器分辨率不同，视频相关页面是否有模糊、适配是否合理；
播放器是否与其他类型播放器冲突（例如音乐播放器打开后，视频是否暂停还是继续播放）；
网络测试：

网络切换测试：无线网与宽带；
弱网测试：弱网情况下视频是否卡顿、画面是否失帧；
无网络状态进入是否会有相应提示；
网络切换时视频是否暂停、保存当前播放状态；
易用性测试：

界面是否一目了然（比如：视频title、片头、片尾、视频画面等）；
视频页面操作是否方便，菜单栏是否正确、易上手；
进度条拖拽使用起来是否方便；
视频是否具有视频记忆功能/是否保存当前播放进度

三角形测试用例

        在三角形计算中，要求三角形的三个边长：A B C 。           

          1、 当三边不可能构成三角形时提示错误，可构成三角形时计算三角形周长。

          2、若是等腰三角形打印“等腰三角形”， 若两个等腰的平方和等于第三边平方和，则打印“等腰直角三角形”。

          3、若是等边三角形，则打印：“等边三角形”。

          4、画出程序流程图并设计一个测试用例。

          分析一下：

             1、构成三角形的条件：任意两边之和大于第三边；

             2、构成等腰三角形的条件：任意两边相等；

            3、构成等腰直角三角形的条件：任意两边相等，而且两条边的平方和等于第三边的平方和；

            4、构成等边三角形的条件：三条边都相等。

           那么用什么样的设计方法进行测试用例的设计呢？

              一、等价类划分：三角形三条边A、B、C的数据类型不同

              二、边界值分析：由于三角形的边长可以是正整数或正小数，所以就不对长度进行测试，那么边界值分析就不用了

              三、因果图法：三角形的三条边数据输入组合

      我们看一下三角形的流程图：

                   

                       注：改正一个小错误，在判断是否是等腰直角三角形中  A的平方=B的平方+C的平方。由于画图时，网络速度问题，导致真或假的值没有标注。

     我们再分析一下三角形的等价类：

                    有效等价类：

                        输入3个正整数或正小数：

                          1、两数之和大于第三数，如A<B+C；B<C+A；C<A+B

                          2、两数之和不大于第三数

                          3、两数相等，如A=B或B=C或C=A

                          4、三数相等，如A=B=C

                          5、三数不相等，如A！=B，B！=C，C！=A

                 无效等价类：

                           1、空

                           2、负整数

                           3、非数字                           

                           4、少于三个数

朋友圈点赞

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-wjquauBV-1624881287790)(C:\Users\Administrator\Pictures\20190705205149766.jpg)]

微信红包

功能测试
1）发给单个好友
① 正确的金额+无留言+无表情
② 错误的金额+无留言+无表情
③ 正确的金额+有留言+无表情
④ 错误的金额+有留言+无表情
⑤ 正确的金额+无留言+有表情
⑥ 错误的金额+无留言+有表情
⑦ 正确的金额+有留言+有表情
⑧ 错误的金额+有留言+有表情
其中，金额（0.01-200）可以测试以下数据
1）数字：测试0, 0.009, 0.01，0.011, 01， 199.99, 200, 200.01这些边界值
2）中文、英文、特殊字符或者这几种的组合
3）是否支持复制黏贴
4）为空/包含空格
5）金额的增删查改
留言可以测试以下数据
1）数字、中文、英文、特殊字符、表情或者他们的组合
2）输入超长文本时，是否会给出相应的限制或提示
3）包含空格
4）是否支持复制黏贴
5）留言的增删查改
表情可以测试以下数据
1）选择收藏的表情测试（动图/静图）
2）选择下载的表情测试（动图/静图）
3）录制表情，并添加进行测试
4）表情的增删查改
⑨ 点击塞钱进红包，选择零钱付款，此时需要考虑金额＞零钱，金额＜零钱，金额=零钱三种情况
⑩ 点击塞钱进红包，选择已添加的银行卡付款，此时同样需要考虑金额＞银行卡余额，金额＜银行卡余额，金额=银行卡余额三种情况
⑪ 点击塞钱进红包，选择使用新卡付款，按照流程添加新卡，此时同样需要考虑金额＞新卡余额，金额＜新卡余额，金额=新卡余额三种情况
⑫ 使用指纹确认付款（正确的/不正确的指纹）
⑬ 使用密码确认付款（正确的/不正确的密码 ）
⑭ 发送成功之后，对应的途径会减少相应的金额
⑮ 发送者/接受者可以点击红包查看到红包的具体信息，且金额，留言，表情均能正确显示
⑯ 好友点击红包之后，零钱中将增加相应的金额，再次点击之后，只能查看到红包的信息
⑰ 24小时之内没有领取的红包，将退回原账户，此时原账户的零钱将增加相应金额的金钱。24小时后好友点击红包，显示红包已过期，无法查看到红包的余额
⑱ 右上角的红包记录中，可以查看刚刚发出的红包的金额
⑲ 检测帮助中心中链接是否均可以正常跳转，查看
20 当红包超过24小时之后，则无法查看红包被每个人领取的详细信息
2）发送群红包（与发给好友的测试点相似，以下仅写出不同的部分）
① 选择为拼手气红包时，群中每个人收到的金额随机（但加起来为红包的总金额），为普通红包时，群中每个人收到的金额相同
② 红包个数（1-100）：0，1，2，大于群成员人数，小于群成员人数，等于群成员人数，99，100，101，小数，中文、英文、特殊字符、表情或者他们的组合
③ 但红包没有被抢完时，此时首次点击该红包的人可以抢到一定金额的红包，不是首次点击该红包的人只能查看该红包的信息；当红包抢完时，所有人只能查看该红包的信息。
④ 在24小时之内红包的金额被完全抢完，且此时为拼手气红包时，金额最多的人会显示为最佳手气（若有两个人取得红包的最大值时，则只有一个人会显示为最佳手气）；若没有被完全抢完，则没有最佳手气，且余额会退还到原账户
⑤ 群中所有人均可以抢红包（包括自己），每个人最多只有一次抢该红包的机会
⑥ 测试当红包个数使得每个红包分到钱小于0.01，即总金额为0.02，而红包个数为3时的情况

兼容性测试
1）苹果手机和安卓手机
2）苹果手机的不同版本
3）安卓手机不同的机型
4）不同分辨率

性能测试
1）打开红包的响应时间不能超过三秒，高并发场景下不能超过5秒
2）耗电量
3）消耗流量的多少
4）所占内存等

UI测试&易用性测试
1）界面的设计风格是否统一
2）界面中文字是否简洁，没有错别字
3）是否易操作，易学习，易理解

中断测试
前后台切换，网络异常，低电量，断电，来电，短信等

网络测试
1）网络兼容性：2g/3g/4g，WiFi，热点，移动/联通/电信
2）无网测试
3）弱网：延时&丢包