我想在以下“输入”的所有可能组合上测试android的行为:
setRequestedOrientation()
(2个可能的值)SCREEN_ORIENTATION_BEHIND
(4个可能的值)Settings.System.ACCELEROMETER_ROTATION
查询)(4个可能的象限)具体来说,我想看看输入如何影响以下“输出”:
因此,这将需要测试至少所有qazxswpoi可能的输入状态。
另外,由于旋转行为通常取决于输入的历史(不仅仅是当前输入值),我想测试(至少)从一个输入状态到“相邻”输入状态的所有可能转换,即输入到输入通过一个输入参数与给定输入状态不同的状态。此类输入状态转换的数量为:
(number of input states) * (number of states adjacent to a given input state) = (15*2*4*4) * ((15-1) + (2-1) + (4-1) + (4-1)) = 480 * 21 = 10080
此外,有时输出取决于先前的输出以及先前和当前的输入(例如getWindowManager().getDefaultDisplay()
,.getRotation()
)。给定输入状态的可能输出数量可以在1到4之间,因此这会将必须测试的转换次数乘以最多4:
10080 * 4 = 40320
这是很多要测试的过渡,因此测试必须是编程/脚本化的。四个输入参数中的三个可以直接以编程方式进行控制;不容易控制的是设备的物理方向。
那么,如何编写脚本呢?我可以想到以下方法。
方法#1:在测试期间用可编写脚本的模拟加速度计替换(物理或仿真)设备的加速度计。但是,如果我理解正确,那么Android的模拟加速度计就不存在了。
方法#2:使用android模拟器,并使用主机上的交互自动化工具(例如applescript / autohotkey / xdotool)按下“逆时针旋转”和“顺时针旋转”按钮。
还有其他想法吗?
事实证明,这实际上是以下一个优秀问题的重复:15*2*4*4=480
有来自@ user1302884的SCREEN_ORIENTATION_LOCKED
:不幸的是,这个问题没有得到尊重,并且被关闭为主题(?!)所以我不会将其标记为重复。
但这里的答案是:不需要使用applescript / autohotkey / xdotool来驱动模拟器的ui;相反,telnet到模拟器并告诉它你想要“向上”的方向。
SCREEN_ORIENTATION_SENSOR_LANDSCAPE
如果模拟显示器在响应中显示旋转了指定的度数,那将是很好的,但你不能拥有一切。