没有软件需求说明书如何建立测试需求矩阵？

snowers

如果测试工程师手头有经过确认的软件需求说明文档，那么创建测试需求与原始需求的矩阵（映射）应该比较容易些；难点在于，如果没有需求，那么如何提炼测试需求，更如何建立测试需求与原始需求的映射呢？

开这个题目，希望有经验的测友提供些实用的做法。反正我对这个是比较头疼的。

fzx

不规范的代价就是产品质量不高，测试只是软件开发过程的一部分，不需要为产品质量负全部责任，尽全力搞到需求，然后再着手测，千万别乱发Bug报告，搞坏了跟开发人员的关系。。。

需求不清和描述模糊的情况下，设计人员是按照他们脑子里想象的需求完成设计的，我们这里也是这种情况：）

沐蓝

1、没有需求说明书，总有其它一些文档吧，比方说项目任务书、设计说明书（不管是草稿还是你与领导、程序员口头交流的结果）。先和他们交流，把意见整理后，大致理解你将要测试的产品是个什么东东。这是最粗糙的需求了。然后做成测试计划，在其中的测试对象中把你了解到的需求都写上。
2、根据你理出来的东西，你可以先召集各方（主要是项目负责人和程序员，如果能把市场部的人也叫到，那就更好）开会，讨论你所写的测试计划。这个时候，你可以看到他们会为你写上的每个需求争论不休。等他们争出个大致的结果后，你记录好。再去做整理。这个过程中，肯定还会出来一大批你前面没想到的问题。然后就又可以再召集大家讨论。如此几次，就清楚了。
3、这当中最需要清单的就是你的说话技巧了。你不能一次把话说死。千万不要让他们有这种感觉：你开一次会议就会解决所有问题。要不断暗示他们后面还有很多问题，需要一步一步来讨论。否则你会死得很难看。

我可是先警告过了。如果有谁照着我说的做，最后受到不公正待遇。不能怪我。

js_pg

我用了很多但是和可是，苦恼ing。。。。

js_pg

我觉得楼主说得是一个现实存在的很严峻但是又是一个很普遍的问题，这就是我们大部分软件企业的现状，要解决这个问题需要多方面的努力，可是我们在一个很不规范的环境中做很规范的测试，恐怕是很难的一件事，但是我们必须做呀

Fuli

楼主，请问你司有谁作“需求调研”，是不是可以从这方面着手？

Fuli

楼主，我明白你的意思了。
国内的测试人员大都在“非标准”环境下工作，而坐在办公室里是想不出“需求”的，只能从市场了解更多的客户需求，所以要跟“市场”套近乎而不是“开发”！？我怎么觉得测试往后走了，与开发相提并论的工种既然沦为市场的第一手工具！
楼主提的问题值得探讨,欢迎交流！

snowers

必须面对的残酷现实：国内很多IT公司的项目都是在没有需求文档、没有设计文档的情况下完成开发的！Y？因为项目是靠内部关系弄到的，所有的文档可以在项目结束后补上，包括需求文档和设计文档。不信，问问大多数人是不是这样？不然就不会有《如何应对无需求的软件测试》这样的文章了。
我说的这种情况呢，大家可以认为需求还是有的，但是很少或没有参考价值，即无法直接将《需求规格说明书》的内容与“测试需求”建立映射。这种情况下，应如何管理测试需求与软件需求的对应关系呢？
有了现成的经过确认的需求，再做测试需求的跟踪矩阵，当然会轻松很多；如果软件公司都按标准的规范的开发流程做事情，测试人员不知道要省多少事呢。然而不幸的事，你不得不面对没有需求的测试项目。无奈吧？但我相信，即使在这种情况下，测试人员还是有作为的。这里想要和大家探讨的，就是你在这种情况下，会采取何种有效的措施？
大家不要谈标准的测试过程，没什么用的，因为很多情况下，你无法按“标准过程”做事的。说实话，标准的过程有几个人不晓得呢？可有多少测试工程师不是在“不规范”的环境中进行测试的呢？
所以，我觉得讨论“标准”的过程和方法固然好，讨论“非标准”的过程和做法则更为有效。当然，我们会做得越来越“标准”，不是吗？
补充一点，与需求有关的资料，现在只有前项目（系列）遗留下来的一些支离破碎的文档，还有开发人员对业务和软件工程的讲解和演示。

[ Last edited by snowers on 2004-11-11 at 16:35 ]

Fuli

需求的定义：
需求是正在构建的系统必须符合的事务。
如果没有需求请问如何立项？如何设计产品？如果没有产品立项哪来的原始需求？