目录
一、项目信息来源
1.1 熟悉项目步骤
- 了解项目的业务特性：项目是用来做什么的？
- 了解项目的角色和用户：项目是给谁用的？
- 了解项目的组织结构图：项目包括哪些功能模块？
- 了解项目的技术栈：项目使用了哪些技术实现的？
1.2 熟悉项目的信息来源
在软件测试项目中，项目的信息可以从多个来源获取，以帮助测试团队全面了解项目需求和测试目标。
- 项目中已存在的文档：需求说明书、用户使用手册、测试用例等。
- 使用项目的现有环境：开发环境、测试环境、线上环境等。
- 询问项目中的其他成员：测试组员/组长、开发人员、产品经理等。
二、项目测试流程
- 需求分析（评审）
- 编写测试计划与测试方案
- 测试用例设计与评审
- 环境准备
- 测试执行与BUG跟踪处理
- 重复测试与回归测试
- 编写测试报告
2.1 需求分析
需求评审的目的：
- 保证需求的完整和准备；
- 保证项目中的相关人员对需求理解的一致性。
测试人员在需求评审的职责：
- 确认自己对需求要有清晰的理解；
- 确认需求文档完整、准确，能够知道后期工作；
- 对需求中不合理的地方提出修改意见。
2.2 测试计划
测试计划：是软件测试过程中的关键文档，它用于规划、安排和组织测试活动的执行。测试计划包含了测试的范围、目标、策略、资源、进度安排以及测试的风险评估等信息，旨在确保测试过程能够有效地进行并满足项目的需求和质量目标。
测试计划的核心内容：
- 明确的测试目标与测试范围
- 执行计划的角色和职责
- 任务的进度安排与资源分配
- 风险评估和应急计划
- 测试的准入/准出标准
2.3 测试方案
测试方案是从测试的角度去分析需求，在方向上明确要怎么测，分析结果重点在于测试策略与技术实现。
测试方案的核心内容：
- 测试策略：描述测试的方法、技术和策略，包括测试的级别（单元测试、集成测试、系统测试等）、测试的类型（功能测试、性能测试、安全测试等）以及测试用例设计方法。
- 测试环境规划：说明测试所需的硬件、软件和网络环境，以及测试环境的搭建和配置。
- 测试工具的设计和选择
2.4 测试用例设计
2.4.1 测试用例需求来源
- 文档：需求文档、产品原型图、UI图。
- 从用户角度：测试软件的易用性
2.4.2 编写测试用例步骤
- 确定测试目标：明确测试的目标和测试的范围。了解要测试的功能或系统的预期行为和要求，以便在编写测试用例时能够覆盖相关的功能和场景。
- 需求分析：以了解系统的功能和设计。
- 确定测试技术和方法：根据项目的需求和测试目标，选择适合的测试技术和方法。常见的测试技术包括黑盒测试、白盒测试、灰盒测试、功能测试、性能测试、安全测试等。
- 确定测试用例的类型和覆盖范围：根据系统的功能和需求，确定测试用例的类型，如正常流程测试、异常流程测试、边界值测试等。同时，确保测试用例能够覆盖系统的各个功能和场景。
- 编写测试用例：根据已确定的测试目标和范围，开始编写测试用例。
- 审查和验证测试用例
2.4.3 编写测试用例的原则
- 易于理解和执行：测试用例应该清晰、简洁，并且易于理解和执行。
- 完整覆盖功能和需求：测试用例应该覆盖系统的各个功能和需求，包括正常流程、异常情况、边界情况等。
- 独立性和可重复性：每个测试用例应该是独立的，不依赖于其他测试用例的执行结果。
- 预期结果明确：测试用例应该明确指定预期结果，即测试执行后期望得到的结果。
- 考虑边界条件和异常情况：测试用例应该考虑边界条件和异常情况，以验证系统在极限情况下的稳定性和正确性。
- 可维护性和可扩展性：测试用例应该具有良好的可维护性和可扩展性，方便进行修改、更新和添加新的测试用例。
- 有效性和高效性：测试用例应该是有效的，能够发现潜在的缺陷和问题。同时，测试用例应该是高效的，能够在有限的时间内完成执行。
- 文档化和可追溯性：测试用例应该进行适当的文档化，并具有良好的可追溯性。可以记录测试用例的编写人员、编写日期、修改历史等信息，以便于跟踪和管理。
2.4.4 执行测试用例原则
- 准确性：确保按照测试用例中描述的步骤执行测试。仔细阅读每个步骤，准确执行，确保测试结果的准确性。
- 及时记录：在执行测试用例的过程中，记录每个步骤的执行结果和观察到的现象。准确记录问题、缺陷和异常情况，以便后续分析和跟踪。
- 不做假设：在执行测试用例时，不要做任何假设或推测。只根据实际观察到的结果来判断测试是否通过或失败。
- 及时报告问题：如果在执行测试用例的过程中发现问题、缺陷或异常情况，及时报告给相关人员，确保问题能够被及时处理。
扫一扫
4万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
