-
Notifications
You must be signed in to change notification settings - Fork 663
Testing Scenarios
Klaas Freitag edited this page Mar 19, 2015
·
50 revisions
This page describes general testing required basically for each client release.
For individual client releases, there are more specific test plans:
- ownCloud Client 1.8: 1.8 Testplan
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!
| 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 |
- Install ownCloud
- expected: files to be found in System-wide app directory.
- Check if hostnames are accepted correctly by the input field
- Check if self-signed certificates are being accepted
(By pausing or logging out) Expected: Client stops syncing Error: Client crashes, Client stays in sync state (check with --logwindow
- Stop syncing while doing local discovery
- Stop syncing while doing remote discovery
- stop syncing while uploading a file
- stop syncing while downloading a file
- stop syncing while deleting files
- stop syncing while renaming files
- 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
- 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.
- Add a new directories full of files and let it sync.
- While syncing, rename directory on the client.
- After two sync, the directory fust have been renamed on the server and must not re-appear on the client, and all the files should be there.
- Now do the same, but delete the directory instead of renaming
- Do the same, but rename the directory on the server when syncing
- The same but delete the directory on the server
- 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 goes away
- Expected: Client recovers
- Error: Client crashes, client stays in error state
- Network goes online again:
- Expected: the sync resumes
- 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?
- 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 from previous client version (server stays the same)
- Upgrade from previous server version (client stays the same)
- Upgrade server and client
The following test cases should be checked.
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
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.
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.
Repeat the tests above, but also with the url changing.
- 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.
- 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
- Add multiples folder : Check that they sync properly
- Remove a folder : There should not be crashes.
- Look at the activity log.
- Click or double click on items. It should open the explorer with the file selected.
- 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.
- 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.
- Check that no username/password is logged in cleartext during operation.
☁️