关于测试驱动开发的思考

关于测试驱动开发的思考

         测试驱动开发（Test Driven Develop）作为敏捷思想的重要组成部分，将开发和测试在同一时段完成，我认为是一个很不错的想法，尤其是经历了无数测试后的返工以及开发中的疏漏后，测试驱动开发将作为以后开发工作中首当其冲的选择。

         据我所知，这里有几个误区需要纠正，其一：敏捷开发的宗旨是高效和高质量，降低开发成本，它是有很多前提条件的，其中之一就是开发人员对敏捷开发的认识水平，所以并不是说敏捷就一定更优，如果能够通过传统方式达到相同的目的（明显传统开发有过多的理性行为假设，需要太多的改进），一样是可行的；

其二，测试驱动开发并不是去准备无处不在的测试用例，不是说覆盖所有的理论可能分支才算是测试，测试用例是为了无法通过测试而制定的，将测试人员的心态结合到开发人员中，是非常重要的优势；

其三，文档是记录方式，并不是交流方式，当文档成为交流方式时，要重新考虑团队的开发状况以及沟通成本；

其四，编写测试用例很容易让开发人员焦躁，从下往上的测试用例的编写，对很多人来说可能是一个灾难，尤其在无法正确估计将来可能所带来的成本时，PM很难说服开发人员去采用TDD的方式。这时候增加测试用例的优先级，合理安排sprint显的尤其重要。对于开发人员来说，一次从原则上很简单的返工往往是毁灭性的，违背了的DRY的原则，让他们认识到这一点后，去重新理解TDD的价值，至关重要。

其五，如第四点所说，从下往上的测试用例的编写对有些人是不适用的，按照用户故事细分，为测试用例区分优先级别，制定更加有针对的测试用例，将会达到事半功倍的效果。

 

         关于UI/UX的测试驱动开发方法，界面迁移的测试代码量往往是重复而且冗余的，很多时候没有太大的意义，UI的测试方法往往通过数据跟踪以及用户反馈来进行评估。测试开发的增量更新有些时候非常不适用，对于UI/UX的设计开发方法，一开始的建模十分重要，，如何迁移是一个方面，实际上迁移所带来的问题是测试驱动开发针对UI设计的关键步骤，举例说明，如果该界面增加一个功能点，通过该功能点进行界面迁移的时，设计最不想看到的情形是什么样的。

        

         利用敏捷开发重新认识工作成本的评估，是十分重要的，IT行业工作量难以衡量并不能成为普遍加班的借口。