Closed sofkyle closed 4 years ago
我看到DubboSample.java中有这样一段注释:
//TODO //当接口返回异常时,sample标识为successful,通过响应内容做断言来判断是否标识sample错误,因为sample的错误会统计到用例的error百分比内。 //比如接口有一些校验性质的异常,不代表这个操作是错误的,这样就可以灵活的判断,不至于正常的校验返回导致测试用例error百分比的不真实
这段话乍一看很有道理,但是细细想来是不太严谨的。作为性能测试,主要关注点应该是在TPS、QPS之类,而不应该去关注校验性质的异常或者其他业务类异常。后面这部分异常,应该由测试人员自行规避,或者在功能测试中进行排查。
譬如说,如果Provider突然中断、或者Dubbo返回超时异常,按照现在的处理逻辑,抛出异常之后,仍然算是成功,而不计入error率,这与性能测试关注点是相违背的。
@sofkyle 其实意思就是只有真正的中断或者超时等错误信息才会统计到error中,其余的一律不算失败
Dubbo调用超时、服务中断的时候都是抛RpcException,如果还有其他场景,让用户自己去规避也是有必要的。
https://github.com/thubbo/jmeter-plugins-for-apache-dubbo/releases/tag/2.7.4
我看到DubboSample.java中有这样一段注释:
//TODO //当接口返回异常时,sample标识为successful,通过响应内容做断言来判断是否标识sample错误,因为sample的错误会统计到用例的error百分比内。 //比如接口有一些校验性质的异常,不代表这个操作是错误的,这样就可以灵活的判断,不至于正常的校验返回导致测试用例error百分比的不真实
这段话乍一看很有道理,但是细细想来是不太严谨的。作为性能测试,主要关注点应该是在TPS、QPS之类,而不应该去关注校验性质的异常或者其他业务类异常。后面这部分异常,应该由测试人员自行规避,或者在功能测试中进行排查。
譬如说,如果Provider突然中断、或者Dubbo返回超时异常,按照现在的处理逻辑,抛出异常之后,仍然算是成功,而不计入error率,这与性能测试关注点是相违背的。