Kiểm thử phần mềm - Cấp độ
Có các mức độ khác nhau trong quá trình thử nghiệm. Trong chương này, mô tả ngắn gọn được cung cấp về các cấp độ này.
Các cấp độ kiểm thử bao gồm các phương pháp luận khác nhau có thể được sử dụng trong khi tiến hành kiểm thử phần mềm. Các cấp độ chính của kiểm thử phần mềm là -
Thử nghiệm chức năng
Kiểm tra phi chức năng
Thử nghiệm chức năng
Đây là một loại kiểm thử hộp đen dựa trên các thông số kỹ thuật của phần mềm sẽ được kiểm tra. Ứng dụng được kiểm tra bằng cách cung cấp đầu vào và sau đó kết quả được kiểm tra xem cần phải phù hợp với chức năng mà nó dự kiến. Kiểm tra chức năng của một phần mềm được tiến hành trên một hệ thống tích hợp, hoàn chỉnh để đánh giá sự tuân thủ của hệ thống với các yêu cầu cụ thể của nó.
Có năm bước liên quan trong khi kiểm tra một ứng dụng về chức năng.
| Các bước | Sự miêu tả |
|---|---|
| Tôi | Việc xác định chức năng mà ứng dụng dự kiến sẽ thực hiện. |
| II | Việc tạo ra dữ liệu thử nghiệm dựa trên các thông số kỹ thuật của ứng dụng. |
| III | Kết quả dựa trên dữ liệu thử nghiệm và các thông số kỹ thuật của ứng dụng. |
| IV | Việc viết các kịch bản kiểm thử và thực hiện các trường hợp kiểm thử. |
| V | So sánh kết quả thực tế và kết quả mong đợi dựa trên các trường hợp thử nghiệm đã thực hiện. |
Một thực hành kiểm thử hiệu quả sẽ thấy các bước trên được áp dụng cho các chính sách kiểm thử của mọi tổ chức và do đó nó sẽ đảm bảo rằng tổ chức duy trì các tiêu chuẩn nghiêm ngặt nhất về chất lượng phần mềm.
Kiểm tra đơn vị
Loại thử nghiệm này được thực hiện bởi các nhà phát triển trước khi thiết lập được bàn giao cho nhóm thử nghiệm để chính thức thực hiện các trường hợp thử nghiệm. Kiểm thử đơn vị được thực hiện bởi các nhà phát triển tương ứng trên các đơn vị riêng lẻ của các khu vực được chỉ định mã nguồn. Các nhà phát triển sử dụng dữ liệu thử nghiệm khác với dữ liệu thử nghiệm của nhóm đảm bảo chất lượng.
Mục tiêu của kiểm thử đơn vị là cô lập từng phần của chương trình và chỉ ra rằng các phần riêng lẻ là đúng về yêu cầu và chức năng.
Hạn chế của Kiểm thử đơn vị
Kiểm tra không thể bắt từng lỗi trong một ứng dụng. Không thể đánh giá mọi đường dẫn thực thi trong mọi ứng dụng phần mềm. Điều này cũng xảy ra với kiểm thử đơn vị.
Có giới hạn về số lượng kịch bản và dữ liệu thử nghiệm mà nhà phát triển có thể sử dụng để xác minh mã nguồn. Sau khi đã hết tất cả các tùy chọn, không có lựa chọn nào khác ngoài việc dừng thử nghiệm đơn vị và hợp nhất đoạn mã với các đơn vị khác.
Thử nghiệm hội nhập
Kiểm thử tích hợp được định nghĩa là kiểm tra các phần kết hợp của một ứng dụng để xác định xem chúng có hoạt động chính xác hay không. Kiểm thử tích hợp có thể được thực hiện theo hai cách: Kiểm thử tích hợp từ dưới lên và Kiểm thử tích hợp từ trên xuống.
| Sr.No. | Phương pháp kiểm tra tích hợp |
|---|---|
| 1 | Bottom-up integration Thử nghiệm này bắt đầu với thử nghiệm đơn vị, sau đó là thử nghiệm kết hợp cấp độ cao hơn dần dần của các đơn vị được gọi là mô-đun hoặc bản dựng. |
| 2 | Top-down integration Trong thử nghiệm này, các mô-đun cấp cao nhất được kiểm tra đầu tiên và dần dần, các mô-đun cấp thấp hơn được kiểm tra sau đó. |
Trong môi trường phát triển phần mềm toàn diện, kiểm tra từ dưới lên thường được thực hiện trước, sau đó là kiểm tra từ trên xuống. Quá trình kết thúc với nhiều thử nghiệm của ứng dụng hoàn chỉnh, tốt nhất là trong các tình huống được thiết kế để bắt chước các tình huống thực tế.
Thử nghiệm hệ thống
Kiểm thử hệ thống kiểm tra toàn bộ hệ thống. Khi tất cả các thành phần được tích hợp, toàn bộ ứng dụng sẽ được kiểm tra nghiêm ngặt để đảm bảo rằng nó đáp ứng các Tiêu chuẩn chất lượng được chỉ định. Loại thử nghiệm này được thực hiện bởi một nhóm thử nghiệm chuyên biệt.
Kiểm tra hệ thống rất quan trọng vì những lý do sau:
Kiểm thử hệ thống là bước đầu tiên trong Vòng đời phát triển phần mềm, nơi ứng dụng được kiểm tra tổng thể.
Ứng dụng được kiểm tra kỹ lưỡng để xác minh rằng nó đáp ứng các thông số kỹ thuật và chức năng.
Ứng dụng được thử nghiệm trong một môi trường rất gần với môi trường sản xuất nơi ứng dụng sẽ được triển khai.
Kiểm tra hệ thống cho phép chúng tôi kiểm tra, xác minh và xác nhận cả các yêu cầu nghiệp vụ cũng như kiến trúc ứng dụng.
Kiểm tra hồi quy
Bất cứ khi nào một thay đổi trong ứng dụng phần mềm được thực hiện, rất có thể các khu vực khác trong ứng dụng đã bị ảnh hưởng bởi thay đổi này. Kiểm tra hồi quy được thực hiện để xác minh rằng một lỗi đã sửa không dẫn đến vi phạm chức năng hoặc quy tắc kinh doanh khác. Mục đích của kiểm tra hồi quy là để đảm bảo rằng một thay đổi, chẳng hạn như sửa lỗi sẽ không dẫn đến một lỗi khác được phát hiện trong ứng dụng.
Kiểm tra hồi quy rất quan trọng vì những lý do sau:
Giảm thiểu khoảng trống trong quá trình kiểm thử khi một ứng dụng có các thay đổi được thực hiện phải được kiểm tra.
Kiểm tra các thay đổi mới để xác minh rằng các thay đổi được thực hiện không ảnh hưởng đến bất kỳ khu vực nào khác của ứng dụng.
Giảm thiểu rủi ro khi kiểm tra hồi quy được thực hiện trên ứng dụng.
Phạm vi kiểm tra được tăng lên mà không ảnh hưởng đến các mốc thời gian.
Tăng tốc độ tiếp thị sản phẩm.
Kiểm tra chấp nhận
Đây được cho là loại thử nghiệm quan trọng nhất, vì nó được tiến hành bởi Nhóm đảm bảo chất lượng, người sẽ đánh giá xem ứng dụng có đáp ứng các thông số kỹ thuật dự kiến và đáp ứng yêu cầu của khách hàng hay không. Nhóm QA sẽ có một tập hợp các kịch bản được viết sẵn và các trường hợp kiểm thử sẽ được sử dụng để kiểm tra ứng dụng.
Nhiều ý tưởng hơn sẽ được chia sẻ về ứng dụng và nhiều bài kiểm tra hơn có thể được thực hiện trên nó để đánh giá độ chính xác của nó và lý do tại sao dự án được bắt đầu. Các bài kiểm tra chấp nhận không chỉ nhằm mục đích chỉ ra các lỗi chính tả đơn giản, lỗi thẩm mỹ hoặc lỗ hổng giao diện mà còn để chỉ ra bất kỳ lỗi nào trong ứng dụng có thể dẫn đến sự cố hệ thống hoặc các lỗi lớn trong ứng dụng.
Bằng cách thực hiện các kiểm thử chấp nhận trên một ứng dụng, nhóm kiểm thử sẽ giảm bớt cách ứng dụng sẽ hoạt động trong quá trình sản xuất. 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.
Thử nghiệm alpha
Thử nghiệm này là giai đoạn đầu tiên của thử nghiệm và sẽ được thực hiện giữa các nhóm (nhóm phát triển và QA). Kiểm thử đơn vị, kiểm tra tích hợp và kiểm tra hệ thống khi kết hợp với nhau được gọi là kiểm tra alpha. Trong giai đoạn này, các khía cạnh sau sẽ được kiểm tra trong ứng dụng:
Lỗi đánh vần
Liên kết bị hỏng
Chỉ đường có mây
Ứng dụng sẽ được thử nghiệm trên các máy có thông số kỹ thuật thấp nhất để kiểm tra thời gian tải và mọi vấn đề về độ trễ.
Thử nghiệm Beta
Thử nghiệm này được thực hiện sau khi thử nghiệm alpha đã được thực hiện thành công. Trong thử nghiệm beta, một mẫu đối tượng dự kiến sẽ kiểm tra ứng dụng. Thử nghiệm beta còn được gọi làpre-release testing. Các phiên bản thử nghiệm beta của phần mềm được phân phối lý tưởng cho nhiều đối tượng trên Web, một phần để cung cấp cho chương trình một thử nghiệm "trong thế giới thực" và một phần để cung cấp bản xem trước của bản phát hành tiếp theo. Trong giai đoạn này, khán giả sẽ thử nghiệm những điều sau:
Người dùng sẽ cài đặt, chạy ứng dụng và gửi phản hồi của họ cho nhóm dự án.
Lỗi đánh máy, luồng ứng dụng khó hiểu và thậm chí là treo máy.
Nhận được phản hồi, nhóm dự án có thể khắc phục sự cố trước khi phát hành phần mềm cho người dùng thực tế.
Bạn càng khắc phục được nhiều vấn đề giải quyết được các vấn đề của người dùng thực thì chất lượng ứng dụng của bạn càng cao.
Có một ứng dụng chất lượng cao hơn khi bạn phát hành nó ra công chúng sẽ làm tăng sự hài lòng của khách hàng.
Kiểm tra phi chức năng
Phần này dựa trên việc kiểm tra một ứng dụng từ các thuộc tính phi chức năng của nó. Kiểm thử phi chức năng liên quan đến việc kiểm tra một phần mềm từ các yêu cầu về bản chất là 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ử phi chức năng quan trọng và thường được sử dụng được thảo luận dưới đây.
Kiểm tra năng suất
Nó chủ yếu được sử dụng để xác định bất kỳ tắc nghẽn hoặc các vấn đề về hiệu suất hơn là tìm lỗi trong một phần mềm. Có những nguyên nhân khác nhau góp phần làm giảm hiệu suất của phần mềm -
Mạng trễ
Xử lý phía máy khách
Xử lý giao dịch cơ sở dữ liệu
Cân bằng tải giữa các máy chủ
Kết xuất dữ liệu
Kiểm tra hiệu suất được coi là một trong những loại kiểm tra quan trọng và bắt buộc xét về các khía cạnh sau:
Tốc độ (tức là Thời gian phản hồi, kết xuất và truy cập dữ liệu)
Capacity
Stability
Scalability
Kiểm tra hiệu suất có thể là định tính hoặc định lượng và có thể được chia thành các loại phụ khác nhau như Load testing và Stress testing.
Kiểm tra tải
Nó là một quá trình kiểm tra hành vi của một phần mềm bằng cách áp dụng tải tối đa về phần mềm truy cập và thao tác dữ liệu đầu vào lớn. Nó có thể được thực hiện ở cả điều kiện tải bình thường và cao điểm. Loại thử nghiệm này xác định dung lượng tối đa của phần mềm và hành vi của nó vào thời gian cao điểm.
Hầu hết thời gian, kiểm tra tải đượ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 tra tự động và tập lệnh được thực thi để xác minh kiểm tra 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 tăng dần tùy theo yêu cầu.
Bài kiểm tra về áp lực
Kiểm tra căng thẳng bao gồm kiểm tra hành vi của một phần mềm trong các điều kiện bất thường. Ví dụ: nó có thể bao gồm việc lấy đi một số tài nguyên hoặc áp dụng tải vượt quá giới hạn tải thực tế.
Mục đích của kiểm thử căng thẳng là kiểm tra phần mềm bằng cách áp dụng tải lên hệ thống và tiếp quản các tài nguyên được sử dụng bởi phần mềm để xác định điểm đứt. Thử nghiệm này có thể được thực hiện bằng cách thử nghiệm các tình huống khác nhau như -
Tắt hoặc khởi động lại các cổng mạng ngẫu nhiên
Bật hoặc tắt cơ sở dữ liệu
Chạy các quy trình khác nhau tiêu tốn tài nguyên như CPU, bộ nhớ, máy chủ, v.v.
Kiểm tra khả năng sử dụng
Kiểm tra khả năng sử dụng là một kỹ thuật hộp đen và được sử dụng để xác định (các) lỗi và các cải tiến trong phần mềm bằng cách quan sát người dùng thông qua việc sử dụng và vận hành của họ.
Theo Nielsen, khả năng sử dụng có thể được định nghĩa theo năm yếu tố, tức là hiệu quả sử dụng, khả năng học hỏi, khả năng ghi nhớ, lỗi / an toàn và sự hài lòng. Theo ông, khả năng sử dụng của một sản phẩm sẽ tốt và hệ thống có thể sử dụng được nếu nó sở hữu những yếu tố trên.
Nigel Bevan và Macleod 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ư kết quả của các tương tác với hệ thống máy tính. Yêu cầu này có thể được đáp ứng và người dùng cuối sẽ hài lòng nếu các mục tiêu dự kiến đạt được một cách hiệu quả với việc sử dụng các nguồn lực thích hợp.
Molich năm 2000 đã tuyên bố rằng một hệ thống thân thiện với người dùng phải đáp ứng được năm mục tiêu sau, tức là dễ học, dễ nhớ, hiệu quả để sử dụng, dễ sử dụng và dễ hiểu.
Ngoài các định nghĩa khác nhau về khả năng sử dụng, có một số tiêu chuẩn và mô hình chất lượng và phương pháp xác định khả năng sử dụng ở dạng thuộc tính và thuộc tính phụ như ISO-9126, ISO-9241-11, ISO-13407 và IEEE std. 610.12, v.v.
Kiểm tra giao diện người dùng và khả năng sử dụng
Kiểm tra giao diện người dùng bao gồm việc kiểm tra Giao diện người dùng đồ họa của Phần mềm. Kiểm tra giao diện người dùng đảm bảo rằng GUI hoạt động theo yêu cầu và được kiểm tra về màu sắc, căn chỉnh, kích thước và các thuộc tính khác.
Mặt khác, kiểm tra khả năng sử dụng đảm bảo một GUI tốt và thân thiện với người dùng có thể dễ dàng xử lý. Kiểm tra giao diện người dùng có thể được coi là một phần phụ của kiểm tra khả năng sử dụng.
Kiểm tra bảo mật
Kiểm tra bảo mật liên quan đến việc kiểm tra một phần mềm để xác định bất kỳ lỗ hổng và lỗ hổng nào theo quan điểm bảo mật và lỗ hổng bảo mật. Dưới đây là các khía cạnh chính mà kiểm tra bảo mật cần đảm bảo:
Confidentiality
Integrity
Authentication
Availability
Authorization
Non-repudiation
Phần mềm được bảo mật trước các lỗ hổng đã biết và chưa biết
Dữ liệu phần mềm được bảo mật
Phần mềm tuân theo tất cả các quy định bảo mật
Kiểm tra đầu vào và xác nhận
Các cuộc tấn công chèn SQL
Sai sót tiêm
Các vấn đề về quản lý phiên
Các cuộc tấn công kịch bản trên nhiều trang web
Bộ đệm làm tràn lỗ hổng
Các cuộc tấn công truyền tải thư mục
Kiểm tra tính di động
Kiểm tra tính khả chuyển bao gồm kiểm tra một phần mềm với mục đích đảm bảo khả năng tái sử dụng của nó và nó cũng có thể được di chuyển từ 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 tra tính di động -
Chuyển một phần mềm đã cài đặt từ máy tính này sang máy tính khác.
Xây dựng tệp thực thi (.exe) để chạy phần mềm trên các nền tảng khác nhau.
Kiểm thử tính khả chuyển có thể được coi là một trong những phần phụ của kiểm thử hệ thống, vì loại kiểm thử này bao gồm kiểm tra tổng thể một phần mềm liên quan đến việc sử dụng nó trong các môi trường khác nhau. Phần cứng máy tính, hệ điều hành và trình duyệt là trọng tâm chính của kiểm tra tính di động. Một số điều kiện trước để kiểm tra tính di động như sau:
Phần mềm phải được thiết kế và mã hóa, lưu ý 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 tra tích hợp đã được thực hiện.
Môi trường thử nghiệm đã được thiết lập.