一年前，因为一个偶然的机会进入到软件测试的这个行业，刚进入测试时，很多人都告诉我，测试是一个很简单的工作。可是随着时间的推移，对测试理解的越多，了解的越深，我发现测试其实是一件充满魅力和激情的工作。更值得高兴的是，我最喜欢做、最擅长做的事情原来是测试。以下是一些体会，愿意与志同道合的朋友共享之。
就其测试流程来看，我认为主要包括对需求的测试、对业务流程的测试以及对数据的测试三个方面。
第一、对需求方面的测试：
假设用户对于需求是主动的，我们可以发现：用户在项目开始时要归纳需求，在项目结束时要对现实的产品检验需求是否达到；而测试人员根据需求的实际内容，在开发结束后检验是否达到需求要求。显而易见，测试人员对于需求是被动的。
实际情况可能会有些出入：用户对需求的认识大多数时候是被动的，主动在于开发人员。此时测试人员和用户对项目的认识的是一样的。测试人员仍然是被动的，因为他们对需求的理解可能会更多的受到开发人员的影响。测试时也会倾向局限于验证正确性，弱化其破坏性的内涵。之所以说需求测试是不可缺少的第一步，就是因为在此步骤中，测试人员既要理解开发人员的开发意图和需求理解，又要深刻了解用户的意图，多从用户的角度考虑问题，尽量与用户保持一致。可能提出“需求测试”可能不大确切，但我想这个步骤是不能少的。
在本步骤中，测试人员不光要深刻理解评审后的需求分析书，还要尽量了解用户意图，从用户的视角找出需求中的薄弱的地方，以便开发人员能使随后的概要设计或详细设计考虑周全、细致，防止后面过程的返工。
第二、对业务流程的测试：
对于用户，更关注业务流程，所以进入测试设计阶段，应该从用户的角度模拟可能出现的问题。对于开发人员，关注点大部分在于功能的实现上，如果需求、概要、详细设计描述不是很全面的话，对于操作性、方便性不会有太多的考虑。这就需要测试人员从中进行弥补：既要满足的考虑用户的需要，也要满足开发实现的实际情况。
第三、对数据的测试：
数据测试，我想应该包括数据源测试、数据完整性测试几个方面。
对于需要连接数据库的软件项目，数据源导致的问题比较多，其中经常出现的问题包括：数据结构前后台不吻合，数据源接口有错误等。数据源测试，形式上和流程的关系不是很大。具体的案例应该单独设计，即包括数据源设置动作的考虑是否全面，对数据库设计符合设计要求，前后台数据项对应是否一致等。
数据完整性测试理论上曾经提到过边界测试、约束测试等。我想这个方面是与流程测试关系最密切。在具体应用的时候应该在流程测试的基础上添加测试数据。基于流程的测试案例如果是一幅骨架的话，测试数据就是血肉。测试数据的要求相对比较低，但比较繁琐：需要对流程中每个动作的数据进行组合，组合后的数量可能很大，但并不复杂，可以用程序实现。组合数据比较麻烦的地方在于各个动作要求数据的选择，如果是数值，要考虑到数据的范围、精度、格式，以及逻辑上的约束（如年份分先后，月日字符个数不同）等，如果是字符，需要考虑哪些是禁用的字符，哪些可用的字符，字符的长短是否和后台数据库相一致。
以上是对测试流程的简单的阐述，其实在项目开发过程中，会遇到需求变更、概要设计、详细设计出现问题的情况。现实中，这些是避免不了的。如何应对，对于测试人员也很挠头。抛开项目的利益因素，谁也不愿意看到返工和重复性劳动。对于各种变更和不确定情况，我觉得只要抓住流程这根线就可以了。流程变更可能是测试设计的最大威胁，工作量也是最大的。具体的问题大部分出于详细设计的改动，包括一些设计细节的随意性，可能导致测试设计的不稳定。这确实需要评审、质量保证等活动进行约束才行。对于有什么更好的办法让测试人员更主动的面对变化，希望能在此抛砖引玉，共同探讨。
|
