Cách viết test case hoàn chỉnh - test case design • 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.

Cách viết test case hoàn chỉnh - test case design

Tất cả các câu hỏi liên quan đến test case

Cách viết test case hoàn chỉnh - test case design

Postby tvn » Wed 10 Nov, 2010 9:50 am

8 hướng dẫn để viết test case hoàn chỉnh

By Marcin Zręda

How can you explain to a beginner tester the idea of writing, executing and reporting of test cases? It’s a tough job, I found this quite recently by training a new person in the team. Everything I had in my head but there was not one clear and consistent explanation on the paper. Many years of experience, unfortunately, has not helped me to verbally justify and explain this issue. This post will be an attempt to complete my own thoughts and these coming from the environment.

For begining, a few sentence to clarify what are the test cases and test scenarios and how they are different and in what order must exist. Starting from the end, let us answer the question “why?”. Test case is a description, a recipe for tester, dealing with how to test a given functionality and how to check whether this works correctly. Looking at the structure, we can identify types of relationship: Test scenario -> test case -> Test Step. Starting from the end again, because it will be easier, I can write:

* Test Step – specifies an action to perform, and the expected response of the test application. For example: Action : Type the password in the password box, Expected result: Your password should be dotted / hidden.
* Test Case – a list of test steps. Also defines the environmental situation and may link to related bugs, requirements etc.
* Test Scenario – usually comes directly from business requirements or userstory. Management tools often ignore test scenario for linkage with a list of the requirements. Scenario contains a list of test cases and often their sequence.

As you can see, varies between a test case scenario is significant, and often the two concepts are confused.
How to ensure the quality of the test cases are created? How to manage their life cycle? How to deliver them quickly and when developers need it ?

1. Template – need one and complete template for creating test cases. We can create it in a text editor, spreadsheet or buy or customize the tool. I have written about this in the context of the JIRA.

2. Descriptive and specific – you need a short, concise title and description. Should clearly define the purpose and scope of their operations. We are writing to all testers, not only for yourself, use simple language, complicated language figures are not popular here. Use rather imperative, therefore “Write abc and press enter” not “I am writing abc, and pressing Enter.”

3. Reusable – one and the same test case can be used in many scenarios. Let us remember that! Creating a new item, we must imagine a different kind of use case of our work. I also imagine that test step could be reused, so pay your attention at this level too.

4. Atomic – the greatest tester nightmare struggled with the manual testing is a test case, which is too long and doing too much dependency checks. Person carrying out a process must have a sense of progress, otherwise is bored, reducing its vigilance, and motivation. Tester may have to perform 100 test cases and do them in one day, but it can also have their 10 and do it for a week. Let us create test case, which can be performed up to several minutes, and gain the favor of the other fellow testers, among the satisfied, we can also include those who write automation scripts.

5. Positive and negative – the next important thing is the order of creation. What to do when the project manager requests a set of test cases on the day following approval of an implementation plan? Usually we do not say that he wanted only the beginning of positive tests, those which check whether the functionality exists and acts in accordance with the requirement. Give him as such set as soon as possible, then we can deal with the preparation of a negative description situation and the relationship between other requirements. To sum up: Positive -> Negative -> Relationships

6. Refactor – if you already done your job we have to remember that applications are changing and the changes in the test cases should follow this process. We can version it, using clone and change method for a given version number. Head of the tests should determine how many past versions we support and we should care enough about our current collection of test cases.

7. Test data – there are moments in which along the correct execution of the test we have to provide some data, which usually (if they are too complex to be described in the text) are attached as binary files. We need to analyze whether it is easier to provide test data or may be easier to add the appropriate test steps.

8. Setup and tear down – if the test case requires the initial configuration, call a particular component, we need to take this into account in the zero step. It is also important to cleanup in the last step like in unit testing or automation, but I believe that during the test manual is worth to preserve this good practice.

Summary
Take to heart my observations if you do not agree write a comment. Perhaps I skipped something, if I drop what I will do an update. At this moment it appears as a complete manual. I promise that soon we will put post in which I will describe exactly the structure of the template test case.

Nguồn: http://www.vietnamesetestingboard.org
tvn
 
Posts: 4688
Joined: Tue 10 Aug, 2010 10:11 am
Location: HCM

Re: Hướng dẫn viết test case hoàn chỉnh

Postby tvn » Mon 29 Nov, 2010 5:16 pm

8 hướng dẫn viết test case hoàn chỉnh

By Marcin Zręda

--- Bản dịch sang Tiếng Việt ---

Làm thế nào để bạn giải thích cho một tester mới vào nghề về cách viết, thực hiện và báo cáo các test case? Đó là một công việc khó khăn, tôi đã nhận ra điều này khá gần đây trong lúc đào tạo một tester mới trong nhóm. Tôi đã có mọi thứ trong đầu nhưng không có một lời giải thích rõ ràng và nhất quán trên giấy tờ. Tôi đã có nhiều năm kinh nghiệm, không may, cũng không giúp tôi biện minh và giải thích vấn đề này. Bài viết này là một cố gắng để hoàn thành những suy nghĩ của tôi đến từ môi trường sản xuất phần mềm.

Để bắt đầu, sẽ có một vài câu để làm rõ về các test case và test scenario và chúng khác nhau như thế nào và theo thứ tự nào. Bắt đầu từ cuối cùng, chúng ta hãy trả lời câu hỏi "thứ tự nào?"

Test case là sự mô tả, công thức cho tester, liên hệ giữa việc làm thế nào để test chức năng và làm thế nào để kiểm tra hệ thống hoạt động đúng hay không. Nhìn vào cấu trúc, chúng ta có thể định nghĩa được các loại quan hệ: Test scenario -> test case -> Test Step. Lại bắt đầu từ cuối cùng, bởi vì như vậy sẽ dễ dàng hơn, Tôi có thể viết như sau:

* Test Step – quy định cụ thể một hành động để thực hiện, và đáp ứng mong đợi của ứng dụng test. Ví dụ:
Hành động: Nhập password vào ô password,
Kết quả mong đợi: password của bạn sẽ hiển thị là *** hoặc ẩn.

* Test Case – là một danh sách các test step. Cũng định nghĩa trạng thái môi trường và có thể liên kiết đến các bug, spec (đặc tả yêu cầu) liên quan,…

* Test Scenario – thường có được trực tiếp từ các đặc tả yêu cầu của khách hàng hoặc user-story. Các công cụ quản lý thường bỏ qua test scenario để kết nối với một danh sách các đặc tả yêu cầu. Scenario chứa một danh sách các test case và nhiều phối hợp của chúng.

Như các bạn có thể thấy, sự khác nhau giữa test scenario và test case là đáng kể, và thường thường hai khái niệm này thì mơ hồ.
Làm thế nào để đảm bảo chất lượng cho test case đã tạo được? Làm thế nào để quản lý life cycle của nó? Làm thế nào để hoàn thành nó sớm và khi nào thì Dev cần nó?

1. Template – cần một hoặc nhiều mẫu hoàn thành để viết test case. Chúng ta có thể tạo test case trong MS Word, MS excel hoặc mua hoặc chỉnh sửa lại các tool khác. Tôi đã viết bài này bằng chương trình soạn thảo JIRA.

2. Descriptive và specific – các bạn cần miêu tả tiêu đề ngắn gọn, xúc tích. Nên định nghĩa các mục đích và phạm vi của các hoạt động test một cách rõ ràng. Chúng ta đang viết cho tất cả các tester, chứ không chỉ viết riêng cho chính mình, sử dụng ngôn ngữ đơn giản, miêu tả bằng ngôn ngữ phức tạp trong test case thì không phổ biến. Nên dùng theo kiểu câu mệnh lệnh, ví dụ, nên ghi là “Nhập abc và nhấn enter” chứ không nên ghi “Tôi đang nhập abc, và sau đó nhấn Enter.”

3. Reusable – một và nhiều test case giống nhau có thể được sử dụng trong nhiều scenario. Hãy nhớ rằng! Khi tạo một hạng mục mới, chúng ta phải tưởng tượng ra một loại use case khác với loại mà chúng ta đang làm. Tôi cũng tưởng tượng rằng bước test cũng có thể được tái sử dụng, vì vậy bạn cũng phải nên chú ý đến mức này.

4. Atomic – ác mộng lớn nhất của tester vật lộn với test thủ công (bằng tay) là test case, vì nó có quá dài và làm quá nhiều kiểm tra phụ thuộc nhau. Người tiến hành một tiến trình phải có ý thích về tiến trình đó, ngược lại thì thật chán, giảm cảnh giác với nó, và nhiệt huyết. Tester có thể phải thực hiện 100 test case và thực hiện nó trong một ngày, nhưng nó cũng có thể có 10 test case và thực hiện nó trong 1 tuần. Chúng ta hãy tạo test case, điều này có thể làm trong vài phút và nó giúp ta giành được nhiều thiện chí của các tester đồng nghiệp khác hơn, trong số các sự hài lòng, chúng ta cũng có thể là người viết script test tự động.

5. Positive and negative (test trường hợp đúng và trường hợp sai) – điều quan trọng tiếp theo là thứ tự của việc tạo test case. Làm gì khi project manager yêu cầu một tập test case vào một ngày đã duyệt trong kế hoạch tiến hành? Thường thì chúng ta không nói rằng anh ấy chỉ muốn bắt đầu bằng các trường hợp test tích cực (chỉ test trường hợp đúng), các trường hợp này là dùng để kiểm tra chức năng tồn tại và các hành động theo đúng với spec (đặc tả yêu cầu của khách hàng). Đưa cho anh ta một tập test case càng sớm càng tốt, thì chúng ta có thể thương lượng anh ta phê chuẩn các trường hợp test sai và các quan hệ giữa các yêu cầu khác. Tóm lại: Positive -> Negative -> Relationships

6. Refactor – nếu bạn đã sẵn sàng kết thúc công việc thì chúng ta phải nhớ rằng các ứng dụng thì thay đổi và các thay đổi trong test case sẽ làm theo trình tự này (theo 8 bước này). Chúng ta nên tạo version cho nó, bắt chước cách thay đổi version number (1.0 -> 1.1 ->…). Quản lý test (ví dụ QC leader) sẽ ước lượng chúng ta sẽ làm có bao nhiêu version và chúng ta nên quan tâm về tập hợp các test case hiện tại của chúng ta.

7. Test data (dữ liệu dùng để test) – đây là những điều quan trọng song song với việc thực hiện test đúng thì chúng ta phải cung cấp một số data, thường thì (nếu nó quá phức tạp để mô tả trong tài liệu này) được đính kèm bằng một file khác. Chúng ta cần phải phân tích cho dù nó dễ cung cấp test data hay dễ thêm vào các bước test thích hợp.

8. Setup and tear down (sắp xếp và tỉa tót lại test case) – nếu test case yêu cầu phải có cấu hình ban đầu, gọi một component riêng biệt, chúng ta cần phải mô tả nó về bước đầu tiên (zero step). Điều này cũng quan trọng để dọn dẹp trong bước bước cuối cùng giống như trong test unit (whitebox) hoặc test tự động, nhưng tôi tin rằng test thủ công thì đáng để sử dụng tốt các bước thực hành này.

Cuối cùng
Phải sử dụng hết khả năng quan sát nếu bạn không đồng ý với việc ghi lại ghi chú. Có lẽ tôi đã giữ lại một số điều, nếu tôi có bỏ sót điều gì tôi sẽ cập nhật lại sau. Lúc này tôi chỉ có thể nghĩ ra bấy nhiêu đây thôi. Tôi hứa là sẽ post bài giải thích cấu trúc của một mẫu test case.

----
Tham khảo cách thiết kế test case tốt khác

Các Kỹ Thuật Thiết Kế Test Case trong Black Box Testing
----
tvn
 
Posts: 4688
Joined: Tue 10 Aug, 2010 10:11 am
Location: HCM







Return to Test cases - Tập hợp các trường hợp kiểm thử

Who is online

Users browsing this forum: No registered users and 3 guests