upstream/harbor
1
0
Fork 0
mirror of https://github.com/goharbor/harbor synced 2024-09-21 07:27:55 +00:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #953 from hainingzhang/dev

Browse Source 
Test cases
This commit is contained in:
Daniel Jiang 2016-10-27 14:50:51 +08:00 committed by GitHub
commit a5c047630a
38 changed files with 1399 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

41
tests/testcases/Group1-user-management/1-01-DB-user-registration.md Normal file
View File

@ -0,0 +1,41 @@
Test 1-01 - User Registration (DB Mode)
=======
# Purpose:
To verify that a non-admin user can register an account (singup) 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:
1. On the Harbor's home page, click "Sign Up"
2. Enter user information to register a user.
3. Use the username of the newly registered user to log in to the UI.
4. Log out from the UI.
5. Use the email of the newly registered user to log in to the UI.
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** . (verify both)
7. Log out from the UI and register another new user. Try to provide invalid values of input to see if validation works:
* username is the same as an existing user
* username is very long in length
* wrong email formatting
* email is very long in length
* password input does not compliant to password rule
* two passwords do not match
# Expected Outcome:
* A new user created in step 2.
* The new user can log in via UI in Step 3 and Step 5.
* The new user can log in via docker client in Step 6 by email and username.
* Invalid input during sign up can be rejected, proper error messages can be displayed in Step 7.
# Possible Problems:
None

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

@ -0,0 +1,36 @@
Test 1-02 - User Log In and Log Out (DB Mode)
=======
# Purpose:
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
# 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 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. (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 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.
# Possible Problems:
None

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

42
tests/testcases/Group2-image-management/2-01-DB-user-create-project.md Normal file
View File

@ -0,0 +1,42 @@
Test 2-01 - User Create Project (DB Mode)
=======
# Purpose:
To verify that a non-admin user can create projects 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).
* At least two non-admin users are in Harbor.
# Test Steps:
**NOTE:**
In below test, user A and B are non-admin users. User A, B and project X, Y should be replaced by longer and meaningful names.
1. Log in to UI as user A (non-admin).
2. Create a new project X with publicity is off (default).
3. Create another new project Y with publicity is on .
4. While keeping user A logging on, in another browswer log in as user B (non-admin).
5. User B checks his/her public projects to see if project Y is listed and project X is not listed.
6. User A changes project X's publicity to on, project Y's publicity to off.
7. User B refreshes his/her public projects to see if project X is listed and project Y is not listed.
8. On a Docker client host, use `docker login <harbor_host>` to log in as user A.
9. User A runs `docker push` to push an image to project X, push an image to project Y.
10. User A checks in the browser that the images had been successfully pushed to project X and Y.
11. On a Docker client host, use `docker login <harbor_host>` to log in as user B.
12. User B runs `docker pull` to an image of project X, and an image of project Y.
# Expected Outcome:
* Step 5, user B should see project Y is listed and project X is not listed.
* Step 7, user B should see project X is listed and project Y is not listed.
* Step 9,10, images should be pushed to project X and Y successfully and can be viewed from UI.
* Step 11,12, user B can pull the image of project X, cannot pull from project Y.
# Possible Problems:
None

38
tests/testcases/Group2-image-management/2-02-DB-user-push-multiple-images.md Normal file
View File

@ -0,0 +1,38 @@
Test 2-02 - User Push Multiple Images (DB Mode)
=======
# Purpose:
To verify that a non-admin user can push multiple images to a project 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).
* At least a non-admin user and the user has at least a project as project admin.
# Test Steps:
**NOTE:**
In below test, user A is non-admin user. User A and project X should be replaced by longer and meaningful names.
1. Log in to UI as user A (non-admin).
2. Verify User A has at least a project X with the role of project admin.
3. On a Docker client, log in as User A and run `docker push` to push an image with tag (e.g. nginx:1.5) to project X.
4. Continue to push at least 5 images with different tags, for example, nginx:1.6, nginx:1.7, nginx:1.8, nginx:release .
5. In the UI, go to "My Projects" to see if all images/tags are properly displayed.
6. Checks the detail info of each tag.
7. Enter keyword to search(filter) images/tags of a project.
8. On a Docker client, log in as User A and run `docker pull` to pull images with different tags from project X.
# Expected Outcome:
* Step 3-5, images can be pushed to project X and can be shown in UI.
* Step 6, image/tag info should be correct.
* Step 7, image/tag should be filtered and results should be matched the search criteria.
* Step 8, images can be pulled from project X.
# Possible Problems:
None

31
tests/testcases/Group2-image-management/2-03-DB-user-push-multiple-projects.md Normal file
View File

@ -0,0 +1,31 @@
Test 2-03 - User Create Multiple Projects (DB Mode)
=======
# Purpose:
To verify that a non-admin user can create multiple projects 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).
* At least a non-admin user.
# Test Steps:
**NOTE:**
In below test, user A is non-admin user. User A should be replaced by a longer and meaningful name.
1. Log in to UI as user A (non-admin).
2. Create 16 or more projects so that the pagination control has multiple pages.
3. Go through multiple pages of the list and click on a few projects to see if pagination work properly.
4. Search projects with keywords to see if the list and pagination update accordingly.
# Expected Outcome:
* As descirbed in step 3-4.
# Possible Problems:
None

33
tests/testcases/Group2-image-management/2-04-DB-user-view-projects.md Normal file
View File

@ -0,0 +1,33 @@
Test 2-04 - User View Projects (DB Mode)
=======
# Purpose:
To verify that a non-admin user can view projects 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.
* There is at least a non-admin user.
* The user has at least 3 private projects.
* The registry has at least 3 public repositories.
# Test Steps:
**NOTE:**
In below test, user A is non-admin user. User A should be replaced by a longer and meaningful name.
1. Log in to UI as user A (non-admin).
2. Create at least 3 projects if he/she has less than 3 projects.
3. Switch a few times between "My Projects" and "Public projects" tab, view listed projects and click to check details of images.
4. Check logs of projects in "My Projects".
# Expected Outcome:
* Step 3, verify the information listed of projects are correctly displayed, such as creation time and role.
* Step 4, should see logs of the project.
# Possible Problems:
None

39
tests/testcases/Group2-image-management/2-05-DB-user-delete-image.md Normal file
View File

@ -0,0 +1,39 @@
Test 2-05 - User Delete Images (DB Mode)
=======
# Purpose:
To verify that a non-admin user can delete images 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).
* At least a non-admin user.
# Test Steps:
**NOTE:**
In below test, user A is non-admin user. User A and project X, Y should be replaced by longer and meaningful names.
1. Log in to UI as user A (non-admin).
2. Create a project X so that the user has the project admin role.
3. On a Docker client, log in as User A and run `docker push` to push an image to the project X, e.g. projectX/myimage:v1.
4. Push a second image with different tag to project X, e.g. projectX/myimage:v2 .
5. Push an image with different name to project X, e.g. projectX/newimage:v1 .
6. Run `docker pull` to verify images can be pushed successfully.
7. In UI, delete the three images one by one.
8. On a Docker client, log in as User A and run `docker pull` to pull the three deleted images of project X.
9. In UI, delete project X.
10. Run `docker pull` to pull the three deleted images of the project X.
# Expected Outcome:
* Step 7, images should be deleted successfully.
* Step 9, project X should be deleted successfully.
* Step 8,10, docker client should report error message.
# Possible Problems:
None

51
tests/testcases/Group2-image-management/2-06-DB-user-delete-projects.md Normal file
View File

@ -0,0 +1,51 @@
Test 2-06 - User Delete Projects (DB Mode)
=======
# Purpose:
To verify that a non-admin user can delete projects when users are managed locally by Harbor (DB mode).
# References:
User guide
# Environment:
* This test requires that two(2) Harbor instances are 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).
* At least a non-admin user.
# Test Steps:
**NOTE:**
* In below test, user A is non-admin user. User A and project X should be replaced by longer and meaningful names.
* Must use two kinds of browsers at the same time to ensure independent sessions. For example, use Chrome and Firefox, or Chrome and Safari.
* DO NOT use the same browser to log in two users at the same time in different windows(tabs).
1. Log in to UI as user A (non-admin).
2. Create a project X so that the user has the project admin role.
3. On a Docker client, log in as User A and run `docker push` to push an image to project X, e.g. projectX/myimage:v1.
4. Push an image with different name to project X, e.g. projectX/newimage:v1 .
5. Run `docker pull` to verify images can be pushed successfully.
6. In UI, delete project X directly. (should fail with errors)
7. While keeping the current user A logged on, in a different browser, log in as admin user.
8. Under "Admin Options", create a replication policy of project X to another Harbor instance. (Do not need to activate this policy.)
9. Switch to the UI of User A, delete all images under project X.
10. In user A's UI, delete project X directly. (should fail with errors)
11. Switch to the UI of admin user, delete the replication policy of project X.
12. In user A's UI, delete project X.
13. In user A's UI, recreate project X,
14. On a Docker client, log in as User A and run `docker push` to push an image to project X, e.g. projectX/anotherimage:v1. The image name should not be the same as those deleted in previous steps.
15. Switch to the UI of admin user, view images under the re-created project X.
16. As an admin user, view the log in dashboard and should see delete and create operaions of project X.
# Expected Outcome:
* Step 6, deleting project X should fail because there are images under it.
* Step 10, deleting project X should fail because there is an image replication policy under it.
* Step 12, deleting project X should succeed.
* Step 13, re-creation of project X should succeed.
* Step 14, push should succeed.
* Step 15, project X should contain newly pushed image. The old images should not be displayed.
* Step 16, there should be logs for delete and create of project X, notice the project name of the deleted operation is displayed differently.
# Possible Problems:
None

25
tests/testcases/Group2-image-management/2-11-LDAP-user-create-project .md Normal file
View File

@ -0,0 +1,25 @@
Test 2-11 - User Create Project (LDAP Mode)
=======
# Purpose:
To verify that a non-admin user can create projects 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 LDAP or AD server. ( auth_mode is set to **ldap_auth** .) The user data is stored in an LDAP or AD server.
* A linux host with Docker CLI installed (Docker client).
* At least two non-admin users are in Harbor.
# Test Steps:
Same as Test 2-01 except that users are from LDAP/AD.
# Expected Outcome:
* Same as Test 2-01.
# Possible Problems:
None

25
tests/testcases/Group2-image-management/2-12-LDAP-user-push-multiple-images.md Normal file
View File

@ -0,0 +1,25 @@
Test 2-12 - User Push Multiple Images (LDAP Mode)
=======
# Purpose:
To verify that a non-admin user can push multiple images to a project 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 LDAP or AD server. ( auth_mode is set to **ldap_auth** .) The user data is stored in an LDAP or AD server.
* A linux host with Docker CLI installed (Docker client).
* At least a non-admin user and the user has at least a project as project admin.
# Test Steps:
Same as Test 2-02 except that users are from LDAP/AD.
# Expected Outcome:
* Same as Test 2-02.
# Possible Problems:
None

25
tests/testcases/Group2-image-management/2-13-LDAP-user-push-multiple-projects.md Normal file
View File

@ -0,0 +1,25 @@
Test 2-13 - User Create Multiple Projects (LDAP Mode)
=======
# Purpose:
To verify that a non-admin user can create multiple projects 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 LDAP or AD server. ( auth_mode is set to **ldap_auth** .) The user data is stored in an LDAP or AD server.
* A linux host with Docker CLI installed (Docker client).
* At least a non-admin user.
# Test Steps:
Same as Test 2-03 except that users are from LDAP/AD.
# Expected Outcome:
* Same as Test 2-03.
# Possible Problems:
None

26
tests/testcases/Group2-image-management/2-14-LDAP-user-view-projects.md Normal file
View File

@ -0,0 +1,26 @@
Test 2-14 - User View Projects (LDAP Mode)
=======
# Purpose:
To verify that a non-admin user can view projects 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 LDAP or AD server. ( auth_mode is set to **ldap_auth** .) The user data is stored in an LDAP or AD server.
* There is at least a non-admin user.
* The user has at least 3 private projects.
* The registry has at least 3 public repositories.
# Test Steps:
Same as Test 2-04 except that users are from LDAP/AD.
# Expected Outcome:
* Same as Test 2-04.
# Possible Problems:
None

25
tests/testcases/Group2-image-management/2-15-LDAP-user-delete-image.md Normal file
View File

@ -0,0 +1,25 @@
Test 2-15 - User Delete Images (LDAP Mode)
=======
# Purpose:
To verify that a non-admin user can delete images 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 LDAP or AD server. ( auth_mode is set to **ldap_auth** .) The user data is stored in an LDAP or AD server.
* A linux host with Docker CLI installed (Docker client).
* At least a non-admin user.
# Test Steps:
Same as Test 2-05 except that users are from LDAP/AD.
# Expected Outcome:
* Same as Test 2-05.
# Possible Problems:
None

25
tests/testcases/Group2-image-management/2-16-LDAP-user-delete-projects.md Normal file
View File

@ -0,0 +1,25 @@
Test 2-16 - User Delete Projects (LDAP Mode)
=======
# Purpose:
To verify that a non-admin user can delete projects in (LDAP mode).
# References:
User guide
# Environment:
* This test requires that two(2) Harbor instances are running and available.
* Harbor is set to authenticate against an LDAP or AD server. ( auth_mode is set to **ldap_auth** .) The user data is stored in an LDAP or AD server.
* A linux host with Docker CLI installed (Docker client).
* At least a non-admin user.
# Test Steps:
Same as Test 2-06 except that users are from LDAP/AD.
# Expected Outcome:
* Same as Test 2-06.
# Possible Problems:
None

48
tests/testcases/Group2-image-management/2-21-admin-view-project.md Normal file
View File

@ -0,0 +1,48 @@
Test 2-21 - Admin View Projects (DB Mode)
=======
# Purpose:
To verify that an admin user can view all projects 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).
* At least a non-admin users is in Harbor.
# Test Steps:
**NOTE:**
In below test, user A is non-admin user. User A and project X, Y should be replaced by longer and meaningful names.
1. Log in to UI as user A (non-admin).
2. Create a new project X with publicity is off (default).
3. Create another new project Y with publicity is on.
4. On a Docker client host, use `docker login <harbor_host>` to log in as user A.
5. Push an image to project X, push another image to project Y.
6. In UI, logs out and log in as admin user.
7. Check "Public Projects" to verify that project Y is listed and project X is not listed.
8. Verify that project "library" is listed.
9. Click project Y and view the newly pushed image in project Y.
10. Click "Users" to view the members of project Y.
11. Check "My projects" to verify that both project X and project Y are listed.
12. Verify that project "library" is listed.
13. Click project X and view the newly pushed image in project X.
14. Click "Users" to view the members of project X.
# Expected Outcome:
* Step 7, admin should see project Y is listed and project X is not listed.
* Step 8, project library should be listed.
* Step 9, the image pushed by user A should be listed under project Y.
* Step 10, user A should be project admin of project Y.
* Step 11, admin should see project X and Y are both listed.
* Step 12, project library should be listed.
* Step 13, the image pushed by user A should be listed under project X.
* Step 14, user A should be project admin of project X.
# Possible Problems:
None

33
tests/testcases/Group2-image-management/2-22-admin-search-projects.md Normal file
View File

@ -0,0 +1,33 @@
Test 2-22 - Admin User Search Projects (DB Mode)
=======
# Purpose:
To verify that a non-admin user can search projects 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).
* At least a non-admin user.
# Test Steps:
**NOTE:**
In below test, user A is non-admin user. User A should be replaced by a longer and meaningful name.
1. Log in to UI as user A (non-admin).
2. Create at least 5 projects with different names.
3. Log out and log in again as admin user.
4. Search projects with keywords to see if projects of user A can be matched by criteria.
5. Click on a few projects to toggle publicity on and off.
6. Check in "Public Projects" to verify the projects with publicity on can be listed.
# Expected Outcome:
* As descirbed in step 4,6.
# Possible Problems:
None

37
tests/testcases/Group2-image-management/2-23-admin-delete-images.md Normal file
View File

@ -0,0 +1,37 @@
Test 2-22 - Admin User Delete Images (DB Mode)
=======
# Purpose:
To verify that an admin user can delete images owned by other users 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).
* At least a non-admin user.
# Test Steps:
**NOTE:**
In below test, user A is non-admin user. User A and project X should be replaced by longer and meaningful names.
1. Log in to UI as user A (non-admin).
2. Create a project X so that the user has the project admin role.
3. On a Docker client, log in as User A and run `docker push` to push an image to the project X, e.g. projectX/myimage:v1.
4. Push an image with different name to project X, e.g. projectX/newimage:v1 .
5. Run `docker pull` to verify images can be pushed successfully.
6. In UI, log out user A's session.
7. Log in as admin user.
8. Under project X, delete the two images one by one.
9. On a Docker client, log in as User A and run `docker pull` to pull the two deleted images of project X.
# Expected Outcome:
* Step 8, admin user can delete images of project X.
* Step 9, docker client should report errors.
# Possible Problems:
None

41
tests/testcases/Group2-image-management/2-24-admin-delete-projects.md Normal file
View File

@ -0,0 +1,41 @@
Test 2-24 - Admin User Delete Projects (DB Mode)
=======
# Purpose:
To verify that an admin user can delete other user's projects when users are managed locally by Harbor (DB mode).
# References:
User guide
# Environment:
* This test requires that two(2) Harbor instances are 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).
* At least a non-admin user.
# Test Steps:
**NOTE:**
* In below test, user A is non-admin user. User A and project X should be replaced by longer and meaningful names.
* Must use two kinds of browsers at the same time to ensure independent sessions. For example, use Chrome and Firefox, or Chrome and Safari.
* DO NOT use the same browser to log in two users in different windows(tabs).
1. Log in to UI as user A (non-admin).
2. Create a project X so that the user has the project admin role.
3. On a Docker client, log in as User A and run `docker push` to push an image to project X, e.g. projectX/myimage:v1.
4. Run `docker pull` to verify images can be pushed successfully.
5. In UI, log out user A.
6. Log in as admin user.
7. Delete project X. (should fail with errors)
8. Delete all images of project X.
9. Delete project X.
10. As an admin user, view the log in dashboard and should see delete operaion of project X and its images.
# Expected Outcome:
* Step 7, deleting project X should fail because there are images under it.
* Step 8-9, deleting images of project X and then deleting project X should succeed.
* Step 10, there should be logs for delete and create of project X, notice the project name of the deleted operation is displayed differently.
# Possible Problems:
None

74
tests/testcases/Group3-RBAC/3-01-DB-user-manage-project-members.md Normal file
View File

@ -0,0 +1,74 @@
Test 3-01 - Manage Project Members (DB Mode)
=======
# Purpose:
To verify that a non system admin user can add members of various roles to a project 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).
* At least three non-admin users are in Harbor.
# Test Steps:
**NOTE:**
* In below test, user A, B and C are non system admin users. User A, B, C and project X should be replaced by longer and meaningful names.
* MUST use two kinds of browsers at the same time to ensure independent sessions. For example, use Chrome and Firefox, or Chrome and Safari.
* DO NOT use the same browser to log in two users at the same time in different windows(tabs).
1. Log in to UI as user A (non-admin).
2. Create a new project X with publicity is off (default).
3. Verify that user A cannot change his/her own role of project X.
4. On a Docker client host, use `docker login <harbor_host>` to log in as user A.
5. Push an image to project X.
6. On the Docker client host, log out user A and log in as user B.
7. Use `docker pull` to pull the image from project X. (should fail)
8. Use `docker push` to push an image to project X. (should fail)
9. Keeps user A's UI session logging on, in a different browser log in as user B.
10. User B views "My Projects", should not see project X.
11. In user A's UI, add user B to project X as a guest.
12. In user B's UI, check project X is in "My projects" and view members and images of project X.
13. Verify that user B cannot change role of other members in project X.
14. Verify that user B cannot add a new member to project X.
15. On a Docker client host, user B again pulls the image from project X.
16. user B pushes a new image to project X. (should fail)
17. In user A's UI, update user B to developer role of project X.
18. In user B's UI, check project X is in "My projects" and view members and images of project X.
19. Verify that user B cannot change role of other members in project X.
20. Verify that user B cannot add a new member to project X.
21. On a Docker client host, user B pushes a new image to project X.
22. In user A's UI, update user B to project admin role of project X.
23. In user B's UI, check project X is in "My projects" and view members and images of project X.
24. Verify that user B can add a new member user C to project X.
25. Verify that user B can change role of user C in project X.
26. On a Docker client host, user B pushes a new image to project X.
27. In user A's UI, remove user B from project X.
28. On a Docker client host, user B pulls an image of project X. (should fail)
29. On a Docker client host, log out user B and log in as user C.
30. User C pulls an image of project X.
# Expected Outcome:
* Step 3, user B cannot change his/her own role, and cannot remove himself/herself from project X.
* Step 7, user B should fail to pull image from project X.
* Step 8, user B should fail to push image to project X.
* Step 9, make sure to keep A's session while using another browser to log in as user B.
* Step 10, user B should not see project X.
* Step 12-14, as described.
* Step 15, user B can pull the image of project X,
* Step 16, user B cannot push images to project X.
* Step 18-20, as described.
* Step 21, user B pushes an image successfully.
* Step 23-25, as described.
* Step 28, user B's pulling should fail
* Step 30, user C's pulling should succeed.
# Possible Problems:
None

49
tests/testcases/Group3-RBAC/3-02-DB-user-manage-project-publicity.md Normal file
View File

@ -0,0 +1,49 @@
Test 3-02 - Manage Project Publicity (DB Mode)
=======
# Purpose:
To verify that a non system admin user can change project publicity of a project 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).
* At least three non-admin users are in Harbor.
# Test Steps:
**NOTE:**
* In below test, user A, B are non system admin users. User A, B and project X should be replaced by longer and meaningful names.
* MUST use two kinds of browsers at the same time to ensure independent sessions. For example, use Chrome and Firefox, or Chrome and Safari.
* DO NOT use the same browser to log in two users at the same time in different windows(tabs).
1. Log in to UI as user A (non-admin).
2. Create a new project X with publicity is on.
3. On a Docker client host, use `docker login <harbor_host>` to log in as user A.
4. Push an image to project X.
5. On the Docker client host, log out user A and log in as user B.
6. User B pulls an image from project X.
7. Keeps user A's UI session logging on, in a different browser log in as user B.
8. User B views "My Projects", should not see project X.
9. User B views "Public Projects", should see project X.
10. In user A's UI, change publicity of project X to off.
11. In user B's UI, user B checks "My Projects" and "Public Projects", should not see project X in both places.
12. On the Docker client host, user B pulls an image from project X. (should fail)
13. In user A's UI, change publicity of project X to on again.
14. User B views "My Projects", should not see project X.
15. User B views "Public Projects", should see project X.
# Expected Outcome:
* Step 6, user B's pulling image from project X should succeed.
* Step 7, make sure to keep A's session while using another browser to log in user B.
* Step 8-11, as described.
* Step 12, user B's pulling should fail.
* Step 13-15, as described.
# Possible Problems:
None

40
tests/testcases/Group3-RBAC/3-03-DB-user-search-project-members.md Normal file
View File

@ -0,0 +1,40 @@
Test 3-03 - Search Project Members (DB Mode)
=======
# Purpose:
To verify that a non system admin user can search members of a project 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).
* At least five(5) non-admin users are in Harbor.
# Test Steps:
**NOTE:**
* In below test, user A, B are non system admin users. User A, B and project X should be replaced by longer and meaningful names.
* MUST use two kinds of browsers at the same time to ensure independent sessions. For example, use Chrome and Firefox, or Chrome and Safari.
* DO NOT use the same browser to log in two users at the same time in different windows(tabs).
1. Log in to UI as user A (non-admin).
2. Create a new project X.
3. Add user B as a project admin role of project X.
4. Add 3 more members to project X with various roles, such as developer, guest.
5. Keeps user A's UI session logging on, in a different browser log in as user B.
6. In user B's UI, search members of project X using different criteria (keywords).
7. In user A's UI, change user B's role to developer of project X.
8. In user B's UI, search members of project X using different criteria.
9. In user A's UI, change user B's role to guest of project X.
10. In user B's UI, search members of project X using different criteria.
# Expected Outcome:
* Step 6,8,10, user B should see results based on search keywords.
# Possible Problems:
None

31
tests/testcases/Group3-RBAC/3-04-LDAP-user-manage-project-members.md Normal file
View File

@ -0,0 +1,31 @@
Test 3-04 - Manage Project Members (LDAP Mode)
=======
# Purpose:
To verify that a non system admin user can add members of various roles to a project 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 LDAP or AD server. ( auth_mode is set to **ldap_auth** .) The user data is stored in an LDAP or AD server.
* A linux host with Docker CLI installed (Docker client).
* At least three non-admin users are in Harbor.
# Test Steps:
**NOTE:**
* In below test, user A, B and C are non system admin users. User A, B, C and project X should be replaced by longer and meaningful names.
* MUST use two kinds of browsers at the same time to ensure independent sessions. For example, use Chrome and Firefox, or Chrome and Safari.
* DO NOT use the same browser to log in two users at the same time in different windows(tabs).
Same as Test 3-01.
# Expected Outcome:
Same as Test 3-01.
# Possible Problems:
None

31
tests/testcases/Group3-RBAC/3-05-LDAP-user-manage-project-publicity.md Normal file
View File

@ -0,0 +1,31 @@
Test 3-05 - Manage Project Publicity (LDAP Mode)
=======
# Purpose:
To verify that a non system admin user can change project publicity of a project 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 LDAP or AD server. ( auth_mode is set to **ldap_auth** .) The user data is stored in an LDAP or AD server.
* A linux host with Docker CLI installed (Docker client).
* At least three non-admin users are in Harbor.
# Test Steps:
**NOTE:**
* In below test, user A, B are non system admin users. User A, B and project X should be replaced by longer and meaningful names.
* MUST use two kinds of browsers at the same time to ensure independent sessions. For example, use Chrome and Firefox, or Chrome and Safari.
* DO NOT use the same browser to log in two users at the same time in different windows(tabs).
Same as Test 3-02.
# Expected Outcome:
Same as Test 3-02
# Possible Problems:
None

26
tests/testcases/Group3-RBAC/3-06-LDAP-user-search-project-members.md Normal file
View File

@ -0,0 +1,26 @@
Test 3-06 - Search Project Members (LDAP Mode)
=======
# Purpose:
To verify that a non system admin user can search members of a project 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 LDAP or AD server. ( auth_mode is set to **ldap_auth** .) The user data is stored in an LDAP or AD server.
* A linux host with Docker CLI installed (Docker client).
* At least five(5) non-admin users are in Harbor.
# Test Steps:
Same as Test 3-03.
# Expected Outcome:
* Same as Test 3-03.
# Possible Problems:
None

78
tests/testcases/Group3-RBAC/3-11-DB-admin-user-manage-project-members.md Normal file
View File

@ -0,0 +1,78 @@
Test 3-11 - Admin Manages Project Members (DB Mode)
=======
# Purpose:
To verify that an admin user can add members of various roles to a project. 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).
* At least three non-admin users are in Harbor.
* At least one project that admin user is not a member of.
# Test Steps:
**NOTE:**
* In below test, user A, B and C are non system admin users. User A, B, C and project X should be replaced by longer and meaningful names.
* MUST use two kinds of browsers at the same time to ensure independent sessions. For example, use Chrome and Firefox, or Chrome and Safari.
* DO NOT use the same browser to log in two users at the same time in different windows(tabs).
1. Log in to UI as admin user.
2. Look for an existing project X that admin is not a member of.
3. Add user A to project X as project admin.
4. Add user B to project X as developer.
5. Add user C to project X as guest.
6. On a Docker client host, use `docker login <harbor_host>` to log in as admin.
7. Use `docker push` to push an image to project X.
8. Use `docker pull` to pull the image from project X.
9. On a Docker client host, log out admin and log in as user A.
10. Use `docker push` to push an image to project X.
11. Use `docker pull` to pull the image from project X.
12. On a Docker client host, log out user A and log in as user B.
13. Use `docker push` to push an image to project X.
14. Use `docker pull` to pull the image from project X.
15. On a Docker client host, log out user B and log in as user C.
16. Use `docker pull` to pull the image from project X.
17. Use `docker push` to push an image to project X. (should fail)
18. Keeps admin's UI session logging on, in a different browser log in as user C.
19. In user C's UI, verify his/her role is guest of project X.
20. In admin's UI, change user C's role to developer of project X.
21. In user C's UI, verify his/her role is developer of project X.
22. On a Docker client host, log in as user C.
23. Use `docker pull` to pull the image from project X.
24. Use `docker push` to push an image to project X.
25. In admin's UI, change user C's role to project admin of project X.
26. In user C's UI, verify his/her role is project admin of project X.
27. In admin's UI, remove user C's from project X.
28. Set project X's publicity to on.
29. On a Docker client host, log in as user C.
30. Use `docker pull` to pull the image from project X.
31. Use `docker push` to push an image to project X. (should fail)
32. In admin's UI, remove user C's from project X.
33. Set project X's publicity to off.
34. On a Docker client host, log in as user C.
35. Use `docker pull` to pull the image from project X. (should fail)
36. Use `docker push` to push an image to project X. (should fail)
# Expected Outcome:
* Step 7,8,10,11,16 should succeed.
* Step 17 should report errors.
* Step 19,21, as described.
* Step 23,24 should succeed.
* Step 26 as described.
* Step 30 should succeed.
* Step 31 should fail.
* Step 35-36 should fail.
# Possible Problems:
None

34
tests/testcases/Group3-RBAC/3-12-DB-admin-user-search-project-members.md Normal file
View File

@ -0,0 +1,34 @@
Test 3-12 - Admin Search Project Members (DB Mode)
=======
# Purpose:
To verify that an admin user can search members of a project 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).
* At least five(5) non-admin users are in Harbor.
* At least 5 members in a project that admin user is not a member of.
# Test Steps:
**NOTE:**
* In below test, user A, B are non system admin users. User A, B and project X should be replaced by longer and meaningful names.
* MUST use two kinds of browsers at the same time to ensure independent sessions. For example, use Chrome and Firefox, or Chrome and Safari.
* DO NOT use the same browser to log in two users at the same time in different windows(tabs).
1. Log in to UI as admin.
2. Look for an existing project X that admin is not a member of, project X should have at least 5 members.
3. Search members of project X using different criteria (keywords).
# Expected Outcome:
* Step 3, admin should see results based on search keywords.
# Possible Problems:
None

39
tests/testcases/Group4-logging/4-01-DB-user-view-logs.md Normal file
View File

@ -0,0 +1,39 @@
Test 4-01 - User Views Logs (DB Mode)
=======
# Purpose:
To verify that a non-admin user can views logs 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:
1. On a Docker client host, use `docker login <harbor_host>` command to log in as a non-admin user.
2. Run some `docker push` and `docker pull` commands to push images to the registry and pull from the registry.
3. Log in to the UI as the non-admin user.
4. Delete a few images from the project.
5. View the logs of the project.
6. Try below search criteria to see if the search result is correct:
* push only
* pull only
* pull and push
* delete only
* all
* push and delete
* different date ranges
* date range and push
# Expected Outcome:
* All operations in Step 2 & 4 should be logged.
* Logs can be viewed in Step 5, check if the time and operations are correct.
* Logs can be filtered in Step 6.
# Possible Problems:
None