6

质量保证如何融入软件开发的设计阶段？

在设计阶段进行了哪些（如果有）质量保证活动？

4

6 回答 6

8

QA 在设计阶段可以做的最有用的事情是确保提供的规范具有一组清晰、可测试的目标。并使用这些目标来制定测试计划。

这样他们就可以回答两个非常重要的问题：“这可以测试吗”和“测试需要多长时间”。首先是确保每个人都知道项目完成的标准很重要。第二个是必要的，因为它构成了实施总成本的一部分。

于 2009-03-23T12:13:52.403 回答
2

设计阶段：设计过程中缺乏质量会使良好的需求规范失效，并可能使正确的实施变得不可能。行业实践表明，在设计过程中使用清单有助于提高设计质量

我们是否解决了 SRS 中提到的所有要求？SRS 是否已置于文件控制之下？在设计过程中是否解决了与以下功能相关的要求？性能、安全性、并发性、可用性、可移植性、可测试性、语言/数据库/操作系统/硬件要求、开发环境、兼容性、遵守行业标准、可扩展性、异常处理

选择的设计方法是否适合要开发的软件项目类型。清晰性：设计文档是否清晰/明确？他的设计是否在技术上是合理的 与现有软件的兼容性 是否已确定该设计对现有软件的影响 我们是否进行了影响分析 该设计是否依赖于其他软件的副作用？该设计是否依赖于任何其他相关设计？

组件级别：接口是否定义良好？是否定义了主要数据结构 是否定义了主要算法 是否定义了数据/控制流 数据结构和算法 是否定义了数据结构 是否定义了对数据结构的访问方法？是否定义了算法？数据结构和算法能解决问题吗

错误/异常处理 是否处理数据类型错误？软件是否验证用户输入？如果发生错误，软件是否会给出明确的、非威胁性的消息？（错误消息的质量）。软件出现错误后可以从任意点重新启动吗？软件是否优雅地处理异常情况，例如访问冲突和浮点错误。

过程接口 实际参数的数量是否与形式参数的数量相匹配？实参的类型和大小是否与形参的类型和大小匹配？我们是否正确指定了局部和全局函数？全局变量是否跨模块一致地定义和使用？是否记录了所有通信（即参数和共享数据）？

过程级别 过程是否与现有过程非常相似？是否有一个库程序可以做同样的事情？程序是否过于复杂 能否将程序分解成独立的、更符合逻辑的部分。程序的大小是否可以接受？

该过程是否只做一件合乎逻辑的事情？该过程是否依赖于过程范围静态变量？该程序是否易于维护和正确引用？该程序是否易于测试？是否描述了副作用？

质量 是否规定了设计目标（可靠性、灵活性、可维护性、性能等）？设计是否满足其既定目标？（需求的可追溯性）是否有证据表明考虑了多个设计选项？是否列出了几个设计选项以及采用或拒绝的原因？是否规定了设计假设 是否规定了设计权衡 设计是否有效？设计是否可维护？设计是否便携？设计能否以最少的修改处理外部环境的变化？是设计参数驱动还是程序中硬编码的值。

要求 设计是否满足所有要求？设计和系统规范之间是否存在可追溯性？设计能否满足开发成本要求？能否在规定时间内完成？设计是否符合要求的内存限制 设计是否符合要求的磁盘使用限制 设计是否满足响应时间要求？设计能否处理预期的交易率？设计能否处理预期的数据流量？

于 2009-03-25T19:14:07.930 回答
2

好的设计是可测试的设计。IMO，即使在设计阶段，人们也需要始终考虑如何测试软件。当然，所需的关注程度取决于您是在进行详细设计还是高级架构。使用诸如 TDD 之类的方法将迫使人们关注设计期间测试的重要性。当然，不应忽视 QA 的其他方面，例如可用性测试、性能测试等。这些也是设计过程中需要考虑的重要因素——如何实现目标以及如何评估目标是否实现。

于 2009-03-23T12:11:50.147 回答
1

质量保证根本不适合设计阶段。QA 是在缺陷发生后对其进行修复，这是上个千年的普遍做法。当然，在设计过程中产生的规范文件中可能存在缺陷，但除了那些你还没有产品的缺陷，因此没有缺陷可查。

另一方面，质量管理是 21 世纪的必经之路。它是一种综合的缺陷预防方法。从一开始就将其集成到您的项目中至关重要，因此它绝对必须适合设计。

关于这个主题有成千上万的书籍和网页，但 IMO 最重要的是：

  1. 从早期的错误中吸取教训。分析类似的项目，看看那里犯的最大错误是什么。尽量在你的项目中避免它们。
  2. 项目完成后，进行事后审查，找出上述步骤 1 中遗漏的内容。在下一个类似项目中使用该信息。
于 2009-03-23T12:22:03.490 回答
1

大致有一个架构设计阶段和一个详细设计阶段。

这些阶段的质量保证活动可能包括：

  • 确保架构支持所有（非）功能需求
  • 确保在详细设计中涵盖并正确设计所有重要模块
  • 确保设计文档处于配置（变更）管理之下
  • 进行（正式）审查以审查架构及其文档
  • 确保遵循预定义的设计标准

这有时被称为“软件质量关键设计评审”。您可以在此处查看示例清单。

于 2009-03-23T12:22:11.760 回答
1

要了解它如何适合您的特定开发过程，您必须考虑：

  • 产品质量是整个团队的责任。每个角色组都必须为项目带来相应的价值（如果您觉得缺少某些技能，请为项目带来帮助）。不要让质量团队进行那些/应该是同行评审的活动，即架构/设计评审。
  • QA 不是你丢掉项目中任何缺失责任的地方，即项目管理应该关心预算、风险等。这个角色的责任是确保所有这些都到位。除此之外，您还可以使用审核+指导来帮助每个团队成员履行职责。
  • QA 确实对架构/设计做出了贡献，因为他们认为架构/设计应该是可测试的。他们积极考虑/计划/设计他们将如何测试所述架构/设计，这是进行有效/成功测试工作的重要因素。
  • QA 为各种工件做出了贡献，就像开发方面一样。始终关注它与他们想要实现的目标的关系。
  • QA 需要准备从开发开始就开始测试自动化。这还涉及与开发人员和计划的重要协调，以便使用允许 QA 团队持续/逐步进行测试自动化的开发方法。
  • 就像开发活动的范围/优先级一样，QA 团队也必须这样做。在一个项目中可以完成的测试有很多变体，以至于不可能在完全覆盖的情况下真正完成所有测试。这将影响项目中的 QA 工作，并且还有助于明确在 QA 团队方面遗漏了哪些内容（可能会采取其他措施来解决其他角色的问题）。
  • 活动的完成方式/时间与所使用的流程和实践密切相关。一个简化是：如果您涉及开发活动/工作，那么质量检查工作也应该进行一些有意义的事情。
  • 不同方法中的大多数角色和活动都是为了增加项目质量和相关产品的不同方面。
于 2009-03-25T17:07:53.803 回答