联系我:新浪微博@架构师Jack 或 dongjietest#163.com联系.(#换为@)

小项目的测试如何做?

上一篇 / 下一篇  2009-11-10 22:05:30 / 个人分类:正确的测试思想

有网友给我发邮件询问:测试架构师的工作职责只适合大公司。如果是一个只有10个测试人员或更少的测试人员的小公司,可没资源来做这些测试活动了。那么应该开展哪些测试活动才是最适合小公司的。

A6M+H[(ts0

其实我工作的第一家公司,虽然测试人员也有大几十号人,但是运作上其实还是一个小公司,资源缺乏,人力不足,产品时间紧。因此,对于小公司测试活动的认识,我也是走了弯路后,最近才反思合理的测试策略应该是什么。

Z/lU:g$Vg7k0

 先说说小公司的特点:公司失败的风险很大,产品失败的风险也大,并且用于研发的时间和人力都少。51Testing软件测试网8Aipp.ZOJ

那么小公司的特点说明什么?说明小公司的测试必须是快速开展,快速见效,有可能测试的不全面,但是只要保住了可以保命的质量,规避了保命的风险就可以满足老板的需求。这里就谈到,小公司的自动化测试什么时候搞合适?我的建议是:产品第一版的测试就不要投一点力量搞自动化了,谁知道下个月还做不做这个产品。只有产品销量成功,公司立志23年都要继续完善该产品时,才有必要投入自动化测试。毕竟自动化测试的成本是很贵的,你投一个人搞自动化测试,你就少了一个保障关键特性质量的测试人员。今天,我终于理解和原谅了04年让我中止搞自动化测试的那位测试经理。我当时一味心思认为只有自动化测试才是测试活动中最有技术含量的工作,并没有站在公司的角度,从大局思考投入产出。51Testing软件测试网H+o7I&o^R0^| p

那么小公司不搞自动化测试了,是否就意味着小公司的测试就可以进行monkey testing。错!小公司可以把时间放在基于风险测试的研究和掌握中,基于风险的测试就是解决资源和时间都不够情况下,我们如何把产品质量引起的失败风险降低到最低的一种最佳投入产出测试准则。

:I0JQ,y_+JU @0

同时,小公司更需要测试人员参与到项目的需求讨论,架构讨论活动中,发挥小公司灵活言论自由的优势,把需求和架构的问题尽早消灭,根据统计50%的bug都是在需求和架构设计阶段就埋入了的,而这些bug要在系统测试阶段发现,不但难度大,而且非常耗时。51Testing软件测试网 Ru5y)J)oD5o's

另外,小公司测试人员要尽可能使用测试工具进行代码自动测试,只要能自动进行代码相关测试的工具就尽可能拿来用,虽然会遗漏代码编写的缺陷,但也比在后期完全依靠系统测试来发现,省人省时多了。51Testing软件测试网S*H~^7g'N6[{

最后,小公司测试可以在功能测试上少花一些人和时间,只做verification,不做testing,当然前提是:已做好了基于风险的测试分析,并进行了充分的early testing。但是在性能测试压力测试方面,还是要依赖工具尽可能去测试,暴露产品在少数极端情况下和长时间正常情况下的bug

#t.N9f IRQ6_0

总结小公司测试策略的建议:51Testing软件测试网mr._a!am&Y

                                      i.             不要过早投入开展自动化测试;51Testing软件测试网b;y4G0}7exgF5bYK

                                    ii.             一定要掌握基于风险的测试方法;

7S+ClW(t3V"b0

                                  iii.             尽可能使用自动测试工具进行代码级测试;

N B3u#E5hO9U4W0

                                  iv.             功能测试侧重verification,少做testing

E9^y.sQ ~0

                                    v.             重视性能和压力测试;

~Nn[D1M*~0

TAG:

Fighting-ing的个人空间 引用 删除 Fighting-ing   /   2017-05-23 16:50:23
小公司的测试必须是快速开展,快速见效,有可能测试的不全面,但是只要保住了可以保命的质量,规避了保命的风险就可以满足老板的需求。
就像先保命后治病一样的道理
Fighting-ing的个人空间 引用 删除 Fighting-ing   /   2017-05-23 16:48:15
5
phoebe_kaka的个人空间 引用 删除 phoebe_kaka   /   2012-04-06 10:01:00
5
luihengk的个人空间 引用 删除 luihengk   /   2012-04-06 09:06:27
总结很好
luihengk的个人空间 引用 删除 luihengk   /   2012-04-06 09:05:20
-1
rachel1991814的个人空间 引用 删除 rachel1991814   /   2012-04-05 17:31:52
3
miranda_lau的个人空间 引用 删除 miranda_lau   /   2012-04-03 12:40:35
原帖由deanaa于2009-11-11 10:28:23发表
个人觉得,小项目的测试工作还是应该集中在功能测试(黑盒)上面,除非是项目、产品本身有很高的性能或是.

-----非常同意這種說法, 我們公司就是這樣做的。
pdn2000的个人空间 引用 删除 pdn2000   /   2011-12-24 11:55:58
3
tyung的个人空间 引用 删除 tyung   /   2010-10-26 09:07:46
1
引用 删除 yilianyouming   /   2010-06-15 16:27:05
恩,说得很好啊!顶!!!
猎头的个人空间 引用 删除 猎头   /   2010-06-12 17:05:46
-3
humh的个人空间 引用 删除 humh   /   2010-03-26 14:00:16
5
SF 引用 删除 shaofei19820625   /   2009-12-15 17:06:57
iv.             功能测试侧重verification,少做testing
这点我有点不理解。
我一直的想法是先做verification,再做testing的。
先确保功能都ok,然后再进行多方面的异常情况测试。而风险测试分析很重要的一点是明确测试优先级,先测什么再测什么。
为什么“当然前提是:已做好了基于风险的测试分析,并进行了充分的early testing”这之后就可以少花人和时间再功能测试上呢??
kekebaobao的个人空间 引用 删除 kekebaobao   /   2009-12-09 18:26:55
原帖由愚人于2009-11-18 08:57:15发表
嗯,比较同意,尤其是基于风险的。风险分析师未雨绸缪,而测试已经是亡羊补牢了……
倚窗听雨 引用 删除 applejuzi   /   2009-12-06 20:28:24
赞,看的很透彻。
愚人也有梦想 引用 删除 愚人   /   2009-11-18 08:57:15
嗯,比较同意,尤其是基于风险的。风险分析师未雨绸缪,而测试已经是亡羊补牢了……
sdm_0915的个人空间 引用 删除 sdm_0915   /   2009-11-11 15:52:46
恩,上面说的很对,小项目的特点都是资源少、时间紧,能把功能搞定就不错了,如果小项目还有存在大规模访问大压力的情况,我觉得这样的项目估计也不能算作小项目了
deanaa的个人空间 引用 删除 deanaa   /   2009-11-11 10:28:23
个人觉得,小项目的测试工作还是应该集中在功能测试(黑盒)上面,除非是项目、产品本身有很高的性能或是稳定性的要求。
小项目,大部分都面临资源少和时间紧的问题。在这个前提下面,一个相对高效的开发和测试策略我觉得反而是把业务和技术尽可能的分离。测试人员关注业务需求,而把技术相关的东西都分离到开发人员手里。由测试人员来把握需求,从功能上保证项目产品的质量,而把侧重代码质量的白盒测试和性能测试交给开发人员来处理。
从客户的角度或者风险管理的角度来讲,除了性能和稳定性非常敏感的项目外,大部分项目的客户满意度还是体现在功能的实现上的,这也是在资源时间有限的情况下一个较优的选择。
 

评分:0

我来说两句

Open Toolbar