在项目中集成测试_项目集成测试问题-CSDN博客

本文链接：https://blog.csdn.net/umewinter/article/details/109531508

在项目中集成测试

项目的开始就要做好测试的规划，如果在规划时不打算将测试和开发集成在一起，就没人做测试了；到最后就得作为一个独立的项目任务且启动晚，耗时长，延迟了开发人员得到反馈的过程
从一开始，就将减少技术债牢记心间
- 可能会先偿还技术债，要跟团队说明该目标；短期回顾，大家分享和吸收修复问题得到的经验
使用小规模测试降低风险
- 单元测试是首选， TDD是实施单元测试的最佳方式，与测试的关系更为紧密
开发人员编写代码和缺陷
- 单元测试是发现和修复缺陷最简便的方式，还可以用来阻止同样的缺陷一再发生
- 单元测试速度最快，成本最低
- 单元测试可以发现编码错误，不仅是设计环境或编译器告知的危机
- 单元测试能帮助开发人员设计系统不仅是发现缺陷，
TDD是在项目中集成测试最简便的方式
- 由内而外的开发方式，不意味着不能在一开始做设计。不过先完成非常详细的设计毫无意义，因为开发人员会让设计根据自己的累积经验不断演化
- 可以先从风险最高，或价值最高的区域开始
单元测试不是万能药
- 测试不足以完全验证所编写的代码，代码覆盖率也不能代表测试覆盖率，还有分支覆盖等
- 讲明单元测试的必要性,缺陷成本。感召大家主动进行单元测试
使用多种测试技巧
- 测试范围越广(系统级别越高），越能发现产品整体的风险；测试重点在某个功能上，就可以建设技术债
- 所有的测试，不仅仅是指测试人员的测试：单元，组件，功能，功能区域，集成，系统级别的测试
- 工作评审可以在很多层面进行，不管是负责开发还是测试

确定每个团队成员在测试中的角色

  系统测试还是需要的，如果单元测试不够；GUI很复杂； 想降低整体上的技术风险

测试人员称职吗
- 设计良好，开发完备，不需要太多维护成本的自动化回归测试，很有助于节省资金
- 一流还是二流的测试人员水平
  - 衡量标准
    - 测试人员是否经常被排除在需求或设计会议之外
    - 测试人员是不是要借助偷听的方式才能了解产品信息
    - 测试人员对于工具的需求是不是经常被推迟或忽略
    - 产品的可测试需求的建立是不是经常被推迟或忽略
    - 测试人员每人平摊的培训经费预算是不是要远少于开发人员
    - 所有测试人员是不是可以互换，即他们掌握类似的技能，谁负责哪个项目工作都无碍大局
    - 非敏捷项目是不是产品构建完成之后，测试人员才跟开发人员一起工作。没有接触更早的产品需求和设计阶段还是他们对此了解的很少，无法反馈
    - 敏捷项目，测试人员是否只跟产品负责人一起编写用例？是无法理解产品内部机制，无法跟开发人员一起开发更复杂的测试
- 一流的测试人员具有足够的创造力，编码工作之前，就能评估系统的设计和架构；编写代码过程中，测试人员会设计和实现他们的测试组件；会衡量测过的部分并评估其风险；还会思考对系统的测试是否已经到位，帮助项目经理弄清当前版本产品面临的风险；和开发人员步调一致，
- 一流测试人员和开发人员的关系是对等的，搭档而不是对手。优秀的测试人员能够改变开发人员创建产品的方式。越早发现问题，开发人员就会创造出更好的产品，拥有更多的灵活度，更愿意在其他需求和设计中加入测试人员，更愿意增加产品的可测试性
- 测试人员的能力：
  - 测试方法：边界条件测试，等价类划分，组合测试，探索测试，产品的端对端测试，而不仅仅是按需求测试；
  - 不仅仅只是发现和报告缺陷，还要将产品信息提供给整个组织
开发人员和测试人员之比应该是多少
- 根据项目情况而定，业界1：1.5 - 10:1 都有可能
- 配比时考虑的因素
  - 需求，产品规模，产品的复杂度和产品风险对该比率的影响。
    - 越复杂，测试也也复杂，测试人员需求越多
    - 产品复杂度可以从多个维度来衡量：大型系统；复杂的，实时的；API定义不完整；GUI依赖数据
  - 项目和流程风险对该比率的影响
    - 所在组织开发产品的方式，客户对于缺陷和延迟交付的忍耐程度。越是接近顺序式生命周期，项目流程的风险越大，需要的测试人员越多。包括：
      - 是否明确说明和管理需求
      - 是否知道如何随项目推进评估产品架构
      - 是否会评估每个功能的设计
      - 是否按功能逐个实现
      - 是否为进行自动化单元测试，拥有单元测试基础架构，且在使用
      - 是否有测试基础架构，供自动化系统测试使用
      - 是否进行每日构建
      - 是否会在跨职能团队中评审为解决的缺陷，以评估其影响
      - 是否拥有并使用每日构建和冒烟测试
    - 快速反馈比如TDD，单元测试，结对编程，代码复查或正式检查，需要的测试人员会减少；按功能实现，对自己的工作深入理解，所需测试人员会减少
  - 开发人员和测试人员的能力对此比率的影响
    - 开发人员能力越强，所需测试人员越少；现有测试人员能力越强，所需测试人员越少
    - 工作效率跟工作经验，自律精神，对相关只是的理解以及解决方案空间域专业知识有关
    - 与人员相关的测试风险因素考虑如下
      - 开发人员对这类产品是否有经验
      - 测试人员对这类产品是否有经验
      - 是否在开发人员的实践中构建反馈机制
      - 测试人员的能力是否有限，给开发人员提供的反馈也有限
让测试和开发同步进行，无论哪种生命周期
为项目制订测试策略比如是否需要正式的产品系统测试阶段，如何做，何时做。
系统测试策略模板包括
- 产品版本和概览
- 产品历史：之前版本历史包括缺陷历史（可体现技术债务的程度）
- 待测试功能：以最有意义的方式组织待测试的功能列表：通过用户功能或架构领域
- 不需测试功能
- 包括和排除的环境配置说明：将要测试和不需测试的硬件和软件配置，矩阵展示这些选项
- 环境需求：比如独立的网络环境，特定固件，软件等
- 系统测试方法：如何保证测试在必要时候进行，专门用来说明系统测试相关的里程碑
- 系统测试的入口条件：产品进入系统测试的最低入口条件，符合Smart原则
- 系统测试的出口条件：结束之前必须满足此处列出的条件
- 测试交付物：日志，自动化测试，计划或度量标准
- 其他参考文档
QA与测试有差别
- QA是流程改进和流程度量活动；流程改进是管理活动， QA团队人员能够改变产品开发流程
- QA具备如下特质：
  - 有权有钱，能够为开发（或技术文案，测试人员，发布工程师，业务分析师，产品过程中的任何人）提供必要的培训
  - 有权解决客户的投诉，或者推动客户投诉的处理，特别是在产品下一版需求的优先级排序过程中
  - 有权，有能力修复缺陷
  - 有权，有能力编写或重写用户手册
  - 有能力了解客户需求，并据此设计产品
  - 有能力根据多个项目度量开发过程，对比结果，并解释这些结果而无需担心
  - 有能力了解当前产品开发过程，并有权对其进行修改
- QA也许并不会直接做这些，但有能力安排相关的人力和工作