Kiểm thử phần mềm (software testing) là hoạt động nhằm tìm kiếm và phát hiện ra các lỗi của phần mềm, đảm bảo phần mềm chính xác, đúng và trọn vẹn theo yêu cầu của khách hàng, yêu cầu của sản phẩm đã đặt ra. Software testing cũng gửi tới mục tiêu, cái nhìn độc lập về phần mềm điều này cho phép đánh giá và hiểu rõ các rủi ro khi thực thi phần mềm. Căn cứ là gì? Hãy cùng LVN Group nghiên cứu thông qua nội dung trình bày dưới đây
1. Bug là gì?
Bug là những lỗi phần mềm được tạo ra trong quá trình code. Lỗi này có thể do code sai hoặc gặp các vấn đề không tương thích. Cũng có thể là lỗi do không hiểu ý tưởng và code sai lệch với yêu cầu ban đầu.
Thông thường bug sẽ được các tester kiểm định chất lượng và phát hiện, xử lý trước khi đưa sản phẩm đến người dùng. Quá trình tìm lỗi gọi là Debug và quá trình sửa bug thì gọi là Fixbug. Đây là cách nâng cao chất lượng của một sản phẩm trước khi chúng được người dùng trải nghiệm.
2. Kiểm thử là gì?
Đây là một trong những loại kiểm thử phần mềm cần thiết để xác nhận xem hệ thống có hoạt động đúng yêu cầu được không. Ở tất cả các mức độ kiểm thử đều được kiểm thử chức năng.
Testing of function là một trong những loại kiểm thử phần mềm cần thiết
Testing of function có thể thực hiện theo 2 quan điểm: business – process – based và requirements-based. Với business – process – based, kiểm thử viên sẽ sử dụng các kiến thức về quy trình nghiệp vụ (mô tả các kịch bản liên quan đến nghiệp vụ của hệ thống mỗi ngày).
Trong khi đó, requirements-based sử dụng các đặc tả yêu cầu của hệ thống làm cơ sở để design test. Để đảm bảo những thành phần cần thiết nhất đều được kiểm thử, hãy xem xét độ ưu tiên của yêu cầu dựa trên tiêu chí rủi ro, theo đó, chúng ta sẽ sử dụng độ ưu tiên để kiểm thử.
Các bước kiểm thử chức năng gồm:
Bước 1: Xác định phần mềm sẽ kiểm thử và chức năng của nó
Bước 2: Dựa trên tài liệu đặc tả chức năng để tạo dữ liệu đầu vào
Bước 3: Dựa vào tài liệu đặc tả chức năng để xác định đầu ra
Bước 4: Thực hiện các trường hợp kiểm thử phần mềm
Bước 5: So sánh kết quả thực tiễn với mong muốn đạt được
3. Vòng đời của bug trong kiểm thử phần mềm
3.1 Vòng đời của bug là gì?
DEFECT LIFE CYCLE hoặc Bug Life Cycle là tập hợp các trạng thái cụ thể mà Bug trải qua trong toàn bộ vòng đời của nó. Mục đích tạo ra quy trình cho một vòng đời bug là để những người chịu trách nhiệm cho bug đó dễ dàng quản lý và thay đổi trạng thái cho đến khi bug được loại bỏ hoàn toàn khỏi hệ thống
Các trạng thái của một bugthường sẽ thay đổi tùy từng dự án. Dưới đây là sơ đồ vòng đời của một bug, bao gồm tất cả các trạng thái có thể:
New: Khi một lỗi mới được ghi lại và đăng lần đầu tiên. Nó được gán một trạng thái là “New”
Assigned: Một khi bug đã được đăng bởi tester thì test leader sẽ phê duyệt lỗi và chuyển giao lỗi cho nhóm phát triển
Open: Dev bắt đầu phân tích và thực hiện sửa lỗi
Fixed: Khi Dev hiện đã sửa xong lỗi bằng cách sửa code và đã xác nhận là sửa xong, bug có thể được chuyển sang trạng thái “Fixed/Đã sửa”.
Pending retest: Sau khi sửa lỗi, dev bàn giao lại bug cho bên tester. Vì quá trình kiểm thử vẫn đang được diễn ra bởi các tester nên trạng thái được chỉ định là “”pending retest/kiểm tra lại đang chờ xử lý”.
Retest: Tester thực hiện test lại chương trình ở giai đoạn này để kiểm tra xem lỗi đã được fixed hay chưa và thay đổi trạng thái thành “Re-test/Kiểm tra lại”.
Verified: Tester kiểm tra lại lỗi sau khi dev đã fixed. Nếu không có lỗi được phát hiện trong phần mềm, thì lỗi đã được sửa và trạng thái được gán là “Verified/đã được xác minh”.
Reopen: Nếu lỗi vẫn tồn tại ngay cả sau khi dev đã sửa lỗi, tester sẽ thay đổi trạng thái thành “Reopen/mở lại”. Bug 1 lần nữa quay lại chu kỳ mới.
Closed: Nếu lỗi không còn tồn tại thì tester sẽ gán trạng thái “Closed/Đã đóng”.
Duplicate: Nếu lỗi được lặp lại hai lần hoặc lỗi tương ứng với cùng một khái niệm về lỗi, trạng thái được thay đổi thành “Duplicate/trùng lặp”.
Rejected: Nếu dev cảm thấy lỗi không phải là khiếm khuyết thực sự thì nó sẽ thay đổi lỗi thành “Rejected/Loại bỏ”.
Deferred: Nếu lỗi hiện tại không phải là ưu tiên chính và nếu dự kiến sẽ được sửa trong bản phát hành tiếp theo, thì trạng thái “Deferred/Trì hoãn” được gán cho các lỗi đó
Not a bug: Nếu nó không ảnh hưởng đến chức năng của ứng dụng thì trạng thái được gán cho lỗi là “Not a bug/Không phải là lỗi”.
3.2 Giải thích về vòng đời của bug
Tester tìm thấy bug
Gán trạng thái cho bug: New/Mới
Chuyển bug sang cho Quản lý dự án để phân tích
Quản lý dự án quyết định xem bug có hợp lệ không
Nếu như lỗi không hợp lệ, trạng thái sẽ được chuyển thành “Rejected/Đã từ chối.”
Nếu lỗi không bị rejected thì bước tiếp theo là kiểm tra xem nó có nằm trong phạm vi không. Giả sử chúng ta có một chức năng khác – chức năng email cho cùng một ứng dụng và bạn thấy có vấn đề với điều đó. Nhưng nó không nằm trong scope của lần phát hành ứng dụng lần này, trạng thái của bug đó có thể chuyển thành “Postponed/hoãn”.
Tiếp theo, người quản lý cần xác minh xem đã có bug nào tương tự đã được tìm ra trước đó hay chưa. Nếu đã có rồi, bug này được chuyển trạng thái thành “Duplicate/trùng lặp”.
Nếu không có vấn đề gì phát sinh trong khi dev fix bug thì bug này được chuyển sang trạng thái là “In- progress/đang tiến hành”.
Khi code được fixed. Bug sẽ được gán trạng thái là “Fixed/đã sửa xong”
Tiếp theo, tester sẽ test lại phần code vừa được sửa. Nếu như các phần test cases liên quan đều passed thì bug đó được đóng lại hay được chuyển trạng thái thành “Closed”. Nếu các trường hợp kiểm thử thất bại một lần nữa, lỗi được mở lại/re-opened và lại được chuyển giao sang cho dev
Hãy xem xét một tình huống trong lần release đầu tiên, một lỗi được tìm thấy theo thứ tự Fax đã được sửa và gán trạng thái đóng. Trong lần nâng cấp thứ hai, lỗi tương tự lại xuất hiện trở lại. Trong những trường hợp như vậy, một khiếm khuyết kín sẽ được mở lại.