项目中需求欠完整，测试人员的尴尬境地 你有吗？
引子：工作中你有遇到过 需求不完整，在测试过程中经常向 项目负责人确认系统业务逻辑的细节的情况么？我相信多数人都有过吧........现在以提高项目质量为核心出发点来谈谈一些看法！
在最近的系统测试中，遇到一个很尴尬的问题是 在测试过程中发现系统中的很多业务逻辑没有考虑到 或者是业务逻辑是错误的！ 发现了大量此类的严重Bug。功能点基本是实现了，但是其数据的来源基本是错误的；导致 系统中很多数据错误！比如财务结算中的数据错误！
能够理解，因为需求文档编写的时间有限 有时间原因 也有其它原因，需求文档虽然简洁，一句简短的语句是无法完整明了地描述一个功能点的内部逻辑的！程序员拿着需求文档就中规中矩地把任务完成了，其中的具体细节文档中没有体现（程序员这样把任务完成了 也能够理解，毕竟你文档怎么写 我就怎么完成是没错的） 结果测试人员 测试后 才发现很多功能点都需要返工，返工率是何其的高！
面对这种情况，个人也只能把 发现的Bug记录在JIRA上 并及时反馈给开发人员；是否对系统开发提点意见，但反过来想想 提建议 稍有不慎，可能就会把自己置于 开发和测试的对立面中！
对软件质量的提高提出个人的几点拙见：
1）在软件开发过程中 需求评审是关键到整个项目成败的一个关键因素，尽管发现每次需求评审都是那么轻松、简单地通过了，可是 需求说明书这个文档 如果不能够 重点、清晰明了 地展现 整个系统中的核心功能模块的 详细业务逻辑，此类需求文档需要加大力度去完善，好歹也浪费了那么多的时间。
小结：一份完整、简洁明了、详尽的 需求文档 对程序员考虑业务逻辑校验大有裨益，为测试人员测试核心业务逻辑时 提供一个有意义的参考。
2）开发人员的代码质量 关系着 系统的质量，开发人员在开发前 就应该充分透彻地掌握 功能点的业务逻辑，确保在 基本功能完成后 发现业务逻辑未校验，或者数据来源错误 再去 返工；这样的代价太大了，长此以往 代码越改越不想改 越不想改 由修改产生的Bug越多！
小结：开发人员在开发前确保透彻掌握功能点的业务逻辑，减少返工。
3）测试人员 能否发现有意义的Bug的前提取决于 对系统中业务逻辑的掌握，在掌握业务逻辑的基础上 测试人员的 测试思维和方法 对发现有价值的Bug起着 关键的作用。
小结：透彻掌握业务逻辑的基础上，测试思维和方法 是保证测试效率的最有效方法。
4）开发模式和 测试模型 对项目的质量、开发周期起着 举足轻重的作用，一个好的开发模式可以减少项目的多次返工和项目周期延迟。不管 瀑布模型、螺旋模型、还是敏捷开发，选择一种适合公司内部的开发模型并在 此模型上加以改进 是缩短项目周期、提高软件质量的一个重要手段。
小结：选择合适的开发模型和测试模型。
5）管理制度的约束俗话说：“无规矩不成汤圆！”在软件开发过程中，我们也同样遵循一个有效的管理制度。个人的理解是 对每个岗位 每个人的职能要 划分明确，并且在工作中要敢于担当。在不损害大多数人员利益的基础上 需要有相应的奖罚制度！
小结：工作中管理制度 是提升管理者对 各个工作岗位监督的最有效办法。
6）在适合公司的前提下，制定cmmi或ISO之类的软件质量管理体系是提升整体项目质量的一个有效保障！随着现代系统的需求越来越庞大、业务逻辑越来越复杂，项目管理成了 管理层都头痛的一个问题，“软件危机”不再是一个新名词！
小结：根据公司的情况，建议制定适合自己公司的 质量管理体系 提高软件质量、缩短项目周期、降低项目成本！
欢迎大家来讨论 这个话题，本人不才 以上观点并不一定准确、全面! 请前辈们给予指正、批评！
没有详细的需求的情况很常见 遇见过，真是太恼火了， 经常的事 题外话，在文章里我看到“无规矩不成汤圆”这句话 ;P 楼上是做测试的，的确能找到问题 正在这种痛苦中煎熬。。。 谢谢分享 许多东西都看公司的软件开发成熟度，规范、过程。中国那有那种公司那，很少能按照软件开发过程走的，大多都是半成品就给用户了，你能指望个什么？业务专家。。。，就和别人喝了几次酒，访谈了几次，就出回家写文档，你真的想多了、、、、、、、、
页:
[1]
