需要系统地梳理下今年的一些思考。

  迈入工作10年生涯,有团队邀请我结合实际案例简单聊聊"工作热情"，附上我自己的理解，希望能对大家有所帮助。像很多成长课程一样,本文也是知易行难,实践是消化的唯一之道。

一 热情的正反表现

正：

冲劲十足，执行力强
自我驱动、要性强
坚持如初,有感染力、激情四射

反：

被动接受任务，分外工作
安于现状
冷却，平淡

你身边的榜样特质又是怎么样的呢?

二热情来源

1做事获取成就感，收获成长，自我鼓励、他人肯定，长期正反馈
2做自己喜欢做并且擅长的事情
3挖掘工作中乐趣，保持好奇心、新鲜感，了解底层原理、实现细节
4适当危机感，持续高标准自我要求，把事情做到极致
5明确阶段性目标，把握节奏，好心态

三 热情消退的方式

1经常性挫折，心累，很有无力感
2缺乏反馈，不受重视
3单纯重复性、事务性工作
4目标过高或者安于现状，自我定位过高，过多比较、计较心

四保持热情的一些做法

和上述消退呼应。

1 不逃避问题，寻求支持，借用团队力量，点滴进步、沉淀到量变导致质变
2从不同角色、角度获取尽早反馈，管理上司
3 换角度思考、思维创新，交流碰撞，开拓思路，反思深度、广度是否够
4目标跳一跳就够着，分解到可执行，调整心态，做好持久战准备
5适当自我调节，他人低谷
6 重复N次变成习惯

 

  寻找前端质量改进技术和工具时,陆续爬到的一些网站。
欢迎补全:)
一 公司
阿里巴巴http://www.aliued.com/
阿里巴巴http://www.aliued.cn/
支付宝:http://ued.alipay.com/
淘宝http://ued.taobao.com/
口碑 http://ued.koubei.com/
阿里妈妈 http://ued.alimama.com/
阿里软件http://www.alisoftued.com/
雅虎 http://www.uedblog.com/
D2技术论坛:http://www.d2forum.org/
19楼 http://blog.19ued.com/
杭州网易 http://ucd.blog.163.com/
网易http://www.ued163.com/
腾讯CDC http://cdc.tencent.com/
腾讯ISD http://isd.tencent.com/?cat=7
腾讯无线 http://wsd.tencent.com/
百度范用户体验 http://www.baiduux.com/
百度无线 http://mux.baidu.com/
百度有啊技术http://www.youalab.com/
搜狐http://ued.sohu.com/
第九城市 http://www.the9ued.com/
盛大 http://www.sndaued.com/blog/
携程 http://ued.ctrip.com/blog/
UCD大社区 http://ucdchina.com/
视角同盟 http://www.visionunion.com/interface.jsp
移动http://mdchina.org/
UED: http://uecom.org/
交互设计 http://alite.aliued.cn/
人机界面 http://www.chinaui.com/
http://www.bbon.cn/
二 个人
玉伯 http://lifesinger.org/blog/
完颜 http://www.smbey0nd.com/category/mobile-web/frontend/
泽飞 http://www.planabc.net/
大熊 http://www.thedaxiong.com/
http://blog.sharkui.com/
http://dimcolor.com/blog/
陈成 http://www.chencheng.org/blog/
阿里人http://www.aliren.org/?p=7
IT民工 http://www.fool2fish.cn/?cat=5
付琦 http://www.imf7.com/archives/category/web
前端之路 http://www.simcn.com/category/html_css_javascript
http://www.anbuyu.com/

  从《测试之美》附录爬虫式找到的一些质量保证领域专家BLOG。欢迎在外企的朋友帮忙补充。

微软测试专家BLOG http://msdn.microsoft.com/en-us/testing/bb880947.aspx
jennitta andrea  twitter：http://twitter.com/jennitta_andrea
性能测试scott barber：http://www.perftestplus.com/presentations.htm

rex black: http://www.rbcs-us.com/blog

adamchristian：http://www.adamchristian.com

isaac clerencia: facebook/titter

john.d.cook: http://www.johndcook.com/blog/category/software-development/

敏捷测试lisacrispin: http://lisacrispin.com/wordpress/

过程改进 adam goucher： http://adam.goucher.ca/?page_id=538

Matthew Heusser
： http://www.informit.com/authors/bio.aspx?a=49E9EE57-4D25-45DF-A5F5-BFD45F95E894

karennjohnson ：http://www.karennjohnson.com/

remko roncon： http://el-tramo.be/

lida wilinson: http://www.practicalqa.com/

一 探索性测试相关工具集：

.NET pex: http://www.infoq.com/cn/news/2008/07/Pex

Visual stidio2010 MTM: http://blog.csdn.net/quicknet/archive/2010/06/20/5682001.aspx

ET进度管理工具：http://sessiontester.openqa.org

 

二 MBT工具集

 

Ms spec-explorer: http://www.infoq.com/cn/news/2009/11/spec-explorer-2010

开源 http://mbt.tigris.org/doc.html

C#写的：http://nmodel.codeplex.com/

 

ET难点在于创新性的测试思维及平衡计划性与随机性，

MBT难点在于对领域知识抽象能力及建模。

更多工具待实践挖掘。

 

1应用javancss/metric 、jdepent度量java代码复杂度、依赖关系

2 复杂度变化大的函数，基于风险策略确保被执行.　被执行可用emma或者clover工具度量

3 建立度量数据趋势图，可集成在hudson持续集成环境上更加直观

 

0 采用代码分析工具理顺代码逻辑：如java 用codelogic, c++用codeviz/ algoview。门槛相对比较低。

 

1 使用标准格式，跟踪svn change反映解决或者新引入的bug　id。

A 内部研发的平台提交代码时，记录jira需求id、bug id和对应的代码文件：函数

B svn ci 时，comment包含必要的信息，如bug id、request view 信息

获取到文件或者函数的bug密度。

2　qc　增加字段标识bug对应的文件名:函数,　增加svn 变更号查看代码快照，以便后续分析。

 

3定期自动化分析qc及svn数据，形成易错函数列表以及模块bug密度;　应用emma度量覆盖数据，确保易错函数被执行

 

4 分析故障及bug , 形成编程规范、code review规范、静态扫描工具

 

5 综合如上信息维护一张高风险的函数列表、高bug密度文件表,持续扩大雷区.

 

目前，据了解淘宝广告、google都在应用

2009很快从指缝溜走，2010拟在业余时间重点关注以下领域。

一　互联网产品生命周期管理

二　软件架构设计评审方法论及原则

如sei  atam,kiss,dry等

三　代码静态分析技术，如java pathfinder;以及软件度量实施，如testability explorer；及findbugs扩展

四　java/linux c++开源测试框架及工具，重点：性能，自动化，profile...。参见sourceforge.net,infoq.com/cn

五　大型互联网公司敏捷实践及测试实践

六　了解互联网技术架构及核心原理，如google 工具，memcached,mysql,apache开源框架及性能优化

 

大方向是不断影响软件工程上游质量，在测试准入准出环节做适当的权衡取舍，数字化方式展现整体研发和测试效率，在高附加值环节突出贡献提升影响力。

 

野心很大，^_^

 

可参考:http://www.51testing.com/index.php?uid-13997-action-viewspace-itemid-193779

http://www.51testing.com/index.php?uid-13997-action-viewspace-itemid-173035

http://www.51testing.com/?uid-170805-action-viewspace-itemid-99226

 

   偶对平常访问较多or有意思的专业测试blog做一个简单的分类,或许有错,也肯定有很多遗漏.呵呵,欢迎大家一起完善,给大家提供一些便利.

Webx朱少民—质量管理

http://blog.csdn.net/kerryzhu

陈绍英--- 性能测试
 http://blog.csdn.net/chenshaoying

段念---性能测试:
 http://www.guanhe.cn/
 http://guanhe.cnblogs.com/

深圳oracle 朱波 –oracle测试,性能/自动化测试
http://www.rickyzhu.com/

陈雷-- 性能,管理 :
 http://jackei.cnblogs.com/

柳胜(性能+自动化):
 http://www.cesoo.com/
 http://blog.csdn.net/namesliu/category/236043.aspx

文斯(白盒):
http://blog.csdn.net/vincetest/
 http://blog.csdn.net/wayne_chan/category/241332.aspx

微软余正洋:
 http://blog.csdn.net/rogeryu/

jack-测试架构:
 http://www.51testing.com/?uid-293557

广东赛宝陈能技-自动化:
 http://blog.csdn.net/Testing_is_believing

刘艳会—c++工具:
 http://www.51testing.com/?uid-10851

于涌—性能测试:
 http://tester2test.cnblogs.com/

深圳金蝶杨学明:
 http://mikeyond.cnblogs.com/

秋阳-综合:

http://www.cnitblog.com/qiuyangzh/category/375.html

阳光:
http://blog.csdn.net/Test_sunny

微软李和恒:

 http://blog.csdn.net/papercrane
微软安全测试:
   http://blog.csdn.net/goldcattle/

楷子狐:
 http://hi.baidu.com/higkoo

zee ---性能测试:
http://www.7dtest.com/
http://blog.csdn.net/zeeslo
http://blog.csdn.net/zeeslo/category/215291.aspx

盛大龚X—性能测试:
http://blog.csdn.net/jacky8024
http://blog.csai.cn/user1/37626/index.html

成都四方辛凯:
 http://blog.csdn.net/nilxin/category/144266.aspx

安全测试:
 http://www.51testing.com/?uid/59943

51testing云层—性能测试

 http://www.51testing.com/?uid-104

崔启亮---本地化:
 http://blog.csdn.net/giltworld/

mayingbao—测试管理:
http://mayingbao.cnblogs.com/

贺炘:
 http://blog.csdn.net/hxcat

小布播客---性能:
 http://wilson66.cublog.cn/
 
阿里云刘新宇:
   http://blog.csdn.net/omomo/
  
阿里巴巴 SQA :
 http://hi.baidu.com/jacob/blog/index/0

阿里巴巴QA:
 http://www.51testing.com/index.php?uid-159438
阿里云陈洪:
 http://hi.csdn.net/linkyou

淘宝QA:
  http://www.51testing.com/?uid-84753

阿里之家:
 http://fafeng.blogbus.com/

陈卫俊:
http://www.51testing.com/?uid/5534

51testing朴春龙---LR:
http://blog.csdn.net/piaocl

宋峰---QTP自动化:
http://www.51testing.com/?uid-35-action-spacelist-type-blog

苏州风过无息---QTP自动化:
http://www.51testing.com/?uid-3528

更夫:
http://www.51testing.com/?uid-1592

   测试团队发展到一定阶段,对目标有了更高追求,对于进一步彰显价值有了更迫切的愿望.

回头看看我们测试 可以做的输出
1) 产品road map建议
2) 具体某一个产品的需求评审
3) 架构评估与选型,设计评审建议
4) 代码code review
5) 单元与集成测试代码编写及review
6) 编写自动化框架及代码
7) 实施测试 (功能,性能,安全, api, 高可用性….)的输出, 如计划/方案/用例/报告
8) 系统性能优化
9) 生产环境性能数据闭环反馈指导性能建模
10) ...

  用代码覆盖率及漏测bug , 每千行代码发现bug,每人日完成的代码行,测试工具的效率提升数据等可量化指标, 加上项目组相对客观的评价,多维度展现测试的输出. 凸显价值可从上述输出及指标逆推.

  只有全面提高研发和测试的技能,及职业化的做事方式方法才能更进一步提高价值.

　

　　大型分布式应用程序测试,可考虑从本机及跨网络实施测试分析.本机考虑测试点:

　长久浸泡在测试领域,了解到很多朋友可能只接触了测试领域冰山一角, 　有很多的风光尚未领略. 　

  　在http://en.wikipedia.org/wiki/Software_testing提供了很多开源及商业的测试工具,大家选择合适工具去实践. 挑一些page link供大家参考. http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis

http://en.wikipedia.org/wiki/Dynamic_program_analysis

http://en.wikipedia.org/wiki/Fuzz_testing

http://en.wikipedia.org/wiki/Benchmark_(computing)

http://en.wikipedia.org/wiki/Fault_injection

http://en.wikipedia.org/wiki/Acceptance_testing

    可以考虑挑一些工具在某些项目试点,尤其是关键性系统. 一般而言,需要多个工具组合才构成整体解决方案

 测试工程师做到一定阶段,需要极强的创新能力及发散能力.

可以考虑做的事情(部分为加分项):

 

1) 架构及技术方案,设计评审

如评审算法选择合理性,架构是否考虑可扩展性...

2) bug 定位及提出fixed bug建议

3) 性能诊断及瓶颈定位, 就是 profile 能力. 以及性能调优,容量建模及预测

4) 大型复杂项目自动化框架建设

5)复杂项目回归测试范围界定

      如从字节码角度出发追溯

6)安全测试,fuzz测试及漏洞修复

7)应对复杂多样的客户端os,浏览器,编程语言及服务器集群的大型分布式跨平台的应用测试. 如云计算平台

8)根据bug 以及漏测缺陷, 反推残留的bug 地图

9) 软件质量度量的维度及落地

10)作为pm 的backup,从全局角度驱动项目质量提升

11)研发测试代码　code review...

12)...

 

 

  综合以上方向,测试做到高端,和研发高端是重合的.  需要具备研发的深厚功底以及测试的敏锐嗅觉,全局视觉, 极具挑战性

 

       事情做到极致,就能不断获得成就感….

 

 

 测试当中,当系统隐Ｂｕｇ含的少于一定的数量时候,每发现一个bug付出的时间成本远高于系统刚提交ＱＡ测试的时刻.
怎么判断这个拐点落在何处呢? 如果有合适工具,度量判断成本如何?适用范围是否足够? 误差有多大?　这些问题都是需要寻求答案的.
 
 那我们是否可从另外一些维度考虑?
 　
 1) 降低产品发布标准.　比如允许最低级别的Ｂｕｇ< 一定数量时可以上线, 或者降低测试覆盖率.
 2) 提高线上故障的容忍度.　比如定义最低级别的1类故障容忍逃逸.

 上述都可能影响用户体验.

 从比较正面的角度出发考虑,
 
 1) 全方位的自动化测试,　包括web ui自动化/接口测试自动化/后台linux shell自动化/模块级自动化.　再结合cruisecontrol/continumm/ buildbot等持续集成工具
 实施持续集成,快速弹出bug ,大幅度提高测试效率.
 
 由于性能调优过程职责不够明晰,优先完成性能测试过程优化.
 
 2)回归测试范围有效界定,　比如研发出判断回归影响范围以及路径的工具,　回归测试不必整体软件全部回归
 3)针对sqa的质量月报,针对当月最影响测试效率的点重点突破
 4)分工精细化,不必每一个人都是全能型选手 ,降低学习成本.　初步划分为 linux  c++/java自动化/,持续集成,缺陷预防与故障分析, 性能测试,api用例设计等子领域
 5)知识库系统补充,充分应用wiki/svn ,bocked的时候可以第一时间搜索到答案
 6) 不断提高研发提交QA 测试门槛,比如代码覆盖率>50%并且过程持续保持水准

 7) 长期致力于测试开发方面的架构和前沿方法探索
 ..)

 

1 每次check in svn之前在review board上完成Code Review(含正式代码及测试代码), commit代码时记录review board的review id,由SCM审计.

 

SQL审核在提交QA测试需要完成

 

2 单元测试代码覆盖率>60%[qa过程中参与测试代码review,确保单元测试代码符合规范],每次接收测试时研发单元测试代码用例通过率100%, 由QA执行验证.

 

如果每退回一次,失败的测试用例需增加必要的测试代码覆盖

 

3 完成持续集成且 build 成功

Java 用continuum

C++用buildbot

 

4 pm需经过流程培训, 并且来自中立方

 

5 约定>10个冒烟点, 每次提交时冒烟测试通过率100%.

对于失败的用例,研发需要增加测试代码覆盖

 

测试计划最终结果把WBS有控制完成。测试计划符合SMART原则。

1 选人：
从几个纬度考虑
(1) 尽量发挥技术特长
(2) 结合项目兴趣
(3) 技能高+ 技能低些的结合。涵盖项目所需技能。或者不完全具备，需要有学习能力强的排头兵

2 工时估算

这个是一个很难估算准确的活。因为一个项目充满变数。
学会工作分解，然后再按每个功能点/测试范围乘一个冗余系数
可以采用project, mindmap, excel等

3 风险分析与规避
通常测试项目风险
1) 研发提交代码质量不高，冒烟测试失败
2) 研发更改频繁，送测版本过多
3) 需求文档或者设计书不够明确,QA 和需求/研发细化耗时
4) QA 测试分析不够全面
5) 性能问题分析以及调整影响面过大
6) 测试的覆盖率过低
7) 技术难题或者测试环境资源问题
...

4 确定测试范围

由于项目有外部耦合模块，要非常明确影响范围十分困难。
通常做法: 用工具绘制调用网状图。或者分析正相关的模块结合自动化测试脚本确定测试范围

5 确定测试策略

确认系统是否需要性能测试，安全测试，兼容性测试，本地化测试...

以及是否需要验证系统的高可用方案， 新旧系统平滑过渡方案 ，可扩展容量估算公式...。

6 项目的工作约定

比如采用的模版，沟通方式（IM/周会。。。)，项目出现问题的解决流程

淘宝网新近开放了TOP平台，阿里软件的同事们根据平台测试的实践编写了《互联网单元测试及实践》，阿里巴巴技术部也在实现Open API给第三方开发商的项目，国内互联网公司Open API开放状况参考http://fairyfish.net/2008/07/16/chinese- open-api/。本月程序员杂志Open API大篇幅占据版面。chinaunix专门开辟openapi专栏 http://bbs.chinaunix.net/forum-137-1.html。
   这些信息都表明，OPEN API是增强网站个性化、定制化的方式之一，将成为主流网站的一个趋势。

一种新的研发模式也必然对测试带来一定的影响。对于开放API的平台商而言，Open API本身的测试也会有自己个性化的特征。

(1) 安全测试要求更高。由于涉及关键数据众多，在用户输入验证、输出展现、安全交互、权限系统设计方面的要求更高。防止SQL注入、命令注入、XSS、缓冲区溢出、整数溢出等主要安全问题围绕整个软件生命周期。

(2) 流量、资源消耗、计费等监控粒度更加细致。

   从第三方开发商过来的请求流量设计方面必须足够聪明,做到有效控制DOS攻击。
   
   需要评估审核第三方开发商研发能力，加强对其管理。
   
   API调用需要大量计算资源，有效监控资源变化包括系统级别的资源（如CPU\IO\网路\内存\进程间通信\打开文件描述符、数据库的CRUD等)以及业务级别资源(页面响应时间、资源下载时间等）,全方位的监控体系保证网站安全。

(3) 性能测试的需求更加迫切。
    大规模的应用访问会让系统感受到PV的强烈冲刺。
    一般应用程序关注用户访问模式，Open API更为关注API自身的调用频率。各种性能profile工具将发挥极致威力
          
(4)非常适合应用单元测试、应用代码覆盖以及做到daily build/test。

   由于提供给第三方开发商使用，其接口必然比较稳定，以及复用程度较高。从成本效益角度衡量，适合单元测试。同时借助代码覆盖率度量工具，增加测试用例。
   由于存在良好的单元测试代码，daily build/test体系建立将让BUG主动跳出来。
     
(5)demo应用程序以及API函数说明书。
   
   demo程序以及API函数说明书同样需要测试。第三方开发商借助这些demo应用程序以及API函数说明书才能有效发挥开放API的威力，由于分处两地，为了减少沟通成本，demo程序以及说明书应该相当详备。

(6) 部署模式测试。

   API部署范围不应局限于在PC/PC Serer上， Open API也应该部署在流行的google application engine平台以及Amazon AWS上进行测试，以满足不同层次的开发商需求。

(7)支持的开发语言调用测试

   针对Open API声称支持的各种开发语言对应的API都做测试。每种语言的数据类型都有差异，这个微小差异有时会导致致命的问题。
  
(8)架构设计文档本身的测试，核心代码尽早执行性能测试
   
    应该有资深的架构师尽早介入，评审关键应用的设计文档，在早期介入减少设计失误。

    核心代码尽早执行性能测试，避免后期大规模修改。
   
  欢迎各位朋友拍砖。

[ 本帖最后由 liangjz 于 2008-7-28 12:47 编辑 ]

MSUP的课程。看了很是心动：）

陆宏杰的课程偶旁听过，给你展现很多MS的东东。有兴趣的朋友请

祥见：www.msup.com.cn



陆宏杰 曾任微软亚洲工程院部门经理
微软资深专家顾问，曾任职于微软亚洲工程院，十余年的软件开发、软件测试和团队管理经验，曾主管过多个大型复杂项目的开发和测试工作，尤其在自动化测试技术和测试管理方面积累了大量的实际项目经验。对于各种测试方法的重点、难点和实施技巧有深入的研究，其主持开发和测试的项目多次获得微软全球最高技术奖项和工程奖项，并获得msup 2007年度top one金牌分享大师、msup 2007年度软件企业内训最佳好评讲师。

课题
简述
Topic 1
对软件测试的理解
（1）软件测试的最高境界是什么
（2）测试驱动开发模式
（3）测试是需要额外增加项目时间
还是加速开发进度？
（4）通过测试提高开发有效代码率
（5）软件测试的存在阶段
（6）怎样实施不间断测试
（7）缺陷分类对开发管理支撑作用
（8）软件风险的概念
（9）测试的充分性准则
要做好测试，首先要有深刻的理解，对实践中最重要、最容易混淆或最容易出问题的地方结合实例阐述，讲解将测试融入开发进程的实战策略以及自动化测试的部署策略。

Topic 2
测试计划
（1）测试计划的制定策略
（2）测试计划和需求分析之间的联系
与配合
（3）如何科学评定工作量、所需人数
和各方面设备
（6）测试范围的界定
（7）测试目标的界定和考评
（8）项目风险评估
（9）测试过程中的假定和局限
（11）被测对象特性描述
（12）具备可操作性的发布标准
（13）对验证粒度的管理和要求
（14）通用方法/工具的建立
（15）所需拓扑逻辑的定义
（16）各种测试工具的比较和选择标准
（17）怎样提高测试效率
（18）如何组织和管理需求文档、设计文档和测试文档
分析文档的核心价值和在软件项目中的作用，为什么要写文档？不写行不行？要写哪些文档？准备文档对项目整体进度的影响是什么？

这部分内容将分别从测试执行者和测试管理者的角度分别出发，讲解如何制定能覆盖到细节的测试计划，文档对项目的实用价值，对文档质量的评审流程，以及准备资源的依据，并最终评定每一个测试人员的测试执行情况。

Topic 3
测试用例
设计
（1）黑盒测试
（2）白盒测试
（3）等价类划分法
（4）边界值分析法
（5）因果图法如何提高测试技术复用程度
在众多测试用例中，验证的深度和白盒测试是测试活动中比较突出的难点，大部分理论中的描述不具有可操作性。这部分内容会着重讲解如何进行深度验证和解决白盒测试的难点，使得白盒测试可以真正得以实施，同时，介绍提高测试效率及效果的技术复用策略。

Topic 4
测试度量体系建立
（1）缺陷库的建立
（2）用例库的建立
（3）测试结果库的建立
（4）自动化测试体系
（5）高效的工作流程
（6）数据统计和数据挖掘
（7）缺陷追踪体系 科学的测试管理
通过对测试度量体系的构建，深入理解如何工程化实施大规模深度测试。

Topic 5
自动化测试
方法及技巧
（1）对功能测试的控制
（2）黑盒/白盒测试的部署技巧
（3）安全性测试的难点和特点
（4）Help、手册和文档的测试分工
（5）全球化和本地化测试
（6）可用性测试定义
（7）可扩展性测试
（8）Geo/Political/Legal的测试方法
（9）Logging/ Message format Tracing/Counters( Diagnos ability)
（10）Testability的评估
（11）Test Hooks高级测试方法
（12）基于场景的测试
（13）可靠性/耐久性测试
（14）集成测试
（15）交互性测试
（16）兼容性测试
（17）UE测试
（18）性能测试的方法和要点
（19）Benchmark
（20）压力测试
（21）性能测试和压力测试的区别
（22）压力测试的难点和技巧
（23）对系统的压力测试
（24）对界面的压力测试
（25）使用工具进行性能测试和压力测试
这一章是自动化测试的重要实战部分，将对每一种测试方法的重点、难点和实施技巧进行讲解，用一个真实的企业级软件项目作为案例，讲解如何在一个真实项目中逐一实施这些测试方法，其中绝大部分的测试方法都以自动化测试的技术和实现方法来讲解。当所有的测试方法都部署完成，讲解何如把这些独立的测试方法和测试活动整合成自动化测试体系。从而实现缺陷预防的持续改进。

Topic 6
自动化测试体系
（1）自动化测试对Bug的控制力度
（2）多种自动化测试工具的分析
（3）自动化测试的运行部署策略
（4）数据驱动的测试
（5）核心功能的自动化测试标准
（6）Pass Rate：测试活动的重要标准
（7）代码覆盖率检查，对测试质量的审查
（8）自动化测试的缺陷跟踪
（9）GUI测试自动化的难点和解决方法
（10）自动化测试的自动化
（11）如何将多种自动化测试工具和技术部署为一个复杂完备的大型质量保证体系
这部分内容是核心中的核心，它是建立在前面用例设计、测试计划和各种测试方法的基础上的，可以说前面的内容都是在为这一块打基础，对于自动化测试来说，光有技术和工具还不够，需要工程化的综合使用，使之成为一个体系，甚至需要实现自动化测试的自动化。

Topic 7
测试管理
（1）如何着手组建和优化测试团队？
（2）一个测试团队必须的3种人才
（3）产品Bug和测试Bug
（4）如何从每一个细节控制测试进度和项目进度
（5）如何协调测试团队和其他团队的配合
（6）周期性测试的活动安排
（7）测试人员的考评标准
（8）测试纪律的制定策略
（9）质量文化
（10）对工作项的时间限定
（11）数据统计和数据挖掘
（12）如何制定项目计划，包括开发计划和测试计划
（13）合理的里程碑及里程碑之间的工作计划
（14）长期计划、中期计划、短期计划
（15）Guideline和CheckList
（16）在项目进度要求很紧的情况下如何保证测试的质量和完备性
（17）作为一个管理者必须控制的3件大事
（18）保持项目的持续成长
没有科学的测试管理就不可能建立完备的质量保证体系，这部分内容分享在测试管理中的有效经验，通过流程控制与过程改进优化测试效率，保证测试质量，加强测试对于需求分析和开发过程以及技术应用的配合，从而完整实现测试驱动软件开

[ 本帖最后由 liangjz 于 2008-6-6 21:55 编辑 ]

 

一 分析现有岗位人员技能特点，最好增加互补型人才

  假如现有的人才都属于通才型，那需要找到一个很有专长的人才，作为互补最合适。
还有如果团队都是年轻人，加入一个经验丰富稳重一些的更好

二 考察专业能力
 
  工程师考察专业能力相对容易一些，可以将自己经历过的项目提炼出一些有梯度的问题，判断应聘者

属于需要人带 、独立做事情、带团队做事情、某个领域的专家中哪种类型

  专业能力最好能涵盖基础知识以及项目实践，把握好深度、广度。基础好的人，发展潜力、爆发力比

较好

三 考察学习能力

 了解碰到疑难问题的解决模式，以及对这个问题是否有提问的智慧。

另外，可以将业余爱好与学习能力结合起来。还有询问经常去的一些网站，记得哪些比较深刻的技术细

节。
 
  一般情况下，如果对某个比较难的技术问题把握得很到位，也可以侧面了解到学习能力高下。
  学习意愿可以从他最擅长的知识入手考察，一般意愿强的人，喜欢寻根究底，深刻理解背后的原理。
反面而言，就是一根筋：）

四　考察适应环境能力
　
　可以从几个方面看
1　承受压力能力：互联网公司项目多＼紧急，一般面临多项工作并行开展，同时节凑快。
2  软技能：测试工作繁复琐碎，需要耐心、细致的特质；由于需要频繁和外部联系，良好的沟通技巧，

有利于顺利开展工作。开放、共享的心态有助自我提升。
 
  还需要判断其缺点是否影响其业绩

3  团队的融入性： 做事风格不能相差太多。认可结果为导向、客户第一等多项价值观

五 职业素质
 
1 比如跳槽是否过于频繁，能否有稳定性
2 对自己是否有一个清晰的定位以及职业发展规划

 实际上，在挑选高级人才时碰到最大的问题有几个
A） 比较接近的候选人偏少
B)  把握不准到底适合这个岗位、流入市场的候选人到底有多少？这里有类似非常复杂的猴子捡玉米问

题
C)  在软技能和潜力把握方面难度比较大

欢迎大家探讨