Experience in Writing Test Cases

Abstract:♂Star nest

Background:

I have never wanted to take the Technical aspectsArticleI wrote it to you to show you that I was afraid that my writing skills would not be good, and I was afraid that some of my first-entry testing peers would not be able to express myself. On the other hand, I was afraid that some of my peers would take advantage of the hype, in addition, there are already a lot of materials on the test cases on the testing website forum. However, I have been asking questions about test cases from my peers, and I am eager to know my experiences in writing test cases. I want to write it in a try-and-Try manner. I hope the old testers can see it and give me more suggestions.

Experience in Writing Test Cases

On my personal mailbox and MSN, my colleagues usually ask me questions similar to the following:

1. To what extent should a test case be written?

2. At the beginning of the test, how did you learn to write test cases?

3. What are your experiences in writing black box test cases? Are there any good versions or standards?

For test cases, the question I am currently thinking about is: How to Write test cases that are valuable to the company? For the company, how to test is the most valuable?

Next, let's analyze the first question: to what extent should a test case be written?

There is no attribute in this question, not in what circumstances, so I can only talk about what I encountered at work. It's a long story. You have to be patient. Pai_^

In my testing work, I have encountered four types of testing: project testing, product testing, product personalized testing, and third-party acceptance testing. Project testing refers to the software I tested as a project and used by a specific user. Product testing refers to the software I tested as a general product for many users. Product personalization testing refers to the software I tested. A user puts forward special features when using the product. In response to these new features, the product has been individually modified for users. We should be familiar with third-party acceptance tests, so we do not need to explain them here.

When testing projects and products, we usually need to consider the cycle and test resources of this project. In my company, project development usually takes 4 to 5 months. However, testing is usually completed at the end of development. One person is responsible for testing. Therefore, time and human resources are a risk for testing. In this case, I am familiar with the business of the system first, grasp the key business and functions, refer to the requirements, and give the test requirements, test plans and test outlines. Due to the time relationship, test cases are all focused services, that is, test cases of integrated testing. In addition, the test cases are based on the test outline. Usually, you must first select the most important test items and risky business functions to write test cases. Because the test cases are executed by myself, the test cases can be written simply, but developers must be able to understand them. Unfortunately, no one in my company came to view my test cases. The test case is used to remind me not to forget the items to be tested. Some valuable bugs are not often found when writing test cases, but during the software testing process, I think about them before going home and going home. This is the charm of manual testing. Some Software defects are suddenly discovered when you use the software. Therefore, it is better for me to answer how many test cases should be written. I feel that as long as your written test cases can be smoothly executed in your company, it does not affect your test execution. Because the test cases are written in too detailed, you need to spend time and manpower, the test cases are the best and most expensive. Once the demand changes, you also need to modify them, at this time, you will find that such detailed test cases are the least profitable. The test case is too rough to be understood by others and cannot be executed. It takes you time to explain it, which increases the test workload. This is not a good method.

The second question is, how did you learn to write test cases when you started testing?

I chose to test this job because, after graduation, I had technical support in my first company, and there were many product problems. As a result, the technical support work was very hard and tiring. In order to make the quality of the products purchased by users good, I chose to do the test, and now the company. When I was just doing a test, I didn't know anything about the test, what test process, and document, and the company's test and management were not standardized. For the test, we all think that it is not just a point with a mouse, anyone can do it. For this reason, I often access the Internet to check the testing materials and find out what kind of career I am suitable for or not for testing, and how I plan my personal development. In fact, it is not easy to do a good test. I really cannot do this job.

Now it's funny to think about writing test cases. Just like a child learning to write. First, I searched for a test case template on the Internet. After combining a few templates, it was formed. The reason why I don't need the company's original test case template is that it is too inapplicable. Fortunately, the company does not strictly require that template, as long as it applies. The template has been found, but it is hard to write. It's not easy to write a new person who just did the test in a seemingly simple form filling job. It was not natural to write at the beginning, and it was quite slow. There was no way. At that time, no one guided me, and I had to learn and comprehend it all by myself. So that was a bitter time! After writing a few more times, you will know and understand that the test cases should be written according to the test outline, and the test outline should be written according to the test plan. The test outline focuses more on the direction of the test items, while the test cases guide how to perform the test. Fortunately, I have programming experience, so I am very familiar with the software. Only when you are familiar with the software business can you write test cases and perform tests better. This is what I learned from 1.1 points. Having said so much, I don't know if such an answer answered this question.

The last question is: I try to write less. If there are too many texts, you will be tired of reading them, and I will be tired of writing them. Hey. Pai_^

What are your experiences in writing black box test cases? Are there any good versions or standards?

My experience:

1. Test cases should be compiled according to the test outline

2. Test cases should also be classified into test items for better analysis and reading. Such as business process testing, installation testing, function testing, user-friendly testing, compatibility testing, performance testing, and security testing.

3. Write test cases to consider various situations and focus on the main business processes and high risks of the software. It is best to prioritize tests.

4. Be familiar with the system and be helpful for compiling test cases.

5. Even if you are familiar with the test, it is necessary and advantageous to compile the test case when the time is very tight.

Today, I thought about it, and I thought about it later. I will paste the template I used to you for some reference, but it depends on whether it is applicable to your company. I will not list the classification of test items, because each company is not the same.