软件与测试的合作问题

[dong83615]

请问一下软件部门提交测试时需要给测试部门提供哪些文档？测试用例是谁来写？测试部门反馈给软件部反馈测试结果的时候应当有哪些要求？BUG描述有什么要求？BUG分析有什么要求？
因为现在出现了部分BUG不能重现的情况，测试部门描述BUG出现了“有时”，“偶尔”之类的用词，搞得开发人员无法判断问题，还有就是关于提交的文档方面有一些争议，大家帮帮忙，给点意见。希望测试的和开发的都说说自己的看法，还有就是规范的操作流程应该是怎样？

[bugger_money]

具体没有做过，只是在大学学习过。
开发文档，代码文档，功能文档，问题描述文档。测试用例当然是由测试部门写了。测试部门提交给软件部门时，要将测试出来的BUG描述清楚，不能带有可能有时的这样模糊的字样。而且提交的文档要规范。BUG要求就是出现社么BUG，以及是社么产生BUG的。对BUG分析要透彻明了，对产生BUG的原因做一下推测。以便开发人员在开发过程中尽量避开BUG。
这是我的一些看法。如有不正确之处，望各位前辈给与提点宝贵的经验

[sitych]

“测试部门描述BUG出现了“有时”，“偶尔”之类的用词”
要求测试人员必须能重现bug，否则开发人员无法解决

[wuye2001]

测试部门描述BUG出现了“有时”，“偶尔”之类的用词
===
让他们将场景记下来，至少步骤要说明阿
还有就是关于提交的文档方面有一些争议
＝＝＝＝
一般的公司都是测试部来写测试用例的
嗯，测试方案最好是开发人员来写，因为有些要点和测试的重点只有开发人员才是心中有数的
不过，如果测试部的明白所有的需求且吃透，也是可以自己写的

[windancer]

个人理解，黑盒测试的情况下
1.请问一下软件部门提交测试时需要给测试部门提供哪些文档？
需求描述文档

2.测试用例是谁来写？
测试员
3.测试部门反馈给软件部反馈测试结果的时候应当有哪些要求？BUG描述有什么要求？BUG分析有什么要求？

要有问题描述，工件类型，功能点，提交人，严重程度等几大因素。bug描述最好是要文字结合截图，bug分析不清楚，感觉应该是开发员的事情

4.bug交互最好还是用BUGTRACKER的工具，比如testtracker,rational clear quest等工具。
测试反馈中不允许出现可能，偶尔什么的，提交的bug描述我个人认为应该达到能够重现才能提交，当然这些会给测试人员造成一些工作上的麻烦，但是可以提供一些建议，比如测试员提供当时的测试数据以及截图等，这样可以减少开发员重现问题所花的时间

[zj101582]

[Quote=引用楼主 dong83615 的帖子:]
    请问一下软件部门提交测试时需要给测试部门提供哪些文档？测试用例是谁来写？测试部门反馈给软件部反馈测试结果的时候应当有哪些要求？BUG描述有什么要求？BUG分析有什么要求？
    因为现在出现了部分BUG不能重现的情况，测试部门描述BUG出现了“有时”，“偶尔”之类的用词，搞得开发人员无法判断问题，还有就是关于提交的文档方面有一些争议，大家帮帮忙，给点意见。希望测试的和开发的都说说自己的看法，还有就是规范的…
[/Quote]

1 请问一下软件部门提交测试时需要给测试部门提供哪些文档？
需求说明一定要的，根据这个制定测试计划，由测试经理或测试组长负责
2 测试用例是谁来写？
一般由测试人员 写
3 测试部门反馈给软件部反馈测试结果的时候应当有哪些要求？
有效的BUG报告文档（作用：1 减少开发部门的二次缺陷率 2 提高开发修改缺陷的速度 3 提高测试部门的信用度 4 增强测试和开发的协作 ）
4 BUG描述有什么要求？
大致：
精简--清晰而简短，
准确--这到底是不是一个BUG，还是用户操作失误，或者是理解错了，等等
中性语言--用中性语言描述事实，不带偏见，不用幽默或者情绪化的语言
精确--这到底是什么问题
定位--这到底是个什么样的问题，尽量缩小这个问题的范围
归纳--还有没有其他的某些地方存在这样的问题
重现--如何引发和重现这个BUG（环境，步骤，前提条件）
影响--这个BUG对客户有何影响？对测试有何影响？
调试--怎么做才可以让开发更容易修改这个BUG （跟踪，截图，日志，直接访问等）
证据--如何证明确实存在这个BUG？
5 BUG分析有什么要求？

bug分析的第一步是发现bug,推测出bug的根本原因,修正缺陷以及记录实现的具体步骤，开发人员还应该对bug进行进一步的分析。这次分析应该着眼于导致bug产生的开发情景。
分析的最后一步就是寻找一个预防类似错误的方法。这一方法不仅涉及到开发、QC工程师，还涉及到不直接负责代码编写的资深开发人员

6 不能重现的BUG
我认为： 测试人员要有重视测试环境的意思，并在Bug Report里面增加对测试环境的准确描述，特别是影响重现此Bug的那些环境因素。
Bug的Step要准确说明操作步骤。为了重现一个Bug，测试人员可能需要对几个Build进行连续跟踪、测试和定位产生这个Bug的最根本原因。
不能一一列举出无法重现的Bug发生所有原因。如果还是遇到某些严重的、却又无法重现的Bug，那么也不必惊慌，你可以按照下面的操作去查找产生Bug的原因：

1. 积极回忆Bug的症状和所有的环境因素，一丝一毫的细节都不要错过。

2. 与开发人员、DBA、系统设计人员、项目经理等一起分析那些环境因素，根据以往的经验分析影响此Bug重现的重要因素，并在相同的环境上安装同样的系统进行测试，以验证所做的猜测。

另外，对于某些无法重现、但严重程度不是很高的Bug，可以暂时只作记录、而不必花费大量的人力和物力去分析。如果下次又出现了，那么根据发生的频率再去分析是否需要跟踪此Bug。如果需要跟踪它，那么在它又出现后一定要立刻对当时的环境进行截图，如错误信息、界面、日志等。这样也利于开发人员定位、分析它，从而准确、快速地修复它。如果条件允许，测试人员应立即保护现有环境，并邀请相关的开发人员和系统分析人员一起研讨产生此问题的原因和解决方法。

7 提交的文档
《测试任务说明书》
《测试计划书》
《测试用例说明书》
《测试报告》
《测试总结报告》
《测试验收报告》
《缺陷跟踪报告》

以上是个人在测试方面的观点 ：） 如有不正确之处，望各位前辈给与提点宝贵的经验

[mengweilil]

装个bugzilla吧（mozilla.org），开源的，可惜是英文版。

大致流程就是，你测出了bug，填表，然后项目经理就分配给开发人员解决。

很多小公司招新人做测试，所以。。。。。。。

[liujinxing]

需要提供
软件需求文档
测试建议文档
等

用例当然是由测试部门编写设计

[以专业开发人员为伍]

[Quote=引用 1 楼 bugger_money 的回复:]
具体没有做过，只是在大学学习过。
开发文档，代码文档，功能文档，问题描述文档。测试用例当然是由测试部门写了。测试部门提交给软件部门时，要将测试出来的BUG描述清楚，不能带有可能有时的这样模糊的字样。而且提交的文档要规范。BUG要求就是出现社么BUG，以及是社么产生BUG的。对BUG分析要透彻明了，对产生BUG的原因做一下推测。以便开发人员在开发过程中尽量避开BUG。
这是我的一些看法。如有不正确之处，望各位前辈给与…
[/Quote]

书生气也许愿望是好的，但做法肯定容易一事无成。

[以专业开发人员为伍]

本来是“灰色”的结果，只能用“灰色”的办法解决，不能用那些强迫别人“黑白分明”的办法解决。软件有改动，应该随时可以“回归”，并且软件每天晚上可以自动被测试成百上千次。因此，人工发现的问题只能作为自动化测试编程的素材，只有自动化测试才能在发现疑难杂症时立即给出编程人员可调试的现场环境。

[以专业开发人员为伍]

我觉得测试的问题是：手工做的太多了，官僚文档太多了，文档管理辅助工具太多了，而精当的自动化测试工具一个都没有，更没有人自己动手去开发（希望天上掉馅饼出现又好又便宜的工具）。

如果一个项目有500个测试用例，每天把它们完全（以随机顺序，并且由程序自动随机地生成崭新的输入数据）跑上100遍，即执行50000个不重复的测试，并不稀奇，因为大多数bug是在某段代码反复执行多次以后才发生的。

测试，就要以自动化测试为目标，手工测试为补充手段。