Kiểm thử phần mềm là đánh giá phần mềm dựa trên các yêu cầu được thu thập từ người dùng và thông số kỹ thuật của hệ thống. Kiểm thử được tiến hành ở cấp độ giai đoạn trong vòng đời phát triển phần mềm hoặc ở cấp độ mô-đun trong mã chương trình. Kiểm thử phần mềm bao gồm Xác thực và Xác minh.
Xác thực phần mềm
Xác thực là quá trình kiểm tra xem phần mềm có đáp ứng yêu cầu của người dùng hay không. Nó được thực hiện ở phần cuối của SDLC. Nếu phần mềm phù hợp với các yêu cầu mà nó được tạo ra, thì nó sẽ được xác thực.
- Xác thực đảm bảo sản phẩm đang được phát triển theo yêu cầu của người dùng.
- Xác thực trả lời câu hỏi – “Chúng tôi có đang phát triển sản phẩm thử tất cả những gì người dùng cần từ phần mềm này không?”.
- Xác thực nhấn mạnh vào các yêu cầu của người dùng.
Xác minh phần mềm
Xác minh là quá trình xác nhận xem phần mềm có đáp ứng các yêu cầu kinh doanh hay không và được phát triển tuân thủ các thông số kỹ thuật và phương pháp thích hợp.
- Xác minh đảm bảo sản phẩm đang được phát triển theo thông số kỹ thuật thiết kế.
- Việc xác minh trả lời câu hỏi– “Chúng tôi có đang phát triển sản phẩm này bằng cách tuân thủ chặt chẽ tất cả các thông số kỹ thuật thiết kế không?”
- Việc xác minh tập trung vào thiết kế và thông số kỹ thuật của hệ thống.
Mục tiêu của thử nghiệm là –
- Lỗi – Đây là những lỗi mã hóa thực tế do các nhà phát triển thực hiện. Ngoài ra, có sự khác biệt giữa đầu ra của phần mềm và đầu ra mong muốn, được coi là lỗi.
- Fault – Khi có lỗi xảy ra lỗi. Lỗi, còn được gọi là lỗi, là kết quả của lỗi có thể khiến hệ thống bị lỗi.
- Thất bại – thất bại được cho là hệ thống không có khả năng thực hiện nhiệm vụ mong muốn. Lỗi xảy ra khi lỗi tồn tại trong hệ thống.
Kiểm tra thủ công Vs tự động
Việc kiểm tra có thể được thực hiện thủ công hoặc sử dụng công cụ kiểm tra tự động:
- Thủ công – Thử nghiệm này được thực hiện mà không cần sự trợ giúp của các công cụ kiểm tra tự động. Người kiểm thử phần mềm chuẩn bị các trường hợp kiểm thử cho các phần và cấp mã khác nhau, thực hiện kiểm thử và báo cáo kết quả cho người quản lý.
Kiểm thử thủ công tốn thời gian và tài nguyên. Người kiểm thử cần xác nhận xem các trường hợp kiểm thử có đúng hay không. Phần chính của thử nghiệm liên quan đến thử nghiệm thủ công.
- Tự động Thử nghiệm này là một quy trình thử nghiệm được thực hiện với sự trợ giúp của các công cụ thử nghiệm tự động. Những hạn chế với kiểm tra thủ công có thể được khắc phục bằng các công cụ kiểm tra tự động.
Một bài kiểm tra cần kiểm tra xem một trang web có thể mở được trong Internet Explorer hay không. Điều này có thể dễ dàng thực hiện với kiểm thử thủ công. Nhưng để kiểm tra xem máy chủ web có thể chịu tải 1 triệu người dùng hay không, việc kiểm tra thủ công là điều không thể.
Có các công cụ phần mềm và phần cứng giúp người kiểm tra tiến hành kiểm tra tải, kiểm tra căng thẳng, kiểm tra hồi quy.
Phương pháp thử nghiệm
Các thử nghiệm có thể được tiến hành dựa trên hai cách tiếp cận –
- kiểm tra chức năng
- thử nghiệm triển khai
Khi chức năng đang được kiểm tra mà không liên quan đến việc triển khai thực tế, nó được gọi là kiểm tra hộp đen. Mặt khác được gọi là thử nghiệm hộp trắng, trong đó không chỉ chức năng được kiểm tra mà cách thức triển khai cũng được phân tích.
Các bài kiểm tra toàn diện là phương pháp mong muốn nhất để có một bài kiểm tra hoàn hảo. Mọi giá trị có thể có trong phạm vi giá trị đầu vào và đầu ra đều được kiểm tra. Không thể kiểm tra từng và mọi giá trị trong kịch bản thế giới thực nếu phạm vi giá trị lớn.
kiểm thử hộp đen
Nó được thực hiện để kiểm tra chức năng của chương trình. Nó còn được gọi là thử nghiệm ‘Hành vi’. Người thử nghiệm trong trường hợp này có một tập hợp các giá trị đầu vào và kết quả mong muốn tương ứng. Khi cung cấp đầu vào, nếu đầu ra phù hợp với kết quả mong muốn, thì chương trình được kiểm tra là ‘ok’ và nếu không thì có vấn đề.
Trong phương pháp thử nghiệm này, thiết kế và cấu trúc của mã không được người thử nghiệm biết đến và các kỹ sư thử nghiệm cũng như người dùng cuối tiến hành thử nghiệm này trên phần mềm.
Kỹ thuật kiểm thử hộp đen:
- Lớp tương đương – Đầu vào được chia thành các lớp tương tự. Nếu một phần tử của một lớp vượt qua bài kiểm tra, thì giả định rằng tất cả các lớp đều vượt qua.
- Giá trị biên – Đầu vào được chia thành giá trị cấp cao hơn và cấp thấp hơn. Nếu các giá trị này vượt qua bài kiểm tra, giả định rằng tất cả các giá trị ở giữa cũng có thể vượt qua.
- Biểu đồ nguyên nhân-kết quả – Trong cả hai phương pháp trước đó, mỗi lần chỉ kiểm tra một giá trị đầu vào. Nguyên nhân (đầu vào) – Kết quả (đầu ra) là một kỹ thuật kiểm thử trong đó sự kết hợp của các giá trị đầu vào được kiểm tra một cách có hệ thống.
- Kiểm tra theo cặp – Hành vi của phần mềm phụ thuộc vào nhiều tham số. Trong thử nghiệm theo cặp, nhiều tham số được thử nghiệm theo cặp cho các giá trị khác nhau của chúng.
- Thử nghiệm dựa trên trạng thái – Hệ thống thay đổi trạng thái khi cung cấp đầu vào. Các hệ thống này được thử nghiệm dựa trên trạng thái và đầu vào của chúng.
kiểm thử hộp trắng
Nó được tiến hành để kiểm tra chương trình và việc triển khai nó, nhằm cải thiện hiệu quả hoặc cấu trúc mã. Nó còn được gọi là thử nghiệm ‘Cấu trúc’.
Trong phương pháp thử nghiệm này, thiết kế và cấu trúc của mã được người thử nghiệm biết. Các lập trình viên của mã tiến hành thử nghiệm này trên mã.
Dưới đây là một số kỹ thuật kiểm thử hộp trắng:
- Kiểm thử luồng điều khiển – Mục đích của kiểm thử luồng kiểm soát là thiết lập các trường hợp kiểm thử bao gồm tất cả các câu lệnh và điều kiện nhánh. Các điều kiện rẽ nhánh được kiểm tra cả đúng và sai để tất cả các câu lệnh đều có thể được kiểm tra.
- Kiểm tra luồng dữ liệu – Kỹ thuật kiểm tra này nhấn mạnh đến tất cả các biến dữ liệu có trong chương trình. Nó kiểm tra nơi các biến được khai báo và định nghĩa và nơi chúng được sử dụng hoặc thay đổi.
Cấp độ kiểm tra
Bản thân thử nghiệm có thể được xác định ở các cấp độ khác nhau của SDLC. Quá trình thử nghiệm chạy song song với quá trình phát triển phần mềm. Trước khi chuyển sang giai đoạn tiếp theo, một giai đoạn được kiểm tra, xác nhận và xác minh.
Thử nghiệm riêng biệt được thực hiện chỉ để đảm bảo rằng không còn lỗi hoặc sự cố tiềm ẩn nào trong phần mềm. Phần mềm được thử nghiệm ở nhiều cấp độ khác nhau –
Kiểm tra đơn vị
Trong khi mã hóa, lập trình viên thực hiện một số kiểm tra trên đơn vị chương trình đó để biết liệu nó có bị lỗi hay không. Kiểm thử được thực hiện theo phương pháp kiểm thử hộp trắng. Thử nghiệm đơn vị giúp các nhà phát triển quyết định rằng các đơn vị riêng lẻ của chương trình đang hoạt động theo yêu cầu và không có lỗi.
Thử nghiệm hội nhập
Ngay cả khi các đơn vị phần mềm đang hoạt động tốt một cách riêng lẻ, vẫn cần phải tìm hiểu xem các đơn vị nếu được tích hợp với nhau có hoạt động mà không có lỗi hay không. Ví dụ: truyền đối số và cập nhật dữ liệu, v.v.
Thử nghiệm hệ thống
Phần mềm được biên dịch dưới dạng sản phẩm và sau đó nó được kiểm tra tổng thể. Điều này có thể được thực hiện bằng cách sử dụng một hoặc nhiều thử nghiệm sau:
- Kiểm tra chức năng – Kiểm tra tất cả các chức năng của phần mềm theo yêu cầu.
- Kiểm tra hiệu suất – Thử nghiệm này chứng minh mức độ hiệu quả của phần mềm. Nó kiểm tra hiệu quả và thời gian trung bình mà phần mềm thực hiện để thực hiện tác vụ mong muốn. Kiểm tra hiệu suất được thực hiện bằng phương pháp kiểm tra tải và kiểm tra căng thẳng trong đó phần mềm được đặt dưới tải của người dùng và dữ liệu cao trong các điều kiện môi trường khác nhau.
- Bảo mật & Tính di động – Các thử nghiệm này được thực hiện khi phần mềm được thiết kế để hoạt động trên nhiều nền tảng khác nhau và được truy cập theo số lượng người.
Kiểm tra chấp nhận
Khi phần mềm đã sẵn sàng để bàn giao cho khách hàng, nó phải trải qua giai đoạn thử nghiệm cuối cùng, nơi phần mềm được kiểm tra về phản hồi và tương tác của người dùng. Điều này rất quan trọng vì ngay cả khi phần mềm phù hợp với tất cả các yêu cầu của người dùng và nếu người dùng không thích cách nó xuất hiện hoặc hoạt động, nó có thể bị từ chối.
- Thử nghiệm alpha – Nhóm nhà phát triển tự thực hiện thử nghiệm alpha bằng cách sử dụng hệ thống như thể nó đang được sử dụng trong môi trường làm việc. Họ cố gắng tìm hiểu cách người dùng sẽ phản ứng với một số hành động trong phần mềm và cách hệ thống sẽ phản hồi với đầu vào.
- Thử nghiệm Beta – Sau khi phần mềm được thử nghiệm nội bộ, phần mềm sẽ được bàn giao cho người dùng sử dụng trong môi trường sản xuất của họ chỉ với mục đích thử nghiệm. Đây vẫn chưa phải là sản phẩm được giao. Các nhà phát triển mong đợi rằng người dùng ở giai đoạn này sẽ đưa ra các vấn đề nhỏ mà họ đã bỏ qua để tham dự.
Kiểm tra hồi quy
Bất cứ khi nào một sản phẩm phần mềm được cập nhật với mã, tính năng hoặc chức năng mới, nó sẽ được kiểm tra kỹ lưỡng để phát hiện xem có bất kỳ tác động tiêu cực nào của mã được thêm vào hay không. Điều này được gọi là thử nghiệm hồi quy.
Tài liệu thử nghiệm
Tài liệu thử nghiệm được chuẩn bị ở các giai đoạn khác nhau –
Trước khi kiểm tra
Thử nghiệm bắt đầu với việc tạo các trường hợp thử nghiệm. Tài liệu sau đây là cần thiết để tham khảo –
- Tài liệu SRS – Tài liệu Yêu cầu chức năng
- Tài liệu Chính sách kiểm tra – Tài liệu này mô tả khoảng thời gian kiểm tra sẽ diễn ra trước khi phát hành sản phẩm.
- Tài liệu Chiến lược kiểm thử – Tài liệu này đề cập đến các khía cạnh chi tiết của nhóm kiểm thử, ma trận trách nhiệm và quyền/trách nhiệm của người quản lý kiểm thử và kỹ sư kiểm thử.
- Tài liệu Traceability Matrix – Đây là tài liệu SDLC, có liên quan đến quy trình thu thập yêu cầu. Khi có các yêu cầu mới, chúng được thêm vào ma trận này. Các ma trận này giúp người thử nghiệm biết nguồn gốc của yêu cầu. Chúng có thể được truy tìm về phía trước và phía sau.
Trong khi được kiểm tra
Các tài liệu sau đây có thể được yêu cầu trong khi thử nghiệm được bắt đầu và đang được thực hiện:
- Tài liệu Test Case – Tài liệu này chứa danh sách các bài kiểm tra cần tiến hành. Nó bao gồm Kế hoạch kiểm tra đơn vị, Kế hoạch kiểm tra tích hợp, Kế hoạch kiểm tra hệ thống và Kế hoạch kiểm tra chấp nhận.
- Mô tả kiểm thử – Tài liệu này là một mô tả chi tiết về tất cả các trường hợp kiểm thử và thủ tục để thực hiện chúng.
- Báo cáo trường hợp thử nghiệm – Tài liệu này chứa báo cáo trường hợp thử nghiệm là kết quả của thử nghiệm.
- Nhật ký kiểm tra – Tài liệu này chứa nhật ký kiểm tra cho mọi báo cáo trường hợp kiểm tra.
Sau khi kiểm tra
Các tài liệu sau đây có thể được tạo ra sau khi thử nghiệm:
- Tóm tắt kiểm tra – Tóm tắt kiểm tra này là phân tích chung của tất cả các báo cáo và nhật ký kiểm tra. Nó tóm tắt và kết luận nếu phần mềm đã sẵn sàng để khởi chạy. Phần mềm được phát hành dưới hệ thống kiểm soát phiên bản nếu nó sẵn sàng khởi chạy.
Thử nghiệm so với Kiểm soát chất lượng, Đảm bảo chất lượng và Kiểm toán
Chúng ta cần hiểu rằng kiểm thử phần mềm khác với đảm bảo chất lượng phần mềm, kiểm soát chất lượng phần mềm và kiểm toán phần mềm.
- Đảm bảo chất lượng phần mềm – Đây là các phương tiện giám sát quy trình phát triển phần mềm, theo đó đảm bảo rằng tất cả các biện pháp được thực hiện theo tiêu chuẩn của tổ chức. Việc giám sát này được thực hiện để đảm bảo rằng các phương pháp phát triển phần mềm phù hợp đã được tuân thủ.
- Kiểm soát chất lượng phần mềm – Đây là một hệ thống để duy trì chất lượng của sản phẩm phần mềm. Nó có thể bao gồm các khía cạnh chức năng và phi chức năng của sản phẩm phần mềm, giúp nâng cao uy tín của tổ chức. Hệ thống này đảm bảo rằng khách hàng đang nhận được sản phẩm chất lượng theo yêu cầu của họ và sản phẩm được chứng nhận là ‘phù hợp để sử dụng’.
Kiểm toán phần mềm – Đây là việc xem xét thủ tục được sử dụng bởi tổ chức để phát triển phần mềm. Một nhóm kiểm toán viên, độc lập với nhóm phát triển, kiểm tra quy trình, thủ tục, yêu cầu phần mềm và các khía cạnh khác của SDLC. Mục đích của kiểm toán phần mềm là kiểm tra xem phần mềm đó và quy trình phát triển của nó có tuân thủ các tiêu chuẩn, quy tắc và quy định hay không.