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

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

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

* 缺陷跟踪平台

缺陷也就是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单点登录的方法是最好的,省得在一堆密码间跳来跳去。

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

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

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


原创文章,作者:ItWorker,如若转载,请注明出处:https://blog.ytso.com/194350.html

(0)
上一篇 2021年11月16日
下一篇 2021年11月16日

相关推荐

发表回复

登录后才能评论