Giúp mình về State Transition Testing • testingvn.com


Thông báo về việc đăng ký mới thành viên: Sau khi đăng ký thành viên xong, các bạn vui lòng Thông báo cho Quản Trị Viên theo link này
để Quản Trị Viên sẽ kích hoạt tài khoản cho các bạn nhé. Xin lỗi vì sự bất tiện này.

Giúp mình về State Transition Testing

Chuyên đề thảo luận về kiểm thử hộp đen (Black-box Testing)
Nội qui chuyên mục
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.

Giúp mình về State Transition Testing

Gửi bàigửi bởi minhokok » T.Ba 26 Tháng 10, 2010 12:04 pm

GIúp mình về kĩ thuật kiểm thử này với
minhokok
 
Bài viết: 6
Ngày tham gia: T.Ba 26 Tháng 10, 2010 11:38 am

Re: Giúp mình về State Transition Testing

Gửi bàigửi bởi tvn » T.Ba 26 Tháng 10, 2010 4:07 pm

Bạn thử tìm hiểu thử file tài liệu này nha.

Nội dung của tài liệu

• Introduction
• State transition testing
• Example
• Exercises
• Conclusion

Vui lòng down về nhé
Vui lòng đăng nhập để thấy link download.
tvn
 
Bài viết: 4580
Ngày tham gia: T.Ba 10 Tháng 8, 2010 10:11 am
Đến từ: HCM

Re: Giúp mình về State Transition Testing

Gửi bàigửi bởi tvn » T.Ba 26 Tháng 10, 2010 4:12 pm

Bạn cũng có thể tham khảo thêm nhiều thông tin khác ở đây

State transition table

1 Common forms
1.1 One-dimensional state tables
1.2 Two-dimensional state tables
2 Example
3 Transformations from/to state diagram


1. Common forms
1.1. One-dimensional state tables

Also called characteristic tables, single-dimension state tables are much more like truth tables than the two-dimensional versions. Inputs are usually placed on the left, and separated from the outputs, which are on the right. The outputs will represent the next state of the machine. Here's a simple example of a state machine with two states, and two combinatorial inputs:

Hình ảnh

S1 and S2 would most likely represent the single bits 0 and 1, since a single bit can only have two states.

1.2. Two-dimensional state tables

State transition tables are typically two-dimensional tables. There are two common forms for arranging them.

* The vertical (or horizontal) dimension indicates current states, the horizontal (or vertical) dimension indicates events, and the cells (row/column intersections) in the table contain the next state if an event happens (and possibly the action linked to this state transition).

Hình ảnh

(S: state, E: event, A: action, -: illegal transition)

* The vertical (or horizontal) dimension indicates current states, the horizontal (or vertical) dimension indicates next states, and the row/column intersections contain the event which will lead to a particular next state.

Hình ảnh

(S: state, E: event, A: action, -: impossible transition)

2. Example
An example of a state transition table for a machine M together with the corresponding state diagram is given below.

Hình ảnh

All the possible inputs to the machine are enumerated across the columns of the table. All the possible states are enumerated across the rows. From the state transition table given above, it is easy to see that if the machine is in S1 (the first row), and the next input is character 1, the machine will stay in S1. If a character 0 arrives, the machine will transition to S2 as can be seen from the second column. In the diagram this is denoted by the arrow from S1 to S2 labeled with a 0.

For a nondeterministic finite automaton (NFA), a new input may cause the machine to be in more than one state, hence its non-determinism. This is denoted in a state transition table by a pair of curly braces { } with the set of all target states between them. An example is given below.

Hình ảnh

Here, a nondeterministic machine in the state S1 reading an input of 0 will cause it to be in two states at the same time, the states S2 and S3. The last column defines the legal transition of states of the special character, ε. This special character allows the NFA to move to a different state when given no input. In state S3, the NFA may move to S1 without consuming an input character. The two cases above make the finite automaton described non-deterministic.

3. Transformations from/to state diagram

It is possible to draw a state diagram from the table. A sequence of easy to follow steps is given below:

3.1. Draw the circles to represent the states given.
3.2. For each of the states, scan across the corresponding row and draw an arrow to the destination state(s). There can be multiple arrows for an input character if the automaton is an NFA.
3.3. Designate a state as the start state. The start state is given in the formal definition of the automaton.
3.4. Designate one or more states as accept state. This is also given in the formal definition.


Nguồn: http://en.wikipedia.org/wiki/State_transition_table
tvn
 
Bài viết: 4580
Ngày tham gia: T.Ba 10 Tháng 8, 2010 10:11 am
Đến từ: HCM

Re: Giúp mình về State Transition Testing

Gửi bàigửi bởi minhokok » T.Ba 26 Tháng 10, 2010 9:21 pm

2 cái này mình có coi qua rồi nhưng có 1 số từ mình k dịch được, dù sao cũng cảm ơn bạn ^^
minhokok
 
Bài viết: 6
Ngày tham gia: T.Ba 26 Tháng 10, 2010 11:38 am

Re: Giúp mình về State Transition Testing

Gửi bàigửi bởi tvn » T.Ba 26 Tháng 10, 2010 10:42 pm

Những chỗ bạn chưa rõ hoặc những từ bạn không dịch được, bạn có thể đưa ra để mọi người giúp bạn được không? Mình có thể thảo luận để hiểu rõ hơn vấn đề này.

Theo mình hiểu thì test chuyển trạng thái là quan sát theo dõi sự chuyển từ trạng thái này sang trạng thái khác khi có tác động gì đó, ví dụ như test sự phân trang khi hiển thị nhiều record trong 1 datagrid hoặc checkbox check all, khi click vào nó thì các checkbox trong cột sẽ được chuyển sang cheked, và ngược lại.

Có rất nhiều trường hợp như vậy, 2 bài trên mô tả và có ví dụ để mình có thể hình dung được nội dung của vấn đề test chuyển trạng thái.

Vấn đề này mình cũng chưa từng tìm hiểu cho tới khi bạn yêu cầu, mặc dù mình cũng đã từng làm việc test chuyển trạng thái nhưng mình không nhận ra điều đó, và nhiều bạn khác cũng vậy, mặc dù đang làm nhiều việc như test unit, test integration nhưng các bạn không biết vì các bạn không nghiên cứu lý thuyết hoặc không quan tâm đến lý thuyết mà chỉ đọc spec và viết test case rồi test.

Mong bạn chia sẻ với mình vấn đề test chuyển trạng thái này.
tvn
 
Bài viết: 4580
Ngày tham gia: T.Ba 10 Tháng 8, 2010 10:11 am
Đến từ: HCM

Re: Giúp mình về State Transition Testing

Gửi bàigửi bởi minhokok » T.Tư 27 Tháng 10, 2010 2:36 pm

Mình có cái định nghĩa về loại kiểm thử này nhưng sao thấy khó hiểu quá:
State transition testing is useful for both procedural and object-oriented development. It is based on the concepts of states and finite-state machines,and allows the tester to view the developing software in term of its states, transitions between states, and the inputs and events that trigger state changes. This view gives the tester an additional opportunity to develop test cases to detect defects that may not be revealed using the input/output condition as well as cause-and-effect views presented by equivalence class partitioning and cause-and-effect graphing. Some useful definitions related to state concepts are as follows:
A state is an internal configuration of a system or component. It is defined in terms of the values assumed at a particular time for the variables that characterize the system or component.
A finite-state machine is an abstract machine that can be represented by a state graph having a finite number of states and a finite number of transitions between states.
minhokok
 
Bài viết: 6
Ngày tham gia: T.Ba 26 Tháng 10, 2010 11:38 am

Re: Giúp mình về State Transition Testing

Gửi bàigửi bởi tvn » T.Năm 28 Tháng 10, 2010 9:12 am

Qua các định nghĩa trên đây của bạn, mình đã tìm hiểu thêm và có thể dịch ra Tiếng Việt như sau, nếu thắc mắc chỗ nào bạn có thể trao đổi tiếp nhé. Qua đây mình cũng học được nhiều điều hay mà trước giờ mình chưa tìm hiểu vì công việc chưa yêu cầu tới. Thanks.

Kiểm thử chuyển trạng thái (State transition testing) dùng được cho cả phát triển theo hướng thủ tục hoặc hướng đối tượng. Nó dựa trên các khái niệm trạng thái (states) và máy mô phỏng trạng thái (finite-state machines viết tắt là FSM), và cho phép các tester xem sự phát triển phần mềm trong một số điều kiện trạng thái của nó, các quá trình chuyển đổi giữa các trạng thái và các điều kiện nhập đầu vào và các sự kiện kích hoạt thay đổi trạng thái. Việc xem xét này làm cho các Tester có thêm cơ hội để phát triển test case để phát hiện ra lỗi mà có thể không phát hiện được bằng điều kiện input, output bình thường cũng như việc xem đồ thị nguyên nhân – kết quả (cause-and-effect) được lập ra từ việc phân lớp tương đương và vẽ đồ thị nguyên nhân – kết quả. Một số định nghĩa hữu ích liên quan đến khái niệm trạng thái như sau:

Trạng thái là cấu hình bên trong của một hệ thống hoặc chức năng (component). Nó được định nghĩa dựa trên điều kiện các giá trị giả định tại một thời điểm riêng biệt cụ thể cho các biến đặc trưng cho hệ thống hoặc chức năng.

FSM: là một thiết bị mô phỏng các hành vi (là mô hình trừu tượng hóa toán học đổi khi dùng để thiết kế ra các lohic kỹ thuật hoặc các chương trình máy tính) bao gồm một số trạng thái có hạn, quá trình chuyển đổi qua lại giữa các trạng thái và các hành động tương tự như một đồ thị luồng xử lý (flow graph), trong đó mình có thể kiểm tra các bước chạy logic khi các điều kiện nhất định được đáp ứng. Nó có bộ nhớ trong, một chức năng nhập đầu vào (input) có thể đọc được những ký hiệu liên tục trong một thời điểm mà không cần phải quay lại và một chức năng output có thể là một hình thức giao diện người dùng khi mô hình hoạt động. Cách hoạt động của một FSM được bắt đầu từ một trạng thái (gọi là trạng thái khởi tạo), đến các chuyển đổi sang các trạng thái khác nhau phụ thuộc vào điều kiện nhập và có thể kết thúc ở bất kỳ trạng thái nào hợp lệ, tuy nhiên chỉ có một tập các trạng thái được đánh dấu là luồng xử lý thành công (được gọi là các trạng thái chấp nhận).

Hình ảnh Hình ảnh

Hình tham khảo ở http://en.wikipedia.org/wiki
tvn
 
Bài viết: 4580
Ngày tham gia: T.Ba 10 Tháng 8, 2010 10:11 am
Đến từ: HCM

Re: Giúp mình về State Transition Testing

Gửi bàigửi bởi minhokok » T.Ba 02 Tháng 11, 2010 11:12 pm

uhm cảm ơn bạn nhiều lắm, à sẵn đây mình muốn hỏi bạn luôn chắc bạn có nhiều kinh nghiệm về test phần mềm, bạn có thể cho mình vài ví dụ đơn giản về phương pháp đoán lỗi (error guessing) không, mình mới năm 2 nên chưa có kinh nghiệm lắm nên khó lấy được ví dụ
minhokok
 
Bài viết: 6
Ngày tham gia: T.Ba 26 Tháng 10, 2010 11:38 am

Re: Giúp mình về State Transition Testing

Gửi bàigửi bởi tvn » T.Tư 03 Tháng 11, 2010 8:28 am

Mình cũng mới làm tester chỉ được một năm thôi, nên nói về kinh nghiệm thì không nhiều lắm. Chủ yếu mình vẫn đang học hỏi kinh nghiệm từ nhiều bạn khác trên đây, và mình tìm hiểu theo câu hỏi của các bạn hỏi, vì khi mình trả lời thì có bạn sẽ chỉnh chỗ sai cho mình, như vậy ngày qua ngày mình sẽ khá hơn.

Nói về đoán lỗi thì mình chia sẻ những gì mình biết nha, kỹ thuật này đòi hỏi kinh nghiệm là chủ yếu, vì sau quá trình mình làm việc nhiều, mình đã gặp nhiều trường hợp, gặp nhiều qui trình xử lý công việc rồi nên khi gặp một dự án mới, một phần mềm mới, mình sẽ biết được dạng phần mềm này hay loại màn hình này (ví dụ màn hình search, màn hình login, màn hình thêm mới, edit, delete,...) thì thường gặp những lỗi gì. Hoặc sau khi thực hiện một vài thao tác thì kết quả phải xảy ra như thế nào,...

Ví dụ:

Đối với màn hình search:
+ Thường xảy ra lỗi search cả những record đã bị xóa (del_flg = 1) vì vậy khi viết test case và test màn hình search thì nên thêm vào test case này (gán del_flg = 1 cho một số record rồi thực hiện search, nếu những record này được hiển thị trên màn hình thì sai).
+ Tiếp theo, nhập điều kiện sao cho khi search được 0 record thì không hiển thị được màn hình mà lại báo lỗi "Null pointer" do trong code không xử lý khởi tạo list chứa danh sách các record search được.
+ Phần phân trang, thường thì mong muốn là: (giả sử phân trang là 20 records - một trang chỉ chứa được 20 dòng)
. ++ Search được 0 record thì chỉ hiển thị header (phần datagrid chỉ hiển thị header)
. ++ Search được 20 records thì hiển thị header và 20 dòng này trên 1 trang
. ++ Search được 21 records thì hiển thị header và 20 dòng này trên trang 1 và 1 dòng trên trang 2.
. ++ Search được 50 records thì hiển thị header và 20 dòng này trên 1 trang và 20 dòng trên trang 2 và 10 dòng trên trang 3
Nhiều khi DEV quên xử lý phân trang thì khi search được nhiều hơn số record chứa trong 1 trang thì bị lỗi hoặc hiển thị tất cả trên 1 trang.
Trong trường hợp đang hiển thị nhiều trang thì click Next và Prev để kiểm tra xem có qua lại giữa các trang được không nhé vì cũng hay bị lỗi chỗ này nếu là control này do mình tự viết (thường thì dùng component của framework nhưng trong ADF thì thường tự viết bằng java để dễ kiểm soát)

Đối với màn hình Login:
+ Chú ý phần bảo mật: Đôi khi DEV code thì gán user name là "admin" và pass là rỗng hoặc là "123" vì vậy mình nên thử trường hợp này.
+ Thử thử các trường hợp SQL injection
+ Để user name và pass rỗng rồi enter. (nhiều khi DEV không xử lý action enter cho login mà phải click button login)

Đối với màn hình Thêm Xóa Sửa:
+ Ở loại màn hình này thường xảy ra lỗi là khi thêm mới vào lần thứ 2 trở đi thì bị báo lỗi exception (lý do: do cách xử lý ID khi thêm mới, thêm lần thứ 2 thì bị trùng ID với lần trước nên DB server không cho insert thêm => lỗi, theo nguyên tắc thì sau khi thêm mới thì load lại data nhưng nhiều DEV không làm đúng như vậy)
+ Những record đã bị xóa thì không được hiển thị lên danh sách xóa - sửa (tương tự màn hình search - vì khi load danh sách là search all)
+ Nếu chương trình có yêu cầu xử deadlock thì thường xảy ra lỗi khi 2 người ngồi trên 2 máy khác nhau cùng sửa trên 1 record cùng lúc.
Cách test: mở 2 màn hình thêm xóa sửa giống nhau bằng 2 browser khác nhau. sau đó sửa trên browser 1 rồi lưu lại (thành công); Tiếp theo sửa trên browser 2 rồi lưu lại, xử lý đúng là hiển thị thông báo lỗi "record này đã được sửa bởi người khác" nghĩa là không cho mình sửa nữa, muốn sửa thì refresh lại màn hình hoặc làm sao đó để load lại data rồi sửa. Xử lý sai là không hiển thị thông báo lỗi mà cho sửa luôn.
(Tình huống của việc này như sau: 9h sáng, Trưởng phòng và Giám đốc cùng mở màn hình xét thưởng, tại một thời điểm nào đó 2 người cùng click vào sửa field thưởng tháng 13 của nhân viên A. Giám đốc cho giá trị 300đồng, rồi lưu lại và nghĩ là nhân viên A sẽ được thưởng 300đồng. Trong khi đó Trưởng phòng cũng mở nội dung thông tin của nhân viên A, và cho field thưởng tháng 13 là 350đồng, và click button Save sau Giám đốc một xíu xiu (ví dụ < 1s) thì giá trị "thưởng tháng 13" của nhân viên A là 350đồng. Như vậy thì chương trình đã vô tình làm cho con người thao tác sai, Nếu chương trình tốt thì phải hiển thị thông báo lỗi khi Trưởng phòng click save. Vì data lúc đó đã khác so với data trước khi load lên để sửa.

Còn nhiều vấn đề nhưng mình không biết nói như thế nào, có gì thắc mắc bạn cứ hỏi mọi người sẽ giúp.
tvn
 
Bài viết: 4580
Ngày tham gia: T.Ba 10 Tháng 8, 2010 10:11 am
Đến từ: HCM

Re: Giúp mình về State Transition Testing

Gửi bàigửi bởi minhokok » T.Tư 03 Tháng 11, 2010 4:12 pm

Designing test cases using the error guessing approach is based on the tester’s/developer’s past experience with code similar to the code-undertest, and their intuition as to where defects may lurk in the code. Code similarities may extend to the structure of the code, its domain, the design approach used, its complexity, and other factors. The tester/developer is sometimes able to make an educated “guess” as to which types of defects may be present and design test cases to reveal them. Some examples of obvious types of defects to test for are cases where there is a possible division by zero, where there are a number of pointers that are manipulated,or conditions around array boundaries. Error guessing is an ad hoc approach to test design in most cases. However, if defect data for similar code or past releases of the code has been carefully recorded, the defect types classified, and failure symptoms due to the defects carefully noted,this approach can have some structure and value. Such data would be available to testers in a TMM level 4 organization.

Mình muốn hỏi bạn 1 phần nữa là ở phần chữ in đậm "TMM level 4 organization" có nghĩa là gì vậy ??? => xem ở trang tiếp theo
minhokok
 
Bài viết: 6
Ngày tham gia: T.Ba 26 Tháng 10, 2010 11:38 am

Trang kế tiếp

Quay về Black box Testing - Kiểm thử hộp đen

Đang trực tuyến

Đang xem chuyên mục này: Yahoo [Bot]1 khách.