|
（注：蓝色的部分是我们部长的批语，
 ）
如何提高项目质量
我们这个项目关于测试试过了很多方法，但是效果并不是很好。
项目前期，测试主要是交叉测试，最后由项目经理再把把关。但是交叉测试后，到项目经理手的时候低级
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
做一次就够了，如果之后还出现类似格式问题，那就是
PG
人员的责任
每一个测试阶段测出的问题，绝对不能遗留到以后的阶段，否则就是测试力度不足！
2.
测试流程的改进
代码格式：
使用Eclipse的format功能，格式化代码。
使用checkStyle插件
对于空格：
如果日方没有要求的话，完全没有必要作，会浪费很多的时间。
而且容易给测试人员造成作了很多工作的假象，认为没有什么可以做了。
如果是代码规范相关的空格，一定要做！客户没有要求，就得按照公司的要求。
这是对编成人员的基本要求。
3.
白盒测试到底好不好
对于代码
coding
人员出身的测试人员，做白盒是非常好的。通过白盒可以更好的了解业务。这样虽然会浪费一些时间，但对质量会有很大的影响。
但是对于不是很了解代码的测试人员，白盒测试只是在作代码格式的
check
，这些
check
完全可以交给工具来做。这样的白盒是很不好的，根本就不需要做，把更多的时间和精力
放在黑盒上会更好。
不作白盒测试会造成项目质量很差吗，这是没有什么根据的。就像我们项目的第三方测试，他们没有做白盒，直接作的黑盒，做的比我们好多了。
所以，综上所述，项目经理不应该把白盒测试作为每个测试人员的常规工作来要求，应该让测试人员自己选择适合自己的测试方法。
通常编码完成后，需要自己做白盒测试。这是必须的！编码不仅仅是把代码写出来，还要保证
写出的代码的正确性。不要把自己的疏漏留给别人测试！
4.
引入
Junit
单元测试到底好不好
这个我也说不清楚，个人经历就是写
Junit
比较浪费时间，纯粹是在糊弄日本人
任何测试工具都有自己的优势和作用。需要根据项目情况做取舍。
用太多的测试工具，成本肯定会增加。
5.
测试应该从哪里入手
项目总结时在谈，待续。
四
.check
的种类
1.
单独
check
必须入力，半角，英数字，数字，日期，等
2.
关联check
日期from < to
相互关联项目的入力
check
（例如：价格和通货
code
价格入力通货则
code
必须入力）
重复入力check
3.
整合性check
哪些字母是不能入力的等（例如：送信要否，只能入力Y或N）
4.
存在check
code
名称master的存在check
基本master的存在check
5.
业务check
和业务相关的
check
，这部分不好分析，只能靠详细设计式样书
6.
排他
check
DB
登录前作是否存在
check
DB
更新，删除前作排他
check
五
.
项目质量和项目周期的关系
1.
充裕的项目时间就会有好的质量吗
看到这个，我们讨论了
mis
系统，
Mis
系统的时间很充裕，但是质量却不是很好。
并不是时间越多，质量就越好。
时间和质量不是线形关系。时间太少则测试不足，太多则浪费。
比如单体测试（包括写测试式样书）的时间和编码时间基本相当。
2.
多少遍的测试是最好的
我们这边测试，基本上都是测试一遍就完事了，对于自己测试过的，如果要求
你在测一遍的话，那就没没有什么热情了，第二遍测试的效果不会很理想的
所以，我们应该重视第一遍的测试。
每个阶段只有一次测试，绝对不能有多次的想法。
3.
如何保证第一遍的测试质量
1.
单体测试式样书
现在大家很多人都认为单体测试式样书是写给日本人看的，真正在测试的时候
都把它给忽略掉了。
最重要的是测试式样书的质量！
2.
抓图
我认为抓图是一项非常好的测试手段。
首先，他会保证测试人员对大体的业务途径都测试过了。
其次，狠抓覆盖率。每个途径必须要有一张图片。
最好，能够保留证据。
抓图是一种测试监督手段，根据人员的怎任感高低情况可以取舍。
3.
测试数据是否需要保留
如果是日方要求的话，那就必须保留了，但是如果是我们自己做的单体测试，
那么测试数据就没有什么作用了，因为抓图是很费时间的，再保留一下测试数据
那就会给测试人员增加很多的工作量
抓图虽然会增加工作量，但只是简单的保留的话，应该不会很浪费时间。
基础的测试数据通常需要保留，特别是比较复杂的数据
4.
如何保证测试的进度
如果制造人员写的代码很差，测试人员随便按一下按钮就有问题的，这样一定会
影响测试进度的
所以我个人认为以测试为基准的开发是非常好的开发方式。
有多方面因素。编码质量，测试式样书质量，技能水平，责任心，任务安排等等
4.
什么才是一个好的测试体系？
A.
我个人认为一个好的监督体系是必不可少的。
B.
好的测试工具是有很好的辅助效果的。
C.
一定要要求测试的覆盖率，确定每条路都侧过了。
我感觉应该还有很多，等到项目总结时在说吧。
（以下是我们部长的总结）
总结
编码完成的标准，不是编码编写完成。应该是经过自测（白盒、黑盒），自认为没有问题的程序。
通过自己调试，测试到各种情况，能够按照设计的要求和逻辑正确的运行。
根据编码人员技能水平、责任心的高低，提交的代码质量就有所不同。
测试式样书写的质量好，对测试人员的要求就低，只要严格按照测试式样书写就可以了。
测试式样书写的不好，测试质量很大程度上依赖于测试人员的水平和责任心。
写好测试式样书，需要对业务的全面把握，也需要一定的技术基础和开发经验。
如果有很好的例子作参考，可以有效地提高测试式样书的质量。
测试密度、
Bug
摘出率等，都有标准的要求。这是提高项目质量的硬性指标和有手段。
过适当的手段，提高员工的责任心，调动大家的积极性可以有效地提高程序质量。
如：根据
Bug
数评出最佳和最差，进行奖惩（书面或金钱）
|