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

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

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

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

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

　　对软件质量的提高提出个人的几点拙见：

　　1）在软件开发过程中 需求评审是关键到整个项目成败的一个关键因素，尽管每次需求评审都是那么轻松、简单地通过了（实际上这里的需求评审 只是项目主管大致讲解了下这个系统的功能点，业务细节完全没有涉及到；需求评审个人理解只是个形式），可是 需求说明书这个文档 如果不能够 重点、清晰明了 地展现 整个系统中的核心功能模块的 详细业务逻辑，此需求文档还不如不做，好歹也浪费了那么多的时间。

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

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

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

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

　　小结：透彻掌握业务逻辑的基础上，测试思维和方法 是保证测试效率的有效方法。

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

　　小结：选择合适的开发模型和测试模型。

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

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

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

　　小结：根据公司的情况，建议制定适合自己公司的 质量管理体系 提高软件质量、缩短项目周期、降低项目成本！


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