【方法论】软件测试的发展与应用实践原创

大家好，我是陈君彤，来自腾讯云coding团队的解决方案架构师。今天我给大家分享的内容是软件测试的发展与应用实践，以及基于coding产品的实践与操作演示。今天的课程会分为以下几个部分，除了介绍起源于发展之外，我们会以持续测试和自动化测试作为切入点，先进行理念介绍，再讲解对应的coding产品实现。我们先来看一段怀旧的历史视频。计算机2000年问题联合测试全国电力系统计算机2000年问题联合测试正式开始。如果你听说过千年虫的话，很可能你已经不年轻了。在2000年的1月1日，差点迎来了世界末日，日本的一处核设施发出了警报，五角大楼也通报了卫星系统将暂停工作，甚至连时任美国总统克林顿也发表了全国动员演讲。

这是怎么回事呢？原来当时因为计算机资源很珍贵，为了节约存储空间，对时间的记录采用的是六位，如图所示，是1999年12月31日的记录方法，也就是对于年份来说，只保留最后两位，那么当时间来到2000年的时候，最后两位是零零。对于计算机来说，可能会理解为1900年，由此可能引发一连串的未知后果，比如大型水电系统瘫痪，航天系统罢工等等。后来这个问题被称为2000年问题，简写为y twok，中文有个形象的叫法，称之为千年虫。

最终，千年虫危机在全世界联合起来的行动下得以平安度过，而且工程师们在计算机系统上为了解决千年虫危机所做的努力并没有白费。这次危机成了一个契机，让软件测试这个理念开始成为主流。这一节开始，我们简单讲讲软件测试的发展史。在过去的数十年里，测试本身并不是一个高优先级的工作，唯一重视测试的地方恐怕是美国宇航局NASA1958年的水星计划project mrcury标志着太空竞赛的开始。在五年时间里，他发射了美国第一颗卫星，并把人送上了太空。Jerry wber是这项计划的软件操作系统负责人。当时对测试并没有特别成熟的做法，他是那个时代的先驱了，他组建了可能是世界上第一支测试团队，聘请的呢，都是那些还不足以胜任程序员的人，这就是第一批单测试的人了。1964年，IBM公司推出了SYSTEM360，它的问是代表着世界上的电脑都有了一种共同的交互方式，他们都共享代号为OS360的操作系统，而非每种产品都用量身定做的操作系统。有超过1000位工程师在其系统上投入了超过十年的时间，使得其预算也从最初的2500万美元涨到了50亿美元。

这也反映了当时60年代软件开发的问题，一是开发周期长，二是人才供给有限。由此带来的影响是低质量的软件充斥着各种漏洞。这也是前面提到的前面从危机爆发的历史背景。也正是IBM system360的架构师f Brooks发表了他那篇著名的文章no silver bullet没有银荡。该论述中强调由于软件的复杂性本质而使真正的淫荡并不存在。所谓的没有淫荡是指没有任何一项技术或方法可以使软件工程的生产力在十年内提高十倍。看起来软件工程的发展之路似乎到头了，结果也不尽然，2001年的时候诞生了敏捷理念与方法，想详细了解敏捷的同学可以翻看我们第二节公开课的内容，我们做了比较详细的阐释。

敏捷的诞生主要是想克服传统的瀑布模型的缺点。在瀑布模型中，测试作为一个单独的阶段存在，这是一个优点，不过与之带来的缺点是太过后置，一旦发现问题就要从头再来。这也意味着开发团队和测试团队并没有在一起紧密协作。而敏捷的几个主要理念包括拥抱变化、快速迭代、开发团队内不同角色紧密协作等，使得测试在软件生命周期的一开始就要介入。与此同时，自动化测试也开始流行起来，测试开始变得不止是一项常规工作，而是形成了一个体系，包括了项目计划、监控和管理等。

这也就是今天所说的质量保障QA，那么今天的团队是怎么做软件测试的呢？首先要做一份测试计划，它描述了针对这个产品的测试策略，里面可以包含如图所示的这么多项内容，看起来很繁杂，对吧？其实怎么写测试计划也一直困扰着。James是何许原点呢？他是谷歌软件测试之道的作者，发表过一篇有名的博客，标题是the ten minute test plan，十分钟就能写好的测试计划。在这篇博客中，Jamess定义了三大核心要素，第一项是attribute属性，其定义了测试的主要目的，第二项是component组件，其定义了测试的对象，第三项是capability能力，其描述了用户能用这个功能实现怎样的能力。有了测试计划后，下一步就是编写测试用例和测试脚本了。

测试用例里一般会包含测试步骤、测试条件以及预期结果，我们也会把这样的测试称之为功能测试，用来检查软件是否按照确定的条件在正确工作。那么到这里，我们就有必要了解一些测试的分类了。测试也有很多种分类，拿功能测试来说，它通常有输入和输出，可以由不知道软件内部怎么实现的人来进行，所以这种方法也称之为黑盒测试。顾名思义，不知道盒子里面装了什么。这种方法也可以用来进行可用性测试，比如对于UX设计师来说，他们不需要看代码是怎么写的，只需要看软件的表现是否如预期即可。配合方式也可以用来做系统测试，测试系统整体的表现和稳定性的，比如会不会崩溃，能支撑多少并发的。除此之外，更多的时候呢，我们更要测试代码本身的质量与安全性。怎么做呢？我们就要从最小的单元测试做起，对于多个代码部分整合在一起的测试，我们称之为集成测试，这些测试方法称为白盒测试。它可以由写程序。

本身的开发或者会写代码的测试来进行，当然也不是所有的测试都有用力，或者有时候时间不允许进行全量测试，所以这时候需要针对重点，类似加法演习，所以有随机测试需要人来操作，毕竟计算机无法完全模拟人的行为。那么问题来了，在测试领域，计算机的强项是什么呢？答案就是自动化测试。

我们编写一次设置脚本，就可以由计算机重复的在不同设备、不同环境下随时进行。并且随着敏捷box的流行，自动化测试也成了持续加速中重要的一环。这是一张软件测试方法的分类图，让我们在系统性讲讲。第一，按照软件质量特性进行划分，包括功能测试和非功能测试。首先，从不良软件质量的几大特性出发，可以分为功能性、可靠性、可用性、有效性、可维护性等。功能测试一般根据测试实现的方式，包括接口测试、UI测试。非功能测试一般有性能测试、安全测试、兼容性测试的，而大多数非功能测试因为其并非一般团队频繁采用所掌握的，所以又称为专项测试。第二，按照测试技术是否借助于代码实现细节进行划分，包括黑盒测试和白盒测试。黑盒不需要了解程序内部的代码及实现，而是从用户角度出发，通过用户能够感知到的功能操作进行验证。白盒测。

是则需要针对程序内部的实现逻辑进行验证，又称为逻辑驱动测试或者结构测试。配合测试一般更容易反映用户的价值，但是一般测试效率不如白盒测试，而且一般在研发流程中处于后置的阶段，需要等到软件实现之后。而白盒测试则因为在代码实现的过程中就可以执行，能够更快反馈问题，但是难以直观反映用户价值，盲目追求覆盖率会容易限于价值不明显的投入误区。除此之外，当我们结合黑盒测试和白盒测试基于程序运行时的外部表现，同时又结合程序内部逻辑结构来设计测试用例，这样的方法又被升为黑核测试，仍然属于黑盒测试。集成类型的接口测试就是个很好的例子，通过编写代码、调用函数或者封装好的接口来模拟程序的执行路径，而无需关心程序内部的实现细节。

第三，按照测试执行方式进行划分，包括手工测试和自动化测试。顾名思义，手工测试是指通过人工的方式进行参与输入和用力执行，而自动化测试则是在预测条件下运行程序并评估运行结果。第四，按照不同开发交付的阶段进行划分，从前期到后期阶段，包括单元测试、集成测试、系统测试、交付验收测试。第五，按照不同测试策略进行划分。从某次测试覆盖的用力结合范围大小分为冒烟测试、回归测试等。冒烟测试是针对程序的主干功能进行的测试覆盖，希望较短时间内验证系统是否正常运行，而回归测试则是基于之前一段时间执行过的用力进行重新测试，看重的是测试覆盖的全面性。回归测试一般是最大的测试集合，较长的耗时注定了难以频繁被执行。

回归测试从验证的目的来看，还可以分为用力回归和缺陷回归。力回归是指无偏差的重复执行相同的测试题来验证是否会发现新问题，而缺陷回归是围绕着缺陷来执行相关的测试用例，验证当前版本中是否修复的之前版本中出现过的缺陷。而今，得到时代强调关注整体效率高于局部，持续不断的反馈、持续改进的文化，业内相关的实践纷纷前置不同类型的测试，努力提升执行效率。总体上，测试类型原先定义的边界开始变得越来越模糊，而更加关注测试的效率和快速反馈。于是才有了Google重新划分测试为小型、中型、大型的做法，分别对应着开发阶段的早期到后期执行的测试。了解完软件测试的发展史后，让我们回到日常工作中，测了什么？测完了没和测的快。

它可谓是团队经常面临的灵魂三考问，而随着敏捷与Del模式在软件行业的推广落地，更频繁的交付更是加重了业界对于测试的担忧。测试不够高效往往成为导致交付延期的首要原因，测试环节也就成为了企业进行de转型的最大瓶颈。为了应对这样的挑战，持续测试或者敏捷测试概念被提出了。那什么是持续测试呢？来自维棋百科的定义是在软件交付流水线中执行自动化测试的过程，目的是为了获取关于预发布软件业务风险的即时反馈，如左边的持续交付莫比乌斯环所示。显然，上述定义充分强调了自动化测试的重要性，这是持续测试的基础。但是回到通过持续测试获得效率提升和最终目标上，仅仅测试执行方式这个单点的效率提升还不足以。

去体现持续测试所带来的测试理念转变的本质。从整体测试效率的角度出发，另外一个双生概念敏捷模式所描述的迭代类测试或者敏捷测试就成为了更好的补充。持续测试应该作为一项基础和持续的活动贯穿于整个软件交付周期之中。右边来自drinking社区的图更好的体现了这个概念。那么要如何实现持续测试呢？持续测试改变的是传统测试后置的工作模式，让测试活动延伸到软件开发生命周期的每个阶段。我们提出以下四点建议，第一点是需求规划阶段尽早计划测试，并且策略性定义测试子集。首先从需求分析的阶段就开始提前计划测试，编写测试用例，使之达成适当的需求覆盖率。对此有帮助的实践包括a ddb DD，尤其是TDD难以落地的团队可以尝试ADD。

其次，要有优化测试覆盖范围的意识。测试不应该盲目追求百分百覆盖，而是基于业务风险和价值的测试策略进行测试百分百覆盖优先级高的需求，远比80%覆盖了所有需求来得有价值。第二点是迭代进行当中推动测试左移，实现测试与开发并行工作。测试执行应该前置到软件开发生命周期的早期，多种工程实践可以帮助团队实现左移，比如重视测试评审，通过单元测试进行基础性保障，基于接口定义的开发和自动化测试，比如代码扫描，判断是否满足编码规范和工程标准。这样在迭代周期内围绕着需求持续进行集成测试用例的编写，并且与开发保持进展协同，为开发提供必要的测试支持，使得测试与开发的工作实现同步进行。第三点是迭代进行当中，以。

便捷的方式提供完整的测试环境和正确的测试数据。一直以来，接近生产的测试环境打造和脱敏数据的快速准备是团队面临的两大重要挑战。现今随着云原生技术的成熟，尤其是多可技术，让按需搭建和销毁环境变得可能。但是测试数据的管理仍然是个难题。基础数据像账号信息、环境信息这一类容易标准化的数据在业内已经有了比较好的解决方案，这已经是个重大进步。而业务数据由于场景多变性，一直缺乏足够好的抽象，还处于依赖框架进行流程规范的基础阶段，基于接口定义的开发，从而实现梦服务也能够带来过程效率的提升。第四点是应用部署之后关注测试右移，传统互补模式把部署作为测试的下一阶段，也就意味着应用发布上线快速验证功能之后就是测试的结束。而持续测试则不认为。

发布完成测试就退出了。强调的是在版本上线后，继续关注生产环境的数据监控和预警，及时发现问题并跟进解决，将影响范围降到最低。并且利用生产上的数据可以作为开发过程带来切实的价值，比如复制生产数据进行脱敏来准备测试数据，对服务访问数据进行分析的结果，也可为开发过程的测试提供优化的指引，从而调整测试并行成更好的冒烟和回归测试策略等等。又一的实现包括数据分析、灰度金丝雀发布、线上实时监控、用户反馈的跟踪处理流程等等。此外，我们在实现持续测试的过程中，要关注数据的沉淀，然后基于数据指标不断优化我们的行为，从而实现得到所推崇的持续改进的团队文化。

在介绍coding测试管理的产品实现之前，我们先来看coding的能力全景图，如上图所示，Coding式一站式的get研发管理平台涵盖了软件开发生命周期中的各个阶段。那么，Coding是如何助力实现迭代类的持续测试的呢？测试过程一般包括计划、设计、用地、执行这几个环节，如图所示。这就是在敏捷模式中的迭代中的测试视角的经典工作流。基于这样的场景，Coding基于以测试计划为测试活动的主体理念，设计并打磨产品，给用户沉浸式的测试体验。接下来让我们看看如何在一个完整的迭代中开展测试活动。

首先从项目协同中规划好的迭代开始，创建团队的测试计划，并关联对应的迭代。然后在团队测试计划创建好之后，计划中会展示迭代的需求故事，接着为需求故事创建相应的功能用例，内容上可能只是会带上规划会上达成一致的验收标准，简称为AC。把相关的用力任务分配给对应的测试同学，就形成了一个测试团队视角的迭代看法。这些操作完全可以在规划会上或者背后的短时间内完成。测试计划包括了迭代故事列表以及相应的AC作为内容的用例，暂且称之为测试计划阿尔法版。开发同学实现编码的同时，测试同学也应该同步编写该故事的测试用例。多数情况下是对AC进行细节性的展开和编写，补充完整。用力逐步补充完整的测试计划可以升为测试计划贝塔版，当用力编写完毕之后，及时进行评审，甚至在接口契约得到保障的情况下，实现接口自动化测试的编码，这样的节奏也就实现了测试与开发的工作同步。需求故事提测后执行测试用例，对照用例步骤验证功能是否完整。这样每个故事都是开发完成后马上测试通过，属于可销付的状态。在这样小步快走的模式下，迭代在任何时候结束，都可以交付有业务价值的需求故事，而不是一批半成品。如此，通过开发测试的紧密协同工作，逐步接近体现业务价值的持续交付。在迭代最后需求故事都完成之后。

我们就可以获得了包含完整测试用例内容的测试计划正式版，由此生成测试报告，根据通过率和报告反映出来的风险来判断是否可以发挥到下一个环境做个总结。coding迭代视角的测试工作流的核心理念是引导测试的前置，在过程中增强了测试与其他角色的协作与反馈，目的是通过产品能力来帮助团队固化良好实践，从而实现高效的测试。当下，业内已经形成了一致的认识，自动化测试是持续测试的基础，是de时代中不可或缺的实践。此外，由于自动化测试的执行效率很高，体现出来的时间成本优势更是明显，甚至比成本优势更能戳中这个快速发布时代的痛点。因为不这样做的话，我们会越来越难以应对短周期发布所需要的快速有效验证。

那么要如何有策略的开展自动化测试呢？我们提供的建议是，测试体系建设需要分层策略指引，接口测试往往最优先。不少人对于金字塔模型的第一印象是其给出在三种测试上的投入占比建议，单元测试最多，接口测试居中，UI测试最少，比如70%、20%、10%。但更为重要的是，麦提出了对于测试进行分层的理念，以及给出了每个层级的测试优缺点，越接近用户使用界面的高层次，测试力度越粗，效率越低，写的测试应该越小，反之，越接近底层代码的测试力度越细，效率越高，应该写的更多，也应该执行的更频繁。而在实践当中，每个企业面临的场景不同，投入情况也不大一样。比如现实情况可能并不是金字塔，而是纺锤形状的。中间的接口测试占比最。

然种种实践表明，在自动化测试建设的初期，接口测试往往是团队开展自动化测试的首选。这是因为接口测试兼备执行效率和体现业务价值两方面的优点，在这个领域进行资源投入较为容易被测试团队和业务团队共同接受，而且由于接口定义的稳定性也较高，其维护成本也是可控的，所以相对单元测试和UI测试来说，接口测试的投入产出比可以说是最高的。

而接口测试以接口定义管理为基础，契约变更的同步提醒和梦是关键。coding测试产品推崇的是业务驱动测试，一切从业务需求出发，通过建立自动化跟业务需求的关联，可以让自动化有效的扩大覆盖率，而不是凭空随意去写测试代码，产生重复的无效测试。同时，坡顶自动化用例库通过对自动化测试代码进行解析，把得到的函数列表匹配到相应的功能用例，基于已有功能用例与需求的关系，形成自动化用例与需求功能的映射关系。基于这样的关联关系，我们就可以顺藤摸瓜，根据某个自动化函数执行失败找到对应的哪个需求有问题，然后根据需求的优先级或者影响范围决定是否进行下一步是打回修复问题，还是决定继续发布上线。那么具体的实现方式也不复杂，第一步是建立自动化代码和功能用例的匹配关系，让自动化覆盖率一目了然。coding提供示例代码导入，帮助用户通过在代码中按照规则在注解注释中填写功能用例ID或者人工判断，让解析出来的自动化代码函数跟已有的功能用例进行匹配，逐步提升功能用力的自动化覆盖率，也会精准测试打下基础。第二步是在迭代进行当中，能够选择性执行客定的自动化用例级，在普通测试计划中，可以缺选部分功能用力来执对应的自动化用例。而在迭代测试计。

计划中缺选特定需求后，对应的功能用力列表也就产生了，从而实现业务驱动自动化用力的执行。coding会持续加强灵活执行自动化测试方面的能力，提供更加流畅的聪明执行的场景方案。最后做个总结，自动化测试体系的建设是一个系统工程，涉及到人、技术、流程等方方面面，我们尤其需要全局思维，全衡利弊，没有最好的，只有最合适的方式。holding测试管理的完整演示视频将由来自腾讯云holding团队的解决方案架构师钟启工为大家进行演示与解说。