这是软件质量的第二篇，上一篇在这里，主要内容是，需求阶段要保证需求的可测试性，开发阶段要保证方案和架构本身的可测试性。
稍微复习一下核心要点。
对于软件的质量保证这件事情有三个原则是可以遵循的。
一件事情越早介入，发现问题和解决问题的成本越低
在成本可控的情况下，对测试目标进行高频次高强度的测试
永远有 Plan B
软件工程作为一项系统工程，缺陷并不是在测试阶段产生的，只能说是在测试阶段才被发现出来。但是历史证明，一个缺陷的出现，常常在设计、编码阶段，甚至在需求阶段就已经显露了必然故障的影子。但是产品经理不关注，开发人员不关注，把这一切都堆积到测试阶段，软件质量可想而知，数据必然是没那么好看的。从FB、Goolge 各个厂的质量保证体系的先进经验来看，其实各个阶段测试同学都可以介入，介入的阶段以及手段，也是很讲究。
需求阶段评估需求可测试性。
设计阶段评估架构可测试性。
编码阶段要求开发自测。
测试阶段进行工具化和平台化。
上线阶段进行预案和监控梳理。
日常阶段进行故障梳理和演练。
那么问题来了，什么样的需求才是可测试的？怎么权衡在需求阶段对于测试资源的投入？开发究竟要交付什么东西，才能让开发和测试都比较开心？
简单来说，我就是不想要bug，而且还要轻松。
我先说说结论，不想要bug而且要轻松的唯一途径，就是把不必要以及优先级不高以及描述不清晰的需求砍掉，需求寻找其他非软件方式的解法。
对于测试来说，开发交付的东西越全面越好，越清晰越好。能用图描述的就不要用文字了。能用结构化的文字描述的就别只写在注释里。能解耦开的东西就不要写在一起了。能使用现有成熟方案的，就使用现有成熟方案不需要投入大量测试了。
对于开发来说，无论其他人要求开发交付什么东西，开发都不会开心。毕竟开发除了代码其他都不想交付。（代码都写不完了还要其他？想啥呢）
但毕竟嘛，需求该做还得做，上线了出问题，大家都得背锅。需求阶段把这几个问题抛给你的产品经理，自己多想想，多问几个为什么，可以减少你非常多的扯皮时间。
这个一个面向用户还是面向汇报还是面向kpi项目？
这个需求背后的用户真正诉求是什么？
如果我是用户，我希望这个产品的形态是怎样的？
不做系统能不能有现成的方案解决用户的诉求？
这个需求真正实现需要怎样的成本？
这个需求是不是一定要现在做？
如果一定要现在做，还有哪些点是需要确定的？如何评估阶段性成果。
需求是不是已经比较明确了？包括需求的边界，产品的流程，系统的输入，系统的逻辑，系统的输出，团队的合作模式，已有技术或产品的可行性评估。
多想一下，你会有自己的判断，当然产品经理会非常讨厌你这样杠他，所以如果一旦有真正需要表达出你自己观点的场合，请务必带着你的思考和方案去 diss ，而不要只是笼统的我就觉得这玩意不行，还不够细，这不是用户的需求。也就是说，发言之前请掂量掂量自己的份量。
面向用户，精细做。
面向汇报，漂亮做，好看能跑就行。
面向kpi，砍到极致，能用就行。
至于开发同学应该交付什么东西，其实也是有一定的标准的。首先开发同学要保证自己接到来自产品经理的需求，是明确不含糊的，而且技术理论上也是可以实现的，才可以把任务迁移到自己身上。如果存在不明确的，请务必留时间让产品经理继续打磨再交付。如果技术还没有被证明可行的，请务必留时间让自己做好技术预研。
这个阶段应该要互相合作，开发做了一个demo，请马上联系产品经理验收和确认，多聊聊。产品经理有一个不得不改的需求，请马上联系开发稍微评估一下可行性和变动成本，如果确实紧急，马上按照需求变更规范进行变更。麻烦不要出现这种情况，开发永远只说这个需求做不了，产品永远只说这个需求很紧急。
这里有个 check list，开发同学在开发设计阶段必须要清清楚楚在自己电脑上写明白的，共不共享看测试同学的诉求。
1、细化到模块的产品流程文档
2、核心模块设计和系统架构图和业务模型设计。
3、核心系统交互流程图。
4、产品异常流程图以及对应的系统交互图。
5、外部接口对接文档的详细解读。
6、所提供服务的接口文档。
7、模块测试用例（测试同学帮忙）
8、数据库设计详细ER图。
9、系统水位预估，是否需要缓存、限流、降级。
10、上线 check list 梳理，部署顺序、数据库、回滚等
能做到这些的，说明你对于稳定服务的意识已经很强了，这时候交付给测试同学的代码内容，也是比较可信的内容。这么梳理除了质量会比较高之外，对于开发同学的开发效率其实也是一个非常高的提升，上面这些内容可能只会花掉你一到两天的时间，这比你将来花更长的时间定位问题处理故障，要好得多得多得多。
当然，如果是面向汇报和面向kpi编程，怎么快怎么来，反正项目死的可能性非常大，你别还没做出来项目就凉了，那就本末倒置了。
以上，下次继续聊聊测试工具化和平台化的事情。