《完美软件》章节试读

《完美软件》的笔记-第169页

狗食测试他们编写轿车上的控制刹车和转向系统用的嵌入式软件，在发布软件之前，每个和开发该软件有关的人都要在一条测试道路上以每小时100英里的速度驾驶一辆使用该软件的轿车。

《完美软件》的笔记-全文 - 全文

第1章 进行测试的原因
不可能有完美的软件，而测试也不可能做到覆盖率100%，但测试可以提供降低风险的信息。人不是完美的，因此编出的程序也必定是不完美的。我们只能做到力争完美，测试实际上更像一种心理行为。
经理的职责是做出管理决定，而不要问测试人员诸如“软件可以交付了吗”这类本该由经理自己决定的事。不要相信测试可以改进产品，测试只是发现问题，产品质量和完善归根结底是开发人员的工作。
第2章 测试无法做的事
人们都存在一种感情倾向，不希望发现自己犯了错误。那么，建立一种奖励出现缺陷数量较低的开发人员的制度，并不一定能刺激他们写出更好的代码，肯定会有一些开发人员故意隐瞒错误和增加同测试人员的冲突。
几种常见的错误：
1.不尊重测试人员；
2.过度尊重测试人员；
3.让测试人员当替罪羊
4.忽略通过测试得到的信息，或对测试数据背后隐藏的问题不关心、不清楚原因。
作为经理，首先应对测试有足够的了解，而不允许经理们以不了解测试过程为借口允许缺陷通过。否则应任命专职的测试经理。
第3章 不对所有可能性进行测试的原因
任何测试用例集都是一种采样方法，无论你有多少资源，都要尽可能选择那些具有最强代表性的测试集。如果不得不减少测试资源，那么应该同时减少测试集的规模，否则代价就是测试质量的降低。获取性价比高的采样集是一种经验和直觉，需要经历过较多的实际产品测试才能获得。
第4章 测试和除错的区别
为定位错误做出时间计划是比较难的，但是可以根据经验为一个功能的测试预估一下可能花费的时间，同时测试人员也应该有一个上限时间——如果一个功能花费了太多时间做测试，应该考虑一下性价比的问题了。
任务切换是最浪费时间的。考虑以下场景：4名开发人员，4个产品，均为2周一次迭代（每个产品的起止时间不固定，一般在迭代开始的计划会议和结束前的回归测试是比较耗时的两大块。应该如何分配测试人员？
测试人员的主要工作是发现问题，而定位问题主要是开发人员的工作。对于不易重现的错误，测试人员如果花大量精力去重现是需要投入大量精力的。经理应权衡，比如有些无法复现的bug，可以在以后的迭代中持续跟踪，但不要刻意去测试重现，而是在日常测试中留心是否重现。
第5章 元测试
以下情形有些虽然听起来像是笑话，但它们确实发生在某些组织中：
我们有详尽的测试说明书，但是找不到了，或者找到时发现落满了灰尘；
我们无法进行测试，因为测试系统被40000多条bug记录搞瘫了；
（十天后）我还没有完成这个产品的测试，而是对XP系统进行了全面的测试，因为我发现一个小bug可能是XP系统的原因；
我们运行了60万个测试用例，系统中没有出现崩溃，但其详细的测试结果我们根本就没有时间看；
我们解决了测试人员提交的bug，但我们没有反馈给他们结果；
我没有报告缺陷，所以开发人员不会对我发脾气，我们将继续和平相处下去；
第6章 信息免疫
信息是中性的，但是人们对信息做出的反应很少会是中性的。要对测试信息进行评估，就必须考虑人们的情绪防卫措施：
我们在生存规则收到威胁的时候会感到害怕；
我们压抑无法接受的事物；
我们让不可接受的事物合理化；
我们将自己的负面品质投射给其他人；
我们转移指责从而免除自己的责任；
我们对自己的不足进行过度补偿；
我们在觉得失去控制时开始出现强迫。
第7章 如何应对防卫反应
指责某人具有防卫性是在讨论中让某人的观点边缘化的常用方法。不要玩这样的花样，这样做会破坏信息。
不要将对方的行为定义为防卫性的，但是按照它是防卫性反应来对待，看看它是否会在一些温和的测试下表现出来。
对待不同人的防卫反应，需要因人而异。
不要用对别人说他们不关心质量：要引导和教育他们而不是侮辱他们。
第8章 良好测试的要素
测试是否覆盖了产品最重要的部分。
测试时不了解产品内部结构或过于了解内部结构，不如介于二者之间的效果好。
测试人员的时间应主要用于测试设计和执行，而不要把过多的时间浪费在安装配置、缺陷调查和报告上。
很多谬论和弄虚作假的行为都可能扭曲测试，经理们对待测试应专心和好奇，做到明察秋毫才能改善此情况。
对待自己开发的产品，应保持专心和好奇。尤其是测试时，更不能讳疾忌医，多一些怀疑的态度总是好的。近期的一些经历也说明，产品经理必须有这种态度，不能太“爱惜”自己的产品。
第9章 有关测试的主要误区
指责 误区：某个人花在寻找用来指责的其他人上面的时间和精力越多，解决该问题的可能性就越低。同时，指责很具有传递性。此外，指责也许能带来短期效果，但是它带来的长期后果可能不是有益的。
认为可以采用“投机取巧”的开发软件，然后通过测试提高质量。质量是整个开发过程的产物，不良的测试会导致不良的质量，但是良好的测试并不一定能导致良好的质量，除非整个开发过程的其他部分都是恰当的并且得到了正确的执行。
系统测试不仅不能捕获所有缺陷，反而会花更长的时间和更多的成本，其性价比远远低于单元测试。当然，也不能完全依靠单元测试，必须辅以系统测试。
第10章 测试不仅仅是敲击键盘
未能“吃自己的狗粮”：如果你对自己的产品都感到担心或者鄙视，别人又为什么要买它？同时，也要避免狗食测试中只使用不具代表性的“狗”：除非是在开发软件开发工具，否则完全由软件开发人员构成的样本不太可能代表整个用户群。
假装演示就是测试：你既可能是做出这种行为的人，也可能是接受这种行为的人。没法说哪种做法更糟——欺骗别人或者欺骗自己。
第11章 信息摄取
萨提亚交互模型将任何沟通都分解成四个主要的阶段：摄取->确定含义->确定重要性->做出反应
以软件交付日期为例，如何避免沟通时双方对信息含义理解的偏差（或者说各自的倾向性）：
1.只采用书面形式给出和接受某个日期；
2.不要给出或接受“点日期”比如“9月1日”，而是只给出和接受以范围形式写出的估算的日期。
如果你发现别人更愿意接受另一个人转述你要传达的信息，不妨想一下自己以前做过什么让大家认为我不是一个可靠的来源？我将来要做些什么来提高他们对我作为信息来源的信任？
如果要对缺陷进行分类，可以遵循以下原则：
（1）只使用四个缺陷报告类别：0～3级
0级的问题会阻碍其他的测试
1级表示如果该问题没有解决，那么产品就不能交付
2级表示如果该问题没有解决，产品的价值就会显著地降低
3级表示如果产品交付时有大量类似的问题，该缺陷才是重要的。
（2）为任何一个缺陷报告分类的时间不能超过一分钟，否则就给他一个临时的“0级”类别并放到一边。（可以使用番茄定时器）
（3）如果时间允许，对临时的“0级”缺陷报告进行重新检查，时间一般每个不能超过5分钟，否则就将其转给更了解到人以获得更多信息。
金象综合征：一头白象也许是一件大而无用的东西，但是如果它是金子做得而且花了很多钱，就会诱惑一些人无论如何都要想办法用它。如果昂贵的测试工具设计有问题、不可靠，或者迫使测试人员只是为了适合该工具而选择本来没有其他原因会选择的方法进行测试，那么这种工具会导致大量的问题。
第12章 确定含义
不同的思维会确定不同的含义，因此最好让整个团队都参与进来；同样，不同的思维会确定不同的重要性。
第15章 避免软件测试变得越发困难
应对测试成本上升的方法：
1.通过合理的控制需求，让系统尽可能的小。开发人员经常犯的一个错误就是试图在软件中处理所有的可能情况。
2.增量构建，测试先行。
3.尽早测试、尽早解决缺陷。
第16章 不使用机器进行测试
投入大量脑力对一个系统进行测试的最简单的方法是技术评审。但不要把技术评审当作惩罚或刻意挑错，而应让每次评审成为对所有参与者都有益的学习经历。
通常，最迅速的评审方法是对“最差的”部分先评审。
测试人员是颇有价值的评审者（和敏捷开发计划会议时需要测试人员参加类似）：
1.通过观察开发人员可能产生的存在瑕疵的思维模式，测试人员可以了解如何设定更好的测试。
2.通过较早的对规格说明进行评审，测试人员可以更早了解到他们测试计划的范围。
3.通过熟悉设计，测试人员可以加快检测缺陷的过程，然后帮助查明他们。
4.通过参与评审，策划死人员可以学习如何能对他们自己的测试用例、测试计划、测试驱动程序和工具进行更好的评审。
第17章 测试欺诈
某些经理幻想着能够远距离地控制软件开发，只使用一些数字而不是至少通过亲自到观察来验证这些数字。当经理采取这样的态度时，他们就让自己很容易成为共谋欺诈的对象。在这种欺诈中，两组人会共同投机取巧。数字可能会有用，但是只有在通过亲身观察加以验证，并置于有关的上下文环境中时才是有用的。
识别欺诈的方法之一就是它们总是承诺不劳而获。
第18章 忘却型欺诈
回归测试不等于新测试：一个回归测试执行的次数越多，对测试产品和测试过程带来的坏处就越多。
计数不等于思考：对测试进行计数可以产生很多灾难性的效果。如，测试人员可能会避免建立任何冗长的或者复杂的测试。他们可能会停止相互帮助进行测试，停止进行其他不会被算作测试用例的有益的测试活动。
当我们迫切希望所有事都进展顺利的时候，就很容易在我们的数据中带上我们的幻想。