想问一下怎 么 检 测 APK 文 件？

Posted 2023-04-20

把ppt的内容总结一下，并把问题说明一下：
把基本步骤搞出来，用notepad的程序吧，直接安装apk，就当做是不知道源码就好啦！
直接用自己的手机上就行啦！！
一、重签名：
步骤：
1、直接运行re-sign.jar进行签名
注意事项：
（1）官网直接搜就行：
（2）对Android 4.4.2（API19）的好像签名有问题，从表象看能够签名成功，去程序里run as android junit test的时候就会提示类似这样的Error：
Test run failed: Permission Denial: starting instrumentation ComponentInfocom.filemanager.test/com.zutubi.android.junitreport.JUnitReportTestRunner from pid=6072, uid=6072 not allowed because package com.filemanager.test does not have a signature matching the target com.estrongs.android.pop ——针对这个问题，就只能通过命令行来签名了，下面的2中会讲到
对Anroid 4.2（API17）和Android 4.3（API18）可以成功签名，以官方提供的例子（notepad.apk）为例，它本身的例子是有源码的，我们重签名apk，按照没有源码的例子来讲解。
好，接下来直接双击运行re-sign.jar，出现了以下提示：（第一种可能出现的问题）
原因是：运行re-sign.jar需要配置ANDROID_HOME的环境变量，应该是程序写死的需要从这个环境变量找到文件目录，然后调用其下面的zipalign.exe程序
解决方案：
配置环境即可：直接我的电脑右键-系统属性-高级属性设置-环境变量-新建环境变量名称：ANDROID_HOME，value是：“D:\Program Files\adt-bundle-windows-x86-20130717\sdk”（这是我的sdk路径，个人安装路径不同，需要请自寻）
之后重新双击re-sign.jar，就不会再出现上面的提示，然后将apk直接拖放到re-sign.jar的运行界面上，会出现一个提示，提示保存生成的重签名后的文件
直接点击保存即可。。。
这里的重签名用的其实也是debug_keystore的这个签名，所以签名带了一个debug，这是猜的哈。。。。
然后re-sign.jar会弹窗提示重签名后的apk文件的包名和MainActivity：
2、命令行签名
用aapt badging 命令查看重签名后的PackageName和MainActivity
原理：robotium为什么需要对程序重签名？
（1）什么是签名？安卓程序为什么要签名
签名就是为了标志自己，为自己的程序打上标记，让别人看到签名的时候知道这个是跟你有关的（不管是程序，还是其他的签名都是如此的作用）
安卓程序签名是Android系统要求，Android系统要求每一个应用程序必须要经过数字签名才能安装到应用系统中，如果不进行数字签名，是没有办法安装到应用系统中的！Android通过数字签名来标识应用程序的作者和在应用程序之间建立信任关系，Android由应用程序的作者完成，并不需要权威认证，只是用来让应用程序包自我认证的。
（2）如何进行签名？（debug模式和release模式）
debug模式：调试模式下，程序不用专门签名，就能够在手机和模拟器上运行，ADT会自动的使用debug密钥为应用程序签名（debug密钥全称：dedug.keystore，具体位置：C:\Documents and Settings\xxx\.android\debug.keystore）
自己使用不同的PC机生成的debug.keystore，发现根本不同，所以如果更换了机器，就会导致签名不同，因此下面会说到，robotium的这个程序，如果testapk是在其他机子上做了修改的，必须重新对原来的待测程序进行重签名，否则就会出现签名不匹配的问题
（具体例见：在A机器上对notepad进行签名作为待测程序，在B机器上编写testcase，直接在eclipse中Run as Android Junit Test，就会出现crash的问题，还是提示签名不匹配？，但还是需要验证一下！！！）
release模式的签名包含两种方式：
1）Eclipse+ADT方式
这个是最简单且常用的方式，步骤如下：
A： Project -> 取消Build Automatically
B： Project -> Clean
C： Project -> Build
D： 右击项目->android tools->Export signed Application package
第一次运行可以使用 Create new keystore，以后签名就可以使用 User existing keystore。按照说明一步步操作即可，很容易就能打包签名成功。
注意：请妥善保管生成的签名文件，不要丢失，以保证应用发布可重复使用，以免不能进行应用的无缝持续升级。
2）命令行方式：详见（转载文章：【转载】关于签名——Android应用程序签名详解【转载】关于签名——Android应用程序签名详解）
（3）被测程序为什么要进行重签名？
签名的好处：
(1)有利于程序升级。
当新版程序和旧版程序的数字证书相同时，Android系统才会认为这两个程序是同一个程序的不同版本。如果新版程序和旧版程序的数字证书不相同，则Android系统认为他们是不同的程序，并产生冲突，会要求新程序更改包名。

(2)有利于程序的模块化设计和开发。
Android系统允许拥有同一个数字签名的程序运行在一个进程中，Android程序会将他们视为同一个程序。所以开发者可以将自己的程序分模块开发，而用户只需要在需要的时候下载适当的模块。

(3)可以通过权限(permission)的方式在多个程序间共享数据和代码。
Android提供了基于数字证书的权限赋予机制，应用程序可以和其他的程序共享该功能或者数据给那那些与自己拥有相同数字证书的程序。如果某个权限(permission)的protectionLevel是signature，则这个权限就只能授予那些跟该权限所在的包拥有同一个数字证书的程序。

robotium为什么需要对被测程序进行重签名？

根据上面签名的好处，知道了重签名后能够共享数据和代码，也能够将被测程序与testapk跑在同一个进程中，这样testapk就能够对被测程序进行直接交互。
具体原因见下方描述：

robotium是对Instrumentation做的二次封装，Instrumentation要求待测程序与testapk跑在同一个进程中，而且需要对其进行数据和资源的操作，那么就必须要保证签名一致，就根据上面所说的签名的好处就可以知道，签名是前提和必要条件，否则将无法用testapk对待测程序进行操作和UI上的测试。
Android提供了自定义的运行测试用例的类，叫做InstrumentationTestRunner。这个类控制应用程序处于测试环境中，在同一个进程中运行测试程序和主程序，并且将测试结果输出到合适的地方。IntrumentationTestRunner在运行时对整个测试环境的控制能力的关键是使用Instrumentation。注意，如果你的测试类不使用Instrumentation的话，你也可以使用这个TestRunner。
当你运行一个测试程序时，首先会运行一个系统工具叫做Activity Manager。Activity Manager使用Instrumentation框架来启动和控制TestRunner，这个TestRunner反过来又使用Intrumentation来关闭任何主程序的实例，然后启动测试程序及主程序（同一个进程中）。这就能确保测试程序与主程序间的直接交互。用eclipse编写testcase，编译完测试工程后，你就可以使用系统工具Activity Manager来运行测试程序。你给Activity Manager提供了TestRunner的名（一般是InstrumentationTestRunner，在程序中指定）；名包括被测试程序的包名和TestRunner的名（这一点在robotium中也一样，也需要提供，才能够找到你需要测试的程序）。Activity Manager加载并启动你的测试程序，杀死主程序的任何实例，然后在测试程序的同一个进程里加载主程序，然后传递测试程序的第一个测试用例。这个时候，TestRunner会接管这些测试用例，运行里面的每个测试方法，直到所有的方法运行结束。如果你使用Eclipse，结果会在JUnit的面板中显示。如果你使用命令行，将输出到STDOUT上。
如果不重签名的话，我们用官方提供的原apk包和自己后来生成的testapk包安装，用testapk包对原apk包进行测试，就会出现以下错误提示：
二、安装已经重签名的待测试的apk文件到安卓手机
直接用adb install 待测试的apk（拖到cmd里面即可），之后enter，安装成功即可
三、Robotium的testcase的编写配置（在eclipse下进行）
1、创建Android Test Project

（1）File-New-Project-Android-Android Test Project
（2）输入工程名-next，选择This project-finish

2、创建Anroid testcase（包括uiatumatorviewer的使用，这个得在17及以上才有吧。。。）
使用uiautomatorviewer获取待测程序的布局，具体可将该工具的路径添加到环境变量中，或者进入该目录，用cmd运行，直接输入uiautomatorviewer就可以运行起来该工具，这是已经封装好的工具，可以直接用。。。

创建testcase的具体过程如下：
（1）工程名-src-包名-右击new-Junit Test Case
（2）在name一栏输入Test Case的名称，比如TestNotePad
（3）Superclass一栏，选择android.test.ActivityInstrumentationTestCase2，之后选择setup，teardown，constructor方法，点击finish即可

3、导入Robotium-jar包（需要注意和需要配置的项目）
通过建立lib文件夹，直接copy文件，需要在Build Path中进行配置。。。。具体步骤与下面添加report-jar包的步骤相同

（1）工程名-new-folder-lib
（2）直接将之前下载的robotium-solo-5.2.1.jar拷贝粘贴到lib目录下
（3）工程名-右击-Build Path-Configure Build Path-Libraries-Add External JARs

（4）点击右边的Order and Export，选择Robotium-solo-5.2.1.jar的选项，点击OK
4、修改AndroidManifest.xml文件
该配置文件的修改主要包含增加<Instrumentation>节点
<instrumentation
android:name="android.test.InstrumentationTestRunner"
android:targetPackage="xxx.xxx.xxx" />
targetPackage与re-sign.jar中所获取到的包名相同，是指被测程序的包名
5、编写测试代码
四、跑case：
可以全部跑，也可以单个跑；可以在eclipse中操作，也可以在cmd下直接用命令行方式操作：
（1）可以用adt工具，从eclipse里直接操作：运行所有用例——如果使用了TestSuite对用例进行一定顺序的处理，就可以在该类中添加你所需要的所有用例，然后在这个类文件上，右键Run as Android Junit Test；运行单个用例——可以直接在某个test的类文件上，右键Run as Android Junit Test，就能够只跑你想要跑的这个类
（2）在cmd下直接用命令行方式操作：
adb shell am instrument -w com.example.test/android.test.InstrumentationTestRunner
参数说明：
-w是必写的，否则看不到测试结果的。。。
com.example.test——为testapk的包名，android.test.InstrumentationTestRunner是AndroidManifest.xml中所配置的
<instrumentation
android:name="android.test.InstrumentationTestRunner"/>的android：name相同即可，即通过什么来启动这个这个测试
如果在程序中导入了report-jar包，那么修改了AndroidManifest.xml中所配置的内容如下：
<instrumentation
android:name="com.zutubi.android.junitreport.JUnitReportTestRunner"/>
就需要修改这个cmd命令为：adb shell am instrument -w com.example.test/com.zutubi.android.junitreport.JUnitReportTestRunner
五、配置report-jar包，直接在手机上生成所需要的xml的测试运行结果
导入这个jar包，就可以不用依赖eclipse了，将程序启动起来后，就可以关闭eclipse，等待程序跑完，就可以在特定位置获取程序运行结果，具体导入步骤见下方：
有现成的jar包可以帮忙完成这个操作，名字是android-junit-report-1.5.8.jar
下载官网：jsankey/android-junit-report · GitHubDownloads · jsankey/android-junit-report · GitHub
然后下载完成之后，需要把这个jar添加到我的test工程的lib文件夹下，然后将其添加到build-path中
具体过程如下：
1、建立一个安卓的测试工程，导入Robotium包，建立好测试用例

2、在测试工程的lib目录下，复制android-junit-report-1.5.8.jar包，可以直接将jar包拖入到工程的lib文件下，松开鼠标，之后会提示是否要copy files，点击确定即可
3、右键该jar包——Build Path——Add to Build Path（注意一定要把Libraries和Order and Export下的该jar都勾选上，点击OK）
4、在测试工程的AndroidManifest.xml文件中，修改<instrumentation>的字段的内容，
修改之前的内容是：targetPackage表示待测程序的包名
<instrumentation
android:name="android.test.InstrumentationTestRunner"
android:targetPackage="xxx.xxx.xxx"/>
修改之后的内容是：
<instrumentation
android:name="com.zutubi.android.junitreport.JUnitReportTestRunner"
android:targetPackage="xxx.xxx.xxx"/>
5、右键测试工程——Run As——Run Configuration
之后打开Run Configuration的界面，选择自己的那个工程，右边的Test下面的Instrumentation runners，选择为之前AndroidManifest.xml中配置好的，之后apply，并确认即可
6、运行程序Run AS——Android Junit Test，运行case，之后就会在 /data/data/ com.xxx.xxx/ files 目录下 生成一个文件junit-report.xml：
然后用adb pull可以将手机端的文件拷贝到电脑端：
adb pull /data/data/xxx.xxx.xxx/files/junit-report.xml D:\
参数说明：xxx.xxx.xxx就是targetPackget，即待测程序的包名，这个xml的测试报告生成位置就在这个包的files目录下，注意：不是在testapk的包名下面
D:\ 的参数不添加的话，文件就被pull到当前目录下，如果想要定位一个特定的位置，如D:\
7、之后能够log信息：
这里能够看到运行的是哪个testsuite里面的哪个testcase，然后运行失败的话，就会打出详细的failure message的信息
如果运行成功的话，就没有<failure message>的节点
六、在整个过程中可能遇到的问题：
1、classnotfound的问题（jar包的导入问题，libraries中没有包含进来，MainActivity写错了。。。）
2、crash的问题（没有安装测试包，找不到这个包名的时候应该也会崩溃） 参考技术A 识别诈骗电话很简单的，你在手机上安装个安全软件就行了，既不用你操心，准确性还高。
比如你可以试试腾讯手机管家啊。管家识别诈骗电话非常准确的，你还能自己设置黑名单屏蔽电话，还有一键举报的功能~
很棒吧？管家是有安全云库做数据支持的，非常强大啊！本回答被提问者采纳

利用ab测试并发可靠么

从一个后端开发的角度来测并发，主要就是无意间看到并发这个东西，就随便测一下，也只是用个极其简单 的工具，做一个极其简单的测试，测试结果会写在下面，不过先从测试过程开始写起把。

1.首先你得有2台服务器，当然一台也行，不过建议是2台，一台用来进行并发，另一台来接收并发。

2.首先，打开A服务器，在A服务器根目录下新建个a.php文件，里面写点代码，我建议随便写一句就行，比如：

<?php

echo ‘test me haha‘;
?>

写完了，保存，然后要保证通过域名或者你的ip能够访问到文件里的这句话哦。

3.然后在B服务器上安装下测试工具，指令是

yum install httpd-tools

安装完成后，我们来进行最重要的测试环节了。

ab -n 50000 -c 5000 http://111.111.111.111/a.php（这个地址就是a服务器上的刚新写的Php文件访问地址，我可能不能写真的，不然你们都去黑我了哈）

其中呢  有2个重要的地方 你们要知道

-n 50000代表的值总请求次数是50000次，就是会有50000次的请求袭来，你也可以理解为有50000人来访问。

-c 5000 代表并发数是5000，就是说每秒有5000个请求

然后 执行

执行完了，我们该干啥呢 当然是看日志了

我的日志是在home/wwwroots下

据说 这种请求每次都有好多是502的坏请求，200成功的并不多 于是我特意搜了一下 502的请求有多少

cat access.log |grep 502|wc -l  一看 40000多次 我去，占了将近90%，看来这测的也不准啊

90%的都是 坏请求 实际有用的请求也就几千次，几千次网站肯定不会崩溃啊，看来不是特别准啊

由上图可以充分看出 一共有103315次请求，但是502的错误请求就有88818次，看来不太准额，以后你们也别用这个测了。。不太准。。。