Báo cáo đề tài: Kiểm thử chi tiết hệ thống The Guru99 Bank - Phạm Quốc Anh

Chuyên khảo phân tích Đề tài kiểm thử trên hệ thống the guru99 bank, đánh giá các khía cạnh quan trọng, đề xuất hướng nghiên cứu tiếp theo.

Chuyên ngành

Kiểm Thử Phần Mềm

Người đăng

Ẩn danh

Thể loại

Đề Tài

2023

90
3
0

Phí lưu trữ

30 Point

Mục lục chi tiết

LỜI CẢM ƠN

1. CHƯƠNG 1: TỔNG QUAN

1.1. Khái niệm kiểm thử phần mềm

1.2. Các nguyên tắc kiểm thử phần mềm

1.3. Các cấp độ kiểm thử phần mềm

1.4. Kiểm thử đơn vị

1.5. Kiểm thử tích hợp

1.6. Kiểm thử hệ thống

1.7. Kiểm thử chức năng

1.8. Kiểm thử giao diện người dùng

1.9. Kiểm thử luồng nghiệp vụ

1.10. Kiểm thử hiệu năng

2. CHƯƠNG 2: GIỚI THIỆU VỀ ỨNG DỤNG KIỂM THỬ

2.1. Tổng quan về ứng dụng

2.2. Đặc tả yêu cầu nghiệp vụ

3. CHƯƠNG 3: DANH SÁCH TEST CASE

3.1. Phiên bản thứ nhất

3.2. Phiên bản thứ hai

4. CHƯƠNG 4: DANH SÁCH BUG

4.1. Phiên bản thứ nhất

4.2. Phiên bản thứ hai

5. CHƯƠNG 5: KẾT LUẬN

5.1. Báo cáo phiên bản thứ nhất

5.2. Báo cáo phiên bản thứ hai

Tóm tắt

I. Hướng dẫn tổng quan đề tài kiểm thử Guru99 Bank A Z

Bài viết này cung cấp một cái nhìn toàn diện và chuyên sâu về đề tài kiểm thử trên hệ thống the guru99 bank, một dự án demo kinh điển dành cho các kỹ sư kiểm thử phần mềm. Nội dung được chắt lọc từ các nghiên cứu thực tiễn, trình bày một cách có hệ thống từ các khái niệm cơ bản, phân tích yêu cầu, đến việc thiết kế kịch bản kiểm thử và báo cáo lỗi. Mục tiêu là cung cấp một tài liệu tham khảo chất lượng, giúp sinh viên và người mới bắt đầu có thể áp dụng vào đồ án kiểm thử phần mềm của mình, đồng thời tối ưu hóa quy trình để đảm bảo chất lượng sản phẩm cao nhất. Việc hiểu rõ các nguyên tắc và phương pháp luận được trình bày sẽ là nền tảng vững chắc để tiếp cận các dự án phức tạp hơn trong tương lai.

1.1. Khái niệm cốt lõi về kiểm thử phần mềm KTPM

Kiểm thử phần mềm là một quy trình thiết yếu trong vòng đời phát triển phần mềm. Theo định nghĩa của IEEE Std 610.12 (1990), đây là quá trình phân tích các yếu tố phần mềm để phát hiện sự khác biệt giữa điều kiện thực tế và yêu cầu đặt ra, đồng thời đánh giá các đặc tính của sản phẩm. Vai trò của KTPM không chỉ dừng lại ở việc tìm lỗi. Nó giúp giảm thiểu rủi ro, nâng cao chất lượng sản phẩm, và quan trọng hơn là gia tăng sự hài lòng của khách hàng. Một sản phẩm được kiểm thử kỹ lưỡng sẽ đảm bảo độ tin cậy, hiệu suất hoạt động ổn định và bảo mật tốt hơn, tránh được những lỗ hổng đáng tiếc. Hơn nữa, việc phát hiện lỗi sớm trong quy trình kiểm thử còn giúp tiết kiệm đáng kể thời gian và chi phí sửa chữa so với việc khắc phục sau khi sản phẩm đã được triển khai.

1.2. Lý do chọn dự án demo Guru99 làm đề tài thực hành

Hệ thống The Guru99 Bank là một dự án demo được thiết kế chuyên biệt cho mục đích học tập và thực hành kiểm thử. Nó mô phỏng đầy đủ các chức năng cơ bản của một ứng dụng ngân hàng trực tuyến, bao gồm quản lý khách hàng, tài khoản, và giao dịch chuyển tiền. Sự phức tạp vừa phải của hệ thống này cho phép người học áp dụng đa dạng các kỹ thuật từ kiểm thử thủ công đến kiểm thử tự động. Tài liệu đặc tả yêu cầu nghiệp vụ rõ ràng, phạm vi được xác định cụ thể giúp người thực hiện dễ dàng lập kế hoạch, thiết kế test case guru99 bank và theo dõi tiến độ. Việc lựa chọn dự án này làm đề tài nghiên cứu không chỉ giúp củng cố kiến thức lý thuyết mà còn mang lại kinh nghiệm thực tiễn quý báu về kiểm thử hệ thống ngân hàng.

1.3. Bảy nguyên tắc vàng trong một quy trình kiểm thử

Để thực hiện kiểm thử hiệu quả, cần tuân thủ bảy nguyên tắc cơ bản. Thứ nhất, kiểm thử chỉ ra sự hiện diện của lỗi, không thể chứng minh phần mềm không có lỗi. Thứ hai, kiểm thử cạn kiệt là bất khả thi; do đó, cần ưu tiên các khu vực rủi ro cao. Thứ ba, kiểm thử sớm giúp phát hiện lỗi từ giai đoạn đầu, giảm chi phí sửa chữa. Thứ tư, lỗi thường tập trung thành cụm trong một vài module nhất định. Thứ năm, nghịch lý thuốc trừ sâu cho thấy việc lặp lại cùng một kịch bản kiểm thử sẽ giảm hiệu quả tìm lỗi mới. Thứ sáu, kiểm thử phụ thuộc vào ngữ cảnh; một ứng dụng web sẽ có chiến lược kiểm thử khác với một ứng dụng di động. Cuối cùng, quan niệm sai lầm về "không có lỗi" - một sản phẩm không có lỗi nhưng không đáp ứng nhu cầu người dùng thì vẫn là một sản phẩm thất bại.

II. Phân tích yêu cầu nghiệp vụ hệ thống Guru99 Bank

Trước khi bắt đầu bất kỳ hoạt động kiểm thử nào, việc phân tích và hiểu rõ yêu cầu hệ thống là bước không thể bỏ qua. Đối với đề tài kiểm thử trên hệ thống the guru99 bank, việc này bao gồm xác định các vai trò người dùng khác nhau và các chức năng tương ứng của họ. Hệ thống được chia thành hai quyền truy cập chính là Manager (Quản lý) và Customer (Khách hàng), mỗi quyền có một tập hợp các tính năng riêng biệt. Việc phân tích kỹ lưỡng giúp xác định phạm vi kiểm thử, định hình các kịch bản kiểm thử và đảm bảo rằng mọi luồng nghiệp vụ quan trọng đều được bao phủ. Đây là giai đoạn nền tảng để xây dựng một test plan hoàn chỉnh và hiệu quả.

2.1. Đặc tả vai trò và chức năng Manager vs. Customer

Hệ thống The Guru99 Bank định nghĩa rõ hai vai trò chính. Vai trò Manager có quyền hạn cao nhất, bao gồm các chức năng quản trị như: kiểm thử tạo khách hàng mới (New Customer), tạo tài khoản mới (New Account), chỉnh sửa/xóa khách hàng và tài khoản, cũng như thực hiện các giao dịch như gửi tiền (Deposit) và rút tiền (Withdrawal). Ngược lại, vai trò Customer có các chức năng tập trung vào việc tự quản lý tài khoản của mình. Khách hàng có thể thực hiện các tác vụ như kiểm tra số dư (Balance Enquiry), kiểm thử chuyển tiền (Fund Transfer), xem sao kê (Mini Statement), và thay đổi mật khẩu. Việc phân quyền rõ ràng này đòi hỏi các test case phải được thiết kế riêng biệt cho từng vai trò để đảm bảo tính bảo mật và đúng đắn của luồng nghiệp vụ.

2.2. Xác định các module ưu tiên cho kiểm thử chức năng

Dựa trên phân tích yêu cầu, các module cần được ưu tiên cho kiểm thử chức năng bao gồm: Kiểm thử chức năng đăng nhập (Login), Tạo khách hàng mới (New Customer), Tạo tài khoản mới (New Account), và Chuyển tiền (Fund Transfer). Đây là những luồng nghiệp vụ cốt lõi, ảnh hưởng trực tiếp đến trải nghiệm người dùng và tính toàn vẹn của hệ thống. Bên cạnh đó, các chức năng như Chỉnh sửa thông tin (Edit Customer/Account) và Xóa (Delete Customer/Account) cũng cần được kiểm tra cẩn thận để đảm bảo các ràng buộc dữ liệu được tuân thủ. Việc xác định đúng các module ưu tiên giúp tập trung nguồn lực kiểm thử vào những khu vực có rủi ro cao nhất, tối ưu hóa hiệu quả của toàn bộ dự án.

III. Cách thiết kế test case cho hệ thống The Guru99 Bank

Thiết kế Test Case là hoạt động trung tâm của mọi đề tài kiểm thử trên hệ thống the guru99 bank. Một bộ test case tốt phải bao phủ được các trường hợp thành công (positive case), trường hợp thất bại (negative case), và các trường hợp biên. Tài liệu nghiên cứu đã trình bày chi tiết cách xây dựng các test case guru99 bank cho từng module, từ việc xác thực dữ liệu đầu vào (validation) đến kiểm tra luồng xử lý nghiệp vụ. Việc áp dụng các kỹ thuật kiểm thử hộp đen như phân lớp tương đương và phân tích giá trị biên là cực kỳ quan trọng trong giai đoạn này để đảm bảo các kịch bản được thiết kế một cách khoa học và toàn diện, giúp phát hiện lỗi một cách hiệu quả nhất.

3.1. Kỹ thuật viết kịch bản kiểm thử cho chức năng New Customer

Chức năng 'New Customer' yêu cầu kiểm tra nhiều trường dữ liệu với các ràng buộc khác nhau. Một kịch bản kiểm thử hiệu quả cần bao gồm các trường hợp: để trống các trường bắt buộc (như Customer Name, Address), nhập ký tự đặc biệt hoặc số vào trường chỉ cho phép chữ (ví dụ TC05, TC06), nhập dữ liệu có khoảng trắng ở đầu (TC08), và kiểm tra định dạng của các trường như PIN (phải đủ 6 số - TC23) và Email (phải đúng định dạng - TC30). Mỗi test case cần mô tả rõ các bước thực hiện (Steps), dữ liệu kiểm thử (Test Data), kết quả mong đợi (Expected Result) và kết quả thực tế (Test Result). Việc này giúp chuẩn hóa quá trình thực thi và dễ dàng xác định các sai lệch so với yêu cầu.

3.2. Áp dụng kiểm thử thủ công và ghi nhận kết quả

Trong khuôn khổ của đồ án kiểm thử phần mềm này, kiểm thử thủ công là phương pháp chính được áp dụng. Kỹ sư kiểm thử sẽ thực hiện từng bước trong test case đã thiết kế, nhập dữ liệu và quan sát hành vi của hệ thống. Mọi kết quả, dù là 'Passed' hay 'Failed', đều phải được ghi nhận một cách cẩn thận. Khi một test case 'Failed', điều đó có nghĩa là một lỗi tiềm tàng đã được phát hiện. Kỹ sư cần ghi lại chi tiết các bước tái hiện lỗi (Steps to Reproduce), kết quả quan sát được (Observed Result) so với kết quả mong đợi. Toàn bộ thông tin này sẽ là đầu vào quan trọng cho việc tạo một báo cáo kiểm thử và báo cáo lỗi chi tiết ở giai đoạn sau.

IV. Phương pháp quản lý lỗi Bug hiệu quả trong dự án

Tìm ra lỗi chỉ là một phần của quy trình kiểm thử. Phần quan trọng không kém là quản lý, theo dõi và báo cáo lỗi một cách hiệu quả. Một quy trình quản lý lỗi (bug tracking) chuyên nghiệp đảm bảo rằng mọi lỗi được phát hiện đều được ghi nhận, phân loại, gán cho lập trình viên để sửa chữa, và kiểm tra lại sau khi đã được khắc phục. Trong đề tài kiểm thử trên hệ thống the guru99 bank, việc ghi lại danh sách bug một cách chi tiết đã cho thấy tầm quan trọng của việc này. Mỗi bug được mô tả rõ ràng với ID, tóm tắt (Summary), các bước tái hiện và kết quả quan sát, giúp đội phát triển nhanh chóng xác định nguyên nhân và đưa ra giải pháp.

4.1. Phân tích các lỗi nghiêm trọng được phát hiện trên Guru99

Tài liệu nghiên cứu đã chỉ ra một số lỗi đáng chú ý trong hệ thống. Ví dụ, Bug ID 03 mô tả một vấn đề logic trong việc xác thực dữ liệu: 'Users can enter disallowed formats after getting a leading whitespace error'. Lỗi này cho thấy hệ thống không xử lý đúng các trường hợp xác thực liên tiếp. Một lỗi khác là Bug ID 04, khi hệ thống không hiển thị thông báo lỗi khi người dùng nhập mã PIN nhiều hơn 6 chữ số. Đây là những lỗi liên quan đến kiểm thử giao diện (UI testing) và xác thực đầu vào, nếu không được khắc phục có thể dẫn đến dữ liệu không nhất quán và trải nghiệm người dùng kém. Việc phân tích các lỗi này giúp hiểu rõ hơn về những điểm yếu của hệ thống.

4.2. Hướng dẫn tạo báo cáo kiểm thử Test Report chuyên nghiệp

Một báo cáo kiểm thử (Test Report) hay báo cáo bug cần cung cấp đầy đủ thông tin nhưng phải ngắn gọn và dễ hiểu. Báo cáo cần bao gồm các mục chính: Tóm tắt (Summary) mô tả ngắn gọn về lỗi; Mô tả chi tiết (Description); Các bước tái hiện (Steps to Reproduce) là phần quan trọng nhất, cần được liệt kê rõ ràng, tuần tự; Kết quả mong đợi (Expected Result) dựa trên tài liệu đặc tả; và Kết quả quan sát được (Observed Result) là những gì thực sự xảy ra. Ngoài ra, cần đính kèm các bằng chứng như ảnh chụp màn hình hoặc video. Một báo cáo tốt giúp loại bỏ sự mơ hồ và tăng tốc độ sửa lỗi, là một kỹ năng không thể thiếu của kỹ sư kiểm thử.

V. Kết luận và bài học từ đồ án kiểm thử phần mềm này

Hoàn thành đề tài kiểm thử trên hệ thống the guru99 bank mang lại nhiều kết quả và bài học quý giá. Quá trình này không chỉ là việc thực thi các test case mà còn là một chu trình hoàn chỉnh từ phân tích, lập kế hoạch, thực thi, báo cáo lỗi và tổng kết. Các số liệu thống kê về tổng số test case đã thực hiện và số bug tìm thấy ở mỗi phiên bản đã cung cấp một bức tranh rõ ràng về chất lượng của sản phẩm qua từng giai đoạn. Đây là minh chứng rõ nét cho vai trò không thể thiếu của kiểm thử phần mềm trong việc đảm bảo một sản phẩm công nghệ thông tin hoạt động đúng đắn, ổn định và đáp ứng được kỳ vọng của người dùng cuối.

5.1. Tổng kết số liệu và đánh giá chất lượng hệ thống

Qua hai phiên bản kiểm thử, tài liệu đã ghi nhận tổng cộng 67 test case được thực thi. Ở phiên bản thứ nhất, 31 test case được thực hiện và đã phát hiện ra 6 lỗi. Ở phiên bản thứ hai, 36 test case tiếp theo được thực hiện, cho thấy sự nỗ lực trong việc mở rộng phạm vi kiểm thử. Tổng kết cuối cùng cho thấy toàn bộ 67 test case đã được thực hiện và 6 bug đã được ghi nhận. Các con số này không chỉ đo lường khối lượng công việc mà còn là một chỉ số quan trọng để đánh giá chất lượng phần mềm. Việc theo dõi các số liệu này qua từng phiên bản giúp đội ngũ dự án có cái nhìn khách quan về sự cải thiện của sản phẩm và hiệu quả của quy trình kiểm thử.

5.2. Bài học kinh nghiệm và định hướng phát triển tương lai

Bài học lớn nhất rút ra từ đồ án kiểm thử phần mềm này là tầm quan trọng của sự tỉ mỉ và một quy trình có hệ thống. Việc tuân thủ các nguyên tắc kiểm thử, thiết kế test case cẩn thận và báo cáo lỗi rõ ràng là chìa khóa thành công. Đồng thời, dự án cũng cho thấy sự cần thiết của việc áp dụng các công cụ hỗ trợ như Selenium WebDriver cho kiểm thử tự động trong các dự án lớn hơn để tăng tốc độ và độ bao phủ. Trong tương lai, kỹ sư kiểm thử cần tiếp tục trau dồi kỹ năng phân tích yêu cầu, học thêm về các công cụ tự động hóa và các phương pháp kiểm thử phi chức năng như kiểm thử hiệu năng và bảo mật để đáp ứng yêu cầu ngày càng cao của ngành công nghiệp phần mềm.

11/07/2025

Trích đoạn nội dung tài liệu

CHƯƠNG 1: TỔNG QUAN 1.1 Khái niệm kiểm thử phần mềm Cùng với phát triển phần mềm, kiểm thử phần mềm cũng có nhiều định nghĩa khác nhau được phát biểu bởi nhiều tổ chức hay cá nhân khác nhau. Theo Myer (1979, Chương 10): “Kiểm thử là quá trình thực thi một chương trình với mục đích tìm ra lỗi.” Theo như định nghĩa này, quá trình kiểm thử bao gồm tất cả các hoạt động từ kiểm tra mã nguồn đến chạy thử chương trình. Theo IEEE Std 610.12 (IEEE, 1990): Kiểm thử phần mềm là quá trình phân tích các yếu tố phần mềm để phát hiện những khác biệt giữa chương trình với các điều kiện yêu cầu và đánh giá các đặc điểm của các yếu tố phần mềm. Theo Daniell Galin: Kiểm thử phần mềm là một quá trình được tiến hành bởi một nhóm chuyên viên kiểm thử, trong đó một đơn vị phần mềm, một nhóm các đơn vị được tích hợp, hoặc cả gọi phần mềm được kiểm tra bằng cách chạy chương trình trên máy tính.

Tất cả các bước kiểm tra liền được tiến hành theo các quy trình kiểm thử và được thông qua ca kiểm thử. - Vai trò kiểm thử phần mềm:  Giảm mức độ rủi ro, tăng chất lượng sản phẩm phần mềm: sản phẩm phần mềm được kiểm tra sẽ đảm bảo được độ tin cậy, hiệu suất hoạt động cao, đảm bảo được các yêu cầu, tính năng cần thiết của nó. Sản phẩm đưa đến tay khách hàng phải là một sản phẩm đạt đủ các yêu cầu của khách hàng về hình thức, giao diện, cấu trúc, tính năng,. và đảm bảo không còn bất cứ lỗi nào trên sản phẩm.

 Gia tăng sự hài lòng của khách hàng: Một sản phẩm càng chỉn chu, càng hoàn thiện, chất lượng càng cao sẽ tạo ra những trải nghiệm người dùng tốt nhất, từ đó càng tạo được niềm tin và uy tín với khách hàng và đối tác. 1 Đề tài: Kiểm thử trên hệ thống The Guru99 Bank  Gia tăng tính bảo mật: Sản phẩm được phát hiện và sửa lỗi giúp loại bỏ các rủi ro và các vấn đề sớm, làm tăng độ tin cậy cho sản phẩm. Đối với ngành công nghệ phần mềm, vấn đề bảo mật là yếu tố cực kỳ nhạy cảm, nó liên quan trực tiếp đến việc sở hữu, sử dụng của người dùng. Vì vậy, việc kiểm thử phần mềm giúp hoàn thiện nhất sản phẩm phần mềm, tránh những lỗ hổng bảo mật đáng tiếc, tăng độ tin tưởng cho người sử dụng.

 Tiết kiệm thời gian, tiền bạc: Kiểm thử phần mềm giúp nhanh chóng phát hiện các lỗi của phần mềm, giúp giảm chi phí sửa chữa.2 Các nguyên tắc kiểm thử phần mềm - Để kiểm thử đạt hiệu quả thì khi tiến hành kiểm thử phần mềm cần phải tuân thủ một số quy tắc sau:  Quy tắc 1: Kiểm thử đưa ra lỗi Kiểm thử có thể cho thấy rằng phần mềm đang có lỗi, nhưng không thể chứng minh rằng phần mềm không có lỗi. Kiểm thử được thực hiện bằng những kĩ thuật khác nhau. Kiểm thử làm giảm xác suất lỗi chưa tìm thấy vẫn còn trong phần mềm, ngay cả khi đã kiểm thử nghiêm ngặt phần mềm vẫn có thể còn lỗi. Vì vậy chúng ta phải tìm được càng nhiều lỗi càng tốt  Quy tắc 2: Kiểm thử cạn kiệt là không thể Nguyên tắc này nói rằng kiểm tra mọi thứ trong phần mềm một cách trọn vẹn là không thể.

Kiểm thử với tất cả các kết hợp đầu vào và đầu ra, với tất cả các kịch bản là không thể trừ phi nó chỉ bao gồm ít trường hợp thì có thể kiểm thử toàn bộ. Thay vì kiểm thử toàn bộ, việc phân tích rủi ro và dựa trên sự mức độ ưu tiên chúng ta có thể tập trung việc kiểm thử vào một số điểm cần thiết, có nguy cơ lỗi cao hơn.  Quy tắc 3: Kiểm thử càng sớm càng tốt Nguyên tắc này yêu cầu bắt đầu thử nghiệm phần mềm trong giai đoạn đầu của vòng đời phát triển phần mềm. Các hoạt động kiểm thử phần mềm từ 2 Đề tài: Kiểm thử trên hệ thống The Guru99 Bank giai đoạn đầu sẽ giúp phát hiện bug sớm hơn.

Nó cho phép chuyển giao phần mềm theo yêu cầu đúng thời gian với chất lượng dự kiến  Quy tắc 4: Sự tập trung của lỗi Thông thường, lỗi tập trung vào những module, thành phần chức năng chính của hệ thống. Nếu xác định được điều này bạn sẽ tập trung vào tìm kiếm lỗi quanh khu vực được xác định. Nó được coi là một trong những cách hiệu quả nhất để thực hiện kiểm tra hiệu quả.  Quy tắc 5: Nghịch lí thuốc trừ sâu Nếu bạn sử dụng cùng một tập hợp các trường hợp kiểm thử liên tục, sau đó một thời gian các trường hợp kiểm thử không tìm thấy lỗi nào mới.

Hiệu quả của các trường hợp kiểm thử bắt đầu giảm xuống sau một số lần thực hiện, vì vậy luôn luôn chúng ta phải luôn xem xét và sửa đổi các trường hợp kiểm thử trên một khoảng thời gian thường xuyên.  Quy tắc 6: Kiểm thử phụ thuộc vào ngữ cảnh Theo nguyên tắc này thì việc kiểm thử phụ thuộc vào ngữ cảnh và chúng ta phải tiếp cận kiểm thử theo nhiều ngữ cảnh khác nhau. Nếu bạn đang kiểm thử ứng dụng web và ứng dụng di động bằng cách sử dụng chiến lược kiểm thử giống nhau, thì đó là sai. Chiến lược để kiểm thử ứng dụng web sẽ khác với kiểm thử ứng dụng cho thiết bị di động của Android.

 Quy tắc 7: Không có lỗi - Sai lầm Việc không tìm thấy lỗi trên sản phẩm không đồng nghĩa với việc sản phẩm đã sẵn sàng để tung ra thị trường. Việc không tìm thấy lỗi cũng có thể là do bộ trường hợp kiểm thử được tạo ra chỉ nhằm kiểm tra những tính năng được làm đúng theo yêu cầu thay vì nhằm tìm kiếm lỗi mới.3 Các cấp độ kiểm thử phần mềm Kiểm thử phần mềm gồm có các cấp độ: Kiểm thử đơn vị, Kiểm thử tích hợp, Kiểm thử hệ thống và Kiểm thử chấp nhận sản phẩm. 3 Đề tài: Kiểm thử trên hệ thống The Guru99 Bank Hình 1. 1 Các mức độ kiểm thử Để thấy được rõ hơn về các cấp độ kiểm thử trong từng giai đoạn phát triển phần mềm, các cấp độ kiểm thử phần mềm thể hiện trong mô hình phát triển thác nước của vòng đời phát triển phần mềm dưới đây: Hình 1.

2 Vòng đời phát triển phần mềm 1.1 Kiểm thử đơn vị Một đơn vị chương trình là một thành phần phần mềm nhỏ nhất mà ta có thể kiểm thử được. Ví dụ, các hàm (Function), thủ tục (Procedure), lớp (Class) hay phương thức (Method) đều có thể được xem là đơn vị. Mỗi đơn vị chương trình được chọn để kiểm tra thường có kích thước nhỏ và chức năng hoạt động đơn giản, chúng ta không khó khăn gì trong việc tổ chức kiểm thử, ghi nhận và phân tích kết quả kiểm thử. Nếu phát hiện lỗi, 4 Đề tài: Kiểm thử trên hệ thống The Guru99 Bank việc xác định nguyên nhân và khắc phục cũng tương đối dễ dàng vì chỉ khoanh vùng trong một đơn vị đang kiểm tra.

Một nguyên lý đúc kết từ thực tiễn: thời gian tốn cho kiểm thử đơn vị sẽ được đền bù bằng việc tiết kiệm rất nhiều thời gian và chi phí cho việc kiểm thử và sửa lỗi ở các mức kiểm thử sau đó. Kiểm thử đơn vị thường do lập trình viên thực hiện. Công đoạn này cần được thực hiện càng sớm càng tốt trong giai đoạn lập trình và xuyên suốt chu kỳ phát triển phần mềm. Thông thường, kiểm thử đơn vị đòi hỏi kiểm thử viên có kiến thức về thiết kế và mã nguồn của chương trình.

Mục đích của kiểm thử đơn vị là bảo đảm thông tin được xử lý và xuất (khỏi đơn vị) là chính xác, trong mối tương quan với dữ liệu nhập và chức năng của đơn vị. Điều này thường đòi hỏi tất cả các nhánh bên trong đơn vị đều phải được kiểm tra để phát hiện nhánh phát sinh lỗi. Một nhánh thường là một chuỗi các lệnh được thực thi trong một đơn vị. Ví dụ: chuỗi các lệnh sau điều kiện If và nằm giữa then.

else là một nhánh. Thực tế việc chọn lựa các nhánh để đơn giản hóa việc kiểm thử và quét hết đơn vị đòi hỏi phải có kỹ thuật, đôi khi phải dùng thuật toán để chọn lựa Cùng với các mục kiểm thử khác, kiểm thử đơn vị cũng đòi hỏi phải chuẩn bị trước các ca kiểm thử (Test case) hoặc kịch bản kiểm thử (Test script), trong đó chỉ định rõ dữ liệu đầu vào, các bước thực hiện và dữ liệu đầu ra mong muốn. Các ca kiểm thử và kịch bản kiểm thử này nên được giữ lại để tái sử dụng.2 Kiểm thử tích hợp Kiểm thử tích hợp kết hợp các thành phần của một ứng dụng và kiểm thử như một ứng dụng đã hoàn thành. Trong khi kiểm thử đơn vị kiểm tra các thành phần và đơn vị riêng lẻ thì kiểm thử tích hợp kết hợp chúng lại với nhau và kiểm tra sự giao tiếp giữa chúng.

- Hai mục tiêu chính của kiểm thử tích hợp: 5 Đề tài: Kiểm thử trên hệ thống The Guru99 Bank  Phát hiện lỗi giao tiếp xảy ra giữa các đơn vị.  Tích hợp các đơn vị đơn lẻ thành các hệ thống nhỏ (Subsystem) và cuối cùng là nguyên hệ thống hoàn chỉnh (System) chuẩn bị cho kiểm thử ở mức hệ thống (System Test). Trong kiểm thử đơn vị, lập trình viên cố gắng phát hiện lỗi liên quan đến chức năng và cấu trúc nội tại của đơn vị. Có một số phép kiểm thử đơn giản trên giao tiếp giữa đơn vị với các thành phần liên quan khác, tuy nhiên mọi giao tiếp liên quan đến đơn vị chỉ thật sự được kiểm tra đầy đủ khi các đơn vị tích hợp với nhau trong khi thực hiện kiểm thử tích hợp.

Trừ một số ít ngoại lệ, kiểm thử tích hợp chỉ nên thực hiện trên những đơn vị đã được kiểm tra cẩn thận trước đó bằng kiểm thử đơn vị, và tất cả các lỗi mức đơn vị đã được sửa chữa. Một số người hiểu sai rằng đơn vị một khi đã qua giai đoạn kiểm thử đơn vị với các giao tiếp giả lập thì không cần phải thực kiểm thử tích hợp nữa. Thực tế việc tích hợp giữa các đơn vị dẫn đến những tình huống hoàn toàn khác. Một chiến lược cần quan tâm trong kiểm thử tích hợp là nên tích hợp dần từng đơn vị.

Một đơn vị tại một thời điểm được tích hợp vào một nhóm các đơn vị khác đã tích hợp trước đó và đã hoàn tất các đợt kiểm thử tích hợp trước đó.

Nội dung được bảo vệ bản quyền — Tải xuống đầy đủ