最近一两个月，随着宝贝的长大，行动有些不太方便，协调沟通和任务跟踪这些事情确实太伤我的神，所以我转变了方向，一直投入在系统的功能测试中。

　　以前一直没有时间分身来测试的系统，经过这么仔细和初步设计了测试思路后，我开始投入这些功能繁多的系统测试执行中。

　　测试设计脱离不了对系统的理解，我找了产品经理要了相关的文档，从加强对业务的理解着手，加上我本身对各系统的需求和任务跟踪过程已有的对业务的理解，以及跟老大写通用测试用例的基础，基本的测试思路还是很容易出来。

　　另一方面，我开始点击系统的每个模块，从界面着手把所有的功能点通过excel列出来，这就是所谓的大纲法。列出后加上对业务上的一些规则和数据约束，对功能点进行说明。

　　接下来就是系统测试执行。测试执行过程中又分了几个阶段。初步执行测试时，对系统的理解还有限，所以点到一些功能后，一边要和开发沟通设计和业务，一边还发现自己还有许多未考虑到的地方，同时把这些未考虑到的测试点加入测试大纲。所以我总结出来，测试不可能只进行一次就能够全面地评估系统的质量，肯定有一个这样的过程：对系统不断地迭代测试。

　　就如**系统测试，这个系统同类功能非常多，所以我测试的时候测完一个菜单就基本整理出来了测试功能点，但是测试到了后期，我在某一个菜单测试时，修改查询条件，再点击翻页，发现翻页实现了新的查询条件。这样的测试在我设计时根本无法考虑到，因为跟业务无关，跟设计一般情况下也没有关系，可能同开发人员的关系大点。我只是偶然间才发现的。所以测试执行过程中的第二个阶段就是发现新的测试点，对同类功能必须重新测试一次；

　　另外，执行测试过程中，对于同类功能点，总以为是相同的原理，有时就有些忽视，例如一个文本链接，我总觉得这只是打开一个新的页面而已，所有同类型功能点都是调用同样的参数。可就在我轻视测试全覆盖的时候，偶尔点一下这个链接，发现提示无法登录，这下我又只能从头至尾执行一次所有该连接的功能点测试，甚至都记不清楚自己哪些测试过的。所以，对于想偷懒的测试人员，这是很好的教训，不要忽视同类型的简单功能点，不要抱任何侥幸心理。做手工测试就老老实实地走一遍功能点。

　　测试问题的整理，这也是测试执行过程应该要注意的一点。对于有问题管理工具的测试人员，这个可能不要考虑这么多，但是我们的管理过程中就是缺bug管理工具。这时问题整理是否清晰就全靠自己的意识了。我基本上喜欢根据模块整理问题数，在word的文档结构图中能够看出每个模块和菜单的问题数，系统总问题数。测试完成之后，对所有的问题进行分类整理，分析系统的问题点在哪些地方，如问题集中在数据正确性，还是功能未实现等。针对特别紧急和严重的问题单独列出来。实际上这就是bug管理工具中的缺陷分类和缺陷严重性。再考虑一下测试环境和其他风险，有了这个问题整理的方法和意识，基本上能够看到整个系统的质量情况。经过这一过程对于问题较多的系统真的非常地明确。

　　最后，我就整理邮件发给对应的项目责任人。实际上，在我们这种项目环境中，一个人对应五六个系统，真正经常去进行系统测试是不可能的。我以前也一直转在项目协调中，经过最近人员的调整和我自身工作的调整，才有这个时间和机会来发现这么多的问题。

　　通过这个测试过程，我想了想测试人员到底应该做什么？怎样才能体现测试人员的价值？我们长时间地被这些版本测试给拖累着，每次都是版本测试+系统升级+各项目问题处理，这样下去测试人员如何能够抽出来进行这样全面的系统测试，或者说根据现有的项目状况，多久应该进行一次全量的系统回归测试。当然，版本测试到位，后期系统回归测试的问题会少很多。但是根据现有的状况，一个系统有上百个bug，这无不体现设计、开发和测试的不到位。尤其对于测试，这样长时间下去，测试人员的技术水平永远停留在这样的水平。我作为要给测试管理者不得不深思。

　　所以，测试人员在这样的项目环境中（一个人负责五个子系统），应该做到如下几点：第一，做好现有的版本测试工作，一个星期三个版本，尽量控制好测试时间和测试质量，避免返工。第二，对现有所负责的系统一定要有全面的测试，尤其是从别人手上接过来的系统，要对它们有足够的了解，包括业务上的和系统的遗留问题。第三，要提升自己的测试技术，不要因为系统多，任务多就把自己困在这样的死循环中，一定要从繁杂的工作中抽身出来看看自己的系统是什么样子了。第四，文档要整理，版本要规范。例如部署手册维护，通过文档去指导实施人员，而不是每次都帮助他们全权解决每一个问题。定期备份基线版本，记录版本台帐，清楚每个版本还剩多少问题，发现新问题就及时维护自己的问题清单。

　　只有真正做到这些，我们测试人员的价值才能体现出来，才能真正评估我们系统的质量。当然，这或许是一个非一两个月能够达到的目标，但是，半年后，如果测试人员达不到这样的水平，对比开发不断去改进和提高，需求不断地融入项目管理中，测试的作用也就越来越弱，在项目中的立足空间会越来越小，这不是我们想看到的结果。

版权声明：本文出自 sunlight426 的51Testing软件测试博客：http://www.51testing.com/?284322

原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。