本发明涉及终端测试技术领域，具体地涉及一种终端人机接口测试方法及系统。
背景技术：
在终端，例如手机、平板在出货之前，都需要预先实施测试，以确定整机各个零部件是否都组装了，并且验证这些零部件的功能是否都能正常运行。
但是，本申请的发明人在实践本申请的过程中发现：人机接口测试（mmitest）终端软件测试中的重中之重，使得终端软件测试都需要消耗较长的时间且极易遗漏，导致验证手机需要花费几天时间，下载各种硬件厂商的测试demo，并且里面测试功繁杂且不通俗易懂。
因此，如何高效可靠地完成mmitest，验证手机的整机硬件及功能完整性是目前业界的热门研究方向。
技术实现要素：
本发明实施例的目的是提供一种终端测试方法及系统，以至少解决现有技术中终端的mmitest人机接口测试效率低和可靠性差的技术问题。
为了实现上述目的，本发明实施例提供一种终端人机接口测试方法，包括：基于测试触发模块，获取与人机接口测试相关的多个测试用例，其中所述测试触发模块被配置有系统组用户权限；基于预定的关于所述多个测试用例的顺序依次执行各个所述测试用例，并检测所执行的所述各个测试用例的运行结果是否为通过，其中所述测试用例唯一对应于终端应用功能。
可选的，所述基于预定的关于所述多个测试用例的顺序依次执行各个所述测试用例，并检测所执行的所述各个测试用例的运行结果是否为通过包括：执行所述多个测试用例中的第一测试用例；响应于所述第一测试用例的执行，在终端的用户界面上显示供测试人员交互操作的多个运行结果选择控件；以及根据被交互操作所选择的所述运行结果选择控件，确定所述第一测试用例的运行结果是否为通过。
可选的，在所述在终端的用户界面上显示供测试人员交互操作的多个运行结果选择控件之后，该方法还包括：若检测到所述多个运行结果选择控件在预定时间段均未被选择，则生成触发用于触发终端执行重启操作的重启指令。
可选的，所述基于预定的关于所述多个测试用例的顺序依次执行各个所述测试用例并检测所执行的所述各个测试用例的运行结果是否为通过包括：当所述运行结果指示存在通过的测试用例时，按照所述顺序自动跳转至执行下一测试用例，并检测所跳转执行的所述下一测试用例的运行结果是否为通过。
可选的，所述基于预定的关于所述多个测试用例的顺序依次执行各个所述测试用例并检测所执行的所述各个测试用例的运行结果是否为通过包括：当所述运行结果指示存在未通过的测试用例时，在终端的用户界面上显示该未通过的测试用例所对应的终端应用功能。
可选的，所述终端应用功能包括音频测试功能，其中所述基于预定的关于所述多个测试用例的顺序依次执行各个所述测试用例并检测所执行的所述各个测试用例的运行结果是否为通过包括：当检测到执行所述音频测试功能所对应的测试用例时，生成音频关联命令；响应于所述音频关联命令，将终端的麦克风和扬声器关联连接；其中，所述麦克风用于接收测试声音，以及当所述扬声器发出对应于所述麦克风所接收到的所述测试声音的扬声信息时，确定对应于所述音频测试功能的测试用例的运行结果为通过。
可选的，所述终端应用功能包括输入防篡改功能，其中所述基于预定的关于所述多个测试用例的顺序依次执行各个所述测试用例并检测所执行的所述各个测试用例的运行结果是否为通过包括：当检测到执行所述输入防篡改功能所对应的测试用例时，生成自动读写命令；响应于所述自动读写命令，通过java本地接口方式向静态指定存储器写入并读取数据；其中，当所写入的数据与所读取的数据相匹配时，确定对应于所述防篡改功能的测试用例的运行结果为通过。
本发明实施例另一方面提供一种终端人机接口测试系统，包括：用例获取单元，用于基于测试触发模块，获取与人机接口测试相关的多个测试用例，其中所述测试触发模块被配置有系统组用户权限；用例测试单元，用于基于预定的关于所述多个测试用例的顺序依次执行各个所述测试用例，并检测所执行的所述各个测试用例的运行结果是否为通过，其中所述测试用例唯一对应于终端应用功能。
可选的，所述用例测试单元包括：用例执行模块，用于执行所述多个测试用例中的第一测试用例；控件显示模块，用于响应于所述第一测试用例的执行，在终端的用户界面上显示供测试人员交互操作的多个运行结果选择控件；结果确定模块，用于根据被交互操作所选择的所述运行结果选择控件，确定所述第一测试用例的运行结果是否为通过。
可选的，所述用例测试单元包括：用例自动执行模块，用于当所述运行结果指示存在通过的测试用例时，按照所述顺序自动跳转至执行下一测试用例，并检测所跳转执行的所述下一测试用例的运行结果是否为通过。
通过上述技术方案，基于已经配置有系统用户权限的测试触发模块，实现了对测试用例的获取和执行，并且由于多个测试用例是被按照预定的顺序来依次执行的，可以不需要测试人员花大量的时间去寻找或匹配测试用例，提高了测试效率；另外，所有的测试用例按照预定的次序执行，使得不会存在测试用例被遗漏测试的情况，保障了测试的全面性，也提高了人机接口测试mmitest的测试结果的可靠性。
本发明实施例的其它特征和优点将在随后的具体实施方式部分予以详细说明。
附图说明
附图是用来提供对本发明实施例的进一步理解，并且构成说明书的一部分，与下面的具体实施方式一起用于解释本发明实施例，但并不构成对本发明实施例的限制。在附图中：
图1是本发明一实施例的终端人机接口测试方法的流程图；
图2是安卓系统层状架构示意图；
图3是本发明一实施例的auto模式下的终端人机接口测试方法的原理流程图；
图4是本发明一实施例的manu模式下的终端人机接口测试方法的原理流程图；
图5是本发明一实施例的终端人机接口测试系统的结构示意图。
具体实施方式
以下结合附图对本发明实施例的具体实施方式进行详细说明。应当理解的是，此处所描述的具体实施方式仅用于说明和解释本发明实施例，并不用于限制本发明实施例。
如图1所示，本发明一实施例的终端人机接口测试方法，包括：
s11、基于测试触发模块，获取与人机接口测试相关的多个测试用例，其中测试触发模块被配置有系统用户权限和强制访问控制权限。
具体的，该方法可以应用于终端，例如可以是在终端的存储介质上存储有指令代码，并且该指令代码可以被终端运行以执行该方法。
以安卓系统为例，mmitest应用一般位于android系统架构的应用层，如图2所示的“yourapp”部分，但其是系统级应用，作为系统内置应用，共享系统组用户权限，android:shareduserid="android.uid.system"否则很多操作没有权限,所以部分测试项可直接调用framework层已有接口直接调用，还有部分测试项是framework层没有的接口，需要通过增加framework层接口实现，剩下部分测试项是直接通过节点读写访问，不需要增加framework层接口，直接通过驱动层的节点文件读写访问，但是上层应用访问节点会有很多文件读写权限限制，以及selinux权限限制，需要在系统层加上这些权限，否则不能操作节点。需说明的是，mmitest应用已经是一个系统级内置应用的基础上，还是有直接读写节点访问权限限制和selinux权限限制；因此，本申请提出：在系统级应用的基础上，继续对文件节点添加用户组权限和selinux权限，以便于添加用户组权限。
在本实施例中，可以是将mmitest应用相关程序代码设置在系统目录development/app/mmitest下，在此目录下，添加了android.mk编译进系统。androidmanifest.xml.mmi和androidmanifest.xml.sw，根据编译变量宏target_build_mmitest是true还是false来判断编译出来是正常版本，还是mini版本，生成androidmanifest.xml，里面定义系统级应用的权限；例如android:shareduserid="android.uid.system"package="com.android.mmi"xmlns:android="http://schemas.android.com/apk/res/android"><uses-sdkandroid:targetsdkversion="23"android:minsdkversion="18"/>
<uses-permissionandroid:name="android.permission.vibrate"/><uses-permissionandroid:name="android.permission.write_external_storage"/>等。所有这些需要访问的权限，可以是通过android原生的framework接口所用到的权限，如振动和读写sd卡等；另外，还有一些是通过直接读写驱动节点来判断硬件是否组装和功能是否ok，就需要添加用户组权限和selinux权限，如三个led灯的循环点亮显示，本来这些节点都是root组用户，app应用层是没有办法直接访问的，普通的第三方应用app更是没有权限去访问。针对此技术难点，本申请中的mmitest应用可以是共享系统组用户权限，所以此应用是系统组用户（android:shareduserid="android.uid.system），具体的，由于这些节点是root组用户，只有kernel层能访问，所以本申请提出可以在系统代码的device/t2m/apollo/init.target.rc文件中，将这几个节点改为system用户组：
chmod0666/sys/class/leds/red/brightness
chownsystemsystem/sys/class/leds/red/brightness
chmod0666/sys/class/leds/blue/brightness
chownsystemsystem/sys/class/leds/blue/brightness
chmod0666/sys/class/leds/green/brightness
chownsystemsystem/sys/class/leds/green/brightness
基于上述代码表达，可以实现将这几个节点的权限就强制改为system系统用户组。另外，针对一些系统层面的功能，该应用还是没有权限访问，因为还存在android系统的强制访问控制selinux权限限制，对此本申请提出还可以在系统代码的system_app.te文件中加入文件读写访问权限，对此，本申请还提出可以在device/t2m/common/sepolicy/file.te中加入针对测试应用所要访问文件类型的声明（例如typesysfs_t2m_mmi,sysfs_type,fs_type,data_file_type）。
s12、基于预定的关于多个测试用例的顺序依次执行各个测试用例，并检测所执行的各个测试用例的运行结果是否为通过，其中测试用例唯一对应于终端应用功能。
关于人机接口测试的模式可以包括自动和手动模式，其中在自动模式下由于一些测试结果需要人工介入才可以实现，所以所推荐的自动模式也可以是半自动化的。
在一些实施方式中，s12的执行可以具体包括如下步骤：执行多个测试用例中的第一测试用例（可以是随机选择的，也可以是该顺序的首个测试用例）；响应于第一测试用例的执行，在终端的用户界面上显示供测试人员交互操作的多个运行结果选择控件；以及根据被交互操作所选择的运行结果选择控件，确定第一测试用例的运行结果是否为通过；例如：可以是测试完第一测试用例后，在终端的屏幕上显示可供用户操作的控件“成功”、“失败”，若用户选择点击“成功”，则证明针对测试用例的运行结果为通过。更优选的，在所述在终端的用户界面上显示供测试人员交互操作的多个运行结果选择控件之后，该方法还包括：若检测到所述多个运行结果选择控件在预定时间段均未被选择，则生成触发用于触发终端执行重启操作的重启指令。
另外，存在一些测试用例，可以通过读取该测试用例的返回值来直接确定测试结果，因此可以实现这些测试用例的完全自动化测试。具体的，可以是当运行结果指示存在通过的测试用例时，按照顺序自动跳转至执行下一测试用例，并检测所跳转执行的下一测试用例的运行结果是否为通过。作为示例，可以是在某一测试用例被调用之后，根据自动返回的值来判断是否通过测试；以及若通过测试，则可以是直接（或在用户界面停留几秒）后自动跳转至下一测试用例。在另一方面，当运行结果指示存在未通过的测试用例时，在终端的用户界面上可以显示该未通过的测试用例所对应的终端应用功能。
以对led灯节点测试为例，在sysclassmanager.java文件中定义了读写文件的接口和访问节点文件路径，以及如下所示，可以对应255的是点亮，对应0的是熄灭，通过java上层接口进行读写才能成功，否则读写文件时会失败。
chargeredled=newsysclassmanager();
chargeredled.setfileoutputstream(chargeredled
.fileoutputopen(sysclassmanager.led_red_file));
chargeredled.writefileoutputchar("255");
这个是其中一个测试项用到的节点示例，此应用中涉及到很多测试节点，于此就不一一列举。
再列举一类是访问prop属性，判断出厂时tuning有没有刷入，如果没有刷入，会造成手机不识别sim卡。
首先在property.te文件中加入
typet2m_tctd_prop,property_type;
然后在property_contexts文件中加入
ro.tunning.emptyu:object_r:t2m_tctd_prop:s0
最后在system_app.te文件中加入
allowsystem_appt2m_tctd_prop:fileread;
此时app就有访问prop的权限，目前android8.0平台app访问prop也需要如此加权限。
checktunning.java中读是否tunning已经被刷入。
stringstatus=systemproperties.get("ro.tunning.empty","true").trim();
以此状态判断tunning是否已经被刷入，判断出不良品，保证良品出货。
第三方应用是没有权限加入这些权限的，只有配置有系统组用户的应用才能加入这些权限，快速判断出硬件功能是否ok，直接操作节点或prop快速方便，节省测试时间，保证工厂高效工作。
需说明的是，以上测试用例之间可以进行任意形式的组合，也就是多个测试用例可以包括半自动化和/或全自动化的测试用例等。
以下将继续展开描述本发明一实施例的终端人机接口测试的工作过程及原理：
正常版本中，用户可以在拨号盘界面输入正确的暗码“*#2886#”，手机会直接跳转到主页面，通过这个页面用户可以进入各个测试项界面，在mini版本里不用输入暗码，开机进入即为测试主界面。
点击auto进入各个自动测试界面，按照顺序依次测试各个测试项，前面测试项测试过后，进入下一个测试项，测试过程中可能有pass或fail。若存在fail，会问是否进行重新测试，其中若不重新测试，则进入下一项，重新测试则重新测试该测试项。
点击manu则进入手动测试项，可以自己手动选择要测试那个项，也无须按照顺序测试。
auto和manu的区别一个是自动，一个是手动，自动的话如果全部成功，最后会有一个flag标志位置1，手动是没有的，所以工厂一般测试都选用auto自动模式，如果全部测试完，并且成功的话，有flag标志位为1时即为良品，否则为不良品，一般手动是用来单独测试某项，或者开发调试时使用。
如图3所示，本发明一实施例的auto测试过程，点击后进入第一个测试项页面，所有测试项（项目可以是保存在res/values/array.xml里），项里的第一项是标题titles，其是进入测试项界面的标题显示，第二项是测试项java文件代码实现的类名，比如第一个项是界面显示和测试项的逻辑处理，第三项是类型type，3代表是auto、menu里都显示，2代表只在menu菜单里显示，0代表两个菜单里都不显示。第四项是key_event，是pc上操作的adb命令，链接手机上直接通过adb命令操作某个测试项，目前都是0，因为这个是开发调试使用，暂时没有扩展。
以上是所有mmitest应用的测试项，type值是3的会执行图3所示的auto流程图所示的测试。在测试人员点击auto按钮后，开始进入第一个测试项traceability页面，此页面有两个界面显示，因为此项显示手机出厂时的trace信息，一个页面放不下，先进入一个显示页面及为displaytestscreen然后手动选择pass或fail按钮，即为selectresult,如果一直没选择，会跳出restartscreen,进入该项重新测试。
如果进行选择，选pass后则看该测试项是不是还有下一个界面，是否是lastscreen,如果是则进入下一个测试项nexttest，如果不是则进入此测试项的下一个界面nestscreen，选fail后会直接记录fail项的索引值：mlastfailidx存入sharedpreferences的文件中，此文件会被一直保存，关机后再开机也会一直存在，选fail后界面显示是进入下一个测试项nasttest按钮还是end按钮，选end会直接关机不再测试，开机再进行auto测试会显示上次测试最后一个fail的索引值mlastfailidx和item项名称,mlastfailidx的值会随着当前测试项currentitemidx的变化而变化，当前测试项由currentitemidx索引值记录，currentitemidx++进入下一个测试项，该值初始化为0，依次增加，最大不会超过testitemmanager.gettestitemcount()及为mmaxtestitemslist.size()，testitemmanager控制整个测试项的初始化管理，从res/values/array.xml的max_test_items里loadstatictestitems，存入list<hashmap<string,object>>mmaxtestitemslist，一个hashmaplist中。通过currentitemidx索引值判断是不是lasttest最后一个测试项，如果是则记录整个测试结果flag,不是则进入下一个测试项nesttest,依次循环上面的流程。
在一些方面，因为有些显示信息是否为对的判断，或者是不是有声音需要测试操作员人为判断，所以大部分测试项的pass和fail按钮需要人为来点击，有部分通过程序返回值可判断的，则会通过延时3秒后自动点击pass进入下一个测试界面或者测试项。也做了预防误点按钮，误操作的逻辑，如果通过程序能判断出来是pass或者fail的，只有测试通过,pass按钮才能点击，否则是灰色显示不能点击，fail按钮是一直可以点击的，如果误操作，可以返回重新进行测试。
所以这里的auto测试只是从头到尾将需要验证手机硬件功能是否ok的测试项，验证一遍，并且记录flag标志值，1则全部通过测试，0则表示有fail项，没有全部通过，并不是完全的自动测试，是需要人为操作和干预的。flag值是通过mlastfailidx的值来判断，mlastfailidx初始化为-1，如果测试到最后一项还是-1，或者被写为-2/test_all_pass，则表示全部测试通过，否则大于等于0的值及为有fail测试项，没有全部通过.该flag值会写入trace分区的traceability中，android系统分配的内存中，关机后开机依然能读到值。
这样开机后通过看这个flag值就知道该整机是不是良品，比下载很多单个测试某项模组的app节省很多时间。
如图4所示，其示出了menu菜单测试模式的流程，其一般也只为开发和调试人员使用，而工厂操作员进行mmitest时一般只用auto测试。在此简单介绍下menu菜单测试，其中在操作员点击menu后，就是进入后会显示所有测试项list列表的项目，想测试哪一项，点击为“选择测试”，然后进入要测试的测试项及为“显示屏幕”，然后进入测试项界面测试，如果一直不选择通过pass或者失败fail，则弹出“重启”界面重新进行测试，如果选择pass按钮能够点击，则点击后看该测试项是不是还有下一个界面需要测试，及是不是最后一屏lastscreen如果不是，则进入该测试项的下一个界面进行测试，如果是则返回list列表界面选择另外的测试项测试或者进入该项重新测试，如果选择fail控件按钮，则也是返回list列表主界面，选择其他测试项或者选该项重新测试。
以下将结合终端的几个应用功能对本发明实施例的技术方案展开描述：
ⅰ防篡改测试
该测试项是测试平板sram是否能正常读写，以及写进寄存器的值是否和读出来一致，一样则为pass，否则为fail，防篡改功能，保证平板后盖是合着状态，客户不能随意打开后盖，否则功能将不能用。
该界面看起来非常简单，但功能实现起来比较复杂，首先芯片支持，其次是驱动层控制sram的读写，上层通过jni的方式，在.cpp文件中通过jni调用驱动层c接口。其中，基于预定的关于多个测试用例的顺序依次执行各个测试用例并检测所执行的各个测试用例的运行结果是否为通过包括：当检测到执行所述输入防篡改功能所对应的测试用例时，生成自动读写命令；响应于所述自动读写命令，通过java本地接口方式向静态指定存储器写入并读取数据；其中，当所写入的数据与所读取的数据相匹配时，确定对应于所述防篡改功能的测试用例的运行结果为通过。
首先要在hardware目前下，新建两个文件sram.h和sram.c，sram.h，里面是用c语言代码，通过ioctl操作，添加接口对寄存器里进行读写：
staticintsram_read(structsram_device_t*sramdev__unused,structtamper_data*tamper_read)
staticintsram_write(structsram_device_t*sramdev__unused,structtamper_data*tamper_write)
然后在mmitest\jni目前下，新建sram.cpp文件，通过jni方式
staticconstchar*classpathname="com/android/mmi/sram";
staticjninativemethodmethods[]={
{"readdevicenode","()i",(void*)readdevicenode},
{"getstatus","()i",(void*)getstatus},
{"reset","()i",(void*)reset},
};
getstatus函数中调用sram.c的接口读取状态，返回结果。
最后在\mmitest\src\com\android\mmi\sram.java中将生成的so库文件加载进来，调用checksramstate函数得到底层寄存器的读写状态。
classsram{
static{
system.loadlibrary("sram_test");
}
staticnativeintreaddevicenode();
staticnativeintgetstatus();
staticnativeintreset();
}
通过这种jni方式实现上层直接可以读写寄存器状态，耗时短，方便快捷，节省测试时间,避免了调用framework层接口发生的转换和接收错误，直接从上层调到kernel层接口。
ⅱ音频测试
当检测到执行音频测试功能所对应的测试用例时，生成音频关联命令；响应于音频关联命令，将终端的麦克风和扬声器关联连接；其中，麦克风用于接收测试声音，以及当扬声器发出对应于麦克风所接收到的测试声音的扬声信息时，确定对应于音频测试功能的测试用例的运行结果为通过。
具体的，该测试项是测试平板扬声器和mic是否ok，进入该项会听到一段紧急电话该拨打什么号码的录音，如果有声音说明扬声器是好的，非则是不好的，手动选择是pass，或者fail，然后进入mainmic测试，测试平板上一个孔，如果吹口气，有回声，则pass，非则是fail，来验证mainmic功能是否ok。
该界面虽然界面比较简单，但设计流程比较复杂，测试扬声器比较简单，主要是用android原生mediaplayer来播放一段录音，但是mainmic程序流程比较复杂，用自己扩展的代理jrdclient，建一个本地的socket,localsocket,发commend到framework层，接收后调用system命令调用驱动层来打开设备，设置声音，发出回声，以及关闭设备，停止声音的命令。
此技术也会遇到权限问题，不是系统级app也是没有权限调用，会在system_app.te中加入访问和写的权限（allowsystem_appt2m_socket:sock_filewrite）。
将mic和receiver两个设备形成一个回路，测试mic设备是否ok。例如，可以是对着mic吹口气，直接在receiver端发出声音相比于传统的mic测试具有很大的改进：具体在于，传统的mic测试是要调用录音功能以进行录音，然后保存录音文件，在通过mediaplayer进行播放，中间经历录音、保存和播放三个环节，导致耗时长、测试繁琐，但工厂环境又比较嘈杂，所以耗时比较长，还有有录音和播放应用才能完成。相比之下，本发明实施例所提供的此实现方式直接调用到system系统命令，具有耗时短、操作方便快捷的优势。
如图5所示，本发明一实施例的终端人机接口测试系统50，包括：
用例获取单元501，用于基于测试触发模块，获取与人机接口测试相关的多个测试用例，其中所述测试触发模块被配置有系统组用户权限和强制访问控制权限；
用例测试单元502，用于基于预定的关于所述多个测试用例的顺序依次执行各个所述测试用例，并检测所执行的所述各个测试用例的运行结果是否为通过，其中所述测试用例唯一对应于终端应用功能。
在一些实施方式中，所述用例测试单元502包括：用例执行模块，用于执行所述多个测试用例中的第一测试用例；控件显示模块，用于响应于所述第一测试用例的执行，在终端的用户界面上显示供测试人员交互操作的多个运行结果选择控件；结果确定模块，用于根据被交互操作所选择的所述运行结果选择控件，确定所述第一测试用例的运行结果是否为通过。
在一些实施方式中，所述用例测试单元502包括：用例自动执行模块，用于当所述运行结果指示存在通过的测试用例时，按照所述顺序自动跳转至执行下一测试用例，并检测所跳转执行的所述下一测试用例的运行结果是否为通过。
关于本发明实施例系统的更多的具体的细节和效果可以对应参照本发明上文关于上述方法实施例的描述，在此便不赘述。
以上结合附图详细描述了本发明实施例的可选实施方式，但是，本发明实施例并不限于上述实施方式中的具体细节，在本发明实施例的技术构思范围内，可以对本发明实施例的技术方案进行多种简单变型，这些简单变型均属于本发明实施例的保护范围。
另外需要说明的是，在上述具体实施方式中所描述的各个具体技术特征，在不矛盾的情况下，可以通过任何合适的方式进行组合。为了避免不必要的重复，本发明实施例对各种可能的组合方式不再另行说明。
此外，本发明实施例的各种不同的实施方式之间也可以进行任意组合，只要其不违背本发明实施例的思想，其同样应当视为本发明实施例所公开的内容。