这是一个放之四海皆必谈的永恒话题。测试亦是如此，我们在项目中常常会问自己这样一些问题：我们有多少可以投入？我们有多少需要产出？我们的投入是否能够达到期望的产出？如果投入所有资源也无法达到期望的产出，我们该如何调整资源，改变计划？　　我记得我最开始做接口测试的时候，一天能够实现2-3个测试用例就已经很不错了，以这样的速度投入项目，实在可以算是“资源有限”，所以那个时候总觉得很忙，因为要做的事情很多，但是做事的效率却很低；后来，对接口测试熟悉了，也有了一些自己的体会了，一天可以实现几十个测试用例，极致的时候甚至可以达到上百个，而且这个时候投入项目的人员也增加了，日常的需求量却没有什么太大变化，这个时候可以说是“资源充足”，但真的充足的吗？那为什么我却感觉到更忙了，资源好像更不够用了，这是一个奇异的现象。　　分析了一下原因，原来是这样：开始的时候，由于资源不足，我们选择先做最重要的部分的测试，在这个基础上，其它次要部分的测试只能尽量多做；后来我们资源相对比较充足了，虽然需求量并没有多大的变化，但工作量却是可以说是指数级的增长，为什么会这样呢？因为我们这个时候力争追求完美，要覆盖一切能够想象得到的场景，甚至不管这样的场景有没有足够的测试理由，只要提出，就要实现。我们尝试了，我们也曾一度做到了，这样做产生了3个结果：1.覆盖的场景的确很全面了；2.覆盖的场景过于全面了，冗余太多（很多都可以归结为等价类，以下称之为非必要测试场景），难维护，资源浪费；3.没有足够的资源放在相对必要的测试场景上，质量反而得不到较好的保障。　　由此可以看出，虽然投入较前期增加了很多，但我们最终要产出的——项目质量，却并没有成比例的增长，甚至有下滑的危险，如下图所示：　　横坐标为投入的资源比例，纵坐标为产品质量，在资源一定的情况下，假设我们有两种投入资源的方式，再假设两种方式都将80%的资源投入到了所有的必要测试场景上，这个时候我们可以看到，产品的质量已经基本得到了保障，这个时候主要流程应该是没有问题的，但可能还会有一些分支流程的小bug或者一些未考虑到的场景（这也是必要场景）未测试而引起的bug。现在还剩下20%的资源，我们有两种投入方式的选择：方式1，将剩下20%的资源继续用于挖掘必要场景，并将其测试实现，同时review已有的场景有无缺陷并修复；方式2，将剩下20%的资源投入到非必要测试场景上，尽可能穷举等价类测试，这样做的理由是尽管很多理论上来说都是等价类场景，但在复杂的系统下，谁也不敢保证我们所分析出来的等价类就真的是等价类，这种情况的确可能存在，但我们有搞不清它到底可能在哪里存在差别，于是我们只好穷举，但我认为它发生的几率比中500万的几率不会大太多。换句话说，方式2的投入基本上算是在做无用功。而这个时候真正必要的测试场景可能我们想得并不够全面，然而我们也没有多余资源去顾及这个了，这就为产品的质量埋下了隐患。　　最后总结一下，问题的关键还是要划分优先级，必要测试应该首先保证（这是必须做的），在这个前提下，我们可以设计一些冗余的场景（这是可以不做的），但不应过多，一是浪费了不必要的资源，二是给后期维护带来困难，更重要的是，它在绝大部分时候，给你带来的收益（对质量的提升）是零，这和买彩票是同一个道理。

Tags：安卓系统是谁开发的,安卓系统开发培训,安卓系统开发教程,asp服务器软件,asp.NET软件,安卓系统开发环境