qileilove

blog已经转移至github,大家请访问 http://qaseven.github.io/

谈软件测试流程和追踪

  首先有一个总体端到端流程,实现测试全生命周期管理,即从测试计划,测试方案,测试设计,测试执行,测试评估的全流程管理。这是最高端的一个端到端流程。测试本身可能又分单元测试,集成测试,验收测试几个阶段,每个阶段都应该有一个测试流程贯穿。特别是集成测试和验收测试阶段的时候。

  在这个大流程下面最重要的一个子流程即缺陷管理流程或叫变更管理流程。按标准的工程变更的思路,变更本身又拆分为了变更请求,变更单和变更活动。在缺陷管理中可以使用两层表单对象,特别是大型多小组团队协作,软硬件公有的产品型测试,一个缺陷的发生在CCB分析后都可能涉及到多方的修改和验证,采用两层业务对象模式是最基本的。缺陷提交一般流程为缺陷提交,CCB缺陷分析指派,相关人修改缺陷并提交验证,提交人验证关闭缺陷。在两层业务对象模型下,必须下层对象必须全部关闭后才能给关闭上层。

  其它是一些可选的子流程,相当多,但是对于大型产品型测试往往都需要考虑。

  测试需求提交或测试申请流程,大型产品研发团队中,测试往往是独立运作的部门或团队,为了进行更好的跨团队协同,也为了测试团队的测试工作有相应的输入。需要有相应的测试申请流程,测试申请通过后测试部门才会根据测试申请进行测试。其二,在测试申请流程中,测试团队可以对开发提交的产品版本和相关资料文档进行测试前评估,确认需要测试的内容符合基本的准入要求。

  版本构建流程,在进行测试前需要进行版本构建,开发提交相应的源代码和自动编译脚本,集成人员负责进行版本构建工作,在版本构建完成后配置管理人员进行版本构建审核,开发对构建的版本进行评估,最终确认版本是否构建成功。构建成功的版本则可以朝测试环境发布。大型项目对于构建需要有独立的构建环境来支撑。构建环境包括了自动编译和持续集成,也包括了自动化单元测试,静态代码测试等相关内容。

  版本提取流程,对于构建成功的版本处于待测试状态,在测试总体计划流程中,可以根据测试实际进度提取相应的版本并发布到集成或验收测试环境。同时对于验收测试通过的正式版本,也存在版本提取正式发布到客户现场的需求。

  在各个流程中会涉及到多个基础数据的维护,包括各个角色和用户组,权限的维护。也包括了产品,项目,版本,客户等基础信息的维护。这些信息在流程中作为基础数据使用到。

  下面谈下测试过程中的核心追踪

  首先测试用例是测试设计的一个核心内容,测试用例需要实现条目化管理。测试用例需要追踪到具体的需求用例。在测试和需求间整个追踪链条为系统-》子系统-》功能模块-》需求用例-》测试场景-》测试用例,通过该追踪关系可以看到测试用例对需求的覆盖程度。

  其次缺陷在提交的过程中,必须追踪到对应的测试用例,以分析测试执行对测试设计的覆盖程度。通过需求到测试用例的追踪,测试到缺陷的追踪,可以详细统计到各个功能模块的缺陷数量。也方便后续细粒度的缺陷密度统计。

  对于提交的缺陷,开发在进行修复的过程中往往涉及到源代码的修改,而源代码最终会入配置管理环境。因此可以进一步追踪每个缺陷究竟修改了哪些源代码文件,以方便后续的源代码变更分析和管理。在缺陷提交后,涉及到进行版本构建,版本构建需要确认在当前构建的版本解决了哪些缺陷,哪些缺陷可以进行回归测试和验证。

posted on 2012-06-26 09:47 顺其自然EVO 阅读(268) 评论(0)  编辑  收藏 所属分类: 测试学习专栏


只有注册用户登录后才能发表评论。


网站导航:
 
<2012年6月>
272829303112
3456789
10111213141516
17181920212223
24252627282930
1234567

导航

统计

常用链接

留言簿(55)

随笔分类

随笔档案

文章分类

文章档案

搜索

最新评论

阅读排行榜

评论排行榜