测试项目启动与研读需求文档

一、 测试团队

1. 测试团队中的角色

• 业务分析人员
  辅助需求分析。
• 测试组长或测试经理
  • 全面负责项目的测试工作，如协调测试计划、统筹资源、组织测试件的评审、监控 测试的执行等。
    • 测试件（Test ware）是用来描述测试工作产品的术语，包括测试计划文档、测 试需求文档、测试用例、测试脚本、测试数据、测试日志或结果、缺陷分析报 告、测试报告等。
  • 测试经理能力要相对全面，包括项目管理、测试流程控制、沟通、业务、技术等各 个方面的能力。
• 测试分析和设计人员
  • 一般由具有丰富经验的资深测试工程师承担，较早进入项目，负责需求评审、设计 评审、测试需求分析、测试用例设计、测试脚本开发等。
    • 测试用例（Test case）是为了特定的测试目的而设计的测试条件、测试数据及 与之相关的测试规程的一个特定的使用实例或场景。
    • 测试脚本（Test script）是测试工具执行的一组指令集合，使计算机能自动完 成测试用例的执行，也是计算机程序的一种形式。
• 测试执行人员
  • 测试执行人员负责执行用例或者运行测试脚本，记录测试日志或结果，提交缺陷报 告等。
  • 一般由加入公司的新手或初级测试人员执行。
• 自动化测试/测试开发/性能测试/安全测试工程师
  • 负责测试工具的开发，自动化测试框架或整个应用测试平台的维护。
  • 需要性能或安全方面的知识、技术和经验，一般由专职的测试人员完成。
• 系统工程师/技术支持
  • 负责测试环境的部署和调试，甚至包括持续构建、持续集成的工作，以及产品发布 的技术流程。
• 质量管理人员
  • 负责制定质量保准并监督质量。
• 配置管理人员
  • 配置管理的目标是标识变更、控制变更、确保变更正确实现并向其他有关人员报告 变更，配置管理记录软件产品的演化过程。

2. 测试团队的基本责任

1. 尽早地发现软件程序、系统或产品中所有的问题。
2. 督促和协助开发人员尽快地解决程序中的缺陷。
3. 帮助项目管理人员制定合理的开发和测试计划。
4. 对缺陷进行跟踪、分析和分类总结，以便让项目的管理人员和相关的负责人能够及时、 清楚地了解产品当前的质量状态。
5. 帮助改善开发流程、提高产品开发效率。
6. 促进程序编写的规范性、易读性、可维护性等。

3. 测试团队与开发团队的 3 种模式

（1）以开发为核心
测试只是开发队伍的一部分，也就是开发团队中有测试人员，但 没有形成独立的团队。

（2）以项目经理为核心，开发小组和测试小组并存，隶属于项目经理领导。

（3）项目经理、开发组长和测试组长“三足鼎立”，测试团队具有独立的、权威的地位。

二、 软件质量需求

1. 软件质量需求的分类

• 软件质量需求用于确定测试目标。
• 测试目标包括：功能、性能、界面、易用性、兼容性、安全性、可用性/可靠性、可维 护性、可扩展性等。
• 功能以外统称非功能。

2. 功能

• 软件能做什么？
• 需要做什么？
• 怎么做是正确的？
• 哪些功能要测试、哪些功能不需要测试？
• 哪些功能重要，哪些不重要？
• 哪些功能先实现或先测试？

3. 性能

• 反映软件运行时的效率和占用资源情况的能力。
  • 时间特性：时间短、速度快、效率高。
  • 资源特性：占用资源（CPU、内存、硬盘、网络）少。

4. 界面（UI）

• 布局合理；
• 控件位置恰当；
• 文字没有乱码、字体大小合适；
• 颜色使用恰当；
• 图片、表格恰当、舒适、美观。

5. 易用性

• 在指定条件下使用时，软件产品被理解、学习、使用和吸引用户的能力。

6. 兼容性/可移植性

• 指软件产品从一种环境迁移到另一个环境的能力，反映一个软件与不同的硬件环境、操 作平台、其他软件的共同使用的能力。
  • 包括与不同硬件、平台、软件自身不同版本、其他软件、数据的兼容。

7. 安全性

• 指软件产品保护信息和数据的能力。

8. 可用性/可靠性

• 指系统正常运行的能力或程度，可用性=正常运行时间/（正常运行时间+非正常运行时 间）×100%。
  • 可用性指标一般要求达到 4 个 9 即 99.99%（全年 52 分钟不正常工作）或 5 个 9 即 99.999%（全年 5 分钟），对一些军事系统，可用性高达 7 个 9（99.99999%（全年 失效时间不超过两秒）。
  • 一般测试时间不足，可以采用空间换时间的办法，如在高负载情况下进行为期一周 或一个月的测试，以判断其可靠性。
  • 关注 MTTF（平均无故障时间）、MTTR（平均恢复时间）、MTBF（平均失效间 隔时间）。

9. 可维护性

• 指软件产品可被修改的能力。
  • 修改可能包括修正、改进或软件对环境需求和功能规格说明变化的适应。
  • 可维护性的软件应该是易改变的、稳定的、易测试的。

10. 可扩展性/可伸缩性测试

• 通过很少的改动就能实现整个系统处理能力的增长。
  • 如在部署两台服务器时测试系统性能（容量，即最大负载），再部署四台、八台服 务器时分别进行系统容量的测试，看其容量是否为上次（两台、四台）实验值的两 倍或接近两倍。如果是，系统就具有良好的可伸缩性。

三、 研读需求文档

1 测试需求分析的过程

• 收集与研读文档，提出并解决问题，整理需求信息
• 功能拆分、功能描述/需求整理
• 编写测试点
• 需求评审

2 研读需求文档

2.1 研读文档主要任务

• 提取有用的需求信息
• 提出需求中不清晰、不理解、不明白的问题
  • 和用户、业务人员、产品经理或产品设计人员、开发人员等沟通

2.2 怎么研读文档

• 分析思路
  • 分析软件的用户群，分析用户的实际需要；
  • 分析软件的开发环境、开发语言、数据类型；
  • 分析软件架构、软件的运行环境和平台、数据库类型；
  • 分析软件要实现哪些目标（功能、性能、界面、易用性、兼容性、安全性）以 及具体的要求是什么；
  • 分析软件有哪些功能，每种功能要完成什么业务，这些业务应该怎么实现，业 务逻辑是什么，业务流程是怎样的，业务规则有何要求；
  • 分析功能或业务间的联系，哪些业务更关键或重要；
  • 明确测试周期，测试目标，测试范围。
• 实施
  • 以情景再现的形式写出需求信息。 ’

2.3 研读需求文档案例

• 拿到一个项目，怎么入手？
  • 即时贴程序部分需求说明
    • 便签的数量最多为 50 个
    • 便签标题字数最多为 40 个字节
    • 便签的正文文字数量最多为 200 个
    • 年份只能设置在 1900－2100 之间