评审是非常关键,并且有用的一个活动。但是在实际运用中,却往往很难发挥作用。这是为什么呢?因为当事人在组织评审之前,并没有对需要评审的对象,进行有效的说明。
比如说:
1 当前文档做成背景,为什么要做成
2 当前测试用例,是根据什么思路,来完成的
※这点非常重要,因为如果设计思路是错误或者混乱的的,
后面的测试用例就完全不用评审了,因为相当于所有评审人员来了一次头脑风暴,从头再来看过一遍整个设计过程。 或者说评审人员也是都下想到哪里说到哪里。毫无效率。
3 此次评审,需要达到什么效果
比如说:
1 当前文档做成背景,为什么要做成
2 当前测试用例,是根据什么思路,来完成的
※这点非常重要,因为如果设计思路是错误或者混乱的的,
后面的测试用例就完全不用评审了,因为相当于所有评审人员来了一次头脑风暴,从头再来看过一遍整个设计过程。 或者说评审人员也是都下想到哪里说到哪里。毫无效率。
3 此次评审,需要达到什么效果
2018-05-24
通过老师的这种方式来写测试用例,其实设计的思路不是很长清楚。
例如 ,用户名密码,错误这一个点,都没有覆盖全面。
现在罗列的点里面 有用户名错误,密码错误。但是却没有覆盖到 用户名以及密码错误。
建议,采用石川图先做测试因子分析,接着对每个测试因子进行状态分析。最后根据业务需求,在进行测试用例组合,这样才能保证覆盖度。
现在这种方式,是看到什么就人为脑补什么用例。
以上愚见
例如 ,用户名密码,错误这一个点,都没有覆盖全面。
现在罗列的点里面 有用户名错误,密码错误。但是却没有覆盖到 用户名以及密码错误。
建议,采用石川图先做测试因子分析,接着对每个测试因子进行状态分析。最后根据业务需求,在进行测试用例组合,这样才能保证覆盖度。
现在这种方式,是看到什么就人为脑补什么用例。
以上愚见
2018-05-24
需求分析 里面应该是要包含
需求理解以及合意
( 这里很重要的一点是,如果是测试与开发并发的话,那么测试应该根据测试的观点,对当前需求提出意见,是否符合一般业务场景)
确认测试范围
做成测试目标
需求理解以及合意
( 这里很重要的一点是,如果是测试与开发并发的话,那么测试应该根据测试的观点,对当前需求提出意见,是否符合一般业务场景)
确认测试范围
做成测试目标
2018-05-24