• 功能测试：
  • 正确输入、为空输入、字符类型校验、长度校验、密码是否加密显示、大写提示、跳转页面是否成功、登出后用另一个账号登录
• 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. 微信红包怎么测试？

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

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

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

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

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

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

11. 定期存款到期自动转存该怎么测？

• 到期肯定会有边界，所以设计里面可以考虑边界值法。自动转存

12. 存钱该怎么测，用什么测试方法
存钱要分类：活期、零存整取等（具体规则百度下），然后根据每类的业务规则选择合适的用例设计方法。譬如一次最少存入多少？最多一次能存入多少等。

13. 我现在有一个程序，发现在Windows上运行得很慢，怎么判别是程序存在问题还是软件系统存在问题？

• 1、检查系统是否有中毒的特征，如：浏览器窗口连续打开，系统中文件图标改成统一图标，CPU使用率保存90%以上等;
• 2、检查软件/硬件的配置是否符合软件的推荐标准;
• 3、确认当前的系统是否是独立，即没有对外提供什么消耗CPU资源的服务，如：虚拟机运行;
• 4、如果是C/S或者B/S结构的软件，需要检查是不是因为与服务器的连接有问题，或者访问有问题造成的；
• 5、在系统没有任何负载的情况下，查看性能监视器，确认应用程序对CPU/内存的访问情况;

14. 在windows环境下，遇到用杀毒软件都无法杀的病毒除了重作系统应该怎么办，如何关闭后台进程，msn上不了都可能是什么问题，怎样解决。

• 1 对于 病毒 ，可以从以下几个方面进行考虑：
  • 使用命令”msconfig”，开启系统配置实用工具，关闭陌生的启动项，然后重新启动，观察系统的运行情况
  • 使用任务管理器，杀掉不正常的进程，看系统的运行情况。
  • 使用命令“regedit”，开启注册表配置工具，清除注册表中的表项。
  • 如果杀毒工具提供了病毒的标识，可以利用搜索引擎，查找相关的手动删除方法。
  • 利用专杀工具进行清除。
  • 给系统打上相应的补丁。
  • 使用系统还原，还原系统。
• 2 关闭后台进程：
  • 使用“管理工具”中的“服务”，将对应的服务关闭掉。
  • 使用gpedit.msc来对系统进行配置。
  • 使用服务自带的管理工具关闭。
  • 直接在任务管理器重杀死进程。
• 3 MSN的问题：
  • 首先检查网络连接是否正常连通。
  • 检查防火墙规则是否正常，是否禁止了程序或者端口。
  • 帐号是否被他人窃取，并且修改了密码。
  • 根据返回的错误消息，上MSN网站的Messenger子站点，查找相应的帮助，根据帮助的向导解决问题。

15. 给你一个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连接支架访问
  • 后台不能直接进入界面

16. AMT取款
参考：https://blog.csdn.net/dpl12/article/details/104370466

• 01 基本流
  插卡、输入正确密码，输入正确取款金额范围，成功取款并打印凭条，取卡
• 02 备选流
  • 场景2：卡无效账户存在
    退卡成功
  • 场景3：账号不存在
    退卡，结束
  • 场景4：密码错误（不超过3次）
    重新输入密码(不超过3次）
  • 场景5：密码错误（超过3次）
    吞卡
  • 场景6：账号余额不足
    重新输入取款金额
  • 场景7：密码错误(3次以内），但余额不足
    重新输入正确密码（在3次内），重新输入取款金额
  • 场景8：ATM已无现金
    退卡结束
  • 场景9：ATM现金不足
    重新输入取款金额
  • 场景10：密码错误（3次以内），但AMT现金不足
    重新输入正确密码（在3次内），重新输入取款金额
  • 场景11：超过提款额度
    重新输入取款金额
  • 场景12：密码错误（3次以内），但超过提现额度
    重新输入正确密码（在3次内），重新输入取款金额
  • 场景13：密码错误（3次以内），重新输入的取款额度超过提现额度
    重新输入正确密码（在3次内），重新输入取款金额
  • 场景14：密码错误（3次以内），ATM现金不足，重新输入的取款额度超过提款额度
    重新输入正确密码（在3次内），重新输入取款金额
  • 场景15：账号余额不足，重新输入取款余额，ATM现金不足，重新输入的取款额度超过提款额度
    重新输入正确密码（在3次内），重新输入取款金额

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

18. 接口测试怎么测？

• 通过性验证：
  • 首先肯定要保证这个接口功能是好使的，也就是正常的通过性测试，按照接口文档上的参数，正常传入，是否可以返回正确的结果。
• 参数组合：
  • 现在有一个操作商品的接口，有个字段type，传1的时候代表修改商品，商品id、商品名称、价格有一个是必传的，type传2的时候是删除商品，商品id是必传的，这样的，就要测参数组合了，type传1的时候，只传商品名称能不能修改成功，id、名称、价格都传的时候能不能修改成功。
• 接口安全：
  • 1、绕过验证，比如说购买了一个商品，它的价格是300元，那我在提交订单时候，我把这个商品的价格改成3元，后端有没有做验证，更狠点，我把钱改成-3，是不是我的余额还要增加？
  • 2、绕过身份授权 ，比如说修改商品信息接口，那必须得是卖家才能修改，那我传一个普通用户，能不能修改成功，我传一个其他的卖家能不能修改成功
  • 3、参数是否加密，比如说我登陆的接口，用户名和密码是不是加密，如果不加密的话，别人拦截到你的请求，就能获取到你的信息了，加密规则是否容易破解。
  • 4、密码安全规则，密码的复杂程度校验
• 异常验证：
  • 所谓异常验证，也就是我不按照你接口文档上的要求输入参数，来验证接口对异常情况的校验。比如说必填的参数不填，输入整数类型的，传入字符串类型，长度是10的，传11，总之就是你说怎么来，我就不怎么来，其实也就这三种，必传非必传、参数类型、入参长度。
• 性能测试:
  • 接口并发情况，如上面提到的：一个账号，同时（大于2个请求）对最后一个商品下单，或不同账号，对最后一个商品下单
  • 接口响应时间，响应时间太长了，肯定需要优化，一般都是毫秒级别

19如何保证设计用例最大可能覆盖需求？

• 功能
  • 正向流程
  • 逆向流程
• 非功能
  • 性能：cpu、内存、网络、IO、tps、qps、用户数据
  • 兼容性：
    • 操作系统(Android、IOS、windows)、平台类型(网页端、移动端）、web端平台版本(window7、win10）、移动端平台版本、手机品牌(小米、华为、荣耀、vivo、oppo、三星、平台)、手机型号
    • 软件版本
    • 网络：2G、3G、4G、5G、WIFI
  • 安全性
    • 账号、密码加密显示
    • 数据库、服务器日志、前端返回、接口响应个人信息脱敏
    • 金额相关：消费方金额减少、接收方金额增加
    • 双花问题：不能消费两次，以最后一次操作为准
  • 易用性：
    • 前端显示、页面布局、使用习惯
  • 专项测试：
    • 电池耗电量
    • 系统资源消耗分析
    • 卡顿测试
    • 弱网测试
    • 健壮性测试：monkey、maxin
  • 极限条件测试(app)：
    • 网络：弱网、断网、2G、3G条件下
    • 突发事件：接收短信、接听电话、后台退出、关机重启、低电量关机

20 文件下载怎么设计用例？

• 功能
  • 支持当前页面下载，还是新窗口打开另存为。
  • 下载后比对文件，是否和上传时的文件完全一致。
  • 注意文件名称为空、含特殊字符及文件名称较长的文件，下载后的文件是否和上传时的一致。
  • 下载文件过程中断网，等网络恢复，看文件是否继续下载。
  • 下载文件是否支持多个文件同时下载，或同一文件多次下载
  • 下载过程服务器异常（断开连接等），服务器恢复正常是否继续下载
  • 点击下载按钮时是否弹起下载页面弹窗
  • 下载完成在服务器日志、数据库查看文件名、文件大小、文件格式、下载开始时间、下载结束时间等和前端抓包接口响应数据是否一致
  • 下载文件异常性测试，如本地磁盘空间不足
• 文件存储
  • 文件上传到服务器之后，采用的是文件存储 NAS 还是对象存储 OSS
  • 文件上传到服务器之后，是否有做容灾备份
• 安全问题
  • 文件上传到服务器之后，文件名是否做了加密
  • 不具备访问权限的用户是否能够访问
  • 不具备下载权限的用户是否能够下载
• 性能
  • 跳转到下载页面响应时间
  • 弹起保存窗口页面响应时间
  • 单用户下载文件速率，是否符合需求目标。
  • 多用户并发下载文件的速率，是否符合需求目标
  • 下载完成的耗时