我想和大家讨论一下测试部到底应该哪些工作

cobol

可以说，我对测试有着浓厚的兴趣。
原先，我们作坊式写软件，都是自己先写，然后再测，也请用户测试。随着发展，成立了测试部，我也乐意担纲此任。测试部，旨在做专业测试（从大的规划来说，除了测试代码，还要测试需求、设计，乃至工程监理）。可是，“专业”，怎么才可以专业呢？这个话题，有点大，说透太不易，必须拆分为子任务，我就想，先从测试部应该做哪些工作议起，即职责。然后再谈如何做，如何做好等进一步的问题。或者，先试着谈一下测试部的职责，开个头，再结合其他部门的职责，和测试工作如何做好。几个议题咬合进行，交替前行。

我先抛几块儿砖。
1、用户手册。应该需求或设计部门写，测试部门来测手册呢？还是由测试部门来写？
2、单元测试，由开发做，还是测试做？
3、测试部门的测试，是否要检查库表的填写（增、删、改）是否准确？
4、对”测出的问题“，是否是问题，如何判断？
5、对测试的问题，有无提出修改建议的责任？建议错了，如何处理？
6、”时隐时现“的错误，如何书写测试报告？和开发部门如何说明？
敬请赐教！

peiping790809

我以前也做软件开发，现在转到做测试，我发现当天出现的问题要及时总结，不然自己都忘了，开发会笑话的。刚成立的部门，不用把精力放到写文档，团队建设上，测试也可以先作坊式运行，等测试部门的工程师多了，在考虑团队建设。

swallow0918

1、用户手册。应该需求或设计部门写，测试部门来测手册呢？还是由测试部门来写？
一般由测试部完成。

2、单元测试，由开发做，还是测试做？
看各个公司自己的情况而定。

3、测试部门的测试，是否要检查库表的填写（增、删、改）是否准确？
需要的，数据库测试也是测试工作的一部分。

4、对”测出的问题“，是否是问题，如何判断？
一般有bug就提交，开发如有疑问大家就面对面沟通来判断是不是问题，如果还不能有结果请项目经理来最后决定。

5、对测试的问题，有无提出修改建议的责任？建议错了，如何处理？
可以提出修改建议性的bug。建议错了，bug关闭。

6、”时隐时现“的错误，如何书写测试报告？和开发部门如何说明？
对于”时隐时现“的错误，在出现错误时找开发人员过来看，从后台运行情况及日志中寻找错误发生的原因，不可以因为是”时隐时现“的错误就放过。

[ 本帖最后由 swallow0918 于 2006-6-4 16:07 编辑 ]