[计算机]如何提高项目质量.docVIP

（注：蓝色的部分是我们部长的批语，） 如何提高项目质量 我们这个项目关于测试试过了很多方法，但是效果并不是很好。 项目前期，测试主要是交叉测试，最后由项目经理再把把关。但是交叉测试后，到项目经理手的时候低级bug非常之多，让人怀疑是否是测试过的代码 到后来项目采用小型测试组，由三位人员进行专门的测试，但是这种测试对测试人员要求比较高，要懂业务，细心，有责任感。如果具备这样的条件那测出来的质量非常高。否则，效果一般。但和交叉测试相比，那是好了很多。 现在比较严重的问题是大家都不知道如何进行测试，测试应该从哪里开始。 测试到什么程度才是完成测试了。 ? 一.业务细节 对于理解业务，应该从下面的资料入手： 1.DB ER图 2.数据流程图 3.画面迁移图 4.画面layout 5.DB字段 主业务表中有一些Flag会表达具体的业务信息。 ? 二.测试 1.交叉测试 项目感悟：开发人员之间的交叉测试根本是在浪费时间。测试效果一点都不好。 原因分析： 1.测试的覆盖率很低，基本上都是瞎跑，大体的地方没有问题就算测试完成了。 2.大家都是开发人员，主观意识很浓，过分的关注白盒，黑盒测试不足。 3.对测试的方式和方法不了解，不知道如何进行测试，怎么测试。 4.交叉测试人员既是开发人员又是测试人员，所以就会出现只要测出问题，就马上修改但是这样就把测试任务放在一边，不管了。 5.制造人员主观认为自己应该对自己的代码负责，很多精力都用在写自己的测试，别人的也就意思意思看看，大体跑没有问题就ok了。 6.交叉测试基本上是第一次测试，测出的问题会很多。但是人都有惰性的，尤其是测出的问题很多，很低级时，就厌倦了，不想测下去了。草草了事。 如果测试式样书质量不高，交叉测试不会有好的效果 责任心和积极性不足也是一个重要因素 ? 2.小测试组 项目感悟：要求测试人员的水平比较高，并且要有足够的责任感和业务理解能力。 原因分析： 1.对业务的理解很重要，站在客户的方面去想问题。这就要求测试人员有足够的业务理解能力 2.测试人员不了解业务的时候，就会去问开发人员，如果没有自己的见解的话， 那业务问题也很难测出来。 3.测试人员如果对程序一点都不熟悉，光跑画面的话，那么就不能确认获取的数据到底对不对了 测试组测试，一定程度上提高了大家的测试工作的责任感 ? 3.日本的测试 日本的测试分成四个部分：日本eland，NSP，第三方测试，及最终的客户 A.NSP：测试大体上都是从结合测试开始，由于日方对业务更加了解，那么测出来的问题很多都是和详细设计相关的。测的主要是功能的实现。 B.第三方测试：从基本的画面项目开始，测试的覆盖率很大，基本上每个测试点都会测一遍。并且bug票的书写非常规范，描述的现象很清楚。 通过他的bug票，明显可以感受到测试是多么仔细认真，我们应该好好的学习。 C.最终的客户:大体跑一下画面，用实际的业务测试，看看用起来是否顺手。 日本的测试为什么比我们的好，我认为主要有两点，首先他们比我们更了解业务，其次他们的测试覆盖率非常高 他们可以做到（非常了解业务，测试覆盖率很高），我们为什么做不到？ 归根结底，我们对业务的学习还是不够，编写测试式样书的能力还不足！ ? 三.测试的方法方式 1.正常的途径： 同行评审?-?代码review（代码格式）?-?白盒测试（业务级，对照详细设计）?- 黑盒测试?-?代码review（代码格式）?-结合测试 代码review做一次就够了，如果之后还出现类似格式问题，那就是PG人员的责任 每一个测试阶段测出的问题，绝对不能遗留到以后的阶段，否则就是测试力度不足！ ? 2.测试流程的改进 代码格式： 使用Eclipse的format功能，格式化代码。 使用checkStyle插件 对于空格： 如果日方没有要求的话，完全没有必要作，会浪费很多的时间。 而且容易给测试人员造成作了很多工作的假象，认为没有什么可以做了。 如果是代码规范相关的空格，一定要做！客户没有要求，就得按照公司的要求。 这是对编成人员的基本要求。 ? 3.白盒测试到底好不好 对于代码coding人员出身的测试人员，做白盒是非常好的。通过白盒可以更好的了解业务。这样虽然会浪费一些时间，但对质量会有很大的影响。 但是对于不是很了解代码的测试人员，白盒测试只是在作代码格式的check，这些check 完全可以交给工具来做。这样的白盒是很不好的，根本就不需要做，把更多的时间和精力 放在黑盒上会更好。 不作白盒测试会造成项目质量很差吗，这是没有什么根据的。就像我们项目的第三方测试，他们没有做白盒，直接作的黑盒，做的比我们好多了。 所以，综上所述，项目经理不应该把白盒测试作为每个测试人员的常规工作来要求，应该让测试人员自己选择适合自己的测试方法。 通常编码完成后，需要