zhifei.xie 发表于 2012-8-10 11:37:37

项目中需求欠完整,测试人员的尴尬境地 你有吗?

引子:工作中你有遇到过需求不完整,在测试过程中经常向项目负责人确认系统业务逻辑的细节的情况么?我相信多数人都有过吧........现在就软件质量的那些事说说吧。


在最近的系统测试中,遇到一个很尴尬的问题是 在测试过程中发现系统中的很多业务逻辑没有考虑到 或者是业务逻辑是错误的! 发现了大量此类的严重Bug。功能点基本是实现了,但是其数据的来源基本是错误的;导致 系统中很多数据错误!比如财务结算中的数据错误! 项目主管对此现象也不闻不问。
能够理解,因为需求文档本来就是 项目主管自己写的,需求文档简洁难懂,一句简短的语句是无法完整、明了地描述一个功能点的内部逻辑的!程序员拿着需求文档就中规中矩地把任务完成了,其中的具体细节相关文档中没有体现(程序员这样把任务完成了 也能够理解,毕竟你文档怎么写 我就怎么完成是没错的)结果测试人员 测试后 才发现很多功能点都需要返工,返工率是何其的高!

面对这种情况,个人也只能把 发现的Bug记录在JIRA上 并及时反馈给开发人员;想对系统开发提点意见,但反过来想想 提建议 稍有不慎,可能就会把自己置于 开发和测试的对立面中!

目前内部的测试状况是:需求文档仅仅包括了系统中有哪些功能点和基本的业务流程。业务中的功能点详细逻辑规则完全没有涉及到。测试时开发人员提供了测试版本就测试,不管是否达到可测的水平;由于项目较多 有时1个人跟进2个系统;在此情况下 无法编写有效、高质量的测试用例(原因:1、没有实际参考意义的需求文档,写出来的测试用例个人认为是无效的 2、项目多且时间紧, 把时间耗在“无意义”的用例上 还不如多去熟悉系统的核心功能点中的 业务逻辑细节和功能数据走向)。备注:非有效、非高质量的case被看作 无意义的用例。高质量的case重点包括 业务逻辑校验、功能点数据取值是否准确、刷新方式是否正确。........

对软件质量的提高提出个人的几点拙见:
1)在软件开发过程中 需求评审是关键到整个项目成败的一个关键因素,尽管每次需求评审都是那么轻松、简单地通过了(实际上这里的需求评审 只是项目主管大致讲解了下这个系统的功能点,业务细节完全没有涉及到;需求评审个人理解只是个形式),可是 需求说明书这个文档 如果不能够 重点、清晰明了 地展现 整个系统中的核心功能模块的 详细业务逻辑,此需求文档还不如不做,好歹也浪费了那么多的时间。小结:
一份完整、简洁明了、详尽的 需求文档 对程序员考虑业务逻辑校验大有裨益,为测试人员测试核心业务逻辑时 提供一个有意义的参考。

2)开发人员的代码质量 关系着 系统的质量,开发人员在开发前 就应该充分透彻地掌握 功能点的业务逻辑,确保在 基本功能完成后 发现业务逻辑未校验,或者数据来源错误 再去 返工;这样的代价太大了,长此以往 代码越改越不想改 越不想改 由修改产生的Bug越多!
小结:开发人员在开发前确保透彻掌握功能点的业务逻辑,减少返工。

3)测试人员 能否发现有意义的Bug的前提取决于 对系统中业务逻辑的掌握,在掌握业务逻辑的基础上 测试人员的 测试思维和方法 对发现有价值的Bug起着 关键的作用。
小结:透彻掌握业务逻辑的基础上,测试思维和方法 是保证测试效率的最有效方法。

4)开发模式和 测试模型 对项目的质量、开发周期起着 举足轻重的作用,一个好的开发模块可以减少项目的多次返工和项目周期延迟。不管 瀑布模型、螺旋模型、还是敏捷开发,选择一种适合公司内部的开发模型并在 此模型上加以改进 是缩短项目周期、提高软件质量的一个重要手段。
小结:选择合适的开发模型和测试模型。

5)管理制度的约束俗话说:“无规矩不成方圆!”在软件开发过程中,我们也同样遵循一个有效的管理制度。个人的理解是 对每个岗位 每个人的职能要 划分明确,并且在工作中要敢于担当。在不损害大多数人员利益的基础上 需要有相应的奖罚制度!
小结:工作中管理制度 是提升管理者对 各个工作岗位监督的最有效办法。

6)在适合公司的前提下,制定cmmi或ISO之类的软件质量管理体系是提升整体项目质量的一个有效保障!随着现代系统的需求越来越庞大、业务逻辑越来越复杂,项目管理成了 管理层都头痛的一个问题,“软件危机”不再是一个新名词!
小结:根据公司的情况,建议制定适合自己公司的 质量管理体系 提高软件质量、缩短项目周期、降低项目成本!


欢迎大家来讨论 这个话题,本人不才 以上观点并不一定准确、全面! 请前辈们给予指正、批评!

futogether 发表于 2012-8-21 10:45:45

质量并不是光靠测试保证的,应该是整个项目团队共同保证的。

zhifei.xie 发表于 2012-9-28 16:43:00

测试自己的工作都没去做好,你还谈屁的质量保证!.................

无花果果糖 发表于 2012-10-8 14:09:09

遇到过这样的问题

chxiang12091 发表于 2012-11-1 16:26:10

经常遇到,我们基本是没什么需求文档的。
    不过,我是在开发人员做开发的时候,就去整理、理解需求,然后遇到不明白或者感觉不合理的就找开发,找需求,有的时候,确实会因为这些反馈而稍微调整设计。而且,并没有因为这和需求、开发的关系处得不好,反而觉得他们更支持、理解我的工作了。有的时候把测试用例发给他们看,他们会根据这些发现有的可能他们确实考虑得不够细,会发现原来测试考虑的东西那么多。大家的合作反而挺好的。
    在自己理解需求的时候,就将一些重要的功能点或者逻辑很复杂的记录下来,测试的时候也不容易漏掉。以前我也觉得写用例浪费时间,后来觉得反正开发没做出来,就写吧,然后写出来用例之后,发现测试的时候,根据写的去测,不用现去考虑,蛮有效果的。
    所以,现在需求一出来,我就会去整理,写用例。
    现在有一种思想,不就是测试推动开发么?先写单元测试代码,然后再去做开发。我觉得是测试不光是只测开发做的,还得测需求、设计,如果需求和设计不合理,咱也可以给他们否了。
    这些只是个人看法哈,别拍我脑袋就行~~

lavender2004 发表于 2012-11-29 11:18:06

回复 5# chxiang12091


很赞同!
测试确实是要在前期就参与进来的。。这样能更多了解、把握需求。不过很多公司都是开发完了再把任务丢给测试,,测试人员往往还需要开发人员讲解需求。。这样太不可取了

archonwang 发表于 2012-11-30 15:59:25

回复 5# chxiang12091

在项目中,往往受到时间、资金、人员方面的约束。

一般成熟的测试人员会先约定做哪些工作,再约定工作项的次序。

姑夫子制 发表于 2013-2-24 09:54:08

第一:稳步增加外链。外链为皇的说法,站长们都知道,新站一上线或是在买了域名往后,就初步给网站增加外链,前进域名权重,这样的做法是对的,但这要提示下我们,不要堆集的增加网站外链,特别是新站,外链增加太快,反而会被搜索引擎认为是作弊的方法,然后遭到K站就不好了。具体的关于网站急剧增加的外链带来的利于弊,我们可参看看下。外链是要多做,可是要稳步的增加,一步一步找到权重高的,安稳的外链,这样网站的运营情况才华耐久的坚持下去。

第二:外链相比较选择。有站长会常常问,论坛签名外链和博客留言外链,终究那个外链会权重高。这2个外链是无法比较的,权重都是不高的,可是要是真的让站长们去选择,仍是要选择博客留言的外链,论坛签名的外链不保险,而且论坛中灌水的东西实在是太多,基本上不是给你的网站带来啥流量。可是博客留言就不相同,和博主相互间的沟通,1.可以打造一个品牌的力气,2.可以前进自己的人脉,3.可以给网站带来许多IP。许多会有人点击论坛签名外链,所以论坛签名的外链仍是少做为妙。www.beijing05.com

第三:选择内容相关途径。互联网的展开,网络上的网站途径一应俱全,不相同类型的网站途径都初步上线。只要是一个新的途径,站长们都可以考虑拿来做外链,但并不是说所有的途径都适宜我们去做,站长们应该要找和自己网站内容相似的途径留外链,这不仅是条外链,也是可以给网站带来流量的。内容相关性也可以增加网站权重,高权重的一些网站你去留外链,收录了就是一条安稳的高权重相关性外链,一同也能前进网站的用户领会。www.beijing02.com

第四:选择途径权重。如今能发布外链的途径真的是许多的,关于站长们来说,去这些途径花费时辰,就是要它的外链能有效果,没效果的没权重的途径,站长们可以忽略不计了。这些途径中权重高的途径也是许多的,论坛类的可以选择掉队,站长百科等;问答类的可以选择baidu知道和腾讯问问;软文站点类可以选择A5和chinaz等;不相同的领域类,都有些权重比较高的途径,权重高的途径中留外链,站长们的得到的外链权重也相对高点,这样不至于在搜索引擎更新时,会俄然掉了许多,推行网站运营。www.beijing03.com

第五:寻找高质量友链。友链也是网站获得外链的重要来历,在找友链过程中也有许多要注意的,网站的相关性,对方网站的运营情况,网站的权重,对方网站的友链情况等等,这些都是要在沟通过程中要注意到的。友链的沟通中还有个作业就是前进关键词的权重,在沟通衔接的时分,最棒是找相关的网站沟通网站的主关键词。有权重的外链,才是站长们做外链的结束目的。
页: [1]
查看完整版本: 项目中需求欠完整,测试人员的尴尬境地 你有吗?