创业团队如何落地敏捷测试，提升质量效能？丨声网开发者创业讲堂 Vol.03

前言

老牛是资深测试专家、技术架构师。具备多年互联网公司从业经验以及十多年一线研发经验。同时也是 DevOps 践行者，近几年兼任质量团队的管理工作。其中，负责的某技术平台，稳定运行两年多，累计调用量超 2800 亿次。

本文基于老牛在「声网开发者创业讲堂 • 第三期丨创业初期如何保障产品质量」活动中分享内容二次整理。关注公众号「声网开发者」，回复关键词「JT0611」即可下载活动相关 PPT 资料。

随着微服务架构、云计算、容器技术的发展和普及，DevOps 在开发者中逐渐成为共识，并成为主流开发模式。但在 DevOps 快速迭代中，测试成为快速交付的一大短板，敏捷测试呼之欲出。很多人提及敏捷测试，却鲜有人提及如何实现敏捷测试。

本文以敏捷测试催化剂为引子，阐述敏捷测试四要素及其组织管理形式，分享中小公司捉襟见肘的测试困境，初创企业如何成功落地敏捷测试的"脱困"案例，及敏捷测试未来的发展趋势与展望。

01 敏捷测试催化剂

1、背景

与炒股一样，软件开发包括基本面和技术面。从基本面的角度来说，随着软件工程技术的发展，软件架构和基础设施、软件工程文化，以及产品的竞争态势与之共同构成软件开发的基础。随着移动互联网的发展，大家都开始遵循唯快不破思想，比拼速度。软件工程文化也从以前的瀑布，到现在的敏捷、scrum、看板等。只有这些基础设施和相关基本层面达到一定程度以后，才能实现业务落地。

图 1 是对基本面的描述，随着 DevOps 的流行，敏捷开发/CICD、微服务/容器技术/云计算、移动互联网的发展、质量内建推动了敏捷测试的发展，对开发侧的触动是非常大的，提升了开发的速度。在快速迭代的过程中，测试随之出现了很多痛点，这也是我从架构又反过来研究测试的原因，也就是希望解决测试这块短板。

■图 1

2、DevOps 对测试的期待

目前测试已成为快速交付的一大短板，很多公司可能每周发布一个版本或是两周（或一个月）进行一次迭代，随着微服务的增加，开发快速交付后，测试如果还是沿用以前的办法，则很难满足需求，这个木桶效应对整个团队的影响很大。

DevOps 要求快速有效的测试以及改进加快交付的途径，随着微服务和云计算等技术的逐渐成熟，我们可以进行动态实时质量的监控，持续的反馈机制、预防性评估等。此外，还要具备流水线环境的管理能力，因为如果部署环境依赖于开发或是运维，而此时如果有停顿，那么就无法继续工作了，其实测试人员完全可以自己来进行 CICD，这样就不用等待了。

对于非功能性的质量保障来说，在上云之后，除了功能性之外，还有与云相关的多租户、无状态、弹性扩展，服务的无状态，服务的治理等，测试人员也需要了解，否则无法满足敏捷开发的需要。最后，整个团队还需要具备敏捷基因，我认为要做敏捷测试，就应该先了解什么是敏捷开发。

02 试如何敏捷起来

1、敏捷测试的四要素

从测试流程来说可能都是一样的，顺序是计划-准备-执行-报告-发布上线。敏捷的过程的本质没变，但是它的组织过程发生了改变，也就是它的组织模式。敏捷开发中包含 scrum、看板、极限等，我认为也可以将其中的迭代、看板放到测试中。

首先，迭代是组织形式；其次，看板是为了方便监管，使工作更透明化；然后还需要自动化，比如发布新版本要做回归，对于大型系统手动回归的工作量太大，此时就需要自动化来辅助，这是为了提升回归的效率；最后，对于测试的产出需要进行度量。因此，如果要实现敏捷测试，我认为必须要具备这四个要素：迭代、看板、度量、自动化。

2、敏捷测试逻辑模型

■图 2

图 2 所示为敏捷测试的模型，左侧是看板和度量，最右侧是 CICD。sprint backlog 对应 sprint case，product backblog 对应 pro case 库。底层是流程驱动，上面是 bug 库，针对这 bug 库包含 To do 和 regression fixed bug，以及其他 To do(接口自动化测试、smoke caseUI 自动化测试，以及其他活动）。每次迭代就是对这些内容的重复操作。

目前市面上的很多测试管理工具都没有迭代概念，基本沿用了 testlink，但它已经不适合敏捷模式。

我们来看看 testlink 测试的组织管理形式的局限性。因为没有迭代，这个抽像层，特别不方便测试执行的过程管理，一个计划（建计划的过程也很繁琐）就是一个待测试用例集(或一个测试任务)，要按排 10 个人执行不同的测试任务，就要建 10 个计划，从管理层面没法了解某个迭代有多少测试任务，以及总体进度如何，相当于 testlink 一下进入细节，少了一个中间管理的抽。

另外，团队人员少时还好些，要是有 10 个人员，testlink 的过程管理，就相当不便，没有全局的视角来分配测试任务，和跟进这些任务这进度。且用例重用，也谈不上，没有可以项目用例双向同步的产品例库，也没有脑图用例等等便捷性的功能，统计分析也很弱，且测试管理不只是管用例编写和用例执行，还有其他前后移的相关任务。

3、敏捷测试持续改进

在项目管理中遵循 PDCA 原则，包括计划、实施、检查和行动四个要素，对应到敏捷测试是执行-评估-改进的过程，如图 3 所示。

■图 3

只有具备这些过程要素，才能保障敏捷测试工作真正落地。我们的工作都在看板上执行，以实现透明化。然后通过度量进行资产质量风险的评估，包括过程的监控、结果的分析，以及团队评估，最后再进行持续的反馈，并围绕这个过程不断地迭代。由此不禁要发出疑问，你的测试工具本身支持按照迭代的方式来进行管理吗？这是一个值得思考的问题。

4、敏捷测试度量

除了常规的统计分析外，一个质量大屏值得拥有,这对促进质量意识很有帮助。

图 4 展示了是对敏捷测试的监控，其中包括用例的情况、发生事故的情况、CICD 的情况、用例执行情况、用例执行的成本等，这里只是一个示例。

■图 4

03 公司（敏捷）测试的困境

1、中小公司测试乱象

中小公司测试存在很多乱象，我总结了如图 5 所示的几个方面：

■图 5

很多公司没有版本的规划，导致需求测试开发疲于奔命，bug 根本无法收敛；随着不断的变更需求，测试时间一直被压缩，测试人员由于没有产出直接的价值而背锅；项目没有有效的项目管理机制，尤其中小型公司（大公司非常健全、规范），基本上项目完成得好与坏取决于人，而正常的公司应该依靠制度而不是人；项目没有较好的质量管理体系，只是通过机械式的工具代表管理，实际上我认为工具只是用于帮助落地，应该通过管理的理念来使用或者适配工具，管理必须是有体系、有规范的，包含过程的规范、过程的监控、不断的迭代和反馈；没有培训机制，团队之间的信息传输仅靠口口相传等。

2、中小公司一线测试人员和测试管理者普遍遇到的问题

我总结了一下中小公司一线测试人员和测试管理者普遍遇到的问题，如图 6 所示。

■图 6

对测试人员来说，普遍遇到的问题包括没有特别好用的平台，影响工作效率；质量控制过程难以保证执行（虽然说公司可能都会有相关规定，但是如何保证过程是按照规定来的呢？从测试人员的角度来说，只要按照规定去做就可以了，不需要懂太多的管理性的问题，但是如果不能推行一个有效的手段，则可能到其他部门就被返回了）；测试任务不方便跟进；工作量及工作质量难以用数据来体现，这是普遍在很多公司都碰到的问题。

对测试管理者来说，普遍遇到的问题包括报告的数据维度单一，测试过程无法充分的分析（如果不能充分分析，就无法通过发现潜在的风险或是进行改进）；缺少项目的基线管理、版本迭代管理、测试任务管理等过程管理，跟进和优化测试过程都比较困难。

3、中小公司的测试困境

关于中小公司的测试困境，我总结了五个方面，如图 7 所示。

■图 7

4、测试陷入困境的症结

从上面的现象由表及里进行总结，问题的本质就是没有质量管理体系、质量控制手段缺失以及基础设施弱（基础设施包括测试环境、运维环境等）/成果难以度量，这些都是主要的症结。

04 敏捷测试落地案例分享

这里会列举 3 个案例。第一个是真实的案例，为什么把它放在第一个案件重点介绍呢？因为我觉得大厂一般比较规范，那么怎么把这些规范放到小厂中落地和实践？我觉得这是一个大家都应该学习的榜样。第二个案例是创业公司，它没有很多规范的流程，也没有很多的资源，这里介绍了他们如何以工具为牵引逐步落地，并总结出了自己的流程和管理规范。第三个案例介绍了起步公司，这些公司可能连老板在内也就十一、二个人，没有专业的 QA 但还要实现高频的发版。

1、共同目标

不管是做敏捷测试，还是别的的测试，我认为我们共同目标就是打造专业化的测试、提升测试的效率、建设一体化的工具链以及提升全员的质量意识。进一步延伸，就是质量内建，包括体系-人-目标-效率。

2、大厂到小厂以顶层设计的方式实践敏捷测试

(1) 大小厂的差异

大厂和小厂的差异如图 8 所示，大厂沉淀多，体系也比较健全，兵强马壮，但是部门墙比较厚，沟通成本也比较高，制度刻板不灵活，重复发明轮子多，基础设施比较完善，团队管理成本高。小厂基本上是拓荒的状态，没有太多的沉淀，体系也不健全，质量意识不强，质量测试管理也比较弱，软硬件不齐，有一定的环境管理能力，但是平台工具比较少或者没打通，团队的整体技术稍弱，有一定的测开能力，优势是灵活、快捷，管理成本相对较低。

■图 8

如图 9 所示，前面分析了差异，在实施敏捷测试的时候，还需要进行摸底，首先是摸底了解现状，摸底了解现状，然后了解一线人员的诉求和管理人员的诉求，找出突出的问题。比如发版随意的情况，如果随便乱发版，而且变更也很频繁，那么大家就会疲于奔命。

■图 9

根据调研的结果，得出初步结论：大厂的规范在小厂中并不适用，需要有所取舍；敏捷化转型需要化解哪些问题；追求质量与效率，轻量级的团队去快速迭代；利用敏捷测试管理平台来缩短跨部门的沟通，解决传统工具链分散，没有打通的问题。

(2) 顶层设计：测试生命周期及组织过程

根据结论就可以从顶层整体测试生命周期，对从需求的评审开始一直到版本发布后的生产验证再到上线的过程不断进行不同版本的迭代，这里甚至存在多个版本并行的情况，具体的流程如图 10 所示，包括测试计划、测试准备（其中最重要的是准入准出的条件）、测试执行（包括缺陷的分析、准入的判断等）、测试报告、发布上线。在测试的过程中，通过合理、科学、标准的测试步骤来规范测试过程，结果才能有保障。

■图 10

图 11 展示了整个测试过程：

■图 11

(3) 敏捷测试落地过程：基础建设

顶层规划之后分了 5 方面进行落地，首先是在基础建设方面建立体系，如图 12 所示，包括发版的流程、测试组织过程、bug 的生命周期的管理、bug 的流转机制、bug 的规范，以及字典的自定义维护、用例编写的规范、报告的产出物等。

■图 12

(4) 敏捷测试落地过程：团队建设

团队的建设如图 13 所示，包括梯队的建设，可在调研之后，提拔小组长，识别核心成员进行培养，对新员工进行培训（部门职能与简介、业务的范围、工作的机制、年度规划等）；质量意识，建立规范之后，要进行宣教并培训，让大家都要了解质量规范，特别是组长，因为他是落地执行的最小管理单元，一定要要深刻地理解质量管理体系的相关内容；制定一年或一年半的技术发展路线，为团队技术定一个基调，让大家都围绕这个方向学习或提升，而不至于偏离；建立学习型的团队。

■图 13

尽量少提钱，花钱的事，不好办，克服困难用现有资源搞定最好，有了业绩，后续伸手找老板要钱，要人才有底气。

(5) 敏捷测试落地过程：过程管理建设

过程管理建设如图 14 所示，前面提到了迭代，这里就要定义是以什么样的方式进行迭代（是按版本来迭代，还是按时间周期来迭代），以及每个迭代的任务分配和监督机制是怎样的，过程管理也可以放在基础建设中，但是我是觉得把过程管理单独拆分出来比较好一些，可以更聚焦过程优化。

对于过程监控部分，在执行过程中，如评审环境的流程，环境的管理流程是怎样的，线上问题的响应机制又是如何的，这些是过程监控需要关注的内容；对于汇报部分，除了测试内部的汇报之外，还包括对 PMO 的质量汇报的机制、形式及内容。一定要从整个项目管理去搞流程改进，同时还要有考核的相关办法（不是私利，要有大棒也要有枣），要不然，最后就是不了了之。

■图 14

(6) 敏捷测试落地过程：平台建设

对于小厂来说还要建设平台，如图 15 所示，应利用管理工具作为辅助，否则如果按传统的周期去培养团队，时间将会非常很长。此时导入一个符合敏捷测试的管理平台，则可以通过无人驱动的方式，通过工具来快速健全各种规范和落地，进而定义敏捷测试管理平台的诉求，并据此做选型的对比，在 POC 完之后与前面定制的质量管理体系进行对标，客观地评估 POC 的结果，以点带面、培训、推广。

■图 15

(7) 敏捷测试管理平台的诉求

对于敏捷测试管理平台的诉求如图 16 所示，它需要具备怎样的能力呢？包括支持以产品和迭代的维度来追踪需求生产到落地的全过程；版本的测试计划的执行过程追踪；以版本的维度设计、编写、评审、维护和管理测试用例；缺陷的追踪和管理；版本质量和测试过程的数据统计分析，这部分是基本的功能要求。

然后是平台的安全问题，因为要强调安全合规，不能在引入工具之后出现安全合规(比如接口测试，用在线的平台，你的 token，加解密过程等等有可能造成安全问题)、数据泄密等问题。接下来是易用性，这里要求必须交付友好，并且学习成本较低。最后要具备二次开发能力。

归纳起来就是，测试部的日常工作流程管理,和安全、稳定、易用、可定制的测试过程也是平台需要具备的。

■图 16

选型的时候，最关键的是要看是否更新频繁，而不是看广告，还要看是不是安全合规，如果说免费，但只是在线的免费，用接口测试这就非常不合适，这免费就是个噱头，安全合规根本过不了关。如果要用商用的，那就要有正当理由说服老板买单，如不能降本增效，用商用的不如用真正免费的替代产品，不为公司创造价值，老板咋可能买单。

比如你选用的商业接口测试，根本没有降低使用门槛，只有测开才能玩得转，很难说降本，如果点工都能用好，这一定能降本。一定要选一个 PLG 导向的，也就是产品驱动的，蓝湖就是 PLG 的榜样,她很牛，但是你见过多少蓝湖的广告!

(8) 敏捷测试管理平台功能对标

如图 17 所示，我根据前面的模型进行了敏捷测试管理平台的功能对标，包括环境的维护、测试流程的设置、接口用例、手工用例、不同的迭代等。

■图 17

其中，在每一个迭代里，不只是对测试用例的执行，还有 bug 以及其他事务等。在迭代下面就是各种分析的报告。前面确定了所需的工具，那么对工具进行评估之后，就反向促进团队敏捷思维的转变，让敏捷测试触手可及。

图 18 所示为一个看板，可以在其中处理 bug 和用例，从领导的角度来说，通过看板，就可以清楚地了解任务进展，实现透明化。

■图 18

图 19 展示了迭代的报告，包括用例、接口、任务、bug 的情况等，导出后会产生企划报告以及各种明细数据。

■图 19

另外，测试流程是可以设置的，如图 20 所示，不仅仅是通常大家所熟悉的提交问题、开发、能验证修复。

■图 20

如果测试人员中的新手特别多，则可以开启测试交叉流程，这样新人提交了 bug 后就能够先流转到有经验的测试人员手中进行 review，从而对新手进行指导，这种手把手的方式好过，对他再说的说教,比如，如何写一个好的 bug。

其他流程还包括分析修改工时、开发之人员之间的交互测试、分歧后有仲裁等，这些测试流程可以根据项目不同阶段，或是团队不同时期，可以实时变更。不同的流程也对应不同的状态的的演化(可按当前流程以及当前处理人，来控制当前 BUG 可转化的 BUG 态),这样才可以按需要来进行微调。

目前市面上我看到的工具基本上都是写死的，而且状态也很简单，很多根本不满足管理的需要，如“待改/持续跟踪”用于偶现的 BUG，暂时找到不原因，通过这状态可以直接看出来当前对这 BUG 的处理结果，另外，如开发设置 bug 状态为“非错”，测试人员不认同，可能设置为“分歧”就流转到仲裁人那里,开发如设置 bug 状态为“待改/延迟”,仲裁人同意后改为"待改/下版本修改"，不同意就是"待改"表明必须当前版本修改。

前面我们还讲到了频繁的变更的情况，如图 21 所示，可以在线下维护用例，再同步到线上，这里不是导入的概念，而是导出在线下执行离线修改。

■图 21

(9) 敏捷测试落地过程：度量及自动化

通过接口自动化可以做到：补充开发自测的不足；初级人员上手容易；快速冒烟；定时的巡检；长稳测试；实现 0 代码，全员都可以进行接口测试；实现 0 代码的压测；完成调用链的跟踪和接口的拓补；测开重点实现，组件服务化。

就度量而言，过程的监控、趋势的分析、结果分析、工作量分析、bug 处理时效、任务进度跟踪、测开重点是实现多维度统计分析。如图 22 所示，接口自动化中能推导出接口拓扑图（自动推导的），方便排查任务，如果出错，可以脱离被测服务，直接在调链上看到一切。

■图 22

如图 23 所示，通过拖拽后产生的断言可以自动生成一个表达式：

■图 23

图 24 展示了拖拽变量的操作：

■图 24

图 25 是接口的拓扑图，接口之间彼此存在依赖关系，如果采用手动执行的方法，我认为是把业务的逻辑强化在脑子中，随着接口的增加，很容易产生混乱。

■图 25

但这里的接口平台是自动推导，这样当执行接口的时候，就可以自动生成交易链，如图 26 所示。

■图 26

当把接口组装成更复杂的场景时，调用链看起来可能如图 27 所示：

■图 27

接口调用的参数情况如图 28 所示：

■图 28

此外还支持接口混沌测试，详见贴尾所列 testerhome 上的贴子。

另外，还有介绍一种通过反模式的方式来实现用例的覆盖率的情况。比如一个 case 要关联一个 bug，如果发现 10 个 bug 结果中有 5 个是没有关联用例的，一种情况是之前没写用例，并且有 10% 的值是允许探索的，最终目的是计算 bug 和用例的配比情况。这不是要求最开始就把用例写完，这么做的目的是规避风险。这样随着项目的推进，哪怕你在项目上线那一天，就把用例补完，那么从公司角度来说，用例既然这么完善，那么人员的变对项目影响就小得多。

用例覆盖率计算公式：（（用例数- 未关联 bug 数）/ 用例数 ）可+10%，开始一个 bug 没有 未关联的 bug 也是 0，这时 100% 对的，等项目做着做着就变了，如果是负数 那就更差，总之值越小覆盖率越低。如果低 1 可能没时间写用例；2 给时间写了，不认真写。算出来后 加一个 10% ，10% 的探索是合理的，我们不是强制要求测试人员一开始写完所有用例，我们是鼓励边测试边丰富用例，补也算他写了，后续版本，这用例就有了，这样 有人离职也不怕 用例在呢；这不是一刀切，只是保证最后得到好的结果。

通过执行成本来度量，而不是单看用例数，度量示例可见案例 29 的截图。

■图 29

(10) 敏捷测试落地过程：遇到的难题

落地过程中遇到的问题如图 30 所示(最上面是事前，中间是事中，最下面是事后)。

■图 30

前期包括调研时不配合（我觉得测试人员应该去考软考高项，而不是说去考 PMP，因为我觉得 PMP 花钱就能过，那么能学的东西就有限，而且软考更专注于 IT。在掌握这些知识之后，再去调研，就能够从项目管理的角度展开，视野会不一样，视野打开才能提出最合理的方案）、取得测试和研发领导的支持、资源不足、有反对的抱怨声、取得开发人员和 PM 的支持、项目提测演示退不下去。

在推进改革时，推不下去最主要的一个原因，是没有软实力，你的话没人信。去推动改进时，要从项目管理的方面去推，不能说开发哪哪不行，测试这块受影响，开发当然不乐意，要从大局来谈过程改进，想从测试则来推，推的人必须要有项目管理的视角，要不然，说难听点和上面沟通时，说话都不利索，也没有高度，上面咋信任你呢对吧，所以我都建议大家考软考高项，没过也没事，主要是确实要学一些东西，要么在大厂干过，有基础，要么自己系统学习过，自己工作中慢慢悟，太慢了。

一句话，软实力就是建立在和上面沟通过程中，你的谈吐的高度，你的认知的外在体现中体现的；测试管理这些其实都很虚，但是要真去做，并没那么简单，我干了这么多年，都一直在学习和改善我的管理体系。我做测试时，我们团队就是救火队的角色，有需要攻坚就是我们出马，尽管各种困难很多，我们还是干了出来，干出来了，说话才有份量，也间接提升了软实力，做事不要先讲客观原因，只要尽心尽力就好了，不要再意别的，干得多成长也快，老板要是瞎了眼，看不到你的价值，用脚投票就行。

另外测试人员，还要对新技术新事物，保持好奇心，每年要有一个成长计划，有什么新的技术，新的工具，都多去了解一下，尽可能的 POC 一下，不要拒绝新事物，后续才能左右缝源，出的方案能考验到方方面面。

作为一个测试人员，如果 mtsc 大会的是什么不知道，不知道 testerhome，我觉得很不应该；面试的话，我都要考查学习能力，以及学习欲望，这样的人一定是自驱动强，值得重点培养的人，潜力无穷。每年还要做好总结中，除本职工作外电，技术上有什么进步，有什么得失，对管理体系，有什么建议，看到什么问 题等等，这些都值得总结。马马虎虎过每年，工作 5 年和工作 2 年，没什么进步，这就危险;还要乐于分享，不要怕你的大招被人学了，分享也是自我总结。慢慢软实力冰就提升了，这是一个慢增长的过程。

前面提到整体从项目管理的角度来推进过程改进，主要是形成大家共同的工程意识，就算团队技术水平不错，技术人员的业务意识也很好，如没有工程意识，协作起来，沟通起来，就很费事。

实施过程中包括紧急需求和需求变更的冲击，可以通过建立产品规划、产品迭代制度、完善项目管理制度来解决；开发自测不充分，分支版本管理乱套，开发随时可以建分支版本，但是在提测的时候，只针对合并过来的版本进行测试。后期则需要通过度量来分析产生的问题，包括进度的分析、质量的分析，然后解决问题。

3、创业公司，以工具平台为牵引，逐步实践敏捷测试

以平台为牵引逐步落实逐步实践敏捷测试的诉求如图 31 所示。

■图 31

包括平台简单易上手，能够规范并固化管理流程，用例、bug 的管理快捷，方便 PM 做好监工角色，应对频繁的需求变更，缺陷状态更丰富，建立起有效的执行管理体系，逐步落地敏捷测试。小公司的测试负责人可能并不知道什么是好的流程，那么可以采用反向的方式，更注重流程的管理以及快捷，把迭代、看板、度量和自动化融合到测试的过程中，然后找到工具并反推其流程，总结出适用的公式流程，比如图 31 所示的测试人员、测试经理、分配人、开发人员、仲裁人员的流转等。

图 32 所示的这些状态可能和市面上看的有些不一样，因为是通过深度研究和反向来整理的。

■图 32

这种形式整理的文档包括测试的流程、冒烟测试流程、bug 的处理的流程等，它通过工具流程的形式反向促进团队的敏捷测试。通过深入研究工具，结合对公司的理解，可以整理出适合自己的规范体系。

■图 33

如图 34 所示，这里的发版也是采用离线形式，流程的实时定制、bug 的处理、演变状态等这里不再赘述。

■图 34

■图 35

■图 36

■图 37

■图 38

■图 39

4、创业起步公司且无 QA 且每两周高频发版的秘诀

创业公司什么都缺，连创始人都是干活的，但是方向和业务都非常清晰，有梦想与创新，加入这种团队也是一种荣幸。在这种情况下应该控制需求的力度，每一个需求都要尽量拆分，不允许一个需求的实现花两天，通过需求倒逼产品。另外，每个迭代都要实现技术方案的评审，评审要求简单讲清楚思路即可，可以两周执行一个迭代，第一周的周四进行单元和接口测试，第二周的周三再测试业务，保持效力。

在过程管理方面，我不提倡加班行为，上班的时候只做工作相关的事情，扁平化、透明化进行管理。日报除了给老板发之外，也应该发在工作群中，让所有人能看见。对于初创公司来说，如果起步刚刚还在 MVP 阶段，创始人对产品的要求很高，基本上都是创始人兼任首席产品的形式，但这只是短期的过渡，最终还是需要有测试团队。

05 敏捷测试趋势及展望

对于后续的展望，我比较认可的就是 testOps，如图 40 所示。

■图 40

06 问答环节

1、在敏捷测试中如何准备一份完善的测试用例？

在我们看来用例完不完善，主要在于 checklist 的时候有没有漏测试点。从执行角度来说要关注细节，但是从领导的角度来说，一份完整的用例首先是不要漏测试点，如果你漏测试点了，那么写再细也没用。在做用例评审的时候，我不会看用例的细节，而是看测试点是不是完整。所以我觉得好的用例应该具备完整的用例测试点，一看标题就能知道这个用例是干什么的，这样才能梳理测试点是否完整，否则细节写再多，我觉得从平台角度来说没办法花时间看。

点没漏，那如何保障执行细节不出差错呢？这就需要在评审时，先做业务讲解，然后再来检查，通过业务讲解可以很好的 cover 住，我们的测试人员是不是真正掌握了业务，业务都不明白，测试结果肯定不行，都不用看他的用例了。

2、案例中分享的工具或平台叫什么名字，能分享一下吗？

这个平台是免费的，大家可以去搜索一下，用关键词"开源中国敏捷测试管理平台" 去搜索。大家也可以看看 testerhome 上这个 122 个赞 ，近 2 W 个浏览量的贴子 。

https://testerhome.com/topics/30495 测试架构师如何解读测试平台的各种争议或是直接访问 www.itest.work