Is your test case sufficient for mobile Internet apps?

When interviewing test engineers, I often asked a question: "Give a test case for saving word as this function ". Aside from basic test exceptions, it is very important to consider various exceptions, such as full memory and insufficient hard disk space. However, the situation for mobile Internet apps is much more complicated.

OneImportant PrinciplesYes: test the version of the app to be released to the user.

The concept of daily building and daily testing may be deeply rooted in the hearts of the people. Many times we test only the development and DEBUG Versions of the app, rather than the final release version. When packaging the final release version, we usually need to add a digital signature or code obfuscation. The final release version is definitely different from the debug version. Our iPhone app has used a third-party open-source library and works properly in the debug version. However, it will surely crash after it is officially launched. This price and experience are very valuable (in fact, this issue has been discussed and warned on the forum of this open-source library ). We later spent a lot of effort to correct and make up for this problem. If you have tested the release version at the beginning, this problem will not occur.

Debug & release

 

There are three very important apps for testing the network.Best practices.

1, 2g, 3G, and WiFi must be covered

These three are not only differences in network speed, they represent three different network environments. In addition, you may not think of a special situation that can be used to determine the problem: the development environment and the production environment.

An experienced development team builds a test environment on the Intranet to test the development process. when the product is launched, the configuration is switched to the production environment. This switch should be a check step in the release process. However, we may miss it.

Therefore, this test case can be used to prevent this situation. In WiFi, the Intranet environment can work fine, but 2G and 3G won't work, only 2G and 3G can work normally in the real environment (think about 2G and 3G can access the address like http://192.168.1.xxx normally ).

2. Both HTTP and HTTPS must be overwritten.

Many apps interact with backend services over HTTP, And everything works normally. Why test the HTTPS environment? In some free Internet access environments, such as McDonald's and Starbucks, all their network environments require a user name and password to access the network through SSL authentication. If you use the library of the HTTP client to not capture and handle such exceptions, your app will surely crash.

3. perform tests in the case of network exceptions, server downtime, or 404 or 502

The stability of background services is sometimes difficult to control, especially when it comes to DNS and space service providers. A well-known DNS service provider in China often suffers a large-scale domain name resolution fault. In this case, your request to the background API may encounter a 404 error. The data you interact with the API should be in a fixed format such as JSON and XML, so that your data parsing will inevitably produce errors and throw an exception. If you do not properly handle the exception, the program may not work properly. The following uses pseudocode to explain the logic:

Try {<br/> If (Request () = success) {<br/> callsuccess (); <br/>} else {<br/> callfail (); <br/>}< br/> hidepopup (); <br/>}catch (e) {<br/> // do nothing, just wait .... Now popup window will show forever on the screen !!! <Br/> // if it is a iOS app, the popup window will lock the screen <br/>}

However, you need to pay attention to different mobile phone systems. Android firmware versions 1.5, 1.6, and 2.0 must be tested in detail. Because many sdks of Android 1.5, 1.6, and above have different implementations, there is a big problem in compatibility. When no special processing is performed, a program that runs normally on Android 1.6 will crash when it is opened on Android 1.5 (resource file and API problems, this can be explained in a separate article ).

Andorid 1.5 is still 1.0% owned

I tested the model of android1.5: Motorola backflip

In addition to ios3, ios4, and ios5 tests for iOS systems. I just want to say as much as possible, as cautious as possible, and as demanding as possible for testing. Due to the lengthy review cycle of the App Store, once your application encounters a serious system error, it is basically impossible for your repaired version to be installed on the App Store in a short time. Then, users will need to tolerate the torment or permanent departure of your app in about a week.

The app store is well known for its strict review and long time.