发明创造名称：测试方法和系统
外观设计名称：
决定号：187189
决定日：2019-08-13
委内编号：1F267383
优先权日：
申请（专利）号：201510092260.0
申请日：2015-02-28
复审请求人：北京嘀嘀无限科技发展有限公司
无效请求人：
授权公告日：
审定公告日：
专利权人：
主审员：蒋煜婧
合议组组长：张弘
参审员：戴丽娟
国际分类号：G06F11/36
外观设计分类号：
法律依据：专利法第22条第3款
决定要点
：权利要求与对比文件相比存在区别特征，而区别特征属于本领域的公知常识，对所属领域的技术人员来说，在最接近的现有技术的基础上结合本领域的公知常识得到该权利要求所要求保护的技术方案是显而易见的，则该权利要求不具备创造性。
全文：
本复审请求涉及申请号为201510092260.0，名称为“测试方法和系统”的发明专利申请（下称本申请）。申请人为北京嘀嘀无限科技发展有限公司。本申请的申请日为2015年02月28日，公开日为2015年05月27日。
经实质审查，国家知识产权局原审查部门于2018年08月14日发出驳回决定，驳回了本申请，其理由是：权利要求1的技术方案与对比文件1（CN1503136A，公开日为2004年06月09日）公开的技术方案相比，区别技术特征为：1）与测试对象相关的参数是由用户输入的；2）其中所述测试对象是应用程序编程接口。其所要解决的技术问题是如何获得与测试对象相关的参数。针对区别技术特征1），在执行自动化测试时，测试相关参数可以在测试中自动生成或调用，也可以通过输入的方式获得，而用户、测试人员、和/或开发人员等都可以有权限进行输入操作，因此本领域技术人员容易想到测试对象相关的参数是由用户输入的。针对区别技术特征2），对本领域技术人员来说，在编写测试用例所需考虑的测试对象有很多，被测软件、应用程序编程接口等都是常用的测试对象，而软件测试领域的一种测试方法思想通常可以兼容不同的测试对象，因此将对比文件1中公开的测试方法用于应用程序编程接口的测试中是本领域技术人员容易想到的，即本领域技术人员容易想到所述测试对象是应用程序编程接口。因此，权利要求1相对于对比文件1和本领域惯用手段的结合不具备专利法第22条第3款规定的创造性。基于类似的理由，权利要求6也不具备专利法第22条第3款规定的创造性。权利要求2-5，7-10的附加技术特征或被对比文件1、对比文件2（《软件测试技术与实践》，邓武等，第31-32页，清华大学出版社，公开日为2012年01月31日）所公开或属于本领域的公知常识，因此权利要求2-5，7-10也不具备专利法第22条第3款规定的创造性。驳回决定所依据的文本为：申请日2015年02月28日提交的说明书摘要、说明书第1-51段、摘要附图、说明书附图图1-6；2018年05月11日提交的权利要求第1-10项。驳回决定所针对的权利要求书如下：
“1. 一种测试方法，包括：
响应于由用户输入的与测试对象相关的参数，自动地触发如下操作：
向所述测试对象发送测试请求；
接收来自所述测试对象的、与所述参数相对应的返回值；以及
通过验证所述返回值而获得测试结果，
其中所述测试对象是应用程序编程接口。
2. 根据权利要求1所述的方法，其中通过验证所述返回值而获得测试结果包括：
将所述返回值和已存储的与所述参数相对应的验证值进行比较；
在所述返回值等于所述验证值时，将所述测试结果确定为合格；以及
在所述返回值不等于所述验证值时，将所述测试结果确定为不合格。
3. 根据权利要求1所述的方法，还包括：
根据所述参数中的已被测试的参数与所述参数的比例，确定参数测试的覆盖率；以及
在所述参数测试的覆盖率小于预定阈值时，继续测试所述参数中的除所述已被测试的参数之外的参数。
4. 根据权利要求1所述的方法，还包括：
根据所述参数中的已被测试的参数与所述参数的比例，确定参数测试的覆盖率；
在所述参数测试的覆盖率小于第一预定阈值时，将测试质量评估为低；
在所述参数测试的覆盖率大于或等于所述第一预定阈值且小于第二预定阈值时，将所述测试质量评估为中；以及
在所述参数测试的覆盖率大于或等于所述第二预定阈值时，将所 述测试质量评估为高。
5. 根据权利要求1所述的方法，其中响应于输入与测试对象相关的参数，向所述测试对象发送测试请求包括：
对输入的所述参数进行封装；以及
响应于输入所述参数，向所述测试对象发送所述测试请求。
6. 一种测试系统，包括：
测试请求发送装置，被配置为响应于由用户输入的与测试对象相关的参数，自动地向所述测试对象发送测试请求；
返回值接收装置，被配置为接收来自所述测试对象的、与所述参数相对应的返回值；以及
验证装置，被配置为通过验证所述返回值而获得测试结果，
其中所述测试对象是应用程序编程接口。
7. 根据权利要求6所述的系统，其中所述验证装置包括：
比较单元，被配置为将所述返回值和已存储的与所述参数相对应的验证值进行比较；以及
测试结果确定单元，被配置为：
在所述返回值等于所述验证值时，将所述测试结果确定为合格；以及
在所述返回值不等于所述验证值时，将所述测试结果确定为不合格。
8. 根据权利要求6所述的系统，还包括：
覆盖率确定装置，被配置为根据所述参数中的已被测试的参数与所述参数的比例，确定参数测试的覆盖率，
其中在所述参数测试的覆盖率小于预定阈值时，所述测试系统继续测试所述参数中的除所述已被测试的参数之外的参数。
9. 根据权利要求6所述的系统，还包括：
覆盖率确定装置，被配置为根据所述参数中的已被测试的参数与所述参数的比例，确定参数测试的覆盖率；以及
测试质量评估装置，被配置为：
在所述参数测试的覆盖率小于第一预定阈值时，将测试质量评估为低；
在所述参数测试的覆盖率大于或等于所述第一预定阈值且小于第二预定阈值时，将所述测试质量评估为中；以及
在所述参数测试的覆盖率大于或等于所述第二预定阈值时，将所述测试质量评估为高。
10. 根据权利要求6所述的系统，其中所述测试请求发送装置包括：
封装单元，被配置为对输入的所述参数进行封装；以及
发送单元，被配置为响应于输入所述参数，向所述测试对象发送所述测试请求。”
申请人（下称复审请求人）对上述驳回决定不服，于2018年11月29日向国家知识产权局提出了复审请求，未对申请文件进行修改。复审请求人认为：1）本申请中输入的与测试对象相关的参数不是对比文件1中所公开的测试数据或测试用例，对比文件1的方法仅适用于嵌入式程序的测试，本申请中测试对象为API接口，与测试对象相关的参数是API参数，因此对比文件1没有公开权利要求1中的特征“响应于由用户输入的与测试对象相关的参数，自动地触发如下操作”和“所述测试对象是应用程序编程接口”；2）权利要求1所限定的技术方案能够简化测试工作、有效验证测试结果、确定测试覆盖率，以实现测试工作自动化，对比文件1和对比文件2均不能实现上述技术效果；3）权利要求3-4和8-9限定的根据所述参数中的已被测试的参数与所述参数的比例，确定参数测试的覆盖率；根据覆盖率执行继续测试所述参数中的除所述已被测试的参数之外的或进行测试质量评估不是本领域技术人员容易想到的。
经形式审查合格，国家知识产权局于2018年12月05日依法受理了该复审请求，并将其转送至原审查部门进行前置审查。
原审查部门在前置审查意见书中认为：1.被测软件相当于测试对象，而测试用例中需包含与被测软件相关的参数（封装、环境、输入输出等）才能针对被测软件进行测试，因此针对被测软件的各种测试用例相当于与测试对象相关的参数。API本质为一些预先定义的函数（参见百度百科对“api”的定义），而函数也是代码的一种表现形式，而软件测试领域的一种测试方法思想通常可以兼容不同的测试对象，因此将对比文件1中公开的测试方法用于应用程序编程接口的测试是本领域技术人员容易想到的。2.对比文件1能够自动运行测试，并验证测试运行结果是否正确，因此在对比文件1的基础上结合本领域的惯用手段所得到的技术方案能够实现权利要求1的技术效果。而对比文件1有益效果部分（参见说明书第2页）提到“极大地提高了测试覆盖率”，且对比文件2公开了一种测试覆盖率的确定方法，因此在对比文件1的基础上结合对比文件2和本领域的惯用手段所得到的技术方案能够实现本申请的技术效果。3.对比文件2中公开了（参见32页）：如果将以上比率转换为百分数，则以下基于需求的测试覆盖的陈述成立：……，这一关于测试覆盖的陈述是有意义的，可以将其与已定义的成功标准进行对比，如果不符合该标准，则此陈述将成为预测剩余测试工作量的基础。因此对比文件2给出了当覆盖率不满足标准时继续进行测试的启示。而以阈值或区间等形式表示某一标准是本领域的常用技术手段。并且根据对比文件2公开的技术特征“基于需求的测试覆盖在测试生命周期中要评测多次，并在测试生命周期的里程碑处提供测试覆盖的标识（如已计划的、已实施的、已执行的和成功的测试覆盖）”，本领域技术人员容易想到在继续测试时对未计划的、未实施的、未执行的和/或未成功的影响测试覆盖的数据进行测试。根据指标所处的区间划分等级从而进行质量评估，例如：缺陷、效率、覆盖率等。因而对覆盖率划分等级以进行测试质量的评估是本领域技术人员容易想到的。因而坚持原驳回决定。
随后，国家知识产权局成立合议组对本案进行审理。
合议组于2019年05月09日向复审请求人发出复审通知书，指出：权利要求1-10不具备专利法第22条第3款规定的创造性。针对复审请求人的陈述意见，合议组认为：1）被测软件相当于测试对象，而测试用例中需包含与被测软件相关的参数（封装、环境、输入输出等）才能针对被测软件进行测试，因此针对被测软件的各种测试用例相当于与测试对象相关的参数。API本质为一些预先定义的函数（参见百度百科对“api”的定义），而函数也是代码的一种表现形式，而软件测试领域的一种测试方法思想通常可以兼容不同的测试对象，因此将对比文件1中公开的测试方法用于应用程序编程接口的测试是本领域技术人员容易想到的。2）对比文件1能够自动运行测试，并验证测试运行结果是否正确，因此在对比文件1的基础上结合本领域的惯用手段所得到的技术方案能够实现权利要求1的技术效果。而对比文件1有益效果部分（参见说明书第2页）提到“极大地提高了测试覆盖率”，且对比文件2公开了一种测试覆盖率的确定方法，因此在对比文件1的基础上结合对比文件2和本领域的惯用手段所得到的技术方案能够实现本申请的技术效果。3）对比文件2中公开了（参见32页）：如果将以上比率转换为百分数，则以下基于需求的测试覆盖的陈述成立：……，这一关于测试覆盖的陈述是有意义的，可以将其与已定义的成功标准进行对比，如果不符合该标准，则此陈述将成为预测剩余测试工作量的基础。因此对比文件2给出了当覆盖率不满足标准时继续进行测试的启示。而以阈值或区间等形式表示某一标准是本领域的常用技术手段。并且根据对比文件2公开的技术特征“基于需求的测试覆盖在测试生命周期中要评测多次，并在测试生命周期的里程碑处提供测试覆盖的标识（如已计划的、已实施的、已执行的和成功的测试覆盖）”，本领域技术人员容易想到在继续测试时对未计划的、未实施的、未执行的和/或未成功的影响测试覆盖的数据进行测试。根据指标所处的区间划分等级从而进行质量评估，例如：缺陷、效率、覆盖率等。因而对覆盖率划分等级以进行测试质量的评估是本领域技术人员容易想到的。
复审请求人于2019年05月31日提交了意见陈述书，同时提交了权利要求书的替换页，包括权利要求第1-8项，其中在原权利要求1和6中增加技术特征“其中当所述应用程序编程接口基于http协议时，所述测试请求是http请求，并且向所述测试对象发送所述测试请求包括：根据不同的http协议对输入的所述参数进行智能化拼装；以及响应于输入经智能化拼装的所述参数，向所述测试对象发送所述测试请求”，并删除原权利要求5和10。复审请求人认为：1.对比文件1和2都没有公开测试请求是http请求，并且向测试对象发送测试请求包括根据不同的http协议对输入的参数进行智能化拼装；2.对比文件1公开的测试用例并不相当于权利要求1中的“与测试对象相关的参数”。
新提交的权利要求1和5如下：
“1. 一种测试方法，包括：
响应于由用户输入的与测试对象相关的参数，自动地触发如下操作：
向所述测试对象发送测试请求；
接收来自所述测试对象的、与所述参数相对应的返回值；以及
通过验证所述返回值而获得测试结果，
其中所述测试对象是应用程序编程接口，
其中当所述应用程序编程接口基于http协议时，所述测试请求是http请求，并且向所述测试对象发送所述测试请求包括：
根据不同的http协议对输入的所述参数进行智能化拼装；以及
响应于输入经智能化拼装的所述参数，向所述测试对象发送所述测试请求。
5. 一种测试系统，包括：
测试请求发送装置，被配置为响应于由用户输入的与测试对象相关的参数，自动地向所述测试对象发送测试请求；
返回值接收装置，被配置为接收来自所述测试对象的、与所述参数相对应的返回值；以及
验证装置，被配置为通过验证所述返回值而获得测试结果，
其中所述测试对象是应用程序编程接口，
其中当所述应用程序编程接口基于http协议时，所述测试请求是http请求，并且向所述测试对象发送所述测试请求包括：
根据不同的http协议对输入的所述参数进行智能化拼装；以及
响应于输入经智能化拼装的所述参数，向所述测试对象发送所述测试请求。”
在上述程序的基础上，合议组认为本案事实已经清楚，可以作出审查决定。
二、决定的理由
审查文本的认定
复审请求人于2019年05月31日提交了权利要求书全文的修改替换页，包括权利要求第1-8项，经审查，上述修改符合专利法第33条和专利法实施细则第61条第1款的规定。
本复审决定依据的文本为：申请日2015年02月28日提交的说明书摘要、说明书第1-51段、摘要附图、说明书附图图1-6；2019年05月31日提交的权利要求第1-8项。
关于专利法第22条第3款
专利法第22条第3款规定：创造性，是指与现有技术相比，该发明具有突出的实质性特点和显著的进步。
权利要求与对比文件相比存在区别特征，而区别特征属于本领域的公知常识，对所属领域的技术人员来说，在最接近的现有技术的基础上结合本领域的公知常识得到该权利要求所要求保护的技术方案是显而易见的，则该权利要求不具备创造性。
在本决定中引用原审查部门在驳回决定中所引用的对比文件1和2作为现有技术，即：
对比文件1：CN1503136A，公开日为2004年06月09日；
对比文件2：《软件测试技术与实践》，邓武 等，第31-32页，清华大学出版社，2012年01月，公开日为2012年01月31日。
1. 权利要求1不具备专利法第22条第3款规定的创造性。
权利要求1请求保护一种测试方法。对比文件1公开了一种嵌入式软件测试方法，其具体公开了以下特征（参见说明书第2页第7行-第3页第8行，附图1）：测试人员在启动测试后，可不必待在现场观察每个测试用例的运行情况，只需查看后台计算机的统计记录就知道整个测试结果；测试程序能自动生成或调用针对被测软件的各种测试用例（由于被测软件相当于测试对象，而测试用例中需包含与被测软件相关的参数才能针对被测软件进行测试，因此相当于输入与测试对象相关的参数），测试程序通过后台计算机的通讯口下发测试用例给目标平台里的被测试软件（由于整个测试过程自动运行，且下发测试用例是响应于该测试用例的，而下发测试用例是一种发送测试请求的方式，因此相当于响应于输入与测试对象相关的参数，自动地触发如下操作：向所述测试对象发送测试请求）；收集在某一测试用例下被测程序的运行结果，将运行结果打包处理，通过通讯口以通讯的方式上报给后台计算机（由于运行结果是来自于被测程序与测试用例的，因此相当于接收来自所述测试对象的、与所述参数相对应的返回值）；后台计算机对反馈的该测试用例运行结果与预期结果进行比较，并统计比较结果（由于比较测试用例的运行结果和预期结果也是一种验证的方式，因此相当于通过验证所述返回值而获得测试结果）。目标平台接受后台下发的数据（测试用例），解包处理后台下发的数据（由于有解包则必然会有打包，因此打包测试用例相当于对输入的所述参数进行封装）；测试程序通过后台计算机的通讯口下发测试用例给目标平台里的被测试软件（由于下发测试用例是响应于该测试用例的，并且下发测试用例是一种发送测试请求的方式，因此相当于响应于输入所述参数，向所述测试对象发送测试请求）。
与对比文件1公开的内容相比，权利要求1的区别技术特征是：1）启动测试的与测试对象相关的参数是由用户输入的；2）其中所述测试对象是应用程序编程接口，其中当所述应用程序编程接口基于http协议时，所述测试请求是http请求，根据不同的http协议对输入的所述参数进行智能化拼装。基于上述区别技术特征，可以确定权利要求1实际解决的技术问题是如何获得与测试对象相关的参数以及应用测试方法并智能拼装参数。
针对上述区别技术特征1），在执行自动化测试时，测试相关参数可以在测试中自动生成或调用，也可以通过输入的方式获得，而用户、测试人员、和/或开发人员等都可以有权限进行输入操作，因此本领域技术人员容易想到启动测试的与测试对象相关的参数是由用户输入的。
针对上述区别技术特征2），对本领域技术人员来说，在编写测试用例所需考虑的测试对象有很多，被测软件、应用程序编程接口等都是常用的测试对象，而软件测试领域的一种测试方法思想通常可以兼容不同的测试对象，因此将对比文件1中公开的测试方法用于应用程序编程接口的测试中是本领域技术人员的惯用技术手段。而当接口基于http协议时，向接口发送http请求是本领域技术人员的惯用手段，而对参数根据不同的http协议进行智能化拼装也是本领域技术人员的惯用手段。
由此可见，在对比文件1的基础上，结合本领域技术人员的惯用手段得到权利要求1所请求保护的技术方案对本领域技术人员来说是显而易见的，因此该权利要求不具备突出的实质性特点和显著的进步，不符合专利法第22条第3款有关创造性的规定。
2. 权利要求2-4不具备专利法第22条第3款规定的创造性。
权利要求2引用权利要求1。对比文件1还公开了以下特征（参见说明书第2页第18行-第3页第8行，附图1）：计算机后台测试程序在接收到目标平台里的测试用例的运行结果后，将该实际运行结果（相当于返回值）与后台计算机根据被测试程序的功能设计要求进行预期的正确运行结果（相当于已存储的与所述参数相对应的验证值）进行比较（相当于将所述返回值和已存储的与所述参数相对应的验证值进行比较）；若实际运行结果与预期结果一致（相当于在所述返回值等于所述验证值时），则表示被测试软件执行该测试用例所实现的功能正确，测试通过（相当于将所述测试结果确定为合格）；若实际运行结果与预期结果不一致（相当于在所述返回值不等于所述验证值时），则说明被测程序可能不能正确执行（由于程序不能正确执行则表明程序没有通过测试，因此相当于该功能将所述测试结果确定为不合格）。由此可见，权利要求2进一步限定的附加技术特征被对比文件1公开。因此，当其引用的权利要求不具备创造性时，该权利要求也不具备突出的实质性特点和显著的进步，不符合专利法第22条第3款有关创造性的规定。
权利要求3引用权利要求1，对比文件2公开了一种测试覆盖率的确定方法，其具体公开了以下特征（参见第32页第5-10行）：测试覆盖率通过以下公式计算：
测试覆盖率=T(p,I,x,s)/RfT
其中，T使用测试过程或测试用例表示的测试（test）数（已计划的、已实施的或成功的）；RfT是测试需求（requirement for test）的总数（相当于根据所述参数中的已被测试的参数与所述参数的比例，确定参数测试的覆盖率）。由此可见，对比文件2公开了“根据所述参数中的已被测试的参数与所述参数的比例，确定参数测试的覆盖率”。上述特征在对比文件2中所起的作用与其在本申请所起的作用相同，都是用于确定测试覆盖率保证测试结果的全面性，因此对比文件2给出了将上述技术特征用于对比文件1以解决其技术问题的启示。而对于计算机网络领域技术人员来说，在进行测试时，为了保证测试结果的全面性，会在测试时设置一个覆盖率阈值，当测试用例不满足覆盖率要求时需要对剩余的用例继续进行测试，因此在所述参数测试的覆盖率小于预定阈值时，继续测试所述参数中的除所述已被测试的参数之外的参数，这是本领域技术人员容易想到的，这属于本领域技术人员的惯用手段。由此可见，在对比文件1的基础上，结合对比文件2和本领域技术人员的惯用手段得到权利要求3所请求保护的技术方案对本领域技术人员来说是显而易见的，因此当其引用的权利要求不具备创造性时，该权利要求不具备突出的实质性特点和显著的进步，不符合专利法第22条第3款有关创造性的规定。
权利要求4引用权利要求1，对比文件2公开了一种测试覆盖率的确定方法，其具体公开了以下特征（参见第32页第5-10行）：测试覆盖率通过以下公式计算：
测试覆盖率=T(p,I,x,s)/RfT
其中，T使用测试过程或测试用例表示的测试（test）数（已计划的、已实施的或成功的）；RfT是测试需求（requirement for test）的总数（相当于根据所述参数中的已被测试的参数与所述参数的比例，确定参数测试的覆盖率）。由此可见，对比文件2公开了“根据所述参数中的已被测试的参数与所述参数的比例，确定参数测试的覆盖率”。上述特征在对比文件2中所起的作用与其在本申请所起的作用相同，都是用于确定测试覆盖率保证测试结果的全面性，因此对比文件2给出了将上述技术特征用于对比文件1以解决其技术问题的启示。而对本领域技术人员来说，在进行测试时，为评价测试质量，常常会将测试覆盖率划分为几个不同的等级，覆盖率高则测试质量高，反之则测试质量低。因此，在所述参数测试的覆盖率小于第一预定阈值时，将测试质量评估为低；在所述参数测试的覆盖率大于或等于所述第一预定阈值且小于第二预定阈值时，将所述测试质量评估为中；以及在所述参数测试的覆盖率大于或等于所述第二预定阈值时，将所述测试质量评估为高，这是本领域技术人员容易想到的，这属于本领域技术人员的惯用手段。由此可见，在对比文件1的基础上，结合对比文件2和本领域技术人员的惯用手段得到权利要求4所请求保护的技术方案对本领域技术人员来说是显而易见的，因此当其引用的权利要求不具备创造性时，该权利要求不具备突出的实质性特点和显著的进步，不符合专利法第22条第3款有关创造性的规定。
3. 权利要求5不具备专利法第22条第3款规定的创造性。
权利要求5请求保护一种测试系统。对比文件1公开了一种嵌入式软件测试方法，其具体公开了以下特征（参见说明书第2页第18行-第3页第8行，附图1）：测试人员在启动测试后，可不必待在现场观察每个测试用例的运行情况，只需查看后台计算机的统计记录就知道整个测试结果；测试程序能自动生成或调用针对被测软件的各种测试用例（由于测试用例是根据被测软件的需求生成或调用的，因此相当于输入与测试对象相关的参数），测试程序通过后台计算机的通讯口下发测试用例给目标平台里的被测试软件（由于整个测试过程自动运行，且下发测试用例是响应于该测试用例的，而下发测试用例是一种发送测试请求的方式，因此相当于响应于输入与测试对象相关的参数，自动地向所述测试对象发送测试请求）；收集在某一测试用例下被测程序的运行结果，将运行结果打包处理，通过通讯口以通讯的方式上报给后台计算机（由于运行结果是来自于被测程序与测试用例的，因此相当于接收来自所述测试对象的、与所述参数相对应的返回值）；后台计算机对反馈的该测试用例运行结果与预期结果进行比较，并统计比较结果（由于比较测试用例的运行结果和预期结果也是一种验证的方式，因此相当于通过验证所述返回值而获得测试结果）。目标平台接受后台下发的数据（测试用例），解包处理后台下发的数据（由于有解包则必然会有打包，因此打包测试用例相当于对输入的所述参数进行封装）；测试程序通过后台计算机的通讯口下发测试用例给目标平台里的被测试软件（由于下发测试用例是响应于该测试用例的，并且下发测试用例是一种发送测试请求的方式，因此相当于响应于输入所述参数，向所述测试对象发送测试请求）。
与对比文件1公开的内容相比，权利要求5的区别技术特征是：1）该权利要求请求保护一种测试系统，包括测试请求发送装置、返回值接收装置和验证装置；启动测试的与测试对象相关的参数是由用户输入的；2）其中所述测试对象是应用程序编程接口，其中当所述应用程序编程接口基于http协议时，所述测试请求是http请求，根据不同的http协议对输入的所述参数进行智能化拼装。基于该区别技术特征，可以确定权利要求5实际解决的技术问题是如何实现测试方法中相应的步骤以及应用测试系统并智能拼装参数。
针对上述区别技术特征1），对于计算机网络技术领域的技术人员来说，常采用装置来实现相应的功能，因此测试系统包括测试请求发送装置、返回值接收装置和验证装置，它们分别实现测试方法中对应的步骤，这属于本领域技术人员的惯用手段。其次，在执行自动化测试时，测试相关参数可以在测试中自动生成或调用，也可以通过输入的方式获得，而用户、测试人员、和/或开发人员等都可以有权限进行输入操作，因此本领域技术人员容易想到启动测试的测试对象相关的参数是由用户输入的。
针对上述区别技术特征2），对本领域技术人员来说，在编写测试用例所需考虑的测试对象有很多，被测软件、应用程序编程接口等都是常用的测试对象，而软件测试领域的一种测试方法思想通常可以兼容不同的测试对象，因此将对比文件1中公开的测试方法用于应用程序编程接口的测试中是本领域技术人员的惯用技术手段。而当接口基于http协议时，向接口发送http请求是本领域技术人员的惯用手段，而对参数根据不同的http协议进行智能化拼装也是本领域技术人员的惯用手段。
由此可见，在对比文件1的基础上，结合本领域技术人员的惯用手段得到权利要求5所请求保护的技术方案对本领域技术人员来说是显而易见的，因此该权利要求不具备突出的实质性特点和显著的进步，不符合专利法第22条第3款有关创造性的规定。
4. 权利要求6-8不具备专利法第22条第3款规定的创造性。
权利要求6引用权利要求5。对比文件1还公开了以下特征（参见说明书第2页第18行-第3页第8行，附图1）：计算机后台测试程序在接收到目标平台里的测试用例的运行结果后，将该实际运行结果（相当于返回值）与后台计算机根据被测试程序的功能设计要求进行预期的正确运行结果（相当于已存储的与所述参数相对应的验证值）进行比较（相当于将所述返回值和已存储的与所述参数相对应的验证值进行比较）；若实际运行结果与预期结果一致（相当于在所述返回值等于所述验证值时），则表示被测试软件执行该测试用例所实现的功能正确，测试通过（相当于将所述测试结果确定为合格）；若实际运行结果与预期结果不一致（相当于在所述返回值不等于所述验证值时），则说明被测程序可能不能正确执行（由于程序不能正确执行则表明程序没有通过测试，因此相当于该功能将所述测试结果确定为不合格）。与对比文件1公开的内容相比，权利要求6的又一区别技术特征是：比较单元，测试结果确定单元。基于该区别技术特征，可以确定权利要求6实际解决的技术问题是如何实现测试方法中相应的步骤。对于本领域技术人员来说，常采用装置来实现相应的功能，因此由比较单元和测试结果确定单元分别实现测试方法中对应的步骤，这是本领域技术人员容易想到的，这属于本领域技术人员的惯用手段。由此可见，当其引用的权利要求不具备创造性时，权利要求6也不具备突出的实质性特点和显著的进步，不符合专利法第22条第3款有关创造性的规定。
权利要求7引用权利要求5，对比文件2公开了一种测试覆盖率的确定方法，其具体公开了以下特征（参见第32页第5-10行）：测试覆盖率通过以下公式计算：
测试覆盖率=T(p,I,x,s)/RfT
其中，T使用测试过程或测试用例表示的测试（test）数（已计划的、已实施的或成功的）；RfT是测试需求（requirement for test）的总数（相当于根据所述参数中的已被测试的参数与所述参数的比例，确定参数测试的覆盖率）。由此可见，对比文件2公开了“根据所述参数中的已被测试的参数与所述参数的比例，确定参数测试的覆盖率”。上述特征在对比文件2中所起的作用与其在本申请所起的作用相同，都是用于确定测试覆盖率保证测试结果的全面性，因此对比文件2给出了将上述技术特征用于对比文件1以解决其技术问题的启示。而对于本领域技术人员来说，在进行测试时，为了保证测试结果的全面性，会在测试时设置一个覆盖率阈值，当测试用例不满足覆盖率要求时需要对剩余的用例继续进行测试，因此在所述参数测试的覆盖率小于预定阈值时，继续测试所述参数中的除所述已被测试的参数之外的参数，并且采用覆盖率确定装置来实现测试覆盖率的确定，这是本领域技术人员容易想到的，这属于本领域技术人员的惯用手段。由此可见，在对比文件1的基础上，结合对比文件2和本领域技术人员的惯用手段得到权利要求7所请求保护的技术方案对本领域技术人员来说是显而易见的，因此当其引用的权利要求不具备创造性时，该权利要求也不具备突出的实质性特点和显著的进步，不符合专利法第22条第3款有关创造性的规定。
权利要求8引用权利要求5，对比文件2公开了一种测试覆盖率的确定方法，其具体公开了以下特征（参见第32页第5-10行）：测试覆盖率通过以下公式计算：
测试覆盖率=T(p,I,x,s)/RfT
其中，T使用测试过程或测试用例表示的测试（test）数（已计划的、已实施的或成功的）；RfT是测试需求（requirement for test）的总数（相当于根据所述参数中的已被测试的参数与所述参数的比例，确定参数测试的覆盖率）。由此可见，对比文件2公开了“根据所述参数中的已被测试的参数与所述参数的比例，确定参数测试的覆盖率”。上述特征在对比文件2中所起的作用与其在本申请所起的作用相同，都是用于确定测试覆盖率保证测试结果的全面性，因此对比文件2给出了将上述技术特征用于对比文件1以解决其技术问题的启示。而对本领域技术人员来说，在进行测试时，为评价测试质量，常常会将测试覆盖率划分为几个不同的等级，覆盖率高则测试质量高，反之则测试质量低。因此，在所述参数测试的覆盖率小于第一预定阈值时，将测试质量评估为低；在所述参数测试的覆盖率大于或等于所述第一预定阈值且小于第二预定阈值时，将所述测试质量评估为中；以及在所述参数测试的覆盖率大于或等于所述第二预定阈值时，将所述测试质量评估为高，并且采用覆盖率确定装置和测试质量评估装置来实现测试覆盖率的确定与评估，这是本领域技术人员容易想到的，这属于本领域技术人员的惯用手段。由此可见，在对比文件1的基础上，结合对比文件2和本领域技术人员的惯用手段得到权利要求8所请求保护的技术方案对本领域技术人员来说是显而易见的，因此当其引用的权利要求不具备创造性时，该权利要求也不具备突出的实质性特点和显著的进步，不符合专利法第22条第3款有关创造性的规定。
对复审请求人相关意见的评述
针对复审请求人2019年05月31日提交的意见陈述，合议组认为：（1）当接口基于http协议时，向接口发送http请求是本领域技术人员的惯用手段，而对参数根据不同的http协议进行智能化拼装也是本领域技术人员的惯用手段。并且本申请中对于智能化拼装的描述仅为：术语“封装”表示根据不同的http协议方式对参数进行智能化拼装，例如直接根据get、post函数来对参数进行拼装。而get和post函数都是http协议测试领域常用函数，本领域技术人员容易想到利用get、post函数对参数进行拼装，因此，对参数根据不同的http协议进行智能化拼装也是本领域技术人员的惯用手段；（2）复审通知书中并不是将测试用例相当于权利要求1中“与测试对象相关的参数”，而是认为测试用例中必然包含与测试对象相关的参数，其可能是参数的某种组合或拼装，那么，在向测试软件输入测试用例时相当于输入与测试对象相关的参数，而且如本申请后面发送测试请求的步骤，本申请也不是将参数直接输入被测对象中，而是对参数进行了拼装。因此，合议组对复审请求人的意见不予支持。
三、决定
维持国家知识产权局于2018年08月14日对本申请作出的驳回决定。
如对本复审请求审查决定不服，根据专利法第41条第2款的规定，复审请求人可自收到本决定之日起三个月内向北京知识产权法院起诉。
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。
