软件测试经验小总结[合集五篇]

第一篇：软件测试经验小总结

需求分析阶段：

1,增加的新功能,以及需求变动, 要考虑到测试范围的变化,务必确保没有因为变动引起测试遗漏.2,拿到需求以后,及时跟开发沟通各个功能点什么时候能够开发完成;尤其在第一个初步的版本出来以后,要跟他们确认下缺失的功能点.因为有个时候开发会遗漏功能点, 尽量想办法把问题提前发现.测试阶段：

采取冒烟测试－〉回归测试－〉系统测试，这样的测试流程。

3, 冒烟测试的时候,所有的模块都要冒烟,即便有些模块最近都没有改动过。因为模块集成后，可能因为某些模块的变动引起其他模块的功能失效

Bug相关：

４, 不同浏览器的问题, 要在标题里加注

非IE浏览器的问题,发现以后在IE里验证.５, UI的问题，一定要截图，除了方便开发定位，另外还起到纪录的作用。

6, Bug标题: 要描述清楚是什么错误.看一眼标题就可以知道标题描述的是期待结果还是实际结果。

7, Bug描述: 某某功能错误,或记录错误的, 一定要在描述里写明复现步骤，是什么错误,怎么错了.8, 激活Bug：Re-active Bug的时候,要写明是什么地方测试未通过,存在什么问题.9, 一个Bug只记录跟踪一个问题：验证Bug的时候，如果发现该Bug引发了新问题，不要再激活原Bug, 应新建一个Bug,但要在原Bug上链接到新Bug.确保一个Bug只记录跟踪一个问题。

10, 出现的Bug都有记录：Bug与开发直接沟通的,确认是一个Bug的,一定要在TFS里提交Bug，确保每个出现的Bug都有记录,方便以后跟踪.11, 每次给客户部署的版本,要记录下此版本上存在的Bug.测试阶段：

1、遇到时间紧，人手不够不能充分进行测试时，着重对新模块和修改过的模块进行测试，其他模块进行简单冒烟

2、必要的随机测试很重要，往往能发现一些按照用例跑所发现不了的bug，最好是让测试人员随机跑其他人员的模块（简单的交叉测试）

用例设计阶段：

正常流程的用例要有，最关键的是对于异常情况考虑要全面，用例覆盖面很重要，必要的时候要多次评审测试用例

需求分析阶段

尽量听取第一手需求，尽量避免从开发人员那里获得需求然后按照他们的思路来测试，这样测试人员的思路会被开发人员带着走，不便于发现隐藏问题（吃过亏的都知道

解Bug：

1、如果部署了正式环境上发现有页面问题，联系开发人员尽快解决，通过替换文件的方式而不用重新发版本，因此这种bug越早发现越好

2、项目时间紧张时候，如果遇到非常严重的bug，除了在工具里提交bug之外还要马上联系开发人员告知bug，因为有时候开发人员没时间及时的去查看bug列表

3、每个人对自己分配的测试模块要去盯开发人员，不能拖着，不然开发人员很容易遗忘）

第二篇：软件测试总结

面向对象程序的软件测试方法

在软件生命周期过程中，软件测试是保证软件质量的关键环节之一。面向对象方法学在软件工程中的引入极大地方便了软件的设计、开发和维护，为创建高可靠性的软件系统提供了重要保证。但面向对象程序的封装、继承、多态和异常处理机制等新特性却给测试带来新的挑战。一方面需要调整、改进传统的测试策略和方法；另一方面探索出适应面向对象程序特征的测试理论与技术也尤为必要。

面向对象(Object Oriented,OO)是当前计算机界关心的重点，它是90年代软件开发方法的主流。面向对象的概念和应用已超越了程序设计和软件开发，扩展到很宽的范围。如数据库系统、交互式界面、应用结构、应用平台、分布式系统、网络管理结构、CAD技术、人工智能等领域。

面向对象的定义或说明对象的定义的非常少。其初，“面向对象”是专指在程序设计中采用封装、继承、抽象等设计方法。可是，这个定义显然不能再适合现在情况。面向对象的思想已经涉及到软件开发的各个方面。如，面向对象的分析（OOA，Object Oriented Analysis），面向对象的设计（OOD，Object Oriented Design）、以及我们经常说的面向对象的编程实现（OOP，Object Oriented Programming）。许多有关面向对象的文章都只是讲述在面向对象的开发中所需要注意的问题或所采用的比较好的设计方法。看这些文章只有真正懂得什么是对象，什么是面向对象，才能最大程度地对自己有所裨益。这一点，恐怕对初学者甚至是从事相关工作多年的人员也会对它们的概念模糊不清。

1、面向对象的基本概念

(1)对象。

对象是人们要进行研究的任何事物，从最简单的整数到复杂的飞机等均可看作对象，它不仅能表示具体的事物，还能表示抽象的规则、计划或事件。

(2)对象的状态和行为。

对象具有状态，一个对象用数据值来描述它的状态。

对象还有操作，用于改变对象的状态，对象及其操作就是对象的行为。

对象实现了数据和操作的结合，使数据和操作封装于对象的统一体中

(3)类。具有相同或相似性质的对象的抽象就是类。因此，对象的抽象是类，类的具体化就是对象，也可以说类的实例是对象。

类具有属性，它是对象的状态的抽象，用数据结构来描述类的属性。

类具有操作，它是对象的行为的抽象，用操作名和实现该操作的方法来描述。

(4)类的结构。

在客观世界中有若干类，这些类之间有一定的结构关系。通常有两种主要的结构关系，即一般--具体结构关系，整体--部分结构关系。

①一般——具体结构称为分类结构，也可以说是“或”关系，或者是“is a”关系。

②整体——部分结构称为组装结构，它们之间的关系是一种“与”关系，或者是“has a”关系。

(5)消息和方法。

对象之间进行通信的结构叫做消息。在对象的操作中，当一个消息发送给某个对象时，消息包含接收对象去执行某种操作的信息。发送一条消息至少要包括说明接受消息的对象名、发送给该对象的消息名（即对象名、方法名）。一般还要对参数加以说明，参数可以是认识该消息的对象所知道的变量名，或者是所有对象都知道的全局变量名。

类中操作的实现过程叫做方法，一个方法有方法名、参数、方法体。消

2、面向对象的特征

(1)对象唯一性。

每个对象都有自身唯一的标识，通过这种标识，可找到相应的对象。在对象的整个生命期中，它的标识都不改变，不同的对象不能有相同的标识。

(2)分类性。

分类性是指将具有一致的数据结构(属性)和行为(操作)的对象抽象成类。一个类就是这样一种抽象，它反映了与应用有关的重要性质，而忽略其他一些无关内容。任何类的划分都是主观的，但必须与具体的应用有关。

(3)继承性。

继承性是子类自动共享父类数据结构和方法的机制，这是类之间的一种关系。在定义和实现一个类的时候，可以在一个已经存在的类的基础之上来进行，把这个已经存在的类所定义的内容作为自己的内容，并加入若干新的内容。继承性是面向对象程序设计语言不同于其它语言的最重要的特点，是其他语言所没有的。

在类层次中，子类只继承一个父类的数据结构和方法，则称为单重继承。

在类层次中，子类继承了多个父类的数据结构和方法，则称为多重继承。

在软件开发中，类的继承性使所建立的软件具有开放性、可扩充性，这是信息组织与分类的行之有效的方法，它简化了对象、类的创建工作量，增加了代码的可重性。

采用继承性，提供了类的规范的等级结构。通过类的继承关系，使公共的特性能够共享，提高了软件的重用性。

(4)多态性(多形性)多态性使指相同的操作或函数、过程可作用于多种类型的对象上并获得不同的结果。不同的对象，收到同一消息可以产生不同的结果，这种现象称为多态性。

多态性允许每个对象以适合自身的方式去响应共同的消息。

多态性增强了软件的灵活性和重用性。

面向对象方法的基本思想是一：面向对象方法是一种运用对象、类、封装、继承、多态和消息等概念来构造、测试、重构软件的方法。

二： 面向对象方法是以认识论为基础，用对象来理解和分析问题空间，并设计和开发出由对象构成的软件系统（解空间）的方法。由于问题空间和解空间都是由对象组成的，这样可以消除由于问题空间和求解空间结构上的不一致带来的问题。简言之，面向对象就是面向事情本身，面向对象的分析过程就是认识客观世界的过程。

面向对象方法从对象出发，发展出对象，类，消息，继承等概念。

面向对象方法的主要优点是：符合人们通常的思维方式；从分析到设计再到编码采用一致的模型表示具有高度连续性；软件重用性好。

面向对象软件测试的特点是: 1.掌握代码检查、走查与评审的基本方法和技术； 2.掌握白盒测试和黑盒测试的测试用例的设计原则和方法； 3.掌握单元测试和集成测试的基本策略和方法；

4.了解系统测试、性能测试和可靠性测试的基本概念和方法； 5.了解面向对象软件和WEB应用软件测试的基本概念和方法； 6.掌握软件测试过程管理的基本知识和管理方法； 7.熟悉软件测试的标准和文档；

8.掌握QESuite软件测试过程管理平台和QESat/C++软件分析和工具的使用方法。

第三篇：软件测试总结

1.软件测试定义：由人工或自动方法来执行或评价系统或系统部分的过程，以验证它是否满足规定的需求，或识别出期望的结果和实际结果之间的差异。2.软件测试的分类：

测试对象或范围分类：需求评审、设计评审、单元测试、程序测试、系统

测试、文档测试、Web应用测试、客户端测试、数据库测试等；

测试目的分类：集成测试、功能测试、压力测试、性能测试等等； 静态测试、动态测试； 白盒测试、黑盒测试。3.软件测试的基本流程与原则

基本流程：

测试用例设计-输入数据、预期结果； 测试执行-输入数据执行被测对象； 检查实际输出与预期结果。基本原则：

开始测试时认定软件有错，测试要证明有错； 测试应该由独立的测试团队来完成； 测试设计必须设计对应的预期输出；

要对合理、不合理（有效、无效）输入数据都进行测试； 检查软件的完备性、多余； 完整保留测试文档；

一个被测对象中有错误的概率与已发现错误的个数成正比。4.Beizer测试成熟度级别：

0级：没有区分测试与调试；

1级：测试的目的是证明软件能用； 2级：测试的目的是证明软件不能用；

3级：测试的目的不是为了证明什么，而是为了降低软件使用风险； 4级：测试是一种智能训练，能够帮助专业人员开发出更高质量的软件。5.软件测试与软件工程，软件过程的关系：

软件工程：在给定的条件下（成本、时间）开发出高质量的软件产品。软件生产过程的特性决定了软件产品中不可避免包含有错误。软件测试则是尽可能多地发现错误，从而保障软件产品的质量。6.McCall的质量因素：

产品修改：

可维护性，灵活性，可测试性 产品转移：

可移植性，可复用性，互操作性 产品运行：

正确性，易用性，可靠性，效率，完整性 7.软件质量困境

软件质量必须足够好：存在价值

软件产品无法完美：需要消耗过多的资源、时间、成本

软件开发需要在两个极端之间进行平衡：软件足够好的同时又不完美。8.质量控制、质量保证和质量管理

软件质量控制其实是基本方法，通过一系列的技术来科学地测量过程的状态。如缺陷率、测试覆盖率等。

软件质量保证则是过程的参考、指南的集合，如ISO9000、CMM/CMMI等，着重内部的检查，确保已获取认可的标准和步骤都已经遵循。

软件质量管理则是实际操作的思想，质量管理控制和协调组织的质量活动，包括质量控制、质量保证和质量改进。9.WebApp应用的属性：

网络密集型应用；并发性；大负载量；性能；高可靠性、高可用性；安全性-内容敏感；

10.软件评审的目的，评审度量及其应用

评审的目标在于：尽早发现软件过程中的错误，防止错误传递、蔓延至后续活动，防止错误转化为缺陷。

准备工作量Ep-实际评审会之前所需工作量； 评估工作量Ea-实际评审所花费的工作量 返工工作量Er-修改评审所发现错误的工作量 工作产品规模WPS-评审对象的规模

发现的主要错误数Errmajor-多于预期的改错工作量的错误数目 发现的次要错误数Errminor-少于预期的改错工作量的错误数目 总评审工作量Ereview = Ep+Ea+Er 错误总数Errtot = Errmajor+Errminor 错误密度：评审的每单位工作产品发现的错误数Ed = Errtot / WPS 错误密度数值的含义：较小（产品质量非常好或评审不够彻底）；较大（产品质量存在缺陷）

11.软件测试计划：描述对计算机软件配置项、子系统、系统进行测试的计划安排，内容包括测试的环境、测试工作的标识及测试工作的时间安排。

软件测试报告：是对计算机软件配置项、软件系统或子系统，或与软件相关项目执行合格性测试的记录 12.软件测试活动

制订测试计划（测试分析员）

测试设计（测试设计人员）－方案设计 测试及测试用例设计 测试过程

桩模块、驱动模块设计

测试实施（测试设计员）－实现测试设计 单元测试（测试员）集成测试（测试员）系统测试（测试员）

评估测试（测试设计人员）

13.无向图的相关定义：

连接性：节点ni、nj是连接的，当且仅当ni、nj在同一条路径上。组件：图的组件是相连节点的最大集合

图G的圈复杂度V（G)＝e－n＋2p，其中e为G的边数，n为节点数，p为组件数。14.图覆盖：给定一个关于图G的准则C的测试需求集合TR，测试集合T在图G上满足准则C当且仅当对TR中每个测试需求tr，path(T)中至少存在一条测试路径p满足tr。

简单路径：如果从ni到nj的一条路径中，除了始节点和终节点可以相同外，没有任何节点出现次数多于一次，则该路径为简单路径。

主路径：如果从ni到nj是一条简单路径，并且它不作为任何其他简单路径的子路径出现，则称之为主路径。

主路径覆盖（PPC）准则：TR包含图中每一条主路径。

指定路径覆盖（SPC)：TR包含一个测试路径集S，S为指定参数。15.白盒测试方法

白盒测试：根据被测对象的内部结构和运行机制来设计测试用例的方法，又称为结构测试、逻辑驱动测试、覆盖测试

被测对象的独立路径至少覆盖一次； 所有逻辑取值测试[真、假]； 循环边界测试；

检查内部数据结构、边界条件。16.黑盒测试方法

黑盒测试方法又称功能测试方法、数据驱动测试方法，测试设计时不考虑被测对象的内部结构，以检查系统功能（功能的正确、完整、逻辑流程、人机界面、文档内容、系统安装/初始化）

以被测对象的外部特征为测试依据。17.模糊测试方法

模糊测试方法：构造大量的随机数据作为系统的输入，从而检验系统在各种数据情况下是否出现问题。

18.增量测试：单元测试、调用依赖的模块集成测试，逐步扩展直到形成整个软件系统。

19.突击测试：所有模块一次性集成为一个完整的系统，然后进行完全测试。20.等价类划分：

等价类划分基于对输入或输出数据情况的评估，划分成两个或多个子集（等价类），然后从每个子集中选取一定的代表进行测试的测试用例设计方法。21.极限测试

极限编程：利用轻量、敏捷的开发过程，使开发人员能够更快地完成应用程序的开发。强调频繁测试、测试驱动的方式保证软件质量。

极限测试：为满足极限编程思想和过程而设计的一套测试策略和流程，原来的测试技术、方法均可以使用 22.配置项测试的内容

功能: 适合性

准确性：功能的准确与精度要求 互操作性：与外部设备、系统的接口 安全保密性：数据访问的可控制性 可靠性: 成熟性：容错处理、平均无故障时间

容错性：边界条件、功能、性能的降级情况、误操作模式、故障模式 易恢复性：自动修复能力/时间、平均宕机时间、平均恢复时间、恢复能力等 易用性

易理解性：功能描述清晰、准确；界面含义精确

易学性：在线帮助、帮助定位、各类手册的易学、易用 易操作性：数据的有效检查、解释信息明确、界面切换 吸引性：人机界面定制 效率

时间特性：响应时间、平均响应时间、响应极限时间、吞吐量、平均吞吐量、极限吞吐量，多任务并行测试

资源利用：大量并发任务下I/O设备利用、极限负载下I/O设备的负载、大量并发任务下用户等待时间、内存使用情况、数据传输能力等

维护性

易分析性：运行状态数据易分析 易变更性：软件的可配置、修改能力 易测试性：变更之后的易测试情况 可移植性

适应性：不同软件、硬件环境的适应能力 易安装性：安装、配置的复杂程度、难以程度 共存性：与其他软件协同的能力 易替换性：版本的替换难以程度 依从性

以上所有特性遵循标准、规范的情况测试

23系统测试：系统非功能性测试，以检验系统在超常数据规模或负载下，线程、CPU、内存资源的利用和响应时间、数据传输等性能指标是否满足要求

24.测试计划

确定测试充分性要求：覆盖范围、覆盖程度 确定测试终止要求； 确定测试所需资源； 确定测试的软件特性； 确定测试技术、方法； 确定测试准出条件； 确定测试进度计划； 测试风险分析。

25.测试设计：测试设计人员、测试程序员

测试用例设计：依据测试特性； 获取测试数据；

确定测试顺序：资源、被测特性； 获取测试资源：软硬件、工具； 编写测试程序； 建立测试环境； 撰写测试设计说明。

26.测试总结：

测试分析员－测试报告

总结测试计划、测试说明的变化情况； 异常终止时测试未覆盖范围； 未能解决的测试问题； 总结测试结果（发现问题）； 编写测试报告；

根据问题报告、测试记录，编写测试问题报告。

27.软件可靠性：在给定的运行时间内和给定的系统配置环境下，运行给定的软件功能时所 表现出来的质量能力 28.系统性能指标

系统资源利用率：分析性能指标，改善性能系统行为指标 请求响应时间：一次请求完成时间

事务响应时间：一个事务所有请求完成的总时间

数据吞吐量：单位时间内服务器接收、发送的数据量。

29.验收测试：用户执行的、使用真实数据进行的测试，依据需求规格中的确认标准进行测试。回归测试：验证已测试过的内容不受变更影响，确认变更没有引入新的错误。

30.α测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操 作环境下进行的测试。

Beta测试由软件的最终用户在一个或多个客户场所进行，开发者通常不在Beta测试的现场。

31.WebApp测试关注的主要内容 Web内容测试 界面 构件

导航测试 安全性 性能

32.测试用例（Test Case）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。

33.软件生存期定义：从软件产品设计到软件被淘汰的时间段。又称软件生命周期、生存周期。进一步划分为两个阶段：开发阶段和维护阶段（40%+60%）。

34.软件安全定义：一种软件质量保证活动，他主要用来识别和评估可能对软件产生负面影响并促使整个系统失效的潜在灾难。

35.软件评审的目标在于：尽早发现软件过程中的错误，防止错误传递、蔓延至后续活动，防止错误转化为缺陷。36.V模型

优点：既有底层测试又有高层测试。底层：单元测试。高层：系统测试。

将开发阶段清楚的表现出来，便于控制开发的过程。当所有阶段都结束时，软件开发就结束了。

缺点：容易让人误解为测试是在开发完成之后的一个阶段。

由于它的顺序性，当编码完成之后，正式进入测试时，这时发现的一些bug可能不容易找到其根源。

实际中，由于需求变更较大，导致要重复变更需求、设计、编码、测试，返工量大。37.W模型：

优点：

将测试贯穿到整个软件生命周期中，且除了代码要测试，需求、设计等都要测试。更早介入软件开发中，能尽早发现缺陷并修复。

测试与开发独立起来，并与开发并行。缺点：

对有些项目，开发过程中根本没有文档产生，故W模型无法使用。

对于需求和设计的测试技术要求很高，实践起来很困难。

从N0中某节点开始到Nf中某节点结束的一条路径称为一条测试路径。

1.软件缺陷：（符合下列规则的叫软件缺陷)：

１）．软件未达到产品说明书的功能

２）．软件出现了产品说明书指明不会出现的错误

３）．软件功能超出产品说明书指明范围

４）．软件未达到产品说明书虽未指出但应达到的目标

５）．软件测试员认为难以理解、不易使用、运行速度缓慢、或者最终用户认为不好

2.单元测试：单元测试是对软件设计的最小单元——模块进行正确性检验的测试工作，主要测试模块在语法、格式和逻辑上的错误。3.回归测试

指软件系统被修改或扩充（如系统功能增强或升级）后重新进行的测试，是为了保证对软件所做的修改没有引入新的错误而重复进行的测试。

4.等价类：指某个输入域的子集合，在该子集合中，各个输入数据对于揭露程序中的错误都是等效的。

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

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

看了<<软件测试经验与教训>>第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）不同阶段，拥有不同心态；