标签：组合 权限设置 内容 环境 界面 数据库 平台 com 资源
目录
1、App测试和Web测试的区别？
2、什么是HTTP请求，HTTP请求方式有哪些？
3、Get请求与Post请求的区别？
4、常用的测试用例设计方法？
5、测试过程中遇到一个bug，开发不认为是bug如何解决？
6、微信朋友圈点赞功能如何设计测试用例？
7、如果在购物平台上选购了物品，并且成功支付，但在“我的订单”中没有查到该笔订单，此时怎么处理？
1、App测试和Web测试的区别？
App测试与Web测试从功能测试和整体流程角度来讲，几乎没有什么区别，都是点点点的测试。
Web测试，包含了UI测试、链接测试、搜索测试、表单测试、输入域测试、数据交互、兼容性测试、安全性测试、性能测试等等很多方面。而App测试，是基于客户端进行测试，测试人员的手机型号不同、版本不同、测试环境不同，涉及到的兼容性问题会有很多。
系统架构：Web测试一般是B/S架构，只要更新了服务器端，客户端就会同步更新。而且客户端能保证每位用户的客户端完全一致。但是App端一般是C/S架构，除非用户更新客户端，否则无法保证软件在每个人手机中的一致性。如果在App下修改了服务端，就意味着又需要进行回归测试。
性能测试：Web测试比较关注网页的响应时间，而App除了关注在流畅网络下的响应时间，还需要关心流量、电量、CPU、GPU、Memory等等因素。
兼容性测试：Web端的测试更倾向于浏览器、电脑硬件配置以及电脑系统方向的兼容，不过一般还是以主流的浏览器为主。而App的测试则必须依赖移动端的设备：手机、平板等，不仅要看设备型号，还要看设备系统：Android、iOS、鸿蒙。
App专项测试：异常场景的考虑以及弱网测试。比如：中断，来电，短信，关机，重启等。而弱网测试是App测试中必须执行的一项测试。包括弱网和网络切换，需要测试弱网时的用户体验问题，提示语和等待页面的设置，回退和刷新是否会造成二次提交，以及延时的处理机制等。
针对App产品性质的测试内容，绝大多数用户使用的都是触屏手机，所以测试的时候还要注意手势，横竖屏切换，多点触控，功能触发区域等测试。
Web测试是针对浏览器，无需考虑安装卸载问题。而App是客户端，需要测试安装卸载和更新的情况。除了常规的操作还要考虑到异常场景。比如说：安装时的中断、弱网、安装后删除文件，强制更新与非强制更新、断点续传、弱网，卸载后删除App相关的文件等等。
2、什么是HTTP请求，HTTP请求方式有哪些？
HTTP，即超文本传输协议，是HyperText Transfer Protocol的缩写。
浏览网页时在浏览器地址栏中输入的URL前面都是以"http://"开始的。
HTTP定义了信息如何被格式化、如何被传输，以及在各种命令下服务器和浏览器所采取的响应。
HTTP请求方式：GET、POST、PUT、HEAD、DELETE、OPTIONS、TRACE、CONNECT
3、Get请求与Post请求的区别？
Get，获取资源，Get方法一般用来从服务器上获取资源的方法。服务器端接到Get请求后，就会明白客户端是要从服务器端获取相应的资源，然后就会根据请求报文中相应的参数，将需要的资源返回给客户端。使用Get方式的请求，传输的参数是拼接在URL上的。
Post，数据提交，Post方法一般用于表单提交，将客户端的数据塞到请求体中发送给服务器端。
Get和Post区别：
1、Get请求无消息体，只能携带少量数据；Post请求有消息体，可以携带大量数据。
2、Get请求将数据放在URL地址中；Post请求将数据放在消息体中。
3、Get请求提交的数据放置在HTTP请求地址中，而Post提交的数据则放在实体数据中；Get方式提交的数据最多只能有1024字节，而Post则没有此限制。
4、常用的测试用例设计方法？
等价类划分法：等价类划分主要适用于单个输入条件，输入为数值型的情况，如果输入规定了输入区间，可划分出一个有效等价类，两个无效等价类；如果输入只规定了输入范围，可划分出一个有效等价类，一个无效等价类。有效等价类：有意义的合理的正确输入；无效等价类：非法的错误的异常的输入。
边界值分析法：边界值方法也是适用于单个输入条件的情况，输入类型可以数值、字符等，要测试的边界包括上点、下点、离点。
相关术语：上点：边界上的点叫做上点；离点：离边界最近的点叫做离点（如果是闭区间，离点落在边界外；如果是开区间，离点落在边界内）；内点：边界内任意一个点叫做内点。
因果图法：如果输入之间有关系，我们在测试时必须考虑输入条件的各种组合，那么可以考虑使用一种适合于描述对于多种条件的组合，相应产生多个动作的形式来设计测试用例，这就需要利用因果图。优点：因果图方法最终生成的就是判定表。它适合于检查程序输入条件的各种组合情况。
错误推测法：错误推测法主要是测试设计人员的测试经验相关，测试经验不同，设计出来的测试用例也区别很大。
判定表驱动法：判定表适合于解决多个逻辑条件的组合。将各种逻辑的组合罗列出来，避免遗漏。不能表达重复的操作。判定表包括条件桩、条件项、动作桩、动作项。
正交法：当输入条件很多时，因果图等设计方法设计出来的用例数往往多的惊人，用正交法可有效减少用例数。正交法的核心思想是从大量测试数据中选取有代表性的点来测试，从而减少测试用例数。
功能图法：功能图法适合于用来设计程序的控制结构的测试用例。有顺序、选择、重复三种控制结构。
场景法：场景法特别适用于控制流清晰的系统。测试过程中可以针对不同的场景设计测试用例。
5、测试过程中遇到一个bug，开发不认为是bug如何解决？
该问题是面试时常见问题，没有固定答案，但是该问题能够反映出测试人员在发现问题后，如何解决问题的能力，能够体现出候选人的主动解决问题的能力和思路，作为一名测试人员，发现并主动解决问题最为关键，这里列出几点，便于参考：
首先分析下到底会有哪些原因会导致开发不修改bug：
1、开发与测试对bug的定义理解不一致产生的问题，例如暴力操作、非常规操作出现的问题、问题路径深、服务器返回的数据不规范、竞品同样有的问题、个别机型问题等情况，开发可能会不愿意修改。
2、工作流程方面的原因，例如开发有更高优先级的任务没有时间修改、上线时间紧急，来不及修改、开发不关注名下的bug、开发认为目前的实现比产品需求好等情况。
3、当然还有个人能力原因，例如找不到好的解决方案、影响范围大、找不到bug原因，没有解决方案、技术实现难，不知道怎么修改等等原因。
4、另外还有一些不可抗力的客观因素，例如系统问题，第三方应用问题等等。
我们逐条分析并列出简单的解决方案：
1、针对路径较深的bug，测试在推动开发修复bug时，需要注意以下几点：
1）从用户的角度分析问题的严重性，分析用户的遇到此问题的概率，引导开发站在用户角度去思考，从而使开发意识到问题的严重性。
2）可以和开发人员列举一个之前的类似问题，为开发提供参考。
3）产品是负责这个软件的人员，当测试与开发意见无法达成一致时，不要因为无法推动开发修改而放弃，一定要找产品确认，最终的决定权交给产品人员。
2、上线时间紧张，开发来不及修改了，这个时候测试应该分析问题的严重性，和产品人员商议是否需要修改。
3、修改bug改动较大，影响范围广，没有最优的解决方案等情况在项目即将上线的节点比较忌讳这种事情的发生。面对这种情况，建议开发人员做调研工作，请教其他的同事，或者组织一个临时会议，集众人之力研究好的修改方案。
4、第三方应用问题，开发无法修改。确认原因之后需要找相关的工作人员，例如产品，联系第三方工作人员，反馈问题，尽量推动应用解决问题。
bug修不修，测试应该有一个自己的原则，同时也要权衡利弊。不能因为推不动开发，就放弃，由着bug上线，也不能揪着一个小bug不放，影响上线时间。
6、微信朋友圈点赞功能如何设计测试用例？
1、首先检查朋友圈可见权限设置，针对不同的权限、好友关系设置哪些好友可见
2、设置单个好友可见时，发送一条朋友圈，对方好友是否可见
3、可见之后是否有可展开的操作栏（其中包括点赞和评论）
4、多次点击后操作栏是否能够重复展开或退回
5、点赞功能：UI检查，是否有点赞图标，点赞提示，评论图标，评论提示
6、点击点赞图标后，图标是否有点赞成功提示
7、点赞成功后点赞提示是否变为取消点赞
8、点赞成功后是否在该条朋友圈下有点赞人姓名及图标
9、点赞成功后，是否在被点赞人朋友圈处出现被点赞数统计提示
10、被点赞人点击被点赞的提示后，页面是否跳转至被点赞朋友圈处，并显示已点赞的好友图标
11、设置多个好友可见时，重复点赞步骤后，被点赞人查看个人朋友圈，是否能够展示所有点赞人的图标，统计数量
12、若多个好友同时点赞，被点赞人收到赞时页面展示是否按照点赞时顺序排序
13、多个人同时点赞时，顺序如何排序
14、若其余几位点赞人之间不互为好友关系，是否能够看到对方点赞情况
15、若有个别人员是好友关系，能否通过点赞的头像进入对方信息
16、点赞之后该条赞能否一直保持
17、若该条朋友圈被删除，点赞的讯息是否也被删除
18、取消点赞，只能对已点赞的朋友圈进行取消点赞
19、在已点赞的朋友圈下点击操作栏，是否弹出取消点赞的图表及提示
20、点击取消后是否提示已取消点赞
21、取消的点赞后是否可以再次点赞
22、取消点赞后是否会通知被点赞人
23、设置朋友圈可见限制，当被点赞人收获很多赞之后，关闭朋友圈可见，那么被点赞人是否能够看到自己收获点赞统计，其点赞好友是否能够看到已点赞的信息
7、如果在购物平台上选购了物品，并且成功支付，但在“我的订单”中没有查到该笔订单，此时怎么处理？
测试人员发现问题后，先确认该问题是否满足需求，若在需求要求下，则：
1、重现问题：如果是测试环境，可以再做一笔订单，详细记录该笔订单讯息，检查该问题是否为偶发性问题，此处分两种情况：
1）若该笔订单能够查到，则需判断，没有找到订单的那笔有可能是偶发现象，需明确记录。
2）若该笔订单还是无法找到，则需确定是前端还是后端问题。
2、排查问题：若为Web类测试，通过开发者工具查看界面返回结果，若“我的订单”中有返回值，但在页面中没有展示，需找前端同事确认是否是做数据处理时没有展示结果；若“我的订单”中没有返回值，有可能是数据没有传给前端，需确认是否是接口没有返回或数据传输丢失。此时可以通过检查数据库对应表格、或者用抓包工具检查接口是否报错。若为App类测试，通过抓包工具检查接口返回，同时检查数据库中对应表，是否有存储该笔数据。
3、确认是前端或后端问题后，可以截图发送给对应同事确认问题，并将该问题提交至缺陷管理工具中，并及时跟踪问题。若问题较严重并短期内无法解决，需及时与负责人、项目经理联系，及时汇报该问题。
4、若该问题为偶发问题，需记录该笔订单详细情况，并在后期测试中重点关注，若经过几个迭代后该问题没有再次出现，则可降低该问题等级，但仍需留意。
标签：组合 权限设置 内容 环境 界面 数据库 平台 com 资源
原文地址：https://www.cnblogs.com/alltests/p/14985302.html
