Some questions about testing

1. Q: What should I do if the black box test has no technical content? How to improve testing techniques?

A: Most of the people who ask this question are newcomers. I have asked this question before. If you pay attention, you may find that most of the comments from seniors say that black box testing is the most technical skill. Why? Because black-box testing is the basis for other testing methods and skills, such as automated testing, exploratory testing, etc., which are very hot now, are all based on black-box testing. Yes and business processes are not familiar, can use test tools but don't know which scenario to simulate and which point to test? What's the use? When you are still struggling with this problem, ask yourself do I really understand the various business processes of the test module? Can I complete the testing tasks of a module or project independently? Am I proficient at every point of requirement analysis, requirement extraction, test analysis, test case design, test plan writing, test plan writing, test execution strategy, test result analysis, test report sorting, etc. Shouldn't it be considered to increase)? Is my relationship with the development well handled? Does the writing of defect tickets still need to be optimized? Wait, if not, I suggest that you understand the above first, and then consider learning something with technical content.

2. Q: I used to do XX, but now I want to switch to the testing industry, can I do it?

A: The seniors who ask this question are generally older than me, and they are all my seniors. They may not be able to give a satisfactory answer, but I still want to say my opinion, just one point: Are you really interested in the test? Anyone who has entered the testing industry knows that testing is sometimes boring and repetitive. The understanding of interest is particularly strong recently: I am testing a project recently, which has been in the ninth round of testing, which has lasted for half a year, and each round of testing lasts for more than 1 week. Due to the particularity of the project, tools cannot be used for regression testing. The main function test is required for each round. The verification test is sometimes a detailed test. Recently, I found that my colleagues in the same group are in a state of numbness, just to verify the bug, and go to other things. The main functions are too lazy to run, let alone run. Learn new techniques to apply in testing to increase scenarios, coverage, and more. If you don't know if you are interested, I can provide a method for reference only: Find a test case for the login module (the more detailed the better), execute it 10 times, and see what your state of mind is during the execution process?

3. Because I often write summaries, or because I am the moderator of 51testing, I am often asked questions by others on QQ (maybe some colleagues think I am very good, but I am actually very good), most of them ask me which test I do, Is it for automation, is it for performance, etc. When I say: mainly focus on system testing, sometimes do stability testing and performance testing, I am not familiar with QTP and LR, and sometimes use some simple It seems that most of them are disappointed in the tool-assisted testing. I feel that I am doing system testing and there is no need to communicate (when I meet such colleagues, sometimes I feel that there is no need to communicate), I have been thinking about the reasons recently. , is everyone's misunderstanding of the black box, or too impetuous, or just follow the trend. I will learn the automation fever, I will also learn the exploratory testing fever, and I will also learn the rise of mobile phone testing. As I said in the 2012 annual summary, I have also been impetuous, there are many testing techniques, and the temptation of various techniques is great, but should we consider which ones are suitable for us and which ones are not? 4. YY

training is on the rise, and various testing communities or websites are engaged in YY training on various topics, almost every day. I see a lot of colleagues who sign up as long as they have it. To quote Mr. Mike's words: It is almost impossible to improve one's skills by relying on YY's thoughts. Here's my take: YY training is really good for those of us on low incomes: no fee. But the YY training is just a direction or a general introduction to a certain topic that the senior teachers have pointed us. If I want to know about the mobile phone test, I may go back and listen to a YY training given by Mr. Monkey to get a general understanding of the characteristics of mobile phone testing and What is the difference from our general desktop software testing, and what are the specific differences? We also need to find the information ourselves and compare it in practice. Having said so much, I want to elaborate on one point: choose the YY training theme that suits you, and don’t be too obsessed with YY training. In the end, all skill improvement comes down to relying on us to acquire, study and practice by ourselves (and remind ourselves).



In the previous stage, some problems were found during system testing and stability testing. I also thought about it and made a brief summary:          

1. Test case design

The test case review and test case organization conducted in this quarter have increased their use case design ability and divergent thinking ability. It also summarizes its own set of processes and methods: when getting a module to be tested, first familiarize yourself with the relevant documents, subdivide it step by step according to the small function modules, and then design use cases for a single small function or single attribute (various tests). Application of use case design methods: domain analysis method, equivalence class division, etc.); then design combination scenarios for several associated attributes (you can use test case design methods such as orthogonal, state diagram, process path coverage, etc., pay attention to Orthogonal is used when designing use cases. You may have a headache. Several combinations of orthogonality will lead to more test cases. In fact, the advantage of orthogonal design method is precisely its disadvantage: equal probability, some special scenarios and users are not considered. For the commonly used scenarios, we can take the scenarios into consideration when using orthogonality, and then filter the test cases); finally, from the perspective of each module, supplement the scenario with the idea of ​​business flow, mainly considering the interaction of each module (more used ones). It is an empirical method. The recent analysis of the bug reported by myself found that the interaction between modules is precisely what I lacked, and I did not look at a product from a higher perspective, and I also need to strengthen it in the future). In the above process, you can use the mind map to clarify your own thinking, constantly expand your thinking, and increase scene coverage.

2. Test case review Test case

   review is mainly to point out the deficiencies of test cases and increase the use case coverage through other colleagues. The biggest gain in this process is: when colleagues point out that their test cases are insufficient, they can think about why they did not design their own test cases. Considering whether it is because of lack of testing skills, lack of practice, or blind spots in your testing thinking, you should supplement and improve your own testing knowledge system and improve your thinking density in a targeted manner.

3. Difficulties in Test Case Execution and Test Case Maintenance

    This problem was also discovered in the recent system testing (especially strong): the test cases used in this round are basically updated, the granularity of the use cases is relatively small, and the number of use cases is huge (tens of thousands); If it is guaranteed, follow the test case, the test progress will definitely be affected (especially the stability test is also carried out in this round), and only other use case execution strategies can be used. Due to the finer granularity of test case design, it is more difficult to maintain when the test module has minor changes. For example, a simple interface change will result in a large number of test cases to be updated, which is more difficult in the case of insufficient test time. Obviously difficult, this should pay attention to the problem of granularity in the future.

4. The focus of stability testing Stability testing has been

done many times. In the past, testing seldom focused on database issues. Everyone tested their own or considered related modules. When the system under test runs for a long time, the database data (such as alarm information, etc.) will continue to increase, resulting in slow database operation and even the server where the CMS is installed is stuck. There is no writing to the database, and no other features of the entire platform are concerned. Recently, I have been thinking about whether I should pay attention to this aspect of the test. The stability test should not only focus on one point of the test. Since it is a long-term operation of simulating on-site use scenarios, should we pay attention to the operation of the entire platform after a long-term operation? ( All aspects), this is also what I have to pay attention to in the future.

5. Resource exhaustion problem

Recently , the system resource exhaustion problem was encountered during the test. Before the software under test was installed, there was no problem in running the PC for several weeks. After the system under test was installed, the problem of resource exhaustion would occur. It is said that the system under test causes resource exhaustion, but there are several strange situations in the past:
1>. The resource consumption of each process is normal, including the software process under test, total CPU, memory, handle, non-page buffer, etc. Normal, can not find which process consumes system resources
2>. Forced to kill the software process under test through the task manager, or resource exhaustion occurs, the resources are not released (if it is caused by the software under test, after killing the process should free up system resources)
3>. Various software antiviruses have been passed, which can rule out the problem caused by viruses.
Now we can't find out where the specific problem is in the development and our testing. The development said that it is a computer problem, but we can't produce strong evidence (the problem is in This version has also appeared in other Builds, and it has appeared four times in total. Sure.

6. Different testers submit the same question, and the results are different.

This phenomenon is also under consideration by myself recently. The reasons why different people report the same question and get different results are summarized as follows:

1> Yes Not bug

2> developer workload.

3> It is determined by the developer himself and his mood.

4> The stage of the project (such as near release and the first round of testing)

5> Support from test leaders

6> Communication and communication with

testers 7> Impressions in the minds of testers and developers

8> Feedback to leaders for communication

The above is also obtained when we communicate with colleagues and work by ourselves. In response to this problem, it is more about how we, as testers, should carry out our own responsibilities, and which reasons are caused by ourselves. This is also our own thinking and belongs to ourselves. Job responsibilities, if there are problems, you must give feedback and communicate, constantly reflect on and improve the entire testing process, you should not let it pass, ignore the small problems, and always keep a fresh sense of the problems, so as to continuously cultivate your own testing feeling and experience The accumulation of more important is to improve product quality and user experience.