《软件测试经验与教训》读后感

第一篇：《软件测试经验与教训》读后感

<<软件测试经验与教训>>读后感

看了<<软件测试经验与教训>>第7、8、11章节后，对照以前的工作情况，感悟比较深的是以下几点：

1、回想测试BA100项目时，和开发工程师的关系处得非常紧张，出现问题相互责备；开发工程师曾经提出不要打击和嘲笑他们的要求。看完了与程序员交互这一章节后，明白程序员不是编码机器，有感情，大多数人都非常在乎所在工作。我们作为程序员的正式批评者，要避免正面冲突情况，要有团体合作精神，相互帮助相互信任；这样会让他们愿意共享信息，使测试工作更有效。向领导只反映所发现的问题不是反应程序员的能力。

2、我们在测试过程中提出一些理解有误或是路径不明确的问题，也有一些描述不清楚的问题；今后严格要求自己，发现问题就要坚持自己的观点，要提出令人信服的问题，并准确清楚描述问题，一步一步地将问题给出，没有多余步骤。使问题描述易读，容易理解。只谈论所看到的现象，不要猜测内部问题的性质，避免开发查找问题时花大量时间。

3、在测试BA100项目时，开发工程师没有做好准备就发布版本，测试员拿到版本直接升级或安装，结果发现正常功能无法执行，但是还在继续测试，或者大家需要退回旧版本重新等待开发再次发布；对于正常功能无法执行的版本我们应该拒绝这种测试版本。我希望以后项目使用冒烟测试，就是发布新版本时，安排一名测试员花上半天时间运行冒烟测试，其他人员等改版本通过冒烟测试才投入测试；这样就不会浪费大家时间。

4、以前我一直认为：2个测试员测试同样的内容是浪费时间，现在看完测试策略这一章节以后明白并不是一回事，2个测试员测试同样的内容也许并不是重复劳动，可能发现不同的问题，可以注意到另外一个测试员忽视的问题，而这种问题都是比较严重的问题，不易发现。

第二篇：软件测试经验与教训评论

<软件测试经验与教训>评注

作者： 傅健，jiafu@cisco.com(转载请注明作者)

经验6： 非常赞同，注重线下沟通方式，与开发做朋友，更容易发现更多测试思路，解决好问题； 经验10： 测试过程如若不限时间，很难定义穷尽之时，完美只是在指定时间/成本/质量要求下满足老板的要求。

经验11： 测试不能保证质量，非常赞同这个说话，考虑两个因素：（1）你给的时间和成本是多少？如果是0，提什么保证质量？（2）质量形成与构建者，也受其他人制约，例如三聚氰胺奶粉生产商不知道自己加了嘛？

经验13 ：测试确实应该尽其所能，横向上覆盖产品的设计，开发，发布，售后等过程，纵向覆盖与其他模块的交互；但是需要分析下为什么测试者往往有“不关我事”理论，无非涉及到管理的层面，例如：（1）薪资等不平等；（2）承接模块过多，失去兴趣和信心；

经验14 ：过程改进很伤感情，测试人员在测试前期不应该成为吹毛求疵的挑剔者，如果如此很可能出现两种情况：（1）开发的代码还没有完成阶段，但明知有很多bug之地，这个时候QA不断提出bug,势必影响开发心情。尊重开发的开发过程很重要；（2）开发的设计或许有其他思路，QA不断强调并说服开发者上司采用其他思路，如果不是非常有把握，就不要自作聪明强烈地说服开发者上司，这样最后往往被证明不定合理；

经验15：不要指望别人理解测试，需要不断向别人解释，这点在其他领域也适用，很多时候事实并不是就是事实，而是观察者眼中的“事实”，因此推销是门学问，“指鹿为马”未尝不可做到。

经验21：测试遗漏的问题更多集中在没有想到的用例，而不是执行不力；

经验22：所以进行Code审查更多的是了解设计从来更好的测试，不能指望直接发现代码错误； 经验30：任何量的测试都不能“确定”一个产品的质量，证明失效比证明正确容易的多。

经验31：客户需求多变，或许自己也不明白真正要什么，需求分析即是辅助、辨别需求。

经验32： 隐式规格说明很重要，很多测试依据都是这些“潜规则”，显式说明文档不可能也没有必要面面俱到。

经验33：测试员中的“它没有问题”，与他人眼中不同。

经验34：对质量印象只能限定在已知局限的前提下；

经验35：配置、运行、观察、评估是行为层面的用例；

经验37：对于复杂的任务模块需要间歇思考、细化击破，同样对于测试工作一样，过大的压力，无休止的加班不定有好的测试结果。测试应该有更多的思考时间；

经验39：防止思维定势，提倡多人思考互补，不用去偏执的带有目的去证明缺陷，而是平常心的客观测试。

经验43：应该提倡结对测试，互补思考，同时要攻破“难”点，越复杂之地越容易出问题，且多次出现频率更高。

经验45: 测试用例过于细节话，有可能限制测试者的想象力和创造性，之所以同一个CASE跑出不同的结果往往也和测试用例不过于细节化有关，但我认为不细节化一定程度上是好事情。

经验46：现在很多人还是以BUG数量、测试效果来衡量测试人员的水平，这条经验告诉人们要看测试人员如何思考；同时我们应该加强测试人才的培养与重视，不要仅仅为的是表面化的一些工作； 经验90：同行评审是个培训、提高的好方式；

经验103： 重试不同、多样测试比反反复复运行自动化脚本有效的多；

经验108： 专业培训的测试员的头脑是最好的测试工具；

经验114： 如果不是非常优秀的开发人员，且具有良好的测试思维，就不要开发测试工具，否则一旦推广害人害己，因为测试工具问题往往比普通产品更容易出现；

经验117： 自动回归测试有时候不能将改进和错误区分，特别是界面和输出格式变动；

经验118： 评估开发机构级别五级底部还有个级别是忘却（Oblivious）级，很多自动化测试没有提醒自己在执行软件开发过程；

经验122：评审自动化测试代码比用代码测试自动化测试代码好；因为后者容易陷入一个无限的逻辑；

经验130： 建议测试数据与测试执行分离；

经验132： 自动化是否绕过界面直接操作API取决于到底是界面稳定还是API稳定；尽量依赖稳定的东西；

经验133： 单元集成测试值得执行；

经验137： 提早测试自动化的好处：1）均衡时间，前期可能不是太忙；2）防止后期测试已经进行中要求自动化所带来的抵触心理；3）在开发完成前可以让开发提供更多的可测性；

经验143： 流程、模板都是用来规范人的行为的，只有不断了解、改善才有意义，如果一个流程、模板不允许任何应需改变则无意义；

经验146： 形式化工作越多，往往本质工作预留的时间越少，思维也限制的更固定；

经验148： 自己的测试文档是产品还是工具？这个问题很好；过于频繁的细节不要写到文档里，否则以后更新繁琐；

经验154： 不要利用程序员的弱点或透露的缺陷直接上报，类似于打小报告，以后的合作会减弱很多； 经验157： 测试是一种服务，不是控制，无法控制最终产品的质量；

经验168： 任务完成时间评估，应由掌握最佳知识的人进行，或者由估计错误需要负责的人执行，而不是根据测试经理的主观期望。

经验173： 可以拒绝某个版本的测试：1）新的版本很快就有，这个版本的测试结果会被忽略；2）重要的功能点没有添加；3）基本功能点不工作，导致大部分测试无法进行；

经验182： 提前应对可能风险，将潜在的风险预处理划分到项目的各个阶段而不是后期应急处理； 经验183：测试思考中总体认为产品不是一天做出的，而是慢慢堆积出的，只要有东西提交，就有可测之地，同时越早越好，只是需要抱着同情、谨慎心态等不同心态而已；

经验186：考虑二轮以上测试；

经验189： 测试：开发人员比例这种问题如果不结合具体项目及要求就不要提！

经验197：测试小组的真正力量是沟通，而非监管；

经验199： Bug数随进度推进而不断降低不能完全说明质量已经符合要求，因为后期可能从事非发现缺陷的活动：如展示产品、回归测试等；简单说：当看到BUG数连续几天较少时，不要完全觉得是产品质量变好，而可能是最近没有从事太多新的测试；

经验211： 要给予员工自己的思考、执行时空自由，尊重他们的测试思路，而不是模板化；

经验213： 非常赞同：指明了如何评价一名测试人员的工作，但是很多公司做不到，因为很辛苦。或许他们更倾向于用BUG数来衡量，这样简单明了，虽然不正确。

经验215： 赞同，所以假设必须分配多个任务给同一个员工，不要纠错式的责备某个时刻某个任务没有做好;

经验216： 测试经理在测试产品领域的视角要开阔；

经验220： 多了解员工的期待与现实感觉，不仅仅对于新员工需要这么做，留住老员工也是必须的，否则会出现离职都不知道真实原因的情况。关心员工、与员工做朋友非常重要。

经验225： 不要在项目末尾添加新手，有可能起到相反作用，这点在项目管理上也提到；同时不要为了以后可能有的培训或者职位更换理由，浪费太多时间在文档活动；在开发程序时也一样，不要为了以后可能还用不到的需求做无限扩大需求活动，否则永无尽头且不实际。

经验226：经理应该 客观评价事物，不要不懂装懂，否则容易误导员工，有失公正；

经验227： 不要使自己陷入导致工作失败（如工作量过大）或者没有希望的工作上，最终只会使自己的情绪受到伤害。管理者总是觉得应该给能者更多的工作，而员工则希望更多的休息，如果给予信任的员工更多的工作，最终可能导致其失败并有损情绪，实际上就是摧残而已。

经验228： 测试经理不应该是传话筒，否则有可能是成为不同决策者的执行机器，而应该是中间沟通协调层，保护其员工不受不同决策者的不同观点的影响，但是这种保护应该是正确的观点指导下。经验235：多样化是项目团队建议的良药；

经验238：跳槽时不要显示对原来公司的不满或泄露原公司的信息；

经验239：速度测验高分只能反映是脑力兔子，或者有可能是训练、练习所致；而低分者可能是脑力乌龟，慢工出细活。

经验245： 从职业发展角度来说，掌握测试技术本身比掌握专业业务逻辑更好，当然这里的专业业务是银行系统等的话，另当别论。

经验250： 面试贯彻2个逐条：逐条解释简历中的每条：逐条解释招聘要求的每个条目为什么自己符合，不符合，但是可以很快学习的地方；

经验252： 和其他公司测试员建立联系，有助于以后的职业发展。

经验253： 如有可能，多休息也是一种缓和跳槽的想法；

经验278：测试计划经常漏掉如何保障测试策略的执行与工作产品；

经验280：讨论风险和覆盖率，研究用例内容比单纯统计测试用例数量更有意义；

经验284： 策略决策可利用资源可简单归纳为：人、事、物；

经验285： V字软件测试模型强调软件测试策略早先制定，实际上随着测试的深入，策略会因风险识别的准确度提高等因素而做出调整，因为V不是非常好的项目组织方法。

经验286： 不要将测试局限在某个阶段，抓住一切机会测试可以测试并值得测试的事物；

经验297：项目初期：同情的测试；开发只想知道已经完成的功能的测试结果，不是想知道自己还没有做的功能的测试结果；整个测试按项目发展分为：同情地测试-》积极地测试-》多样地测试=》谨慎地测试；

经验292： 当遇到测试问题过多的模块（可能需要其他设计替换），应提醒开发，不要再痛打落水狗；要测试模糊不清的地方（接口之地、新的技术方案、需求模糊之地）；测试员负责任务之间的缝隙处（交叉部分）容易出问题；

总结：

（1）关注如何思考；

（2）关注本质，少看数量；

（3）关注多样化；

（4）强调结对测试；

（5）测所有可测之地，越早介入越好；

（6）不同阶段，拥有不同心态；

第三篇：软件测试经验与教训 学习笔记 1 1-15

测试员是项目的前灯。测试就是要找到信息。测试的使命决定要做的一切。快速找出重要软件问题，对产品质量提出总体评估，确认产品达到某种具体标准，帮助客户改进产品质量和可测性，保证测试过程能够达到可分清责任的标准，就测试和与测试员协作方式培训客户，采用特定的方法集或遵循特定的规则集，帮助预测和控制支持成本，帮助客户改进其过程，以最小化成本，时间或尽可能减少副作用的方式，完成自己的工作，为满足特定客户要求，完成所有必要的工作。测试员为很多客户服务。项目经理----向此客户报告工作状态，迅速报告重要问题。程序员---向此客户提供好的错误报告。技术文档编写员---向此客户报告文档类型错误，技术支持员和市场开发员，项目负责人，用户。测试员发现的信息会打扰客户。测试团队需要根据客户对价值的定义，通知客户有关威胁产品价值的任何信息。迅速找出重要程序问题。首先测试经过变更的部分，后测试没有变化的部分。先核心功能，后辅助功能，先测试能力后测试可靠性，先测试常见情况，后测试少见情况。先测试常见威胁，后罕见威胁，先测试影响大的问题，后影响小的问题，先测试最需要的部分，后测试没有要求的部分。跟着程序员走。及时的向程序员报告发现的问题。让程序员成为项目的瓶颈。询问一切，但不是外漏。测试员想到的任何问题，都会有助于启发自己的思想，最终产生对问题新的认识测试员关注失效，客户才能关注成功。不能说 通过测试来确认程序正常，只能说 就我所执行的测试来说，没有发现产品不正常。测试员通过发现程序中客观存在的问题，是为了更好的能够帮助项目团队更加了解自己的技能以及产品风险。不会发现所有程序问题。知道并承认自己不能做所有的事之后，测试员必须选择如何使用自己的时间 10 当心“完备的”测试。总结自己实施的测试以及为什么值得实施这些测试，并告诉客户自己没有做的其它值得做的测试，以及为什么没有做这些测试。通过测试不能保证质量。测试员测试和错误报告提供促进项目质量保证的信息，但是这种保证要来自整个团队。永远别做看门人。要由控制项目，条件最好的人承担发布产品的责任。当心测试中的不关我事理论。应尽其所能，通知团队可能会对产品的价值产生消极影响的所有问题。14 当心成为过程改进小组。可以成为过程改进的一员，但避免成为全部。别指望任何人会理解测试，或理解测试员需要什么条件才能搞好测试。测试员可以向管理层和程序员提供帮助自己的机会

第四篇：软件测试经验与教训 学习笔记2 16-30

Flowing is the today's summary.测试运用的是认知论。认知论研究如何认识所了解的东西，研究证据和推理。目标是了解如何才能改进我们的思维。多用how提问。how to know the software is perferct? if it is not perfect how to know?研究认识论有助于更好的测试 研究认识论 可帮助测试员设计有效的测试策略，更好的意识工作中的错误，理解自己的测试能证明什么，不能证明什么。入门书籍 《批判性思维的工具:心里学的元思想》，《思考与决策》，《研究的技巧》认知心理学是测试的基础。认知 心里 学 告诉 我们的是我们是如何思考的。有助于理解 影响测试员工作成绩的因素，以及影响人们理解自己工作方式的因素。测试在测试员的头脑中。注重测试设计选择，解释所观察的现象的能力，以及非常令人信服的分析描述这些现象的能力。测试需要判断，并不是只做输出与预期结果的比较。掌握探索时推断的艺术。以一种不能事先预测的方式，通过一种思想引出另外一种思想，然后再引出下一种思想。优秀测试员会进行技术性，创制性，批判性和实用性地思考。黑盒测试并不是基于无知的测试 更应该了解用户，了解结束，了解软件运行环境的配置，了解开发过程，了解这个软件要与之交互的其他软件。黑盒强调有关软件的用户和环境知识。测试员不只是游客。测试员做的大量非测试事是为了更好的了解产品，但是需要把精力放在评估产品上。所有的测试都试图回答某些问题。所执行的测试，都是要回答有关现实的产品和应该得到的产品之间关系的某个问题。所有的测试都基于模型。学会一种对产品建模的新方法，就像是学会了观察产品的一种新方法。26 直觉是不错的开始，但又是糟糕的结束。直觉只是在开始的时候更有用，而非其他时候。把直觉当做指南，而不能用作合理性证明。为了测试，必须探索。探索需要大量的思索。前向思索，后向思索，侧向思索。实用诱导推断逻辑发现推测实用猜想与反驳逻辑评估产品。

第五篇：无领导小组经验与教训

人力资源管理之无领导小组经验与教训

2011/11/28

一、评委

1.评分细则，评分表的制作（前期准备，评分标准不容易明确）

2.加减分细则，标准不统一

3.不可避免受到平时印象的影响加减分数，很难做到绝对的公平公正。

4.前期分工和合作很重要

5.忽略某些细则（如加减分）

6.评委前期应该开会统一意见，制定标准

7.评委应该对考生进行近距离全方位的观察

8.评分表的操作性高很重要

9.评委应该保留数据

10.考官各方面的比例应该合理（譬如：性别、人数）

二、考生

1.2.3.4.5.6.把握自己在讨论中的位置 首先统一共识的标准 注意自己在讨论中的行为举止 性别有可能对结果造成影响 注意对讨论内容的规划 考官不可能看到过程中的每一细节，所以考生不必太过在意自己一时的错误

7.独立发表意见，综合整合结果

8.更早地确定小组发言人

9.声音洪亮，语速平缓，观点明确

三、观众

1.过于关注考生考官

2.考官男女比例失调，人数不足

3.考生之间关系协调度，情商的注意

4.音量音速的控制，信息表达效果，观点长度的控制

5.明确出题人的意图，注意本次考核的价值观

6.总结观点时应该注意取舍问题

7.明确目的，标准统一

8.团队：交流方式，对观点的自信度，意见的深思熟虑