学历代表过去→能力代表现在→学习代表未来

【51软件测试每周一问,整理】没有需求文档的时候如何来设计测试用例?(08-06-20)

上一篇 / 下一篇  2008-06-26 11:44:29 / 天气: 舒适 / 心情: 平静 / 个人分类:学习日记

这是根据51Testing软件测试网上软件测试每周一问问答整理而成,集大家之智慧!

【引题】测试用例应该是按照需求文档来开发,但是当项目没有需求文档时,该如何设计测试用例呢?

【题外话】大家在求职时参加的面试中会被问到各种各样的问题,有些问题的确是有确定的唯一的答案,而更多的问题是开放性的,面试着主要是你想了解求职人的自己的看法,而回答问题的方式也能看出个人看问题,思考的方式。本身,思考,就是一种方法学。

【正题】hjjlearning的回答是我比较满意的。Case by case的讨论问题,总是比较全面,而且可以引导大家更为全面的去思考,从而提高一个问题的广度。针对“没有需求文档”这样一个现象,我们去想解决问题时,需要花点时间去考虑造成这种现象的原因。针对不同的原因,也就是找对“病因”了,解决问题的方法也就有了。这就如中医看病,总是从表象的症状去寻其根究。就比如头通,表现出来的这一种症状,却有不同的原因,西医总是“头痛医头,脚痛医脚”,而中医主张从其根本去分析,痛其实是身体某处经络不通造成的,把相应的经络打通了,那痛的问题就会解决了,有时头痛可以通过按摩脚底的穴位,或是敲打胃经,胆经,等等。又扯远了,哈!

分析“没有需求文档”,分析其具体原因再针对性的解决:

1.  整个项目的开发人员和项目经理的意识不足,开发流程不规范,或是认识不到需求文档对于测试的举足之重。认为做过了市场可行性分析了,认为项目组的成员对于整个项目都有清楚,而且任务分配下去了,就没有必要写需求文档了。

针对这种情况,测试负责人应该坚持要求项目负责人派专人给出需求文档,否则就拒绝测试。这对于规范的软件开发项目来说应该是理所当然的事情,可是在中国(我不知道别的国家是怎么样子的),做事都讲究官大压死人。bingcha320说的好,上报'没有需求文档将无法进行测试用例设计'的事实给高层管理者(练口才的时候到了),引起他们的重视,让他们尽可能推动开发组或产品组完成需求文档,哈哈

2.  项目进度紧张,后期需求变动会比较大,来不及也不好写详细的需求文档,或是项目是从原有项目上进行升级,开发人员认为不要再进行

当项目经理把自己的难处说给你听,并给你一个“Sorry”的时候,那就要动用各方面的关系自己去搜集功能点啦。

简言之,不能瞎乱糊草的写测试用例。对自己的时间和精力负责,对整个项目负责,自己整一份feature check point list

Zhuzx给出了比较详尽的条条框框的指导性的回答,(有经验有头脑的人就是厉害哈!我在其精彩回答后加了点自己的“挑刺”)

下面是我的一些看法,恳请各位同行批评指正:
1.根据客户的功能点整理测试需求追朔表:
一般的客户都要把要开发软件的功能点写成一个表格交给市场部,让市场部门转交研发部。所以客户的功能点是编写测试用例一个最最重要的依据。【其实这只是一个依据,客户列出的功能点,要转化为软件实现的功能点并能在开发人员和测试人员之间更好的沟通的话,还是需要一点处理的】

2.根据开发人员的Software Specification List整理我们的功能测试点:
一般来说,开发人员实现一个功能都要把该功能分成几个子模块来实现,所以Software Specification List也是我们参考的另一个比较重要的依据。【只做过黑盒测试,在做黑盒测试时,参考开发人员的design doc时,尽量避免被开发人员误导,因为有些在他们看来是要实现并验证的功能,在用户使用时其实只是一种情况,而有些在他们看来是一个问题时,实际上用户使用时会有不同的体验,测试人员不是为了验证代码的逻辑的正确,而是为了确保交付给用户使用时,软件的质量很高。当然了,这些开发文档在没有需求文档时是比较好的资料啦
J

3.开展项目跨部门讨论会:
可以抽出时间,叫市场部的项目负责人、产品经理、项目经理、软件开发经理和软件开发人员,分别讲讲他们对整个产品的认识和设计模式,对每个功能点的理解和认识,理顺思路,达成共识,测试人员负责记录,测试Leader负责整理汇总,形成测试的部分参考文档。

4.测试人员整理用例需求疑问递交项目组和客户代表回复:
测试人员根据项目讨论会后的理解,测试过程中可能碰到的问题(如:边界值、输入数据类型等等)和需求不明确的问题,整理用例需求疑问,让相关的模块负责人在用例需求疑问表格中回复,并给出详细解释和说明。

5.项目内部用例评审:
测试人员根据对项目的理解,编写测试用例要点,测试组内部评审修改后,可以召集项目组的成员,帮助Review一下,然后进行修改。经过多次修改和评审以后,测试用例要点可能会更加全面一些。

6.邮件和客户代表确认部分争议问题:
测试人员与开发人员、项目组成员,在需求问题上讨论有时候观点不一致,各说各有理,这种情况下最好把争议问题写成邮件,发给客户让客户来拍板,确定那种需求合理,到底如何做?抄送项目组的全体成员,方便大家都了解客户的意见。最后编写测试用例的时候,以客户的邮件内容为准。

7.项目Demo和部分已开发系统:
大部分的系统,由于没有需求,为了避免项目风险,开发方一般都要做成Demo,不断让客户确认后签字,不断展现新开发的功能,以达到吸引客户的目的。如果项目中有DemoDemo也是参考标准。如果什么都没有,那已经开发的部分功能模块,要去随时让用户了解了解,并提出部分修改意见,也可以为我们熟悉系统提供部分依据。

8.参考同行业和竞争对手的类似产品:
假如说是做一个网上书店类似的网站,我们编写测试用例的时候,可以看看当当网“China—pub”等等类似成熟相关的网站。很容易发现本公司产品的问题,无意识给产品添加了竞争力。对于竞争对手的了解一定不能够少。

9.交叉模块的测试,最容易被人忽略:
一般的产品,功能部分的交叉,即是说在A模块中设置了参数,在B模块和C模块中体现该参数的实际运用。比较难的如我们现在测试的银行系统中的交叉模块,还可能牵涉到不同的用户,3个以上的模块之间的调用。即是有了需求也很少写,同时也是需求编写的一个薄弱环节。这样的测试用例编写问题,一般初级测试工程师很难考虑全。对于有这种交叉功能的模块,必须要求项目组中的精兵强将,画出相关的调用关系图,表明调用关系,方便后面编写测试用例。

10.可以使用电话、MSNSkype等网络聊天工具咨询部分需求:
我们做的产品,大多数的客户都在国外,测试经理也可以用这些网络聊天工具和客户确认部分需求疑问。不过要要事先越好时间,并注意异地的时差

其实这些方法远不止是告诉我们在没有需求文档时该如何处理,这些方法同时也帮助写需求文档的人如何多方面的搜集资料,和QA如何更好的在软件开发过程中,获取相关资料从而更好的把握软件质量。

哎呀,论坛里的人才真是太多了,我只获取这么一点点吧

因为毕竟经验有限,有了这些方法上的指导,大家在实际项目中就灵活处理吧!

 


TAG: 51Testing 软件测试 需求文档 测试用例 学习日记

liu51的个人空间 引用 删除 liu51   /   2014-06-18 10:21:05
总结的不错!
liu51的个人空间 引用 删除 liu51   /   2014-06-18 10:20:23
5
 

评分:0

我来说两句

日历

« 2024-03-22  
     12
3456789
10111213141516
17181920212223
24252627282930
31      

数据统计

  • 访问量: 5218
  • 日志数: 8
  • 建立时间: 2008-04-08
  • 更新时间: 2008-06-26

RSS订阅

Open Toolbar