Bối cảnh và vấn đề nghiên cứu

Trong bối cảnh công nghệ thông tin phát triển với tốc độ nhanh chóng, hệ thống mạng và các ứng dụng phần mềm đang gia tăng mạnh mẽ cả về số lượng quy mô lẫn độ phức tạp cấu trúc. Sự mở rộng của các hệ thống phần mềm quy mô lớn, bao gồm hàng nghìn module chức năng do các đội ngũ hàng nghìn kỹ sư phát triển, đã kéo theo nhiều nguy cơ tiềm ẩn về lỗi và hỏng hóc kỹ thuật. Những sai sót này gây ra ảnh hưởng tiêu cực trực tiếp đến các hoạt động kinh tế và xã hội, xuất phát từ nguyên nhân phần mềm không được kiểm duyệt kỹ lưỡng trước khi bàn giao cho người dùng cuối, hoặc do các đối tượng cố tình khai thác lỗ hổng bảo mật nhằm đánh cắp dữ liệu cá nhân như tài khoản ngân hàng, danh bạ, số điện thoại và tin nhắn. Thực tiễn lịch sử đã ghi nhận nhiều sự cố nghiêm trọng như sự cố máy tính Y2K năm 2000 làm tê liệt hàng loạt hệ thống máy tính lớn, cùng sự xuất hiện liên tục của các loại virus tấn công vào điểm yếu bảo mật.

Vấn đề chất lượng phần mềm trở thành một thách thức lớn trong toàn bộ vòng đời sản xuất. Việc thực hiện kiểm thử phần mềm bằng phương pháp thủ công (manual testing) đối với các hệ thống phức tạp bộc lộ nhiều hạn chế về thời gian, nhân lực và khó đảm bảo tính chính xác toàn diện. Theo các số liệu tính toán được tác giả trích dẫn, công tác kiểm thử đóng vai trò trọng yếu khi chiếm tới 40% tổng chi phí sản xuất một sản phẩm phần mềm. Do đó, việc xây dựng và áp dụng các giải pháp kiểm thử phần mềm tự động (automation testing) là yêu cầu cấp thiết nhằm rút ngắn thời gian thực thi, nâng cao độ an toàn và tối ưu hóa năng suất kiểm thử.

Đồ án được xây dựng nhằm giải quyết các mục tiêu và nhiệm vụ nghiên cứu cụ thể:

  1. Hệ thống hóa cơ sở lý luận về phần mềm, vòng đời phát triển phần mềm (SDLC) và quy trình Rational Unified Process (RUP).
  2. Khảo sát, phân tích các mô hình phát triển phần mềm kinh điển và hiện đại (Waterfall, Spiral, Agile, Iterative, Incremental, V-Model, Scrum, RAD).
  3. Làm rõ khái niệm, vai trò, cấp độ và quy trình lập kế hoạch kiểm thử phần mềm (Test Plan).
  4. Phân tích chi tiết các kỹ thuật kiểm thử hộp đen (Black Box Testing), kiểm thử hộp trắng (White Box Testing) và kiểm thử hộp xám (Grey Box Testing).
  5. Nghiên cứu công cụ kiểm thử tự động Selenium (Selenium IDE) và định hướng áp dụng vào kiểm thử ứng dụng web phát triển trên nền tảng ASP.NET MVC.

Đối tượng và phạm vi nghiên cứu:

  • Đối tượng nghiên cứu: Quy trình phát triển phần mềm, các kỹ thuật và cấp độ kiểm thử phần mềm, công cụ kiểm thử tự động Selenium IDE, và ứng dụng web ASP.NET MVC.
  • Phạm vi nghiên cứu: Giới hạn trong khuôn khổ đồ án môn học thuộc Khoa Công nghệ – Trường Đại học Kinh tế Công nghiệp Long An; tập trung nghiên cứu lý thuyết quy trình kiểm thử, phương pháp thiết kế kịch bản kiểm thử chức năng và nguyên lý hoạt động của công cụ Selenium trong môi trường ứng dụng web.

Cơ sở lý thuyết và phương pháp

Đồ án vận dụng hệ thống khái niệm, mô hình kỹ thuật phần mềm và các phương pháp luận kiểm thử tiêu chuẩn:

  • Khái niệm và phân loại phần mềm: Phần mềm (Software) được xác định là tập hợp các câu lệnh được lập trình theo trật tự nhất định để điều khiển phần cứng hoặc thực thi tác vụ. Đồ án phân loại phần mềm thành ba nhóm: phần mềm hệ thống (Hệ điều hành, BIOS), phần mềm ứng dụng (như MONA Ecommerce, MONA Jewelry), và phần mềm lập trình.
  • Mô hình quy trình phát triển phần mềm Rational Unified Process (RUP): Phương pháp phát triển phần mềm có cấu trúc do Rational Software (IBM) phát triển, hoạt động theo chu kỳ lặp (iterative) và gia tăng (incremental) qua 4 giai đoạn: Khởi đầu (Inception), Lập kế hoạch (Elaboration), Xây dựng (Construction), và Chuyển giao (Transition).
  • Nguyên lý Xác minh và Xác nhận (Verification and Validation - V&V):
    • Verification: Qu PROCESS đánh giá hệ thống hoặc thành phần ở một giai đoạn phát triển nhằm xác định sản phẩm có đáp ứng các điều kiện đặt ra tại thời điểm bắt đầu giai đoạn đó hay không (ví dụ trong phần mềm cờ Monopoly: xác minh hai người chơi không thể cùng sở hữu chung một căn nhà).
    • Validation: Quá trình đánh giá hệ thống ở cuối chu kỳ phát triển để xác định sản phẩm có thỏa mãn toàn bộ nhu cầu và đặc tả của khách hàng hay không.
  • Phương pháp nghiên cứu:
    • Phương pháp phân tích - tổng hợp lý thuyết: Thu thập, phân loại và hệ thống hóa các tài liệu chuyên ngành về kỹ thuật phần mềm, vòng đời SDLC và các mô hình quản lý dự án.
    • Phương pháp mô hình hóa quy trình: Thiết lập các sơ đồ luồng công việc kiểm thử (Test Execution Workflow, Defects Workflow, Test Plan Workflow).
    • Phương pháp thiết kế ca kiểm thử (Test Case Design): Áp dụng các kỹ thuật kiểm thử chức năng hộp đen (Phân lớp tương đương, Phân tích giá trị biên, Bảng quyết định) và kiểm thử cấu trúc hộp trắng (dựa trên giải thuật và mã nguồn).
  • Nguồn dữ liệu: Các giáo trình kỹ thuật phần mềm, tài liệu đặc tả yêu cầu phần mềm (SRS - Software Requirement Specification), chuẩn quy trình RUP/Scrum, cùng các tài liệu hướng dẫn kỹ thuật của công cụ kiểm thử Selenium.

Nội dung chính theo từng chương

Chương 1: Tổng quan về đề tài

Chương 1 trình bày lý do lựa chọn đề tài xuất phát từ thực trạng bùng nổ công nghệ thông tin và sự gia tăng quy mô của các hệ thống phần mềm. Tác giả nhấn mạnh rằng các lỗi phần mềm tiềm ẩn gây ra tổn thất lớn cho nền kinh tế và an ninh thông tin. Do công tác kiểm thử chiếm đến 40% tổng chi phí sản xuất phần mềm và phương pháp kiểm thử thủ công không còn đáp ứng được yêu cầu về tiến độ cũng như độ chính xác đối với các phần mềm hàng nghìn module, việc nghiên cứu kiểm thử tự động với Selenium IDE là cần thiết nhằm cải tiến quy trình và nâng cao năng suất kiểm thử.

Chương 2: Phần mềm là gì ? Tổng quan về qui trình phát triển phần mềm

Chương 2 phân tích định nghĩa phần mềm, phân loại phần mềm thành ba nhóm (hệ thống, ứng dụng, lập trình) và đi sâu vào quy trình Rational Unified Process (RUP) cùng 8 mô hình phát triển phần mềm.

Mô hình phát triển Đặc điểm cốt lõi Phạm vi ứng dụng phù hợp Ưu điểm chính Nhược điểm chính
Thác nước (Waterfall) Tuần tự qua các pha: Requirements, Analysis, Coding, Testing, Implementation, Maintenance. Dự án nhỏ, ngắn hạn, yêu cầu ổn định, rõ ràng ngay từ đầu. Dễ quản lý, tiếp cận rõ ràng, phát hiện lỗi sớm theo từng pha. Rất khó thay đổi yêu cầu; không phù hợp cho dự án dài, phức tạp.
Xoắn ốc (Spiral) Kết hợp Prototyping và Waterfall qua 4 pha lặp: Xác định mục tiêu, Đánh giá rủi ro, Phát triển, Lập kế hoạch. Hệ thống lớn, đắt tiền, phức tạp, yêu cầu đánh giá rủi ro cao. Quản lý rủi ro chặt chẽ ở từng mức tiến hóa; phát hiện vấn đề sớm. Chi phí cao, mất nhiều thời gian; đòi hỏi kỹ năng quản lý dự án cao.
Agile Phát triển theo hướng lặp và gia tăng (Iterative & Incremental); chia nhỏ các khung thời gian. Mọi dự án cần chức năng nhanh, có sự tương tác cao từ khách hàng. Linh hoạt điều chỉnh, tăng tính cộng tác nhóm, xây dựng chức năng nhanh. Khó xử lý phụ thuộc phức tạp; rủi ro về tính bảo trì do ít tài liệu.
Tiếp cận lặp (Iterative) Lặp đi lặp lại để tạo ra các phiên bản hoàn thiện dần spec mà không chờ đặc tả toàn diện. Dự án lớn, nhiệm vụ quan trọng, vừa làm vừa tiếp cận công nghệ mới. Giảm chi phí khi đổi phạm vi; tạo sản phẩm sớm để lấy phản hồi. Yêu cầu tài nguyên lớn; cấu trúc hệ thống dễ phát sinh lỗi bất ngờ.
Tăng trưởng (Incremental) Chia đặc tả thành nhiều phần/module nhỏ; phát triển song song hoặc tuần tự. Dự án có yêu cầu rõ ràng; khách hàng có nhu cầu sử dụng sớm từng phần. Phát triển nhanh, linh hoạt thay đổi, dễ kiểm tra và sửa lỗi. Tổng chi phí cao hơn mô hình thác nước; đòi hỏi thiết kế tốt.
Mô hình chữ V (V-Model) Mở rộng của thác nước; giai đoạn kiểm thử được ghép cặp tương ứng với từng pha phát triển. Dự án ổn định, yêu cầu được định nghĩa rõ, công nghệ không đổi. Kỷ luật cao, kiểm thử được lập kế hoạch ngay từ đầu, dễ quản lý. Rủi ro cao nếu có thay đổi yêu cầu; kém linh hoạt với dự án phức tạp.
Scrum Chia giai đoạn thành các Sprint (1-4 tuần); họp Daily Meeting (15-20 phút); hướng khách hàng. Dự án yêu cầu thay đổi liên tục hoặc chưa rõ ràng ngay từ đầu. Một người đảm nhận nhiều vai trò; phát hiện lỗi sớm; thích ứng cao. Đòi hỏi nhóm có kỹ năng tốt; khó kiểm soát ngân sách và thời gian.
RAD (Rapid Application Development) Tạo mẫu nhanh; phát triển module hóa song song trong chu kỳ ngắn 2-3 tháng. Dự án module hóa rõ ràng; có sẵn công cụ thiết kế và chi phí lớn. Rút ngắn thời gian phát triển; tăng khả năng tái sử dụng thành phần. Chỉ áp dụng cho hệ thống có thể chia module; đòi hỏi nhân lực giỏi.

Bên cạnh đó, chương 2 phân tích cơ cấu Scrum gồm 3 yếu tố: Tổ chức (Product Owner, ScrumMaster, Development Team 4-7 kỹ sư), Tài liệu (Product Backlog, Sprint Backlog, Estimation), và Quy trình (Sprint Planning, Review, Daily Scrum). Vòng đời phát triển phần mềm (SDLC) được tổng kết qua 7 bước: Lập kế hoạch (Planning), Xác định yêu cầu (Defining qua tài liệu SRS), Thiết kế kiến trúc (Designing), Lập trình (Building), Kiểm thử (Testing), Triển khai (Deployment), và Bảo trì (Maintenance).

Chương 3: Tổng quan về kiểm thử phần mềm

Chương 3 làm rõ vai trò của hoạt động kiểm thử trong toàn bộ quy trình phần mềm. Tác giả chỉ ra kiểm thử không chỉ giới hạn ở việc kiểm tra mã nguồn mà phải bao quát mọi công đoạn phát triển. Nội dung chương phân định ba loại hình kiểm thử theo nền tảng thực thi: kiểm thử ứng dụng Desktop, kiểm thử Web/Cloud (như Google Document, Microsoft web apps), và kiểm thử Mobile.

Về quy trình quản lý kiểm thử, chương này trình bày chi tiết về Kế hoạch kiểm thử (Test Plan) do Test Manager hoặc Test Leader chủ trì xây dựng, được đánh giá bởi QC Team, Developers, Business Analyst (BA), Technical Architect (TA), Project Manager (PM) và khách hàng, sau đó được PM và khách hàng chính thức phê duyệt. Các luồng làm việc chính gồm có:

  • Test Execution Workflow: Thực hiện kiểm thử theo test case đã định nghĩa, thực hiện kiểm thử ad-hoc, và kiểm thử lại (re-test) các lỗi đã khắc phục.
  • Defects Workflow: Quy trình ghi nhận, phân loại, báo cáo và theo dõi lỗi phát sinh cho đến khi được giải quyết triệt để.

Chương 4: Các kỹ thuật cơ bản, giai đoạn (cấp độ) và công cụ (Selenium) kiểm thử phần mềm tự động

Chương 4 phân tích các cấp độ kiểm thử chính: Kiểm thử đơn vị (Unit Test), Kiểm thử tích hợp (Integration Test), Kiểm thử hệ thống (System Test), Kiểm thử chấp nhận (Acceptance Test), và Kiểm thử hồi quy (Regression Test). Chương tập trung vào ba kỹ thuật kiểm thử nền tảng:

  1. Kiểm thử hộp đen (Black Box Testing): Kiểm tra chức năng dựa hoàn toàn vào tài liệu đặc tả yêu cầu mà không can thiệp vào cấu trúc mã nguồn bên trong; áp dụng hiệu quả nhất trong System Test và Acceptance Test. Tác giả phân tích sâu ba kỹ thuật:
    • Phân lớp tương đương (Equivalence Class Partitioning): Chia tập dữ liệu đầu vào thành các nhóm giá trị tương đương (hợp lệ và không hợp lệ). Mỗi lớp chỉ cần chọn một ca kiểm thử đại diện, giúp giảm số lượng test case cần thực thi mà vẫn đảm bảo độ bao phủ.
    • Phân tích giá trị biên (Boundary Value Analysis): Tập trung thiết kế ca kiểm thử tại các điểm biên của lớp tương đương liên tục. Với mỗi biên, quy trình yêu cầu thiết lập 3 ca kiểm thử: một tại giá trị biên, một ngay dưới biên, và một ngay trên biên.
    • Kỹ thuật dùng bảng quyết định (Decision Table): Biểu diễn các điều kiện dữ liệu đầu vào ($Condition_1 \dots Condition_m$) và các hành động tương ứng ($Action_1 \dots Action_n$) dưới dạng các cột quy tắc nghiệp vụ phức tạp.
  2. Kiểm thử hộp trắng (White Box Testing): Phương pháp kiểm thử dựa trên việc nắm rõ cấu trúc mã nguồn, giải thuật và luồng điều khiển bên trong; thích hợp nhất cho kiểm thử đơn vị (Unit Test). Người kiểm thử phải có kỹ năng lập trình để thiết kế kịch bản bao phủ các nhánh lệnh.
  3. Kiểm thử hộp xám (Grey Box Testing): Kỹ thuật kết hợp giữa hộp đen và hộp trắng, có mục tiêu chính là phục vụ kiểm thử các ứng dụng trên nền tảng web (web-based).
  4. Kiểm thử tự động và công cụ Selenium: Khái quát về tự động hóa kịch bản kiểm thử nhằm thay thế các thao tác thủ công lặp lại trên trình duyệt web.

Chương 5: Kết luận và hướng phát triển

Chương 5 tổng kết lại toàn bộ các nội dung nghiên cứu lý thuyết về quy trình phát triển và các kỹ thuật kiểm thử phần mềm, đồng thời xác định định hướng phát triển trong việc ứng dụng công cụ kiểm thử tự động Selenium IDE vào việc xây dựng kịch bản kiểm thử cho các ứng dụng web cụ thể sử dụng công nghệ ASP.NET MVC.

Kết quả và đóng góp

Đồ án đã tổng hợp và trình bày các kết quả nghiên cứu chính dựa trên văn bản:

  • Hệ thống hóa toàn diện các mô hình phát triển phần mềm: Phân tích cấu trúc, ưu điểm, nhược điểm và phạm vi áp dụng của 8 mô hình phát triển phần mềm (Thác nước, Xoắn ốc, Agile, Lặp, Tăng trưởng, Chữ V, Scrum, RAD) cùng quy trình chuẩn RUP.
  • Làm rõ các chỉ số định lượng kinh tế trong kỹ thuật phần mềm: Dẫn chứng số liệu kiểm thử chiếm tới 40% tổng chi phí sản xuất phần mềm, làm cơ sở khoa học chứng minh sự cần thiết của tự động hóa kiểm thử.
  • Xây dựng quy trình quản trị kiểm thử chuẩn mực: Chi tiết hóa các hoạt động của Test Plan, vai trò trách nhiệm của các vị trí nhân sự (Test Manager, Test Leader, Test Analyst, Tester) và sơ đồ luồng phối hợp giữa các bên liên quan (QC, Dev, BA, PM, Customer).
  • Quy chuẩn hóa phương pháp thiết kế ca kiểm thử: Cung cấp quy trình 3 bước cho kỹ thuật phân tích giá trị biên (tại biên, trên biên, dưới biên) và phương pháp xây dựng Bảng quyết định cho các quy tắc nghiệp vụ phức tạp.
  • Định hướng ứng dụng công nghệ kiểm thử web: Đề xuất giải pháp kết hợp giữa kỹ thuật kiểm thử hộp xám và công cụ Selenium IDE nhằm tối ưu hóa hoạt động kiểm thử trên nền tảng ASP.NET MVC.

Hạn chế và hướng nghiên cứu tiếp

  • Hạn chế: Nội dung đồ án phần lớn tập trung vào việc tổng hợp, phân tích cơ sở lý thuyết về quy trình phát triển phần mềm, quy trình kiểm thử và các kỹ thuật thiết kế ca kiểm thử; phần triển khai thực nghiệm chi tiết các kịch bản kiểm thử tự động bằng Selenium IDE trên ứng dụng ASP.NET MVC thực tế chưa được trình bày chi tiết trong văn bản.
  • Hướng phát triển: Tác giả định hướng tiếp tục nghiên cứu sâu việc xây dựng bộ kịch bản kiểm thử tự động hoàn chỉnh bằng Selenium IDE, tích hợp kịch bản kiểm thử vào các module chức năng của hệ thống phần mềm ASP.NET MVC, và nghiên cứu mở rộng sang các công cụ tự động hóa kiểm thử nâng cao.

Giá trị tham khảo

Đồ án là nguồn tài liệu hữu ích cho sinh viên ngành Công nghệ thông tin, Kỹ thuật phần mềm và các chuyên viên kiểm thử phần mềm (QC/Tester):

  • Phần tổng quan quy trình và mô hình SDLC (Chương 2): Cung cấp tài liệu tổng hợp có cấu trúc rõ ràng về 8 mô hình phần mềm phổ biến, đặc biệt là cơ chế vận hành chi tiết của mô hình Scrum và quy trình RUP.
  • Phần phương pháp luận kiểm thử và kỹ thuật thiết kế test case (Chương 3 và Chương 4): Là tài liệu tham khảo thực hành giá trị cho người mới bắt đầu làm kiểm thử, hướng dẫn cụ thể cách tiếp cận phân lớp tương đương, phân tích giá trị biên và cách thiết lập kế hoạch kiểm thử (Test Plan) chuyên nghiệp trong doanh nghiệp.

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

1. Theo số liệu trong đồ án, công tác kiểm thử phần mềm chiếm tỷ trọng bao nhiêu trong tổng chi phí sản xuất phần mềm?
Theo tính toán được tác giả trích dẫn trong văn bản, công việc kiểm thử đóng vai trò hết sức quan trọng và chiếm tới 40% tổng toàn bộ chi phí cho việc sản xuất phần mềm.

2. Quy trình phát triển phần mềm RUP gồm những giai đoạn cơ bản nào?
Quy trình RUP (Rational Unified Process) gồm 4 giai đoạn cơ bản: Giai đoạn khởi đầu (Inception), Giai đoạn lập kế hoạch (Elaboration), Giai đoạn xây dựng (Construction), và Giai đoạn chuyển giao/triển khai (Transition).

3. Đội ngũ phát triển (Development Team) trong mô hình Scrum có quy mô bao nhiêu kỹ sư và mỗi Sprint thường kéo dài bao lâu?
Development Team trong Scrum gồm từ 4 đến 7 kỹ sư phần mềm. Mỗi giai đoạn Sprint thường kéo dài từ 1 tuần đến 4 tuần (không dài hơn 1 tháng), kèm theo cuộc họp Daily Meeting diễn ra hàng ngày từ 15 đến 20 phút.

4. Khi thiết kế ca kiểm thử theo kỹ thuật phân tích giá trị biên, người kiểm thử cần tạo bao nhiêu test case cho mỗi biên?
Đối với mỗi biên của một lớp tương đương, người kiểm thử cần tạo 3 test case: 1 test case tại giá trị biên, 1 test case ngay dưới biên, và 1 test case ngay trên biên (tùy thuộc vào đơn vị đo lường là số nguyên hay số thập phân).

5. Điểm khác biệt căn bản giữa kiểm thử hộp đen và kiểm thử hộp trắng là gì?
Kiểm thử hộp đen kiểm tra chức năng của phần mềm chỉ dựa trên tài liệu đặc tả yêu cầu mà không cần biết cấu trúc mã nguồn bên trong; trong khi kiểm thử hộp trắng đòi hỏi người kiểm thử phải nắm rõ thuật giải, mã lệnh và cấu trúc dữ liệu bên trong để kiểm tra các luồng thực thi của chương trình.

Kết luận

Đồ án "Áp dụng SeleniumIDE vào kiểm thử phần mềm Asp.net MVC" của sinh viên Hồ Phú Khương đã hệ thống hóa đầy đủ các kiến thức nền tảng về phần mềm, vòng đời phát triển SDLC và các mô hình quy trình phổ biến trong ngành công nghệ thông tin. Báo cáo phân tích sâu sắc các cấp độ và kỹ thuật kiểm thử hộp đen, hộp trắng, hộp xám, đồng thời làm rõ vai trò của công tác lập kế hoạch kiểm thử nhằm nâng cao chất lượng sản phẩm. Đây là công trình tổng quan lý thuyết có giá trị tham khảo thiết thực cho sinh viên và kỹ sư phần mềm trong việc chuẩn hóa quy trình kiểm thử và định hướng tự động hóa bằng công cụ Selenium.