需求阶段测试工作的开展
上一篇 / 下一篇 2007-06-27 16:45:56 / 个人分类：01.软件测试
首先，测试用例和测试工作本身是不断完善的，在开发过程的初期，可以认为是需求阶段，或者没有规范需求工作的设计阶段。如果有一个比较明确的需求文档，可以在这个阶段检查完了需求文档以后开始设计测试用例。这里，
对于需求文档的检查主要是两个方面：
1.检查需求文档描述的正确性，愚以为测试人员要对于真实的系统所涉及的业务非常熟悉，比如一个简单的财务软件，那么测试人员本身就要对会计工作熟悉，财务制度熟悉，在检查需求
文档的时候不要迷信所谓的“都是用户真实的需求”，这里存在两个问题，一是用户是否真的能正确地描述自己的需求，二是需求人员是否真的能正确地理解需求。另外，还有一个用户的需求是否符合行业规范的问题，如果不符
合，那么是否要确认����这里存在一个隐患，用户可能会在开发的后期突然要求他们自己要走行业规范，让你的需求变动，所以要事先明确好。
2.检查需求文档描述的准确性。主要是考虑文档中是否存在描述的模糊的地方，对于自己不清楚的问题一定要明确。这个时候是要保证需求的可测试性����我得意思是说保证需求是可以完全为测试工作服务的。
那么在检查完了需求之后，就可以开始设计测试用例了，愚以为，在这个阶段因为没有开始设计工作，所以对于测试用例的考虑不能仅仅从界面出发����虽然RUP中对于用例的要求有这一项。因而测试用例的设计应该从业务角
度出发，从实际业务出发来设计测试用例。当然，在测试用例的描述时，要尽量考虑怎样同应用程序脱离开而仍然具有有效性。
当然，这个阶段所实现的测试用例是不过完善的，只能涵盖某些内容，但是我认为这些用例不仅仅全部都是功能测试用例，而且在整个项目中都将有效。
不过，当缺少需求文档时，那就要发挥测试人员自己的能动性了，要主动的工作，而不是被动的等待。要自己尝试着去熟悉实际业务，要尽量通过自己所能想到的方法来开展工作。
相信学过马克思哲学的朋友都知道什么是客观性和主观能动性吧。
当然，在设计阶段和最后的编码阶段，都还可以继续添加、修改或者剔除掉部分测试用例，使之更加完善。
jackei by 2004-01-09
Link URL: http://www.cnblogs.com/jackei/archive/2005/01/12/90986.html
TAG:
我的栏目
标题搜索
日历
|
|||||||||
| 日 | 一 | 二 | 三 | 四 | 五 | 六 | |||
| 1 | |||||||||
| 2 | 3 | 4 | 5 | 6 | 7 | 8 | |||
| 9 | 10 | 11 | 12 | 13 | 14 | 15 | |||
| 16 | 17 | 18 | 19 | 20 | 21 | 22 | |||
| 23 | 24 | 25 | 26 | 27 | 28 | 29 | |||
| 30 | |||||||||
数据统计
- 访问量: 292474
- 日志数: 354
- 建立时间: 2006-12-26
- 更新时间: 2007-09-16
