• 秦浩然
    2019-04-09
    虽然 TDD 并不适合所有项目,但是将 TDD 思想放大到整个开发流程上,我总结了一套开发流程,请大家参考。

    所有人员参与需求评审 -> 测试人员编写测试用例 -> 所有人员参与用例评审 -> 开发人员按照测试用例进行编码 -> 开发人员执行用例,进行自测,所有用例通过后 -> 开发人员提测 -> 测试人员进行测试。

    其中的好处个人觉得主要有两点:
    1. 在编码前完成测试用例,可减少开发中需求变更带来的风险。因为在写测试用例的时候,会对需求进行深度分析,思考需求是否合理,在我的经验中,测试组一定会发现不合理的需求,如果这些不合理的需求在编码前就被发现,后面返工的几率就小很多;
    2. 在自测环节,开发人员保证所有用例都通过,可以减少测试环节的轮次。因为如果提测质量太差,会增加测试人员和开发人员沟通成本,如果一些基本问题能在自测环节解决,那测试人员会有更多精力放在探索性测试、压力测试、整体功能回归等测试中。

    总而言之,如果能达到“缩短发布周期,提高发布质量”的目的,都是好方法。
    展开
     6
     12
  • 叶夏立
    2018-10-08
    tdd怎么样做才能落实到项目中,我觉得这才是核心问题,当然不是所有的项目都适合tdd。不知道茹老师是否能分享一下tdd落地推动的做法?

    作者回复: 很高的问题,首先就像你说的,不是所有的项目都适合tdd,而且采用tdd对测试人员的要求会很高。我的建议是一些小型的poc项目,或者是功能相对单一的微服务开发是比较适合tdd的。另外,要推动tdd,一定需要改革整个研发的流程,这个往往是十分困难的,也正是这个原因,实际开展tdd的项目也不是很多。

    
     3
  • 刘海贤
    2019-08-10
    做到TDD这样的流程,目前国内我是不知道有哪些公司。另外,这样的研发改革,是不是开发可有可无了?因为实现这些功能测试同学都可以去完成了哈。。。
    
     1
  • a坚果
    2019-06-07
    有一本书就是《测试驱动开发》,老外写的,使用python需要,TDD的思想开发的一个项目,对这方面有需要了解和学习的可以去看看。
    欢迎大家关注我的微信公众号「软件测试艺术」,一起交流,一起学习。
    
     1
  • 秦浩然
    2019-04-08
    确实要考虑项目的适用性,如果对于试水项目、用户需求不确定的,就不太合适了。后期需求频繁变更的话,测试的维护成本也是很高的。
    
     1
  • 我是谁
    2019-02-18
    tdd感觉就是详细的单元测试,那对于测试用例的项目建立,包括持续集成,都是由测试来做。开发人员是不是就不需要写单元测试了,那开发自测用测试人员写的测试用例吗,是拉去测试这边项目吗
    
     1
  • subona
    2018-12-24
    tdd测试代码都是单元测试了吧

    作者回复: 都是直接面向代码的

     1
     1
  • 涅槃Ls
    2018-10-09
    打卡44,国庆节后 好好学习

    作者回复: 支持打卡👍

    
     1
  • 伪专家
    2018-10-08
    没有强的coding能力,不行的

    作者回复: 是的,tdd一定要求有很好的代码能力。

    
     1
  • 仰望星空
    2018-10-08
    老师讲的很系统,每篇都听,几乎涵盖了测试的方方面面。有一点就是设计安全性方面的测试能否也讲一讲呢

    作者回复: 感谢支持,后面马上会有讲渗透测试的文章

    
     1
  • 刘超 mingo
    2019-12-22
    我们写java单元测试时候都是需要注册到主测试类,这样每个人都改主测试类,提交不拼频繁,容易冲突,有没有好的团队写单元测试,避免冲突的方法?
    
    
  • Gz
    2019-10-29
    TDD这件事情实话我觉得应该是在开发自己对业务更加了解的情况下来做,现在的情况下“测试”驱动开发的话之前需要定义好规则尤其在GUI测试上,相对来说接口也还好因为前置条件是后端开发出接口文档,那么这个就是测试依据,也就是说能够先出用例,然后上持续集成平台让开发自己上测试服务自己进行测试 。在通过所有用例以后基本上也就能快测试了。
    
    
  • Kelly
    2019-10-10
    实施过程中2的测试不太理解怎么执行,此时开发代码都没写出来。
    
    
  • Geek_905bf9
    2019-07-10
    那么想问下,用例变成需求了,那么产品人员呢?需求文档呢?是不是就可以粗糙的写了呢?
     1
    
  • wangq
    2019-07-10
    会不会增加代码量,延长代码开发周期?理论上讲整体交付时间应该不会影响甚至提前
    
    
  • 口水窝
    2019-05-17
    对于TDD,我有两点要说。1是TDD对于测试人员的要求较高,至少要会百合测试,而且测试用例的粒度,是否有遗漏,测试用例代码通过率都有要求,这对于很多企业都觉得测试职业都是点点点的公司来说,根本做不到,而且从领导层面上都没有这个意识去落实的。2是TDD的推动要从领导层,甚至公司技术部的最高层从上而下去推动,这才是最难执行的,这一点也和作者想法一样,所以现实中很多无法实现。
    
    
  • 小老鼠
    2018-11-29
    您是不是把TDD、BDD、ATDD混在一起了😄

    作者回复: 本质上这三个是不同层面的东西,但是出发点和思路是异曲同工的

    
    
  • 郭小菜
    2018-11-07
    个人认为先写测试代码比较适合单一场景,如果是较为复杂业务场景先去写测试代码是很复杂的,测试代码的数量甚至多余系统代码
    
    
  • 木宇寒影
    2018-10-29
    如果代码能力不高,测试驱动开发可以先从excel用例入手,先保证开发出的功能都是符合要求的
    
    
  • 喵呜呀呵嘿🌈
    2018-10-15
    测试人员的综合能力强于开发人员,感觉TDD会更好推行也适合使用。相反则不然吧。
    
    
我们在线,来聊聊吧