开发团队关于测试的两个问题

刚才旁听一个组建时间不长的开发团队的周例会，团队大致有20多人，分多个小组，注意到了两个问题：
1、指定几位开发人员作为测试人员：
由于暂时没有专业的测试人员，指定了几个对业务熟练的开发人员（或小组长）做测试，测试结果提交TD。对于业务复杂的庞大系统，在模块开发阶段没有专业测试人员的情况下，我比较倾向这种方式。
2、开发过程中的测试数据准备：
记得以前模块开发过程中，对于junit单元测试所用数据，是自己创建、自己应用、自己删除的；
在通过界面测系统模块功能时，则没有什么规则，经常会发生甲做了一批测试数据，今天测了一部份，明天数据就被乙删掉了的情况，测试数据相护使用。
我在想在一个团队里有多个小组如何合理有效的建立模块测试数据：创建数据不做重复劳动，数据可充分“复用”、“共享”、不产生冲突。单独成立一个测试数据构造组？是不是有点投入过大？

评论

20 楼 wufan0023 2008-03-17  

越是熟悉逻辑往往越无法测试出来什么结果。测试人员站的角度和开发的不同才能看出bug。

19 楼 deadcode 2008-03-09  

感觉可以使用一些自动化的测试工具来解决楼主的问题

测试的第一部是准备测试数据，比如先清空目标数据库，用脚本初始化测试数据，
然后再运行test case。

18 楼 jimmy_c 2008-03-06  

hyhongyong 写道

测试数据的复用还不好不复用，毕竟造数据不算个事，但维护数据就成本高了，没有必要！

cvs一下成本很高么？
对于很多应用来说，造数据并不容易。
对于很多test case来说，不同的数据就代表了不同的边界测试和异常测试。
保存下曾经出错的数据，定期重复测试就意味着Regression Test。

17 楼 hyhongyong 2008-03-06  

测试数据的复用还不好不复用，毕竟造数据不算个事，但维护数据就成本高了，没有必要！

16 楼 jimmy_c 2008-03-06  

banner 写道

刚才旁听一个组建时间不长的开发团队的周例会，团队大致有20多人，分多个小组，注意到了两个问题：
1、指定几位开发人员作为测试人员：
由于暂时没有专业的测试人员，指定了几个对业务熟练的开发人员（或小组长）做测试，测试结果提交TD。对于业务复杂的庞大系统，在模块开发阶段没有专业测试人员的情况下，我比较倾向这种方式。不应该由业务熟练的开发人员（或小组长）来操作，反倒应该是不太熟练的人做更合适，组长的责任应该是控制进度，最好另外找一个人写test case
2、开发过程中的测试数据准备：
记得以前模块开发过程中，对于junit单元测试所用数据，是自己创建、自己应用、自己删除的；
在通过界面测系统模块功能时，则没有什么规则，经常会发生甲做了一批测试数据，今天测了一部份，明天数据就被乙删掉了的情况，测试数据相护使用。
我在想在一个团队里有多个小组如何合理有效的建立模块测试数据：创建数据不做重复劳动，数据可充分“复用”、“共享”、不产生冲突。单独成立一个测试数据构造组？是不是有点投入过大？我觉得问题不是“复用”，而是你们没有很好的保护测试数据和测试用例，应该有专门的软件控制和管理测试用例和测试数据，比较粗糙的可以保存在cvs里

15 楼 welllove53 2008-03-06  

踩地雷明显就是一种原始方式，最好的就是地毯轰炸。。。
usercase --testcase--code coverage,这个是保证质量最好的办法

14 楼 njwander 2008-03-05  

我觉得开发人员测试的时候是从需求的角度来测试，只要需求满足，就不容易去考虑其他情况，这样反而容易忽略一些非需求，但低级的bug。

13 楼 老肥羊 2008-03-01  

celine 写道

maybe这不是这个项目范围内的事
maybe需求bug

gigix 写道

mingo 写道

gigix 写道

movingboy 写道

个人认为由开发人员测试有种倾向：测试时倾向于走正常的业务逻辑，不太重视异常逻辑。由专门的测试人员（甚至是对系统不熟悉人员）来测，他们会采用“踩地雷”的方式测试，反而会发现一些看起来很低级的错误

个人认为软件系统根本就没有什么正常逻辑和异常逻辑的区别，只有你想到的逻辑和你没想到的逻辑。开发人员做的测试用来保证你想到的东西做得和你的想法一样，测试人员做的测试用来检查有没有应该想到但没有想到的东西。

re。

一般的，开发人员要保证能够自圆其说。

一般的，测试人员要保证能够合乎需求。

“合乎需求”这事也很奇妙。如果一种异常情况从来就没有出现在需求里以致于开发人员在编程的时候都没有考虑它，测试人员从这里测出问题来应该算什么？

如果需求本身存在逻辑问题,当然,是很隐蔽的逻辑问题,应该直接提交需求发起方并抄送需求审核方,然后挂起相关的问题

12 楼 老肥羊 2008-03-01  

gigix 写道

mingo 写道

gigix 写道

movingboy 写道

个人认为由开发人员测试有种倾向：测试时倾向于走正常的业务逻辑，不太重视异常逻辑。由专门的测试人员（甚至是对系统不熟悉人员）来测，他们会采用“踩地雷”的方式测试，反而会发现一些看起来很低级的错误

个人认为软件系统根本就没有什么正常逻辑和异常逻辑的区别，只有你想到的逻辑和你没想到的逻辑。开发人员做的测试用来保证你想到的东西做得和你的想法一样，测试人员做的测试用来检查有没有应该想到但没有想到的东西。

re。

一般的，开发人员要保证能够自圆其说。

一般的，测试人员要保证能够合乎需求。

“合乎需求”这事也很奇妙。如果一种异常情况从来就没有出现在需求里以致于开发人员在编程的时候都没有考虑它，测试人员从这里测出问题来应该算什么？

需求挖掘是一定要作好的..
呵呵..
个人观点,如果是从来没有出现在需求规格说明书里的情况.一般记录但不做处理,等待定期讨论处理.

11 楼 老肥羊 2008-03-01  

mingo 写道

gigix 写道

movingboy 写道

个人认为由开发人员测试有种倾向：测试时倾向于走正常的业务逻辑，不太重视异常逻辑。由专门的测试人员（甚至是对系统不熟悉人员）来测，他们会采用“踩地雷”的方式测试，反而会发现一些看起来很低级的错误

个人认为软件系统根本就没有什么正常逻辑和异常逻辑的区别，只有你想到的逻辑和你没想到的逻辑。开发人员做的测试用来保证你想到的东西做得和你的想法一样，测试人员做的测试用来检查有没有应该想到但没有想到的东西。

re。

一般的，开发人员要保证能够自圆其说。

一般的，测试人员要保证能够合乎需求。

换一种说法:

开发人员保证自己操作系统时,系统正常(包括操作异常时系统的正常响应)

测试人员保证在用户(客户)操作系统时,系统正常.

10 楼 老肥羊 2008-03-01  

gigix 写道

movingboy 写道

个人认为由开发人员测试有种倾向：测试时倾向于走正常的业务逻辑，不太重视异常逻辑。由专门的测试人员（甚至是对系统不熟悉人员）来测，他们会采用“踩地雷”的方式测试，反而会发现一些看起来很低级的错误

个人认为软件系统根本就没有什么正常逻辑和异常逻辑的区别，只有你想到的逻辑和你没想到的逻辑。开发人员做的测试用来保证你想到的东西做得和你的想法一样，测试人员做的测试用来检查有没有应该想到但没有想到的东西。

看逻辑的角度不同吧.
可以分为正常和异常
也可以分为想到的和没想到的
个人感觉,在可操作性方面,按正常异常划分会比较容易,因为我们想不到我们"没想到的"逻辑.

9 楼 老肥羊 2008-03-01  

movingboy 写道

个人认为由开发人员测试有种倾向：测试时倾向于走正常的业务逻辑，不太重视异常逻辑。由专门的测试人员（甚至是对系统不熟悉人员）来测，他们会采用“踩地雷”的方式测试，反而会发现一些看起来很低级的错误

踩地雷是一种方式
但如果要保证测试覆盖率,可能需要踩无数的地雷,这个工作量是很大的

8 楼 老肥羊 2008-03-01  

抛出异常的爱 写道

测试库就不要复用了.....
复用的东西不好改大家都知道...
这与TDD的理念不同.

呵呵,走一个极端,复用的东西大家都不去改..在一定程度上可以解决利用的东西不好改这个问题

7 楼 老肥羊 2008-03-01  

banner 写道

刚才旁听一个组建时间不长的开发团队的周例会，团队大致有20多人，分多个小组，注意到了两个问题：
1、指定几位开发人员作为测试人员：
由于暂时没有专业的测试人员，指定了几个对业务熟练的开发人员（或小组长）做测试，测试结果提交TD。对于业务复杂的庞大系统，在模块开发阶段没有专业测试人员的情况下，我比较倾向这种方式。
2、开发过程中的测试数据准备：
记得以前模块开发过程中，对于junit单元测试所用数据，是自己创建、自己应用、自己删除的；
在通过界面测系统模块功能时，则没有什么规则，经常会发生甲做了一批测试数据，今天测了一部份，明天数据就被乙删掉了的情况，测试数据相护使用。
我在想在一个团队里有多个小组如何合理有效的建立模块测试数据：创建数据不做重复劳动，数据可充分“复用”、“共享”、不产生冲突。单独成立一个测试数据构造组？是不是有点投入过大？

对于开发人员作为测试人员这个,我更倾向于从公司借调几个同事来进行一次测试,当然,这需要在开发结果到了一定的可操作程度时才可以.
测试数据一般采取定期清空的方式,在早期的时候,建议大家非必要交叉数据尽量不要产生交叉,如果有需要,可以尽量自己创建相关数据,在中后期的时候,一般不会清空测试数据,测试数据会定时分版本保留,因为有相当多的BUG可能是由于某些数据差生交叉之后才引起的,这个时候如果要重现的话,就需要.
还是提倡在需求分析阶段就有测试工程师的跟踪和介入

6 楼 celine 2008-02-27  

maybe这不是这个项目范围内的事
maybe需求bug

gigix 写道

mingo 写道

gigix 写道

movingboy 写道

个人认为由开发人员测试有种倾向：测试时倾向于走正常的业务逻辑，不太重视异常逻辑。由专门的测试人员（甚至是对系统不熟悉人员）来测，他们会采用“踩地雷”的方式测试，反而会发现一些看起来很低级的错误

个人认为软件系统根本就没有什么正常逻辑和异常逻辑的区别，只有你想到的逻辑和你没想到的逻辑。开发人员做的测试用来保证你想到的东西做得和你的想法一样，测试人员做的测试用来检查有没有应该想到但没有想到的东西。

re。

一般的，开发人员要保证能够自圆其说。

一般的，测试人员要保证能够合乎需求。

“合乎需求”这事也很奇妙。如果一种异常情况从来就没有出现在需求里以致于开发人员在编程的时候都没有考虑它，测试人员从这里测出问题来应该算什么？

5 楼 gigix 2008-02-27  

mingo 写道

gigix 写道

movingboy 写道

个人认为由开发人员测试有种倾向：测试时倾向于走正常的业务逻辑，不太重视异常逻辑。由专门的测试人员（甚至是对系统不熟悉人员）来测，他们会采用“踩地雷”的方式测试，反而会发现一些看起来很低级的错误

个人认为软件系统根本就没有什么正常逻辑和异常逻辑的区别，只有你想到的逻辑和你没想到的逻辑。开发人员做的测试用来保证你想到的东西做得和你的想法一样，测试人员做的测试用来检查有没有应该想到但没有想到的东西。

re。

一般的，开发人员要保证能够自圆其说。

一般的，测试人员要保证能够合乎需求。

“合乎需求”这事也很奇妙。如果一种异常情况从来就没有出现在需求里以致于开发人员在编程的时候都没有考虑它，测试人员从这里测出问题来应该算什么？

4 楼 mingo 2008-02-26  

gigix 写道

movingboy 写道

个人认为由开发人员测试有种倾向：测试时倾向于走正常的业务逻辑，不太重视异常逻辑。由专门的测试人员（甚至是对系统不熟悉人员）来测，他们会采用“踩地雷”的方式测试，反而会发现一些看起来很低级的错误

个人认为软件系统根本就没有什么正常逻辑和异常逻辑的区别，只有你想到的逻辑和你没想到的逻辑。开发人员做的测试用来保证你想到的东西做得和你的想法一样，测试人员做的测试用来检查有没有应该想到但没有想到的东西。

re。

一般的，开发人员要保证能够自圆其说。

一般的，测试人员要保证能够合乎需求。

3 楼 gigix 2008-02-26  

movingboy 写道

个人认为由开发人员测试有种倾向：测试时倾向于走正常的业务逻辑，不太重视异常逻辑。由专门的测试人员（甚至是对系统不熟悉人员）来测，他们会采用“踩地雷”的方式测试，反而会发现一些看起来很低级的错误

个人认为软件系统根本就没有什么正常逻辑和异常逻辑的区别，只有你想到的逻辑和你没想到的逻辑。开发人员做的测试用来保证你想到的东西做得和你的想法一样，测试人员做的测试用来检查有没有应该想到但没有想到的东西。

2 楼 movingboy 2008-02-26  

个人认为由开发人员测试有种倾向：测试时倾向于走正常的业务逻辑，不太重视异常逻辑。由专门的测试人员（甚至是对系统不熟悉人员）来测，他们会采用“踩地雷”的方式测试，反而会发现一些看起来很低级的错误

1 楼 抛出异常的爱 2008-02-25  

测试库就不要复用了.....
复用的东西不好改大家都知道...
这与TDD的理念不同.