随笔点滴——第47期51Testing深圳软件测试沙龙

随笔点滴

                                 ——第47期51Testing深圳软件测试沙龙

差点杯具

之前深圳沙龙也有报名，但是由于种种原因没能去成。这次原本计划也是要加班了，但由于进度有点延迟，没有测试版本，测试不用加班。所以能参加第47期51Testing深圳软件测试沙龙非常庆幸。

王老师的风采

本次沙龙由51Testing创始人之一王威老师担任主讲，在之前单位的时候上过几次王老师的课，渊博的知识、丰富的经验与诙谐讲课风格，让人非常受教，所以沙龙通知出来我就在祈祷，千万不能加班啊。再加上这里主题“高效的测试需求分析和测试用例设计”是我比较关注的方向。这次，王老师渊博的知识在51Testing自主研发的全球首款测试分析设计工具TestPlatform（TP）演示下，将“高效的测试需求分析和测试用例设计”这个抽象的主题讲的更清晰明了。

TestPlatform（TP）

把这个工具作为一个小标题不知道会不会被人认为给51Testing作广告的嫌疑，但是个人觉得，这真是一款很不错的工具。因为我之前也上过“测试需求分析和测试用例设计”的课，也做个这方面的工作。那时候上课和工作中都是用的表格，自己把分析的规格复制粘贴，相当不方便，还有一些逻辑或者方法的问题，给学习和分析带来不少困惑，至少让我很困惑。什么继承分析，交互分析，正交集成，都需要人去思考分析。而这款工具把这些复杂的东西作为算法，做到工具里面了，在使用的时候只要舒服分析的内容，很多东西都可以让工具本身去解决了。这就使得工作变得非常方便。具体的其他好处就不说了，不然真的成了打广告的了。

测试的技术含量

这款工具让我更加肯定，软件测试有技术含量的不是自动化工具或者会编程，会使用LR，而是测试思想。这种思想是站在产品一定的高度，对整个测试过程进行统筹规划和设计，这些完成了就是实现问题了，就是LR高手，编程高手（测试编程）就开始忙了。打个比方说，之前的工具、写在纸上的设计方发都是招式，而测试思想就是口诀，没有口诀的招式，就会是些花架子，对付一般的（表面上的东西，如简单的功能测试），遇倒高手（比较复杂的问题）就束手无策了。很多人可能会有这样的感受，从书上看到的设计方法或者工具使用法，感觉也精通了，但是真正用到实际上，尤其复杂系统的测试上，就感到无从下手。我想这个跟软件架构师的设计思想可以类比一下吧，架构师属于技术类较高级别的职位，他们在长期的实践中积累了一套设计思想，让他们在设计中如鱼得水，东西设计好了，那就是程序人员去实现的问题了。当然这是要不断的学习、实践和积累的。

两个小故事

    在王老师的演讲过程中，我想到两个小故事，应该绝大多数都听过，一则是《庖丁解牛》，另一则叫《磨刀不误砍柴工》。不知道为什么会想到这两个故事，但是我觉得其中还是有一定的联系的吧。等哪天参详透了，再跟大家分享吧，有高手也可以点拨一下俺……

沙龙内容

    沙龙过程中，对沙龙内容简单了做了笔记，因为以后51还有把胶片和录音上传的，所以只简单的罗列一下王老师PPT中的内容（见附录）。

现场问答

     按照惯例，在主讲奖完后，是现场提问环节。个人觉得，本次沙龙更适合高级测试工程师和测试经理或者主管参加，从提问环节更可以看出来，提出的问题多数跟本次主题无关，主要都是多数人常问的问题，比如测试的职业发展，进度紧，留给测试时间少的情况下怎样保证产品质量，没有需求怎么做测试设计等……对此环节没多少印象了，只对王威老师关于职业发展的一个问题的回答印象比较深刻，主要意思是干一行爱一行，打好基础，以后无论往哪个方向发展都能够胜任……具体可以听现场录音。

其他：

1、沙龙开始前，来了一个嘉宾，被邀请到第一排的位置，而他觉得显得太高调了，不愿意。后来有幸得到一张名片，才发现乃某某公司研发总监，果真低调。

2、有幸跟一些公司测试方面的负责人进行测试发展和个人职业方面的交流，还有幸认识了51testing深圳负责就业工作的两位美女老师……

3、还跟嘉宾就当今社会形势和经济等作了热烈讨论

(是不是越来越像新闻稿了……不要打我啊，马上打住)

小结：总得来说，此次沙龙收获蛮多的，不仅仅是与沙龙主体相关的，还有许多与主体无关的……测试界需要沙龙，需要百家争鸣，在争鸣中推进测试的发展和个人素质提高，希望以后能多参加这种活动……

附录：

（沙龙内容，笔记不是很完整，见谅）

一、测试用例质量的判定

       1、对需求的覆盖率

  2、用例的精确程度

  3、测试用例发现缺陷率

  4、可执行性和执行效率

二、测试分析设计常见问题

     1、方法、技术

1）测试需求分析

2）用例设计方法

3）被测是产品的可测试性

4）产品相关的业务知识

2、流程、工具

  1）测试用例设计的合理性和测试用例设计的效率

  2）测试需求分析工程师和测试设计工程师分工

  3）对需求到测试用例的全面跟踪和变更管理

  4）针对多个版本继承的测试用例的搞笑裁剪和补充

3、人

1）基本素质

2）技能培养

3）业务知识

三、典型测试分析模式

1、与开发分析过程相对应的测试过程

业务需求分析       需求项管理

需求规格分析       测试项分析

概要设计           测试用例规划

详细设计           测试用例实现

编码               执行

2、典型的测试分析模式

（具体内容请看胶片）