CIO在软件选型的过程中，除了要关注软件与企业是否合身外，还需要关注应用程序在设计与开发上，是否存在着一些软件漏洞。所以，如何迅速定位应用程序的漏洞，也是CIO必须掌握的一项技能。

　　为了帮助CIO提高这方面的能力，笔者根据自己这几年应用程序选型与测试方面的经验，谈谈自己的看法。希望这些个人工作经验的总结，能够帮助大家解决心中的疑惑。

　　意外且常见的功能需要额外的关注

　　意外与常见，可能看起来比较有矛盾。其实，在应用软件功能测试上，这两个名词往往经常碰在一起。一方面，企业的实际情况跟应用软件设计的假设模型有差异，这就导致了一些意外需求的发生。另一方面，如果这些需求是时常发生的，则说明这已经不是意外事件了，而是在应用软件中必须实现的需求。这种情况，在软件选型中会经常碰到。如财务管理软件中，单据凭证需要的编制就是其中的一种。根据相关法律的规定，凭证的编号必须连续。但是，在实际工作中，往往因为错误或者其他原因，需要删除某些凭证。此时，凭证编号就不连续了。而在财务管理设计中，有时候程序开发人员就假设用户不会因为错误而删除凭证，至少只是把凭证做废掉而已。但是，事与愿违。现实中，其实恰好相反。企业用户更喜欢删除没用的凭证，而不会作废凭证。

　　所以，CIO在选型之前，就需要去向用户收集这些需求。并在软件测试的过程中，着重做好这方面需求的测试。要知道，对于常规的需求，通常情况下，软件都可以满足，也不会发生错误。而对于这些异常的情况，若产品设计人员实务经验比较比较缺乏的话，则考虑问题的时候就会偏向于理论化。这些意外而且常见的功能往往就是这些应用软件的软肋。故CIO如果能够调整自己的战略方向，把软件功能测试的重点放在这些方面的话，可能就可以迅速定位应用程序的问题。

　　首先测试二次开发的部分，然后再测试没有变化的部分

　　企业出于应用软件的部署成本或者规范化来考虑，现在往往是通过购买成熟的商业软件来提高自己的信息化办公水平。这就出现了一个新的问题。由于商业套装软件往往是根据预计的管理模型而设计的，跟企业的实际需求往往有一段距离。根据笔者的经验，还没有哪一家企业，在没有进行二次开发的情况下，就可以顺利利用这个套装软件。所以，在通常情况下，企业肯定需要通过二次开发来完善ERP的部门功能，以适应企业个性化的需要。

　　但是，在一个成型的应用软件上进行二次开发，就好像在一幢已经造好的房子进行修修补补，很明显会破坏应用软件原有的完整性，从而影响管理软件的稳定性。为此，CIO在应用软件测试的时候，二次开发功能的测试，将是其测试的重点。

　　另外，除了在测试二次开发本身的功能之外，还需要测试那些虽然没有变更、但是跟二次开发直接相关的作业。看看变更后的二次开发功能跟原有的系统作业是否协调、兼容。千万不能够顾此失彼。如果原有的作业不能够对新开发的功能提供很好的支持，那么二次开发也就一切白搭。

　　并发性测试也是必不可少的一部分

　　很多CIO在软件测试的时候，往往只重视软件的功能，而忽视了软件运行的性能，特别是并发性访问的性能关口问题。因为在软件测试的时候，很多CIO只能够在单机的环境下，对软件进行测试。这也是造成这个问题的一个原因。

　　在单机测试的情况下，无法真实反映应用软件的性能问题。如不少CIO在单机环境下使用应用软件时，觉得速度还可以接受。但是，一当应用软件并发访问的人数增加了，则应用软件的性能呈直线下降。

　　现在企业大部分应用软件都是基于服务器/客户机模式。所以，应用软件的并发性访问将是常态。若通过单机测试，CIO无法了解其软件设计的是否合理。如不知道数据库中并发性访问是否会导致比较多的冲突；不了解应用软件并发性访问的关口在哪里；不清楚应用程序如何解决多个用户同时访问某个窗口而同时要保证数据库一致性问题等等。这些问题处理的好坏，直接跟应用程序的并发性访问性能有关。

　　故笔者认为，企业在应用软件测试过程中，不要只是简单的单机测试。单机测试往往只能够看看功能上面的问题，而不能够判断应用软件的性能问题。换一句话说，即使单机运行的速度很快，也不能够保证并发性访问时取得比较好的性能。

　　笔者建议，企业在应用软件测试时，最好能够部署一个联网的并反性访问测试环境。在必要的情况下，组织多个用户多同一个窗口进行同时访问，看看其性能是否有明显下降。并进行更改测试，看看在并发访问的情况下，应用系统如何来保证数据的一致性问题。

　　多多删除或者作废，可能会有意外的收获

　　在应用软件测试的时候，笔者建议CIO，不要从头做到尾。而应该在中间稍微停顿一下，并且多试试删除操作。或许，从中我们可以有意外的收获。

　　这主要是因为企业在用户实际操作中，往往不会一帆风顺。当出现各种各样的问题时，用户往往需要删除当前的单据，从头再来。如在ERP系统中，用户从销售订单生成采购订单之后，有可能会发现某种原材料仓库中有库存或者可以利用其他材料来代替，不需要采购；或者也可能因为订单的变更而导致采购订单的作废等等。此时，若CIO尝试着把采购订单删除，则可能就会发现应用软件中的一些错误。

　　如采购订单作才掉之后，再按照销售订单生成采购单，是否再次允许声称采购订单。通常情况下，这是不允许的。既然采购订单作废了，也就表示不需要采购这方面的内容。那么在系统中就要实现控制，当采购订单作废了之后，就不能够再根据这张销售订单生成者张采购订单了。虽然有些应用软件中实现了类似的控制，但是其中仍然存在着一个漏洞。就是如果一张销售订单所需要的原材料供应商达到十个，在生成采购订单的时候，就会生成十张采购订单，一个供应商。有些软件若考虑的不够周到的话，则只要把其中一张采购订单作废掉的话，则其他采购订单也将无法生成。很明显，则是不合理的。也就是说，采购订单作废时要保证一定的独立性。

　　所以，笔者建议各位CIO，在软件选型测试的过程中，要多多利用系统单据的删除或者作废功能。看看起是否会有一些考虑不周到的地方。通常在这个环节中，会发现比较多的问题。如果在选型的时候没有把好关的话，到时候企业只能够自己掏腰包解决了。

　　变更测试，也是发现问题的一个重要渠道

　　变更操作，在应用软件测试中也是非常重要的一个环节。通过变更测试，往往我们CIO可以发现应用软件中的一些薄弱环节。如在ERP系统采购管理中，同一个零件往往会有不同的供应商。在系统中自动生成采购订单的时候，往往选择的供应商是企业默认的供应商。但是，企业往往由于各方面原因，如默认供应商交期不能够保证等等，会对供应商进行变更。为此，若供应商变更在应用系统中是否采取了一定的应对措施，这就是CIO所需要测试的内容。

　　根据笔者的经验，不少ERP系统中在这方面考虑的不够完善。如不同的供应商可能对应不同的价格。虽然在采购订单上可以更改供应商，但是，单身的采购订单价格却无法随之改变，而需要用户进行手工的更改。很多ERP软件忽视了这方面的细节，凭空给用户操作带来了不少的麻烦。

　　变更测试中另一个典型的案例就是采购订单分单问题。如企业需要采购某个物料1000套。可能数量太大供应商无法一个人生产，又或者出于在供应商之间平衡的目的，企业往往会分几个供应商下。若企业按照应用系统正常的流程来测试，往往不能够发现这个问题。只有利用变更测试方法，才能够发现其中的不足。如根据以前管理的经验，这种分单只需要变更自动生成采购订单的数量，然后再手工开立采购订单即可。但是如此的话，若想知道某张销售订单的到料情况，因为手工开立采购订单跟销售订单失去了联系，系统中就无法生成类似的报表；或者在报表中将会有内容遗漏。

　　故笔者认为，通过变更测试可以帮助企业CIO在软件选型的过程中，迅速定位应用软件的问题；为企业软件选型提供帮助。