没有需求如何写用例
前言：浏览51testing的每周一问时，看到没有需求文档该如何设计测试用例这个话题，是以前的问答，根据自己的测试经验，也给自己回答以下，算做一个工作小结吧，写之前没有看其他人的回答，因为看了其他人的后，可能会不自觉的对自己的思路有影响，所以先自己写完后又去看了下论坛里面其他人的回答，觉得zhuzx的回答更全面一些，学习之。=======================华丽的分割线，步入正题==================
当项目比较紧张的时候，很多时候需求文档这个重要的步骤就会被省略或者延后，从流程上来说是绝对不规范的，但是没有办法呀，对于一些没有形成系统测试规范的公司，且国内测试现状也大概如此，缺胳膊少腿的现象是很正常的，我们测试人员只能灵活应对才是王道撒。根据个人经验，发表点意见：
1、没有需求文档，找别的文档。
需求文档可能由于时间原因暂时无法获取，那就尽量的去获取其他的文档吧，比如开发的一些设计文档---概要设计、功能设计、详细设计等等。如果开发连这些文档都没有，那么可以去网上查询同类产品的一些规格说明书，幸运的话，也许能down到别人类似产品的一些需求说明。这些材料虽然不是自己产品的需求说明，但是因为是同类产品，功能方面也总会有8、9分类似，所以研究别人的产品，自然也就会对自己产品有了几分把握。
2、模块定位和划分
如果开发有详细的设计文档，那么就按照开发的设计，将产品按照功能模块迅速简捷的先进行模块划分。如果没有开发文档，那就要跟开发沟通，让他们简单介绍一下产品的功能模块并自己试用后对产品进行模块划分。模块划分后，组内分工合作，进行探索性测试同时不断完善测试计划和测试需求，因为前期概要的了解产品绝对不可能一次到位的对各个模块划分准确的。
3、测试方法
如果没有需求文档，测试用例的编写肯定没有参照。所以测试过程中测试用例的设计不可能非常详细，在有了1、2的调研、研究产品的基础后，可以设计一些简单的场景测试、流程测试用例，按照这些用例测试的过程中，必然会发现各种各样的问题，同时对产品也会不断熟悉。测试用例的编写可以放在一个轮次的测试完成后进行补充编写，然后在以后的测试过程中不断完善。
由于没有需求文档的情况下，想要先详细的设计出测试用例再进行测试是不太现实的，只能简单的进行用例设计后，确定大概的测试方向，然后在测试过程中不断完善测试用例才行。
注意注意：这种先测试后完善测试用例的方式必须是针对一个周期较长且需要做回归测试的项目，如果一个项目周期很短，且完成后不需要进行回归，那么这种方法并不是太理想，因为用例完成了却利用率不高，只能作为后期参考,以及对后来新人的一个培训和积累公共测试用例的途径（呀，看来用处还蛮多的嘛，呵呵，不过对于项目本身来说，用处不太大咯），从公司和项目角度来说，实际投入成本是增大了而这些投入的产出又比较小。
个人绘制了一个简单的进度图。 写的挺具体的，鲜花送上
不过没有需求，我都是基本摸熟版块再写测试用例的 没有需求 写测试用例 比较你难吧 郁闷 学习了 学习了要是没有需求 我只好先熟悉软件 然后和开发或项目负责人沟通 再做测试的工作 开发也没熟悉需求 只能自己摸索了
回复 6# 的帖子
那开发怎么编程序了？回复 7# 的帖子
如果项目很大，，每个开发负责的是部分模块，不可能对整个项目的需求都很了解！难道要和每个模块的开发一一去进行沟通？
回复 8# 的帖子
你说对了。使用一切方法了解真实需求才是正道。当然，如果你有更快捷的方法，也可以。
不过往往“快捷”带来的是模糊。比如，了解项目方面如果只与PM交流的话，你得到信息大多是宏观或框架方面的，而对细节部分就了解的少了。
回复 8# 的帖子
测试人员肯定不只一个呀，每个分工进行沟通合作呢，本来整个项目也就需要各个部门不断沟通的 一般整个的系统 我是先根据需求熟悉软件 抓重点写用例 最重要的先要熟悉业务吧！ 熟悉了业务，没有需求文档，自己也大概知道什么是测试重点了 写得很好，赞一个！！！！！ 写得很好，赞一个！！！！！！！ 学习下 没有需求的时候根据模块的情况来写吧，自己站在使用者的角度设定一些需求，然后再根据实际进行补充，等产品需求出来之后在完善它 确实很难写啊，什么文档都没有，老板又把开发外包出去了，只说了网站要做成什么样，像某个网站那样，具体要求一个没有，但到时候少了什么又会被说，case全部得自己摸索，查资料。谢谢楼主，牛的，至少我知道我该先干嘛了 学习了..写的不错，， 学习了..写的不错，，
页:
[1]
2
