Để thực hiện dự án, sản phẩm phần mềm bất kỳ thì kiểm thử phần mềm (testing) là công việc không thể thiếu. Nó chính là bước quan trọng để giúp bạn có thể nhanh chóng kiểm tra lỗi có liên quan đến phần mềm, giúp chất lượng sản phẩm tăng lên từ đó mới có thể hạn chế lỗi hoặc rủi ro trước khi giao đến tay khách hàng. Và để thực hiện quá trình trên 1 cách an toàn và hiệu quả nhất thì test case được xem là dữ liệu tổng quát để có thể kiểm soát được các lỗi đang gặp phải trong phần mềm. Vậy Test case là gì? Bao gồm những thành phần nào? Cùng theo dõi trong các thông tin dưới đây của Testerpro.vn nhé!
Test case là gì?
Test case được định nghĩa theo nhiều luồng dữ liệu khác nhau. Theo wikipedia thì Test case được hiểu là tập hợp các điều kiện, thông số trong quá trình kiểm thử và những kết quả đạt được thông thường sẽ phục vụ cho 1 mục đích cụ thể.
Vậy Test case là gì?
Hiểu đơn giản là thì test case chính là kịch bản cho công việc kiểm thử. Kịch bản này là dữ liệu mô tả cho dữ liệu đầu vào, hành động test và thu về kết quả. Dựa vào kết quả này để xác định lại chức năng của dự án phần mềm đó đã hoạt động đúng theo kế hoạch và yêu cầu của khách hàng hay chưa?
Thông thường, bộ test case sẽ được viết khác nhau tùy vào từng dự án. Nhưng bộ test case đó vẫn phải đầy đủ các thông tin như: Tên test case, mã test case, mục tiêu, thông tin dữ liệu đầu vào, chi tiết các bước sẽ thực hiện và kết quả của quá trình Test.
SRS chính là tài liệu đặc tả yêu cầu phần mềm dùng để viết test case, bên cạnh đó chúng cũng có thể được viết trên Google Sheet hoặc Excel. Do đó, để đảm bảo test case có thể bao phủ được toàn bộ các trường hợp cần test thì nó phải bao gồm đầy đủ các yêu cầu và nghiệp vụ mà hệ thống đề ra.
Hơn thế nữa, Test case là quá trình có thể giúp bạn nhanh chóng tìm ra lỗi của dự án. Chính vì thế, kịch bản test càng sớm thì quá trình tìm kiếm và phát hiện ra lỗi càng nhanh từ đó có thể giúp giảm đi các chi phí phát sinh có liên quan.
Thành phần chính của test case
Bên cạnh việc nắm rõ kiến thức về Test case là gì? Thì để tạo nên bộ test case chi tiết với dữ liệu đầy đủ và chất lượng thì thành phần test case đóng vai trò quan trọng. Vậy thành phần test case là gì?
Một biểu mẫu test case sẽ bao gồm 6 thành phần chính là: ID test case, Test case Description, Test Data, Test Steps, Expected Results, Test Results. Cụ thể:
ID test case
ID test case là yếu tố giúp xác định số lượng, yêu cầu của kiểm thử.
Thông thường, ID Test case sẽ được viết theo công thức cụ thể như sau:
Ký tự chính trong tên viết tắt của dự án + Số thứ tự. Ví dụ dự án có tên: UNavi Blog thì ID sẽ được viết thành UB1…..
Test case Description
Đây là phần dữ liệu để mô tả lại mục đích sử dụng test case làm gì? Trong 1 dự án bất kỳ thì phần tên của test case sẽ không thể miêu tả đầy đủ chính vì thế đây là thành phần giúp mô tả đầy đủ nhất.
Test Data
Trong 1 dự án sẽ có những dữ liệu cần test data và có nhiều dữ liệu chúng ta không cần thực hiện việc kiểm tra này. Thông thường việc test data sẽ áp dụng trong các phần mềm phức tạp, khi này bạn sẽ phải sử dụng 1 tài khoản và lấy Function của tài khoản đó để kiểm tra. Ví dụ: Valid Data.
Test Steps
Là thành phần mô tả lại chỉ tiết các bước thực hiện test, nhưng để đảm bảo nội dung dễ hiểu thì test chỉ nên mô tả ngắn gọn và đầy đủ thông tin nhất có thể. Và không nên bỏ lỡ các sự kiện quan trọng để thực hiện lại khi có lỗi phát sinh xảy ra.
Expected Results
Với mỗi dữ liệu mô tả các bước thực hiện test data thì sẽ tương đương với Expected Results. Đây cũng là thành phần quan trọng nên có trong 1 test case.
Bên cạnh đó nó cũng là thành phần giúp hiển thị đầy đủ kết quả đạt được của các bước kiểm thử. Từ đó, đánh giá được kết quả mong muốn dựa trên yêu cầu từ phía khách hàng hoặc dựa vào tài liệu chuyên môn.
Test Results
Là kết quả thực tế đạt được dựa trên môi trường của hệ thống dự án. Thông thường dữ liệu này sẽ ở dạng Pass, Fail hoặc Pending.
Tại sao phải viết test case
Bên cạnh mục tiêu chính của test case là giúp cho chức năng của phần mềm được hoạt động đầy đủ theo đúng dự kiến và mong muốn của khách hàng. Giúp xác định các lỗi trong dự án phần mềm đã thực sự được khắc phục chưa hoặc đã đủ điều kiện để đưa ra thị trường…..
Ngoài ra, việc thực hiện test case cò giúp:
– Phạm vi của kiểm thử luôn được đảm bảo an toàn.
– Chất lượng của dự án sản phẩm, phần mềm luôn được xác định và cải thiện.
– Giúp tiết kiệm chi phí bảo hành hoặc sửa chữa phần mềm.
– Hỗ trợ xác định chính xác các yêu cầu cuối cùng của người dùng.
– Tester có thể nhìn nhận mọi việc ở nhiều khía cạnh và góc độ.
– Có thể là nguồn dữ liệu tham khảo cho các dự án tiếp theo trong tương lai.
Phân loại test case
Có nhiều phương pháp kiểm thử khác nhau ứng để chất lượng của dự án được đảm bảo tốt nhất. Tùy vào mục đích của việc kiểm thử mà bạn có thể thực hiện các loại test case khác nhau sao cho phù hợp nhất.
Để quá trình kiểm thử đem lại tác dụng và hiệu quả cao nhất thì Test case được phân chia thành các loại sau:
Positive
Trường hợp kiểm thử – Test case với mục đích để kiểm tra hoạt động và chức năng của dự án phần mềm thì dữ liệu trong phần mềm sẽ được xác nhận bằng dữ liệu đầu vào được xử lý chính xác trong tài liệu công cụ.
Ví dụ: Để xác định kiểm thử với Positive cần xác định đúng định hình của dữ liệu Email…
Negative
Trong 1 bộ test case cần dự đoán các trường hợp lỗi có thể xảy ra từ bên trong phần mềm và dữ liệu này cũng có thể là nguyên nhân dẫn tới các thông báo lỗi. Bên cạnh đó, cũng có thể xác định được chính xác các trường hợp lỗi xảy ra ngoài dự đoán.
Boundary Value
Boundary Value hay còn gọi là giá trị biên, đây cũng là cách kiểm tra có trong giá trị của 1 trong 2 ràng buộc.
Một trong những giá trị biên này sẽ có liên quan trực tiếp tới kiểm thử Positive – Tích cực và dữ liệu giá trị còn lại sẽ là kiểm thử tiêu cực – Negative.
Integration – kiểm thử tích hợp
Kiểm thử tích hợp là loại kiểm thử giúp kiểm tra lại các liên kết có trong dữ liệu không giống nhau của dự án phần mềm. Integration còn được nhận định giống với cấp độ kiểm thử hơn là trường hợp kiểm thử.
Đặc biệt, đây là loại kiểm thử bắt buộc, bạn phải thực hiện quá trình mô tả chúng nếu như có ít nhất 2 mô – đun đang tồn tại trong hệ thống của bạn.
Hơn thế nữa, để chắc chắn hơn thì bạn cũng có thể đưa ra các trường hợp kiểm thử quản lý các dữ liệu được nhập trong các bộ phận khác nhau của phần mềm.
Testing Localisation
Testing Localisation còn được biết tới là phương pháp kiểm thử nội địa hóa. Với loại test case này sẽ giúp bạn nhanh chóng kiểm tra thành phần có trong giao diện của phần mềm với vị trí và các loại ngôn ngữ khác nhau.
Bên cạnh đó, bạn cũng có thể viết ra các dữ liệu để kiểm tra GUI. Mô tả lại các dữ liệu bị nóng, phím lỗi…..Chia ra các Localisation nếu có nhiều thành phần ngôn ngữ riêng biệt.
5 Kỹ thuật thiết kế test case
Phân tích giá trị biên – Boundary Value Analysis (BVA)
Phân tích giá trị biên là kỹ thuật kiểm thử hộp đen để kiểm tra ranh giới giữa các phân vùng thay vì kiểm tra nhiều giá trị trong vùng tương đương. Điều này là do chúng ta thường tìm thấy một số lỗi lớn tại các đường biên chữ không phải tại tâm của các giá trị đầu vào được xác định và nếu nó đúng với các giá trị biên thì cũng đúng với toàn bộ vùng tương đương. Ngoài ra, BVA được coi là một loại thiết kế test case bổ sung để phân loại tương đương.
Hướng dẫn thiết kế BVA: Chọn các giá trị biến đầu vào ở mức tối thiểu/tối đa, ngay dưới mức tối thiểu/tối đa, ngay trên mức tối thiểu/tối đa, một giá trị tùy chọn.
Ví dụ các giá trị hợp lệ nằm trong khoảng từ 20-50
- Giá trị biên tối thiểu là 20
- Giá trị biên tối đa là 50
- Lấy 19, 20, 21, 49, 50, 51
- Đầu vào hợp lệ: 20, 21, 49, 50
- Đầu vào không hợp lê: 19, 51
Vì vậy các test case sẽ giống như:
- Trường hợp 1: Nhập giá trị 19: Không hợp lệ
- Trường hợp 2: Nhập số 20: Hợp lệ
- Trường hợp 3: Nhập số 50: Hợp lệ
- Trường hợp 4: Nhập số 51: Không hợp lệ
Phân vùng tương tương – Equivalence Class Partitioning
Đây là một phương pháp thiết kế test case phân chia dữ liệu miền đầu vào thành các lớp dữ liệu tương đương khác nhau, giả sữ rằng dữ liệu trong mỗi nhóm hoạt động giống nhau. Từ đó thiết kế test case cho các giá trị đại diện cho từng lớp có thể thay thế kết quả của cả lớp.
Khái niệm đằng sau kỹ thuật này là test case của một giá trị điển hình bằng với các kiểm thử của các giá trị còn lại trong cùng một nhóm. Do đó, nó giúp giảm số lượng các test case được thiết kế và thực hiện.
Các bước để thiết kế test case theo phân vùng tương đương:
- Định nghĩa các lớp tương đương
- Xác định test case cho mỗi lớp
Ví dụ tên người dùng hợp lệ nằm trong khoảng 5-20 ký tự văn bản
Vì vậy các test case sẽ giống như:
- Trường hợp 1: Nhập trong khoảng 5 – 20 ký tự text: Hợp lệ
- Trường hợp 2: Nhập <3 ký tự: Hiển thị thông báo lỗi “Tên đăng nhập phải từ 5 – 20 ký tự”
- Trường hợp 3: Nhập >20 ký tự: Hiển thị thông báo lỗi “Tên đăng nhập phải từ 5 – 20 ký tự”
- Trường hợp 4: Để trống hoặc không có ký tự: Hiển thị thông báo lỗi “Tên đăng nhập không hợp lệ”
Bảng quyết định – Decision Table
Bảng quyêt định là một kỹ thuật kiểm thử phần mềm dựa trên mối quan hệ nguyên nhân – kết quả, còn được gọi là bảng nguyên nhân – kết quả. Được sử dụng để kiểm tra hành vị hệ thống trong đó đầu ra phụ thuộc vào sự kết hợp lớn của đầu vào. Chẳng hạn, điều hướng người dùng đến trang chủ nếu tất cả các khoảng trống/ khoảng trống cụ thể trong phần đăng nhập được điền vào.
Trước hết bạn cần xác định chức năng mà đầu ra đáp ứng kết hợp với các đầu vào khác nhau. Sau đó, với mỗi chức năng, chia tệp đầu vào thành các tệp con nhỏ hơn có thể tương ứng với các đầu ra khác nhau.
Đối với mỗi chức năng, chúng ta sẽ tạo một bảng quyết định. Một bảng bao gồm 3 phần chính:
- Danh sách tất cả các kết hợp đầu vào có thể
- Một danh sách các hành vi hệ thống tương ứng (đầu ra)
- T (True) và F (False) đại diện cho tính chính xác của các điều kiện đầu vào.
Ví dụ:
- Chức năng: Người dùng sẽ được điều hướng đến trang chủ nếu đăng nhập thành công.
- Điều kiện đăng nhập thành công: đúng username, password, captcha.
- Trong phần đầu vào: T & F là viết tắt của độ chính xác của thông tin đầu vào.
- Ở phần Output: T là kết quả khi hiển thị trang chủ, F là kết quả khi hiện thông báo lỗi.
Vì vậy, các test case sẽ là:
- Nhập đúng username, password, captcha: Pass
- Nhập sai username, password, captcha: Hiển thị thông báo lỗi.
- Nhập đúng tên người dùng, sai mật khẩu và captcha: Hiển thị thông báo lỗi.
- Nhập đúng username, password và sai captcha: Hiển thị thông báo lỗi.
Chuyển đổi trạng thái – State Transition
Là một cách để thiết kế test case trong kiểm thử hộp đen, trong đó những thay đổi đầu vào sẽ làm thau đổi trạng thái của hệ thống và kích hoạt các đầu ra khác nhau. Trong kỹ thuật này, tester thực hiện các trường hợp hợp lệ và không hợp lệ thuộc chuỗi sự kiện để đánh giá hành vị hệ thống
Ví dụ khi người dùng đặng nhập vào ứng dụng smart banking, nhập sai 5 lần mật khẩu liên tiếp sẽ bị khóa tài khoản. Điều này có nghĩa có thể đăng nhập nếu nhập đúng mất khẩu ở lần thứ 1 đến 5 và trạng thái sẽ được chuyển thành truy cập được chấp nhận.
Kỹ thuật chuyển đổi trạng thái thường được sử dụng để kiểm thử các chức năng của ứng dụng đang kiểm thử (AUT) khi thay đổi đối với đầu vào tạo nên những thay đổi về trạng thái của hệ thống và tạo ra các đầu ra riêng biệt.
Đoán lỗi – Error Guessing
Trong kỹ thuật đoán lỗi, các test case được thiết kế chủ yếu dựa trên kinh nghiệm của các nhà phân tích kiểm thử. Họ sẽ cố gắng đoán và giả định các lỗi có thể xảy ra hoặc các tình huống dễ xảy ra lỗi có thể xảy ra trong code ; do đó các nhà thiết kế test case là những người tester có kỹ năng và kinh nghiệm.
Trong đoán lỗi, các trường hợp thử nghiệm có thể dựa trên:
- Kinh nghiệm trước đây về kiểm thử các sản phẩm phần mềm tương tự / liên quan.
- Hiểu biết về hệ thống cần kiểm thử.
- Kiến thức về các lỗi phổ biến trong các ứng dụng như vậy.
- Các chức năng được ưu tiên trong tài liệu đặc tả yêu cầu (để không bỏ sót chúng).
Bài viết trên, chúng tôi đã giải đáp với bạn Test case là gì? Và các thông tin có liên quan tới test case. Mong rằng thông tin trên là hữu ích tới bạn giúp bạn có thể hiểu và nắm vững hơn các kiến thức về test case. Thêm vào đó, đây là bước quan trọng trong 1 dự án bất kỳ vì thế hãy xây dựng test case và thực hiện sát theo các nội dung đó để tiết kiệm thời gian và công sức nhé!
>>> Tham khảo: Cách viết mẫu test case bằng excel đơn giản
