认识达内从这里开始

软件测试一直以来都是软件开发项目中不可缺少的一个环节，而我们在做测试的时候也会发现各种不同的编程问题，今天我们就通过案例分析来了解一下，软件测试常见问题与解决方法。

一、项目初期发现bug数量多，修复率低，上线频频延期

团队初期由于项目节奏比较快，项目组成员不是在评审，就是在评审的路上，几乎每天都有各种项目相关的会议，大家都在赶项目上，而忽略了项目过程遇到的流程不健全的问题，具体点就是没有要求开发冒烟测试，开发自测完事后走一遍流程就提测了，而测试过程发现缺陷比较多，而且reopen的缺陷比较多。

当然，针对缺陷比较多的问题，我们自身也进行了缺陷分析原因和归类，大致有以下几类：

需求问题产生的bug，需求设计不合理，而直到测试阶段才发现问题

开发实现和需求不一致产生的bug

开发自测打马虎眼，对bug睁一只眼闭一只眼

开发新人对产品功能不熟悉

环境问题导致的bug

二、测试过程发现了需求之外的缺陷如何处理?

随着业务压力越来越大，老板也给我们很对外包招聘名额，后续团队陆陆续续增加到7人，其中6个外包，当然并不是每个项目都是6个人一起上，而是将其划分了3、2、1的模式，其中3个人cover一个较大的项目，2个人cover较小的项目，1个人是自由人，主要承担线上反馈问题处理以及随时补位。较大项目一般2周发布，小项目一周一发。由于两条项目线并行的问题，这样就出现了A项目的测试同学负责的项目发现B项目测试同学负责过的版本存在遗漏的缺陷，而对这种问题，我们分情况处理：

如果测试过程发现历史缺陷，产研测会将此问题抛出来，评估严重程度以及修复成本。(1).严重程度决定是否修复;(2).修复成本用于评估额外的项目成本是否对项目整体造成延期的风险。

如果缺陷比较严重，修复成本比较高，则会延期修复。

如果缺陷不严重，则根据开发测试意愿自己决定是否修复。

如果A小组负责项目上线后，发现了B小组测试的项目版本出现缺陷，则缺陷责任人属于B小组测试人员。

三、开发过程需求经常变更

你是否也遇到过类似问题，开发实现的产品和交互设计的不一致?问了开发原因才晓得是产品单独找开发更改需求了。。。

当然并不是说需求不能变更，需求问题在任何公司，我想都是不可避免的。因为随着系统复杂度的不断提高等原因，产品同学确实不太容易考虑完全。

该问题也比较常见，对项目的影响：

提测前需求变更，导致开发过程不流畅，且会存在设计变更的风险，缩短开发时间，影响开发进度及项目质量。

提测后需求变更，影响开发新版本的流程及开发修复bug时间，影响QA的测试进度。且需求变更容易引出新的问题致使项目质量不可控。

需求变更直接影响是，增加项目不确定性风险。

解决方案：

针对需求问题，我们通过以下措施去推动解决：

硬性要求，需求变更必须通知到研测，三方共同拍板，并重新评估项目排期。

测试角度，产品同学提前发需求文档，鼓励测试同学在需求评审的过程参与需求测试，多思考异常场景。

产品角度，避免需求文档中出现不确定、同上等模糊不清的说辞。如变更需求，PRD应及时更新要有变更记录，避免口头变更。

开发角度，避免盲从产品变更需求，应三方确认后，重新更新技术方案，如有必要可以重新技术评审。

如未告知测试进行需求变更，测试有理由拒绝测试。

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销，赚更多好礼。