当前位置:C++技术网 > 精选软件 > 程序接口联合开发调试的基本方法参考

程序接口联合开发调试的基本方法参考

更新时间:2016-06-30 13:48:25浏览次数:1+次

    在很多开发场景中,你的程序不只是本机的程序,而是需要和其他程序对接的程序。这样的程序在调试时是比较麻烦的。C/C++中,通常是Socket编程。而web程序,则通常是基于http或者https之类的协议实现的接口。不管是哪样的,都需要双方联合起来调试。
    我们再细分下各种场景,然后再来分别梳理调试方法。

1.对方通过测试,稳定运行的,有完整的文档。
    这种情况,一般是大公司提供的接口,稳定运行的程序提供接口,而且接口有完整的说明文档。如腾讯微信、如谷歌AI等。我们的程序和这样的接口对接,要完全按照文档说明来做。所有规定都是定好的,接口也描述好了。做得好的接口,在错误提示中,会给比较具体的错误信息,便于调试。而做的差的,错误不细致,需要根据其他信息来推断,只能求助于文档说明了。
    可以肯定的是,一般出问题,尽可能在自己程序找问题,因为对方是可靠的接口,通过测试的,没有那么容易出问题。不能太自大了,去挑别人毛病。如果确实反复得知对方的问题,那可以去官方反馈,这算是在联调,人家会愿意提供回复的。

2.对方通过测试,稳定运行的,没有文档,但有人配合。
    这种情况一般不会是向公众提供的接口。因为它不提供文档。这个是公司之间合作常见的方式。很多时候为了赶项目,很少留下文档,就是留下也是很少的。但是会有人对接调试,此时的调试就是通过大量的沟通来找问题。双方对接,必然是确定好了接口再开发的。既然对方都是稳定的,所以我们这边开发不是去找对方的问题,而是仔细询问接口的规范,接口的返回结果、错误码错误信息这类问题。你不要去管对方如何实现,你只需要把握好接口就行了。实在解决不了问题,就建议对方调整接口。反正你只能看到接口。

3.对方通过测试,稳定运行的,没有文档,没人配合,但有源码。
    这种情况就必要麻烦了。这种情况出现在外包项目中。你的公司将后台的项目外包给另一家公司做,在验收的时候,在自己公司提供客户端来对接。对接的时候是会有人跟你联调的,就是第2种情况。但是如果第一个联调差不多了,也基本没有问题了,对方会将源码给你公司。后续入职的要在这个后台里开发,就没有文档、没有人配合,但是有源码。我现在就是这样的情况。
    此时源码就是一切了。虽然有了源码,但是没有明确的文档说明,没有细致的接口描述,仅有源码也是很麻烦的。此时不关心的不只是你一方的程序。你需要去对方的源码里提取接口相关的信息,也就是从代码的逻辑里推断接口操作流程,然后再在自己的代码里实现对应的流程来对接。
    如果有一个已经实现的对接项目,你可以参考这个项目源码。在公司里,你需要的能够利用的还是都可以满足的。只是源码都需要你去解读,然后让接口越来越明确细致。我们也不要想着去改造对方的源码,来适配你的程序,这是很不合适的。对方的代码都是写好的,不能随便改,看似无关紧要的一个修改,可能隐藏的危机了整个系统的运作。这个出发点就是不对的。对方的源码的利用,仅仅用来提取接口信息和得到正确的样本数据而已。
    但是,不同的项目,使用的语言可能就不一样。在web中都遵循http协议,但是实现起来五花八门,有php、asp.net、jsp、python(和C++配合写的网站),再加上各种框架,你总有不会的吧。如果刚好项目用的你懂,那好说,如果不懂那就难了。所以,你只能从整体上观摩对方的代码,而不要去细致研究每一行代码的作用。我们通过基本点变量名函数名以及功能应该有的逻辑,不断的推断正确的流程和规范。不管是什么语言,语法上虽然有所不同,但是逻辑上都是差不多的,因为编程的根本就是逻辑游戏。逻辑是编程最通用的东西,这也是项目经验的评价因素。
    在不同的语言的对接时,对于同一个技术实现,实现细节不一样,默认的参数也不一样,直接从表面代码看,你是不可能知道的,而且也是不推荐的。我们只能将对方当做黑盒测试。我们知道对方的接口的基本描述,不然我们也没法开发,只是没有详细的说明而已。所以不一致是不同语言实现最大的障碍之一,另一个就是流程细节没有描述。流程细节描述我们通过对方的源码的逻辑流程可以推断出来,然而技术实现的语言差异我们不好得到,所以只能用黑盒子看待。
    在流程正确的情况下,我们用对方产生一系列的正确的数据样本,给我们测试。我们不要直接用试验数据盲目的将对方当做黑盒子去测试。我们先得保证自己这一方程序的可用性和正确性。我们用自己随便定义的数据,如果本地自己能够正确的处理,那说明我们自己程序是没有问题的。这样才可以进一步测试接口一致性。测试的方法就是用对方产生的正确的数据样本在我们程序里测试,输入和输出如果不一致,我们程序要调整参数,直到输入和输出与对方的一样。这样就调试好了接口。
    我们不能双方都在调试,需要确定一方,调试另一方。在自己这一方调试的时候,最先用正确的数据去检测自己的代码是否可用和检测接口一致性。只有正确的都通过了之后,才能使用不正确的数据去测试程序的稳定性和程序的异常处理能力。千万不要颠倒,否则会混淆结果,让你很难找到正确的结果。我现在遇到的也就是这一点,被异常数据干扰了,后来调整了思路,才找到了正确的结果,才发现一直过不去的是异常情况,而我之前以为这个是接口不一致的问题。更意外的是,这样的异常是非常意外的,我完全没有想到错误的数据会引起异常,如AES解密。因为对于一些技术,我们只是在用,很多内在的问题,研究的很浅所以不懂。
    因为这个场景正是我遇见的,所以总结的比较细致,后面一部分描述就是针对这样的场景,综合给出的调试方法建议。

4.对方通过测试,稳定运行的,没有文档,没人配合,没有源码。
    这种情况,只有简单的接口描述,没有更多的文档。我们就没有办法通过前面几种方法来获取接口信息了。我只有通过时刻的对接,得到反馈结果,来推断。这种推断也就是逆向破解中最常用的方法了。
    通过大量的测试,各种情况的测试,看看对方返回什么样的结果或者崩溃,从而推断对方的实现逻辑,进而破解。这种方法难度很高,需要你掌握很深的相关技术,而且思维要广阔。能够洞察每一细节透露出的更深的含义。正常的开发中,这样的情况还是比较少的,除了破解逆向反病毒之类的公司,这样的方法还是很多的。

5.对方正在开发调试,没有确定接口。
    如果双方都在调试开发,那么保持一致就是双方一开始就要协商确定的。而且,因为双方都是在调试开发,所以都是动态的,唯一不变的就是接口。如果开始定的接口让一方或者双方实现有点困难的话,就要重新商定接口。此时的双方都是活跃状态,只要及时沟通,调试没有太大的问题的。

    那么以上就对5中联合开发的调试方法做了一个整体的说明。可能不是很完善,或者不止5中场景,欢迎留言补充。我们这里讨论的所有联合调试的方法,都是围绕着接口来做的,接口是我们唯一的参考。知道了接口就可以互通了。如果你对于联调没有概念,相信本文可以给你一定的调试基础。如果暂时看不出什么名堂,记住,接口是联调的关键。不要越过接口干涉对方的实现,也不要越过接口为对方而改变。你想研究对方,目的也是更好的了解接口。如果一下子看不太明白,请再读一遍。