如何发现隐含的测试点

     最新开始忙了，项目进入了系统测试阶段，突然觉得忙起来也是一件很有意义的事情，也许是之前我闲的时间太长了吧，还没开始测试之前，就忙着准备一切，希望自己能把这次项目做的更好，根据之前的经验总结，把之前容易犯错的问题在后续的工作中避免出现，得到提高。

 

    一般测试人员都是根据软件需求说明书来展开对系统的全面测试，然而很多时候，因为文档写起来会比较繁琐，开发人员并不是写的特别详细，特别明确的，很多细小的要点都不会在需求说明书中体现，作为测试人员，在测试过程中，结合实际的系统和说明书我们要有一种敏锐的观察，能看出哪些隐藏的测试要点也是很重要的，在测试过程中是不能忽略的重点测试对象。系统中那些各个模块有关联功能的，是很容易被忽略的，可能各个测试模块的人员不同，在最后很难说我会去测其他同事负责测试的模块，这中间就需要在最后一步做一个所谓的联测，即一条数据流走后台到前台，从我这里发出的数据请求，在其他模块能否正确得到应答等等，都需要重点关注；

 

   根据我所测试的系统分析，往往被隐藏的测试点主要有这些：

 

1，参数管理模块：比如说某一个参数，它有个最低最高层级的设置，但是需求中开发并不会很明确的说这个最低最高层级会有怎样的限制，他们往往也会忽略这个细小的判断，即最高层级不能小于最低层级，在我们的实际系统中，这个逻辑判断就没有限制，那么我们在测试的时候，脑海中要立即闪现出这个测试点，程序上是否做了判断；

 

2，查询模块：比如说有一个查询功能，根据不同的机构，不同的角色，不同的用户id等条件可进行查询，原先的功能是机构只有一个，如果登录的用户属于这个机构，选择角色之后，该机构下属于该角色的多个用户ID可供选择，现在又加了2个机构的选择，但是软需上没有写明查询的用户要剔除正在登录的那个id。在测试过程中，这里很容易忽视用户id的判断，基本上都会看看能不能用单一或是组合的查询条件，能不能查询出来数据，不会关注到本身已经登录的用户在用户id中不能进行选择，不管是什么机构下的用户角色都不选择自己；这个也是在我测试的系统中开发忽略了的；

 

3，初始化脚本：我们的系统中有些模块是需要提供初始化脚本，虽然检查脚本也是一种方法，但是在脚本运行好之后，验证前台也是一种保险的做法；比如说有些初始化数据，某个字段不可维护xx字段，后台字典值记得是1-是，0-否，前台验证的时候，要特别关注前台显示的字典值是否正确，且某个字段不能维护，前台要新增一次看看这个字段是不是不可维护的，只有默认值显示等；

 

  以上是今天先写的几个方面，后续的会逐步补充。。。