一些见解欢迎大家讨论指正

[benci26]

首先强调：以下的想法都是假设在充分评审、权责明确的前提下进行；测试流程默认为理论上所有的测试行为，并不细分某些人在某一实施阶段的特定测试活动。鉴于本部分（1-4）的重点不在于此，特此说明。

我认为测试流程中包括对需求的测试、对流程的测试、以及对数据的测试。其中需求测试作为测试人员对项目的总的认识，是不可缺少的第一步。流程测试是测试人员对项目测试的设计，以及对用户行为的假设，在此步骤中，测试案例已经初具雏形。数据测试是对已有的测试案例的一个具体实现，在此步骤中应该既包括对正确流程的实现，也应该包括对错误流程的实现。

1．对需求方面的测试
假设用户对于需求是主动的，我们可以发现：用户在项目开始时要归纳需求签合同、在项目结束时要对着现实的产品检验需求是否达到；而测试人员根据需求的实际内容，在开发的过程中编写测试案例，在开发结束后检验是否达到需求要求。显而易见，测试人员对于需求是被动的。
实际情况可能会有些出入：用户对需求的认识大多数时候是被动的，主动在于开发人员。此时测试人员和用户对项目的认识的是一样的。测试人员仍然是被动的，因为他们对需求的理解可能会更多的受到开发人员的影响。测试设计也会倾向局限于验证正确性，弱化其破坏性的内涵。
之所以说需求测试是不可缺少的第一步，就是因为在此步骤中，测试人员既要理解开发人员的开发意图和需求理解，又要深刻了解用户的意图，多从用户的角度考虑问题，尽量与用户保持一致。
可能提出“需求测试”可能不大确切，但我想这个步骤是不能少的。
在本步骤中，测试人员不光要深刻理解评审后的需求分析书，还要尽量了解用户意图，从用户的视角找出需求中的薄弱的地方，以便开发人员能使随后的概要设计或详细设计考虑周全、细致，防止后面过程的返工。

2．对流程的测试
我想流程对于软件项目，可以分为两种：业务流程和界面流程。
对于用户，更关注业务流程，所以进入测试设计阶段，应该从用户的角度模拟用户可能出现的问题。对于开发人员，关注点大部分在于功能的实现上，如果需求、概要、详细设计描述不是很全面的话，对于操作性、方便性不会有太多的考虑。这就需要测试人员从中进行弥补：既要满足的考虑用户的需要，也要满足开发实现的实际情况。
绝对的双赢是不可能的，对于测试设计，应该更倾向于用户的角度，尤其是设计中流程的全面性、合理性。当然，测试设计必须要得到开发负责人的认可，这毕竟会导致一些变更。
一个业务流程可能是由多个界面流程实现的，一个界面流程只能实现一个业务流程。我们可以按照业务流程界面流程动作模式逐级细分，以满足流程的全面性。可以根据需求测试的结果，判断全部流程的合理性，截断的流程是否应该出现提示或警告。前者可以通过排列组合的方式排出各种流程的动作顺序，后者主要是根据需求测试和测试案例的评审，排除可能性较小或不符合业务流程的部分。

3．对数据的测试
数据测试，我想应该包括数据源测试、数据完整性测试几个方面。
对于需要连接数据库的软件项目，数据源导致的问题比较多，其中经常出现的问题包括：数据结构前后台不吻合，数据源接口有错误等。数据源测试，形式上和流程的关系不是很大。具体的案例应该单独设计，即包括数据源设置动作的考虑是否全面，对数据库设计符合设计要求，前后台数据项对应是否一致等。实施的过程中，强烈建议进行白盒测试，了解代码和数据库情况，可以提高测试的效率。黑盒测试只能发现问题，容易描述不清，导致问题鱼龙混杂。
数据完整性测试理论上曾经提到过边界测试、约束测试等。我想这个方面是与流程测试关系最密切。在具体应用的时候应该在流程测试的基础上添加测试数据。基于流程的测试案例如果是一幅骨架的话，测试数据就是血肉。流程至少需要两道工序遴选的话，那么测试数据的要求相对比较低，但比较繁琐：需要对流程中每个动作的数据进行组合，组合后的数量可能很大，但并不复杂，可以用程序实现。组合数据比较麻烦的地方在于各个动作要求数据的选择，如果是数值，要考虑到数的范围、精度、格式，以及逻辑上的约束（如年份分先后，月日个不同）等，如果是字符，需要考虑哪些是禁用的字符，哪些可用的字符，字符的长短是否和后台数据库相一致。

4．对需求变更或其他情况的预防与协调
项目开发过程中，会遇到需求变更、概要设计、详细设计出现问题的情况。现实中，这些是避免不了的。如何应对，对于测试人员也很挠头。抛开项目的利益因素，谁也不愿意看到返工和重复性劳动。现在很多工具软件都应运而生，功能也都各有春秋。但是每个人都用来得心应手。对于测试人员，工具软件过于庞大，可以进行针对性较强的程序实现。
对于各种变更和不确定情况，我觉得只要抓住流程这根线就可以了。流程变更可能是测试设计的最大威胁，工作量也使最大的。如果可以把流程细分到动作，通过程序进行流程的组合，可以相对方便的应对流程的变化。但具体的问题大部分出于详细设计的改动，包括一些设计细节的随意性，可能导致测试设计的不稳定。这确实需要评审、质量保证等活动进行约束才行。
对于有什么更好的办法让测试人员更主动的面对变化，希望能在此抛砖引玉，共同探讨。

以上是我在测试工作中的一些具体办法，如有雷同，不胜荣幸，共同探讨。

[digital1]

系统分析人员在写需求用例的时候，就要给出系统级的测试用例。
系统设计人员在设计的时候要给出结构测试用例，测试系统结构，契约等。
编码人员给出单元测试用例。

你的需求测试是需求用例测试吧？数据测试，流程测试在任何阶段都有啊

[moonly]

我的观点与你有所不同，我认为测试人员应该具有主动权，而开发人员相对来说被动一些。开发人员应该根据测试人员的要求来开发。
我认为测试人员的任务很重，因为他们要对项目不仅应该有总的了解，而且还应该系统、深入的了解，也就是要把项目的各个环节不仅熟悉，而且要把它们贯穿起来，在这种情况下还应该与开发人员进行商讨，对于必须有的要求，是不能向开发人员妥协的。

[ntlan]

首先感谢楼主，如此好文！

楼主的“需求测试”真是一语惊醒梦中人哪，是的，在我们项目中的测试重点大部分在“流程”与“数据”上了。关于 moonly(小月)朋友所谓的主被动问题，我想做个项目工程管理的经理们应该清楚，程序业务实现得如何大多数是取决于开发人员的，特别是应用软件，客户对自己的业务很懂但不一定知道如何用计算机实现，在做需求分析的时候可以感受到。

我认为“需求测试”这个观念很好，很好的把测试理念提升到项目中的每个流程，且能很好的提前对工程进行把握！

[benci26]

我估计在大多数公司中，测试人员目前不可能接触到开发过程的各个阶段，会必然会导致资源的不合理利用。比如只要求某些人做黑箱测试，可能机理比较简单的错误，测试结果会描述的很复杂；或者在开发人员眼中本不是错误的地方，由于理解的不同，会被定为错误的。这不仅容易导致测试与开发之间的矛盾，也大大浪费了有限的测试资源。
多数情况下，测试人员也不可能与开发人员同步进行测试设计。使得测试不能跟着需求走，只能跟着开发走。

[Rose2000]

wait

[xiaohaiz]

楼上各位的看法都不错.我原来做测试的时候也总是倾向于理想的环境,但是理想和现实总是有距离的. 传统的软件工程在某些新的领域是否还有用?答案可能是否定的,我个人也愿意认为是否定的. 在敏捷的开发方法中,应该把测试工作和开发合在一起,每个人都是设计师,每个人都是开发人员,每个人都是测试工程师,每个人都是集成工程师(来源自XP).
按照这样的敏捷方式尝试过一个小项目,测试驱动开发.个人认为取得的效果不错.
之所以说以上的废话,就是想表明,把测试和开发的职责,人员划分开(甚至在行政上划分开)可能是行不通的,扯皮的事情经历过,见过,听说过的多得海了去了.
当然如果你做外包软件的除外,不在讨论的范围.