追悼会（二）

               从一期结束到二期开始，中间又过了2个月，再次接收该项目，觉得以前的东西有些淡忘了许多了。于是又拿出需求仔细研读一下，突然发现以前一期已经做稳定的部分需求又有改变，还好主要是性能要求上的，没有多改内容，窃喜~新增加需求比较少才九个，又窃喜~。到最后，有喜有忧，总结一条：喜的是本次测试重点主要针对性能，不必过多注意功能。忧的是产品性能测试以前做的很少，这次如果没有什么新的创意，怕是不好过关。

          我心里头琢磨，就三人，在目前设备还得想办法腾出来才可以用；时间是三个星期，要交出测试报告和安装程序，肯定是不够的，最多拖一个星期，这是我们公司默认的规矩，没有项目不拖的。主要是性能测试，我得先着手安排。还有要吸取上次经验教训，一定先做验收测试，省得又折腾三星期就陪他们耗在安装程序上。定个初步计划，第一个星期用二天研究需求，开会定并性能测试方案，剩下三天做功能测试，主要注意新需求。第二个星期用一个人专人负责验收测试并注意功能BUG的修改，二个人去搭建源代码版本的项目并按照性能方案进行测试，并修正方案中不正确的地方。第三个星期拿到安装程序，部署安装程序版本的性能测试，并部署一台机器做稳定性测试运行7*24小时，最后拿出测试报告和最终发布的安装程序。

         哪里知道安排着好好的呢，可惜做起来处处不如意，弄的我差点心灰意冷。首先第一个星期工作的还不错，功能测试方案虽然不太满意，在如此短短时间下也算定下来了。

      问题出在第二个星期，研发部门将该项目中重要模块的同事调到项目现场去做最后一个需要现场调试的模块了，做安装的人不清楚他做的其他模块的事情，结果光一个验收测试一个星期都没接受好，居然拖到第三个星期二。第二个星期突然中途又接到写用户测试方案的事情，本人可是大姑娘上轿子——头一回写。客户监理传了个第三方软件公司模板，按照要求从测试用例库中导出用例给客户看。大家都知道我们自己写的用例有很多是不能给客户看的，不知道大家是怎么做这方面的，是否专业2套，一套给客户看一套给自己用的。只好匆匆着人写了导出程序，然后所有用过数据库查询语句的用例都一个字删，调整版本，OK，又花费我三天/2人，也就是星期二搭建源代码版本按性能方案测试就只有二天时间，时间太紧，光环境搭配就用了大约2天，根本没做过来，事情依情推到第三个星期二才算马马虎虎弄明白了个大概，也因为安装程序出来，必须开始测试安装才停止。

      其实看我上面的计划，现在分析来，有一个重大的失误：那就是没有安排缓冲，并且在指定测试时间下，我天真的以后测试产品在第二周就可以搞定，只指定了测试BUG的时间，没有考虑到修改BUG的时间问题和搭建环境要用的时间问题。其实从第二周已经很明显了，搭建环境花费时间过多，按照性能测试方案测试出来按照我们指定的测试阶段BUG等级是否停止测试来讲，就该停止测试的，出现多次死机等重大问题。由于我们也是刚制定规则，有时候自己都忘记了，执行更谈不上了，大家也知道箭在弦上不得不发的道理，更何况没有项目经理掌控的我们小公司呢。结果直到第三个星期三，我们开始安装程序性能测试和压力测试，陆续发现BUG，都没有改。持续到第四个星期终于把测试按照计划做完了，发放了一个版本。其实我们三个人心里都是悬的很，由于测试得出的数据根本不能提交客户的，匆匆伪造了数据交付了了事。也不知道我们公司和客户关系太铁还是怎么样，还是我们担心的性能问题在客户3个CPU，8G内存上跑，我们这里显示的劣势居然到目前恁是没提出什么问题来。

        想想真是做测试的悲哀，有时候真是迷茫啊。在软件测试这行呆了三年了，我反正是越来觉得，一个项目是否能成功并不在于你技术和质量有多高（当然也不能太差到一眼就可以看出问题），而在于你的销售作的有多好。这种最严重级别BUG没有改，就敢拿出去做用户验收的项目，估计着是比比皆是啊。

       打住，打住，这里是项目追悼会，不要发感慨太远。总结来说，本次项目，优点在于性能测试比较完美，并且在测试的过程中研究出针对本产品使用了Lodarunner实现并发测试的方法，也是属于我上面说的要有点创意吧。缺点是，由于给定时间太紧，匆匆定下的计划中没有给与充分的缓冲时间来修改BUG和搭建性能测试环境的时间，虽然时间紧，由于我们公司传统，我应该计划四周，并争取头的同意，应该还可以延缓一段时间，尽力把这个项目掌控好吧。其实我在这中间有些倦怠，因为我们辛苦测试的东西，居然被说成不计入绩效，闷，反正好坏一个样子，估计谁也没有心情认真去掌控了。看来孔方兄的力量还是比较大的。所以从项目管理的经验来讲，绩效也是钱可以刺激项目的顺利进展是很正确的。

最后，需要注意的是，尽量不要让研发人员地理空间距离太遥远，不太好沟通。

这次这个验收测试就让我组一个人忙活了一周，真是TNND一个恨字啊~