你为什么还只是一个测试的"菜鸟"
笑看软测明天，谈谈几个制约测试发展的问题相对软件开发理论的成熟度来讲，测试理论还非常的稚嫩。（当然，和工业开发理论比较，软件开发理论也是非常的稚嫩。）测试行业的兴起，将会有很大一部分取决于测试理论的成熟度。现在的测试（技术和管理）还有一些问题是没有定论的，也是我在一直思考的问题（也许这些问题已经有人解决，小生孤僻寡闻而已），下面将这些问题作一个总结，以期望能在以后找到解答。
1.测试的终点在哪里？
作为一个工程过程，无法清晰的定义活动的结束准则，像在大海中航行的船只，没有自己的目的地，是一件很可怕的事情。测试是这么一条没有目标的船。
合适的测试结束的准则应该是缺陷数控制在一个可以接受的范围内。但是在实际的过程中，是永远无法知道未发现的缺陷的数量的，虽然会有方法可以估计出未知缺陷的数目，可是其准确性和所付出的成本使其的可行性并不高。所以虽然这个准则合适，但是并不实用。
另外一个测试结束准则是以过程为衡量标准。按照测试过程走完了相应的步骤，完成了该作的工作，算测试完成。这种测试结束准则和没有准则没有什么两样，根本没有达到验收的目的。换句话说，该结束准则有一个假设，这个假设是已定义的测试过程是完全有效的，在这种情况下，才能采用这个准则来结束掉测试活动。所以这个准则虽然不是很准确，却是常见的测试结束的准则。
还有一个也是很常见的准则，是时间线结束准则。到了dead line了，不管怎么样，算结束。这种准则也会经常在一些不规范的公司遇到。个人认为这种准则对测试的危害大，遇到组织里是以这个准则来结束测试的话，测试质量只能靠上帝来保佑了。
综上所述，如果能够定义出一个既能作为客观的评价标准，又比较容易实施的测试结束准则的话，是将会对测试理论的成熟有深远的影响。
2.如何评价测试员的优劣
作为测试活动的行为主体，测试员的优劣直接影响测试活动的优劣。可是如何才能评价测试员的优劣呢？
不能以发现缺陷的数量去衡量测试员的水平，这样做只能将测试引到以发现表面的缺陷为主的活动。
不能编写的文档的数量时间比去衡量测试员的水平。
不能以被接受的缺陷数去衡量测试员的水平的测试员能见微知著；的测试员有独特的思维方法，能不断创新测试方法；的测试员能清晰的将缺陷描述清楚，并能说服开发人员改正；的测试员能从用小的信息获得对系统的大理解；的测试员需要思维灵活，知识全面。
这些都是定性的分析，有很大的主观因素在里面，如果能有一种方法，能将这些与结果挂钩，进行量化，将会对测试方面的人力资源管理有很大的帮助。
3.如何体现测试的价值
测试作为开发的一个服务部门，能不能很好的体现自己的价值，这将是以后测试能不能良性的发展的一个重要因素。
体现测试的价值有很多的难点，下面我逐一说明：
1.测试的成果多是无形资产，很难衡量。产品质量和企业形象这类资产可以说是测试能产生的直接结果，但是这种资产，将会很难度量。测试能产生的第二类成果是提高开发的能力，也同样属于难以衡量的结果。
2.被识别的测试成果很容易被忽略是测试的价值。一提到的软件，很多人首先想到的是高超的程序设计，娴熟的编程技巧，成熟的软件过程，很少人想到是经过了严格而全面的测试。测试总是生存在这个被遗忘的角落。
3. 过多的体现测试的价值会造成开发和测试的对立。测试能产生的直观的结果是缺陷，而缺陷恰恰是证明了开发的不足（虽然说是对事不对人，但是谁有能看到自己写的程序被人吹毛求疵，还拿结果来作为其工作成果而保证不大动肝火呢？）过多的强调测试价值，会让敌对的情绪滋生，所以明智的产品经理，往往会弱化测试的功效，而趋向于建立起一种平衡。所以，现阶段测试价值的体现，往往决定于对测试的态度，测试的价值也只有在他的心中能有所体现。这种不能得到大多数人广泛认同的局面，明显是不利于建立测试的权威性和其它人员对测试活动的支持的。找到恰当的体现测试价值的方法，是困扰测试经理和对测试有良好认识的产品经理的一个大问题。
4.有关测试模式的思考对测试模式的想法完全起源于设计模式。既然能够把复杂的体系结构设计能抽象，总结成这么一套东西，为什么不能对测试活动也如是观之呢？
现在我对模式的理解还不是很深，也没有很多的测试经验，所以到现在为止，只能抽象成一种模式，我将其命名为包含模式（include）模块A中引用模块B作为A的子功能，这时的测试方法应该是先测试B模块，然后再将B模块中的任何一个路径作为A的一部分来测试A模块，这时B模块中的任何一条路径，已经被同化成等价类（虽然在B模块的测试中，它们可能不属于同一个等价类）
（这只是一种思维构想，希望能够抛砖引玉，能将这个体系完善起来）
5.测试与开发的关系测试到底和开发处在怎么样的一个关系下才能够较好的产生测试应该达到的效果呢？
测试部门独立于开发部门。这种模式可能源于传统制造行业的QC和生产部门的分开。其目的是为了保证测试过程和测试结果的客观性和有效性。这种模式相当于把测试和开发分成两个泾渭分明的活动，并没有过多的考虑两种活动之间的互为补益。在这种模式下，很可能演变成测试和开发之间的对立，或者增加测试和开发之间的沟通成本。边测试，边开发。这是XP的轻量级开发过程所倡导的，现在的测试驱动开发理论是符合了这种模式。采用先设计测试，再进行开发，当开发的软件通过了所有的测试，软件完成了。这种方式其实并没有规避自己测试自己代码所产生的局限性问题，只是将思维的顺序作了些改变，降低了思维定式对软件开发产生缺陷的影响。
测试部门属于研发中心，但独立于项目组。这种模式保证了测试与项目组之间的终目标的一致性（高质量的软件产品），能有效的降低沟通成本，又能保证测试人员有一定的独立性，不会过分的受产品经理的控制，避免测试失效现象产生。但在这种情况下，相比两个部门独立，测试的结果有可能不会被项目组所重视，需要频繁的进行协调，才能及时处理缺陷。
