职业经验 测试开发之路--聊聊自动化的打开方式

孙高飞 · February 04, 2017 · Last by 黑山老妖 replied at August 20, 2019 · 10254 hits
本帖已被设为精华帖!

前言

自动化好像是测试行业永恒不变的热点话题。貌似也是测试行业争议最大的话题。不知道现在还有多少言论说自动化没有用的,记得前段时间的时候网上还有不少人在争论自动化的价值和作用,但其实自动化不仅仅是存在测试行业。 现在的运维行业以及最近特别火的devops概念都是深深的依赖着自动化的。 好像我们也从没听说人家运维圈子在争论自动化有没有用。往近了说我们公司专门有运维开发来搞运维自动化, 往远了说google也有SRE团队大行其道。自动化是人家圈子里根正苗红的标配。为什么到了测试圈子里争议就这么大呢?我一直觉得这是个很奇怪的现象。大道理我就不讲了,理科男没那么多文绉绉的词汇,我只讲讲我觉得有价值的自动化是怎么个打开方式把。
注:测试圈子太大,每个领域有各自不同的情况,如有不同,欢迎探讨。

自动化的目的

节省资源。我实在想不出来有什么目的比这个还更重要的了。我一向觉得不以节省资源为目的的自动化都是耍流氓。

先说说UI自动化

误区一: UI自动化实现很简单

之所以有这么一个误区原因也很简单。UI自动化不论是selenium还是rf。平常用的API确实没多少,很好学。稍微有代码基础的人就能很快上手,并且觉得这真的很简单。 但是,实则不然。写个脚本跑起来很简单。但是按产品业务构建起一个由数百甚至数千个脚本组成的自动化测试项目就完全不是一回事了。脚本的稳定性,可维护性,可扩展性,业务上的拆分,执行的性能,报表的展示,日志的展示,异常捕获与处理,分布式运行,与数据库和各种底层存储介质的通信等等都是要考虑的。同时你还要考虑自动化最大的敌人--需求变化所带来的影响。你要从项目之初就设计好自动化项目的架构来针对这个多变性。 这要求测试人员有起码的代码设计能力。只可惜很多人用着python,用着java。可我看着都以为这是在写shell,写c。连起码的封装都做不好,我实在不觉得这是在用“面向对象的语言”。

误区二: UI自动化没用

造成这个误区的原因也很简单。技术和业务拆解能力不足就直接去搞自动化了。所以自然就没什么好效果。而且忙于在维护脚本中奔波。然后总结出了一个结论--UI自动化没有什么卵用。

正确的打开方式
  1. 首先,代码能力要好,代码能力要好,代码能力要好。重要的事情说三遍。好的UI自动化项目依赖于好的设计。好的代码能力不是说你会使用各种牛逼的技术,框架。而是你能设计好一个项目,该封装变化的封装变化,该抽象分层的分层,设计模式该用就用。把脚本层,数据层,基础框架层,业务层,page层等等剥离清楚。 按业务需求把各模块分割明白。 这时候要明白,我是写代码的。以一个开发的标准要求自己。
  2. 挑选最合适的开源框架。别装逼自己写,自己写的肯定没人家开源的做得好。除非你是大神否则别自己写。但也别一刀不动,要根据自己的需求对开源框架做二次开发。 推荐一个java系的工具链。UI工具用selenide,注意不是selenium。report框架allure,断言框架assert-core和assert-db。基础测试框架testng或junit。 UI相关的差不多就这些。别再用老旧过时的工具了,还在用原生webdriver是很痛苦的。连自旋等待机制都没有。
  3. 别迷恋关键字驱动,录制回放和各式测试平台。这些东西的发展就目前来说虽然逼格满满,但还无法做好自动化,它们善于降低学习成本,让没有技术能力的人能迅速做到60分,而我们这里说的是要做到90分以上。并且脚本数量一上来就是维护噩梦。公司体量没到一定程度的时候也别去自研测试平台,测试平台也不是保姆式的无脑降低学习成本,主要目的还在于标准化,自动化。
  4. 要与业务绑定,让技术人员只写脚本不管业务测试是大忌。先不说别的,架构都是根据业务拆分设计的,你看哪个架构师设计的时候不看业务需求直接动手的?退一步讲业务不熟练你用例都写不好。
  5. 标准化,我们并不是在一个人在战斗。最好要有统一的技术栈,运行环境,代码风格等等。标准化真的是好处多多。
  6. 理性看待UI自动化,合理运用UI自动化。它不是神,有很多东西不适合做UI自动化的别硬去做。也别因为有些东西UI自动化做的不好就否定它。

每个项目面对的情况不一样,我就不说太多了。介绍下我厂现在的情况。 6个浏览器并发一个小时基本跑完所有UI自动化。之前3个QA3天跑完所有case,现在是7个小时。现在的痛点仍然是运行速度问题。 希望今年能申请到更多的资源。

接口自动化

这个在业界比较火,各大厂测试圈子的宠儿。自从分层测试理念出现以后就开始崭露头角。成本低,速度快,效果好,运行也稳定。UI自动化中很多奇形怪状的坑在接口测试里是踩不到的。根据金字塔型的测试理念,测试人员大多都更关注这一层。 打开方式上其实与UI自动化并无太大的区别,上面说的那些该做的还是得做。还是那句话,得有代码设计能力和业务能力来支撑接口自动化。只不过接口自动化不仅仅是http接口自动化,还有各类底层协议通讯,例如一些RPC协议的接口。 广义上来说只要是对外提供服务的都是接口,不仅局限于需要网络通讯的。哪怕是个lib是个jar包,都是可以做接口测试的。 我们公司也叫模块级测试。这时候就是语言相关的东西了,不再是你想用什么语言就用什么语言,是要使用开发的语言去开发的repo里以单侧的形式编写测试代码。这时候偏底层的东西多,需要了解开发代码和架构,需要用mock。正确的打开方式参照UI吧,理念上差的不太多。工具还是推荐java的,rest-assured,其他的跟UI的工具一样

环境自动化

这部分也一直是有争议的。纠结于到底是QA来还是运维来负责这部分自动化。各家公司的观点都不一样,之前面试的时候问过很多候选人环境相关的问题,其中比较多的都是说交给运维来做的,他们最多自动化部署一个前端(app,browser)或某一个模块。很少见候选人是能独立把整个产品部署起来的,能画出产品架构图的就更少了。我比较偏向于公司内部的产品环境由QA维护,我厂也确实是这么做的。我的理由也很简单,我们的产品很偏底层,要测负载均衡,高可用,异常处理等等,经常要增减节点,kill掉各种底层服务。所以必须要对产品架构很了解。要清楚各层各模块是怎么通讯的,都负责什么任务。出了错怎么定位,去哪看日志,找哪个开发都要清楚,所以搭建环境的过程是十分有助于之后的测试工作的。同时QA负责环境自动化也是有一些好处的。

  1. 首先,QA更了解自己对于测试环境的需求,直接自己定制比跨部门协作效率高。
  2. 其次,QA是连接开发,运维,产品,售前,进场工程等职位的角色。可以说我们跟所有部门都紧密的合作着,我们是比较容易获取他们对于环境的需求。
  3. 最后,我现阶段倾向于QA作为一个接口输出方,交出去的就是直接可用没有坑的产品以及部署方案。把运维从这些琐碎的事情中解放出来。

到底该谁来做不争论了,各家有各家的情况。我来介绍一下我们的打开方式把。

基于docker的解决方案

现在业界要么用传统的虚拟机加shell。要不就用当前大火的docker。 我之前使用前者,现在热爱后者。下面是我厂的环境部署流程图。

过程说明:
  1. 首先读取用户配置,启动N个编译容器并发编译所有模块。
  2. 统一发送到汇总容器,由汇总容器打成一个符合部署规范,可以直接发送给进场同学的大包。并传送到FTP服务器上。
  3. 根据配置挑选部署镜像(各版本的centos, ubantu, suse, redhat等),从FTP上拉取部署包进行部署。如果是线上镜像,不会部署,而是制作成一个可在线上部署的镜像。
解释一下

之所以弄成这样要解释一下,这个跟我们的业务形态耦合的很重。 由于我们是TO B的业务,而且大部分情况是进入到客户场地部署的。客户场地会出现各种限制。 例如没有网络,没有root权限,五花八门的操作系统等等。所以就衍生出了部署测试,我们也称后端兼容性测试。所以上图的右边我们的部署镜像有很多个系统版本的。这些是我们跟运维和进场工程师共同协定的标准镜像----基本就是一个官方的OS镜像加少量的工具。同时使用一个普通的没有任何额外权限的用户。目的就是测试产品对各种情况的兼容性。所以才造就了我们的部署包很大,因为依赖都打在了部署包里。 我们部署环境的时候可以选择一个镜像进行部署。

正确的打开方式

  1. 标准化,docker很适合做标准化。所有环境都是一样的,不会出现什么bug在这个地方能重现,那个地方复现不了的。也能让开发人员尽早发现部署上的bug,例如自己开发的时候不小心用了root权限,这样会很快发现这个bug,因为所有环境里都是没有root权限的。
  2. 并行化,我可以一个人起N个容器并发编译所有模块增加编译速度,也可以N个人同时起更多的容器并发的部署不同的环境。不会像以前的虚拟机一样一个人编译的时候另一个人就得等着。
  3. 定制化,标准化之外我们还可以定制化。为不同的角色定制化他们需要的环境。例如产品人员需求稳定可用的环境,我们给他们做蓝绿部署,服务高可用。运维人员需求一个标准镜像直接在线上部署,我们就给他做一个镜像。进场人员需求一个部署包,我们就在部署环境的过程中自动的打成一个大包(上图的汇总容器)放到FTP上,他下载直接带走。开发人员除了日常部署还需要能随时搭建一个老版本的产品(TO B业务的特性)来重现并修复一个bug,我们就对环境部署项目也做多分支策略,保留每个版本的镜像。总之我们可以针对不同的岗位为他们定制化不同的功能。
  4. 环境编排,当你的环境到达一定数量以后必然就会面临一个问题,一台服务器无法抗住这么多容器运行的压力。所以就会慢慢的变成2台,3台甚至更多。 这时候需要考虑很多东西,例如资源分配怎么搞,怎么确定哪些容器部署再哪个节点上。例如如果一台节点挂了怎么办?难道在它恢复正常之前这个节点上的服务就一直不可用么,是不是要加入recovery机制等等。所以这时候需要引入环境编排机制。一般无非就是在swarm,mesos,k8s,rancher上选了,一般公司没那个精力自研。只是用在测试环境上推荐docker 1.12内置的swarm mode, 之前还分别研究了mesos和k8s, 对于QA来说它们都过于复杂了,需要相当大的学习成本。以mesos来说需要各种其他插件才能正常服务,光是一个服务发现就需要安装一个mesos dns,高可用得维护ZK等等,就算你什么都没要求也得装个marathon,各种配置文件确实也让我这个非运维感觉比较棘手,想搞好它真的需要投入大量精力。而swarm mode所有的东西都已然内置,使用起来很简单方便,至于swarm mode的那些令人诟病的缺点,我们可以忽略了,这又不是生产环境。 当然了,劝告各位QA同僚。。。能不搞集群就别搞集群,能一台机器扛着就一台机器扛着。一但涉及到环境编排,那坑就多了。。。。。。 对swarm mode有兴趣的同学请看我之前发的swarm mode的科普贴

持续集成

以上介绍的所有自动化类型都是要加入到持续集成里的。 我之前写过一篇文章介绍过持续集成,在那里我就说过持续集成是个比较难的东西。它是对团队工程文化的一种考验。是细节的堆砌。你要把上面所说的所有自动化类型都做好,然后开发人员要写好单元测试,团队要设计好的分支模型。具体细节可以翻我之前的帖子,我就不重复的逼逼叨了。

总结

好了,这就是小弟做过的能拿的出手的自动化了,其他各类牛逼的东西不提也罢,我都不专业。

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
共收到 63 条回复 时间 点赞

👍
但是很多公司或者部门上来就想搞平台,大而全,最后都无法落地,交完一波kpi就烂在那里了

#1楼 @wenchao 我厂现在就处于这种情况,QA人员不懂技术,不写代码,而且各种逼格各种自动化需求。

感觉楼主写的文章都挺有深度,每一篇我都仔细看了,收获良多。对于这篇中的进场测试,是你们到了客户场地,查看客户操作系统版本是Centos6.6,然后你们从ftp上拉取Centos6.6的容器进行部署测试?对于楼上的说法,我也深有感触,能将新技术落地并提高生产力才是最好的,要不搞了半天还不如不搞。对于环境编排,我们测试环境用的也是swarm node,感觉挺好,结合shipyard,可以通过web来操作,比较方便。顺便问下楼主,你们的微信公众号是啥

思寒_seveniruby 将本帖设为了精华贴 04 Feb 16:23

如果能跟公司的运维体系搞成一套是最好的. 让自动部署可以无缝的支持多套环境. 这样qa的环境运维也就节省一部分了.

#1楼 @wenchao 恩,我的意思是一步一步来,别企图一口吃成一个胖子

#3楼 @airfer 不是的,做的是部署测试,是还没进场的时候就开始的测试。 我们跟进场工程师们做过一些沟通,他们总结出在客户那里常见的系统环境和碰到的问题。并和售前,运维沟通,规定都支持什么样的系统。我们事先准备好这些景象,在版本发布前就在所有的镜像上做部署测试了。 所以进场工程师拿到的部署包就是经过了部署测试的状态。 我没有个人的公众号~~ 是一个同学做了一个公众号叫QA之道,我就是把写的东西都发那上面帮他吸吸粉

#5楼 @seveniruby 恩,我也希望能跟公司的运维体系搞成一样的。 你们那大概是怎么做的呢? 怎么衔接QA和运维的工作呢? 我们之前讨论过几次怎么让QA和运维更紧密的合作。但是效果不是太好。

#7楼 @ycwdaaaa 哦,这么说就明白多了,是我理解偏差了,我当时还疑问为啥非要到客户场地测试呢。。

selenide 只能用于web端的吧??

#10楼 @f_si 恩 对, 我没做过移动端测试。 所以就不充大尾巴狼瞎扯移动端的测试了

#10楼 @f_si 可以用于移动端的 我自己没试过 google上可以搜到很多例子

还有对自动化编写的要求真是非常认同,没有好的编码能力,即使搞起来,维护代价也是很大的,从开始着手就得考虑很多了。我就是编码能力是瓶颈啊,还得继续修炼

#3楼 @airfer 对了,打听一下你们用swarm mode的时候用的是什么网络? 是overlay么? 还是用的其他插件?

#12楼 @shljsh 嗯,可以用于移动端,简化了

@ycwdaaaa @seveniruby 自动化这块我目前有个困惑点还望两位解答一下。 以UI自动化举例:目前所有的case都是直接写代码的,每次有新的东西要验证了都会去写对应的代码。那么在往框架或者平台的发展道路上,我所知道的就是通过文件流自动把代码写到一个class文件里,然后在把需要跑的case写到testng的xml里。对于现在很多人都写的这些框架啊平台啊之类的,生成case然后执行,这块是怎样实现的

#16楼 @jackie 没太明白你想问什么。。。。

#16楼 @jackie 框架和平台的作用,仅仅在于让测试工程师能够更好的写Case,更好的组织Case,更好的维护Case,更好的运行Case,更好的管理Case数据,更好的查看测试报表报告,更好的排查错误。至于你说的什么生成Case直接运行,搞不懂你想表达什么。

#18楼 @ycwdaaaa @jet 确实有点难以描述,我现在要验证一个登录的功能,还是举两个例子:原始状态:1.需要在IDE里新建一个login的class文件然后去做对应的操作,再把这个login.class加到testng。xml里运行,2.框架和平台,只需要在一个文件(excle)或者一个case管理页面(平台)把登录操作需要的定位路径,操作,断言等写在里面。 我的问题就是在你的框架或者平台里,管理case时,怎样把这些case转化成代码去运行。

#19楼 @jackie 我理解这不是关键字驱动框架么?虽然我十分反感这种框架,但如果你想用,其实有县城的rf,没必要自己实现。 如果你想自己写。就自己定义一组关键字,写个解释器去翻译成代码执行就可以了

#20楼 @ycwdaaaa 可能是我自己把问题搞复杂了,也就是你们把框架或者平台都建好了,但是case是在增加或者变化的,run的时候终归是跑的代码,把case中的数据转化到代码中,这个转化是怎么实现的,这样貌似更贴切我的问题。因为之前看人家写的是把case中的数据像写文件一个写到一个class里。 我的知识面太狭窄,所以问的可能就局限在关键字框架上了,你要是懂我的问题了就帮忙提点一下把,使用关键字框架是怎么实现的,不使用关键字框架是怎么实现的(你上面的文章中不是也不提倡关键字驱动的么)

#21楼 @jackie 额。你这一解释我又懵逼了。。。case中的数据转化到代码中是什么。。。。把case中的数据写到一个class里又是什么。。。我基本没见过把测试数据写class里的。。我见过写进xml,写进excel就是没见过写class里。。。是说数据驱动么?就是把测试要用的参数提取到一个文件里,框架动态读取这个文件的内容然后传递给测试代码,有多少组参数就调用多少次这段测试代码。 是这个意思么?

#22楼 @ycwdaaaa

然后每次新增或者修改case就维护 这个excle。 平台的话可能就是一个xml之类的。

  • 不用这样维护case的话,我就是在IDE中新建一个login.java 文件,每次新增case就新建个XX.java 运行的话在到testng。xml进行配置
  • 使用这样的方式管理case(目前我知道的就是这样的关键字的数据驱动),然后把表格里的数据使用文件流写一个xx.java文件

我的问题是在把excle里的数据变成脚本代码运行,这块是怎么实现的
不知道这样你有没有懂😂 还不行的话能否价格Q or 微信

#23楼 @jackie 就是关键字驱动了~~, 原理其实挺简单的,像RF那种成熟的我没研究过,假如用比较挫的方式解决: 自己定义关键字,然后写个程序翻译这些命令。 举个例子,你可以定义一个统一的关键字接口,所有的关键字都做个单独的类继承这个接口。 这个接口有一个关键的方法,假如就叫action。你的程序顺序读取excel把所有关键字按顺序组成一个链表。 遍历这个链表挨个调用action方法就行了。 其实就是设计模式中的策略模式。

#23楼 @jackie

关键字 描述 参数(css selector)
click_element 点击元素 .btn

在代码里读入后,执行如下逻辑,比如java

String keyword = READ_FROM_FILESYSTEM();
if(keyword.equals('click_element')) {
String cssSelector = READ_FROM_FILESYSTEM();
driver.findElement(By.css(cssSelector)).click();
} else {...}

这是最傻瓜的套路,方法体里代码要怎么写你随意,大概就是这意思。

#24楼 @ycwdaaaa @jet 总感觉还是少了点什么,先照着你们的解答 我先搞搞 有啥问题再问🙏 😁

#14楼 @ycwdaaaa 没有使用overlay,我们现在测试环境的机子都是centos5,和centos6的,能部署的最高的docker版本是1.7,无法提供overlay支持,现在节点都是使用的host模式。现在集群主要用来跑分布式,节点之间没有啥通信,所以暂时也没考虑跨节点通信这块

#27楼 @airfer 哦哦 原来是这样~ 那是用的swarm 不是swarm mode?

#28楼 @ycwdaaaa docker1.12版本之后才提供了新版的swarm,就是swarm node,集成到engine中。由于现在测试环境docker的版本过低,所以目前使用的是老版本的swarm。顺便问一下,你们机子现在都是运行的docker1.12之上的版本?版本低的机子都做了升级吗?

#29楼 @airfer 恩,几个月前把机子都重装了。我们小团队,没几个机子,所以没费多大事。 swarm mode比较特别,我一开始也想用host模式。但是发现host,briage都不支持。最后我只能创建overlay网络了

#30楼 @ycwdaaaa 哦,对于swarm mode,我也只是了解过,没有在真实的机子上用过,等后续我这边机子升级后,我也来实验一下~~ 后续多交流😀

#31楼 @airfer 好的以后多沟通哈😁

自动化概念确实很大,甚至不一定用什么框架才叫自动化,只要实现快速、便捷的管理与测试就好。运维圈管理的系统更加标准化、统一化,变动相对较小,甚至可能能够直接用一些开源工具,布几个服务就能实现自动化管理了,效果自然比测试这种需求变动巨大的项目要稳定的多、效果也更好。也许是本人长期从事服务端测试的缘故,UI的自动化确实没有见过哪家用的好的,如果兄弟团队用的不错,倒是很想去学习一下。

#34楼 @dkleaves 其实现在的运维也不是下载几个开源的工具就能堆出来的了,系统越来越复杂,现在已经要求运维二次开发或者自研自动化运维平台,业务的体量和需求也在变化,所以运维同学也要时长的改东西的。现在已经有专门的SRE(也可以叫运维开发吧)。UI自动化个人觉得比较依赖业务和代码架构能力,一般公司的同学搞不好UI自动化我再文章中也写了。 我们的UI自动化就比较稳定,因为设计的比较到位,所以需求变动的时候改动并不大。当然了有的业务类型变动就是特别大特别快的,也确实不适合做自动化

#35楼 @ycwdaaaa 嗯嗯,谢谢回复,可能个人在运维的问题上回复的有些片面了,只的是一些开源工具。我们部门的OPS兄弟确实也做出了很强大的管理系统,像docker这类也在做二次开发工作,他们把资源、管理多个方面集中一起,开发了一套平台系统。

做了一段时间测开,对老司机的观点比较有体会,我现在就处于慢慢自创到学会熟练二次开发成熟框架的过程吧,赞一个。

请教下,selenide 时间等待怎么写??

#38楼 @f_si 默认等待4秒。如果你想定制,可以用下面的方法

#39楼 @ycwdaaaa 谢谢!感觉selenide写不太稳定,有时候跑是对的,有时莫名的出错了

#40楼 @f_si 用好了其实很稳定的,比其他框架稳定多了

@ycwdaaaa ,断言框架assert-core和assert-db。这个是什么东东,能详细说明下么。

report框架allure,我用mvn敲命令运行,mvn jetty:run 可以看到报告,用jenkins集成,这样配置怎么老是显示同一份报告。怎么配置,立即构建,allure查看最新报告。


#44楼 @AAtest 好奇怪啊。。。。我怎么没碰到这个问题, 不过你可以用这么一个方法,在所有测试执行前,清理一下report的目录。。。。。我以前就这么干的

46Floor has been deleted
47Floor has been deleted

楼主,能说说关键字驱动为什么不好吗?谢谢!我用了好几年,为什么觉得还挺好的呢?当然写一个case,花的时间会长一点

孙高飞 #49 · March 27, 2017 作者
caivivi 回复

主要是维护起来是个噩梦。本来业务变化就很大,不仅要改case还得改框架,我觉得维护成本太高。 为了能让不会写代码的人使用。要封装的东西太多,例如如何让不懂代码的人调试和debug?光这一项就够让我头疼了。又例如我还被要求过提供一个酷炫的UI。总之各种坑。

50Floor has been deleted

谢谢楼主!主要我们组的人都是写测试代码的,而且也是等业务稳定了才写自动化case的,所以感受跟你不同。不过你说的这些工具很有借鉴意义,我去研究研究,谢谢啦!😀

52Floor has been deleted
53Floor has been deleted

hi 楼主,你用selenide不是封装成关键字驱动,难道是封装成数据驱动吗?谢谢啦!

#6楼 @ycwdaaaa 好文,支持下

—— 来自TesterHome官方 安卓客户端

在这里想请教楼主一个问题,因为我们的app是教育学习软件,注重内容,经常做的是试题的更新(客户端无需做更新),编辑那边在制题端校验了试题内容后就不会管内容在APP上的展现是否正常了。所以我们的测试工作有一部分时间是去校验试题内容在APP上的展现问题,常有样式问题例如对齐有误,某个选项的图很大等。想过做UI用截图对比,但是每套题内容又是不一样的,但题型一致,不知道能否做图片的局部对比。这个问题问的确实有点怪,抱歉打扰了,期待得到回复,谢谢~

从今天开始我就是你的小迷弟了, 你真厉害!

孙高飞 回复

有个问题问下大大,如果不用关键字驱动,用什么方式写到脚本里去会比较好维护呢,是用枚举吗?

请问ui自动化需要用到spring吗?如果需要有什么好处呢?

写得好好

叶子 回复

我也在被这个问题困扰

0x88 回复

不会写代码就做基于业务的前端功能测试吧

想请问下楼主,根据业务来设计脚本,这个大概啥意思?能不能讲的详细点,想了解一下这块的内容

Author only

感谢有你,一路同行

飞哥,我现在做的就是自动化测试的岗位.
做的成绩,就是有一套订单参数做标准数据, 使用Python + selenium获取网页上订单的值,按照业务流程进行点击各个按钮,再判断各个阶段,网页上的订单值或者数据库里的订单值,是否和订单参数标准是否一致, 感觉和你们做的不一样.

Author only
孙高飞 #68 · June 17, 2019 作者
Popstar 回复

第四范式

Author only
需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up