测试流程

lovetesting52

规范的测试流程：
第一步：制定测试计划。该计划被审批后转向第二步。
第二步：设计测试用例。该用例被审批后转向第三步。
第三步：如果满足“启动准则”，那么执行测试。
第四步：撰写测试报告。
第五步：消除缺陷。如果满足“完成准则”，那么正常结束测试。

本人抛砖引玉，请大家讨论一下各自公司的测试流程。这是我第一次发贴，请大家多多支持哦！谢谢

lovetesting52

自己先顶一下，欢迎大家踊跃讨论。先说说我第一家公司的测试流程吧。我的第一家公司是规模很小的私企，技术总监是刚留学回来的，管理方面做的不是很到位。那时我刚培训测试出来，在公司主要是做网站测试，那时是一个产品刚做出来就让我们开始测试，开发人员根本就没有做过单位测试，也没有需求文档，据说是市场有什么样的需求开发就新增那方面的功能。这样的产品不用想都可以知道是怎么样的。所有我们做测试的就天天马不停蹄的提缺陷，遇到不明白的地方领导就让问开发人员去，这样就导致一些本事问题的问题变得不是问题了，而且有些开发人员说话挺牛的，说的不好听就是“测试的是吃饱撑着了，没事找事做”。感觉那时挺郁闷的，但是我们也没办法改变。如果领导要看用例的话我们就立马开始写用例。我们测试人员辛苦提了几百个bugs放了半个月甚至一月都没有人处理，最后再我们再三要求下领导给话了，要求开发人员在一个星期内把所有的bug处理掉。所有测试是没有启动和结束标准的，当然测试也很不规范。现在所在的公司还是挺规范的，基本上做到了测试流程中的5点。感觉挺幸运的，所以现在要加油好好干，相信以后测试的前途会越来越好！付出就会有收获的。

david.wang

哈哈，
中国现阶段，应该有自己特色的软件测试流程，特别是中小企业。
首先测试用例在测试的时候根本就不能知道测试，大部分都是测试完了后补上的。
其次测试计划都是不定的，基本上都没有测试计划，都是跟着项目的时间定的。

65138935

理论上的测试流程都描述得不错
但是实际中真正能完整的执行这样的测试流程是做不到的，不规范

lovetesting52

是呀，中国的很多公司测试都很不规范，所有很多时候测试人员就没有开发员吃香。曾经去一个公司要5k的工资，那个经理竟然说什么怎么测试人员的工资还比开发的高，当场就晕。不过我现在的公司还是挺规范的，规模稍微大的测试都必须先写测试计划。不过个人觉得测试计划似乎都是给别人看的，

[ 本帖最后由 lovetesting52 于 2008-7-23 15:06 编辑 ]

shll0513

我还没找到工作呢，不过想好找软件测试方面的，希望以后能找到个正规的公司，好好发展，感觉以后的测试应该会比较重要

月上百合

实际工作中,和理论流程有出入

xqs_dl

写的很好    现实中不是这么规范

耗子砍猫

我们是这样的:
审核需求和设计(测试计划编写与潜在风险评估和风险规避办法)—〉设计测试(测试用例设计)—〉实施运行测试(维护测试用例和写测试报告)
审核需求包括：
（1）由PM根据用户要求（信息来源于市场部门，用户支持部门、游戏设计部门、美术部门、程序部门等等）而编写的需求文本（Requirement   Specification）和测试计划；
（2）由Team Leader根据需求文本和开发团队(游戏设计、美术、程序)提供的游戏设计文本(Design Doc)编写（Functional Design  Specification）,定义测试重点和用例的编写重点；
（3）由Test CaseOwner根据功能文本而编写测试用例实施设计文本（Implementation Design  Specification）并完成测试用例设计,一般设计两套用例;一套只检查基本功能,另一套检查内容详细,从端到端,点到点都不放过,极其苛刻,尽可能做到最大覆盖。

对这些文件的管理与调配,TL完成功能设计文本,通过邮件发送给PM,并抄送手下组员,目的让大家了解这个Mliestone测试重点和相关测试功能模块PM对功能设计文本进行审核,并与设计团队和开发团队一起会审,评审所写的所有Case。发现问题或者有不清楚的地方,进行Review动作。一般一个用例从设计到最后被确定使用,会经过2~4次Review。

测试人员也要参与所有这些文本的审核,主要是与开发沟通,和成员内部进行交叉评审。作为测试人员，审核重点是检查文本对用户需求定义的完整性、严密性和功能设计的可测性。同时这种审核对于测试人员也是一种热身活动。

2、当确定下测试用例后,定义优先级,用例的分配(分配到测试小组),由每个组的TL放入专门服务器,PM设置访问权限和修改权限,由PM统一管理,测试开始时会依据测试进度分发Case。

Mliestone开始之前,会召集所有测试人员进行战前部署,告诉大家这次测试的功能模块,自动化的测试、性能都会涉及。让每一个测试人员清晰了解测试的功能模块有哪些,需要注意什么,等等。

3、实施运行测试是最长最复杂的一个阶段。就是将上一步设计的测试用例按计划付诸实施的过程。这包括编写自动化测试脚本、反复运行自动化测试脚本，也包括阶段性执行手动测试用例。在Mliestone中,自动化测试和性能测试与手动测试同时进行,自动化测试这里有一点要特别指出，有很多测试用例是要反复运行的，特别是基本的自动化测试每一天，每一个Build上都要运行。尽管这些测试大多数情况下都是通过的，很少再发现新的Bug，就是为了防止质量回归。

另外,非自动化的测试用例要进行维护,非常烦琐的工作,比如通常以下两种情况下要新增一些测试用例，一是对于当初测试设计不周全的领域，二是对于外部的Bug（比如从客户报告来的,客户也会参与我们的测试），没有被现有测试用例所覆盖。当产品的功能设计出现更改时，所涉及的测试用例当然也要相应地修改。

我们还有一种特殊的方法,就是每个Milestone的末期,测试的任务已经完成95%,会组织一次大的Bug大扫除工作,所有的测试人员(包括测试管理人员),开发团队,甚至BOSS,都会参与其中,不使用任何用例,完全凭个人自由发挥,看谁找的BUG多对于发现严重BUG最多和严重等级的人给予奖励,这种大扫除一般持续2~3天,这种大扫除应该是对里程碑测试的补测,,这种大扫除测试是交叉测试的,每个人测试自己没测试过的功能模块,就是为了发挥主观能动性和集思广益。。

里程碑测试的同时,开发会查看我们上报的BUG,并开始修复,一般在里程碑测试完毕后,会出一个Build,告诉哪些修复了,我们会进行回归测试,对于一个里程碑里发现的所有BUG,不会在里程碑彻底结束前还保留,也就是说里程碑彻底结束后,我们在Milestone里的BUG都应该是修复状态,对于没修复的,有设计变动的,或者是有争议的,会进行3方会审,参与的人员有PM (PM和开发一起)、测试经理和测试人员、我们的客户也参与;审核这个BUG:1、是否接受?2、BUG的严重等级和优先级?3、处理意见和建议,以及交由哪个开发人,处理方式的建议等等。

当Milestone结束后,我们会对此次Milestone测试的过程中不完善的地方,已经做好的地方进行评估,让每个测试人员说自己在期间的感受和看到不足的地方,并加以筛选和改进,对于一些好的测试方法和技巧,会写成文档,记录进入知识库。

我们是游戏公司,其他游戏公司测试的流程不知道和我们是不是接近,有做游戏测试的吗,欢迎来讨论指教?

[ 本帖最后由 耗子砍猫 于 2008-10-15 21:08 编辑 ]

7842

怎么测试啊
用什么测试啊

翔少奶奶.orz

zlpxm

写了好多，我简单的写下我们公司的测试流程哈
1、需求分析
2、测试计划
3、测试用例
4、提交bug
5、回归bug
6、测试总结
哈哈，很简单吧，不过把主要的测试工作都罗列进去了。很多都是细动作，大家自己体会，根据自己公司的现状和具体情况而定

hiphop_c

那么测试过程又是怎么样的呢，流程和过程有什么区别？

liuhai0921

wtm1000

我的公司是一个小的公司，现在测试流程还不完善。我们一般在项目的中后期介入，而且时间不怎么足，这样就造成，我们只写测试用例，及bug的提交和跟踪等。就我本人感觉，不写测试计划，并不影响测试工作。

千里

那是最基本的一个流程，也是最适合于小公司的一个流程。

千里

原帖由 lovetesting52 于 2008-7-21 16:07 发表
规范的测试流程：
第一步：制定测试计划。该计划被审批后转向第二步。
第二步：设计测试用例。该用例被审批后转向第三步。
第三步：如果满足“启动准则”，那么执行测试。
第四步：撰写测试报告。
第五步：消除 ...

消除BUG应该在测试报告之前吧，难不成测试报告都写完了，反而那些BUG还没消除？
我写的测试流程只有四步，也就是楼主中第四步和第五步合并起来。
这不能说是规范，只是流程中间的一种。