Test cases for file upload
Updated 2026-11-13 · 6 min read
Thirty private-attachment cases using explicit PDF and PNG limits. Covers byte boundaries, spoofed metadata, scan failures and safe recovery after interrupted uploads.
How to answer in an interview
Ask what file types, sizes and counts are allowed, who may download them and whether processing is asynchronous. Start with upload followed by download and content comparison. Then separate selection, transfer, validation and processing failures: an upload progress bar reaching 100 percent does not necessarily mean the document is usable.
Scope and test data
Assume a private attachment form accepting PDF and PNG, at most three files and at most 5,242,880 bytes per file. Empty files are rejected. Files remain unavailable until validation and a configured scanner complete. Duplicate names are allowed as distinct attachments. Use harmless synthetic documents, valid images padded through an appropriate fixture tool and a scanner stub that can report clean, rejected or unavailable. Do not use live malware. OWASP recommends layered file validation and access controls; a filename extension or browser filter alone is not sufficient.
The 30 cases below are a test design, not an execution report. Replace the example rules with approved requirements before recording pass or fail. Performance budgets and supported device versions must be agreed before execution.
Selection and basic upload
| ID | Category | Test case | Expected result |
|---|---|---|---|
| F01 | Functional | Upload one valid small PDF | One attachment becomes ready after validation and can be downloaded |
| F02 | Functional | Upload a valid PNG and download it | Downloaded content matches the accepted fixture or documented transformed output |
| F03 | Functional | Select three valid files together | Three distinct attachments reach ready state |
| F04 | Boundary | Select a fourth file when three are already attached | Fourth file is refused and existing three remain intact |
| F05 | Functional | Cancel the operating-system file chooser | Existing attachment selection remains unchanged |
| F06 | Functional | Upload two different files with the same visible filename | Separate attachment identifiers preserve both contents |
| F07 | Functional | Remove a selected file before submission | Removed file is not uploaded or attached |
| F08 | Functional | Remove an uploaded attachment | It is detached and subsequent access follows the configured deletion policy |
Size and type boundaries
| ID | Category | Test case | Expected result |
|---|---|---|---|
| F09 | Boundary | Upload a valid fixture of 5,242,879 bytes | File passes the size rule |
| F10 | Boundary | Upload a valid fixture of exactly 5,242,880 bytes | File passes the inclusive size limit |
| F11 | Boundary | Upload a fixture of 5,242,881 bytes | Server rejects it with the stated limit and no ready attachment |
| F12 | Negative | Upload a zero-byte file | Empty-file error appears and no attachment becomes ready |
| F13 | Negative | Rename a disallowed file to end in .pdf | Content validation rejects the mismatch |
| F14 | Security | Spoof the request Content-Type for disallowed bytes | Server does not accept the file merely because of the claimed MIME type |
| F15 | Negative | Upload a truncated PDF fixture | Processing fails clearly without exposing a corrupt ready document |
| F16 | Negative | Use a double-extension filename for disallowed content | Server rejects the disallowed content despite the allowed-looking name |
| F17 | Functional | Upload a valid file with spaces and local-script characters in its name | Display name remains readable and stored content is retrievable |
Failure handling and access
| ID | Category | Test case | Expected result |
|---|---|---|---|
| F18 | Negative | Disconnect during transfer | Partial upload is not attached as ready; user can retry |
| F19 | Functional | Retry after losing the response to a successful upload | Recovery does not attach the same logical submission twice |
| F20 | Negative | Make the scanner return a rejected fixture result | File remains unavailable and a rejection status is shown |
| F21 | Negative | Make the scanner unavailable | File stays pending or fails safely; it is not released as clean |
| F22 | Security | Request another account private attachment by identifier | Download is denied without returning file contents |
| F23 | Security | Upload after the user session expires | Server refuses the unauthenticated attachment operation |
| F24 | Security | Supply path traversal segments in a controlled filename | Stored object cannot escape its designated location or overwrite another file |
| F25 | Security | Use a filename containing harmless HTML-like text | Filename is rendered as text without becoming markup |
| F26 | Security | Send an upload through an unauthorised cross-site form in a cookie-authenticated setup | Request is refused by the application cross-site request protection |
Usability and resource limits
| ID | Category | Test case | Expected result |
|---|---|---|---|
| F27 | UI | Use keyboard and screen reader to select, remove and inspect a rejected file | Controls have names and each file error is associated with its file |
| F28 | UI | Upload several files with one invalid fixture | Each outcome is visible; accepted files are not silently discarded |
| F29 | Performance | Upload the permitted batch on the agreed slow-network profile | Progress and cancellation remain usable and completion meets the defined budget |
| F30 | Compatibility | Repeat picker selection on supported desktop and mobile browsers | Accepted types upload successfully and cancellation preserves form state |
Evidence and prioritisation
Prioritise F01, F11, F14, F21 and F22. Record byte size, content type, hash where originals are preserved, attachment ID and processing transitions. Keep transfer success separate from scan success. A follow-up about archives needs a separate decompression and extraction policy; archives are outside this PDF/PNG suite. The common mistake is trusting a disabled file-picker choice as server-side validation.
Downloads
Quick answers
Does an allowed extension prove a file is safe?
No. Validate content and permissions in layers; client-provided names and MIME types are untrusted.
Should a scanner outage allow the file through?
Not under this private-attachment contract. Keep it inaccessible until the approved validation completes.
Sources
Want a project you can show in interviews?
The portfolio project kit walks you through testing a deliberately buggy app with Selenium or Playwright and API tests, then explaining it. The app itself is free.