如何衡量测试结果？

xiaoyaoke

当前我的工作性质应该是介于GUI测试和Funcation测试之间，也是使用QTP，但测试结束后却以pureCoverage这款软件计算出来的funcation coverage 和line coverage为工作成果主要衡量标准，并要提交未覆盖的funcation原因
工作在界面层，却要研究代码层的未覆盖原因，个人认为很不合理，不过却想不到更合理的衡量办法
请问大家在进行同类测试的时候是用哪项指标来衡量测试结果的？
谢谢

xiaoyaoke

up

winfood

我觉得应该先弄清楚分析Coverage的目的。
单元测试的Coverage分析可以保证尽可能多的代码被测试过；
功能测试的Coverage分析是为了保证尽可能多的功能(可以跟踪到需求)被测试过。

像你说的情况，前面测试的是功能/GUI，最后分析的却是代码的覆盖率，好像偏离功能测试的重点了。从测试类型上看，既不是黑盒也不是白盒或者灰盒，像是黑盒测试的过程+白盒测试结果。

你们的工作要求里面要分析未覆盖Function的原因，这里的Function指的不是应用程序层次的功能而是代码层次的函数吧？如果是的话，那不应该问测试Team了，应该问开发Team了。如果设计人员能够把功能和Function的跟踪关系完整清晰的列出来，测试人员就可以分析为什么没有覆盖到了。是不是哪个功能漏测了，导致Function没有覆盖到。如果这层跟踪关系没有建立起来，那测试人员怎么分析功能和函数的关系，只能靠猜了。

仅个人观点。

ppent

我也曾经这么想过，原因是当时情况做不到单元测试，同时又想度量、提高一下核心代码的测试覆盖率。因为觉得仅靠对功能覆盖的度量还不够。不知道你们公司是否也是这样考虑。
大家认为这种方式可行吗？

winfood

原帖由 ppent 于 2007-8-17 15:57 发表
我也曾经这么想过，原因是当时情况做不到单元测试，同时又想度量、提高一下核心代码的测试覆盖率。因为觉得仅靠对功能覆盖的度量还不够。不知道你们公司是否也是这样考虑。
大家认为这种方式可行吗？

嗯，好像从黑盒测试的角度同时兼顾白盒的测试目标。我觉得难度比较大，主要是两方面吧。
技术上的难度主要是核心代码和功能之间的跟踪关系。如果系统复杂的话，这种跟踪关系维护起来会比较困难；
管理上的难度则是这种工作谁来负责呢，有点儿吃力不讨好。按说应该是需求分析和设计/开发人员来承担这样的工作，可是对他们没有什么好处。