经典测试用例

admin管理员组

文章数量:1530873

目录

测试流程

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

测试中遇到开发不认为是BUG的BUG怎么办

经典用设计例

微信发红包

登录框

视屏播放器测试点

session、token、cookie 三者的区别

性能测试的指标有哪些

所在部门的人数与分工，以及测试是如何分工的

部门负责人的简称

---

测试流程

需求评审（有开发人员，产品经理，测试人员，项目经理）－>

需求确定(出一份确定的需求文档)－>

开发设计文档（开发人员在开始写代码前就能输出设计文档）－>

制定测试计划，写出测试用例－>

发给开发人员和测试经理看看（非正式的评审用例）－>

接到测试版本（可能测试的代码 通过冒烟测试的代码）－>

执行测试用例（中间可能会补充用例）－>

提交bug（有些bug需要开发人员的确定（严重级别的，或突然发现的在测试用例范围之外的，难以重现的），有些可以直接写到TD（Test Director 相当于禅道））－>

开发人员修改（可以在测试过程中快速的修改）－>

回归测试（可能又会发现新问题，再按流程开始跑）

---

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

首先，在遇到非必然重现的 bug ，一定要提 bug ，并且要在 bug 单中说明复现的概率。

在发现 bug 时，要分析产生的原因，尽量多尝试可能出现的步骤。排除环境和自己电脑配置的原因，比如浏览器的版本，系统的版本等。还可以寻找开发帮助，让开发对相应地方的代码进行检查，看一下是否可以通过代码层面检查出问题。

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

那些一直未能复现的 bug ，需要测试经理定期将这些 bug 汇总，选择优先级高的缺陷，组织开发人员和测试人员专门投入到复现问题。如果经过这样的专门复现依然不能复现，可以降低问题的优先级。如果在项目前期，跟踪至少3个版本，如果仍然无复现，可以暂时关闭该 bug ，备注说明并不是因为修复关闭，而是经过x个版本后不复现了。

如果项目周期比较紧张，不能跟踪多个版本，那么 bug 就不能关闭，上线后及时关注用户的使用反馈，如果持续3或者4个版本没有出现，那么可以将 bug 暂时关掉了，同时关掉的时候要进行备注说明。

测试中遇到开发不认为是BUG的BUG怎么办

　1、首先明确开发说不是bug的理由。测试

　2、如果是需求变更，那就找产品经理确认是否是需求变更。

　3、如果开发说测试环境问题，让他说明清楚测试环境问题是什么，按照他说的验证一遍，如果确实如他所说，关闭bug，但是不是他说的那样，继续激活bug给开发解决，确保产品质量。

　4、如果开发说用户不存在这种使用场景，但是我们不认可他说的，把这个bug知会到测试经理，让测试经理去判定。

   5、在最后提交测试报告中，把之前可能出现BUG的地方标注以及用例，以免替开发背锅

---

经典用设计例

微信发红包

1、功能测试
1）发给单个好友
① 正确的金额+无留言+无表情
② 错误的金额+无留言+无表情
③ 正确的金额+有留言+无表情
④ 错误的金额+有留言+无表情
⑤ 正确的金额+无留言+有表情
⑥ 错误的金额+无留言+有表情
⑦ 正确的金额+有留言+有表情
⑧ 错误的金额+有留言+有表情
其中，金额（0.01-200）可以测试以下数据

数字：测试0,  0.009,  0.01，0.011,  01， 199.99,  200,  200.01这些边界值
中文、英文、特殊字符或者这几种的组合
是否支持复制黏贴
为空/包含空格
金额的增删查改

留言可以测试以下数据

数字、中文、英文、特殊字符、表情或者他们的组合
输入超长文本时，是否会给出相应的限制或提示
包含空格
是否支持复制黏贴
留言的增删查改

表情可以测试以下数据

选择收藏的表情测试（动图/静图）
选择下载的表情测试（动图/静图）
录制表情，并添加进行测试
表情的增删查改

⑨ 点击塞钱进红包，选择零钱付款，此时需要考虑金额＞零钱，金额＜零钱，金额=零钱三种情况
⑩ 点击塞钱进红包，选择已添加的银行卡付款，此时同样需要考虑金额＞银行卡余额，金额＜银行卡余额，金额=银行卡余额三种情况
⑪ 点击塞钱进红包，选择使用新卡付款，按照流程添加新卡，此时同样需要考虑金额＞新卡余额，金额＜新卡余额，金额=新卡余额三种情况
⑫ 使用指纹确认付款（正确的/不正确的指纹）
⑬ 使用密码确认付款（正确的/不正确的密码 ）
⑭ 发送成功之后，对应的途径会减少相应的金额
⑮ 发送者/接受者可以点击红包查看到红包的具体信息，且金额，留言，表情均能正确显示
⑯ 好友点击红包之后，零钱中将增加相应的金额，再次点击之后，只能查看到红包的信息
⑰ 24小时之内没有领取的红包，将退回原账户，此时原账户的零钱将增加相应金额的金钱。24小时后好友点击红包，显示红包已过期，无法查看到红包的余额
⑱ 右上角的红包记录中，可以查看刚刚发出的红包的金额
⑲ 检测帮助中心中链接是否均可以正常跳转，查看
20 当红包超过24小时之后，则无法查看红包被每个人领取的详细信息
2）发送群红包（与发给好友的测试点相似，以下仅写出不同的部分）
① 选择为拼手气红包时，群中每个人收到的金额随机（但加起来为红包的总金额），为普通红包时，群中每个人收到的金额相同
② 红包个数（1-100）：0，1，2，大于群成员人数，小于群成员人数，等于群成员人数，99，100，101，小数，中文、英文、特殊字符、表情或者他们的组合
③ 但红包没有被抢完时，此时首次点击该红包的人可以抢到一定金额的红包，不是首次点击该红包的人只能查看该红包的信息；当红包抢完时，所有人只能查看该红包的信息。
④ 在24小时之内红包的金额被完全抢完，且此时为拼手气红包时，金额最多的人会显示为最佳手气（若有两个人取得红包的最大值时，则只有一个人会显示为最佳手气）；若没有被完全抢完，则没有最佳手气，且余额会退还到原账户
⑤ 群中所有人均可以抢红包（包括自己），每个人最多只有一次抢该红包的机会
⑥ 测试当红包个数使得每个红包分到钱小于0.01，即总金额为0.02，而红包个数为3时的情况
2、兼容性测试
1）苹果手机和安卓手机
2）苹果手机的不同版本
3）安卓手机不同的机型
4）不同分辨率
3、性能测试
1）打开红包的响应时间不能超过三秒，高并发场景下不能超过5秒
2）耗电量
3）消耗流量的多少
4）所占内存等
4、UI测试&易用性测试
1）界面的设计风格是否统一
2）界面中文字是否简洁，没有错别字
3）是否易操作，易学习，易理解
5、中断测试：前后台切换，网络异常，低电量，断电，来电，短信等
6、网络测试
1）网络兼容性：2g/3g/4g，WiFi，热点，移动/联通/电信
2）无网测试
3）弱网：延时&丢包

登录框

功能性测试用例包括：
1.输入已注册的用户名和正确的密码，验证是否登录成功；
2.输入已注册的用户名和不正确的密码，验证是否登录失败，并且提示信息正确；
3.输入未注册的用户名和任意密码，验证是否登录失败，并且提示信息正确；
4.用户名和密码两者都为空，验证是否登录失败，并且提示信息正确；
5.用户名和密码两者之一为空，验证是否登录失败，并且提示信息正确；
6.如果登录功能启用了验证码功能，在用户名和密码正确的前提下，输入正确的验证码，验证是否登录成功；
7.如果登录功能启用了验证码功能，在用户名和密码正确的前提下，输入错误的验证码，验证是否登录失败，并且提示信息正确。
8.用户名和密码是否大小写敏感；
9.页面上的密码框是否加密显示；
10.后台系统创建的用户第一次登录成功时，是否提示修改密码；
11.忘记用户名和忘记密码的功能是否可用；
12.前端页面是否根据设计要求限制用户名和密码长度；
13.如果登录功能需要验证码，点击验证码图片是否可以更换验证码，更换后的验证码是否可用；
14.刷新页面是否会刷新验证码；
15.如果验证码具有时效性，需要分别验证时效内和时效外验证码的有效性；
16.用户登录成功但是会话超时后，继续操作是否会重定向到用户登录界面；
17.不同级别的用户，比如管理员用户和普通用户，登录系统后的权限是否正确；
18.页面默认焦点是否定位在用户名的输入框中；
19.快捷键 Tab 和 Enter 等，是否可以正常使用。

20.鼠标光标是否只在固定位置才显示可点击或编辑状态

安全性测试用例包括：
1.用户密码及个人信息是否加密存储；
2.用户密码及个人信息在网络传输过程中是否加密；
3.密码是否具有有效期，密码有效期到期后，是否提示需要修改密码；
4.不登录的情况下，在浏览器中直接输入登录后的 URL 地址，验证是否会重新定向到用户登录界面；
5.密码输入框是否不支持复制和粘贴；
6.密码输入框内输入的密码是否都可以在页面源码模式下被查看；
7.用户名和密码的输入框中分别输入典型的“SQL 注入攻击”字符串，验证系统的返回页面；
8.用户名和密码的输入框中分别输入典型的“XSS 跨站脚本攻击”字符串，验证系统行为是否被篡改；
9.连续多次登录失败情况下，系统是否会阻止后续的尝试以应对暴力破解；
10.同一用户在同一终端的多种浏览器上登录，验证登录功能的互斥性是否符合设计预期；
11.同一用户先后在多台终端的浏览器上登录，验证登录是否具有互斥性。

12.登录接口返回的数据是否对用户信息进行加密显示

13.登录UA获取，确保是用户本人登录

性能压力测试用例包括:
1.单用户登录的响应时间正常网络环境下是否小于 2 秒；
2.单用户登录时，后台请求数量是否过多；
3.高并发场景下用户登录的响应时间是否小于 5 秒；
4.高并发场景下服务端的监控指标是否符合预期；
5.高集合点并发场景下，是否存在资源死锁和不合理的资源等待；
6.长时间大量用户连续登录和登出，服务器端是否存在内存泄漏。

7.防止同一用户恶意并发

兼容性测试用例包括：
1.不同浏览器下，验证登录页面的显示以及功能正确性；
2.相同浏览器的不同版本下，验证登录页面的显示以及功能正确性；
3.不同移动设备终端的不同浏览器下，验证登录页面的显示以及功能正确性；
4.不同分辨率的界面下，验证登录页面的显示以及功能正确性。

视屏播放器测试点

UI测试：

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

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

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

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

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

---

session、token、cookie 三者的区别

cookies

用户登录以后，在浏览器端生成一个文件，保存在浏览器的客户端
一般存储用户的身份信息
可以删除，删除后重新登录可以再次生成
使用不同的浏览器，电脑登录同一网站，会产生不同的cookies
有的系统会通过cookies存储用户行为习惯

储存在用户本地终端上的数据，服务器生成，发送给浏览器，下次请求统一网站给服务器
 

session

登录后服务器端发送一个随机的ID值，来进行用户身份的识别
session的有效性，是在代码中进行设计的，一般是30分钟
session只针对一个应用服务器有效

会话，代表服务器与浏览器的一次会话过程，这个过程是连续的，也可以时断时续。

cookie中存放着一个sessionID，请求时会发送这个ID；

session因为请求（request对象）而产生；

session是一个容器，可以存放会话过程中的任何对象；

session的创建与使用总是在服务端，浏览器从来都没有得到过session对象；

session是一种http存储机制，目的是为武装的http提供持久机制。

token

登录后，服务器端发送一个token令牌
token也有时效性
token可以支持多平台访问

最简单的token组成:uid(用户唯一的身份标识)、time（当前时间的时间戳）、sign（签名）。

在Token中包含足够多的信息，以便在后续请求中减少查询数据库的几率；

服务端需要对cookie和HTTP Authrorization Header进行Token信息的检查；

基于上一点，你可以用一套token认证代码来面对浏览器类客户端和非浏览器类客户端；

因为token是被签名的，所以我们可以认为一个可以解码认证通过的token是由我们系统发放的，其中带的信息是合法有效的；

cookie与session区别

cookie数据存放在客户端上，session数据放在服务器上；

cookie不是很安全，且保存数据有限；

session一定时间内保存在服务器上,当访问增多，占用服务器性能。

session与token

作为身份认证，token安全行比session好；

Session 认证只是简单的把User 信息存储到Session 里，因为SID 的不可预测性，暂且认为是安全的。这是一种认证手段。 而Token ，如果指的是OAuth Token 或类似的机制的话，提供的是 认证 和 授权 ，认证是针对用户，授权是针对App 。其目的是让 某App有权利访问 某用户 的信息。

token与cookie

Cookie是不允许垮域访问的，但是token是支持的， 前提是传输的用户认证信息通过HTTP头传输；

---

性能测试的指标有哪些

RT：响应时间
TPS：每秒完成事务数
CPU性能指标：利用率、负载
Mem：内存性能指标，可用物理内存、虚拟内存使用率
Disk：磁盘性能指标，Disk Time、IO等待
NetWork：网络指标，带宽使用率、任务队列长度
TCP连接数，可以用netstat命令统计得到
中间件建立的线程池，监控线程状态
JVM性能指标，GC情况、Heap使用情况
CPU负载队列长度

服务器与中间件之间建立的连接数及连接状态
一般性能分析的过程
序号 步骤名称 说明
1 检查RT 客户端响应时间
2 检查TPS TPS大时RT小， 说明性能良好
3 检查负载机资源消耗 检查CPU使用率
4 检查被压服务器的资源消耗 CPU 、 内存、磁盘IO、带宽、响应时间
5 检查中间件配置 确定是否有配置参数问题
6 数据库服务器 CPU、内存、IO繁忙程度、数据库监控。

---

所在部门的人数与分工，以及测试是如何分工的

一个测试经理，N个测试组长，每个组有N个测试人员：包括自动化测试，白盒测试，功能测试等等N个测试工程师。
往往都是根据接到的项目来组成测试团队。当然人手不够的时候，可以请几位开发人员参与到测试工作中。

---

部门负责人的简称

1、Dev：软件研发技术负责人

软件开发是根据用户要求建造出软件系统或者系统中的软件部分的过程。软件开发是一项包括需求捕捉、需求分析、设计、实现和测试的系统工程。

2、RD：研发（Research and Development）

如：软件RD工程师就是软件研发工程师，诸如PHP程序猿，Java程序猿，无论是爱疯的还是安卓的都是属于这一类别。偏向于后端的技术实现。

3、CPO：首席产品官（Chief Product Officer）

首席产品官把首席技术官（CTO）和首席市场官（CMO）这两个角色合二为一，注重用户体验，从而为公司赢得市场发挥重要作用。

4、TeamLeader： 项目组长

项目组长主要与团队成员一并商讨，问题的原因，最终达成共识，确定解决方案。

5、QA：测试（QUALITY ASSURANCE，中文意思是“质量保证”）

为了提供足够的信任表明实体能够满足质量要求，而在质量管理体系中实施并根据需要进行证实的全部有计划和有系统的活动”。有些推行ISO9000的组织会设置这样的部门或岗位，负责ISO9000标准所要求的有关质量保证的职能，担任这类工作的人员就叫做QA人员。

6、PM：项目经理( Project Manager )

从职业角度，是指企业建立以项目经理责任制为核心，对项目实行质量、安全、进度、成本管理的责任保证体系和全面提高项目管理水平设立的重要管理岗位。项目经理是为项目的成功策划和执行负总责的人。

7、PO：产品运营(Product Operation)

在互联网行业，尤其是阿里巴巴集团，PO是产品运营的缩写，全称是product operation，隶属于产品部门，与PD（product design ，产品设计）相对应。

本文标签： 测试经典