程序接口测试方法及装置-复审决定


发明创造名称:程序接口测试方法及装置
外观设计名称:
决定号:197763
决定日:2019-12-18
委内编号:1F269588
优先权日:
申请(专利)号:201610069677.X
申请日:2016-01-29
复审请求人:广州酷狗计算机科技有限公司
无效请求人:
授权公告日:
审定公告日:
专利权人:
主审员:宋霖
合议组组长:吴海涛
参审员:田书凤
国际分类号:G06F11/36
外观设计分类号:
法律依据:专利法第22条第3款
决定要点
:如果一项权利要求请求保护的技术方案与对比文件公开的技术方案相比存在区别技术特征,但该区别技术特征对于本领域技术人员来说是公知常识,并且也未产生任何意料不到的技术效果,则权利要求所请求保护的技术方案相对于对比文件和公知常识的结合不具有突出的实质性特点和显著的进步,不具备创造性。
全文:
本复审请求涉及申请号为201610069677.X、发明名称为“程序接口测试方法及装置”的发明专利申请(下称本申请),本申请的申请人为广州酷狗计算机科技有限公司,申请日为2016年01月29日,公开日为2016年06月01日。
经实质审查,国家知识产权局原审查部门于2018年09月19日以本申请权利要求1-6不具备专利法第22条第3款规定的创造性为由驳回了本申请。驳回决定所依据的文本为:于申请日2016年01月29日提交的说明书第1-190段、说明书附图图1-6、说明书摘要和摘要附图;2018年07月18日提交的权利要求第1-6项。驳回决定引用了一篇对比文件,即:
对比文件1:CN102495799A,公开日为2012年06月13日。
驳回决定的具体理由是:(1)权利要求1相对于对比文件1具有区别技术特征,但是该区别技术特征对本领域技术人员来说属于常用技术手段,并且使用了常用技术手段的证据(《微软的软件测试之道》,Alan Page等,北京:机械工业出版社,公开日2009年09月30日),因此,权利要求1相对于对比文件1及本领域的常用技术手段不具备创造性;(2)从属权利要求2-3的附加技术特征或被对比文件1所公开,或为本领域的常用技术手段,因此,当其引用的权利要求不具备创造性时,从属权利要求2-3也不具备创造性;(3)权利要求4-6是与权利要求1-3要求保护的方法权利要求完全一一对应的产品权利要求,基于权利要求1-3不具备创造性的理由,权利要求4-6不具备创造性。
驳回决定所针对的权利要求书的内容如下:
“1. 一种程序接口测试方法,其特征在于,所述方法包括:
确定至少一个测试用例,所述测试用例用于对待测试程序中的某一项接口功能或者某个涉及多个接口的功能业务进行测试;
确定所述测试用例对应的测试函数;
获取所述测试用例对应的用例数据;所述用例数据由所述测试用例或所述测试函数引用变量控制文件获取,所述变量控制文件中存储有可变的变量文件,或通过函数来构造用例数据然后再将构建数据方法返回到具体变量中提供给测试用例或测试函数使用;
获取所述测试用例对应的测试规则,所述测试规则用于指示测试时间和测试次数;
当所述测试时间达到时,按照所述测试次数将所述用例数据传输给所述测试函数,由所述测试函数根据所述用例数据执行相应的测试步骤,获得测试结果;
将所述测试结果传输给所述测试用例对应的校验函数,由所述校验函数对所述测试结果进行校验,获得校验结果。
2. 根据权利要求1所述的方法,其特征在于,所述获取所述测试用例对应的用例数据,包括:
根据预设的选取规则从预存的所述测试用例对应的各个用例数据中选取所述测试数据,所述各个用例数据独立于所述测试用例存储;
或者,
通过与所述测试用例关联的功能接口获取所述测试数据。
3. 根据权利要求1所述的方法,其特征在于,所述方法还包括:
统计并输出所述测试结果和所述校验结果。
4. 一种程序接口测试装置,其特征在于,所述装置包括:
用例确定模块,用于确定至少一个测试用例,所述测试用例用于对待测试 程序中的某一项接口功能或者某个涉及多个接口的功能业务进行测试;
函数确定模块,用于确定所述测试用例对应的测试函数;
数据获取模块,用于获取所述测试用例对应的用例数据;所述用例数据由所述测试用例或所述测试函数引用变量控制文件获取,所述变量控制文件中存储有可变的变量文件,或通过函数来构造用例数据然后再将构建数据方法返回到具体变量中提供给测试用例或测试函数使用;
规则获取模块,用于获取所述测试用例对应的测试规则,所述测试规则用于指示测试时间和测试次数;
数据传输模块,用于当所述测试时间达到时,按照所述测试次数将所述测试用例对应的用例数据传输给所述测试函数,由所述测试函数根据所述用例数据执行相应的测试步骤,获得测试结果;
校验模块,用于将所述测试结果传输给所述测试用例对应的校验函数,由所述校验函数对所述测试结果进行校验,获得校验结果。
5. 根据权利要求4所述的装置,其特征在于,所述数据获取模块,包括:
第一获取单元,用于在所述数据传输模块将所述测试用例对应的用例数据传输给所述测试函数之前,根据预设的选取规则从预存的所述测试用例对应的各个用例数据中选取所述测试数据,所述各个用例数据独立于所述测试用例存储;
第二获取单元,用于在所述数据传输模块将所述测试用例对应的用例数据传输给所述测试函数之前,通过与所述测试用例关联的功能接口获取所述测试数据。
6. 根据权利要求4所述的装置,其特征在于,所述装置还包括:
统计输出模块,用于统计并输出所述测试结果和所述校验结果。”
申请人(下称复审请求人)对上述驳回决定不服,于2018年12月24日向国家知识产权局提出了复审请求,陈述了意见,提交了权利要求书的全文替换页(共6项权利要求),其修改为在独立权利要求1和4中增加了技术特征“每个接口包括测试函数和测试用例,一个接口根据测试的业务不同,定义多个不同的测试函数,不同的测试用例存放不同的用例数据,所述测试函数根据接收到不同用例数据自动执行所对应的业务流程”。其请求复审的主要理由为:1)本申请是对接口测试,对比文件1是对移动终端进行测试,测试对象不同,且本申请提供了确定用例数据的实现方式;2)本申请使用测试函数执行测试流程,而对比文件1使用测试脚本,不能简单替换;3)对比文件1未涉及对测试结果的校验。
复审请求人于2018年12月24日提交的修改后的权利要求1、4的内容如下:
“1. 一种程序接口测试方法,其特征在于,所述方法包括:
确定至少一个测试用例,所述测试用例用于对待测试程序中的某一项接口功能或者某个涉及多个接口的功能业务进行测试,每个接口包括测试函数和测试用例,一个接口根据测试的业务不同,定义多个不同的测试函数,不同的测试用例存放不同的用例数据,所述测试函数根据接收到不同用例数据自动执行所对应的业务流程;
确定所述测试用例对应的测试函数;
获取所述测试用例对应的用例数据;所述用例数据由所述测试用例或所述测试函数引用变量控制文件获取,所述变量控制文件中存储有可变的变量文件,或通过所述测试函数来构造用例数据然后再将构建数据方法返回到具体变量中提供给测试用例或测试函数使用;
获取所述测试用例对应的测试规则,所述测试规则用于指示测试时间和测试次数;
当所述测试时间达到时,按照所述测试次数将所述用例数据传输给所述测试函数,由所述测试函数根据所述用例数据执行相应的测试步骤,获得测试结果;
将所述测试结果传输给所述测试用例对应的校验函数,由所述校验函数对所述测试结果进行校验,获得校验结果。”
“4. 一种程序接口测试装置,其特征在于,所述装置包括:
用例确定模块,用于确定至少一个测试用例,所述测试用例用于对待测试程序中的某一项接口功能或者某个涉及多个接口的功能业务进行测试,每个接口包括测试函数和测试用例,一个接口根据测试的业务不同,定义多个不同的测试函数,不同的测试用例存放不同的用例数据,所述测试函数根据接收到不同用例数据自动执行所对应的业务流程;
函数确定模块,用于确定所述测试用例对应的测试函数;
数据获取模块,用于获取所述测试用例对应的用例数据;所述用例数据由所述测试用例或所述测试函数引用变量控制文件获取,所述变量控制文件中存储有可变的变量文件,或通过函数来构造用例数据然后再将构建数据方法返回到具体变量中提供给测试用例或测试函数使用;
规则获取模块,用于获取所述测试用例对应的测试规则,所述测试规则用于指示测试时间和测试次数;
数据传输模块,用于当所述测试时间达到时,按照所述测试次数将所述测试用例对应的用例数据传输给所述测试函数,由所述测试函数根据所述用例数据执行相应的测试步骤,获得测试结果;
校验模块,用于将所述测试结果传输给所述测试用例对应的校验函数,由所述校验函数对所述测试结果进行校验,获得校验结果。”
经形式审查合格,国家知识产权局于2018年12月28日依法受理了该复审请求,并将其转送至原审查部门进行前置审查。
经过前置审查,原审查部门坚持驳回决定。前置审查意见认为:首先,本申请所要解决的技术问题是,现有技术中测试数据预先编写入测试用例代码中,如需更换测试数据则需要修改用例代码,代码的可维护性低;为了解决这一技术问题,本申请将测试用例和测试函数进行分离,测试用例中只存放测试数据,由测试函数执行相应的测试步骤,当需要更换测试数据时不需要对测试函数进行修改,从而提高代码的可维护性,可见,本申请技术方案中的关键技术手段是“测试函数和测试数据分离”。对比文件1公开了一种移动终端的自动化测试方法,用于对移动终端的应用层软件进行测试,根据测试需求将测试的基本动作编写成测试指令集合,即测试脚本,然后准备测试数据,测试数据和测试脚本独立;测试时将测试数据填入测试脚本、按照测试逻辑组合配置生成数据包,进而解析、执行、获得测试结果。对比文件1同样属于软件测试领域,同样采用了“测试数据和测试代码分离”的关键技术手段,其客观上能够解决“如需更换测试数据则需要修改用例代码,代码的可维护性低”这一技术问题,且明确记载了能够达到“提高测试系统的可维护性,创建、修改和维护测试脚本的工作量大大减少,降低方便用户修改测试用例”(参见说明书第[0115]段)的技术效果,也即,对比文件1采用了同样的关键技术手段,能够解决本申请所要解决的技术问题,达到相同的技术效果,虽然本申请用于对程序接口进行测试而对比文件1用于对移动终端的应用层软件进行测试,但二者都属于软件测试的范畴,实质上均是根据被测对象设计相应的测试代码和测试数据,执行测试并获取测试结果,因此,本领域技术人员有动机借鉴对比文件1的方法,用于对程序接口进行“测试数据和测试代码分离”的测试。进一步地,对比文件1公开了根据测试需求来准备测试脚本和测试数据,二者相独立,也即,公开了对于不同的测试需求设置不同的测试脚本和测试数据来完成测试,在此基础上,由于软件测试领域中生成测试数据的方式有多种(例如动态分析、遗传算法生成、程序插桩等等),当被测对象为程序接口时,根据测试业务的不同(也即,不同的测试需求),根据实际需求选择生成测试数据的方式,在接口中设置相应的测试函数和测试数据,是本领域技术人员容易想到的。本申请中,测试函数用于根据测试数据执行对应的测试流程,其是由具体的一组动作序列封装成的,而对比文件1中的测试脚本同样用于执行测试步骤,其是将测试用例分解得到的基本动作编写成计算机可读测试指令而得到的测试指令集合,也即,二者本质上均是一组测试动作的集合,因此将对比文件1中测试脚本的形式替换为以测试函数的形式来实现,是本领域技术人员容易想到的。以校验函数的方式对测试结果进行校验是本领域的常用技术手段,对此,在驳回决定中已经给出了工具书证据:《微软的软件测试之道》,Alan Page等,北京:机械工业出版社,公开日2009年09月30日,第172-174页公开了“执行测试中的步骤只是自动化测试的开始,在执行以后,还必须进行一定程度的调查以确定测试的结果。为了确定函数是否真的工作以确定一个精确的测试结果,还须进行大量的附加测试,测试工程师可以创建一个测试准则或测试校验函数来帮助确定测试状态”。综上,复审请求人的意见陈述不成立,坚持驳回决定。
随后,国家知识产权局成立合议组对本案进行审理。
合议组于2019年06月24日发出复审通知书,指出:(1)权利要求1相对于对比文件1具有区别技术特征,但是该区别技术特征对本领域技术人员来说属于常用技术手段,并且使用了常用技术手段的证据,因此,权利要求1相对于对比文件1及本领域的常用技术手段不具备创造性;(2)从属权利要求2-3的附加技术特征或被对比文件1所公开,或为本领域的常用技术手段,因此,当其引用的权利要求不具备创造性时,从属权利要求2-3也不具备创造性;(3)权利要求4-6是与权利要求1-3要求保护的方法权利要求完全一一对应的产品权利要求,基于权利要求1-3不具备创造性的理由,权利要求4-6不具备创造性。
针对上述复审通知书,复审请求人于2019年08月06日提交了意见陈述书,并对申请文件进行修改,提交了权利要求书的全文替换页(共6项权利要求),对权利要求序号和引用关系进行适应性修改。复审请求人在意见陈述书中指出:1)本申请使用测试函数执行测试流程,而对比文件1使用测试脚本,不能简单替换;2)对比文件1未涉及对测试结果的校验。因此,本领域技术人员不可能根据对比文件1容易的想到本申请的技术方案,权利要求1具备创造性。
复审请求人于2019年08月06日提交的修改后的权利要求书如下:
“1. 一种程序接口测试方法,其特征在于,所述方法包括:
确定至少一个测试用例,所述测试用例用于对待测试程序中的某一项接口功能或者某个涉及多个接口的功能业务进行测试,每个接口包括测试函数和测试用例,一个接口根据测试的业务不同,定义多个不同的测试函数,不同的测试用例存放不同的用例数据,所述测试函数根据接收到不同用例数据自动执行所对应的业务流程;
确定所述测试用例对应的测试函数,所述测试函数为一组封装的动作序列;
获取所述测试用例对应的用例数据;所述用例数据由所述测试用例或所述测试函数引用变量控制文件获取,所述变量控制文件中存储有可变的变量文件,或通过所述测试函数来构造用例数据然后再将构建数据方法返回到具体变量中提供给测试用例或测试函数使用;
获取所述测试用例对应的测试规则,所述测试规则用于指示测试时间和测试次数;
设置自动定时构建,当所述测试时间达到时,按照所述测试次数将所述用例数据传输给所述测试函数,由所述测试函数根据所述用例数据执行相应的测试步骤,获得测试结果;
将所述测试结果传输给所述测试用例对应的校验函数,由所述校验函数对所述测试结果进行校验,获得校验结果。
2. 根据权利要求1所述的方法,其特征在于,所述获取所述测试用例对应的用例数据,包括:
根据预设的选取规则从预存的所述测试用例对应的各个用例数据中选取所述测试数据,所述各个用例数据独立于所述测试用例存储;
或者,
通过与所述测试用例关联的功能接口获取所述测试数据。
3. 根据权利要求1所述的方法,其特征在于,所述方法还包括:
统计并输出所述测试结果和所述校验结果。
4. 一种程序接口测试装置,其特征在于,所述装置包括:
用例确定模块,用于确定至少一个测试用例,所述测试用例用于对待测试程序中的某一项接口功能或者某个涉及多个接口的功能业务进行测试,每个接口包括测试函数和测试用例,一个接口根据测试的业务不同,定义多个不同的测试函数,不同的测试用例存放不同的用例数据,所述测试函数根据接收到不同用例数据自动执行所对应的业务流程;
函数确定模块,用于确定所述测试用例对应的测试函数,所述测试函数为一组封装的动作序列;
数据获取模块,用于获取所述测试用例对应的用例数据;所述用例数据由所述测试用例或所述测试函数引用变量控制文件获取,所述变量控制文件中存储有可变的变量文件,或通过函数来构造用例数据然后再将构建数据方法返回到具体变量中提供给测试用例或测试函数使用;
规则获取模块,用于获取所述测试用例对应的测试规则,所述测试规则用于指示测试时间和测试次数;
数据传输模块,用于设置自动定时构建,当所述测试时间达到时,按照所述测试次数将所述测试用例对应的用例数据传输给所述测试函数,由所述测试函数根据所述用例数据执行相应的测试步骤,获得测试结果;
校验模块,用于将所述测试结果传输给所述测试用例对应的校验函数,由所述校验函数对所述测试结果进行校验,获得校验结果。
5. 根据权利要求4所述的装置,其特征在于,所述数据获取模块,包括:
第一获取单元,用于在所述数据传输模块将所述测试用例对应的用例数据传输给所述测试函数之前,根据预设的选取规则从预存的所述测试用例对应的各个用例数据中选取所述测试数据,所述各个用例数据独立于所述测试用例存储;
第二获取单元,用于在所述数据传输模块将所述测试用例对应的用例数据传输给所述测试函数之前,通过与所述测试用例关联的功能接口获取所述测试数据。
6. 根据权利要求4所述的装置,其特征在于,所述装置还包括:
统计输出模块,用于统计并输出所述测试结果和所述校验结果。”
经审查,合议组认为本案事实已经清楚,可以作出审查决定。
二、决定的理由
1. 关于审查文本
复审请求人在答复复审通知书时,提交了权利要求书的全文修改替换页(包括6项权利要求)。经审查上述修改符合专利法第33条以及专利法实施细则第61条第1款的规定,本复审决定依据的审查文本为:即:复审请求人于2019年08月06日答复复审通知书时提交的权利要求第1-6项;于申请日2016年01月29日提交的说明书摘要、说明书第1-190段、摘要附图和说明书附图图1-6。
2.关于专利法第22条第3款
专利法第22条第3款规定:创造性,是指与现有技术相比,该发明具有突出的实质性特点和显著的进步,该实用新型具有实质性特点和进步。
如果一项权利要求请求保护的技术方案与对比文件公开的技术方案相比存在区别技术特征,但该区别技术特征对于本领域技术人员来说是公知常识,并且也未产生任何意料不到的技术效果,则权利要求所请求保护的技术方案相对于对比文件和公知常识的结合不具有突出的实质性特点和显著的进步,不具备创造性。
本复审决定引用了与驳回决定相同的对比文件,即:
对比文件1:CN102495799A,公开日为2012年06月13日。
2.1权利要求1不具备创造性
权利要求1要求保护一种程序接口测试方法,对比文件1是最接近的现有技术,其公开了一种移动终端的自动化测试方法,并具体公开了(参见说明书第[0105]-[0115]段、图2):编写测试脚本,具体包括分析测试需求,总结测试用例,并将所述测试用例分解成基本动作,将该基本动作编写成计算机可读测试指令的集合即为测试脚本;准备测试数据,所述测试脚本和所述测试数据独立,按照需求将测试数据填入测试脚本组成测试工程,测试脚本开发调试环境采取可视化工作方式按照所述测试逻辑组合配置所述测试工程生成测试规则,所述测试规则被应用于被测设备并开始测试生成测试任务,测试管理服务器据此生成测试任务数据包发送给测试执行子模块,所述测试执行子模块接收所述测试任务数据包,解析出所述测试任务数据包中包含的测试脚本并执行测试脚本,并发送测试指令到待测移动终端,待测移动终端接收并执行所述测试指令,并返回所述测试指令的执行结果数据。
由上述内容可知,对比文件1公开了一种测试方法,确定至少一个测试用例,确定所述测试用例对应的测试脚本,获取所述测试用例对应的用例数据,所述测试脚本和所述测试数据独立,将所述用例数据传输给所述测试脚本,由所述测试脚本根据所述用例数据执行相应的测试步骤,获得测试结果。
由此可见,权利要求1所要求保护的技术方案与对比文件1公开的技术内容相比,区别技术特征是:1)权利要求1的测试方法针对程序接口进行测试,接口包括测试用例,其测试用例用于对待测试程序中的某一项接口功能或者某个涉及多个接口的功能业务进行测试;2)权利要求1中的具体测试步骤由测试函数来执行,测试函数为一组封装的动作序列,接口根据测试的业务不同,定义多个不同的测试函数,不同的测试用例存放不同的用例数据,测试函数根据接受到不同用例数据自动执行所对应的业务流程,对比文件1中的测试动作由测试脚本来执行;3)用例数据由所述测试用例或所述测试函数引用变量控制文件获取,所述变量控制文件中存储有可变的变量文件,或通过函数来构造用例数据然后再将构建数据方法返回到具体变量中提供给测试用例或测试函数使用;4)获取所述测试用例对应的测试规则,所述测试规则用于指示测试时间和测试次数,设置自动定时构建,当所述测试时间达到时按照测试次数执行测试;5)将测试结果传输给测试用例对应的校验函数,由所述校验函数对所述测试结果进行校验,获得校验结果。基于上述区别技术特征,权利要求1实际解决的技术问题是:程序接口测试中如何获取用例数据及如何自动执行测试并校验测试结果。
对于区别技术特征1),对于移动终端软件的测试和对程序接口的测试实质上均是根据被测对象设计相应的测试代码和测试数据,执行测试并获取测试结果,将对比文件1公开的“测试代码和测试数据分离”用于程序接口测试是本领域技术人员容易想到的,而程序接口测试的测试用例用于对待测试程序中的某一项接口功能或者某个涉及多个接口的功能业务进行测试,是本领域的常用技术手段。
对于区别技术特征2),本领域技术人员皆知,测试函数是对具体的测试动作序列的封装,测试脚本同样是对具体测试动作进行的有顺序的组合,二者本质上均是一组测试动作的集合,因此将对比文件1中测试脚本的形式替换为以测试函数的形式来实现,接口根据测试不同定义不同的测试函数,不同测试用例存放不同的用例数据,根据用例数据不同自动执行所对应的业务流程,均是本领域技术人员容易想到的。
对于区别技术特征3),在测试领域中,本领域技术人员能够根据需要从多种构造测试数据的方法中进行选择,常见的构造测试数据的方法包括:遗传算法、程序插桩、程序流程图、动/静态分析等,其中,通过函数或包含了可变变量文件的方法来构造测试数据是本领域的常规选择。
对于区别技术特征4),为了实现测试的自动化,本领域通常预设测试执行的相关信息,设置自动定时构建,如测试开始/结束时间、测试次数、测试并发数、运行的选择策略等,因此,预设测试时间和测试次数并据此执行测试是本领域的常用技术手段。
对于区别技术特征5),在测试领域中,为了检测执行得到的测试结果的正确性,通过校验函数对测试结果进行校验时本领域的常用技术手段,对此可举证如下:《微软的软件测试之道》,Alan Page等,北京:机械工业出版社,公开日2009年09月30日,第172-174页公开了“执行测试中的步骤只是自动化测试的开始,在执行以后,还必须进行一定程度的调查以确定测试的结果。为了确定函数是否真的工作以确定一个精确的测试结果,还须进行大量的附加测试,测试工程师可以创建一个测试准则或测试校验函数来帮助确定测试状态”。可见,以校验函数的方式对测试结果进行校验是本领域的常用技术手段。
因此,在对比文件1的基础上结合本领域的常用技术手段以获得权利要求1所要求保护的技术方案,对本领域的技术人员来说是显而易见的,因此权利要求1所要求保护的技术方案不具备突出的实质性特点和显著的进步,不具备专利法第22条第3款规定的创造性。
2.2权利要求2不具备创造性
权利要求2是权利要求1的从属权利要求,对比文件1公开了(参见说明书第[0105]-[0115]段、图2):测试脚本和所述测试数据独立。在此基础上,为了获取测试过程中所需的独立存储的测试数据,本领域技术人员有多种方式来实现,例如通过即时的手动输入、读取特定格式的数据文件、从预存的用例数据库中选取、通过功能接口获取等,是本领域的常用技术手段。因此,当其引用的权利要求不具备创造性时,该从属权利要求不具备专利法第22条第3款规定的创造性。
2.3权利要求3不具备创造性
权利要求3是权利要求1的从属权利要求,为了直观展示测试结果,将测试结果及校验结果进行统计输出是测试人员进行测试时的常用技术手段。因此,当其引用的权利要求不具备创造性时,该从属权利要求不具备专利法第22条第3款规定的创造性。
2.4权利要求4-6不具备创造性
权利要求4-6要求保护的是与权利要求1-3要求保护的方法权利要求完全一一对应的产品权利要求,基于权利要求1-3不具备创造性的理由,权利要求4-6也不具备专利法第22条第3款规定的创造性。
三、关于复审请求人的意见
针对复审请求人的意见陈述,合议组认为:1)本申请中,测试函数用于根据测试数据执行对应的测试流程,其是由具体的一组动作序列封装成的,而对比文件1中的测试脚本同样用于执行测试步骤,其是将测试用例分解得到的基本动作编写成计算机可读测试指令而得到的测试指令集合,也即,二者本质上均是一组测试动作的集合,因此将对比文件1中测试脚本的形式替换为以测试函数的形式来实现,是本领域技术人员容易想到的。对比文件1同样属于软件测试领域,同样采用了“测试数据和测试代码分离”的关键技术手段,其客观上能够解决“如需更换测试数据则需要修改用例代码,代码的可维护性低”这一技术问题,且明确记载了能够达到“提高测试系统的可维护性,创建、修改和维护测试脚本的工作量大大减少,降低方便用户修改测试用例”(参见说明书第[0115]段)的技术效果,也即,对比文件1采用了同样的关键技术手段,能够解决本申请所要解决的技术问题,达到相同的技术效果。2)合议组认可对比文件1中没有明确公开进行校验,但是,以校验函数的方式对测试结果进行校验是本领域的常用技术手段,对此,工具书证据:《微软的软件测试之道》,Alan Page等,北京:机械工业出版社,公开日2009年09月30日,第172-174页公开了“执行测试中的步骤只是自动化测试的开始,在执行以后,还必须进行一定程度的调查以确定测试的结果。为了确定函数是否真的工作以确定一个精确的测试结果,还须进行大量的附加测试,测试工程师可以创建一个测试准则或测试校验函数来帮助确定测试状态”。
复审请求人陈述的意见不能成立。
基于上述理由,合议组依法作出如下决定。
四、决定
维持国家知识产权局于2018年09月19日对本申请作出的驳回决定。
如对本复审请求审查决定不服,根据专利法第41条第2款的规定,可以自收到本决定之日起三个月内向北京知识产权法院起诉。





郑重声明:本文版权归原作者所有,转载文章仅为传播更多信息之目的,如作者信息标记有误,请第一时间联系我们修改或删除,多谢。

留言与评论(共有 0 条评论)
   
验证码: