Skip to content

Testing Scenarios

Jump to bottom
Olivier Goffart edited this page Jan 21, 2015 · 50 revisions

Introduction

This page describes general testing required basically for each client release.

For individual client releases, there are more specific test plans:

Add manual test here to this page that are

  • critical for the applications basic functionality
  • features that might easily regress, esp. bugs that you have fixed (add bug number)
  • not specific to one release

Use this as a guide to test releases in the beta phase. All tests should be described in a way such that they can be performed by anyone (no hard developer knowledge should be required). It is strongly recommended never to test with production data. always use at least a test-user. These tests are designed to make the Client explode or at least push it to its limits. You have been warned!

Where to find directories on the various OSes

Windows Mac OS X Linux
User app settings %LOCALAPPDATA%\ownCloud ~/Library/Application Support/ownCloud ~/.local/share/data/ownCloud
System-wide app directory %ProgramFiles(x86)%\ownCloud /Applications/ownCloud.app/Contents/Resources /usr/bin (binary)
/etc/owncloud (settings)
Default sync directory %USERPROFILE\ownCloud ~/ownCloud ~/ownCloud

Test classes

Installer/Uninstaller

  • Install ownCloud
  • expected: files to be found in System-wide app directory.

Setup

  • Check if hostnames are accepted correctly by the input field
  • Check if self-signed certificates are being accepted

Syncing

  • User stopps syncing
  • Expected: Client stops syncing
  • Error: Client crashes, Client stays in sync state (check with --logwindow output!)

Test resuming of uploads

  • Add a big files locally (100Mb or more) and look at the server logs: it should start sending chunks
  • Kill the client while syncing.
  • Restart the client: it should resume from the last sent chunk, and stop when all the chunk are transfered (observe that on the server log)
  • Do the same but instead of killing the client, shut the server off or turn off the network

Test resuming download

  • Add a big file on the server
  • Look at the progress bar of the sync and kill the client when it is almost over
  • Restart the client
    • The sync should resume from what it already downloaded.
    • Known bug: the progress still show it has too download it full
    • But after the remaining megabytes have been downloaded, the progress bar should jump to the end.

Test shared folder

  • Have a read only Shared/ folder
  • Adding a file there should cause an error. The error should be blacklisted after a few sync.
  • Editing a file should cause an error saying that a conflict file has been created and the original file restored. Verify it worked
  • Removing a file should restore the file
  • Renaming a file should restore the original, and show an error for the new one.
  • Rename Shared/ to something else : Syncing should move Shared/ back
  • Move a subfolder of Shared outside of Shared : The original files should be restores at their original location, and the new directory uploaded to the server
  • Remove a subfolder : The original files hsould be restored

Network-related

  • Network goes away
  • Expected: Client recovers
  • Error: Client crashes, client stays in error state
  • Network goes online again:
  • Expected: the sync resumes

Crash Recovery

  • client crashes (kill -9, force end via task manager)
  • Expected: client recovers
  • Error: client shows error message, DB corrupts, settings are forgotten
  • Important: check behavior also with clean settings directory. Does the client forget its credentials?

Server interaction checks

  • Client must not initiate new session per request, make sure cookie gets passed along.
  • Remove DB.
  • Expected results: no changes after initial sync.
  • Tolerated: some conflicts when server and client are not time-synced
  • Error: Conflict files get uploaded to server

Upgrade (where applicable)

  • Upgrade from previous client version (server stays the same)
  • Upgrade from previous server version (client stays the same)
  • Upgrade server and client

Credential Management

The following test cases should be checked.

First startup

This is the situation new users have: There is no former installation with credentials stored somewhere.

  • Check if the account has set credentials in the password storage which is Registry on Windows, Wallet system on Linux and the System Password storage on MacOS. Remove all ownCloud related entries there. Do that after ever test here.
  • Test if the user can connect to a http server with correct credentials.
  • Test if the user can connect to a https server with correct credentials.
  • Test what happens if user connects with wrong user.
  • Test what happens if user connects with wrong password.
  • Test what happens if user presses "Cancel" without having connected.
  • Verify that user can not press "Finish" before a successful connection was established.
  • Verify that if we bo back and enter different URL everything works correctly

Update

Test authentication after the user updated from a previous version. Basically repeat the tests from before but with existing credentials in the credential store.

  • Check if the client starts without asking for password on first start after update.

Password change, without URL change.

Test the case that the user wants to change her password. For that, run the configuration dialog and just change the users password. For that, first change the password on the server using the web interface.

  • After the password change on the webinterface, check the client's reaction when it tries to connect with the old, now wrong credentials. Start the client with the wrong credentials.
  • Change the credentials on the server while the client is running. Check the reaction.
  • Test if the new password is accepted and appears in the credential store.
  • Test if the client connects to the server and starts syncing after user pressed "Finish".
  • Test if the old configuration remains unchanged after user pressed "Cancel".
  • Test if the proxy settings are the same as before after reconfiguration.
  • Go back in the configuration wizard and check if the password is still consistently used.
  • Test with a wrong password.

Password change, with URL change

Repeat the tests above, but also with the url changing.

Wrong password

  • Sing out. (from the menu in the systemtray)
  • Sign in: It should ask for the password
  • Press cancel: it should stay disconnected and not ask for the password
  • Sign in, and enter the wrong password: it should ask for the password again
  • Enter the wrong password a couple of times: it must always ask for the password
  • Enter the right password: It should do the sync and connect and not ask for the password anymore.

Shiboleth

  • Change the account to use an account on the shibboleth test server
  • Connect and start a sync.
  • Try sign in / sign out
  • Try wrong password, try closing the shibboleth window without loggin in.
  • Try loggin with a different user. This should not be allowed

Multiples folders

  • Add multiples folder : Check that they sync properly
  • Remove a folder : There should not be crashes.

Activity log

  • Look at the activity log.
  • Click or double click on items. It should open the explorer with the file selected.

Windows Office Files

  • Save an office file under windows into the sync dir. Keep the file open in the office app. Every time the file is saved in the office app, the file should be synced.

Big File modified during Upsync

  • Put a big file into the sync dir. While it is synced up, change it. The client should realize the change, stop syncing and redo it later.

☁️

Clone this wiki locally