我们怎么测试
测试的工作本质上是观察程序的运行行为是否和设想的相同，强调的是整个行为过程，而程序设计更多关注结构本身的结构，特别是面向对象的设计，强调类间调用，弱化了面向过程的概念。正是由于这两个不同的概念，测试人员在和开发人员沟通过程中，感觉始终鸡同鸭讲。那么同样是从需求分析得出的，为什么会有这么大的差别呢？
首先我们来看如下视图：
业务人员根据业务拓展需要，提出了业务需求，也就是集合S，而真正业务及系统影响的范围是U，剩下的U-S的部分其实就是日常的维护。
假设开发分析和程序设计完全一致，那也就是图中的集合P，S∩P的部分就是需求已经说明并且已经实现的部分，在不引入缺陷的情况下，该部分被认为是令人满意的。S-P的部分则是需求已说明或已涵盖，但是程序没有设计的部分，这部分内容在业务测试的角度看，就是缺陷部分，而P-S则是程序根据需求拓展的部分，可能在未来业务的需要会起到一定作用。
从上面的分析来看，在只有一层的业务测试的情况下，真正有效的程序设计就是S-P的部分。
引入测试之后，情况发生了变化：
引入测试集合T之后，对图形发生了重大变化，由上面的分析就可以知道，真正有效的测试变成了S∩P∩T，这部分的功能得到了强化，能满足业务的需要。3=(T∩P)-S，这部分就是测试已经涉及，需求没有说明的部分，这部分可能正确也可能不正确，其实就是测试和开发争论但是始终没有结果的部分，4=(S∩T)-P，这部分是测试对于需求的覆盖，是无争议的缺陷，而7=T-(S∪P)存在无意义的测试设计。
因此，测试首要是了解需求提出的意图以及程序设计功能，适当保留7，以备拓展，严格把关1，尽早发现4，让业务尽快确立3，自身提高水准，发现2。
TAG:
