测试流程梳理

测试流程梳理思维导图：包含阅读相关技术文档，参加需求评审会议，根据最终确定的需求文档编写测试计划（根据需求情况再定）等等

测试流程

• 1、阅读相关技术文档；
  • 技术文档有哪些？
    • 如需求文档、UI设计、产品流程图等。
  • 如何熟悉需求文档？
    • Who：谁要这个功能？When：何时用到这个功能？Where：在哪里使用这个功能？What：这个功能是用来做什么？Why：为何要用到这个功能？How：如何实现这个功能？
  • 为什么要熟悉需求文档？
    • 测试人员拿到需求、设计文档后，应积极地与需求、设计人员进行沟通确认，并及时地提出自己对相关文档的疑问，这样做的好处一方面在于帮助测试人员充分理解需求，以保证设计全面、正确的测试用例;另一方面在于帮助需求、设计人员找出文档中不完善甚至错误的地方，以便尽早解决，这样就降低了后续过程中的风险和成本，也缩短了研发的工作进度。
• 2、参加需求评审会议；
  • 参与人员有哪些？
    • 需求提出人、开发、测试
  • 测试人员需要干什么？
    • 不清楚的就问！搞清楚为止！
• 3、根据最终确定的需求文档编写测试计划；（根据需求情况再定）
  • 测试计划的目的?
    • 借助软件测试计划，参与测试的项目成员，尤其是测试管理人员，可以明确测试任务和测试方法，保持测试实施过程的顺畅沟通，跟踪和控制测试进度，应对测试过程中的各种变更。
  • 测试计划编写6要素？
    • why—为什么要进行这些测试；what—测试哪些方面，不同阶段的工作内容；when—测试不同阶段的起止时间；where—相应文档，缺陷的存放位置，测试环境等；who—项目有关人员组成，安排哪些测试人员进行测试；how—如何去做，使用哪些测试工具以及测试方法进行测试
  • 测试计划包含哪些内容？
    • 1、 测试目标：对测试目标进行简要的描述。2、 测试概要：摘要说明所需测试的软件、名词解释、以及提及所参考的相关文档。3、 测试范围：测试计划所包含的测试软件需测试的范围和优先级，哪些需要重点测试、哪些无需测试或无法测试或推迟测试。4、 重点事项：列出需要测试的软件的所有的主要功能和测试重点，这部分应该能和测试案例设计相对应和互相检查。5、 质量目标：制定测试软件的产品质量目标和软件测试目标。6、 资源需求：进行测试所需要的软硬件、测试工具、必要的技术资源、培训、文档等。7、 人员组织：需要多少人进行测试，各自的角色和责任，他们是否需要进行相关的学习和培训，什么时候他们需要开始，并将持续多长时间。8、 测试策略：制定测试整体策略、所使用的测试技术和方法。9、 测试进度和任务人员安排：将测试的计划合理的分配到不同的测试人员，并注意先后顺序.如果开发的进度不确定，可以给出测试的时间段，对于长期大型的测试计划，可以使用里程碑来表示进度的变化。10、 测试开始/完成/延迟/继续的标准：制定测试开始和完成的标准；某些时候，测试计划会因某种原因(过多阻塞性的Bug)而导致延迟，问题解决后测试继续。11、 风险分析：需要考虑测试计划中可能的风险和解决方法。
• 4、编写测试用例；
  • 编写测试用例的方法有哪些？
    • 1、等价类划分法
      • 有效等价类：指符合《需求规格说明书》，输入合理的数据集合
      • 无效等价类：指不符合《需求规格说明书》，输入不合理的数据集合
    • 2、边界值分析法
      • 有效
      • 无效
    • 3、判定表驱动法
    • 4、场景图法
      • 测试人员把自己当成最终用户，尽可能真实地模拟用户在使用此软件的操作情形
  • 测试用例要素？
    • 1、测试用例编号:由字母、字符、数字组合而成的字符串，有唯一性，易识别性；2、测试项目:当前测试用例所在测试用例所属大类、被测需求、被测模块、被测单元等;3、测试用例标题:对测试用例的简单描述。用概括的语言描述该测试用例的测试点。每个测试用例的标题不能够重复，因为每个测试用例的测试点事不一样的；4、重要级别:分为高、中、低三等;高级别：保证系统基本功能、核心业务、重要特性、实际使用频率比较高的用例；中级别：重要程度介于高和低之间的测试用例；低级别：实际使用的频率不高，对系统业务功能影响不大的模块或功能的测试用例；5、预置条件:执行当前测试用例需要的前提条件，如果这些前提条件不满足，则后面测试步骤无法进行测试或无法得到预期结果；6、测试输入:用例执行过程中需要输入的外部信息。根据软件测试用例的具体情况，有手工输入的内容、上传的文件、数据库记录等；7、操作步骤:执行当前测试用例需要经过的操作步骤，需要明确的给出每一个操作的详细描述，测试人员可以根据测试用例操作步骤完成测试用例执行；8、预期结果:当前测试用例的预期输出结果，包括返回值内容，界面的响应结果，输出结果的规则符合度等；9、实际结果：成功或失败。
  • 测试用例模板
    • 参考附件
• 5、测试用例评审；
  • 什么是用例评审？
    • 用例写完了之后，不代表这份用例写的都是正确的，场景覆盖是全的，需要多方人员进行查漏补缺，用例评审是产品、开发、测试一起对写好的用例进行一个评审的过程
  • 参与人员有哪些？
    • 产品、开发、测试
  • 什么时间进行评审？
    • 开发提测前
• 6、开发提测；
  • 开发先自测，然后再测试人员进行测试
• 7、执行测试用例，记录发现的Bug;
  • 如何执行测试用例？
    • 逐条执行！
  • 如何记录缺陷？
    • 缺陷工具（TAPD、禅道等）
    • 文档记录（Word、Excel）
  • 记录一条BUG需要包含哪些内容？(参考问题清单模板)
    • 1、编号；2、标题；3、所属模块；4、重现步骤；5、预期结果；6、实际结果；7、发现版本；8、优先级；9、重要程度；10、创建人；11、指派给谁；12、适当的截图；
• 8、验证bug与回归测试；
  • 如何验证bug?
    • 按照 bug 的重现步骤执行一下，确认 bug 不存在了，已经被修复了
  • 什么是回归测试？
    • 是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。
• 9、编写测试报告；
  • 测试报告包含哪些内容？
    • 1、测试背景。2、测试目标。3、测试范围。4、测试环境。5、测试数据。6、测试标准。7、测试进度。8、测试结果。9、测试结论。
  • 测试报告模板
    • 参考附件
• 10、产品上线；
  • 标准是什么?
    • 1、需求实现本版本所有需求都已经实现;2、测试任务完成本版本所有测试任务都已经执行完毕;3、缺陷（Bug）修复率达标bug修复情况要达标，特级bug（主路径问题及严重崩溃问题）需要修改完毕，剩余各个优先级的bug要有相应的解决率标准值。