最近工作的苦恼!!(关于测试用例与测试计划，版主注)
最近工作的苦恼。我在写测试计划和用例，以前主要是干执行测试的，平时对于这些理论：测试计划，测试用例
也知道个大概，表面上的。但真的实际来写，却从来没写过。
首先是测试计划，我接触了几个摸板，有华为的和我们自己的，我觉得都差不多，各个项目也差不多，唯一变化的是，要画出系统的测试框架图，指出测试点。我相信这不难，因为以前的需求分析，项目分析方案都指出来了，自己看了也知道。所以我就很快的搞定了，但老是感觉写测试计划没什么提高（用处不大），他们都说测试计划中最重要的是测试用例（虽然计划和用例应该分开 ，但有的公司是放在一起的），我也就默认了。
到了测试用例，我老是感觉自己写的过于简单，没自信。可能是需求分析台北写的不够好，但后来项目经理重写了份，因为软件没有很固定的GUI，我有时不能确定它的输出。黑盒测试不就是比较输入输出吗？比如：一个流程，它执行（运行很多步）了很多，你也感觉到它是一个关键部位，应该测试，但不知道它的中间输出在哪里，因为你要验证它的一步一步正确性，只知道它的最后输出，怎么办？还有事件的备选流，要重新写个例子吗？？比如，保存数据，它的执行流是保存成功，备选流是不成功，系统无法保存，我难道要写2个测试用例吗？
盼高手给我解答。。。。。。。ing
[ Last edited by jackei on 2005-5-19 at 11:18 ] 呵呵！！以上本来是写给jackie斑竹的一封信，jackie叫我把它贴到网上，大家共同谈论。说实在的，这其实是我第二次贴这个了，第一次是在新手区里贴，可遭到了某一斑竹的嘲笑，说我什么都不懂，没有这个能力云云。。我不服，不懂就要问撒，能力是培养的，反驳了几句，却遭到了删帖的命运！！！！
所以我很不爽，在灌水区写了篇文章：他是如此的无聊。。。
今天跟jackie 斑竹聊，请教了他。他叫我让大家共同讨论，感谢jackie 斑竹！！！！ 从非技术的方面回复一下吧。也是自己的经验和感受。
1.关于测试计划，测试需求是一个很重要的方面，如果无法确定被测的内容、范围，那么就很难计划如何开展工作、制定时间表、准备各种资源。测试需求关注的是你准备要“测什么”，或者说你准备对哪些地方展开测试，自己怎么想的就怎么写吧，有了新的想法或者发现问题就继续补充或者修改，不要指望一次可以完成的很完美。
2.无论是测试计划或者测试用例，最好的方法就是根据工作的实际需要来开展。第一次做，也不要指望一下就能做到最好，有了想法就尝试，发现合适就继续推广，发现不合适就调整。
关键是想到就做，经常性的回顾、总结一下，把工作的成果同大家一起分享、沟通，然后就慢慢的知道怎样做更好了。
对工作的计划和测试用例的设计，与其说是技术，还不如说是技能，只有通过大量的练习和经常的思考才能明白到底该怎么做。
[ Last edited by jackei on 2005-5-19 at 14:20 ] 恩！！我明白。
你能帮我从技术上分析吗？？
我应该怎么做？？ 我也有同样的困惑，虽然看了不少的书，但是当动手写得时候有有些无从下手的感觉。依然不懂得如何去写个优秀的测试用例，看来还是没把测试理论搞透彻。继续学习中。 恩！
我不这么觉得，还是我们的经验少了！、
纸上得来终觉浅，绝知此事要躬行。
我得好好的动手干干，边摸索变看书！ 我觉得看书很有效果的 我也是新手呢
看文档的时候感觉差不多都清楚了,写得时候又一下有好多的问题呢
看来还是要一边看书,一边试着写些实例,多动手做做很重要的吧. 1)我们公司的测试前要提交的测试文档是：测试计划.doc，测试方案.doc，测试用例表.xls；测试方案有整个测试用例的一个大纲和说明，测试用例表.xls只是是把测试方案内的用例细化，然后用execl来表现；
2)其实黑盒测试，如果做的细致点，可以一步步跟踪系统内部那些发生变化（例如数据库某字段或输出啥；这部分有些可以与研发人员沟通，有些靠自己摸索出来）；做的粗点的话，只关心最终输出结果；而不关心中间发生了什么变化（这样会遗漏某些在中间发生错误但结果还是一致的BUG）
对于LZ提的那个保存问题，你可以作为一对用例组2个测试用例来写；也可以做为单独一个测试用例，2种可能结果来做区分；个人觉得这是细节问题，不必太拘束于表达的形式问题
以上只是个人一些浅薄的看法 希望各位指教
页:
[1]
