软件测试培训
达内IT学院
400-111-8989
软件测试培训
Bug到底是怎么产生的？为什么就是控制不了？
- 发布：多则惑少则明
- 来源：51Testing软件测试网
- 时间：2019-03-07 18:04
相信每一个软件测试工程师都有一个疑问：Bug到底是怎么产生的?为什么就是控制不了?我们今天就来深入探讨、分析下这个问题。
产生bug的具体原因或许多种多样，但在bug原因分析过程中，希望能抽丝剥茧，找出其产生的根本原因。之前写过如何减少线上故障、典型故障分析、故障的坑，你踩了多少遍等等，如果能结合起来看线上、线下的bug，或许会对bug产生的原因有不一样的认识。
一、前后端使用架构导致
前端使用es7+react+node使用，在开发方面增大了工作量：
封装组件;
多个模块公用组件，导致改动一个功能点，改坏其他模块;对测试的影响就是，该一个模块，需要回归其他涉及的多个模块哦。
后端属于大数据基础上做各种条件筛选，在具体实现上采用了“重内存”方案，即：
1、将数据定时更新到内存中;
2、在内存中做多条件的筛选;
带来的问题就是：
1、 fullgc问题 导致需要大内存服务器;
2、定时数据更新机制，常常发现一个接口多次筛选返回的数据不一致;
二、开发人员经验问题/思维严谨性导致
此类问题和经验、或每个开发人员的合作、做事风格有很大的关系，具体问题包括：
1、前后端默认参数约定
2、前端传参
3、需求点没有实现
4、“显而易见”的主功能没有实现
三、业务特点导致
每一个业务除了公共的业务特点外，还有各自独特的业务特征。例如，前端业务与纯后端业务侧重点有很大不同，而APP端的前端业务与web的前端业务又有很大的不同。反应到具体产生的bug上，无论是bug的数量，还是bug本身的隐藏深度，都有很大的不同。
四、测试人员的经验缺乏导致
这里不必多说了，测试方案制定的完整性和深度，甚至测试执行层面的经验，都决定了究竟有多少bug可以被暴露出来了。
五、迭代周期不合理导致
这里涉及团队所有成员对迭代速度和规模的接受程度了。一个过度追求迭代速度的团队，整体上会牺牲一些产品质量了。
六、上下游业务严重耦合导致
这里举一个实际的用户实际使用场景先后涉及的业务方：
业务B--->业务A--->业务B
在这里业务A与业务B严重耦合起来了，导致在实际的项目中，测试业务A的同学常常非常被动：
需要业务B同学造若干场景，需要反反复复的沟通
数据来自业务B，而其测试环境非常不稳定，又需要反反复复的沟通
业务B的改动，需要业务A来回归，但业务A同学又没有比较好的途径了解其改动，只能“盲测”
在若干次反反复复的迭代中，记忆犹新的一件事情： 业务B修改了某个逻辑，结果出现了线上故障，却反过来问业务A的同学，为什么没有发现。这种哭笑不得的场景，或许是最为严重、切业务方不可控的因素了。经过反反复复的“血泪史”后，终于在一次架构调整中，把业务A归并到了业务B中了。
感谢您的阅读，以上就是对Bug到底是怎么产生的，为什么就是控制不了的相关解读，你了解了吗?如果我们可以严格把控各个环节，那么Bug将会被消灭很多哦!更多软件测试的相关资讯，尽在达内软件测试培训机构官网，敬请关注!
免责声明：内容和图片源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
预约申请免费试听课
填写下面表单即可预约申请免费试听！ 怕学不会？助教全程陪读，随时解惑！担心就业？一地学习，可全国推荐就业！
下一篇：软件测试真的不重要吗？
-
扫码领取资料
回复关键字：视频资料
免费领取 达内课程视频学习资料
Copyright © Tedu.cn All Rights Reserved 京ICP备08000853号-56 
京公网安备 11010802029508号 达内时代科技集团有限公司 版权所有
选择城市和中心
北京
黑龙江省
吉林省
内蒙古
河北省
陕西省
江苏省
上海
湖北省
四川省
重庆
湖南省
江西省
贵州省
云南省
广西省
广东省
海南省
台湾