软件测试经验谈——5个大于

发表于:2013-9-26 11:35

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

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

分享:
  从一名软件实施人员,经过研发人员、需求分析人员、测试人员的历练,一路来到测试主管兼项目主管的位置,实属不易。回首往昔,深觉经历的重要,也感叹实事造就人的真理。既感谢领导,也感谢同事。身为一名从事应用系统软件开发十余载的技术人员,今天相谈一些对于软件测试的感想。
  一、计划大于执行
  这是我第一件感慨的事情。经常见到手下新人对测试充满激情、兴致盎然,拿到测试任务,草草看过需求文档或说明书,一头扎进程序和用例当中里,戏耍个天翻地覆,找bug乐此不疲。但这与真正的软件测试还差得很远,我一问Why?说出都是“与需求相呼、与设计相应”的大道理。其实,他/她不解,我想问的是:需求为何如此?设计为何如此?计划为何如此?用例为何如此?执行为何如此?
  要回答这些问题,就要知道软件工程的终极目标:完全的控制能力!一个软件从知道意向开始到交付运维,方案、技术、工具、人员、资金、进度所有的一切都受控,才是软件工程的目标。那么,只有在软件工作的所有环节中都贯穿这一思想,整件事情才是受控的,软件测试也不例外。
  那么如何获得控制能力,就是在进行每项工作时都以那个“戴明环”(PDCA:Plan-Do-Check-Action)为方法论,开展具体工作。这个PDCA就是以计划为开端的,因此所有的执行都应当是计划的遵照、调整、删补,甚至是推翻重建,但是前提是必须有计划作参照。
  既然计划这么重要,大家就不要以“我发现了多少多少bug”自居了。如果测出的bug都在计划中,而且测试覆盖率计算标准科学,你才算会测试!这时我会说“你是在做测试,而不是在玩测试。”换句话说,在没有计划时,你只是图个新鲜,与小孩子遇到游乐场是一样的,但从某种意义上说(经济结果),在游乐场中的你分明是被设计者玩的。
  最后,回答一下开始我提的问题。1、需求为何如此?是因为业务背景(使用者、受众、政策、环境)业务范围如此,这些是非常软性的,但又是客观存在,不可违反的(在一定程度上是),这部分是新鲜力量最缺乏,也是最不愿意接触的。2、设计为何如此?因为需求和实现代价如此。需求就不说了,代价是你的团队赖以生存的条件,如果一个软件做10年能达到极高质量,但是人家要2个月交付,你怎么办?让对方等10年吗?所以10年有10年的设计,2个月有2个月的设计,说到底还是需求——隐性需求。3、计划为何如此?因为需求、设计如此。4、用例为何如此?因为计划和软件成品如此,用例必然不能天马行空,“计划给指导,软件来执行”。5、执行为何如此?因为计划、用例和制度如此。很多人都会忽略制度约束,找一些不必要的麻烦。如果你非要在没有权限的情况下验证涉密逻辑或数据,那你不是在测试软件,而是在测试组织制度和领导处罚人的坚定性。这些问题我也只是简要回答,肯定不全面,但原于实践,到底对不对,还请您用实践检验。
  这些问题回答完后,如果你能自觉地制定计划、执行计划、修订计划,你就开始向真正的测试领域迈进了。
  二、覆盖率大于执行效率
  这是我做具体测试工作的总结。俗话说“治病除根”,而不是“治病除症”。人如果头疼了,是的只吃止疼片,让头不疼呢,还是应当把头疼的原因消除呢?实际上两个都要做,先临时止疼,然后看病除根。“除病根”是长远目标,“止疼”只是短期目标。
  作为测试工作,测试覆盖率是一个很关键的指标,经常看到一些测试计划中动不动就写覆盖率100%,但是根本不提覆盖率的计算范畴,是需求层面、设计层面,还是代码层面的。如果都考虑全了,这个100%是比较难达到的(尤其是需求层面)。
  关于覆盖率和执行率的关系,我举个例子。我们要烙芝麻烧饼了,需要准备灶火、饼铛、盆、盘、面粉、油酥、芝麻、盐、水等;覆盖率相当于把每样东西大致检查一遍,虽然不细致,但是如果马上要开始烙烧饼就可以了(可能质量不高),不耽误大事;执行效率相当于在检查芝麻、油酥每种原料时的细致程度和速度,可是如果没有先检查所有的原料齐不齐,就开始挨着粒的查芝麻,我只能说您很可爱了(可能等芝麻查完了,发现没有盐,那可就糗大了)。
  测试工作也是如此,测试人员应当时刻记着远期目标,操作时关注短期目标。可是很多人,包括我自己在开始做测试时,都是有了短期目标,就完全忽略远期目标,测着测着不知道该干什么了,才想起看看远期目标?这是不好的习惯,而且说明对于将要进行的测试,没有一个清晰的思路和整体目标,业就无法形成你自己的执行策略,总体执行效率必然不高,很有可能要漏掉某些测试方面。
  三、记录大于操作
  我看到的很多研发人员都有一个毛病:急于实现,而不喜欢记录。这一毛病在很多测试人员身上也有,只是出现的形式不同罢了。在一般的开发工具中都会有两个辅助工具:ToDoList和日志。一个是要做什么的记录,一个是做了什么的记录。前一个类似于计划(不过只是给自己看的),后一个类似于操作记录。有了记录保证了很多事情:
  1、计划性——就是给自己一个比较明确的指导,第一部分啰嗦得够多了,不多说了。
  2、描述性——可以通过简单的文字看出要做什么和做了什么,做完这件事本身就是把思路和头绪理清了。
  3、可追溯性——可以在结项一段时间以后,看出自己做了什么(当然看用例也能做到),但有些时候需要查问题,最重要的是自己当时怎么想的,具体怎么操作的,甚至能够想起为什么,这一点是非常重要的。
  4、任务的中止与恢复能力——如果测试项目中止了一段时间,恢复测试项目时,你可以快速地知道做过什么了,该做什么了。
  5、多任务并发能力——有了记录机制,就有了上一种机制,内么任一一个任务都可以方便地中断和恢复。
  6、回顾与总结——文字是人类的宝贵遗产啊!有了回顾的资料,才能总结进步,是吧?
  说了这么多好处,有什么不好的呢?
  1、麻烦——肯定要写东西嘛,不过这只是因为没有习惯这种方式。
  2、容易忘记火化——年轻人经常闪现“火花”,但是有什么火花非要先试试不可(如果是火烧眉毛或人命关天的事除外),而不能先记下来呢?
  再多啰嗦一点,这里的记录更重要讲的是“养成思路成文,文字指导、记载的习惯”,大家不要教条于记什么、怎么记、何时记等等的事情,最终要的是通过这种习惯弥补质量控制和记忆力的不足。可能有些东西只是给自己看的,也只有自己才看得懂,有时记事本上的一句话顶得上一周的工作量。
21/212>
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

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

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

沪ICP备05003035号

沪公网安备 31010102002173号