keng

那些年测试踩过的坑

问题一:串行测试

想必很多测试团队不只是一个人。那么测试是如何分工的呢?无外乎两种吧。
1.根据项目进行分工,每个人负责一个项目;
2.根据功能模块进行分工,每个人负责一些功能模块。组内的测试成员每人负责一个功能。
很多产品功能内部是有很多的耦合性的,比如:先上架一个产品,在执行浏览、下单、支付等流程。

那么势必会遇到一个测试人员正在测试的时候,下一个测试请求就需要等待场景。

问题二:SVN合并

很多开发团队还在使用SVN,那么svn的合并问题是一个比较大的问题。比如:一个项目有A\B\C三个开发人员,分别向开发分支里提交代码,这时A正在开发某项功能,B则已经解决了某个BUG需要立即提测,犹豫SVN中混杂这AB的代码,造成需要等到A开发完成才提测的问题,如果不开发完则有可能上线的代码中包含A的半成品代码。

目前,Git基本能解决这种混杂的代码开发方式,江边望海正在团队中努力推进Git的普及。

问题三:程序的耦合性

对于大型的网站项目开发,一般为了提高并发,会将产品按照模块分解到不同的svn中,这样修改某个svn其他模块代码不受影响,也容易进行测试。但是有些项目所有的程序都在一个代码库,而且以来很多后端的接口和服务,造成测试的线拉的很长,测试起来非常的不容易。

问题四:为什么需要阶段性发布

阶段性发布虽然有助于产品的迭代稳定,但是阶段性发布也是以前就的软件开发的步骤,互联网公司的产品大多是基于B/S的,一个BUG或者一个漏洞都可能会造成用户的流失,如果按照阶段性发布的原则势必太过古板。

现在的持续集成大行其道也正式多数互联网公司提倡的,如果一个测试人员还在为别人没有按照阶段性发布恼火的时候,是应该考虑自己是否OUT了。当然,正常的产品迭代还是要遵守的,但是有持续集成别不相悖。

发表评论

电子邮件地址不会被公开。 必填项已用*标注