【功能测试面试题】
面试题：
参考文献
难忘的bug：
SG站点detailAddress字段是否必填有特殊逻辑，研测不清楚这个逻辑（对业务了解不深入），线上验证时随机选择postcode保存地址，未遇到页面多出detail字段场景
测试环境：两个需求分支同时部署，一个分支被覆盖，没问题
线上环境：只上线一个分支，逻辑有问题
Portal 印尼后台页面白屏-20220915
pop地址写死，本托的美国地址前端少传一个协议参数：
http和https的区别：
http：超文本传输协议，被用于在web浏览器和网站服务器之间传递信息，
http：以明文方式发送内容，不提供任何方式的数据加密
https：应用层协议，为了数据传输的安全，https在http的基础上加入了ssl协议
● http是不安全的明文传输，而https是安全的加密传输
● http端口号是80，而https的端口号是443
● http和https工作于应用层，ssl在传输层之上
● http无法验证身份，而依赖于ssl证书的https可验证服务器身份
● http无需证书，而https需要ssl证书
cookie和session的区别
cookie --客户端会话技术 cookie 保存在客户端，携带cookie 请求服务器
session – 服务端会话技术 sessionID 保存在服务端，携带sessionID 请求服务器
token – 令牌token保存在客户端 携带token请求服务器
常见响应状态码
2xx 成功
200 ok，成功
3xx 重定向
301 永久重定向
302 临时重定向
4xx 客户端错误
400 bad request，请求报文存在语法错误
401 unauthorized，未经过身份认证
403 forbidden，表示对请求资源的访问被服务器拒绝
404，资源不存在
5xx 服务器错误
500 internal sever error，表示服务器端在执行请求时发生错误
503 service unavailable，表示无法处理请求
get请求和post请求的区别
get请求一般从服务器上获取资源、post请求一般用于表单提交，将客户端的数据塞到请求题中发送给服务器
get请求无消息体，只能携带少量参数，post请求有消息体，可以携带大量的参数
get请求传输的参数是拼接在url上，post请求放到请求体中
兼容性测试
app：
操作系统
机型
品牌
分辨率
弱网
web：
操作系统
浏览器：谷歌、火狐
B/S和C/S的优缺点
B/S优点：
● 分布性：可以随时进行查询、浏览等业务
● 业务扩展方便：增加网页即可增加服务器功能
● 维护简单方便：改变网页，即可实现所有用户同步更新
● 开发简单，共享性强，成本低，数据可以持久存储在云端而不必担心数据的丢失。
● B/S架构的维护和升级都非常容易。只要更改页面内容或者增减页面即可，客户端几乎是零维护，只需要维护好服务器。所以相对来说更简易，方便。由于B/S可以随时随地的访问，所以极易扩展。
C/S缺点：
- 对客户端硬件要求高
- 安全性差：建立在广域网上，面对不可知人群
- 扩展性差、维护成本高，更新需要所有客户端都更新
- 跨平台性不好，针对不同的操作系统需要不同的客户端
- 软件维护也比较麻烦，需要专业人士进行维护
C/S优点： - 可扩展性：CS架构可以轻松地扩展，因为服务器可以添加更多的资源来处理更多的客户端请求。
- 安全性：CS架构可以提供更高的安全性，因为服务器可以控制客户端的访问权限和数据访问。
- C/S架构建立在局域网之上，面向比较固定的用户，对安全的要求较高。
- 可维护性：CS架构可以更容易地进行维护和更新，因为服务器可以集中管理和维护应用程序。
- 可靠性：CS架构可以提供更高的可靠性，因为服务器可以处理客户端请求并提供稳定的服务。
- C/S架构能够实现单一的复杂功能，如财政管理等，所以现在大多数比较大型的ERP系统仍是C/S架构，B/S架构的界面比较通用，所能处理的逻辑事务较少，所以功能较弱。
C/S缺点：
● 单点故障：CS架构存在单点故障的风险，如果服务器出现故障，整个应用程序将无法正常工作。
● 成本：CS架构需要更多的硬件和软件资源，因此成本可能会更高。
复杂性：CS架构可能会更加复杂，因为需要处理客户端和服务器之间的通信和数据传输。
延迟：CS架构可能会引入延迟，因为客户端需要向服务器发送请求并等待响应。
● 可伸缩性：CS架构的可伸缩性可能会受到限制，因为服务器可能会成为瓶颈，无法处理更多的客户端请求。
6、维护、升级以及扩展
C/S架构一旦有业务的变更或要升级，客户端界面就要重新设计，需要投入大量的人力物力。。用户扩展也比较麻烦，需要安装客户端，对软硬件要求高。B/S架构的维护和升级都非常容易。
linux命令
#查看系统进程
ps -aux | grep bin
#强制关闭对应的进程
-kill -9 进程号
#查看特定进程的端口信息
netstat -anptu | grep mysql
cat
用于查看整个日志文件的内容：
查看日志文件的全部内容
cat ./app.log
tail
用于查看日志文件的末尾部分，常用于实时监控日志更新，常用参数包括-f（跟踪模式），-n（显示行数，默认10行）:
动态查看实时输出的日志信息
tail -f ./app.log
查看日志文件的最后20行
tail -n 20 ./app.log
动态查看包含关键字的日志
tail -f ./app.log | grep “cafehaus”
head
与tail相反，用于查看文件的前若干行，常用参数包括-n（显示行数，默认10行）：
查看日志文件的前20行
head -n 20 ./app.log
less
用于分页查看长文本文件，常用参数包括-N（显示行号，将在浏览文件时显示行号），less命令可以在查看文件内容时滚动屏幕，而且还支持在文件中查找内容，所以也常用来查看日志：
分页查看，可以通过键盘上上下箭头翻页
less ./app.log
less 提供了强大的搜索功能，可以让我们在打开的文件中搜索指定的字符。输入上面的查看命令后，只需按下键盘上的 /，接着再输入关键词并按回车，就可以高亮显示向下搜索出包含关键词的日志行（如果要向上搜索 / 就换成 ?）。
输入 G 移动到最后一行，输入 g 移动到第一行，输入 q 可以退出 less 命令。
grep
用于在日志文件中搜索特定的模式或字符串，一般会通过管道符号 ｜ 来配合上面的其他命令一块使用：
查看整个日志中包含关键字的日志内容
cat ./app.log | grep “cafehaus”
通过管道符 | 和 grep 过滤数据，–color 可以高亮关键字
less app.log | grep ‘1345102704’ | grep ‘zhou’ --color
直接通过绝对路径，联合查询，grep -v 反向过滤
grep ‘1345102704’ /data/cafe-user/log/cafe-user.log | grep -v ‘zhou’ | tail -n 10
平时用得比较多的也就 tail、less 和 grep，实际用法自己去开发服务器上跟着示例敲两遍也就会用了，所以查看日志其实并没有多高深，本质跟我们平时在电脑上用其他软件打开一个文件来查看一样，只不过服务器上我们需要敲对应的命令才能来完成同样的操作。
因为日志文件本质也就是一个文本文件，所以上面的命令对于 .txt 文本文件也是同样适用的。
测试时间比较紧张，如何保证测试质量（高频）
（1）测试尽量提前介入，提前开展工作
（2）要求开发自测，提高提测质量
（3）对于重复执行的回归测试，如果可以的话，使用技术手段做成自动
化，提高测试效率
（4）根据模块和功能的重要性和优先级，合理安排测试顺序
（5）有必要的话，向领导申请更多的测试资源和人力
（6）在必要的话，通过加班来追赶下进度
线上出现bug怎么办（高频）
根据之前的一些经验来看，首先和开发一起初步评估bug的严重程度和产生原因。
如果是出现了影响面比较大的功能性问题，且暂时不好定位具体原因，首先考虑是做代码回滚，恢复到上一个稳定版本。然后在测试环境进行复测，并定位问题原因。
如果能快速定位问题原因，开发会做紧急修复，测试通过后会申请紧急上线。
如果是性能方面的问题，一般会进行扩容，或者重启尝试解决，然后开发会做进一步问题定位和优化。如果是不太严重的问题，通常会放在下一个版本解决。
最后，线上bug解决后，要做问题复盘，将整个过程记录下来并进行相关分析总结，避免后续出现类似问题。
项目快上线了突然发现了一个bug怎么处理（高频）
首先和开发、产品一起评估下这个bug的严重程度和影响范围。
如果是比较轻微的bug，可以考虑先上线，在后续迭代版本中修复；
如果是比较严重的bug，找开发沟通下，看看能不能快速修复，并且有足够的时间去做下测试；
如果时间不足了，那就得跟相关人员沟通下，是不是先延期上线，毕竟强行上线后可能会造成严重的后果。
需求评审的时候测试人员主要干什么（中频）
理解功能需求，评估测试时间，并对不合理需求提出建议
如果让你单独负责一个项目，需要注意哪些事项（中频）
（1） 评估项目的测试范围和测试周期，是否能单独完成。
（2）做好测试策略和计划安排，尽量保证每个环节按时完成
（3）如果白己解决不了问题，要及时向外抛出，暴露风险，寻求帮助
（4）尽量采用一些技术手段，提升测试效率
（5）对用例设置好优先级，按照优先级去执行
（6） 及时对bug进行追踪，推动开发尽快解决bug
（7） 把控好上线标准，测试报告中标明上线风险
项目总结和复盘包括哪些内容（中频）
（1） 测试计划和实际测试周期
（2） 测试过程中的相关数据（用例数量、bug数量等）
（3） bug总结与分析（bug的分类，产生的原因）
（4） 有没有影响进度的bug
（5） 有没有遗留问题
（6）相关问题的改进方案，指定到人去落实
开发提测是怎么提的，用什么形式？（中频）
我们公司的项目都是用禅道管理的，开发提测时，禅道会自动给我们发邮件，邮件里有需求的信息，测试的地址等
项目里的bug都有哪些类型，哪些地方容易出bug（中频）
bug的类型：主要是代码逻辑错误、配置错误等
哪些地方容易出bug：参数校验、边界条件、复杂的逻辑、以及一些异常的业务场景没考虑周全
有过线上bug的经历吗？什么情况下会造成漏测（中频）
基本上我所测试的，没有出现过PO和 P1级别的BUG。
偶有一些很小的问题，主要的原因都是兼容性方面。特别
是安卓手机，它的碎片化太严重。
那我主要说一下常见的漏测bug的原因：
需求规格不明确，导致测试用例编写过于粗略。
需求规格变更，测试用例未及时更新测试用例覆盖不全面，
场景出现遗漏测试过程中未严格按照测试用例执行
测试时间不充足，导致一些功能点在测试过程中被忽略
测试环境或测试数据受限，导致缺陷漏测
开发人员修复其他bug时引入的新BUG。
项目选代间隙，都在做什么事情？（低频题目）
（1） 新需求的用例编写
（2）并行测其他的项目
做过交叉测试吗？怎么做的？（低频题目）
一般比较大的项目，在时间充裕的情况下，会在测试后期进行交叉测试。交叉测试就是组长会安排大家交换各自的测试模块，毕竟白己老测自己的模块，可能会存在一些思维定势，通过交叉测试，可能会发现一些新问题。
B/S和C/S的优缺点
B/S优点：
1、分布性：可以随时进行查询、浏览等业务
2、业务扩展方便：增加网页即可增加服务器功能
3、维护简单方便：改变网页，即可实现所有用户同步更新
4、开发简单，共享性强，成本低，数据可以持久存储在云端而不必担心数据的丢失。
B/S缺点：
- B/S架构相应速度慢，主要的重任在数据库服务器身上，
C/S优点： - 可扩展性：CS架构可以轻松地扩展，因为服务器可以添加更多的资源来处理更多的客户端请求。
- 安全性：CS架构可以提供更高的安全性，因为服务器可以控制客户端的访问权限和数据访问。
- 可维护性：CS架构可以更容易地进行维护和更新，因为服务器可以集中管理和维护应用程序。
- 可靠性：CS架构可以提供更高的可靠性，因为服务器可以处理客户端请求并提供稳定的服务。
C/S缺点： - 对客户端硬件要求高
- 维护成本高，更新需要所有客户端都更新
- 跨平台性不好，针对不同的操作系统需要不同的客户端
缺点：
单点故障：CS架构存在单点故障的风险，如果服务器出现故障，整个应用程序将无法正常工作。
成本：CS架构需要更多的硬件和软件资源，因此成本可能会更高。
复杂性：CS架构可能会更加复杂，因为需要处理客户端和服务器之间的通信和数据传输。
延迟：CS架构可能会引入延迟，因为客户端需要向服务器发送请求并等待响应。
可伸缩性：CS架构的可伸缩性可能会受到限制，因为服务器可能会成为瓶颈，无法处理更多的客户端请求。
测试用例设计方法
测试用例设计是软件测试中的重要环节，以下是几种常见的测试用例设计方法：
- 等价类划分法
原理
● 把程序的输入域划分成若干个等价类，每个等价类代表输入域中的一部分，这些部分具有相似的特性。在设计测试用例时，从每个等价类中选取少量有代表性的数据作为测试用例，从而减少测试用例的数量，提高测试效率。
● 等价类分为有效等价类和无效等价类。有效等价类是符合程序输入要求的输入数据集合，无效等价类是不符合程序输入要求的输入数据集合。
举例
● 假设一个登录系统，用户名长度要求在6 - 18个字符之间。
● 有效等价类可以划分为：用户名长度为6 - 18个字符（例如用户名为“abcdef”）。
● 无效等价类可以划分为：用户名长度小于6个字符（例如“abc”）、用户名长度大于18个字符（例如“abcdefghijklmnopqrs”）。
优点
● 能够系统地从大量可能的输入数据中选取测试用例，避免盲目性，提高测试用例的代表性。
● 可以发现程序对不同等价类输入数据的处理是否正确，有助于发现程序中可能存在的边界问题和逻辑错误。
缺点
● 对于复杂的输入条件，划分等价类可能会比较困难，需要仔细分析输入条件之间的关系，否则可能会遗漏一些重要的等价类。
● 不能完全保证覆盖所有可能的输入情况，对于一些特殊情况可能无法通过等价类划分来发现。 - 边界值分析法
原理
● 对输入或输出的边界值进行测试的一种黑盒测试方法。边界值是指输入或输出等价类的边界，通常包括最小值、最大值、边界内的值和边界外的值等。
● 通过测试边界值，可以检查程序在边界情况下的处理能力，发现程序在边界附近的错误。
举例
● 还是刚才的登录系统，密码长度要求在8 - 16个字符之间。
● 边界值可以选取：密码长度为7（边界外）、8（边界内）、16（边界内）、17（边界外）。
优点
● 边界值是错误的高发区域，通过边界值测试可以有效地发现程序在边界情况下的问题。
● 与等价类划分法相结合使用效果更好，可以更全面地覆盖输入数据。
缺点
● 需要准确地确定边界值，对于一些复杂的输入条件，确定边界值可能会比较困难。
● 有时边界值测试可能会受到其他输入条件的限制，需要综合考虑多个输入条件之间的关系。 - 因果图法
原理
● 通过因果图来表示输入条件之间的因果关系，然后根据因果图设计测试用例。
● 因果图是一种图形化的表示方法，能够清晰地展示输入条件之间的逻辑关系，如与、或、非、异或等逻辑关系。
举例
● 一个简单的文件上传系统，要求文件大小不超过10MB，文件格式为jpg、png、gif。
● 因果图可以表示为：文件大小≤10MB（条件1）和文件格式为jpg、png、gif（条件2）→文件上传成功（结果）。
● 根据因果图可以设计测试用例，如文件大小为5MB且格式为jpg（满足条件1和条件2）、文件大小为15MB且格式为jpg（不满足条件1但满足条件2）等。
优点
● 能够清晰地表示输入条件之间的逻辑关系，有助于发现程序中可能存在的逻辑错误。
● 可以系统地设计测试用例，避免遗漏一些重要的测试情况。
缺点
● 对于复杂的系统，因果图可能会变得非常复杂，难以绘制和理解。
● 需要对输入条件之间的逻辑关系有深入的理解，否则可能会绘制错误的因果图。 - 场景法
原理
● 通过描述系统的使用场景来设计测试用例。一个场景通常包括一系列的操作步骤和输入数据，以及对应的预期结果。
● 场景法可以分为基本流和备选流。基本流是系统正常运行时的操作流程，备选流是系统在异常情况下或者用户进行特殊操作时的操作流程。
举例
● 一个在线购物系统，基本流可以是：用户登录（步骤1）→搜索商品（步骤2）→添加商品到购物车（步骤3）→结算（步骤4）→支付成功（步骤5）。
● 备选流可以是：用户登录失败（步骤1失败）→重新登录（步骤1）→搜索商品（步骤2）→添加商品到购物车（步骤3）→结算（步骤4）→支付失败（步骤5失败）→重新支付（步骤5）。
优点
● 能够从用户的角度出发，模拟真实的使用场景，发现程序在实际使用过程中可能出现的问题。
● 可以全面地测试系统的功能和流程，包括正常流程和异常流程。
缺点
● 需要对系统的业务流程有深入的了解，否则可能会遗漏一些重要的场景。
● 场景法设计的测试用例数量可能会比较多，需要花费较多的时间和精力来设计和执行测试用例。 - 正交试验设计法
原理
● 正交试验设计是一种数学方法，通过正交表来安排试验，从而减少试验次数，提高试验效率。
● 在测试用例设计中，可以将输入条件作为因素，将输入条件的不同取值作为水平，通过正交表来选取测试用例。
举例
● 一个软件有三个输入条件：A（取值为1、2）、B（取值为1、2、3）、C（取值为1、2）。
● 可以选择一个合适的正交表，如L4（2^3）表，根据正交表来选取测试用例，如A=1、B=1、C=1；A=1、B=2、C=2；A=2、B=1、C=2；A=2、B=3、C=1等。
优点
● 能够在较少的测试用例中覆盖较多的输入条件组合，提高测试效率。
● 通过正交表的均衡分散性和整齐可比性，可以保证测试用例的代表性。
缺点
● 需要选择合适的正交表，对于一些复杂的输入条件组合，可能难以找到合适的正交表。
● 正交试验设计法在软件测试中的应用相对较少，需要一定的数学基础和经验。 - 错误推测法
原理
● 基于经验和直觉来猜测程序中可能出现的错误，然后设计测试用例来验证这些错误是否存在。
● 错误猜测法是一种非系统性的测试用例设计方法，主要依靠测试人员的经验和对系统的了解。
举例
● 在一个电商系统中，测试人员可能会猜测在商品促销活动期间，如果用户同时购买多个促销商品，可能会出现价格计算错误的情况，于是设计测试用例来验证这个猜测。
优点
● 能够发现一些系统性测试方法可能遗漏的错误，特别是那些隐藏在特殊场景下的错误。
● 不需要复杂的理论基础和工具，只要有足够的经验和直觉就可以进行测试用例设计。
缺点
● 缺乏系统性，测试用例的选取具有一定的随意性，可能会遗漏一些重要的测试情况。
● 对测试人员的经验和能力要求较高，不同的测试人员可能会设计出不同的测试用例。
在实际的测试工作中，通常会根据项目的具体情况和需求，综合运用多种测试用例设计方法，以达到最佳的测试效果。s s s s s s
如何提交高质量的软件缺陷
- 缺陷描述内容
缺陷描述的内容可以包含缺陷操作步骤，实际结果和期望结果。操作步骤可以方便开发人员再现缺陷进行修正，有些开发的再现缺陷能力很差，虽然他明白你所指的缺陷，但就是无法再现特别是对系统不熟悉的新加入开发人员，介绍步骤可以方便他们再现。实际结果可以让开发明白错误是什么，期望结果可以让开发了解正确的结果应该是如何。
1） 缺陷的标题尽量简单、明确、完整；
2）尽量使用惯用的表达术语和表达方法，保证表达准确专业；
3） 一个缺陷报告只包括一个缺陷，复现步骤描述清楚；
4） 是UI问题的话，尽量配上截图标注好有问题的地方；功能问题，尽量配上视频；闪退一类的bug配上1og日志等
5） 一些特殊数据出现的bug，需要备注好数据信息；
6） 一些非必现的问题，多测试几遍，然后备注清楚bug的复现率；
如果是兼容性问题需要备注上设备型号、操作系统及浏览器版本等信息；
8） 缺陷尽量保证不重复提交；
一条软件缺陷记录都包含了哪些内容
bug 标题，需要简单、清晰的描述现象
bug 的优先级、严重程度
bug产生的模块
bug出现时的测试环境，产生的条件即对应操作步骤；
bug详细现象描述，包括操作记录、截图、录像…等等
bug 附件中能给出相关的日志和截图。
和 bug 产生对应的软件版本
印象深刻的bug：
只有一个站点有问题，其他站点没有问题
兼容性问题：谷歌和火狐，mac和windows
app测试和web端测试的区别
相同点：
同样的测试用例设计方法；
同样的测试方法；都会依据原型图或效果图检查 UI；
测试页面载入和翻页的速度、登录时长、内存是否溢出等；
测试应用系统的稳定性
不同点：
app 的中断测试：来电中断、短信中断、蓝牙、闹钟、拔插数据线、手机锁定、手机断电、
手机问题（系统死机重启）
app 的安装卸载：全新安装、升级安装、第三方工具安装、第三方工具卸载、直接卸载删除、
消息推送测试、手机授权测试、前后台切换、网络环境（wifi/2G/3G/4G/无网络）
兼容性测试：web 项目考虑不同浏览器的兼容；app 需要考虑手机不同操作系统、不同机型、
不同屏幕等
web 自动化测试工具较常用：selenium，而手机自动化 monkey、monkeyrunner
系统架构：
web端一般是b/s(浏览器/服务器)架构，只要更新了服务端，客户端就会同步更新。客户端能保证每一位用户的客户端完全一致
app端一般是c/s（客户端/服务器）架构，除非用户更新客户端，否则无法保证美味用户的客户端完全一致
性能测试：
web端需要关注网页的响应时间
app除了要关注在流畅网络下的响应时间，还需要关系流量，电量，cpu、gpu，memory等等因素
兼容性测试：
web端更倾向于浏览器（谷歌，火狐）、浏览器版本、操作系统（windows、mac）
app端的测试主要关注：操作系统（ios、android）、手机牌子、手机型号，分辨率、app版本
app专项测试
异常场景的考虑以及弱网测试。比如：中断、来电、短信，关机，重启
安装时的中断、弱网、安装后删除文件，强制更新与非强制更新、断点续传，卸载后删除app相关的文件
手势、横竖屏切换，多点触控
弱网：
测试要点：
用户体验问题：响应时间、加载图标、异常的提示文案
等待页面的设置，短时间多次重复提交会不会有问题
保证请求不发生堆积，导致数据错乱。例如：弱网情况下，商家用户频繁触发充值，导致请求堆积，金额被扣但充值实际未到账，或被扣金额只有一笔，但实际充值到账多于预期的情况，涉及公司资损
测试点:
1）插电场景 确保升级过程中，耗电不会导致手机低电量甚至没电。
2）wifi场景，确保升级过程中，流量消耗不会使用用户话费中流量包，不会导致因消耗话费流量伤害用户体验
网络测试的一般流程
● 首先要考虑网络正常的情况
- 各个模块的功能正常可用
- 页面元素/数据显示正常
● 其次要考虑无网络的情况
- APP各个功能在无网络情况下是否可用
- APP各个页面之间切换是否正常
- 发送网络请求时是否会导致闪退、卡死等异常情况
- APP各个页面是否显示完整美观，未刷新的页面是否做了相应的提示和处理
- 在无网络情况下数据是否会丢失
- 无网络提示信息是否友好
● 再次考虑弱网情况
- 弱网情况下APP是否针对请求做了超时处理
- 网络延迟的情况下，操作app进行数据同步、OTA升级是否会发生Crash、ANR等严重错误
- 弱网情况下，APP请求回调未完成时，执行其他动作以及交互时，是否会出现APP闪退（如：驾考IOS开屏闪退）等异常。
- 弱网情况下，原始数据是否出现丢失的情况（弱网下载时会出现丢包情况）
- 弱网环境下，是否会出现请求堆积的情况
- 弱网环境下，APP各个页面是否显示完整
- 系统超时，提示信息是否清晰明确
- 弱网情况下APP的响应时间是否在一个合理的时间范围内
- 请求回调未完成–XXX项目XX难题攻克弹窗
- 这个弹窗是服务器说了算，服务器知道该用户啥时候弹弹窗。若用户在做题页面时返回了，则该用户下次进入且在服务器缓存时间内，应该给出弹窗（产品逻辑：弹窗出现后用户必须看到才消失）
- 请求堆积：水池注水排水问题
● 最后考虑网络状态之间的转变
- 断开网络连接以后，操作APP各个功能是否正常
- 同步数据过程中，断开网络连接，APP是否出现异常情况
- 传输数据过程中，网络由wifi切换到gprs，APP是否出现异常情况
- 弱网环境下发送的请求是否在恢复网络以后出现重复提交的情况
应用场景
● 场景：互联网金融APP，申购流程中创建订单后是否支付成功，用户关注度最高（涉及扣费）。
测试点：弱网环境，创建订单失败，用户关注是否被扣费；创建订单成功后支付失败，再次支付是否重复扣费等。
● 场景：弱网环境下直至超时，ui界面友好&app是否稳定
测试点：弱网环境直至超时时，判定为断网专题，UI界面和提示友好（若容错机制主要是考虑弱网情况下带来的不稳定，常见的问题是：loading超时导致ANR ：application not respanding）or crash
● 场景：断网后环境下，是否自动重发请求
测试点：断网后恢复网络，是否堆积网络请求（目前来说 理财模块 当10s左右无返回 则会重发请求），此时请求和返回正常情况下，是否出现异常情况。比如1次支付操作，断网后堆积多个支付请求，恢复网络后因堆积多个支付请求，是否完成多次支付。
● 场景：微信希望在线升级某些内容，会自动监听用户是否插着电 or 连着wifi，一旦监听符合上述场景，APP自动升级
常见错误现象
- 用户登录应用时下载初始化大数据，下载过程中因网速太慢点击取消重新登录，数据初始化完成后出现重复，导致数据不一致
原因：数据下载过程中，下载失败后，未进行数据回滚，中止后重新下载，出现数据重复 解决：通过事务处理数据下载逻辑，可以是下载失败后，应用本地数据库进行数据回滚 - 用户点击数据上传，数据上传过程中网络弱或不稳定，基于联网状态自动触发数据上传，导致出现数据重复写入，造成脏数据
原因：数据上传过程中，由于失败重传机制，会出现连续2次写操作，并且未做唯一识别处理 解决方案：根据数据特性，对可能造成脏数据的地方，通过关键字段，例如创建时间，key-value值等生成hash值，标记记录唯一性，即数据写入时，检查hash键师傅存在，如果存在不在新增 - 在弱网环境下，用户输入用户名和密码点击登录，应用链接超时返回用户名和密码错误提示
原因：在弱网环境下的连接超时后，按照业务逻辑处理，导致返回超时异常 解决方案：弱网连接超时后，检查应用本地数据库是否有用户登录信息，若存在，获取本地用户信息登录 - 在弱网环境下，用户输入用户名和密码点击登录，登录过程中应用崩溃并闪退
原因：弱网环境下数据下载超时，加载数据严重依赖于后来的异步加载，数据还没来得及返回，应用跳转到下个activity，导致崩溃 解决：健壮数据加载流程，通过标记后台数据下载状态加载界面，依赖数据下载完成后，再进行页面跳转 - 弱网环境下，用户请求页面响应时间较长，等待的过程中页面部分控件仍然可以操作，当用户点击控件时，出现闪退现象
原因：没有对数据加载流程进行判断，直接暴露控件可控，当出现依赖数据的控件操作时，没有再数据返回前做兼容处理 解决：再数据加载过程中，设置页面对外暴露的控件为“不可操作”，当数据加载完再释放 - 弱网环境下，用户第一次输入搜索关键字没有得到响应后，再次输入全新的关键字并发送请求，等待搜索结果返回后，当期结果页被之前的关键字搜索结果刷新覆盖
原因：中间的请求返回较慢，显示最终的结果后，之前的请求返回的数据应不做处理，客户端经常做一种处理，请求对象发送返回失败，客户端会重试，请求必须是异步进行的，此时可 能会出现重试失败，仍然一直在发请求，重试策略有问题 解决：对异步请求未完成的任务进行cancel - 弱网下，页面加载过程中程序闪退
原因：webview超时处理未在UI线程。Toast、关闭页面等操作需要再UI线程。 - 302跳转页面，达到内置超时阀值后，webview自动关闭
原因：业务员有页面加载超市自动关闭的逻辑，超时机制未考虑302场景
