Monkey测试针对不同的对象和不同的目的采用不同的测试方案，首先测试的对象、目的及类型如下：     测试的类型分为：应用程序的稳定性测试和压力测试     测试对象分为：单一apk和apk集合     测试的目的分为：解决问题的测试(忽略异常的测试)和验收测试（不忽略异常的测试）        对于应用程序的稳定性测试有两中情况  在针对单个apk是，对不忽略异常的，在进行单个apk的验收测试时，则使用单一apk且不忽略异常的命令执行。对忽略异常的，在进行单个apk的解决问题的测试时，则使用单一apk且忽略异常的命令执行，这样可以在一次执行的过程中发现应用程序中的多个问题。        ...

    在设计了测试用例并通过评审之后，由测试人员根据测试用例中描述的规程步步执行测试，得到实际结果与期望结果的比较。在此过程中，为了节省人力、时间或硬件资源，提高测试效率，便引入了自动化测试的概念。自动化测试就是把以人为驱动的测试行为转化为机器执行的一种过程。今天就简单说说，在Android测试中常用的测试包括：Monkey和MonkeyRunner。        Monkey是一个命令行工具，可以运行在模拟器里或实际设备中，它是一种轻量级的性能测试工具。它向系统发送伪随机的事件流，实现对正在运行的应用程序进行压力测试。        Monkey包括许多选项，包括：基本配置选项，；运行约...

    随着互联网发展，APP应用的盛行，最近了解到手机APP相关的安全性测试。目前手机App测试还是以发现bug为主，主要测试流程就是服务器接口测试，客户端功能性覆盖，以及自动化配合的性能，适配，压测等，对于App安全性测试貌似没有系统全面统一的标准和流程，其实安全性bug也可以是bug的一种，只不过更加隐秘，难以发现，尤其针对于手机App。        特别是以webview为主体的app，先简单说说，站在入侵或者攻击的角度来讲，安全隐患在于http抓包，逆向工程。    目前大部分app还是走的http或者https，所以防http抓包泄露用户信息以及系统自身[url=]漏洞[/url...

    之前为写了写单元测试的基础原理和简单的环境调试，这次就简述一下在进行单元测试是需要注意的东西和基础框架。        首先，要做好单测，首先要捋清楚开发的代码结构，为成功搭建单测环境奠定基础。对于一个比较复杂的代码工程，首先要找到程序初始化的入口，明确初始化需要的成员变量和初始化的步骤逻辑，然后找到程序的主要接口，明确各个接口的作用，如果有明确提测接口，就按提测接口一层层剖析下去。         还需注意程序的公用类，在测试准备阶段，大致了解公用接口的作用，方便测试过程中调用，也利于提高代码复用性。        那怎么提高单元测试的效率呢？     1. 注意测试工程的整体架构设...

最近很多小伙伴都在研究Android APK反编译，它是研发过程中很重要的内容，我在工作中积累了部分Android APK反编译经验，希望与大家共勉分享。        一、Android APK反编译    1 、首先找到Android软件安装包中的classes.dex        把.apk文件改名为.zip，然后解压缩,得到其中的classes.dex文件，它就是java文件编译再通过dx工具打包成的。   APP  测试          2 、把classes.dex拷贝到dex2jar.bat所在目录       在命令行模式下定位到dex2jar.bat所在目录，运行 dex...

运筹帷幄之中，决胜千里之外。古人足不出户，通过正确的部署就能决定千里之外战争的胜利！而于测试人员而言，制定正确的测试方案，就是日后测试就是是否顺利的决定性因素。        在整个测试过程中，对测试人员、资源以及时间分配，合理的测试方案，能帮助测试过程有条不紊的进行，避免在测试过程中遭遇人员、时间、资源的冲突，以及测试环境搭建对测试进度的影响。          那么怎样的内容才算得上测试方案呢：         首先，要确定大方针，落实负责人和目标，在根据需求确定具体做什么类型的测试及规划、执行步骤，当然最重要的还是用例的设计   测试负责人需要负责沟通和推进整个测试过程，人员和时间安排，...

之前的文章介绍了黑盒测试的几种用例设计，包括等价类划分法、边界值分析法、错误推测法、因果图法、判定表驱动法、正交试验设计法、功能图法等。        通过这些方法设计的用例覆盖率是很高的，当然用例太多，也意味着更多的工作量，那没问题来了，在确保用例的一定覆盖率的情况下，尽量减少我们的工作，达到最高的效率，例如大量的重复用例和无效用例需要怎么去判断，今天就用例进行精简方面说说我的想法         首先是对用例重复进行合并，所谓用例重复，不是说很多用例完全一样，而是说部分用例的检查点或影响因素相同，操作步骤相同，使用例看起来像是重复的用例一样，对于这种情况，可以进行合并。当对象部分功能类似，...

作为一个多年的测试猿，对这个问题还是比较纠结的！        先说手工测试，也就是传统的测试方法，由测试人员手工编写测试用例，缺点在于测试工作量大，重复多，回归测试难以实现；自动化测试利用软件测试工具自动实现全部或者部分测试工作：管理、设计、执行和报告，自动化测试节省大量的测试开销，并能够完成一些手工测试无法实现的测试。              我的看法是自动化测试是对手工测试的一种补充，自动化测试不可能完全替代手工测试，因为很多数据的正确性、界面是否美观、业务逻辑的满足程度等都离不开测试人员的人工判断。而仅仅依赖手工测试的话，则会让测试过于低效，尤其是回归测试的重复工作量对测试人员造成了...

 前面介绍了黑盒测试中的划分等价法，今天来说说因果图法。        前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系，相互组合等。考虑输入条件之间的相互组合，可能会产生一些新的情况。但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多。因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图。        因果图方法最终生成的就是判定表。它适合于检查程序输入条件的各种组合情况.         利用因果图生成测试用例的基本步骤：      1...

关于一些误解黑盒测试想法的论述         之前分别写了一些白盒测试、黑盒测试、回归测试、自动化测试的一些基本的东西，这期就重点说说白盒测试和黑盒测试的不同        一般软件开发人员和测试人员对白盒测试和黑盒测试的感念都有一定的认识，但认为是编代码所做的测试是白盒测试，黑盒测试不用编写代码，这其实是一种误解。        虽然不管是app测试还是软件测试等，都可以使用以下两种方法之一进行测试。        黑盒测试，它是通过测试来检测每个功能是否都能正常使用。在测试地，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能...

「转载」论述白盒测试的覆盖方法        之前说了黑盒测试，今天聊聊白盒测试        白盒测试用例设计的一个很重要的评估标准就是对代码的覆盖度。一说到覆盖，相信大家都感觉非常熟悉，但是常见的覆盖都有哪些？各自有什么优缺点？在白盒测试的用例设计中我们应该如何自如地运用呢？        简单说说，白盒测试的覆盖方法：语句覆盖、判定覆盖、条件覆盖、组合覆盖和路径覆盖。          语句覆盖，就是针对代码语句。设计出来的测试用例要保证程序中的每一个语句至少被执行一次。通常语句覆盖被认为是“最弱的覆盖”，因为它仅仅考虑对代码中的执行语句进行覆盖而没有考虑各种条件和分支，因此在实际运用中...

「转载」从回归测试来看精准测试的必要性        上期刚刚说了一点回归测试，说起这个回归测试，想必多数做过的同志也是感慨良多。        是否在做回归测试的时候常常会因为范围评估不准而遗漏一些bug？    是否在做回归测试时候的你面对一条条的回归用例而发愁呢？        可能由于开发人员很久以前的写的代码或者由于交接了别人所写的代码，导致修改了一个函数但是对于该函数影响的范围没有完全的定位，这样就导致了可能有的用例或者场景没有被回归范围覆盖到。        知道了具体影响范围但是回归的时候不知道具体是什么影响因素，以至于只能大部分甚至所有的影响因素用例都跑了一遍，直接造成了大量...

「转载」为什么现在的移动应用测试还不够敏捷？        做移动端的都知道吧，测试的重要性。严格的测试是移动应用的保证质量，那么敏捷测试就是保证可以持续、及时的对移动应用质量情况进行全面的反馈。由于在敏捷开发过程中每个迭代都会增加功能、修复缺陷或重构代码，所以在完成当前迭代新增特性测试工作的同时，还要通过回归测试来保证历史功能不受影响。       要怎么才能实现敏捷测试 测试范围足够广：   •测试用例要覆盖所有功能；    •要在各种可能的环境下作兼容性测试；   •系统的稳定性、性能都要测试；        测试频率足够高：    •每日构建产生的版本要保证可用；    •每个迭代都需...