两个测试小案例

点击链接加入QQ群229390571（免费公开课、视频应有尽有）：https://jq.qq.com/?_wv=1027&k=5rbudQa

案例1：

测试人员在测试系统发现在系统A和系统B之间通过总线通讯，偶尔会出现timeout现象。反馈开发后，开发难以重现。根据简要分析后，认为是测试系统性能不行，拍胸脯保证在生产系统，用于系统通讯的总线不会出现这种问题。测试人员加强了性能测试强度，发现硬件提高后，的确性能测试场景中未能重现timeout。最终否决了缺陷。结果上到生产上后，timeout又出现了，而且对核心业务产生了一定影响（多亏有补救办法）。最后用生产数据分析，是有些报文过长的时候，的确会产生性能问题。

分析：

性能测试虽然模拟了峰值压力，但是没有使用真正的生产数据。测试数据中没有包含生产系统中比较少的那种情况产生的数据。在性能测试过程中，尽可能的选择与生产数据相近的数据或者直接使用生产系统复制下来的随机数据可以更有效的检出问题。

测试人员虽然测出了问题，且有一定几率重现，没有深究这个bug。其实如果没有太大的进度压力，应该推动开发同事找到根因，这在核心交易系统测试的时候尤为重要。大部分有一定规模的公司会有系统分级的定义，较高级别的系统，如果存在这样的“issue”是不满足测试出口条件的。

小强观点：

很多时候我们总被要求造数。。。。。其实一直以来我都不太赞同。一般我们造出来的数都是一定规则的，和真实数据分布是严重不符合，这样有些潜在问题很难发现。所以像我们做性能测试一般都是用线上数据（敏感数据做脱敏处理即可或者引流到线上做）

案例2：

一个新的功能上线后，发现存在收益漏洞，不得不暂时手工purge异常交易（还好有收益整合系统能及时检测出）。而这个收益漏洞产生的原因是：有用户使用了现行系统十几年前的一个边缘功能（早已无人使用）打破了现有业务的完整性。初步推断是从业的老手所为。

分析：

当一个系统复杂到一定地步（往往涉及多个子系统），不断修改、运营多年后，肯定会出现业务完整性被打破的情况。这种例子屡见不鲜，举两个我有清晰印象的小例子：还记得前几年联通玩的几百个套餐组合的营销么？因为控制不了复杂度，引发了好多bug，包括很多原有系统隐形bug，最后不得不草草收场。今年6月份我在一个中型电商网站上也亲历了这样一个bug，网站临时搞促销活动，做组合销售，买一本高折扣的书，搭配一本指定书籍后，折扣会加15个百分点。你选择指定书籍后跳转到到结算页面后删除被搭配的书，15个点的折扣还在。

如何解决这个问题呢？能想到的有这么几条方法：

1.对于历史遗留系统：定期找BA做业务完整性检查，梳理业务交叉可能带来的影响。这个其实挺难做的，对于大系统，豢养几个上下业务都精通的BA尤为重要。从外边找点儿外专帮助做业务渗透测试也是好办法，安全测试这么玩很有效，金融业也有这样的流动查漏队伍。看过史泰龙和施瓦辛格这两年拍的片子《金蝉脱壳》么？

2.大规模自动化回归测试也是一种不错的手段，当然回归测试的用例得专门有一部分是“场景测试案例”（我们一般叫做长流程案例或者业务端到端案例）。

3.采取某种业务建模的方法。如UML系列，BPMN，这两种东西都能够从一定程度上识别业务相关性，业务交叉点的信息，帮助测试人员设计出这种集成测试用例（有时候也叫兼容测试用例，关联测试用例）。

4.基于场景的测试分析建模方法，状态转换图法，基于模型的测试（状态转换图法是基于模型的测试的一种常见实现形式）都是很好的应对这种业务密集型产品滚动演进过程的好方法。

5.实时系统（飞控，机控），医疗设备，与钱相关的，超高访问量的，与库存相关的这样的系统应该把风险最大的区域做通透的测试，不然出事儿都不是小事儿。

小强观点：

说个稍微偏离主题的事儿，我经常碰到一些干了多年测试的朋友，他们经常会问我我现在就是功能测试，其他的会那么一点点，薪资还是不错的，没必要学其他技术了啊。这个话题我在很多场合都说过，现在是什么就业情况大家自己应该更加明白。这里我说下另外一点，那就是当你的系统复杂性越来越高的时候（比如，电商，不要觉得简单，一个完整的电商大生态是极其复杂的）我们要想减少bug，那只能利用技术的多样性来，你会更多的测试技能就会从不同角度、场景发现更多的bug，这就是你以后跳槽、加薪的价值。