软件测试和软件工程都是大家很熟悉的概念了，尤其对于那些从事软件测试的人来说，软件测试已经成了大脑中挥之不去的一部分，但往往是独立于软件工程之外的一部分，这就使得软件测试经常事倍功半，本文就是有感于此而写的。
实际上，测试人员被测试搞得晕头转向，测试管理人员不知所措是常有的事情（相对来讲，一些知名的大型跨国公司做的比较好）。这些主要和测试时间紧迫，测试质量与产品质量的标准很难度量有关——最可怕的不是对手厉害，而是未知的对手。要解决这些问题显而易见要找到这些问题的根本原因，那就要从根本上说起，软件测试是软件工程的组成部分，脱离软件工程框架的软件测试是不可以想象的，软件工程的工程思想和方法作用在软件产品的每个阶段，当然软件测试也不能例外。换句话说，软件工程的思想为软件测试提供了基础的思想和方法，任何的软件测试不论在哪个阶段都不应该脱离软件工程的思想， 孤立的去思考，设计，规划，执行，并验证。但实际上是，由于测试工作的繁忙（大多数是由缺少标准和规划而无法控制所致），更多的时候，可能只是就问题论问题了，从而偏离了软件测试的方向，使得测试质量不可控。
抛开具体的软件工程的具体模型，一般的产品周期流程可以如下划分
[图片]
大圈的产品周期模型是所有软件产品都不可避免的遵循，也是比较成熟的，小圈的内容模型每个公司做法各异，简单的和复杂的，随意的和规范的，可以说是五花八门，但是对产品质量的贡献却很难测度，其做法也很难规制，结果也很难在标准上量化，所以这种小圈通常做的情况是，做了，大概这样就行了。至于应该做到的尺度和已经做到的程度，以及瞻前顾后的思考与评价就很难了。而实际上恰恰就是这种小圈的质量一步步的决定了大圈的质量，产品的质量。这也是为什么作者要把小圈放在大圈中间的原因。随着软件产业的发展，相信小圈的质量也会越来越规范化和标准化。更重要的是，这个仁者见仁智者见智的地方，也是产品负责团队水平的一个验证。
就软件测试而言，显然是既包含大圈也包含小圈。大圈的测试规程和方法有很多，这里不再说明。而小圈是软件工程的每一个小的组成阶段，也是一个小的周期或者循环，既然具体到了每一个阶段，那么每个阶段的任务，方法，判断尺度等都是不同的，也就是要求测试人员，要对每个阶段都有足够的能力去完成。这也是评判一个测试人员水平的标准，具体到不同产品阶段的标准。