If you are looking for a functional testing job, during the software testing engineer interview process, some interviewers will ask one or two very simple questions
What is Test Case?
How did you write Test Case?
Let's take a look at the introduction of test cases
What are test cases?
Test Case (Test Case) is a set of test inputs, execution conditions and expected results prepared for project requirements in order to test whether a certain program meets customer needs.
In fact, the test case is a document, or a descriptive document.
The document includes some key content such as input, conditions, and expected results. Through your conditions, input and expected results, I can judge whether this program satisfies customers when it is executed ( User's needs. We call this type of document a test case. (The tester's basis content)
Of course, for some irregular or small companies. I was originally a software test engineer, and then I didn't have time to write test cases, so I took the software and started the test directly, then in this case, it also has no test cases.
But in the absence of test cases, it is very likely to cause a lot of problems, such as missed testing, such as repeated testing, and the inability to measure the amount of work completed by software testing. There is no basis and so on.
So for companies that are slightly more standardized, we have to write test cases, and we will spend a lot of time on writing test cases.
Why write test cases?
- 1. Familiar with the business of the software under test
- 2. Clarify the thinking and way of testing
- 3. Ensure that test function points are not missed during testing
- 4. An output of the test job
Just to avoid some of the problems mentioned above.
The first one is that when we write test cases, we are actually familiar with the process of software testing business. In fact, this is very necessary, including before we test this project, for example, if you go to a new company, you or The month before, you were doing the same thing-looking at the documentation.
Get familiar with the business of the tested software as soon as possible by looking at the documentation.
The more familiar you are with the business of the software being tested, the more accurate you can test during the testing process. Some unnecessary errors can be avoided.
Second, we can clarify our thinking and methods in software testing.
Third, this is an output of your work in software testing. In other words, I went to get off work at 9 o'clock in the morning and got off work at 6 o'clock in the evening. When the boss asked you what you did today, you didn't have this and that. I wrote the test cases. I wrote three to five hundred test cases a day. This is also a measure of work. (Of course there are no hard and fast rules for how many items)
Test cases that can find bugs are good use cases? This is wrong!
What is a good test case?
Test cases that can fully cover the requirements are good test cases
The scope of use of
test cases 1. Manual test cases (functional testing)
2. Automated testing (interface automation, UI automation)
3. Performance test cases
Whether in manual testing, automated testing, or performance testing, we all need to write test cases .
Four elements of test cases
Context-preconditions, entry conditions
For example, if we want to log in to Zhihu, what are his conditions? Do we have to install Zhihu first? This is his context. For another example, if we want to post an article on Zhihu, his prerequisite is also to log in. The operation of this login is his context or precondition)
Test Data
Test data is very critical. For example, the login data we know is the user name and password. Only when you are ready, you can test this function. This data is very large, and here we have to think of one point, which cannot be exhaustively tested. We will talk about this when we talk about testing principles. Because of the limited time of our project in the first, and the limited labor cost in the second, the amount of data in the third is so huge that we simply cannot perform an exhaustive test on it. Because we have to classify and filter these data. Choose some representative data to test.
For test data, some methods must be used to classify it, and some representative data should be selected. This one is actually a very important part of our test cases, which is the method of designing use cases. Including equivalence classes, boundary values, decision tables, etc., are all to help you filter the data.
Test steps
What to do in the first step, what to do in the second step, what to do in the third step, this is easy to understand. Because we write test cases not only for ourselves. First of all, you must understand the test cases you write yourself. In addition to being able to see them at the time, maybe I will come back to the test after a year or two. I also need to be able to understand the use cases. It is also for others to see, because the test cases we write ourselves are not necessarily executed by ourselves, which is also one of the principles of our testing. Because it is easy to form a mindset (cross-test)
Assertions-expected results
We are going to set an expected result to determine what standard our test case uses to determine whether it is correct or incorrect, so as to verify whether the function is OK
The test case must contain these four elements, none of which is indispensable!
The article was first published on the public account: Programmer Yifan, please indicate the source for reprinting!