How to Test File Upload in Mobile and Web Apps

File upload sits at the intersection of UI, network, and backend validation. Small bugs manifest as big problems: users cannot submit forms, documents are silently corrupted, or malicious files slip t

File upload sits at the intersection of UI, network, and backend validation. Small bugs manifest as big problems: users cannot submit forms, documents are silently corrupted, or malicious files slip through. This guide covers the test plan that catches all three.

What to test

Upload UI

1. Tap / click triggers file picker
2. Camera option (mobile) for photos
3. Gallery option (mobile) for existing media
4. Document picker (files) on supported platforms
5. Drag-and-drop (web) works and is visually signaled
6. Multiple files selectable (if supported)

File restrictions

1. Accepted types enforced (images only, PDFs only, etc.)
2. Invalid types rejected with clear message
3. File size limit enforced client-side
4. File size limit enforced server-side (do not trust client)
5. Total upload size limit (if multiple files)

Upload process

1. Progress indicator visible
2. Progress accurate (not jumping to 99%)
3. Cancel mid-upload works
4. Upload resumes after transient network drops (if supported)
5. Force-close mid-upload: queued or lost cleanly (not corrupted)
6. Multiple simultaneous uploads handled
7. Upload succeeds on Wi-Fi, cellular, roaming
8. Low-bandwidth upload times out gracefully

Post-upload

1. Success state clear (filename, thumbnail, URL)
2. Error state actionable ("Upload failed, try again")
3. File replaceable (re-upload overwrites or adds)
4. File removable (delete clears server record)

Security

1. File type validated by content, not just extension (.exe renamed to .jpg detected)
2. File size capped server-side
3. Uploaded files scanned for malware (antivirus integration)
4. Executable files blocked for typical-user uploads
5. Filename sanitized (no path traversal like ../../../etc/passwd)
6. EXIF / metadata stripped from images (location leak)
7. Uploaded file URL not predictable (random UUID, not user_id/filename)
8. ACL enforced — user A cannot access user B's upload

Mobile-specific

1. Camera permission requested correctly
2. Gallery permission requested correctly
3. Background upload continues if user backgrounds app
4. Permission denied → clear recovery path
5. HEIC images (iOS) converted if server expects JPG

Accessibility

1. Upload button labeled
2. Progress announced to screen reader
3. Success / error state announced
4. Touch target ≥ 48dp

Edge cases

1. 0-byte file → rejected
2. Exactly-max-size file → accepted
3. Just-over-max file → rejected with message
4. Very long filename → truncated display, full name stored
5. Filename with special characters, emoji → preserved or sanitized consistently
6. Duplicate file upload → handled per policy (dedup or version)
7. Concurrent uploads from two devices → last-write or conflict UI

How to test manually

Prepare a test file bank:

• Minimum: 1 tiny valid file, 1 just-under-max, 1 just-over-max, 1 wrong-type, 1 zero-byte
• Ideal: also a large valid file, a file with special chars in name, an image with EXIF/GPS data, a file that looks like one type but is another (file.jpg that is actually .exe)

Test on:

• Strong Wi-Fi
• Weak Wi-Fi
• 4G
• Edge (slow cellular)
• Packet loss conditions (mitmproxy / network conditioner)
• Flight mode (rejection)

Automated testing

Playwright

def test_file_upload(page):
    page.goto("/upload")
    page.set_input_files('input[type="file"]', 'test_assets/small.jpg')
    page.click('button[type="submit"]')
    expect(page.locator('.success-message')).to_be_visible()

Appium (Android)

# Push file to device first
driver.push_file("/sdcard/Download/test.jpg", source_path="test.jpg")
driver.find_element(AppiumBy.ID, "upload_btn").click()
# Navigate the file picker
driver.find_element(AppiumBy.XPATH, "//android.widget.Button[@text='Downloads']").click()
driver.find_element(AppiumBy.XPATH, "//android.widget.TextView[@text='test.jpg']").click()

Backend validation

Unit-test the server validator with a matrix of filenames, types, sizes. Ensure:

• Extension and content-type match
• Size within bounds
• Filename sanitized
• Path traversal blocked

How SUSA handles file upload

SUSA pushes a test assets bundle to the device and drives upload flows. Test files include valid, invalid, boundary-size, and special-character filename cases.

susatest-agent test myapp.apk --persona adversarial --test-assets ./assets

The adversarial persona tries invalid file types and oversized files, stressing the client-side validation. Findings include: upload that silently ignored a server error, client accepting files server rejects, progress bar stuck after cancel.

Common production bugs

1. Client validates extension, server validates size — can upload oversized binary if named .jpg
2. Progress jumps from 0% to 100% — not actually monitoring upload
3. EXIF GPS data leaked in user-uploaded photos on public profile
4. Cancel does not stop the upload — request continues, bandwidth wasted
5. Filename collisions overwrite — user loses old upload silently

Upload is worth a dedicated test pass every release. The security implications alone justify the attention.