一种基于软件产品生命周期的用户体验测试方法与流程

文档序号:11582517阅读:300来源:国知局

本发明涉及软件设计技术领域,具体地说是一种基于软件产品生命周期的用户体验测试方法。



背景技术:

社会经济形态不断发生着变化,从产品经济、商品经济再到服务经济,从20世纪90年代,人类又进入了新的经济时代——体验经济。在经济社会发展到体验阶段以及it技术发展必然条件下,对于企业研发出高质量的软件产品,挖掘用户价值、吸引用户,提高产品市场占有率等方面用户体验的价值突显,提高软件产品的用户体验势在必行。对于用户体验的提升与改进,除了设计与研发人员的努力外,测试过程必不可少。一套好的用户体验测试方法,可以检测出更多的用户体验问题,规避更多的用户体验性障碍,进一步保证了上线产品的体验质量。

现阶段在产品工业设计领域有一些用户体验测试方法,但是在软件产品用户体验测试领域还是缺少科学的系统的测试方法。有的也是一些针对软件产品的某一环节或某一阶段开展的测试方法,测试方法比较单一和薄弱、缺少系统性和全面性,并且大多是理论描述。众所周知,用户体验来源于实际用户使用中的主观感受,由于软件产品特别是互联网产品涉及的用户使用群体多样、复杂,因此给用户体验测试带来很多困难。单一的测试方法并不能全面科学的反映出用户体验问题的实质。



技术实现要素:

本发明的技术任务是针对以上不足之处,提供一种基于软件产品生命周期的用户体验测试方法,通过定性、定量等多个维度的测试方法,从不同角度出发,加大了测试的深度和广度,提高了发现各类用户体验问题的概率,进一步保证了产品的用户体验。

本发明解决其技术问题所采用的技术方案是:

一种基于软件产品生命周期的用户体验测试方法,结合软件产品生命周期的用户体验测试,是一系列与软件开发阶段相结合的用户体验测试方法的集合,包括可用于软件产品用户体验测试的五种方法,分别是产品设计阶段的专家评估法、原型开发阶段的可用性测试、可运行阶段的易用性测试、试运行阶段的全民ce和上线后的定量测试,并对每种方法有配套的介绍和操作流程,可以全面、科学、系统地进行软件产品用户体验测试。

具体测试内容包括:专家评估、可用性测试、易用性测试、全民ce、定量测试。

本发明的一种基于软件产品生命周期的用户体验测试方法和现有技术相比,具有以下有益效果:

通过多个测试方法的分阶段应用,以不同的角度和方法层层测试,为软件产品用户体验测试提供全面的、科学的、系统的、可操作的测试方法,对于开发出高质量的满足用户使用要求的产品起到关键作用;。

结合软件开发生命周期各阶段,使用不同的五种测试方法,对软件产品用户体验进行全面测试;

秉承尽早测试的理念减少软件产品投放市场后因用户体验问题的返工成本,为企业节省经济成本;

依据国家软件质量模型中软件产品易用性的要求,具有专业性和权威性;

来源于本单位多年来在软件产品用户体验测试领域实践总结,测试方法全面、测试步骤细致,具有较强的可操作性;

使用本单位自研发的一款用户体验定量测试工具,可为用户体验测试提供准确的量化测试数据,是定性分析方法的有益补充;

本发明覆盖软件开发全生命周期各阶段适用的五种测试方法,从定性测试和定量测试两个方面出发,测试执行人群涉及专家、目标客户代表、专业测试人员、最终用户等多类群体,既有理论依据又有实践总结出的操作流程,是比较全面、科学、系统、可操作的用户体验测试方法,填补目前软件产品用户体验测试领域的空白。对软件产品在体验上的持续改进,研发出高质量用户使用满意的软件产品方面具有广泛的社会价值。

具体实施方式

下面结合具体实施例对本发明作进一步说明。

一种基于软件产品生命周期的用户体验测试方法,结合软件产品生命周期的用户体验测试,是一系列与软件开发阶段相结合的用户体验测试方法的集合,包括可用于软件产品用户体验测试的五种方法,分别是产品设计阶段的专家评估法、原型开发阶段的可用性测试、可运行阶段的易用性测试、试运行阶段的全民ce和上线后的定量测试,并对每种方法有配套的介绍和操作流程,可以全面、科学、系统地进行软件产品用户体验测试。

1、专家评估

1)、测试方法介绍

专家评估是集合公司对用户体验需求、设计、测试有经验的人员组成虚拟的专家小组,在涉及产品用户体验的各个环节进行评审工作,用于设计初期提出评审意见,避免后期修改产生大的返工工作量。

2)、参与者和职责

参与者角色主要包括:产品经理、用户体验设计人员、研发经理、测试人员。

产品经理更了解产品的核心价值,产品定位,用户需求和期望,在用户战略规划时提出更多建议。

用户体验设计人员利用丰富的设计理念和经验对不同产品存在的用户体验问题提出自己的建议。

研发经理要考虑在用户体验前后台交互代码实现的技术方式。

测试人员从用户角度提出使用中的存在的影响用户体验的问题。

专家评估小组的参与者根据各自领域知识和经验参与用户体验的战略层、范围层、结构层、框架层、表现层的重点设计的评审工作,提出各类影响用户体验的问题。

3)、测试流程

a、需要进行用户体验专家评估的单位向用户体验虚拟小组组长提出评估任务,明确用户体验专家评估的目标。以便组织合适角色的人员参与。

b、用户体验虚拟小组组长选择合适的专家评估成员,形成专家评估组

c、专家评估组根据评估任务制定评估计划,获得任务提出单位同意

d、任务提出单位协同专家评估组完成评估工作

e、评估材料存档,价值信息保存到知识库

4)、测试方法总结

适用场景:

可用性测试、a/b测试、全面参与多集中在产品的后期的用户体验评估工作,更多是从产品使用时提出用户体验问题。但是我们希望在产品规划阶段、设计阶段就开始进行用户体验的评估工作,专家评估可以更早期的参与用户体验评估工作。

带来价值:

因各部门用户体验设计人员比较分散,平时横向沟通比较少,利用虚拟小组可以相互借鉴设计经验和理念,提升多产品领域的用户体验。

注意事项:

因用户体验小组是以虚拟形式存在,各人员隶属于不同的部门,并且不在用一个办公地点,协调大家一起参与某产品评估,可能在时间上存在风险。因此可以提前提出评估任务,按时间情况选择其中有时间参与的人员;

做好参与专家评估人员激励。

2、可用性测试

1)、测试方法介绍

可用性测试一般可从高保真原型开始介入。

用户与产品设计者在想法及做法上存在差异,这是大多数可用性问题存在的主要原因,因此了解用户使用我们产品时的想法及做法,便成了提高产品可用性的有效途径,这便是可用性测试的基本思想。现如今可用性测试已成为各大互联网公司皆采用的对软件产品的可用性进行校验及研究的方法。

可用性测试是指让用户使用产品(服务)的设计原型或者成品,通过观察,记录和分析用户的行为和感受,以改善产品(服务)可用性的一系列方法。它适用于产品(服务)前期设计开发,中期改进和后期维护完善的各个阶段,是以用户为中心设计思想的重要体现。

可用性测试的是用户在我们的产品上执行预先制定的测试场景,主持人在旁引导用户说出他的想法,但引导过程中不能带有个人观点,亦不能在操作上给用户提醒。观察记录用户使用过程反映出的可用性问题。

可用性测试的结果不仅可以评价软件可用性的优劣、定位软件产品的可用性问题,还可以解决软件研发过程中产生的争议,因此可用性测试的过程需要客观,特别是对用户的引导过程,即可用性测试的主持人的工作内容,对于组织机构完善的互联网公司而言,可用性测试多由独立于该研发项目的用户体验或可用性专职人员组织进行。

2)、测试流程

标准的可用性测试,人力物力成本比较高,因此很可能导致可用性测试的次数大大降低,甚至不进行可用性测试,以至于后期需要投入大量的精力对其可用性问题进行改进。

我们考虑可投入的成本及可用性测试实践总结,形成一种设备要求简单,测试流程短,成本较低的可用性测试方法下面介绍一下可用性测试的主要实施流程:

测试前准备,

选择测试场景,

在可用性测试的过程中,我们要观察的是用户的做法,基于对做法的分析找到问题的源头,因此在进行可用性测试时,我们要尽可能地还原用户的实际操作情况,对于一般用户而言,用户在软件产品上的操作是有背景、有目的的,因此可用性测试的过程,需要给用户提供目的清晰的系列场景。场景设计一般包含用户角色、登录账号、前置条件、场景描述等方面内容。

招聘参与者,

对于可用性测试中参与者的招聘问题,最基本的要求是:非项目相关人员。一般3-5人,即可达到一轮的测试效果。该环节可由主持人向产品研发团队了解该产品的目标用户类型,根据测试需求确定参与者类型,并将其描述出来。本次参与者的选择,可从下面几个角度考虑:

根据目标用户选择参与者,也就是产品的最终使用者或潜在使用者:如年龄要符合产品的目标年龄层、男女比例要符合产品的目标用户比例等,并且将来会使用或者很可能使用该产品的目标用户。

根据测试需求和目的的不同,也需选择潜在用户、新手用户、普通用户或者高级用户。例如,在旧版本的基础上进行改进,则需要未接触过该产品的潜在用户及已使用过该产品的用户(新手用户、普通用户、高级用户)参与测试。

如果只是简单地为了发现产品中存在哪些可用性问题,降低用户标准也是一种可行的方法:以公司内部员工充当用户,但建议选择非软件相关岗位的员工,如财务、人力等。

测试设备:

对于以发现严重问题为目的的简易可用性测试而言,所需的设备是比较简单的:

场所:办公室。若工作人员不多,2-3个人,一个办公室即可;若工作人员较多,建议主持人、记录人与参与者在一间办公室,观察者在另一间办公室(带有投影设备)。

设备:笔记本电脑一台且安装屏幕录制软件及屏幕共享软件、麦克风一个。

注:屏幕录制软件用于录制测试过程中参与者的操作情况,屏幕共享软件用于将当前的操作内容共享给另一间办公的观察者观看。同时,录制的视频可供日后分析,或提供给未参加本次可用性测试的其他项目相关人员观看。笔记本可正常访问待测产品。

进行测试,

向参与者介绍注意事项,

需涉及以下几点:

我们要测试的是网站,而不是你。

在测试期间你有任何问题,都可以问,我们可能不能立刻回答。

在测试过程中,我们将把屏幕上发生的情况以及我们之间的谈话录下来。当然录像只会用于我们确定改进网站的方法,而不会被与该项目无关的任何人看到。

与参与者进行简单的沟通,

测试的结果会受到参与者的职业,性别,上网习惯,性格特点等影响,测试前了解一些基本信息,有利于对测试结果的分析,因此在测试之前,可由主持人向参与者询问下列信息:

你从事哪种职业,每天都做些什么呢,

你每周上网大概多少小时,

浏览网页大概都访问什么样的网站,有非常喜欢的网站么,

主页观光,

主页作为网站的第一个页面,影响用户对网站的评价,甚至直接影响用户的去留,所以主页一定要清晰地表达网站的用途,并且能够吸引住用户。因此,在开始之前,由主持人引导参与者浏览下主页是非常必要的,这里可以简单提及几个问题:

你觉得什么地方最吸引你

这是个做什么的网站,你能在这里做什么,

参与者在主页随意浏览,尽量留在主页,不要进行其他操作。

执行测试场景,

该环节由参与者边说边执行测试场景,主持人在旁引导,记录员及观察者记录出现的问题。

主持人的工作,

主持人宣读测试场景,引导参与者执行场景并说出其感受。主持人要尽量营造一个真实的操作氛围,过程中要保持态度中立,不能在操作及想法上给用户暗示,同时,尽量保证能够掌握参与者每个操作背后的想法,因为参与者操作背后的动机会成为我们改进该问题的依据。测试过程中可以提问,但不能过多,当用户困惑时,不能给出帮助,可以给出鼓励,必要时可以终止测试。

问题记录工作,

记录主要由记录员及观察者进行,有精力的主持人也可简单记录,无论是有条件实时观察,或者需要后续看录像进行观察,记录时都要注意,记录的重点不是参与者说了什么,而是参与者如何使用。参与者所说的,会包含一定程度的个人喜好,甚至是“包装”过的内容。记录问题时,不必苦思冥想着解决方法,不仅会分散观察精力,而且马上想到的方案或者参与者提出的方案并不一定是最好的,这个工作可以留待可以安静思考或者大家讨论时进行。

问题探讨,

在所有测试场景执行后,由主持人问一些需要参与者澄清的内容(最好收集各观察者的内容),如:

你在这里这样做的用意是…对吗,

你为什么要那样做呢,

“没有注意到左边的导航栏”或者“选择第二个链接”为什么,

测试后总结,

测试结果的整理应及时,以解决重点问题为目的进行讨论:

主持人、记录人、观察者及时沟通,最好测试后立即沟通,以免后期遗忘,确定的可用性问题,按严重程度及出现频率(影响范围)制定优先级,并汇总简要的测试报告,以抛出问题为主。(若观察人员较多,可直接确定解决方案,并确定解决问题的关键人)

报告确认后,召开会议,将测试结果与相关人员分享。

确定需要优化的具体问题,确定解决问题的大体方案,确定解决问题的关键人。

采用最简单的方式修改可用性问题。对于发现的可用性问题,其中的一些可能不能立即消除问题的根源,但是总是可以采取一些措施来减轻该问题对用户的影响(如,删除某功能的入口),特别是已经发布的产品,及时修改问题很重要,制定较为复杂的计划或推后处理的结果可能就是不处理,那么我们的可用性测试的作用就消失了。

3)、可用性测试中的其他说明

关于“尽早测试,越早越好”:

与普通的测试一样,可用性测试也要求尽早测试,但是不是越早越好呢。可用性测试最早可从设计原型开始,设计原型包括:低保真、中保真及高保真。低保真的优点是较早的将用户意见反馈给了设计者,将内容架构展示给用户看,剔除了视觉的影响,有问题可以提早纠正;缺点是低保真,与用户实际使用的网页/软件差异大,需要对参加人员进行培训,无法展示丰富的交互内容,生态效度不高,同时为配合测试任务所需制作的纸面原型也很耗时。中保真兼具高低保真的特点,如果只能进行一次原型测试,可选择此类。高保真与成品比较接近,便于开展测试,但是相对来讲如有问题,修改的成本相对较高。对于不是很大的产品而言,建议采用高保真原型进行测试。

关于可用性测试文档:

在可用性测试过程中关注的是用户的操作,特别是存在问题的操作,但是在第三方形成可用性测试文档时,建议不仅仅列出产品的可用性问题,最好列出几项最重要的优点,这样会让产品研发人员感到欣慰、感受到你中立的态度,增加对报告的接纳程度,同时,当你在报告中再次强调时,可以避免在后期迭代开发中丢失掉原本的优点。

若主持人及记录人为用户体验或可用性相关人员,则文档中亦可从专业角度提出比较好的改进建议,可采用“启发式评估报告”的形式。

可用性测试的优劣:

可用性测试是通过观察用户对产品的使用过程来判断产品优劣的测试方法,较单纯的咨询用户想法而言,能够更准确的反应产品的情况。但由于可用性测试抽取的测试样本较小,因此其结果更倾向于定性结果,同时,在结果的分析过程中,会融入测试人员的判断,可用性测试结果的好坏在一定程度上还受测试人员经验的影响。总之,可用性测试是一种实用容易上手且效果较好的测试方法。

3、易用性测试

本发明所在单位具有多年软件测试经验,已通过cnas认证及工信部的能力评定,且已获得cmmi5认证。目前gb/t16260.1–2006《软件工程产品质量第一部分:质量模型》为本单位进行软件测试的主要依据标准之一,经单位在易用性这一质量特性上的多年积累和对用户体验测试的充分研究,最终提炼出一套用户体验测试方法——易用性测试,这是传统的软件测试方法与用户体验测试的第一次结合,也是gb/t16260.1–2006中易用性测试在用户体验测试领域的首次应用。

易用性测试是由易用性测试工程师对产品进行系统全面的测试,以快速发现产品中大部分体验类问题并给出改进建议。该测试方法较依赖测试人员的能力,需要测试人员具有丰富的易用性测试经验,以便能够快速、准确的发现更多的用户体验问题。为规范易用性测试工程师的测试行为和指导新员工,本单位依据不同设备的设备特点及用户使用习惯,总结归纳出一套易用性测试规范,规范由两部分组成:pc端软件产品易用性测试规范及移动端软件产品易用性测试规范。

不同类型的设备具有不同的设备特点,同时也决定了用户的使用行为及习惯会存在较大的不同。对于pc端而已,用户一般通过鼠标、键盘完成大多数的操作,较移动设备而言,属于间接式的操作体验,一般的pc设备具有13寸及其以上的屏幕大小,基于以上种种,用户会形成一系列针对这一类设备的操作及浏览习惯,如纵向滚动条,就是一个非常符合鼠标使用特点的存在,除此之外,还有导航、配色、操作、各类组件、加载、反馈等等符合设备特点的体验要求,本规范即是对以上内容的详细阐述及要求规范,并配有用避免的和建议采取的实现方式。

移动设备较pc设备而已,在使用特点上有明显的不同,首先移动设备的操作体验比较直观,大多数的操作通过触摸完成,且设备小可随身携带,也可随时使用,因而在用户使用场景和用户使用姿势及状态上会有很大不同,但同时由于网络、电源等种种限制导致操作可能随时中断,所以移动设备在体验的具体要求上跟pc设备有较大区别,因而需要针对移动设备提供一套新的具有针对性的规范。

4、全民ce

1)、测试方法介绍

现阶段,各大型互联网公司都在提倡“全民ce”这一理念,“ce“即customerengagement(全民参与)。“全民ce”与通常意义上的测试方法有本质上的差异,它更像是一种企业文化,它号召公司中的每一位员工都能非常关心自己的产品,常用这些产品,并且让身边人都使用它们,同时鼓励甚至奖励使用者讲出自己使用的感受,道出产品存在的不足,进而从中挖掘出更多的信息。它号召公司中的每一位员工关注用户体验,甚至将提升每个产品的用户体验作为自己的工作职责。

综上所诉,“全民ce”有以下特点:

参与人员多,收集到丰富的用户体验反馈。

面向公司员工,树立每个人都关注产品用户体验的意识。

2)、测试流程

本单位根据在全面ce方面的经验积累,梳理了以下测试流程:

产品分析,

为了选择合适的测试流程、测试方法、测试人群进而达到预期的测试目标,测试之前需对产品从以下几个方面进行分析。

产品的使用方式:web访问、移动终端、单机版、其它方式;

分析产品的目标客户:互联网用户、特定人群(特定人群类型);

全面ce的目标:做全民体验的目的是什么,想收集哪些方面的体验问题;

确定测试开展方式,

全面ce的方式,即从什么方式来发放需进行用户体验的产品,收集用户体验方面的反馈问题。(可以利用的平台:公开测试网址、公司内网、邮件发布通知等)

招募测试者,

根据目标客户和测试目的选取并招募进行测试参与者;

分析本次测试的目的,划定测试者范围;

分析产品的目标用户群体情况,按照特定比例抽样测试;

以组织单位,批量测试。

按照职能、年龄等几个维度划分,定向测试。按一定的规则指定各部分的组织者,粗略统计可参与测试的人员。

确定问题反馈与收集方法,

问题的反馈和收集可以采用的方式:

发放调查问卷,调查问卷中根据测试目标定义好问题及其备选项,若有需求,设置部分开放性问题,由测试者试用产品后填写并反馈调查问卷。

开放性调查,由使用者试用产品后,自己反馈遇到的任何体验不好的问题。

自动统计,在公开测试的网站中增加自动统计的功能,统计访问量、点击率、转化率等指标。

问题分析,

对收集的反馈问题进行汇总,分类,统计分析,找出典型问题制定改进方案。

4)测试配备

人员:参与角色职责。

发起者:提出为开发的产品做用户体验测试的团队或人员。

需要准备公开测试地址、产品分析、目标客户分析、测试目标分析等。并对反馈的问题进行统计分析,制定优化方案。

组织者:辅助发起者进行产品分析、目标客户分析和测试目的分析,制定并实施测试方案,收集反馈问题等。

测试者:根据目标客户和测试目的选定的测试参与者,负责进行产品试用,按要求反馈问题。

工具平台,

进行公开测试,反馈问题,收集问题的平台或者工具。

定义文档模板,

调查问卷的模板、问题分类分析的模板。

5)、测试方法总结

适用场景:

公司研发的产品在公司范围内也有典型代表的使用群体,可选定目标群体组织全民ce测试。

带来的价值:

全民ce可以快速发现大部分问题;

问题反馈集中。

提升全员对用户体验的关注度。

注意事项:

最要根据目标制定调查问题,并且要简单易用;

对反馈者提供奖励。

5、定量测试

定量测试,与上述其他测试方法有本质的区别,前文所介绍的测试方法皆为定性测试法,注重主观的判断,定量测试法需要数据的支撑,测试结果更为客观,但相对的测试数据的收集及分析工作较为繁琐,所以两种测试方式各有利弊,需相互补充。本发明中,所提到的定量测试,即是产品正式上线后,通过统计工具,统计用户在产品使用过程中的典型行为,通过对用户行为的分析找到产品中可以优化的方向,该测试方法需要较大的数据量,且是一个长期的工作。

定量测试的测试过程是数据收集、数据分析的过程,因而需要借助测试工具完成。对于外网产品,业界有一些测试工具。但是对于内网产品,由于网络的限制,一般的测试工具都无法正常运行,本说明使用本单位自主研发的可用于内网产品的用户行为分析工具,以弥补此方向上的不足。

流程说明:

日志采集,

主要采集访客对网站的访问轨迹(访问时间、访问页面、来源页面、客户端ip、浏览客户端、应用标识、用户标识)。可计算浏览量(pv)、访客数(uv)、ip数、平均停留时长。

定时转移日志,

定时器定时将日志转移到apacheflume监控目录,转移频率可根据业务需要进行设置。

日志收集、存储,

apacheflume将日志存储至hadoop/hive/mysql,具体采集哪种存储方式可根据业务需要进行设置。

计算服务,

针对采用mysql数据库进行日志存储的,定时启动计算服务进行计算,将计算结果存储至结果数据库。

网站统计,

根据结果数据库的数据,进行管理和界面展现。

以下情况视为新访客:

访客关闭浏览器后重新进入该网站;

访客不关闭浏览器,但是使用其他浏览器进入该网站;

访客不关闭浏览器,但是清除了缓存。

独立ip数,

说明:使用不同ip地址的用户访问网站的数量。

计算方法:统计之间内,用户访问网站时使用的不同ip地址的数量。

访客数(uv)

名词:uv=uniquevisitor(独立访客数)

说明:一天之内网站的独立访客数(以cookie为依据),一天内同一访客多次访问网站只计算1个访客。

计算方法:统计之间内,以cookie为依据的独立访客数。

浏览量(pv)

名词:pv=pageview(网站浏览量)

说明:用户每打开一个网站页面就被记录1次。用户多次打开同一页面,浏览量值累计。

计算方法:统计时间内,网站页面被打开的次数累加。

用户数

按照收集的用户标识来统计

访问深度(dv)

名词:网站访问深度就是用户在一次浏览网站的过程中浏览的网站的页数(相同页面只记录一次)。简称dv。(访客一次访问会话中浏览的不同页面数)

说明:网站访问深度就是用户在一次浏览你的网站的过程中浏览了你的网站的页数。如果用户一次性的浏览了你的网站的页数越多,那么就基本上可以认定,你的网站有他感兴趣的东西。

计算方法:

每个cookie的访问深度:统计时间内,每个cookie一次访问浏览的页数累加

每个user的访问深度:统计时间内,每个user一次访问浏览的页数累加

网站的访问深度:统计时间内,每个访问深度的访客数(uv)、用户数(user)

页面的平均停留时长

访客浏览某一页面时所花费的平均时长,页面的停留时长=进入下一个页面的时间-进入本页面的时间。

计算方法:页面的停留时长/浏览量(pv)

网站的平均停留时长

访客浏览网站时所花费的平均时长,网站的停留时长=最后一个页面的访问时间-第一个页面的访问时间。

计算方法:网站的停留时长/访客数(uv)

最后一个网页的停留时长

由于最后一个页面的关闭时间很难得到,如何计算最后一个页面的停留时长呢。针对未能收到关闭时间的页面将采取以下方法进行优化计算:

用户一次访问中只访问了一个页面而该页面的关闭时间未收到,则系统赋予该页面一定定值作为停留时长。

用户一次访问中涉及到n(n≥2)个页面,其中第n个页面的关闭时间无法收到,则系统将前(n-1)个页面的平均停留时长作为第n个页面的停留时长。

通过上面具体实施方式,所述技术领域的技术人员可容易的实现本发明。但是应当理解,本发明并不限于上述的具体实施方式。在公开的实施方式的基础上,所述技术领域的技术人员可任意组合不同的技术特征,从而实现不同的技术方案。

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1