|
注:已经将个人的QQ号屏蔽掉~此外尊重知识产权,因此保留昵称^_^
2005-10-31 14:24:33 Nokia(1)
一个人如何规范公司测试流程?越简单越适用越好,谢谢
2005-10-31 14:25:27 wwwmagic(2)
一个人?[表情]
2005-10-31 14:25:45 Nokia(1)
是的。越简单适用越好,谢谢
2005-10-31 14:28:37 wwwmagic(2)
是不是公司就你一个人负责测试?
2005-10-31 14:29:09 Nokia(1)
是的。
2005-10-31 14:30:41 wwwmagic(2)
那意味着你得身兼数职了?
2005-10-31 14:31:16 Nokia(1)
是的,很多。
2005-10-31 14:31:34 悦儿(3)
我认为最重要的就是管理好测试报告了,也就是bug的管理
2005-10-31 14:31:47 wwwmagic(2)
错。
2005-10-31 14:32:35 wwwmagic(2)
首先既然我们做测试,就需要正确的定位测试。
2005-10-31 14:33:26 悦儿(3)
关于测试的定位要根据公司的情况来定
2005-10-31 14:33:35 wwwmagic(2)
如果大家对软件工程有些了解的话,就可以找到测试的位置。
2005-10-31 14:33:43 悦儿(3)
不是可以硬搬
2005-10-31 14:33:55 Nokia(1)
书本上的东西有时不适合具体工作。
2005-10-31 14:33:59 悦儿(3)
对
2005-10-31 14:34:00 wwwmagic(2)
先听我说完。
2005-10-31 14:34:13 悦儿(3)
书本上的不能全搬
2005-10-31 14:35:55 wwwmagic(2)
你所说的那些规则、流程是从哪里来的,都是从书本上来的。书本上的东西又是从哪儿来的,还不是大家从实践中得出的。
2005-10-31 14:37:31 wwwmagic(2)
你不可能离开前辈们的足迹自己独创一套规则,那样无法成其为标准。软件行业中,标准就是一门公共语言,大家都能明白。
2005-10-31 14:40:43 wwwmagic(2)
也有很多公司,会根据自身的情况对标准的流程做一些变通,但不会偏离太远,记得我开始应聘的一家公司,开始由于对一些软件标准不太重视,结果和安全部打交道的时候,所有的材料都给退回来了。从那以后,脚踏实地的按照国家标准来做了。
2005-10-31 14:42:11 wwwmagic(2)
所以,我还是建议大家尽管可以或者允许我们自定义一些规则和流程,但是有一定的限度,也就是有一定的作用域。
2005-10-31 14:43:09 wwwmagic(2)
如果你想让你的想法能为大多数人接受,你必须首先能接受大多数人的想法。
2005-10-31 14:44:01 wwwmagic(2)
而书正是描述了大多数人的想法。
2005-10-31 14:44:28 wwwmagic(2)
下面归入正题。
2005-10-31 14:46:14 wwwmagic(2)
1、如果大家还没有接触过软件工程的话,建议首先了解它。了解它,就等于找到了测试的家谱。
2、测试在整个软件开发过程中不是主动发起的,而是由需求驱动的,这和软件开发是同宗同源的。一句话都是为客户服务的。
3、既然都是由需求驱动的,意味着我们的测试过程和开发过程是一对孪生兄弟。我们的过程是相铺相成的。
4、虽然和开发过程类似,但是,测试在不同的阶段的服务对象会有所不同。这点和开发过程也很类似。以下举例说明。
在客户提供了需求之后,这时候会由需求分析人员整理出业务用例。
这个业务用例可能需要用图表示出来,也可能只是语言描述。
2005-10-31 14:55:55 Nokia(1)
不好意思打断一下,能不能简单说明一下测试流程:如测试计划-测试的执行-测试报告-测试缺陷跟踪,这样是不是适合一个人的测试规范?
2005-10-31 14:56:01 wwwmagic(2)
对应这个业务用例,测试部门需要测试其是否符合需求。这是测试过程的第一步。
2005-10-31 14:56:49 wwwmagic(2)
当然可以啦。所以刚才我问你是不是一个人负责所有的业务。
2005-10-31 14:57:10 Nokia(1)
基本是所谓的“全能”。。。。。[表情]
2005-10-31 14:57:16 悦儿(3)
嘿嘿,如果没有人整理业务用例呢?
2005-10-31 14:57:54 wwwmagic(2)
如果是你一个人的话,你就得自己撰写测试需求、测试方案、测试用例、测试报告了。
2005-10-31 14:58:28 Nokia(1)
需求不用写了,直接是计划-执行-报告-跟踪了。需求是从开发那里找来的。
2005-10-31 14:58:30 悦儿(3)
对了,能不能解释一下,测试需求的含义?
2005-10-31 14:58:41 wwwmagic(2)
一般情况下,会由测试组长来撰写测试方案和测试计划。
2005-10-31 14:58:47 Nokia(1)
帮助文档还有用户手册都是我自己编写的。
2005-10-31 14:59:48 wwwmagic(2)
实际上不应该是你们写。但人手少的时候只能你们写。
2005-10-31 15:00:14 Nokia(1)
等等再问他,能不能接着刚才的话题说完,你说到业务用例了,wwwmagic
2005-10-31 15:00:22 wwwmagic(2)
再解释测试需求。
说到测试需求,实际上很多公司并不注意这个。
2005-10-31 15:00:57 微微(4)
还是公司有测试小组会比较有地位,在开发组没什么权利,主要看自己了。
2005-10-31 15:01:27 秋天(5)
要是做测试,公司就用一个人来做
说明公司规模还不是很大
所以压力也还可以了
我本来是来公司做测试的
可是现在有一个项目出问题了
开发人员请假回家了,要我来改
我才觉得压力大呢,什么都不会呀
2005-10-31 15:01:51 wwwmagic(2)
一个很明显的例子就是,在和客户讨论需求的时候,一般的公司很少要求测试人员参加。
这无论是在理论和实际工作中都是非常荒唐的。
因此,在整理测试需求时,不少的测试人员不得不向开发人员打听。
有时造成以讹传讹。非常浪费资源。
2005-10-31 15:04:11 微微(4)
只要公司重视测试就不会产生这些问题了
2005-10-31 15:04:32 wwwmagic(2)
正常的情况下,在和客户讨论需求时,至少应该有一名测试代表列席。
由他产生的报告就是测试需求的来源。
当然,他的理解是以客户的提供的需求为根本。开发也是这样。
然后,测试组会根据他们的理解,对开发提供的业务用例进行测试,这就是测试过程的第一步。
接下来,开发会继续他们的概要设计、详细设计,代码编写,测试部门则编写他们的测试用例。
上面略去测试方案和测试计划。
等开发完成他们的代码后,测试人员便开始介入其中,这个过程会视具体项目而定。
有些项目比较大,测试会分段介入,项目如果比较小,则在开发完成单元测试之后,测试就可以介入。
很多人对尤其是很多开发人员很不看重测试。
所以才造就了一堆垃圾代码和一个不健壮的系统。测试人员孜孜以求,任人是非,目标只有一个,你手上的系统是否符合你们的测试代表当初提供给你们的需求。
在对开发提供的程序进行测试时,一般是先功能测试、再性能测试,先单元测试,再集成测试。至于用什么测试工具,大家比我清楚。
等测试通过之后,一般来说,还有一个用户验收测试,这个测试是由我们的测试人员与用户共同完成的。根据就是用户签字的那份需求。如果满足那个需求,就算测试通过,如果不满足,就得打回再来。
2005-10-31 15:19:50 ⺗地乆⺌兲伥(6)
wwwmagic(2) 15:10:42
有些项目比较大,测试会分段介入,项目如果比较小,则在开发完成单元测试之后,测试就可以介入。
wwwmagic(2) 15:16:24
在对开发提供的程序进行测试时,一般是先功能测试、再性能测试,先单元测试,再集成测试。至于用什么测试工具,大家比我清楚。
这2个可能有点问题
2005-10-31 15:20:36 冰河(7)
测试介入时间太晚
2005-10-31 15:20:40 ⺗地乆⺌兲伥(6)
恩
2005-10-31 15:20:46 冰河(7)
测试分阶段进入是什么意思啊?
2005-10-31 15:21:02 Nokia(1)
可他说的这种情况在很多公司都有这个现象。
2005-10-31 15:21:37 wwwmagic(2)
测试介入时间会视具体项目而定。实际上很多项目测试到最后阶段才介入。
2005-10-31 15:21:40 ⺗地乆⺌兲伥(6)
如果有比较成型的测试或者质量控制部门,最起码的评审工作应该是有的
2005-10-31 15:22:07 冰河(7)
需求评审和用例评审都不可少
如果缺少了这两步,风险会很大!
不管什么项目都是这样的!
2005-10-31 15:22:42 ⺗地乆⺌兲伥(6)
那就是测试人员的问题了,无论如何在概要设计和详细设计阶段都应该进行评审
否则会发现最后出来的产品和原来想的完全不一样
2005-10-31 15:22:44 松oоО(8)
像我们专们分为测试部,还是产品组中的测试
2005-10-31 15:24:05 wwwmagic(2)
产品组中的测试实际上只是模拟用户测试而已。不能说是一个独立的测试过程。
2005-10-31 15:24:54 松oоО(8)
对的,
2005-10-31 15:25:10 冰河(7)
你们这样的情况,在测试过程中设定合适的测试里程碑比较合适!
这样效果会很好点
2005-10-31 15:25:18 松oоО(8)
主要在集成中测试部才全面的介入
2005-10-31 15:25:51 wwwmagic(2)
一般的公司都这样,所以测试的意义不是特别大了。
2005-10-31 15:26:15 Nokia(1)
要靠自己让它的意义变大。
2005-10-31 15:27:24 wwwmagic(2)
大家如果对质量控制有感觉的话,应该知道事后控制比事前控制难得多。
2005-10-31 15:27:48 冰河(7)
测试的重要意义倒不太看重测试什么时候介入项目,而看的是测试过程总的方法和测试对质量的全面影响!
2005-10-31 15:27:53 松oоО(8)
因为在单元,及联条测试阶段,主要测试的还是功能测试,是否符合需求设计,产品组中的测试人员就可以了,测试部一般会在单元,联条阶段进行验收
2005-10-31 15:29:40 松oоО(8)
在进入集成后,测试部就会组织重点进行项目测试, |
|