1. Trang chủ
  2. » Luận Văn - Báo Cáo

Đề tài kiểm thử hệ thống var hrm

146 8 0

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Tiêu đề Kiểm Thử Hệ Thống Var HRM
Người hướng dẫn Th.s. Cao Thị Nhâm
Trường học Trường Đại Học Kinh Tế
Chuyên ngành Hệ Thống Thông Tin Quản Lý
Thể loại Báo Cáo Thực Tập Nghề Nghiệp
Thành phố Đà Nẵng
Định dạng
Số trang 146
Dung lượng 7,83 MB

Cấu trúc

  • 1. Mu ̣c tiêu của đề tài (20)
  • 2. Nhiệm vụ của đề tài (20)
  • 3. Đối tượng và phạm vi nghiên cứu (20)
  • 4. Kết cấu của đề tài (20)
  • CHƯƠNG 1. TỔNG QUAN VỀ DOANH NGHIỆP VÀ VỊ TRÍ VIỆC LÀM 2 1.1. Giơ ́ i thiê ̣u tổng quát về doanh nghiê ̣p thực tâ ̣p (21)
    • 1.1.1. Tổng quan về công ty (21)
    • 1.1.2. Tầm nhìn và sứ mệnh (21)
    • 1.1.3. Lĩnh vực hoạt động (22)
    • 1.1.4. Cơ cấu tổ chức (23)
    • 1.1.5. Chính sách đãi ngộ (23)
    • 1.2. Tổng quan về vi ̣ tri ́ viê ̣c làm (24)
      • 1.2.1. Yêu cầu về kiến thức và kĩ năng (24)
      • 1.2.2. Công việc của một Tester (24)
      • 1.2.3. Mức lương (24)
      • 1.2.4. Con đường phát triển (24)
  • CHƯƠNG 2. CƠ SỞ LÝ THUYẾT VỀ KIỂM THỬ PHẦN MỀM (25)
    • 2.1. Tổng quan về Kiểm thử phần mềm và Manual Testing (25)
      • 2.1.1. Khái niệm về Kiểm thử phần mềm (25)
      • 2.1.2. Mục tiêu trong Kiểm thử phần mềm (25)
      • 2.1.3. Khái niệm về Manual Testing (26)
      • 2.1.4. Khái niệm về Testcase (26)
      • 2.1.5. Ưu điểm của Manual Testing (26)
      • 2.1.6. Nhược điểm của Manual Testing (27)
    • 2.2. Quy trình kiểm thử phần mềm (27)
    • 2.3. Các mô hình phát triển phần mềm (27)
      • 2.3.1. Mô hình thác nước (28)
      • 2.3.2. Mô hình chữ V (28)
      • 2.3.3. Khung làm việc Scrum (28)
      • 2.3.4. Mô hình xoắn ốc (29)
      • 2.3.5. Kết luận (29)
    • 2.5. Tổng quan về Unit Test (UT) (30)
    • 2.6. Các kĩ thuật viết Testcase (30)
    • 2.7. Bug và Log bug (30)
  • CHƯƠNG 3. PHÂN TÍCH THIẾT KẾ HỆ THỐNG (31)
    • 3.1. Tổng quan về hệ thống (31)
      • 3.1.1. Tổng quan về hệ thống VAR HRM (0)
      • 3.1.2. Một vài module của hệ thống VAR HRM (31)
      • 3.1.3. Sơ đồ chức năng của hệ thống VAR HRM (32)
    • 3.2. Workflow chung của hệ thống VAR HRM (32)
      • 3.3.1. Sơ đồ use case tổng quát cho chức năng Manage Asset Type (35)
      • 3.3.2. Phân tích use case Search Asset Type (35)
        • 3.3.2.2. Đặc tả yêu cầu cho use case “Search Asset Type” (37)
      • 3.3.3. Phân tích use case Add Asset Type (38)
        • 3.3.3.1. Đặc tả yêu cầu cho use case “Add Asset Type” (38)
      • 3.3.4. Phân tích use case View Asset Type (41)
        • 3.3.4.1. Đặc tả yêu cầu cho use case “View Asset Type” (41)
      • 3.3.5. Phân tích use case Edit Asset Type (43)
        • 3.3.5.1. Đặc tả yêu cầu cho use case “Edit Asset Type” (43)
      • 3.3.6. Phân tích use case Delete Asset Type (45)
        • 3.3.6.1. Đặc tả yêu cầu cho use case “Delete Asset Type” (45)
    • 3.4. Phân tích use case Manage Asset List (47)
      • 3.4.1. Sơ đồ use case tổng quát cho chức năng Manage Asset List (47)
      • 3.4.2. Phân tích use case Search Asset List (47)
        • 3.4.2.1. Đặc tả yêu cầu cho use case “Search Asset List” (47)
      • 3.4.3. Phân tích use case Add Asset List (49)
        • 3.4.3.1. Đặc tả yêu cầu cho use case “Add Asset List” (49)
  • CHƯƠNG 4. TRIỂN KHAI THỰC NGHIỆM (56)
    • 4.1. Thiết kế Test plan (56)
      • 4.1.2. Phạm vi kiểm thử (56)
        • 4.1.2.1. Phạm vi kiểm thử của Asset Management (56)
        • 4.1.2.2. Phạm vi kiểm thử của Resource Management (57)
        • 4.1.2.3. Phạm vi kiểm thử của Skill Management (57)
      • 4.1.4. Yêu cầu về tài nguyên (59)
      • 4.1.6. Chiến lược kiểm thử (60)
      • 4.1.7. Quy trình xử lý lỗi (60)
    • 4.2. Phân tích kiểm thử (Test Analysis) (60)
    • 4.3. Thiết kế kiểm thử (Test design) (61)
    • 4.4. Test Implement (61)
      • 4.4.1. Thực hiện viết TCs (61)
      • 4.4.2. Set up môi trường Test (62)
      • 4.4.4. Lưu ý khi UT (62)
    • 4.5. Thiết kế và thực thi Test case cho hệ thống (63)
    • 4.6. Công cụ hỗ trợ log bug (66)
      • 4.6.1. Khái niệm JetBrains Space (66)
      • 4.6.2. Thực hiện log bug trên JetBrains Space (67)
    • 4.7. Kết quả (68)
      • 4.7.1. Log bugs hệ thống và một vài minh chứng tại một số màn hình đã log 49 1. Asset Management (68)
  • TÀI LIỆU THAM KHẢO (73)
  • PHỤ LỤC (73)
    • 1.1.1. Yêu cầu về kiến thức và kĩ năng (73)
    • 1.1.2. Công việc của một Tester (74)
    • 1.1.3. Mức lương (74)
    • 1.1.4. Con đường phát triển (74)
    • 2. C ÁC MỤC BỔ SUNG CHƯƠNG 2 CƠ SỞ LÝ THUYẾT VỀ KIỂM THỬ PHẦN MỀM (75)
      • 2.5.1. Khái niệm về Unit Test (UT) (75)
      • 2.5.3. Lợi ích của UT (75)
      • 2.5.4. Các loại test khác ngoài UT (76)
      • 2.6.1. Phân vùng tương đương (Equivalence Class Partitioning) (76)
      • 2.6.2. Phân tích giá trị biên (Boundary Value Analysis) (76)
      • 2.6.3. Bảng quyết định (Decision tables) (76)
      • 2.6.4. Đoán lỗi (Error Guessing) (77)
      • 2.6.5. Chuyển đổi trạng thái (State Transition) (77)
      • 2.7.1. Khái niệm về Bug (77)
      • 2.7.2. Khái niệm về Log bug (77)
      • 2.7.3. Vòng đời của bug (78)
      • 2.7.4. Cấu trúc của report bug (79)
    • 3. C ÁC MỤC BỔ SUNG CHƯƠNG 3 PHÂN TÍCH THIẾT KẾ (55)
      • 3.4.4. Phân tích use case View + Edit Asset List (80)
        • 3.4.4.1. Đặc tả yêu cầu cho use case “View + Edit Asset List” (80)
      • 3.4.5. Phân tích use case Delete Asset List (82)
        • 3.4.5.1. Đặc tả yêu cầu cho use case “Delete Asset List” (82)
      • 3.4.6. Phân tích use case View report (83)
        • 3.4.6.1. Đặc tả yêu cầu cho use case “View report” (83)
      • 3.5.2. Phân tích use case Scan QR code (85)
        • 3.5.2.1. Đặc tả yêu cầu cho use case “Scan QR code” (85)
      • 3.5.3. Phân tích use case Print QR code (87)
        • 3.5.3.1. Đặc tả yêu cầu cho use case “Print QR code” (87)
      • 3.5.4. Phân tích use case Save QR code (89)
        • 3.5.4.1. Đặc tả yêu cầu cho use case “Save QR code” (89)
      • 3.6.2. Phân tích use case Search handover asset (90)
        • 3.6.2.1. Đặc tả yêu cầu cho use case “Search handover asset” (90)
      • 3.6.3. Phân tích use case Add Handover asset (91)
        • 3.6.3.1. Đặc tả yêu cầu cho use case “Add Handover asset” (91)
      • 3.6.4. Phân tích use case View Handover asset (95)
        • 3.6.4.1. Đặc tả yêu cầu cho use case “View handover asset” (95)
      • 3.6.5. Phân tích use case Edit Handover asset (97)
        • 3.6.5.1. Sơ đồ hoạt động của Edit Handover asset (97)
        • 3.6.5.2. Đặc tả yêu cầu cho use case “Edit Handover asset” (97)
      • 3.6.6. Phân tích use case Delete Handover asset (100)
        • 3.6.6.1. Đặc tả yêu cầu cho use case “Delete Handover asset” (100)
      • 3.7. Phân tích use case Manage Project (102)
        • 3.7.1. Sơ đồ use case tổng quát cho chức năng Manage Project (102)
        • 3.7.2. Phân tích use case Search project (102)
          • 3.7.2.1. Đặc tả yêu cầu cho use case “Search project” (102)
        • 3.7.3. Phân tích use case Add Project (104)
          • 3.7.3.1. Đặc tả yêu cầu cho use case “Add Project” (104)
        • 3.7.4. Phân tích use case View Project (107)
          • 3.7.4.1. Đặc tả yêu cầu cho use case “View Project” (107)
        • 3.7.5. Phân tích use case Edit Project (109)
          • 3.7.5.1. Đặc tả yêu cầu cho use case “Edit Project” (109)
        • 3.7.6. Phân tích use case View report (111)
          • 3.7.6.1. Đặc tả yêu cầu cho use case “View report” (111)
        • 3.7.7. Phân tích use case View project effort (112)
          • 3.7.7.1. Đặc tả yêu cầu cho use case “View project effort” (112)
        • 3.7.8. Phân tích use case View project timeline (113)
          • 3.7.8.2. Đặc tả yêu cầu cho use case “View project timeline” (113)
        • 3.7.9. Phân tích use case View project resource (115)
          • 3.7.9.1. Đặc tả yêu cầu cho use case “View project resource” (115)
      • 3.8. Phân tích use case Manage Phase (116)
        • 3.8.1 Sơ đồ use case tổng quát cho chức năng Manage Phase (116)
        • 3.8.2. Phân tích use case Search phase (117)
          • 3.8.2.1. Đặc tả yêu cầu cho use case “Search phase” (117)
        • 3.8.3. Phân tích use case Add Phase (118)
          • 3.8.3.1. Đặc tả yêu cầu cho use case “Add Phase” (118)
        • 3.8.4. Phân tích use case View + Edit phase (122)
          • 3.8.4.1. Đặc tả yêu cầu cho use case “View + Edit phase” (122)
        • 3.8.5. Phân tích use case Add member (124)
          • 3.8.5.1. Đặc tả yêu cầu cho use case “Add member” (124)
        • 3.8.6. Phân tích use case Evaluate progress phase (127)
          • 3.8.6.1. Đặc tả yêu cầu cho use case “Evaluate progress phase” (127)
        • 3.8.7. Phân tích use case Put effort (130)
          • 3.8.7.1. Đặc tả yêu cầu cho use case “Put effort” (130)
        • 3.8.8. Phân tích use case View report phase (131)
          • 3.8.8.1. Đặc tả yêu cầu cho use case “View report phase” (131)
    • 4. C ÁC MỤC BỔ SUNG CHƯƠNG 4 TRIỂN KHAI THỰC NGHIỆM (133)
      • 4.7.1.2. Resource Management (134)
      • 4.7.1.3. Skill Management (140)
    • 5. Link Test case Asset Management (144)
    • 6. Link Test case Resource Management (144)
    • 7. Link Test case Skill Management (144)
    • 8. Link log bug (145)

Nội dung

Mu ̣c tiêu của đề tài

Mục đích của nghiên cứu là kiểm soát chất lượng hệ thống VAR HRM, bao gồm các chức năng chính như Quản lý Tài sản, Quản lý Tài nguyên và Quản lý Kỹ năng Nghiên cứu sẽ thực hiện các hoạt động kiểm thử cho các chức năng như tìm kiếm, thêm mới, xem sửa và xóa, nhằm hiểu rõ hơn về công việc của một kiểm thử viên trong doanh nghiệp.

Nhiệm vụ của đề tài

- Tìm các bug phát sinh do dev tạo ra khi code

- Đạt được sự tự tin và cung cấp thông tin về mức độ chất lượng sản phẩm

- Ngăn ngừa lỗi, đảm bảo rằng kết quả cuối cùng đáp ứng các yêu cầu nghiệp vụ và người sử dụng.

Kết cấu của đề tài

Đề tài được tổ chức gồm phần mở đầu, 4 chương nội dung và phần kết luận

- Chương 1: Tổng quan về doanh nghiệp và vị trí việc làm

- Chương 2: Cơ sở lý thuyết về kiểm thử phần mềm

- Chương 3: Phân tích thiết kế hệ thống

- Chương 4: Triển khai thực nghiệm

- Kết luận và hướng phát triển

TỔNG QUAN VỀ DOANH NGHIỆP VÀ VỊ TRÍ VIỆC LÀM 2 1.1 Giơ ́ i thiê ̣u tổng quát về doanh nghiê ̣p thực tâ ̣p

Tổng quan về công ty

Meta được thành lập vào năm 2020, chuyên về công nghệ chuỗi khối và thực tế ảo/thực tế tăng cường Từ 3 thành viên ban đầu, công ty hiện có 40 kỹ sư nhiệt huyết và cam kết cung cấp dịch vụ công nghệ tiên tiến Trụ sở chính tại Hà Nội và văn phòng đại diện ở Đà Nẵng, Meta phục vụ khách hàng toàn cầu từ Hồng Kông, Nhật Bản, Singapore đến Vương quốc Anh, hỗ trợ phát triển các sản phẩm như nền tảng giao dịch tiền điện tử, Launchpad, cung cấp mã thông báo chứng khoán, ví điện tử và thị trường NFT.

Tầm nhìn và sứ mệnh

Tầm nhìn: Var Meta dự định xây dựng một tương lai gắn kết tiên tiến với công nghệ

Var Meta cam kết cung cấp dịch vụ toàn diện trong việc xây dựng blockchain, thực tế tăng cường và thực tế ảo (AR/VR) dựa trên nền tảng vững chắc.

Var Meta luôn cam kết phát triển với giá trị cốt lõi là đặt khách hàng làm trung tâm, từ đó tối ưu hóa nỗ lực và gia tăng giá trị cho khách hàng Các yếu tố thiết yếu để duy trì giá trị cốt lõi này bao gồm sự thấu hiểu nhu cầu của khách hàng, cải tiến dịch vụ và sản phẩm, cùng với việc xây dựng mối quan hệ bền vững.

Lĩnh vực hoạt động

Dịch vụ tư vấn phần mềm cung cấp những ý tưởng sáng tạo và mới mẻ, giúp doanh nghiệp đưa ra quyết định công nghệ hiệu quả và cập nhật hệ thống phần mềm một cách hợp lý.

Blockchain giúp Meta tự động hóa nhiều quy trình kinh doanh, bao gồm việc trao đổi dữ liệu khách hàng một cách an toàn, quản lý chuỗi cung ứng một cách minh bạch và số hóa tài sản hiệu quả.

● MetaVerse development: xây dựng các ứng dụng metaverse hoàn hảo, không gian ảo 3D và thị trường NFT metaverse trên các nền tảng phi tập trung

● NFT Blockchain: lên kế hoạch phát triển các dự án dựa trên các nền tảng blockchain của thế giới cho các chức danh của công ty

Staking NFT Gaming: Tối ưu hóa quy trình phát triển nền tảng với các tính năng bảo mật chặt chẽ, đáp ứng nhu cầu đa dạng của khách hàng.

Ví tiền điện tử là công cụ quan trọng giúp người dùng lưu trữ khóa riêng liên kết với sổ cái chuỗi khối Việc phát triển ví tiền điện tử không chỉ đảm bảo an toàn cho khóa riêng mà còn cung cấp các biện pháp bảo mật hiệu quả nhằm bảo vệ tài sản số của người dùng.

● ICO và Cryptocurrency: phát triển trang web hoàn toàn phù hợp với bất kỳ loại tư vấn kỹ thuật số hoặc doanh nghiệp tiền điện tử

● Cryptocurrency Exchange: phát triển nền tảng giao dịch tiền điện tử

● STO: phát triển mã thông báo tiện ích hoặc bảo mật dựa trên công nghệ sổ cái phân tán

● Development Apps: cung cấp dịch vụ phát triển ứng dụng di động và web từ xây dựng đến thiết kế

- VR/AR: Var Meta đưa sản phẩm từ thế giới vật chất sang thế giới kỹ thuật số

● AR Development: phát triển các giải pháp thực tế tăng cường tùy chỉnh

● VR Development: phát triển trải nghiệm nhập vai để cải thiện trực quan hóa dữ liệu, tương tác sản phẩm và tiến hành đào tạo VR hiệu quả

● Rapid Prototyping: giúp doanh nghiệp thử nghiệm các ý tưởng AR/VR

- Design: Var Meta có thể thiết kế tùy chỉnh, từ ý tưởng đến giải pháp và truyền cảm hứng cho nhu cầu công nghệ cho doanh nghiệp cụ thể.

Cơ cấu tổ chức

Công ty được thành lập với CEO hiện tại là ông Trần Đình Nhã

Hình 2 Cơ cấu tổ chức Công ty Var Meta

Chính sách đãi ngộ

- Lương và phúc lợi hấp dẫn: cung cấp mức lương cạnh tranh và các gói phúc lợi hấp dẫn, bao gồm bảo hiểm sức khỏe, bảo hiểm nhân thọ,

- Chế độ làm việc linh hoạt: áp dụng chế độ làm việc linh hoạt như làm việc từ xa, làm việc theo giờ linh hoạt

- Phát triển và đào tạo: đầu tư vào việc phát triển và đào tạo nhân viên, bằng cách tổ chữ các chuyên đề sharing knowledge thứ 6 hàng tuần

- Cơ hội thăng tiến: tạo cơ hội thăng tiến cho nhân viên thông qua việc đề xuất chuyển vị và thăng chức nội bộ

Môi trường làm việc thoải mái và sáng tạo là yếu tố quan trọng để nâng cao năng suất lao động Để đạt được điều này, cần thiết lập không gian làm việc hiện đại, bao gồm các phòng họp tiện nghi và khu vực giải trí Bên cạnh đó, tổ chức các hoạt động thể thao và sự kiện như bóng đá, cầu lông sẽ giúp nhân viên gắn kết hơn và tạo ra bầu không khí làm việc tích cực.

Chương trình thưởng và đánh giá hiệu suất hàng năm được thiết lập nhằm ghi nhận và tri ân những nhân viên cống hiến nhiều cho công ty Những chương trình này không chỉ khuyến khích tinh thần làm việc mà còn tạo động lực cho nhân viên phát triển và đóng góp tích cực vào sự thành công chung của tổ chức.

- Hoạt động team – building và du lịch hàng năm Tổ chức hoạt động ăn uống Happy hour chiều t6 hàng tuần,

Tổng quan về vi ̣ tri ́ viê ̣c làm

Phần Tổng quan về vị trí việc làm rất dài và chiếm nhiều trang, vì vậy tôi xin phép tóm tắt các mục quan trọng như yêu cầu về kiến thức và kỹ năng, cũng như công việc của một vị trí cụ thể.

Tester là một nghề đang được nhiều người quan tâm, với mức lương hấp dẫn và nhiều cơ hội phát triển Để tìm hiểu chi tiết về các khía cạnh này, quý thầy/cô có thể tham khảo phần Mục lục và các liên kết chi tiết bên dưới.

1.2.1 Yêu cầu về kiến thức và kĩ năng

Yêu cầu về kiến thức và kĩ năng

1.2.2 Công việc của một Tester

Công việc của một Tester

CƠ SỞ LÝ THUYẾT VỀ KIỂM THỬ PHẦN MỀM

Tổng quan về Kiểm thử phần mềm và Manual Testing

2.1.1 Khái niệm về Kiểm thử phần mềm

Kiểm thử phần mềm là quá trình thực thi một chương trình nhằm phát hiện lỗi, đảm bảo rằng sản phẩm phần mềm đáp ứng chính xác, đầy đủ và đúng theo yêu cầu của khách hàng Quá trình này đánh giá chất lượng phần mềm và giúp giảm thiểu nguy cơ lỗi khi phần mềm hoạt động thực tế.

Kiểm thử phần mềm gồm 2 loại: Manual Test (Kiểm thử thủ công ) và Automation test ( Kiểm thử tự động)

2.1.2 Mục tiêu trong Kiểm thử phần mềm

● Ngăn ngừa lỗi trong sản phẩm phần mềm

● Đánh giá các sản phẩm công việc (requirement, design, code…)

● Xác minh liệu tài liệu requirement đã đầy đủ các trường hợp chưa

● Xác định liệu đối tượng được kiểm thử đã hoàn thành và đáp ứng được yêu cầu của khách hàng, các bên liên quan mong đợi hay chưa?

● Xây dựng niềm tin về chất lượng của sản phẩm, đối tượng được kiểm thử

● Giảm thiểu rủi ro: tích hợp quy trình quản lý rủi ro để xác định mọi rủi ro càng sớm càng tốt trong quá trình phát triển

Cung cấp thông tin đầy đủ cho các bên liên quan là rất quan trọng, giúp họ đưa ra quyết định sáng suốt, đặc biệt liên quan đến chất lượng của đối tượng thử nghiệm.

● Tìm lỗi, xác định tối đa lỗi có trong sản phẩm phần mềm

Hình 3 Mục tiêu kiểm thử phần mềm

2.1.3 Khái niệm về Manual Testing

Manual testing là một công việc kiểm thử phần mềm hoàn toàn được làm bằng thủ công bằng tay

Kiểu kiểm tra nguyên thủy này không sử dụng công cụ nào để phát hiện lỗi trong hệ thống phần mềm, nhằm đảm bảo rằng các phần mềm và ứng dụng hoạt động đúng theo yêu cầu bằng cách tuân thủ các kịch bản và điều kiện trong test case.

Test case là một mô tả chi tiết về dữ liệu đầu vào, hành động thực hiện và kết quả mong đợi, nhằm xác định xem chức năng của ứng dụng phần mềm có hoạt động đúng hay không.

Một file Testcase cơ bản cần bao gồm các trường như TestcaseID, mục tiêu test, các bước thực hiện test, và kết quả trả về (expected result) để xác định tính chính xác theo yêu cầu test Bên cạnh đó, có thể bổ sung thêm điều kiện tiên quyết và dữ liệu test để hoàn thiện hơn.

2.1.5 Ưu điểm của Manual Testing

● Dễ dàng trong việc test giao diện

● Sẽ không phải mất quá nhiều thời gian cho việc kiểm tra đối với các trường hợp kiểm thử nếu chương trình có thay đổi nhỏ

Có nhiều cơ hội để thử nghiệm và khám phá kiểm thử, giúp phát hiện những lỗi khó mà có thể không dễ nhận thấy, từ đó nâng cao kỹ năng của tester.

● Tiết kiệm được chi phí ngắn hạn

2.1.6 Nhược điểm của Manual Testing

● Quá trình thực hiện các ca kiểm thử ít tin cậy hơn vì có thể gặp những sai sót do yếu tố con người

● Nó không có tính tái sử dụng vì các quá trình thực hiện các ca kiểm thử không được ghi lại

Việc thực hiện kiểm thử stress testing và performance testing một cách thủ công là rất khó khăn, vì chúng yêu cầu các công cụ chuyên nghiệp để đảm bảo tính chính xác và hiệu quả.

● Tiêu tốn nhiều thời gian cũng như công sức của các tester hơn trong việc phát hiện ra các bugs

● Cho ra kết quả chậm hơn và không hiệu quả bằng Automation Testing.

Quy trình kiểm thử phần mềm

● Lập kế hoạch kiểm thử (Test planning)

● Giám sát và điều khiển (Monitoring and control)

● Phân tích kiểm thử (Test analysis) phân tích các tài liệu yêu cầu, các cơ sở kiểm thử

● Thiết kế kiểm thử (Test design) áp dụng các kỹ thuật để thiết kế các trường hợp kiểm thử

● Thực hiện viết TCs, setup môi trường test, tạo data test (Test implement)

● Thực hiện/chạy kiểm thử và kiểm tra kết quả (Test Execution)

● Hoàn thành kiểm thử (Test completion)

Các mô hình phát triển phần mềm

Có 2 loại mô hình phát triển phần mềm:

- Mô hình tuần tự (Sequential development models)

- Mô hình lặp và tăng dần (Iterative and incremental development models)

Hình 5 Mô hình thác nước

Hình 7 Khung làm việc Scrum

Hình 8 Mô hình xoắn ốc

Trong bất kỳ mô hình vòng đời phát triển phần mềm nào đều có một số đặc điểm của kiểm thử như sau

● Đối với mỗi hoạt động phát triển đều có một hoạt động kiểm thử tương ứng

● Mỗi cấp độ kiểm thử có mục tiêu kiểm thử cụ thể cho các cấp độ đó

● Phân tích và thiết kế kịch bản kiểm thử cho một cấp độ nhất định phải bắt đầu trong giai đoạn phát triển tương ứng

Người kiểm thử nên tham gia tích cực vào các cuộc thảo luận để xác định yêu cầu và thiết kế, đồng thời tham gia xem xét các sản phẩm công việc như yêu cầu và thiết kế ngay từ giai đoạn bản nháp.

2.4 7 nguyên lý kiểm thử phần mềm

Hình 9 Nguyên lý kiểm thử phần mềm

● Kiểm thử chỉ cho thấy sự hiện diện của lỗi

● Không thể kiểm thử toàn bộ

● Kiểm thử càng sớm càng tốt

● Nghịch lý thuốc trừ sâu

● Kiểm thử phụ thuộc vào ngữ cảnh

● Quan niệm sai lầm về việc không có lỗi

Tổng quan về Unit Test (UT)

Phần Tổng quan về Unit Test (UT) có nội dung dài và chiếm nhiều trang, do đó, các mục như Khái niệm về Unit Test (UT), Khái niệm về PCL, Lợi ích của UT và Các loại test khác ngoài UT sẽ được đưa vào Mục lục Kính mong quý thầy/cô thông cảm và tham khảo chi tiết các mục này qua các liên kết ở phần Mục lục dưới đây.

2.5 Tổng quan về Unit Test (UT)

Các kĩ thuật viết Testcase

Phần Các kĩ thuật viết Testcase rất phong phú và chiếm nhiều trang, vì vậy tôi sẽ tập trung vào một trong những kỹ thuật quan trọng là Phân vùng tương đương (Equivalence Class Partitioning).

Phân tích giá trị biên (Boundary Value Analysis), Bảng quyết định (Decision tables), Đoán lỗi (Error Guessing), Chuyển đổi trạng thái (State Transition) ở phần Mục lục

Mong quý thầy/cô thông cảm và xem chi tiết các mục ở phần Mục lục trong link chi tiết ở dưới đây ạ:

2.6 Các kĩ thuật viết Testcase

Bug và Log bug

Vì phần Bug và Log bug rất dài và chiếm nhiều trang, em xin phép để các mục như Khái niệm về bug, Khái niệm về log bug, Vòng đời của bug, và Cấu trúc của report bug ở phần Mục lục Mong quý thầy/cô thông cảm và xem chi tiết các mục tại phần Mục lục trong link dưới đây.

PHÂN TÍCH THIẾT KẾ HỆ THỐNG

Tổng quan về hệ thống

3.1.1 Tổng quan về hệ thống VAR HRM

VAR HRM là hệ thống quản lý nguồn nhân lực do công ty Var Meta phát triển, cung cấp các công cụ, quy trình và chính sách hỗ trợ quản lý thông tin nhân viên, tiến độ công việc và lịch trình Hệ thống phục vụ cho các đối tượng như Director, Manager, Leader và Member, với quyền hạn khác nhau VAR HRM hoạt động 24/7 và hỗ trợ hai ngôn ngữ: Tiếng Việt và English Hệ thống bao gồm nhiều module, trong đó đã hoàn thành một số module như Quản lý Tài nguyên, Quản lý Tài sản và Quản lý Kỹ năng.

Ngoài ra, hệ thống đang định hướng phát triển thêm như: Request For Proposal; Internal Stackoverflow; Internal Wikipedia,

3.1.2 Một vài module của hệ thống VAR HRM

Các tính năng của hệ thống VAR HRM với role là Director trong quá trình thực tập được liệt kê theo bảng dưới đây:

Quản lý tài sản hiệu quả cho phép người dùng theo dõi và quản lý các tài sản trong công ty một cách chủ động Người dùng có thể dễ dàng thêm mới tài sản, tạo và in mã vạch, cũng như quét mã vạch được dán trên từng tài sản để đảm bảo quá trình quản lý diễn ra thuận lợi.

2 Resource Management Người dùng có thể tạo project, tạo phase, add member vào phase của project và nhập effort tương ứng

3 Skill Management Người dùng có thể theo dõi và quản lý thông tin về kỹ năng của từng nhân viên

Bảng 1 Các tính năng của hệ thống VAR HRM với role là Director trong quá trình thực tập

3.1.3 Sơ đồ chức năng của hệ thống VAR HRM

Sơ đồ chức năng dưới đây là toàn bộ mô phỏng khái quát về chức năng ở hệ thống VAR HRM

Hình 10 Sơ đồ tổng quát về hệ thống VAR HRM

Workflow chung của hệ thống VAR HRM

Link workflow: https://drive.google.com/file/d/1XVySllWfEdPjHb9YS1rgf747sd5AZG-

Hình 11 Work flow chung của hệ thống VAR-HRM

Trong quá trình thực tập em chỉ làm việc với một vài chức năng bao gồm: Resource

Trong bài báo cáo này, tôi sẽ trình bày những kiến thức liên quan đến các chức năng mà tôi đã thực hiện trong quá trình thực tập, bao gồm quản lý, quản lý tài sản và quản lý kỹ năng.

15 Hình 12 Use case tổng quát hệ thống VAR-HRM 3.3 Phân tích use case Manage Asset Type

3.3.1 Sơ đồ use case tổng quát cho chức năng Manage Asset Type

Hình 13 Use case tổng quát của Manage Asset Type Use case “Manage Asset Type” gồm các use case:

3.3.2 Phân tích use case Search Asset Type

Mô tả chi tiết khi Đăng nhập vào hệ thống:

Hình 14 Giao diện đăng nhập

- Khi user truy cập vào phần mềm xuất hiện giao diện đăng nhập và yêu cầu log in với Google Account đã được cung cấp trước đó

- Sau khi đăng nhập thành công phần mềm hiển thị danh sách các chức năng chính của hệ thống

Hình 15 Giao diện sau khi đăng nhập thành công

3.3.2.2 Đặc tả yêu cầu cho use case “Search Asset Type”

Tác nhân: Director, Manager Điều kiện tiên quyết: Đăng nhập thành công vào hệ thống và có quyền truy cập vào chức năng Manage Asset Type

Mô tả khái quát: Use case này nhằm mục đích phân loại tài sản thông qua một ô tìm kiếm, cho phép kiểm tra các trường thông tin liên quan đến phân loại tài sản bằng cách nhập từ khóa tìm kiếm.

Bước 1: Director/Manager truy cập vào giao diện Màn hình chính

Bước 2: Director/Manager click tab Asset Type ở tab menu Asset Management

Bước 3: Director/Manager nhập tên phân loại tài sản cần tìm kiếm vào search box và bấm phím "Enter"

Kết quả tìm kiếm hiển thị trên giao diện cho người dùng, với danh sách phân loại tài sản phù hợp yêu cầu Thông tin bao gồm Tên loại tài sản, Mã loại tài sản, Đơn vị, Mô tả, cùng với các hành động như nút Xem và nút Xóa.

- Director/Manager tìm với tên phân loại tài sản tương đối: hiển thị một hoặc nhiều phân loại tài sản

- Tìm với tên phân loại tài sản tuyệt đối: hiển thị duy nhất một phân loại tài sản

Luồng xử lý ngoại lệ:

- Nếu không có kết quả tìm kiếm dựa trên từ khóa đã nhập: Hệ thống hiển thị “No data”

Nếu ô tìm kiếm không có dữ liệu nhập, giao diện ban đầu vẫn sẽ được hiển thị với bảng và các trường thông tin liên quan đến phân loại tài sản.

Giao diện khi tìm kiếm thành công

Hình 16 Giao diện tìm kiếm Asset Type thành công

3.3.3 Phân tích use case Add Asset Type

3.3.3.1 Đặc tả yêu cầu cho use case “Add Asset Type”

Tác nhân: Director, Manager Điều kiện tiên quyết: Đăng nhập thành công vào hệ thống và có quyền truy cập vào chức năng Manage Asset Type

Trong bài viết này, chúng tôi mô tả một use case nhằm thêm phân loại tài sản vào hệ thống Mỗi phân loại sẽ được đặt tên và mô tả cụ thể, giúp dễ dàng gán cho các tài sản tương ứng Việc này không chỉ hỗ trợ phân nhóm mà còn nâng cao khả năng quản lý tài sản trong hệ thống.

Bước 1: Director/Manager click button Add ở màn hình Asset Type

Hình 17 Giao diện màn hình Asset Type

Bước 2: Hệ thống sẽ mở ra Pop up “Add new asset type”, tại đây Director, Manager sẽ nhập thông tin của phân loại tài sản bao gồm:

Tên trường Trường bắt buộc Mục đích

Director/Manager nhập tên cho phân loại tài sản

Director/Manager nhập mã cho phân loại tài sản

Format: Nhập chữ cái in hoa và viết liền kề, cho phép nhập ký tự số, kí tự đặc biệt Example: MAYVITINH_01

Rule: Sau khi lưu add phân loại tài sản thành công thì trường Code asset type sẽ bị fix cứng và không thể edit trường này

Director/Manager nhập đơn vị cho phân loại tài sản

Director/Manager nhập mô tả cho phân loại tài sản

Bảng 2 Các trường thông tin của Pop up “Add new asset type”,

Hình 18 Giao diện pop up Add new asset type

Bước 3: Giám đốc/Quản lý nhấn nút Lưu để lưu phân loại tài sản mới Hệ thống sẽ hiển thị thông báo "Tạo phân loại tài sản thành công!" và trở về màn hình Phân loại Tài sản, nơi phân loại tài sản mới sẽ được hiển thị trong danh sách.

Hình 19 Giao diện thêm phân loại tài sản mới thành công

Luồng xử lý ngoại lệ:

- Nếu Director/Manager để trống các trường bắt buộc: Hệ thống hiển thị các error message với mỗi trường tương ứng:

Name asset type Name is invalid Code asset type Code asset type is a required field

Bảng 3 Error message khi để trống các trường trong pop up “Add asset type”

If a Director or Manager enters any numeric or special character in the Name, Asset Type, Unit, or Description fields and clicks the Save button, the system will display an error message: "This field must contain only alphabetic characters." The cursor will also focus on the specific required field that contains the error.

Nếu Giám đốc/Quản lý nhập trường Tên loại tài sản và Mã loại tài sản trùng với một Tên loại tài sản hoặc Mã loại tài sản đã có trong danh sách phân loại tài sản, hệ thống sẽ thông báo “Tên loại tài sản này đã tồn tại” và “Mã loại tài sản này đã tồn tại”, do đó không lưu thành công vào hệ thống.

- Nếu Director/Manager click button Cancel thì hệ thống quay lại màn hình Asset Type và không lưu phân loại tài sản vào hệ thống

3.3.4 Phân tích use case View Asset Type

3.3.4.1 Đặc tả yêu cầu cho use case “View Asset Type”

Để thực hiện chức năng Quản lý loại tài sản, người dùng cần là Giám đốc hoặc Quản lý, đã đăng nhập thành công vào hệ thống và có quyền truy cập Hệ thống yêu cầu ít nhất một phân loại tài sản đã tồn tại.

Mô tả khái quát: Use case này nhằm cung cấp thông tin chi tiết về phân loại tài sản, giúp Giám đốc và Quản lý hiểu rõ hơn về phân loại tài sản cụ thể Điều này hỗ trợ họ trong việc ra quyết định, quản lý và theo dõi các hoạt động liên quan đến phân loại tài sản một cách chính xác và hiệu quả.

Bước 1: Director/Manager click button View tương ứng ở row của 1 phân loại tài sản bất kì

Hình 20 Giao diện màn hình Asset Type

Bước 2: Hệ thống hiển thị màn hình View asset type và fix cứng các trường thông tin đã nhập trước đó

Hình 21 Giao diện View asset type

Bước 3: Director/Manager click button Cancel Hệ thống quay lại màn hình Asset Type

When the Director or Manager clicks the Edit button, a pop-up window titled "Edit Asset Type" appears, allowing users to modify the information related to the asset category currently being viewed.

3.3.5 Phân tích use case Edit Asset Type

3.3.5.1 Đặc tả yêu cầu cho use case “Edit Asset Type”

Để thực hiện chức năng Quản lý Loại Tài Sản, người dùng cần là Giám đốc hoặc Quản lý và phải đăng nhập thành công vào hệ thống Ngoài ra, người dùng phải có quyền truy cập vào chức năng này và ít nhất một phân loại tài sản đã được tạo ra trước đó.

Mô tả khái quát: Use case này được thực hiện nhằm chỉnh sửa/cập nhật thông tin phân loại tài sản

Bước 1: Director/Manager click button View tương ứng ở row của 1 phân loại tài sản bất kì

Bước 2: Director/Manager click button Edit

Bước 3: Hệ thống hiển thị pop-up thông tin phân loại tài sản đã thêm, cho phép người dùng chỉnh sửa các trường như Tên loại tài sản, Đơn vị, Mô tả, trong khi trường Mã loại tài sản sẽ được cố định.

Hình 22 Giao diện màn hình Edit asset type

Step 4: The Director/Manager edits the asset classification information and clicks the Save button The system then displays the message “Update asset type success!” confirming that the recently edited asset classification information has been saved.

Hình 23 Giao diện edit asset type thành công

Luồng xử lý ngoại lệ:

- Nếu Director/Manager để trống các trường bắt buộc: Hệ thống hiển thị các error message với mỗi trường tương ứng:

Name asset type Name is invalid

Bảng 4 Error message khi để trống các trường trong Edit asset type

If a Director or Manager enters mandatory fields such as Name, Asset Type, Unit, and Description with only numeric or special characters and clicks the Save button, the system will display an error message: “This field must not contain only numeric characters or special characters,” and the cursor will focus on the specific mandatory field in question.

- Nếu Director/Manager không thực hiện edit thông tin và click button Save thì hệ thống quay lại màn hình Asset Type

- Nếu Director/Manager click button Cancel thì hệ thống quay lại màn hình Asset Type và không lưu thông tin vừa mới edit của phân loại tài sản

3.3.6 Phân tích use case Delete Asset Type

3.3.6.1 Đặc tả yêu cầu cho use case “Delete Asset Type”

Phân tích use case Manage Asset List

3.4.1 Sơ đồ use case tổng quát cho chức năng Manage Asset List

Hình 27 Use case tổng quát Manage Asset List Use case “Manage Asset List” gồm các use case:

3.4.2 Phân tích use case Search Asset List

3.4.2.1 Đặc tả yêu cầu cho use case “Search Asset List”

Để thực hiện chức năng quản lý danh sách tài sản, người dùng cần đăng nhập thành công vào hệ thống và có quyền truy cập Điều kiện tiên quyết là phải có ít nhất một loại tài sản đã tồn tại trong hệ thống.

Mục đích của use case này là tìm kiếm tài sản thông qua hộp tìm kiếm hoặc sử dụng các bộ lọc để kiểm tra thông tin liên quan đến tài sản.

Bước 1: Director/Manager click tab Asset list Hệ thống hiển thị màn hình Asset list

Bước 2: Director/Manager nhập tên tài sản cần tìm kiếm vào search box và bấm phím

Step 3: The search results are displayed to the user on the interface, showcasing a list of assets that meet the user's criteria Each entry includes essential details such as the ordinal number, ID, asset name, asset code, base office, original value, depreciation start date, purchase date, creation date, status, and action buttons for viewing, printing, and deleting.

Hình 28 Giao diện tìm kiếm tài sản thành công

Luồng xử lý ngoại lệ:

- Nếu không có kết quả tìm kiếm dựa trên từ khóa đã nhập: Hệ thống hiển thị “No data”

- Nếu search box không có data nhập vào thì vẫn hiển thị giao diện ban đầu với bảng và các trường thông tin liên quan đến tài sản

Luồng sự kiện bổ sung:

Directors and managers can search for assets by selecting the status and type of the asset from the dropdown menus, which include options such as Available, In Use, and Under Repair Additionally, they can filter the results by Asset Type or display options based on Asset Name or Recipient Name.

- Có thể kết hợp tất cả điều kiện để có kết quả tìm kiếm tốt hơn

Giao diện khi tìm kiếm tài sản thành công bằng combobox

Hình 29 Giao diện tìm kiếm tài sản thành công bằng combobox

3.4.3 Phân tích use case Add Asset List

3.4.3.1 Đặc tả yêu cầu cho use case “Add Asset List”

Tác nhân: Director, Manager Điều kiện tiên quyết: Đăng nhập thành công vào hệ thống và có quyền truy cập vào chức năng Manage Asset List

Mô tả khái quát: Use case này được thực hiện nhằm thêm một tài sản vào hệ thống

Bước 1: Director/Manager click button Add ở màn hình Asset List

Hình 30 Giao diện màn hình Asset List

Bước 2: Hệ thống sẽ mở ra màn hình“Add asset”, tại đây Director, Manager sẽ nhập thông tin của tài sản bao gồm:

Tên trường Trường bắt buộc

Director/Manager click chọn phân loại tài sản đã tạo sẵn/có sẵn ở tab Asset type để gán phân loại tài sản cho tài sản

Director/Manager nhập ngày mua tài sản theo format DD/MM/YYYY hoặc click icon calendar để chọn ngày mua

Trường này được fix cứng không thể nhập liệu

Rule: Sau khi Director/Manager lưu add tài sản thành công thì trường trường Code asset list sẽ tự tạo theo format: Name asset list_number và fix cứng

Director/Manager kích chọn combobox để chọn các value (Be purchased/Be gifted)

Director/Manager kích chọn combobox để chọn các value (Da Nang Office/ Ha Noi Head Office)

Director/Manager nhập tên tài sản

Director/Manager nhập số lượng tài sản

Trường này bị fix cứng, không thể nhập liệu

Rule: Khi Director/Manager lưu add tài sản thành công thì trường

Unit sẽ tự động lấy đơn vị được gán theo Name asset type đã chọn theo Quản lý phân loại tài sản

Director/Manager kích chọn combobox để chọn người quản lý tài sản

Rule: Không thể edit trường Người quản lý tài sản khi tài sản này đã có bàn giao cho người khác ở màn Thông tin bàn giao

Trường này bị fix cứng, không thể nhập liệu/chỉnh sửa

Hiển thị cứng “Assign for management”

Director/Manager nhập ngày chiết khấu tài sản theo format DD/MM/YYYY hoặc click icon calendar để chọn ngày

Trường này bị fix cứng, không thể nhập liệu

Rule: Khi Director/Manager lưu add tài sản thành công thì trường

Annual depreciation rate sẽ tự động được tính bằng (Original value/Depreciation time)

Director/Manager nhập nguyên giá cho tài sản

Cho phép nhập số năm tính thời gian trích khấu hao của tài sản theo công thức: X năm Trong đó X: là số tự nhiên

Trường này bị fix cứng, không thể nhập liệu

Rule: Khi Director/Manager lưu add tài sản thành công thì trường

Monthly depreciation rate sẽ tự động được tính bằng công thức: Original value/36

Year of manufacture Cho phép nhập năm sản xuất của tài sản

Cho phép nhập nhãn hiệu của tài sản

Cho phép nhập số seri của tài sản

Country of manufacture Cho phép nhập nước sản xuất tài sản

Cho phép nhập model của tài sản

Cho phép upload bill của tài sản chỉ dưới dạng file pdf

Bảng 5 Các trường thông tin trong màn hình Asset List

Hình 31 Giao diện màn hình Add asset

Hình 32 Giao diện màn hình Add asset

Bước 3: Director/Manager click button Save để lưu tài sản mới Hệ thống hiển thị

“Create asset success!”, và quay trở về màn hình Asset List Hiển thị tài sản mới tạo trong danh sách tài sản

Hình 33 Giao diện thêm tài sản mới thành công

Luồng xử lý ngoại lệ:

- Nếu Director/Manager để trống các trường bắt buộc: Hệ thống hiển thị các error message với mỗi trường tương ứng:

When managing asset information, it is essential to ensure that all fields are completed accurately The asset type must be specified, and it cannot be left empty Additionally, the purchase date is a critical detail that also requires completion It is important to note that the quantity of assets must be provided, as well as the original value, both of which cannot be left blank Furthermore, the assignment of the asset must be clearly indicated, and this field cannot remain empty Lastly, the bill is a mandatory field that must be filled out to ensure proper documentation.

Bảng 6 Error message khi để trống các trường trong màn hình Add asset list

If a Director or Manager enters any numeric or special character in the Name asset field and clicks the Save button, the system will display an error message: "This field must not contain only numeric characters or special characters," and the cursor will focus on the required field.

If a Director or Manager enters an Asset name that already exists in the asset list, the system will display a message stating, "This asset name exists," and the entry will not be successfully saved in the system.

If a Director or Manager enters a negative number, decimal, or zero in the fields for Quantity, Original Value, or Year of Manufacture, the system will display an error message stating, "Quantity/Original Value/Year of Manufacture must be a positive integer," and the data will not be successfully saved in the system.

If the Director or Manager inputs a Purchase date that is earlier than the Depreciation start date, the system will display an error message stating, “Purchase date must be greater than Depreciation start date,” and the data will not be successfully saved in the system.

- Nếu Director/Manager click button Cancel thì hệ thống quay lại màn hình Asset List và không lưu tài sản vào hệ thống

Do các phần phân tích và mô tả các use case còn lại rất dài và chiếm nhiều trang, em xin phép tóm tắt các mục này trong phần Mục lục Kính mong quý thầy/cô thông cảm và tham khảo chi tiết các mục ở phần Mục lục qua liên kết dưới đây.

3 Các mục bổ sung chương 3 phân tích thiết kế

TRIỂN KHAI THỰC NGHIỆM

Thiết kế Test plan

4.1.2.1 Phạm vi kiểm thử của Asset Management

US 1 Là 1 manager, tôi muốn có một chức năng quản lý tài sản trong HRM để tôi có thể chủ động quản lý 1 cách hiệu quả và theo dõi các tài sản trong công ty

US 2 Là 1 manager, tôi muốn có 1 nơi thêm mới các tài sản của công ty để tiện theo dõi và quản lý phân bổ đúng nguồn lực

US 3 Là 1 manager, tôi muốn có chức năng tạo và in barcode tương ứng với từng tài sản

US 4 Là 1 manager, tôi muốn có chức năng quét barcode được dán trên từng tài sản để nhân viên có thể xem và kiểm tra thông tin chi tiết của tài sản mà họ đang sử dụng

Bảng 7 User story của Asset management

Màn hình Director Manager Leader Member

Danh sách phân loại tài sản ✔ ✔ x x

Thông tin phân loại tài sản ✔ ✔ x x

Khi người dùng quét mã QR, thông tin chi tiết về tài sản chỉ được hiển thị nếu tài sản đó đã được phân bổ cho người dùng đó.

Danh sách bàn giao tài sản ✔ ✔

Thông tin bàn giao tài sản ✔ ✔ (Chỉ hiển thị trang thông tin bàn giao tài sản nếu tài sản đó được phân bổ cho chính người dùng đó )

Bảng 8 Phân quyền trong Asset management

4.1.2.2 Phạm vi kiểm thử của Resource Management a) User story

US 1 Là 1 manager, tôi muốn có chức năng quản lý dự án để quản lý và phân bổ hiệu quả các nguồn lực cho các dự án khác nhau và đảm bảo sử dụng hiệu quả các nguồn lực

US 2 Là 1 manager, tôi muốn có thể tạo mới các dự án mà công ty sắp, đã và đang thực hiện để có cái nhìn tổng quan và theo dõi 1 cách hợp lí

US 3 Là 1 manager, tôi muốn có khả năng chỉ định các nguồn lực cụ thể cho các dự án hoặc nhiệm vụ để đảm bảo mỗi dự án hoặc nhiệm vụ đều có các nguồn lực cần thiết được phân bổ

US 4 Là 1 manager, tôi muốn có 1 nơi để nhập và xem effort của từng nhân viên và dự án mà họ được phân công để ước tính và đảm bảo được tiến độ và năng suất làm việc của nhân viên

Bảng 9 User story của Resource management b) Phân quyền

Màn hình Director Manager Leader Member

Bảng 10 Phân quyền trong Resource management

4.1.2.3 Phạm vi kiểm thử của Skill Management

Là 1 manager, tôi muốn có một phân hệ quản lý kỹ năng để theo dõi và quản lý thông tin về kỹ năng của từng nhân viên Điều này giúp tôi xác định các kỹ năng hiện có, đánh giá sự phát triển của nhân viên và quản lý nguồn nhân lực một cách hiệu quả

Milestones Deliverables Duration Start date End date

Xem lại các tài liệu

Lập kế hoạch kiểm thử

Tài liệu Test Plan 3 ngày 27/06/2023 29/06/2023

Bảng 11 Lịch trình công việc

4.1.4 Yêu cầu về tài nguyên

Máy tính cá nhân có kết nối mạng Internet

Đặng Thị Ánh Hồng, với vai trò Test Manager/Tester, đảm nhiệm việc xem xét kế hoạch kiểm thử, quản lý tiến độ hoạt động kiểm thử, và thực hiện việc review các test case Bên cạnh đó, cô còn thiết kế các test case bổ sung, thực thi chúng, ghi nhận lỗi và đánh giá kết quả kiểm thử.

Xem lại các Test case

Skill Management: upcoming… Ghi nhận và đánh giá kết quả kiểm thử

Skill Management: upcoming… Update document và update lại Test case (nếu có)

Phan Thị Thùy Linh là một Intern Tester, đảm nhiệm việc thiết kế kế hoạch kiểm thử, xây dựng và viết các test case, thực hiện các test case, ghi lại lỗi và đánh giá kết quả kiểm thử, cũng như cập nhật lại test case khi cần thiết.

Bảng 12 Phân bổ nhân sự Test

Các loại kiểm thử được sử dụng:

Chiến lược kiểm thử chức năng và giao diện

- Mục đích: đảm bảo các chức năng và giao diện được thực hiện đúng theo SRS Document

Kỹ thuật kiểm thử bao gồm việc thực hiện tất cả các test case có thể cho từng chức năng và giao diện, bao gồm các control và component Quá trình này sử dụng cả dữ liệu hợp lệ và không hợp lệ để đảm bảo kiểm tra đầy đủ, từ các trường hợp test thất bại đến các trường hợp test thành công.

Tất cả các test case đã được thiết kế và thực hiện đầy đủ, đảm bảo tiêu chuẩn dừng Mỗi lỗi phát hiện đều có lý do rõ ràng, giúp các lập trình viên dễ dàng khắc phục.

- Chịu trách nhiệm kiểm thử: Test Manager/Tester

- Cách kiểm thử: thực hiện bằng tay và làm từng bước như trong test case đã viết

- Xử lý ngoại lệ: liệt kê các vấn đề phát sinh trong quá trình viết và thực thi test case

- Tiêu chuẩn chấp nhận: Pass tất cả các test case đã viết và thiết kế

4.1.7 Quy trình xử lý lỗi

Khi phát hiện lỗi trong quá trình thực thi test case, hãy ghi chú trong test case và tạo báo cáo lỗi trên không gian làm việc Gán lỗi cho lập trình viên để sửa chữa Tiếp tục theo dõi và thực hiện lại các test case liên quan để cập nhật trạng thái của lỗi Lỗi sẽ được đóng khi tất cả các test case liên quan đều đã được thông qua.

Phân tích kiểm thử (Test Analysis)

(đã thực hiện phân tích kiểm thử ở Chương 3 Phân tích thiết kế hệ thống)

Thiết kế kiểm thử (Test design)

Áp dụng các kỹ thuật thiết kế trường hợp kiểm thử được trình bày trong mục 2.6 của chương 2 về Cơ sở lý thuyết, bao gồm các phương pháp viết Test case hiệu quả.

Test Implement

- Công cụ hỗ trợ: Excel 2016, Google Sheet, Template Test case

- Các mục bắt buộc phải có trong Test case:

+ Test Description: Mô tả ngắn nhất flow test ở PCL này

Mỗi vùng trong TC_ID đại diện cho một phần kiểm thử khác nhau, chẳng hạn như giao diện hoặc chức năng Mô tả test case cung cấp tóm tắt về mục đích của việc kiểm thử, giúp xác định những gì sẽ được kiểm tra Để thực hiện test case, cần có các điều kiện tiên quyết nhất định.

+ Test case procedure: Mô tả step by step

+ Expected output: Từng output tương ứng với từng input của step

+ Test result: Pass/Fail/Untest/N/A

+ Reference: Nếu có EVD thì refer tới tài liệu EVD

+ Tester: Điền tên người thực hiện test

+ Test Date: Điền ngày thực hiện test

Hình 34 Một template tescase mẫu

4.4.2 Set up môi trường Test

Máy tính cá nhân có kết nối mạng Internet để truy cập vào trang web bằng trình duyệt Hệ điều hành sử dụng là Microsoft Windows 7

Input là 50 ký tự viết in hoa có chứa khoảng trắng

Input là 100 ký tự viết thường có chứa khoảng trắng qwertyuiopqwertyuiopqwertyuiopqwertyuiopqwertyuiopqw ertyuiopqwertyuiopqwertyuiopqwertyuiopqwertyuiop

Input là kí tự đặc biệt @@

Input là ký tự số nguyên 9999999

Input là ký tự số thập phân 9999.999

Input là ký tự số âm -9999

Bảng 13 Một số data test đặc trưng

Trước khi create PCL bất kỳ:

+ Phải CLEAR requirement, clear checklist UT (nếu có)

- Những lưu ý khi thực hiện create PCL:

+ Format phải thống nhất với nhau, thống nhất font chữ, cỡ chữ, chữ hoa chữ thường + Các mục Refer sheet phải đúng

+ Nếu là testcase ma trận thì 1 line viết ra phải có maru, Test RESULT phải đánh đầy đủ, đúng, Content công thức phải đúng

- Những lưu ý khi thực hiện Execute UT:

+ Đọc kĩ nội dung Testcase

+ Thực hiện Run Test step by step: (Input là gì, Điều kiện là gì, Output là gì)

+ Khi test phải chứng minh hết được từng chữ ghi trong Testcase

+ Điền Test Result đầy đủ (OK/NG/Pending, Người test, Ngày Test, Ghi chú, v.v )

- Những lưu ý khi thực hiện get EVD:

+ Khi get EVD phải chứng minh hết được từng chữ ghi trong Testcase

+ Các EVD phải gần như thống nhất 1 size ảnh Đặt EVD là 1 hàng dọc thẳng hàng

+ Check permission, Check giao diện

+ Check hiển thị (Dropdown, checkbox, radio button )

+ Check mặc định, check giá trị trong DDL

+ Check error - Trái sang phải - Từ trên xuống dưới

+ Check từng item thì sẽ theo thứ tự trong DD hoặc check bắt buộc, duy nhất, maxlength (Cận biên dưới, biên, cận biên trên), v.v

+ Check button (check abnormal trước, normal sau) - Trái sang phải - Từ trên xuống dưới

Trong một số trường hợp, việc thực hiện button A là bắt buộc trước khi có thể tiến hành button B Do đó, thứ tự sắp xếp sẽ phụ thuộc vào điều kiện ưu tiên của button, thay vì tuân theo thứ tự từ trái sang phải hay từ trên xuống dưới Cuối cùng, hãy kiểm tra khóa độc quyền để đảm bảo tính chính xác.

Thiết kế và thực thi Test case cho hệ thống

Hình ảnh của một vài test case đặc trưng cho Asset Management, Resource Management, Skill Management trong quá trình thực tập

Hình 35 Một vài test case GUI cho màn hình Danh sách phân loại tài sản (Asset

Hình 36 Một vài test case Function cho màn hình Danh sách phân loại tài sản (Asset

Hình 37 Một vài test case GUI cho màn hình Overview of projects + Tab Project list

Hình 38 Một vài test case Function cho màn hình Overview of projects + Tab Project list

Hình 39 Một vài test case GUI cho màn hình Role Category (Skill Management)

Hình 40 Một vài test case Function cho màn hình Role Category (Skill Management)

Trên đây báo cáo chỉ trình bày các Test case đặc trưng Asset Management, Resource

Management, Skill Management, dưới đây sẽ là bảng tổng kết thực tế số lượng test case của các chức năng em đã thực hiện trong kỳ thực tập:

Chức năng Total case Passed Failed

Bảng 14 Tổng kết thực tế số lượng test case của các chức năng thực hiện trong kỳ thực tập

Trong quá trình thiết kế và viết test case, file BA thường xuyên được cập nhật, dẫn đến việc danh sách test case có thể gặp nhiều thiếu sót Chúng tôi mong Quý Thầy/Cô thông cảm về điều này.

Link test case chi tiết:

Test case Asset Management: https://docs.google.com/spreadsheets/d/13B9WW-lIQDnG5Tkj_65FamgHZIpqho- S/edit?usp=sharing&ouid3196010917176429226&rtpof=true&sd=true

Test case Resource Management: https://docs.google.com/spreadsheets/d/1SBtGcj1gePLig2mIXWm7wyrBRFtxNPY8/e dit?usp=sharing&ouid3196010917176429226&rtpof=true&sd=true

Test case Skill Management: https://docs.google.com/spreadsheets/d/1PhKXYCMdg5BNC7NXaNJAa1MlXiium2K5/edit?usp=sharing&ouid3196010917176429226&rtpof=true&sd=true

Công cụ hỗ trợ log bug

JetBrains Space là nền tảng hợp tác tích hợp dành cho phát triển phần mềm, cung cấp môi trường làm việc toàn diện cho các nhóm Nền tảng này giúp quản lý dự án, tăng cường hợp tác, theo dõi tiến độ và thảo luận hiệu quả.

Hình 41 Nền tảng JetBrains Space

4.6.2 Thực hiện log bug trên JetBrains Space

● Bước 1: Tạo Bug Report: Khi phát hiện lỗi hoặc vấn đề trong phần mềm, tạo một bug report trên JetBrains Space thông qua "Issue Boards"

Trong báo cáo lỗi, hãy cung cấp thông tin chi tiết và rõ ràng về vấn đề gặp phải Điều này bao gồm các bước cần thiết để tái hiện lỗi, thông tin về phiên bản phần mềm và hệ điều hành, cùng với bất kỳ thông tin gỡ rối nào có sẵn.

Sau khi tạo báo cáo lỗi, bước tiếp theo là gán công việc cho đội ngũ phát triển để xử lý Việc đánh giá mức độ ưu tiên của lỗi giúp xác định những công việc quan trọng cần được hoàn thành trước, đảm bảo quy trình phát triển diễn ra hiệu quả.

● Bước 4: Theo dõi Tiến độ: Theo dõi tiến độ giải quyết bug và đảm bảo rằng công việc được thực hiện đúng hạn

Bước 5: Thảo luận và Tương tác là rất quan trọng; nếu cần, hãy trao đổi với các thành viên trong nhóm hoặc người sửa lỗi để nắm bắt rõ hơn về vấn đề và đưa ra các giải pháp thích hợp.

Bước 6: Kiểm tra và Xác nhận là giai đoạn quan trọng sau khi đã giải quyết bug Hãy tiến hành kiểm tra lại để đảm bảo vấn đề đã được khắc phục hoàn toàn Xác nhận rằng bug đã được đóng và không còn ảnh hưởng đến phần mềm nữa.

Hình 42 Minh họa Log bug trên JetBrains Space

Kết quả

4.7.1 Log bugs hệ thống và một vài minh chứng tại một số màn hình đã log

Hình 43 Log bug màn hình [Asset Type]

- Màn hình [Add asset type]

Hình 44 Log bug màn hình [Add asset type]

Hình 45 Log bug Màn hình [Asset List]

Hình 46 Log bug Màn hình [Add asset]

- Màn hình [Thông tin QR code]

Hình 47 Log bug Màn hình [Thông tin QR code]

- Màn hình [Quét QR code]

Hình 48 Log bug Màn hình [Quét QR code]

Trên đây là một số hình đặc trưng minh họa cho kết quả log bug cho các màn

Danh sách phân loại tài sản và thông tin chi tiết về tài sản sẽ được cung cấp, bao gồm việc quét mã QR để truy cập nhanh Một số hình ảnh minh họa cho kết quả log bug của các màn còn lại sẽ được đính kèm trong phần phụ lục theo liên kết: 4 Các mục bổ sung chương 4 triển khai thực nghiệm.

Link log bug chi tiết: https://docs.google.com/spreadsheets/d/1kIou6AU1IadJM7cA83Ab6lY7nBToxdP5Pnt9 wpyELgI/edit?usp=sharing

KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN

Sau 2 tháng thực tập dưới sự hướng dẫn của cô Cao Thị Nhâm, giảng viên khoa Thống kê – Tin học tại Trường Đại học Kinh tế - Đại học Đà Nẵng, cùng với sự hỗ trợ từ chị Đặng Thị Ánh Hồng và các thành viên trong team BA, DEV tại công ty Var Meta, em đã hoàn thành nhiệm vụ và đạt được mục tiêu đề ra Đề tài thực tập không chỉ mang lại cho em những trải nghiệm quý báu về vị trí thực tập mà còn giúp em hiểu rõ hơn về quy trình kiểm thử phần mềm Đây là cơ hội tuyệt vời để em có cái nhìn thực tế về ngành nghề và định hướng sự nghiệp trong tương lai Qua quá trình thực tập, em đã tiếp thu được nhiều kiến thức và rút ra những kinh nghiệm quý giá.

- Hòa nhập và thích ứng với môi trường làm việc mới

- Thực hành kiểm thử dự án, nắm vững các kiến thức nền tảng về Manual Testing và quy trình khi thực hiện kiểm thử một hệ thống

- Nâng cao khả năng chịu áp lực với cường độ công việc cao khi thực tập tại công ty

- Hoàn thiện bản thân và có định hướng rõ ràng hơn trong công việc sau này của bản thân

- Kỹ năng giao tiếp, ứng xử và làm việc nhóm chưa được cải thiện nhiều

- Kỹ năng chuyên môn trong việc thiết kế và viết test case vẫn còn nhiều thiếu sót

Qua kỳ thực tập hè, tôi đã nhận thức rõ hơn về quy trình và vai trò quan trọng của việc kiểm thử sản phẩm, đồng thời có những trải nghiệm đầu tiên cho con đường nghề nghiệp tương lai của mình.

Để thực hiện dự án kiểm thử một cách hiệu quả và tối ưu, cần chủ động học hỏi và trang bị kiến thức chuyên sâu Luôn sẵn sàng tiếp thu từ những người đi trước về kỹ năng và kiến thức liên quan Tập trung vào việc nâng cao kỹ năng sử dụng các công cụ hỗ trợ cho công việc tương lai Đồng thời, nên bắt đầu tìm hiểu và phát triển kiến thức về vị trí Automation Tester.

Ngày đăng: 12/12/2023, 19:43

TÀI LIỆU CÙNG NGƯỜI DÙNG

TÀI LIỆU LIÊN QUAN

w