说在前面
每当你和团队完成了一款软件产品的开发，是否很容易被问到这样一个问题：质量怎么样？或者是能上线发布吗？如果你是团队的负责人，你会如何回答这样的问题呢？对软件质量的评判标准，不见得所有人都是同样的看法。质量要求的标准可能各不相同。本文聊聊软件质量的事情。
谈谈质量评估的依据
重温了下《软件测试》（美，Ron Patton著）的部分章节，那位佛系年长教授给我的印象至今依然十分深刻，他当时说：软件测试是一种非常有意思的事情。现在想来他老人家是通透明了了。针对软件中的问题，本文不在名字上过于计较，统称“缺陷”。算作读后感吧，加入自己的理解，我总结了一些要点。
高标准没有错，这是一种理想和信念
软件质量不能出任何问题，你要找出所有的缺陷，并修复所有的问题。上线后不允许出现任何重大问题。
上述要求有错吗？合理吗？当然没问题，必须有这种要求的，这是一个完美的目标，是所有团队梦想追求的结果，这个方向是没有错的。有些项目甚至是苛刻的要求，我国最近接连两次的卫星发射失败，就是惨痛的教训。
但终归要认清现实
你无法找出所有的缺陷。你可以说自己找到了一个缺陷，但你不能说缺陷不存在了。程序员买苹果的段子，测试计算器软件的例子，等等......直接说明了程序设计工作的复杂性，这也直接导致了针对软件产品做“完全测试”几乎变成了一种空想。你所运用的任何测试方法，都会存在不同程度的取舍，比如删除一些重复的、无必要的用例等。出现了取舍，就代表着引入了风险，那种无法发现所有缺陷的一个风险。
你无法无限期的测下去。每个项目都有一个最优的测试量。试图过度的投入，会导致项目成本大幅增加。大多数情况下，缺陷数量达到一定程度后，不会再发生显著变化。我们的目标应该是找准最优的测试量。如果你的项目真的不计时间，不计成本，那就可以一直测试。但任何产品的研发，都是有周期要求的。
任何人都没有发现的缺陷，算不算缺陷？
如果这个问题很难回答，那我们就思考下另外一个问题：一棵树倒在森林中，如果没有人听见也没有人看见，那它发出声音了吗？答案显而易见了。我们可以称呼这种无人发现、也没有现身的缺陷，叫潜在缺陷。
真的不能开发出无缺陷的代码吗？
- 程序员是一个个非常主观的人，他心情可能不好或能力不行，写了缺陷可能不自知。
- 程序设计其实是主观题，答案不唯一，很难有满分。
- 就算刚开始真的做的很棒，无可挑剔，但耐不住变化太多。唯一不变的就是变化，这句话已经不像是在开玩笑了。
- 有些缺陷可能让你觉得无所谓，不值得。但他有时可能只是表面现象，真实的问题会让你如坐针毡。
缺陷没有清零，就是质量欠佳吗？可以上线吗？
并非所有的软件缺陷都要修复，比如这些：
- 不算真正的缺陷；
- 修复的风险太大的；
- 不值得修复的；
- 没有足够时间修复的，交付日期逼近；
- 其他一些原因，被认同可以不改的；
这些都要根据各项目的管理制度和规范，寻求团队自己的商业风险决策。之所以称风险，想必也是只有时间才能验证这样的决策是对的，还是错的。这是普遍的一个现象，会让团队或者决策层甚至产生非常不适的体验，这时往往需要团队自上而下的一致团结。除了团结，测试相关的流程和数据，是要严格考察的。
很多团队都会有这样的要求，在交付或上线前，缺陷必须清零。但往往那也只是表面上的清零，往往那些遗留的真正问题，并没有得到解决，只是以另一种形式消失不见了。这不是一件值得高兴的事情。如果你的团队做到了真正的清零，那真的很优秀，很难得。但你也要对潜在缺陷有一定的心理准备和团队级别的应对处置方案。
最后还有一个陷阱，不得不提：
产品说明书或者叫产品文档，就是真正的需求吗？它一定都是正确的吗？
- 文档里是否就是需求，你一定有渠道或办法去确认！
- 需求是正确的吗？你一定有方法或思路去验证！
尝试用正确的需求，去做产品研发。坚持下去，你一定会受益匪浅。
尽可能降低出错的概率
虽然不可能发现所有缺陷，但我们仍然可以去不断探索各种技术和方法，去尽可能的提前找出错误，甚至避免错误，降低生产环境出错的概率。
- 创造好的环境和空间，让你的程序员越来越靠谱；
- 养成问题复盘和分享的习惯，让团队持续成长；
- 让每个人都明白：逻辑严谨的重要性和必要性；
- 让每个人都明白：何时有必要发起评审；
- 引入必要的工作流，提早发现问题；
- 引入专业的测试团队，专职服务于产品研发；
- 提前验收，尽早验收，多次验收；
- 能想到的测试方法和范围，尽可能做（功能、性能、压力、疲劳、容错、安全等等）；
- 尽可能找有测试天分或责任心的测试工程师；
- 越早结对代码评审越好；
- 保障最低限度的同行代码评审；
- 了解行业动态，同行交流，持续完善方法论，形成良性反馈闭环。