关闭

遭遇测试概念--我与测试之z公司(1)

发表于:2012-11-08 11:23

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:huawen    来源:51Testing软件测试网采编

  另外,测试团队的尽早介入也能够帮助测试团队自身尽快熟悉待测试的软件,这种熟悉过程既然迟早都要发生,那么来的早比来得晚要好些。

  测试的实施一定是发生在待测产品可测之后,这是测试实施开始的时间,同时项目计划中也会对测试的终止做出时间和内容上的规定。因为有理智的老板是不会听任测试人员挖地三尺,无休无止地测试下去的。这就是“特定的时间”。

  “特定的环境”是什么意思?

  有两个方面,一是指测试要在一定的环境中进行。如果待测设备是手机,那么实现了待测功能的无线网络GSM、CDMA、GPRS、EDGE等就是必须的环境了;而如果待测的是PC上运行的应用软件,可能一台PC就足够了。另外一种环境是测试流程运行的环境,需要有数据库存储和管理测试的中间过程文档。比如:测试用例、测试结果、测试报告、问题报告等。/*目前TM项目的开发要求所有活动基于配置库开发,包括代码和文档。这样过程产品就受控了。并且根据计划的时间点进行基线。基线的文档要符合规范化要求。这就是流程运行的环境,流程包括代码的编写,代码的变更,代码的走查,文档的编写,文档的变更,文档的评审等。还有问题管理系统,这些研发活动的产出均通过该环境,做了记录。*/没有这种环境,虽然不能说测试就一定无法进行,但是效率和管理肯定是谈不上了。/*过程产出的文档、代码受控后,整个开发过程就受控了;同时基于该环境,可以方便的得到过程当前状态的,如有多少条测试需求,对应这些测试需求是否开发了测试用例,针对这些用例是否进行了测试,测试的结果是怎样的?案例的首次通过个数是多少?这些数据,可以让我们清晰的知道当前的产品质量如何。同时可以基于统计意义,为后续需要多长时间完成测试等提供依据。这也为后续的项目提供了历史数据。*/

  为什么要限定测试是出于“正常合理的目的”呢?有不正常不合理的测试吗?

  岂止有,简直比比皆是。很多苦大仇深的开发人员一提起这个来就暴跳如雷。按照我们刚才说的“事先制定的标准”,可以说大多数测试是有章可循的,引起争端的概率不大。但是事情总不会是十全十美的,事先没有考虑到的地方总会有,正所谓智者千虑,必有一失。在这一点上,开发人员出于弱势,因为测试在暗处,可以无边无际,无孔不入,无法无天,无事生非;而开发却在明处,头上有比球星古力特还多的小辫子等着别人去抓。这个时候,双方用正常人的标准来协商是必须的。我们得清楚产品是做给用户的,如果能够确定客户将永远遇不到这一问题,不改也罢。但知易行难,我们没有人能权威到能代表成千上万的用户来判断哪个问题能遇到哪个遇不到,这时最常见的就是用经验和历史数据来判断了。最后实在不行还可以使用权利,也就是高层老板的一锤定音。偏离目的的测试,往往容易沦落为吹毛求疵和鸡蛋里挑骨头,就像在追求“回”字的四种写法一样,但是很多测试人员却会不知不觉地迷失这个最为重要的方向。/*回想测试的工作精力,自己有没有吹毛求疵、鸡蛋里挑骨头的时候呢?还在lenovo network 时,测试web页面管理switch时,提出过一些英文单词翻译不顺畅的问题,应该说是此类问题把?*/

  我给你出个选择题:软件测试是为了什么?选项(A)为了软件没有BUG,质量完美;选项(B)软件质量足够可靠。你选哪个答案?

  当然是(A),做软件却有BUG,那算什么!

  选择(B)是测试人员的天职和义务。凡事都要有度,对质量的重视并不等于除了质量就没有其他。归根结底,做项目是为了利润,绝不能像书呆子一样地去力求做一个完美的产品,这是所有项目的底线。所以,测试的目的也必然得是“正常合理”的。

  难道明知软件有问题我们要看着它而不做修改吗?

  吃测试这碗饭的无论如何要记住:测试是有终点的,而且终点来源于理智而不是情感。有时候就是要明知有问题而不修改。因为测试是一个经济学的概念,测试投入与产出的关系,随着测试投入的增加,产品遗留的bug数急剧减少,从而BUG带来的损失也是急剧下降,但是这里存在一个分界线,在线左边,测试的投入小于BUG带来的损失,这是在测试方面的投入是可以获得回报的;但在线的右边,策划四的投入将开始大于BUG带来的损失,也就是说在测试上的继续投入是不合算的。

  在实际的项目中,从成本上考虑,该BUG花的钱也是一种损失,如果改BUG花的钱比留着BUG带来的损失还要小,还是不改为好。/*这个说法和芯片测试有些不太符合,芯片测试很多是非0即1的,尤其是ASIC的芯片。如我们之前做的TM二期,在测试到最后,还是发现了某个版本断流的问题。*/

  有些损失是显性的,比如改BUG的损失,我们可以把投入的人力物力换算成钱来衡量;但是有些损失是隐形的,比如用户因为使用的产品中有BUG而觉得十分不爽,从此不再信任你家的产品了,这种损失其实更大更危险。换句话说,看一个BUG值不值得修改,不仅要考虑到它可能给公司带来的直接损失,还要考虑到品牌和信誉受到伤害而带来的间接损失。

32/3<123>
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号