关于测试结果的质量评估的前提条件

　　测试过程结果质量的评估并不是一件非常容易的事情，少在现在的测试过程任务来说，测试过程任务的可观察性及其质量的可评估性并没有想象般的那么显而易见。虽然现在软件工程角度对于测试过程任务的划分来说，其可见性和观察性已经比以前的项目有着非常大的改进。但测试过程结果本身来说，质量的评估并不是非常的容易，所以导致效率的评估也是一场空谈。对于基本相同的需求来说，测试过程的结果并不一定有一个可以很容易评定的标准，比如，是占用内存大，运行速度较快的程序比较好，还是占用内存小，运行速度较慢的程序比较好呢？

　　当然，这是少在两个程序都是在可以正常运行的情况下的比较。所以有一个低标准：可以正常运行的程序肯定要比不能正常运行的程序要好，虽然也许不能正常运行的程序有着非常优良的架构，有着非常优良的设计，有着非常好的编码习惯及有着非常好的文档，但有一点，重要的一点，不能正常运行，所以，尽管可以正常运行的程序在结构上要稍稍欠缺一些，在设计上可能并没有照顾到方方面面，也许编码习惯会因这个测试组成员的个人差异而有不同层次的参差不齐，或者在一定程度上文档也没有完整性，但这个程序的大的也是重要的部分在于可以正常运行。所以，在对于测试过程结果质量的评估的低标准应该是测试过程结果低限度的符合需求并且可以正常的运行。

　　关于测试过程结果质量的评估的需求标准

　　从另一角度来说，测试过程结果低符合标准可以正常运行后，可以从需求角度考察测试过程结果，对于测试过程结果来说，完完全全的符合需要的情况是非常非常的少，一般情况下总会有或多或少的不合适，当然，对于测试过程结果与需求的评定方面可以从功能点考虑，当然，功能点可以适当的细，这样，才能比较容易的观察到测试过程结果与需求的偏离度。当然，可能有些时候一些功能点所占的比重并没有其它某个功能点所占的比重那么大，但一般情况下，在系统越大的时候，功能点的比重越可以看得平均，在此，相对来说，大系统的需求偏离度的判定比小系统要容易一些。当然，这是从理论的角度考察整个测试过程项目后得出的结论，尤如从5000米的高空观察中国，发现除了人驾驶着汽车朝着不同方向运动外，很难再得到其它方面的信息。所以，从高屋建?的角度来观察测试过程结果的质量，所得出的结论只会有一定的参考性，却也不能完全作为的标准。

　　从系统的整体架构方面评估测试过程质量

　　系统的整体架构方面来说，需要有稳定性和稳固性两个方面。

　　对于稳定性，比较合适的比喻是一个系统的整体架构在确定之后，对于需求的变更，可以产生不同的设计的变更，也可以产生需要分析方面的某种程度的反作用力，犹如现在的建筑，当确定了钢筋混凝土结构及房屋的架构设计后，对于房屋的一些其它方面的需求比如窗户的设计或者是屋内布局的设计不影响到已经确定的房屋的架构设计，系统的架构的稳定性越好，则系统相对于需求的可变化性越小，相对来说，则系统适应大规模的需求变动的适应性越差，但在这种情况下，系统的稳固性越好，有利于整个测试团队的磨合及整个测试团队的前进方向的专一性及成长方式的专一性。

　　当然，大规模的需求变更并不是不允许，大规模的需求变更可能会引发系统整体架构的剧烈变动，具体变动未知，所以说系统的架构的稳定性和稳固性与系统架构的可适应性是相斥的一个方面，简单的说，一个系统的稳定性和稳固性越好，则系统架构的可适应性越差，可适应性越差带来的影响是架构的变更成本的上升及开发团队的重新建设或者测试团队整体方向上的变更。及测试团队中成员的学习成本的上升。当然，上面所提到的系统的架构的设计的稳定性和稳固性及适应性的关系是在大规模的变更时的一种情况，比如从JAVA团队转型为C团队。