公司要内部培训TD,现在有这些问题,希望大家帮忙解决下,谢谢了!

Sunny瞳瞳

1.测试需求谁写，谁审批，

    2.测试用例谁写，
   
    3.design,ready,import,repair这几个状态代表什么意思？

    4.缺陷跟踪，开发人员关注哪几个状态?
                      测试人员关注哪几个状态?
       流程如何?

maxhoo8003

首先你要出关于TD 使用的操作手册 为开发人员编写
1 定义了开发人员TD的操作权限比如没有CLOSE权限
2 缺陷状态变更了开发人员必须添加注释等
3 自己定义了缺陷种类和严重程度 和测试计划里面的种类，严重度，优先级别一致
4 作为测试人员你能够熟练的配置TD操作页面
5 。。。等太多 可加我QQ 48860970 讨论测试
其次你要写为什么要普及TD 的推广计划
TD这东西你可以装个虚拟机自己不总结，用多了你自然就

xueyun

1. 测试需求一般由测试经理写（经过与开发、设计主要人员讨论而定），由项目经理、设计、开发组长review

2. 测试用例如果有测试组自然是测试组写，如果没有就是开发人员写，还要看是哪类程序，有些系统是需要设计人员来写用例的。

3. design,ready,import,repair这几个状态主要作用用于统计，比如领导要看现在一共有哪些用例、哪些各在什么状态，还有在统计报告、图表时可以根据需要对这些字段进行过滤。对于没这种需求的这些状态是没用的（我们项目没管这个）。design表示仍处于设计状态还未完成,ready表示已经完成设计可以用于测试,import表示是导入的,repair表示是修正过的。

4. 缺陷跟踪：
新增的缺陷状态为new，开发人员每天打开缺陷管理工具，检查bug状态为open或reopen并且属于自己的缺陷，如果的确是bug的话，对其进行修改，修改完成后，将它的状态修改为fixed(已修改)，如果这条bug提重复或者不是bug时，将它的状态改为Rejected（拒绝），如果认为bug在这次版本中不需要修改，需要延期的，将它的状态改为deferred(延期)；开发负责人或测试负责人每天打开缺陷管理工具，检查是否有bug状态为rejected或deferred的缺陷，确认这些bug是否真的要延期或拒绝修改，如果认为开发人员的理由合理，将rejected的bug状态修改为closed，将deferred的bug状态不进行修改，如果认为开发人员的理由不合理，将rejected和deferred的bug状态修改为reopen；测试人员每天在TD中提交新的bug，并在新的版本中确认bug状态为fixed的bug，如果fixed的bug已被修改，将其状态置为closed，如果fixed的bug没有被修改，将其状态置为reopen。

附件是我为我们项目规范写的缺陷状态变化流程及各方关注点

其实在TD自带的demo项目里不同类型的人员可以看到的缺陷及缺陷的改变状态都是不一样的，你可以到这个项目里去看看，试验一下。

yelo

楼上讲的挺好的

yuyu2000

我们的测试需求和测试用列是由测试人员编制,然后测试经理核查,最后由需求人员审核;
那几个状态我也没有研究过,呵呵
至于测试和开发关心什么状态,其实状态是依你们自己实际情况而定的,
开发组长关心new状态,分析并分配任务open,若没有问题就是d_noproblem或者不实现d__unfix;
然后开发人员开始修复,完成修复fixed,
配管更新测试环境updated,
测试人员开始回测BUG,测试通过closed,不通过reopen;同时还要对开发组长提出的没有问题和不实现的d_noproblem和d__unfix的进行确认,如果确认是问题提交需求裁决review
反正我们的流程是设置的比较复杂,并且比较适合实际开发情况;上面说的是主要步骤,

jy00274486

我最近也要给公司内部人员做这个培训,想问下大家有什么建议吗??我还菜的很

tongke

上面的问题主要是每个公司流程不同,其解决方法也不同的..