重读《软件测试的艺术》

能静下心来看本好书真是一件爽爽的事情

简单记录以下书中的新颖有趣的观点。

• 软件测试是为发现错误而执行程序的过程

有趣的观点，因为程序员总是会正向思考问题，使用过程觉得程序就该这么用，谁知道用户却是那么用，别以为用户很聪明，用户会按照产品的设想去使用产品。

因此遵循这一点，测试工程师在进行测试过程中应该带着这种心态去开展测试工作，相信程序一定存在bug。心理学研究表明，当一个人觉得某项任务可以完成时，工作进行会更好，并且信念可以支撑做的最好。

• 成功的测试是发现错误，并且错误可以修复

很多人本末导致，认为执行测试用例过程中未发现错误就以为是成功的，其实是错误的。理论上来讲，一个大型程序是找不完的bug的，只是有些bug太隐蔽、太轻微、或者程序可以自修复。（以手机项目为例，MTBF测试需要测试7天7夜，感觉就像一个轮回一样，这种高压稳定性测试，往往能暴露出很多隐藏问题）。再类比去医院看病，花了不少检查和化验费用，医生却未诊断出任何病因，病人就会质疑医生的诊断能力。

代码检查、走查与评审

要点：

1、测试人员要懂代码，（看得懂最好）能够总结出一些常犯错误：编码规范、逻辑

2、会议过程中对事不对人；（对于自己做的东西人都喜欢捂着，怕犯错）

3、会议由开发人员宣讲代码逻辑过程，人数控制在3～4人， 时间控制在半小时（会议越长越低效）；

4、过程中，意识到问题最多的可能就是代码编写人本身，在宣讲过程中自己就意识到问题；

5、过程中发现的错误不是代码作者的弱点，而是伴随着软件开发过程中艰难性固有的。

6、代码虽说是给机器执行而编写的，但也需要提供给人阅读；

好处：

1、提高研发人员水平（做到对事不对人，不然后果很严重，此点变成缺点）；

2、提升软件质量，错误发现越早，改正错误成本越低，正确改正的可能性越大；

3、提升团队凝聚力，多相处聊聊开发关系更好，大家互相信得过；

4、比之前代码review更好（指定reviewer），两人互相，其实缺乏促进效应、竞争气氛、表现机会，人民都喜欢发现问题来展示自己能力。

5、更好的熟悉工程代码，能快速上手他人模块；

缺点：

1、搞不好容易背道而驰（对事不对人，不要有人格攻击，或采取防范态度），应该提出建设性建议（会议主持者应该提出制止此类态度），管理人员不要参与过程利用检查结果做考核；

2、占用4 乘以 0.5 时／人 甚至更多，但是不是根据时间就会拖慢团队进度，还真不一定；

3、waring：估计有程序员会有晕车现象，尤其是新人，会有强烈不适应这种撕逼过程，所以先小范围开搞实施；

4、科学的review，减少大家压力，后续稳定下来可以抽查，看情况；