项目终于有些松下来。在这个传说中这个如何高级别的项目，正好最近有在推项目质量相关的宣传，于是把这段时间项目中出现的问题从项目质量的角度进行了思考。

　　在此抛开整个项目中其他人员的工作，单纯从测试的角度来看如何去推动项目质量的把控。之所以说是推动，因为我们的开发才是系统的真正的实现者，做个不是特别恰当的比喻他们是一线的将领，军权的掌握者，因此是保证战争胜利的关键。题外话不多说，那在一个特殊的项目中如何测试去推动项目质量把控至关重要的一点就是在需求前期准确的评估好实现所有需求的测试工作量。

　　在项目开始的需求阶段就需要要对项目的需求量进行评估，权衡轻重，及时抛出测试时间和测试工作可能存在的风险。俗话说：凡是预则立，不预则废。可能需求是怎么样，系统是怎么实现，我们测试都是没有多权威的话语权，但对于测试工作量的评估，没有人比我们更了解。这个工作做好可以好说好处多多，评估好测试工作量换句话来说就是给测试足够的时间来完成测试设计和测试。在项目开始就为测试准备充足的时间，测试人员才能细致准确饿做好测试设计和测试用例编写，等到用例写到一半时才发现就算把所有的资源和时间都投入进去，根本没有按时完成的可能。然后我们的测试人员车马劳顿不停的赶工，我想这样的测试设计和测试用例本身的质量就很难保证，又怎么谈的拉上去成为项目质量的把关，其结果只有是每个测试对测试将近一半大量的需求变更不满意，对自己测试用例没有信心，对测试结果没有安全感。

　　作为一名测试，每经历一个项目，都是对自己设计测试和测试用例编写技术的积累和提升，项目中测试需要充足的思考时间，来逐步提高自己测试的能力，而不是把以前的用例库里的用例拿来粘帖复制那么简单，如果是这样，我想就算做再多的项目，也不会对个人的测试能力有什么真正的提升。而这些能力对于一个测试人员是最基本的素质，也是最精华的部分。

　　项目过程中，还有交叉测试这一环节，这是为了保证某个测试思维上的惯性而遗漏了bug，但在项目时间特别赶的时候，很多项目组就省略了这个一步，又一次弱化了对项目质量的保证。

　　我们的这个项目在前期这个工作就没有充分做好哦，导致tc编写，所有的测试人员不但加班加点，还完成不了，幸好这时pm和测试负责人及时的和pd沟通，抛出了测试存在风险，整个项目分期上线，才化解了危机。呵呵……

　　总之，能够准确的把握测试工作量，对保证项目质量，提高用例质量都有至关重要的作用，希望测试人员，尤其是项目测试负责人足够的重视，不要像小媳妇一样逆来顺受，最后的结果是咱么资源投入多，加班多，而得到的是抱怨多（其它团队人员觉得我们工作效率低，自己觉得工作的太累），最最关键的产出的项目质量低。（以上言论仅代表作者的个人观点，不代表51Testing观点）