State transition exercise

Chuyên đề thảo luận về kiểm thử hộp đen (Black-box Testing)
Forum rules
Chuyên đề này chỉ thảo luận về Black-box Testing.
Để có kết quả nhanh, các bạn nên search trước khi tạo chủ đề mới.
Post Reply
tvn
Admin
Posts: 4900
Joined: Tue 10 Aug, 2010 10:11 am
Location: HCM
Contact:

State transition exercise

Post by tvn »

Hôm nay chúng ta thử làm bài tập này xem sao nhé

Giỏ hàng trên một trang mua bán trực tuyến được bắt đầu với trạng thái là rỗng (không có món hàng nào). Khi bạn chọn một sản phẩm thì nó sẽ được đưa vào giỏ hàng. Bạn cũng có thể bỏ chọn các món hàng trong giỏ hàng. Khi bạn quyết định mua hàng, thì sẽ xuất hiện màn hình tổng hợp các món hàng đang có trong giỏ cùng với thông tin về giá tiền, số lượng và tổng tiền của giỏ hàng, để cho bạn xác nhận xem đúng hay chưa. Nếu bạn thấy số lượng hàng và giá tiền OK thì bạn sẽ được chuyển sang trang thanh toán. Ngược lại bạn sẽ quay lại trang mua hàng (lúc này bạn có thể bỏ chọn các món hàng bạn muốn bỏ bớt).

Yêu cầu:
  • a. Đưa ra sơ đồ trạng thái - state diagram – cho thấy các trạng thái/states và sự chuyển tiếp/transition khác. Xác định test case – một loạt các trạng thái – bao phủ toàn bộ các chuyển tiếp.
    b. Đưa ra một bảng trạng thái. Cho một ví dụ kiểm thử trường hợp chuyển tiếp không hợp lệ.
Mời các bạn xem thêm các bài tập sau:



seaside
Hoc Tester
Posts: 3
Joined: Fri 24 Sep, 2010 2:57 pm
Contact:

Re: State transition exercise

Post by seaside »

tvn oi, ban giai bai tap nay giup minh voi, minh dang tim hieu ve chủ đề này, thanks bạn.



tvn
Admin
Posts: 4900
Joined: Tue 10 Aug, 2010 10:11 am
Location: HCM
Contact:

Re: State transition exercise

Post by tvn »

Hình bên dưới là sơ đồ trạng thái của giỏ hàng. Trạng thái (state) khởi tạo là S1 khi giỏ hàng chưa có hàng (empty - đang rỗng). Khi thêm một món hàng vào giỏ (add item) thì sẽ chuyển sang (transition) trạng thái có hàng S2. Khi thêm một món hàng khác nữa vào giỏ thì không làm thay đổi trạng thái này (lúc này chỉ làm thay đổi số lượng hàng trong giỏ). Các món hàng trong giỏ có thể bỏ bớt (remove item), khi bỏ bớt 1 món hàng, mà trong giỏ còn hàng thì nó không làm thay đổi trạng thái, nhưng khi bỏ mớt món cuối cùng (remove last item) thì sẽ bị chuyển sang trạng thái S1, vì lúc này giỏ rỗng. Khi khách hàng muốn tính tiền (Check out) thì chuyển sang trạng thái S3 tổng kết và tính giá tiền (summary & cost) để mua. Nếu danh sách hàng này hợp lệ (số hàng và tổng số tiền mình thấy được - OK), thì chuyển sang trạng thái S4 là thanh toán; Nếu kiểm tra thấy không phù hợp (vì không đủ tiền để mua chẳng hạn,…) thì phải quay lại trạng thái S3, khách hàng có thể lấy bớt hàng ra rồi quay lại trạng thái S4. Tổng cộng chúng ta có 4 trạng thái (nốt hình tròn) và 7 sự kiện (các đường mũi tên).

Chú ý: Trong ví dụ này, S1 là Trạng Thái Bắt Đầu (Start State) và S4 là Trạng Thái Kết Thúc (End State), nghĩa là chỉ có ở S4 là không đi đâu được nữa, còn ở các trạng thái khác thì chúng ta đều có thể đi đến 1 trạng thái bất kỳ nào đó khác.

Image

Dưới đây là một trường hợp – test case – bao phủ toàn bộ các trạng thái. Lưu ý rằng trạng thái kết thúc từ một bước (step) hoặc sự kiện (event) là trạng thái cho sự kiện tiếp theo, vì vậy các bước này phải được đi qua theo thứ tự này.

Image

Mặc dù trong ví dụ này chúng ta không quan tâm đến việc gì sẽ xảy ra tại Trạng thái 4, nhưng có thể có vài sự kiện hoặc hành động nào đó xảy ra, ví dụ như click Cancel (không mua hàng nữa) hoặc click nút Payment để tiến hành thanh toán, và có thể là sau khi thực hiện thanh toán nó sẽ hiển thị màn hình thông báo hoặc chuyển sang màn hình khác hoặc bắt đầu một sơ đồ trạng thái khác (state diagram) như kiểm tra tính hợp lệ của thẻ credit card, số dư, email, v.v…

Dưới đây là một bảng mô tả trạng thái tương ứng với sơ đồ trạng thái trên:

Image

Trong bảng trên tất cả các ô chứa dấu – là trạng thái không hợp lệ (invalid transition). Sau đây là một vài ví dụ các trường hợp kiểm thử không hợp lệ có thể xảy ra:
  • • Thử thêm một món hàng ở trạng thái S3 - tổng kết và tính giá tiền.
    • Thử bớt một móng hàng khi giỏ hàng đang rỗng (empty – không có món hàng nào - ở trạng thái S1
    • Thử bấm OK khi đang shopping – ở trạng thái S2 – vì ở màn hình shopping thì không có nút OK mà chỉ có nút Check out.
Từ bảng trên chúng ta sẽ viết được các test case sau:

Image

Vì trạng thái đầu tiên của chúng tra trong bài tập này là ở màn hình mua hàng và giỏ hàng đang rỗng => vì vậy ở đây mình không thêm case đang ở màn hình chính, click nút mua hàng để vào màn hình mua hàng; hoặc đang ở màn hình login, rồi vào màn hình mua hàng - shopping.
Và cũng không có case mô tả ở màn hình thanh toán sẽ đi đâu nữa, khi click Cancel thì quay về màn hình mua hàng hoặc khi click nút Thanh toán thì hiển thị màn hình in biên lai,…

Các test case TC1 đến TC6 là test case cho các trường hợp hợp lệ (valid – Positive test case); các test case TC7 đến TC13 là cho các trường hợp không hợp lệ (invalid – Negative test case). Trong trường hợp không hợp lệ thì có một số case trên là không thực hiện được, nghĩa là không thể test được như TC7, trên màn hình shoping không có nút Check out thì làm sao mình click được nên test case này sẽ được loại bỏ. Vì đây là giả định nên mình cố gắng liệt kê ra càng nhiều test case càng tốt.

Mời các bạn xem thêm các bài tập sau:



seaside
Hoc Tester
Posts: 3
Joined: Fri 24 Sep, 2010 2:57 pm
Contact:

Re: State transition exercise

Post by seaside »

Thanks ban tvn nhieu, bài giải của bạn đầy đủ và rõ ràng lắm.
Mình có 1 vài thắc mắc sau:

1. Những case invalid: nếu requirement mô tả không có những button Add item, remove item ở màn hình kiểm tra hàng/tiền và màn hình thanh toán thì sẽ không có những case invalid này trong bộ testcase của mình, phải ko bạn?
2. Đối với những dạng project/requirement dạng nào thì áp dụng State Transition Diagram này (Cách nhận dạng project để áp dụng mô hình này để coverage case)?
3. Nếu không dùng mô hình này để viết testcase mà chỉ đọc requirement và dựa trên kinh nghiệm thì liệu mô này có cover đầy đủ case hơn là dựa theo kinh nghiệm không?
Vì thế mục đích và ý nghĩa của việc sử dụng mô hình này là gì? và khi nào dùng nó?
4. Bạn có bài tập nào có thêm state variable? share minh voi, thanks ban nhieu.



tvn
Admin
Posts: 4900
Joined: Tue 10 Aug, 2010 10:11 am
Location: HCM
Contact:

Re: State transition exercise

Post by tvn »

seaside wrote:Thanks ban tvn nhieu, bài giải của bạn đầy đủ và rõ ràng lắm.
Mình có 1 vài thắc mắc sau:

1. Những case invalid: nếu requirement mô tả không có những button Add item, remove item ở màn hình kiểm tra hàng/tiền và màn hình thanh toán thì sẽ không có những case invalid này trong bộ testcase của mình, phải ko bạn?
2. Đối với những dạng project/requirement dạng nào thì áp dụng State Transition Diagram này (Cách nhận dạng project để áp dụng mô hình này để coverage case)?
3. Nếu không dùng mô hình này để viết testcase mà chỉ đọc requirement và dựa trên kinh nghiệm thì liệu mô này có cover đầy đủ case hơn là dựa theo kinh nghiệm không?
Vì thế mục đích và ý nghĩa của việc sử dụng mô hình này là gì? và khi nào dùng nó?
4. Bạn có bài tập nào có thêm state variable? share minh voi, thanks ban nhieu.
Chào bạn, đây là comment của mình:

1. Những case invalid: nếu requirement mô tả không có những button Add item, remove item ở màn hình kiểm tra hàng/tiền và màn hình thanh toán thì sẽ không có những case invalid này trong bộ testcase của mình, phải ko bạn?
=> Đúng, vì đây là giả định cho bài tập nên mới đưa ra nhiều trường hợp, khi có requirement rõ ràng thì dựa vào đó mà viết test case.

2. Đối với những dạng project/requirement dạng nào thì áp dụng State Transition Diagram này (Cách nhận dạng project để áp dụng mô hình này để coverage case)?
=> Không phải dạng tài liệu nào mà là dựa vào yêu cầu và luồng hoạt động của ứng dụng, cứ thấy ứng dụng có các trạng thái khác nhau như trong ví dụ hoặc các ứng dụng ngân hàng như ATM (có các trạng thái nhất định) hoặc áp dụng cho các ứng dụng dạng flow, lúc này mình xem mỗi màn hình là 1 State, còn hành động click button next hay privious để sang màn hình khác, hoặc click nút reset thì clear dữ liệu tại màn hình đó (như add item ở State 2),... Cái này link động một xíu. Và phải áp dụng nhiều kỹ thuật test vào một dự án chứ không chỉ là 1 kỹ thuật là được.

3. Nếu không dùng mô hình này để viết testcase mà chỉ đọc requirement và dựa trên kinh nghiệm thì liệu mô này có cover đầy đủ case hơn là dựa theo kinh nghiệm không?
Vì thế mục đích và ý nghĩa của việc sử dụng mô hình này là gì? và khi nào dùng nó?
=> Viết test case dựa trên kinh nghiệm là một trong các kỹ thuật thiết kế test case, để viết test case tốt thì cần phải áp dụng nhiều kỹ thuật khác nhau cùng lúc, việc áp dụng kỹ thuật nào đó là giúp cho mình khỏi bỏ sót trường hợp test. Các kỹ thuật thiết kế test case thường được sử dụng là phân tích giá trị biênphân vùng tương đương, bảng quyết định, state transition, dựa vào kinh nghiệm thì có kỹ thuật đoán lỗi,...

4. Bạn có bài tập nào có thêm state variable? share minh voi, thanks ban nhieu.
=> Cái này thì để vài bữa nữa sưu tầm đã :D



seaside
Hoc Tester
Posts: 3
Joined: Fri 24 Sep, 2010 2:57 pm
Contact:

Re: State transition exercise

Post by seaside »

Thanks ban tvn nhieu, mình đợi bạn nhé...hihi



truongtnd
Hoc Tester
Posts: 4
Joined: Fri 01 Mar, 2013 4:59 pm
Contact:

Re: State transition exercise

Post by truongtnd »

Rất dễ hiểu,hy vọng tvn có thêm những ví dụ/bài tập như vậy để cho những bạn chưa có kn nắm vững các kỹ thuật nhé :)



trang123456
Hoc Tester
Posts: 2
Joined: Mon 25 Mar, 2013 5:13 pm
Contact:

Re: State transition exercise

Post by trang123456 »

Bạn tvn có thể public nick yahoo cho mình biết được ko



tvn
Admin
Posts: 4900
Joined: Tue 10 Aug, 2010 10:11 am
Location: HCM
Contact:

Re: State transition exercise

Post by tvn »

Bạn để ý chỗ tên bên phải sẽ thấy nick chat.

thân



kysudientu
Jr. Tester
Posts: 68
Joined: Wed 25 Dec, 2013 9:30 pm
Contact:

Re: State transition exercise

Post by kysudientu »

Hi tvn,

Bài viết của bạn rất hay. Cho mình hỏi là khi định dạng cho loại test case này thì mình sẽ để là Functional test case đúng không bạn.



Post Reply

Return to “Black box Testing - Kiểm thử hộp đen”