Các mức độ trong kiểm thử phần mềm

Có nhiều mức độ trong quá trình kiểm thử phần mềm như kiểm thử chức năng, kiểm thử phi chức năng, kiểm thử đơn vị, kiểm thử tích hợp, kiểm thử hệ thống, kiểm thử chấp nhận... Bài viết này sẽ mô tả các mức độ đó.

Các mức độ trong kiểm thử bao gồm nhiều phương pháp khác nhau được sử dụng trong khi tiến hành kiểm thử phần mềm. Các mức độ chính của kiểm thử phần mềm là:

• Kiểm thử chức năng
• Kiểm thử phi chức năng

1. Kiểm thử chức năng (Functional Testing)

Đây là một loại của kiểm thử hộp đen dựa trên các thông số kỹ thuật của phần mềm đã được kiểm tra. Ứng dụng được kiểm thử bằng cách cung cấp các đầu vào, sau đó kiểm tra kết quả có phù hợp với chức năng đã được thiết kế hay không. Kiểm thử chức năng được tiến hành khi phần mềm các chức năng đã được xây dựng hoàn thành, tích hợp vào hệ thống để đánh giá mức chính xác của hệ thống với yêu cầu của người dùng.

Dưới đây là các bước trong kiểm thử chức năng của phần mềm:

Bài viết này được đăng tại [free tuts .net]

Thực hiện kiểm thử hiệu quả sẽ áp dụng các bước ở trên cho các chính sách thử nghiệm của mọi tổ chức và từ đó nó sẽ đảm bảo để các tổ chức duy trì các tiêu chuẩn nghiêm ngặt nhất khi nhắc đến chất lượng phần mềm.

2. Kiểm thử đơn vị (Unit testing)

Loại kiểm thử này được thực hiện bởi những Developer trước khi chuyển giao cho đội Tester chính thức bắt đầu chạy các trường hợp kiểm thử (test cases). Unit testing được thực hiện bởi chính lập trình viên đó theo những đơn vị mã nguồn tương ứng được chỉ định. Lập trình viên sử dụng dữ liệu kiểm thử khác nhau từ testcase để đảm bảo chất lượng.

Mục đích của Unit testing là cô lập từng phần chương trình và cho thấy rằng những phần riêng lẻ đáp ứng các yêu cầu và chức năng.

Hạn chế của Unit Testing:

• Kiểm thử không thể bắt hết lỗi trong phần mềm. Không thể đánh giá được các luồng thực hiện trong mỗi phần mềm và Unit Testing cũng vậy.
• Có giới hạn về số lượng kịch bản và dữ liệu kiểm thử mà lập trình viên có thể sử dụng để xác minh mã nguồn. Sau khi đã chay hết các trường hợp kiểm thử, không có lựa chọn nào khác ngoài việc dừng Unit Testing và tích hợp các phân đoạn mã nguồn với các thành phần khác.

3. Kiểm thử tích hợp (Integration Testing)

Integration Testing được định nghĩa như kiểm thử kết hợp các phần của ứng dụng để xác định các chức năng chạy đúng. Có hai cách kiểm thử tích hợp:

• Kiểm thử tích hợp từ trên xuống (Bottom-up integration testing).
• Kiểm thử tích hợp từ dưới lên (Top-down integration testing).

Trong môi trường phát triển phần mềm hiện nay, kiểm thử từ dưới lên luôn được hoàn thành trước, tiếp theo là kiểm thử từ trên xuống. Quá trình này sẽ kết thúc sau nhiều vòng kiểm thử trên phần mềm hoàn chỉnh, tốt nhât là thiết kế kịch bản giả lập được các tình huống thực tế.

4. Kiểm thử hệ thống (System Testing)

System Testing là kiểm thử toàn bộ hệ thống. Khi tất cả các thành phần được tích hợp, toàn bộ phần mềm được kiểm thử một cách nghiêm ngặt để thấy rằng nó đáp ứng các tiêu chuẩn chất lượng. Loại kiểm thử này được thực hiện bởi nhóm tester có kiến thức về hệ thống.

System Testing rất quan trọng vì những lý do sau:

• System Testing là bước đầu tiên trong vòng đời phát triển phần mềm (Software Development Life Cycle), giai đoạn mà hệ thống sẽ được kiểm thử toàn bộ.
• Ứng dụng được kiểm tra kỹ càng để xác minh rằng các chức năng và thông số kỹ thuật của nó có được đáp ứng.
• Ứng dụng được kiểm thử trong môi trường rất giống với môi trường thật, nơi mà các ứng dụng phần mềm được triển khai.
• System Testing cho phép chúng ta kiểm tra, xác minh và xác nhận cả những yêu cầu chức năng cũng như phi chức năng.

5. Kiểm thử hồi quy  (Regression testing)

Có bất cứ sự thay đổi trong một ứng dụng phần mềm sẽ hoàn toàn có thể gây ảnh hưởng tới những thành phần khác. Regression testing được thực hiện để xác minh rằng các lỗi đã được sửa không làm thay đổi kết quả của chức năng khác hoặc ảnh hưởng đến các thành phần khác. Mục đích của Regression testing là để đảm bảo rằng thay đổi sẽ không dẫn đến lỗi khác được phát sinh trong ứng dụng phần mềm.

Regression testing được coi là quan trọng vì những lý do sau:

• Regression testing giúp giảm thiểu lỗ hổng trong kiểm thử khi một ứng dụng có thay đổi.
• Kiểm thử các thay đổi mới để xác minh các thay đổi không ảnh hưởng đến bất kỳ phần nào của ứng dụng.
• Giảm thiểu rủi ro khi Regression testing trên ứng dụng.
• Chất lượng phần mềm được tăng cường mà không ảnh hưởng đến mốc thời gian (timelines).
• Tăng tốc độ release sản phẩm.

6. Kiểm thử chấp nhận (Acceptance Testing)

Đây được coi là một trọng những loại kiểm thử quan trọng và được thực hiện bởi nhóm đảm bảo chất lượng (QA Team), nó sẽ đánh giá ứng dụng liệu có thể đáp ứng các thông số kỹ thuật và yêu cầu của khách hàng hay không. Nhóm QA sẽ có một bộ kịch bản được viết sẵn và sẽ được sử dụng để kiểm thử ứng dụng.

Nhiều ý tưởng về ứng dụng sẽ được chia sẻ và có thể thực hiện nhiều testcase hơn để đánh giá độ chính xác về sản phẩm, đó là lý do tại sao dự án được bắt đầu. Acceptance Testing không chỉ đưa ra các lỗi chính tả đơn giản, lỗi giao diện hoặc làm giảm các lỗi, mà còn chỉ ra những lỗi thiết kế có thể gây ra sự cố hệ thống hoặc lỗi nghiêm trọng trong ứng dụng.

Nhóm kiểm thử sẽ kết luận làm thế nào để bàn giao sản phẩm. Ngoài ra còn có các yêu cầu pháp lý và hợp đồng để chấp nhận hệ thống. 

7. Kiểm thử alpha (Alpha Testing)

Thử nghiệm này là giai đoạn đầu tiên của kiểm thử được thực hiện nội bộ giữa các team (lập trình viên và QA). Kiểm thử đơn vị, kiểm thử tích hợp và kiểm thử hệ thống được kết hợp với nhau gọi là kiểm thử alpha. Trong giai đoạn này, các vấn đề sau sẽ được kiểm tra trong ứng dụng:

• Lỗi chính tả
• Liên kết bị hỏng
• Định hướng của trang
• Phần mềm sẽ được kiểm thử trên các thiết bị có đặc điểm kỹ thuật thấp nhất để kiểm tra thời gian tải và bất kỳ vấn đề về độ trễ nào.

8. Kiểm thử beta (Beta Testing)

Loại kiểm thử này được thực hiện sau khi thử nghiệm alpha đã được thực hiện xong. Beta Testing cũng được biết đến như là kiểm thử sản phẩm trước khi phát hành sản phẩm (pre-release testing). Phiên bản kiểm thử beta của phần mềm được phân phối cho nhiều đối tượng dùng thử, một phần sẽ đưa chương trình thử nghiệm ra "thế giới thực", một phần sẽ cung cấp bản Preview của đợt phát hành tới. Trong giai đoạn này, những người được thử nghiệm sẽ kiểm tra những vấn đề sau:

• Người dùng cài đặt, chạy ứng dụng phần mềm và gửi phản hồi tới nhóm dự án.
• Tạo lỗi chính tả, gây rối loạn chương trình và tạo ra những sự cố.
• Khi nhận được phản hồi, nhóm dự án có thể khắc phục các vấn đề trước khi phát hành phần mềm cho người dùng thực tế.
• Giải quyết được các vấn đề của người dùng thực tế, chất lượng ứng dụng sẽ càng cao hơn.
• Ứng dụng có chất lượng cao hơn khi phát hành sẽ làm tăng sự hài lòng của khách hàng.

9. Kiểm thử phi chức năng (Non-Functional Testing)

Thực hiện loại kiểm thử này dựa trên việc kiểm thử một ứng dụng từ các thuộc tính phi chức năng của phần mềm. Non-Functional Testing liên quan đến việc kiểm thử phần mềm từ những yêu cầu phi chức năng nhưng quan trọng như hiệu suất, bảo mật, giao diện người dùng, v.v…

Một số loại kiểm thử Non-Functional Testing quan trọng:

Kiểm thử hiệu năng (Performance testing)

Thực hiện loại kiểm thử này nhằm xác định hệ thống có thê hoạt động ổn định và đáp ứng với yêu cầu tải cao hay không. Chủ yếu được sử dụng để xác định các vấn đề về hiệu năng hơn là tìm lỗi một phần mềm. Có nhiều nguyên nhân khác nhau góp phần làm giảm hiệu năng của phần mềm.

• Độ trễ mạng.
• Xử lý phía máy trạm.
• Xử lý giao dịch CSDL.
• Tải cân bằng giữa các máy chủ.
• Biên dịch dữ liệu.

Performance testing được coi là một trong những loại kiểm thử quan trọng và bắt buộc thể hiện dưới khía cạnh sau:

• Tốc độ
• Sức chứa
• Khả năng ổn định
• Khả năng mở rộng

Performance testing có thể là định tính hoặc định lượng, có thể chia thành các loại khác nhau như Load testing và Stress testing.

Load testing

Là một quá trình kiểm thử hiệu năng của một phần mềm bằng cách áp dụng tải tối đa về mặt phần mềm truy cập và thao tác với dữ liệu đầu vào lớn. Load testing có thể được thực hiện ở cả hai điều kiện tải trọng bình thường và cao điểm. Loại kiểm thử này xác định hiệu suất tối đa của phần mềm và hiệu suất của phần mềm vào thời gian cao điểm.

Load testing được thực hiện với sự trợ giúp của các công cụ tự động như Load Runner, AppLoader, IBM Rational Performance Tester, Apache JMeter, Silk Performer, Visual Studio Load Test, v.v..

Người dùng ảo (Vusers) được xác định trong công cụ kiểm thử tự động và tập lệnh được thực hiện để xác minh việc tải cho phần mềm. Số lượng người dùng có thể được tăng hoặc giảm đồng thời hoặc thực hiện dựa trên các yêu cầu.

Stress testing

Stress testing là kiểm thử hiệu năng của phần mềm trong điều kiện bất thường. Ví du:  có thể bỏ đi một số tài nguyên hoặc áp dụng tải trọng vượt quá giới hạn thực tế.

Mục đích của Stress testing là kiểm thử phần mềm bằng cách áp dụng tải trọng cho hệ thống và tiếp nhận các tài nguyên được phần mềm sử dụng để xác định điểm phá vỡ. Stress testing có thể được thực hiện bằng cách kiểm tra các kịch bản như sau:

• Tắt/bật các cổng mạng ngẫu nhiên.
• Tắt/bật CSDL.
• Chạy các chương trình tiêu thụ tài nguyên CPU, bộ nhớ, máy chủ,…

10. Kiểm thử tính hữu dụng (Usability testing)

Usability testing là một kỹ thuật hộp đen và được sử dụng để xác định lỗi và cải tiến trong phần mềm bằng đánh giá giao diện người dùng.

Theo Nielsen, Usability testing có thể được xác định theo năm yếu tố: dễ sử dụng, dễ tìm hiểu, dễ nhớ, an toàn và thỏa mãn nhu cầu người dùng. 

Nigel Bevan và Mecleod cho rằng khả năng sử dụng là yêu cầu chất lượng có thể được đo lường như là kết quả của sự tương tác với một hệ thống máy tính. Yêu cầu này có thể được đáp ứng và end-user sẽ hài lòng nếu mục tiêu đự định đạt được và hiệu quả với việc sử dụng các tài nguyên thích hợp.

Molich vào năm 2000 đã tuyên bố một hệ thống thân thiện với người dùng phải hoàn thành năm mục tiêu sau: dễ nghiên cứu, dễ nhớ, hiệu quả, thỏa mãn yêu cầu sử dụng và dễ hiểu.

Ngoài các định nghĩa  về khả năng sử dụng, cố một số tiêu chuẩn mô hình chất lượng và phương pháp xác định khả năng sử dụng như: ISO-9126, ISO-9241-11, ISO-13407 và IEEE std. 610,12,…

11. Kiểm thử Giao diện người dùng và kiểm thử tính hữu dụng (UI and Usability testing)

Kiểm thử giao diện người dùng liên quan đến việc kiểm tra giao diện đồ họa người dùng. Kiểm thử giao diện người dùng đảm bảo rằng các chức năng giao diện người dùng (GUI) theo yêu cầu và được kiểm thử về màu sắc, căn chỉnh, kích thước và các thuộc tính khác.

Mặc khác, kiểm thử tính hữu dụng đảm bảo giao diện người dùng thân thiện, dễ sử dụng có thể dễ dàng xử lý. Kiểm thử giao diện người dùng có thể được coi là một phần của kiểm thử tính hữu dụng.

12. Kiểm thử bảo mật (Security testing)

Kiểm thử bảo mật liên quan đến việc kiểm thử phần mềm để xác định bất kỳ sai sót và lỗ hổng, xử lý bảo mật dữ liệu và ngăn chặn sự mọi sự xâm nhập vào hệ thống. Dưới đây liệt kê các khía cạnh chính mà Security testing phải đảm bảo:

• Tính Bảo mật
• Tính đúng đắn
• Tính Xác thực
• Tính Khả dụng
• Tính  Ủy quyền
• Ngăn chăn các lỗ hổng bảo mật
• Phần mềm được an toàn
• Dữ liệu phần mềm được bảo mật
• Phần mềm tuân theo mọi quy định bảo mật
• Kiểm tra và xác thực đầu vào
• Tấn công thêm dữ liệu SQL
• Tấn công những sai sót
• Vấn đề quản lý phiên
• Tấn công Cross-Site Scripting(CSS)
• Các lỗ hổng tràn Buffer
• Tấn công qua các thư mục 

13. Kiểm thử tính di động (Portability testing)

Kiểm thử tính di động bao gồm thử nghiệm một phần mềm với mục đích đảm bảo khả năng tái sử dụng và có thể được chuyển sang một phần mềm khác. Sau đây là các chiến lược có thể được sử dụng để kiểm thử tính di động:

• Chuyển phần mềm đã cài đặt từ máy hiện tại sang máy khác.
• Xây dựng các testcase để chạy trên nhiều nền tảng khác nhau.

Kiểm thử di động có thể được coi như một trong kiểm thử hệ thống, loại kiểm thử này liên quan đến việc sử dụng trên các môi trường khác nhau. Phần cứng máy tinh, hệ điều hành và trình duyệt là trọng tâm chính của kiểm thử tính di động. Có một số điều kiện kiểm thử tính di động như sau:

• Phần mềm nên được thiết kế và phát triển, thỏa mãn các yêu cầu về tính di động.
• Kiểm thử đơn vị đã được thực hiện trên các thành phần liên quan.
• Kiểm thử tích hợp đã được thực hiện.
• Môi trường thử nghiệm đã được thiết lập.