|
如何提取测试需求
一、与需求相关的
1、直接来自需求
测试需求的绝大部分直接来自需求。工作中其实容易混淆什么是真正的需求,什么是需求的解决方案,什么是设计和实现带来的约束。什么是需求呢?如果不这样就不行的,才是需求。例如,作为一个银行系统,客户需要能够查询余额。不能查询余额的系统银行不会为这个系统而买单。所以,这是需求。那么,需要密码才能查询余额是不是需求呢?这不是需求。因为我可以通过指纹识别来查询余额吧,为什么一定要用密码呢?那么要设定一个6位数字当作密码是不是需求呢?当然也不是。这只是为了达到保密目的而做的一个设计上的限制。6位密码其实完全可以是8位或者别的身份标志。所以,先弄清什么是真正的需求,然后提取出来作为测试需求。
2、补充需求
需求并不完美,所以你还可以补充一些需求。具体包括:遗漏(如:分支流程、对特殊数据的支持和处理。。。);隐性的需求(如:对某些人或特定领域来说的常识;行业规范;UI标准;停留在需求分析人员脑中的隐含需求);竞争对手的类似系统的功能等。
3、挖掘需求
通过提问的方式可以挖掘一些需求。例如,通常比较难以得到高质量的非功能需求。因为用户只是需要越快越好,他也无法告诉你多快才是他能接受你又可行的。这时,通常相应的性能测试需求可以通过Q&A的形式以具体的问题去启发或者得到。还有一些需求,虽然一直存在,但用户长期以来已经习惯了忍受。你不从某个角度去问,他也不会当作需求提给你。
二、不会出现在需求中的
某些测试需求不会出现在需求中,因此需要测试人员补充。
1、反向测试用例
你最常需要补充的测试需求中很重要的一块是反向测试用例,即需求要求这样做了。那么需求上没有要求做的是否系统没有做。
2、设计和实现约束
前面“直接来自需求”中提到的需求的解决方案或者设计/实现的约束,在其进一步确认后需要逐步补充到测试需求中来。
3、可测试性的需求
最后一点常容易被人忽视:测试人员还需要补充为了提高系统可测试性而提的测试需求。例如,某个系统依赖于多个其他系统的接口。为了在对方没有提供可测试的环境或者版本的时候可以先测试我方对接口的正常处理,需要系统提供一个功能,模拟生成对方的数据,也可以查看我方发给对方数据包的具体内容。 |
|