质量保证如何适应软件开发的设计阶段？
在设计阶段完成了哪些（如果有的话）质量保证活动？
答案 0 :(得分：8)
QA在设计阶段可以做的最有用的事情是确保提供的规范有一套清晰，可测试的目标。并使用这些目标来制定测试计划。
这样他们就可以回答两个非常重要的问题：“可以测试”和“测试需要多长时间”。第一个是确保每个人都知道项目完成标准的重要性。第二个是必要的，因为它构成了实施总体成本的一部分。
答案 1 :(得分：2)
好的设计是可测试的设计。 IMO，人们需要始终考虑即使在设计阶段也会如何测试软件。当然，所需的关注程度取决于您是在进行详细设计还是高级架构。使用诸如TDD之类的方法将强调关注设计期间测试的重要性。当然，不应忽视质量保证的其他方面，如可用性测试，性能测试等。这些也是设计过程中需要考虑的重要因素 - 如何实现目标以及如何评估目标是否实现。
答案 2 :(得分：2)
设计阶段： 设计过程中缺乏质量会使良好的需求规范无效，并且无法实现正确的实施。 行业实践表明，在设计过程中使用检查表有助于提高设计质量
我们是否已满足SRS中提到的所有要求？ SRS是否已置于文件控制之下？ 在设计过程中是否解决了与以下功能相关的要求？ 性能，安全性，并发性，可用性，可移植性，可测试性，语言/ DB / OS /硬件要求，开发环境，兼容性，遵守行业标准，可伸缩性，异常处理
选择的设计方法是否适合要开发的软件项目类型。 明晰： 设计文档是否清晰/明确？ 他的设计能否在技术上合理化 与现有软件的兼容性 确定了此设计对现有软件的影响 我们做过影响分析吗？ 这种设计是否依赖于其他软件的副作用？ 这种设计是否依赖于任何其他相关设计？
组件级别： 接口是否定义良好？ 是否定义了主要数据结构 是否定义了主要算法 是否定义了数据/控制流 数据结构和算法 是否定义了数据结构 是否定义了数据结构的访问方法？ 是否定义了算法？ 数据结构和算法是否解决了问题
错误/异常处理 是否处理了数据类型错误？ 软件是否验证用户输入？ 如果发生错误，软件是否会提供明确的，无威胁的消息？ （错误消息的质量）。 错误后可以从任何点重启软件吗？ 软件是否能够正常处理异常情况，例如访问冲突和浮点错误。
程序接口 实际参数的数量是否与形式参数的数量相匹配？ 实际参数的类型和大小是否与形式参数的类型和大小相匹配？ 我们是否正确指定了本地和全局函数？ 是否跨模块定义和使用全局变量？ 是否记录了所有通信（即参数和共享数据）？
程序级别 该程序是否与现有程序非常相似？ 是否有一个库程序可以做同样的事情？ 程序是否过于复杂 程序是否可以分解为单独的，更合乎逻辑的部分。 程序是否可接受？
该程序只做一个合乎逻辑的事情吗？ 该过程是否依赖于过程范围静态变量？ 该程序是否易于维护和直接引用？ 程序可以轻松测试吗？ 是否描述了副作用？
质量 是否规定了设计目标（可靠性，灵活性，可维护性，性能等）？ 设计是否满足其既定目标？ （可追溯性要求） 是否有证据表明考虑了多个设计方案？ 是否列出了几个设计选项以及采用或拒绝的原因？ 是否说明了设计假设 是否说明了设计权衡 设计效率高吗？ 设计是否可维护？ 设计便携吗？ 设计能否以最小的修改处理外部环境的变化？ 是设计参数驱动还是在程序中硬编码的值。
要求 设计是否满足所有要求？ 设计和系统规格之间是否有可追溯性？ 设计能否满足开发成本要求？ 可以在给定的时间范围内完成吗？ 设计是否符合要求内存限制 设计是否保持在所需的磁盘使用限制范围内 设计是否满足响应时间要求？ 设计是否会处理预期的交易率？ 设计是否会处理预期的数据流量？
答案 3 :(得分：1)
质量保证根本不适合设计阶段。 QA是关于在发生缺陷之后修复缺陷，这是上一个千年中常见的做法。当然，在设计过程中产生的规范文档可能存在缺陷，但除了那些没有产品的产品之外，没有缺陷可以找到。
另一方面，质量管理是21世纪的发展方向。它是缺陷预防的综合方法。从一开始就将它集成到您的项目中至关重要，因此它必须适合设计。
关于这个主题有成千上万的书籍和网页，但IMO最重要的是：
答案 4 :(得分：1)
建筑设计阶段和详细设计阶段都很粗糙。
这些阶段的质量保证活动可能包括：
这有时被称为“软件质量关键设计评论”。您可以查看示例清单here。
答案 5 :(得分：1)
要了解它如何适合您的特定开发过程，您必须考虑：