是时候抛弃传统的软件测试用例了!

先给一个传统的测试用例的例子,作为讨论的上下文。

(传统的测试用例)先抛出本文的观点:是时候,抛弃传统的测试用例,即抛弃上述规范描写的测试用例(含有具体操作步骤等)。抛弃传统的测试用例,不意味着抛弃测试设计。测试设计是需要的,但可以用思维导图、矩阵、测试模型、测试场景、用户故事的验收标准等不同形式来描述测试设计,只是不用上述传统方式来描述。我也不是无视传统软件测试用例的价值,但在今天来看,这种价值已经很小了。虽然在我的教材中,可能还包含 “如何书写规范的测试用例”,让大学生来练习也许还有价值,至少先让他们了解传统的测试用例是如何写的。就像讲《软件工程》中敏捷开发模式之前,还是先要让同学们了解瀑布模型、V模型,这样才能更好理解敏捷模型。我也知道,当初为什么要写规范的测试用例,是因为:

  • 测试的依据,包括测试执行、评审、管理的基础;
  • 作为测试的主要文档,传递测试知识;
  • 测试设计、测试执行由不同的人执行;
  • 更容易通过CMMI/TMMI 认证;
  • ……

下面就一条一条来讨论,说明我们可以改变这些初心了。

一、详细的测试用例能不能成为测试的依据?直观上看,详细的测试用例是可以作为测试的依据,测试人员按照测试用例执行,心里感觉踏实;测试用例是白纸黑字,评审起来似乎也有根有据;测试用例是规范的文档,也符合维护、管理的要求。
但是,许多项目很难写出明确的期望标准,因为需求的标准就不明确,而是需要测试人员的综合判断,这时依赖测试用例很困难。基于用例来执行测试,容易限制测试人员的思维,甚至让许多测试人员不去思考,而测试用例自身又很难写得完整,需要不断完善。当测试用例写得越详细,其维护的工作量越大,人们就更不愿意去维护,时间长了,许多用例失效了,也没有得到修改。把大量时间花在写测试用例、维护测试用例上,投入产出比(RoI)低,不合算,测试人员有更重要的事情去做。如果评审几千条用自然语言写的详细测试用例,不仅工作量大,而且也不容易发现问题,因为不容易看到全局。如果把测试点、测试场景、测试数据很好地整理归纳在一张思维导图上,即使分解为几张思维导图,任何遗漏、不足之处倒是很容易发现。基于思维导图的测试设计评审更容易。花在重写测试用例步骤上的时间是否有价值?是不是更应该花在其他测试活动上?例如用于探索式测试方式测试新特性,用更多时间在测试分析上,测试分析比测试设计更有价值,首先要知道测试什么,然后再决定如何测。即使对一个优秀工程师,要确定清楚哪些要测,依旧有挑战,而如何测,倒是比较简单。

二、测试用例能很好传递测试知识吗?测试用例可以传递测试知识,但靠测试用例来传递,效率偏低。如果用单位时间能吸取多少知识来衡量,可以感觉出来,读了大量的测试用例获得的知识有限,还不如看几十页的图书。
作为一个公司或一个团队,在平时测试分析、设计和执行中要善于总结出知识、经验和优秀实践,用wiki或其它工具建立系统的、结构化的、规范的知识库,甚至形成一些内部的培训课程。在今天,我们是不是更应该建应用/业务领域的知识图谱,通过知识图谱更好地服务未来测试建模、业务依赖性分析等。

三、测试设计、测试执行该不该由不同的人执行?把测试设计和测试执行分开,是错误的做法,不仅增加了沟通成本,而且不能保证测试设计和执行的质量。一方面,测试人员通过测试执行可以更好地理解功能、产品、业务等,从而进一步完善测试设计。另方面,测试设计长期脱离测试的执行,对产品、特性的理解也会退化,自然对测试设计有不良影响。


有人说,我们有大量外包人员,他们流动快,主人翁意识不强,只能执行。你希望把他们当作测试工具、按部就班地执行测试用例吗?作为外包人员也乐意成为测试工具吗?如果是这样,为什么不直接写成自动化测试脚本?让工具执行还更靠谱、更快、成本更低。至于认证,你懂,一般只是一种政绩工程,或者是为了项目投标用。如果你要投标,要做外包,为了证明自己,写出规范的测试用例来交差,那就继续下去。今天,你如果是用敏捷开发模式,有了用户故事就是有了用户行为,只要追加“场景”,列出需要验证的测试场景,类似BDD的GWT描述。虽然测试场景还不是测试用例,不能执行,但离测试用例也就差一步,即加上测试数据,而这时测试数据可以自动生成。所以,在敏捷开发模式中,主要为每个用户故事给出场景列表,这个也容易评审,越简单的东西,一旦有问题,就越容易发现。越简单的东西,维护的成本也就越低。如果你不是用敏捷开发模式,而是用传统的开发模式,我倒是希望你画一张业务流程图,标上业务规则、业务角色,针对这个进行测试,更能保证业务覆盖,而业务覆盖才是最根本的。咱们一切工作都是为了业务,测试就是为了会更好地保障业务的质量。当我们谈覆盖率,实际包含了三个层次的覆盖率:代码、功能/非功能特性、业务。单元测试侧重代码覆盖率,而系统测试侧重功能/非功能特性覆盖。非功能特性,性能、安全性、可靠性等会单独去考虑,即我们常说的专项测试,而功能测试,完全可以被业务覆盖而覆盖,即E2E业务覆盖更彻底。今天来做测试,依旧建议新功能用探索式测试,就根本不写测试用例。而回归测试彻底实现自动化,也根本不写测试用例(千万不要先写测试用例,再翻译成测试脚本,这样更浪费时间!),直接写测试脚本。所以,今天可以彻底抛弃传统的测试用例,甚至连自动化测试都要抛弃传统的测试脚本,推行codeless自动化测试。

CMMI能力成熟度模型

01 基本概念

1.1 过程改进

在软件开发中,约束软件项目的三个要素是质量、进度和成本,被称为软件开发铁三角,软件开发总是在这三个要素中妥协平衡,不时要抉择保哪个牺牲哪个,不断在刀尖上跳舞。而决定质量的要素又有三个:人、过程和技术,其中CMMI主要关注过程的改进。

因为CMMI有一个基本的假设前提:产品的质量很大程度上受影响于所使用的开放与维护过程的质量。所以为了改进产品质量,需要改进过程质量,称为过程改进。

1.2 CMMI的定义

  • CMMI, Capability Maturity Model Integration,能力成熟度模型集成。
  • CMMI是美国国防部发起并资助的一个项目,由卡内基梅隆大学软件工程研究所(SEI)开发。
  • CMMI是一种过程改进模型。
  • CMMI是业界过程改进的最佳实践集合。

CMMI关注于改进组织内部的过程,描述了从随意、不成熟的过程到提高了质量与有效性的、有秩序、成熟的过程的演进道路。

1.3 CMMI模型

CMMI 1.3分为三种模型:CMMI-DEV开发模型(应用最广)、CMMI-SVC服务模型和CMMI-ACQ采购模型。它们有公用的一些过程域,也有特有的一些过程域。

CMMI的最新版本为2.0,但相关资料非常少,官网购买CMMI-DEV 2.0指南需要150美元。

1.4 过程域PA

CMMI-DEV-v1.3为例,包含22个PA,分为过程管理类、项目管理类、工程类和支持类4类:

  1. 过程管理5个PA:OPD组织级过程定义、OPF组织级过程关注、OPM组织级绩效管理、OPP组织级过程性能、OT组织级培训。
  2. 项目管理7个PA:IPM集成项目管理、PMC项目监督与控制、PP项目计划、QPM量化项目管理、REQM需求管理、RSKM风险管理、SAM供应商协议管理。
  3. 工程管理5个PA:PI产品集成、RD需求开发、TS技术解决方案、VAL确认、VER验证。
  4. 支持类5个PA:CAR原因分析与解决、CM配置管理、DAR决策分析与解决、MA度量与分析、PPQA过程与产品质量保证。

02 CMMI级别

即CMMI成熟度级别。CMMI把开发组织的成熟度分为1-5级,每一级是一个层次,作为继续过程改进的基础。其中1-3级为低成熟度级别,4-5级为高成熟度级别,所以4级是一个门槛。

2.1 CMMI 1级

CMMI 1级没有标准,过程通常是随意且混乱的,常超出预算。他们的成功依赖于组织内人员的能力与英雄主义。CMMI 1级组织的特征是具有过度承诺的倾向,他们在危机情况下会舍弃他们的过程,而且没有能力去复制他们的成功。CMMI 1级又叫初始级,是不需要认证的。

以一次团队聚餐为例:你被主管任命为团建组织者,现在有1000元经费,要求你组织一次团队聚餐活动。

CMMI 1级水平相当于:没有任何策划,下班的时候口头通知大家去江南大院聚餐。大家一哄而去,现场点菜大吃一顿。

存在大量风险:可能有人缺席,可能订不到包厢,可能菜不合胃口,可能经费超支等等。

2.2 CMMI 2级

CMMI 2级已经有基本的项目管理,确保其过程按照方针得到计划与执行。国内最早参与CMM认证(CMMI的前身)的公司,有认证CMM 2级,现在基本没有了,至少从CMMI 3级开始起步。

还是以一次团队聚餐为例,CMMI 2级水平相当于:实施了项目管理,做了项目计划PP、度量分析MA、需求管理REQM、采购管理SAM、配置管理CM、产品和过程质量保证PPQA和项目监控PMC。

  • PP:大家什么时候有空?
  • MA:统计出席人数。
  • REQM:预定菜单,控制经费。
  • SAM:是否自带酒水?
  • CM:整个策划方案评审并归档。
  • PPQA:找一个人来监督计划实施。
  • PMC:跟踪大家出席的情况。

得到的结果:大家能够吃得满意而且费用不超支吗?主管满意吗?

不一定,还遗忘了什么?等等看CMMI 3级是怎么做的。

2.3 CMMI 3级

CMMI 3级时,过程得到清晰的说明与理解,并标准化为组织级流程。项目根据裁剪指南,通过对组织的标准过程集进行裁剪来建立项目级过程。

仍然以一次团队聚餐为例,CMMI 3级水平相当于:除了有CMMI 2级的项目管理,还实施了需求开发RD、确认VAL、风险管理RSKM、需求验证VER、技术方案TS、组织过程定义OPD、组织过程焦点OPF和组织级培训OT。

  • RD:需求调研“大家想吃什么?”
  • VAL:利用问卷调查App做了选菜的投票确认。
  • RSKM:提前打电话预定包厢。
  • VER:聚餐过程中利用问卷调查App收集反馈意见,观察菜品的残余程度。
  • TS:聚餐活动完成后总结问题,研讨解决方案。
  • OPD:经过长期活动积累,输出《吃喝玩乐一纸禅》活动指南。
  • OPF:发布团建活动PCB(过程能力基线),并确定未来一年的改进重点。
  • OT:新组织这上岗前先学习《吃喝玩乐一纸禅》。

备注:举例并不覆盖当前级别所有的PA。

2.4 CMMI 4级

CMMI 4级时,组织与项目建立了质量与过程性能的量化目标并将其用作管理项目的准则。CMMI 3级与CMMI 4级的关键区别在于对过程性能的可预测性。

CMMI 4级时,项目绩效与选定的子过程的性能得以使用统计与其他量化技术进行控制,基于对细粒度的过程数据的统计分析进行预测。

和吃饭杠上了,继续以一次团队聚餐为例,CMMI 4级水平相当于:除了有CMMI 2级的项目管理和CMMI 3级的过程标准化,还实施了组织过程性能OPP和量化项目管理QPM。从CMMI 3级开始,感觉活动组织成功率提高了,大家比以前满意了,但没有具体的数字说明。

  • OPP:根据收集的大量历史数据(网上公开点评数据,本公司的历史聚餐数据等)和组织改进焦点(本团队历次聚餐的满意度调查意见),建立了本团队的过程性能模型——“团队聚餐量化管理模型”。
  • QPM:具体到本次聚餐,运用“团队聚餐量化管理模型”,输入参数经费、人员及其他要求,预测出本次聚餐获得的成功率(满意度)将低于8成,模型给出推荐选择方案:增加预算。经过向主管申请增加预算500元,获得通过。调整输入参数经费,得到新的成功率9成,可以按方案执行了。

到了CMMI4级,感觉一切尽在掌握,成败在策划中已确定。实话说,这是一种错觉。

2.5 CMMI 5级

CMMI 5级时,组织基于对其业务目标和绩效的需要,不断改进其过程。组织使用量化的方法来理解过程中固有的偏差与过程结果的原因。CMMI 5级关注于通过增量式的与创新式的过程与技术改进,不断地改进过程性能。

最后一次说吃饭了,仍然以一次团队聚餐为例,CMMI 5级水平相当于:除了有CMMI 2级的项目管理、CMMI 3级的过程标准化和CMMI 4级的量化项目管理,还实施了组织绩效管理OPM和原因分析与解决CAR。

  • OPM:定下组织新的绩效目标——提升满意度10%。
  • CAR:发现A同学组织活动的满意度比基线高15%,调查分析后得知原因:A每次组织活动都会组织抽奖,并事先调查大家需要什么。把A的做法写入流程,提升基线能力。

小结

从CMMI 1级到CMMI 5级,成熟度级别的提升带来两个变化:风险和浪费减少,生产率和质量提升。从CMMI 1级到CMMI 3级,关注点从个人到项目团队,再到组织;从CMMI 3级到CMMI 5级,关注点从组织到项目团队,再回归个人。

03 CMMI发展和现状

3.1 CMM起源

1960s开始,“软件危机”出现,美国军方项目受此影响严重。

1983年,美国审计局的研究表明只有3%软件交付后可以使用,49%扔掉了,48%使用前需要返工。因此,美国国防部委托SEI研究解决方案,用于评估军方软件供应商的能力。

SEI对软件危机的研究表明,软件危机的主要问题不是技术,而是过程管理。

汉弗莱(Humphrey)借鉴了全面质量管理TQM的思想(还有休哈特、戴明、朱兰、克劳士比等质量大师的思想),提出了能力成熟度模型CMM。

3.2 CMMI演化历程

从CMM到CMMI

  • 1991年,SEI发布了第1个能力成熟度模型CMM 1.0,这是CMM的起源。CMM最初是为了解决软件问题的,因此又叫SW-CMM,以区别后来出现的其他能力成熟度模型。
    CMM 1.0发布后很快在软件界获得了巨大的成功。SW-CMM模型的成功促使其他学科也相继开发类似的过程改进模型:IPD-CMM集成产品开发能力成熟度模型,SECM系统工程能力成熟度模型,P-CMM人力资源能力成熟度模型,SA-CMM软件采购能力成熟度模型。
  • 1993年,SEI发布CMM 1.1。至此,CMM就发布过2个正式版本。
  • 1997年,SEI准备发布CMM 2.0,被美国国防部叫停,因为有一个更紧急的项目CMMI等着SEI。
    CMMI项目产生的缘由是因为同一个组织采用多个CMM模型时,产生了新问题:多个CMM模型之间很可能会引起冲突和混淆。CMMI项目就是为了解决多个CMM模型之间的协调而产生的。
  • 2000年,SEI发布CMMI 1.02。这个CMMI 1.02包含了CMMI-SE/SW/IPPD三个模型,是个试用和推广版本,其中SE来自SECM、SW来自SW-CMM、IPPD来自IPD-CMM。

CMMI演化历程

  • 2001年11月,SEI发布CMMI 1.1(CMMI-SE/SW/IPPD/SS),这是一个正式版本。多了一个SS模型供选择,来自SA-CMM。
  • 2003年,SEI宣布停止SW-CMM模型的维护。SEI并没有废除SW-CMM模型,而是停止了SW-CMM评估,改以CMMI评估代替。
  • 2006年,SEI发布CMMI 1.2。这个版本分为开发、服务与采购三种模型,使用开发模型取代CMM 1.1的软件工程与系统工程领域。
  • 2010年11月,SEI发布CMMI 1.3。这个版本更加开放,把敏捷最佳实践也纳入规范框架(没办法,敏捷太火了)。
  • 2018年3月,SEI发布CMMI 2.0。这是当前的最新版本。

从CMMI的演化历程我们可以看出,CMMI同样关注自身的持续改进。

3.3 CMMI认证

国内学习和实践CMM/CMMI已有二十多年历史了,是CMMI最活跃的阵地(没有之一)。SEI数据显示,中国通过的CMMI评估总数已连续十年居世界第一。

2012年9月CMMI官网数据:全球通过CMMI评估的组织约5000家,中国2128家约占4成(其中4级50家,5级53家),美国1416家(其中4级5家,5级73家),印度581家(其中4级4家,5级139家),为TOP3国家。

据CMMI研究院2018年年报数据,2018年度一共有3049个评估项目,中国占了其中的65%。

2020年9月20日CMMI官网数据:中国已经通过CMMI认证(3年有效期内)的组织6509家(5级912家,4级70家,3级5511家,2级16家),不管是总数量还是高成熟度级别的数量都远超过美国和印度。

国人参加CMMI认证的热情令人咂舌!应了一句话——咱中国人不差钱。为什么会这样?与政府鼓励有很大关系。国务院2000年6月发表的《鼓励软件产业和集成电路产业发展的若干政策》第17条规定“对软件出口型企业CMM认证费用予以适当支持”。

多年以前北上广深、杭州、苏州等地政府就对CMMI 3-5级分别奖励30、40、50万(以抵扣税收方式),成都等地奖励70%退税抵扣,湖南、沈阳、烟台等地奖励50万。现在,各地政府仍然对CMMI认证给予税收奖励,只是对CMMI 3级这样的低级别已经没有奖励或奖励较少了。

通过CMMI 3级认证的公司和通过CMMI 5级认证的公司有很大差别吗?

实际上没有多大差别,能过3级的公司,基本上就能过5级。我任职过两家CMMI 5级的公司,第一家公司华三通信,确实在认真做过程改进,2009年通过CMMI 3级(亲历),2013年通过CMMI 4级(亲历),2020年通过CMMI 5级。第2家公司(名字就隐了),2017年7月通过CMMI 3级(也就只有这个水平),很快2019年1月跳过CMMI 4级马不停蹄通过了CMMI 5级认证。

为什么能过?因为评估师的目标和公司的目标是一致的,都是要通过认证评估,否则评估师拿不到大部分认证费用(一般都是签包过合同)。按CMMI的规定,评估师和咨询师不能是同一个人,但是国内的情况,有几个是这样执行的?反正,我遇到的都是即当教练又当裁判,没有碰到认证不通过的情况。

3.4 过程改进的目的

CMMI过程改进的目的,就是写在CMMI文档封面的一句话:

Improving processes for developing better products and services.

为开发更好的产品与服务而改进过程。

过程改进应该为了商业目标,即为了帮助业务而改进,而不是为了改进而改进。

更好、更快、更经济地交付产品与服务,是所有公司梦寐以求的愿望,也是CMMI的愿望。CMMI迎合了很多组织的期望:生产率的增长、质量的提升、开发周期的缩短,并且计划与预算变得更准确和可预测,所以获得了巨大的商业成功。

3.5 CMMI的基本思想

1)过程改进不可能一蹴而就,而是一个长期的,甚至永无止境的过程。

2)持续改进——PDCA

3)流程也有保鲜期——定期审视、更新流程。

4)开放、学习的心态。

3.6 CMMI和敏捷

CMMI更倾向于把人看成是产品开发生产线上的螺丝钉,是可以替换的,大部分工序既不需要高超的技能、也不需要多面手。CMMI的方法更适合制造业和传统IT行业,对个人的技能要求不高,对个人的纪律要求较高,适合大兵团作战,适合暴兵的人海战术。一个方阵过去,碾压一切障碍,不会为损失小兵停下脚步,甚至不会为更换统帅停下脚步。

而现在流行的敏捷更倾向于把人看成是单打独斗或小团队作战的特种兵,强调个人和小团队的能力,既需要高超的技能、也希望成员都是多面手。敏捷的方法更适合互联网行业,对个人的要求更高,适合小团队作战,适合重点突破斩首战术,适合敌后渗透。

CMMI和敏捷两种模型本身无所谓孰优孰劣,各有适合的行业和场景。当然,相比而言,CMMI对个人的要求更低一些,即使是平庸的人员在CMMI严密的流程管理下,也能够做出合格的产品。

所以,那些逃离CMMI拥抱敏捷的个人或团队,如果不是行业转换的话,在CMMI流程下做不好的个人和团队,在敏捷流程下很大可能更做不好,不关于流程,只关乎人。笨蛋就是笨蛋,难道换了套衣服就变聪明了吗?只有那些在CMMI流程下能成功的个人和团队,在敏捷流程下将延续成功的战绩,甚至释放潜力,更加成功。

CMMI是持续改进的模型,在V1.3版本吸收了敏捷实践。从这个意义上理解,敏捷与CMMI并不是对立或矛盾的。