请大家帮我完善这个生命周期缺陷管理矩阵，谢谢！

suchboy

多提点意见 发上来，谢谢～







---------------------------------------
msn:  suchboy2008@hotmail.com

QQ:  34724600

Satery_Li

个人觉得功能测试、性能测试什么的划分到系统测试比较好，集成测试是研究系统或者子系统之间是否能正常调用的测试

xyuan007

我的意见，不一定合适啊
1、我觉得单元测试（或集成测试）时的功能测试和系统测试时的功能测试还是有一些分别的，不过笑侠说的对，分类方法不一样，功能测试和性能测试放在单元测试（或集成测试）下也可以。
2、没有用户验收测试这一块？

suchboy

补充 笑侠 的话：

单元测试、集成测试、系统测试与功能测试、性能测试的分类的依据不一样，所以是互相包含的，即单元测试中有功能测试、也有性能测试，系统测试中也有功能测试和性能测试

既然需求有评审，设计也应该评审呀，设计评审很重要的

笑游天涯侠

呵呵，你这个东西覆盖了整个生命周期的全过程，范围大，难度大，提点个人看法：
   1 前期跟踪、招投标、合同谈判这几个阶段应该不存在着缺陷管理。
   2 要对需求、设计阶段进行缺陷管理，可操作性会不强，只能通过评审来进行。
   3 需求阶段的缺陷管理，就是把用户的需求对应到软件属性的各个子特性上，通过评审看看需求说明书中的定义是否完全覆盖了用户需求和行业软件的特有需求，软件属性中的各子特性是否都在需求说明书中有所体现，未体现的，注明理由（是软件本身不需要的，还是需求调研、分析遗漏了的）。
   4 设计阶段的缺陷管理，通过评审检查设计是否考虑了用户需求对应的软件属性中的各子特性。
   5 测试阶段的缺陷管理，把测试出的bug对应到软件属性中的各子特性上，评估软件属性中那个子特性的质量差，以对开发下版本或下个软件起到借鉴。

  纯属个人看法，欢迎大家讨论。

kernzhang

我看你的矩阵哦！感觉画得很细哦！但是有几点不明白：
1。1，2，3级指的是什么概念
2。软件的生命周期你是否以上下排列来代表生命周期的每个阶段的！如果是这样，测试放的位置就正确了！那你就割裂的测试与开发的关系，就像现在很多专家在批评测试的V模型一下
3。我看了你的缺陷定义的那么的子部分验证，说实在的，你的提纲可以这么写，但是你要真正的定义出什么才是”易用性“等等标准，将可能成为你最困难的事情，我建议你可以对应比较粗一点，去关注项目的质量！比如：项目的可扩展性，实际这个下面涵盖很多的方面，如果你把这个再往下分！这将是一件很痛苦的事情！

呵呵！以上是我的看法！欢迎大家一起讨论哦

suchboy

谢谢各位的讲解， 我很有收获！

关于K版的话， 我理解测试应该在需求阶段就介入并贯穿整个软件生命周期，

但在需求调研阶段，我能想到的，也只是测试人员参与需求调研、分析而已，

然后测试人员依据需求调研写 测试用例checklist。

至于 设计阶段， 编码阶段，我不懂缺陷管理在此时段能干什么，请大家指点指点。

[ 本帖最后由 suchboy 于 2006-3-22 22:34 编辑 ]

suchboy

昨天晚上突然想到， 软件测试的一个重要过程是验证啊，为了保证测试的广度，必需要了解软件的每个属性
什么易用性、健壮性、安全性等等...而且正如 K版所说 “项目的可扩展性，实际这个下面涵盖很多的方面，如果再往下分！这将是一件很痛苦的事情！”  我已经很痛苦了，因为我不专业啊，sdlkfj 但为了保证测试的深度，这个工作是必需的啊，希望大家能帮我拆分 ：  1、 软件生命周期的具体流程，每步流程的主要任务，如笑侠上面讲了很多  。  2、 软件的必备属性，每个属性的主要特征。  这两个点非常重要啊～


任何一个物质都有其若干属性的， 必需先全部罗列，再层层剥离，直到颗粒度能由自己完全掌控，才能进行检查、分析。 功能测试也罢，性能测试也罢， 缺陷管理也罢， 面向对象的测试...都应该如此。

[ 本帖最后由 suchboy 于 2006-3-23 10:18 编辑 ]

笑游天涯侠

1 关于“软件生命周期的具体流程，每步流程的主要任务”，你可以参考书本上的软件开发的V/W/H模型。
2 你这个“生命周期缺陷管理矩阵”应该属于一个测试管理中的一个文档，对软件的属性分到这种程度就行了，到具体项目应用时，再去定义各个属性及其子特性的具体内容。因为项目不同，各软件属性的关注度也不同，一些子特性的定义也不同。

xyuan007

看了半天又想了半天，觉得SUCHBOY的意思是不是：在软件生命周期的每个阶段（EXCEL中的纵向），针对软件的各个属性所应该做的工作？
要比较详细地制定某个属性的“标准”，确实比较难，感觉无从下手，
结合我公司目前的情况，我觉得在进行需求评审时，如果能将上述的所有软件属性都提出来，让开发人员能够考虑到就已经不错了。项目结束后，大概的“标准”我们自己就有个概念了，然后在开发下一个项目时，结合上个项目的情况再适当提高一些“标准”的要求。

呵呵！以上是我的看法！欢迎大家一起讨论哦
突然发现我成了中级战友了，变成太阳了，嗯，以后要多发点光才行。