软件测试学习（四）

软件测试需求分析

根据需求来源的不同，软件分为产品类软件和项目类软件，每种软件需求获取方式不一样，对人员素质要求也不一样。
（1）项目类软件
         项目类软件的需求由特定用户以合同等契约形式明确下来。需求是通过和用户交流沟通的方式，比如访谈、交流、一起工作等渠道获取。它要求需求获取人员具有良好的业务背景、很好的交流沟通能力和亲和力，还需要具有很强的分析能力。
（2）产品类软件
         产品类软件没有特定用户以合同形式明确需求。需求主要由市场分析人员分析潜在客户的潜在需求获得，开发的产品源于公司已有的一些项目、技术专利等。比如office、Photoshop、微信等软件。产品类软件的需求获取一般通过市场调查、问卷、用户反馈、心理分析研究等方式，需要我们的需求获取人员具有深厚的业务背景、敏锐的洞察力、前瞻的预测能力和创造性思维。

软件测试工程师需求评审检查单

序号	检查单
1	需求中的每个规格是否都有明确的说明？
2	软件的需求的表述是否清晰？
3	软件的需求是否存在二义性？
4	是否对特定含义的术语给予了定义？
5	需求是否有自相矛盾的情况？
6	需求中有没有遗漏一些异常的约束关系？
7	需求中有没有包含不确定的描述，如：大约、可能、等。
8	环境搭建是否有困难或可能有困难？

软件测试计划概述

       软件测试是有计划、有组织和有系统的软件质量保证活动，而不是随意地、松散地、杂乱的实施过程。为了规范测试内容、方法和过程，在对软件进行测试之前，必须创建测试计划，为后续的测试工作提供直接的指导作用。

1. 什么是软件测试计划？
          软件测试计划包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。借助软件测试计划，参与测试的项目成员，尤其是测试管理人员，可以明确测试任务和测试方法，保持测试实施过程的顺畅沟通、跟踪和控制测试进度，应对测试过程中的各种变更。
2. 编写测试计划有什么作用呢？
          在项目管理中，决定着项目成败是项目三约束条件TRQ。T-Time（项目进度）、R-Resource（项目资源配置/成本）、Q-Quantity（项目范围）。如图3-1所示。
   
          软件测试计划是指导测试过程的纲领性文件，在项目执行中发挥核心作用，设定了测试准备工作和执行测试的必备条件，同时形成了测试过程质量保证的基础。
          综上所述，关于编写软件测试计划的好处总结如下：
          （1）软件测试计划是保证项目成功的重要因素之一；
          （2）管理者可以根据测试计划做宏观调控，进行相应资源的配置管理；
          （3）可以增加团队间交流，使测试人员了解整个项目不同阶段所要进行的工作安排；
          （4）便于其他成员了解测试人员的工作内容，配合有关工作；
          （5）如果是项目式软件的话，可以通过测试计划交代的内容，比如测试过程、人员技能、资源、使用工具等信息，给客户信心。
          但需要记住一个核心的基本点，编写软件测试计划的重要目的就是使测试过程能够发现更多的软件缺陷。
3. 如何做好软件测试计划工作
          （1）测试计划的制定越早越好
          （2）坚持5W1H的基本思路，明确软件测试计划内容的6要素

       （3）采用评审和更新机制
       （4）软件测试计划要简洁、易读

软件测试计划内容

一、项目概述

1.1项目背景

       项目背景中需要列出测试计划所从属的软件系统的名称。说明没有这个产品的时候所处的“悲惨境地”；还要说明这个产品解决了什么问题，能达到什么样的美好未来，以及促成这个转变所需要的产品功能点。

1.2编写目的

（1）使项目测试工作的所有参与人员（客户方参与人员、测试管理者、测试人员）对本项目测试的目标、范围、策略、方法、组织、资源等有一个清晰的认识；

（2）使项目测试工作的所有参与人员理解测试控制过程；

（3）从策略角度说明本项目测试的组织和管理，指导测试进展，并作为项目测试工作实施的依据；

（4）为测试工作提供了一个整体框架和规范。

1.3计划受众

（1）项目经理可以根据该测试计划制定进一步的计划、安排（工作任务分配、时间进度安排）和控制测试过程；

（2）客户指派人员通过该测试计划了解测试过程和相关信息；

（3）测试人员根据该测试计划中制定的范围、方法确定测试的需求、设计测试用例、执行测试和报告缺陷。

1.4术语定义

（1）软件未实现产品说明书要求的功能；

（2）软件出现了产品说明书中指明不应该出现的错误；

（3）软件实现了产品说明书未提到的功能；

（4）软件未实现产品说明书虽未明确提及但应该实现的目标；

（5）测试人员认为软件不好用，或者不应该出现的功能。
  专有术语定义表

术语	说明
流量	指一个网站的访问量，包括网站的独立用户数量、总用户数量（含重复访问者）、页面浏览数量、每个用户的页面浏览数量、用户在网站的平均停留时间等。
点击率	指网站页面上某一内容被点击的次数与被显示次数之比，它反应了网页的受关注程度。
吞吐量	指服务器单位时间内处理事务的数量。
禅道	项目管理软件，同时也是一款测试管理软件。
测试策略	测试工程的总体方法和目标。
测试范围	测试该项目所需要执行的全部工作。
测试用例	为特殊目标编制的输入、执行条件以及预期结果。

缩略语定义表

缩略语	说明
Web	浏览器方式的万维网
IE	微软互联网浏览器
Windows Server	微软服务器操作系统
SQL Server	微软数据库管理系统
I5、I6	英特尔处理器及型号
RAM	电脑或手机的运行内存

缺陷的严重级别定义表

缺陷严重级别	等级定义及描述
致命缺陷 Fatal	（1）操作系统无法正常使用、死机、出现致命错误；（2）数据丢失；（3）被测系统频繁崩溃、程序出错、使功能不能继续使用；（4）性能与需求不一致；（5）系统资源引发性能问题；（6）系统配置引发错误；（7）安全性问题。
严重缺陷 Critical	（1）功能与需求不一致，或功能未实现；（2）功能有错误，影响使用；（3）数据传输有错误；（4）安装与卸载问题。
重要缺陷 Major	（1）功能有错误，但不影响使用；（2）界面错误；（3）边界条件出错。
一般缺陷 Minor	（1）界面设计不规范；（2）消息、提示不准确；（3）交互界面不友好。
改进意见 Enhancement	测试人员认为的改进意见或建议。

1.5参考资料

（1）本项目经核准的计划任务书、合同或上级机关的批文；

（2）属于本项目的其他已发表的文件；

（3）本文件中各处引用的文件、资料，包括所要用到的软件开发标准。列出这些文件的标题、文件编号、发表日期和出版单位，说明这些文件资料的来源。

比如：

《计算机软件工程规范国家标准汇编2003》，中国标准出版社；

《GBT 15532-2008 计算机软件测试规范2008》；

《GBT 9386-2008 计算机软件测试文档编制规范2008》；

《某某项目需求规格说明书》V1.5版，项目小组内部文档；

《某某项目开发计划书》V1.2版，项目小组内部文档；

《某某项目产品原型图》V1.7版，项目小组内部文档；

二、测试范围

三、测试策略

3.1功能测试

测试策略这一项需要注意以下几点：

（1）列出对测试对象进行测试的推荐方法；

（2）对于每种测试，都应提供测试说明，并解释其实施的原因；

（3）将要使用的测试技术以及完成标准；

	功能测试测试策略
测试目标	确保系统提供的功能与需求和用户手册相符。
使用技术	（1）基于黑盒测试技术，通过GUI与应用程序进行交互，并对交互的输出或结果进行分析，以此来核实应用程序及其内部进程； （2）系统测试阶段依据需求规格说明书逐项测试；（3）重要的功能应该投入更多的精力进行测试并及时小结。
完成标准	需求规格中指明的功能实现，且可以正确执行。
特殊事项	（1）注意多种状态中的组织和转换，不要有遗漏；（2）注意值域测试的提示信息。

3.2界面测试

	用户界面测试策略
测试目标	（1）确保页面正确反应业务的功能和需求，包括：窗口与窗口之间、字段与字段之间的浏览； （2）确保各种访问方法（Tab键、鼠标移动和快捷键）的使用符合标准规范； （3）确保使用窗口的对象和特征（菜单、大小、位置、状态）符合标准。
使用技术	（1）按照相关规定逐项检查，包括菜单、按钮、版权信息等； （2）检查提示信息中的文字和标点符号、图标等。
完成标准	程序界面符合相关的规范。
特殊事项	事项 并不是所有定制或第三方的对象特征都可以访问。

3.3安装测试

3.4兼容性测试

	兼容性测试策略
测试目标	核实测试对象是否按需求可以在Windows XP中文版和Windows 10中文版中正常运行。
使用技术	使用自动化测试工具Selenium通过功能测试脚本的回放进行测试。
完成标准	在两个系统平台中可以完成同样的事件。
特殊事项	暂无。

3.5接口测试

	接口测试策略
测试目标	确保接口调用的正确性，测试所有软件、硬件接口，记录输入输出数据。
使用技术	优先使用Jmeter接口测试工具，或者SoapUI、HttpClient等工具。
完成标准	每个输入数据对应的接口输出数据与预期相符。
特殊事项	接口的限制条件。

3.6集成测试

四、测试资源

测试资源包括软硬件资源和人力资源。在项目期间测试可能用到的任何资源都要考虑到。详细列出例如：

• 人员：人员数量、经验和专长？他们是全职、兼职、合同还是学生？承担什么角色？

• 设备：计算机、测试硬件、打印机、工具

• 办公室和实验室空间：在哪里？有多大？如何布局？

• 软件：文字处理程序、数据库程序和自定义工具。要购买哪些东西？要写什么材料？

  4.1软件资源

  软件资源：
  操作系统：Windows 10操作系统
  浏览器：IE10、Firefox33.1.1、Google Chrome81.0.4044.92

  4.2硬件资源

  硬件资源：
  主体：Thinkpad 笔记本电脑
  CPU：第十代智能英特尔酷睿i7-1065G7处理器，1.3GHz睿频至3.9GHz。
  内存：8G
  显卡：LED背光、分辨率1920x1080、宽屏16:9、集成显卡，支持双屏显示
  硬盘：1块SCSI系统硬盘512G SSD
  机箱：带有配套视频接口背板的机箱

  4.3人力资源

工作角色	具体职责
测试项目负责人	管理监督测试项目，提供技术指导，获取适当的资源，制定基线，技术协调，负责项目的安全保密和质量管理。
测试分析员	确定测试计划、测试内容、测试方法、测试数据生成方法、测试（软、硬件）环境、测试工具、评价测试工作的有效性。
测试设计员	设计测试用例，确定测试用例的优先级，搭建测试环境。
测试开发人员	开发软件测试所需要的辅助工具和软件。
测试员	执行测试、记录测试结果、提交缺陷、回归缺陷。
测试系统管理员	对测试环境和资产进行管理和维护。
系统配置管理员	设置、管理和维护配置数据库。

4.4测试工具

测试工具是指本项目中所用到的测试工具。测试过程涵盖单元测试、集成测试、系统测试、回归测试、交付测试等各个阶段，如何有效地组织管理起这些不同阶段的测试尤为重要，这就需要软件测试工具的辅助。比如软件测试管理工具、功能测试工具、性能测试工具等。软件测试管理工具能管理整个测试过程，从测试计划、测试用例、测试执行、测试结果到测试报告，提供一个基于中央数据库的、协同合作的环境，即使测试人员分布在各地，也可以随时随地都能参与整个测试过程。除软件测试管理工具之外，还有功能测试工具、性能测试工具等，这个在第1章中有讲解到，此处不再赘述。

五、测试进度

5.1任务分工

测试员	测试任务分配
张三	测试字符格式：字体、大小、颜色、样式
李四	测试布局：项目符号、段落、制表位、换行
王五	配置和兼容性测试
赵六	用户界面测试：易用性、外观、辅助特性
董皊	压力测试和负载测试

5.2测试里程碑

序号	测试活动	计划开始日期	计划结束日期	所需工时
1	系统培训	2025-08-04	2025-08-08	5个工作日
2	制定测试计划	2025-08-11	2025-08-15	5个工作日
3	设计测试用例	2025-08-18	2025-09-30	34个工作日
4	执行测试用例	2025-10-08	2025-11-07	22个工作日
5	测试总结报告	2025-11-10	2025-11-13	4个工作日

最大关键路径法：

比如：如果张三负责的A模块需要3天完成，李四负责的B模块需要5天完成，王五负责的C模块需要4天完成，那么这轮测试计划的时间就按照5天来算。这个时间计算的前提是这3人的工作是并行的。

倒推法：

简单的说，如果一个项目是3个月，其中2个月是开发时间，那最终的测试时间就只有1个月了，测试就只能在这1个月之内进行计划和安排。

表3-13 系统测试执行计划

序号	测试活动	计划开始日期	计划结束日期	所需工时
1	第一轮测试	2025-10-08	2025-08-22	12个工作日
2	第二轮测试	2025-10-23	2025-10-31	7个工作日
3	第三轮测试	2025-11-03	2025-11-07	5个工作日

5.3测试进度

序号	测试活动	计划开始日期	所需工时
1	制定测试计划	说明书完成后7天	2个星期
2	设计测试用例	测试计划完成	6个星期
3	执行第1轮测试	代码构建完成	3个星期
4	执行第2轮测试	Beta版代码构建完成	3个星期
5	执行第3轮测试	发行版构建完成	2个星期
6	测试总结报告	软件测试到达最佳平衡点	1个星期

六、测试准则

6.1测试进入的准则

测试进入的准则：是指开始执行测试的时机；

6.2测试暂停的准则

测试暂停的准则：描述系统在什么情况下暂停全部或部分测试工作；

6.3测试恢复的准则

测试恢复的准则：描述系统恢复测试的必要条件；

6.4测试退出的准则

测试退出的准则：描述测试退出的条件，有正常退出，也有非正常或意外的退出。

准则	描述
测试进入的准则	（1）测试环境已经准备好；（2）软件源代码正确通过编译或汇编；（3）系统基本业务流程能走通，能通过冒烟测试；（4）测试所需的文档资料已经完整。
测试暂停的准则	（1）测试环境被破坏；（2）系统基本业务流程不通，无法通过冒烟测试；（3）重要功能的页面点击错误。
测试恢复的准则	（1）测试环境重新搭建好；（2）系统基本业务流程可以走通；（3）重要功能的页面点击错误解决。
测试退出的准则	（1）测试内容已经完成；（2）实际测试的过程遵循了原定的软件测试计划和软件测试说明；（3）客观地记录了软件测试中发现的所有问题；（4）软件测试文档齐全、符合规范，且已归档；（5）软件中的问题或异常有合理解释或正确有效的处理；（6）软件测试工作通过了测试评审；

七、风险及应对方案

7.1风险分析

（1）需求风险。需求理解不准确或者需求发生变更而导致测试时间被压缩的风险。

（2）测试用例风险。测试用例设计不完整导致测试时间被压缩的风险。

（3）缺陷风险。缺陷难以复现或者没有很好的被跟踪的风险。

（4）代码风险。代码质量差、修改难度大；或者系统架构设计不足导致扩展性不足的风险。

（5）测试环境风险。测试环境数据量不足可能导致测试结果误差；再比如一些功能（如支付功能）无法在测试环境进行实际测试，可能导致实际生产环境出现问题。

（6）测试技术风险。测试人员技能局限导致测试结果不准确的风险。

（7）回归测试风险。回归测试时，业务流程不通导致修复验证，从而造成进度延后的风险。

（8）沟通协调风险。部门之间的沟通协作不畅的风险，比如需求变更没有及时沟通，测试结果的反馈不及时等问题。

（9）研发流程风险。研发流程不规范导致的一些临时风险。

（10）其他不可预计的风险。比如一些突发状况、不可抗力的因素。

7.2风险应对方案

八、测试提交的文档

软件测试计划应规定测试完成后测试人员需要归档的文档。如软件测试计划、软件测试用例、软件缺陷报告、缺陷处理日志、软件测试总结报告等。