1. 什么是Bug
Bug，指软件中的缺陷，它可能会引发软件失效。
关于软件中的缺陷被称为Bug，即虫子，这是有一段故事的。在早期的计算机中，常采用大量的继电器，用继电器的开合来表示二进制。马克二型计算机就是这样的。1945年9月9日，下午三点，马克二型计算机无法正常工作了，技术人员试了很多办法，最后定位到第70号继电器出错。负责人哈珀观察这个出错的继电器，发现一只飞蛾躺在中间，已经被继电器打死。她小心地用摄子将蛾子夹出来，用透明胶布帖到“事件记录本”中，并注明“第一个发现虫子的实例。”自此之后，引发软件失效的缺陷，便被称为Bug。
2. 能做出完全没有Bug的软件么？
很抱歉，答案是不能。
任何软件都有缺陷，这是软件测试领域的一个真理。
在软件质量标准中，软件的可靠度用R(t)表示，它表示在指定的运行条件下，软件在规定的时间内不发生故障的概率。
一定有R(0)=1，即软件在初始运行时刻一定是无故障的，否则说明软件还没有开发完成，尚不能运行。一定有R(+∞)=0即任何软件都是有缺陷的，在无限长时间运行后一定会发生故障。
3. 在故障原因上，软件有何特点
与我们常见的桥梁、楼宇、手机、文具等各类实体产品不同，软件有一个非常重要的特点：它不会因为复制、运行而发生衰退。
毕竟软件不会生锈、老化、分解等。这算是软件的一大优点。
因此理论上，我们可以通过不断的投入测试成本来降低软件发生故障的概率。但即便如此，软件的故障概率会趋向于0，而永远不会等于0。
况且，在现实中“不计成本”这种事情是不会发生的。
现实中的软件往往存在大量缺陷，其一大原因是因为软件的复杂性。具体可能产生bug的因素会在下节讲。
软件测试十分必要。但是要记住一点，软件测试不是为了清除软件中的bug，而是减少软件中的bug。
4. Bug是如何产生的？
这就回到了我们问题的重点，Bug如何产生。
接下来我们按照软件的生命周期顺序一一介绍。
A: 需求错误–未知需求
问：这个软件为什么不能上传Excel导入数据？
愣：开发前你有提到过说要用Excel导入数据么？
B：需求错误–未理解需求
问：这个软件为什么按钮文字上没有拼音？小朋友不认识字啊？
愣：啥？小朋友？啥？拼音？
C：设计错误–模型选择错误
问：这两个操作能不能一起执行啊？
愣：坏了，选的是责任链模式，不支持并行啊！
D：设计错误–模式选择错误
问：再接一个输入源好不好？
愣：没采用适配器模式，不好改啊！咋办？
F：设计错误–框架选择错误
问：好，那我们去手机端看一下页面。
愣：完了，选的框架不支持动态适配。还看啥啊，界面一定乱了！
G：设计错误–并发不达标
问：为什么人少的时候可以，人一多就会停止服务？
愣：坏了，当时没考虑这个问题。
H：设计错误–兼容性不达标
问：我们升级了一下别的应用，它就不工作了。
愣：坏了，写死绑定那个应用了，那个应用不能升级啊。
I：设计错误–容量不达标
问：数据一多，就存不进去了。
愣：坏了，设计的容量出问题了。
J：开发错误–外部依赖缺陷
问：这个地方报错了。
愣：妈蛋！引用的开源包有问题！
K: 开发错误–死循环
问：点一下就死机了。
愣：我看看，你这么输入的啊……那，坏了，触发死循环了。
L: 开发错误–越界
问：数个空格进去，就报错了。
愣：坏了，空格被忽略了，但是计数器没调整，肯定越界了。
M：开发错误–异常未捕获
问：没网络的时候，点一下就死机。
愣：坏了，有异常抛到了最上层。
N：开发错误–IO未关闭
问：重启完机器就正常了，过几天就没响应了。
愣：搞半天，每次操作都忘关IO了，导致socket被耗尽。
O：开发错误–空指针异常
问：突然就死掉了。
愣：原来是，文件没找到，报了NullPoniterException。
P：开发错误–变量混乱
问：输出的结果，驴唇不对马嘴。
愣：我去，变量wife和wifi用混了。
Q：开发错误–手误
问：为什么显示“下楼好”？。
愣: 奥，输错了，应该是“下午好”。
R: 开发错误–日志未关闭
问：硬盘被打满了！
愣：是不是正式版忘了关调试日志?
S: 开发错误–内存未初始化
问：第一遍运行正常，第二遍就有乱码。
愣：难不成，变量没初始化？
T: 开发错误–类型转换异常
问：全数字的身份证号是没问题的，一输入后面带字母X的就报错。
愣：坏了，把身份证号当数字处理了。
U: 开发错误–颜色设置错误
问：为啥他登陆后名字是绿色的？
愣：奥，错了，应该是背景是绿色的，弄混了！
V: 开发错误–忘记屏蔽
问：为啥她能看到我的密码？
愣：我去，大问题！忘了脱密了！
W: 使用错误–忘记插线
问：为啥鼠标无法操作？
愣：我去，你鼠标线都没插。
X: 使用错误–输入错误
问：为什么总是说信息输入错误？
愣：你为什么在“姓名”栏位写个“男”
Y: 使用错误–理解功能错误
问：为啥你的软件不能显示附近的人?
愣：这是外卖软件……约人的活真干不了。
因此要想保证软件的正确，必须保证需求、规划、开发、使用各个环节都正确。这，太难了。
可见，软件开发者不容易。
写一个成功软件的道路没几条，而写一个失败软件的道路数不清！
要不是英文字母不够了，还能列举下去！
Z: 使用错误–操作失误
问：为什么不能点赞？
愣：你点了么？再点一下试试！
