测试管理工具.pptVIP

测试管理工具 张炯 微软的管理形式 相对应的工具 PM －》需求－》SharePoints DEV －》源代码 －》Source Depot Tester －》BUG －》RAID 开发过程 规划 开发 测试 发布 BUG管理体制 在整个产品的研发过程中，特别是在测试产品、修复 Bug 的中后期，团队中所有人都生活在 Raid中。 测试人员（Tester）只要发现问题就立即新建一个 Bug 予以跟踪并指派给相关的开发小组长（DevLead） 开发小组长会判断这个Bug 属于某个特定的开发人员（Dev）并指派给他处理 BUG管理体制 开发人员会根据 Bug 的详细描述信息找到问题所在，修改程序解决这个 Bug 并把 Bug返回给当初的测试人员；或者有争议的时候，把Bug 指派给这个 Feature 的定义者PM，要求一个澄清说明 测试人员在看到某个 Bug被解决后，就去验证这个Bug 是否真的不存在了，根据最初的发现步骤去证实问题真的解决了就关闭这个Bug；若还能重现，或者不同意开发人员的解法，可以激活这个 Bug，返还给当初的开发人员做进一步调查处理 BUG管理体制 当测试人员和开发人员无法达成一致意见的时候，由对应的PM出面做协调，判断这个Bug的严重程度、对用户可能的影响，根据产品的进度和项目资源做出评估，是否真的需要修理掉这个问题 管理团队利用Raid 来跟踪整个进度：单个人的工作、小组的进度，整个产品研发进度研发队伍中的所有人都通过 Raid 来商议、沟通某个 Bug 是否符合当前解决 Bug 程度，决定是否需要真正修理掉这个 Bug、如何修理、可能的副作用、如何测试其解决方案等等。 BUG管理体制 每月、每周甚至每天，参与这个产品研发的人都收到一封当前 Bug 状态的Email：每个人都上有多少Bug，Dev、PM、Tester头上Bug 数最多的前 5 名都是谁，哪个子产品、子模块中的问题还是处于上升阶段，整个 Bug 的趋势怎么样等等。这是最详尽的产品状况,暴露在团队中每个成员的面前，一览无遗。只要你的名字被列在 Email 中，你就非常紧张，因为你脑袋上的 Bug 比较多、影响整个产品的质量。 Everything should be tracked in RAID! 软件运行环境 BUGfree 基于php＋mysql 软件运行 1 建立测试 2 建立用户 3 测试流程 * * *