关于项目的一些感想

   最近，十分荣幸的参加了公司一个新项目的测试，“一个新项目”，估计部分听到会很兴奋，这意味着新的挑战，公司新的发展，
个人新的机遇。对于一个老油条来说，事实却是刚刚的相反，这意味着弯路又要再走一次，失误再面临一次，失望在出一次。可能大
部分人会很鄙视的说，这人是来捣乱的吗？然后脱离这个问题答案，更加多的是事实。
      进入项目的测试，好兴奋，听到开发已经提交了全部代码，因为之前已经等了2，3个星期了；看到了程序已经发布出来，内心
十分的感动，毕竟终于可以开始测试了，这个的绩效估计不会杯具了。开始只持续了一会问题就来了，打开设计文档，里面的描述，只
能用一个字来形容“晕”，居然一点业务的逻辑都没有，只有部分修改的库表（注：这个项目是原有项目的升级版本）。于是有点疑虑的
问了一下，到底测试目标，如何判定测试能否结束。结果从上头返回的结果是，先开始吧，写测试用例先，项目紧张，开发忙得很，没那么
多时间去做文档，边测试边问吧。既然领导这么说了，那就只能照做拉，因为牢骚也发过，又能如何呢。凭借着经验，开始着页面用例的
编写，由于设计实在不清楚一点逻辑，只能每一下都询问看法，库表结构、查询数据库SQL、业务逻辑，什么都得跟开发沟通。刚开始
开发的MM会了一句话，就离开了QQ，甚是郁闷。无奈之下，只能在每天测试的日报中向上头反映解决了，日报果然是一个解决方法啊，第2天
开发MM乖乖的配合。当然日报要把问题写清楚，就天在这个模式下，一直在写用例，但是自己就有一个疑问了，用例是出来了，但是
自己在写什么呢。开发告诉我的，都是该页面的相关SQL和库表，自己都是根据经验去编写用例。于是问题就出现了，页面的业务逻辑关系，
在一点都体现不了，尽管，我是完成了用例的编写。
      对于新项目，这个情况，估计大部分人都有遇到过。不同的公司，出现的情况一样。有些人把这些问题归究与人手不足。难道永远
都是这个原因吗。这个时候，就会有些人站出来了，“计划赶不上变化”成了最好的解析。第一次可以这样，第二次可以是这样，那么第三
次之后，应该是否从过往项目的过程中吸收经验呢，项目的经验总结体现在那里呢？而且带领项目的都是公司里面资历有相当的老员工了。
这些情况真没遇到过吗？是计划得不好？这个也有一定的理由，IT人员流动大，当领导摸好了手下人员的能力后，各位都开始了谋划自己的
新前途了，如果又一批新人到了，能力要重新摸清。如果计划定制时候，可能会造成偏差。对项目可能遇到的困难准备不足？一个我看到的缺点
是项目的领导过分身兼多职了，导致结果是，他们应付不过来工作，出现的情况，估计大家都知道了。

    

     哈哈上面讲到管理上去了，返回到测试，需求文档和概要设计，详细设计都没有，去写测试用例，这样的用例一点意义都没有。为什么？

用例的作用就是让测试人员自己知道什么样的逻辑，自己已经考虑并在用例中涉及到，什么样的逻辑还没进行设计，一目了然。用例的一个重

要目的就是帮助测试人员整理自己的思绪，因此没有需求文档和设计，只根据自己的经验或者开发人员的口头讲述来编写用例，这样的工作流，

真的太儿戏，太没计划性了。这里提到计划性不得不提，导致项目走向了这样的一个景况，不是计划出现问题，还能怪谁呢。