软件测试场景题一览

1、设计一个登录页面的用例

功能测试：
正确输入、为空输入、字符类型校验、长度校验、密码是否加密显示、大写提示、跳转页面是否成功、登出后用另一个账号登录
UI：
界面布局合理、风格统一、界面文字简洁好理解、没有错别字
性能测试：
打开登录页面需要几秒、点击登录跳转首页需要几秒、多次点击、多人点击
安全性：
用户名和密码是否加密发送给服务器、错误登录的次数限制（防止暴力破解）、一台机器登录多个用户、一个用户多方登录、检查元素能否看到密码
兼容性测试：
不同浏览器、不同的平台（Windows、Mac）、移动设备能否工作
易用性：
输入框可否tab键切换、回车能否登录等

2、介绍一下测试用例设计方法（用例设计方法&测试方法需分清楚）

黑盒测试用例设计：
等价类划分法、
边界值分析法、
错误推测法、
因果图法、
正交试验分析法、
流程分析法（场景法）、
判定表法
白盒测试：
语句覆盖、
判定覆盖、
条件覆盖、
条件组合覆盖、
判定/条件覆盖、
路径覆盖

3、你说原来充值功能，你是怎么测试的？

1、首先我们先测试充值的 主体功能，看看能否充值成功；

（等价类，边界值，判定表，流程分析法，状态迁移法，错误推测法，异常处理法来测试）
(1)用边界值的方法测试充值限定的额度能否充值成功
(2)用特殊字符在充值输入框输入是否有提示语提醒
(3)充值输入框为空时点击充值是否有提示
(4)在输入框里输入金额，再后退网页再进入充值页面，是否还保存着输入的金额数
(5)多次往返充值界面，是否还可以正常充值
(6)选择多个充值支付方式能否充值成功
(7)选择各银行网银能否充值成功
(8)充值成功时，有没有相关的提示和页面是否正确跳转
(9)充值成功后，相关联的金额是否正确显示
(10)充值成功后，查看数据库的相关数据是否有存在和正确
(11)点击第三方支付（如支付宝，微信）是否有相关的连接页面跳转
(12)能否同时选择多个支付方式来充值
(13)交叉选择支付方式后，再选择其中一个支付方式能否充值成功
(14)充值输入框多次修改充值金额，能否充值正确
2、我们再测试充值的 性能，用jmeter模拟大量用户同时充值，看看能否充值成功；

3、我们再对充值的 安全性 进行测试

（1）绑定银行卡充值和未绑定银行卡能否充值成功；
（2）绑定多张同名的银行卡以及一个用户绑定多张不同名的银行了能否绑定充值成功
（3）实名认证和未实名认证能否充值成功；
（4）用边界值的方法测试每天充值限额，次数
（5）测试一天之内最多可以输入密码错误次数是多少，次数达到多少次锁卡，是否需要
到银行解锁方能再进行充值
（6）输入充值金额后需要输入多少次密码，是否有加密，不输入密码能否充值成功；
（7）使用其他的支付方式支付能否充值成功；
（8）测试充值金额的类型；
（9）充值之后所充值的账户以及平台的余额额度是否有增加；
（10）单次点击，多次点击会不会充值成功；以及多次点击会不会多次充值；
（11）同时打开多个充值界面，能否充值成功；
（12）不登陆用户的情况下是否充值成功；
（13）不选择银行卡或其他方式支付是否能充值成功；
（14）跨站攻击，数据泄密；
4、我们还要对 兼容性 进行测试，看看不同的版本、分辨率，不同的浏览器，能否正常充

值；

5 、对 易用性 进行测试，测试充值的整个流程是否易用，遇到一些不懂的有没有相应的温
馨提示；

6、还会考虑测试 异常的情况：（网络异常和设备异常）,比如说：

（1）充值的过程中突然没网或者网络中断或弱网情况下是否充值成功；
（2）充值过程中突然断电了，能否充值成功；
（3）充值过程中设备卡顿能否充值成功；
（4）银行卡挂失，被注销，卡内余额不足，卡里金额被冻结，额度超过限额的情况能否
充值成功；
7、我们再对 界面 进行测试：

（1）界面是否美观，格式是否正确，中文是否有错别字；
（2）在其他浏览器能否打开我们这个充值界面，能否正常显示并且正常充值；
（3）界面上的按钮是否符合用户的使用习惯，主要关键的功能按钮是否容易找到，操作是否便捷；
（4）在不同的浏览器里界面缩放后，界面排版是否正常显示

4、如何测试一个纸杯?

功能度：用水杯装水看漏不漏;水能不能被喝到
安全性：杯子有没有毒或细菌
可靠性：杯子从不同高度落下的损坏程度
可移植性：杯子在不同的地方、温度等环境下是否都可以正常使用
兼容性：杯子是否能够容纳果汁、白水、酒精、汽油等
易用性：杯子是否烫手、是否有防滑措施、是否方便饮用
用户文档：使用手册是否对杯子的用法、限制、使用条件等有详细描述
疲劳测试：将杯子盛上水(案例一)放24小时检查泄漏时间和情况;盛上汽油(案例二)放24小时检查泄漏时间和情况等
压力测试：用根针并在针上面不断加重量，看压强多大时会穿透

5、给你一个网站怎么测试？

1.首先，查找需求说明、网站设计等相关文档，分析测试需求。
2.制定测试计划，确定测试范围和测试策略，一般包括：功能性测试、界面测试、性能测试、数据库测试、安全性测试、兼容性测试
3.设计测试用例：
功能 可以包括，但不仅限于以下几个方面：
链接测试。链接是否正确跳转，是否存在空页面和无效页面，是否有不正确的出错信息返回
提交功能的测试
多媒体元素是否可以正确加载和显示
多语言支持是否能够正确显示选择的语言
界面测试 可以包括但不仅限于以下几个方面：
页面是否风格统一、美观
页面是否布局合理，重点内容和热点内容是否突出
控件是否正常使用
对于必须但但未安装的控件，是否提供自动下载并安装的功能
性能测试 ：
压力测试、负载测试
数据库测试 要具体决定是否需要开展:
考虑连结性，对数据库的存储操作，数据内容的验证等方面
安全性测试:
基本的登录功能的检查
是否存在溢出，导致系统崩溃或权限泄露
相关开发语言的常见安全性问题检查，如SQL注入，跨站点攻击。
兼容性测试，根据需求说明的内容，确定支持的平台组合
浏览器的兼容性
操作系统的兼容性
软件平台的兼容性
数据库的兼容性

4.开展测试，并记录缺陷
合理的安排调整测试进度，提前获取测试所需的资源，建立管理体系(需求变更、风险、配置、测试文档、缺陷报告、人力资源等)
5.定期评审，对测试进行评估和总结，调整测试的内容

6、如何全面测试一款产品，以手机短信功能为例辅助说明，手机自带的短信功能，并非微信、qq这种软件

能正常打开或关闭短信界面
短信可以正常编辑、修改、删除
短信可以正常发送和接收
短信页面字体、颜色显示正常
短信字体可调
给多人同时发短信
给特殊号码发短信
运营商
不存在的手机号
服务号（收费、不收费）
接收验证码
短信耗电量测试
短信在联网、不联网情况下
短信干扰测试
编辑短信期间，打电话进来
隐藏到后台，进行其他操作，再返回来

7、微信朋友圈点赞测试？

1.功能测试
微信好友是否可以点赞和取消点赞
发动态本人是否支持点赞和取消点赞
多次点赞会出现什么情况
多人点赞时的顺序是否按照时间顺序进行排列
点赞是否显示名称
点击点赞微信昵称是否可以跳转到该用户主页
点赞之后能否进行评论
点赞之后退出该页面，再次进入朋友圈点赞消息是否还存在
多用户点赞，再次打开朋友圈是是否可以按照顺序看到是谁谁谁赞了我
2.接口测试
点赞之后相同好友是否收到提示信息
相同好友处的提示信息是否按照时间顺序
相同好友处的点赞是否显示微信昵称
3.兼容测试
电脑端和手机端是否都可以进行点赞和取消点赞功能
不同的移动端是否都可以行点赞和取消点赞功能（包括苹果，安卓）
4.可用性测试
弱网的时候进行点赞是什么情况
网络断开时是否可以点赞
用户点击点赞几秒后可以看到点赞成功，取消同理
多用户同时给我点赞时，我是否可以全部接收到提示消息
5.安全性测试
点赞是否会泄漏微信用户相关信息

8、微信红包怎么测试？

9、如果京东有一个购物网页给你，你要怎么进行测试？测试哪些主要功能？

首先进行 需求分析 ，用xmind梳理测试点，再编写案例，之后就行案例评审，寻求他人意见。之后再完善案例，发出来给其他人检查。
测试点，首先是 UI方面 ：美观度，和易操作型，易理解性型方面进行测试。
然后再考虑他的 功能 点，注册登录，添加购物车，下单，付款，发货，确认收货，评价。
还有支付时候的绑定银行卡，实名认证。
性能方面：打开网页，确认订单、付款的响应时间等等。
兼容性：支持各种主流浏览器，ie，360，火狐，谷歌等。

10、针对添加购物车这个测试点说一下你要怎么测试“添加购物车”（增删改查的角度）

1 能否加入购物车，同一件商品能否再次添加到购物车。
2 购物车商品件数的上限限制（淘宝限制100件）
3 购物车是否可以正常移除商品，移除商品后，能否再添加回来。
4 添加的每种商品是否可以正常增减数量，数量大于0
5 退出购物车，再去查询购物车，商品正常。
6 购物车的商品可以全选，取消全选，可以复选，选中的商品和数量可以正常下单。
7 商品添加到购物车以后，已下架。购物车会提示此宝贝已失效。
8 商品添加到购物车以后，降价了，购物车会有降价提示。
9 商品添加到购物车以后，库存不足了。

11、网上银行转账是怎么测的，设计一下测试用例。

宏观上可以从质量模型（万能公式）来考虑，重点需要测试转账的功能、性能与安全性。
设计测试用例可以使用场景法为主，先列出转账的基本流和备选流。然后设计场景，最后根据场景设计数据。
1 先检查 ui界面。
2 再 测试功能：
2.1验证同行转账，跨行转账。
2.2验证转账限额。
2.3验证非法账户（挂失，冻结，锁定的账户）的转账。
3 再测试 性能方面 的。

12、给你一个app，怎么测(app测试用例?)

01 界面
测试界面跟需求文档中界面原图是否一致，
使用不同的手机界面分辨率，以及界面大小等方面进行测试
02 功能
除安装，卸载，更新 和web端差不多
03 兼容性
系统兼容(ios、安卓)
机型兼容（iPhone、华为、小米、三星、vivo、OPPO）
分辨率兼容
系统版本兼容
软件本身向前向后兼容
04 稳定性
检查软件长时间运行，会不会出现崩溃
05 交互性
跟手机固有的功能模块，进行交互使用
音量的调节，锁屏，旋转，返回键，主菜单键，截图，闹钟，待机，插拔数据线，耳机，wifi、蓝牙，电话，短信，低电量，看功能是否正常使用,
界面是否为原来界面，输入数据是否保存，还有跟其他app进行交互性测试
06 安全性
sql语句的注入
xss脚本的攻击
重要数据加密
权限测试
07 易用性
用户使用是否方便，好用
08 性能测试
Emmagee去测试APP的性能
监测cpu、内存、fps等
09 网络测试
2G，3G，4G，移动，电信，联通，还有网络之间切换，用fiddler进行弱网测试
10 权限
前台不能访问后台
不能通过url连接支架访问
后台不能直接进入界面

13、AMT取款

需求规格说明：

插入卡后，输入的密码正确，进行取款操作，取款成功后打印凭条后退卡，完成取款流程。

插入卡后，卡无效或账号不存在，退卡结束流程；

密码输入错误次数不得超过3次，否则给出提示并退卡，结束流程；

插入卡后，账号和密码验证成功，选择取款操作后，ATM已无现金，退卡结束流程；

以下3种情况，给出提示后，需重新输入取款金额：

取款金额 > 账户余额；

取款金额 > ATM余额；

取款金额 > 取款额度。

请用场景法设计测试用例。

1.首先根据需求规格说明得到基本流以及备选流：

2.程序的基本流和备选流整理整理：
基本流：即正常情况下的场景，本题应该为插卡，输入正确密码，成功取款并打印凭条，取卡。
备选流：则是一些非正常情况下的情景，如密码不正确，卡无效等。
简单来说，基本流可以达到目的，备选流达不到最终目的。

3.根据基本流和备选流生成场景

4.生成测试用例对应场景

14、输入3个整数，输出等边三角形、直角三角形，等腰三角形，普通三角形测试用例？

14、文件下载怎么设计用例？

功能
支持当前页面下载，还是新窗口打开另存为。
下载后比对文件，是否和上传时的文件完全一致。
注意文件名称为空、含特殊字符及文件名称较长的文件，下载后的文件是否和上传时的一致。
下载文件过程中断网，等网络恢复，看文件是否继续下载。
下载文件是否支持多个文件同时下载，或同一文件多次下载
下载过程服务器异常（断开连接等），服务器恢复正常是否继续下载
点击下载按钮时是否弹起下载页面弹窗
下载完成在服务器日志、数据库查看文件名、文件大小、文件格式、下载开始时间、下载结束时间等和前端抓包接口响应数据是否一致
下载文件异常性测试，如本地磁盘空间不足

文件存储
文件上传到服务器之后，采用的是文件存储 NAS 还是对象存储 OSS
文件上传到服务器之后，是否有做容灾备份

安全问题
文件上传到服务器之后，文件名是否做了加密
不具备访问权限的用户是否能够访问
不具备下载权限的用户是否能够下载

性能
跳转到下载页面响应时间
弹起保存窗口页面响应时间
单用户下载文件速率，是否符合需求目标。
多用户并发下载文件的速率，是否符合需求目标
下载完成的耗时

15、搜索框如何测试？

• 功能测试
  • 搜索内容为空，验证系统如何处理
  • 搜索内容为空格，查看系统如何处理
  • 边界值验证：在允许的字符串长度内外，验证系统的处理
  • 超长字符串输入，系统是否会截取允许的长度来检验结果
  • 合法的字符串长度后，加空格验证检索结果
  • 多个关键字中间加入空格，逗号，tab验证系统的结果是否正确
  • 验证每种合法的输入，结果是否正确
  • 是否支持检索内容的复制、粘贴、编辑等操作
  • 是否支持回车键搜索
  • 多次输入相同的内容，查看系统的检索结果是否一致
  • 特殊字符、转义字符、html脚本等需要做处理
  • 敏感词汇，提示用户无权限等
  • 输入的内容是否支持快捷键操作等
  • 只能输入允许的字符串长度等
  • 输入链接是否正确跳转
  • 搜索的历史纪录是否显示在下面
  • 搜索内容有没有联想功能
  • 是否可以输入数字，英文，中文
  • 是否可以混合输入数字英文中文
  • 输入拼音也可以进行检索
  • 语音搜索的内容是否匹配
  • 断网时，无法搜索
  • 进行图片搜索时可以选择拍照或从相册中选取图片进行搜索
  • 如果从相册中选取图片进行搜索，图上的大小是否有限制，最大为多少
  • 搜索框边上有相机图片，便于图片搜索
  • 点击清空历史记录，搜索框是否会清空历史记
  • 能否识别图片中的内容
  • 点击搜索，显示搜索界面
• 界面测试
  • 查看UI是否显示正确，布局是否合理
  • 是否有错别字
  • 搜索结果显示的布局是否美观
  • 已查看的结果链接，链接的颜色要灰化处理，
  • 结果数量庞大时，页面的分页布局是否合理
  • 界面的颜色搭配是否合理
• 安全性测试
  • 脚本的禁用
  • SQL的注入，检索SQL SELECT语句等
  • 敏感内容的检索是禁止的
  • 特殊字符的检索
  • 被删除、加密、授权的数据，不允许被查出来，6.是否有安全设计控制
• 兼容性测试
  • 多平台Windows，mac
  • 移动平台android，ios
  • 多浏览器火狐、chrome、IE等
• 性能测试
  • 搜索页面的链接打开速度的时间
  • 搜索出结果消耗时间
  • 弱网时搜索的响应时间
  • 不同网速下搜索时的响应时间3g,4g,WIFI
• 易用性
  • 有联想功能
  • 搜索内容与搜索结果的匹配程度
  • 支持拍照搜索，语音搜索

15、电梯/雨伞/杯子/笔/A4纸/纸杯… 怎么测试？

如何分析
以下以拉杆箱为例来给大家讲：

1.那么首先，你应该反问面试官，需求是什么样的，比如测什么样的拉杆箱，大小？材质？品牌？

2.如果回答是没有，那么你接下来的思路是：没有需求文档，但我了解拉杆箱的基本业务功能，以此为依据，从下面几个方面进行分析：

功能测试（单个功能、逻辑业务/功能交互）、界面测试、易用性测试、兼容性测试、安全性测试、性能测试

具体案例分析
——功能测试——

->拉杆箱大小、箱子厚度、容量、各个面（包括拉杆面、脚轮面）承重、拉杆承重是否符合质检标准

->拉杆箱超出容量、各个面（包括拉杆面、脚轮面）超出承重、拉杆超出承重是否正常使用

->拉杆的伸缩是否正常，展开收回是否灵活 ->轮子的滚动是否正常，是单向，还是360度旋转

->箱子的箱锁是否正常，开锁解锁是否方便安全

——界面测试——

->箱子面料材质、颜色、花纹、形状是否符合要求，颜色是否容易脱落

->箱子拉杆材质颜色长度、箱子脚轮材质颜色大小是否符合要求

->箱子吊牌logo是否正确、辅助说明是否正确

——易用性测试——

->箱子拉杆手把是否易握防滑、侧面手把是否易握防滑

->箱子开合的拉链是否易拖动、脚轮是否灵活

——兼容性测试——

->箱子脚轮滚动是否支持平底、沙地、泥土地、楼梯使用

->箱子在不同温度、例高温、低温、超低温是否能正常使用

->箱子在下雨天、下雪天、冰雹天是否能正常使用

——安全性测试——

->箱子面料材质是否安全无毒；遇高温、淋雨是否释放有害物质

->箱子各个边角是否光滑无棱角

->箱子拉杆把手、侧面把手是否光滑

——压力性能测试——

->负重连续30公里，查看拉杆脚轮箱是否正常无磨损

->负重并拉杆展开，提起拉杆把手使箱子处于悬挂状态，左右震荡500次，拉杆是否正常

->负重从1米左右落下，各个面（包括拉杆面、脚轮面）做5次落地，是否正常无磨损

->负重后，360度滚动整个箱子30圈，是否正常无磨损

->负重后，下25个阶段，脚轮拉杆箱面是否正常无磨损

->拉杆来回展开收回，重复1000次，拉杆是否正常

以后碰到这种题型，不管三七二十一，都可以这么来回复面试官：我不知道这个具体需求，但是我了解基本功能使用，所以我会从以下几个方面来分析，首先从功能测试来考虑的话，balabla；界面考虑的话，balabla，…，压力测试考虑的话，balabala；以上就是我的回答，谢谢 这样来回答的话，会显得条理很清楚，每个不同的测试方向自己临场发挥，怕啥，反正是思维发散题，能想到多少可以说多少~

16、登录界面的测试用例：

1.界面UI测试：
①布局是否符合需求文档的要求；
②输入框和按钮的长度、高度是否符合要求；
③界面的设计风格是否与UI的界面设计风格统一；
④界面的文字是否简洁易懂，无错别字。

2. 功能测试：
   ①输入正确的用户名和密码，验证登录成功；
   ②用户名、密码为空，验证登录失败并提示信息；
   ③登录成功后，是否跳转到相应的界面；
   ④用户名和密码过长或过短是否有提示信息；
   ⑤用户名和密码之间有空格、特殊字符或者其他非英文的处理；
   ⑥登录失败后，不能有记住密码的功能；
   ⑦密码是否加密显示；
   ⑧登录页面的注册、忘记密码、登出等用另一账号登录链接是否正确。
   ⑨输入密码，大写键盘打开是否有提示信息；
   ⑩输入错误的用户名和密码，查看提示信息。
3. 性能测试：
   ①打开登录界面，需要几秒（时长）；
   ②输入正确的用户名和密码登录成功，登录时长不超过5s。
4. 兼容性测试：
   ①主流浏览器是否显示成功；
   ②不同的平台是否显示成功；
   ③移动设备上是否显示成功（Android iOS）；
   ④不同的分辨率；
5. 可用性测试：
   ①是否支持全键盘操作，是否有快捷键；
   ②输入用户名和密码，按回车是否可以登录；
   ③输入框能否tab键切换。
6. 安全性测试：
   ①用户名和密码是否通过加密的形式发送给web服务器；
   ②用户名和密码的输入，应该屏蔽SQL注入（是指web应用程序对用户输入的数据的合法性没有判断或过滤不严，得到相应的数据信息；；方式有：数字型注入、字符型注入以及其他型注入，比如cookie注入，post注入）；
   ③用户名和密码的输入，应该禁止输入脚本（依据一定的格式编写的可执行文件）；
   ④错误登录的次数限制；
   ⑤考虑是否支持多用户在同一机器上的登录；
   ⑥考虑一用户在多态机器上的登录。

17、针对王者里一个游戏的测试：

比如说亚瑟：
①技能能否使用，以及普攻能否正常使用；
②他能否出装和卖装；
能否换皮肤和购买新皮肤；
④亚瑟的口头禅是否顺利并且带有感情色彩表达出来；
⑤每个技能的有效时长；
⑥不进行操作时，他是否自己会操作；
⑦带的闪现、终结或者惩戒、弱化等验证是否正常使用；
⑧回血技能是否可以使用；
⑨发起进攻、撤退等操作可否进行；
⑩快捷语能否实现；

18、微信红包测试用例

单个红包：

1、红包金额为空、0、0.01、200.00、200.01、199.99、200

2、留言输入数字、字母、汉字、特殊字符

3、留言长度

4、留言复制粘贴

5、表情选择收藏表情、其他表情

6、删除表情、重新选择表情

7、选择支付方式 零钱、银行卡、添加新卡支付。其中钱数<红包钱数、其中钱数=红包钱数、其中钱数>红包钱数

8、使用指纹确认付款（正确的、错误的指纹）

9、使用密码确认付款（正确的、错误的密码）

10、红包成功发送后 相应支付方式中钱数减少（减少金额与红包金额一致）

11、接受者能看到红包具体信息，红包金额、留言、表情均能正确显示

12、红包被拆开后显示已领取，领取者零钱中增加正确金额，再次领取只能查看红包信息

13、发红包者自己领红包

14、红包24小时未被领取提示红包被退回，相应支付方式中钱数增加（增加金额与红包金额一致），对方不能领红包

群发红包-普通红包： （只写了与单个红包不同的地方）

1、红包个数 为空、0、001、100、99、101

2、红包拆开每个金额一样 均为发红包时设置的单个金额对应的钱数

3、红包被拆时，有相应提示

4、发红包者自己领红包

5、红包24小时内未被拆完，剩余钱被退回，相应支付方式中钱数增加

群发红包-拼手气红包：

1、红包总额/红包个数<0.01

2、红包每个人拆开金额不同，总金额与发红包设置的总额一致

3、红包24小时内拆完后显示最佳手气

4、红包24小时内未被拆完不显示最佳手气

兼容性： 安卓、苹果 不同型号版本手机

UI测试： 界面无错别字，风格统一

中断测试： 不同应用之间切换、断网、来电、短信、低电量、手机没电

网络测试： 2g/3g/4g WiFi 移动联通电信 弱网 无网

19、微信朋友圈测试用例

功能测试

1、朋友圈发送功能

1）只发送文本

a、考虑文本长度：1-1500字符（该数据为百度数据）、超出最大字符长度

b、文本是否支持复制粘贴

c、为空验证

2）只发送图片

a、本地相册选择/拍摄

b、图片数量验证：1-9张图片、超出9张

c、为空验证

3）只发送视频

a、本地相册选择/拍摄

b、视频秒数验证：1-10s，超出10s

c、视频个数验证：1个，超出1个

d、视频格式验证：支持的视频格式，例mp4、不支持的视频格式

e、视频大小验证：苹果400kb以内、Android200-300kb（此为百度数据）、超出规定大小

f、视频预览增删改操作

g、为空验证

4）发送文本+图片：输入满足要求的文本、图片进行一次验证

5）发送文本+视频：输入满足要求的文本、视频进行一次验证

6）发送图片+视频：不支持发送

7）朋友圈发送内容是否有限制，例如涉及黄赌毒等敏感字

8）所在位置

a、不显示位置：发送到朋友圈动态不显示位置

b、选择对应位置：搜索支持、自动定位、手动编辑

C、点击取消，返回上一级页面

9）谁可以看

a、设置公开：所有朋友可见

b、设置私密（仅自己可见）：自己查看朋友圈-可见、好友查看朋友圈-不可见

c、设置部分可见（部分朋友可见）：选择的部分好友-可见、不被选择的好友-不可见、是否有人数上限

d、设置不给谁看（选中的朋友不可见）：不被选中的朋友-可见、被选中的朋友-不可见、是否有人数上限

e、点击取消，返回发送页面

10）提醒谁看

a、提醒单人/提醒多人：被提醒的朋友-收到消息提醒、未被提醒-未有消息提醒

b、是否有人数上限

c、点击取消，返回发送页面

11）同步QQ空间：默认不同步、同步到QQ空间

12）取消发送朋友圈操作

a、选择相机，点击取消，返回朋友圈页面

b、进入朋友圈发送页面，选择文本图片，点击取消

13）朋友圈当天发送次数是否有上限限制

2、朋友圈浏览功能

1）文本查看：

a、过长文本内容是否隐藏，并支持查看全文

b、右键选择复制、收藏、翻译

c、url链接是否支持点击跳转网页

2）图片查看

a、小图右键支持收藏/编辑

b、点击支持大图浏览

c、选择发送给朋友、收藏、保存图片、编辑

d、多张图片支持左右滑动浏览

3）视频查看

a、右键视频支持静音播放/搜藏

b、点击视频播放按键支持播放视频

c、选择发送给朋友、收藏、保存视频、编辑

4）分享动态浏览：QQ空间/公众号文章/非腾讯产品分享后朋友圈是否正常显示

5）赞：点赞、取消点赞

6）评论

a、评论长度：评论字数合理长度、评论超过字数上限

b、评论类型：纯中文、纯数字、纯字母、纯字符、纯表情（微信表情/手机自带表情）、混合类型、包含url链接；

c、评论是否支持复制粘贴

d、为空验证

e、发表评论后删除

f、评论回复操作

7）删除朋友圈动态

8）更换相册封面

9）刷新是否正常获取新动态

10）上滑是否加载更多

界面/易用性测试

1、技术人员角度：页面布局设计是否跟产品原型图/ui效果图一致

2、但除了考虑1之外，我们同样要考虑到用户使用：功能操作是否简便，页面布局排版风格是否美观合理，提示语相关信息是否易于理解

中断测试

1、主要考虑：a)核心功能 b)当前功能存在实时数据交换，例发朋友圈、浏览朋友圈进行中断，是否容易出现崩溃

2、中断包括：前后台切换、锁屏解锁、断网重连、app切换、来电话/来短信中断、插拔耳机线/数据线

网络测试

1、三大运营商不同网络制式测试

2、网络切换测试：WIFI/4G/3G/2G

3、无网测试：对于缓存在本地的数据，部分朋友圈信息是否支持浏览

4、弱网测试：

a、延时：页面响应时间是否可接受、不同网络制式是否区分超时时长、出现请求超时，是否给予相应的提示

b、丢包：有无超时重连机制、如果未响应，是否给予相应提示

c、页面呈现的完整性验证

兼容性测试

1、Android手机端、苹果手机端、pad版（主流）功能界面显示是否正常

2、各平台朋友圈展示数据是否一致

安全测试

发送朋友圈时，文本输入脚本代码，是否出现异常

性能测试

1、服务器性能测试

可通过loadrunner/jmeter工具实现，主要关注TPS、响应时间、吞吐量、CPU、内存等

2、app客户端性能测试

可通过GT工具实现，运行时关注cpu、内存、流量、电量等占用率

20、微信朋友圈点赞功能测试用例设计

21、如何对吃鸡游戏进行压力测试

1.游戏服务器硬件
硬盘I/o、内存、CPU

2.网络压力
a.长连接
　　最大连接数、流量(内网、外网、进、出)
b.长连接短周期(类似Http的TCP应用，这个比较特殊的一个需求，专门针对LoginAgent)
　　每秒建立的连接数、实际处理能力

3.数据库
　　每秒事务数、每秒锁等待数、平均延时(ms)、CPU暂用

4.多线程的最优线程数
　　数据库执行的多线程、多连接处理

二.Windows Server环境测试方式

1.服务器性能监测
使用Server自带的性能监测器设置各个进程的监测参数。Window的这个自动工具做的相当强大。大家自己摸一摸基本就会用了。每个参数都由详细的说明。

2.案例设计注意
a.对于数据库的性能测试上，现在由于所有的游戏服务器构架在DB前面都有一个实现DB缓冲功能的进程，以减少数据库频繁的读写操作。所以其实数据库的读是一个轻量级的数量；而数据库的写操作是一个周期性能过程。案例设计一定要能够驱动这种周期性能过程。比如我们游戏的战斗，导致游戏玩家数据的改变，或驱动所有在线玩家数据的周期性存储。
b.选择具有代表性，并且最频繁的游戏操作。用于进行最高用户在线的各种性能指标采集。如，开枪、道具拾取、道具使用、移动、聊天
c.聊天性能测试
广播聊天是最为考验游戏信息发送能力的功能。通过进行全局广播的压力测试。我们可以获取服务器进程发送信息到客户端的最高承载量。进而可以对我们的各种广播功能进行一个预估和频率限制。
d.同屏玩家的移动测试
移动+广播。这两种信息，基本是网络游戏流量的70-80%左右。同屏玩家数量，将会增加各种数据的广播需求，非常影响游戏性能。所以同屏的移动测试也是广播测试的一个必要环节。需要根据实际结果进行适当的优化。
e.大量玩家同时登录测试
玩家登录时，有大量的信息需要进行分配和初始化；同时也有大量的数据需要下传客户端。服务器需要进行大量的TCP连接建立。所以是一个比较关键的过程。这个测试案例是一个比较特殊，但是运营是肯定会碰到的案例。
f.由于线程池处理事务，随着事务的时耗，存在一个最优线程数的问题。过多的线程反而会降低服务器效率

3.细节问题
a.进行测试需要仔细思考客户端性能影响服务器最后表现的可能性。比如
a1.模拟客户端的性能无法有效处理服务器返回信息,可能就导致服务器发送的信息缓存在服务器系统缓存，从而表现出服务器内存不断增加。表现为服务器发送能力不足，其实可能根本就是客户端的性能问题
a2.客户端性能问题，导致发起的请求数过少，从而导致单位时间内服务器处理的请求过少。表现为服务器性能不足，其实根本就是客户端的请求能力不足。
b.网络带宽导致最后表现不足
b1.确认服务器的各个网卡，以及相互的带宽。不然可能因为相互带宽，导致服务器对于客户端请求的处理延时。表现为服务器卡机
b2.客户端模拟多个玩家，比如1000个玩家。而客户端的网卡或者客户端与服务器之间的中转服务器带宽过小，导致服务器数据发送不出，内存不断增加。表现为服务器发送能力不足，其实是中间带宽问题。
c.debug i/o导致服务器性能下降
c1.进行性能测试，一定要取消debug用的同步的i/o.比如我们服务器的debuginternalLog.同步i/o是非常影响性能的，特别在压力测试下可能导致每秒上千上万甚至几十万次的执行。一处的文件写入操作就可以导致几十万次的处理能力变成几千次的处理能力。
c2.客户端避免进行阻塞操作导致模拟多用户性能下降，导致服务器表现性能下降
d.流量需要区分内网网
内、外网流量在游戏正式运行时是完全分开的。价格也是完全不同的。一个千M的外网是一个无法想象的运营成本，而kmbps/s现在已经是一个可以接受的代价。游戏进程需要进行不同网卡的配置和绑定。确定内外网流量。

22、如何对淘宝搜索框进行测试

一, 功能测试

1. 输入关键字，查看: 返回结果是否准确，返回的文本长度需限制
   　　1.1输入可查到结果的正常关键字、词、语句，检索到的内容、链接正确性；
   　　　　　　1.2输入不可查到结果的关键字、词、语句；
   　　　　　　1.3输入一些特殊的内容，如空、特殊符、标点符、极限值等，可引入等价类划分的方法等；
2. 结果显示：标题，卖家，销售量，单行/多行，是否有图片
3. 结果排序：价格 销量 评价 综合
   4.返回结果庞大时，限制第一页的现实量，需支持翻页
4. 多选项搜索：关键字 品牌 产地 价格区间 是否天猫 是否全国购
5. 是否支持模糊搜索，支持通配符的查询
   7, 网速慢的情况下的搜索
6. 搜索结果为空的情况
7. 未登录情况和登录情况下的搜索（登录情况下 存储用户搜索的关键字/搜索习惯）
   二.性能测试：
   1压力测试：在不同发用户数压力下的表现（评价指标如响应时间等）
   2负载测试：看极限能承载多大的用户量同时正常使用
   3稳定性测试：常规压力下能保持多久持续稳定运行
   4内存测试：有无内存泄漏现象
   5大数据量测试：如模拟从庞大的海量数据中搜索结果、或搜索出海量的结果后列示出来，看表现如何等等。
   三. 易用性：交互界面的设计是否便于、易于使用
   1、依据不同的查询结果会有相关的人性化提示，查不到时告知？查到时统计条数并告知？有疑似输入条件错误时提示可能正确的输入项等等处理；
   2、查询出的结果罗列有序，如按点击率或其他排序规则，确保每次查询出的结果位置按规则列示方便定位，显示字体、字号、色彩便于识别等等；
   3、标题查询、全文检索、模糊查询、容错查询、多关键字组织查询（空格间格开）等实用的检索方式是否正常？
   4、输入搜索条件的控件风格设计、位置摆放是否醒目便于使用者注意到，有否快照等快捷查看方式等人性化设计？
   四. 兼容性
   1、WINDOWS/LINUX/UNIX等各类操作系统下及各版本条件下的应用
   2、IE/FIREFOX/GOOGLE/360/QQ等各类浏览器下及各版本条件下、各种显示分辨率条件下的应用
   3、SQL/ORACLE/DB2/MYSQL等各类数据库存储情况下的兼容性测试
   4、简体中文、繁体中文、英文等各类语种软件平台下的兼容性测试
   5、IPHONE/IPAD、安卓等各类移动应用平台下的兼容性测试
   6、与各相关的监控程序的兼容性测试，如输入法、杀毒、监控、防火墙等工具同时使用
   五. 安全性
   1、被删除、加密、授权的数据，不允许被SQL注入等攻击方式查出来的，是否有安全控制设计；
   2、录入一些数据库查询的保留字符，如单引号、%等等，造成查询SQL拼接出的语句产生漏洞，如可以查出所有数据等等，这方面要有一些黑客攻击的思想并引入一些工具和技术，如爬网等。
   3、通过白盒测试技术，检查一下在程序设计上是否存在安全方面的隐患；
   4、对涉及国家安全、法律禁止的内容是否进行了相关的过滤和控制；

23、账户登录：

一、功能测试
正常
输入正确的用户名和密码，点击提交按钮，验证是否能正确登录。
登录成功后能否能否跳转到正确的页面
记住用户名的功能
密码是否非明文显示显示，使用星号圆点等符号代替。
牵扯到验证码的，还要考虑文字是否扭曲过度导致辨认难度大，考虑颜色（色盲使 用者），刷新或换一个按钮是否好用
登录页面中的注册、忘记密码，登出用另一帐号登陆等链接是否正确
输入密码的时候，大写键盘开启的时候要有提示信息。
异常：
输入错误的用户名或者密码,验证登录会失败，并且提示相应的错误信息。
登陆失败后，不能记录密码的功能
用户名和密码，如果太短或者太长，应该怎么处理
用户名和密码，中有特殊字符（比如空格），和其他非英文的情况
什么都不输入，点击提交按钮，检查提示信息。
二、界面测试
1.布局是否合理，testbox和按钮是否整齐。
2.testbox和按钮的长度，高度是否符合要求。
3. 界面的设计风格是否与UI的设计风格统一。
4. 界面中的文字简洁易懂，没有错别字。
三、性能测试
1.打开登录页面，需要的时间是否在需求要求的时间内。
2.输入正确的用户名和密码后，检查登录成功跳转到新页面的时间是否在需求要求的时间内。
3.模拟大量用户同时登陆，检查一定压力下能否正常登陆跳转。4.在不同网络（2G/3G/4G/5G）情况下，登录的响应时间,在离线情况下是否支持登录。
四、安全性测试
1.登录成功后生成的Cookie，是否是httponly (否则容易被脚本盗取)。
2.用户名和密码是否通过加密的方式，发送给Web服务器。
3.用户名和密码的验证，应该是用服务器端验证， 而不能单单是在客户端用javascript 验证。
4.用户名和密码的输入框，应该屏蔽SQL注入攻击。
5.用户名和密码的的输入框，应该禁止输入脚本 （防止XSS攻击）。
6.防止暴力破解，检测是否有错误登陆的次数限制
7.是否支持多用户在同一机器上登录。
8.同一用户能否在多台机器上登录。
五、可用性测试

1. 是否可以全用键盘操作，是否有快捷键。
2. 输入用户名，密码后按回车，是否可以登陆。
3. 输入框能否可以以Tab键切换。4. 密码和用户名是否可以粘贴复制。
   六、兼容性测试
   1.不同浏览器下能否显示正常且功能正常（IE,6,7,8,9, Firefox, Chrome, Safari,等）。
   2.同种浏览器不同版本下能否显示正常且功能正常。
   2.不同的平台是否能正常工作，比如Windows, Mac。
   3.移动设备上是否正常工作，比如Iphone, Andriod。
   4.不同的分辨率下显示是否正常。
4. 不同语言环境下，页面的显示是否正确七、场景交互1.来电话了2.正在播放音乐3.前后台的切换

24、假如你是一个玩具公司的质检员，你会怎么在流程控制和用例设计方面去保障玩具的质量。

作为一名玩具公司的质检员，我的工作责任是确保玩具的制造过程中没有问题，并且最终交货的产品质量是高的，安全的。在流程控制和用例设计方面，我会采取以下措施来保证玩具的质量：

1. 流程控制：我会定期检查和评估公司的生产和检测流程，检查是否有任何可能影响产品质量的短板和不足。如果发现有不足，我会建议公司采用最佳做法来解决问题，以确保生产流程的质量和连续性。

2. 用例设计：我会为每种玩具制定一组详细的用例设计，以确保生产过程中每个步骤都得到检查和验证。这些测试用例将覆盖从提供原材料到制造，包装和发货的整个过程。用例将涵盖关键方面，如尺寸，重量，材料组成，产品外观等等，以确保每个产品都符合规范。

3. 样品测试：还会在每个生产周期中从每个批次中选取样品，进行全面的测试和评估。这些测试将涵盖各种方面，如产品质量和安全性，产品的结构完整性和舒适性等等。进行测试的数据将帮助我们确定制造过程中的任何质量问题，并且能够追溯到可能存在的质量问题的原因。

25、对天猫的优惠机制进行测试：小二会在优惠开始之前将优惠策略写入数据库，系统读入缓存中；到优惠生效过程中，你能考虑到的测试点，去保证整个流程运转正确。（两个角度，小二角度；用户角度）

以下示例仅供参考，从小二的角度考虑：

1. 验证小二在写入数据库时，是否正确地写入优惠策略，以及优惠策略是否符合要求，包括但不限于折扣率、满减规则等等。

2. 验证小二的填写策略的过程是否正常，包括但不限于填写策略的UI、填写策略的流程等。

3. 验证优惠策略被写入数据库后，是否能够正确地读取出来，并且被正确地存储到缓存中，如果缓存失效了，能否正确地重新加载。

4. 验证小二在策略生效前是否可以进行修改、删除等操作，并且修改后是否能够正确地封存、终止过期的策略。

5. 在写入优惠策略时，需要考虑并发的情况，例如同时写入相同的策略，需要验证并发的情况下是否能够正常运作，并且写入的数量是否准确。

从用户的角度考虑：

1. 验证用户是否可以正确地获取自己当前适用的优惠策略，在用户购买时是否已经将优惠减免的金额正确地反映。

2. 验证用户是否可以在付款前取消优惠，并且是否可以正确地反映优惠被取消的状态，是否需要重新计算支付金额。

3. 验证用户在购买过程中，如果优惠策略过期或被修改，是否可以正确地通知用户，并且提供恰当的解决方案。

4. 验证用户在编写优惠策略时能够得到明确的说明和帮助，可以了解自己享受的优惠是否合规、是否合理，是否有其他更为优惠的选择。

5. 当出现异常、错误等异常情况时，能否及时调整、处理，避免影响到用户的正常使用。

26、QQ登录的测试用例

27、购物车的测试用例

28、电梯测试用例如何设计