好久没写东西了。人都是有惰性的，作为一个测试人员，应该定期的检查与反省自己，写些工作和生活总结。
今年没什么进步，该敲响警钟了。
测试代码都会分成以下几个部分：
* Caller
对开发接口函数调用的包装，使得案例有一个统一的入口调用开发的函数。开发接口函数变动，只需要变动我们的Caller。（封装变化）
* Checker
对接口函数调用的验证方式的封装。对被测函数的返回值检查是最基本的，更多的时候，返回值并不能告诉你一切，返回值告诉你它做了什么，但它没有证明给你看它确实做到了
* DataDefine
测试数据是必不可缺的，我将测试数据单独抽离出来，方便管理和组织。
* TestFixtureBases
TestFixture的基类，这是我喜欢使用的方式，定义某一类案例的基类，它们做同样的SetUp和TearDown，共享同样的函数调用。
* TestCases
最终到了测试案例这一分类，如果我们把上面的四个分类都做好了，就会发现，测试案例都可以使用一种非常简洁的方式来表达。在我看来，一个测试案例代码，五行左右代码是最优美的。
* （附加）CommonSpec
有时候，为了让测试案例更加容易理解，我还喜欢使用BDD的方式表述测试案例。因此，我个人可能还会有一个分类叫CommonSpec，定义的一些自然语言相关的函数。可能这个并不一定适合每个人。
5. 上周五去听了一个关于软件架构师的课程，总结一下大约有如下几点收获：
* 架构师首先要明白真正需要解决的问题是什么。例子：老太太买梨
* 一个优秀的架构师，必须有一套自己明确的方法论。
* 政治->经济->技术，架构师容易只看到技术上的问题，其实有时技术问题并不是最大的问题。
* 架构师是参谋长，也是辅导员。有了自己的架构设计，还要将自己的架构设计描述清楚，并推动设计方案的实施。
* （概念部分）架构师的定义，分类，架构设计的过程等等。
. 质量评估标准（淘宝）：
* 接口覆盖率是否达到要求。内部接口90%，外部接口95%。
过度要求高的代码覆盖率，可能会造成反面影响。
* 测试用例中对接口业务规则的验证是否完整。
关键词：业务规则，保证了业务规则，就保证了用户使用的大部分功能。
* 测试用例中是否覆盖接口之间的关联性测试。
* 遗留的 bug对系统的影响程度。
* 测试用例与测试代码是否一致。
1. 能一定程度上说明测试覆盖的广度。
2. 通过代码覆盖率结果，能够比较直观的了解到哪些代码未被测试，哪些分支未被覆盖，进而补充相应的测试案例。
3. 代码覆盖率具有非常好的可操作性，可以在一定程度上衡量测试人员的工作。
4. 代码覆盖率给程序员和测试人员以信心。
但是，即使你的代码覆盖率达到了80%或者更高，不要被代码覆盖率蒙蔽了双眼！
1. 好好回想一下覆盖的80%的代码中，你一共发现了几个Bug？
2. 剩下的20%代码，极有可能产生80%的Bug！
3. 覆盖的80%代码中，你真正进行验证的代码函数有多少？
4. 覆盖的80%代码中，你真正了解的代码有多少？或者说，有多少代码是无意间被执行的。
5. 你是否保证了不同操作系统下测试案例的执行？
6. 这80%覆盖的代码中，你是否偷懒省去了某些复杂的检查点的检查？
7. 你是否会因为某个分支只有一行代码，而省去这个分支的测试案例？
8. 你是否存在一个检查点也没有的测试案例？
看了上面的8条，再想想你的80%代码覆盖率，还会感觉测试已经完全，无事可做了吗？
代码覆盖率只是一个最基本的前提，一定要保证，但不是意味着达到指标就代表测试的完成。
永远要记住，80%的代码覆盖率也许只是刚刚开始，被测试代码中到底潜藏有多少Bug，谁也不知道！
我们主要通过CodeReview和自己的人品，并没有做太多严格的审核。
* 测试用例是否可持续回归。
* 经过测试的接口是否达到了调用方的标准，调用方能否使用该接口来开发出产品设计说明书所设计的应用。
