不写编码，直接通过手工对页面的测试思路

通过这次‘敏感用户自动识别’项目的测试经历。前期对于函数级别的测试，还是比较的顺手，后期对于纯页面的手工测试经历了一些坎坷，总结如下：

 

静态页面的查看 ：

依据MRD对于静态页面的描述，细致的查看每一条是否都符合要求，包括html结构，css属性，显示的内容是否都符合要求？要拿着MRD一点点的比对。

 

动态特性的测试 ：

动态特性包括很多方面，

.....

 

写不出来了。

 

问下新玲之后又有更加牛逼的理论，应用重点论的测试理论 ：

x：测试重要程度；y：测试时间花费。

 

然后x轴和y轴就形成了4个象限。

 

第一象限（测试时间长，重要程度高）：这种类型，要针对每个粒度构造足够量的case，对其进行认真的测试。

第四象限（测试时间短，重要程度高）：这种类型，因为可以迅速的测试完成，可以稍微构造一些数据，快速的测试完成。

 

第二象限（重要程度稍低，测试时间长）：这种类型，因为可以迅速的测试完成，但因花费时间较长，可以找规律尝试去减少测试的case。基本逻辑测到了就可以。

第三象限（重要程度低，花费时间短）：这种类型，最短的时间，快速的完成。

 

 

 

那么如何区分重要程度和测试时间长短 呢？下面举个例子：

 

就拿我测试的那个 敏感用户自动识别的项目来说吧。拿到这个网页（其实在这个网页之前我也应该知道这个网页会做成什么样子，因为MRD和详设都写明了 ），首先根据需求和业务，我要大体判定我的这个这个产品的主要目的。也就是主要要完成的任务 ，这样的话

 

1       这些主要完成的任务就是我测试的重点

 

1.1    在测试的重点中，又分为需要时间较长的和时间不是特别长 的2种类型吧。

1.2    在一个测试重点中，又可以细分为重点和非重点2种类型 。

 

所以全都这样细化分的：

测试也是一个功能分解的过程 ，这种分解是根据（重要程度+时间花费）来划分的，因为最小的粒度就是上面4个象限的其中一种，假设把最小的粒度喊为:leaf.这样的话，parent也是4个象限的其中一种，就这样针对不同的类型进行不同的测试。当然parent类型的优先级要高于leaf类型的优先级的，对每个粒度都进行了合理的测试，这样整个的测试就有条不紊的完成了。

 

 

2       然后其他的就是次重点（比如一些辅助性的）。

 

然后是如何合理的安排多次迭代测试的重复手工测试 呢？

其实：如果按照上述的办法进行测试的话，在不断分解的过程中，不仅是根据业务和需求的分解，就可以思考下RD底下的代码之间的关联程度，这样当这次修改之后，虽然还是在走上次的case，可是我已经心里有谱了，新添加的功能可能对其他的隔离的模块并没有那么影响，就可以适当的心里有谱。