一.衡量软件测试结果的依据—需求1.需求的概念满足用户期望或正式规定文档合同、标准、规范所具有的条件和权能包含用户需求和软件需求IEEE 给的定义软件需求是1用户解决问题或达到目标所需的条件或权能Capability。2系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。3一种反映上面1或2所述条件或权能的文档说明。它包括功能性需求及非功能性需求非功能性需求对设计和实现提出了限制比如性能要求、质量标准或者设计限制。在多数软件公司中需求通常分为两部分一部分是用户需求另一部分是软件需求。1用户需求可以简单理解为甲方提出的需求如果没有甲方那么就是终端用户使用产品时必须要完成的任务。该需求一般比较简略通常是一句话。用户的需求五花八门往往只是一句话比如实现一个声控灯实现一个软件的登录功能。2软件需求或者叫功能需求。该需求会详细描述开发人员必须实现的软件功能。软件需求是测试人员进行测试工作的基本依据。大多数公司在进行软件开发时会把用户需求转化为软件需求而开发人员和测试人员工作的直接依据就是软件需求。理解起来就是用户需求就是一句话软件需求是一个文档详细描述用户需求如何实现日常工作中通常是用软件需求进行开发测试。⽤⼾需求和软件需求有什么不同呢看看下⾯的案例⼥朋友饿了的例⼦ ⽤⼾需求 ⼥朋友说, 我饿了, 这是⼀个⽤⼾需求. 很简略. 软件需求 需要你和她反复的沟通了解更加详细具体的需求, 来制定解决⽅案. ⽐如你问她, 想吃啥?, 她说, 随便 吃⽶饭炒菜?, 不想吃; 那你想吃啥?, 随便 吃油泼⾯?, 不想吃; 那你想吃啥?, 随便 ... 最终理解清楚⽤⼾需求之后, 知道⼥朋友想吃的是你做的红烧⾁, 那么再去研究⾁怎么买, 怎么做等等 的具体步骤, 是软件需求.在⼯作中我们实际⻅到的软件需求⽂档类似于下⾯的表述软件需求规格说明书 ⼀、⽤⼾需求 平台⽀持邮箱注册 ⼆、软件需求 1.1.1.1 注册账号 1.1.1.1.1 功能概述 用户可以通过填写邮箱信息在平台注册个人用户。 1.1.1.1.2 用户角色 匿名用户。 1.1.1.1.3 前置条件 无。 1.1.1.1.4 输入 序号 栏位名称 栏位说明 长度 类型 备注 1 姓名 必填录入个人姓名 6~15位 字符型 2 电子邮箱 必填录入电子邮箱 字符型 3 密码 必填输入的密码隐藏*号显示 6~15位 字符型 4 确认密码 必填输入的密码隐藏*号显示 6~15位 字符型 5 验证码 必填录入验证码 字符型 6 注册 注册操作 操作型 1.1.1.1.5 处理 1.1.1.1.5.1 基本事件流 1、用户选择注册 2、系统展现用户协议界面并请用户确认是否同意用户协议。 若用户不同意协议系统禁止用户注册。 若用户同意协议用户进行注册信息填写。 3、用户填写注册信息。 注册个人填写姓名电子邮箱密码确认密码验证码。 4、用户提交注册信息 5、系统提示用户并向用户注册的电子邮件地址发送一封含有激活信息的电子邮件。系统并提示用户若未收到激活邮件可使用注册的邮箱和密码登录系统后再次发送激活邮件。 6、用户可执行激活操作直接跳转至注册邮箱门户页面。 7、用户通过接收到的电子邮件中的激活信息激活账号用户注册完成流程结束。 1.1.1.1.5.2 扩展事件流 用户注册并激活成功后第一次登录平台时提示用户完善信息 1.1.1.1.5.3 异常事件流 若用户未收到激活邮件可在登录界面录入电子邮件及密码后再次发送激活邮件。 每次发送的激活邮件仅在发送邮件后起24小时之内有效超过24小时后需重新发送激活邮件。 1.1.1.1.6 输出 用户注册成功 1.1.1.1.7 后置条件 该模块为用户登陆等的前置模块。注意⽤⼾的需求不能直接作为开发和测试的依据。针对⽤⼾的需求产品经理需要进⾏需求分析技术可⾏性、市场可⾏性、成本投⼊和收益占⽐等后才可转变为软件需求。为什么要有需求有需求才有目标做事就需要有明确的需求。2.从软件测试人员角度看需求需求是测试人员开展软件测试工作的依据。在具体设计测试用例时首先需要搞清楚每一个业务需求对应的多个软件功能需求点然后分析出每个软件功能需求点对应的多个测试需求点最后针对每个测试需求点设计测试用例。过程如下业务需求 -- 软件功能需求点 -- 测试需求点 -- 测试用例以“用户登录”为例来阐述一下整个过程3.为什么需求对软件测试人员如此重要从软件功能需求出发无遗漏地识别出测试需求是至关重要的这将直接关系到测试用例的覆盖率。对于识别出的每个测试需求点需要采用具体的设计测试用例的方法来进行测试用例的设计。4.如何才可以深入理解被测试软件的需求测试工程师应在需求分析和设计阶段就开始介入因为这个阶段是理解和掌握软件原始业务需求的最好时机。只有真正理解了原始业务需求之后才有可能从业务需求的角度去设计针对性明确、从终端用户的使用场景到端到端的覆盖率较高的测试用例集。二.测试用例Case的概念测试用例Test Case是为了实施测试而向被测试系统提供的一组集合这组集合包含测试环境、操作步骤、测试数据、预期结果等要素。测试用例解决了两大问题测什么怎么测。测试用例的作用指导测试执行避免遗漏便于回归测试和版本迭代衡量测试覆盖率方便测试人员之间的协作与交接。1.举例如下【测试用例淘宝购物下单】测试环境淘宝 APPAndroid 端 / iOS 端操作步骤打开 APP搜索商品加入购物车提交订单完成支付测试数据商品名称、收货地址、支付方式支付宝/微信、优惠券预期结果订单提交成功支付成功订单状态变为“待发货”序号1、2、3....标题商品成功下单并完成支付【测试用例taobao-001】测试用例 taobao-001: 用户成功购买商品 -------------------------------------------------------------------------------- 步骤动作: | 期望的结果: -------------------------------------------------------------------------------- 打开淘宝 APP登录账号 | 登录成功进入首页 -------------------------------------------------------------------------------- 搜索指定商品并进入商品详情页 | 商品详情页正常展示包含价格、库存、评价等 -------------------------------------------------------------------------------- 选择商品规格颜色、尺码点击加入购物车 | 提示加入购物车成功购物车数量1 -------------------------------------------------------------------------------- 进入购物车勾选商品点击结算 | 进入订单确认页面商品信息、收货地址正确 -------------------------------------------------------------------------------- 选择收货地址选择支付方式提交订单 | 订单提交成功跳转到支付页面 -------------------------------------------------------------------------------- 完成支付支付宝/微信 | 支付成功订单状态变为“待发货” -------------------------------------------------------------------------------- 测试方式 | 手工 -------------------------------------------------------------------------------- 重要性 | 重要 -------------------------------------------------------------------------------- 测试环境 | Android 13 / iOS 16 -------------------------------------------------------------------------------- 测试前提 | 账号已登录收货地址已添加网络正常 -------------------------------------------------------------------------------- 功能模块 | 购物下单2.为什么要有测试用例测试过程中可能会遇到以下问题不知道是否较全面地测试了所有功能测试的覆盖率无法衡量对新版本的重复测试很难实施存在大量冗余测试影响测试效率。测试用例的产生就是为了解决上述问题。测试用例可以提高测试人员的工作效率降低测试人员工作的重复性。测试用例是建立自动化的基础。自动化就是把测试人员的双手解放出来让代码代替人工执行测试三.软件错误BUG的概念第一个 bug1945 年 9 月的某天在一间老式建筑里从窗外飞进来一只飞蛾。此时 Hopper 正埋头工作在一台名为 Mark II 的计算机前并没有注意到这只即将造就历史事件的飞蛾。这台计算机使用了大量的继电器电子机械装置那时还没有使用晶体管。突然Mark II 死机了。Hopper 试了很多次还是不能启动她开始用各种方法查找问题最后定位到了某个电路板的继电器上。Hopper 观察这个继电器惊奇地发现一只飞蛾已经被继电器打死。Hopper 小心地用镊子将飞蛾夹出来用透明胶布贴到“事件记录本”中写上“第一个发现虫子的实例”。Hopper 的事件记录本连同那只飞蛾现在都陈列在美国历史博物馆中。软件错误的一般定义程序与规格说明之间不匹配。注意以上说法是片面的。准确地说当且仅当规格说明软件需求 / 规格说明书是存在的并且正确程序与规格说明之间的不匹配才是错误预期结果 ! 执行结果。当需求规格说明书没有提到的功能时判断标准以最终用户为准当程序没有实现其最终用户合理预期的功能要求时就是软件错误。四.开发模型和测试模型1.什么是模型随着软件⼯程学科的发展⼈们对计算机软件的认识逐渐深⼊。软件⼯作的范围不仅仅局限在程序编写⽽是扩展到了整个软件⽣命周期如软件基本概念的形成、需求分析、设计、实现、测试、安装部署、运⾏维护直到软件被更新和替换新的版本。软件⼯程还包括很多技术性的管理⼯作例如过程管理、产品管理、资源管理和质量管理在这些⽅⾯也逐步地建⽴起了标准或规范。2.软件的⽣命周期认识具体的开发模型之前先了解软件的⽣命周期。什么是⽣命周期⽣命周期指的是从⽣命的开始到⽣命结束的⼀段时间。以⼈为例⼈类的⽣命周期是从⽣命孕育的开始中间会经历幼年童年少年⻘年⽼年最终直⾄死亡。⽽软件/产品的⽣命周期也是如此需求的开始是软件⽣命的起点中间会经历需求的计划、设计程序开发程序测试等阶段直⾄软件不再进⾏维护便到了⽣命的重点。案例假如我想要建造⼀套房⼦别问问就是⼀个⼈造房⼦房⼦的⽣命周期流程是什么样的因此我们就得到了软件开发的⽣命周期需求分析⸺计划⸺设计⸺编码⸺测试⸺运⾏维护对于软件的⽣命周期中每个阶段都在做什么呢阶段具体内容产出需求分析分析需求是否合理从市场、技术等多个维度开展评估分析。输出需求相关文档。计划针对已确认的需求制定项目执行计划明确需求交付周期划分各时间段需要落地的功能模块。输出项目计划文档。设计把需求拆解为独立任务团队成员认领任务开展技术设计包含架构方案、接口定义、技术选型等工作。输出技术相关文档。编码开发人员依据需求文档、设计文档、交互原型等资料完成代码开发工作。代码文件及配套开发文档。测试测试人员开展软件测试工作依据测试用例对软件各项能力进行验证。测试用例、测试方案、测试报告测试报告是软件上线的准入依据无合格测试报告软件不得上线。【测试报告】 项目名称 学生信息管理系统 开发 张三 测试 李四 产品经理 王五 Bug 描述 在学生信息管理系统中当用户进入 “学生列表” 页面点击 “新增学生” 按钮并提交表单时如果表单中 “学号” 字段为空系统没有给出明确的错误提示而是直接保存了一条学号为空的学生记录。该问题导致学生列表中出现异常数据影响后续查询和统计功能。 测试周期 5 天6.01 - 6.05 开发周期 10 天5.20 - 5.30 风险 低风险。该问题不会造成系统崩溃或数据泄露但会影响数据准确性建议在后续版本中增加表单校验和错误提示最后一个阶段运行维护具体产出项目测试结束之后项目需要进行上线并对产品进行线上的维护。线上的维护主要分为三个方面分别为修复性维护、完善性维护和预防性维护。修复性维护对项目中未发现的问题进行修复。完善性维护对功能进行完善。预防性维护居安思危为了避免产品在线上出现一些其他不可预料的问题进行一些防护的手段。如果出现线上问题此时测试人员需要协助开发定位问题 解决问题。3.测试模型 —— 瀑布模型Waterfall Model瀑布模型在软件⼯程中占有重要地位是所有其他模型的基础框架。瀑布模型的每⼀个阶段都只执⾏⼀次因此是线性顺序进⾏的软件开发模式。阶段产出需求分析输出需求文档计划确定项目起止时间与排期设计输出技术文档包含接口、数据库表、消息队列、定时任务等内容、UI 视觉稿编码程序代码开发测试执行测试用例、提交缺陷、开展验收(1) 优点开发过程划分成清晰独立的阶段阶段性强重视项目前期规划与需求调研工作重视产品测试环节每个阶段的工作内容与交付物明确清楚模型为线性流程各阶段仅执行一次是很多其他软件开发模型的基础框架(2) 缺点测试滞后前期各阶段埋下的问题往往等到测试阶段才暴露极易引发大规模返工错失早期修复缺陷的机会需要预留充足的测试时间若测试时间不足测试覆盖不全缺陷会直接交付给用户影响产品质量项目整体周期偏长可用产品交付很晚容易出现需求过时、功能不符合当下业务的情况高度依赖前期一次性需求调研很难应对需求中途变更流程单向不可逆项目过程中积累的经验无法反向优化本项目前面的开发环节项目风险大多到后期测试阶段才显现没办法尽早纠正瀑布模型的⼀个最⼤缺陷在于可以运⾏的产品很迟才能被看到。这会给项⽬带来很⼤的⻛险尤其是集成的⻛险。因为如果在需求引⼊的⼀个缺陷要到测试阶段甚⾄更后的阶段才发现通常会导致前⾯阶段的⼯作⼤⾯积返⼯业界流⾏的说法是“集成之⽇就是爆炸之⽇”。尽管瀑布模型存在很⼤的缺陷例如在前期阶段未发现的错误会传递并扩散到后⾯的阶段⽽在后⾯阶段发现这些错误时可能已经很难回头再修正从⽽导致项⽬的失败。但是⽬前很多软件企业还是沿⽤了瀑布模型的线性思想在这个基础上做出⾃⼰的修改。例如细化了各个阶段在某些重点关注的阶段之间掺⼊迭代的思想。在瀑布模型中测试阶段处于软件实现后这意味着必须在代码完成后有⾜够的时间预留给测试活动否则将导致测试不充分从⽽把缺陷直接遗留给⽤⼾3适用的项目比如那些需求固定的小型项目适用于这种模型。4.测试模型 —— 螺旋模型Spiral Model⼀般在软件开发初期阶段需求不是很明确时采⽤渐进式的开发模式。螺旋模型是渐进式开发模型的代表之⼀。这对于那些规模庞⼤、复杂度⾼、⻛险⼤的项⽬尤其适合。这种迭代开发的模式给软件测试带来了新的要求它不允许有⼀段独⽴的测试时间和阶段测试必须跟随开发的迭代⽽迭代。因此回归测试的重要性就不⾔⽽喻了。1优点对项目全流程开展严格的风险管控。重视软件每个开发阶段的质量保障。在项目过程中可以评估项目价值判断是否继续推进项目。引入风险分析机制与原型开发。在每个迭代周期内同步完成风险评估与原型搭建降低各阶段遗留隐患规避线上故障。2缺点模型对风险识别、评估、管控的要求很高项目风险管控效果很大程度取决于风险负责人的专业能力对人员技术经验要求高。风险评估存在误判可能性同时单独配备风险分析人员会带来额外人力、资金与时间开销抬高项目整体成本。3适用的项目适合规模大、业务复杂、潜在风险较高的项目。 该模型属于迭代开发模式对软件测试提出新要求不存在独立完整的测试阶段测试工作需要跟随开发迭代同步开展回归测试在此模型中尤为关键。5.开发模型 —— 增量模型、迭代模型增量模型把庞大的需求拆解成若干独立的小功能模块逐个完成开发并上线。迭代模型先交付一个基础版本该版本覆盖全部业务功能但实现效果比较简易后续不断迭代优化升级。增量开发可以有效降低项目风险搭配软件持续构建的思路是目前软件工程领域很主流的实践方式。增量模型支持收集用户反馈在每一轮迭代中开发团队按照可预期的循环模式推进产品研发。在该模式下每一轮迭代都可能带来需求调整同时产出新的可运行程序版本测试工作需要高频开展测试人员要和开发人员紧密配合。增量开发和迭代开发经常被混淆但二者核心思路不一样增量侧重分模块逐步搭建迭代侧重在整体雏形上反复打磨完善。举个例子画人像。增量思路先画头部接着画躯干最后补全四肢一块一块完成。迭代思路先勾勒完整人像轮廓得到粗略初稿之后不断细化线条、填充色彩持续优化整张画。伴随着互联网行业发展很少有企业单独使用其中某一种模型大多会把增量与迭代模型结合起来落地。适用场景大型项目、需求模糊不确定的项目。6.开发模型 —— 敏捷模型早期迭代瀑布模型曾广泛用于项目开发但在实际落地时开发人员会遇到不少难题。最突出的问题就是项目开发阶段很难处理客户提出的需求变更一旦改动往往要投入大量时间与成本去适配这些变更。为了解决瀑布模型存在的这些短板敏捷软件开发模型在 20 世纪 90 年代中期被提出。敏捷模型的核心目标是让项目能够快速响应需求变动以此助力项目高效交付。想要实现这一点就需要依靠敏捷性让开发流程适配项目本身剔除对当前项目没有必要的工作摒弃一切会浪费人力与时间的活动。在敏捷模型里整体需求会被拆分为多个小型模块采用增量 迭代的方式进行开发。每一个模块都在迭代周期内完成开发单次迭代体量小、容易管控一般几周内就能完成。团队会针对每一轮迭代进行规划、开发并交付给客户不会制定跨度很长的项目计划。敏捷模型里有一份核心文档 ——《敏捷宣言》内容如下个体和交互高于流程和工具看重高效沟通可运行的软件高于详尽的文档提倡精简文档文档不作为验收标准客户协作高于合同谈判主动持续了解客户真实需求响应变化高于固守计划主动接纳需求变动宣言采用对比表述但每一组对比里并不是说后者毫无作用只是我们会优先看重前者不会完全否定后者的价值。从敏捷宣言能够提炼出敏捷模型四大特征文档轻量化、流程轻量化、聚焦目标、重视可交付成果。敏捷开发包含多种实践框架Scrum 就是其中应用十分广泛的一种。从这份宣言也能看出敏捷本质上属于软件开发中的社会工程学。敏捷最大的价值在于它关注如何调动开发人员的工作积极性而这一点在软件工程过去几十年的发展中常常被忽视。1Scrum敏捷开发包含多种实现框架Scrum 是应用十分广泛的一种它属于迭代增量式软件开发模型。Scrum 框架包含三大核心角色与五项关键会议。a. 三个角色Scrum 团队由产品负责人Product Owner、Scrum Master 以及研发团队构成。产品负责人Product Owner梳理用户故事明确各项需求的业务价值对需求优先级排序制定产品发布规划全权对最终产品负责主要工作收集整理需求。产品负责人是连接业务方与研发团队的桥梁需要持续与客户、用户沟通确保团队始终朝着正确的业务方向推进。Scrum Master组织各类项目会议协调项目内各类事务为研发团队扫清障碍、提供支持。Scrum Master 是 Scrum 流程的守护者负责确保团队遵循 Scrum 的规则与实践帮助团队持续改进工作方式提升协作效率同时保护团队免受外部干扰让团队成员能够专注于迭代目标。研发团队集合各类专业技能人员依靠团队紧密协作完成每一轮迭代任务交付可用产品。团队包含前端、后端开发、测试、交互、设计等岗位人员。研发团队是自组织的成员之间相互配合、共同对交付质量负责在每一轮 Sprint 中自主认领任务、评估工作量并通过每日站会同步进度、及时暴露风险确保迭代目标能够按时达成。b. 迭代开发和瀑布模型不一样Scrum 把整个产品开发拆分为多个短小的 Sprint 迭代周期周期时长范围为 14 周最长不超过 4 周。团队规模一般维持在 59 人。每一轮迭代要完成的用户故事在迭代开始就确定下来每次迭代结束都会产出可交付成果。c. scrum 的基本流程scrum的基本流程如上图所⽰产品负责⼈负责整理user story形成左侧的product backlog。发布计划会议product owner负责讲解user story对其进⾏估算和排序发布计划会议的产出就是制定出这⼀期迭代要完成的story列表sprint backlog。迭代计划会议项⽬团队对每⼀个story进⾏任务分解分解的标准是完成该story的所有任务每个任务都有明确的负责⼈并完成⼯时的初估计。每⽇例会每天scrum master召集站⽴会议团队成员回答昨天做了什么今天计划做什么有什么问题。演⽰会议迭代结束之后召开演⽰会议相关⼈员都受邀参加团队负责向⼤家展⽰本次迭代取得的成果。期间⼤家的反馈记录下来由po整理形成新的story。回顾会议项⽬团队对本期迭代进⾏总结发现不⾜制定改进计划下⼀次迭代继续改进以达到持续改进的效果。Scrum 敏捷开发模型完整的迭代循环流程起点用户需求池收集所有用户需求统一存放作为整个项目的需求来源。发布计划会议评估需求是否合理筛选确定本轮迭代要完成哪些需求。迭代计划会议把选定的需求拆解成具体任务确定任务负责人、预估工时团队成员认领任务在迭代周期内开展工作。迭代周期内每日站会每日会议团队每天简短开会回答三个问题昨天完成了什么、今天计划做什么、遇到了哪些阻碍。 作用同步进度、暴露问题保障迭代能按时交付。迭代结束演示会议本轮迭代完成产出可交付的软件版本。团队向相关人员演示成果收集反馈找出产品现存缺陷、待优化点、新增需求。回顾会议复盘本轮迭代整个流程找出本次迭代过程里存在的问题总结经验制定优化方案改进后续工作。循环闭环演示和回顾产生的新需求、优化建议全部回流到用户需求池。然后开启新一轮迭代循环往复持续交付软件(2敏捷中的测试轻⽂档和快速迭代敏捷模型中强调轻⽂档所以测试⼈员不应使⽤传统的Excel编写测试⽤例的⽅法更多的是思维导图、探索性测试强调⾃由度设计和执⾏同时进⾏根据测试结果不断调整测试计划、⾃动化测试等敏捷讲求合作在敏捷项⽬组中测试⼈员应多主动跟开发⼈员了解需求、讨论设计、⼀起研究bug出现的原因。7.软件测试 —— V 模型V模型最早是由Paul Rook在20世纪80年代后期提出的⽬的是改进软件开发的效率和效果。是瀑布模型的变种 。V 模型V 模型是瀑布模型的变种开发阶段和测试阶段一一对应左侧开发阶段用户需求产品经理收集用户需求整理输出软件需求。需求分析与系统校验需求准确性选定项目的编程语言与开发框架。概要设计完成项目整体架构、项目结构的方案设计。详细设计明确各个接口、数据库表、相关任务细节。编码开发人员编写代码。右侧对应的测试阶段单元测试对最小代码单元测试Java 测试类与方法C 语言测试函数。对应详细设计阶段。集成测试把多个模块组合起来开展联合测试。对应概要设计阶段。系统测试验证各个模块在一起运行模块之间不会相互干扰。对应需求分析阶段。验收测试一般由产品或者运营人员执行做最终验收。对应用户需求阶段。V 模型特点:V 模型清晰划分出各类测试活动直观展示测试阶段与软件开发各阶段之间的对应关系有助于提升测试工作的质量与效率。模型左侧代表开发流程右侧代表测试流程整体思路和瀑布模型相近。V 模型的核心观点单元测试与集成测试用来校验程序实现是否符合软件设计规定系统测试检验系统的功能、性能等指标是否满足系统需求验收测试确认软件成品能否满足用户需求或是合同约定。优点将测试工作拆分为多种不同类型分工明确。缺点只把测试当成编码完成之后才开展的工作测试活动无法提前介入需求阶段。和瀑布模型存在相同短板测试人员参与项目时间偏晚缺陷发现的时机滞后。V 模型覆盖的范围不只是编码环节它贯穿软件产品开发的全部流程阶段。8.软件测试 —— W 模型双 V 模型V模型中未将测试前置的问题在W模型中得以解决。W模型增加了软件各开发阶段中应同步进⾏的验证和确认活动。W模型由两个V字型模型组成分别代表测试与开发过程图中明确表⽰出了测试与开发的并⾏关系。W 模型特点测试对象不只是代码程序需求文档、设计方案等产出物同样需要开展测试测试活动和开发活动同步推进开发工作形成一个 V对应的测试工作同步形成另一个 V。优点测试人员可以提前介入需求阶段能够更全面地挖掘项目缺陷。比如需求分析工作一完成测试人员就能参与需求的核查与确认尽早发现问题。 同时对需求进行测试也能帮助团队提前评估项目难点与测试风险提前准备应对方案大幅缩减整体测试耗时加快项目推进速度。缺点需求、设计、编码等工作依旧被看作串行任务。测试和开发在一定程度上还是线性先后关系必须等上一个阶段全部结束下一个阶段才能正式启动很难适配需求频繁变动的场景不支持敏捷开发。 W 模型偏重固定流程面对当下复杂多变的软件开发场景无法完全解决测试管理遇到的各类难题。