俗话说”人无完人“，软件是人写的，所以软件不可能完美。这些不完美，叫软件“缺陷”。

先举个例子，保证都是“血淋淋“的亲身经历：

1.   某软件项目，由于合同时间点的关系，系统必须在某日上线，并让客户使用，此日期前很长一段时间开发工程师没日没夜的加班，由于过度疲劳和未详细测试，在编码过程中埋下了很多“坑”。到客户现场的培训过程中，客户使用软件后，说“你们应该给我的测试费，你们不光拿我们当小白鼠，还把我们当你们的测试人员”，对于在乎脸面的人来说，脸是火热的，心是***。

2.   汽车远程监控系统，车载数据采集设备，并用移动网络进行数据传输，设计预留15分钟的数据存储空间，就是说在没有移动信号的情况下最多存储15分钟数据，信号正常进行数据快速传输。在大多数情况没问题，但极端情况下比如汽车进入某些山区就会不止15分钟没信号，可能2小时或更长时间不会有移动信号，这种情况下导致15分钟后的数据丢失。

软件问题可大可小，小的是软件不能运行或浏览器出现错误。大的是造成非常巨大的经济损失和人员伤亡，可能是火箭发射不久的爆炸，可能是炮弹在在到达指定位置就爆炸导致人员伤亡。所以，软件的成败决定系统的成败。

什么是软件缺陷呢？

回答几个问题自己去总结什么是软件缺陷：哪些功能是需要的，但现在没有？哪些功能是不需要的，但现在有？哪些功能被遗忘了？你为什么不喜欢这个软件？只要是能回答出来就说明软件有缺陷。

1.   软件未实现产品说明书要求的功能：如果是瀑布开发模型，大部分不能百分百完成说明书上所有功能，当然没完成的原因可能有很多，客户不需要了、需求变更了等。这些没有完成的功能，必须要进行评审，哪些是必须要完成的还没有完成的，比如一些性能指标，或者一些非功能需求等。就像项目实施快结束时重新审核合同和技术协议一样。这是非常必要的工作。对于这类问题的解决方案是使用一些软件工具进行需求条目跟踪，自动显示完成比率，也达到时刻提醒的作用。叫需求“可视化”。

2.   软件出现了产品说明书指明不应该出现的错误：比较直接的就是软件bug，界面按钮没反应、页面出现大面积英文提示、功能不符合要求等。或者一些不一致，比如说明书要求显示10个字段内容，而最终显示了11个，其中一个是开发人员认为很有必要显示的内容，或者是没有核对需求说明书而导致的问题。这方面内容比较好理解，只要是不符合要求的就属于这类错误。这类问题的解决方案很简单，改正就好了。

3.   软件实现了产品说明书未提到的功能：举个例子，早些年的程序员，那时还是CS架构，好多人喜欢在软件中放“彩蛋”（非常态下才能出现的界面，比如关于窗口中，按住Ctrl+Alt+鼠标左键+鼠标右键，才出现的软件开发人员列表，可能还是个小动画。），这就属于未提到的功能。另外可能是在本次发布的软件包含了下一版本的软件功能。可别小看这个错误，程序员很喜欢根据自己的意愿去编程的，这种情况很常见。这类问题的解决方案是应用“代码审核”机制，这些事情不会出现。

4.   软件未实现产品说明书虽未提及但应该实现的目标：比如按钮反应超过3秒；某些执行时间较长的功能，没有进度显示等；Mac系统的浏览器不能正常显示软件界面等。这类问题也属于软件缺陷。这类问题需要软件测试团队协助，一是早期介入，测试驱动研发团队进行系统兼容性功能测试；二是最终交付软件产品代码的质量守护。

5.   软件难以理解、不易使用、运行缓慢或者从测试角度看最终用户会认为不好：软件界面用词，不应该是技术语言，而应该是业务语言，是软件用户易理解的言词。软件操作步骤过于复杂。软件运行一段时间后，系统运行异常缓慢。还有多数据显示界面里把相关联数据分成两页显示，用户使用起来不方便等。这类问题很常见，又是用户体验的重要部分，不容忽视。这类问题解决方案是小批量适用，根据反馈意见酌情进行修正即可。

最后提醒注意，不是所有的缺陷都要修改。让所有人都满意的软件是不可能的。对于用户体验问题一定要全面客观地评价。最终交付近乎完美的产品。