项目管理及测试驱动的一些心得

1.对项目延期的处理方式：

   有些项目开始时非常乐观，但是到最后因为各种原因延期，主要的原因如下：

  （1） 有些灰色地带没有考虑清楚，或者没有引起重视。

  （2） 项目开始时大家非常轻松，工作不紧不慢的。到项目的后期发现要延期了，就加班加点。

  （3） 测试时发现严重的bug，一时三刻解决不了。

  （4） 设计时没有考虑性能问题，导致性能很差。

 

  解决项目延期有如下方式：

  （1） 在项目开始时尽量往前赶，超出计划时间，多给项目后期留更多时间，这样在项目后期遇到问题时由于有充足时间，导致项目延期的可能性大大减少。

  （2） 大家在从事项目的过程中，在设计阶段往往比较空，讨论讨论问题，写写文档。其实可以把这些比较空余的时间也利用起来，可以在设计阶段完成一些关键模块的原形，验证一下技术上是否可行。

  （3） 在代码开发阶段，每完成一个函数就可以上别人review你的代码，而不是在所有代码都完成后再review代码。这样把代码review的时间分散到开发阶段。

 

2.测试驱动

   最近部门在强力推行测试驱动开发，我最初有点反感，到现在完全、彻底支持。

   测试驱动要求你在编写代码前，先写测试代码，开始时测试代码肯定通不过，因为你的代码还没有写，当你的测试代码写好后（把所有情况都考虑到了），你写代码的唯一目的就是把测试用例通过。

   我觉得测试驱动有如下优点：

   (1). 在写某模块代码前，你先写测试代码，可以对你的代码的输入输出有一个全面的认识，对边界条件你也会心理有数。

   (2). 事后确保机制： 在你写完所有代码后，如果过一段时间后发现某bug,你fix调用这个bug后，你需要运行一下这个系统的所有testcase,如果有失败，则表示你的修改有问题，需要找原因，把失败的testcase通过，或修改testcase,或者修改代码。

   (3) .测试用例一般在设计阶段完成，所以在设计阶段就需要考虑可测试性。

 

   记得老大描述测试驱动时，举了一个比较贴切例子来解释测试驱动，开始时我没有明白，现在明白了。 把我们从事项目设计，开发比喻成以前从井里打水，古代井里打水是这样的，在井口有一根木头，木头上缠绕绳子，绳子的一端系上水桶，当需要打水时，慢慢转动木头，把水桶放到井里，然后打水，水桶里打满水后，再转动绳子，把水桶从井里慢慢往上拉。直到水桶拉出井口。

 

   老大说测试用例就是绳子上一个锲子，当你慢慢把水从井底拉上来时，每隔一短距离（比喻你的一段代码）你就要打一个锲子（你对这段代码写的测试用例），这样当你把水桶拉到一半，你想休息一下时，由于有锲子，所以最多只会掉下一点点，不会重新掉到井底。暗喻你的代码质量有保证，不会把所有代码都推倒从来，或者你不知道这一堆代码里，哪些代码是好的，哪些代码是不好的。

 

在实际的测试驱动开发过程中,我有如下体会:

(1) 你在设计过程中写的测试驱动有可能要往往不够,在开发过程可能要新增测试用例,因为你在设计过程中考虑的往往非常粗,只考虑某个类的接口.在实际实现这些接口过程中,会新增函数,而这些函数可能非常重要,你必须写一个单独的测试用例来测试它.

(2) 测试用例一定要认真写,考虑全面,把各种情况要考虑一边,各种边界条件也要测试到,否则你会把测试驱动开发形式化,你在按照测试驱动开发在运作,但实际上没有发挥作用. 有时候可能考虑不全面,但事后发现bug时一定要把相应的测试用例补上。

(3) 有时候你为了测试某个函数，这个函数对这个类非常关键，而这个函数是private的，因为只会给这个类的接口调用到，所以private,但是为了测试这个函数，你又不得不把它public,因为测试驱动开发你要求你的测试方法必须是public的，后来老大说这样做不好，把不该暴露的函数暴露给外面，那个时候讨论的结果是，你要么不测试它，你要测试它，就或者public这个函数，或者新增一个接口testAAA,这个函数只给测试用例用，我觉得这也不太好。后来我想了一个办法，我觉得可行，这个类把测试用例的类作为友元类或许可以解决这个问题。