Introduction to Android Knowledge
1.1 Android System Architecture:
1. Application layer
2. Application Framework Layer
3, the system runtime library layer
4. System kernel layer
1.2 Android Privilege System:
Android operating system is actually a multi-user linux operating system. Each Android application uses different users and runs in its own safety sand table. The system sets permissions for all files so that only applications of the same user can access them. Each application has its own separate virtual machine, so the application code is isolated at runtime, that is, the code of one application cannot randomly access or accidentally modify the internal data of other applications.
1.3 Introduction of Android Debugging Bridge:
ADB, or Android Debug Bridge, is a general debugging tool provided by Android. With this tool, we can debug the developed programs very well. adb.exe is under the platform-tools directory of the installed Android sdk development kit.
It is a command line tool for client/server architecture, mainly composed of the following 3 parts:
1. adb Client: A client running on a computer used for user development programs
2. adb server: responsible for the communication between the client and the daemon process of user equipment
3. adb daemon: a daemon that runs in the form of a background process on a simulator or a physical mobile phone device
1.4 system monitoring ADB commands
1.4.1 Viewing Time Consumption of Application Startup
adb-sDevice id* shell am start -W -n application name.app app/ .MainActivity
1.4.2 Obtain battery power and battery temperature
adb shell dumpsys battery
1.4.3 Application for Obtaining the Most Consuming Resources
adb -sDevice idshell top -m 6 -n l -s cpu
1.4.4 Obtaining Memory Usage
adb -sEquipmentIdadbshell dumpsememinfo application package name
1.4.5 Get cpu Usage of Specified Program
adb -sEquipmentId shell dumpsys cpuinfo application package name
1.4.6 Obtaining PID of Specified Program
adb shell “ps | grep packageName”
Android APP Test Flow Chart:
App test point
3.1 UI tests
1. Static interface tests such as buttons, dialog boxes, lists and windows
2, content (list page, prompt box) dynamic interface test
3.2 Compatibility Test
1. Different Mobile Phone Brands
2. Different operating systems and different versions of operating systems
3, different mobile phone screen resolution and different screen size (general test mainstream resolution)
4. Compatibility of network environment (WiFi, mobile network, weak network environment, no network environment)
5. Compatibility with local software
3.3 Installation and Uninstallation Test
1. Normal installation of application program, icon display is normal, and normal operation after installation (installation under different operating systems)
2. cover the installation between Different Versions
3. Retention of User Data after cover the installation
4. Normal uninstallation of the application program. Do you want to delete the user data after uninstallation
5. Abnormal conditions during installation/uninstallation (power failure, insufficient space, etc.)
6. Does the installation/uninstallation process support cancellation
Version 3.4 Upgrade Test
1. When the client has a new version, there will be an update prompt.
2. When the version is a non-mandatory upgrade version, the user can cancel the update and the old version will be used normally. The user will still be prompted to update the app the next time he starts it.
3. When the version is the mandatory upgrade version, when the user has not made the update after giving the mandatory update, exit the client. The next time you start app, you will still be prompted for a forced upgrade.
4. When the client has a new version, under the condition of not deleting the client locally, directly update and check whether it can be updated normally.
3.5 Interactive Testing
1. Front and back-end switching of applications
2. Killing process
3. Lock the screen
4. Long-term standby
3.6 Client Database Test
1. Data update test for adding, deleting, modifying and checking of client background data
2. Test for Empty Data
3. Check whether app data can be automatically retrieved from client data when client data exists, and check whether app data can be automatically retrieved from client data when client data exists.
4. Whether the client and server will have corresponding updates after the business modifies and deletes the data.
3.7 Interface Test
1. Business Logic Function Test
2. Boundary Value Test
3. Parameter Combination Test
4, abnormal situation test
3.8 Performance Test
1. Electricity consumption per unit time
2. Network Traffic Per Unit Time
3. Utilization Rate of Relevant Resources at Mobile End
4. Service Response Time
5. Frame Rate (Mainly for Game Applications)
Introduction to the tool Emmagee:
Emmagee is a small tool developed by the qa team of Netease Hangzhou Research Institute to monitor the performance of Android clients. It can monitor the startup time, CPU, memory, traffic and power changes of the device during the application. Users can customize the frequency of monitoring and real-time display of performance, and finally generate a performance statistics csv file to support Android version 2.2 and above.
4.2 Main Functions
1. Detect the CPU usage of the application under test and the overall CPU usage at the current time.
2. Detect the amount, percentage and remaining amount of memory occupied by the application under test at the current time.
3. Detect the amount of traffic consumed by the application from the start to the current time.
4. The test data is written into CSV file and stored in the directory of mobile phone /storage/sdcard0. At the same time, it supports sending files by mail.
5, can choose to open the floating window function, floating window real-time display the measured application occupancy performance data information.
6. The wifi network of the mobile phone can be quickly started or shut down in the floating window.
4.3 Implementation Principle
4.3.1. Implementation Principle of Monitoring CPU
Android system is based on Linux kernel, so the structure of system files is the same as that under Linux. The overall CPU usage information of the system is put under the /proc/stat file, and the /proc/CPUinfo file stores other CPU information, including CPU name, and can be read directly. Emmagee is to pass in the PID of the selected application, read the /proc/PID/stat file information and obtain the CPU information of the program corresponding to the PID.
4.3.2. Implementation Principle of Monitoring Memory
Memory and cpu are handled in a similar way. The PID of the application under test is obtained first, and then the memory information currently occupied by the application under test is obtained from the /proc/meminfo file according to the PID.
4.3.3 Implementation Principle of Monitoring Flow Consumption
In the system, the overall flow and the flow statistics for the current program are stored. tcp_rcv and tcp_send files are stored under /proc/net/dev and /proc/uid_stat/UID, respectively, the downstream flow and the upstream flow are stored, and the results are obtained by subtracting before and after the operation.
4.3.4 Implementation Principle of Monitoring Electricity Quantity
Electricity, voltage and temperature are obtained by monitoring the broadcast of battery management events of the system.
4.3.5 Implementation Principle of Monitoring Start-up Time
When we click the start test of the interface, the program will start EMAGEEService, and then all data statistics and updates will be processed by EMAGEEService. EmmageeService will start a thread “handler.postDelayed(task, 1000)” in onStartCommand (), update the data and try to get the startup time of the software from logcat through ActivityManger.
What’s inside the red box is to call a system service called SurfaceFlinger, which manages Android frame buffers, to obtain frame data for calculating fps. for details, please refer to the calculation method of Android fps.
Source:Yixin Institute of TechnologyAuthor: Zhang Xiaoyan