提升测试的广度和深度（二）

     

  上周和大家交流了一些关于提升测试的深度和广度的话题，很感谢大家热情的参与和支持。今天我们继续来讨论上次遗留的几个问题。我们一起来说说，对于我们测试人员，如何快速有效的提升我们对于开发流程的学习和分析这件事情。
 

   首先我们要有一个全面的观念，即开发不是只有写代码这一项工作， 但是很多已经在测试岗位上工作的朋友，可能看到您的公司里面除了项目经理就是写代码的开发工程师，其实这是公司组织结构不规范，工作流程不完备造成的一些缺漏。很对软件公司，由于这样那样的原因都会形成注重代码而看清设计和文档的现象，这些我们作为测试首先要理解，因为公司也有公司的难处和不易。但是我们不能因此也跟着“随波逐流”，即开发过程不完善，质量较差，我们就只满足于黑盒的点点测试，也能发现很多问题，而使我们的测试工作停滞不前，技术没有拓展。因为如果我们这样做了，一方面对公司整体的软件质量提升没有任何的帮助，同时更是对自身职业发展的不负责任。大家可以想象一下，作为一名测试工程师，如果每天都是围绕着界面功能，点点画画，别说三五年之后，就是一两年之后，我们也可能随时被人取代，而且你就算想重新找工作，能找到的工作仍然也只是界面上的点点测试之类的。因为所有公司在招聘员工时，都是针对你已经做过的事情来评判你的能力，从而给你一个适当的岗位。绝不会有公司，因为你想成为什么样的人，而给你什么样的职位，除非我们和公司的领导有关系，人家愿意花血本培养我们。除此之外，是绝没有发展的可能的。
 

   所以我们一定不能把希望寄托在它处，只能是以我们自己为中心，首先可以把我们在培训过程中学习过的相关的测试工具选择一个来应用熟练，无论公司是否在使用，我们都可以将其装在我们自己的机器上进行应用，（比如可以先从QC或QTP入手，因为这两个工具比较简单，也容易上手，取得成果），在应用的过程中，切记以下几个方面：
 

   第一：本职工作一定要出色的完成，主动与主管交流看是否还有其他工作需要你完成，在没有其他工作需要完成的前提下，再考虑使用我们学习过程中的测试工具来优化我们的测试工作。否则，不要着急工具的应用。有人可能要说，那我工作一直很忙，我们公司也没有条件让我装工具怎么办。那也没有关系，只是我们要辛苦一些，利用业余时间，给自己制定一个计划，回家后或利用加班时间来提升。有人可能又说，我已经很累了，这样不是更累吗？那看大家能不能思考一个问题，你是想这一辈子都这么辛苦，没有突破？还是说辛苦一段时间，好早点脱离苦海呢？我不能替大家做任何的选择，只是希望大家都能有一个好的发展，而发展的快慢，是完全由我们个人决定的，和公司没有任何的关系。所以当我们没有发展，或发展速度较慢时，我们先从自身问起，先从自身做起，这样我们才能逐步达到“境随心转”，才能完全的自由自在啊！
 

    第二：在进行测试工具应用的过程中，千万不能贪多，在培训时，因为时间有限，又希望大家能掌握了解的多一些，所以短期内学习了不少的内容，但是在工作中，我们要做到的是数量和精通，不需要多。我们用一年的时间熟练掌握一门工具足矣（比如第一年目标是QTP自动化，第二年性能测试，第三年白盒测试），这样也不需要太久，你就成了测试全才了，所以大家一定要一门深入，长时熏修，这样才会有效果，千万不要东抓一把，西抓一把，也不要看什么流行学什么。因为你掌握好了一类里的一门工具，其他都是类似的原理，无非就是操作语法稍有不同，原理规律都一样，不要赶时髦。
 

   第三：也是最重要的，不要认为只要把测试做好，学好就是目标，我们要学中医治病的方法，要标本兼治，要成为一个全科医生，而不是头疼治头，脚疼治脚。要想成为一名优秀全面的测试工程师，就得从我们说的开发过程入手，无论你所在的公司开发流程多么不完备，我们都可以通过自己的努力提升，来为开发查漏补缺。比如当我们拿到数据库设计报告时，就要开始逐一分析，这个数据库设计与需求以及概要设计相符吗？存在问题吗？有错误吗？这些一定要有意识的去分析，而不是傻傻的，只知道进行界面功能测试，如果数据库设计出问题了，那么就是大问题了，而且这一类问题，一般在后期才有可能会被提出来，但是对公司而言，这个风险和成本就太高了。比如，有一个员工管理功能，实现员工信息的增、删、改、查。我们看到其对应的数据库表结构（为了让大家容易理解，我都用汉字来进行，实际中一般不会这样写），如下表所示：

当我们看到这样的表结构设计时，不知道大家是否能看出其中的问题？这里面存在一些冗余字段。在我上次给大家推荐的《软件是这样“炼成”的》这本书中，关于冗余数据分析，有较详细的解释和说明（在第三篇，数据结构，P453页—冗余数据分析），大家有空可以看一看。我就简要说明一下关于数据库设计中冗余字段的缺陷隐患问题。

 

   在上面这张员工信息表中有员工部门编号、员工部门名称、职称编号和职称名这四个字段是冗余的，（因为在部门信息表中，一定有部门编号，部门名称。在职称信息表中，一定有职称编号和职称名），但我们看到这些冗余字段时，一定要特别小心。有些冗余是必须的，有些冗余是可有可无的，但如果加入这些冗余字段，一定要警惕，级联更新和级联删除的问题，否则就会造成大量的“脏数据”，即同一数据在不同表中的值不相同的问题。就拿我们上面这张表来讲。加入部门编号和职称编号是可取的，因为要进行多张表的数据关联，要依靠外键进行连接，否则我们不知道这个员工对应的部门和职称信息。但是部门名称和职称名称放在这个表中，就不是特别合适了。但是开发或设计人员可能会说，在系统中，我们经常都要查询员工的所有信息，把这两个字段加进来能提高查询的效率，大大提高员工查询和统计的速度。如果我们不懂数据库设计，一听人家这么一说，我们可能就无语了。但其实这样的冗余字段设计，虽然提高了查询的效率，但是它还有一个被我们忽视的副作用。就像我们常说的：“凡药三分毒”一样。这样的设计，如果负责部门信息维护和职称信息维护的开发人员并不了解员工表的设计，很容易在修改部门名称或修改职称名称的过程中，根本就不知道同时要修改员工表中对应的字段值。这就是我们说的没有考虑到或根本就不知道要进行数据的级联更新。
 

     那作为我们测试人员，我们就一定要做到以下两点：
第一：分析部门名称和职称名称可能修改的频率，如果修改频率并不高，可以这样设计，但一定要明确告知负责部门信息维护和职称信息维护的开发人员，在进行修改和删除时，要考虑与员工表的级联更新和级联删除的问题。
第二：如果我们分析后，发现部门名称和职称名称可能修改频率很高，那么就要向设计人员提出风险建议，因为每更新一次部门名称或职称名称就要更新大量的员工信息数据，会导致更新的效率非常低。至于设计人员如何决断，我们无从要求，但是我们有义务提出这样的风险。
 

做到这些，才能说我们不光只是测功能界面，我们在考虑全面的软件研发质量问题，进而才有可能成为一个全面、优秀的测试人才！