• 不需要听你男票的,做你喜欢的事情就可以了~而且虽然你男票是iOS开发,但是我相信他对测试技术也一定不大了解,至多就功能测试,要学习更深入的还是要靠自己,对于无计算机基础的人来说,可以说是一个大坎。如今的行情,就算是计算机专业毕业的,也未必能混得好。还是慎重选择吧。

  • 问题已解决 at 2017年11月03日

    个人拙见~
    1.需求评审会议应该是产品,开发,测试一起参与的,这样有利于测试清晰整个产品的架构和逻辑,以及可以评估下风险,对自己设计和编写用例有很大的帮助。
    2.如果情况是测试有事没参与需求评审会议,那会后只需要给确定下来的需求文档到测试即可,并不需要再跟产品开多一次会,纯属浪费时间。测试对需求文档有疑问的地方,可以先记录下来,再找个时间跟产品确认即可。
    3.我觉得你公司在需求评审会议时有要求测试参与,这点可以看得出公司对测试有一定的看重,而这个会议的质量得自己去把握,有的人喜欢别人直接告诉他怎么做,他就怎么做;有的人喜欢参与别人的讨论中,一起开启头脑风暴。至于利弊,我想你心里也应该有个数吧~
    4.我从你的文字中看出了你的急躁,也看出了你似乎很忙碌?或许可以说是一种效率不高的表现?如果我说错那我道歉哈~其实你大可不必这么忿愤,每件事都有它的意义,耐心一点也许你会发现其中的好处,如果一点好处都没有,那就当做是放松自己咯~
    希望对你有些帮助~

  • 感谢挽尊,哈哈~

  • 给自己挽尊~哈哈😂 😂

  • 狗头

  • 哇好棒!有没有一些文章系列说明呀,代码量还是有点多的,希望能快速了解其中实现原理,然后自己实现出来~💪 💪

  • 😁 😁 谢谢称赞~

  • 😁 😁 谢谢鼓励,你也是~

  • 🍻 🍻 一起加油~

  • 我的想法是,把返回值模拟掉,然后自己本地搭建一套支付环境,或者自己拉一套代码分支,在本地做支付接口的测试~你看这个想法可实行吗?有什么其它比较好的建议你也可以说说看哦😁 😁 😁

  • 哈哈,你说的对,实际上是不需要mock的,但是支付宝微信那些没有呀,但目前项目先上的是PayPal,所以拿PayPal来练练手~看看这个过程是怎么实现的,学学习~有啥好建议吗😁 😁

  • 嗯,主要还是所处的平台太小,可施展的地方太少~你给的建议很棒,我会慢慢去实现的,争取变得优秀一点,去更好更大的平台见识更多和学习更多的东西~💪

  • 总结得很到位,对我有启发~之前处于瓶颈,不知道在自动化上还能怎么开展下去,现在看来,我还是有很多未做到位的地方~共同努力吧!

  • 楼主总结的好赞~虽然不太懂java,但是实现的方式和思路蛮赞的,我是用python作自动化的,有些思想很是可以借鉴~我仍然还是不懂怎么去持续构建,且用docker去维护测试环境似乎也不好进行,目前公司都是运维去维护的,很多东西测试都不能参与其中,不知道要做些啥改变,才可以更多的接触到更底层的东西呢?

  • 好的,我去下载看看~期待文章的下一个系列~

  • 文中说的关于测试用例的模板作用,意思是测试开发人员需要在接口测试用例上把需要的库或者参数配置好,让业务测试人员修改传参的参数即可。但每个接口传参都不一样,因此引用的库也不一样,校验返回值也不一样,那测试开发人员就需要在模板上针对接口的不同去引用不同的库和不同的校验值,业务测试人员或许懂得修改校验值但不一定懂得需要引入哪些库,这样的话,还是需要测试开发人员定义好很多配置的东西,既然都做了这么多,那自己传参岂不是更方便些?这样的话把接口交由业务测试人员好像也不大需要了?不知道我的理解对不对,还请指教下~🙋 🙋

  • 请问下,为啥不把token等加密信息封装在代码里面,而是放在了测试用例上呢?这样做会不会导致加密信息容易泄露?封装在代码上的话,判断需要带上签名的接口再调用这个加密算法即可,不知道这个方法对不对,还请指教下~🙋 🙋

  • 嗯,没关系的嘛,年轻人,多点折腾也不是一件坏事!重要的是你要有个目标,这样你才会有动力呢~加油哦

  • 16年毕业,但也已工作了两年了,实习的那一年,恐怕是我人生中最灰暗的一年吧~我也是一直都是一个人在搞测试,所以只能去网上搜索各种相关资料学习,我把testerhome的大牛们当做我的老师,深入学习和研究他们的技术贴,进而转化为自己的技能~我想我的苦也并不比你少,但即使是暴风雨我也要逆风而上~你得先坚定你的目标才能更好的走下一步,不管啥职业,保持学习和坚持不懈的品质都很重要~现在不敢说自己很牛逼,但至少比两年前的那个自己好的不止那么一点点~加油吧~💪 💪

  • 在没看到这些演进文章前,我已经研究过ApiTestEngine项目中的每一个实现方法了,其中有很多陌生的语法,也有很多不懂的方法含义,带着这些疑问来看这些文章,使我有茅塞顿开之感,且能慢慢的深入项目中体会到其中的设计思路,实在是很赞!感谢楼主的无私分享~很期待接下来的文章~☀ ☀ ☀

  • 😊 😊 有待进步呢~

  • 楼主的设计思想是,读取fiddler录制下来的接口,跟本地数据或者跟上一次录制下来的接口的字段信息进行对比,从而检验接口的正确性,是吗?那为啥不直接跟开发要一份接口文档呢,这样的话就可以直接对接口做自动化测试了,然后再集成到Jenkins上做日常监控~我看你写的代码有些复杂,花了半天时间去看了下代码,代码基本是做处理录制下来的接口信息,读写文件,操作文件夹,处理json字段等,有些方法的思路还是不错的,但是我个人觉得用这样的方式去测试接口回归接口不算是一个高效的方式~

    不知道自己有没有理解错误,也请多多指点~

  • 我曾经就是那个觉得什么都要懂,但是什么都可以不用精通的那类人~以至于在某一段时间内,我特别的迷茫,迷茫不知道还有多少我不懂的东西等着我去学,迷茫不知道下一步该要做什么…后来想通了,学百样不如精一技,真的就是找准了方向,才能更好的走下去~我的学习方法就是,勤思考,多总结~感谢楼主的分享,让我多了一个学习方法,那就是从0开始,逐步深入~

  • 已解决问题 at 2017年05月11日

    感激感激啊我已经搞定了,就是你说的这个问题☀ ☀

  • 兄弟,靠谱啊~~感激不尽,问题完美的解决了,比心~😍