你们系统真烂。
多么简单的一句话，一个系统故障可以把很多很多同学的全部心血付诸东流。这个时候经常是互相甩锅的时候。
甲方爸爸：你们怎么搞的？你们今天必须给我一个交代。
老板：怎么搞的？问题出在哪里？赶紧给我解决。
测试：开发的同学赶紧看一下啊，什么原因。
开发：测试 TMD 的没测试充分，出问题又要我背锅。
产品：开发真不靠谱，这点小需求这么多问题。
流程：嗯，我再增加个发布卡点。
很多时间，测试同学就是这样测试。用鼠标点着屏幕，或者用着手对着屏幕戳戳戳。测试同学忙得要命，很认真很负责，但是很遗憾，故障依然居高不下，开发依然要时刻背锅，甲方爸爸依然骂。肯定是哪里出了问题。
对于软件的质量保证这件事情有三个原则是可以遵循的。
一件事情越早介入，发现问题和解决问题的成本越低
在成本可控的情况下，对测试目标进行高频次高强度的测试
永远有 Plan B
软件工程作为一项系统工程，缺陷并不是在测试阶段产生的，只能说是在测试阶段才被发现出来。但是历史证明，一个缺陷的出现，常常在设计、编码阶段，甚至在需求阶段就已经显露了必然故障的影子。但是产品经理不关注，开发人员不关注，把这一切都堆积到测试阶段，软件质量可想而知，数据必然是没那么好看的。从FB、Goolge 各个厂的质量保证体系的先进经验来看，其实各个阶段测试同学都可以介入，介入的阶段以及手段，也是很讲究。
需求阶段评估需求可测试性。
设计阶段评估架构可测试性。
编码阶段要求开发自测。
测试阶段进行工具化和平台化。
上线阶段进行预案和监控梳理。
日常阶段进行故障梳理和演练。
[可测试的需求]
很少有测试同学从需求阶段就开始介入，往往都是到了设计阶段甚至测试阶段，才发现这个需求本身就没法测试。
比如这样的需求：
生成一个随机数
响应时间要快
实现一个登陆功能
上面的需求基本是无法测试的，那么怎样的需求才是可测试的？或者说合格的需求，应该具备怎样的素质？合格的一个需求，应该至少具备下面五个特质。
一致性、完整性、无歧义、可量化、可操作
一致性：一样的输入，理论上应该要有一样的输出或者可观察的表现。如果一样的输入永远有随机性，那么是不可测的。（比如生成一个随机数这个事情，基本就不可测试）
完整性：一个需求是完整的，是可以逻辑自洽的，不缺少某些核心需求描述。（比如，实现一个登陆功能）
无歧义：一个需求描述不应该是歧义的，一个描述永远只有一个解释。（比如，给每个用户的优惠券，能给多少给多少）
可量化：可测试的需求都需要是可以数字化或者可被明确观察的。（比如，这个网页响应速度要快）
可操作性：理论上和实际上都具备可操作性，而且是成本可控的，如果只是理论上可行，实际不可行或者成本太高，那么也是不可操作的。（比如，实现一个精确计算中国平均年龄的算法）
从需求阶段就介入，是提高一个软件质量，减少被甲方爸爸骂的最好的时机，也是很多测试同学忽略的时机。但这个阶段需求可能变化比较大，如果测试同学过多介入的话需要投入比较多的精力，这就需要产品经理和开发同学本身比较靠谱，这也是后面要讲可测试组织的原因。
[可测试的代码]
需求阶段ok之后，其实就把接力棒交到了开发小哥哥手上了，当然这个阶段测试同学就不好自己把需求代码实现了吧。这个阶段测试同学要做的事情呢，可能是要介入到开发小哥的方案设计上，并且给开发小哥列举好需要自测的列表和标准，在移交给测试同学之前必然要有一定的代码质量把控。
我们通常从以下几个方面来描述一个技术方案的可测试性：
可控制性：是否可以将待测系统的状态控制到如测试条件要求。
可观察性：是否可以观察（中间或最后的）测试结果。
可隔离性：各个模块是否可以隔离测试。
关注点分离：各个模块是否有单一且清楚定义的任务。
易懂性：模块本身是否有说明文档，或是本身可读性很高。
可自动化性：模块是否可以进行自动测试。
异质性：是否需要不同的测试方法及工具平行测试。
虽然能否写出高性能的优雅的代码，那是开发小哥哥的事情。但是否能写出可测试的代码，这可能是比较高级别的测试同学需要密切关注的。毕竟，方案如果设计得烂，代码如果写得烂，你怎么测质量都不会好到哪里去。
想想在测试阶段是这样的情况。
[昨日进度:待解决缺陷130个]
[今日进度:解决缺陷50个，待解决缺陷230个]
欲哭无泪...
今天就先写到这里吧。。。太长了，后面有空再聊有空再继续聊，再会。