到底单元测试是做什么用的？单元测试是一种测试，它不是代码的一部分；单元测试是最低层级的测试，它只保证函数的可靠性，不保证其它；单元测试应该能保证每一个函数的可靠性。

敏捷测试要求测试能够测试在“短的时间间隔内持续发生”且能够在“短时间内完成”。考虑到纯粹的依赖人工测试基本不可能达到“短的时间间隔内持续发生”和“短时间内完成”这两个目标，而自动化测试在执行效率方面具有天然的优势，在敏捷测试中使用自动化测试技术应该是自然而然的选择。

Appium的核心是一个web服务器，他使用WebDriver json wire协议，来驱动系统的UIAutomation库。WebDriver Json wire协议的Server端采用node.js封装了iOS UI Automation的接口，提供提供出一套RESTFul web service的接口，这样Client端以HTTP请求获得操纵UI的能力。

首先测试用例设计阶段，设计并维护一个各个功能入口的说明文档。其实这个文档的作用很大，一方面对于bug回归阶段的人来说，这是用于提醒的;另外一个方面，在随机测试的时候，随机程度也能有所提高，测试人员能够自己随意组合可能的路径。当然，一样一份文档也能提升文档设计人员，文档阅读人员对于模块的整体认识

敏捷测试指的是在敏捷软件开发过程中跟质量相关的一系列活动，和传统意义上的软件测试有很多区别，因为敏捷软件测试的概念一直比较模糊，所以经常会有人走入误区，这次和大家分享一下我的理解。

案列：当开发人员需要对功能进行比较大的修改，估计需要两天时间才能完成代码，这时测试人员反对这样做，本来只有5天测试时间，验收测试已经很紧张。如果再延迟两天，测试没法完成。而产品经理认为，你们不是在用敏捷测试方法，应该测得很快，三天应该能完成测试工作啊!

性能测试就是用来测试应用运行性能的。性能测试可以发生在各个测试阶段中，即使是在单元层，一个单独模块的性能也可以使用白盒测试来进行评估，然而，只有当整个系统的所有成分都集成到一起之后，才能检查一个系统的真正性能。　　性能测试经常和压力测试一起进行，而且常常需要硬件和软件测试设备，这就是说，常常有必...

Monkey测试针对不同的对象和不同的目的采用不同的测试方案，首先测试的对象、目的及类型如下： 测试的类型分为：应用程序的稳定性测试和压力测试 测试对象分为：单一apk和apk集合 测试的目的分为：解决问题的测试(忽略异常的测试)和验收测试（不忽略异常的测试） 对于应用程序的稳定性测试有两中情况 在针对单个apk是，...

Android自动化测试方法，其中包括CTS、Monkey、Monkeyrunner、benchmark、其它test tool等。今天先说说Monkey测试。

在设计了测试用例并通过评审之后，由测试人员根据测试用例中描述的规程步步执行测试，得到实际结果与期望结果的比较。在此过程中，为了节省人力、时间或硬件资源，提高测试效率，便引入了自动化测试的概念。自动化测试就是把以人为驱动的测试行为转化为机器执行的一种过程。今天就简单说说，在Android测试中常用的测试包...

随着互联网发展，APP应用的盛行，最近了解到手机APP相关的安全性测试。目前手机App测试还是以发现bug为主，主要测试流程就是服务器接口测试，客户端功能性覆盖，以及自动化配合的性能，适配，压测等，对于App安全性测试貌似没有系统全面统一的标准和流程，其实安全性bug也可以是bug的一种，只不过更加隐秘，难以发现，尤...

对于一些基本的、逻辑性不强的操作，可以使用自动化测试工具。应该说，现在在移动应用中app测试的性能测试、压力测试等方面，自动化测试有其不可替代的优势。它可以用简单的脚本，实现大量的重复的操作。从而通过对测试结果的分析，得出结论，这样不仅节省了大量的人力和物力，而且使测试的结果更准确。对于一些逻辑性很...

最初自动化测试依靠的是传统的“录制-回放”技术，这种技术与现在的工具的“录制-回放”思想不一样，其其实就是一个“模拟”的过程，即模拟操作而形成的，其基于对输入操作的原理，这种机制对环境的依赖性太强，对变化性太过于敏感，因此不可能发展成一种规模。

首先，要做好单测，首先要捋清楚开发的代码结构，为成功搭建单测环境奠定基础。对于一个比较复杂的代码工程，首先要找到程序初始化的入口，明确初始化需要的成员变量和初始化的步骤逻辑，然后找到程序的主要接口，明确各个接口的作用，如果有明确提测接口，就按提测接口一层层剖析下去。

之前已经讲了一些白盒测试测试的原理及一些方法，这次，我们从白盒测试出发，讲讲单元测试，相信做过的朋友都了解，今天就线简单说说单元测试的原理。

运筹帷幄之中，决胜千里之外。古人足不出户，通过正确的部署就能决定千里之外战争的胜利！而于测试人员而言，制定正确的测试方案，就是日后测试就是是否顺利的决定性因素。

通过这些方法设计的用例覆盖率是很高的，当然用例太多，也意味着更多的工作量，那没问题来了，在确保用例的一定覆盖率的情况下，尽量减少我们的工作，达到最高的效率，例如大量的重复用例和无效用例需要怎么去判断，今天就用例进行精简方面说说我的想法

随着这几年国内IT行业的快速发展，特别是移动互联网，很多传统行业纷纷进入，各种各样的app，种内繁多的手游，测试已经不在限制与传统的软件和硬件，测试这一职位也越来越受到企业的重视，需求量越来越大，但是测试人才却存在巨大的缺口。

先说手工测试，也就是传统的测试方法，由测试人员手工编写测试用例，缺点在于测试工作量大，重复多，回归测试难以实现；自动化测试利用软件测试工具自动实现全部或者部分测试工作：管理、设计、执行和报告，自动化测试节省大量的测试开销，并能够完成一些手工测试无法实现的测试。

前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系，相互组合等。考虑输入条件之间的相互组合，可能会产生一些新的情况。但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多。因此必须考虑采用一种适合于描述对于多种条件...

之前，有发过一篇介绍关于黑盒测试的用例设计的一些常见方法。不过在用例设计上确实还是要靠经验，有些人就问我，例如一些方案的具体方法和设计原则，今天就以划分等价来说明一下。

黑盒测试是以用户的角度，从输入数据与输出数据的对应关系出发进行测试的。很明显，如果外部特性本身有问题或规格说明的规定有误，用墨盒测试方法是发现不了的。

白盒测试用例设计的一个很重要的评估标准就是对代码的覆盖度。一说到覆盖，相信大家都感觉非常熟悉，但是常见的覆盖都有哪些？各自有什么优缺点？在白盒测试的用例设计中我们应该如何自如地运用呢？

可能由于开发人员很久以前的写的代码或者由于交接了别人所写的代码，导致修改了一个函数但是对于该函数影响的范围没有完全的定位，这样就导致了可能有的用例或者场景没有被回归范围覆盖到。

做移动端的都知道吧，测试的重要性。严格的测试是移动应用的保证质量，那么敏捷测试就是保证可以持续、及时的对移动应用质量情况进行全面的反馈。由于在敏捷开发过程中每个迭代都会增加功能、修复缺陷或重构代码，所以在完成当前迭代新增特性测试工作的同时，还要通过回归测试来保证历史功能不受影响。要怎么才能实现敏...

时下某拼车软件，在新版本更新之后，出现定位问题，导致用户无法叫车，这样的bug直接影响了app的整体运行。发现后，官方立即进行了弥补措施，弹窗道歉、赠送代金券等，并迅速更新新的叫车入口等措施。但由于，受App store审核规则所限，且无法即使发布无bug的新版本，直到一周之后才得以解决，可想而知这一周内必定有大...

其实测试相对来说是很简单的，比没有太多的复杂，基本就是根据需求制定测试流程，按步骤执行，当然，其中也包含一些必要的的测试工具，不管是手游测试还是app测试，基本思想谁不变的，就算是自动化的测试也一样。

了解测试的都知道，自动化测试是我们所希望的展开方式，虽然目前测试趋于自动化发展，但在实施自动化测试是困难重重。 我之前有做过移动应用的自动化测试，所说App和手游的开发技术不同，两者的自动化测试技术也是是截然不同，但在自动化流程的实现上区别不大。