功能测试：也叫黑盒测试，功能测试指测试软件各个功能模块是否正确，逻辑是否正确。对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。这种测试的目标是核实数据的接收、处理和检索是否正确，以及业务规则的实施是否恰当。此类测试基于黑盒技术，该技术通过图形用户界面(GUI) 与应用程序进行交互，并对交互的输出或结果进行分析，以此来核实应用程序及其内部进程。功能测试的主要参考为类似于功能说明书之类的文档。
性能测试：指验证软件的性能可以满足系统规格给定的指定要求的性能指标。性能测试是一个比较大的范围，可以进一步衍生出负载测试、强度测试、压力测试、稳定性测试。通过自动化测试工具模拟多种正常、异常、峰值条件，对系统各项性能指标测试。
请描述你对测试的了解，内容可以涉及测试流程，测试类型，测试方法，测试工具等：
测试流程：
需求分析---需求评审（项目需求人员，开发人员，测试人员）--定排期（开发人员制定开发计划，测试人员定测试计划）--开发人员进行代码开发，同时测试人员编写测试用例--开发人员开发完成提交代码--测试人员showcase用例评审--运维人员部署软件测试线--测试--开发修bug--测试完成，提交测试报告--上线--线上检查--邮件抄送组内进行上线通报。
测试类型：
根据项目流程阶段划分：单元测试，集成测试，系统测试，验收测试
根据对代码的可见程度划分：黑盒测试，白盒测试，灰盒测试
根据是否投入大量人力划分：手工测试，自动化测试
还有冒烟测试，回归测试，随机测试
测试方法：
黑盒测试：边界值，等价类划分，因果图，决策表，错误推测法
白盒测试：语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖、路径覆盖
测试工具：
接口测试工具：jmeter，postman，robotframework
性能测试工具：Jmeter，loadrunner
UI测试：Selenium
有关登录的测试用例（收集至51testing--http://www.51testing.com/html/59/n-4458459.html）：等价类和边界值
安全性测试
性能测试：
兼容性测试：
思维导图测试用例补充：
支付功能的测试用例：转载于https://blog.csdn.net/qq_42782258/article/details/84321836
支付流程：
1：正常的发起一笔流量充值请求，检查点：
1）用户发过去的信息有携带key值
2）商户系统本地数据会留存一份用户的订单信息，并且会根据每笔订单信息生成一笔支付信息（同时留存到本地）
3）第三方支付成功，第三方有存支付订单信息
4）充值成功，用户的流量余额有对应增加
异常用例
1、修改用户发过去的数据：
1）产品ID 与价值不对等---->检查点：篡改数据和key，检查商户系统报错：key值不对或者是用户数据有误。
2）取消充值流量
3）重复发起流量充值请求
2、商户系统-第三方之间：
1）密钥搞错-第三方报错，不接收密钥
2）提交商户系统里面不存在的订单/支付订单->第三方这里也是不能通过请求
3）篡改用户支付金额–>第三方也要检查
3、第三方–用户之间:
1）支付密码错误/余额不足
2）取消支付
3）重复支付[对账—>处理退款]
退款流程
正常的用例：
1.用户发起退款—>该用户的订单以及支付订单号都要存在。—检查点：商户系统/第三方检查数据没有问题，可以退款成功—>交易状态改成退款
异常用例：
1：无故发起退款：提交不存在的订单号或者支付订单号 —>订单号不存在/支付订单号不存在
2：信息不匹配发起退款：提交订单号与支付订单号不匹配的数据—>订单号/支付订单号有误
3：退款大于实际金额：提交的退款金额大于实际支付订单的金额–>商户系统要报错
4：商户系统这里发过去的请求：退款金额大于实际支付金额–>第三方要报错
分析二：
对于支付模块的相关测试，我们应该如何进行呢？比如，针对游戏来说，使用第三方支付往游戏充值游戏币功能，看起来是不是很简单，大家主要思考下以下内容：
1、支付都是与第三方支付（支付宝、微信、财付通、QQ钱包、短信支付等）进行对接，那么，是否了解了第三方接口有哪些？是否都能清楚我们的产品与第三方是如何交互的？是否能画出流程图？
2、异常场景有哪些？
3、有哪些风险，如何规避？
第三方支付的流程，与商户的对接方式基本相似，大同小异。
第三方支付接口：
· 下单接口：商户提交下单请求到第三方支付接口，第三方支付收单成功后返回下单成功结果给到商户系统。（下单接口的最终处理结果分为下单成功和下单失败，若未收到明确结果可调用单笔订单查询接口查询结果。）
· 支付接口：调用该接口时指定支付参数，完成买家账户向商户账户的支付，采用页面跳转交互模式和后台通知交互模式。（结果分为两路返回：一路为前台在return_url页面跳转显示支付结果；一路为后台在notify_url收到支付结果通知后进行响应。）
· 退款接口：调用第三方支付的支付请求接口返回付款成功后，在需要做退款处理时调用退款请求接口发起退款处理。（退款接口的最终处理结果分为退款成功和退款失败，若未收到明确结果可调用退款查询接口查询结果。）
· 单笔订单查询接口：根据订单号查询单笔订单信息和状态。
· 退款订单查询接口：调用第三方支付的退款接口返回后，在需要查询退款请求状态可调用退款订单查询接口查询退款订单的状态和订单信息。
那么针对第三方的接口，我们大致也有所了解了，接下来针对测试过程中涉及到主要的测试点整理如下：
测试过程中需要注意的主要测试点及异常场景：
· 首先要保证接口都能正常调用；
· 生成一笔订单，支付完成后，同步或异步重复回调，只有一次有效；
· 生成一笔订单，复制订单号和金额，再次生成一笔订单，用fiddler设置断点，用第一笔已完成的订单号和订单金额去替换现有的订单号和金额，无法完成支付；
· 生成一笔订单，跳转到第三方时修改金额，无法到账，或者如果是游戏充值游戏币的话，到账为篡改后的金额对应的游戏币；
· 异步通知屏蔽，同步有效，进行支付，同步能够正常到账；
· 同步设置无效，异步有效，进行支付，异步能够正常到账；
· 同步异步都设置无效，在第三方支付完成后，在重发机制时间范围内，设置异步有效，到下次通知时间点时，能够正常通知到账（补单机制的验证，如果商户收到第三方支付成功的通知后，要告知第三方支付收到了成功的通知，如果第三方支付收到商户应答不是ok或超时，第三方支付就会认为通知失败，会在规定的时间内持续调用notify_url，一般有时间或次数的限制）；
· 针对支付订单在数据库中存储是否完整和正确进行校验（比如：第三方订单号–方便与第三方对账和问题排查、订单金额、订单状态等）；
· 如果是用户购买实物商品，用户发起退货，要保证退货流程正常，资金能正常返还，要考虑下并发情况的验证以确保安全性；
· 如果是用户购买虚拟商品，比如话费、油卡之类的商品，只有在发货失败的时候才能发起退货，注意验证；
遇到过的坑：
· 用户购买100元游戏币时，前往第三方支付跳转进行金额的篡改由100元改成0.01元，结果就拿了0.01元充值了100元的游戏币。对订单金额没有做校验导致这样的后果，损失比较大。大家在测试的过程中一定要注意对服务端进行校验，支付时数据的篡改一定要有校验。
· 当同步、异步通知都存在的情况的，异步通知（第三方支付成功后台通知），没有到账，导致部分用户充值不到账，引起客诉。当同步、异步并存的时候，一定要分别对同步和异步进行检验，确保都能正常到账。
我们所做的绝大多少的互联网产品都会涉及到第三方支付，所以支付功能必然是重要的，作为测试互联网产品的一员，我们必须要做好支付的安全性。