测试分析

最新推荐文章于 2021-10-09 23:15:00 发布

青果HA

最新推荐文章于 2021-10-09 23:15:00 发布

阅读量2.7k

点赞数 3

分类专栏：面试相关

本文链接：https://blog.csdn.net/Strive_0902/article/details/81842579

版权

面试相关专栏收录该内容

35 篇文章 0 订阅

订阅专栏

你用浏览器打开一个网站，却没有按预期看到应有的网页内容。请分析各种可能的原因，如果这些原因表现出来的现象不同，也请描述

人的原因：弄错网址；拼写错误；未打开网络；
本机原因：浏览器版本低不兼容网页；本机防火墙阻止访问；中病毒导致浏览器工作不正常；
服务端原因：服务器宕机；服务器出错；服务器高负载无法及时回应；服务器超负载主动拒绝回应；本机被服务端加入了黑名单；
网络原因：网络不通；网络拥塞；DNS解析失败；DNS解析到错误的IP；
其他环境原因：域名被劫持；访问被黑客攻击；

学校局域网部署了一个图书馆管理系统，该系统架构为，前端页面、静态资源部署在web服务器；逻辑处理部署在应用服务器；数据部署在数据库服务器。某一天该系统图书列表页面打开非常缓慢，耗时超过1分钟，但首页打开正常，试分析该系统可能存在什么问题

应用服务器cpu使用率太高，导致响应太慢;
应用服务器load飙升，导致响应太慢;
应用服务器GC频繁，导致响应太慢;
数据库查询缺少索引，导致响应太慢

网络连接超时设置，可以保护服务端和客户端在弱网环境下的稳定性，下列哪种方法可以验证http协议建立连接过程超时阈值设置的有效性

iptables设置TCP ACK报文丢失，client连接server，是否显示连接超时失败

服务上线部署，需要有详细的操作步骤和对应回滚方案，回归方案能够在上线发生异常情况下使服务回到上线前状态，减少上线损失。以下哪些测试点可以有效验证回滚方案？

配置文件内容能否恢复到上线前;

回滚操作是否产生脏数据;

二进制编译文件能否恢复到上线前;

下游服务启停操作是否对上游无影响

美团有一个API用于创建团购订单，地址如下
https://open.meituan.com/order/createorder?token=1234567890abcdefghijklmnopqrstuvwxyz
其中，token用于验证用户身份
请求方法：POST
参数类型：application/json
参数列表（隐去无关参数）：
{
"dealid": 90,
"quantity": 5
}
传入deal ID（要购买的团购券的ID）和数量后，返回新生成的订单ID（隐去无关参数）。例如：
{
"success": 0, // 正常情况为0
"msg": "", // 正常情况为空
"orderid": 2910100100, // 订单id
}
设计测试用例进行测试，尽可能覆盖的完备。

1、输入合法参数，是否正确的生成订单；

2、输入为空，是否有提示；

3、输入dealid为非数值型，是否有提示；

4、输入dealid不存在时，是否有提示；

5、quantity为0或负数，是否有提示；

6、quantity大于库存，是否有提示；

7、token无效时，是否有提示；

8、输入不是json时，是否有提示；

性能测试：

1、压力测试：系统在极限压力下的处理能力

2、狭义性能测试：验证系统能够达到一定的处理能力

3、并发测试：测试数据库和应用服务器对并发请求的处理

兼容性：

在不同浏览器上测试；在不同系统上测试；

安全性测试：1）sql注入攻击2）token伪造3）大量订单4）deal遍历

功能测试

1. 正向功能；

2. 参数为空；

3. dealid不存在；

4. dealid为非数字的值；

5. quantity为0或负值；

6. quantity大于库存量；

7. token无效

8. 入参不是JSON

性能测试

1. 压力测试，考察系统在极限压力下的处理能力

2. 狭义性能测试，验证系统能够达到一定的处理能力

3. 并发测试，测试数据库和应用服务器对并发请求的处理

安全性测试

1. 伪造token攻击

2. 订单潮水攻击

3. deal遍历攻击

4. SQL注入攻击

加分项订单复用：当同一个用户提交的dealid、quantity相同时，返回的orderID总是一样（没有重复创建订单）

每年的5月17日，点评都会在全国各大城市举办517吃货节优惠活动，如果你来负责手机端517某一个活动的测试任务，你会想到从哪些方面测试，来保证517活动的质量？
此次活动投放首页上”全城好券”活动中的每日优惠页面
1. 用户领取条件：每个商户的券每个用户只能领取一次。
2. 券数目限制：每个商户的每天的券有数目限制。
3. 领券时间限制：只有上午10点开始可以才可以领券

UI界面测试

排版正常，不出现重叠、缺失等现象
图片正常展示，无明显拉伸现象
字体大小样式展示正常，过长截断
点击跳转正常
用户滑动无卡顿
加载更多无重复

功能测试：

账号在登录和非登录状态领券
用户在经纬度缺失时距离显示
商户券领完后，不能重复领。
商户券达到领取上限后，直接下线。
10点之前不能参加抢购；
抢之后『xxx人已抢』的显示数量要增加

兼容性测试：

屏幕大小测试：大屏、小屏手机
系统兼容性测试 ios、android
window ,mac,ipad
分辨率

性能测试：

CPU，内存占用，低配置Android机体验效果
压测对应的后端接口的QPS，预测峰值流量及所对应集群的QPS。制定相应方案。

网络测试：

Wiki测试
3g/4g
弱网络情景

其他：

图片太多，图片不宜太大，以免消耗用户太多流量。
用户数据统计等信息，统计商户曝光率，点击率等信息测试

“招商银行信用卡”微信公众号，新推出一个“好友点击助力瓜分积分”活动，参与活动的用户可以分享活动链接给好友，好友点击完成助力即可获得一次瓜分积分机会。注意：

（1）每个关注公众号的用户，仅可以帮好友助力一次(A帮B助力过后，则不能再帮C助力，A只可帮B助力一次)

（2）未关注公众号的用户，点击他人分享的助力链接后，会先弹出二维码引导用户关注公众号，关注完后自动为该用户助力(若该用户未给他人助力过则助力成功，若助力过则提示助力失败)

我们假定你已经熟悉微信公众号常见的一些基本功能，请从不同角度设计有效合理的测试场景。

功能测试：

（1）未关注公众号的用户点击好友分享链接，关注公众号，点击成功完成助力；再次点击其他好友分的链接，提示“仅能给好友助力一次”，本次助力失败

（2）已关注公众号的用户点击好友分享链接，成功完成助力；再次点击其他好友分的链接，提示“仅能给好友助力一次”，本次助力失败

性能测试：

（1）1w好友并发给1个人助力

（2）1w好友并发给5000好友助力

兼容性测试：不同的平台以及操作系统上都能实现。网页版以及移动端，不同的ios系统，Android系统等均能成功关注公众号完成助力

易用性：公众号中助力的引导明确，助力的步骤和过程简单明了

关于冒烟测试：看软件是否能正常启动，正常关闭，软件打开后，内容显示是否正常

首先，冒烟测试源于硬件测试。想像一下，为了验证一根管子的大概质量，从一头注入烟雾，如果从另一头出来，其余部分没有冒烟，我们就可以基本确认这根管子没有大问题，才能继续下一步细节的测试，包括材料、耐久等。同样的，把这个例子套用到软件系统的测试中，也是相同的道理。

对于软件的冒烟测试，就是对该系统整体重点功能的功能流程测试，要确保通过冒烟测试，系统能够跑通（正常运行）；比如：对于一个登录系统的冒烟测试，我们只需测试输入正确的用户名、密码，验证登录这一个核心功能点，至于输入框、特殊字符等，可以在冒烟测试之后进行。然后，还存在另一种可能发生的情况：一个软件系统存在BUG，在测试人员发现BUG并反馈给开发人员后，开发人员及时修复，再次更新系统代码，这个时候，冒烟测试的重点就要放在更新的这一部分，需要验证该部分内容是否能够融入整个系统之中，不对系统的其他业务造成影响，所以，对于冒烟测试我们可以理解为“宽切浅”。至于网上说冒烟测试就是一袋烟的功夫做完的测试，可能有待完善，因为对于一个大型工程上线前的冒烟测试也是需要一定时间才能够完成的。

冒烟测试的执行对象一般是程序的开发者，可以建议在开发人员的自测报告中加入冒烟测试的情况反馈，因为只有通过冒烟测试才能进行更深入的系统测试，如果连冒烟测试都没有通过的版本，交给测试人员，很有可能因为环境、部署等问题回退。

最后说一下冒烟测试的好处，正确开展冒烟测试可以有效的提高测试效率，节省整体的测试时间，而且有益于执行人对于系统认知的加深，做出更符合需求、更易用的产品。

https://www.cnblogs.com/imyalost/p/5630940.html

https://blog.csdn.net/xiaoxiaxiaen/article/details/77607699

微信朋友圈的设计

结构（s）：组成部分；

功能（f）：是否符合预期，比如显示别人发的朋友圈，比如自己发的朋友圈；

数据（d）：每个功能对应不同的数据，比如只有文字或者只有图片；

接口（f）：朋友圈客户端和服务端的交互接口功能，消息提示、朋友圈点赞功能平台

平台（P）：手机、web、pad是否兼容

操作场景（o）：显示各种消息，对评论回复、看个人朋友圈所有内容、三天可见、半年可见

时间（t）：速度、延迟