在昨天接近凌晨的时候，看到一条围脖是阐述了一个现象。现在移动互联网很多团队中会出现项目分类很多，项目发布周期短，测试和开发人员少这样屡见不鲜的情况。时间一长，身在这样团队的员工真的有苦说不出，因为他们整天很忙碌，却断断续续，最终发布的产品还极其不稳定。相信昨天我看到这条围脖的作者也是这样的感受。
这里我简单介绍以下在这样特定的迭代周期中的测试能够采取的几种解决方案。
1、测试用例分类和优先级
一般情况，公司会要求写很多的测试用例。当然这些用例的数量肯定是远远超越在段时间内测试人员能够执行完的。（这里也就不去提这些测试用例是不是一直维护，以及更新的问题了，大家懂得）那么此时按照一般的情况，我们将测试用例分成“基本功能”，“定制功能”，“场景测试”，“回归测试”这样几类，当然根据每个公司的产品业务不同可以再进行分类。优先级的话一般分成P1，P2，P3三类。曾经其实尝试过按照标准的4类划分，后来发现其实P4的用例真的用到的概率非常小，所以去除了。
那么在快速迭代中，我们先要清楚要发布的产品的核心功能，业务是什么。比如你发布一个pptv的电视盒子，那么毫无疑问，核心价值就是看视频。发布一个输入法，核心价值就是输入。这些核心价值绝对是在基本功能中，并且是P1的。作为测试人员你需要定制一套规则。因为在多少时间内能够执行完多少用例你应该是最清楚的，而在有限时间内我们需要去执行的就是那些最最有效，对于降低产品风险最高的用例。你分别在一天，半天，5小时，1小时这些时间内去执行哪些用例组合。打比方说，你有2个小时进行一个产品的发布，那么此时你一定是这样一个策略：“基本功能”（核心功能）P1＋回归测试（核心功能）P1＋“定制功能”（核心功能）P1＋其他。而这些不是靠拍脑袋，也不是靠每个人的定义，而是需要有一个文档进行归类，约束，引导的。比如2年前我写的一分用例概括表。
每个功能点的用例都有号码分类，可以看到都有两个白色没有写的区域，第一个是这个功能用例的数量，第二个就是是否实现自动化。这个表也起到了能够让leader或者团队的成员一目了然的作用。
2、逻辑分层测试
这里的逻辑分层可能需要对测试人员的要求相对会高点。需要进行分析，从而减去不必要的工作量。举两个例子。曾经测试过一个机顶盒升级的功能，这里我们分析一下。测试目标两个1.系统目录中的文件是否被更新 2.版本号是否更新。 用户升级有几种方法
那么是不是我们测试这个功能就必须将这些点进行排列组合呢？答案是大部分测试人员不会这样做，但是他们并不知道该怎么做。但是我们进行逻辑上的分析发现最关键的一个功能点——升级这个功能的逻辑，我们其实只需要写个很简单的工具查看这个功能是不是正确，验证之后，无论升级文件的来源，至少升级这个功能是正常的。接下来U盘和网络的升级其实都是将升级文件先放在本地的一个储存器中，读取之后升级。那么我们的测试点就变成了系统是否可以正常读取各种渠道的文件了。我们知道，android或linux这样一个升级的工作必然夹杂着网络的切换，开机，关机等等测试人员看着很头疼的事项。那么我们分析拆分之后也就变的没有那么繁琐了。
发现很多测试人员知道各种写用例的方法，但是却没有就自己测试产品功能的分析能力。这样其实最后发现测试用例的数量很臃肿，质量也不尽人意。其实主要问题就是出在这里。
另外还有探索性测试的方法，这里就不详细说了，需要用到探索性测试方式中，旅游法，通宵法等进行产品功能的分析，总结，然后实践。同样也是能够起到很好的效果。
这里也顺带说下开发面临这种情况下，就算不搭建CI，也需要通过ant＋xml配置的方法进行快速自动的编译版本，否则真的是哑巴吃黄连。另外平时勤快的使用find bugs，lint，MAT等工具进行代码的检查，ios的话同样多使用一些自带的分析工具和instruments里面的工具。相信会好很多。