Upstream/harbor
1
0
Fork 0
mirror of https://github.com/goharbor/harbor.git synced 2024-12-23 00:57:44 +01:00
Code Issues Projects Releases Wiki Activity

add usecaes

Browse Source
This commit is contained in:
Henry Zhang 2016-10-24 00:22:29 +08:00
parent 6b1c555359
commit f2a152555b
13 changed files with 386 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
tests/testcases/Group1-user-management/1-01-DB-user-registration.md
View File

@ -3,7 +3,7 @@ Test 1-01 - User Registration (DB Mode)
# Purpose:
To verify that a user can register an account (singup) when users are managed locally by Harbor (DB mode).
To verify that a non-admin user can register an account (singup) when users are managed locally by Harbor (DB mode).
# References:
User guide
@ -28,7 +28,7 @@ User guide
* wrong email formatting
* email is very long in length
* password input does not compliant to password rule
* two passwords not matching
* two passwords do not match
# Expected Outcome:

16
tests/testcases/Group1-user-management/1-02-DB-user-log-in-log-out.md
View File

@ -3,7 +3,7 @@ Test 1-02 - User Log In and Log Out (DB Mode)
# Purpose:
To verify that a user can log in and log out when users are managed locally by Harbor (DB mode).
To verify that a non-admin user can log in and log out when users are managed locally by Harbor (DB mode).
# References:
User guide
@ -14,21 +14,21 @@ User guide
* A linux host with Docker CLI installed (Docker client).
# Test Steps:
USE a non-admin user for this test case. Admin user has other test cases.
**NOTE:** Use a non-admin user for this test case. Admin user has other test cases.
1. Use the username of a user to log in to the UI.
2. Log out from the UI.
3. Use the email of the user to log in to the UI.
4. Log out from the UI.
1. A non-admin user logs in to the UI by username.
2. The user logs out from the UI.
3. A non-admin user logs in to the UI by email.
4. The user logs out from the UI.
5. Use the incorrect password and username/email of the user to log in to the UI and check the error message.
6. On a Docker client host, use `docker login <harbor_host>` command to verify the user can log in by either the **username** or **email** . (check both)
7. Use `docker login <harbor_host>` command to log in with incorrect password by either the **username** or **email** .
# Expected Outcome:
* The user can log in via UI in Step 1 & 3, verify the dashboard and navigation bar are for a non-admin user.
* The user can log in via UI in Step 1 & 3, verify the dashboard and navigation bar are for a non-admin user. (should not see admin options)
* After the user logged out in Step 2 & 4, the login page will be displayed again.
* The error message in Step 5 should not show which input value is in correct. It should only display the username(email) and password combination is incorrect.
* The error message in Step 5 should not show which input value is incorrect. It should only display the username(email) and password combination is incorrect.
* Docker client can log in in Step 6.
* Docker client fails to log in in Step 7.

36
tests/testcases/Group1-user-management/1-03-DB-user-update-password.md Normal file
View File

@ -0,0 +1,36 @@
Test 1-03 - User update password (DB Mode)
=======
# Purpose:
To verify that a non-admin user can update password when users are managed locally by Harbor (DB mode).
# References:
User guide
# Environment:
* This test requires that a Harbor instance is running and available.
* Harbor is set to authenticate against a local database. ( auth_mode is set to **db_auth** .) The user data is stored in a local database.
* A linux host with Docker CLI installed (Docker client).
# Test Steps:
**NOTE:** Use a **non-admin** user for this test case. Admin user has other test cases.
1. A non-admin user logs in to the UI by **username**.
2. The user changes his/her own password.
3. The user logs out.
4. The same user logs in to the UI by **email** using the new password.
5. The user can log in using `docker login` command using the new password.
6. The user goes to the page to change his/her own password. Provide invalid values of input to see if validation works:
* old password is incorrect
* password input does not compliant to password rule
* two passwords do not match
# Expected Outcome:
* Password can be changed in Step 2.
* User can log in using new password in Step 4.
* In Step 6, the user cannot change password due to various errors. Proper error message should be displayed.
# Possible Problems:
None

35
tests/testcases/Group1-user-management/1-04-DB-user-update-account-settings.md Normal file
View File

@ -0,0 +1,35 @@
Test 1-04 - User update account settings (DB Mode)
=======
# Purpose:
To verify that a non-admin user can update his/her account settings when users are managed locally by Harbor (DB mode).
# References:
User guide
# Environment:
* This test requires that a Harbor instance is running and available.
* Harbor is set to authenticate against a local database. ( auth_mode is set to **db_auth** .) The user data is stored in a local database.
* A linux host with Docker CLI installed (Docker client).
# Test Steps:
**NOTE:** Use a **non-admin** user for this test case. Admin user has other test cases.
1. A non-admin user logs in to UI.
2. The user changes his/her account settings, including email, full name and comments.
3. The user logs out.
4. The same user logs in again using **new email**, and verify the user's account settings had been changed.
5. The user goes to the page to change his/her settings again. Provide invalid values of input to see if validation works:
* email formatting
* very long email address string
* required fields are empty
# Expected Outcome:
* Account settings can be changed in Step 2.
* User can log in using new email in Step 4 and the settings are the same as input in Step 2.
* In Step 5, the user cannot change account settings due to various errors. Proper error message should be displayed.
# Possible Problems:
None

41
tests/testcases/Group1-user-management/1-05-LDAP-user-log-in-log-out.md Normal file
View File

@ -0,0 +1,41 @@
Test 1-05 - LDAP User Log In and Log Out (LDAP Mode)
=======
# Purpose:
To verify that a non-admin user can log in and log out when users are managed externally by an LDAP server (LDAP mode).
# References:
User guide
# Environment:
* This test requires that a Harbor instance is running and available.
* Harbor is set to authenticate against an LDAP server. (auth_mode is set to **ldap_auth** .) The user data is stored in an LDAP server.
* A linux host with Docker CLI installed (Docker client).
* An LDAP server has been set up and it has a few users available for testing.
# Test Steps:
1. A user has **NEVER** logged in to Harbor. He/she logs in to the UI for the first time by his/her id in LDAP. The id could be the uid attribte (or what is configured in ldap_uid) of his/her LDAP user DN.
2. The user logs out from the UI.
3. The user logs in again to the UI, should not see his/her own account settings and cannot change password(need to go to LDAP/AD for this).
4. The user logs out from the UI.
5. Use the incorrect password and username of the user to log in to the UI and check the error message.
6. On a Docker client host, use `docker login <harbor_host>` command to verify the user can log in by username/password.
7. Run `docker login <harbor_host>` command to log in with incorrect password of the user.
8. Log in as a system admin to UI, go to "admin Options" and should see above LDAP user in the list. System admin can assign or remove system admin role to the above LDAP user.
9. Disable or remove the user in LDAP.
10. The user should no longer log in to UI or by Docker client.
# Expected Outcome:
* The user can log in to UI by LDAP id in Step 1 & 3, verify the dashboard and navigation bar are for a non-admin user. (should not see admin options)
* In Step 3, also verify that the user cannot update his/her account settings and cannot change password.
* After the user logged out in Step 2 & 4, the login page will be displayed again.
* The error message in Step 5 should not show which input value is incorrect. It should only display the username(email) and password combination is incorrect.
* Docker client can log in in Step 6.
* Docker client fails to log in in Step 7.
* LDAP user should have no difference from a user in local database in Step 8.
* The user's login should fail in Step 10.
# Possible Problems:
None

41
tests/testcases/Group1-user-management/1-06-AD-user-log-in-log-out.md Normal file
View File

@ -0,0 +1,41 @@
Test 1-06 - AD (Active Directory) User Log In and Log Out (LDAP Mode)
=======
# Purpose:
To verify that a non-admin user can log in and log out when users are managed externally by an AD server (LDAP mode).
# References:
User guide
# Environment:
* This test requires that a Harbor instance is running and available.
* Harbor is set to authenticate against an AD server. (auth_mode is set to **ldap_auth** .) The user data is stored in an AD server.
* A linux host with Docker CLI installed (Docker client).
* An Active Directory (AD) server has been set up and it has a few users available for testing.
# Test Steps:
1. A user has **NEVER** logged in to Harbor. He/she logs in to the UI for the first time by his/her id in AD. The id could be the cn attribte (or what is configured in ldap_uid) of his/her AD user DN.
2. The user logs out from the UI.
3. The user logs in again to the UI, should not see his/her own account settings and cannot change password(need to go to LDAP/AD for this).
4. The user logs out from the UI.
5. Use the incorrect password and username of the user to log in to the UI and check the error message.
6. On a Docker client host, use `docker login <harbor_host>` command to verify the user can log in by username/password.
7. Run `docker login <harbor_host>` command to log in with incorrect password of the user.
8. Log in as a system admin to UI, go to "admin Options" and should see above AD user in the list. System admin can assign or remove system admin role of the above AD user.
9. Disable or remove the user in AD.
10. The user should no longer log in to UI or by Docker client.
# Expected Outcome:
* The user can log in to UI by AD id in Step 1 & 3, verify the dashboard and navigation bar are for a non-admin user. (should not see admin options)
* In Step 3, also verify that the user cannot update his/her account settings and cannot change password.
* After the user logged out in Step 2 & 4, the login page will be displayed again.
* The error message in Step 5 should not show which input value is incorrect. It should only display the username(email) and password combination is incorrect.
* Docker client can log in in Step 6.
* Docker client fails to log in in Step 7.
* AD user should have no difference from a user in local database in Step 8.
* The user's login should fail in Step 10.
# Possible Problems:
None

37
tests/testcases/Group1-user-management/1-07-LDAP-mode-general.md Normal file
View File

@ -0,0 +1,37 @@
Test 1-07 - LDAP Mode general functions
=======
# Purpose:
To verify that Harbor's UI works properly in LDAP mode.
# References:
User guide
# Environment:
* This test requires that a Harbor instance is running and available.
* Harbor is set to authenticate against an AD or LDAP server. (auth_mode is set to **ldap_auth** .)
* An Active Directory (AD) or LDAP server has been set up and it has a few users available for testing.
# Test Steps:
1. The login page should not have "sign up" button. There is no need to allow self-registration.
2. Log in as a non system admin user(LDAP/AD) to the UI, he/she should NOT see the option of changing password or updating account settings.
3. Log out the user.
4. Log in as a system admin user to the UI, he/she should see the option of changing his/her own password or updating account settings.
5. The system admin user should NOT see the option of adding a new user.
6. The system admin user should see above LDAP/AD user in the list.
7. From the list, the system admin assigns system admin role to an AD/LDAP user A.
8. On a different browser(e.g. if the admin logs in using Chrome, then choose Safari or FireFox ), log in as the AD/LDAP user A to verify that user A has admin privilege.
9. From the list, the system admin removes system admin role from user A.
10. On a different browser, refresh the UI to verify user A has no admin privilege any more.
11. The system admin user deletes an AD/LDAP user in Harbor. **NOTE:** The user can log in again to regain access, however, all the previous projects he/she is a member of are lost.
To really disable a user's login, the user must be removed or disabled in AD or LDAP.
# Expected Outcome:
* As described in steps 1-6.
* A LDAP/AD user can be assigned or removed admin role in Step 7-10.
* The user can be deleted successfully in Step 11.
# Possible Problems:
None

32
tests/testcases/Group1-user-management/1-08-admin-log-in-log-out.md Normal file
View File

@ -0,0 +1,32 @@
Test 1-08 - Admin User Log In and Log Out (DB Mode or LDAP mode)
=======
# Purpose:
To verify that an admin user can log in and log out.
# References:
User guide
# Environment:
* This test requires that a Harbor instance is running and available.
* Harbor is set to authenticate against a local database or LDAP server.
* A linux host with Docker CLI installed (Docker client).
# Test Steps:
1. The admin user logs in to the UI by username.
2. The admin user logs out from the UI.
3. Use the incorrect password of the admin user to log in to the UI and check the error message.
4. On a Docker client host, use `docker login <harbor_host>` command to verify the admin user can log in.
5. Use `docker login <harbor_host>` command to log in with incorrect password.
# Expected Outcome:
* The admin user can log in/out successfully in Step 1 & 2.
* The error message in Step 3 should not show which input value is incorrect. It should only display the username and password combination is incorrect.
* Docker client can log in in Step 4.
* Docker client fails to log in in Step 5.
# Possible Problems:
None

44
tests/testcases/Group1-user-management/1-09-admin-create-delete-user.md Normal file
View File

@ -0,0 +1,44 @@
Test 1-09 - Admin User Create, Delete and Recreate a User(DB Mode)
=======
# Purpose:
To verify that an admin user can create/delete/recreate a user when users are managed locally by Harbor (DB mode).
# References:
User guide
# Environment:
* This test requires that a Harbor instance is running and available.
* Harbor is set to authenticate against a local database.
* A linux host with Docker CLI installed (Docker client).
# Test Steps:
1. The admin user logs in to the UI.
2. The admin user creates a user from the UI.
3. On a different browser, log in as the newly created user.
4. The user views his/her own account settings.
5. The user create two projects in the UI.
6. On a Docker client host, use `docker login <harbor_host>` command to verify the user can log in.
7. The admin user deletes the user from the UI.
8. When clicking on any link on the page, the deleted user's session on the different browswer should be redirected to the login page and logged out.
9. On a Docker client host, use `docker login <harbor_host>` command to verify the user cannot log in.
10. The admin user re-creates a user with the same username of the deleted user.
11. On a different browser, log in as the re-created user.
12. The user views his/her own account settings.
13. The user views "My Projects" to see what projects he/she owns.
14. On a Docker client host, use `docker login <harbor_host>` command to verify the re-created user can log in.
15. The admin user view logs from the dashboard and should see two items of two project creation of the deleted user. The user has special number associated with him/her username.
# Expected Outcome:
* The newly created user can log in successfully in Step 3.
* The newly created user can view his/her own settings as entered by the admin in Step 4.
* The newly created user can create project successfully in Step 5.
* The admin should be able to re-create the user in Step 10.
* The re-created user should be able to log in, however, the previous projects no longer belong to him/her (Step 11-13).
* Docker client logs in successfully in Step 14.
* Should see special user id in logs in Step 15.
# Possible Problems:
None

28
tests/testcases/Group1-user-management/1-10-admin-update-account-settings.md Normal file
View File

@ -0,0 +1,28 @@
Test 1-10 - Admin User update account settings (DB Mode)
=======
# Purpose:
To verify that the admin user can update his/her account settings.
# References:
User guide
# Environment:
* This test requires that a Harbor instance is running and available.
* Harbor is set to authenticate against a local database. ( auth_mode is set to **db_auth** .) The user data is stored in a local database.
* A linux host with Docker CLI installed (Docker client).
# Test Steps:
1. Thw admin user logs in to UI.
2. The user changes his/her account settings, including email, full name and comments.
3. The user logs out.
4. The admin user logs in again using **new email**, and verify the account settings had been changed.
# Expected Outcome:
* Account settings can be changed in Step 2.
* User can log in using new email in Step 4 and the settings are the same as input in Step 2.
# Possible Problems:
None

29
tests/testcases/Group1-user-management/1-11-admin-update-password.md Normal file
View File

@ -0,0 +1,29 @@
Test 1-11 - Admin User update password (DB Mode)
=======
# Purpose:
To verify that the admin user can update password.
# References:
User guide
# Environment:
* This test requires that a Harbor instance is running and available.
* Harbor is set to authenticate against a local database. ( auth_mode is set to **db_auth** .) The user data is stored in a local database.
* A linux host with Docker CLI installed (Docker client).
# Test Steps:
1. The admin user logs in to the UI by **username**.
2. The admin user changes his/her own password.
3. The admin user logs out.
4. The admin user logs in to the UI by **email** using the new password.
5. The admin user can log in using `docker login` command using the new password.
# Expected Outcome:
* Password can be changed in Step 2.
* User can log in using new password in Step 4.
# Possible Problems:
None

28
tests/testcases/Group1-user-management/1-12-admin-assign-sys-admin-role.md Normal file
View File

@ -0,0 +1,28 @@
Test 1-12 - Admin User Assign and Remove Admin Role to a User.
=======
# Purpose:
To verify that Admin user can assign/remove admin role to/from a user.
# References:
User guide
# Environment:
* This test requires that a Harbor instance is running and available.
* Harbor is set to authenticate against a local database. ( auth_mode is set to **db_auth** .) The user data is stored in a local database.
# Test Steps:
1. Log in as the admin user to the UI.
2. The admin user should see a list of users in "Admin Options".
3. From the list, the admin user assigns system admin role to a user A.
4. On a different browser(e.g. if the admin logs in using Chrome, then choose Safari or FireFox ), log in as user A to verify that user A has admin privilege.
5. From the list, the admin user removes system admin role from user A.
6. On a different browser, refresh the UI to verify user A has no admin privilege any more.
# Expected Outcome:
* As described in steps 1-6.
# Possible Problems:
None

25
tests/testcases/Group1-user-management/1-13-admin-search-users.md Normal file
View File

@ -0,0 +1,25 @@
Test 1-13 - Admin User Search Users.
=======
# Purpose:
To verify that Admin user can search users.
# References:
User guide
# Environment:
* This test requires that a Harbor instance is running and available.
* Harbor is set to authenticate against a local database, LDAP or AD.
# Test Steps:
1. Log in as the admin user to the UI.
2. The admin user should see a list of users in "Admin Options".
3. Enter different keywords or partial words to see if the user list can be filtered according to the criteria.
# Expected Outcome:
* As described in steps 1-3.
# Possible Problems:
None