Let's Go!

微软软件测试技巧

上一篇 / 下一篇 2009-05-20 23:17:54 / 个人分类：测试理论

2.1 两点间直线最近，QA建立轨道让开发在直线间滑行
2.2 测试最高境界：不需要测试
2.3 预防缺陷成本<发现BUG；预防缺陷成本<事后追究责任成本
2.4 测试驱动开发，让测试与开发同时结束
2.5 BUG 分类深刻原因：经验模式转向量化数据、统计分析的科学模式，便于定义优先级、资源分配，穿插管理思想。
2.6 执行用户体验 (UE ) 测试。UE设计能用一步完成绝不用2步。
2.7 测试不局限于你看到的内容，把测试扎得很深、透。测试对象不局限于软件，文档也是测试对象
2.8 对测试的软件施加酷刑
2.9 白盒测试是很高难度的，用工具而非肉眼阅读
2.10 Daily build与daily test结合才有意义，每个用例每日都运行，报告反映软件最新的全貌
2.11 没人对QA 产出进行审核？
2.12 如开发多次询问BUG重现步骤，说明内部质量管理是有问题的
2.13 严格执行测试计划，排除测试随意性。但鼓励测试工程师创造性
2.14 让测试数据说话，对用例和BUG统计了解项目发生了什么
2.15 测试理论从实践中提炼，异于推理性理论。
2.16 V模型包含妥协，其思想是在何时做某一个测试更合适。但每一个阶段都应该全部测试。应该打破V模型的局限
2.17 文档记录下思路，和他人一起评审；补文档效益不显著。文档没有写好，更多反映态度问题。用最简单、直接的方式表达思路给他人。
2.18 定格子明确测试范围，确认是否完备？有重复？接口测试按模块切分了么？
2.19 测试资源不足时，思考现有人员是否有潜力？是否有效利用资源了？是否有其他方式可以解决？招聘后资源空余如何处理
2.20 在时间和质量矛盾时，选择保证质量
2.21 5天内专业团队发现0个BUG，达到ZBB阶段(Zero Bug Bounce
2.22 Case 通过率：促使开发修复BUG;代码覆盖率：促使测试增加测试用例
2.23 区分工程师能力之一：功能验证点
2.24 衡量代码覆盖率的技巧：awk 在程序分支处加入printf（序号），运行检查遗漏的序号
2.25 内部产品必须平滑过渡
2.26 灰盒测试是一种妥协，一定要追求白盒测试；白盒测试本质用程序测试另外一种程序，编写白盒测试工具也是能力转换的方式。白盒测试工具与应用程序互验证。
2.27 购买工具思考清楚想解决什么问题，用一个工具来解决，否则工具多反而效率下降。工具需可定制化
2.28 自动化流程从创建开始，到环境恢复止。自动化测试主干流程容易重复，重视单元级的细致测试
2.29 用自动化思维思考问题，抽样也是一种妥协
2.30 定制控件，不要牺牲软件特性换取程序可测试性
2.31 B 测试不是让用户找BUG，而是让用户判断是否满足功能需求、UI需求
2.32 创造UE测试标准
2.33 自动化编码原则
用例间独立运行，不依赖其他
用例结束RESET
用例运行次数建执行无障碍

2.34 1个人+ 1群机器运行，高效
2.35 从入库开始，代码就接近可发布的ZBB
2.36 手工测试为主，研发与测试比例2：1 ，最高不超4：1；自主研发测试工具为主的team，研发与测试比例1:1
2.37 不单纯依据BUG数量衡量开发人员水平，否则带来无穷的争吵和问题
2.38 不要轻易放过一个有测试专长的人才
2.39 测试纪律不要定制太多太琐碎，应该保证充分严肃性
2.40 开发部门与测试部门配合是否流畅，和2部门经理风格相关，在于形成共识
2.41 规范无止境

微软测试管理一些通用理念

1.1 结果是刚性的，过程是柔性的
1.2 熟视无睹的事情容易出问题，做事情回溯到本源
1.3 所谓效率即一次把事情做对、做好。让适合的人做适合的事情，价值最大化
1.4 把最好结果、最坏结果，理顺目标才做事情
1.5 微软让人震撼的是全球经理提微小的BUG，非常严格的BUG 标准
1.6 要赢得别人尊重，要一如既往专注、专业，需要自身付出努力和实力，用自己价值赢来。
1.7 管理者要了解心理学，分配工作确定owner
1.8 一部分人的产出物没有做好，浪费更多人的时间
1.9 衡量团队成熟度指标：自管理度。经理花更多时间在运筹帷幄、新技术研究上
1.10 管理者获取信息途径包括人、平台，避免数据失真。管理者必须有思想，减少层层汇报。
1.11 人力成本隐性的，人力浪费更多是浪费机会成本
1.12 搭建一个团队公平展现能力的平台，不要做无价值的工作。和组员讨论职业发展，有是非分明的处事方法，同时不要怕承认错误

微软 测试技术可借鉴的点

1.1    测试驱动开发，尽早、不间断地进行软件测试。建立强大的支撑daily build和daily test的自动化测试体系。围绕BUG数据为中心建立缺陷管理平台、统计分析、项目管理平台。决策从经验模型转向科学模型，整个软件开发流程宏观、微观细节都用数据说话。透过数据管理者花精力在尚未做好的事情上
1.2    建立制衡制度、文化，不让有问题的代码check in，保证代码库神圣。减少围绕BUG的各种成本。
1.3    完善各种CheckList 或者模版(文档、用例)、开发测试工具（白盒…），让能力瞬间transfer 到团队，充分应用已有成员的成果，提升team Level。充分避免手工测试弊端(无知识传承、置信度低、相对持续在一个水平)
1.4    自动化测试不仅仅是技术，更是思想，自动化测试不是找BUG的而是一种质量保证手段。自动化本质是引入一种痛苦解决另外一种痛苦。基础设施不足是问题根本。脚本是自动化的最低形式。框架充分re-use、封装复杂度，提高框架的适应能力。自动化测试应在单元级上细致验证。建立自动化的平方环境
1.5    在每一个环节细致严格要求，比如BUG提交规范减少人为沟通。每一个QA把自己的事情一次作好、做专业
1.6    发布标准： 95% case通过率以及85% 代码覆盖率，<5%不重要的case bug。
1.7    强调文档价值（能力转换形式，对管理的支撑）以及定义高质量文档的要求
1.8    可靠性测试、可扩展性测试针对设计而言，尽早测试，否则即使结果不满意，成本也很高昂
1.9    Work around和彻底解决问题间，选择后者。硬碰硬突破
1.10  测试工程师业绩考核指标：增加check in前预防BUG、发现别模块的BUG、开发自动化工具等贡献度大的项比重

阿里巴巴质量保证平台整合趋势

当下阿里巴巴质量保证部门采用主要的平台、软件、工具有：

1) 项目管理工具: IBM  rpm 。系统架构： jboss4.2 + oracle9 + redhat 3.8 。

缺点：由于IBM SQL 加密以及数据库表结构未提供，经过几次系统调优，操作响应速度依然不尽如人意。
   目前所需要的部分报表是不满足的，需要导入到数据仓库平台分析。

  初步评估Microsoft share point。接触HP ppm(能够和quanlity center 、Microsoft project很好集成)。

国内华为花费重点购买rpm以及昂贵的咨询费让IBM 一起提升软件开发规范度。

2) 需求管理工具

需求部门采用confluence。系统架构： linux。

用例颗粒度尚未符合软件工程的Use case，细致程度待提升。

目前部分测试报告、测试文档也放在confluence。

confluence用 wiki风格。其版本管理能力、交流能力稍弱。comment具有类似回帖功能。

3) 测试用例与缺陷管理

采用quality center。系统架构: jboss +IIS + sql server express+ windows 2003 server
QA 经常使用的模块：测试用例分析与设计、缺陷管理、后台备份恢复等

需求管理、dashboard报表系统未充分使用，另外有些团队测试实验室利用率稍低。
由于web项目频繁变更，报表模板复用率偏低，故报表系统能力未充分发挥。

主要缺点：每个全功能缺陷连接license在3-5万。

4) 测试部门文档管理

采用svn。系统架构: apache + redhat linux

缺点：全文检索能力弱。可以结合google 本地搜索功能或者MS的搜索功能

5) 内部技术论坛

自主研发的论坛opentech。系统架构： java + webx+ linux 。

我个人认为还是相当不错的，功能齐全。有论坛、知识库，支持帖子搜索。且有高质量的文档。

缺点：QA评价是有点阳春白雪  ，我看来缺点就是外部合作伙伴由于信任证书无法登录。

6) 即时通信

采用阿里巴巴自主研发的贸易通。系统架构：c++ + linux。
平常各个测试组建立群，可以在群上迅速交流。

缺点：新来的员工无法看到先行者的一些讨论、分享。

7) 数据仓库平台

MicroStrategy之上二次开发。后端Oracle。

从上面看，信息分散到不同的平台中，为了进一步提升使用效能，整合平台工具需求呼之欲出。
主线大致有几点：

1) 项目管理->需求分析->测试分析与用例设计->BUG 管理->报表、统计分析，一个环状的闭环系统。

由于平台采用多家产品，整合难度提高。仅仅从数据层面流动意义不大。

希望上述多个环节能穿接起来，形成一个宏观层次提供报表、微观层次给测试工程师工作的平台

2) 需求分析->测试分析与用例设计->BUG 管理->源代码，形成一个需求和源代码的映射关系，做到需求和代码的有效变更跟踪

  sina 采用开源工具做。

3) 测试文档、交流、搜索功能一体化

主要针对文档放在SVN，项目计划文档放Confluence,交流在贸易通上集散。

希望能做到集文档、交流、全文检索功能于一身。这个过于个性化的需求，暂时没有找到开源工具解决。

光针对全文检索需求，可以采用自主研发的isearch3.0或者开源lucense。带附件的帖子不能简单做搜索。

4) 其他

针对项目管理平台RPM，改善成性能更好、数据纬度更丰富、数据流/接口清晰的平台

...

每一个需求真正融汇贯通，实现成本相当不菲。

阿里巴巴测试难题

测试技术方面：

(一) 功能测试

1测试环境搭建时编译抛出错误，快速判断是否系代码问题
2测试中抛出500错误（或log文件中error），快速判断系代码or数据or外部接口问题
3自动化测试脚本是否细化验证点为所有可验证内容（页面所有内容显示区域、数据库、搜索引擎、cache、本地cookies等）? 检查细化，但维护量非常大
4（高优先级) 测试数据准备工具（数据库、搜索引擎、cache等持久化或临时数据）
5个人pc机本地测试环境差异（操作系统状态、完整性，浏览器版本、完整性），引起问题的原因是软件的添加/卸载，浏览器插件安装/删除，补丁程序，系统设置与浏览器设置等等
6 数据准备如：不同类型账号生成，像生成10中供新单账号， 10个中供服务中账号等等，批量生成而不需要手工完成，否则效率慢了。
7 搜索引擎支持多个站点，每个站点又有不同的数据应用，se.conf存在众多的配置项、分词器，测试的矩阵非常庞大，如何保证尽少资源获取最好测试效果
8 抽样检查分词器的功能有遗漏，但分词器算法和外部已有的分词器算法不同，如何提高分词效果核对效率
10 海量数据查询结果正确性验证

(二) 性能测试
  1 生产环境硬件模拟
生产环境依赖于外部昂贵的设备，在测试环境开展性能测试如何模拟？比如有专用邮件服务器，图片服务器,CACHE服务器？
2 数据模拟
      生产环境的数据量巨大，如何剪裁合适的数据集作为性能测试基准数据？
3 用户行为模拟
   虽时间变化日志系统分析的数据会很快过时，如何低成本跟进访问模式

  4 特殊场景下性能瓶颈定位与监控等等
   比如国际站凌晨2点突然LOAD 升高，原因未明
  5  容量规划的效果如何衡量

(三) 质量管理平台
1 没有缺陷报告平台，需要详细或自定义报表时无法给出
如QC 的报表、需求管理2部分功能一直没有采用。
2 项目管理、需求管理、缺陷管理多个系统入口，并没有统一关联。另外代码与需求之间映射关系随着业务变更也难以一一映射
3  现有的软件测试平台更适合传统的大型软件测试，能否、如何定制更适合快速上线的WEB系统？

(四) 测试管理
1 测试机器的使用权限（Linux、Windows）管理，做到近少互相干扰
2 如何有效度量测试工程师的绩效？
3 (高优先级) 如何更快找到合适的测试人才？
4 (高优先级)如何提高开发、测试双方的满意度？
5 (高优先级)如何提高估计测试时间的准确度？

(五) 测试新技术的应用与推广

1  如何有效开展安全与漏洞测试
如：sql注入，cookie安全机制，安全证书、加密等. 服务器与客户端的安全漏洞检测等
2 白盒测试工具引入及白盒技术等
如：单元测试工具Junit, parasoft的白盒测试工具使用与引入等。
3 自动化测试在项目中是否需要介入，何时介入？（数据准备？回归测试？）
4  如何在自动化覆盖率和验证点密度  与自动化成本间找到一个合理的平衡点

测试策略与方法方面
(一) 测试用例分析与设计
  1 冗余的测试用例的精简化问题
  2 (高优先级) 底层代码的修改如何测试，回归范围如何确定，测试策略如何确定？
如 ejb, jboss改造的性能与功能测试
  3 如何使用冒烟测试对大型软件进行快速测试，用例的选择问题
  4 如何为复杂产品/大型测试项目选取测试策略？如
镜像站点测试
异地数据同步测试
重构项目测试
  5 Apache Modul如何测试（功能测试与性能测试）如中文站最近发布的将Image server固定域名通过modul替换成动态域名？

  6 (高优先级)支持多浏览器(IE6/ie7/firefox...)/多OS软件如何测试？支持国际化语言版本的软件如何测试？如国际站网站支持英文，繁体版，马来西亚语言。

   降低成本的测试方法有哪些？
正交表测试方法满足我们的需求么？
  7 (高优先级)如何在时间、进度压力下，最优选取测试集合？回归测试的面积多大算合理?

  8(高优先级) 跨部门、跨公司的接口测试如何开展，以提高协调效率？
   如中文站和阿里软件贸易通状态接口，国际站和后台CRM 接口，

（二) 测试执行

1开发的代码中缺少足够的接口来支持自动化或者黑盒测试的问题
2 反复测试引发的测试疲劳如何应对（个人、团队）？交叉测试什么时候引入合适？如何衡量交叉测试的绩效?

（三) 测试标准
1 如何定义测试“完成”，比如如何定义搜索引擎测试完成？
2 如何提升对项目是否可以release的影响力
3 (高优先级)如何清晰度量产品的测试质量
按测试覆盖率？按BUG遗漏数？按已经发现BUG的曲线图？哪些标准度量最合适
4 测试人员是否需要了解代码，了解代码需要到达何种程度？
5 如何在没有单元测试代码情况下，度量代码测试覆盖率

微软软件测试质量体系最佳实践课程

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）保持项目的持续成长
没有科学的测试管理就不可能建立完备的质量保证体系，这部分内容分享在测试管理中的有效经验，通过流程控制与过程改进优化测试效率，保证测试质量，加强测试对于需求分析和开发过程以及技术应用的配合，从而完整实现测试驱动软件开

遴选合适岗位人才要领

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

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

二考察专业能力

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

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

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

较好

三考察学习能力

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

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

节。

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

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

有利于顺利开展工作。开放、共享的心态有助自我提升。

还需要判断其缺点是否影响其业绩

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

五职业素质

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

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

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

欢迎大家探讨

web软件测试碰到的难题

最近在整理测试难题，以及打算在跨子公司讨论、分享的话题。呵呵，大致列举一些

1 如何清晰度量产品的测试质量？

按测试覆盖率？按BUG遗漏数？按已经发现BUG的曲线图？哪些标准度量最合适

2 如何为复杂产品/大型测试项目选取测试策略？如

镜像站点测试
异地数据同步测试
重构项目测试

3 支持多浏览器(IE6/ie7/firefox...)/多OS软件如何测试？

降低成本的测试方法有哪些？

正交表测试方法满足我们的需求么？

4 支持国际化语言版本的软件如何测试？如国际站网站支持英文，繁体版，马来西亚语言。
降低成本的测试方法有哪些？

5 如何在时间、进度压力下，最优选取测试集合？
回归测试的面积多大算合理?

6 如何提高估计测试时间的准确度？

7 跨部门、跨公司的接口测试如何开展，以提高协调效率？

如中文站和阿里软件贸易通状态接口，国际站和后台CRM 接口，

8 如何有效度量测试工程师的绩效？

9 生产环境依赖于外部昂贵的设备，在测试环境开展性能测试如何模拟？

比如专用邮件服务器，图片服务器？

10 生产环境的数据量巨大，如何剪裁合适的数据集作为性能测试基准数据？

11 如何更快找到合适的测试人才？

12 如何提高开发、测试双方的满意度？

13 如何在没有单元测试代码情况下，度量代码测试覆盖率

14 现有的软件测试平台更适合传统的大型软件测试，能否、如何定制更适合快速上线的WEB系统？

如QC 的报表、需求管理2部分功能一直没有采用。

15 项目管理、需求管理、缺陷管理多个系统入口，并没有统一关联。另外代码与需求之间映射关系随着业务变更也难以一一映射

...待续

技术管理初体验

在技术管理方面，偶是绝对的新手。

不过就像很多事情一样，都有人无师自通的J,可惜偶不算这种。

以下都是偶的一些浅显见解。

技术管理和纯技术工作还是有很大的不同

1) 技术管理需要经常REVIEW成员的成果，REVIEW的工作量取决于REVIEW的粒度，太细会把握不住重点且工作量大，太粗无法看出门道。由于要REVIEW组员成果，需要对组员的工作领域有比较深刻的把握，故技术管理需要杂家。纯技术则一门心思把自己的事情做好，并偶尔帮忙请教的同事解决问题，在自己的领域专注得比较深