给经理关于测试方案及测试用例的建议

jackleipm

国内的测试水平关注程度不够高是现实，大家要坚持。

sangrou

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

你应该先做出点成绩来,给大家看.还有不断的加长buglist,这样开发还是有压力的...老大看到你的成绩才能支持你呀.

sangrou

定期汇总buglist,因为项目有移植代码,很多的项目有共同的bug,修复的过程浪费了很大的人力资源,抄份给老大,他会去思考的.老大比你更清楚软件质量的重要性
楼主最好的办法是先实行后建议...

[ 本帖最后由 sangrou 于 2007-12-10 18:23 编辑 ]

Wheatlee

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

楼主，你说的这两个我早在1年前就尝试过的。一般bug库是大家都有的。测试用例库当初是我自己开发（asp.net + sqlserver 2005）。

但是，效果呢？我觉得只能用一句话说明“看起来很美”。 尤其是测试用例库。需求变化了，会导致很多测试用例根本就是无效的。如果你建立一个公用的测试用例库，你会发现你需要修改清理很多公用的测试用例，这样时间会占用很多。你的初衷是将很多基本，复用性高的测试用例存起来供大家使用。但是测试用例本身就在变化，所以你这样的“封装”是无用的。
至于bug库，我倒觉得你可以这么做。找出bug是如何被发现的。是测试人员在测试中随意测出来的，还是用户日积月累后发现，是根据测试用例发现的，还是别的什么因素发现的。然后你要统计，将测试人员的随意变成你们的测试方法论。而且，通过统计，你能发现你们的测试用例是否真的有效。如果无效，你需要跟整个测试组去找出无效的原因。

呵呵，楼主，这只是个人观点。如有冒犯或者说的不对的地方，望指出：）

msnshow

同意楼上的说法，BUG库的确很重要，就拿我们公司来说，没有好好利用BUG库，每次送测的新的应用都存在着以前提过的类似的BUG

（因为我们的应用很多，又是不同的开发人员负责，在上一个应用中遇到的问题，在下一个应用中还会有）如果好好的整理BUG，让每个开发人员都知道，他们在开发的时候就会注意，就减少出现类似BUG的机率，从而减少测试的工作量!

testman

想法挺好，执行很难，

r_sunny

境况类似....唉,执行起来太不易了

11ling

学习了

free_xiaoyu

我觉得大家天天都在说重视测试，但是对于测试，大多数人还是处于初级认识阶段，关键是看公司领导对测试是否有更新的认识，当认识多了，也就重视起来，测试也就有了最大的保证，不过就国内现状，还得等待。

takiro

想法都不错，应用性不高。
bug库的整理还是有必要的，将重复出现的bug找出来并归结原因，在测试组内建立自己的检查表是有一定的指导意义的。也可以将该表转化为项目组其他成员可用的形式发出。
至于说测试案例的评审希望项目组全体参加，这个基本上不可能，如果是业务逻辑复杂的应用，拉整个项目组的时间来做评审，项目组成员答应老板也不会答应。控外不如控内，关键是让手下的测试人员多熟悉系统架构和应用需求。
测试用例的复用，个人建议是针对核心模块（保证正常流程的一定要写）来做测试用例的编写，外部的功能或表现实现结合用检查表的形式进行检查，一；充分保证80%的缺陷在20%的代码中发现，二；提高测试效率，减少无谓的用例维护和测试时间。

vicky_yan

收藏,学习

leo_hu_100

测试用例如果没时间全部评审的话，可以列出一些测试点来评审，把测试用例的位置放到只是对于测试点内容的细化上，这样我想对于BA，Dev应该可以节省更多的时间。

naonao

不错,支持!

数码宝贝

原帖由 刘洪鹏 于 2007-7-12 17:15 发表
测试方案和测试计划你认为那个重要啊 ?

aaaa

数码宝贝

我

数码宝贝

支

数码宝贝

持

hxf

现在，测试没这么正规。项目需求评审的很少。并且，在时间不充裕的情况下，不写测试用例。就直接凭借测试人员积累的经验，直接执行测试。

linuxsky2008

其实很多东西都要从实际出发，楼主说的建议确实不错，但也要分公司，还有什么重要什么不重要，没有开始哪来结束，所以测试计划和测试方案都很重要，只是阶段不同

yaozhongji

对楼主的想法很认同，正在想同样的问题。
测试用例有两种：
一种是操作结果可保存的，这种测试尽量用自动化测试。
一种是操作结果不可保存的，是一种过程测试，需要手动测试。
自动化测试的执行能够很大程度的提高工作效率，保证测试质量。避免回归测试的疏忽。

测试没有不变的规则，不同行业，不同软件的测试是灵活的。