“好多QA转PM，因为QA（的地位）始终是要低一些”

“我现在做的事情跟几年前没有区别”

“资深QA在项目上做的事情新来的毕业生也能做”

上面的话你是不是也有同感？我相信大部分人会这么认为，因为这些表面上看起来的确是这样的！

那么，软件测试人员或者说QA真的有这么惨淡吗？

对于开篇引用的几句话，我们一一来分析一下。

测试工作的价值不容置疑

“好多QA转PM，因为QA（的地位）始终是要低一些”

说这话是没有看到QA所做工作带来的价值。相反的，我认为QA之所以可以转PM是QA工作过程中获得的锻炼挺多的，不仅可以转PM，可以转PO，技术型的QA还可以转Dev。

其实，QA和PM并没有地位高低之分，只是分工和职责不一样，QA转其他角色并不是地位的改变，可能只是更加适合自己。积极主动的做好本职工作，都能为团队带来很大价值；做的不好的话，都同样的不能带来价值。况且，做的不好的PM可能影响到整个团队，所带来的价值远不如一个优秀的测试人员带来的价值大。

我们应该以合作的心态看待这个问题，一直强调的团队为质量负责，需要每个人都有团队的意识，有分工只是因为兴趣特点和擅长领域不同而已，并没有高低贵贱之分。

质量越来越受到各行各业的关注，质量问题不容忽视。软件质量的保障工作，软件产品的测试当然也是非常重要有价值的，这一点根本不用怀疑。

只是，质量的好坏带来的价值不是那么直接可见的。反而需求人员多分析了几个需求，开发人员多开发了几个功能点，又或者多写了几个自动化测试，这些都是显而易见的，似乎带来的价值更大，更容易被人认可和重视。而另一方面，需求的验证、测试的设计、质量状态的关注、风险的把控、快速的发现和定位问题，这些是不容易被量化的，也就不容易被重视或尊重。

能力提升是关键

“我现在做的事情跟几年前没有区别”

这是只看到所做的事情似乎没有差异，比如说都是一起分析需求、设计测试、测试story、写自动化测试等，可能的确几年前就做这些事情，现在还是做这些事情。但是，我相信只要你在做每件事情都能认真对待，有自己的思考和总结，就不会一样。比如：

• 同样的分析需求，几年前可能只看到BA写出来的需求，看看有没有边角case漏掉了；而现在的你可以从行业业务角度去看待这个需求整体考虑的合理性，是不是能给用户带来价值、能给企业带来竞争力。这两者还是有很大的区别的。
• 同样的测试story，几年前可能只是根据验收标准和自己想到的一些边角case去测试，一个story需要一天才能测试完；而现在的你，利用自己对于领域知识的掌握、技术的了解、系统功能的熟悉，结合自身这么多年阅历和增加的常识，半天估计能测试包含几个story的一个feature，或者一个junior测试人员测试过的story，你拿过来一下就能发现一些问题。这就是成长，这就是价值！

“资深QA在项目上做的事情毕业生也能做”

如果只是看所做的事情，可能还是停留在表面，跟上一条讲的几年前的自己和今天的自己一样。

当然，有很重要的一点，资深QA不能仅仅是工作年限长，得是有真正的能力，不然的话可能还不如优秀的毕业生。

QA能够随着年龄和工龄的增长，让自己的能力也能不断的提高，才能让测试工作有更多价值的体现。因此，能力提升至关重要！

那么，能力该如何提升呢？

能力提升路径

看似相同的事情，不同能力的人做出来的效果不一样。为什么他解决问题的能力那么强？我们来了解一下学习提升的过程。

第一阶段，知识积累

通过阅读、听课、观看视频等方式可以获取到知识点，将这些知识点总结归纳之后，变成自己理解的知识。

这是第一阶段知识积累的过程。

第二阶段，经验积累

将所学知识进行试验，进一步用于实际项目，获取实践经验，不断反复的实践可以获得经验的积累。

这一阶段还不够，还没变成真正解决问题的能力。

第三阶段，能力提升

在实践中坚持回顾和总结，对实践过程进行批判和改进，并且举一反三的运用所学知识，将会实现能力的积累。

到此，就实现了知识到能力的转变过程。

积累和分享很重要

前面每个阶段都可以获取新的知识，然后经历同样的知识-经验-能力的转变，不断的积累，将会实现能力的提升；每个阶段都可以把知识或经验分享给他人，在帮助他人获得相应知识的同时，更是自身能力提升的一个非常好的方式。

多次反复的知识-经验-能力的转变，达到一定积累之后就会带来惊人的效果，这不是一个线性的增长。

在整个过程中不断发掘自己的兴趣点，将学习、兴趣有机结合起来，会达到事半功倍的效果。

终身成长

了解了能力提升路径，很重要的一点还有可能是我们需要转变固有的思维模式。这里给大家推荐我非常喜欢的一本书《终身成长》，书中讲到两种思维模式：固定型思维模式和成长型思维模式，具备成长型思维模式的人将更容易获得成功。我们需要更多的关注自身的成长，而不是关注外界、跟外界进行比较。

前面所讲并不只是跟软件测试人员相关，可以适用于任何角色、任何职业的朋友，只是同样作为质量工作者，听到不少人的担忧，才撰写此文。

相信积累多了，就会发生质变！

最后，让我们一起多阅读、多学习、多实践、多思考、多总结、多分享，做到终身成长！

“我们公司的测试好多都转业务或开发了，还有的转管理了，测试做不长久…”

“现在好多公司已经不招测试人员了，感觉测试没有什么前途…”

“ThoughtWorks技术雷达上都是开发相关的内容，测试相关的内容越来越少…”

软件测试总是被看做没有技术含量、没有前途的工作，很多做软件测试的朋友也比较迷茫，表示发展受限。在这个技术飞速发展的时代，各行各业都在实行数字化转型，各种高新技术似乎离测试人员越来越遥远…

那么，测试人员真的是前途渺茫吗？本文将根据ThoughtWorks最新发布的第20期技术雷达来分析当前流行的技术给软件测试人员带来的影响是什么，有哪些机遇与挑战。

技术雷达上的内容涵盖有技术、平台、工具和语言&框架四个维度，我观察到其中跟测试人员关系比较紧密的主要有以下几个方面：

1. 支持快速、持续交付的基础设施与DevOps实践

质量和速度是最关键需求，为了适应各行各业对速度的要求，配套的支持快速、持续交付的基础设施与DevOps实践是成功之必备。技术雷达上与之相关的条目有很多，比如：Terraform生态系统和四个关键指标等。

• Terraform生态系统

Terraform是一种安全有效地构建、更改和版本化基础架构的工具，可以管理现有和流行的服务提供商以及定制的内部解决方案，正在迅速成为通过声明式定义来创建和管理云基础设施的首选工具。本期雷达Terraform相关的内容重点包括Terratest（用于测试基础设施代码)，以及GoCD的新提供商（可以使用Terraform配置GoCD)。

基础设施不仅是Ops或者开发人员需要关注的领域，作为测试人员，同样需要加强这项知识的掌握：

1. 了解了基础设施知识，结合已有的测试sense，测试人员可以和开发或Ops一起测试基础设施；
2. 了解基础设施特点，可以指导测试的设计，在测试的时候更有针对性的关注比较脆弱的节点、环节，规避风险，增强系统的反脆弱性；
3. 利用基础设施知识，可以指导测试环境的搭建和维护、自动化测试数据的准备和管理等。

• 四个关键指标

埃森哲发布的DevOps报告指出组织绩效跟软件交付性能关系紧密，而衡量组织绩效的四个关键指标分别是前置时间、部署频率、平均修复时间(MTTR)和变化失败率。本期技术雷达采纳了这项技术。

作为测试人员，我们需要了解每个指标的真正含义，并且思考我们测试策略是否需要做某些调整来提供对应的指标值。比如说为了提高部署频率，可能不需要那么高的E2E自动化测试覆盖率，而是达到覆盖效果和执行效率最佳平衡的一个状态即可。

2. 支持业务灵活扩展的微服务架构

引入微服务令我们受益匪浅，使用微服务，团队可以扩展那些独立部署和维护的服务的交付，从而方便业务的灵活扩展。微服务架构正在逐渐被越来越多的企业采用。我们看到技术雷达上应对微服务的相关条目有服务网格、混沌工程、API测试框架Karate等。

• 服务网格（Service Mesh）

服务网格是一种安全、快速、可靠的运行微服务生态系统的方式。这种方式为轻松地大规模采纳微服务奠定了基础。它提供了检测、保障、跟踪、监控和故障处理功能。它提供的这些跨功能能力无需共享API网关等资产或将很多依赖库纳入到每个服务中。

• 混沌工程（Chaos Engineering）

混沌工程是对系统进行试验的一门学科，旨在建立对系统抵抗生产环境中不确定条件的能力的信心。在去年，我们看到混沌工程从一个备受关注的 、想法，转变成公认的主流方法，来改善并保证分布式系统的弹性。主要用于以下几类故障时增强系统的弹性：基础设施故障、网络故障和应用程序失败，对应的工具有Gremlin和Chaos Toolkit等。

• Karate

Karate是一款API测试框架，其特色在于，直接使用Gherkin来编写测试，无需依赖常用编程语言来实现测试行为。Karate是一个领域特定语言，用来描述基于HTTP的API测试。虽然该方法很有趣，可以为简单的测试创建非常易读的规范，但用于匹配和验证负载的专用语言可能会变得语法晦涩、难以理解。从长远来看，使用此风格编写的复杂测试是否将可读且可维护，仍有待观察。

微服务带来灵活性的同时，也带来很多的复杂性和不确定因素，尤其是对质量保障带来了挑战，因此微服务系统的测试也备受关注。作为测试人员，只有了解了微服务架构与服务网格的特点及其对测试的影响、混沌工程对质量保障的帮助、API测试的框架选择与测试优化等，才能更好的做好微服务系统的测试。

3. 多样化数据形态的支持

随着数据源的增加、数据规模的扩大、数据种类越来越多，相应的数据形态也呈现出多样性，包括NoSQL、时间序列、像CockRoachDB和Spanner这样提供全局一致性的SQL存储，以及提供聚合日志文件查询功能的事件流。不再是关系型数据库解决一切存储的时代了，要考虑真实需求，采用合适的策略和工具。

数据形态的变化，必然对测试也提出不同的要求。作为测试人员，需要了解不同的数据规模、不同的存储形态、不同的数据类型分别该如何验证、测试该如何设计、测试数据该如何准备，还有数据安全、数据匿名化、数据分析等数据相关技术对测试的支持等。比如，对于大量数据处理的项目，测试人员需要了解数据处理的技术与处理逻辑，分别从功能层面验证处理逻辑的正确性，以及从非功能方面考虑大量数据处理的性能、数据处理的安全规约等。

4. 网络安全始终是重中之重

网络给我们生活带来便利性的同时，其安全性也是备受关注。2018年欧盟颁布了GDPR法令，使得众多企业不得不紧急调整系统功能做好个人身份信息的保护工作。网络安全始终是质量保障的重中之重，绝对不容忽视。本期技术雷达推荐的安全相关条目有密码即服务、容器安全扫描、密钥销毁技术等。

• 密码即服务（Secrets as a service）

在构建和运维软件的价值流中，密码凭据在多个场合都需要使用：构建流水线需要使用密码来与容器注册中心等安全基础设施进行交互，应用程序需要使用API密钥作为密码凭据来获得业务功能访问权限，而服务间通信则需要以证书和密钥作为密码凭据来保护其安全，这些密码凭据不建议通过源代码的方式管理，而是采用密码即服务的技术来存储和访问。利用这种技术，可以使用Vault或AWS Key Management Service(KMS)等工具来读写HTTPS端点上的密码凭据，同时实现精细的访问控制。

• 密钥销毁技术（Crypto shredding）

密钥销毁是指主动覆盖或删除用于保护敏感数据的加密密钥，以保护敏感数据不被读取。对于审计应用程序或区块链这样不应该或不能删除历史记录的系统来说，密钥销毁技术对于隐私保护和GDPR合规非常有用。

• 容器安全扫描（Container security scanning）

围绕Docker的容器革命显著减少了应用在跨环境迁移时的阻力，并推动持续交付和持续部署的采纳。但尤其是后者，对于传统的投产控制带来了相当大的漏洞。容器安全扫描技术是对该威胁载体的必要响应。构建流水线中的工具，会自动检查流水线中的容器是否存在已知漏洞。

作为测试人员，对于上面的安全相关技术可能不需要掌握的很深，但是需要了解有这样的一些技术，以及对应的使用场景。这样，才能对于系统整体的安全质量有更好的把握。此外，测试人员需要了解相应的安全测试技术，需要关注业务方面的安全需求，了解不同领域的安全规范和要求，从需求阶段做好威胁建模开始，跟团队一起在软件开发生命周期做到安全内建（Build Security in）。

5. 自动化测试与线上质量的关注

要快速交付，必然离不开自动化测试，而要做好自动化测试，更是离不开相应工具的支持。本期技术雷达上列出的Cypress、TestCafe和Puppeteer被誉为后Selenium时代的Web UI测试的三驾马车，值得关注。这三个工具不同于WebDriver时代的自动化测试工具，具有更加轻量级、更加稳定、速度更快的优点。

随着技术架构的演进和业务领域的发展，软件系统生态越来越复杂。过于重视预生产环境的测试，不仅不能很好的保证生产环境的质量，而且影响交付速度。因此，我们要把质量关注点拓宽到生产环境，做到测试右移。本期技术雷达列出的相关工具有：日志管理工具Humio，Honeycomb，以及前面提到的混沌工程相关条目等。

• Humio

在日志管理领域，Humio是一款相对较新的工具。该工具完全从零开始构建，通过基于定制设计的时序数据库的内置查询语言，在日志提取和查询方面性能非常快。从提取、可视化和报警提醒的角度来看，该工具能够与几乎所有工具相集成。

• Honeycomb

Honeycomb是一个可观测性工具，它从生产环境中提取出丰富的数据，并通过动态采样使其可管理。开发人员可以记录大量丰富的事件，并在之后决定如何划分和关联它们，这对于大型分布式系统的问题诊断很有帮助。

作为测试人员，自动化测试成为了必备技能，需要关注自动化测试工具的发展，了解新工具的特点与适应场景，更好的让自动化测试工作发挥最大的价值。另外，测试右移的思想也越来越被大家接受，需要测试人员更多的了解基础设施相关技术、线上监控技术等，跟Ops紧密的合作，做好QA in production。同时，利用生产环境的数据，为预生产环境的测试设计和数据准备等提供帮助，构建反脆弱的软件系统。

6. 新兴领域不容忽视

最火热的新兴领域当属AI，这也是未来的发展方向。本期技术雷达上列出的有机器学习和神经网络训练等内容，比如：机器学习持续交付模型、NLP的迁移学习和fastai等。

另一个热门新技术是区块链，技术雷达上区块链相关技术条目有智能合约、超越以太坊的EVM和企业版以太坊Quorum等。

技术雷达上还提到一个新的内容，那就是随着社会对科技的依赖程度日益增长，建议软件开发团队在制定决策时必须考虑道德问题，思考自己所构建的软件会在未来产生什么影响。相应的工具有技术塔罗牌和道德风险手册。

作为测试人员，这些都是大家可以关注并深入了解的方向。新兴领域必然会对测试有不同的要求，比如：关于AI的测试需要考虑两个方面，一个是对于AI产品的测试，另一个是把AI技术运用于测试中，比如自动化测试的智能化、生产环境数据的智能分析等。另外，对于区块链，需要考虑它对测试带来什么挑战、有什么样不同的测试方法来支持；对于道德风险的把控，我们软件测试人员又该注意些什么？能够提供哪些支持呢？

写在最后

前面列的这几项，除了自动化测试工具以外，其他的内容通常被认为跟测试人员没多大关系。其实，软件测试已经不再是那个简单的通过模拟用户行为点击去验证功能是否满足的时代了，测试人员的眼光要放更开阔一些，考虑更多的质量相关因素。对于前面总结的这些项目，我认为不是跟测试人员没有关系，而是给测试人员带来了新的挑战，提出了新的要求。同时，机遇跟挑战并存，这些挑战同样也给测试人员带来了很多新的发展机会。

那么，在众多机会面前，测试人员该如何把握呢？推荐大家可以根据T型能力模型去提升自己的能力。

T的横表示能力广度，T的竖表示能力深度。前面提到的方方面面都属于广度，包括不同技术和不同业务领域的扩展，而深度就是对于其中一个领域进行深入的学习研究，发展对应的测试技能。

广大的测试朋友们可以结合自己的兴趣特点，找到最适合自己的那个领域，深入发展。了解足够的相关知识，通过实践将知识转换为经验，然后总结归纳、不断锻炼，以获得利用经验解决问题的能力，拥有一技之长。

同时，要拓宽视野，了解更多领域的知识，做到广度和深度协调发展。

曾经在《敏捷中的QA》一文里介绍了敏捷开发模式下，QA如何参与从需求到测试的每个阶段，在每个实践中如何跟不同角色的合作，以及敏捷QA跟传统开发模式下的测试人员的区别等。

这些内容在今天依然适用，但在真实项目中往往情况比较复杂，总会听到一些困惑或者是质疑的声音。

在敏捷项目团队摸爬滚打多年以后，我想跟大家一起再来聊聊这个话题，下面逐个来分析我所见（听）到的质疑或困惑。

敏捷QA流程必须严格遵守

“如果QA没有参加Kick-off，我们拒绝做Desk Check；如果没有QA参与Desk Check，我们拒绝测试。”

从需求分析到生产环境，推荐QA参与每一个环节，跟多个角色进行充分的沟通和合作。

有人把这个当做圣旨，觉得不管怎样都不能漏掉某个环节，但难免有特殊情况。比如，由于QA请假或者开会等，错过了某一次Desk Check，一定要求等有时间了（甚至第二天或第三天）再补上，没准那个时候代码都已经上到测试环境，完全可以直接测试没必要在折腾大家来做一次全面的Desk Check了。

QA参与每个环节的目的是尽可能早期发现需求或者设计中的不足，做到Bug的预防。如果已经错过了这个“早”，那就没有必要再纠结非要严格进行每个环节了，不然不仅没有意义，还带来浪费。

QA不用了解太多的业务上下文，一样做的很好

“需求来的晚，QA手头忙着测试当前迭代的Story，根本没有时间去参与需求分析，不过这样也不影响，测好当前的卡就可以很好的保障质量了。”

这个想法是狭隘的。敏捷测试的原则之一是优化业务价值。如果连业务上下文都不清楚，如何做到优化业务价值？了解业务上下文的重要性不言而喻。

那么，真的忙的没有时间如何来破解呢？这其实是进入了一个恶性循环，需要找到突破点，打破这个不良环路，让其变成一个良性循环就好了。

不破不立，对于这个循环，就是需要减少测试Story的时间。可行的方案是：加强Desk Check，确保单元测试的覆盖，保证开发验收完成到最终交付的代码在自动化测试的保护下不被后续环节破坏；同时QA参与技术方案的设计讨论，这样测试的时候就可以有针对性的测，必要时候辅助以Bug Bash，由此节省出时间。经过两三个迭代的调整，情况定会有所改善。

技术方案讨论跟QA没什么关系

“技术方案，那是Dev们的事情，QA的重要任务是如何做好测试，参与技术讨论浪费时间。”

知己知彼，百战不殆。如果完全不了解技术实现，很难做到有的放矢。正如前面提到的，QA参与技术方案的讨论，了解更多技术细节，知道技术方案可能的风险，就能更好的指导测试，使测试更有针对性、更高效。

比如，对于微服务架构，了解了服务的熔断和降级机制，测试就能有效覆盖到相关方面。

单元测试Review没有价值

“单元测试还挺复杂，Dev新人写起来都不容易，QA更看不懂。QA Review单元测试，提不出有价值的反馈，感觉是在浪费时间。”

敏捷QA有个实践就是在做Desk Check的时候Review开发人员写的单元测试，其目的是两个方面：

• 帮助发现漏掉的或者需要修改的测试，QA更好的了解测试覆盖情况
• 帮助开发人员增加测试Sense，同时也能帮助QA提高代码阅读和理解能力

我理解对于单元测试Review的质疑是由于DEV和QA的相关技能还有所欠缺的情况下可能会发生的情况，但并不能因此否认这个实践的价值。

这时正确的做法是DEV跟QA解释每个测试所测到的内容，而QA从业务的角度考虑有哪些Case是遗漏掉了的。经过一段时间的磨合，我相信Dev的测试Sense和QA阅读代码、理解测试的能力都会得到提高。

必须严格Review每一个单元测试

“我对Dev写的单元测试总是不放心，不严格的Review根本不行。”

另一个极端情况就是，不管花多少时间，认为必须严格Review每个测试，认真的去检查测试的每个实现细节。

对于复杂一点的Story，严格Review每个单元测试，我见过最长的是花了两个小时，到最后大家都已经筋疲力尽…这显然是一种浪费！

QA Review单元测试更多的是关注测试的覆盖情况，而不是关注每个测试的实现细节，后者更多的是属于Code Review范畴。更重要的是，任何实践都不能只关注形式，要看其价值，具体问题具体分析。对于新的团队新的人，可能刚开始需要多花时间去了解所写的测试。而对于成熟的团队，或者是非常有经验的Dev，这个Review过程可以简化，只看测试的标题，或者只是听Dev说一下测试覆盖到了哪些内容就可以了。

我一般要求整个Desk Check控制在15分钟以内，对于特别复杂的Story，最多也不要超过30分钟。

没有发现Bug的测试不是好测试

“这些自动化测试从来没有发现过Bug，ROI太低，没有存在的必要！”

由于有些测试执行起来太耗时、测试实现成本和维护成本都很高，大家在讨论要不要去掉这些测试的时候，总能听到上面那样的声音。

其实，自动化的回归测试并不是用来发现Bug的，有数字表明自动化回归测试发现Bug的比例仅有15%。自动化测试只是形成一道保护的屏障，增加对系统质量的信心。

敏捷团队的QA对质量应该有全面的认识，在制定测试策略的时候需要综合考虑多方面因素，要真正理解每个实践、每个活动背后的真实价值。

敏捷QA该怎么做？

关于QA的定义，有下面三个层次：

1. QA = Quality Assurance质量保障
   第一个层次QA的要求是做好质量保障工作，确保我们交付给客户的软件产品是正常工作的。
2. QA = Quality Analyst质量分析
   第二个层次的QA通过测试、数据收集的方式，分析系统的质量，识别风险，并反馈给团队，和团队所有成员一起确保交付的质量是合格的。
3. QA = Quality Advocate质量倡导者
   第三个层次的QA不再局限于只关注质量，通过培养对产品和流程持续改进的思维模式、了解产品的整体质量视图和持续关注产品质量的意识，引导整个团队构建正确的产品，并且正确地构建产品。

敏捷QA需要做到第三个层次，通过分析软件风险并制定相应实践，确保软件在其整个生命周期中持续工作并创造价值，为业务和团队提供信心，从而为客户提供价值。

敏捷QA的所有实践和活动都需要以价值为核心来驱动，根据不同团队的具体情况可以适当调整，且在不同项目阶段应该也是演进式的。敏捷QA跟各个角色的沟通和协作，也是随着团队成员的了解程度、配合默契度不同而有变化，并不是要求一成不变的。

“这次发布之前怎么这么多的缺陷，是不是需要分析一下啊？” 答案是肯定的，可是这个时候才想起要分析已经有点晚了，有可能这些缺陷很难分析了。这是发生过的一个真实场景，所记录的缺陷包含信息很有限，很难有效的做好分析！本文就来聊聊如何有效的管理和分析缺陷。

缺陷记录

曾经有个项目是在QC(Quality Center)里记录缺陷，需要填写很多必填属性字段，加上QC服务器在国外，访问速度非常的慢，每次记录缺陷成为了大家极其痛苦的一件事情。于是，很多时候，发现了缺陷也不愿意往QC里填，而是直接写个纸条简单记录下，验证完了它的生命周期就结束了，这样后面就没办法去很好的跟踪和分析了。（题外话：当时采用脚本稍微减轻了点痛苦。）

也有的项目对缺陷的格式和属性没有严格要求，记录的时候很简单也很自由，这样记录的缺陷由于很多必要信息的缺失，对后续的跟踪和分析也是极为不利。

还有一种情况就是记录缺陷时同样有一些属性要求填写，但是这些属性值可能不是那么有意义，导致存储的信息不仅没用，反而添加混乱，也是不利于跟踪和分析的。比如，其中的“根源（root cause）”属性的值如下图1所示，这些值根本就不是根源，这是一个没有意义的捣乱属性。

图1.某项目缺陷根源属性值

缺陷记录应该做到尽量简单，且包含必要的信息。

1. 标题：言简意赅，总结性的语句描述是什么缺陷

2. 详情：包括重现步骤、实际行为、期望结果等，根据具体情况确定其详细程度，必要时可以添加截图、日志信息等附加说明。

3. 重要属性：优先级、严重性、所属功能模块、平台（OS、浏览器、移动设备的不同型号等）、环境、根源等，这些属性对应的值需要根据不同项目的情况自己定义，其中“根源”是相当关键的一个属性，后面有示例可以参考该属性对应的值有哪些。

4. 其他：每个项目对应的还会有其他信息需要记录的，自行定义就好。

在敏捷开发环境中，测试人员可能随时在测试、随时都会发现缺陷，包括还在开发手里没有完成的功能。什么时候发现的缺陷需要记录呢？通常情况下，开发还没完成的用户故事（story），测试人员发现缺陷只需要告诉开发修了，在该故事验收的时候一起检查就好了，无需单独记录；在开发已经完成，交到测试人员手里正式测试的故事，再发现缺陷就需要记录来跟踪了；后续的所有阶段发现的缺陷都需要记录。

缺陷分析

比较推荐的一种缺陷分析方法是鱼骨图分析法，可以将跟缺陷相关的各个因素填写到鱼骨图里，对缺陷进行分析，如下图2示：

图2. 鱼骨图缺陷分析法

缺陷相关的各属性拿到了，就可以用表格、曲线图、饼图等统计各个属性对应的缺陷数量，分析缺陷的趋势和原因。下面是我在项目上做过的分析报告图：

图3. 功能/环境对应缺陷数量统计表和缺陷根源比例图

图4. 缺陷根源统计表和比例图

图5. 缺陷迭代趋势分析图

分析完得到统计的结果就要采取对应的措施，从而防范更多的缺陷产生。比如：修缺陷（上面示例中的“bug fixing”）引入的新缺陷比较多，可以在修复缺陷后添加对应的自动化测试；浏览器兼容性问题相关的缺陷较多的话，可以在开发完成验收的时候在多种浏览器上验收，等等。

什么时候该进行缺陷的分析呢？通常，推荐每个迭代周期分析一次，并且跟以往各个迭代进行对比，进行趋势对比。当然，有时候可能一个迭代发现的缺陷非常少，分析的周期可以根据具体情况做出调整。

总结

缺陷记录是为更好的跟踪和分析缺陷做准备的，而缺陷分析是软件质量保证的重要环节，对于软件过程的改进，软件产品的发布来说具有十分重要的参考价值，建议各项目定期都要做做缺陷分析。

（此文发表于TW洞见）