拖放交互在列表整理、文件管理、桌面图标移动等场景中很常见，但测试时如果只验证“从A拖到B能放下”，往往会漏掉大量真实问题。拖放不是单一点击事件，而是一组连续事件，中间任何一环被拦截或返回值不对，都会导致后续动作丢失。做好拖放测试，需要同时关注事件链、数据传递、拖影渲染以及多窗口下的表现。
一、先理清DragEvent事件链路和监听返回值
Android的拖放由View.startDragAndDrop触发，系统将后续事件封装为DragEvent，通过View.OnDragListener回调给注册过的目标View。事件顺序通常是ACTION_DRAG_STARTED、ACTION_DRAG_ENTERED、ACTION_DRAG_LOCATION、ACTION_DRAG_EXITED、ACTION_DROP、ACTION_DRAG_ENDED。测试人员不一定要背全，但需要知道每个事件的意义：STARTED表示拖放开始，DROP表示数据被放入，ENDED表示整个拖放结束，即使没有成功放入也会触发。
监听器的返回值经常被忽视。如果ACTION_DRAG_STARTED返回false，后续的ENTERED、LOCATION、DROP等事件都不会继续派发给该View。因此测试时发现目标区域完全收不到事件，先检查所有目标View的OnDragListener在STARTED阶段是否返回true。代码中可以加日志打印每个事件，验证事件序列是否符合预期。
预置条件方面，源View必须设置长按或触摸监听，调用startDragAndDrop时传入ClipData和DragShadowBuilder。ClipData用于携带数据，不是可选项。如果传null，某些ROM会在拖放过程中崩溃。测试前可以先做一次冒烟检查：源View可长按、目标View能收到STARTED、拖影可见、松手后ENDED触发。
二、手工测试用例设计：不要只测成功路径
基础用例至少覆盖四类：顺手拖入目标区域、拖到空白区域释放、拖到目标边缘后回退、拖放过程中取消。很多测试只做第一种，忽略空白释放。实际上空白释放会触发ACTION_DRAG_ENDED，但不会触发ACTION_DROP，此时目标View如果没有清理状态，下次拖放可能出现异常。
多指操作也要纳入用例。用户可能一边拖放一边用另一根手指滚动列表或旋转屏幕。测试时可以在拖放过程中点击返回键、Home键、通知栏，观察恢复后拖影是否消失、事件是否终止。旋转屏幕是高频场景，Activity重建后拖放状态会丢失，如果没有重新初始化监听器，会出现目标区域完全无响应。
数据传递验证同样关键。ClipData可以携带文本、Uri、Intent等类型。测试不能只看拖放动画，还要检查目标View实际收到的数据是否正确。尤其是跨Activity拖放时，数据可能经过Intent传递，需要验证Uri权限、MIME类型、数据是否被系统裁剪。这份用例可以为后面的自动化脚本提供断言点。
三、Espresso与UIAutomator自动化实现
Espresso本身没有直接的dragAndDrop操作，需要自定义ViewAction。一个可行方案是使用GeneralClickAction模拟长按后，再用swipe或精确坐标移动。也可以写一个基于MotionEvent的动作，从源View中心按下、等待超过长按阈值、再移动到目标中心最后抬起。下面给出一个Java自定义ViewAction的简化实现。
public static ViewAction dragDropTo(final int targetId) {
return new ViewAction() {
@Override
public Matcher<View> getConstraints() {
return isDisplayed();
}
@Override
public String getDescription() {
return "从源View拖放到目标View";
}
@Override
public void perform(UiController uiController, View view) {
int[] sourceLocation = new int[2];
int[] targetLocation = new int[2];
view.getLocationOnScreen(sourceLocation);
View target = view.getRootView().findViewById(targetId);
target.getLocationOnScreen(targetLocation);
float startX = sourceLocation[0] + view.getWidth() / 2.0f;
float startY = sourceLocation[1] + view.getHeight() / 2.0f;
float endX = targetLocation[0] + target.getWidth() / 2.0f;
float endY = targetLocation[1] + target.getHeight() / 2.0f;
long downTime = SystemClock.uptimeMillis();
uiController.injectMotionEvent(MotionEvent.obtain(downTime, downTime, MotionEvent.ACTION_DOWN, startX, startY, 0));
uiController.injectMotionEvent(MotionEvent.obtain(downTime, downTime + 500, MotionEvent.ACTION_MOVE, startX + 10, startY + 10, 0));
SystemClock.sleep(800);
uiController.injectMotionEvent(MotionEvent.obtain(downTime, downTime + 1300, MotionEvent.ACTION_MOVE, endX, endY, 0));
uiController.injectMotionEvent(MotionEvent.obtain(downTime, downTime + 1400, MotionEvent.ACTION_UP, endX, endY, 0));
}
};
}
该动作的核心是先触发ACTION_DOWN，再通过MOVE产生长按拖拽，最后在目标坐标UP。实际项目中建议把坐标计算放到主线程，并用SystemClock.sleep替代Thread.sleep以避免中断。测试断言可以检查目标View的文本或状态，而不是只看是否无异常。
UIAutomator跨应用或系统级拖放更方便。UiObject提供了dragTo方法，可以直接指定目标UiObject或坐标。示例代码如下。
UiDevice device = UiDevice.getInstance(InstrumentationRegistry.getInstrumentation());
UiObject source = device.findObject(new UiSelector().resourceId("com.example.app:id/source_view"));
UiObject target = device.findObject(new UiSelector().resourceId("com.example.app:id/target_view"));
source.dragTo(target, 20);
dragTo的第二个参数是移动步数，越大移动越平滑但耗时越长。自动化测试中建议先验证目标区域能收到STARTED事件，否则dragTo只是一段无效滑动。
四、兼容性与性能排查清单
不同厂商ROM对拖放行为有差异。部分设备长按触发时间被系统调到更长，或者拖影颜色被主题覆盖。测试时至少覆盖原生系统、主流厂商定制ROM、平板和折叠屏。折叠屏展开与折叠状态下屏幕尺寸变化，拖放距离和坐标会出现偏移，需要检查目标View是否用固定坐标而不是相对于父布局。
拖影绘制是另一个容易出问题的点。自定义DragShadowBuilder如果未处理视图大小变化，拖影可能异常巨大或模糊。测试应截图对比拖影在源位置、目标位置、越界位置的显示效果。尤其是列表项拖放时，源View可能被回收或复用，拖影引用了一个已经失效的View会导致空白或闪烁。稳定性测试可以连续执行30次拖放，观察内存和帧率。
无障碍场景也值得关注。开启TalkBack或Switch Access后，用户无法使用长按拖放。应用应提供替代操作，例如按钮触发移动、菜单选择。测试验证替代路径是否与拖放路径数据一致。性能方面，拖放过程中系统会频繁回调ACTION_DRAG_LOCATION，如果监听器中做了耗时操作或频繁重绘，目标区域会出现明显掉帧。可以用Profiler查看回调频率，确保每次LOCATION事件处理不超过几毫秒。
拖放测试最终要回到用户路径上。把事件链验证、异常场景、自动化脚本和兼容性清单结合起来，才能避免只测出“能用”而漏掉“难用”的问题。测试人员不妨从一次长按开始，逐步补全整条链路。