来源：https://www.cnblogs.com/wintersun/p/5297352.html
常见的SQA的架构
我们持续演化，对于将软件 QA 浓缩到所有开发任务完成后的测试阶段的方法，它们的问题在于：会给团队带来巨大成本并将整个项目置于高风险之中。在测试阶段，开发人员竭尽全力确保他们的代码具有极少的缺陷。然后测试人员努力揭示软件中每个可能的缺陷，而经理和客户希望他们拥有适合向市场发布的软件。
仓促的开发可能会为团队节省片刻的时间，但是，如果有一些重大开发问题没有从一开始就考虑到，最终可能导致需要投入更多的时间。结果是浪费了大量团队资源来修复和重新设计代码，而不是将这些资源投入到更有用的事情上。软件团队人员内心里对整个始末一目了然，但面对着唠叨的客户、严格的销售团队，以及一些自我感觉编写了无缺陷的软件的开发人员，软件团队确实很难将 QA 撇在一边而只顾着完成代码。
有几种实践方法，包括需求审核、代码审核和演练、基于会议的测试、基于风险的测试等.
在开始每个新开发阶段之前审核软件需求，这样做能够最大限度地减少缺陷并满足客户的需求。在实现之前审核需求，这样做有助于考虑潜在的变化，克服在项目的整个寿命中可能发生的误解。团队必须与客户一起反复检查所有应实现的业务领域细节。需求审核也可以使用原型和领域模型来完成。当开发团队在开始实际实现之前完成这个小任务时，他们的项目或开发迭代会获得良好的开局。通过确保在实现之前所有利益相关者都达成共识，并且每位团队成员都意见一致，客户和管理人员可确信开发人员将在开发周期结束时交付正确的成果。
而“代码审核和演练”听起来像很简单，但代码审核是软件开发中最有效的实践之一。它对减少缺陷数量以及增强代码和软件设计的质量具有直接影响。这消除了在未来的版本中执行重大的代码重构和清理的需求。
依据项目需求和实现细节，团队可能认同简单的编码和设计原则。团队成员应共同遵守这些原则，而且只要开发一项新功能，一个或多个团队成员（除了作者）应审核新代码，并搜索所有编码或设计错误。 这种做法可在许多方面为团队带来帮助，包括提高代码质量和设计，最大限度地减少缺陷，并预防它们。另外，它还使得整个团队能够深入了解彼此的工作，轻松移交工作，并提高团队对不同软件组件和功能的认知。团队协作验证和证明代码的质量和设计的实现方法。它们从同事那里获得直接反馈。这么做可谓一举两得：代码质量增加了，团队的认知和项目责任也增加了。
第三个实践是“基于会议的测试”，表示将测试负载分解为会议，每个会议有一个任务（一种希望从测试会议获得的明确规定的结果）。每个会议有一个既定的时间范围（从 20 到 40 分钟），测试人员在执行测试会议期间不应中断。
这就像将测试人员放在一个测试房间一段时间，让测试人员专注于查找特定软件特性或功能的缺陷。在会议期间，测试由一组测试案例引导执行，测试人员也可以执行探索性测试。因此，基于会议的测试是正式测试方法与测试创新的一种组合，因为它提供了测试人员房间来进行探索和获得直觉思维，留出了时间和自由空间来发现不常见的缺陷，或者通过折腾软件来进一步了解它。 会议期间，测试人员应将软件的行为记录在案，获取快照，以及写下软件在特定输入和设置下的行为。会议结束时，将与团队领导或技术经理讨论会议脚本。从他们的讨论中，他们找出所认为的正常行为和不正常行为，然后基于讨论创建缺陷报告。
另一种则是“基于风险的测试”，因为在开发流程中进行了一些更改，开发团队通常拥有同一个软件的许多常用版本。一种重要的 QA 实践是在每个主要版本之后彻底测试软件。另一方面，在每个版本中都对整个软件运行全面的回归测试既耗时又很难实现。但是，仅测试更改的功能或笨拙地删减测试案例套件是不安全的。一段代码可能解决了一个缺陷，但也可能破坏了代码中的其他内容。
基于风险的测试方法采用了折中方式。它的基本理念是按降序对软件功能和失败模式排序，从最重要或风险最高到值得拥有的功能和简单的风险（一个类似工具是 FMEA：失败模式和影响分析）。如果测试人员在严格的时间限制下测试某个新版本时手头有这个列表，他就可以集中精力确保新引入的更改不会破坏其他任何内容。然后就可以轻松地确保更改不会破坏软件中的任何最重要的功能，因而不会发生任何最严重的风险。
我们期望是
测试和开发同时进行。编写一些代码，马上进行测试和构建。接着，编写更多的代码，继续测试。更好的是，在你编码的时候或者编码之前，就计划好你的测试。测试不是一个独立分开的过程，它是开发的一部分。质量不等同于测试；要想有高质量的产品，就要把开发和测试紧密捆绑在一起，直到不分彼此。
保证质量，预防胜于检查：
质量来自开发，而不是测试。为了拓宽开发环节，我们可以把测试融入到开发中去。我们已经建立了一个超高效的增量流程，只要有一个增量被证明缺陷太多，我们就可以回滚这些错误。我们不仅预防了很多产品级问题，还大大地减少了那些为确保消除“召回级别”缺陷而安排的测试人员的人数。
衡量软件质量的常用指标
软件开发实践过程中常用的几个衡量软件质量的指标，包括源代码行数、代码段/模块/时间段内的平均Bug数、代码覆盖率、设计/开发约束等
源代码行数（SLOC）
计算源代码行数也许是最简单的办法。它主要体现了软件的规模，并为项目的发展和规划提供了有用的信息。比如，如果我们每月计算一次源代码行数，那么就可以绘制一个项目成长图。当然，这种方式并太不可靠，原因是重构和设计阶段等因素会对此产生影响，但是至少可以为项目描绘一个趋势。首先，使用代码行数之和无法有效评估一个项目的实际进度，因为它更注重行为而不是结果。最终产品在多大程度上依赖于代码的性能和质量，这也是代码行数无法说明的。因此，聚焦于此实际上是非常有限的工作效率测量方式。SLOC无法表明要解决的问题的复杂性，也不能以可维护性、灵活性、扩展性等等因素来说明最终产品的质量。说到质量，它反而可能起到负面作用。通过重构、使用设计模式会减少代码行数，同时提升代码质量。代码量大，可能意味着有更多不必要的代码、更高不必要的复杂性、更加僵化难懂。
代码段/模块/时间段内的Bug数
缺陷跟踪对于更好的测试和维护是必不可少的。通过缺陷跟踪，我们可以利用报告工具（如Mantis）计算出每个代码段、模块或者特定时间段内的bug数量。凭借这些数据，我们可以尽早的查出和解决缺陷起因。Bug数量可能会作为衡量开发人员效率的指标之一，但是必须非常谨慎。如果把这项指标看得太重，那么开发人员和测试人员可能会成为敌人。在一个高效率的公司，所有的员工必须团结协作。为了更好地实现评估，bug可以被分为低、中、高等，因为这些缺陷的重要性和解决成本不是相同的。
代码覆盖率
代码覆盖率反映了程序当中源代码被测试的程度。有许多自动化工具可以完成该功能，比如Cobertura。代码覆盖率不能完全代表单元测试的整体质量，但是可以反映出测试覆盖率的问题。它可以和其他测试指标一起作为软件质量的指标。同时，单元测试代码、集成测试场景和结果应该经常地被审查。
有效的代码度量模型应具备以下特征：
- 与组织的目标一致：代码度量模型的底线要与组织的要求一致，和业务相关的东西会体现在规范里。在支付宝，代码安全规范、敏感信息处理规范被作为代码质量最基本的要求。
- 有针对性：要做针对性分析，比如对线上故障的研发原因进行分析，分析的规则会有周期性变动的，但不要太频繁，而且规则会随着组织的成熟度而改变。
- 可操作性：要对度量维度做进一步分解，比如测试要有明确的检查点，覆盖要完整，可重复运行。支付宝就制定了具体的度量维度，从多个维度对系统加以度量。
- 有工具支持：这不是必要条件，工具不能解决所有问题！能用工具最好，不行的话就人工检查。工具检测维度要按照优先级和操作性，逐步增加精细化维度。这一点上，支付宝将一些编码规则的检查放入了持续集成工具之中，以求尽早检查、频繁检查。
设计/开发约束
在软件开发过程中，存在许多设计约束和准则，其中包括：
- 类和方法的长度
- 单个类里方法和属性的个数
- 方法或者构造函数的参数个数
- 代码中的魔数、字符串用法等等
- 注释行比例等
研发流程
整个研发做到了类似于火车发车的发布过程：
- 各个bundle在有着自己的需求、开发、测试计划，相互独立。
- 主项目制定发布计划，确定集成窗口和发布时间点。
- 在集成窗口时间bundle可以自主提交集成。
- 集成提交需要走流程，包括填写checklist、代码检查、bug统计、提前编译预集成包进行测试等。这就避免了明显的集成问题遗漏到集成环境中。
- 集成期间的集成包每天出一个或者两个，避免了测试人员不断拿包回归的情况。
- 集成窗口对于时间要求严格，赶不上计划或者质量不达标的bundle不予集成。这就是火车不等人的原则。
- 以上机制保证了手机淘宝每天都有一个候选包，可以随时进行灰度发布，并且灰度发布单独拉取一个依赖配置分支，不影响集成窗口。
- bundle的独立，依赖配置的独立保证了手机淘宝可以并行多个发布计划，各个bundle可以按照需求自主决定搭乘哪个发布计划进行发布。
- 目前项目节奏为两个星期发布一个版本。如果需要还可以更快的进行发版。最短只需要1个小时就可以发一个新版。
所有的项目生命周期都有相应的平台工具支持，如下图：
质量保证手段
有了高效稳定的流程，剩下的事情就是如何保证产品在快节奏的持续交付下的保持很高的质量。质量保障上面手机淘宝研发团队做了几方面事情：
1. 流程方面
1）创建了提测单、集成单、发布单等流程。建立了标准，并依托平台自动检查，提高了交付的质量。
2）建立持续集成体系，不但能提早发现更多的问题，而且提升了测试人员拿到的包的质量。
3）建立线上线下监控分析体系。
2. 包稳定性方面：
1）bundle阶段根据项目进度自己控制提测包的频率，集成阶段每日验证DailyBuild即可，所以解决了之前测试同学不断安装新版本的包的问题。
2）研发阶段的包内部支持环境切换，这实现了只构建一次，环境根据配置切换的梦想。测试时手机上只需要安装一次包即可完成多种环境下的测试。
3. 自动化测试与测试工具方面
1）引入多种静态扫描引擎，并定制多种规则：适配规则、Crash规则、框架约定规则、安全规则等，并且不断地将测试阶段、线上问题等总结抽象成新的扫描规则补充进入扫描引擎。
2）在测试阶段包种插入相应的测试SDK，并且这种SDK不会侵入应用代码，所以只需要在发布的时候去掉测试SDK即可。测试SDK可以在测试人员（包括外包适配测试人员）正常使用过程中自动检测并上报问题，这样就可以在同一的平台上看到研发过程中的质量情况并进行修复。
3）自动化平台方面也在根据测试经验不断的进化，在整个研发过程中自动化测试一直在执行，不仅可以提高产品稳定性，也可以发现性能、电量等非功能问题。
4）mock工具、验证平台等辅助测试工具也提升了测试人员的效率。
4. 线上线下监控分析
1）线下质量数据、线上业务问题、舆情反馈等信息统一汇集到平台上进行统一的分析告警，不仅能快速的发现问题，而且能通过数据分析能够帮助快速定位和解决问题。
2）根据平台中的数据，可以用经验推动流程的优化、补充测试用例、添加扫描规则、增加自动化场景、催生新的测试工具等，这样可以使经验形成闭环，使质量保障工作更加高效。
在敏捷开发过程下质量保证
对于目前的开发架构来说，一个用户故事，涉及这四个点，可以从这四个点入手来进行质量保证。如何做呢？单元测试就开发人员处理了；代码审查，测试人员可以参与和监督，其实就是要保证：将开发任务与提交到Git的代码进行关联。这样一来，当测试人员检查开发任务的时候，就可以找到改变过的代码。我曾经试过从这些代码里面查看逻辑，找到分支场景，补充到测试用例里面。
Scrum中测试人员价值应当体现在：
- 预防缺陷的手段，提高洞察力，增强业务知识。 缺陷在需求、开发前期就已经存在了，关键是用什么手段去挖掘出来预防。在sprint前获取到的需求，测试人员可以站在客户角度上来阐述自己的观点，与开发人员进行充分交流和讨论，使自己在用户体验、业务逻辑等等方面的经验充分体现出来。
- 在开发过程中，测试人员除了站在客户的角度进行测试，还应当提供更全面的质量反馈，包括代码质量的检查，这个可以通过redmine与git双向关联来做检查依据。目前整个过程测试人员尚未参与代码编写，应当参与并推进代码评审，将代码问题及时反馈出来；并且参与或者推进单元测试，检查单元测试状态（确保单元测试达到80%以上覆盖率，帮助开发人员开发出具有良好可测试性的代码），自始至终将质量问题及时反馈出来，保证在sprint的整个过程中质量受到足够的关注，提高质量改进的持续性和可视性。
- 随着版本任务的增加，每个版本回归测试的成本增加，可以适当考虑部分稳定功能进行自动化测试。当然，这是远景。
- 持续改进、反馈，充分发挥每个版本统计报告的作用，对缺陷进行分析，总结出一些规律，帮助开发人员建立良好的习惯，改进代码的质量。
敏捷中的QA日常活动
从迭代到发布，敏捷测试的生命周期各个阶段QA的活动主要有：测试分析，测试自动化策略分析、框架构建等，故事测试，迭代计划会议和客户演示，测试自动化的维护和执行等。如下图示：
QA通常不是仅仅工作在某个迭代，而是并行的同时工作在多个迭代：要对当前迭代的故事进行验收测试、探索性测试，和开发人员结对实现测试自动化；还要和业务人员结对分析下一个迭代的故事，编写验收标准和测试用例。
在单个迭代内部，伴随着故事生命周期，QA的活动有哪些呢？用户故事生命周期包括以下几个阶段：故事分析、故事计划、故事开发、故事验收、故事测试／探索性测试、系统测试和客户演示。QA参与故事的整个生命周期，在每个阶段都会发挥作用。
- 故事分析阶段：需求澄清，业务场景和验收测试的确认
- 故事计划阶段：拆分测试任务，在每个故事开发估算基础上考虑测试的时间和估算
- 故事开发阶段：和开发人员结对实现自动化测试，和团队沟通发现的问题和缺陷
- 故事验收阶段：开发人员开发完故事后，QA和业务分析人员要在开发机器上进行验收，以提供快速的反馈；同时还要对测试覆盖率（单元测试、组件集成测试、功能测试）进行确认和提出反馈
- 故事测试／探索性测试阶段：执行自动化验收测试，执行探索性测试，强调会阻碍故事发布的因素，和团队就测试覆盖率进行沟通，为发现的缺陷添加自动化测试
- 系统测试和客户演示阶段：执行端到端的系统测试，执行业务或集成的用户测试场景，和团队及客户就功能特性的质量和稳定性进行沟通，参与给客户演示功能和特性
正如前面提到的，在每个阶段，QA除了要独立进行测试，通常还需要跟不同的角色结对，包括业务分析人员、开发人员、以及客户。
- QA与业务分析人员结对：通常在业务分析师分析用户故事的时候，QA要与业务分析人员结对编写验收标准。通过与业务分析人员结对，QA能够更好的理解领域知识，从而有利于定义合适的测试用例；QA从测试角度添加的验收测试用例可以帮助整个团队对产品功能性有更好的理解。
- QA与开发人员结对：QA和开发人员分别能给团队带来不同的技能集，认识到这一点很重要。作为一个团队，最好通过平衡不同的技能集来获得共同的目标。这对于传统的瀑布式团队来说是一个很重要的心态改变。通常在实现测试自动化的时候，QA与开发人员结对是比较理想的方式。这样结对实现的自动化测试质量相对较高，有测试意识较强的QA参与能够保证自动化测试测得是真正需要测试的部分，而开发人员的编码能力有利于写出简洁可维护的自动化测试代码。另一方面，QA通过与开发人员结对，编码能力也会相应有所提高，而开发人员通过与QA结对，测试意识也会增强，更有利于编写质量较高的产品代码，更有利于形成全功能团队。
- QA与客户结对：客户是业务领域专家，通过与客户结对，QA能够更好的从终端用户的角度理解系统，从而定义或者增加更多的端到端的测试用例；一旦QA理解了领域知识和终端用户的观点，其业务价值分析能力会有所提高，在团队需要的时候可以承担业务分析角色；在用户验收测试（UAT）阶段，QA通过与客户结对，帮助客户熟悉使用系统，在必要时可以帮助客户解决一些系统问题。
敏捷QA的这些日常活动，的确反映出敏捷QA的日常工作内容和方式都跟传统开发模式下的测试人员有很多不同。
敏捷QA与传统测试人员有何不同。我们分别从团队构成、测试阶段、工作方式、关注点、业务知识来源以及发布计划制定几个方面，来看看敏捷QA与传统测试人员有哪些不同：
传统测试人员 | 敏捷QA |
|---|---|
单独的测试团队 | 多角色开发团队的一员 |
在开发流程后期才开始测试 | 测试贯穿于整个开发流中 |
通常是独立工作 | QA和不同角色进行结对 |
被当作最后也是唯一的质量保证 | 关注并强调风险 |
缺乏与业务人员的直接沟通 | 和业务人员直接沟通 |
没有机会参与发布计划制定 | 参与发布计划的制定 |
从上表的对比可以看到，敏捷QA是特殊的，主要体现在：
- 敏捷QA是提出建议者而非看门人，需要在参与的每个阶段提出自己的建议，而不是等到开发流程最后来对系统进行验证；不仅要验证开发设计是否满足需求，还要发现需求是否能真正体现业务价值，分析是否有不恰当或缺失的需求。比如说，敏捷QA在跟业务人员结对编写验收标准的时候发现故事分析过程中漏掉的需求，在跟开发人员结对过程中跟开发人员讨论某个测试放在哪层实现比较合理等。
- 发现风险，并将风险与团队及客户沟通。QA参与整个开发流程，对系统整体的认识和把握可以说是团队里边最全面的，因此也更容易看到系统存在的风险。
- 及时向团队提供关于产品质量的反馈，便于调整。在每个迭代结束时候，QA需要分析统计该迭代的缺陷，并结合自己通过测试对系统质量的了解，及时跟团队反馈，讨论分析质量下降的原因以尽快作出改进，或总结质量上升的经验，鼓励团队再接再厉。
- 在制定产品和版本的发布计划的时候，QA可以根据自己对产品质量的了解，从测试人员独有的视角提出一些关键的建议。
- QA通过参与开发流程的每个阶段，能够协助团队从内部提升质量，让质量融入到产品开发中来。比如：在故事验收阶段对测试覆盖率的确认。
这些特殊性对敏捷QA也提出了更高的要求，需要做到：
- 具有丰富的产品知识和对用户业务目标的准确了解
- 对不同系统和数据库所用到的技术知识的了解
- 和不同角色以及客户进行有效沟通
- 主动验证质量目标并及时说出自己的想法
- 编写测试计划，列出需要执行的活动并进行估算
- 自动化测试的能力和对测试工具的基本了解
- 在团队内部进行知识分享，协助整个团队参与到测试活动中来
- 持续提供并获取反馈
敏捷软件测试的七个关键成功要素
包括使用团队整体参与的方法、采用敏捷测试思维、自动化回归测试、提供并获取反馈、构建核心实践的基础、与客户合作、保持大局观等。
1. 使用团队整体参与的方法
当整个开发团队负责测试和质量问题，你会拥有很多不同的技能集合和经验等级来处理测试可能发生的问题。测试自动化对于技能高超的开发人员来说不是大问题。当测试置于团队的优先权，任何人都参与测试任务，团队才会设计可测试的代码。使测试人员真正成为开发团队的一部分意味着向他们提供支持和训练他们适应敏捷开发的快节奏。他们需要时间掌握新技能以便与开发和客户团队紧密协作。
如果你管理一个敏捷团队，帮助团队使用团队整体参与的方法。记住质量，而不是速度，才是敏捷开发的目的。团队需要测试人员帮助客户理清需求，转化为指导开发的测试，提供发布优秀产品的唯一观点。确保测试人员能够把技能和长处转移到团队其他成员身上。确保他们不是局限于一种角色，如只做手动测试。确保当他们需要帮助时（可能需要极大的勇气），团队成员能够提供。反过来也是如此。测试人员应该随时准备帮助那些需要他们帮助的队友。
如果你是敏捷团队中的测试人员，并且计划会议和设计讨论没有邀请你，或者业务用户正在独自定义故事和需求，那你应该站出来和团队的其他成员交流。和开发人员一起参与会议，并提议尝试“三方协作”，即测试人员、开发人员和业务专家。谨慎地提供反馈并帮助客户提供例子。让你的问题成为团队的问题，让他们的问题成为你的问题。请你的同事采用团队整体参与的方法。
2. 采用敏捷测试思维
我们提醒敏捷测试人员丢掉一直以来的“质量警察”思维。现在你在敏捷团队中，开发人员参与测试，测试人员可以做任何事情以帮助团队生产最优秀的产品。敏捷测试态度是前瞻性的、创造性的、欢迎新思想、乐于承担任何任务。敏捷测试人员不断磨练自己的技能，随时准备协作，相信直觉，希望帮助团队和业务成功。我们并不是说你应该披上超级测试王的斗篷，去保护世界免受缺陷的危害。在敏捷团队中不存在狂妄自大。团队成员分享你对质量的追求。关注团队目标，帮助每一个更好地工作。使用敏捷准则和价值观指导你。不断尝试最简单的方法来满足测试需要。勇敢地寻求帮助和实验新想法。关注于产生价值。尽可能多的直接交流。灵活地应对变化。记住敏捷开发以人为中心，我们应该享受工作。当对此怀疑时，回顾敏捷价值和准则来决定该怎么做。
敏捷测试思维的一个重要部分是不断想办法改进工作。成功的敏捷测试人员持续地磨练技能。读好书、博客和文章以获得新想法和技能。参加本地的用户组会议。加入邮件列表讨论以获得问题或者新想法的反馈。如果你的公司没有付钱让你参加一个很好的会议，那么把你的经验写成报告在免费的会上作交换。对测试和敏捷开发社区进行反馈也会对你有益。实验新的实践、工具和技术。鼓励团队尝试新方法。短期迭代非常适合这种实验。你可能会失败，但是很快你可以尝试其他的。如果你管理敏捷测试人员或者敏捷团队，给他们时间去学习并提供所需的培训支持。移除障碍使他们更好地工作。当你面对影响测试的问题时，让团队都知道这些问题。通过头脑风暴的方式克服这些障碍。回顾会议可以讨论这些问题并想办法解决。维护一个阻碍事项列表，并在每个迭代中解决一到两个。使用可视化的大图片或者虚拟方式，确保所有人都知道发生的问题并可以跟踪编码和测试的进度。
3.自动化回归测试
敏捷团队没有测试自动化会成功吗？可能吧，但是我们所知道的成功团队都依赖自动化回归测试。如果你花费全部时间用在手动回归测试上，绝没有时间用于重要的探索性测试（会发现隐藏在代码中的危险行为）。敏捷开发利用测试来指导开发。为了编写代码使测试通过，你需要快速、简单地运行测试。没有短期反馈周期和安全的回归测试，团队将很快陷入技术债务，缺陷不断增加，速度越来越慢。
自动化回归测试是团队的工作。整个团队应该选择每种测试适合的工具。提前考虑测试将帮助开发人员为了便于测试自动化来设计代码。使用敏捷测试象限和测试自动化金字塔来帮助你自动化各种类型的测试。记住从简单入手。你会惊讶地发现一些基本的自动化冒烟测试或者自动化单元测试会发生很大作用。测试自动化是团队的工作。开始时很艰苦，需要克服很大的痛苦。如果你管理开发或者测试团队，确保在时间、培训和激励上提供了足够的支持。如果你是没有自动化测试的团队的测试人员，开发人员疯狂地编写代码以至于不会停下来考虑测试，那么你会面临很大的挑战。尝试从管理层和团队成员中获取支持以开始小规模的自动化工作。
4.提供并获取反馈
反馈是敏捷的核心价值。敏捷的短期迭代可以提供持续的反馈以帮助团队运转正常。测试人员通过自动化测试结果、探索性测试的发现和系统实际用户的观察结果的形式帮助提供反馈。敏捷方法允许团队获取有关构建中软件的反馈。这是关键。故事代表了测试人员和分析人员向开发人员提供反馈的工作单元。迭代发布有助于团队外部的反馈。大多数敏捷实践都创建了反馈循环使团队应用。测试人员也需要反馈。你怎么知道从客户手里拿到了预期行为的正确例子？你怎么知道编写的测试用例正确地反映了这些例子？开发人员通过查看你收集的例子和你创建的测试能够理解应该编写什么代码吗？一个最有价值的技能是学习如何寻求自己工作的反馈。询问开发人员是否得到了足够的信息以理解需求并且是否能够指导编码。询问客户是否理解质量标准。花时间参与迭代计划会议和回顾会议以讨论这些问题并提出改进方案。
5.构建核心实践的基础
- 持续集成
每一个开发团队都需要代码管理和持续集成。如果不知道自己在测什么，就无法有效地测试，如果无法配置代码你根本无法测试。所有团队成员需要至少每天一次导入自己的工作。每一次集成必须通过自动化构建验证，其中包括提供软件状态快速反馈的测试。实现持续集成过程应该是软件开发团队中优先级最高的事情。如果团队没有每日构建验证的版本，停止手里的工作，开始构建。就是这么重要。一开始并不要求太高。如果你有很大的系统需要集成，肯定会更具挑战性。通常来说没有那么困难，市面上存在很多优秀的工具，开源的、商业的。
- 测试环境
没有可控的测试环境就无法有效地测试。你需要知道部署了什么版本，使用的数据库模式是什么，其他人是不是正在更新，其他进程是否运行在那台机器上。硬件总是越来越便宜，开源软件越来越多。团队必须投资以有效地执行自动化和手动探索性测试。如果测试环境出现问题，赶紧说出来，让全队一起解决。
- 管理技术债务
即使优秀的软件开发团队在感觉到时间压力之后，也会忽视重构或者快速解决问题修补缺陷。随着代码越来越混乱和难以维护，更多的缺陷出现，很快团队的速度就慢了下来，因为要解决缺陷才能添加新的功能。团队必须不断地评估技术债务的数量，并努力减少和避免。大家经常说：“我们的管理层不会给我们时间做这些，没有时间重构，日程很紧”。但是，我们可以很容易举一个业务用例来显示增长的技术债务如何耗费公司的成本。衡量代码和缺陷率哪些会导致技术负债变为对底线的影响存在很多办法。仅仅指出不断下降的速度就足够了。业务需要软件开发团队保持持续的生产力。他们不得不减少期望功能的范围以保证足够的时间来进行良好的、测试规范的代码设计和优秀实践，如持续小规模重构。自动化回归测试的良好覆盖率是最小化技术债务的关键。如果缺少，那就在每个迭代中拿出时间来构建自动化测试，规划一个“重构迭代”以升级或添加必要的工具，编写测试并进行重构。在每个迭代中花时间通过测试指导代码，重构必要的代码，添加丢失的自动化测试。对这件工作要重视。长期来看，团队能够变得更快。
- 增量工作
敏捷团队能够生产高质量代码的一个原因是他们小规模地工作。故事代表了几天的工作量，每个故事被分解成小增量，按步构建。测试可以针对一小块，并且随着功能聚集再增量测试。如果团队成员喜欢一次开发一大块功能，鼓励他们采用步骤式的方法。提出问题：“这个故事的核心业务价值是什么？这块代码的最基本路径是什么？下一步干什么？”建议大家编写任务卡片以编码和测试小增量，记录设计概念和确认测试和测试自动化策略。
- 编码和测试是同一个过程的组成部分
对敏捷思想不熟悉的人经常会问敏捷测试人员：“在所有故事完成并且可以测试的时候你会怎么做？”经验丰富的敏捷实践者会说：“测试人员必须贯穿整个迭代，整个开发过策划那个。否则就会失败”。测试人员基于客户提供的例子编写测试，以帮助开发人员理解故事并开始编程。测试和例子提供了一种通用语言使所有人都参与到软件理解中。测试人员和开发人员在编码时紧密合作，他们也会与客户紧密合作。开发人员向测试人员展示他们编写的功能，测试人员向开发人员展示他们发现的异常行为。测试人员随着编码进展编写更多测试，开发人员是其通过测试，测试人员进行更多探索性测试以了解是否生产了正确的价值。每一个敏捷迭代包含了若干持续、快速、增量的测试——代码—— 测试——代码——测试迭代。当这种合作和反馈周期被打断，并且测试与开发分离时，糟糕的事情会发生。如果故事是在编码之后的迭代中被发现的，开发人员不得不停止新的故事，回忆代码是如何实现上个迭代的故事的，修补它，并且等待其他人测试。在软件开发中没有什么几个事实，但是我们确定缺陷发现的越早，修补的成本越低。当编码一直由测试指导，编码的同时进行测试，我们更有可能达到客户预期的行为，提供客户所需的价值。测试是团队的职责。如果团队没有这种观念，让所有人想一想对质量的关注、对发布优秀产品的期待和采取哪些措施来确保团队实现目标。
- 实践之间的协作
单个敏捷开发实践如持续集成能够发挥作用，但是多个敏捷实践的组合比各个部分相加要大。测试驱动设计、共有代码所有权和持续集成一起促进快速反馈、持续改进代码设计和快速产生业务价值。自动化测试很好，但是使用自动化测试驱动开发，随后是探索性测试以发现缺陷或者弱点，分多层次更好。某些实践单独操作并不好。没有自动化测试，重构是不可能的。通过迷你瀑布型的方式发布小版本会丢失敏捷开发的所有优势。如果你的现场客户没有做决定的授权，那么他对团队的价值有限。敏捷实践是互补的。花时间理解各个实践的目的，想想如何利用全部优势，针对什么对团队有用做出深思熟虑的决定。
6.与客户合作
测试人员对敏捷团队的最大贡献之一是帮助客户理清需求并设定优先级，通过预期行为和用户场景的具体例子描绘需求，并把这些例子转换为可执行的测试。测试人员使用业务的领域语言和开发团队的技术语言。我们担任优秀的辅助者和翻译。千万不要阻碍开发人员和客户之间的直接沟通。鼓励尽可能多地直接交流。使用“三方协作”方法。当需求丢失或者被误解，客户、开发人员和测试人员需要一起解决问题。请客户经常在白板或者其他虚拟工具前讨论问题。如果客户发布于不用的地区、国家，那就使用任何能找到的工具来加强沟通和协作。电视会议、即时消息和 wiki不能完美的替代面对面的交流，但是也比发邮件或者什么都不做要好。
7.保持大局观
我们发现测试人员有大局观，通常从客户的角度看问题。开发人员通常关注于实现当前的故事，虽然他们使用测试来指导，但是不得不关注于需求的技术实现。大局观对团队贡献巨大。测试驱动开发，如果完成得很好，单独的代码没有缺陷。如果新的功能导致一些应用明显不相关的部分崩溃怎么办？一些人不得不考虑这种对较大系统的影响并引起团队注意。如果我们忽略了一些可能惹恼客户的细节怎么办？新的UI可能没什么缺陷，但是如果背景颜色使文本难以阅读怎么办？这都是最终用户会注意到的问题。使用敏捷测试象限作为纲领来帮助规划测试覆盖所有范围。使用测试金字塔思想确保测试自动化的良好投资回报率。通过测试指导开发有助于确保你没有丢失重要的事情，但并不完美。使用探索性测试了解系统应该如何工作，测试应该指向哪个方向。让你的测试环境尽可能与生产环境类似，使用反映现实世界的数据。勤于重新构建一个生产环境类似的场景，如负载测试所需。团队的每一个人都很容易只关注手边的一个任务或者故事。这是一次只做一块功能的缺点。帮助你的团队后退一步，评估当前的故事如何负责业务的大局。不断问自己如何才能更好的产生真正的价值。
互联网产品下质量保障
质量保障的核心目标是质量 & 效率并重，对于互联网产品来说诠释如下：
质量
i.不仅仅是功能可用性层面，需要关注用户体验。
ii.不仅仅是上线前的质量保证，需要延伸至把关上线中、线上的质量。
iii.不仅仅只停留在好坏的感性模糊认识，需要将质量概念量化、可视化。
iv.不仅仅光靠抽样个例，需要大数据统计做强有力的支撑。
v.不仅仅只局限自身产品的质量，也需要关心竞品。
效率
i.加快产品迭代，唯快不破。
ii.提高问题暴露，定位以及解决速度，快中求稳。
对产品建立质量标准，将其度量化并形成稳定的、可衡量的产品质量benchmark，对于产品可以列出数据完整性、安全性、传输速度、在线消费体验等最核心的质量维度。线下以此作为发版标准，驱动产品质量迭代越来越接近目标；线上以此作为监控范围，对线上质量问题主动防御，加快应对。
“以质量为中心，以数据为驱动”为宗旨贯穿整个流程，将各种测试工具和方法融入进来，构筑一套全流程质量保障体系，如下图所示:
二、测试技术
线下集成持续化、测试服务化，以应用质量（QPS、SLA、性能）、业务指标、过程质量（代码覆盖率，千行 bug 率）一系列发版标准为目标，将自动化测试、性能、单测、异常等工具集成入构建—部署—quickcheck—slowcheck—release 的流程中，快速发现问题并解决，迭代质量。线下需要更多精力关注在异常和性能测试中，这些往往是线上问题多发区。
上线过程中灰度控制，把产品发布过程划分为多个级别，每个级别限制一定的流量和用户范围，并在每个级别对产品进行部署和验证的迭代过程。一方面逐步放量，小心验证，降低上线带来的风险；另一方面开展用户测试，让用户参与产品测试，加强与用户互动。让用户参与 beta 环境分为两种情形：被动命中（将同一特征的用户强制划分至小流量环境中）和主动邀请（邀请粉丝或有偿用户）。对服务器来说架构能够支持逐步放开流量，对客户端发版来说有一个平台支持哪些版本哪些用户能升级到beta版本，并且在小流量阶段要密切关注监控和用户反馈，将问题及时扼杀在萌牙阶段，不带到全量阶段。
线上监控 & 定位，从基础拓扑（网络、单机、数据库等底层服务）、服务稳定性（接口成功率、5XX、4XX非预期返回码的占比等服务器可用性层面）和业务质量（上传、下载的成功率等用户功能层面的易用性）三个核心要素延展开全方位细粒度的监控覆盖，并从质量标准、质量防线和质量闭环三个维度进行质量建设：首先对产品建立一套完善的产品质量标准体系，并将其度量化，固定成 benchmark。紧紧围绕质量数据，组建从用户（舆情热点）、端（产品体验）、服务器（稳定性）到基础网络（SLA）的层层实时防护网，最后通过上线管理—报警中心—智能定位—故障通报的质量闭环环节落地，不断迭代优化，能够快到线上问题快速预警、定位及解决。
三、专项质量保障
（1）多副本分布式存储：旁路测试 & 线上数据检查，以数据完整 & 安全为使命
考虑灾备冗余、成本因素，云存储都会使用多个机房，跨机房的传输相比单机房的数据流动本身即增大了延迟，不同机房网络属性、机器性能等差异更对服务质量的保障提出了挑战。单一的机器性能测试已经不满足需求，需要引入旁路测试：复制线上的部署拓扑，进行等比例缩放，仿真线上的数据，在测试环境里重放，观察复杂部署和网络环境下服务的稳定性，辅佐一定的异常流量，评估系统的容错性以及灾难发生时预案是否能生效等。为更进一步保障数据的安全，对线上每日新增的数据较验各个副本的一致性及完整性。
（2）多机房 & P2P 流量架构：流量 diff 系统 & 实网系统 & 众测测速，传输速度体验
下载由源站IDC、CDN和P2P三部分承担，用户端、网络端、服务器云端的每一个环节都会影响速度。服务端的流量调度是根据用户地点、运营商网络、请求入口、文件所在机房、资源热度等多重属性对用户分配多个可带优先级的下载域名，让客户端充分并发及容错。多重维度的组合注定了调度策略的复杂性以及验证的难度，流量 diff 系统应运而生：在线下构造两套流量系统，一套线上代码环境，一套测试代码环境。通过回放线下真实流量，diff 前后调度是否符合预期，是否带来了非预期的变化。
三、最终
从质量标准、质量防线和质量闭环三个维度进行质量建设。首先对产品建立一套完善的产品质量标准体系，并将其度量化，固定成 benchmark。紧紧围绕质量数据，组建从用户（舆情热点）、端（产品体验）、服务器（稳定性）到基础网络（SLA）的实时防线，最后通过“上线管理—报警中心—智能定位—故障通报”的质量闭环环节落地，不断迭代优化。
文化价值驱动质量
产品也是创造它们的文化产物。麻省理工学院马丁信托创业中心的总经理Bill Aulet，同时也是麻省理工斯隆商学院的资深讲师，提醒我们：文化会吞噬策略，并且，我质疑流程也一样会被文化所吞噬。当组织文化与流程改变的精神相冲突时，例如当命令式与控制式的文化试图通过自管理，敏捷团队来达到生产率的目的，每一次冲突都会是文化获胜。文化通过组织的价值观、标准、信念和习惯表现出了自己，这些表现形式进而通过规范团队行动的方式产品质量产生影响。我的这一观点并非来自某个组织的报告说明，而是通过组织在每一个级别上的行为所得出的。首先，组织的价值观通常能够帮助团队排列出优先级最高的任务。
- 领导重视。关于质量，领导需要展示如何“付诸行动”。并且必须来自于上层的授意。你可以通过如下方式来达成这一点：
特别要注意的一点是，当你要在组织中介绍或改变度量的时候。就像其他任何变化一样，至关重要的是在采取这个改变时要在大家的认同和强行执行之间权衡利弊。度量的风险在于，不同的团队可能已经在使用自己的度量方式了，他们会着重于强调他们所感兴趣的部分。因由于度量的目的是全面地测量和转变团队的行为，因此关键在于让所有的干系人（高层领导、产品经理、质量保证人员和工程师）认同并且坚持某些通用原则，你可以通过如下方式来达到：
- 有目的地建立一个跨职能的工作组。清晰地说明出，如果没有度量的情况下，当前存在的痛点，为什么必需要采取行动，以及常见的度量是如何帮助我们的，通过这些来激发大家对度量的需求。邀请那些有影响力的干系人，让来自于不同部门的高层领导、产品经理、质量保证人员和工程师来设计度量。在讨论的过程中，每一个参与者都代表了他们团队感兴趣的部分，也帮助了我们把度量在内部推广给其他人。选择一个好的引导师，并且请确保在度量设计完成之后，明确地要求参与者把这个结果推销给他们的同事。
- 对有价值的产出进行测量。让工作组首先识别出不同的干系人所关心的、他们理想中的定性的产品产出是什么。一旦这些识别出这些产出之后，然后再邀请小组人员返回度量设计，选择促进或偏离每一个产出需要的测量。比方说，假设你的产品是一个云应用，计算成本上升的速度比使用的增长速度还快，高层管理人员对此问题表示关注。工作组可能会识别出各种度量来测量有效性，例如各台服务器的CPU使用率，而这是可以在开发和测试阶段进行监控的。一旦这些度量最终被确定和使用，请展示给你的团队并告诉它带来的影响是什么。
- 对跨团队的度量进行标准化。让工作组创建模板或者仪表盘，因此所有的团队可以以此进行度量的查看。邀请每一位参与者展示他们特定团队的结果，并且确保各个团队统一使用这些标准工具。因为每个职能部门都对该流程表达了自己的观点，并且清晰地设定了期望。因此这些度量就可以让每个人在以后工作中使用。
- 跟踪质量度量。定义高层领导、产品经理、质量保证人员和工程师都认同的有意义的质量测量。
- 让你的度量可见。经常把在会议中提到它们，并且和你的团队定期地回顾评审。
- 用质量做取舍。对最小质量级别创建清晰的定义和规范，当邻近发布时需要做出取舍时，就可以在会议中使用它们。当团队看到质量度量用于决策的取舍时，他们就会了解为什么要重视质量了。
- 消息的可靠性。成功的经理人都会根据与团队的共鸣度谨慎地选择正确的方式去沟通有关质量方面的消息。做好这一点也许需要经过一些试验。从不同的内部或外部的干系人的视角来沟通产品质量，看看如何激发你的团队。例如以下几种方式：
- 客户满意度。采访或调查客户对产品的整体满意度，在过程中注意以语言引导他们的情绪。
- 演示中的销售体验。就像任何一个销售代表会告诉你的一样，在预期演示的时候出现产品崩溃会带来十分严重的伤害，并且会让销售代表很难堪。应该注意了解销售代表在演示产品中的表现，以及他们在演示中产品所表现出的可靠程度。
- 高层领导的看法。在很多组织中，高层领导（尤其是创始人）喜欢动手尝试新的产品功能。在邻近发布时，邀请他们参与使用，并且询问他们的体验。
- 同事参与。一旦他们开始彼此参与度量时，你的团队可能会将质量深入内心，你可以通过下面不同的步骤来鼓励团队：
- 在设计阶段创造一些仪式。在设计讨论阶段，帮助你的团队开发一个流程来评估不同设计方案对质量的影响。为团队准备一些问题，让他们回答他们所考虑的每一个方案对质量的影响，并且在发布之后展示这些问题是如何对整体的质量做出贡献的。
- 邀请同事评估。在定期的状态审核会议中，为你的团队展示最近的质量度量情况，并且要求每个人站在他们的立场做自己的评估。哪些是他们同意的，哪些是他们对结论有分歧的？不管答案是什么，只要邀请团队做他们自己的评估，就会让他们注意到质量。
- 鼓励结对编程。如果定期实施结对编程，尤其是在初级的和资深的开发人员之间进行结对，这会鼓励大家在设计和实施的阶段讨论质量的问题。鼓励你们团队的资深开发人员在每一次结对编程的过程中进行讨论。
- 员工的主人翁意识和授权。你可以给你的团队授权，让他们做质量决策，并且通过这个结果，他们会感到更强的主人翁意识。可以考虑到用以下方式实现这一点：
- 识别质量贡献者。创建个人的质量测量(例如每名开发的缺陷、也许根据项目的复杂度会变大)，提供可见性，并在团队中赞誉那些获得优秀结果的人。创建一个仪表板，清晰地显示每个人与同事的对比。并且将这个结果用到会议中。
- 创造竞赛意识。对于大的项目，可以考虑给那些编写出最高质量的代码，表现出众的员工颁奖。确保在开始的时候就宣布这个竞赛，并且说明衡量标准。你会从中获得很大乐趣。
- 创造学习机会。邀请那些交付最好记录的团队成员参加午饭演讲活动，让他们分享创建高质量的方法、他们所做的设计决定和最近项目的一些产出。在准备这个演讲时，鼓励团队成员展示在他们在某一个功能实施时如何与质量方法的连接，客户、销售代表或者高层领导如何体验。
团队
任何时候都需要团队，需要这样的团队成员:
1.具有创新精神的测试人员 这类测试人员往往会较快的接受新生事物，他们喜欢探求从未使用过新奇工具、技术等。这些新的测试工具或新技术的发现，会带动整个测试团队技术上的推陈出新，让本来墨守成规的测试工作充满了新鲜的体验。大家在交流新技能的同时也会带动起较高的学习热情。
2.有测试欲望并能够持之以恒的测试人员 充满测试热情、善于发现隐藏的软件缺陷、较真是这类软件测试人员的共性。 往往枯燥的工作会让人失去耐心，但这类测试人员会始终抱着最大的热情投入到测试工作中。对于这样的成员来说，发现软件缺陷是他们最大的乐趣，工作上的每一个发现都会带给他们源源不断的自信。团队中也正是有这样的成员存在，正是有他们在关键时刻发现软件产品的隐患才能避免事后补救的不必要的人力、物力资源的浪费。
3.富有经验的软件测试人员 不管情况如何，他们都可以找到正确的位置来运行程序以发现关键的缺陷。这正是富有经验的软件测试人员的宝贵之处。在很多情况下，根据对相似类型的项目的经验，一个软件测试工程师可能会准确知道在哪里找“致命缺陷”。
4.具有远见性的测试人员 与具有创新精神的测试人员不同的是，具有远见的软件测试工程师往往会发现更高级的，策略性问题的解决方案。团队需要一个能看清团队发展方向的人——对如何进行软件测试有广泛认识，而且对团队成员的具体程序有深入认识的人。这类测试人员会推动整个团动的不断进步。
