软件测试入门之测试项目启动与研读需求文档（精辟干货）
说明：该篇博客是博主一字一码编写的，实属不易，请尊重原创，谢谢大家！
接着上一篇博客继续往下写 ：https://blog.****.net/qq_41782425/article/details/103493511
一、组建测试团队
1.测试团队中的角色
-
业务分析人员
√辅助需求分析。 -
测试组长或测试经理
√ 全面负责项目的测试工作，如协调测试计划、统筹资源、组织测试件的评审、监控测试的执行等。
✰ 测试件（Test ware）是用来描述测试工作产品的术语，包括测试计划文档、测试需求文档、测试用例、测试脚本、测试数据、测试日志或结果、缺陷分析报告、测试报告等。
√ 测试经理能力要相对全面，包括项目管理、测试流程控制、沟通、业务、技术等各个方面的能力。 -
测试分析和设计人员
√ 一般由具有丰富经验的资深测试工程师承担，较早进入项目，负责需求评审、设计评审、测试需求分析、测试用例设计、测试脚本开发等。
✰ 测试用例（Test case）是为了特定的测试目的而设计的测试条件、测试数据及与之相关的测试规程的一个特定的使用实例或场景。
✰ 测试脚本（Test script）是测试工具执行的一组指令集合，使计算机能自动完成测试用例的执行，也是计算机程序的一种形式。 -
测试执行人员
√ 测试执行人员负责执行用例或者运行测试脚本，记录测试日志或结果，提交缺陷报告等。
√ 一般由加入公司的新手或初级测试人员执行。 -
自动化测试/测试开发/性能测试/安全测试工程师
√ 负责测试工具的开发，自动化测试框架或整个应用测试平台的维护。
√ 需要性能或安全方面的知识、技术和经验，一般由专职的测试人员完成。 -
系统工程师/技术支持
√ 负责测试环境的部署和调试，甚至包括持续构建、持续集成的工作，以及产品发布的技术流程。 -
质量管理人员
√ 负责制定质量保准并监督质量。 -
配置管理人员
√ 配置管理的目标是标识变更、控制变更、确保变更正确实现并向其他有关人员报告变更，配置管理记录软件产品的演化过程。
2.测试团队的基本责任
- 尽早地发现软件程序、系统或产品中所有的问题。
- 督促和协助开发人员尽快地解决程序中的缺陷。
- 帮助项目管理人员制定合理的开发和测试计划。
- 对缺陷进行跟踪、分析和分类总结，以便让项目的管理人员和相关的负责人能够及时、清楚地了解产品当前的质量状态。
- 帮助改善开发流程、提高产品开发效率。
- 促进程序编写的规范性、易读性、可维护性等。
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 之间
2.4 得出信息和提出问题
- 根据研读以上案例需求文档，将得出的信息以及疑问问题写在记事本上
2.5 整理需求信息
- 解决以上问题，整理需求信息，根据对产品的了解来获取潜在的需求信息
四丶项目实战
1.项目介绍
- 学生管理系统项目是一个咨询OA系统，用于职业顾问部一些人来进行使用的，管理咨询部老师的信息以及学生的信息，如下这是项目的一些文档（此时项目可能还没有开始做）
√ 系统设计说明书可能会涉及一些开发的东西一般是给开发看的
√ 需求规格说明书会对软件有一些详细的说明
√ 环境配置说明书一般是给用户看的，怎么安装怎么使用
2.研读需求规格说明书
说明： 一个项目肯定存在多个文档，先是一个文档一个文档的单独看，最后再将多个文档结合着再看
- 读的时候一定是要带着疑问去阅读的
- 根据以上的一个系统概述，则可以得出以下问题
- 继续阅读功能简介章节，但是这里只给大家演示到连接数据库需求，文档比较多，就不一一的演示了
- 最终研读需求规格说明书得出以下问题以及信息
3.研读系统设计说明书
- 首先打开说明书查看需要的部分文档（目前只看连接数据库部分）
- 根据系统设计说明书，得出以下信息以及问题
4.研读环境配置说明书
- 环境配置说明书关于数据库配置内容如下
- 研读环境配置说明书后，得到的信息以及问题如下
5.需求问题解答
- 职业顾问部的老师是做什么的
√ 与想要报名学习的学生进行沟通咨询，学生报名后老师将学生的信息录入到本系统当中 - 测试目标是什么，测不测兼容性丶易用性丶性能以及界面，将来的测试环境以及平台选什么
√ 询问项目经理或者客户经理，目前来说只测功能，易用性以及界面；环境选择win7系统 - 程序怎么尝试连接，PsPing什么时候运行，怎么运行
√ 服务器开机设置数据库丶IP丶网线丶路由器交换机网络保证一切正常，客户机装上软件，IP设置好，网络正常，打开软件，弹出数据库连接窗口，在连接窗口输入服务器IP点击确定后，此时会调用PsPing连接是否能成功，会悄悄在前台运行 - 服务器IP将保存到用户计算机中的什么位置
√ 保存到安装目录下的db.info文件中，采用明文存储的方式 - 数据库sql server版本是多少
√ sql server 2008 - 密码必须设置sql_2008，这样不好，实际工作中很可能不一致或者需要修改，这个怎么处理
√ 基于数据库密码一般人接触不到，暂时维持这个密码，后期版本升级会进行修改 - 修改数据库密码联系管理员，是谁
√ 公司网管，也就是有修改数据库权限的人
6.需求信息整理
- 将需求信息应用到场景中，分为服务器丶网络丶客户机进行整理