5,177
社区成员
发帖
与我相关
我的任务
分享请发表友善的回复…
发表回复
骷髅罗王 2003-09-08
- 打赏
- 举报
对啊，比如lotes notes
willie 2003-09-08
- 打赏
- 举报
web版对中文支持不是太好了，web版登陆后使用中文容易出现乱码!!
还是客户端登陆比较好！
还是客户端登陆比较好！
LiwuxLiang 2003-09-05
- 打赏
- 举报
test track pro
支持b/s(cool!), c/s 模式
自定义角色
自定义流程（cool!）
filter(cool!)
report(cool!)
email通知（cool! cool!）
非常用户友好。
这家伙本身就是一个经典范例，研究他的过程中，你会得到很多关于设计的inspiration.
也会得到关于测试流程的许多inspiration.
支持b/s(cool!), c/s 模式
自定义角色
自定义流程（cool!）
filter(cool!)
report(cool!)
email通知（cool! cool!）
非常用户友好。
这家伙本身就是一个经典范例，研究他的过程中，你会得到很多关于设计的inspiration.
也会得到关于测试流程的许多inspiration.
glb1223 2003-09-05
- 打赏
- 举报
现在有testtrack的web版，功能强大,很好用的,大家可以试一试.
willie 2003-09-05
- 打赏
- 举报
我们用的是test track,功能很强大。
很不错
很不错
dodowei 2003-09-04
- 打赏
- 举报
看了两位的回复，明白了好多，很感谢，不过本公司现在着方面太欠缺，我经验也不够，所以需要更多的向大家学习。
termite 2003-09-03
- 打赏
- 举报
如果大一点的公司，会将缺陷管理升华为变更管理，这样不仅可以记录1.3.0在1.2.3基础上修改了什么bug，也记录了新增加了什么功能，什么功能做了改变，等等。
yes! what has been done in my company by scm.
yes! what has been done in my company by scm.
termite 2003-09-03
- 打赏
- 举报
bugzilla
白虹李李 2003-09-03
- 打赏
- 举报
我也是新手，大家一起学习吧
缺陷管理是变更管理中的一种，也就是说缺陷是变更（原因）的一种。主要是确保每一个缺陷都记录在案，并按照流程进行了正确的处理（流程大多一样，但各个公司根据实际情况有区别），最重要的是流程而不是工具。也就是说如果有好的流程，就算用纸来记录和传递bug，也许还是比坏的流程而使用好的缺陷管理工具好。
缺陷管理中把缺陷的生命周期分为不同的状态，并且标识每种状态之间的合法活动（类似状态机）。缺陷管理工具确保状态与状态间必须按照合法的流程进行变更（例如测试人员提出了一个缺陷，是不允许相应开发人员自己关闭的，必须要返回验证）；并且通过结合一套邮件工具，自动的在某人处理完毕后向下一处理人发出通知；缺陷管理通常也意味着提供了各种报表功能。
不算ClearQuest的话我只用过bugzilla。
至于什么是好的缺陷管理，关键是这套流程适合你的公司的规模和开发的规模。将投入和产出平衡到一个好的平衡点，如果流程太复杂，开发人员和测试人员会怨声载道，大家会把流程作为一个形式，试图去避免它，进行私下交易。太简单的流程就更是走形式了，你翻看原来的记录，发现什么都没有记录下来，也不清楚是否都解决清楚了。
单纯的缺陷管理是不够的，通常必须结合版本控制，这样才清楚版本1.2.1是在1.2.0的基础上修改了那些bug。避免小公司由于新员工的进入，测试人员反复的发现去年新员工进来时发现的bug（就算开发人员300-400的公司也同样发现这个问题，我可是亲眼看到的）。
如果大一点的公司，会将缺陷管理升华为变更管理，这样不仅可以记录1.3.0在1.2.3基础上修改了什么bug，也记录了新增加了什么功能，什么功能做了改变，等等。变更管理==记录任何变更。
缺陷管理是变更管理中的一种，也就是说缺陷是变更（原因）的一种。主要是确保每一个缺陷都记录在案，并按照流程进行了正确的处理（流程大多一样，但各个公司根据实际情况有区别），最重要的是流程而不是工具。也就是说如果有好的流程，就算用纸来记录和传递bug，也许还是比坏的流程而使用好的缺陷管理工具好。
缺陷管理中把缺陷的生命周期分为不同的状态，并且标识每种状态之间的合法活动（类似状态机）。缺陷管理工具确保状态与状态间必须按照合法的流程进行变更（例如测试人员提出了一个缺陷，是不允许相应开发人员自己关闭的，必须要返回验证）；并且通过结合一套邮件工具，自动的在某人处理完毕后向下一处理人发出通知；缺陷管理通常也意味着提供了各种报表功能。
不算ClearQuest的话我只用过bugzilla。
至于什么是好的缺陷管理，关键是这套流程适合你的公司的规模和开发的规模。将投入和产出平衡到一个好的平衡点，如果流程太复杂，开发人员和测试人员会怨声载道，大家会把流程作为一个形式，试图去避免它，进行私下交易。太简单的流程就更是走形式了，你翻看原来的记录，发现什么都没有记录下来，也不清楚是否都解决清楚了。
单纯的缺陷管理是不够的，通常必须结合版本控制，这样才清楚版本1.2.1是在1.2.0的基础上修改了那些bug。避免小公司由于新员工的进入，测试人员反复的发现去年新员工进来时发现的bug（就算开发人员300-400的公司也同样发现这个问题，我可是亲眼看到的）。
如果大一点的公司，会将缺陷管理升华为变更管理，这样不仅可以记录1.3.0在1.2.3基础上修改了什么bug，也记录了新增加了什么功能，什么功能做了改变，等等。变更管理==记录任何变更。
dodowei 2003-09-02
- 打赏
- 举报
怎么没有人回答我啊？大家帮帮忙拉
