Tổng quan về kiểm thử phần mềm
Kiểm thử phần mềm là đánh giá phần mềm dựa trên các yêu cầu thu thập được từ người dùng và các thông số kỹ thuật của hệ thống. Kiểm thử được tiến hành ở cấp độ pha 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 các yêu cầu của người dùng hay không. Nó được thực hiện ở cuối SDLC. Nếu phần mềm phù hợp với các yêu cầu mà nó được tạo ra, nó sẽ được xác nhận.
- Việc xác nhận đả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 nghiệp vụ hay không và được phát triển tuân theo các đặc điểm kỹ thuật và phương pháp luận phù hợp.
- Việc xác minh đảm bảo sản phẩm đang được phát triển là theo thông số kỹ thuật của thiết kế.
- 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 của thiết kế không?"
- 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 bài kiểm tra là -
Errors- Đây là những sai lầm mã hóa thực tế của các nhà phát triển. Ngoài ra, có sự khác biệt trong đầu ra của phần mềm và đầu ra mong muốn, được coi là một lỗi.
Fault- Khi lỗi tồn tại lỗi xảy ra. Lỗi, còn được gọi là lỗi, là kết quả của một lỗi có thể khiến hệ thống bị lỗi.
Failure - 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 có lỗi trong hệ thống.
Kiểm tra tự động bằng tay Vs
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:
Manual- Việc kiểm tra 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 độ khác nhau của mã, thực hiện các bài kiểm tra và báo cáo kết quả cho người quản lý.
Kiểm tra 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ó sử dụng đúng các trường hợp kiểm thử hay không. Phần chính của thử nghiệm liên quan đến thử nghiệm thủ công.
AutomatedThử nghiệm này là một quy trình thử nghiệm được thực hiện với sự hỗ trợ 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ách sử dụng các công cụ kiểm tra tự động.
Một bài kiểm tra cần phải kiểm tra xem một trang web có thể được mở trong Internet Explorer hay không. Điều này có thể dễ dàng thực hiện với thử nghiệm 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, thì hoàn toàn không thể kiểm tra theo cách thủ công.
Có các công cụ phần mềm và phần cứng giúp người kiểm tra thực hiện kiểm tra tải, kiểm tra căng thẳng, kiểm tra hồi quy.
Thử nghiệm các phương pháp
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 thử nghiệm mà không quan tâm đến việc triển khai thực tế, nó được gọi là thử nghiệm hộp đen. Mặt còn lại được gọi là kiểm thử hộp trắng, nơi không chỉ kiểm tra chức năng mà còn phân tích cách thực hiện nó.
Các bài kiểm tra hết sức là phương pháp mong muốn tốt 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 giá trị trong kịch bản thế giới thực nếu phạm vi giá trị lớn.
Kiểm tra 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à kiểm tra 'Hành vi'. Người thử nghiệm trong trường hợp này, có một bộ 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 khớp với kết quả mong muốn, chương trình được kiểm tra 'ok' và có vấn đề khác.
Trong phương pháp thử nghiệm này, người thử nghiệm không biết thiết kế và cấu trúc của mã, và các kỹ sư thử nghiệm và người dùng cuối tiến hành thử nghiệm này trên phần mềm.
Các kỹ thuật kiểm tra hộp đen:
Equivalence class- Đầu vào được chia thành các lớp tương tự nhau. Nếu một phần tử của lớp vượt qua bài kiểm tra, thì giả sử rằng tất cả lớp đó đều vượt qua.
Boundary values- Đầu vào được chia thành các giá trị cuối cao hơn và thấp hơn. Nếu các giá trị này vượt qua bài kiểm tra, thì giả định rằng tất cả các giá trị ở giữa cũng có thể vượt qua.
Cause-effect graphing- Trong cả hai phương pháp trước, chỉ một giá trị đầu vào tại một thời điểm được kiểm tra. Nguyên nhân (đầu vào) - Hiệu ứng (đầu ra) là một kỹ thuật kiểm tra 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.
Pair-wise Testing- 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.
State-based testing- Hệ thống thay đổi trạng thái cung cấp đầu vào. Các hệ thống này được kiểm tra dựa trên trạng thái và đầu vào của chúng.
Thử nghiệm 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, người thử nghiệm đã biết thiết kế và cấu trúc của mã. Lập trình viên của mã tiến hành kiểm tra này trên mã.
Dưới đây là một số kỹ thuật kiểm tra Hộp trắng:
Control-flow testing- Mục đích của thử nghiệm luồng điều khiển để thiết lập các trường hợp thử nghiệm 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, để có thể bao quát tất cả các câu lệnh.
Data-flow testing- Kỹ thuật kiểm tra này nhấn mạnh để bao hàm 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à xác định và nơi chúng được sử dụng hoặc thay đổi.
Kiểm tra mức độ
Bản thân việc kiểm tra có thể được xác định ở nhiều cấp độ SDLC khác nhau. Quá trình kiểm thử chạy song song với 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.
Kiểm tra riêng được thực hiện chỉ để đảm bảo rằng không có lỗi hoặc vấn đề ẩn trong phần mềm. Phần mềm được kiểm tra ở nhiều cấp độ khác nhau -
Kiểm tra đơn vị
Trong khi viết mã, 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 nó có lỗi hay không. Thử nghiệm được thực hiện theo phương pháp thử nghiệm hộp trắng. Kiểm thử đơ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 hoạt động tốt 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 tốt 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:
Functionality testing - Kiểm tra tất cả các chức năng của phần mềm theo yêu cầu.
Performance testing- Thử nghiệm này chứng minh phần mềm hiệu quả như thế nào. Nó kiểm tra tính hiệu quả và thời gian trung bình của phần mềm để thực hiện công việc 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 mức người dùng và tải dữ liệu cao trong các điều kiện môi trường khác nhau.
Security & Portability - Các bài kiểm tra này được thực hiện khi phần mềm hoạt động trên nhiều nền tảng khác nhau và được nhiều người truy cập.
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 nó được kiểm tra về sự tương tác và phản hồi 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.
Alpha testing- Đội ngũ lập trình viê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 xem người dùng sẽ phản ứng như thế nào với một số hành động trong phần mềm và cách hệ thống nên phản hồi với các đầu vào.
Beta testing- Sau khi phần mềm được kiểm tra nội bộ, phần mềm đượ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 hy vọng rằng người dùng ở giai đoạn này sẽ gặp phải các vấn đề nhỏ, đã được 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. Đây được gọi là kiểm tra hồi quy.
Tài liệu Kiểm tra
Tài liệu kiểm tra được chuẩn bị ở các giai đoạn khác nhau -
Trước khi thử nghiệm
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 -
SRS document - Tài liệu Yêu cầu Chức năng
Test Policy document - Điều này mô tả việc kiểm tra sẽ diễn ra trong bao lâu trước khi phát hành sản phẩm.
Test Strategy document - Điề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 tra và kỹ sư kiểm tra.
Traceability Matrix document- Đâ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 yêu cầu mới đến, chúng được thêm vào ma trận này. Các ma trận này giúp người kiểm tra biết được nguồn 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 khi bắt đầu thử nghiệm và đang được thực hiện:
Test Case document- Tài liệu này chứa danh sách các thử nghiệm cần được tiến hành. Nó bao gồm kế hoạch kiểm thử Đơ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.
Test description - 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à các thủ tục để thực thi chúng.
Test case report - 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.
Test logs - Tài liệu này chứa các bản ghi thử nghiệm cho mọi báo cáo trường hợp thử nghiệm.
Sau khi kiểm tra
Các tài liệu sau có thể được tạo sau khi thử nghiệm:
Test summary- Bản tóm tắt kiểm tra này là phân tích tập thể 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.
Kiểm tra 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.
Software quality assurance- Đây là các phương tiện giám sát quá trình phát triển phần mềm, qua đó đảm bảo rằng tất cả các biện pháp được thực hiện theo các 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ủ.
Software quality control- Đây là 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, nhằm nâng cao thiện chí 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'.
Software audit- Đây là một đánh giá về thủ tục được tổ chức sử dụng để 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 phần mềm, thủ tục, các yêu cầu 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 phần mềm đó và quá trình phát triển của nó, cả hai đều tuân thủ các tiêu chuẩn, quy tắc và quy định.