dblfl 发表于 2005-8-8 13:02:27

楼上说的没错！顶一下！

海的女儿 发表于 2005-8-30 09:56:29

测试人员参与阶段评审有两个用途：一方面提前熟悉系统，为接下来的系统测试打基础；另一方面，力所能及地发现问题，并提出自己的观点。主要还应该是前者。如果公司安排测试人员做单元测试、集成测试的话，那么在需求、设计等阶段评审中就要下番功夫了！

sho166 发表于 2005-9-14 17:32:33

测试人员只参见需求评审是不够的。一个项目的需求是何其复杂，靠4、5 个小时或2、3 天来让测试人员了解需求，未免太粗糙了。会议形式本来效率就不高，很多人听到1个小时的会议就会疲倦，不想问题了，更何况讲需求的老兄就更加累了，希望快点讲完的心理就很明显了。
关键是大家要参与到需求调研与需求分析中去。那样一点点的理解。评审会议只是一个礼仪上的形式，所谓的“过”一遍，就是看一遍。看大家最后还存在什么理解上的分歧，理解上的误点。
评审就是按系统操作上的一个“确认”而已。

pride 发表于 2006-4-11 16:25:37

opinion

评审会议只是一个礼仪上的形式，所谓的“过”一遍，就是看一遍。看大家最后还存在什么理解上的分歧，理解上的误点


自己以前曾参与过几次评审，评审别人与被评审，
个人以为在评审过程中主要还是关心的这个过程，
在被评审时，
当自己在叙述自己的代码思路是是一个很好的再次思考和回顾的过程，
自己在叙述代码时会发现很多缺陷，
而且都是深层次的。
当自己转作、qa时发现，
去评审自己的角度变了，
会变成一个挑剔的客户，
这可以让自己的测试策略上升一个大台阶。
能了解客户真正想要的！！

songfun 发表于 2006-7-24 19:52:45

首先要搞清楚为什么要评审？

举一个很简单的生活的例子吧。容易理解。
A-B 地理上2个位置，我们现在在B上班，
A是一家餐厅，A到B 600米，现在我们下班了，打算去那边吃饭——而且我们饿昏了，恨不得早点过去吃饭。
我设计的方案是：打的 到A吃饭。

大家没有评审，我们就这么去了，结果发现路上塞车非常严重，堵了20分钟还没到。最后受不了了，付了打的费，半路上 下车，走过去吃饭。白花7元钱。

结果当然有点郁闷。

但是如果我当初提这个方案的时候，你们几个参与了评审，当时楼主指出，A到B这条路 一向堵车严重，尤其下班这个时候，还是走过去比较好。于是经过大家的一致确认，我们步行过去，果然10分钟不到就抵达餐厅了。少花了冤枉钱，还早吃到饭。


这就是评审带来的作用和效果。

luoyear 发表于 2006-7-25 18:14:16

原帖由 songfun 于 2006-7-24 19:52 发表
举一个很简单的生活的例子吧。容易理解。
A-B 地理上2个位置，我们现在在B上班，
A是一家餐厅，A到B 600米，现在我们下班了，打算去那边吃饭——而且我们饿昏了，恨不得早点过去吃饭。
我设计的方案是：打的 到 ...

精辟

欣欣 发表于 2006-7-26 10:28:39

原帖由 海的女儿 于 2005-8-30 09:56 发表
测试人员参与阶段评审有两个用途：一方面提前熟悉系统，为接下来的系统测试打基础；另一方面，力所能及地发现问题，并提出自己的观点。主要还应该是前者。如果公司安排测试人员做单元测试、集成测试的话，那么在 ...


很同意这个说法！我们公司也要对《详细设计说明书》进行评审了，参与的人员可不只是测试，还有设计和开发sdlkfj2

loug 发表于 2006-7-28 18:29:45

其实大家也不要一味地贬低测试人员，认为参加评审是浪费时间。如果是行业软件，测试人员（老员工）参与过此行业的软件测试，在评审中同样可以从业务需求方面去评审。另外就算是新接触这个软件，在学习文档的过程中，也可以对文档的需求描述是否合理易懂去评审，需求和设计文档是为以后阶段作指导，如果文档描述不清晰，让人看不懂，在以后阶段中个人的理解不一样就麻烦了。其实这个问题在评审中就可以很好的解决，大家对文档中有什么看不懂的，就可以让作者解说。
页: 1 [2]
查看完整版本: 如何评审？？？