项目中需求欠完整，软件测试人员的尴尬境地你有吗？

"_M*Ns{7c0　　引子：工作中你有遇到过需求不完整，在测试过程中经常向项目负责人确认系统业务逻辑的细节的情况么？我相信多数人都有过吧........

　　在最近的系统测试中，遇到一个很尴尬的问题是在测试过程中发现系统中的很多业务逻辑没有考虑到或者是业务逻辑是错误的！发现了大量此类的严重Bug。功能点基本是实现了，但是其数据的来源基本是错误的；导致系统中很多数据错误！比如财务结算中的数据错误！项目主管对此现象也不闻不问。51Testing软件测试网&}APN$})c$p_)Q H

　 　能够理解，因为需求文档本来就是项目主管他自己写的，需求文档简洁难懂，一句简短的语句是无法完整明了地描述一个功能点的内部逻辑的！程序员拿着需求文 档就中规中矩地把任务完成了，其中的具体细节文档中没有体现（程序员这样把任务完成了也能够理解，毕竟你文档怎么写我就怎么完成是没错的）结果测试人员测 试后才发现很多功能点都需要返工，返工率是何其的高！

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

　　对软件质量的提高提出个人的几点拙见：51Testing软件测试网4B3bO2Sk!so

　　1）在软件开发过程中需求评审是关键到整个项目成败的一个关键因素，尽管发现每次需求评审都是那么轻松、简单地通过了，可是需求说明书这个文档如果不能够重点、清晰明了地展现整个系统中的核心功能模块的详细业务逻辑，此需求文档还不如不做，好歹也浪费了那么多的时间。51Testing软件测试网4fLU b#E8{%Cv

　　小结：一份完整、简洁明了、详尽的需求文档对程序员考虑业务逻辑校验大有裨益，为测试人员测试核心业务逻辑时提供一个有意义的参考。

　　2）开发人员的代码质量关系着系统的质量，开发人员在开发前就应该充分透彻地掌握功能点的业务逻辑，确保在基本功能完成后发现业务逻辑未校验，或者数据来源错误再去返工；这样的代价太大了，长此以往代码越改越不想改越不想改由修改产生的Bug越多！51Testing软件测试网"Z]1\_%U/Vr

Po|jB"D0　　小结：开发人员在开发前确保透彻掌握功能点的业务逻辑，减少返工。

　　3）测试人员能否发现有意义的Bug的前提取决于对系统中业务逻辑的掌握，在掌握业务逻辑的基础上测试人员的测试思维和方法对发现有价值的Bug起着关键的作用。51Testing软件测试网In/O V8zeGm(V X

I+KFos.|0　　小结：透彻掌握业务逻辑的基础上，测试思维和方法是保证测试效率的最有效方法。51Testing软件测试网}n S?I1y a S(l*\

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

KPj bh5G'J0　　小结：选择合适的开发模型和测试模型。

　　5）管理制度的约束俗话说：“无规矩不成汤圆！”在软件开发过程中，我们也同样遵循一个有效的管理制度。个人的理解是对每个岗位每个人的职能要划分明确，并且在工作中要敢于担当。在不损害大多数人员利益的基础上需要有相应的奖罚制度！

　　小结：工作中管理制度是提升管理者对各个工作岗位监督的最有效办法。

　　6）在适合公司的前提下，制定cmmi或ISO之类的软件质量管理体系是提升整体项目质量的一个有效保障！随着现代系统的需求越来越庞大、业务逻辑越来越复杂，项目管理成了管理层都头痛的一个问题，“软件危机”不再是一个新名词！51Testing软件测试网k,FxZ h.wfN)e

　　小结：根据公司的情况，建议制定适合自己公司的质量管理体系提高软件质量、缩短项目周期、降低项目成本！51Testing软件测试网,k)g)Z@'w:| n`

n%s W rR!C%P0　　欢迎大家来讨论这个话题，本人不才以上观点并不一定准确、全面！请前辈们给予指正、批评！51Testing软件测试网2Ql OH^

版权声明：本文出自 zhifei.xie 的51Testing软件测试博客：http://www.51testing.com/?25453651Testing软件测试网p's};v/V;Tz