精华内容
下载资源
问答
  • 软件测试经验与教训

    2018-10-06 18:18:31
    UFT是一种自动化测试工具,...UFT支持功能测试和回归测试自动化,可用于软件应用程序和环境的测试。UFT自动化测试的基本 功能包括: ①创建测试 ②检验数据 ③增强测试 ④运行测试脚本 ⑤分析测试结果 ⑥维护测试
  • 软件测试经验与教训(测试小白必看书籍)软件测试经验与教训(测试小白必看书籍)软件测试经验与教训(测试小白必看书籍)
  • 软件测试相关:软件测试经验与教训 介绍软件测试的经验和教训,以便于做测试工作的学习经验,接受教训。
  • 最近拜读了《软件测试经验与教训》一书,其中给出的很多经验和教训都富有参考价值,摘录了一些个人觉得比较有用的条目。与大家一起分享学习。 迅速找出重要程序问题 先测试经过变更的部分,后测试没有变化...

        最近拜读了《软件测试经验与教训》一书,其中给出的很多经验和教训都富有参考价值,摘录了一些个人觉得比较有用的条目。与大家一起分享学习。

    • 迅速找出重要程序问题
            先测试经过变更的部分,后测试没有变化的部分。
            先核心功能,后辅助功能。
            先能力,后可靠性。
            先常见情况,后少见情况
            先常见威胁,后罕见威胁。
            先影响大的问题,后影响小的问题。
            先最需要的部分,后没有要求的部分。
            测试如果对产品、产品必须与之交互的软件和硬件以及将使用软件的人越了解,越有可能更快的找出重要问题。
     
    • 黑盒测试
            为了做好黑盒测试,就要了解用户,了解他们的期望和需求,了解技术,了解软件运行环境的配置,了解这个软件要与之交互的其他软件,了解软件必须管理的数据,了解开发过程等等。
     
    • 通过会议、推到和参照发现需求
            需求文档经常是不完整、不准确的。从以下三种途径搜集需求信息。
            1.会议,找出其有关质量的意见具有影响力的人,与他们交流,了解他们最关心什么。
            2.推到,通过外推已知项目和产品其它信息,确定什么需求最重要。
            3.参照,发现显示、隐式规格说明。
     
    • 既要使用显示规格说明,也要使用隐式规格说明
            显示规格说明是一个有用的需求信息源,经过客户的权威确认。隐式规格说明是没有经过客户权威确认的一个有用的需求信息源。
            隐式规格说明的形式:1、竞争对手的产品;2、相关产品;3、统一产品的老版本;4、项目团队之间的电子邮件讨论;5、顾客意见;6、图形用户界面风格指南;7、操作系统兼容性需求;8、测试自己的丰富经验。
     
    • 不要将试验和测试混淆起来
            测试任何产品至少包含以下四种活动:1、配置,准备要测试的产品,将其置于正确的其实状态。否则测试结果会受到不良变量的影响。2、运行,向产品输入数据,向产品发命令,以某种方式与产品交互。3、观察,收集有关产品行为信息,输出数据,系统整体状态,与其他产品的交互等方面的信息。4、评估,运用规则、推理或可检测所观察到数据中存在问题的机制。
     
    • 运用试探法快速产生测试思路
            试探法是一种基于经验做出猜测的方法。由于可能的测试用例数量是无限的,因此要选出在所面临的时间和预算约束条件下有小的少量测试用例。一组好的试探方法有助于很快地生成测试。采用试探法测试的一些例子:
            1.测试边界。边界更可能暴露规格说明的模糊问题。
            2.测试所有错误信息。错误处理代码与主流功能代码相比,一般比较弱。
            3.测试与程序员的配置不同的配置。
            4.运行比较南设置的测试。在其它条件相同的情况下,易于设置的测试更有可能已经被执行过了。
            5.避免冗余测试。如果某个测试实际上是重复其它测试,就不会产生新价值。
     
    • 如果遗漏一个问题,检查这种遗漏是意外还是策略的必然结果
            如果出现遗漏问题,需要思考出现问题是因为执行了好的测试策略,碰巧没有发现这个特定问题?如果是这样,可以保持原有方针不变。但是如果遗漏程序错误是因为测试策略关注了错的问题类型,可以利用这个机会改进测试策略。
     
    • 关注测试员、覆盖率、潜在问题、活动和评估的组合测试手段
            测试五要素:
            1.测试员。
            2.覆盖率。测试了那些哪些内容。
            3.潜在问题。测试的原因。
            4.活动。如何测试。
            5.评估。怎样判定测试通过还是不通过。
            测试手段不一定只涉及一种要素,也不应该这样,所有的测试应该都要涉及五个要素。应该期望跨多个要素的更综合的测试手段。
     
    • 关注测试员的基于人员的测试手段
            以执行测试的人来区分的常见手段。
            用户测试:将使用该产品的典型人员进行输入测试。
            α测试:有测试小组执行的内部测试。
            β测试:利用不属于开发机构并且是产品的目标时长成员的测试员实施的用户测试。
            强力测试:利用秘书、程序员、时长开发人员和可以找到的任何人所实施的内部测试。
            有关领域的专家测试:向软件目标领域内的专家提供产品,并寻求反馈意见。
            成对测试:两个测试员在一起发现程序错误。
            自用测试:全公司使用并依靠自己软件的试用版,通常要等到软件足够可靠能够实际使用时,才像市场销售。
     
    • 关注测试内容的基于覆盖率的测试手段
            功能测试:逐个测试每个功能。
            特性或功能集成测试:一起测试多个功能,以检查功能在一起执行的情况。
            菜单浏览:遍历GUI产品中所有菜单和对话框,使用每个可用的选项。
            域测试:搜集所有的输入输出变量,把其可能取值集合划分为等价类。以这个变量作为输入或输出,测试涉及这个变量的每个功能。
            等价类划分:等价类是认为等价的一组变量取值。一旦找出一个等价类,可只测试其一两个成员。
            边界测试:边界值就是类的最小和最大值。在边界测试中,要测试这些值,还要测试相邻类的边界值。
            最佳代表测试:等价类的最佳代表是暴露软件中的错误的可能性方面至少与类中其它值一样的值。但有时候不一定是数值,要根据具体问题选择这个类的最佳代表。
            输入字段测试大纲或矩阵:对于每组输入字段,可以开发一组相当标准的测试用例。
            用各种方式映射和测试编辑字段:可以是手动输入,或者拷贝或者其它等等。
            逻辑测试:试图检查程序中的所有逻辑关系,因果图是一种用于设计大量基于逻辑测试的手段。
            基于状态的测试:在基于状态的测试中,每次都要通过经过大量状态前移,并自洗检查结果来检验程序。
            路径测试:一条路径包含测试员所执行的所有步骤,或程序为了得到正确状态所通过的所有语句。路径测试包括测试通过程序的很多条路径。
            语句与分支覆盖率:如果测试执行了程序中所有的语句,则达到了100%的语句覆盖率。如果执行了所有语句和一个语句到另一个语句之间的所有分支,则达到100%的语句和分支覆盖率。设计自己的测试,达到高的语句与分支覆盖率,
            配置覆盖率:配置覆盖率度量测试员已经运行的配置测试占计划运行的配置测试总数的百分比。
            基于规格说明的测试:这种测试关注验证在规格说明中所做的有关产品的每个事声明。
            基于需求的测试:测试关注证明程序满足需求文档中的所有需求。
            组合测试:相互组合两个或更多便利。
     
    • 关注测试原因(基于风险测试)的基于问题的测试手段
            基于风险的测试至少有两个主要含义。进行风险分析是为了确定下一步要做的测试。另一个含义就是进行风险测试时为了发现错误。
     
    • 关注测试方法的基于活动的测试手段
            回归测试:回归测试涉及相同测试的重用,使得在软件变更以后可以重新执行。
            脚本测试:手工测试,采用由更高级的测试员编写的测试过程步骤,一般由低级程序员执行。
            冒烟测试:这种副作用回归测试的目标,是证明新版本不值得测试。
            探索式测试:不断创建并使用新测试。
            游击式测试:对程序快速,有力的攻击。
            场景测试:这种测试涉及四个属性,1.测试必须是现实的,反映客户实际要做的事;2.测试应该是复合的,要以能够对程序构成一定挑战的方式包含多个功能;3.应该能够容易并快速的显示出程序是否通过测试;4.如果程序没有通过测试,有关人员会强烈要求修改程序。
            安装测试:以各种方式,在可以安装该软件的不同类型系统上安装该软件。
            负载测试:在面临很多资源要求的系统上运行,攻击被测程序或系统。
            可靠性测试:测试需要持续一定的时间来暴露问题。
            性能测试:运行这些测试通常要确定程序运行有多快,以便确定是否需要优化。
     
    • 关注测试是否通过的基于评估的测试手段
            评估手段描述确定程序是否通过测试的方法,说明如果能够采集到一定的数据该如何评估。
     
     
    • 不可重现程序错误是可重现的
            程序错误要在特定的条件下出现。如果遇到自己不能重现的程序错误,可以尝试找出条件是什么。列举了一些有助于思考的条件例子:1.程序错误可能有延迟效应;2.程序错误可能只是在安装、使用产品或使用产品的特定功能时出现一次。3.程序错误可能依赖于特定的数据取值或被破坏了的数据库。4.程序错误可能只在特定的时间点发生。5.缺陷可能依赖于特定顺序执行一系列相关的任务。6.程序错误可能是前面失效的残余。7.程序错误可能是由被测应用程序与后台运行的其他软件,或和与被测应用程序竞争访问的软件交互引起的。
     
    • 有关测试策略要问的三个基本问题是”为什么担心?”、“谁关心”、“测试多少?”
            为什么担心?测试是昂贵的,除非测试策略解决足够重要,需要花时间测试的问题,否则测试策略中不要包含活动。
            谁关心?只在测试策略中包含与他们利益有关的活动
            测试多少?到底打算实际测试多少?
     
    • 实际测试计划是指导测试过程的一套想法
     
    • 所设计的测试计划要符合自己的具体情况
            测试计划的目标,是所选的测试过程能够使测试控制在项目环境中,同时又能充分利用资源,完成自己的任务。给定五种资源和约束是:
            开发;产生将要测试的产品和系统。如何接收该产品?该产品的可测试性如何?
            需求;成功产品的评判准则。该产品的风险是什么?有关质量谁的意见最重要?
            测试团队;能够投入该产品测试的人员。有合适人选吗?能够及时完成任务吗?
            测试实验室;使测试团队能够完成测试任务的系统、工具和材料。有合适的设备吗?程序错误跟踪系统的状态是否良好?
            任务;测试团队必须按照客户认可的成功标准解决的问题。快速找出重要问题?对质量做出准确评估?
     
    • 利用测试计划描述在测试策略、保障条件和工作产品上所做的选择
            测试计划必须描述三类选择:
            1.策略。如何测试产品以快速找出重要问题?需要对哪些部分进行特殊测试?要运用什么手段创建测试?当程序错误出现时怎样识别?测试策略要规定测试项目与测试任务之间的关系。
            2.保障条件。如何利用资源实现测试策略?谁来测试?什么时候测试?要想成功需要什么条件?
            3.工作产品。怎样向客户提供工作产品?如何跟踪程序错误?需要编写什么测试文档?需要编写什么报告?
     
    • 测试策略要解释测试
            好的测试策略是:
            1.与具体产品有关。
            2.关注风险。显示测试过程中可以怎样描述重要问题。
            3.多样化。多样化测试策略要包含各种不同的测试手段和方法。
            4.实用。测试策略必须能被执行。
     
    • 根据产品的成熟度确定测试策略
            项目初期,同情的测试。
            项目中期,积极地测试。
            项目末期,多样地测试。
            项目最后,谨慎地测试。
            总体目标是随着产品开发的进展,不断地调整测试策略,使得产品开发整个过程中,重要错误的发现率都保持比较高的水平。
     

    转载于:https://www.cnblogs.com/mujiujiu/p/9308670.html

    展开全文
  • 软件测试经验与教训》--读书笔记

    千次阅读 2015-01-15 01:30:42
    软件测试经验与教训》--读书笔记
    《软件测试经验与教训》--读书笔记





    前言:
            《软件测试经验与教训》汇集了293条关于软件测试的经验及建议,全部来自作者的工作实践。作者组织这些经验教训时,分为散文式的十一个章节。我做
    的笔记会重新组织,记录对我有用的部分。其实,一些经验教训是需要有相应工作经验才能够理解的。功力不够,可能产生歧义。所以,放到后面再做。






    第1章 测试员的角色
        经验1:测试员是项目的前灯
        感受:若希望测试员是项目的前灯,则需要测试员在项目的需求阶段发挥更大的作用,且需要测试员对于行业业务知识等有深入的理解。

        经验2:测试员的使命决定要做的一切
        经验3:测试员为很多客户服务
        经验4:测试员发现的信息会“打扰”客户
        经验5:迅速找出重要程序问题
        感受:(优先情况:经过变更的部分、核心功能、冒烟、常见情景、常见威胁、影响大的问题、最需要的问题;)

        经验6:跟着程序员走
        经验7:询问一切,但不一定外露
        经验8:测试员关注失效,客户才能关注成功
        经验9:不会发现所有程序问题
        经验10:当心“完备的”测试
        经验11:通过测试不能保证质量
        经验12:永远别做看门人
        经验13:当心测试中的不关我事理论
        经验14:当心成为过程改进小组
        经验15:别指望任何人会理解测试,或理解测试员需要什么条件才能搞好测试





    第2章 按测试员的方式思考
        经验16:测试运用的是认识论
        经验17:研究认识论有助于更好测试
        经验18:认知心理学是测试的基础
        经验19:测试在测试员的头脑中
        经验20:测试需要推断,并不只是做输出与预期结果的比较
        经验21:优秀测试员会进行技术性、创造性、批判性和实用性地思考
        经验22:黑盒测试并不是基于无知的测试
        经验23:测试员不只是游客
        经验24:所有测试都试图回答某些问题
        经验25:所有测试都基于模型
        经验26:直觉是不错的开始,但又是糟糕的结束
        经验27:为了测试,必须探索
        经验28:探索要求大量思索
        经验29:使用诱导推断逻辑发现推测
        经验30:使用猜想与反驳逻辑评估产品
        经验31:需求是重要任务所关心的质量或条件
        经验32:通过会议、推导和参照发现需求
        经验33:既要使用显式规格说明,也要使用隐式规格说明
        经验34:“它没有问题”真正的含义是,它看起来在一定程度上满足部分需求
        经验35:最后,测试员所能得到的只是产品的印象
        经验36:不要将试验与测试混淆起来
        经验37:当测试复杂产品时:陷入与退出
        经验38:运用试探法快速产生测试思路
        经验39:测试员不能避免偏向,但是可以管理偏向
        经验40:如果自己知道自己不聪明,就更难被愚弄
        经验41:如果遗漏一个问题,检查这种遗漏是意外还是策略的必然结果
        经验42:困惑是一种测试工具
        经验43:清新的眼光会发现失效
        经验44:测试员要避免遵循过程,除非过程先跟随自己
        经验45:在创建测试过程时,避免“1287”
        经验46:测试过程的一个重要成果,是更好、更聪明的测试员
        经验47:除非重新发明测试,否则不能精通测试





    第3章 测试手段
        经验48:关注测试员、覆盖率、潜在问题、活动和评估的组合测试手段
        经验49:关注测试员的基于人员的测试手段
        经验50:关注测试内容的基于覆盖率的测试手段
        经验51:关注测试原因(针对风险测试)的基于问题的测试手段
        经验52:关注测试方法的基于活动的测试手段
        经验53:关注测试是否通过的基于评估的测试手段
        经验54:根据自己的看法对测试手段分类





    第4章 程序错误分析
        经验55:文如其人
        经验56:测试员的程序错误分析会推动改正所报告的错误
        经验57:使自己的错误报告成为一种有效的销售工具
        经验58:错误报告代表的是测试员
        经验59:努力使错误报告有更高的价值
        经验60:产品的任何项目相关人员都应该能够报告程序错误
        经验61:引用别人的错误报告时要小心
        经验62:将质量问题作为错误报告
        经验63:有些产品的项目相关人员不能报告程序错误,测试员就是他们的代理
        经验64:将受到影响的项目相关人员的注意力转移到有争议的程序错误上
        经验65:决不要利用程序错误跟踪系统监视程序员的表现
        经验66:决不要利用程序错误跟踪系统监视测试员的表现
        经验67:及时报告缺陷
        经验68:永远不要假设明显的程序错误已经写入报告
        经验69:报告设计错误
        经验70:看似极端的缺陷是潜在安全漏洞
        经验71:使冷僻用例不冷僻
        经验72:小缺陷也值得报告和修改
        经验73:时刻明确严重等级和优先级之间的差别
        经验74:失效时错误征兆,不是错误本身
        经验75:针对看起来很小的代码错误执行后续测试
        经验76:永远都要报告不可重现的错误,这样的错误可能是时间炸弹
        经验77:不可重现程序错误时可重现的
        经验78:注意错误报告的处理成本
        经验79:特别处理与工具或环境有关的程序错误
        经验80:在报告原型或早期个人版本的程序错误之前,要先征得同意
        经验81:重复错误报告是能够自我解决的问题
        经验82:每个程序错误都需要单独的报告
        经验83:归纳行是错误报告中最重要的部分
        经验84:不要夸大程序错误
        经验85:清楚地报告问题,但不要试图解决问题
        经验86:注意自己的语气,所批评的每个人都会看到报告
        经验87:使自己的报告具有可读性,即使对象是劳累和暴躁的人
        经验88:提高报告撰写技能
        经验89:如果合适,使用市场开发或技术支持数据
        经验90:相互评审错误报告
        经验91:与将阅读错误报告的程序员见面
        经验92:最好的方法可能是向程序员演示所发现的程序错误
        经验93:当程序员说问题已经解决时,要检查是否真的没有问题了
        经验94:尽快检验程序错误修改
        经验95:如果修改出现问题,应与程序员沟通
        经验96:错误报告应该由测试员封存
        经验97:不要坚持要求修改所有程序错误,要量力而行
        经验98:不要让延迟修改的程序错误消失
        经验99:测试惰性不能成为程序错误修改推迟的原因
        经验100:立即对程序错误延迟决定上诉
        经验101:如果决定据理力争,就一定要赢!





    第5章 测试自动化
        经验102:加快开发过程,而不是试图在测试上省钱
        经验103:拓展测试领域,不要不断重复相同的测试
        经验104:根据自己的背景选择自动化测试策略
        经验105:不要强求100%的自动化
        经验106:测试工具并不是策略
        经验107:不要通过自动化使无序情况更严重
        经验108:不要把手工测试与自动化测试等同起来
        经验109:不要根据测试运行的频率来估计测试的价值
        经验110:自动化的回归测试发现少部分程序错误
        经验111:在自动化测试时考虑什么样的程序错误没有发现
        经验112:差的自动化测试的问题是没有人注意
        经验113:捕获回放失败
        经验114:测试工具也有程序错误
        经验115:用户界面变更
        经验116:根据兼容性、熟悉程度和服务选择GUI测试工具
        经验117:自动回归测试消亡
        经验118:测试自动化是一种软件开发过程
        经验119:测试自动化是一种重要投资
        经验120:测试自动化项目需要程序设计、测试和项目管理方面的技能
        经验121:通过试点验证可行性
        经验122:请测试员和程序员参与测试自动化项目
        经验123:设计自动化测试以推动评审
        经验124:在自动化测试设计上不要吝啬
        经验125:避免在测试脚本中使用复杂逻辑
        经验126:不要只是为了避免重复编码而构建代码库
        经验127:数据驱动的自动化测试更便于运行大量测试变种
        经验128:关键词驱动的自动化测试更便于非程序员创建测试
        经验129:利用自动化手段生成测试输入
        经验130:将测试生成与测试执行分开
        经验131:使用标准脚本语言
        经验132:利用编程接口自动化测试
        经验133:鼓励开发单元测试包
        经验134:小心使用不理解测试的测试自动化设计人员
        经验135:避免使用不尊重测试的测试自动化设计人员
        经验136:可测试性往往是比测试自动化更好的投资
        经验137:可测试性是可视性和控制
        经验138:尽早启动测试自动化
        经验139:为集中式测试自动化小组明确章程
        经验140:测试自动化要立即见效
        经验141:测试员拥有的测试工具会比所意识到的多





    第6章 测试文档
        经验142:为了有效地应用解决方案,需要清楚地理解问题
        经验143:不要使用测试文档模板:除非可以脱离模板,否则模板就没有用
        经验144:使用测试文档模板:模板能够促进一致的沟通
        经验145:使用IEEE标准829作为测试文档
        经验146:不要使用IEEE标准829
        经验147:在决定要构建的产品之前先分析需求,这一点既适用于软件也同样适用于文档
        经验148:为了分析测试文档需求,可采用类似以下给出的问题清单进行调查
        经验149:用简短的语句归纳出核心文档需求





    第7章 与程序员交互
        经验150:理解程序员怎样思考
        经验151:获得程序员的信任
        经验152:提供服务
        经验153:测试员的正直和能力需要尊重
        经验154:将关注点放在产品上,而不是人上
        经验155:程序员喜欢谈论自己的工作。应该问他们问题
        经验156:程序员乐于通过可测试性提供帮助





    第8章 管理测试项目
        经验157:建设一种服务文化
        经验158:不要尝试建立一种控制文化
        经验159:要发挥耳目作用
        经验160:测试经理管理的是提供测试服务的子项目,不是开发项目
        经验161:所有项目都会演变。管理良好的项目能够很好地演变
        经验162:总会有很晚的变更
        经验163:项目涉及功能、可靠性、时间和资金之间的折衷
        经验164:让项目经理选择项目生命周期
        经验165:瀑布生命周期把可靠性与时间对立起来
        经验166:进化生命周期把功能与时间对立起来
        经验167:愿意在开发初期将资源分配给项目团队
        经验168:合同驱动的开发不同于寻求市场的开发
        经验169:要求可测试性功能
        经验170:协商版本开发进度计划
        经验171:了解程序员在交付版本之前会做什么(以及不会做什么)
        经验172:为被测版本做好准备
        经验173:有时测试员应该拒绝测试某个版本
        经验174:使用冒烟测试检验版本
        经验175:有时正确的决策是停止测试,暂停改错,并重新设计软件
        经验176:根据实际使用的开发实践调整自己的测试过程
        经验177:“项目文档是一种有趣的幻想:有用,但永远不足”
        经验178:测试员除非要用,否则不要索要
        经验179:充分利用其它信息源
        经验180:向项目经理指出配置管理问题
        经验181:程序员就像龙卷风
        经验182:好的测试计划便于后期变更
        经验183:只要交付工作制品,就会出现测试机会
        经验184:做多少测试才算够?这方面还没有通用的计算公式
        经验185:“足够测试”意味着“有足够的信息可供客户做出好决策”
        经验186:不要只为两轮测试做出预算
        经验187:为一组任务确定进度计划,估计每个任务所需的时间
        经验188:承担工作的人应该告诉测试经理完成该任务需要多长时间
        经验189:在测试员与开发人员之间没有正确的比例
        经验190:调整任务和不能胜任的人员
        经验191:轮换测试员的测试对象
        经验192:尽量成对测试
        经验193:为项目指派一位问题查找高手
        经验194:确定测试的阶段计划,特别是探索式测试的阶段计划
        经验195:分阶段测试
        经验196:通过活动日志来反映对测试员工作的干扰
        经验197:定期状态报告是一种强有力的工具
        经验198:再也没有比副总裁掌握统计数据更危险的了
        经验199:要小心通过程序错误数度量项目进展
        经验200:使用的覆盖率度量越独立,了解的信息越多
        经验201:利用综合计分牌产生考虑多个因素的状态报告
        经验202:以下是周状态报告的推荐结构
        经验203:项目进展表是另一种展示状态的有用方法
        经验204:如果里程碑定义得很好,里程碑报告很有用
        经验205:不要签署批准产品的发布
        经验206:不要签字承认产品经过测试达到测试经理的满意程度
        经验207:如果测试经理要编写产品发布报告,应描述测试工作和结果,而不是自己对该产品的看法
        经验208:在产品最终发布报告中列出没有排除的程序错误
        经验209:有用的发布报告应列出批评者可能指出的10个最糟糕的问题





    第9章 测试小组的管理
        经验210:平庸是一种保守期望
        经验211:要把自己的员工当作执行经理
        经验212:阅读自己员工完成的错误报告
        经验213:像评估执行经理那样评估测试员
        经验214:如果测试经理确实想知道实际情况,可与员工一起测试
        经验215:不要指望别人能够高效处理多个项目
        经验216:积累自己员工的专业领域知识
        经验217:积累自己员工相关技术方面的专门知识
        经验218:积极提高技能
        经验219:浏览技术支持日志
        经验220:帮助新测试员获得成功
        经验221:让新测试员对照软件核对文档
        经验222:通过正面测试使新测试员熟悉产品
        经验223:让测试新手在编写新错误报告之前,先改写老的错误报告
        经验224:让新测试员在测试新程序错误之前,先重新测试老程序错误
        经验225:不要派测试新手参加几乎完成的项目
        经验226:员工的士气是一种重要资产
        经验227:测试经理不要让自己被滥用
        经验228:不要随意让员工加班
        经验229:不要让员工被滥用
        经验230:创造培训机会
        经验231:录用决策时最重要的决策
        经验232:在招募期间利用承包人争取回旋余地
        经验233:谨慎把其他小组拒绝的人吸收到测试小组中
        经验234:对测试小组需要承担的任务,以及完成这些任务所需的技能做出规划
        经验235:测试团队成员要有不同背景
        经验236:录用其他渠道的应聘者
        经验237:根据大家意见决定录用
        经验238:录用热爱自己工作的人
        经验239:录用正直的人
        经验240:在面谈时,让应聘者展示期望有的技能
        经验241:在面谈时,请应聘者通过非正式能力测验展示其在工作中能够运用的技能
        经验242:在录用时,要求应聘者提供工作样本
        经验243:一旦拿定主意就迅速录用
        经验244:要将录用承诺形成文字,并遵守诺言





    第10章 软件测试职业发展
        经验245:确定职业发展方向并不懈努力
        经验246:测试员的收入可以超过程序员的收入
        经验247:可大胆改变职业发展方向并追求其他目标
        经验248:不管选择走哪条路,都要积极追求
        经验249:超出软件测试拓展自己的职业发展方向
        经验250:超出公司拓展自己的职业发展方向
        经验251:参加会议是为了讨论
        经验252:很多公司的问题并不比本公司的问题少
        经验253:如果不喜欢自己的公司,就再找一份不同的工作
        经验254:为寻找新工作做好准备
        经验255:积累并维护希望加入的公司的名单
        经验256:积累材料
        经验257:把简历当作推销工具
        经验258:找一位内部推荐人
        经验259:收集薪金数据
        经验260:如果是根据照片广告应聘,应根据广告要求调整自己的申请
        经验261:充分利用面谈机会
        经验262:了解准备应聘的招聘公司
        经验263:在应聘时询问问题
        经验264:就自己的工作岗位进行谈判
        经验265:留意人力资源部
        经验266:学习Perl语言
        经验267:学习Java或C++
        经验268:下载测试工具的演示版并试运行
        经验269:提高自己的写作技巧
        经验270:题号自己的公众讲话技巧
        经验271:考虑通过认证
        经验272:不要幻想只需两个星期就能够得到黑带柔道段位
        经验273:有关软件工程师认可制度的警告




    第11章 计划测试策略
        经验274:有关测试策略要问的三个基本问题是“为什么担心?”、“谁关心”、“测试多少?”
        经验275:有很多种可能的测试策略
        经验276:实际测试计划是指导测试过程的一套想法
        经验277:所设计的测试计划要符合自己的具体情况
        经验278:利用测试计划描述在测试策略、保障条件和工作产品上所做的选择
        经验279:不要让保障条件和工作产品影响实现测试策略
        经验280:如何利用测试用例
        经验281:测试策略要比测试用例重要
        经验282:测试策略要解释测试
        经验283:运用多样化的折衷手段
        经验284:充分利用强有力测试策略的原始材料
        经验285:项目的齿数·初始测试策略总是错的
        经验286:在项目的每个阶段,可自问“我现在可以测试什么,能够怎样测试”?
        经验287:根据产品的成熟度确定测试策略
        经验288:利用测试分级简化测试复杂性的讨论
        经验289:测试灰盒
        经验290:在重新利用测试材料时,不要迷信以前的东西
        经验291:两个测试员测试同样的内容也许并不是重复劳动
        经验292:设计测试策略时既要考虑产品风险,也要考虑产品要素
        经验293:把测试周期看作是测试过程的韵律







    注:
        软件测试经验与教训  Lessons Learned in Software Testing    Cem Kaner  James Bach  Bret Pettichord 著 韩柯 等译   机械工业出版社  中信出版社    2004


    展开全文
  • 1)测试给项目产品做关键决策时提供信息依据。2)测试员要明确自己的在项目中的使命,使命决定要做的一切。3)测试员要服务于多类客户,针对不同客户,提供不同信息。(例如:技术支持、管理者、市场人员)4)测试员...
  • 软件测试经验与教训-读后感

    千次阅读 2018-06-15 16:55:23
    在这本革命性的新书中,他们汇总了293条测试经验建议,阐述了如何做好测试工作,如何管理测试,以及如何澄清有关软件测试的常见误解。读者可直接将这些经验用于自己的测试工作中。这些经验中的每一条都...
    Lessons Learned in Software Testing 
    美 Cem kaner、James Bach、Bret Pettichord著
    本书的三位作者具有多年的测试经验,知道成功的测试都需要什么。在这本革命性的新书中,他们汇总了293条测试经验建议,阐述了如何做好测试工作,如何管理测试,以及如何澄清有关软件测试的常见误解。读者可直接将这些经验用于自己的测试工作中。这些经验中的每一条都是与软件测试有关的一个观点,后面是运用这条经验的方法、时机和原因的解释或例子。

    本书是第三次阅读,每次阅读都能获取一些新的认识和灵感。
    第一次阅读是三年前,刚入行测试不满一年,更多的是在执行,对于测试的认识和理解还比较肤浅,当时的初衷就是想了解一些测试的相关经验和理论,无意中搜索到了本书,就尝试着阅读了电子版,因为本书全部是以一条条的经验教训展开的,阅读起来非常的方便直接。隐约记得当时读完之后的感受如下:
    1、测试经验教训整理的非常全,且描述简洁,易于理解;
    2、结合之前的工作经验,尝试理解书里的全部内容,限于经验和能力,理解了大部分,有很多没有理解到位或者说理解有误;
    3、书里的大部分内容并未结合工作去实践,更多停留在理解层面,并未掌握及应用,比如第三章的测试手段和第四章的程序错误分析;
    4、书里的部分观点颠覆或者改变了我对测试的认识,打开了我的测试认知之门,比如第一章的测试员的角色和第五章的测试自动化;
    5、当时一边学,一边整理成读书笔记,记忆上比较深刻;
    第二次阅读则是一年前,我也从一名普通的测试人员升级为测试部经理,我对这本书的印象依然很深刻,同时我那些年的测试工作也在不断实践和思考着大师们的经验和教训,只希望成长的更快一些,少走一些弯路。第二次阅读本书的主要原因是要建立我们部门的培训体系,而本书又特别经典,所以又重新阅读整体了一下,给部门人员进行了相关知识培训。
    第二次阅读的感受如下:
    1、比第一次阅读的速度更快,半天就可以看完;
    2、随着自我的经验和理论积累的提高,读起来非常的轻松,绝大多数理论和经验都掌握的比较到位;
    3、个别理论和经验,因为实践的少,还停留在理解层面,希望后续有机会实践一下,同时持续思考;
    第三次阅读则是前几天,又仔细阅读了全书293条经验和教训,感悟颇多。顺带整理下自己的博客,同时把更好的知识分享给更多测试同仁,也希望大家学习后能有更大的收获。
    从我这几年的经验来看,软件测试类的经典书籍大多集中在国外,国内测试类书籍整体的技术水平和编写能力还是要稍微差一些。建议大家先从一些经典书籍入手,哪怕是翻译过来的,推荐的是软件测试(第二版)、软件测试经验与教训、谷歌测试之道、微软测试之道、快速测试、探索式测试等。学习的话分三步走:第一步,以学为主,暂时不理解的先过,大量的学习必然会带来厚积薄发;第二步,以实践为主,结合所学知识,持续不断应用到日常工作中;第三步,反复思考,理论结合实践,查漏补缺,使得自己的知识体系如螺旋状提高。终有一天,你会发现,你已经领先同龄人太多,到那时,我相信,之前所有的努力、付出、实践和思考一定是值得的。


    展开全文
  • 一、软件测试的基础 抽样:对场景/路径和数据抽样。故而,不可能穷尽所有的路径和数据。 ps: 要想在所有可能出现问题的地方穷尽测试,要么功能极其简单,要么测试员想象力差。 二、最佳实践 不相信最佳实践,在...

    一、软件测试的基础

    抽样:对场景/路径和数据抽样。故而,不可能穷尽所有的路径和数据。

    ps: 要想在所有可能出现问题的地方穷尽测试,要么功能极其简单,要么测试员想象力差。

    二、最佳实践

    不相信最佳实践,在一定条件下,一些实践比另一些要好

    三、测试在项目中的作用

    在产品交付前,及时使用【质量问题】进行了各方敲打,可能最终的问题仍然归于敲打不彻底;

    项目中各个功能离“悬崖峭壁”还有多远;

     

    注意:

    过于偏重某一方面,而忽略另一个方面;

    与产品,开发,UI等协调关注点;满足其需要;

    个人的理解:

     

    • 测试与用户在使用的根本差别

    用户: 带着问题,需求,迫切需要一个方案;

     

    • 测试与程序员,产品的差别

      区别: 客观性

      医不自治医生能给别人治病却不能给自己治

      ps:写工具/框架时,尽管自己也随时测试;感觉比程序员好一些; 但同时一定不再是一个合格的测试员了(初级测试员)

     

    四、测试的理想情况

    理想情况:

    程序员为了修改测试员找出的问题忙的团团转,使得程序员,而非测试员,成为项目的瓶颈。

    ps: 虽然是终极目标,但由于项目本身的特性(UI比重,上下游,项目本身的复杂程度等),能够实现自动化的程度不同,有些场景是必须复杂的手工才能确保万无一失的。

    测试前,中,后, 有效的提出问题;

    测试: 不仅知道可以干什么,还知道: 不能干什么,错误路径应该傻瓜式提示;

    尽早避免用户在使用产品中的消极情绪的出现;

    不会发现所有问题,故而合理分配测试时间更加重要

    五、通过测试不能保证质量

    测试通过: 在某些条件/场景下,系统没有发现异常/可正常工作。并不能保证所有场景/条件均正常。系统不可能通过测试达到100%的质量。不能证明100%正常,只能证明在一定条件下没有不正常。

    测试目标:目前条件下做到最好

    六、当心成为过程改进小组

    过程改进需要真个团队的参与与执行,并非测试员一个角色的工作

    七、测试员的素质

     

    • 测试需要自我驱动。质量的把握程度需要测试员自我驱动去“精益求精”。
    • 认识论-批判性思维。抱着“问题心态”去审视产品。
    • 推理思维。根据现有“证据”推理更多可能的问题所在,并找出更多的证据加以证明
    • 判断力。需要采用各种手段将预期结果与实际结果做对比,并对对比结果加以筛选和判断(个人理解: 测试的整个过程,某个角度可以说是对比)。
    • 视野。产品的理解,测试手段的理解
    • 复杂产品的陷入和退出。在测试特别复杂的产品时,需要适时地陷入和退出,不能指望快速理解复杂产品,可以理解30分钟后,干点别的事情。
    • 不能避免偏向,需要管理偏向。每个人都是自己的擅长与盲点,下意识。例如同样一个输入框,人员A可能输入混乱的字符,人员B可能下意识输入类似“111111”、“222222”类似的字符。测试员虽然不能避免类似的偏向,但需要适当管理,比如模拟不同偏好用户操作、利用不同方法相互印证等等
    • 观察和学习

    八、探索测试

    所有的测试都是采样,样本永远不可能完备,探索式思考在最大化测试价值中起作用。

    探索测试同时需要大量的思考和联想,才能发挥功能测试不可完成的作用。

    九、不要期望需求的完整性

    不同成熟度的产品需求,由于都是由某个/某些人提出的,必然存在可推敲,可完善,甚至需要改进的地方。

    十、测试策略的完备

     

    • 遗漏一个问题,是偶然还是必然

    如果是偶然,比如不同人员执行问题,理解问题,那么测试策略本身不需要改变;

    如果是必然,那么就要去修改测试策略本身了。

    通过遗漏的问题本身,也是一个反向检查测试策略完备性的一个方法。

     

    • 困惑也是一种测试工具

    测试中遇到的产品困惑,应该作为需求/设计方面的问题,向产品提出。测试员的困惑往往也是用户使用时的困惑。

    另外最大化减少产品使用困惑的方法,便是加入用户内测了,让真正用户,或内部人员参与上线前的内测。

    ps:测试策略中当然需要包括用户体验方面的测试

     

    • 避免测试惯例

     

        理解事物,把新信息吸收到已知信息中,同时修改已知信息来适应新洗洗的高智力过程。测试员在理解产品/功能后,在头脑中形成映射,随着对产品的了解,逐渐从各个方面提高对产品的反应能力和敏感性,并且头脑不再那么努力工作。

        对测试员来说,可能是个问题:非常了解产品后,会对产品做出更多的假设,并更少检查这些假设,以越来越窄的方式进行测试,这便是测试惯例。

    避免的方法:

    1)特别留意自己困惑和烦恼的地方;

    2)与新成员一起工作时,观察他们了解产品的反应;

     

    • 根据产品成熟度来制定测试策略

    十一、清晰报告问题,而非解决所有问题

        测试员应该清晰报告所有问题,但不要试图解决所有问题。提出bug的同时,是否要花时间去“独立”找问题的根源,应该依照实际情况而言。测试的执行过程是一个极具思考用例、执行用例、对已有问题联想的不易“中断”的过程,如果发现一个问题,需要停下来去找问题的根本原因,很可能打断甚至打乱了原本的思路,甚至错过了本该尽早发现的问题。

    十二、不要强行解决所有问题,要量力而行

     

    • 可能引入更多的问题
    • 项目周期不允许
    • 问题本次没有达到非修不可的程序

    十三、自动化测试

     

    • 自动化目标

    迅速检测新版本中不稳定的变更

    尽可能迅速暴露回归程序问题

    快速报告问题

    • 自动化范围

    范围:

    冒烟测试

    单元测试

    功能测试

    性能测试

    • 自动化实施

        不要强求100%自动化

      界定非自动化不能完成的部分

    自动化实施前要求测试员具备较好的测试策略理解和自动化实施方案,否则自动化转移测试员的注意力

     

    • 自动化vs手工测试

    自动化测试是手工测试的补充,能够完成手工测试不能完成的工作

     

    • 测试自动化是一种投资(要充分考虑)。测试自动化设计要尽可能完善。与实现尽可能解耦,避免产品升级导致的自动化成本

    十四、测试管理

     

    • 测试团队需要不同背景,不同专长的人员
    • 超出公司,制定自己的发展规划。哪怕公司倒闭,你的发展规划应该是不变的。

     

     

    展开全文
  • 软件测试经验与教训>评注 作者: 傅健,jiafu@cisco.com(转载请注明作者) 经验6: 非常赞同,注重线下沟通方式,与开发做朋友,更容易发现更多测试思路,解决好问题; 经验10: 测试过程如若不限时间,很...
  • 老美高级工程师写的这本软件测试的总结.. 涉及技术和经验 对测试和编程人员都是很有帮助的
  • 经验249:超出软件测试拓展自己的职业发展方向 转换职业,掌握一些软件开发的其他技能 经验250:超出公司拓展自己的职业发展方向 经验251:参加会议是为了讨论 参加有关软件测试或软件开发的会议时,不要只是坐在分组...
  • 一、迅速找出重要程序问题 文中,写出了迅速找出重要程序问题的几个关键点,在测试过程中,很有参考意义。 二、永不做看门人,作为质量... 以上五点,在软件测试的生涯当中,多多少少确确实实是会遇到的,我...
  • 这本书总共有11章,主要针对的是有一定测试经验的人员,而不是新手。分别从测试员本身、测试手段、程序错误分析、自动化、测试文档、管理项目等方面进行阐述。每个章节的重点都有所不同,但又不是完全独立的,彼此...
  • 为什么不让软件测试软件? 经验102.加快开发过程,而不是试图在测试上省钱 支持开发节奏的手段:自动化冒烟测试、自动化单元测试 经验103.拓展测试领域,不要不断重复相同的测试 负载测试,多人使用被测软件 ...
  • 第三章 测试手段 测试员应该做什么? 经验48.关注测试员、覆盖率、潜在问题、活动和评估的组合测试手段 测试员。进行测试的人 覆盖率。测试了哪些内容 潜在问题。测试的原因,要测试什么风险 活动。如何测试 ...
  • 第七章 程序员交互 如何程序员交互? 经验150:理解程序员怎样思考 为了更好的测试测试员必须...测试员尽早程序员接触,测试员可以提供给程序员有哪些严重的问题 经验152:提供服务 主动直接为程序员提...
  • 经验143:不要使用测试文档模板:除非可以脱离模板,否则模板就没有用 经验144:使用测试文档模板:模板能够促进一致的沟通 经验145:使用IEEE标准829作为测试文档 如果测试员要创建过程脚本化的测试用例,标准829...
  • 第一章 按测试员的方式思考 测试员的思考方式是不同的。怎么不同? 经验16.测试运用的是认识论 认识论研究如何认识所了解的东西:研究证据和推理。这是科学实践的基础。 经验17.研究认识论有助于更好测试 研究...

空空如也

空空如也

1 2 3 4 5 ... 9
收藏数 170
精华内容 68
关键字:

软件测试经验与教训