测试评估 - UCD大社区

专家评审

jonathonwong@yahoo.cn(折折熊) — 2009-07-15 00:09:11

由于部门加入了DQA的角色，也由于为了能够把设计量化，在部门的设计流程里面增加了“专家内部评审”的一个环节。不过执行一段时间之后几个设计师都在向我抱怨，参加这个评审有很大的挫败感，无论是在评审上被批判还是最后的得分，都受到严重的心理创伤。

我很抱歉听到这样的消息，其实这个专家评审的原身是我和白鸦在项目中一起做的。部门之所以想要“效仿”的原因是因为发现经过这个环节之后的设计质量明显提升很多。当然这不排除每个人的个人能力，但更多的是我不希望把这种“原身”演化成一种官方的审核。

这个“专家评审"现在主要有以下几点问题：

1.所谓的专家是不是够格。

大部分公司都会遇到这个问题，所谓的专家都是从部门内部选拔或者钦点出来的，这些人（大部分是高管）能否有资格来对其他人进行专业性审核，这点需要商讨。有没有具体量化考核的标准，小满说根据可用性测试的要求可以来定义专家：1.看过成千上万的网站、2.获得过无数专业称号、3.设计过上千款杰出的作品、4.并且参加过不下10次的可用性评估等。真的有这样的人吗？如果有，他也没有时间来给大家一一做评审。所以我们就不要再披着“伪专家”的皮，换个方式虚心地进行指导吧。

2.分数怎么来衡量。

很多人认为分数是这个评审中的最终结果，包括DQA也为了这些忙碌着收集各方面相对资深的意见。但最终谁都没办法评判这个分数的准确性。比如60分为及格，但是所有设计师得到的分数都只有20-30分，那就像学校考试一样，到底是试卷太难还是学生智商有问题。可想而知，如果每个设计师都低分，只能说明分数的不公正。

3.提出问题的方式是否会激怒设计师。

当然这点是每个人不同沟通方法的问题。但是我听到的抱怨声最多的就是这点，很多评审们都会说一句：“有则改之，无则加勉。”来掩盖自己提出错误问题的窘境。那我也要为广大受评审之苦的人说一句：“士可杀，不可辱。”评审不是“官审民”，但很多时候评审都是部门的经理，而接受评审的人都是部门经理下面的设计师，这样的结构状态从根基上决定了“官审民”的状态。如果“民”要告“官”，除了坚持到头破血流，其他都是成为一代先烈。这样的结果只能使设计师按照评审家的意思进行设计，再也没有自己设计的主见。（当然有些人会说你也可以不按照他们的意思进行设计，如果真的是这样，那这个评审还要来干嘛？）

4.怎么样的设计才是好的设计。

这个是亘古不变的话题，既然是评审，那肯定是要评出个好坏来。好的设计是长什么样的，坏的设计又需要怎么样的改进，这个如果只有在评审的时候设计师才能知道的话，那只能说这些是评审们的砝码，没了它，评审们就再也没什么价值。好的设计需要扬长，坏的设计需要避短，这些都需要大家互相学习和沟通才能解决的，而不是一个简单的评审。

还有很多的问题存在，但我想说的是，评审是种手段，但不是目的。当手段使结果更加恶化时，我觉得就应该去改变手段。

最后我希望看到的不是一种评审而是一种支持，既然改变不了专家的角色（在整个部门里面，经理是最有说话权的），那可以让这个角色发挥更大更好的作用。最终变成一个“专家支持”。

当然刘叔叔提出来说分数是为了激励和提升设计师的能力，并且不应该让设计师太过依赖“专家支持”。我同意，但是在应试教育下的产物总归是畸形的。我们不能期望通过某一种系统的机制去提高设计师的能力。给人挫败感的危害远大于不能激励设计师的危害，这也是为什么现在中国的教育体系要改革分数体系的原因。至于不能让设计师太依赖“专家支持”这点，我倒觉得现在还没有什么专家可以让人非依赖不可。

要提升设计质量，要的是大家的建议，而不是大家的意见。要的是分享专业的能力，而不是藏着掖着变成潜规则。要的是提升自己能力的同时再带动其他人一起提升，而不是站在山顶使劲踩那些一只手刚刚攀到顶峰的人。

相关话题：测试评估源地址：http://www.jojobox.cn/blog/default.asp?id=155

心理分析案例系列（二）：不可能完成的任务?

finger — 2009-04-23 13:18:27

Finger 说明：其实这次测试的性质很模糊。我自己把它当做是一次用户体验的实践。但是，一来这个测试方案本身的出发点还是要获得软件兼容性测试数据，测试的时间又非常紧迫，二来我自己也很清楚软件工程和可用性工程的方法差异巨大，因此在本文中采用新方法的唯一目的是满足实际情况需要，并不代表哪种方法更好。

软件兼容性测试：不可能完成的任务？

前天被头儿叫过去开会，要求我们UE组两个人对公司一款产品的软件兼容性测试方法重新评估。事件起因是这样的：

产品部领导想要了解我们产品（下面都用A产品指代）和其他产品（分别是B、C、D、E、F、G、H）对某主流软件的兼容性，于是公司需求组的同事制订了一份详细功能点列表，总数大约是1000多项，交给测试部门。可怜的测试工程师们，他们一看就傻眼了：1000多项功能点，乘以7个产品，这就是7000多次测试了。再加上，测试工程师们有他们自己的测试方法，他会根据你列出的功能点，编制出对应的测试用例。比方说，你告诉测试工程师我要测知道软件是否能正常显示段间距，那么测试工程师就是编出1倍、2倍、10倍甚至317.8倍行距这样奇怪的数值，以确保是否正常显示。但是这样一来，从功能点到测试案例，要测试的次数呈几何级数爆炸式增长了。进行到这个份上，软件兼容性似乎变成了不可能完成的任务。最后这个光荣的任务就落到了UE小组的头上，于是一段传奇经历就此展开。

敌情侦察

孙子曰：“知己知彼，百战不殆。”我们打算先把当前的战场情况搞清楚。我们找到了需求组的同事，向她们详细了解为何要进行这项测试以及期望的输出物是什么，最后得到了这样一张战场态势图。

战棋推演

根据目前掌握的情况，我们迅速制订了这次的作战目标：
1) 快速有效地获得A产品与其他几款软件对某著名软件兼容程度的比较数据
2) 获得软件各组件用户使用权重的客观数据
3) 确定一套可重复执行的方法论，反映软件产品的兼容性

作战目标一旦明确，我们就开始制订具体的作战计划。我们的思路很明确，既然是一套可重复执行的方法论，那么它的数据收集一定是客观的（可测量的定量数据），它的处理方法也是自动化的。换句话说，在传统软件兼容性测试中靠人工逐一排查问题的方法将在本次测试中被无情抛弃。那么可行的方法是什么呢？

首先确定测量指标，这个指标必须是客观、简单、并且可重复测量。我们首先想到的是对某个任务是否通过做二项判断：通过或者不通过。要知道之前我们是要求测试工程师们对每个功能点的兼容性做从1—5的打分的，这中间就掺杂了很大的主观性。做二项判断后，工程师的判断难度是降低了，但是又一个问题来了：如果一个功能点上有3个测试用例通过，5个没通过，该给1分还是0分呢？A作战计划失败！

于是我们又想到：计算单个功能点的通过率。这下总没有问题了吧？包三哥曰：非也非也。计算出通过率后，暮然回首，我发现自己完全被大大小小通字辈给包围了，大通（测试用例较多的功能点）和小通（测试用例较少的功能点）完全没有可比性（因为分母不同）。B作战计划失败！

没办法，只有启动我们的C作战计划了。这时候我们突然想到：既然Google可以用PageRank一项指标来反映网页的流行程度，我们为什么不找一个合适的指标呢？我的脑海中这时灵光一闪：任务时间和鼠标点击次数。我的假设是这样的：
产品对该著名软件的兼容性反映在用其他软件打开后内容显示的相似程度（Ho）
由此又得出一个扩展推论是：
兼容性差的软件，用户打开后需要较多的步骤才能达到著名软件的显示效果（H1）

因此我们的实验任务就很简单了：随机找到100篇测试材料（或者你可以自己制作），先用该著名软件打开，然后在依次用待测试软件打开，要求用户判断二者显示是否相同，如果不同则手动调到相同，任务即算完成。由H1我们可以反推：当用户操作时间过长并且鼠标点击次数过多（这些数据都可以通过相关软件实时获得）时，反映出软件兼容性较差。并且，由于我的测试指标都是可测量的客观指标，可以进行统计推断，这就保证了我可以用较少的样本推论较大总体的情况，从而节省了时间。

我为自己天才的想法而沾沾自喜，下午跟头讨论的时候似乎底气也足了写，胜利就在眼前了。然而不幸的是，头对我这种想法并不认可，他需要的仍然是逐项排查并且得出每个功能点的具体情况的汇总表。正好测试部门同事说大部分测试案例已经排查完了。于是，事情又回到了它最初的原点，按原计划测完所有功能点。C计划彻底失败！

作战总结
我不是很了解软件工程的测试流程，但是我的出发点是想找到一种简便、快捷并且抽样的自动化算法代替传统的排查法。这次实践虽然失败了，但是我会继续探索下去。希望计算机专业和其他专业背景的朋友看的本文后不要吝啬发表你的高见。

相关话题：测试评估源地址：http://www.userfree.cn/?p=857

让产品设计师跟踪测试产品

奇遇 — 2009-02-05 04:39:06

注：先明确一下这里所说的产品设计师的职责：需求收集、信息架构、交互设计、产品设计文档撰写。

“我们的设计很好，可开发的产品很差！”，这个问题想必困扰着不少公司或团队，在近期的工作中，逐渐体会到一套行之有效的方法–让产品设计师跟踪测试自己设计的产品。设计师不要小看这测试的工作，跟踪测试起来颇有成就，你可以知道你的设计被实施了多少，看着实施符合设计，设计师会很有成就感。我也是被CTO逼着走过了这个过程才逐渐体会到它的好处。

产品设计师不大可能与程序员一起写程序，但可以跟踪测试开发的产品，并把测试结果直接反馈给大家(程序员、项目经理、产品经理、测试人员)。这应该算是一个管理问题，确切的说是协作流程问题。所以这种做法，必须得到cto等高层管理者的大力推行，否则编程者是不买帐的，毕竟谁都不愿意让人跟在屁股后面指责哪里做错了，高管把产品设计师的测试工作纳入流程，大家照章办事，工作起来会更顺利一些。

测试的时机：
产品开发基本成型，功能基本完备，研发者能提供可测试版本。

测试的相关协作：
发送测试文档给开发者，同时抄送给项目经理、产品经理、测试等等相关人员；遇到争议主动找项目经理、产品经理等相关领导协商。

测试依据的文档：
做过测试工程师的应该都知道，测试工程师是根据自己编写的测试用例(精简测试用例、详细测试用例)来测试，一般情况下，设计师根据精简测试用例文档来测试就好了，设计师只是要依据某个使用过程来试用并发现问题。当然如果设计师愿意写几个主要使用场景，然后根据自己的使用场景来测试更好，不过要注意自己的使用场景和设计文档保持一致。

让产品设计师跟踪测试的好处：

1、设计师比测试工程师更多关注可用性，可以保证产品的高质量。毕竟设计师对评判产品好坏较强的审美能力。
2、遇到问题可以直接给出解决方案，效率高。
3、可以看到更多的设计问题，便于及时补充和修正设计文档。设计师可以锻炼细节关注能力，积累更多经验。(本条第收获很大呀！)
4、设计师可以很好的参与到开发中去。

分享一下自己做跟踪测试的经验和教训

1、设计师在跟踪测试之前应做足的工作：确保设计文档写的更详细和易读，确保无主要逻辑缺失。最好做出原型并依据原型多体验几遍，或者邀请其他设计师一起来体验，争取在开发前发现更多的问题，确保文档质量。否则，一旦开发出现问题或者开发进度延迟，会把全部责任推到产品设计师身上。开发者会说：“文档没写”或“文档没写明白，看不懂。”遇到这样的情况，设计师百口难辨，设计师的确是有责任的(虽然不是全部)。

2、搞好关系，不要直接指责开发人员或开发中的问题。理智的做法应该是：”客观的表述操作，客观的提出正确的方案。”描述问题时不要有任何情绪，或者可能让合作者产生“逆反心理”的语气。比如：“竟然”“居然”“错误”等，当然适当的夸奖一下也是可以的。

3、在遇到争议时，通过正确的渠道解决问题，主动通过双方主管协商解决，开发人员不会听你的，不要试图说服他们，和他们争论的结果只会让他们记恨你，还有肯能找机会给你穿小鞋，设计师争取避免这个问题。遇到问题要先学会倾听，然后才有可能正确处理问题。否则容易产生误解，让别人误以为你不好合作或不好沟通(但实际上你是为产品质量而挣)。

4、和开发人员、测试人员保持紧密的沟通，提高解决问题的速度；有需求变动或文档改动要迅速反应，并及时通知大家。否则，如果研发没有按照变动来修改，会怪罪你没有及时通知。

……，更多感受还需到工作中去体会。

小结：说了那么多，这样做还得公司高层大力支持并推行为前提；设计师要真正处理好各种关系还得自己实际去体会，毕竟每个公司的情况都不尽相同；设计师可以获得很多，更清楚要向开发者“表达什么？如果表达？”。

相关话题：测试评估源地址：http://www.ui123.com/blog/2008/11/16/designertest/

让产品设计师跟踪测试产品

奇遇 — 2008-11-17 22:55:58

注：先明确一下这里所说的产品设计师的职责：需求收集、信息架构、交互设计、产品设计文档撰写。

“我们的设计很好，可开发的产品很差！”，这个问题想必困扰着不少公司或团队，在近期的工作中，逐渐体会到一套行之有效的方法–让产品设计师跟踪测试自己设计的产品。设计师不要小看这测试的工作，跟踪测试起来颇有成就，你可以知道你的设计被实施了多少，看着实施符合设计，设计师会很有成就感。我也是被 CTO逼着走过了这个过程才逐渐体会到它的好处。

测试的时机：
产品开发基本成型，功能基本完备，研发者能提供可测试版本。

让产品设计师跟踪测试的好处：

分享一下自己做跟踪测试的经验和教训

……，更多感受还需到工作中去体会。

相关话题：测试评估源地址：http://www.ui123.com/blog/?p=111

ASK ME，产品设计的评测

白鸦 — 2008-07-26 23:13:07

上周去北师大、北邮、北理工三所高校作了题为“我的UCD思考”的小演讲（10.1以后还可能会去北大）。在学校里和大家的交流很有收获，让我对于国内UCD行业未来的发展和良好的人才储备更加充满期望。
回顾在三所高校中同学们提到的问题，结合我最近收到的一些咨询邮件，总结几个关于“产品设计和评估”的常见问题如下：

问题一，产品设计到了什么阶段才可以开始测试？是不是最早也要到有了高保真的界面原型才能开始测试？
1、这个说法是不对的，产品设计的任何阶段都可以进行测试，只要条件允许也都应该进行测试；
2、什么时候进行测试，其实取决于你对于产品有什么样的问题，只要你有问题都应该去做；
3、具体说一个例子：你现在要设计一个IM软件，和QQ基本相似；
那么，哪怕是在你的产品设计之初，只有简单想法还没有任何具体界面设计的时候，如果你有拿不准的问题一样可以通过测试解决。
你可能会问“我什么都没有，拿什么去测？”。“拿QQ呗”；
再往后，“纸原型”、“可简单演示的低保真原型”、“可互动的高保真原型”、“beta版本”都可以去做。
4、补充一下：我说到的“测试”不局限于“找用户来作”，一样包括“访谈”和自己的“评估”。

问题二，我们现在没有完善的“可用性实验室”，没有好的环境如何客服测试的问题？测试中您认为关键的问题有那些？

1、首先，产品的测试和评估并非一定要在实验室进行。测试应该是随时随地的，作为一个设计师必须要具备随时随地观察相关用户使用过程的“习惯”，这也是一种测试。
2、不得不说很多“科学”仪器和实验室“装备”都是极其“科学”的，但是否实用？甚至说是否有用？我持反对观点。

3、我个人认为作产品测试最关键的点有5点：测试的准备、测试的方法、被测的人、测试的人、测试的环境；
所谓“测试的准备”主要指“明确测试的目的性”和“准备测试的问题”。往往我们很容易搞清楚自己“为什么测试”，目的性都不是什么大问题；
但，“测试之前没有充分准备‘问题’测试中随机应变，导致测试结果大多没有什么价值”，这是大多数“经验丰富”之人常犯的错误，所以我建议：“在整个测试项目中，用50%的时间去做准备工作”；
然后，如何准备问题也是非常重要的。比如，一个关于语音搜索的产品测试，可以“从以往用户的录音中提炼问题来测试”而不要用“给话务员培训的对答脚本”来测试；
还有，某领导往往喜欢用自己遇到的问题去测试，当我提到“这不一定是用户的问题”时，领导反倒理直气壮的告诉我“我就是用户呀”，我只能回答他：“在咱们自己的产品面前您只能是领导，不是用户”…

关于“测试的方法”这个其实很简单，相信大多数科班出身的人都能很好的掌握。我只想不中听的提醒纯“心理学”专业的同学：站在“产品设计”的角度测试，而非纯粹的“心里测试”角度测试。
这么说只是因为我遇到不少“心理学”专业的朋友，他们给了我这种感觉，导致一些测试结果对于“产品”本身的直接意义很小。（并非说完全没有作用）

“被测的人”指“如何明确自己产品的针对性用户群，如何找到准确的典型用户”。这些都是我们成天提到的东西，无需我来讲；
往往“如何让被测者很好的与系统和测试者进行交互”其实是最大的课题，当你遇到一个“死活不说话、测试过程紧张无比”怎么都无法从他那里得到有效信息的被测者时，“暂时把话题扯开谈谈轻松的事情、聊聊家长、说说他喜欢的话题、甚至讲讲小笑话”都会是不错的做法。。。

“测试的人”我就不说了，只有一个建议：测试的人和总结测试报告的人要是同一人。

“测试的环境”是我最想强调的，这也是我个人一直不支持“在实验室”里测试的主要原因之一；我见过很多实验室设计的太“不自然”了（设计合理的实验室倒还好），用户在测试中根本没有平时使用的感觉；
我个人一般比较支持“低成本”的更加自然的测试环境，尽量不要改变用户平时用户的环境，只作为一个让他没有感觉到的“旁观者”或者“偷窥者”更合适。
还比如，测试一个语音搜索产品的话务员操作系统，“把话务员“关”到严肃的实验室用个大摄像头对着他，自己龟缩在单面玻璃后面”的“科学”方式，还不如“去话务员工作的地方，把话务员的显示器切为双屏显示，通过另外的耳机旁听话务员正常工作”效果更好。

问题三，在应用用户测试的结果上能不能给我们一些建议？
wow！这个问题比较大，很多理论性的做法已经很多地方可以看到相关资料了。我想说点主要的：
1、首先，再强调一下“测试和评估之前的准备工作十分重要”，往往我们的测试可能有两种情况──
第一种：你设计了两个杯子，你认为第一个设计比第二个设计好，你需要通过测试来验证你的观点；
第二种：你设计了两个杯子，你不知道那一个更好，你需要通过测试来得到答案；
如果你明确了你的目的，然后又做了充分的准备，我想“提炼结果”应该不是大问题。
2、不是所有用户说的都是对的，以用户为中心不等于“用户怎么说就怎么作”。
我见过一个人，测试中用户说“我觉得这个地方全部展开不好，太占空间了，应该收缩到下拉菜单里”，用户一走他马上就心花怒放的去改了。问他为什么？他告诉我：“这是用户说的”！
第二天又测试了一个用户，这个用户说“这个地方其实很重要，收缩起来可能找不到，你应该给展开”。他晕了，问我“怎么办？”，我回答他：“我不是用户，”。
3、其实我想说：“把用户的测试当作意见来源，而非指示来源。
既然是意见就需要‘筛选’”，“提炼用户研究的结果最关键还是你自己的思考和辨别能力”，这种能力只能靠“你比任何人都更深入理解产品和用户”。同我回答“如何做好搜索引擎的用户研究？”一样：最基础的还是“至少每天搜索200个字以上”。

问题四，“专家评估”是不是就是站在产品专家的角度去使用产品，然后总结出来设计的问题？
和我们作启发式评估不同，启发式评估往往完全可以对产品没有任何了解，就只是用户的角度去作即可；但专家评估往往是站在专家的角度“用用户的模式思考”。
我个人一直比较主张：“专家评估”之前一定要熟悉“产品架构和业务流程”，因为你提出的不应该只是“用户的问题”，还得包含“产品的因素”，这样才能很好的直接应用。

专家评估的问题总结需要有技巧性，尽量要让问题的表现更加明了而且要出来修正的办法。我自己往往会用PPT的方式，先把问题分类然后再展示问题表现、问题分析、危险程度、修正办法等

问题五，当数据统计和用户访谈结果出现不一致时，应该怎么选择？
呵呵，这个问题听起来比较棘手；
1、首先我建议你去找一找数据统计或用户访谈在什么地方出错了；
2、我向来认为“数据”和“用户”是两个互相依赖的部分，数据是支撑用户结果的依据，用户可以找到数据现象发生的缘由；
3、往往我们只看数据不知道“这是为什么”，这个时候我们需要通过和用户的接触去了解数据现象背后的原因；如果只靠数据就下一个背后原因的结论，大多数时候是很危险的；
4、往往我们只根据用户反应的情况，就去作一个大改动也是不合适的，因为他可能是片面的，这个时候我们需要用数据去论证他。

最后，总结一下：
1、产品的任何阶段都可以进行测试，无需等待完整的设计完成之后；
2、测试和评估是随时随地的；
3、不一定在实验室的测试和评估就更好，我个人比较排斥那种“不自然”的方式；
4、把“数据”和“用户”相结合很重要；
5、作专门测试项目时，拿出50%的时间作准备工作；
6、测试的目的：验证观点或者得到观点；
7、读懂数据和提炼用户测试结果的基础是：深入理解自己的产品和用户。

相关话题：测试评估源地址：http://ucdchina.com/blog/?p=320

开展全面的网站评估

千鸟 — 2008-07-26 23:07:09

有时会被问到“看看XXX网站如何？”之类的问题。

谈到评估，通常都是指产品级的网站，如果模式很新，了解需要花一定时间。于是，很多人又问“那么你仅从UI/UE的角度看看呢？”首先我们得达成共识，一切花里胡哨都在为功能服务，如果功能满足都成问题，其他就没必要谈了。

举例分步说明，注意先后顺序。

第一，没有足够应用经验，不可能了解网站的功能和结构，如何做出判断？

初步印象

是否有眼前一亮的感觉？任何元素都可能抓住用户，先入为主。
能否尽快搞清楚，网站提供何种服务，并且能尽快明白，有无注册的必要？

信息可视化

好页面似一杯鸡尾酒，具有层次感，远近都能看出效果，而不是一坨浆糊。
呈现是否平衡？不相干的元素之间，也可能建立联系，很多不协调的根源，就在这里。
尝试在纯UI的角度深度感知，整体氛围是否和已了解的概念搭配？比如够不够热闹、有没有品位。
通过模块能否分辨出网站？不看Logo还认识网站么？检查内容+界面的相关性。

导航系统

多深入几级页面，是否清晰自己的位置？
多纵横逛几个来回，是否已经迷路？

第二，假设对产品有了初步了解，确定自己需要此服务，如何细化尝试？

功能结构

主体逻辑是否清晰？思路是否顺手等习惯问题。
能满足自己多少需求？只是衡量产品的成熟情况，但不是好坏关键。
有多少创新？让自己意外了，统统记下来。

设计细节

交互设计，挑主要业务流程进行测试，主要看逻辑是否混乱。
视觉设计，不仅仅是图形，字符效果同样需要推敲，也属于深入信息可视化的范畴。
信息设计，内容有没有生命力？情感化等同于催化剂。

客户端技术

交互流畅程度，大量的Ajax技术应用会影响效率。
搜索引擎的优化工作，可以借助Alexa和Google两大工具。
代码质量，看几个代表性页面就可以。

第三，在竞争对手的角度，如何提炼总结？

产品跟踪

更新节奏，改版中可能会暴露发展方向和一些好创意。
解决方案，重要的不是完美，而是统一，体系才能形成壁垒。

数据挖掘

找准用户群，并在运营的角度进行细分、锁定各自特征值，提供可修正的参考依据。
关注用户忠诚度，不满意就意味着寻求改变。
用户活跃程度和活跃倾向，也是值得参考的重要数据。

我经常参与测试产品，不管是自己的、别人的、感兴趣的、不感兴趣的、见过的、没见过的，大致都可以使用同样的方法体系。把事情做彻底，目地就是搞清楚设计意图。

三个部分阐述，其实也暗合用户理解的本能、行为、反思三层结构。通常，人做事的能力和态度具有相关性，从前边的工作成果，基本上就能评估出后续工作的斤两。

相关话题：测试评估源地址：http://ucdchina.com/blog/?p=317