How to conceive the test case of smart phone

The R&D structure of 1. products needs to be clearly designed. At present, most of the development of smart phones directly apply the complete design scheme, and then add several custom functions. Therefore, first of all, we need to sort out the following contents: a. What is directly used but cannot be modified b. What is directly used but can be redesigned c. What is a custom new app and its calling relationship with other related apps in the system; After these three parts are sorted out, you can start deploying test resources. _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ is also traditional: basic test+targeted test+performance test+(other) PS: "other" mainly refers to whether the company develops products. If it is a complete product, there will be acceptance test (including hardware) +CTA test. I won't say much about the basic test and performance test, but only the "targeted test" between them. It is related to the aforementioned point 1, and the principle is to determine the center of gravity of the test. As far as a single mobile phone system is concerned, it involves too many apps, and other companies can't completely test every function except big companies. Therefore, the overall test strategy is generally: simple and comprehensive functional test+test focus coverage test. The "test focus" comes from three aspects: a. Non-repeated test area (repeated test is not limited to whether your own test team has conducted the same test, but needs to be extended to whether other teams have conducted the same test) b. Add/modify app and its related areas C. In actual test, the test depth of the area with high user attention is the same as that of the test team, regardless of whether it is. There is no so-called standard value or reference specification. The real difficulty of testing is also reflected in this point. It is suggested that when designing deep coverage test cases, try to reach the limit of the current test team; When the test is scheduled, deeper coverage tests can be selectively tested when the test cycle is idle. ——————————————— Deep interpretation of testing: According to a certain testing goal, different levels of use case groups are designed to achieve different testing purposes. For example, for the "new contact function". In the version acceptance test, just use the normal new contact use case; In the regression test, you need to use all the attributes of the new contact; In functional testing, it is necessary to add use cases for the boundary value/character attribute of a single attribute of a contact. Different use case groups are used for different test types, that is, different test depths guide the distribution of test resources. ——————————————————————————————————————————————————————————————