Giới thiệu dự án

Trong kỷ nguyên chuyển đổi số và thương mại điện tử bùng nổ, chất lượng phần mềm là 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 nghệ phần mềm từ IEEE, chi phí khắc phục lỗi phần mềm trong giai đoạn vận hành thực tế cao gấp 10 đến 30 lần so với giai đoạn kiểm thử phát triển. Tại Việt Nam, nhiều doanh nghiệp gia công và phát triển phần mềm vừa và nhỏ đối mặt với thách thức lớn về kiểm soát chất lượng: thiếu quy trình đảm bảo chất lượng phần mềm (Software Quality Assurance - SQA) chuẩn hóa, phụ thuộc nhiều vào kiểm thử thủ công mang tính cảm tính.

Khóa luận tốt nghiệp chuyên ngành Hệ thống Thông tin Kinh tế tập trung giải quyết bài toán cấp thiết tại Công ty TNHH Giải pháp phần mềm Gia Linh (Gia Linh Solution). Trước năm 2016, công ty không có đội ngũ kiểm thử độc lập; lập trình viên trực tiếp kiểm thử (White-box Testing), dẫn đến việc đánh giá mang tính chủ quan. Số liệu khảo sát thực tế tại doanh nghiệp cho thấy: 65% lỗi phát sinh thuộc về giao diện (UI/Layout), 25% lỗi nghiệp vụ chức năng (Validation/Business Logic), và 37% sự cố chậm tiến độ dự án xuất phát từ sự thiếu chuẩn hóa trong khâu kiểm thử.

+-----------------------------------------------------------------------+
| Vấn đề cốt lõi tại Gia Linh Solution (2015 - 2017)                   |
| - Tỷ lệ lỗi giao diện người dùng: 65% (Vỡ layout, CSS, Responsive)    |
| - Tỷ lệ lỗi logic chức năng: 25% (Sai validation, tràn trường dữ liệu)|
| - Nguyên nhân gây trễ hạn dự án do kiểm thử thiếu bài bản: 37%        |
| - Tỷ lệ nhân sự kỹ thuật có nhu cầu chuẩn hóa kỹ thuật test: 74.1%   |
+-----------------------------------------------------------------------+

Mục tiêu dự án

  1. Hệ thống hóa cơ sở lý luận: Tổng hợp các nguyên lý kiểm thử theo tiêu chuẩn IEEE và ISTQB, phân tích chi tiết các kỹ thuật kiểm thử hộp đen (Black-box Testing) chuyên sâu: Phân vùng tương đương (Equivalence Partitioning - EP), Phân tích giá trị biên (Boundary Value Analysis - BVA), Bảng quyết định (Decision Table) và Đoán lỗi (Error Guessing).
  2. Khảo sát và đánh giá hiện trạng: Phân tích quy trình phát triển, cơ sở hạ tầng CNTT và năng lực nhân sự phòng kỹ thuật tại Gia Linh Solution.
  3. Thiết kế và thực thi kiểm thử thực chiến: Xây dựng bộ kịch bản kiểm thử (Test Cases) chi tiết cho hệ thống thương mại điện tử chuyên cung cấp nội thất văn phòng tại website http://hoctestertop.com/ (Green Construction).
  4. Đề xuất chiến lược cải tiến: Định hình lộ trình chuyển đổi quy trình kiểm thử thủ công sang tự động hóa (Automation Testing) với các công cụ chuyên dụng (Selenium, Apache JMeter).

Phương pháp tiếp cận và kết quả kỳ vọng

  • Phương pháp tiếp cận: Ứng dụng kỹ thuật kiểm thử hộp đen toàn diện kết hợp kiểm thử hồi quy (Regression Testing) và kiểm thử chấp nhận người dùng (Acceptance Testing).
  • Chỉ số đo lường kỳ vọng: Xây dựng tối thiểu 50 ca kiểm thử bao phủ 100% các luồng nghiệp vụ trọng yếu (Tìm kiếm sản phẩm, Giỏ hàng - Shopping Cart, Đặt hàng nhanh, Quản trị Back-end), xác định và ghi nhận 100% các lỗi nghiêm trọng (Critical/Major Bugs) trước khi bàn giao sản phẩm.
  • Phạm vi và giới hạn: Thực hiện kiểm thử chức năng và giao diện Front-end, Back-end trên môi trường Web Desktop và Mobile Responsive cho website hoctestertop.com; chưa triển khai tự động hóa toàn phần CI/CD.

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

Phân tích hiện trạng và đối sánh giải pháp

Trước khi chuẩn hóa quy trình, hoạt động kiểm thử tại doanh nghiệp đối mặt với nhiều bất cập. Bảng dưới đây so sánh ba phương pháp tiếp cận chính:

Tiêu chí so sánh Kiểm thử tùy hứng (Ad-hoc Testing) Kiểm thử hộp đen chuẩn hóa (Đề xuất) Kiểm thử tự động (Automation Test)
Độ bao phủ Test Case Thấp (< 45%), phụ thuộc cảm tính Cao (> 90%), theo ma trận phân tích Rất cao (> 95%) cho luồng cố định
Khả năng phát hiện lỗi biên Dễ bỏ sót giá trị cực trị Triệt để nhờ BVA và EP Tối ưu nếu script được thiết kế chuẩn
Chi phí thiết lập ban đầu Rất thấp Thấp - Trung bình Cao (đòi hỏi kỹ sư Automation)
Tính tái sử dụng kịch bản Không thể tái sử dụng Tái sử dụng tốt cho Regression Test Tự động thực thi lặp lại liên tục
Mức độ phụ thuộc Tester Phụ thuộc hoàn toàn vào kinh nghiệm Chuẩn hóa theo tài liệu SRS Phụ thuộc vào framework mã nguồn

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

Hệ thống kiểm thử cho website hoctestertop.com được phân loại yêu cầu nghiêm ngặt:

  • Must have (Bắt buộc có): Kiểm tra xác thực dữ liệu giỏ hàng, giới hạn số lượng đặt mua ($1 \le Qty \le 100$), tìm kiếm không phân biệt chữ hoa/thường, chặn ký tự đặc biệt gây lỗi hệ thống.
  • Should have (Nên có): Tự động cập nhật thành tiền (Ajax auto-calculate), cơ chế gợi ý từ khóa thông minh (Auto-suggestion), hiệu ứng hover trên danh mục sản phẩm.
  • Could have (Có thể có): Cơ chế lọc sản phẩm nâng cao nhiều tiêu chí cùng lúc, pop-up xác nhận xóa sản phẩm khỏi giỏ hàng.
  • Won't have (Chưa ưu tiên): Tích hợp cổng thanh toán quốc tế đa tiền tệ, đồng bộ tải dữ liệu thời gian thực qua WebSocket.

Thiết kế kiến trúc và Technology Stack

Hệ thống ứng dụng và môi trường kiểm thử được cấu hình chuẩn hóa trên hạ tầng doanh nghiệp:

graph TD
    Client[Client Browsers: Chrome, Firefox, Mobile Web] -->|HTTP/HTTPS Request| WebServer[Web Server: Apache 2.4 / AWS EC2]
    WebServer -->|PHP 7.1 Engine| AppLogic[Business Logic Modules: Search, Cart, Order]
    AppLogic -->|SQL Queries| DB[(MySQL 5.7 Database)]
    QA_Station[QA Testing Environment: Windows 10, NetBeans 8.2 IDE] -->|Black-box Testing & API Inspection| Client
    QA_Station -->|Admin CP Management| BackEnd[Back-end Portal: /admincp]
  • Môi trường Web Server: Apache 2.4 chạy trên nền tảng điện toán đám mây Amazon EC2 (AWS).
  • Ngôn ngữ phát triển: PHP 7.1 kết hợp mô hình MVC, JavaScript, HTML5/CSS3.
  • Cơ sở dữ liệu: MySQL Community Server 5.7.
  • Công cụ phát triển và quản trị: NetBeans IDE 8.2, Adobe CS6, TeamViewer 13, Microsoft Outlook, Windows Server.
  • Công cụ kiểm thử nâng cao (R&D): Selenium WebDriver 3.x, Apache JMeter 3.3, HP QuickTest Professional (QTP/UFT).

Phương pháp luận phát triển và kiểm soát chất lượng

Dự án áp dụng mô hình chữ V (V-Model), gắn liền từng giai đoạn phân tích yêu cầu với kế hoạch kiểm thử tương ứng. Ma trận truy xuất nguồn gốc yêu cầu (Traceability Matrix) được thiết lập để đảm bảo mọi dòng đặc tả yêu cầu phần mềm (Software Requirement Specification - SRS) đều có ít nhất 2 Test Cases kiểm chứng.

Implementation và kết quả

Quy trình phân tích và thuật toán thiết kế Test Case

Áp dụng kỹ thuật Phân tích giá trị biên (BVA) và Phân vùng tương đương (EP) vào kiểm thử trường "Số lượng đặt mua" ($Qty$) của chức năng Mua sắm (Quy định: $1 \le Qty \le 100$, chỉ nhận số nguyên):

Phân vùng tương đương (EP):
- Phân vùng hợp lệ: 1 <= Qty <= 100 (Giá trị đại diện: 50)
- Phân vùng không hợp lệ 1: Qty < 1 (Giá trị đại diện: 0, -5)
- Phân vùng không hợp lệ 2: Qty > 100 (Giá trị đại diện: 101, 250)
- Phân vùng không hợp lệ 3: Qty không phải số (Ký tự chữ cái, Ký tự đặc biệt)

Điểm biên (BVA):
- Biên dưới: 0 (Không hợp lệ), 1 (Hợp lệ), 2 (Hợp lệ)
- Biên trên: 99 (Hợp lệ), 100 (Hợp lệ), 101 (Không hợp lệ)

Thuật toán kiểm tra và xử lý logic giỏ hàng chuẩn mực cần đạt:

<?php
/**
 * Logic kiểm tra tính hợp lệ của số lượng đặt mua sản phẩm
 * @param mixed $inputQty Dữ liệu đầu vào từ người dùng
 * @return array Kết quả kiểm thử và trạng thái xử lý
 */
function validateCartQuantity($inputQty) {
    $result = [
        'isValid' => false,
        'quantity' => 0,
        'message' => ''
    ];

    // Kiểm tra tính rỗng
    if ($inputQty === '' || $inputQty === null) {
        $result['message'] = 'Bạn phải nhập Số lượng';
        return $result;
    }

    // Kiểm tra định dạng số nguyên dương
    if (!filter_var($inputQty, FILTER_VALIDATE_INT) || intval($inputQty) <= 0) {
        $result['message'] = 'Số lượng phải nhập bằng số nguyên dương';
        return $result;
    }

    $qty = intval($inputQty);

    // Kiểm tra giá trị biên
    if ($qty > 100) {
        $result['message'] = 'Chỉ cho phép mua tối đa 100 sản phẩm/1 mặt hàng';
        return $result;
    }

    $result['isValid'] = true;
    $result['quantity'] = $qty;
    $result['message'] = 'Số lượng hợp lệ';
    return $result;
}
?>

Dữ liệu thực thi kiểm thử và phân tích lỗi (Defect Tracking)

Quá trình kiểm thử tập trung vào 2 module chức năng then chốt của website http://hoctestertop.com/:

+-------------------------------------------------------------------------+
| Kết quả kiểm thử thực nghiệm (Test Execution Summary)                   |
| 1. Module Tìm kiếm (Search Engine):                                     |
|    - Tổng số Test Cases: 12                                             |
|    - Đạt (Pass): 12/12 (Tỷ lệ 100%)                                     |
|    - Không đạt (Fail): 0                                                |
| 2. Module Mua sắm & Giỏ hàng (Shopping Cart):                           |
|    - Tổng số Test Cases: 38                                             |
|    - Đạt (Pass): 31/38 (Tỷ lệ 81.6%)                                    |
|    - Không đạt (Fail): 07/38 (Tỷ lệ 18.4% - Lỗi hệ thống phát hiện)     |
+-------------------------------------------------------------------------+

Chi tiết 7 lỗi nghiêm trọng được phát hiện trong module Mua sắm:

  1. Lỗi ID 05: Nhập số lượng chứa ký tự đặc biệt (@#$%^&) -> Hệ thống không đổi màu viền textbox sang đỏ cảnh báo.
  2. Lỗi ID 06: Bỏ trống trường số lượng -> Không hiển thị thông báo "Bạn phải nhập số lượng".
  3. Lỗi ID 09 & 19 & 38: Nhập số lượng $Qty = 101$ (vượt biên trên) -> Hệ thống vẫn nhận dữ liệu thay vì chặn và hiển thị thông báo: "Chỉ cho phép mua tối đa 100 sản phẩm/1 mặt hàng".
  4. Lỗi ID 11: Click nút "Hủy đơn hàng" trong pop-up Đặt mua -> Không hiển thị pop-up xác nhận xóa, xóa trực tiếp gây mất dữ liệu người dùng.
  5. Lỗi ID 22: Giỏ hàng chưa có sản phẩm, người dùng click vào icon giỏ hàng -> Không hiển thị thông báo thân thiện "Chưa có sản phẩm nào trong giỏ hàng".
pie title Tỷ lệ trạng thái Test Case trên toàn bộ hệ thống
    "Pass (Đạt)" : 43
    "Fail (Phát hiện lỗi)" : 7

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

Cải tiến kỹ thuật đột phá

Khóa luận mang lại những đóng góp mang tính thực tiễn cao cho hoạt động phát triển phần mềm:

  • Chuẩn hóa quy trình QA/QC nội bộ: Chuyển đổi toàn diện từ mô hình "Lập trình viên kiêm Tester" sang mô hình "Phòng Kiểm thử độc lập", loại bỏ hoàn toàn tính chủ quan trong đánh giá chất lượng.
  • Xây dựng khung tài liệu mẫu (Test Suite Template): Định hình cấu trúc viết kịch bản kiểm thử chuẩn hóa bao gồm: ID, Module, Test Purpose, Pre-conditions, Steps, Test Data, Expected Result, Actual Result, Status (Pass/Fail).
  • Ứng dụng toán học vào thiết kế Test Case: Việc sử dụng BVA và EP giúp giảm 60% số lượng ca kiểm thử dư thừa nhưng tăng 40% khả năng phát hiện lỗi tại các điểm cực trị so với phương pháp kiểm thử ngẫu nhiên.
+-------------------------------------------------------------------+
| Hiệu quả cải tiến định lượng tại Gia Linh Solution                |
| - Độ bao phủ kiểm thử chức năng: Tăng từ 45% lên 92%              |
| - Thời gian phát hiện lỗi hồi quy: Rút ngắn 35%                   |
| - Mức độ hài lòng của nhân viên kỹ thuật với quy trình: Đạt 74.1% |
| - Tỷ lệ lỗi lọt qua môi trường UAT khách hàng: Giảm 50%           |
+-------------------------------------------------------------------+

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

Kịch bản triển khai thực tế

Quy trình và bộ Test Cases trong nghiên cứu được triển khai trực tiếp cho dự án website thương mại điện tử Green Construction (http://hoctestertop.com/) - chuyên cung cấp trang thiết bị và nội thất văn phòng (bàn ghế, máy in, máy chiếu, linh kiện vi tính).

sequenceDiagram
    autonumber
    actor Tester as Kỹ sư Kiểm thử
    participant Web as hoctestertop.com (Front-end)
    participant Back as Hệ thống Quản trị (/admincp)
    participant Dev as Đội ngũ Lập trình

    Tester->>Web: Nhập dữ liệu kiểm thử (BVA: Qty = 101, Chữ, Ký tự lạ)
    Web-->>Tester: Phản hồi giao diện & Tính toán thành tiền
    alt Phát hiện Bug (Fail)
        Tester->>Dev: Log Bug chi tiết kèm Screenshot & Steps to Reproduce
        Dev->>Back: Fix mã nguồn tại Backend & Database
        Dev->>Tester: Bàn giao bản build mới
        Tester->>Web: Thực hiện Kiểm thử hồi quy (Regression Test)
    else Đúng đặc tả (Pass)
        Tester->>Web: Đánh dấu Pass & Đóng ca kiểm thử
    end

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

  • Chi phí đầu tư: Đào tạo đội ngũ 7 Tester chính thức và 20 thực tập sinh; thiết lập môi trường test tiêu chuẩn trên máy trạm Windows 10 và máy chủ ảo hóa AWS.
  • Lợi ích kinh tế:
    • Ngăn chặn 07 lỗi logic thanh toán nghiêm trọng trước khi Golive, ước tính bảo vệ doanh thu tránh thất thoát đơn hàng.
    • Rút ngắn thời gian chuyển giao phần mềm cho khách hàng từ 45 ngày xuống còn 30 ngày/dự án.
    • Tỷ suất hoàn vốn đầu tư (ROI) cho hoạt động QA ước tính đạt 185% sau 6 tháng áp dụng nhờ giảm chi phí nhân sự sửa lỗi (Bug Fixing Cost) sau bàn giao.

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

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

  • Mức độ phụ thuộc Manual Testing: Hoạt động kiểm thử tại website hoctestertop.com phần lớn vẫn thực hiện thủ công, tốn nhiều nhân lực khi hệ thống mở rộng danh mục hàng hóa lên hàng chục nghìn SKU.
  • Phạm vi kiểm thử phi chức năng: Chưa triển khai kiểm thử hiệu năng tải cực hạn (Stress Testing) và kiểm thử bảo mật nâng cao (Security Penetration Testing - SQL Injection, XSS trên toàn hệ thống).

Hướng phát triển tương lai

  1. Tích hợp kiểm thử tự động (Automation Testing): Xây dựng Framework kiểm thử tự động hóa với Selenium WebDriver (Java/Python) kết hợp mô hình Page Object Model (POM) cho toàn bộ luồng E-commerce.
  2. Kiểm thử hiệu năng chuyên sâu: Ứng dụng Apache JMeter 3.3 để giả lập 5.000 đến 10.000 người dùng đồng thời (Concurrent Users) thực hiện giao dịch trong các đợt Flash Sale.
  3. Triển khai CI/CD Test Pipeline: Tích hợp kiểm thử tự động vào quy trình Jenkins/GitLab CI để tự động kích hoạt Test Suite mỗi khi lập trình viên thực hiện git push.

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

  • Sinh viên ngành CNTT & HTTT: Nắm vững tài liệu tham khảo thực chiến, hiểu rõ sự khác biệt giữa lý thuyết kiểm thử và thực tế dự án doanh nghiệp.
  • Lập trình viên (Developers): Thấu hiểu tư duy của Tester, từ đó nâng cao kỹ năng tự viết Unit Test và chủ động bẫy lỗi dữ liệu biên ngay từ giai đoạn code.
  • Chuyên viên Đảm bảo chất lượng (QA/QC Engineers): Sở hữu bộ Test Cases mẫu chuẩn mực cho các module thương mại điện tử đặc thù (Search, Cart, Checkout, Admin CMS).
  • Doanh nghiệp phần mềm vừa và nhỏ (SMEs): Có được mô hình tham chiếu tối ưu để xây dựng và vận hành phòng kiểm thử độc lập với chi phí tiết kiệm nhưng hiệu quả vượt trội.

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

1. Yêu cầu phần cứng và phần mềm tối thiểu để triển khai bộ kịch bản kiểm thử này là gì?

Máy trạm Tester cần cấu hình tối thiểu CPU Intel Core i3, 8GB RAM, hệ điều hành Windows 7/8/10, cài đặt trình duyệt Chrome, Firefox và kết nối mạng nội bộ ổn định đến máy chủ web Apache (AWS EC2).

2. Kỹ thuật Phân tích giá trị biên (BVA) khác gì so với Phân vùng tương đương (EP)?

EP chia miền dữ liệu đầu vào thành các nhóm hợp lệ và không hợp lệ rồi chọn 1 giá trị đại diện cho mỗi nhóm; trong khi BVA tập trung kiểm tra chính xác tại các ranh giới cực trị của các phân vùng đó (ví dụ: điểm biên dưới, điểm biên trên, cận biên) vì đây là nơi lập trình viên dễ mắc lỗi so sánh sai toán tử (< thay vì <=).

3. Tại sao kiểm thử hộp đen lại quan trọng đối với website thương mại điện tử?

Kiểm thử hộp đen đặt Tester vào đúng vị trí và trải nghiệm của khách hàng mua hàng thực tế mà không bị chi phối bởi cấu trúc code bên trong, giúp phát hiện các khiếm khuyết giao diện, luồng thao tác bất hợp lý và sai sót trong trải nghiệm người dùng (UX/UI).

4. Khi nào doanh nghiệp nên chuyển từ kiểm thử thủ công sang kiểm thử tự động?

Doanh nghiệp nên áp dụng Automation Test khi hệ thống đã có độ ổn định nhất định về mặt tính năng, có các ca kiểm thử hồi quy cần chạy lặp đi lặp lại qua nhiều bản build (Releases) hoặc khi cần kiểm tra hiệu năng chịu tải với số lượng người dùng lớn mà thao tác thủ công không thể đáp ứng.

5. Làm thế nào để đo lường độ bao phủ (Coverage) của các ca kiểm thử hộp đen?

Độ bao phủ được đo lường thông qua Ma trận truy xuất nguồn gốc yêu cầu (Requirements Traceability Matrix - RTM), đối chiếu tỷ lệ phần trăm các yêu cầu nghiệp vụ trong tài liệu đặc tả (SRS) đã có ít nhất một kịch bản kiểm thử tương ứng được thiết kế và thực thi thành công.

Kết luận

Nghiên cứu ứng dụng các kỹ thuật kiểm thử phần mềm cho website thương mại điện tử http://hoctestertop.com/ của Công ty TNHH Giải pháp phần mềm Gia Linh đã chứng minh tầm quan trọng cốt lõi của hoạt động SQA trong chu kỳ phát triển phần mềm. Việc chuẩn hóa và áp dụng bài bản các kỹ thuật kiểm thử hộp đen (EP, BVA, Decision Table) không chỉ giúp phát hiện sớm 7 lỗi nghiệp vụ nghiêm trọng trước khi bàn giao sản phẩm mà còn nâng cao hiệu suất làm việc của toàn bộ phòng kỹ thuật lên 35%. Đây chính là nền tảng vững chắc để doanh nghiệp tiến tới tự động hóa quy trình kiểm thử, tối ưu hóa chi phí vận hành và mang lại những sản phẩm phần mềm chất lượng cao, bền vững cho thị trường.