测试部日常工作所需的工具流程及模板

创造和使用工具以及创造和使用方法，是人类是区别于其他动物的显著特征之一。但我们的大学教育往往只侧重知识传播，忽视工具和方法论的教育。在这里我总结一下IT行业测试部门所需要的工具平台及相关流程和方法。

创新互联是一家专注于成都网站设计、网站制作与策划设计,嘉善网站建设哪家好?创新互联做网站,专注于网站建设十余年,网设计领域的专业建站公司;建站业务涵盖:嘉善等地区。嘉善做网站价格咨询:028-86922220

=测试部需要建设的工具平台=

* 缺陷跟踪平台

缺陷也就是bug,也有叫MR(Modify Requirement)的，是测试工程师日常工作成果的最直接的展现。提交bug时逻辑清楚叙事通顺是首要的，有点像是写一篇记叙文，时间地点人物起因经过结果都应该有。常见的缺陷跟踪平台有Bugzilla,Clearquest,Jira,Redmine等。一般的缺陷跟踪平台都会提供项目管理、版本管理、模块管理、自动Email通知、权限管理、自定义参数等功能。我认为一个好的缺陷跟踪平台应该是简洁、直观、迅速、易上手的。如果能提供排序，汇总，图形化那就更好了。缺陷管理平台作为测试团队和其他团队之间最重要的接口，应该融入到公司的整体IT环境里去，IT部门需要保证各团队访问的便利性，以便促进团队间交流的效率。如果一个产品经理不关心产品的缺陷情况，就不是一个合格的产品经理。

* 知识管理平台

知识管理平台用来在团队内部和团队间分享产品知识和心得。IT行业人员的流动率出了名的高，因此一个好的知识管理平台对团队健康成长是非常有必要的。Wiki由于有便利的更新功能，可以保持文章的常用常新，因此几乎成为知识分享的标准平台，完全可以淘汰论坛，SVN等等工具。在一个有一定积累的知识管理平台上，从市场到研发，产品上下游几乎所有人都能从中受益。常见的Wiki工具有Mediawiki,Confluence等。

* 自动化测试平台

自动化测试对于代码重构、版本间的回归测试是非常重要的。可以说，敏捷开发模式之所以兴起，完全是因为自动化测试技术的Open和进步。尤其对一个生命周期比较长、版本比较多的产品来说，自动化测试是非常重要的防火墙。自动化测试的本质是以软件测试软件，因此需要以软件工程的方法对待。几乎所有编程语言都有其对应的xUnit自动化测试框架，但是需要注意的是并不是只有单元测试才能做自动化，IT，SIT, SVT阶段都可以做自动化，需要根据产品特点，选择产品不同阶段自动化测试的方法。

* 探索测试平台

很多测试工程师都会发现，有时候根据spec和plan做测试发现的bug，还不如发散测试和探索测试发现的多，因此好的探索测试平台是很有必要的。探索测试平台应该是一个工具平台，解决测试环境的仿真问题，需要持续的将适用和好用的工具加到平台下来。探索测试平台应该和自动化测试平台形成良好的互动，将好的工具持续引入自动化测试平台中。

* 持续集成平台

持续集成平台的建设可以大量提高软件发布过程的效率，减少人为错误。持续集成的的目标是更快，更全，更直观。代码的checkout、编译、发布、部署，测试、报告，每一步都有巨大的效率提升空间，自动化everything。常见的持续集成平台有Jenkins/Hudson,CruiseControl，Bamboo等等。软件改变世界，工具改变世界。

* 辅助工具平台

辅助工具平台用来辅助测试工程师日常工作，比如用例设计，文档检查，时间规划，邮件处理，IM,截图工具等。团队应该尽量使用同一套工具，遵循同样的配置，以减少不必要的交流和误解

* 版本管理平台

脚本，文档和工具都应该版本化管理，个人推荐Git,相比于Svn，少了很多的.svn文件夹，copy起来方便很多

* 用例管理平台

在团队规模日益膨胀，用例和版本日渐增多的时候，建设一个用例管理平台就非常有必要了。常见的用例管理平台有testlink，testcenter等，可选范围还是比较小的。相比于Excel强大的稳定性和易用性，不建议在测试管理平台上直接写用例，无穷无尽的麻烦，使用一个Excel用例文档到用例管理平台的辅助导入工具是最好的。

=测试部日常工作所需流程=

* 任务分解流程

爱因斯坦说，把复杂的事情做简单，我理解意思就是分解。现代社会的特征就是分工更细，1+1>>>2的团队才是优秀团队。因此建立一个分等级的专家团队，各展所长，保证每个人无论本领经验如何都能最大程度发光发热，这也是华为团队成功的法宝之一吧。

* 缺陷处理流程

每个团队的资源都是有限的，大多数时候我们并不能等到所有缺陷都解决了才去发布产品，因此如何处理和评价缺陷事关产品整体，会涉及到市场，研发，测试等各个团队，需要明确的流程来保障

* 产品发布流程

在产品发布前，通常需要确认所有的风险都已规避，所有相关的资料手册都已完备，最终版本和需求匹配，这也是牵扯公司很多部门和环节的事情，因此，产品发布应该建立一套强流程的规范，协调不同团队间工作的顺序展开

* 用例及脚本维护流程

敏捷开发的理念之一就是轻文档重交流，这是因为维护文档的状态常新是一件很麻烦的事情，如何保证用例、脚本的一致性，如何保证网上问题的闭环，这些都是测试团队需要注意的问题，因此，在一个统一的流程下操作是很有必要的

* 新员工培训流程

对于新员工的培养，一定要建立一系列明确的目标，需要掌握哪些工具、模板、流程、资源，如果事先做好培训计划和流程，可以省很多事情哦

* 文档的Review流程

文档是最能反应工程师职业化素养的输出，逻辑和语言都是需要训练才可掌握的东西，没有经过Review的文档都是不合格的文档，Review的过程即可以查漏补缺，也可以统一口径。对于测试部主导输出的文档，都应该规定何时何人用何种方法Review，从哪里来到哪里去，这些都应该有明确的流程和制度来保障。

* 工作状态汇报及跟踪流程

周报，日报，重点任务，甘特图，里程碑，这些东东都用起来吧，习惯成自然

=测试部常用模板=

* 测试用例模板,计划/需求/报告模板

* 周报/日报/任务跟踪模板

=需要注意的事情=

# 这些平台及流程的建设并不只是测试部门的事，应该尽量融入公司整体的IT环境，比如Email系统，身份管理等，用SSO单点登录的方法是最好的，省得在一堆密码间跳来跳去。

# 需要注意对新员工的培训，保证所有人都能以正确的方法使用整套的工具

# 借用任老板(正非)的话：职业化就是规范化、表格化、模板化、数据化、流程化

# 任何工作都应该是一个持续优化，不断改进的过程，教条是不好的，借用敏捷宣言：以人为本。再借用任老板的话：先僵化，再优化。