昨日下午，团队内的数十位专业人士齐聚一堂，以线上方式召开了一场关乎重大线上事故分析的会议。会议的焦点在于深入探究近期线上事故的原因，并针对这些问题寻求有效的解决方案。
在金融软件领域，每一次线上事故的发生都可能给公司带来无法估量的损失。无论是少扣或多扣用户的资金，都可能引发公司的资金亏损、不必要的合约纠纷或法律诉讼。金融软件的线上bug的重要性远超过其他行业的软件。在金融软件中，不存在所谓的“小bug”，任何bug都可能引发重大的问题，必须引起高度关注。
有句古话说得好，“人非圣贤，孰能无过”。软件亦是由人所编写，难免会出现问题。我们的目标在于尽可能避免这些问题的出现，尤其是重复出现的问题。对于软件测试人员而言，分析线上bug是一个极为重要的环节。通过深入分析，我们可以找出测试人员在测试过程中的疏忽之处，从而提醒他们在未来的测试工作中扩大思考范围，尽可能全面覆盖测试内容。
线上bug的出现，多数是由于开发者和测试人员的疏忽所致，并非不可避免。经过深入分析，我们发现线上bug的出现原因主要有以下几点：
一、开发人员在使用Java框架时存在错误。例如，某开发人员在利用多线程时误将多例当作单例使用，导致系统在处理高并发时发生数据混淆现象。尽管使用单例有助于节省资源和降低系统占用率，但在当前系统架构下并不适用。这种情况在测试过程中难以被察觉，必须在实际的数据高并发环境下才能发现。针对这一问题，解决方案在于调整技术策略，将单例改为多例。
二、开发人员在合并代码时存在遗漏。例如，某开发人员在合并git分支代码到master时，误删除了master中的某行代码，导致某个功能失效。针对这一问题，解决方案包括在合并代码时创建一个新分支，将master上的代码与新分支合并后的代码进行对比和审查，确保无遗漏。建议开发人员建立良好的习惯，定期将master上的代码合并到个人开发的分支上。
三、测试人员进行回归测试时存在不全的情况。这相当于一定程度的漏测，主要是因为测试人员思考不全面导致的某些方面的遗漏。为了解决这一问题，我们强调回归测试的重要性，要求测试人员在回归测试时不仅要关注主流程，还要关注与修改bug相关的代码部分。我们提出了几个具体的解决方案，包括强化回归测试的步骤和流程、确保业务流程的完整性以及提高测试过程的细致度等。
四、在多系统同时上线时，联调过程存在问题。为了解决联调过程中的问题，我们需要加强联调前的准备工作和联调过程的审查力度。考虑到当前系统的成熟度不足、改动频繁以及业务流程和需求的不稳定性，我们暂时无法引入自动化测试。为此，我们需要探索更为有效的手动测试方法和技术来确保联调过程的准确性和稳定性。公司业务涉及多个复杂系统间的交互与接口调用，其中测试人员在模拟系统交互时，经常借助mock来模拟返回或回调。尽管这种方法在测试中十分常见，但由于模拟返回并非真实系统反馈，联调测试时稍有不慎便可能埋下隐患。
联调测试的重要性不言而喻，因测试人员的疏忽，对联调内容的遗漏，往往导致业务上线后的一系列问题集中爆发：
1. 查询任务调用时，对方系统持续反馈“处理中”，致使整个流程陷入僵局。
2. A系统与B系统之间的回调失败，竟是因为编码方式的不同导致的沟通障碍。
3. 某系统一旦功能故障，其查询接口便无法正常工作，报错连连。
4. 调用某系统时，期望获得code=1的返回，却收到code=0的错误响应，导致业务处理完全偏离预期。
诸如此类的问题，大多源于系统间的调用或回调环节在实际操作中的线上bug。那么，如何避免这些隐患呢？以下是一些解决方案：
1. 在联调之前，务必完成自己系统中本次项目的所有用例测试。
2. 编写详尽的联调用例，并与各方测试人员充分沟通，确保用例能全面覆盖业务流程和各项任务。
3. 联调过程中，必须验证所有业务流程的畅通性，以及返回值的准确性。
联调测试与常规功能测试的重点和关注点存在明显差异：
1. 联调测试的核心在于确保业务流程的顺畅。
2. 联调测试时，需严谨核查其他系统返回的数据是否正确，以及相同数据在各系统的值是否一致。
3. 还需检查报文的mapping是否与其他系统接口文档中的完全一致。
此次线上BUG分析再次警示我们，程序中的bug往往源于人为的疏忽。为了避免这些情况，开发人员在编码过程中需养成良好的习惯，而测试人员在测试设计时则需全面考虑，避免遗漏任何测试点。对于任何不明确的地方，无论是开发还是测试人员，都应积极讨论、交流，杜绝闭门造车、不懂装懂的现象。
在此也想问问大家，你们的项目中是否也发生过一些让人痛定思痛的重大事故？不妨分享出来，让我们共同引以为戒，共同学习进步。 |
