TCQAE112024信息化工程项目软件验收测试

ICS35.080

CCSL77

团体标准

T/CQAE11XX-XXX

信息化工程项目软件验收测试

Acceptancetestingforinformationalengineeringprojectsoftware

（报批稿）

2024-XX-XX发布2024-XX-XX实施

中国电子质量管理协会发布

T/CQAE11XX-XXXX

目次

前言...............................................................................I

1范围.................................................................................1

2规范性引用文件.......................................................................1

3术语和定义...........................................................................1

4总则.................................................................................2

4.1验收测试依据.....................................................................2

4.2验收测试条件.....................................................................2

4.3验收相关方及其职责...............................................................2

4.4验收测试流程.....................................................................2

5验收测试要求.........................................................................3

5.1测试准备阶段.....................................................................3

5.2测试策划阶段.....................................................................4

5.3测试设计与执行阶段...............................................................5

5.4测试总结阶段.....................................................................7

附录A（资料性）软件缺陷级别定义.................................................9

附录B（资料性）性能效率测试需求分析与设计（示例）..............................11

附录C（资料性）软件兼容性测试需求分析与设计（示例）............................13

T/CQAE11XX-XXXX

信息化工程项目软件验收测试

1范围

本文件确立了信息化工程项目中软件验收测试的依据、条件，各方职责及流程，规定了信息化工程

项目软件验收测试的准备、策划、设计与执行、总结阶段的技术要求。

本文件适用于信息化工程项目中的软件验收测试。

2规范性引用文件

下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中，注日期的引用文件，

仅该日期对应的版本适用于本文件；不注日期的引用文件，其最新版本（包括所有的修改单）适用于本

文件。

GB/T11457软件工程术语

GB/T15532计算机软件测试规范

GB/T25000.10系统与软件工程系统与软件质量要求和评价（SQuaRE）第10部分：系统与软件

质量模型

3术语和定义

GB/T11457、GB/T15532、GB/T25000.10界定的术语以及下列术语和定义适用于本文件。

3.1建设方owner

执行信息化工程项目软件建设计划，监督软件开发部署，支配并使用软件建设投资的单位。

3.2需求方acquirer

提出软件开发需求，并在软件开发过程中负责提供并确认软件需求相关信息的单位。

3.3开发方developer

接受建设方委托，在软件生存周期中执行开发活动(包括需求分析、设计直至验收)的单位。

3.4测试方tester

独立于信息化工程项目软件开发方，对信息化工程项目软件执行验收测试的单位。

注：测试工作可由建设方、需求方自行负责或者委托具备测试能力的单位执行。

3.5信息化工程项目informationalengineeringproject

信息化工程项目是指通过现代信息技术手段，如计算机、通信和其他信息技术，进行的信息网络、

信息安全、信息资源、信息应用系统的新建、扩建或改建项目。

3.6信息化工程项目软件informationalengineeringprojectsoftware

1

T/CQAE11XX-XXXX

信息化工程项目中的软件系统，包括但不限于数据共享、数据分析、业务协同、业务处理等软件。

4总则

4.1验收测试依据

验收测试前，建设方、需求方和开发方应就信息化工程项目软件验收测试依据达成共识，约定验收

依据的标准和相关文档。验收测试依据除项目招投标文件、合同和建设方案中的软件开发需求等文档外，

还应包括信息化工程项目建设应遵循的法律法规、相关标准。

4.2验收测试条件

本项要求包括：

a)被测软件应完成开发，开发方应确保软件测试期间版本可控；

b)经过建设方、需求方和开发方确认，验收测试依据规定的各类文档应齐备；

c)被测软件和相关设备应完成部署，参数配置正确，满足测试要求；

d)被测软件宜完成试运行。

4.3验收相关方及其职责

本项要求应包括：

a)建设方：负责组织信息化工程项目软件验收测试工作开展，包括测试方和测试需求确定、测试

方案审批、测试过程监督、测试结果确认；

b)需求方：配合软件建设方和测试方，完成软件测试需求确定和测试结果确认；

c)开发方：负责提供被测试软件和相关文档，测试过程中，保证被测试软件的可执行性和版本可

控，配合测试方完成软件测试工作；

d)测试方：负责软件验收测试需求分析，制定测试方案并负责实施，记录测试结果，给出测试结

论并提交验收测试报告。

4.4验收测试流程

验收测试流程应包括：

a)测试准备阶段

b）测试策划阶段

c）测试设计与执行阶段

d）测试总结阶段

具体流程见图1。

2

T/CQAE11XX-XXXX

图1验收测试流程图

5验收测试要求

5.1测试准备阶段

5.1.1概述

测试准备阶段包括确定验收测试方、召开验收测试启动会、提交验收测试依据文档、确定验收通过

准则四项工作内容。

3

T/CQAE11XX-XXXX

5.1.2测试准备阶段工作内容

5.1.2.1确定验收测试方

宜由项目建设方确定软件验收测试方，如经建设方同意，可由项目需求方或开发方确定软件验收测

试方，测试方应具备如下条件：

a)具备独立、客观、科学的立场；

b)具备实施软件验收测试的技术能力；

c)具备与被测软件验收测试规模相适应的人员、工具和环境。

5.1.2.2召开验收测试启动会

项目启动会应符合如下要求：

a)项目启动会前确认软件满足4.2所要求的条件；

b)由建设方、需求方、开发方、测试方人员参会；

c)项目启动会内容包括确定软件验收测试目标和要求、测试阶段划分、管理流程、各方职责，并

进行各方关键角色任命；

d)建设方、需求方、开发方、测试方就启动会内容达成一致，形成会议纪要。

5.1.2.3提交验收测试依据文档

应按如下要求提交验收测试依据文档：

a)由项目开发方向项目建设方提交验收测试依据文档；

b)项目建设方对验收测试依据文档进行确认后，将文档移交测试方；

c)验收测试依据文档保持版本固定、内容完整齐备；

d)文档经过开发方、建设方、需求方确认。

5.1.2.4确定验收测试通过准则

软件测试方应按如下要求确定验收测试通过准则：

a)与建设方、需求方、开发方共同确定信息化工程项目软件验收测试通过准则；

b)通过准则内容参考验收测试依据以及软件缺陷数量、级别和影响范围，软件缺陷级别定义参见

附录A。

5.1.3测试准备阶段输出

软件测试信息。

5.2测试策划阶段

5.2.1概述

测试策划阶段包括验收测试依据文档检查、开展验收测试需求分析、确定验收测试实施要求、编制

验收测试方案四项工作内容。

5.2.2测试策划阶段工作内容

5.2.2.1验收测试依据文档检查

本项工作应符合如下要求：

a）测试方对文档是否齐全进行检查；

4

T/CQAE11XX-XXXX

b）测试方对文档内容是否完备进行检查；

c）测试方对文档内容是否正确进行检查；

d）测试方对文档内容是否一致进行检查。

5.2.2.2开展验收测试需求分析

测试方开展验收测试需求分析，本项工作要求如下：

a）应确定验收测试范围；

b）验收测试可参照GB/T25000.10确定测试需求内容；

c）对于文档中不明确的测试需求，测试方可通过与建设方、需求方沟通，获取软件承载业务应用

情况和历史数据，对测试需求进行进一步分析，本文附录B和附录C给出信息化工程项目软件性能

效率、兼容性测试需求分析案例；

d）应确认验收测试方法和工具；

e）必要时，测试需求分析人员可对被测试软件进行探索性测试以获取准确的验收测试需求信息；

f）软件测试方应就测试需求内容与建设方、需求方、开发方进行确认。

5.2.2.3确定验收测试实施要求

测试方对验收测试实施要求进行确定，本项工作应符合如下要求：

a)确定测试启动、暂停、恢复、完成准则，可参考如下情形：

1)启动：软件满足验收测试条件，软件测试资源齐备；

2)暂停：项目实施过程中发生影响测试执行的事件，如测试中出现缺陷影响测试继续执行、

测试范围发生重大变更、测试需求与实际应用需求不一致、政策要求变化、不可抗力等情

况；

3)恢复：影响测试执行的事件已关闭，测试可以继续进行；

4)完成：完成测试方案中规定的测试任务，软件测试设计与执行阶段交付文档规范齐全。

b)确定验收测试组成员及任务分配信息，包含且不限于：

1)测试组成员角色覆盖项目管理、测试执行、质量监督等任务；

2)测试组成员包括测试方及建设方、开发方、需求方相关验收测试对接负责人员。

c)确定项目交付成果物，包含且不限于软件缺陷报告、验收测试报告。

5.2.2.4编写验收测试方案

测试方编写验收测试方案，本项工作应符合如下要求：

a)将测试需求分析、测试实施要求纳入测试方案；

b)明确测试过程、质量、进度、沟通、变更、风险等管理措施；

c)就测试方案内容与建设方、需求方、开发方达成一致。

5.2.3测试策划阶段输出

测试方案。

5.3测试设计与执行阶段

5.3.1概述

测试执行阶段包括设计测试用例、准备测试资源、执行测试用例并记录执行结果、测试执行情况分

析、软件缺陷整改、软件回归测试六项工作内容。

5

T/CQAE11XX-XXXX

5.3.2测试设计与执行阶段工作内容

5.3.2.1设计测试用例

测试方设计测试用例，应遵循如下要求：

a)测试用例完整覆盖软件验收测试需求；

b)测试用例的设计符合GB/T15532中4.5的要求。

5.3.2.2准备测试资源

本项工作要求如下：

a)测试环境满足如下要求：

1)宜在生产环境中开展软件验收测试；

2)如果生产环境不适宜进行验收测试，则应搭建模拟仿真环境，原则上，模拟仿真环境应采

取和生产环境一致的软硬件配置；

3)如果软件已上线使用，测试执行宜避开被测试软件业务高峰；

4)测试方应充分评估软件测试执行风险，包括不限于系统业务中断、数据完整性损坏等，并

告知建设方、开发方；

5)开发方应配合测试方，针对软件测试风险，制定软件备份与恢复策略，并在测试之前开展

软件和数据备份。

b)测试方应按照如下要求准备测试工具：

1)配备测试范围内涉及的各类测试用工具，可选择商业采购工具、开源工具、自主开发工具；

2)测试方负责测试工具来源、版本确认等工作；

3)测试执行前，测试工具经过建设方、开发方许可后接入被测试软件网络。

c)测试方按照测试方案配备测试人员，测试人员应具备执行所分配测试任务的能力；

d)开发方应配合测试方按照如下要求准备测试数据：

1)准备数据对敏感信息进行脱敏处理，如公民个人数据、企业商业信息等；

2)准备数据完整覆盖软件的各功能，避免人为制造业务流断点、数据流断点；

3)准备数据格式满足软件设计文档的格式要求；

4)准备数据量满足测试需求中对基础数据量的要求；

5)开发方保证对测试数据的操作不影响软件正常业务运行。

5.3.2.3执行测试用例并记录执行结果

测试方执行测试用例并记录执行结果，本项工作应符合如下要求：

a)测试用例执行结果与期望结果一致时，测试用例判定为通过；

b)如出现与期望结果不一致的测试用例执行结果，测试用例判定为不通过，进行详细记录，并保

留相关截图或提示等信息；

c)开发方配合测试方执行测试用例。

5.3.2.4测试执行情况分析

测试用例执行完成后，测试方对测试执行情况进行分析，确认测试是否满足完成条件，本项工作应

包含如下要求：

a)测试方对测试内容是否充分覆盖软件测试需求进行分析，确认测试工作是否充分：

1)测试工作充分性分析工作参照GB/T15532中验收测试分析进行；

2)如测试工作不充分，按照5.3.2.1要求设计新的测试用例，并按照5.3.2.3要求执行。

6

T/CQAE11XX-XXXX

b)测试方对软件缺陷情况进行分析：

1)测试方对不通过的测试用例进行分析，确定软件缺陷；

2)测试方与建设方、需求方、开发方确认软件缺陷，形成软件缺陷报告；

3)测试方与建设方、需求方、开发方确认软件缺陷整改要求，向开发方移交软件缺陷报告，

等待开发方缺陷整改完成。

5.3.2.5软件缺陷整改

本项工作应符合如下要求：

a)由建设方、开发方、测试方约定缺陷整改期限；

b)由开发方对发现的软件缺陷进行整改；

c)软件缺陷整改完成后，开发方重新部署整改后的软件，并向测试方提交缺陷整改情况说明，整

改情况说明包含软件缺陷整改详情和软件变更范围信息。

d)如因信息技术发展水平限制或硬件资源限制当前无法进行更换等因素，整改范围内的软件缺陷

不具备整改条件，无法进行整改，开发方完成如下工作内容：

1)开发方保证未整改软件缺陷不影响软件主要业务实现；

2)开发方承诺在以后的软件使用过程中，当软件未整改缺陷的整改条件满足时，对该软件缺

陷进行整改；

3)开发方填写软件缺陷未整改情况备案说明，说明内容包含以上两点，经建设方确认同意后

提交软件测试方。

5.3.2.6软件回归测试

本项工作应符合如下要求：

a)测试方接收到缺陷整改情况说明后，分析软件变更情况，确定变更是否满足如下条件：

1)整改后的软件符合软件需求；

2)如果因软件缺陷修复引起软件需求变更，开发方提供经建设方、需求方认可的正式需求变

更文件。

b)测试方分析回归测试所需测试用例，包括如下内容：

1)软件未通过的用例，以及缺陷关联功能的测试用例；

2)如果涉及软件实现逻辑、流程等发生变更，按照软件变更修改测试用例并执行；

3)如果软件增加了新的功能或流程，按照5.3.2.1要求设计新的测试用例。

c)回归测试按照5.3.2.3要求执行。

5.3.3测试设计与执行阶段输出

a)测试用例；

b)测试记录；

c)软件缺陷报告；

d)缺陷整改情况说明；

e)缺陷未整改情况备案说明。

5.4测试总结阶段

5.4.1概述

测试总结阶段包括编写验收测试报告、被测软件还原两项工作内容。

7

T/CQAE11XX-XXXX

5.4.2测试总结阶段工作内容

5.4.2.1编写验收测试报告

测试方编写验收测试报告，报告应包含如下内容：

a)总结被测试软件与验收测试依据文档中软件要求的差异；

b)总结测试缺陷发现及整改情况；

c)总结软件测试需求符合情况；

d)依据测试通过准则形成验收测试结论；

e)缺陷未整改情况备案说明（如有）。

5.4.2.2被测软件还原

a)开发方应清理测试数据，将被测软件还原。

5.4.3测试总结阶段输出

验收测试报告。

8

T/CQAE11XX-XXXX

附录A

（资料性）

软件缺陷级别定义

A.1致命

阻断了软件业务流程或者使软件功能无法全面展开的致命问题。包括：

a)项目合同中要求的软件主要功能模块无法启用，导致与其相关的所有功能无法使用；

b)操作造成产品无法继续运行、重要系统文件被破坏、操作系统死机等现象。发生频率100%，

并且没有避规方法。

A.2严重

对系统的正常运行造成严重后果的问题。包括：

a)操作造成产品无法继续运行、重要系统文件被破坏、操作系统死机，发生频率较高；

b)常规操作或者符合产品需求的大量客户端或日志下造成产品或操作系统重要进程非法退出、死

循环、主要通讯中断或主要功能模块异常，重要数据破坏丢失或数据库异常，并且没有避规方

法，发生频率较高；

c)测试过程中，需求规格说明书里主要功能模块无法使用；

d)正常应用下，频繁出现资源严重泄漏、蓝屏、死机现象。

A.3比较严重

对系统的正常运行造成比较严重后果的问题。包括：

a)非常规操作造成产品崩溃、操作系统死机；

b)非常规操作（属于正确操作范围)或者在符合产品规格的压力测试（包括但不限于大量客户端

上线、下线，大数据量日志入库，长时间运行）中造成系统重要进程非法退出、死循环、主要

通讯中断或主要功能模块异常，重要数据破坏丢失或数据库异常；

c)软件的主要功能模块功能基本实现，但在合同或者需求规格说明书允许的流量、连接数等复杂

应用下功能模块工作不正常；

d)软件的次要功能模块功能失效，没有避规方法；

e)常规操作造成其它常用软件异常、系统或用户数据被破坏等问题；

f)正常应用下，出现资源泄漏、蓝屏、死机现象。

A.4一般

影响系统的次要功能或一般功能，但不会对系统的整体运行造成严重影响。包括：

a)软件的主要功能模块界面配置的问题；

b)常规操作中，软件次要模块功能失效或异常，但可以规避；

c)界面信息有歧义，提示信息造成2/3以上人员误解；

d)软件的中辅助功能模块功能失效，无法规避；

e)合同或需求规格说明书里规定的操作系统兼容性出现的问题。

A.5微小

通常不影响系统的正常运行，只是用户体验上的小问题。包括：

a)界面上对正常使用、理解没有太大影响的显示错误；

b)对键盘、鼠标支持不友好；

9

T/CQAE11XX-XXXX

c)软件次要、辅助功能模块基本功能实现，但有缺陷；

d)文档类错误；

A.6建议

从多个方面进行改进和优化，以提高软件质量。包括：

a)产品在易用性和提示风格等方面的建议；

b)从使用角度考虑建议增加或改进的功能；

c)针对功能的实现方式所提出的建议；

d)界面输入输出不规范。

10

T/CQAE11XX-XXXX

附录B

（资料性）

性能效率测试需求分析与设计（示例）

B.1被测软件背景

被测试软件为**专业技术职称申报软件，每年在规定的时间段内集中进行职称评审信息化申报工作，

为期两个月。用户通过互联网在政务服务平台统一登录后可访问职称申报软件，该软件设置了浏览器和

移动端APP两种访问方式；软件保存近三年申报数据，三年以上数据迁移归档。主要功能包括互联网端

在线提交专业技术职称评审资料和政务网端审核专业技术职称申报资料并反馈审核结果。被测试软件在

实际使用时面临着大批量用户集中访问软件情况，且对软件业务处理效率和连续性要求较高。

B.2被测试软件性能效率需求

被测试软件性能效率需求如下：

a)页面平均载入时间小于等于3s；

b)数据平均提交时间小于等于5s。

B.3性能效率测试需求分析

B.3.1性能效率测试对应功能分析

需求方对示例被测试软件的性能效率需求未指定功能点以及具体的数据容量，为保证软件能够在实

际使用时满足性能效率需求，需详细分析性能效率测试对应功能以及软件数据容量等信息，确保经测试

通过的软件在未来业务压力增大的情况下使用正常。

经分析被测试软件用户群体主要为全省企事业单位职工，根据软件核心功能以及用户使用频率情况

分析，职称申报信息填报页面载入、用户申报信息提交2处对业务连续性要求较高、性能效率压力最为

集中。

B.3.2数据容量分析

专业技术职称申报的大部分用户资料提交，集中在申报开始后的12天内，近3年职称申报人数分

别为43.7万人、40.4万人、46.5万人，性能效率测试时，数据库数据应满足未来增长最高容量，并按

照每年申报人数和申报时间计算软件用户访问峰值。

按照近三年用户申报数量，最高人数46.5万人，可以采用20%余量满足用户增长情况，取每年总

体申报人数55.8万，按照80-20原则，80%用户集中在12天申报，软件未采取错峰报名等策略，可采

用平均日访问量的3倍估算峰值日访问量：

万人

考虑用户数据容量时，按照峰值日访问量数据进行测试，根据80-20原则，每日80%用户集中在20%

55.8∗80%÷12∗3=11.16

时间申报，注意这里每日访问时间集中在09:00~21:00用户非休息时间12h，而不是24h，每日2.4h

的用户量为：

万人人

B.3.3并发场景信息分析11.16∗0.8=8.928=89280

经探索性测试，人员填报资料提交时间约为20分钟，可计算最大同时在线用户数（所有用户所需

时间除以占用时间2.4h，时间换算成分钟）约为：

人

89280∗20÷2.4∗60=992011

T/CQAE11XX-XXXX

一般可取同时在线用户数的10%~20%作为最大并发，此处并发用户数取在线用户数20%，最大用

户并发数为*20%=1984人。

B.3.4疲劳9场92景0信息分析

经探索性测试，通过抓包工具发现人员填报资料时与服务器产生交互为两个操作：打开申报信息填

报页面和提交申报数据，极限疲劳场景实际需达到目标是89280人在2.4h完成打开申报信息页面和提

交申报数据各一次。

B.4性能效率测试设计

B.4.1基础数据准备

被测软件三年共产生历史数据约84万条，软件性能效率宜在最大数据量环境下进行测试，性能效

率测试模拟第三年申报情况，性能效率测试时数据库中预先存储数据量应至少为84万条，考虑到未来

数据增长情况，增加20%数据作为数据容量的余量，测试时在数据库中预先装载100万条数据。

在性能效率测试时，需要不同人员填报职称申报数据，人员涉及到身份鉴别信息，测试时需要准备

约9万以上不同身份的用户，且考虑到数据容错，开发方预先在用户表中装载9.5万条模拟用户数据，

向测试方提供9.5万人的登录用户名、密码等信息。

B.4.2测试场景设计

测试场景设计如表B.1所示。

表B.1测试场景设计

场景对应用户用户

场景名称场景说明运行策略关注指标

类型功能个数加载

响应时间、

在互联网端模拟网页

用户并发申报事务成功

和对软件发出页同时

执行页面APP页面迭代次率、服务器

面载入请求，直至页1984加载10

载入载入资源利用

面载入完成。

用户情况

并发

在互联网端模拟网页响应时间、

场景

用户并发和对软件发出申申报事务成功

APP同时

执行申报报数据提交请求，直数据迭代次率、服务器

1984加载10

数据提交至返回提交成功提提交资源利用

示。情况

在互联网端模拟网页持续执行

和APP对软件发出申申报12个2.07h（因请

报页面载入直至完页面用户求中添加响应时间、

持续执行

成，在申报页面载入载入起，每思考时总通过事

疲劳页面载入0.33h

和申报数据提交之间和申秒增间，需保证务数、服务

场景与申报数93744

设置分钟思考时报数加执行完器资源利

据提交20122.4h

间，再执行申报数据据提个用毕），每个用情况

提交请求，直至返回交户请求迭代1

提交成功提示。次

12

T/CQAE11XX-XXXX

附录C

（资料性）

软件兼容性测试需求分析与设计（示例）

C.1被测试软件背景

被测试软件为某智慧民政综合管理平台项目中的数据库管理软件，该软件建设目的是为了实现智慧

民政基础信息全省统一入口和管理，机制上保障一人一数原则，支撑全省业务软件实时联动、业务协同，

满足跨地区、上下多级、横向多部门间数据共享需求。被测试软件对外提供36个基于WebService的接

口服务，平台中的6个应用软件根据自身需求独立调用被测试软件多个接口服务，被测试软件架构如图

C.1所示：

图C.1智慧民政综合管理平台项目软件关系图

C.2被测试软件兼容性需求

被测试软件兼容性需求如下：

a)应实现被测试软件与平台其他调用其接口服务的应用软件兼容；

b)应实现被测试软件与用户常用杀毒软件、办公软件、即时通讯软件兼容。

C.3兼容性测试需求分析

C.3.1兼容性测试内容分析

按照GB/T25000.10中对软件兼容性质量特性的定义，软件兼容性包括两方面，第一是共存性，被

测试软件运行时内部组件间或者与同一运行环境中的外部软件不会发生冲突；第二是互操作性，被测试

软件与产生交互的软件能够正常交换并使用所交换的信息，信息交换可通过程序接口，也可以通过数据

文件进行。

C.3.2与平台其他调用接口服务的应用软件的共存性分析

因被测试软件与调用其接口服务的应用软件并没有运行在同一环境，因此只需考虑接口服务调用时

被测试软件内部共存性，可确定为以下两方面：

a)应保证各应用软件对接口调用不会导致被测试软件其他接口服务关闭；

b)应保证不同应用软件同时调用被测试软件同一接口时，不会发生调用请求失败情况。

13

T/CQAE11XX-XXXX

C.3.3与平台其他调用接口服务的应用软件的互操作性分析

被测试软件与调用其接口服务的应用软件互操作性体现在接口调用操作上，互操作性测试内容应为

验证提供接口服务是否正确规范，包括以下方面：

a)被测试软件应提供基于WebService的接口服务；

b)应对调用接口请求参数是否必填进行校验；

c)接口调用请求参数、响应参数数据结构、类型、含义应与接口需求规格说明书一致；

d)应保证接口响应参数中信息提示码与接口需求规格说明书定义信息提示一致；

e)应保证新增、修改类接口调用结果实际生效，且不会影响其他未做变更的数据；

f)文件上传类接口，支持的上传文件类型与接口需求规格说明书该接口请求参数约束定义一致；

g)文件下载类接口，导出文件类型应与接口需求规格说明书中该接口响应参数的参数含义一致；

导出内容完整，与请求结果一致。

C.3.4与用户常用杀毒软件、办公软件、即时通讯软件共存性分析

分析被测试软件与其他同一环境软件共存性，应考虑软件之间是否发生接口信息交换，比如被测试

软件与其他软件是否存在互相启动或控制动作。被测试软件与杀毒软件、办公软件、即时通讯软件不存

在通过接口交换信息情况，因此只需分析软件间外部共存性，包括以下方面：

a)应保证被测试软件与杀毒软件、办公软件、即时通讯软件可同时正常运行，不发生端口冲突。

C.3.5与用户常用杀毒软件、办公软件、即时通讯软件互操作性分析

因被测试软件与用户常用杀毒软件、办公软件、即时通讯软件不存在接口交换信息情况，可进一步

分析是否存在通过数据文件交换信息情况。被测试软件存在文件上传下载接口，因此互操作性应测试上

传下载行为是否对文件造成损坏，包括以下方面：

a)应保证软件上传、下载文件可正常打开读取，文件内容无乱码。

C.4兼容性测试设计

C.4.1基础数据准备

兼容性测试对数据量的需求不高，一般需准备可供查询统计类接口服务使用的基础数据；软件开发

方应提供完整的接口需求规格说明书或规范文档，文档中应包含与业务信息相关的编码规则，构造数据

相关的数据词典、接口调用请求数据结构和返回数据结构、约束等详细描述的内容。

通过对接口需求规格说明书分析，智慧民政数据库管理软件接口服务调用的请求数据分为Control

和Content两部分，其中Control段存储的是接口服务鉴权相关数据，包含了调用接口的应用软件和发

起人身份信息，包括软件访问标识和个人CA证书签名，因此需开发方提供6个应用软件接口访问权限

数据，应用软件用户CA签名数据。

C.4.2兼容性测试方法设计

兼容性测试方法设计如表C.1所示。

表C.1兼容性测试方法设计

序号测试内容测试方法

应保证各应用软件对接口调用不会导致被测在执行调用被测试软件接口服务时，观察所有

1

试软件其他接口服务关闭接口服务是否出现关闭、出错情况

14

T/CQAE11XX-XXXX

表C.1（续）

序号测试内容测试方法

针对同一接口，采用并发方式同时发送接口调

应保证不同应用软件同时调用同一接口时，不用请求，并发用户分别设置为所有对该接口具

2

会发生调用请求失败情况备调用权限的软件和用户，观察接口响应信息

是否与请求信息对应

采用WebService方法对被测试软件提供的接口

被测试软件应提供基于WebService的接口服

3