1、根据公司项目的现有情况，我建议系统测试方案编写应侧重场景流程的描述，而测试用例则重在针对测试具体功能点时所使用输入的测试数据。我们可以重在编写测试方案，在测试方案中根据需求详细的描述分为i主成功场景与分支流，要求覆盖所有功能与业务规则，达到功能的100%覆盖。而测试用例在测试任务较紧张的时候可以暂不编写，由测试人员根据经验自行判断在测试活动中应该运用何种数据。在测试任务较轻松的时候，测试组成员可依照统一标准共同编制一个测试用例库，将公用的、常用的数据建立数据库，可重复调用，逐渐积累，将会很大程度上减轻测试用例的编写工作。

2、测试方案的评审现在为测试组内评审，我建议此评审可在项目组内进行。原因一，项目组成员更熟悉系统需求，比测试组内评审对项目而言更具针对性，也容易在早期发现实现可能出现的问题与遗漏，BA和开发人员可以及早确认解决；原因二，测试方案可以辅助开发人员关注开发要点，毕竟我们测试是为了发现BUG而是为了预防BUG。

3、测试方案及测试用例的完成可以作为一轮测试完成的标准。现在的处理方式大多是由时间来决定测试是否结束。如果时间不足，部分测试要点会有遗漏；如果时间很充裕，测试人员可能会反复测试这个项目。测试方案及测试用例可以方便的统计出测试的执行率和通过情况。这样既不会遗漏测试要点，也不会重复测试，可以辅助测试活动的统计和管理。

[ 本帖最后由 walker1020 于 2007-7-15 12:44 编辑 ]

在测试任务较轻松的时候，测试组成员可依照统一标准共同编制一个测试用例库，将公用的、常用的数据，建立数据库，可重复调用，逐渐积累，将会很大程度上减轻测试用例的编写工作。
--------------------------------------------------------------------------------------
这个想法不错

“测试组成员可依照统一标准共同编制一个测试用例库，将公用的、常用的数据，建立数据库，可重复调用，逐渐积累，将会很大程度上减轻测试用例的编写工作。”
这个也不错

我觉得楼主是根据贵公司目前的项目情况来写的建议，对不了解项目状况的外人来说很难作评论你的建议是否完善sdlkfj5

4楼的有道理~~
我大概介绍一下公司业务情况，公司现状和大部分公司类似，项目时间紧，需求变动大，测试地位不高，测试组建立时间不长，一切都有待完善。
目前测试用例和测试方案基本流于形式，没人认真写也没人认真看，基本没什么用。
某测试组同事看过我的建议，跟我说想法很好，可行性不高，比方说第二点，连需求同行评审他测了20多个项目也就参加过2次，按照规定可是每个项目都应该要需求同行评审的，但通常项目经理都忘记发邮件通知测试组，想要项目组评审测试方案，谁有这个空哦~
唉~~我打击很大哟~~

目前我在本项目中是这样做的。供参考(部分)
1、测试用例不容疏忽啊，至少核心模块必须写用例。
2、集成测试计划安排必须到位。（进度合理尽量细化、整理集成测试计划关于业务的流程图以及每条分支的测试数据、流程的明细。）
3、开发人员自测能力的培训。（关键是测试意识的培训）新近的开发人员，我都会去强调一《页面面规范》的内容。
4、定期整理开发工程中的有共性的BUG，随时更新。整理出来发邮件给开发人员，提醒开发人员。

我觉得还是应该让公司高层先重视起测试这块，这样测试的一些工作才能顺利的开展sdlkfj3

看了6楼的我又有两个新想法了~sdlkfj3

4、以统一标准建立bug库，测试组在某个周期内进行统计，将常见缺陷以邮件方式发送给开发组（软件部），不仅可以帮助开发组预防类似缺陷，同时bug库对于测试组也是宝贵的财富，可以用于测试组成员同行学习、总结、提高。
5、对于会多次回归的项目采用自动化测试（例如早期交付给客户一个软件原型，里面有些基本功能，然后经过多次演示，再慢慢扩展需求和功能的项目），在首次测试时录制测试脚本，下次回归时根据增减功能调试并运行测试脚本，减少重复工作，复用性高的测试脚本可存入脚本库，以供下次项目使用。（对自动测试还不太熟悉，不确定可行性，需要再摸索）

引用:

原帖由 小小丫 于 2007-5-16 10:43 发表
我觉得还是应该让公司高层先重视起测试这块，这样测试的一些工作才能顺利的开展sdlkfj3

我占同这位人兄的看法。所以我想把那些常见的BUG直接发给项目经理那些老大级的人看好效果应该好点

测试方案和测试计划你认为那个重要啊 ?

没有计划，方案很好的可能性应该不大吧。都是一环扣一环的。刚开始如果不太好的话，越到后面，会越糟的。

如果可能的话，可以考虑使用TD或者是QC之类的测试管理工具。

楼主的建议很有针对性，并且提出了自己的Solution。如果有机会，建议楼主一定要在测试工作中体现出来。这样既可以验证你的Solution的可行性，又可以丰富和完善你的Solution。 有可能某些Solution b不符合目前项目的具体情况，那么你就要及时调整和修改你的Solution。

楼上几位说得果然不错,收藏!

不错受教

学习

系统测试用例非常必要,而且一些准备数据的脚本也很重要.
在流程上,用例评审很重要,但是一般都没有时间或者没有合适的人去评审

受益了，谢谢！

引用:

原帖由 小小丫 于 2007-5-16 10:43 发表
我觉得还是应该让公司高层先重视起测试这块，这样测试的一些工作才能顺利的开展sdlkfj3

一点都不错，就像我现在这样，提了N多可行性建议，组长一个都没上报，郁闷啊

不错，值得学习！
一个好的测试方案对测试来说是至关重要的！！