这话题之前内部也探讨过。
今天参加淘宝的黑灯辩论，也是这个主题。

正方观点：写细点好。细致到从操作上不可再拆分的程度。好处：覆盖率高、可操作性强、便于工作量评估、便于跟踪、便于新同学学习理解，等等。

反方观点：写粗点好。突出测试思想框架，关注业务流程关注系统间交互，不纠缠页面细节，杜绝同类性重复用例。好处：养成有高度有宽度的测试思想，控制重复性细节性此类投入产出比低的投入。

以上，是我替他们大致总结的观点。

辩论本身并不是很精彩。但给我一个机会回炉自己的想法。

这本身是一个伪命题。用例的粗细粒度，很难有标准，更难说一定是细好还是粗好。就像我的博客上写的，测试是艺术。既然是艺术，哪有标准可言，只有是否适合口味的差别。所以这肯定是没有标准答案的。

但是，我们目前的实际做法中，肯定还是有倾向性的。我想批判一种倾向性的现象----对已知的浅显的测试需求，用例写到细的不能再细，而不花精力去思考未知的潜在的可能被遗漏的测试需求。这样下去，人慢慢就变成机器人了，只是反复的、一丝不苟的做那些已知的事情。线上故障会有，人的能力也不会上去。这个现象，暂且简称为机械主义。我想周遭是能看到这样的现象的。

我比较倾向的做法是，平时，对于已知部分，凭借经验尽可能抽象出公共可用的用例，而且要写的足够细致全面。项目中，同类测试需求，稍微加以修改就可以保证高覆盖率；多腾出一些时间来思考未知测试需求，构建新的测试用例。如果项目中的测试需求全部是新的，没有历史的可用，那么在时间进度压力下，我倾向于“重”测试分析“轻”测试用例，从分析层面/思想层面保证测试的覆盖（抓准业务流程规则/资金流转规则/系统间交互规则/非功能测试需求等），如对于资金流转，其实你画个图比你写一堆测试用例要有用简洁的多，虽然它可操作性不强，有可能会导致测试执行偏差，但我宁愿选择把这个风险靠人员的责任心去弥补，而不是担心人的责任心而要求用例一定要细致细致再细致。况且，互联网的测试跟传统软件行业的测试是有差别的，要做到快速响应，就不得不有取舍，有策略。

支付宝急招资深软件测试工程师和资深测试开发工程师。详见 http://job.alipay.com/recruit/offerDetail.htm?offerId=21683。

有意者投递简历至resume@alipay.com或ling.gll@alipay.com.

期待您的加入！

工作地点： 杭州、上海

某大型项目，PRD很差（差的意思是说后续开发测试基本脱离了它），系分不好评价（不好评价的意思是说目前来看似乎系分最有技术含量，它直接指导了开发），编码实现让人很分特（让人很分特的意思是说它不断延期，交出来的东西缺陷一堆堆），测试很伟大（伟大的意思是说靠着口头沟通所得整理测试需求）。本来说开发是一次交付的，后来改成两次交付了，因为第一次交付的时间点上很多东西没做完，或者交付没有测试通过。测试再次的伟大，评估了一下说两次交付也可以接受，因为在第二次交付之前可以针对第一次交付通过的内容进行详细测试，整体上对进度影响不大（实际上真的不大吗？你进行测试，他还在开发剩余内容，谁给你改缺陷？），只是跟预先计划的测试顺序稍稍有些变化。

现在进到计划的第二次交付的时间点，还是延期。这个时候，测试不再伟大了，说这样的状况，肯定是不ok的。这个时候关键人物们着急了，因为这个项目大，关联性大，不能延期。于是说这几天我们开发保证把该完成的内容全部完成，哪怕我们加班加点，但是要增加测试资源来确保后续进度。咋一听是可行的，但实际上是荒唐的。后续加测试资源就能解决问题？加新资源进来不需要分散已有人员的精力去做任务分解，去辅导新加入进来的人？加进来测试资源，缺陷提交速度更快了，开发会不会都来不及改（本来就来不及改了）造成测试等待更多？再说，如果开发这两天不能保证完成所有东西，那是不是还得再加更多测试资源？测试资源是唯一用来解决问题的法宝？

问题的关键根本不在测试资源，最后却变成要测试部门来消化这个后果。为什么不去解决本质问题呢？为什么不早点为本质问题做预防呢？为什么早的时候都拍着胸脯那么乐观呢？

时间、成本、质量，这三者的管理和平衡。看似简单，但我们却总是一而再再而三的犯错。

业务量的膨胀带来测试资源需求猛增，可能是因为前期与产品规划部门的沟通没做好，显然我们是没有做好充分的事先准备的。因为接这个部门时间也较短，内外部满意度都要兼顾，所以就会尽量想办法精简现有项目里的人，腾出来应对更多的项目。

发现有个项目，测试负责人安排了5个测试人员但其中三个人的工作量不是百分百。于是我想从里面抽一个人出来，要解释也很简单，让每个人都百分百，不就可以腾一个人出来了嘛。去跟测试负责人确认，她是反对的，理由是这样PM不会同意，我们的人员名单已经在kickoff的时候就跟PM定了。于是找PM,他果然反对，我深挖原因，真因是这样的：项目过程中会出现很多的意外状况，影响测试的进度，特别是开发可能碰到的技术障碍等等，在项目deadline不变的情况下测试时间就被压缩了，但是如果测试人力多一点预留的话，就可以抵消这些风险。原来如此！我表示理解，虽然我知道预防这种风险其实还有其他办法，而且从项目管理来说更应该做的是预防这些风险的发生，而不是尽可能储备风险发生后的解决。但因为我是在kickoff之后抽人，情感上有些愧疚，所以也没深究，最后与PM达成的共识是将我们这样做的后果列为整体项目风险（测试人力全部都百分百投入以至于没有buffer应对可能发生的延迟风险）。

其实现在回头来反思一下，其实有这么几个需要改进的地方：

1.我们做测试人力安排，应该从测试需求出发分解测试任务，需要承诺的是总人力而不是总人头。

2.从项目管理来说，为项目留buffer，更应该的是从策略上去做风险控制，而不是多腾些人力，尤其是测试的人力，这样反而会让开发的产生惰性。特别是当前组织的特性就是要求每个人有很高的工作效率，整体上尽可能多的容纳业务需求，怎么还可能用这种腾人力的方式作为buffer呢。

最近多接了一个新部门，除了架构组之外。实在是变化太多太快，有点恍惚。没能好好的做有深度的思考，关于上面的一些分析还欢迎拍砖。

最近又是经历了很多的变化，忙呼呼，一定要停下脚步，稍微整理一下了。

1.切忌不要为问题人员花费太多的时间

  这点得益于老板的点拨。我们的时间是有限的，需要我们投放精力的事情有太多。对问题员工要快速高效处理，但假若多次明显无改观，那我们宁愿选择放弃。

2.不是百分百能实现的事情，最好不要提前承诺给员工。

  有时候是想用提前承诺去激励员工，但更多时候这些承诺的实现是带有风险的，假若实现不了，你需要花费很大的精力去做疏导，甚至会种下你意想不到的隐患。

3.人员能力体现关键看应急能力

  有条不紊状况下看到的人员能力表现往往是肤浅的，只有紧急异常状况发生时才能较好的判断出员工的主动性、技能自信度、耐压能力、协调能力、影响力。能很好的对抗紧急异常状况的员工，才是我们最需要的优秀骨干力量。同时，紧急异常发生时，也是我们对能力偏弱员工进行辅导的绝佳时机。

小公告：

    很久没有上来写东东，主要是实在是太忙了，以至于完全像个死蜜蜂一般。等我忙完了这阵，偶来总结一下子。

调查：

    你最近在看什么书？

与职业大学的合作已经正式步入正轨了，课程已经进行到1/3，自我感觉比较良好，因为开班两周后，还是有学生陆续的来报名交费。

周日在讲台黑板上刷刷的写粉笔字，回头再看学生们饶有兴致的神情，忽然体会到一种幸福感。

当然，这背后更多的是责任感。

目前，省内的高校几乎都还没有软件测试这个专业。职业大学应该算是走得比较快的，毕竟他们比较追求就业实用性。我们的培训，从结构体系设计来说，应该是比较全面的覆盖了软件测试专业知识，我们备课也很注重实用性；但就深度来说，毕竟受到了时间的限制，只能做到入门级别。

于公，这次的培训是在为企业带来利润，带来影响力；

于私，其实我是在传播测试文化。我已经是一个职业的测试人，在日常招募工作中/新人培训中很深刻的体会到院校教育在这块是非常之薄弱的。所以能让学生们在进入企业之前就受到来自企业的正规培训，其意义是深远的。我为之感到自豪。

周日课程结束的时候，叶老师开车送我回家，聊到学校想把这块放大，做成全校理工科的公开课。我觉得这个思路挺好，但是涉及到企业与学校的矛盾利益关系，我还要仔细研究一下策略。最好是能真正双赢。

最近，在做职等晋升。第一步是要做能力盘点。

但是忽发现之前留档的能力结构表有些混乱，一时间乱了盘点的思路。故索性花时间重新调整了一下。

因为涉及到公司机密，测试类各职等的详细能力标准（阶梯形）就不贴出来了。

现在还不敢确认这样的结构就是完美的，但至少感觉是适用的。

因为这个人小有吸引力的Title，我去听了这次演讲。

总体感觉下来-比较失望，Just so so。

1。Slide的美观度极低，都是黑白镶嵌的静态文字；

2。辅助论点的例证不具备震撼力，至少我觉得蛮牵强；

我感觉都不如听Kevin的演讲。

他的主题是围绕80/20原则展开，其实我本来是很想听他的成长心得的，而不是所谓成功规则。

简单记录他的论点如下：

20%的人            80%的人

正面思考            反面思考

做事业              做事情

爱投资              爱购物

有目标              爱瞎想

问题中找答案         答案中找问题（找茬）

改变自己             改变别人

会坚持              爱放弃

重复简单的事情       不愿做简单事情

-----------

What i  really got are:

1.Personnel doc management.

  这个其实不是他讲的，是讲的过程中我忽然想到的。我愕然的发现我的工作知识管理做得还有条有理，但个人生活相关的（饮食/旅游/购物/运动）这些我管理的很贫乏。非常愕然，我居然这么重工作轻生活。这个一定要痛改！

2.培养多一些专长

  当然这个前提是有一个专长先。当你具备多项技能后，你就会比较不患得患失。就算这里失败了，真的尽力后失败了，我还可以做别的，我还有拿手绝活。这多好。

3.少理会挫勇者。

  这个比较好理解。谁老是给你泄气，你就基本可以不用理他了。

 这是本人的第三个Blog。

 第一个在ChinaBlog，第二个在公司的Portal上，第三个又诞生了。

 首先申明这种行为不代表我的本质---遍地开花，见异思迁。

 实质上，ChinaBlog的那个是我的生活空间，公司的那个基本上我是荒废掉了，这里嘛，显然我要栽培成我的工作空间，职涯空间。本人其实还是算是小有事业心的，所以我相信：这里可以搞得红红火火！而且一定会搞得红红火火！