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

第一篇：软件测试经验与教训 学习笔记 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 直觉是不错的开始，但又是糟糕的结束。直觉只是在开始的时候更有用，而非其他时候。把直觉当做指南，而不能用作合理性证明。为了测试，必须探索。探索需要大量的思索。前向思索，后向思索，侧向思索。实用诱导推断逻辑发现推测实用猜想与反驳逻辑评估产品。

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

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

作者： 傅健，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）不同阶段，拥有不同心态；

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

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

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

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

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

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

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

第五篇：软件测试学习

软件测试学习

1． 什么是软件测试？

答：软件测试是为了发现错误而审查软件文档、检查软件数据和执行程序代码的过程，其目的在于在软件交付使用前充分发现缺陷并协助相关部门定位、解决缺陷，最后交付一个高质量的软件产品给用户。

2．软件测试的分类有哪些？

答：软件测试活动可以分为以下几类：

 黑盒测试：

黑盒测试又叫功能测试，数据驱动测试或基于需求规格说明书的功能测试。（主要用于系统测试和确认测试中）

 白盒测试

白盒测试又称结构测试、逻辑驱动测试或程序代码内部构成的测试。

 灰盒测试

灰盒测试结合黑盒和白盒测试两种方法，一方面考虑程序代码的功能性表现，另一方面，又需要考虑程序代码的内部结构。（主要用于性能测试、自动化功能测试） 静态测试

静态测试就是用眼看，阅读程序代码、文档资料等，与需求规格说明书中的客户需求进行比较，找出程序代码中设计不合理及文档集料有错误的地方

 动态测试

动态测试即为实际的执行被测对象的程序代码，输入事先设计好的测试用例，检查程序运行得到的结果与测试用例中设计的预期结果之间是否有差异，判定实际结果与预期结果是否一致，从而检验程序的正确性、可靠性和有效性，并分析系统运行效率和健壮性等性能状况。

动态测试由四个部分组成：设计测试用例、执行测试用例、分析比较输出结果、输出测试报告。

动态测试有三种方法：黑盒测试、白盒测试、灰盒测试。

 手动测试

手动测试大部分的测试就是模拟用户的业务流程，来使用软件产品，从而发现软件产品中的缺陷。手动测试是最传统的测试方法，也是现在大多数公司都是用的测试形式。他是测试人员设计测试用例并执行测试用例，然后根据实际结果去和预期的结果相比较并记录测试结果，最终输出测试报告的测试活动。

优点：可以充分发挥测试工程师的主观能动性，将其智力活动体现于测试活动中，能发现很多的缺陷。

缺点：手动测试有一定的局限性与单调枯燥性。

 自动测试

自动测试就是利用一些测试工具，模拟用户的使用流程，让它们自动运行来查找缺陷。也可以编写一些代码，设定特定的测试场景，来自动寻找缺陷

优点：能够很快、很广泛的查找缺陷，同时可以做很多重复性的工作，大大提高了测试的效率和测试的准确性，而且写出的比较好的测试脚本，还可以在软件生命周期的各个阶段重复使用。

3．软件测试的流程：需求测试、单元测试、集成测试、系统测试、性能测试、用户测试、回归测试

 需求测试：主要从以下几个方面考虑

①完整性：每一项需求都必须将所要实现的功能描述清楚，从而为开发人员设计和实现这些功能提供所有必要的需求依据。

②正确性：每一项需求都必须准确的陈述其要开发的功能

③一致性：一致性是指与其它软件需求或高层（系统、业务）需求不相矛盾，或者与我们的项目宣传资料一致。

④可行性：每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。⑤无二义性：对所有需求的读者都只能有一个明确统一的解释，由于自然语言极易导致二义性，所以尽量把每项需求用简洁明了的用户语言表达出来。

⑥健壮性：需求的说明中是否对可能出现的异常进行了分析，并且对这些异常进行了容错处理。

⑦必要性：“必要性”可以理解为每项需求都是用来授权你编写文档的“根源”。要是每项需求都回溯至某项客户的输入，如需求用例或别的来源。

⑧可测试性：每项需求都能通过设计测试用例或其它验证方法来进行测试。

⑨可修改性：每项需求只应在SRS（软件需求规格说明书）中出现一次。这样更改时易于保持一致性。另外，使用目录表、索引和相互参照列表方法将使软件需求规格说明书更容易修改。

 单元测试

单元测试又成为模块测试，是对程序代码中最小的设计模块单元进行测试。（可以发现大约80%的软件缺陷，大多数公司中，由对应的开发工程师负责）单元测试方法：主要采用静态测试和动态测试相结合的办法。

单元测试工具：Juint等。

单元测试优点：在软件生产过程中及时的开展单元测试可以降低编码的错误率，提

高编码质量。

 集成测试

集成测试又称为组装测试，就是将软件产品中的各个模块组装起来，检查其接口是否存在问题，以及组装后的整体性能、性能表现。

集成测试方法：一般采用非增式集成方法、增式集成方法（自底向上集成；自顶向下集成；组合方式集成）等策略进行测试，利用以黑盒测试为主，白盒测试为辅的测试方法进行测试。

（集成测试一般由测试工程师但当）

集成测试的目的：主要解决的是各个软件组成单元代码是否符合开发规范、接口是否存在问题、整体功能有无错误、界面是否符合设计规范、性能是否满足用户需求等。

 系统测试

系统测试是将通过集成测试的软件部署到某种较为复杂的计算机用户环境（指一般用户的计算机环境）进行测试。

系统测试的目的：通过与系统的需求进行比较，发现软件与系统的定义不符合或与之矛盾的地方。主要考察被测软件的功能和性能表现。

系统测试方法：主要采用黑盒测试方法，进行的是安装卸载测试、兼容性测试、功能确认测试、安全性测试等。

系统测试过程其实也是一种配置检查过程，检查软件在生产过程中是否有遗漏的地方，在此时做到查漏补缺，以确保交付的产品符合用户的质量要求。如果软件可以按照用户合理期望的方式来工作的时候，即可认为通过系统测试。

 性能测试

性能测试就是要求被测软件在业务处理速度、处理能力和所耗用的硬件系统资源比率满足用户的需求。

对测试人员的要求：测试人员要掌握编程语言，精通业务流程，拥有深厚的项目经验。所以，想顺利的开展性能测试，需要测试工程师不断的学习，掌握相应的知识。例子：对于某个论坛，我们需要测试论坛支持10000个用户同时使用，并且在这种情况下，打开帖子的速度能否控制在4秒钟以下，论坛服务器的CPU使用率不超过80%，内存的占用率不超过75%等，这些都是典型的性能测试指标。

性能测试优点：一方面可以验证被测软件是否符合用户需求，另一方面，可以得到相关的性能数据，为被测软件的优化提供参考。

性能测试工具：LoadRunner自动化性能测试工具等。

 用户测试

用户测试可以称其为用户确认测试。在正式验收前，需要用户对本系统做出一个评价，用户可对交付的系统做测试，并将测试结果反馈回来，进行修改、分析。用户测试在整个软件生产流程中非常重要，这个环节是被测软件首次作为正式系统交由用户使用，用户会根据他们的实际使用情况进行测试、试用，并提出实际使用过程中的问题。

用户测试是软件生产流程中的最后质检关。

 回归测试

回归测试就是过一段时间以后再回过头来对以前修复过的Bug重新进行测试，看该Bug是否会重新出现。

回归测试的目的：检查以前的测试用例能否再次通过，是否还有需要补充的用例等。

回归测试工具：QTP等。