• @monkey 哈哈,我们项目就偶一个人,问了一圈,我司其他项目还在用 ECLIPSE。。。
    GIT 偶还处于初级阶段,谢谢陈兄,我先看看自己维护一个测试库,同步开发库能不能搞定。。。指望开发是指望不上的。~
    实在不行用 APPIUM 了,慢就慢点吧,UI 也测不出太多问题。~

  • @monkey 恩,2.用 GRADLE 命令就可以了(还没实践)。
    主要还是 1,如 BUILD.GRADLE 不是要加入:androidTestCompile 'com.jayway.android.robotium:robotium-solo:5.2.1'
    开发分支的文件和我本地的文件不就不一致了么。
    然后 GIT 管理工程的话,也是一个工程管理的吧,开发应该不太会让我把我这边的代码合入。打包也是开发打的,现在工程合一,咋整呢?
    测试来打发布包?没有成熟的方案开发应该是不太愿意让我把代码合进去的。

  • @xiyue 楼主,你这部分的代码是如何管理的?合入开发分支么?~
    持续集成呢?用 gradle 命令做么?

  • @xiyue 楼主,你这部分的代码是如何管理的?合入开发分支么?~
    持续集成呢?用 gradle 命令做么?

  • XCTEST 开发都不会做也不愿意做的飘过。。。

  • @james88233 打 100 个电话这是稳定性测试吧?我的意思是这种手机硬件相关的测试和纯应用测试还是有区别的。~

  • 最近才和其他部门的同事聊过,这里的整机应该主要是针对一个固定型号的机器进行相应的整体功能性测试吧?因此性能是通过其他方式测试硬件,他们整机主要是测功能覆盖,然后目前的新机型主要都是 4.4 以后的,不存在取不到控件的问题。功能么,主要是测试 SDK 自带的和 ROM 封装的功能?我这么说有没有问题啊?大家的测试对象都不太一样,建议下次最好将需要测试的对象稍微描述一下吧?~~@carl 我这么理解有没有问题啊?望指正哈~

  • 个人理解,盒子本身是没有未来,没有生态圈的盒子,就只能是个盒子。

  • @halo_lan 目前还没有考虑压力测试,我们是家庭产品,一般来说不会有超过 5 个用户同时登录,目前只考虑了常规的一些性能测试,请问压力测试这部分有什么可以建议的么?多谢!~
    呵呵,我们就是因为考核开发 BUG 数目,所以 API 都是扯皮的事情~必须要有实际操作异常,才会理会你。API 改了,只要实际功能能跑通,测试脚本跑不跑的通那是测试的事,和开发无关。。。这里槽点比较多,就不细说了~

  • @sam_insist 你上面说得都是一些基本的功能,我个人理解还是需要整合一下的,测试归根结底还是要验证功能。做完之后心理有底,给领导交差时也会好看些~个人建议只做简单的整合,不要搞得太复杂。

  • _,吐槽有点多~以下是我个人的观点,供吐槽~
    我个人是这样理解的,10 个接口,接口组合感觉这种就不是接口测试讨论的范畴了。这个应该是测试方法,测试架构讨论的内容。如关键字驱动之类的。
    大家可能接触测试理论都会说要覆盖要完善,但怎么说呢,完备是需要成本的,有些覆盖在代码中是有约束的,比如条件 A 触发以后才会运行 B,某些完备是没有意义的。我们看到开发提供的接口可能有 10 个,你组合多少合适呢。这个感觉还是经验和项目需要或者是用户来驱动。呵呵,有不少东西,我知道自己项目怎么玩,但是别人的项目适用不适用就很难讲了。
    我感觉自动化不是万能的,有很多内容比如 DB 同步,异常测试的一些内容,就需要自己去想办法挖掘组合。目前我感觉自动化把基本的跑跑通,降低回归测试的成本就很不错了,个人建议不要想太多,手工也是不可能完全替代的。
    接口测试个人认为最大的优势就是 UI 改起来太痛苦,接口简单很多,也更贴近代码,更好操作。~
    题外话:领导最后要看的是成果,至少最基本的内容要能跑过,接口最终还是要变成一个一个可呈现出来的东西~适当的组合还是必须的。

  • @sam_insist 你这个是关键字组合的问题了。。。这个和自动化关系感觉不大。
    我个人的意见是简单组合,复杂组合除非出过问题,没有必要专门进行接口组合覆盖。
    当然还要看你们项目的要求,自动化到底要实现到什么程度。自动化不是万能的。。。~
    PS:我能吐槽一下么,用户一个操作调 10 个接口,这个操作还不封装一下,这 10 个接口之间会没有顺序么?这要不封装的话,这用户体验,代码结构也算是奇葩了,个人建议结合业务流程,不要做太多无用用例~到最后还是要考虑执行时间的问题。

  • @sam_insist 不知道你的需求是什么,功能的自动化用例也完全可以由接口组合啊?
    或者换个维度,用户故事算么?

  • 个人的经验是:该汇报汇报,该工作工作,合理的接受,不合理的理不理他是另一码事。领导不合适还是努力提升自己,想出路吧。
    PS:自动化不是万能的,不要太理想。~API 自动化远没有想象的那么牛 X。

  • Crosswalk 简介 at 2015年05月29日

    @lihuazhang 恒温,你不是做盒子的么,我一直有个疑问啊,你们盒子的 APP 还要 Hybrid 么?用 Hybrid 有什么优势么?~

  • 赞一个。~就是有点远。。。
    PS:现在互联网形势不是一片大好么,政策面都支持了。~

  • 接口自动化思路 at 2015年05月26日

    @xuxu 帅哥,看到你的答复,正好最近回去写接口,RF 只提供了一部分库吧,如果是自定义报文,还有不少第三方库的使用,怎么弄呢?
    比如我这边文件访问需要测 SAMBA,客户端实现需要第三方库支持,感觉类似的一些功能,RF 很多没法用啊。反正我是都自己封了一遍,就是还得再整一套流程输出报告比较坑。求经验~

  • 我很想知道,薪酬——薪酬+月奖+年奖+期权,保证全上海最佳!
    上海最佳是多少米?

  • @seveniruby 基本上是明白了,谢谢思寒的解答。~

  • 这么说啊,主要是觉得思寒从报文中提取测试源数据这个很牛 X。
    感觉我们写 API,都是自己写 API 接口,自己设计入参,判断返回。没有想过中间去抓取数据,再作为源数据传入。
    我个人有个疑问啊,这样的话,如果目标 IP 变化,或者 HTTP 的 SESSIONID 变化,这样不就歇菜了,源报文也要变化啊。
    这个我暂时理解不了,求解答~~~
    是不是我理解的有问题啊?这个主要是测试 DIFF 的?具体数据怎么驱动还是要代码支持?

  • 牛 X,我一直以为接口测试都是自己写代码一个一个接口过,土鳖了。。。

  • 这个问题太大了,个人经验供参考:
    1.首先要看老板或者领导愿意投入多大的意愿去干这么一件事情。如果领导只是说说建议你谨慎,因为中间他可能催你,可能觉得你进展慢,你遇到困难时,可能获得的支持有限。
    2.建议测试对象必须是稍微稳定点的产品,如果产品的稳定性都没法保证,建议你缓缓,因为 PM 肯定是向着开发而不是向着你,这样会很痛苦。
    3.流程方法这些大部分这里只能提个皮毛,用例和最后的实践很多涉及信息安全啥的,不方便提。自动化测试用例可以参考 SHIXUE33 美女前段时间发的帖子,大部分内容都包括,可以参考这个来做。论坛获取到的信息一般都是技术层面上的和零散的一些信息,如果有可能还是尽量从内部挖掘一些流程上整体上资源。~
    4.UI 自动化只是最基本的,安全性能等等,总之还是要贴近自己的应用,知道哪些能做,哪些不能做,哪些做起来很麻烦。没有什么理想中一蹴而就的东西,就是填的坑多了,也就那样了。~
    共勉之~