标签：
【定义】
软件测试是使用人工或者自动手段来运行或测试某个系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。
它是帮助识别开发完成（中间或最终的版本）的计算机软件（整体或部分）的正确度 、完全度和质量的软件过程。
【内容】
软件测试主要工作内容是验证(verification)和确认(validation )。
验证是保证软件正确地实现了一些特定功能的一系列活动，即保证软件做了你所期望的事情。(Do the right thing)
确认是一系列的活动和过程，目的是想证实在一个给定的外部环境中软件的逻辑正确性。即保证软件以正确的方式来做了这个事件(Do it right)
软件测试的对象不仅仅是程序测试，软件测试应该包括整个软件开发期问各个阶段所产生的文档，如需求规格说明、概要设计文档、详细设计文档，当然软件测试的主要对象还是源程序。
【目的】
软件测试的目的是想以最少的人力、物力和时间找出软件中潜在的各种错误和缺陷，通过修正错误和缺陷提高软件质量，回避软件发布后由于潜在的软件缺陷和错误造成的隐患带来的商业风险。
| 软件测试的出发点就是质量，软件测试的一切工作应该围绕质量而开展，测试是保证质量的重要手段之一，测试本身就是为质量服务的。 |
?
?
【原则】
所有的软件测试都应追溯到用户需求，测试人员要始终站在用户的角度去看问题、去判断软件缺陷的影响，系统中最严重的错误是那些导致程序无法满足用户需求的缺陷。
有了质量标准，才能依据测试的结果对产品的质量进行正确的分析和评估，例如，进行性能测试前，应定义好产品性能的相关的各种指标。同样，测试用例应确定预期输出结果，如果无法确定测试结果，则无法进行校验。
在软件开发生命周期早期引入的错误占软件过程中出现所有错误（包括最终的缺陷）数量的50%～60%。，缺陷存在放大趋势。如需求阶段的一个错误可能会导致N个设计错误，因此，越是测试后期，为修复缺陷所付出的代价就会越大。
在进行实际测试之前，应制定良好的、切实可行的测试计划并严格执行，特别要确定测试策略和测试目标。测试计划应包括：所测软件的功能，输入和输出，测试内容，各项测试的进度安排，资源要求，测试资料，测试工具，测试用例的选择，测试的控制方法和过程，系统的配置方式，跟踪规则，调试规则，以及回归测试的规定等以及评价标准。
要根据测试的目的，采用相应的方法去设计测试用例，从而提高测试的效率，更多地发现错误，提高程序的可靠性。除了检查程序是否做了应该做的事，还要看程序是否做了不该做的事；不仅应选用合理的输入数据，对于非法的输入也要设计测试用例进行测试。
抓住80/20原则可以有针对性的优化测试，在最短的时间内发现更多的问题，同时也能保证测试者对测试过程的整体把握。特别是当项目时间紧、复杂度高时，可以分时间、阶段、模块解决问题，是有效的解决问题的方式之一。
由于心理因素，人们潜意识都不希望找到自己的错误。基于这种思维定势，人们难于发现自己的错误。因此，软件开发者应尽量避免测试自己的产品，应由第三方来进行测试，当然开发者需要在交付之前进行相关的自测。一定程度的独立测试（可以避免开发人员对自己代码的偏爱），可以更加高效的发现软件缺陷和软件存在的失效。但独立测试不是完全的替代物，因为开发人员也可以高效的在他们的代码中找出很多缺陷。在软件开发的早期，开发人员对自己的工作产品进行认真的测试，这也是开发人员的一个职责之一。
穷尽测试是不可能的，应结合当前实际情况当满足一定的测试出口准则时测试就应当终止。
修改程序后，应该重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。
软件产品质量评价国际标准ISO 14598 把软件质量定义为：软件特性的总和，软件满足规定或潜在用户需求的能力。上述定义反应如下3个方面的问题：
软件测试只是质量保证工作中的一个环节，软件质量保证与软件测试是软件质量工程的两个不同层面的工作。
质量保证是通过预防、检查与改进来保证软件质量，采用全面质量管理和过程改进的原理来开展质量保证工作，主要关注软件质量的检查与测试，主要着眼于软件开发活动的过程、步骤和产物；软件测试是通过执行软件来对过程中的产物（开发文档和程序）进行走查，发现问题，报告质量。
具体说来，软件测试盒软件质量保证的区别体现在：从性质上看，软件测试属于技术性工作，而软件质量保证属于管理性工作；从对象上看，软件测试的对象是软件产品，而质量保证的对象是整个软件过程，覆盖公司层面的各个领域；从手段上看，软件测试以事后检验为主，而软件质量保证则强调缺陷的预防。
| 质量不是测试人员测试出来的，糟糕的早期设计结合最优的后期质量保证往往颇费力气，仍然打造不出用户满意度高的产品。 |
?
?
如何组织一个测试团队，应当视企业的人力资源而定。
一般，一个比较健全的测试组，所具有的角色包括测试组长、实验室管理人员、自动化测试工程师、资深测试工程师、初级测试工程师。
测试组长：业务专家，负责项目的管理、测试计划的制定、项目文档的审查、测试用例的设计和审查、任务的安排、与项目经理和开发组长的沟通等
实验室管理人员：设置、配置和维护实验室的测试环境，主要是服务器和网络环境等
资深测试工程师：负责产品设计规格说明书的审查、测试用例的设计和技术难题的解决，主要参与数据库、系统性能和安全性等技术难度较高的测试
自动化测试工程师：负责测试工具的开发、测试脚本的开发等
初级测试工程师：执行测试用例和相关的测试任务，侧重功能测试用例的设计和执行
软件测试与软件开发具有天然的联系。软件测试的输入是软件开发的产品，测试输出的结果需要开发人员相应处理，处理后的结果再次需要测试人员的验证。因此，软件测试与软件开发如影相随，互为服务对象。
开发人员和测试人员需要不断的沟通合作，才能持续优化项目。对于开发人员而言，利用测试人员对需求的理解，越早将测试提到项目周期，帮助就越大；对于测试人员而言，搞好和开发人员的关系，则可以在测试方向上获得更多的帮助：编写测试用例时询问可能遗漏的用例，在测试即将结束时询问测试是否有风险。
识别风险是试图系统化地确定对项目计划的威胁，识别风险的一个方法是建立风险条目检查表，检查表包括：
风险分析活动的目的是辅助项目组建立处理风险的策略，一个有效的策略必须考虑如下3各问题：
【测试费用有效性】
测试的策略由商业的经济利益来决定，对风险测试过少，会造成软件的缺陷和系统的瘫痪，测试的过多，会增加测试成本。下图的测试费用-质量曲线可以形象的表示测试费用的有效性：
【测试成本】
【缺陷探测率】
缺陷探测率DDP是另一个衡量测试工作效率的软件质量成本的指标。
缺陷探测率DDP＝Bugs（tester）/ （Bugs（tester）+ Bugs（customer））
缺陷探测率越高，也就是测试者发现的错误多，发布后客户发现的错误就越少，降低了外部故障不一致成本，达到节约总成本的目的，可获得较高的测试投资回报率。
软件测试过程一般包括:测试计划、测试设计、测试准备、测试执行、测试评估和缺陷跟踪等阶段，每个阶段都有一系列的任务。
测试过程具有以下几个特点：
映出了测试活动与分析设计活动的关系。从左到右描述了基本的开发过程和测试行为，非常明确的标注了测试过程中存在的不同类型的测试，并且清楚的描述了这些测试阶段和开发过程期间各阶段的对应关系。
但V模型存在一定的局限性，它仅仅把测试作为在编码之后的一个阶段，是针对程序进行的寻找错误的活动，而忽视了测试活动对需求分析、系统设计等活动的验证和确认的功能。
W模型强调：测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、设计等同样要测试，也就是说，测试与开发是同步进行的。W模型有利于尽早地全面的发现问题。
但W模型也存在局限性。在W模型中，需求、设计、编码等活动被视为串行的，同时，测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。这样就无法支持迭代的开发模型。
H模型将测试活动完全独立出来，形成了一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来。测试准备和测试执行分离，有利于资源调配，降低成本，调高效率。有组织、结构化的独立流程，有助于跟踪测试投入的流向。H模型还充分体现了测试过程（不是技术）的复杂性。
?
【单元测试】
【集成测试】
【确认测试】
【系统测试】
【验收测试】
【产商测试】
开发方测试通常也叫"验收测试"或"a测试"，在软件开发环境中，开发者检测与证实软件的实现是否满足软件设计说明或软件需求说明的要求。
【用户测试】
在用户的应用环境下，用户检测与核实软件实现是否符合自己预期的要求。β测试通常被认为是用户测试，把软件有计划地免费地分发到目标市场，让用户大量使用、评价检查软件。
【第三方测试】
由第三方测试机构来进行的测试，也称独立测试。
【静态测试】
静态测试又称为静态分析技术，不执行被测试软件，对需求分析说明书、软件设计说明书、源程序做结构检测、流图分析、符号执行等找出软件的错误。
【动态测试】
通过输入一组预先按照一定的测试准则构造的实例数据动态运行程序，而达到发现程序错误的过程。
【白盒测试】
白盒测试也称为结构测试或逻辑驱动测试，是通过对程序内部结构的分析、检测来寻找问题，检查程序的结构及路径是否正确，检查程序的内部动作是否按照设计说明的规定正常进行。
【黑盒测试】
黑盒测试又称功能测试，通过运行程序发现其缺陷和错误。黑盒测试是对程序接口进行的测试，它只检查程序功能是否能按照规格说明书的规定正常使用，程序是否能适当地接收输入数据产生正确的输出信息，并且保持外部信息的完整性。
【灰盒测试】
介于白盒和黑盒测试之间，关注输出对于输入的正确性，也关注程序的内部结构，但没有白盒测试那样详细、完整。
【检查内容】
代码检查包括桌面检查，代码审查和走查等方式，主要对以下内容进行检查：
【检查方式】
【检查项目】
在静态结构分析中，测试者通过使用测试工具分析程序源代码的系统结构、数据结构、数据接口、内部控制逻辑等内部结构，生成函数调用关系图、模块控制流图、内部文件调用关系图等各种图形图表，清晰地标识整个软件的组成结构，便于理解，通过分析这些图表，检查软件有没有存在缺陷或错误。主要包括控制流分析、数据据流分析、接口分析、表达式分析。
代码质量度量法即根据ISO 9126质量模型的6个方面（即功能性、可靠性、易使用性、效率、可维护性、可移植性）对软件进行的动态测试方法。白盒测试的动态测试包括功能确认与接口测试、覆盖率分析、性能分析、内存分析等。动态测试通常在静态测试之后进行。白盒测试的动态测试要根据程序的控制结构设计测试用例，其原则是：
序号 | 输入条件（数据） | 划分等价类 |
1? | 规定了取值范围 值的个数 | 一个有效等价类 两个无效等价类 |
2? | 规定了输入值的集合 规定了"必须如何"的条件 | 一个有效等价类 一个无效等价类 |
3? | 是一个布尔量 | 一个有效等价类 一个无效等价类 |
4? | 输入数据的一组值（n个），并且程序对每一个输入值分别进行处理 | n个有效等价类 一个无效等价类 |
5? | 规定必须遵守的规则 | 一个有效等价类（符合规则） 若干个无效等价类 |
6? | 在确知已划分的等价类中，各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步地划分为更小的等价类 | |
序号 | 输入条件（数据） | 输入边界值数据 |
1? | 规定了取值范围 | 刚刚达到这个范围 刚刚超越这个范围 |
2? | 规定值的个数 | 最大个数、比最大个数大1 最小个数、比最小个数少1 |
3? | 根据规格说明书的每个输出条件，使用 原则1、2 | |
4? | 输入或输出是个有序集合 | 集合的第一个、最后一个元素 |
5? | 程序中使用一个内部数据结构 | 内部数据结构边界上的值 |
6? | 分析规格说明，找出其他可能的边界 | |
?
错误推测法就是基于经验和直觉推测程序中所有可能存在的各种错误，有针对性地设计测试用例的方法。错误推测法的基本思想是列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据它们选择测试用例。
因果图法是从用自然语言书写的程序规格说明的描述中找出因（输入条件）和果（输出条件），通过因果图转换成判定表。
判定表是分析和表达多逻辑条件下执行不同操作的情况的工具。
适合使用判定表设计测试用例的条件：
正交试验法从大量的试验数据中挑选适量的、有代表性的点，从而合理地安排测试的一种科学的试验设计。正交试验法在软件测试中是一种有效的方法，例如在平台参数配置方面，每个参数就是一个因子，参数的不同取值就是水平，这样我们可以采用正交试验法设计出最少的测试组合，达到有效的测试目的。正交试验法有如下优点：
一个程序的功能说明通常有动态说明和静态说明组成，动态说明描述了输入数据的次序或转移的次序，静态说明描述了输入条件与输出条件之间的对应关系。对于较复杂的程序，由于存在大量的组合情况，仅用静态说明组成的规格说明对于测试来说是不够的，必须用动态说明来补充功能说明。功能图法是用功能图形形象地表示程序功能说明，并机械的生成功能图的测试用例。
功能图方法实际上是一种白盒和黑盒相混合的用例设计方法，要用到逻辑覆盖和路径测试的概念和方法。
现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。这种在软件设计方面的思想也可以引入到软件测试中，可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，同时使测试用例更容易理解和执行。
?
自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。通常，在设计了测试用例并通过评审之后，由测试人员根据测试用例中描述的规程一步步执行测试，得到实际结果与期望结果的比较。在此过程中，为了节省人力、时间或硬件资源，提高测试效率，便引入了自动化测试的概念。
这条原则是所有这四条原则中的"老大"，也是在工程中最容易被忘记和忽略的，它或多或少的都影响到其它几条原则。
测试用例的覆盖边界定义更清晰，则测试结果对产品问题的指向性更强。
测试用例间的耦合度最低，则彼此之间的干扰也就越低。
上述这些优点所能带来直接好处是，测试用例的调试、分析和维护成本最低。每个测试用例应该尽可能的简单，只验证你所要验证的内容。
通常我们会在开发的初期（Scrum每个Sprint的头两天）用Word文档或者OneNote的记录产品的需求、功能描述、以及当前所能确定的任何细节等信息，勾勒将要实现功能的样貌，便于团队进行交流和细化，并在团队内达成对产品功能共识。但随着产品开发深入，团队会对产品的功能有更新的认识，产品功能也会被更具体细化，在一个迭代或者Sprint结束的时候最终实现的功能很可能是A+。如此往复，在不断倾听和吸收用户的反馈，多个迭代过后，原本被描述为A的功能很可能最终变为了Z。这是时候再去看看曾经的Word文档和OneNote页面，它们仍然记录的是A。之所以会这样 ，是因为很少有人会去以及能够去不断地去更新那些文档，以准确地反映出功能当前准确的状态。
成本永远是任何项目进行决策时所要考虑的首要因素，项目中的测试也是如此，对成本的考虑也应该客观和全面的体现在测试的设计、执行和维护的整个阶段中。
测试中的成本按其时间跨度可以分为：单次投入成本和多次投入成本。例如：编写测试用例可以看作是单次投入成本，因为编写测试用例一般是在测试的计划阶段进行（Scrum每个Sprint的开始阶段）的，虽然后期会有小的改动，但绝大多数是在一开始的设计阶段就基本上成型了；
这条原则实际上是单次投入成本和多次投入成本原则 - 针对自动化测试用例的扩展和延续。在编写自动化测试代码时，要重点考虑如何使得测试结果分析和测试调试更为简单，包括：用例日志、调试辅助信息输出等。
从用户需求出发，了解功能设计背景。针对不同的功能特性会有多种用例，而每个用例有可以有多个不同的应用场景，所以，从需求到功能、从功能到用例、从用例到场景，可以逐步分解，形成一对多的关系，最后为每个应用场景设计一个到多个测试用例。
针对功能测试用例，要从业务流程图着手，把业务需求转化为流程图。
逐层细化业务流程，并根据业务流程设计测试用例
UML（Unified Modeling Language）即统一建模语言，它是一种定义良好、易于表达、功能强大且普遍适用的建模语言。UML视图包括结构图和行为图。结构图描述系统及其组成部分的静态关系，常包括类图、对象图、包图、综合结构图、组件图、部署图等。行为图描述系统的动态信息，包括用例图、状态机图、活动图、和交互作用图。根据测试方法选择不同的视图能够有效帮助我们设计测试用例。
| 很多应用中，功能点都存在一定的交叉，如果合理设计用例，不仅可以完成目标功能点测试，还可以覆盖其他交叉点的测试。 |
?
功能测试主要分为以下几个阶段：测试准备、测试计划、测试用例设计、测试执行、测试总结。
接到一个项目任务时，不要立即去执行测试用例，而是要先做好测试准备工作。
了解做什么、为什么做、用了什么新技术等问题，对于测试人员，了解这些对发现更多缺陷、出现问题时进行有效分析将有很大帮助。
从用户需求到产品需求说明书，再到用户接口规格说明书等一系列项目过程文档都是测试对象，问题发现的越早越好，可以减少不必要的麻烦，同时更好的保证质量。
分析业务功能点，画出功能图，方便理解需求、确定范围。
功能图描述了完成的主要功能点，而各功能点又有着一定的联系。可以通过流程图来抽象出功能点之间的数据流动及端到端的业务过程。
根据项目相关文档，需要定义测试范围、测试策略、人员分配、软硬件配置、进度表以及测试过程每个阶段需要达到的目标
测试用例必须能够使测试人员能够明确理解，并能够依据测试用例的描述执行测试。其次，测试之前必须明确功能逻辑，熟知每个测试用例的场景。
测试用例主要包括用例编号、用例描述、前提条件、输入数据、测试步骤和期望结果6项关键内容：
用例的组织要方便测试人员执行测试用例，应设计一套良好的用例编号体系。
用例描述应使用最精简的文字，描述出用例的全貌。让测试人员不用看测试步骤，只看这个描述就可以知道这个用例是描述哪个场景、哪个功能点。
一个测试用例一般是针对一个特点的场景，而需要测试的场景发生时通常会有一些铺垫场景，即测试用例的前提，如软硬件环境配置、权限设置，数据准备。
一个测试用例可以有一个或多个输入数据，也可以无输入数据。
测试步骤是测试用例的主体，一个测试用例由一个或多个步骤组成，每个步骤之间有一定的前后关系。每个步骤必须表述详细，描述清晰，用于规范、严谨而又客观，最基本的要求是能够使其他人理解，并能正确的执行编写者希望的操作。
期望结果是测试执行对执行结果进行对比的标尺，是测试是否通过的判断依据。测试结果必须保证其正确性。
测试用例是经过设计、思考的，力图涵盖所有的功能点，所以它是测试执行的依据，但是因为测试的深度有限，很难覆盖所有的路径，加上需求变更，测试用例很难及时更新，而且只生搬硬套测试用例执行，效果不好。手工测试时，仅把测试用例作为一个参考即可，不要过分依赖它，我们可以进行更多的发散测试，加上不断的思考，效果要好得多。
测试用例的描述，有个基本原则是不要写得太复杂，所以功能交叉的测试用例，一般不会写得太复杂。但测试执行时，要特别注意多种条件组合及其逻辑先后顺序，要学会从多个单一的测试用例中，基于整体考虑而生成更多的测试用例，这也是熟悉业务的测试人员比不熟悉的测试人员发现更多测试点的原因之一。
功能测试一般分为走查、基本功能验证、回归测试。
正式测试之前，可以安排少量熟悉需求的人员走查一遍开发提交的测试版本，把基本需求、主要功能等走查一遍。如果有很多影响测试的问题，可以拒绝测试，让开发人员继续进行单元测试。
参照测试用例，适时的查找相关文档来测试，在此测试的过程中，可以由表及里，由局部到整体进行测试。
基于主要功能点和项目整个阶段、特别是最近修复的严重缺陷，反复验证测试用例
| 空或0值是数值的临界值，也常用作标记软件中某种特殊运行状态（如初始状态）或数据状态（如初始默认值），因此置零是软件边界测试重点，也是容易出现错误的地方，类似的还有空格、null、最大值、最小值等数据。 |
?
测试的执行，通常按测试用例来进行，但测试用例的设计编写是依据产品规格说明书、需求规格说明书、界面设计规范等。写测试用例时难免有考虑不到的地方，因此反复阅读说明文档，也许会有一些新的思路和启发。在项目后期，回归测试阶段，容易思维定势、疲惫，这是可以把这些文档拿出来，再看一下功能点是否覆盖，覆盖到的是不是和需求一致，没有偏差。
变动是一个项目过程中不可少的部分，而这些变动，通常是通过讨论的方式定下来的，因此会有一些文档记录和邮件。反复阅读这些邮件和文档记录，可以更深入的理解项目。
每个人的思路、考虑的角度和操作习惯各不相同，因此发现的问题就会不一样。多阅读别人的缺陷可以拓宽思路，看多了，也会不自觉把多种思路集中到一起，慢慢得应用到测试实践中了。
功能测试对测试人员来说大多是黑盒测试，只有开发人员最清楚哪个函数调用哪个函数、哪块单元测试不够充分、哪个逻辑结构比较复杂，多和他们沟通，可以知道哪里还需要多关注一下。
特别在回归测试、验收测试阶段，除了验证前面发现的缺陷，还要重视那些与缺陷相关的模块。一个底层参数的变动，可能会引起很多相关功能的问题，继而造成缺陷的遗漏。
一段代码的改动，需要开发人员和测试人员去识别。开发人员知道改动的地方会被哪些模块调用或者会引起哪些模块的变化，但由于时间紧、任务重、很难做好单元测试，因此开发人员要通知测试人员需要关注的测试点。
一个项目的成功不是把缺陷全报出来，而是在有限的代价下达到预期的质量。按计划进行的项目，主要功能的质量在一定程度上决定了产品的好坏。在项目工期紧张时，全部走完所有测试用例是很难的，可以基本功能为主线，做好相关测试用例的执行，保证不会发生大的质量事故。
| 在测试后期，测试人员可能对质量已经很有信心，受思维和经验的局限性，可能仅限于此。若此时，在产品发布之前，调动其他组的员工参与限时测试并给予奖励，必然能有效减少软件缺陷带来的风险，提高产品质量。 |
?
测试发现软件中的缺陷，避免问题在软件发布之后还遗留在系统里，实际上就是事后检查，确保所发布的产品满足用户需求，并具有较高的质量。但是当我们做测试时，问题已经发生了，我们只是去找问题，找到问题后让开发人员修正问题。修正问题需要返工，造成人力成本的浪费。如果是代码问题，返工比较少；如果是设计、需求的问题，就需要重新定义需求、修改设计，然后再修改代码。除了开发人员返工之外，测试人员在开发修改之后还要进行回归测试，会占用更多的人力成本。因此，我们要降低开发成本，就必须减少缺陷，根本方法就是预防问题的产生，从一开始就将事情做对、做好。
自软件开发项目启动之时，从需求定义、系统设计到编程，就不断引入问题，质量也就取决于这个过程中引入多少问题。在这个工程中，引入的问题越少，质量就越高；引入的问题越多，质量就越低。要想减少问题、避免缺陷的引入，就要抓住每个入口，让每个入口符合标准、满足事先预定的要求。而在软件开发中就要做好需求评审、设计评审和代码评审等工作，以保证开发的各个环节都能获得高质量的阶段性成果。
通过软件缺陷根本原因分析（Root Cause Analysis，RCA），可以找到问题发生的根本原因。对缺陷进行分类统计，了解缺陷主要发生在哪些模块、哪一类缺陷最多或排在前三位缺陷的是哪几类，制订相应的防护措施，以避免今后发生类似的问题。需记录的缺陷信息包括：软件缺陷产生所属模块、缺陷来源（如需求设计文档、技术设计、源代码等）、缺陷被发现的阶段、缺陷所表现出的现象（如不清晰或错误的需求规范、不正确的行为、数据不一致、计算错误、设计不合理等）、测试跟踪（如新引进的缺陷、迟发现的缺陷、回归缺陷等）、缺陷对应的测试用例ID。
只有找到问题的根本原因，才能消除问题产生的根源。主要从人员、技术、流程、业务四个方面出发，通过和团队讨论，一起回顾产品测试过程，就能发现问题的根本原因。
真正的原因被挖掘之后，找到解决的办法就不难了。当然，找到解决办法还不够，还需要设定相应的目标，跟踪这个改进过程，直至达到目标，如果没有达到效果，就需要进行新一轮的根本原因分析。在软件测试管理中，这是一个持续分析、持续改进的过程。
不同的测试人员对于测试软件的看法、实践经验都会有所不同，即使对于同一个软件，测试人员发现的缺陷也相差甚远，因此周期性进行头脑风暴，在一起讨论测试的系统、测试可能疏忽的问题，可以集众人智慧，促成知识融合，加快测试进度，保证测试质量。
在测试时间较紧的情况下，使得测试人员可能疲于"奔命"，这种情况下，测试人员学习的速度可能比较快，但是也可能因为疲劳、时间紧而放弃利用学过的知识及时调整测试的方法或细节。因此在项目进行中，权衡项目时间与测试质量是必须要考虑的。可以考虑给测试人员一定的时间自由轻松的去思考，去完善测试，从而持续优化质量。
项目的难度、测试人员的工作经验直接影响测试开展的时间、方式和效果。如果项目比较简单、测试人员经验丰富，在项目计划和测试设计阶段可完成大多数测试的设计，相反，如果测试项目难度大、测试人员经验不足，在测试计划阶段就要思索如何学习要测试的系统、如何有效的测试等问题。
敏捷开发要求在短时间内开发出高质量的软件产品，并且符合客户需求。极限编程（XP）就是敏捷型开发的一种。与传统开发方法相比，敏捷开发有如下特点：
以上两个特点很好的概括了敏捷开发方法的核心思想：适应变化和以人为中心。
敏捷开发可理解为在原有软件开发方法基础上的整合——取其精华，去其糟粕。因此敏捷开发继承了不少原有方法的优势。
【敏捷开发的理念】
【遵循的原则】
针对敏捷开发方法的敏捷测试不同于以往针对传统开发模式的测试，在敏捷团队中，测试是整个项目组的"车头灯"，它告诉大家现在到哪了，正在往哪个方向走。测试人员为项目组提供丰富的信息，使得项目组基于这些可靠的信息作出正确的决定。不仅是测试人员要保证质量，而是整个项目组的每一个人都要对质量负责。测试人员不跟开发人员纠缠错误，而是帮助他们找到目标，共同为达到项目的最终目标而努力。敏捷测试也需要高度迭代工作、频繁得到客户的反馈，需要动态调整测试计划、测试的执行。并且，敏捷测试人员参与到了更多的敏捷生产活动中，积极的影响了团队做出的决定和计划。
根据公司项目目前采用的敏捷开发模式，相应的敏捷测试建议采用以下流程：
需求和设计具体来说一般包括：
在测试初期，测试人员要学会做静态测试，做好需求分析，做好对设计逻辑的分析。测试人员要更多的思考需求的可实现性，将自身作为第一用户积极参与项目和系统的需求分析，设计和开发。积极地参与前期工作，并迅速反馈给设计和开发其静态测试结果。要尽早的开始测试，不要等待到功能完全做好才开始。
在敏捷开发的过程中由于是根据每个用户故事（user story）来估算时间的，开发人员将对本次迭代所需要的完成的user story进行评估。开发人员可以和客户直接沟通，来确定每个user story的优先级。
测试人员根据已审核通过的需求和设计编制测试计划，设计测试用例。在前面提到的两种文本中，功能设计文本是主要依据。测试的这两个文本也要被项目经理和开发人员审核。
在传统项目开发测试中，测试工程师需要花很多时间设计测试用例，这些测试用例具有详尽的数据准备、输入数据、严格的步骤和期望结果。对于敏捷开发团队来说，编写并维护一份系统功能和测试方法相结合的测试用例是个高效的方法。没有测试用例的测试是不可靠的，敏捷团队更需要设计易于阅读和测试的测试用例，来对系统功能及其测试方法的依据进行描述。适用于敏捷开发的测试用例应具有以下特点：
在敏捷方法中，测试有两种：单元测试和接收测试。单元测试是由开发人员来完成的，接收测试是由客户代表来完成。
在daily build版本给测试前，开发首先要做单元测试，提前告知软件中的薄弱环节，帮助测试人员调整测试重点。做单元测试的好处是可以提高版本质量，减轻测试的工作量，减少浅层次的bug的发生率，使测试人员能够将更多的精力投入到寻找深层次的bug上面。
测试人员的验证测试从总体上说就是将上一步设计的测试用例按计划付诸实施的过程。这一阶段的测试必须在周密的计划下进行。这种计划性首先体现在开发和测试的相互协调配合，根据产品的架构和功能模块的依赖关系，按照项目的总体计划共同推进。从测试的过程来看，测试执行的一开始可以是针对部分功能的，之后可以逐步扩展。接着开始采用迭代的过程完成测试任务，即将测试任务划分为多个周期，一开始可以做些关键的功能性测试，可以对代码中的可复用部分（组件，构件）做完整的测试。接着的迭代周期可以做边缘化的功能测试和其他测试，最后的几个迭代应该用于回归测试，和关键的性能和稳定性测试。
在实施运行测试过程中，需要关注以下几项工作：
为方便衡量项目的进度，测试可每天测试完毕后提供测试的bug趋势，即将每天新生成的Bug数和每天被解决的Bug数标成一个趋势图表。一般在项目的开始阶段新生Bug数曲线会呈上升趋势，到项目中后期被解决Bug数曲线会趋于上升，而新生Bug数曲线应下降，到项目最后，两条曲线都趋向于零。PM会持续观察这张图表，确保项目健康发展，同时通过分析预测项目Bug，对于每个版本的bug，开发都应该想想为什么会出现这样的问题，特别是很低级的bug，对于同类的bug，是否可以避免。
在执行测试阶段中，测试人员需要对已有的测试用例进行及时的维护。通常以下两种情况下要新增一些测试用例：一是对于当初测试设计不周全的领域，二是对于外部的Bug（比如从Beta客户报告来的），没有被现有测试用例所覆盖。当产品的功能设计出现更改时（敏捷项目中功能设计的更改频繁），所涉及的测试用例也要相应地修改，使测试用例保持和现有的功能需求同步。
在项目进行过程中，测试人员需要不断积累经验，不断补充、完善各类目的Common Sense标准。在以后的项目中要严格按照它来执行测试，保证以前出现过的失误在以后的项目测试中不会再出现。在保证项目质量的同时，不断积累新的经验。
为更好地保证软件质量，规避风险，必须加强对中间版本的控制。例如，客户要求或者计划周五要提交版本，则周三一定要提交一个中间过程的版本进行测试，也就是控制中间版本，避免所有的工作都压到后期最紧急的时候去完成。以前的项目中出现过项目前期很轻松，到后期bug越来越多，开发人员和测试人员都异常忙碌，经常加班的情况。为减少后期工作量，规避风险，建议开发进行Daliy Build，或者按照完成一个feature就进行一次build，针对这个feature进行测试，这样就可以有效避免后期bug越来越多的状况发生，后期工作量也就会相应减少，项目的质量也会更有保证。
在每次发布版本之前，测试人员要根据待发布的版本情况编写版本说明，使客户对发布的版本情况一目了然。版本说明主要包括三方面的内容：Fixed，New Features，Known Problems。其中，Fixed部分写明此版本修复了上个版本中存在的的哪些比较大的bug；New Features部分写明此版本新增加了哪些功能；Known Problems部分写明此版本尚存在哪些比较大的问题，有待下个版本改善；或者列出需求不太明确的地方，有待客户给出明确答复意见，在下个版本中完成。
采用敏捷开发模式的项目中，客户对于需求的变更很频繁。因此，需求管理是十分必要和重要的工作。整个项目进行过程中，对不断变化的需求，一定要作跟踪，每次的需求变更都要有相应的历史记录，方便后期的管理和维护工作。可将每次的变更整理记录到需求跟踪文档中，并使该文档始终保持最新更新的状态，与需求的变化保持同步。
在项目开发的末期，可以开展"bug大扫除"活动。划出一个专门的时间段，在这期间所有参与项目的人员，集中全部精力，搜寻项目的Bug。尽管这是一个测试活动，但参与者并不仅限于测试人员。项目经理，开发人员甚至于高层管理人员都应参加，如同全民动员，目的是要集思广益。要鼓励各部门，领域交叉搜索，因为新的思路和视角通常有助于发现更多的Bug。为调动积极性，增强趣味性，可以适当引入竞争机制，比如当活动结束时，评出发现Bug最多，发现最严重Bug的个人，给以物质和精神奖励。测试活动可以分专题展开，比如安全性、用户界面可用性、国际化和本地化等等。
敏捷测试不能简单的理解为测得更快，绝对不是比以前用更少的时间进行测试，也不是将测试的范围缩小或将质量降低来减少测试任务。敏捷测试应该是适应敏捷开发方法而采用的新的测试流程、方法和实践。由于敏捷开发方法中迭代周期短，测试人员应尽早开始测试，包括及时对需求、开发设计的评审，更重要的是能够及时、持续的对软件产品质量进行反馈。简单的说，敏捷测试就是持续地对软件质量问题进行及时的反馈。
?
【测试方法】
【测试要点】
【用户手册的测试】
【联机帮助的测试】
软件缺陷是指系统或系统部件中那些导致系统或部件不能实现其应有功能的缺陷。一般定义缺陷有以下5条原则：
测试过程中，当发现某个界面不正确，某个功能不正常时，我们可以判为发现bug了。一般来说，bug会存在于下列情况之中：
用户体验不仅要求在满足功能需求的情况下简化操作、尽量减少用户界面新元素的个数，还包括用户视觉甚至是听觉等方面的感官体验。用户体验目标总结为：
找到bug后，发现bug的测试人员不应该满足于记录bug的表面症状，重要职责是发现bug的根本原因。常用的隔离分析方法如下：
例如，要隔离一个出现在某个平台上某个浏览器上的功能性bug，可以通过下面列出的矩阵分析记录：
平台/浏览器 | IE8(32bit/64bit) | Chrome3 | Firefox3.6 |
Win XP SP3 | ? | ? | ? |
Win vista SP2 | ? | ? | ? |
Win7（32bit/64bit） | ? | ? | ? |
假如一个bug是因为经过了A、B、C、D操作以后产生的，我们可以对操作步骤进行分段隔离找出一个最简单的步骤。
如果发现了一个bug，不能确定是不是bug时，可以采用对比法，检查下系统中其他类似的功能是如何设置的，这个bug是否是系统自身的特性。
Bug描述的基本要求是分类准确、叙述简洁、步骤清楚、实际结果描述准确、复杂问题有据可查（截图或其他形式的附件）。基本要求如下：
问题描述时，建议分几步描述：模块或功能点=>测试步骤=>期望结果=>实际结果=>其他信息
Bug提交后，测试人员要时刻准备向开发人员展示所发现的bug，同时需要说服开发人员，报告中的bug都是真实存在且需要解决的。在这个过程中，软件测试人员一定要为下面的几种情况做好准备：
报告这个bug的最好方法是向开发人员展示它，这样他们可以真实的看到并了解我们是如何操作应用的，如何和应用交互的。测试人员应避免在最短时间内报告大量不能重现的bug。
面对这种问题，测试人员要有耐心，同时要保留测试数据和截屏等信息。
有时因为配置问题或需求理解不一致等问题，开发人员不能重现问题，或与测试人员存在不同的看法。对于同一个测试结果，测试人员认为是错的，而开发人员认为是正确的，为了避免这种情况，最好找出客户原始的真实的需求是什么、我们真正看到了什么、发生了什么、从这几个方面说明我们的观点。
发现bug时不要嘲笑开发人员，不要大声嚷嚷，并请留意另外一种极端：测试人员与开发人员关系很好，可能会导致测试的时候"手下留情"，这对项目也是一种伤害。
?
?
?
标签：
原文地址：http://www.cnblogs.com/lazytest/p/5545571.html
