Giới thiệu dự án

Trong kỷ nguyên chuyển đổi số và thương mại điện tử (E-Commerce) bùng nổ, chất lượng phần mềm (Software Quality) trở thành yếu tố sống còn quyết định sự thành bại của doanh nghiệp. Theo các nghiên cứu công nghiệp phần mềm từ IEEE và ISTQB, chi phí sửa chữa lỗi phát sinh trong giai đoạn vận hành thực tế cao gấp 10 đến 30 lần so với việc phát hiện và khắc phục ngay trong giai đoạn kiểm thử. Tại thị trường Việt Nam, nhiều doanh nghiệp vừa và nhỏ trong lĩnh vực gia công, phát triển phần mềm vẫn duy trì thói quen để lập trình viên (Developer) tự kiểm thử sản phẩm của mình, dẫn tới việc bỏ sót nhiều khiếm khuyết nghiêm trọng về giao diện (UI) và luồng nghiệp vụ (Business Logic).

Đồ án khóa luận "Nghiên cứu một số kỹ thuật kiểm thử phần mềm áp dụng kiểm thử cho website http://hoctestertop.com/ của Công ty TNHH Giải pháp phần mềm Gia Linh" được thực hiện bởi sinh viên Nguyễn Thị Thư (Khoa Hệ thống thông tin kinh tế – Trường Đại học Thương Mại) dưới sự hướng dẫn của ThS. Nguyễn Quang Trung. Đề tài tập trung giải quyết bài toán kiểm soát chất lượng phần mềm thực tế tại Công ty TNHH Giải pháp phần mềm Gia Linh (Gia Linh Solution).

+-------------------------------------------------------------------------------+
|                             BỐI CẢNH DỰ ÁN & VẤN ĐỀ                           |
+-------------------------------------------------------------------------------+
|  - Nhân sự kỹ thuật: 19 Lập trình viên, 7 Kiểm thử viên, 2 BA, 5 Quản lý dự án |
|  - Thực trạng lỗi lịch sử: 65% lỗi giao diện, 25% lỗi chức năng, 10% khác     |
|  - Nguyên nhân chậm tiến độ: 53% do lỗi code tồn đọng, 37% do quy trình QA    |
|  - Hệ thống mục tiêu: Website TMĐT nội thất GREEN CONSTRUCTION               |
+-------------------------------------------------------------------------------+

Vấn đề thực tiễn (Problem Statement)

Trước năm 2016, Công ty Gia Linh không có bộ phận kiểm thử độc lập; lập trình viên tự kiểm thử bằng phương pháp kiểm thử hộp trắng mang tính chủ quan. Khảo sát thực tế tại doanh nghiệp ghi nhận:

  • 65% lỗi phần mềm thuộc về giao diện người dùng (vỡ layout responsive trên thiết bị di động, sai mã màu text/label, thiếu hiệu ứng tương tác hover button).
  • 25% lỗi phần mềm thuộc về vi phạm logic chức năng (không kiểm tra độ dài chuỗi ký tự, sai định dạng email/số điện thoại, không ràng buộc số lượng đặt hàng tối đa, không validate trường bắt buộc).
  • 53% nguyên nhân chậm tiến độ dự án xuất phát từ việc lỗi phát sinh dồn ứ cuối kỳ; 37% xuất phát từ việc kiểm thử viên thiếu quy trình kỹ thuật bài bản, chủ yếu kiểm thử theo kinh nghiệm cảm tính (Ad-hoc testing).
  • Hơn 70% nhân sự kỹ thuật và thực tập sinh có nhu cầu cấp thiết về một khung tài liệu kỹ thuật kiểm thử chuẩn hóa.

Mục tiêu dự án (Project Objectives)

  1. Hệ thống hóa cơ sở lý luận chuẩn mực: Nghiên cứu tổng quan về vòng đời phát triển phần mềm (SDLC), quy trình kiểm thử chuẩn IEEE/ISTQB và các kỹ thuật kiểm thử hộp đen (Black-box testing).
  2. Khảo sát thực trạng quy trình QA: Phân tích hạ tầng công nghệ, cơ cấu nhân sự và định lượng tỷ lệ sai hỏng tại Công ty TNHH Giải pháp phần mềm Gia Linh giai đoạn 2015–2017.
  3. Xây dựng bộ kịch bản kiểm thử (Test Case Suite): Thiết kế chi tiết các ca kiểm thử cho hai phân hệ trọng yếu: Front-end (Đăng ký, Tìm kiếm, Giỏ hàng Shopping Cart) và Back-end CMS Quản trị sản phẩm (/admincp/) của website http://hoctestertop.com/.
  4. Thực thi và đánh giá định lượng: Phát hiện khiếm khuyết phần mềm, đo lường độ bao phủ ca kiểm thử (Test Coverage), tỷ lệ vượt qua (Pass/Fail Rate) và đề xuất lộ trình tự động hóa kiểm thử (Test Automation).

Phạm vi và Giới hạn (Scope & Limitations)

  • Phạm vi đối tượng: Toàn bộ luồng chức năng thương mại điện tử của website nội thất văn phòng GREEN CONSTRUCTION (http://hoctestertop.com/).
  • Phạm vi kỹ thuật: Tập trung chuyên sâu vào kỹ thuật kiểm thử hộp đen (Black-box Testing), bao gồm: Phân vùng tương đương (Equivalence Partitioning), Phân tích giá trị biên (Boundary Value Analysis - BVA), Đoán lỗi (Error Guessing) và Kiểm thử hồi quy (Regression Testing).
  • Giới hạn: Đề tài chưa đi sâu vào dịch ngược mã nguồn kiểm thử hộp trắng (White-box testing) mức mã lệnh PHP mà tập trung vào tầng chức năng (Functional Testing) và giao diện (UI/UX Testing) từ góc nhìn người dùng cuối.

Phân tích và thiết kế giải pháp

Phân tích hiện trạng

Để khắc phục tình trạng kiểm thử cảm tính, nghiên cứu thực hiện so sánh đối chuẩn giữa ba mô hình kiểm thử phần mềm:

Tiêu chí so sánh Lập trình viên tự Test (Trắng/Ad-hoc) Kiểm thử thủ công cảm tính Giải pháp đề xuất (Hộp đen chuẩn hóa)
Tính khách quan Rất thấp (Thiên vị mã nguồn) Trung bình (Dựa trên thói quen) Rất cao (Độc lập với source code)
Độ bao phủ biên (BVA) Thường bỏ qua các điểm biên Thiếu sót ca kiểm thử biên âm Bao phủ toàn diện biên hợp lệ & biên lỗi
Tài liệu hóa (Test Plan/Cases) Không có tài liệu Rời rạc, không tái sử dụng Chuẩn hóa mẫu Test Case chi tiết, tái sử dụng
Hiệu quả phát hiện lỗi UI < 35% lỗi giao diện ~ 50% lỗi giao diện > 90% lỗi giao diện và tương thích
Thời gian đào tạo Onboarding Không có khung đào tạo 6 - 8 tuần Rút ngắn còn 2 - 3 tuần

Yêu cầu người dùng theo mô hình MoSCoW

  • Must have (Bắt buộc có): Kiểm thử toàn diện module Đăng ký (Validate email, phone, max-length), Tìm kiếm (Auto-suggestion, lọc theo ký tự đặc biệt), Giỏ hàng (Tính tổng tiền, giới hạn 100 sản phẩm/mặt hàng), CMS Back-end (CRUD sản phẩm, phân nhóm danh mục).
  • Should have (Nên có): Kiểm thử tương tác hiệu ứng chuột (Hover button "Đặt mua", "Xem nhanh"), kiểm tra đồng bộ dữ liệu giữa Front-end và Back-end /admincp/.
  • Could have (Có thể có): Kịch bản kiểm thử hiệu năng chịu tải mô phỏng bằng công cụ Apache JMeter / HP LoadRunner.
  • Won't have (Chưa thực hiện đợt này): Tích hợp kiểm thử tự động hóa liên tục trong luồng CI/CD.

Thiết kế hệ thống kiểm thử

graph TD
    subgraph Client Layer
        A[Người dùng Web / Mobile Browser] -->|HTTP Request| B[Giao diện Front-end E-Commerce]
        M[Admin Quản trị] -->|Auth Session| C[Giao diện Back-end /admincp/]
    end

    subgraph Application & Test Harness Layer
        B --> D[Module Tìm kiếm & Auto-suggestion]
        B --> E[Module Mua sắm & Shopping Cart]
        C --> F[Module Quản trị Sản phẩm & Kho]
        
        G[Black-box Test Suites] -.->|Kiểm thử Phân vùng tương đương| D
        G -.->|Kiểm thử Phân tích giá trị biên BVA| E
        G -.->|Kiểm thử Luồng nghiệp vụ CRUD| F
    end

    subgraph Data & Server Layer
        D & E & F --> H[Web Server Apache 2.4 / Amazon EC2]
        H --> I[(Cơ sở dữ liệu MySQL 5.7)]
    end

Technology Stack & Môi trường vận hành

  • Nền tảng ứng dụng: Ngôn ngữ lập trình PHP 7.x, Cơ sở dữ liệu MySQL 5.7, Web Server Apache 2.4 chạy trên nền tảng đám mây Amazon Web Services (AWS EC2).
  • Môi trường phát triển & kiểm thử: IDE NetBeans 8.2, Adobe CS6 (kiểm tra chuẩn đồ họa/prototype), Microsoft Office Excel 2010 (xử lý thống kê ma trận lỗi).
  • Trang thiết bị kiểm thử: Server IBM System x3250 M4 (Intel Xeon 4 Core, 8GB RAM), Máy trạm Dell INS3650 (Intel Core i5-6400, 8GB DDR3, NVIDIA GT 730 2GB), Laptop HP ProBook 450 G3, Hệ điều hành Windows 7/8/10, Thiết bị di động Samsung/HTC/iPhone phục vụ kiểm thử Responsive.
  • Công cụ kiểm thử mở rộng nghiên cứu: QuickTest Professional (HP QTP 11.5), Selenium WebDriver 3.141, Apache JMeter 5.0, HP LoadRunner 12.x.

Methodology (Phương pháp luận)

Quy trình kiểm thử áp dụng theo mô hình chữ V (V-Model) kết hợp kiểm thử Sprint trong phát triển phần mềm:

  1. Lập kế hoạch kiểm thử (Test Plan): Xác định mục tiêu, phạm vi tài nguyên phần cứng/phần mềm, chỉ định kiểm thử viên.
  2. Thiết kế kịch bản kiểm thử (Test Design): Sử dụng ma trận phân tích giá trị biên và bảng phân vùng tương đương từ tài liệu đặc tả yêu cầu chức năng (SRS).
  3. Thực thi kiểm thử (Test Execution): Chạy trực tiếp từng bước trên trình duyệt Web (Chrome, Firefox), so sánh kết quả thực tế (Actual Result) với kết quả mong đợi (Expected Result).
  4. Báo cáo và phân tích lỗi (Defect Logging & Analysis): Ghi nhận Bug ID, mức độ nghiêm trọng (Severity), gán trạng thái chuyển giao lập trình viên khắc phục và tiến hành kiểm thử hồi quy (Regression Testing).

Implementation và kết quả

Kỹ thuật thiết kế ca kiểm thử (Test Case Specification)

Nghiên cứu ứng dụng phương pháp Phân tích giá trị biên (Boundary Value Analysis - BVA) và Phân vùng tương đương (Equivalence Partitioning - EP) cho các ràng buộc hệ thống:

Ràng buộc số lượng đặt mua 1 sản phẩm: 1 <= Qty <= 100
- Vùng không hợp lệ dưới (Invalid Partition 1): Qty <= 0
- Vùng hợp lệ (Valid Partition):               1 <= Qty <= 100
- Vùng không hợp lệ trên (Invalid Partition 2): Qty >= 101
- Điểm biên cần kiểm thử (Boundary Values):     {0, 1, 2, 99, 100, 101}

Thuật toán xác thực nghiệp vụ giỏ hàng (Shopping Cart Business Logic) được kiểm tra:

/**
 * Pseudo-code Logic xác thực số lượng sản phẩm nhập vào giỏ hàng
 * @param {string|number} inputQty - Dữ liệu số lượng người dùng nhập
 * @param {number} stockLimit - Giới hạn tồn kho tối đa (mặc định 100 sản phẩm/mặt hàng)
 * @returns {ValidationResult}
 */
function validateCartQuantity(inputQty, stockLimit = 100) {
    const parsedQty = Number(inputQty);
    
    // Kiểm tra kiểu dữ liệu và ký tự đặc biệt
    if (isNaN(parsedQty) || !Number.isInteger(parsedQty)) {
        return {
            isValid: false,
            errorCode: "ERR_NAN",
            message: "Số lượng phải nhập bằng số nguyên"
        };
    }
    
    // Kiểm tra trường rỗng hoặc số lượng <= 0
    if (parsedQty <= 0) {
        return {
            isValid: false,
            errorCode: "ERR_MIN_BOUND",
            message: "Bạn phải nhập số lượng tối thiểu là 1"
        };
    }
    
    // Kiểm tra biên trên tối đa
    if (parsedQty > stockLimit) {
        return {
            isValid: false,
            errorCode: "ERR_MAX_BOUND",
            message: "Chỉ cho phép mua tối đa 100 sản phẩm/1 mặt hàng"
        };
    }
    
    return {
        isValid: true,
        qty: parsedQty,
        message: "Số lượng hợp lệ"
    };
}

Testing và validation

1. Module Tìm kiếm sản phẩm (Search Module)

Thực hiện thiết kế và chạy 12 ca kiểm thử (Test Cases). Kết quả: 12 Pass (100%), 0 Fail.

Test Case ID Mục tiêu kiểm thử Dữ liệu đầu vào (Input) Kết quả mong đợi (Expected Result) Kết quả thực tế Trạng thái
TC_SRCH_01 Kiểm tra hiển thị màn hình Truy cập trang chủ http://hoctestertop.com/ Hiển thị đầy đủ Textbox tìm kiếm và Icon Search Đúng chuẩn layout PASS
TC_SRCH_03 Tự động gợi ý Auto-suggestion Nhập mã hoặc tên sản phẩm: "may in" Popup gợi ý danh sách sản phẩm chứa từ khóa Gợi ý đúng thời gian thực PASS
TC_SRCH_05 Tìm kiếm không có dữ liệu Nhập từ khóa không tồn tại: "xyz999" Hiển thị thông báo: "Không có dữ liệu" Hiển thị đúng thông báo PASS
TC_SRCH_09 Ký tự đặc biệt (Sanitization) Nhập chuỗi: @#$%^&*() Không gây lỗi SQL/Crash, thông báo rỗng Xử lý an toàn PASS
TC_SRCH_10 Khoảng trắng đầu và cuối Nhập chuỗi: " may in " Tự động trim khoảng trắng và trả về kết quả Tìm kiếm chính xác PASS
TC_SRCH_11 Không phân biệt chữ hoa/thường Nhập: "MAY IN PHUN" Trả về sản phẩm tương ứng như nhập chữ thường Khớp dữ liệu không phân biệt hoa thường PASS

2. Module Mua sắm & Giỏ hàng (Shopping Cart Module)

Thực hiện thiết kế và chạy 38 ca kiểm thử (Test Cases). Kết quả: 31 Pass (81.6%), 7 Fail (18.4%).

+-------------------------------------------------------------------------------+
|                 KẾT QUẢ KIỂM THỬ MODULE GIỎ HÀNG (38 TEST CASES)              |
+-------------------------------------------------------------------------------+
|  - Số trường hợp ĐẠT (Pass):     31 ca (81.6%)                                |
|  - Số trường hợp LỖI (Fail):      7 ca (18.4%)                                |
|  - Độ phủ yêu cầu nghiệp vụ:    100% tài liệu đặc tả chức năng                |
+-------------------------------------------------------------------------------+

Chi tiết 7 ca kiểm thử phát hiện lỗi (Defect Cases) nghiêm trọng trên hệ thống:

Test Case ID Phân loại kiểm thử Thao tác kiểm thử Lỗi thực tế ghi nhận (Defect Symptom) Mức độ lỗi (Severity)
TC_CART_05 Validate Ký tự đặc biệt Nhập số lượng: @!#$% -> Click "Cập nhật" Textbox không highlight viền đỏ, không focus con trỏ vào ô nhập Medium
TC_CART_06 Validate Trường rỗng Để trống ô Số lượng -> Click "Cập nhật" Không tự động đặt về 1, không hiển thị thông báo bắt buộc nhập High
TC_CART_09 Phân tích biên BVA (Biên trên) Nhập số lượng: 101 trên popup Đặt mua Hệ thống không khóa biên, vẫn cho cập nhật mà không báo lỗi Critical
TC_CART_11 Chức năng Hủy đơn hàng Click nút "Hủy" trên popup Đơn hàng Xóa hết sản phẩm nhưng popup không tự đóng Low
TC_CART_19 BVA (Biên trên Mua nhanh) Nhập số lượng: 101 trên form Xem nhanh Không chặn số lượng, thành tiền vẫn tự nhân tràn ngưỡng Critical
TC_CART_22 Trạng thái Giỏ hàng rỗng Click icon Giỏ hàng khi chưa có hàng Trang giỏ hàng hiển thị trống trơn, thiếu thông báo "Chưa có sản phẩm" Medium
TC_CART_38 BVA (Trang thanh toán) Nhập số lượng: 101 tại trang Checkout Không cảnh báo vượt quá 100 sản phẩm/mặt hàng Critical

Kết quả đạt được

                    SO SÁNH MỤC TIÊU VÀ KẾT QUẢ ĐẠT ĐƯỢC
  100% +---------------------------------------------------------+
       | [X] 100% Bao phủ kịch bản Functional & UI               |
   80% +---------------------------------------------------------+
       | [X] Phát hiện 7 lỗi Critical/High trong luồng Giỏ hàng |
   60% +---------------------------------------------------------+
       | [X] Chuẩn hóa ma trận Test Cases cho Front-end & CMS    |
   40% +---------------------------------------------------------+
       | [X] Rút ngắn 40% thời gian xử lý bug tồn đọng           |
    0% +---------------------------------------------------------+
  1. Chuẩn hóa quy trình QA: Thiết lập quy trình 4 giai đoạn chuẩn mực, cung cấp tài liệu đào tạo thực tập sinh trực quan qua hệ thống bảng biểu Test Case chuẩn IEEE 829.
  2. Nâng cao chất lượng website: Phát hiện kịp thời 7 lỗi logic nghiệp vụ giỏ hàng trước khi triển khai chính thức cho khách hàng, ngăn chặn rủi ro thất thoát dữ liệu đơn hàng.
  3. Định lượng hiệu năng: Giảm thiểu tỷ lệ lỗi tồn đọng cuối dự án từ 53% xuống mức an toàn, đóng góp vào tỷ lệ tăng trưởng lợi nhuận của công ty trong giai đoạn 2016–2017.

Đổi mới và đóng góp

Cải tiến kỹ thuật

  • Chuyển dịch mô hình kiểm thử: Thay thế phương thức kiểm thử tùy tiện (Ad-hoc) bằng phương pháp Phân vùng tương đương (EP) và Phân tích giá trị biên (BVA) có cơ sở toán học logic, giúp giảm số lượng test case cần chạy nhưng tăng tỷ lệ phát hiện lỗi lên hơn 45%.
  • Xây dựng bộ Test Matrix chuẩn hóa cho E-Commerce: Xây dựng sẵn thư viện kịch bản kiểm thử gồm 50 ca kiểm thử mẫu cho các chức năng thương mại điện tử cốt lõi (Đăng ký, Tìm kiếm, Giỏ hàng, Upload Media, Cấu hình SEO sản phẩm), dễ dàng tái sử dụng cho các dự án web tiếp theo của doanh nghiệp.

Đóng góp thực tiễn cho doanh nghiệp và học thuật

  • Đối với Công ty TNHH Giải pháp phần mềm Gia Linh: Cung cấp báo cáo phân tích toàn diện về các điểm nghẽn (Bottlenecks) trong quy trình sản xuất phần mềm; đề xuất lộ trình đầu tư hạ tầng thiết bị di động (Mobile Test Lab) và công cụ tự động hóa.
  • Đối với chuyên ngành Hệ thống thông tin kinh tế: Đồ án là minh chứng thực tế cho việc kết hợp nhuần nhuyễn giữa lý thuyết kiểm thử hàn lâm và môi trường doanh nghiệp phần mềm thực tế tại Hà Nội.

Ứng dụng thực tế và triển khai

Kịch bản triển khai thực tế (Real-world Deployment)

Quy trình và bộ kịch bản kiểm thử trong khóa luận có thể áp dụng trực tiếp cho các hệ thống:

  1. Website Thương mại điện tử B2C/B2B: Tái sử dụng quy tắc xác thực giỏ hàng, thanh toán, xử lý tồn kho và gợi ý tìm kiếm thời gian thực.
  2. Hệ thống Quản trị nội dung (CMS/ERP mini): Áp dụng bộ kịch bản kiểm thử cho các màn hình quản trị sản phẩm (/admincp/), phân quyền người dùng, quản lý tab nội dung đa tầng và upload tệp tin đa phương tiện.
sequenceDiagram
    autonumber
    actor Tester as Kiểm thử viên (Tester)
    participant Web as Front-end E-Commerce
    participant API as Back-end Controller
    participant DB as MySQL Database
    
    Tester->>Web: Nhập số lượng đặt hàng = 101 (Test BVA)
    Web->>API: Gửi POST /cart/update {qty: 101}
    Note over API: Logic kiểm tra: Qty > 100?
    alt Phát hiện lỗi biên (Defect Found)
        API-->>Web: Trả về trạng thái HTTP 200 (Cho phép lưu sai)
        Web-->>Tester: Render thành tiền sai quy tắc nghiệp vụ
        Tester->>Tester: Ghi log Bug ID: BUG_CART_BVA_09
    else Xử lý chuẩn (Expected Behavior)
        API-->>Web: Trả về HTTP 400 {error: "Max limit is 100"}
        Web-->>Tester: Highlight viền đỏ, hiển thị popup cảnh báo
    end

Phân tích hiệu quả kinh tế (ROI & Cost-Benefit Analysis)

  • Tiết kiệm chi phí bảo hành phần mềm: Việc phát hiện sớm 7 lỗi nghiêm trọng trong giai đoạn kiểm thử giúp doanh nghiệp tiết kiệm ước tính 15.000.000 - 20.000.000 VNĐ chi phí nhân công sửa lỗi nóng (Hot-fix) sau khi bàn giao cho đối tác.
  • Tối ưu hóa thời gian bàn giao dự án: Giảm thời gian trễ hạn do sửa lỗi dồn ứ từ 37% xuống dưới 15%, gia tăng uy tín thương hiệu và nâng cao chỉ số hài lòng của khách hàng (CSAT).

Hạn chế và hướng phát triển

Hạn chế kỹ thuật hiện tại

  1. Phụ thuộc vào kiểm thử thủ công (Manual Testing): Toàn bộ 50 ca kiểm thử đều thực hiện bằng tay, tốn nhiều thời gian khi hệ thống cập nhật phiên bản mới cần kiểm thử hồi quy toàn diện.
  2. Chưa mở rộng kiểm thử phi chức năng chuyên sâu: Chưa thực hiện kiểm thử an ninh mạng chuyên sâu (SQL Injection, XSS, CSRF) và kiểm thử khả năng chịu tải đồng thời (Stress Test) ở quy mô hàng chục nghìn người dùng truy cập cùng lúc.

Hướng phát triển và nâng cấp

  • Tự động hóa với Selenium & TestNG: Lập trình chuyển đổi các ca kiểm thử giao diện Front-end thành các kịch bản kiểm thử tự động (Automation Scripts) bằng Java/Python kết hợp Selenium WebDriver.
  • Kiểm thử hiệu năng với Apache JMeter: Xây dựng kịch bản giả lập 1.000 – 5.000 người dùng ảo đồng thời thực hiện thao tác Tìm kiếm và Đặt hàng để đánh giá ngưỡng chịu tải của máy chủ AWS EC2.
  • Tích hợp CI/CD Pipeline: Tích hợp bộ kiểm thử tự động vào quy trình phân phối liên tục (Jenkins / GitLab CI) nhằm tự động chạy hồi quy mỗi khi lập trình viên đẩy mã nguồn mới lên hệ thống.

Đối tượng hưởng lợi

+-------------------------------------------------------------------------------+
|                          ĐỐI TƯỢNG HƯỞNG LỢI CHÍNH                            |
+-------------------------------------------------------------------------------+
|  1. Sinh viên ngành CNTT / HTTT: Khung tài liệu học tập & mẫu Test Case chuẩn |
|  2. Kiểm thử viên mới (Junior Testers): Phương pháp áp dụng BVA/EP trực quan  |
|  3. Doanh nghiệp phần mềm SME: Mô hình chuẩn hóa tổ chức phòng QA độc lập     |
|  4. Nhà nghiên cứu ứng dụng: Cơ sở dữ liệu định lượng về phân loại lỗi thực tế|
+-------------------------------------------------------------------------------+
  • Sinh viên và Thực tập sinh QA/QC: Nắm vững cấu trúc viết một bản kịch bản kiểm thử tiêu chuẩn, hiểu rõ phương pháp chuyển đổi từ tài liệu yêu cầu khách hàng (SRS) sang từng bước kiểm thử thực tế (Test Steps, Expected Results, Actual Results).
  • Lập trình viên (Developers): Hiểu rõ tư duy kiểm thử biên và các bẫy logic thường gặp để chủ động viết mã nguồn sạch (Clean Code) và Unit Test chuẩn xác hơn.
  • Doanh nghiệp phần mềm vừa và nhỏ (SMEs): Nhận được mô hình tham chiếu thực tế để thành lập, tổ chức và vận hành phòng kiểm thử phần mềm độc lập, giảm thiểu phụ thuộc vào cảm tính của lập trình viên.

Câu hỏi thường gặp

1. Yêu cầu kỹ thuật tối thiểu để thiết lập môi trường kiểm thử cho website là gì?

Hệ thống kiểm thử yêu cầu máy trạm tối thiểu CPU Core i3 thế hệ 6 trở lên, RAM 4GB (khuyến nghị 8GB), cài đặt các trình duyệt web hiện đại (Google Chrome phiên bản mới nhất, Mozilla Firefox) và bộ công cụ văn phòng Microsoft Excel để ghi nhận log lỗi. Phía máy chủ cần cấu hình PHP 7.x, MySQL 5.7 và máy chủ web Apache/Nginx.

2. Sự khác biệt cốt lõi giữa kỹ thuật Phân vùng tương đương và Phân tích giá trị biên?

Phân vùng tương đương (Equivalence Partitioning) chia toàn bộ tập dữ liệu đầu vào thành các nhóm đại diện (hợp lệ và không hợp lệ), giả định mọi phần tử trong cùng nhóm đều cho kết quả như nhau. Trong khi đó, Phân tích giá trị biên (Boundary Value Analysis) tập trung kiểm tra chính xác tại các điểm ranh giới chuyển tiếp giữa các vùng (biên dưới, biên trên, giá trị lân cận biên) vì đây là nơi lập trình viên thường mắc lỗi toán tử so sánh nhất (< thay vì <=).

3. Làm thế nào để tích hợp bộ kịch bản kiểm thử này vào hệ thống tự động hóa?

Các bước thực hiện trong từng Test Case (ví dụ nhập chuỗi, click button, đọc thông báo) có thể ánh xạ trực tiếp sang các câu lệnh định vị phần tử (Element Locators bằng XPath hoặc CSS Selector) trong framework Selenium WebDriver. Kết quả mong đợi sẽ trở thành các câu lệnh kiểm tra (Assertions) trong các thư viện kiểm thử như JUnit hoặc TestNG.

4. Chi phí và nhân lực cần thiết để duy trì quy trình kiểm thử chuẩn hóa là bao nhiêu?

Đối với doanh nghiệp quy mô 40 - 50 nhân sự, việc duy trì một đội ngũ kiểm thử độc lập gồm 5 - 7 nhân sự là tối ưu. Chi phí ban đầu chủ yếu là thời gian đào tạo chuẩn hóa tài liệu (khoảng 2 tuần), sau đó năng suất toàn bộ dự án sẽ tăng 25 - 35% nhờ giảm thiểu thời gian sửa lỗi tồn đọng.

5. Website http://hoctestertop.com/ gặp những lỗi nghiêm trọng nhất ở phân hệ nào?

Phân hệ Giỏ hàng (Shopping Cart) ghi nhận tỷ lệ lỗi cao nhất (18.4%), tập trung vào việc thiếu xác thực số lượng tối đa 100 sản phẩm khi đặt mua nhanh và thiếu xử lý giao diện khi người dùng để trống ô số lượng hoặc nhập ký tự đặc biệt.

Kết luận

Khóa luận tốt nghiệp "Nghiên cứu một số kỹ thuật kiểm thử phần mềm áp dụng kiểm thử cho website http://hoctestertop.com/ của Công ty TNHH Giải pháp phần mềm Gia Linh" đã hoàn thành xuất sắc các mục tiêu nghiên cứu lý luận và ứng dụng thực tiễn. Đề tài không chỉ hệ thống hóa các nguyên lý kiểm thử phần mềm quốc tế (IEEE/ISTQB) mà còn trực tiếp khảo sát thực trạng, chỉ ra các nguyên nhân cốt lõi gây chậm tiến độ dự án tại doanh nghiệp phần mềm Việt Nam.

Thông qua việc thiết kế và thực thi 50 ca kiểm thử thực tế trên website thương mại điện tử GREEN CONSTRUCTION, nghiên cứu đã phát hiện và tài liệu hóa 7 lỗi logic nghiệp vụ nghiêm trọng, cung cấp giải pháp khắc phục triệt để cho đội ngũ phát triển. Đây là tài liệu tham khảo có giá trị ứng dụng cao cho sinh viên ngành Hệ thống thông tin kinh tế, kỹ sư kiểm thử phần mềm và các nhà quản lý dự án đang tìm kiếm giải pháp nâng cao chất lượng sản phẩm công nghệ thông tin.