你真的会测试吗？

 

前段时间公司在做一个专案，关于开发SAP三方交易单据联动的平台，大概功能就是系统里面两家公司交易业务里自动根据销售公司对客户的销售订单生成相应的采购订单和销售订单，包括后续交货单联动创建，开票和发票校验联动创建等。

或许你会问为何不用SAP标准的公司间销售（跨公司销售）的功能，因为公司财务觉得此标准功能有财务税务风险而且少了一些单据，不让用。所以开发三方交易联动的平台，满足所有单据生成的同时也可以省去很多工作量。扯远了，我想说的是，系统上线之前，我自己测了一遍，发现问题不少，跟供方和内部集成测试得出的结果有出入。

 

 

主要表现在：

a.数据存在性校验缺失（配置画面可以输入不存在的销售订单类型）；

b.数据有错误

c.前后表单数据关联性缺失（某个类别已经分配了具体配置信息了还能被删除）；

d.数据逻辑锁缺失（维护画面可以同时多人进入维护）；

e.数据一致性缺失（具体表现在采购单生成了但销售订单没有生成）；

f.系统反馈信息很生硬（比如客户没有维护信贷范围、订单可用量不能大于未清量、系统出错等）;

g.缺乏有效的唯一记录（配置信息可以维护一模一样的记录，系统读取的时候只是读取任一一条，这是不严谨的做法）；

h.可以提供选择的栏位并没有提供查询选择功能（比如销售订单类型和客户代码，没有提供小按钮查询）；

 

想到这么些年过来，每次遇到系统/功能要上线都是测试没问题，但上线一使用就各种问题出现，乙方顾问拍拍屁股走人了，只剩下甲方顾问惨淡得沦为“人肉运维”。

 

 

那么到底要怎么测试才算合格呢？

一、测试环节：

1、开发人员基础测试

很多开发人员做完一个功能/报表之后，只是激活成功就提交给内部顾问来测试了，结果发现测试的问题一大堆，比如栏位写错，比如变量没有清空，比如表关联条件写错等等。合格的开发人员在做系统功能的之后应该要简单测试一下，避免开发层面的错误，还要学会简单地造业务数据，自己先测试一下基础功能是否OK；

2、业务顾问测试

开发环节测试之后，提交到业务顾问这边进行测试。业务顾问就要对当前功能的所有功能点以及业务场景进行测试。业务顾问对当前程序功能逻辑是非常清楚的，测试的时候难免就会潜意识里避免各种错误和漏洞，测试过程比较循规蹈矩，往往深挖不了各种错误。所以业务顾问的测试就要尽量做到全面细致，对每个逻辑要测试一遍；测试OK之后再提交给业务人员测试。

3、业务人员测试

业务人员并不清楚系统功能是如何开发实现的，他们只关心系统展现出来的数据各方面都符合自己的预期，满足自己操作便捷的需要就可以了。业务人员会比内部顾问还更懂得业务场景和数据规则，往往他们能够测得出来更多深层的问题。

 

 

 

二、测试要点

1、数据正确性测试，尤其是重要的数据；

2、数据一致性测试；

3、提示信息是否直观明了，是否用户一看就知道问题所在；

4、数据锁住功能，保证维护唯一性；

5、异常流程测试，异常操作测试；

6、功能逻辑是否符合业务场景、业务流程；

7、操作方式是否简单便捷，录入和输出信息是否有反馈；

8、与其他系统的接口对接是否正常；

9、数据规则校验，比如被除数不能为0；

10、其他；

 

一个系统或者功能上线，测试的最大比重在于内部业务顾问，担任承上启下的作用，懂IT系统又懂业务是业务顾问的优势，一定要把自己“放空”，不要让潜意识占据自己的测试方式。一会儿自己很清晰明了业务逻辑，一会儿要把自己当做什么都不知道的用户。如果业务懂开发，必要的时候还要翻开代码查看个别重要的逻辑（业务顾问会开发，做什么都会很有效率和质量）。把一切问题都消灭在测试阶段，让系统更健壮，让用户对系统更有信心，避免让自己成为没完没了的人肉运维。