测试用例以及相关问题

文章目录

测试相关问题
- 1.测试流程
- 2.测试过程遇到了不能复现的bug的时候应怎么办？
- 3.测试过程中遇到开发不认为是bug的bug你怎么办？
- 4.经典用例设计（纸杯，购物车，电梯，登录框，多部电梯具有联动性，视频播放器测试点，三角形的测试设计点，朋友圈点赞的测试用例的设计点，微信发红包）
- - 一、纸杯
  - 二、购物车
  - 三、电梯
  - 四、登录框
  - 五、多部电梯具有联动性
  - 六、播放器测试的测试点
  - 七、三角形的测试设计点
  - 八、朋友圈点赞的测试用例的设计点
  - 九、微信发红包
- 5.token session cookie 三者的区别？
- 6.性能测试的指标有哪些？
- 7.所在部门有多少人？以及测试如何分工的?
- 8.部门负责人的简称:pm

测试相关问题

1.测试流程

分析需求点
编写测试计划，参考软件需求规格说明书等内容
编写测试用例，会参考需求文档(原型图)、概要设计、详细设计等文档；用例编写完成后进行评审
搭建测试环境，执行预测(冒烟)
出测试报告，对整个测试的过程和版本质量做一个详细的评估。确认是否可以上线。

2.测试过程遇到了不能复现的bug的时候应怎么办？

遇到问题就要提，在提交的Bug描述中需要加上一句话，那就是复现概率，尝试10次，出现1次或者尝试10次，出现5次，开发会根据bug的复现概率，调整改bug的优先级
尽量回想发生问题时的复现步骤，不要漏掉任何一个细节，按照步骤的组合尝试复现
保留发生bug时的log，附加到提交的bug中，希望可以通过log中找到一些蛛丝马迹，或使用录屏工具将操作步骤录下来
与开发人员配合，让开发同学对相应地方的代码进行检查，看一下是否可以通过代码层面检查出问题
在接下来的测试中，时刻保持关注，每次执行同样或者相近的步骤的时候，看下是否能够复现之前的bug通过上述的办法，仍然无法复现，根据bug的优先级，在上线之前对该bug进行处理，严重级别的bug，要召集项目组的成员，集合大家的力量尽可能的复现bug，不严重的bug，也不要关掉，上线后及时的关注用户的使用反馈，如果持续3或者4个版本没有出现，那么可以将bug暂时关掉了，同时关掉的时候要进行评论说明并不是因为修复，而是经过x个版本后不复现了。

3.测试过程中遇到开发不认为是bug的bug你怎么办？

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

4.经典用例设计（纸杯，购物车，电梯，登录框，多部电梯具有联动性，视频播放器测试点，三角形的测试设计点，朋友圈点赞的测试用例的设计点，微信发红包）

一、纸杯

功能：- 是否可以成不同液体（热水冷水固体）
- 纸杯的形状
- 纸杯容量大小
- 纸杯的材质是否环保
- 纸杯是否漏水界面：- 纸杯的颜色
- 纸杯的图案
- 纸杯的logo
- 杯口杯壁是否圆整性能：- 是否容易变形，掉色，保温
- 盛水后多长时间漏水
- 盛热水或者是冷水的时间
- 杯底是否容易脱落
易用:- 杯子尺寸是否合理
- 是否方便握持，携带，运输
- 是否有隔热/防滑措施
- 是否方便清洗，回收
- 是否方便老人小孩使用
安全:- 材质是否无毒，易燃
- 存放其他液体是否会产生化学反应
- 装热水的时候是否会烫伤人
- 长时间放置材质是否会溶解

二、购物车

界面测试：·打开页面后，页面的布局是否合理，显示是否完整；·鼠标浮动在购物车按钮，迷你购物车界面显示是否正常；·不同卖家的商品在不同的table区域显示，区分明显；·页面的tooltips能正常显示；
功能测试：·所有页面链接功能正常，可以点击到正确页面；·页面关联本地软件阿里旺旺的icon点击后，能打开软件；·从商品信息页面添加的商品能显示在购物车中；·购物车页面打开的同时，在其他页面添加了商品，购物车页面刷新后，新的商品能显示；·若未登录，点击购物车，则提示用户输入用户名和密码，或者提示其他的非注册用户购物方式；·商品未勾选的状态下，结算按钮是灰色无法点击的；·勾选商品后，已选商品的总价会显示，结算按钮变高亮可点击工作；·勾选商品，点击结算按钮后，进入确认订单信息页面；·购物车页面中，可以对添加的商品信息做信息的修改，并自动保存成功；·卖家在线的时候，旺旺icon高亮，反之，灰色；·购物车有商品降价或者库存告急的，那么点击对应的tab，降价或者告急商品会归类后显示；·购物车能添加的商品种类是有数量上限的；·不要的商品，可以删除；（其他特有的功能不做赘述，只讨论常见通用功能）
性能测试：·打开购物车页面要多久；可用性测试：·快捷键功能知否支持
兼容测试：·不同浏览器上的测试功能是否正常；·app上测试

三、电梯

功能：按钮功能，开门（运行中按开门键不开门），关门，电梯内按钮功能（电梯按键在按下时是否点亮，按错楼层是否可以取消）
上升，下降（每一层申请是否有效，是否可以正常停靠），超载时是否会忽略其它楼层的上行和下行申请，电梯的两边按钮是否都可以使用
电梯内电话、灯光等性能：反应时间、关门时间、速度(是否造成人体不适）压力：超载，碰撞电梯壁安全：进入电梯喊话，外面是否听到，拨打手机是否有信号；
停电（不会坠落。电梯门可以通过外力打开，紧急电话可用），报警装置（超载），通风状况；
停靠位置，有人扒门（不会强制关门），若有异物阻碍，会停在当前楼层；
监控装置
UI测试：标识的承重和人数，仅提供可到达楼层的按钮，美观程度，光滑程度、形状可用性：按键高度、操作是否方便稳定性：长时间运行情况

四、登录框

一、界面
1、登录界面是否清晰合理美观，无乱码（文字简洁、无错别字）二、功能（主要采用等价类、边界值方法）
1、输入正确的用户名、密码，是否登录成功
2、输入错误的用户名或者密码，登录失败有没有提示（用户名或密码为空）
3、用户名、密码支持的字符类型
4、输完用户名之后按Tab键是否能到输入密码的框，输完密码之后按回车能否登录
5、如果有记住用户名密码的功能，下一次打开页面，是否默认有用户名密码
6、用户名、密码是否大小写敏感
（具体还可以考虑：这个用户名密码是否已注册）三、安全性
1、在登录页面，输入的密码是否隐藏显示
2、多次登录失败，系统会不会阻止后续的尝试以应对暴力破解
3、用户名、密码能否支持复制、黏贴
4、在浏览器中直接输入登录成功后的URL地址，验证是否会重新定向到用户登录界面
5、密码输入框内的密码是否都可以在页面源码模式下被查看四、兼容性
1、不同操作系统上同版本的浏览器能否正常打开登录界面，界面正常
2、相同操作系统的不同浏览器能否正常打开登录界面，界面正常
3、这个登录界面能否在移动手机端正常打开五、性能压力
1、输入正确用户名、密码之后点击登录按钮，直到登录成功打开页面，需要多长时间（小于3秒）
2、多个用户同时进行登录操作，相应登录的时间是否会变长（小于5秒）

五、多部电梯具有联动性

界面测试：
外观（里面、外面）美观性
电梯空间尺寸是否和设计尺寸一致
按钮是否清晰和易懂
显示楼层的显示屏是否安装
是否联系外界的电话、紧急电话
设备检测说明书
安全规范说明书
灯
标识的承重和人数
扶手
镜子
仅提供可到达楼层的按钮
电梯制作的材料功能测试：
测试电梯能否实现正常的上升和下降功能，每层是否都可以停靠。
每层停靠楼层是否与所按的楼层一致
电梯按键在按下时是否点亮按键灯
电梯在每个楼层的上行和下行的申请是否可以有效
电梯满负载的时候，是否会忽略其他楼层外部的上行和下行申请
电梯的两边按钮是否都可以使用，三列按钮。
电梯的楼层选择是否可以取消
电梯门的打开，关闭是否正常关闭（自动关闭）。
报警装置是否可用。（满载）
超重时是否能强制关门
超重时重新挪动一下人员是否可以上下行
与另外一部电梯之间是否协作良好。（算法）
电梯的灯光是否满足看书的要求
联系外界的电话是否可用
通风状况如何，人多的时候是否会很热，通风不畅（排气扇）
电梯里面的摄像头是否可用，拍摄是否清晰
门不夹人
伸手的话，应该不会强制关门
管理员可以和内部人通话
在各种场合下，可以强制开门
运行中时，不能按开门键，不会强制开门
在不同情况下（如：有人挡着、马上关门的时候、停电的时候、没有请求的时候…），一直按开门键和关门键
从电梯外部可以强制开门
不同温度下的测试
进入电梯，拨打手机，是否有信号
进入电梯喊话，外面是否能听到
楼层显示屏显示的楼层、以及电梯运行升降状态是否正确
两台电梯能否同时使用（或停用）
其中一台使用，另一台是否可以停用
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测试步骤地随机测试，在电梯内部和外部均有不同组合申请的情况下，验证楼层停靠是否准确和合理。
电梯的平稳性，是否会上升过快或者下降过快，造成人体不适应反应可靠性：
无任何申请的时候，可以长时间停留在某层，并且门是关闭的
门关上的一刹那出现障碍物。
长期有障碍物在门口堵住，电梯应该也不会关门或上升和下降
同时按关门和开门按钮。
快速交替按关门开门按钮
点击当前楼层号码。
快速点击不同楼层
上升到顶层后，电梯中的原有下楼请求均会被取消
下降到负楼层后，电梯中的原有上楼请求均会被取消
电梯外部同时按上键和下键会怎样。
长按打开按钮，电梯门是否持续打开
突然停电或超载时的情况，电梯（停靠、正在上升、正在下降）不会坠落，电梯门可以通过外力打开，并且紧急电话可用
电梯运行中，申请马上要经过的楼层停靠，电梯应该不会停靠。
在电梯里面蹦跳，电梯不会出现不稳定的情况。
电压不稳定的情况下的电梯运行情况
电梯不能正常工作的时候是否有监控系统自动报警
电梯不能正常工作的时候，是否有流程可以精确的指定到人进行所有故障解决的高效处理易用性：
电梯的按钮的设计符合一般人使用的习惯吗．
按钮是否考虑残疾人和小孩儿
楼层显示屏是否处于电梯的上部，方便别人看到
可维护性
是否有方便维修和维护电梯的工作条件（竖井通道、统一断电等）
电梯的常用配件是否容易更换
电梯的维修成本如何
电梯的安装、维护、测试
超过维修年限，是否可以正常运转

六、播放器测试的测试点

一.功能测试
1.打开，关闭播放器2.播放，暂停，停止播放器3.上一个視频，下一个视频4.音量大小，静音5.最大化，最小化6.播放列表的添加，删除，查看7.播放列表的播放顺序，单循环，多循环，顺序播放，随即播放8.支持的所有播放格式的文件9.能否播放被隐藏的媒体文件10.能否通过网络播放已共享的媒体文件二.易用性测试
11.界面是否方便，整洁12.快捷键是否正确13.菜单是否正确14.图像是否清楚15.拖拽滚动条16.是否支持直接拖动文件到播放器中17.是否具备播放记忆功能18.是否能否自动保存以前的播放列表三.性能测试
19.一次性添加多个文件到播放列表，看播放器的反应时间20.播放大容量的文件，看加载多长时间能正常播放四.兼容性测试
21.播放器是否能在其他平台上正常播放22.播放器是否与其他类型播放器兼容五.安装测试
23.播放器是否安装成功24.播放器是否能自定义安装25.安装过程是否能回到上一步重新安装26.是否能成功卸载27.卸载后要检查安装文件夹是否同时被删除，如果在安装时在注册表中填入了关键字，是否在卸载后进行了删除，如果在安装时增加了服务，是否在卸载后进行了删除，如果在安装时设置了端口好，是否在卸载后对端口号进行了释放28.是否有默认安装29.播放器软件的升级安装30.在播放媒体文件的过程中进行播放器软件的升级31.播放器软件正在使用过程中，进行播放器软件的卸载操作32.播放器软件正在使用过程中，在系统后台删除播放器软件对应的安装目录33.是否能够自动监测到升级版本，提示用户进行安装升级34.安装成功后，检查后台的安装文件夹及相关文件内容是否完整，准确，安装目录是否与用户安装时指定的目录相一致35.安装成功后，如果要向注册表中填入相关的关键字，则要查找注册表信息是否填写完整正确36.安装成功后，如果要创建相关的服务，则要查看是否添加了相关的服务，服务是否默认自动启动37.安装成功后，如果占用了某个端口号，则要查看是否进行了正确的端口号配置（34-36可能不适合于播放器软件的安装，但可以在其他系统安装时作为测试点考虑）六.可靠性测试
38.是否能打开网络共享的文件39.打开不支持的文件，是否有相应提示40.从播放列表中播放不在存在的文件，是否会提示出错41.出错后，是否能再次打开支持的文件42.是否能播放不完整的文件（比如，bt下载示完成）43.若系统没有安装扬声器，是否可以进行播放器软件的使用44.能否同时打开多个播放器45.在文件被播放的同时，能否剪切、删除或移动媒体文件46.在文件被播放的同时，能否修改媒体文件的名称或类型47.如果在播放过程中，异常退出（程序关闭，系统断电或网络故障），是否记录了相关的播放点，在异常排除后，能否从播放点继续播放48.当某个媒体文件出现播放错误后，不影响其他媒体文件的播放49.是否具备自动纠错功能50.在不同客户端机器上，同时播放同一个媒体文件七.文档测试
51.帮助文档是否存在，完整，准确

七、三角形的测试设计点

主要验证点是，设计的测试用例中是否针对：是否是整数，是否满足三个整数，是否符合三角形成立规则，是否考虑了数字0，同一组数字是否考虑了输入顺序等。
可见测试用例设计，主要还是对需求进行拆分，保证每一个条件都尽可能进行了正向和反向验证。

八、朋友圈点赞的测试用例的设计点

主要从界面、功能、兼容性、性能、并发等几个角度进行设计，至于安全性这块，不知道针对这个功能应该如何进行，所以未涉及
主要的测试点在功能测试，尽力覆盖了能想到的常用功能的测试点

九、微信发红包

单个红包：1、红包金额为空、0、0.01、200.00、200.01、199.99、2002、留言输入数字、字母、汉字、特殊字符3、留言长度4、留言复制粘贴5、表情选择收藏表情、其他表情6、删除表情、重新选择表情7、选择支付方式 零钱、银行卡、添加新卡支付。其中钱数<红包钱数、其中钱数=红包钱数、其中钱数>红包钱数8、使用指纹确认付款（正确的、错误的指纹）9、使用密码确认付款（正确的、错误的密码）10、红包成功发送后 相应支付方式中钱数减少（减少金额与红包金额一致）11、接受者能看到红包具体信息，红包金额、留言、表情均能正确显示12、红包被拆开后显示已领取，领取者零钱中增加正确金额，再次领取只能查看红包信息13、发红包者自己领红包14、红包24小时未被领取提示红包被退回，相应支付方式中钱数增加（增加金额与红包金额一致），对方不能领红包群发红包-普通红包：（只写了与单个红包不同的地方）1、红包个数 为空、0、001、100、99、1012、红包拆开每个金额一样 均为发红包时设置的单个金额对应的钱数3、红包被拆时，有相应提示4、发红包者自己领红包5、红包24小时内未被拆完，剩余钱被退回，相应支付方式中钱数增加群发红包-拼手气红包：1、红包总额/红包个数<0.012、红包每个人拆开金额不同，总金额与发红包设置的总额一致3、红包24小时内拆完后显示最佳手气4、红包24小时内未被拆完不显示最佳手气兼容性：安卓、苹果 不同型号版本手机UI测试：界面无错别字，风格统一中断测试：不同应用之间切换、断网、来电、短信、低电量、手机没电网络测试：2g/3g/4g  WiFi 移动联通电信  弱网  无网

5.token session cookie 三者的区别？

1.token令牌，是用户身份的验证方式。最简单的token组成:uid(用户唯一的身份标识)、time（当前时间的时间戳）、sign（签名）。对Token认证的五点认识2.一个Token就是一些信息的集合；在Token中包含足够多的信息，以便在后续请求中减少查询数据库的几率；服务端需要对cookie和HTTP Authrorization Header进行Token信息的检查；基于上一点，你可以用一套token认证代码来面对浏览器类客户端和非浏览器类客户端；因为token是被签名的，所以我们可以认为一个可以解码认证通过的token是由我们系统发放的，其中带的信息是合法有效的；3.session会话，代表服务器与浏览器的一次会话过程，这个过程是连续的，也可以时断时续。cookie中存放着一个sessionID，请求时会发送这个ID；session因为请求（request对象）而产生；session是一个容器，可以存放会话过程中的任何对象；session的创建与使用总是在服务端，浏览器从来都没有得到过session对象；session是一种http存储机制，目的是为武装的http提供持久机制。4.cookie储存在用户本地终端上的数据，服务器生成，发送给浏览器，下次请求统一网站给服务器。5.cookie与session区别cookie数据存放在客户端上，session数据放在服务器上；cookie不是很安全，且保存数据有限；session一定时间内保存在服务器上,当访问增多，占用服务器性能。6.session与token作为身份认证，token安全行比session好；Session 认证只是简单的把User 信息存储到Session 里，因为SID 的不可预测性，暂且认为是安全的。这是一种认证手段。 而Token ，如果指的是OAuth Token 或类似的机制的话，提供的是 认证 和 授权 ，认证是针对用户，授权是针对App 。其目的是让 某App有权利访问 某用户 的信息。7.token与cookieCookie是不允许垮域访问的，但是token是支持的， 前提是传输的用户认证信息通过HTTP头传输；token就是令牌，比如你授权（登录）一个程序时，他就是个依据，判断你是否已经授权该软件；cookie就是写在客户端的一个txt文件，里面包括你登录信息之类的，这样你下次在登录某个网站，就会自动调用cookie自动登录用户名；session和cookie差不多，只是session是写在服务器端的文件，也需要在客户端写入cookie文件，但是文件里是你的浏览器编号.Session的状态是存储在服务器端，客户端只有session id；而Token的状态是存储在客户端。

6.性能测试的指标有哪些？

资源使用率；cpu；内存；io；70-75%；TPS；响应时间；2-5-8；电压；电流的损耗；FTP;响应成功率。

7.所在部门有多少人？以及测试如何分工的?

项目组；前端；后台；移动端；测试

集体测试
按测试内容分工
按测试流程划分
按项目模块划分
按照测试类型分工

8.部门负责人的简称:pm

测试用例以及相关问题相关推荐

测试用例-其他相关知识
前后用了不少的篇幅来谈测试用例,包括它的方法.编写原则与标准. 本篇文章来分享关于测试用例的剩余基础知识. 测试用例级别划分描述此部分内容时,以淘宝作为参考对象. 1.极为重要这一级别测试用例要重 ...
测试用例编写注意事项
1)测试用例是否按照公司定义的模板进行编写的: 2)测试用例的本身的描述是否清晰,是否存在二义性: 3)测试用例内容是否正确,是否与需求目标相一致: 4)测试用例的期望结果是否确定.唯一的: 5)操作 ...
汇智动力软件测试问题,汇智动力—测试工程师都是怎么写测试用例的？
一.测试用例管理测试用例设计活动开展前,测试工程师根据测试管理需要,制定测试用例管理相关制度及流程,便于指导后续的测试用例设计活动.测试用例管理活动一般包括3个部分: 1.测试用例属性管理测试用例 ...
Selenium+python怎么搭建自动化测试框架、执行自动化测试用例、生成自动化测试报告、发送测试报告邮件
目录一.项目结构介绍 1.mztestpro测试项目 2.bbs目录 3.test_case 二.编写公共模块三.编写Page Object 四.编写测试用例五.执行测试用例小结: 本人在网上 ...
一个好的测试用例怎么写？我来告诉你
目录前言那一个"好的"测试用例必须具备哪些特征? 如何写好测试用例做好需求分析提前制定好对应的测试用例模板总结前言对于软件测试人员来说,有几大核心能力: 测试策略设计 ...
【测试用例评审标准】
测试用例评审标准目的范围评审分类评审内容评审方式评审结束标准目的 1.目的为用例评审提供一个参考标准,测试用例评审的目的在于查漏补缺,保证评审的覆盖率和有效性. 范围 2.范围本文档 ...
软件测试-工作流程（需求分析评审、测试计划、测试用例、用例评审、执行测试、跟踪定位bug、测试报告、缺陷报告）
一.需求分析.评审 (1)需求分析对要解决的问题进行详细的分析,弄清楚问题的要求,包括需要输入什么数据,要得到什么结果,最后应输出什么. ①如何做需求分析? 通读需求,对需求有个大致的了解,比如: ...
测试用例编写及用例评审方法
编写测试用例是测试人员的基本功,可是在学校的时候我们好像也没有相应的课程来教我们相应的设计方法.后来我们从网上或是一些软件测试相关的书上会看到不少介绍编写测试用例的方法,如:等价类划分,边界值分析法, ...
Google Test(GTest)使用方法和源码解析——模板类测试技术分析和应用
写C++难免会遇到模板问题,如果要针对一个模板类进行测试,似乎之前博文中介绍的方式只能傻乎乎的一个一个特化类型后再进行测试.其实GTest提供了两种测试模板类的方法,本文我们将介绍方法的使用,并分析其 ...
Android开源项目分类汇总-转载
太长了,还是转载吧... 今天在看博客的时候,无意中发现了@Trinea在GitHub上的一个项目Android开源项目分类汇总,由于类容太多了,我没有一个个完整地看完,但是里面介绍的开源项目都非常有 ...