基于软件度量的测试体系建设

去年年底在质量年会上的发言稿，感谢赛迪现场的录入

信息产业部软件与集成电路促进中心(CSIP)已成功地主办了两届中国软件质量年会。本届年会将以“软件质量创新 助力两化融合”为主题，继续深化我们已取得的成绩，把软件质量年会做实，为增强我国软件企业竞争能力、振兴我国软件产业，助力信息化与工业化融合做出积极贡献。

贺炘 北京慧灵科技有限公司总经理 软件测试虚拟社区测试时代负责人

时间也比较晚了，希望最后一个内容对大家来说有一定的帮助。

今天跟大家分享的题目是基于软件度量的测试体系建设。

下面是我的一个介绍，大家都上过测试时代网站，所以掠过了。

在以下半个小时的时间大家有任何疑问或者不明白的，你就举手说，会场可以产生互动，没有任何问题。

在座有多少测试人员，很高兴，大概是百分之百，大家都是同行，看有没有这样的问题。

虽然觉得软件测试很重要，但苦于没有办法组建规范的测试中心，什么叫规范的测试中心，有章有法，你的技术是可控的，你的人是可控的，很少有这样的公司，我做过企业内训的公司有上百家了，但很少，大多数认为是成本中心，或者是花钱，公司一直在不停的投入，但是对产品的质量没有多少帮助。有多少帮助？你能说出来的，老板持续给你买工具，组建团队，招聘新人，由于你的存在，由于你的团队的存在，你为公司创造了很多效益，有吗？你隐隐约约觉得有，但没有办法拿数字说明，所以没有办法证明你存在的价值，或者你部门存在的价值。

无法衡量软件测试工作的成果，你说我的测试工作很规范，很努力，我写了一千的测试用力，工作成果好不好？很难说，因为你的老板会说，才写了一千个啊？我认为应该是上万个，因为我的系统很复杂。可能还会问什么呢？你怎么能写一千个呢？我认为咱们系统有一两个足够了，你用力怎么写的，是不是花了很多无用功，都有这样的疑问。你还没办法说明它。

总感觉测试工作，或者测试团队的工作是不可控的。不可控在什么程度，在座有这么多测试人员，大家都会有这样的感觉，我可能今天很累，累在什么地方，我好好测试我的软件一个BUG都没有发现，你的老板问你工作成果是什么，你没办法说。你可能今天很闲，你心情不好，不想干活，你可能上了一天网，被测的软件没有打开，虽然今天没干活，但是对整个质量也没产生影响，你可以心安理得的回家，第二天再说，对吗？可能都有这样的经历。作为公司，作为部门经理如何对你监控，从公司的角度来说，这是一件很可怕的事情。

测试过程混乱，无法进行有效的持续改进。什么叫持续改进，没有人有能力，没有公司有能力，一次把所有的事情都做正确，都做好，做对，没有人，没有公司。你要知道你现在目标在哪儿，而且能判断到你持续向你的目标迈进。

我们这么多做软件测试的，软件测试的目标是什么？上午和下午有很多嘉宾说，保证产品质量，认为是保证产品质量的我看看，很遗憾，保证不了，谁可以说经过你的测试，这个软件质量就可以保证，谁敢说？那么多第三方的评测机构，哪个评测机构敢说这个软件经过它的评测，质量就没问题，谁敢说，你保证不了。

做一个简单的数学题，一个软件有一百个功能点，这个软件大吗？很小。如果从测试的角度来说，它可能有的功能点组合有多少？概率，C100、100，C100、100的数学等等多少？等于100的阶乘，已经是天文数字了，从数学模型来讲，测试无法建立，这个目标你可以影响，但保证不了。

验证需求和实际软件的相符程度，同意这个举手我看看？同意吗？软件和需求相符就证明软件的质量高吗？需求就做错了，你怎么办？

对开发团队进行有效的考核？行吗？好象都不对。

软件测试的目标是什么？可能是一个很大的问号。

我现在提出两个目标，这两个目标可能在其他的书上，或者在网上都看不到，最近才提出来的，两个什么目标？

第一个，稳定控制软件产品质量的振幅，ISO做了那么多质量管理体系，它能保证单一的产品进来就肯定出去是一个优秀的产品吗？不可能。它能做什么？是以统计学的观点控制软件产品质量的振幅，你通过我的流程，出现一个高品质产品的概率高，同意吗？是概率高，不可能完全控制。

稳定控制软件产品质量的振幅这件事情不归测试人员管，归谁管？头长是通过SEPG组，建立度量体系，进行有效跟踪和监控实现，是统计学。

第二个，测试做什么？高效的提高软件测试用例的覆盖率。好的测试人员和差的测试人员有什么区别？放在日常工作中，就是你想不到，同意吗？你的组长或者你的老板永远比你想的多一点，多的那点是什么？就是测试用例的覆盖度，同意吗？我们找了两个关键字，一是高效，二是覆盖度，后面我会证明这两个怎么度量。

怎么样能高效？通过测试用例的复用来达到高效，以数据驱动的形式自动化测试用例可以提高效率，通过有效的测试用例设计方法，扩大覆盖率。我现在要做什么事情？首先我把软件测试的质量分解为一个目标，这个目标是高效提高软件测试用例的覆盖度，把一个复杂的问题简单化，简单为一个明确的问题。下面我又做了分解，我把高效提高软件测试用例的覆盖度分为三个指标。就是通过测试用例的复用，以数据驱动的形式自动化测试用例，通过有效的测试用例设计方法扩大覆盖率。

这是典型软件测试过程文档体系结构，我们来看通常情况下，我会把整个软件测试划分为几个步骤，首先最关键是软件测试策略的制订，测试策略提供几个信息，项目实施范围，可见可衡量的指标，验证方法和阶段。通常情况下，我们会把整个软件测试过程划分为单元集成系统。从所有的软件工程或者从所有方法来说，都需要怎么做呢？都需要单元集成系统，一个都不能少。通常在不同企业里面做不同程度的裁减，单元测试必须要做吗？

WPS1.0你相信第一个版本出现的时候会通过单元集成系统测试，我不相信，你们相信吗？我肯定也不相信，但是不影响这个产品。产品在每个阶段有不同的竞争要求。WPS刚出现的时候，是功能上的竞争，填补市场空白，只要有就OK，只要能用就OK，当竞争到一定程度，WPS到现在你能相信它不进行单元集成系统测试就可以卖吗？不可想象。你现在就是选择适合你的过程，当我们明确完策略以后，我们一般会把测试分为计划、方案、实施、报告几个阶段。计划主要解决五个W问题，谁，什么时间、什么地点，干什么事，由谁来完成，就是做资源合理分配，然后进行专项测试方案。专项测试方案就是性能测试方案，安全测试方案，易用性测试方案，加密狗测试方案等等，然后进行测试实施，测试实施主要做两个内容，首先是测试记录，通过写记录证明你执行到哪儿，没通过的写缺陷报告，整个阶段完成写阶段完成报告，包括测试评估，然后做测试结论。

通常情况下测试策略我们会明确以下几个内容：

1、明确测试需求，你要对什么进行测试，这个点很重要，重要到什么程度？这么多人做软件测试，我问大家一个问题，如果产品发布了以后，产生了质量问题，谁的问题？是测试员的问题吗？是吗？同意是测试员的问题，举手我看看，不同意是测试员的问题我看看。经过你最后一道手发布出去了，产品出现问题了，你说不是你的问题，你能解释吗？很重要一个问题要明确测试的工作范围，如果在你测试范围内发现问题，肯定是你的问题，在你测试范围外发现的问题，就不是你的问题吗？不一定。我们要明确测试工作范围，需要测试的对象，达到的目标等，可以来源于软件需求，个人经验，以前发生的错误等。我们要确定测试目标，确定测试类型和方法，测试风险分析。

策略完成以后，大家一定要注意，策略里面不包括人和时间，为什么不包括这两项，从项目的角度来讲，这两项变化的风险太大。测试策略中一定不包含可能变化比较频繁的要素，目的就是测试策略不允许随便修改，它确定了该项目最关键的要素，当我们确定测试策略以后，将进行测试计划的制订。测试计划包括什么呢？目标、方法、环境、工具，确定时间段，确定资源，自动化测试分析。一个项目里一定要进行自动化测试分析吗？完全没必要，自动化测试不能帮助你解决发现BUG的问题。首先大家要对自动化或者功能类自动化工具产生明确的认识，它不能帮助你发现新的BUG，它能帮助你提高效率，提高测试用例覆盖效率。

但计划完成以后，我们要进行专项测试方案制订，我们要把计划策略中所有需求拿出来，进行备案，然后细化测试规矩等等。

测试实施包括测试记录和测试报告。

阶段总结报告要提供测试执行株距，证明测试过程完整的执行了测试计划内容，提供测试分析数据，证明系统的质量达到要求或未达到要求，如果比较重要的系统要提供模拟测试，比如说银行或者电信系统，当它一个周期是一个月的数据，如果你随意切换，你的系统不行怎么办，有一种方式就是这一个月的数据，原来的系统跑一遍，新上线的系统在另外一套系统跑一遍，两个出现的结果对比一下，走一个月就可以顺利切换了。

其次提供遗留问题及后续的解决办法，刚才都问到一个问题，测试什么时候结束，测试结束有两个必要条件，缺陷处于收敛状态，所有遗留问题都有了明确的解决方案。

刚才跟大家简要的说了一下我们认可的，或者我们觉得比较合适的一个软件测试过程控制方法，谈到度量，谈到对过程的控制，我们首先要明确过程是什么，刚才我们过程摆在那儿了，我们再来看。

我们把复杂的问题明确为两个问题，一是质量振幅，二是高效提高软件测试用例覆盖率。质量振幅如何控制，针对软件测试过程的符合度进行控制，通过由EPG组进行监控，SQA进行检查，检查报告就是振幅的一个指标，不在我们讨论范围之内。

我们谈测试相关的东西，高效提高软件测试用例的覆盖率，高效和覆盖度是我们关注的目标。通过这两个目标，我们去抓整个的软件测试过程，我们看怎么抓。

软件测试工作如何提出效率，可能的指标有什么？我只能说可能的指标，因为度量也好，过程也好，针对每个公司都是个性化的过程，比如说我们通常在网上能拿到的数据，最完备的过程是什么？是RUP，一张光盘，上头有整个从项目需求一直到最后部署，整套的文档，整套的模板，你能用吗？我跟IBM的工程师聊过，RUP的精华在什么？精华在裁减，你只有了解的全部，了解到本企业的现状才知道自己用什么，不要盲目套用任何一套你看的好的方法或者模板，必须要个性化定制。这块谈到的目标只是参考。可复用的产品多，可能提高效率吧，如果每次做项目能用到复用的产品很多，一定会提高效率，我们的指标就是测试资源复用率，包括计划、方案、用例，自动化测试脚本等等一系列，你在一个项目中产生的所有文档、代码或者思想，这些复用率有多高，拿一个指标控制。

无用的工作少，上礼拜我们在对面开测试时代的交流会，有几个人，测试用例我们写到什么程度，大家想象，如果你只有一个礼拜的测试时间，五个工作日，你花三天写测试用例，两天做测试执行，合理吗？五天全部做测试执行，我不写测试用例，合理吗？假设一年我八个月写测试用例，四个月做执行，合理吗？我一年不写测试用例，只执行，合理吗？所以当你看你项目的时候，绝对没有一个统一的方法、指标让你去做，要根据目标来决定。

上午在说我推崇一句话，这句话是两部分，第一部分是目标决定过程，一定要注意，目标决定过程，第二部分，过程决定质量。为什么目标决定过程？跟敏捷开发方法的理念是一样的，你想做什么，想达成什么样的结果，就让过程不多不少的配合你，你要做什么，完全跟你的目的有关系，不要做过多或者过少的工作。所以它都是定制化的过程。无用的工作少，你要做度量，比如说以前我作为测试组，或者你们作为测试人员，有多少测试人员在写文档，我指的文档是用户使用手册说明书，举手我看看。在小组织小工作量下是没问题的，如果你的测试工作或者测试有效工时三分之一以上都被明显跟工作质量无关的工作就有问题了，所以我们要拿到有效测试工时率。

和开发的配合好，在研发过程中，测试是辅助流程，还是主流程？辅助流程，如果你是辅助流程，你当然要跟主流程配合。跟主流程如何配合，首先协作点的数量，你跟开发人员有多少次交互，我指的正式交互，不是你平常没事吃饭、打球、聊天，而是在技术方案中你跟开发人员做的交互有多少点，协作点的正确率，正确率主要指时间和质量，1月1号说给你协作点，1月1号没给你，这个协作点没有成功，如果给了你，你没有评估，这也没有成功。

测试项目进度贴合度好，什么叫贴合度好？第一，我没看到过没有发现BUG的项目，有没有这样的测试人员，我测试一个产品压根没发现BUG。项目变化率，你作为项目经理，你写了份测试计划，你的计划会有多少次变化，变化的程度会是怎样的，也是判断你的效率。工期贴合率，你们之间的工期是否有很好的贴合。

自动化测试提高效率，首先自动化测试不能发现BUG，它可以把你的手工测试用例自动化，自动化手工测试用例的数量，跟手工用例的比例，这个比例越高越好，但一定要考虑成本和产出，值不值得这样做。以前我看一个项目，它的测试经理给我们展示QDP做的自动化测试，从头到尾自动化，所有的操作不用人工干预，我看了挺高兴，后来我问他，它发现过BUG吗？没发现，你平常测试用它吗？也不用。做它干什么？演示。你就看到鼠标在那儿点，一个流程一个流程完成。为什么这么做？处于测试人员自我的爱好，他觉得这个有意思，技术含量高，想学这门技术，也给老板做演示，老板看了很高兴，它不产生实际的效率。

测试用例的覆盖度，测试用例的覆盖度是一个求积分的过程，什么叫求积分的过程？可以无线接近，但是永远到达不了，只可能无限接近，但不可能等于。

有效度量测试用例覆盖度增加的条件：

1、现有测试用例进行了有效的管理，首先测试用例你需要用工具或者手段管理起来，一条一条放在那儿，做一个基线。

2、明确测试用例编写的颗粒度，大家都有这种感觉，你写测试用例，你测试这个产品的时候，你十条测试用例就测试完了，有人写三十条，你就觉得奇怪，我觉得十条已经是局限了，怎么你能写到三十条，你去看他的用例，发现这也能算一条，这是组织内部测试用例颗粒度没有达成一致，颗粒度你可以跟代码行数对应，跟功能点对应，组织内部测试用例颗粒度要统一，保证所有人员大致是一致的。

3、单个功能点都进行了有效的规整，确定最小测试范围。你如果做测试用例的度量，需要保证单一个功能点进行了规整。

4、提高的方式放在功能点的组合和测试数据的增加上，如果你想提高效果，很重要的两个目标，就是功能点的组合增加了多少，测试数据又增加了多少。

5、每轮新增测试用例量和率，通常情况下测试一个软件，你的测试用例要跑好几轮，三到五轮，有的可能更多，每轮会新增一些用例，这些新增的量和率是多少，如果在组织稳定的时候，新增数量不会太大，如果组织不稳定，或者产生新的功能点比较多的时候，新的功能点组合比较大，这个率就会比较高。对于你进行一个项目控制也是有借鉴意义的。

软件测试过程的定制是一个个性化很强的工作，每个企业都应该不一样，如果一样了，就会有问题，指标确定确立不能照抄，你抄没问题，你照着人家的进行，就有很大问题，需要根据能力成熟度进行有效的分析和定制。

质量的提高，工作的改进是一个渐进的过程，绝不能一蹴而就。

通过分析，要先解决重要的事情，要有总体的规划，而不是头痛医头，脚痛医脚。

我大致的发言就到这儿，谢谢大家。

文章来源于软件测试时代 http://www.ltesting.net/

推荐软件测试时代的主要栏目：

软件测试技术: 软件测试工程师　 测试用例　功能测试　测试管理　缺陷管理　手机测试　自动测试　单元测试　性能测试　安全测试 软件测试环境: Windows　Unix　网络知识　 服务器 开源测试: 开源功能测试　开源性能测试　开源缺陷管理　开源配置管理　开源解决方案　 测试开发: JAVA　.net　UML　脚本语言　数据库　中间件　 测试资料: 商业测试工具　开源测试工具　软件测试教程 质量保证: 项目管理　需求管理　软件度量　 项目估算　质量模型　解决方案 测试工具: Mercury测试工具　Rational测试工具　Silk测试工具　其它 软件测试时代 软件测试服务 |软件测试培训