【转贴】几个制约测试发展的问题
相对软件开发理论的成熟度来讲，测试理论还非常的稚嫩。（当然，和工业开发理论比较，软件开发理论也是非常的稚嫩。）测试行业的兴起，将会有很大一部分取决于测试理论的成熟度。现在的测试（技术和管理）还有一些问题是没有定论的，也是我在一直思考的问题（也许这些问题已经有人解决，小生孤僻寡闻而已），下面将这些问题作一个总结，以期望能在以后找到解答。
1.测试的终点在哪里？
作为一个工程过程，无法清晰的定义活动的结束准则，就像在大海中航行的船只，没有自己的目的地，是一件很可怕的事情。测试就是这么一条没有目标的船。
最合适的测试结束的准则应该是缺陷数控制在一个可以接受的范围内。但是在实际的过程中，是永远无法知道未发现的缺陷的数量的，虽然会有方法可以估计出未知缺陷的数目，可是其准确性和所付出的成本使其的可行性并不高。所以虽然这个准则最合适，但是并不实用。
另外一个测试结束准则是以过程为衡量标准。按照测试过程走完了相应的步骤，完成了该作的工作，就算测试完成。这种测试结束准则和没有准则没有什么两样，根本没有达到验收的目的。换句话说，该结束准则有一个假设，这个假设就是已定义的测试过程是完全有效的，在这种情况下，才能采用这个准则来结束掉测试活动。所以这个准则虽然不是很准确，却是最常见的测试结束的准则。
还有一个也是很常见的准则，就是时间线结束准则。到了dead line了，不管怎么样，就算结束。这种准则也会经常在一些不规范的公司遇到。个人认为这种准则对测试的危害最大，遇到组织里是以这个准则来结束测试的话，测试质量只能靠上帝来保佑了。
综上所述，如果能够定义出一个既能作为客观的评价标准，又比较容易实施的测试结束准则的话，是将会对测试理论的成熟有深远的影响。
2.如何评价测试员的优劣
作为测试活动的行为主体，测试员的优劣直接影响测试活动的优劣。可是如何才能评价测试员的优劣呢？
不能以发现缺陷的数量去衡量测试员的水平，这样做只能将测试引到以发现表面的缺陷为主的活动。
不能编写的文档的数量时间比去衡量测试员的水平。
不能以被接受的缺陷数去衡量测试员的水平
优秀的测试员能见微知著；
优秀的测试员有独特的思维方法，能不断创新测试方法；
优秀的测试员能清晰的将缺陷描述清楚，并能说服开发人员改正；
优秀的测试员能从用最小的信息获得对系统的最大理解；
优秀的测试员需要思维灵活，知识全面。
这些都是定性的分析，有很大的主观因素在里面，如果能有一种方法，能将这些与结果挂钩，进行量化，将会对测试方面的人力资源管理有很大的帮助。
3.如何体现测试的价值
测试作为开发的一个服务部门，能不能很好的体现自己的价值，这将是以后测试能不能良性的发展的一个重要因素。
体现测试的价值有很多的难点，下面我逐一说明：
1.测试的成果多是无形资产，很难衡量。产品质量和企业形象这类资产可以说是测试能产生的最直接结果，但是这种资产，将会很难度量。测试能产生的第二类成果是提高开发的能力，也同样属于难以衡量的结果。
2.被识别的测试成果很容易被忽略是测试的价值。一提到优秀的软件，很多人首先想到的就是高超的程序设计，娴熟的编程技巧，成熟的软件过程，很少人想到是经过了严格而全面的测试。测试总是生存在这个被遗忘的角落。
3.过多的体现测试的价值会造成开发和测试的对立。测试能产生的最直观的结果就是缺陷，而缺陷恰恰是证明了开发的不足（虽然说是对事不对人，但是谁有能看到自己写的程序被人吹毛求疵，还拿结果来作为其工作成果而保证不大动肝火呢？）过多的强调测试价值，会让敌对的情绪滋生，所以明智的产品经理，往往会弱化测试的功效，而趋向于建立起一种平衡。
所以，现阶段测试价值的体现，往往决定于领导者对测试的态度，测试的价值也只有在他的心中能有所体现。这种不能得到大多数人广泛认同的局面，明显是不利于建立测试的权威性和其它人员对测试活动的支持的。找到恰当的体现测试价值的方法，是困扰测试经理和对测试有良好认识的产品经理的一个大问题。
4.有关测试模式的思考
对测试模式的想法完全起源于设计模式。既然能够把复杂的体系结构设计能抽象，总结成这么一套东西，为什么不能对测试活动也如是观之呢？
现在我对模式的理解还不是很深，也没有很多的测试经验，所以到现在为止，只能抽象成一种模式，我将其命名为包含模式（include）
模块A中引用模块B作为A的子功能，这时的测试方法应该是先测试B模块，然后再将B模块中的任何一个路径作为A的一部分来测试A模块，这时B模块中的任何一条路径，已经被同化成等价类（虽然在B模块的测试中，它们可能不属于同一个等价类）
（这只是一种思维构想，希望能够抛砖引玉，能将这个体系完善起来）
5.测试与开发的关系
测试到底和开发处在怎么样的一个关系下才能够较好的产生测试应该达到的效果呢？
测试部门独立于开发部门。这种模式可能源于传统制造行业的QC和生产部门的分开。其目的是为了保证测试过程和测试结果的客观性和有效性。这种模式相当于把测试和开发分成两个泾渭分明的活动，并没有过多的考虑两种活动之间的互为补益。在这种模式下，很可能演变成测试和开发之间的对立，或者增加测试和开发之间的沟通成本。
边测试，边开发。这是XP的轻量级开发过程所倡导的，现在的测试驱动开发理论就是符合了这种模式。采用先设计测试，再进行开发，当开发的软件通过了所有的测试，软件就完成了。这种方式其实并没有规避自己测试自己代码所产生的局限性问题，只是将思维的顺序作了些改变，降低了思维定式对软件开发产生缺陷的影响。
测试部门属于研发中心，但独立于项目组。这种模式保证了测试与项目组之间的最终目标的一致性（高质量的软件产品），能有效的降低沟通成本，又能保证测试人员有一定的独立性，不会过分的受产品经理的控制，避免测试失效现象产生。但在这种情况下，相比两个部门独立，测试的结果有可能不会被项目组所重视，需要频繁的进行协调，才能及时处理缺陷。
广告秀: 希望广大热心的同行和企业支持和赞助一台服务器和网络带宽，维持本论坛的运行。希望有更多热心的朋友帮助我们。 请各位访问中国软件测试社区规定 时间线结束准则,深有感触,深受其害. Originally posted by luckhj at 2004-10-15 05:16 PM:
时间线结束准则,深有感触,深受其害.
那是因为你用一个测试人员的思考角度去看待产品发布,换个角度,比如销售,宣传等等,你就可以明白dead line的重要了,毕竟软件是要卖的....
路漫漫其修远兮，吾将上下而求索！
路漫漫其修远兮，吾将上下而求索！ 我的公司测试部门有非常强的独立性，但是慢慢的在演变，现在更倾向与测试与开发的融合。确实独立性会引起测试和开发的对立，而且这种对立带来的负面作用远远不是沟通就能解决的。但是我认为测试和开发之间的沟通问题和测试的独立性没有必然的关系。只能说目前的软件测试组还没有达到软件开发租的成熟度，一方面在技能上，另外一方面在管理上，都跟不上。技术上不符合要求必然会遭到开发人员的质疑；管理上如果又不能及时输导，后果必然是积怨越来越深。最近我加入了一个mini的项目，在良好的沟通下，提出的问题只要能描述清楚，并将可能产生的后果说明白，开发人员非常乐意改，开发对测试的评价也非常的高。总之测试不要“贫穷而孤立”，而是“富足而团结”，首先要提高自己，和开发建立良好的沟通，大家都是为了产品好，有什么不好谈的？ 呵呵
参考国际成熟测试
1.其实关于测试问题呢，在国际上是公认的，没有一个客户愿意使用没有经过专门测试的产品，而且还要考核你的测试，看你发现了多少bug，写了多少用例，测试了多长的时间，以及发现bug的情况等方面。业界的标准是100行里约有4-6个bug。2.测试价值的体现我觉得是中国观念的问题，因为这个是常识性的问题，软件不经专门的测试，是不能提交给客户，以及客户也不会接受没有经过专门测试的产品的。这是软件质量管理中最重要的一个部分。
3.测试模式的话，我还是觉得不要有专门的测试部门，而是根据每个项目分别成立各自的测试组，其中要有对项目需求了解的，有专门的代码专家，还要有经验人士，不要专门的测试部门来进行，就能避免很多问题，而且还有很多好处。 ding 做测试时间不久,觉得还是很值得付出. 希望国内的测试早日走上正轨，大家好好努力，爱测试，爱IT,爱国 哇,这帖的时间好久了啊.:time: 04年到现在已经5年了，今天看前辈们5年前的总结，感觉测试的发展很缓慢啊！ 不知道描述缺陷的能力怎么去培养？？我之前在这关上面已经载过一次 大环境不配合，小环境又有何作为那 太强了,赞一个 :) 收获不少啊 特别关注前3条! 感觉很必要. 谢谢！ 同感啊 回复 1# szxutao
赞一个 2011年
页:
[1]
2
