软件测试的由经验到实际操作的演进

 

   关与系统2.0版2012-09-12~2012-09-17时间段内的测试。

   这次的测试主要是针对系统2.0版由于备案和监控两系统统一共用的基础数据库所做的修改。原有系统中备案和监控共用同一个主框架，现在将两者分离开来，但两者之间共用的数据比如说用户信息、单位信息等需要统一，这些改变会牵扯到数据库数据结构的更改，而数据结构的更改必然引起系统代码方面的更改以及部分数据优化方面的更改。所以对于测试人员来说，整个系统都要全面的测试一遍。

   接着，具体的描述一下这次的整个测试思路以及测试过程。

   因为之前有看过一份网上详细的测试报告，中间描述了具体而有效的版本控制的思想，所以在一开始组织测试时，就有意识的将测试分为各种阶段，借以模仿版本控制。

   开始测试的时间是在周三上午，要求礼拜末就要发布一个可以对外的版本，意味着有整整三天的时间来进行测试。

  

1小时
BVT	重大问题发现		验证BUG以及小功能测试		验证BUG
2012-09-12（周三）		2012-09-13（周四）		2012-09-14（周五）

   测试流程分为四个阶段：第一阶段，进行版本验收测试，主要看系统是否可以运行起来，模块核心功能在正常情况下能不能实现；第二阶段，也是最重要的测试阶段，在这个阶段里关注主要业务逻辑、需求、详细测试，总之一切重大缺陷的发现都应该在这个阶段进行；第三阶段，这个阶段比较繁琐和散乱，在这个阶段里主要进行上个阶段BUG的验证以及一些剩余小功能点的测试，主要还是应该以上阶段BUG的验证为主，在这个阶段对于工作优先级的把握，做好递归工作；第四个阶段，剩余周五下午进行剩余BUG的验证，在这个阶段里，尽量保证严重或者麻烦的BUG已经几乎不存在了，这样才能正常的保证任务的完成。

在这个过程中，各个阶段的工作的把握和控制很需要有一定的梳理。接下来结合实际的测试过程，对上述四个阶段进行评述。

真正展开这个项目的测试工作是在10点，按照之前的计划，BVT测试的时间要控制在1个小时之内。因为数据库的问题，导致更新的版本无法访问，各模块点击无反应。经饶xl的一番更改之后，存在的安监站列表无法显示等问题消失，开始正式从10点起进行测试。在这轮的操作中，应该以最快的速度查找出系统是否有主要功能直接报错的问题，比如说点击系统主要功能看是否报错、主要模块的新增功能是否能顺利进行、页面显示是否有很明显的缺陷，主要应该从上述三个方面来进行最快的测试。虽说是一整个大系统，但是功能模块确实也就那么几个，保证在一个小时内完成这些测试的执行并且将问题描述给开发人员，时间还是比较充分的。在实际的测试中，时间略有超出。在BVT的执行过程中，不小心就纠结在了施工单位模块的详细测试上和一些查询操作上，当发现剩余的时间对于测试剩余的模块来说有点紧张的时候，就不可避免的有点手忙脚乱了。最后在超出约10分钟后，完成了这个阶段的测试。在整个系统的测试过程中，对于重要的功能模块自己心里应该有个谱，接着对于这些模块的BVT测试中要保持一视同仁，不应因为某些新增功能而多加逗留（在这次里施工单位管理中将另外两种单位都增加在了这个模块中）。

因为时间比较赶，所以第一个版本中严重的影响测试进一步进行的BUG还是比较多的，但另一方面，表现的越严重的BUG解决起来越快，所以第二个阶段的测试还是可以很顺利的展开的。

在这一阶段主要应该集中注意力在监控登记模块和实时监控模块还有其他用户所见系统里，监控登记模块中的工程项目子模块和施工单位模块要重视，子工程项目中逻辑关系相对比较复杂而且会影响到的系统其它的方面比较多一点，施工单位模块中较原系统中有了很多的不同。施工单位管理这个模块是11:20~14:10（约50分钟）中间测试的，视角主要定位在原系统和现系统间施工模块区别的角度来测试，这块的问题确实比较多，但也在计划的时间内完成了。工程项目子模块的测试，本来预期在14:15~14:45内测完，但是出现的问题还是比较多，只能一推再推，直到16:00才告一段落，大约用了两个小时，这期间有点混乱，出现了很多阻止继续测试的BUG，然后和开发交流，因为之前没有考虑周全替代的可并行的测试线路，导致在等待开发修改代码的过程中有点措手不及，有点忙乱。虽然在这个版本之前有约一个礼拜的时间配合开发人员完成了工程项目子工程项目的功能，这次是由于基础库的原因接着做一次更改，但是开发提交的版本还是问题比较多，可能也确实在系统大多地方都是靠工程来统领的：监控登记、实时监控、统计报表，可谓牵一发动全身。实时监控模块这里问题倒不是很多，有也是工程那块的更改引起这里的问题。接下来的时间基本都是在验证部分BUG的问题上了。第二天也就是礼拜四，集中在其他用户登陆系统的测试中了。在这块里问题特别多，虽然除安监站外的用户登陆系统后的模块都很少，但是由于开发考虑的比较少，所以严重的问题比较多，眼看着时间如此紧迫，后来咨询过经理后，被告知监理单位用户和产权单位用户的情况可以暂时不予考虑，工作量骤减。到此第二个阶段算是完成了。

周四下午，展开第三个阶段的测试。验证之前的BUG，以及小功能点的测试。包含有监控登记、报警信息处置、安监站管理。现在想想自己对于实时监控中的运行数据、吊重数据、运行时间的测试还是很不到位，本来应该在这一阶段覆盖上去的。这几个子模块要么逻辑比较简单要么是没有因为基础数据库的问题影响多少，所以放在这个阶段进行测试。在此阶段所验证的BUG基本都是上个阶段测试出来逻辑功能有问题的。在周五上午主要是工程管理模块中BUG的一些验证。

周五下午，第四个阶段，残余的测试工作就寥寥可数了，所以还算比较清闲，基本上是简单的验证BUG。现在想想在这个阶段应该在展开之前，认真的分析系统哪些地方BUG多发，哪里比较重要，用户使用率高，从而进行有条理的探索式测试，散而不乱。当时真的是难受极了，没有章法的在测试，整个人就被BUG的验证所支配了。对于漫无目的的测试实在是无能为力，在5点的时候，和开发沟通了一些笔记下的BUG的更改情况后，就呆在畅xx旁边看他改2.0版里面剩余的BUG，观察改BUG的过程。

测试过程中和之后心里有些关于测试的想法这里来主要阐述一下。

第一阶段中要注意的东西不是很多，高效率的测试出影响系统运行起来的缺陷。

第二阶段的测试需要提前进行很好的设计。这里应该对主要模块的主要业务逻辑进行集中火力的测试，侧重点应该放到这里。如果这种业务逻辑全靠测试执行中的突发奇想来完成，很容易有遗漏。这里发现的问题应该是一些需求、逻辑方面的，对于开发来说修改起来比较麻烦的，如果在前期漏测，在后面的阶段才想起来的话，将会很影响整个项目的进度。在这个阶段，发现问题后，大多会引起本模块的测试的无法进行，所以在设计测试思路的时候，还要考虑和其重要等级相似的模块，当必须等待开发修改完毕之后才能展开此模块的测试的时候，可以及时的将等级相似的另外一个模块的测试提上日程，以防自己会手忙脚乱。还有，对于容易出问题的开发人员的开发出的模块，因为他们一般改好一个模块会比较麻烦，所以在这个阶段尽量早的测试，给他更多的时间。

第三个阶段中涉及到前期BUG的验证还有剩余小功能模块的测试，要时刻记得将BUG的验证放到更高的优先级，并且在BUG验证的过程中有意识的发掘除第二个阶段中覆盖到的业务逻辑外是否还有其他的业务逻辑没有考虑周全。

第四个阶段是测试末期，应该立足整个系统之上，就本次系统特点分析系统问题多发点，将其罗列出来，继而进行探索式的测试。