软件系统安全测试方案

2024-05-10

软件系统安全测试方案（精选6篇）

篇1：软件系统安全测试方案

1.系统测试与验收方案

1.1.测试方案

1.1.1.单元测试

1.1.1.1.单元测试说明

在计算机编程中，单元测试（又称为模块测试）是针对程序模块(软件设计的最小单位)来进行正确性检验的测试工作。程序单元是应用的最小可测试部件。在过程化编程中，一个单元就是单个程序、函数、过程等；对于面向对象编程，最小单元就是方法，包括基类（超类）、抽象类、或者派生类（子类）中的方法。

单元测试的目标是隔离程序部件并证明这些单个部件是正确的。一个单元测试提供了代码片断需要满足的严密的书面规约。因此，单元测试带来了一些益处。单元测试在软件开发过程的早期就能发现问题。

1.1.1.2.单元测试方法与内容

单元测试主要采用白盒测试技术，用控制流覆盖和数据流覆盖等测试方法设计测试用例；主要测试内容包括单元功能测试、单元性能测试和异常处理测试等。

1.1.1.3.单元测试流程

图15-1 单元测试流程图

从配置库获取源码文件，设计测试用例，执行测试用例，并利用相关测试工具对单元代码进行测试，将测试结论填写到单元测试报告和软件Bug清单中。把软件Bug清单和测试用例执行结果提交测试负责人，并进入纳入质量管理。对源码文件进行的测试，视程序存在缺陷的情况，可能要重复进行，直至问题解决。

单元测试的执行者，一般情况下可由程序的编码者进行，特殊情况可由独立于编码者的测试人员进行。

1.1.1.4.单元测试用例

编程组组长组织、指导开发人员根据《系统设计说明书》，编写所负责代码设计模块的《单元测试用例》，设计单元测试脚本。

1.1.2.代码评审

代码评审也称代码复查，是指通过阅读代码来检查源代码与编码标准的符合性以及代码质量的活动。

评审的内容：

1)编码规范问题：命名不规范、magic number、System.out等； 2)代码结构问题：重复代码、巨大的方法和类、分层不当、紧耦合等； 3)工具、框架使用不当：Spring、Hibernate、AJAX等；

4)实现问题：错误验证、异常处理、事务划分、线程、性能、安全、实现过于复杂、代码可读性不佳、扩展性不好等； 5)测试问题：测试覆盖度不够、可测试性不好等。

评审的优点：

1)提高代码质量：在项目的早期发现缺陷，将损失降至最低

2)评审的过程也是重新梳理思路的过程，双方都加深了对系统的理解

3)促进团队沟通、促进知识共享、共同提高 1.1.3.集成测试

1.1.3.1.集成测试目的

集成测试，也叫组装测试或联合测试。集成测试是在单元测试的基础上，根据《系统概要设计》及《系统集成与开发详细设计》，对系统的各单元进行组装。把分离的系统单元组装为完整的可执行的计算机软件。集成测试的目的是检查软件单元部件是否能够集成为一个整体，完成一定的功能，并找出单元测试中没有发现的错误，包括数据定义有没有重合与冲突，接口会不会产生错误，组合以后的模块功能会不会互相影响，组合的系统是不是达到预期的效果等。

1.1.3.2.集成测试采用的方法和内容

集成测试采用白盒测试和黑盒测试相结合的测试技术和渐增式的测试策略，用数据流等测试方法设计测试用例。主要测试内容包括单元之间的接口测试、全局数据结构测试等。

1.1.3.3.集成测试流程

集成测试包括集成测试设计、集成测试准备、集成测试实施和测试记录、集成测试问题跟踪和结束测试等阶段。

集成测试设计由测试组组长根据项目计划和开发计划编制《集成测试计划》，设计《测试用例》。

测试计划和测试用例应当通过项目经理的审查。

集成测试准备需要系统测试组组长建立独立的测试环境。测试环境包括测试硬件环境、网络、数据库、应用服务器等以及测试对象(程序)的安装和初始化工作。

集成测试实施和测试记录是由系统测试组组长组织人员按照测试计划和测试用例要求进行测试，并且记录测试过程和测试结果。

集成测试问题跟踪是在测试过程中发现的问题由系统测试组组长根据测试记录提交测试问题报告，并由系统设计人员和开发人员解决每一个问题的过程。

测试结束指测试问题报告中的问题解决后，进行回归测试。当测试问题降低到一定程度并通过测试通过准则时，系统测试组组长提交测试总结报告结束测试。

1.1.4.功能测试

功能测试包括两大部分，一是包括基本业务功能、业务测试、接口测试和可用性测试等方面的功能测试，二是包括：安全性测试、故障恢复测试、数据库测试、配置测试、安装测试的产品化测试。验收测试主要从系统的实用性、稳定性、可维护性、灵活性、可操作性、和安全性方面进行测试。

（1）测试目标

组织并执行测试，以降低软件产品中存在的缺陷，保证产品的质量和可用性，测试工作的目标就是降低BUG率，从各个方面提高软件产品的质量和可用性。

（2）测试流程

在确定具体的测试范围及内容后，进行测试分类，并根据分类的结果确定需要设计的测试用例。

在整个测试过程中，我们将用缺陷管理工具BugBase对测试大纲、测试用例、测试问题等进行管理，并可对问题进行统计。

（3）测试完成标准

 实现功能完全符合功能列表。 所有的功能页面均可达。

 TD上的问题得到妥善处理，不含有A,B,C类问题。 定义的测试项目完成。 产品化测试的约束达成。

（5）缺陷管理追踪工具

在上节描述中提到的TD，可以应用于测试的全过程，也可以用于管理各类评审的缺陷等。TD还提供一些模板，例如测试计划、测试总结、测试大纲、测试问题卡，因此可以通过BugBase实现从测试计划到总结的各测试活动管理。

我们以需求说明书、软件需求规格说明为输入编写测试大纲，对应测试大纲中的内容和测试需求编写测试用例，测试人员可以根据测试大纲和用例执行测试，发现问题后，记录在TD中，测试负责人通过查看缺陷问题列表将问题分配给对应的开发人员，开发人员通过查看问题列表修改问题，TD还提供了各种统计功能，例如根据问题的发现日期、问题等级、问题的分布、问题引入阶段等进行统计，这些统计结果可用来进行分析和总结

1.1.5.性能测试

性能测试总体流程与业务系统测试的流程基本相同。验收测试主要从系统的实用性、稳定性、可维护性、灵活性、可操作性、和安全性方面进行测试。性能测试的内容源于用户对平台系统的性能要求。

1.1.5.1.测试目标

性能测试的目标是在整个系统或一个系统的特定组件上定义、建立和执行性能测试。验证系统是否满足标书的性能要求，如不能满足，要进行相应的优化。

1.1.5.2.测试流程

首先对性能测试进行策划，确定性能测试的类别和测试方法。

然后开发性能测试的用例，确定测试环境并准备就绪后执行性能测试，确定测试中的系统或组件的性能，并使用其结果决定性能是否可以被业务所接受。如果在测试中度量的性能特性证明是不能被接受的，我们可以通过对业务的改进、数据库、应用服务器等进行调优，以提高性能质量，在进行系统调优前，我们同样要进行调优的设计与分析。性能测试与应用和技术架构紧密相关并且两者互相影响。

1.1.5.3.性能测试指标

a)响应时间响应速度在用户心理所能承受的范围内。无论是客户端还是管理端，当用户登陆，进行任何操作的时候，系统应该及时进行反映，系统应能检测出各种非正常情况，并及时提示用户。

b)可扩展性

在设计上必须具有适应变化的能力，当系统新增业务功能或现有业务改变时，应保证业务在整体框架不变的基础上，业务变化造成的影响局部化。

c)易用性

所有的业务功能界面风格和操作流程一致，业务表单做到所见即所得，录入能够完全通过键盘完成。

d)可靠性

系统应保证7*24小时内不宕机，保证在正常情况下和极端情况下业务逻辑的正确性。

e)可用性

必须避免由于单点故障或系统升级而影响整个系统的正常运行。

f)可维护性

系统能够简单方便的修改和升级，包含可度性、可修改性、可测试性等。

g)可管理性和服务支持能力

每个层次、每个构件都提供标准的管理接口。实现统一的、一致的日志功能。每个构件都提供应用架构总体设计规定的必要的标准外部接口。

1.1.6.用户测试

1.1.6.1.测试流程

用户测试流程如下：

1)明确测试内容，其中包括功能、性能、可用性、安全性、兼容性、与其他系统集成

2)确定测试范围：确定业务情况类型是是非常重要的。每一种业务情况类型都对应一个实际商业业务。业务情况类型可以被表达成多种状况（例如，简单情况、或需要进行复杂处理的例外情况）。

3)测试小组成员确定：由管理人员、业务人员、技术人员等组成，我方提供验收测试过程中的技术支持。4)明确问题分类标准

5)系统的功能通过功能测试进行验证。在功能测试过程中发现的问题根据其严重程度进行分类。下表列出了功能测试问题的分类。

1.1.6.2.用户测试设计

设计测试用例：确定每个功能的测试用例，明确系统输入信息和期望的输出结果。针对需求规格说明书的每一条测试内容，确定测试用例。每个测试用例包括测试条件（包括生成测试条件需要的测试数据类型）和期望的结果。每个测试用例都应该是唯一确定的（例如，赋一个数值）。

设计测试大纲：依据测试范围生成测试大纲。对每一种业务情况类型，生成尽可能多的测试用例来完善测试大纲。为了保证测试大纲包含所有的测试用例，将测试用例的条件映射为测试大纲是非常必要的。测试大纲中测试用例的顺序安排是非常重要的，它应考虑多种方面的因素，主要考虑的因素是按照系统产生的数据，在测试大纲中安排测试用例的顺序，使得一个测试的结果作为另一个测试前提。

测试环境准备：为了预防出现问题，如数据损坏或对系统资源的争用，需要建立一个独立的测试环境。在进行测试之前，根据测试计划中确定的时机建立一个独立的测试环境。

1.1.6.3.用户测试结果

1)测试结束后，测试小组根据测试数据，制定并向验收工作领导小组提交《用户测试报告》。

2)测试报告结果说明软件满足下列要求： 3)在认可的外部设计文档中表述的功能要求 4)在认可的系统描述文档中表述的非功能要求 5)此外，测试报告中还包括对系统提出的改进意见。

1.1.7.测试产出

1)《测试计划》 2)《系统测试方案》 3)《测试用例》 4)《系统测试案例》 5)《系统测试报告》 6)《试运行测试报告》

1.2.验收方案

1.2.1.验收流程

在验收阶段，平台系统将按照用户和我公司都认可的《系统需求分析》，组织验收小组，进行功能和性能的验收测试。从系统的实用性、稳定性、可维护性、灵活性、可操作性、和安全性及系统文档、代码、规范及注释说明等方面组织全面验收。验收测试安排分为系统初验和系统终验。

1.2.2.系统初验

经过系统内部试运行，我公司对内部试运行期间发现的问题改正后，提出系统初验书面申请。验收标准将按照“需求说明书”和双方认可的有关系统设计文档所提的要求进行。用户在收到我公司验收申请后，尽快组织系统初验。初验前我公司提供全部的工程文档和安装测试报告，并提供初验测试文档，在用户认可后进行初验测试，初验通过后，系统进入正式试运行期。我公司应解决试运行期间所反映出的问题，若系统达不到合同规定要求，试运行期将继续顺延，直到系统完善，但试运行期最长不得超过一个月。

1.2.3.系统试运行

初验合格后，经用户同意，系统进入试运行阶段，试运行周期不超过三个月。在试运行期间，我公司按用户要求提供培训和技术支持，保证用户能够正确理解和使用系统；我公司对试运行中出现的任何问题及用户提出的修改意见将及时做出响应，并提交解决方案，在用户确认后实施。试运行期间如出现重大故障，则试运行期从故障排除之日起重新计算。

1.2.4.系统终验

试运行期结束后，如系统无功能缺陷，能够正常运行，在具备终验条件下进行系统终验，由我公司提出终验书面申请，用户在收到我公司验收申请后，尽快组织系统终验。成立项目全面验收小组，由用户、我公司以及外部专家等组成，对项目进行全面验收。系统终验前，我公司提交终验测试标准和终验测试计划，内容包括：测试对象及应达到的测试指标、测试方法和测试条件、测试资料和数据，并以图表说明每一测试对象或过程的功能输入输出测试进度。

系统终验标准：

1)系统实用性：项目验收最关键的指标，检查系统是否符合当前业务的需要，特别是业务流的整体性和数据流的一致性，并前瞻性提供未来业务接口。

2)系统稳定性：硬件环境的稳定性、软件运行异常处理和正常运行情况。3)系统可维护性：含网络系统管理与维护、服务器系统平台管理与维护、操作系统管理与维护、应用系统软件管理与维护、数据库管理与维护以及数据库备份、应用系统备份，灾难事件处理与解决实施方案等。

4)系统文档：验收文档是否齐全、规范、准确、详细，主要的文档包括：需求分析报告，框架设计报告，数据库物理及逻辑设计报告，详细设计报告，编码规范及技术选型报告，测试报告，系统部署和发布报告，集成方案，软件用户使用手册，系统维护方案和操作文档等。

5)代码规范及注释说明：程序代码编写是否规范；注释说明或代码文档是否详细全面；接口定义是否符合局信息系统规划一致性的要求。

6)系统灵活性：系统是否方便客户进行维护；系统是否在先进性的基础上具备未来升级和可扩充性；是否利于系统平台迁移和部署等。

7)系统可操作性：界面是否友好性；是否实现傻瓜化操作和智能化数据检索功能。

8)系统安全性：是否有完善的安全机制保证系统的安全性，如软件方面的安全防范（加密措施、相关认证、数据库安全防范），硬件方面（防火墙、物理隔离和逻辑隔离）的安全设置。

9)其他验收标准：其他的与本系统相关的验收标准。系统终验流程安排

1)我公司按照项目验收计划完成验收准备工作 2)用户代表运行验收测试用例集，记录运行结果

3)如果发现没有通过的验收测试用例，则我公司立即解决问题 4)用户主持项目验收会

5)我公司向用户报告项目实施结果 6)用户代表向用户报告试运行结果

7)用户评议项目实施和试运行结果，起草和审定项目验收报告。

1.2.5.系统终验相关文档

我公司在软件开发和系统集成中将严格按照国家软件工程有关要求提供的文档来提供，验收的技术文档至少包含以下内容： 1)系统需求分析 2)系统概要设计 3)系统详细设计 4)数据库详细设计 5)应用系统集成实施方案 6)系统测试大纲 7)系统测试报告 8)系统验收报告 9)系统用户使用手册 10)系统安装维护管理手册

1.2.6.终验报告

验收小组将在终验结束后提交一份由专家签名的验收报告。验收报告附平台系统和整体系统测试结果报告，同时给出以下明确结论之一：

（1）通过验收；

（2）基本通过验收，要求在五个工作日内完善后再次进行验收；（3）未通过验收，要求在十五个工作日内改正后再次进行验收；如再次验收后仍然不能全部通过，用户有权终止合同，并要求我公司承担违约责任。

验收结束时,我公司将平台系统相关产品说明书、系统安装手册、技术文档、资料及安装、测试、验收报告等文档汇集成册交付用户。

篇2：软件系统安全测试方案

（仅供参考）

文档版本控制

文档版本号

日期

作者

审核人

说明

V1.0.0

2015/X/X

创建文档

1.概述

【软件的错误是不可避免的，所以必须经过严格的测试。通过对本软件的测试，尽可能的发现软件中的错误，借以减少系统内部各模块的逻辑，功能上的缺陷和错误，保证每个单元能正确地实现其预期的功能。检测和排除子系统（或系统）结构或相应程序结构上的错误，使所有的系统单元配合合适，整体的性能和功能完整。并且使组装好的软件的功能与用户要求(即常说的产品策划案)保持一致。】

2.测试资源和测试环境

2.1硬件的配置

关键项

数量

性能要求

期望到位阶段

测试PC机

1台以上

奔4，主频2.6GHZ，硬盘300G以上，内存2G以上，此配置是实际用机

需求分析阶段

数据库服务器

暂定1台

奔4，主频2.6GHZ，硬盘300G以上，内存4G以上，此配置是实际用机

需求分析阶段

2.2.软件配置

资源名称/类型

配置

操作系统环境

操作系统主要分为windows

XP，windows

7。其中windows

XP和windows

7是重点测试对象

浏览器环境

主流浏览器有：IE（IE8以上）、Chrome、Firefox。此测试根据软件研发人员提供的依据决定测试范围

功能性测试工具

手工测试

测试管理工具

DevSuite

2.3.测试数据

本测试方案的测试数据来源于软件测试需求以及测试用例。

3.测试策略

系统测试类型及各种测试类型所采用的方法、工具等介绍如下：

3.1.1.功能测试

测试范围

验证数据的精确度、数据类型、业务功能等相关方面的正确性。

测试目标

核实所有功能均已正常实现，即是否与需求一致。

采用技术

主要采用黑盒测试、边界测试、等价类划分等测试方法。

工具与方法

手工测试

开始标准

开发阶段对应的功能完成并且测试用例设计完成完成标准

测试用例通过并且最高级缺陷全部解决

特殊项

比如该产品可能隶属于A产品线，且A线新功能点多等风险性产品

3.1.2.用户界面(UI)测试

测试范围

1.导航、链接、Cookie、页面结构包括菜单、背景、颜色、字体、按钮名称、TITLE、提示信息的一致性等，2.友好性、可操作性（易用性）

测试目标

核实各个窗口风格（包括颜色、字体、提示信息、图标、title等）都与需求保持一致，或符合可接受标准，能够保证用户界面的友好性、易操作性，而且符合用户操作习惯。

采用技术

网页测试通用方法

工具与方法

手工测试、目测(扫描)

开始标准

界面开发完成完成标准

UI符合可接受标准，能够保证用户界面的友好性、易操作性，而且符合用户操作习惯

测试重点与优先级

根据实际需求而定

需考虑的特殊事项

根据实际需求而定

3.1.3.性能测试

测试范围

1.用户、管理员的密码安全

2.权限

3.非法攻击

测试目标

1.用户、管理员的密码管理

2．应用程序级别的安全性：核实用户只能操作其所拥有权限能操作的功能。

3．系统级别的安全性：核实只有具备系统访问权限的用户才能访问系统。

采用技术

代码包或者非法攻击工具

工具与方法

手工测试

开始标准

功能测试完成完成标准

执行各种非法操作无安全漏洞且系统使用正常

测试重点与优先级

根据实际需求而定

需考虑的特殊事项

根据实际需求而定

3.1.4.安全性测试

测试范围

1.用户、管理员的密码安全

2.权限

3.非法攻击

测试目标

1.用户、管理员的密码管理

2．应用程序级别的安全性：核实用户只能操作其所拥有权限能操作的功能。

3．系统级别的安全性：核实只有具备系统访问权限的用户才能访问系统。

采用技术

代码包或者非法攻击工具

工具与方法

手工测试

开始标准

功能测试完成完成标准

执行各种非法操作无安全漏洞且系统使用正常

测试重点与优先级

根据实际需求而定

需考虑的特殊事项

根据实际需求而定

3.1.5.兼容性测试

测试范围

1．使用不同版本的不同浏览器、分辨率、操作系统分别进行测试。

2．不同操作系统、浏览器、分辨率和各种运行软件等各种条件的组合测试。

测试目标

核实系统在不同的软件和硬件配置中运行稳定

采用技术

黑盒测试

工具与方法

手工测试

开始标准

项目组移交系统测试

完成标准

在各种不同版本不同类项浏览器、操作系统或者其组合下均能正常实现其功能（此测试根据开发提供依据决定测试范围）

测试重点与优先级

根据实际需求而定

需考虑的特殊事项

根据实际需求而定

3.1.6.回归测试

测试范围

所有功能、用户界面、兼容性、安全性等测试类型

测试目标

核实执行所有测试类型后功能、性能等均达到用户需求所要求的标准

采用技术

黑盒测试

工具与方法

手工测试和自动化测试

开始标准

每当被测试的软件或其环境改变时在每个合适的测试阶段上进行回归测试

完成标准

95%的测试用例执行通过并通过系统测试

测试重点与优先级

测试优先级以测试需求的优先级为参照

需考虑的特殊事项

软硬件设备问题

3.2．测试实施阶段

测试类型

测试阶段

单元测试

集成测试

系统测试

验收测试

功能测试

性能测试

安全性测试

兼容性测试

用户界面（UI）测试

回归测试

每当被测试的软件或其环境改变时在每个合适的测试阶段上进行回归测试。

备注：“ü”表示由测试组执行，“×”表示由项目组执行；

4.软件测试的通用标准

被测系统无业务逻辑错误和二级的BUG。经确定的所有缺陷都已得到了商定的解决结果。所设计的测试用例已全部重新执行，已知的所有缺陷都已按照商定的方式进行了处理，而且没有发现新的缺陷。

注：缺陷的严重等级说明

A：严重影响系统运行的错误；

B：功能方面一般缺陷，影响系统运行；

C：界面布局不美观或轻型错误；

不影响运行的错别字等；

E：合理化建议。

5.测试用例及测试用例追溯表

5.1.1测试用例模板(仅供参考)

篇3：移动安全测试方案

当前随着移动智能终端的普及, 越来越多的公司都在将其业务从传统PC互联网模式向移动终端模式发展和迁移。企业在快速开发和推广APP应用系统的同时, 不可避免地引入了大量新的安全问题, 移动终端安全面临着技术、管理和法律等几个方面的挑战, 主要包括终端窃取和假冒、无线网的窃听、交易抵赖、移动终端遗失和设备的不安全等。因此为了提高移动业务系统和关联数据的安全性, 保证企业移动业务系统的安全、快速发展, 必须在针对移动应用系统展开有效的安全检测。但目前对于移动安全的研究主要集中在各项防御技术的突破上, 如文献[1]提出以地址为驱动的网络体系, 充分利用IP地址的多重属性, 解决互联网的规模扩展、安全可信等问题;文献[2]特别为电力企业设计的移动安全接入平台等。相反关于移动安全测试方面的研究较少, 如文献[3]提出针对移动银行信息安全进行加密等技术防范;文献[4]提出包括静态行为和动态行为的检测方式, 解决了静态行为检测缺乏对未知样本的检出能力问题, 但都不够全面。本文旨在提出一套简单而系统的移动安全测试方案。

1 移动安全测试方案

本方案从应用程序安全、密码和安全策略、权限与界面安全、隐私与存储安全、通信安全等方面对移动应用进行全方位的安全测试。

1.1 应用程序安全

移动应用程序安全测试可以从以下几个方面进行验证[5]:

(1) 源代码保护

加密系统核心代码, 保证代码在静态或者运行时均不可见、具备反调试机制, 防止被破译或者反编译。

(2) 反动态攻击

客户端对关键操作应采取反劫持攻击防御;尽力避免在内存中保留关键数据, 减少非加密信息存在的时间;在读取利用任何数据的时候, 考虑数据被篡改的可能性;应针对内存中临时存在的关键信息做加密或者映射处理。

(3) 异常处理

当软件发生系统故障时, 保证系统能够保存重要数据并正常结束。拒绝在异常处理过程中直接把异常信息返回给用户, 以防有经验的攻击者据此分析程序逻辑。

(4) 软件更新检查

移动客户端应用程序应该提供安全更新接口, 同时检查更新程序的合法性防止恶意程序伪装成合法的应用程序。

1.2 密码与安全策略

密码安全重要性是不言而喻的, 制定验证密码安全策略是一个移动测试方案的重要组成部分, 主要可以从以下几个方面进行:

(1) 身份鉴定

标识:用户注册时, 采用用户名和用户标识符标识用户身份, 确保系统整个生存周期用户标识的唯一性。

鉴别机制:每次用户登录和重新连接系统时, 应采用受控制的口令、基于生物特征的数据、数字证书以及其他具有安全强度的两种或两种以上的组合机制进行用户身份鉴别, 而且其中一种鉴别数据是不可伪造。

认证方式:用户身份鉴别强度选择应该依据重要的程度, 对高价值、可能造成风险的操作使用高强度的身份鉴别。

此外, 对鉴别数据进行保密性和完整性保护;验证必须在可信系统上进行:包括HASH计算, 避免向客户端透露更多的计算信息。

(2) 二次身份鉴别

对高价值交易、系统和业务关键功能重新进行身份鉴别。如:修改密码、业务交易关键流程、系统配置信息。

(3) 认证失败后的处理方式

连续失败后锁定账号:锁定后可由系统维护人员解锁, 或者一定时间后自动解锁, 锁定的时间应该足够长, 但不能长到允许执行拒绝服务攻击。

安全报错信息:用户认证失败的提示应该模糊处理, 不应该使用“用户不存在”或者“密码错误”这类可以逆推业务逻辑的提示。

(4) 口令策略

口令强度:限制口令设置的最小长度, 大小写字母、数字、特殊字符混淆的口令强度。

双因素认证:如果使用手机短信或动态令牌双因素认证, 应该设置口令的有效生命周期。

(5) 图片验证码

图片验证码可以抵御自动识别软件的暴力登录攻击, 一般在服务端进行, 先验证图片验证码, 再验证用户名和密码。图片验证码的实现应该最低4位, 并且使用字符随机扭曲、字符颜色和背景色随机、大小随机等多种防自动识别机制。

(6) 密码重设

重设问题应支持尽可能的随机, 或者让用户选择重设问题;重置密码发送邮箱避免完整的显示给用户时, 设置邮件的有效生命周期;重设后应该强制用户修改密码, 修改完应通知用户。

(7) 常规登录控制

登录验证码技术:使用图形验证码进行系统注册等关键操作, 可以有效防止恶意程序的试探和暴力破解。

超时控制:登录后超过N分钟未使用, 服务器端设置用户链接超时, 重新登录等。

登录控制:登录时, 连续超过N次输入密码或图形验证码错误, 则锁定账户, 用户需亲昨临柜面办理解锁业务或通过其它方式验证身份来修改密码。

1.3 权限与界面管理

(1) 权限界面原则

通过权限的管理, 确定已通过验证用户的访问和操作权限。防止错误的授权或弱授权导致应用程序信息和用户敏感信息被非法访问或篡改。

①纵向越权:一个低权限的用户访问高权限用户的资源或功能。

②横向越权:用户尝试访问与其同级权限用户的资源或功能。

(2) APP权限最小化

程序本身可以在安装或运行时被授予很多权限和功能, 如发送短信, 手机定位, 访问其他应用程序等, 这些权限和功能在特定环境下可能被恶意代码所利用。根据软件设计的基本原则——最小特权原则, 在设计应用程序的功能和权限时, 只赋予完成操作的必备权限和最少功能。

(3) APP权限管理

创建基于角色的授权:制定创建基于角色授权的访问控制方法, 同时对所有系统用户分析访问角色, 当用户尝试访问受限制资源时, 验证其角色。

代码执行权限最小化:用户不能做的事情, 代码也不能做, 以防止某些情况代码权限被滥用。

使用可信系统对资源进行授权和验证。

(4) 对下列资源进行访问授权控制

制定文件、受保护的URL、应用程序、数据、用户、数据属性的访问控制策略、任何服务端的数据、文件的创建行为都应受控。此外, 如果访问状态数据必须存储在客户端, 则应使用加密算法, 并在服务端检查其完整性以防止状态改变。

(5) 限制单位时间内事务请求数量

限制单一用户或者外部数据请求在单位时间内可执行的事务数量, 请求数量应该高于业务实际需求, 但也应该足够抵御和判断自动化攻击, 常见的如:获取某些状态数据、用户执行业务操作频率。

(6) SQL注入

移动系统提供了应用轻量级数据库系统, 应用程序可以构造SQL语句, 实现对本地数据库的各种操作, 方便数据存取。移动平台SQL语句操作与普通WEB平台一样存在SQL注入危险, 造成越权访问, 最终导致应用程序的敏感数据和用户隐私数据泄露。

1.4 隐私与数据存储安全

(1) 内存数据安全

关键信息在内存中加密存储、使用完毕后, 及时清除, 不能存留了非业务必须的敏感数据。

(2) 本地数据安全

应对本地存储数据进行有效的加密保护;敏感信息在日记显示及相关数据表中存储时, 采用替代处理;如果存储了Cookie数据, 在用户退出时及时删除;加密存储HTML5、JS等文件, 引入反纂改保护机制。

(3) 调试信息安全

软件运行时会输出运行日志, 关键信息必须进行脱敏处理, 以防日志输出功能设计失误, 导致泄露用户和系统的敏感信息等危险。

1.5 通信安全

(1) 会话管理

设计者应该根据会话的特性制定合理的会话管理机制:

COOKIE:由客户端以文件的形式保存在硬盘上或者浏览器所占的内存中, 在一定时间内保持生效, 生效时间内再次访问不需要进行身份鉴别, cookie由于是在客户端保存, 所以被盗用的风险比较高。

SESSION:验证完后在服务端生成一段会话标识, 由服务端保存。所以session安全性高于cookie, 但更耗服务器资源, 可考虑采取清除长时间不活动的session来保证服务器性能。

COOKIE+IP或SESSION+IP:为了防止会话标识被盗用, 目前比较好的控制手段是验证访问者的IP和会话标识符, 如果同一会话标识符两次访问的IP地址不相同, 则认为session被盗用。

(2) 传输安全控制

移动应用设计应采用SSL安全传输协议, 该协议能够有效地防破译、防篡改、防重发, 对传输数据进行高强度的加密, 确保数据安全性。

(3) 通讯全程加密

除了SSL之外, 还应采用数据二次加密处理, 实现手机终端与服务器应用之间通讯的全程数据加密。

(4) 组件通讯安全

客户端应用组件与组件之间的通信, 所引发的安全问题也应该被进行关注。

1.6 输入输出安全

(1) 密码键盘控件

登录密码及交易密码等敏感信息均采用服务器生成混淆后的动态密码输入键盘进行录入和对应密码编码, 输入信息在内存或者本地均不以明文存在, 从根本上对信息进行有效保护, 用户提交密码时由客户端上传密码编码, 由服务器解释成密码明文。

(2) 反屏幕录像

输入关键信息时, 屏幕应该不回显任何输入信息, 不能以按键水印, 按键变色等方法提示用户输入, 关键信息也不能短暂明文显示。

(3) 反屏幕劫持

输入关键信息时, 应用应当有能力检测当前页面是否由本程序显示, 并始终保持本应用显示界面处于最顶端。

总之, 移动安全测试方案并不是一个固定的方案或者操作流程, 而应该是一个方法论和指导思想, 每个企业的移动应用环境都有着自身的特性, 企业在进行移动安全测试、防范企业移动应用安全漏洞时, 应该结合自身的特点, 为企业本身打造一个安全的移动应用环境。

2 总结

本文从移动安全测试的角度提出了整个移动安全测试的着重关注点和验证点, 较为系统的介绍了移动安全的测试方案, 提升了移动用户使用设备的安全防范意识, 有效的提高移动安全测试人员安全测试的效率和安全测试质量。

参考文献

[1]吴建平, 李丹, 毕军, 徐恪, 李星, 朱晶.ADN:地址驱动的网络体系结构[J].计算机学报, 2015.

[2]吴克河, 崔文超, 何健平.电力企业移动安全接入平台[J].计算机系统应用, 2014.

[3]郑德春, 姚庆栋, 刘鹏, 余巧燕.移动银行的信息安全及防范对策[J].武汉大学学报, 2008.

[4]陈建民.基于行为的移动应用程序安全检测方法研究[J].计算机工程与设计, 2012.

篇4：软件测试方案分析与研究

关键词：软件测试测试方案测试计划测试用例

0引言

目前，越来越多的软件企业涉及高质量高可靠性软件项目的开发，作为软件质量控制和保证软件工程过程质量的最有效方法，软件测试在项目开发过程中的地位与日俱增。软件测试的总目标就是：确保软件的质量。如何有序开展测试工作从而保证软件高质量高可靠性，已经成为众多企业面临的一个重要课题。本文主要讨论了测试过程的核心测试方案的相关理论和技术。

1软件测试方案概述

1.1测试方案概念测试方案属于软件工程的范畴，制定合理规范的测试方案是软件测试的核心环节。测试方案是描述所测软件的测试特性、测试方法、测试用例设计、测试代码设计、测试环境规划以及测试工具设计和选择的一种策略与方法。测试方案有助于软件项目成员理解和执行测试过程中的各项活动，同时测试方案也有助于测试活动的管理。

1.2测试方案目标测试方案描述和定义了软件系统进行测试的策略和方法。其主要目标是：在完整的软件开发周期中，有效安排和管理测试工作，建立一个全面的测试计划，定义该软件在不同阶段的测试性质和测试程度，协调测试工作使其按照进度表有序进行，并按期接收应该交付的文档和作品。

1.3测试领域发展目前，测试领域的需求和应用非常广泛，所应用的技术从软件技术到模拟数字、从电子商务到低频高频，微波、从测试到诊断、从维修到保障，方方面面都在快速发展，展现在我们面前的专业词汇，如仪器、虚拟仪器、测试、虚拟测试、虚拟试验、诊断与维修、预测与评估、BIT等日新月异，这些都是测试领域新技术发展和应用的载体。针对不同的测试对象，制定测试方案的策略和重点也不同。

2测试方案和测试计划

目前，仍然有学习者误认为测试方案就是测试计划。实际中，由于各个测试项目规模和范围的不同，一些软件企业的测试工作往往都是在制定测试计划之后直接开始测试设计以及测试执行，这就给初学者们造成一定的误解，以为测试计划就等同于测试方案，然而这种想法是错误的，测试方案不同于测试计划，它和测试计划有着明显的区别。当然也存在一定关联。

2.1定义不同测试计划是对测试过程的组织、资源、原则等进行的规定和约束。测试计划制订测试过程各个阶段的任务以及时间进度等安排，提出对各项任务的评估、风险分析和需求管理。而测试方案则是描述所测软件的测试特性、测试方法、测试用例设计、测试代码设计、测试环境规划以及测试工具设计和选择的一种策略与方法。

2.2层次不同测试计划是管理层面的，从组织管理的角度规划涮试活动.而涮试方案是枝术层面的.从技术的角度规划测试活动。

2.3进度不同测试过程分为四个阶段：单元测试、集成测试、系统测试和验收测试。而每个阶段都要按照测试计划，测试设计.测试实现，测试执行的步骤来实现。测试计划说明书是测试计划阶段的产品，而测试方案则是测试设计阶段的产品。其中每个阶段的执行必须是在上层阶段产品通过评审后才能开始。

2.4内容不同测试方案和测试计划包含内容上的区别是二者的本质区别。

2.4.1测试方案的内容：明确策略，细化测试特性(形成测试子项)，测试用例的规划，测试环境的规划，自动化测试框架的设计以及测试工具的设计和选择。

2.4.2测试计划的内容：①明确测试组织的组织形式；②测试组织和其他部门关系以及责任划分；③测试组织内的机构和责任安排；④明确测试的测试对象(明确测试项，用于后面划分任务，估计工作量等)：⑤完成测试的需求跟踪；⑥明确测试中需要遵守的原则；⑦明确测试工作任务分配是测试计划的核心：a进行测试任务划分b进行测试工作量估计c人员资源和硬件资源分配d明确任务的时间和进度安排e风险的估计和回避措施f明确测试结束后应交付的测试工作产品。

由上可以看出测试方案和测试计划有着明显区别，但实际上在一些规模较小的软件企业中，由于受人力资源和资金成本的限制，制定测试方案和测试计划的界限并不明显，有时会在测试计划中会包含一些测试方案的内容，即测试环境规划、测试工具选择以及测试用例设计方法等，也就是说对于小规模软件项目，其测试计划和测试方案有时会结合在一起。但这种做法是不合适的，一般对于大型软件公司，针对大规模项目，必须把测试方案和测试计划的制定分开进行，这样更加有利于整个测试项目运作和项目组之间的交流，更会起到保障软件质量的作用。

总而言之，测试方案需要在测试计划的指导下进行，测试计划提出“做什么”，而测试方案明确“怎么做”。二者既有区别又有联系，概念总归是概念，读者可以不必拘泥于此，根据软件项目规格大小以及实际应用环境，测试人员应该具体问题具体分析。

3结束语

篇5：汽车类EMC测试系统解决方案

近几年来我们国家的汽车行业在近年发展较快，但是总体来讲我国在汽车电磁兼容测试标准和规范方面的发展相对滞后，不过近几年的相关标准的更新以及新标准的发布，都证明了在标准制定方面的快速发展，以同步国内汽车行业的发展。随着科技的发展，汽车业的强劲增长，车载电子设备的增加，汽车EMC设计标准和规范就扮演着极为重要的角色。现在，汽车里的多媒体娱乐，蓝牙通讯，卫星定位，刹车，安全气囊等系统都有可能对外界发出干扰信号，或者汽车进入强干扰区，因车载电子系统过于敏感而导致操作失灵，轻则造成驾驶不便，重则导致车祸，危及生命安全。所以，汽车电子电磁兼容包括干扰测试(EMI）和抗扰度测试(EMS)，两种测试都含有辐射及传导的测量要求。

目前在汽车及车载电子设备EMC测试领域，其标准主要有以下几类：汽车电磁兼容国际标准，如ISO、CISPR等；欧洲汽车电磁兼容标准；美国汽车工程学会（SAE）电磁兼容标准等。当然，相对比较发达的大的汽车原厂，有自己的EMC测试标准和规范。

基于上述标准和规范的发展趋势、汽车及车载电子设备EMC性能的要求，更加突出了ISO和CISPR标准的重要性，下面就是相关的主要测试标准和规范，及常宁为客户所提供的方案。

汽车,SAE,ISO 和特殊制造商测试：

1.ISO11452-2 在微波暗室中测试辐射传导抗扰度，200MHz-18GHz 2.ISO11452-3 在TEM小室中测试辐射传导抗扰度，10KHz-200MHz 3.ISO11452-4 为放射测试,使用大电流注入,1-400MHz

4.ISO11452-5 测试辐射传导抗扰度，10kHz-400MHz 5.ISO11452-7 为直接注入方式的放射测试，250kHz-500MHz 6.CISPR25 为辐射和传导放射测试，10kHz-1GHz 7.ISO7637 为射频脉冲的不同波形和测试水平

对于原厂测试规范，各厂商的侧重点有所不同，有的厂商注重汽车电子设备的EMC及其安全性能，有的厂商则注重于汽车EMC及其机械性能。然而，随着汽车市场的国际化，汽车原厂在EMC标准及规范方面有统一的趋势，以国际标准 CISPR 和ISO 作为设计规范参考。对于国内的汽车工业要走向国际化市场，需要对这方面的发展和变化作以跟踪，以适应其标准，这样才会在竞争中处于有利地位。• EMI测试：辐射发射骚扰

传导耦合/瞬态发射骚扰 • EMS试验：辐射场抗扰性试验传导耦合/瞬态抗扰性静电放电（ESD）大电流注入（BCI）横电磁波（TEM）小室带状线

机动车电磁兼容性（EMC）的重要性

机动车（包括汽车和摩托车）的电子控制自动化程度日益提高，涉及车辆的安全、环保、节能等国内技术法规和强制性检验标准。

机动车对环境的电磁干扰以被视为与噪声、排放同等重要的公害，涉及到环境保护、人身健康安全等。

机动车整车及零部件工作环境通常很恶劣，始终处于一个充满电磁噪声的环境，为了避免互相干扰，车辆必须具有优良的电磁兼容性能。

机动车电磁兼容性（EMC）的作用

对外界环境发射出的电磁骚扰强度必须足够低。

能够承受的外界电磁环境的干扰。

内部电子控制系统间不能残生相互干扰。

机动车电磁兼容性（EMC）测试标准

常宁设计、制造和安装在机动车测试中的测试系统，遵照ISO规定完全适用于以上标准。

测试场地类型：

电波暗室场地中：

（如有电波暗室安装有汽车EMC专用测试转鼓对测试将会有非常大的帮助。）

机动车电磁兼容性测试的技术条件 EMC电波暗室系统部分

大型半电波暗室、转鼓室、控制室、放大器室等。

EMC测试仪器系统：

辐射/传导骚扰测试系统、辐射/传导抗扰性测试系统、静电放电抗扰性测试系统等，及各类测试天线组成。

EMC测试转鼓系统

转台：安装全套转鼓的机械设备，同时带动车辆和转鼓水平旋转

转鼓：能够模拟汽车行使状况，采集测试数据。

冷却：用迎面风机对车辆和发动机进行冷却。

固定装置：用于固定车辆，保障车辆的安全轴距调整系统：调整前后轴之间的距离，以适应不同轴距的车辆。

车辆尾气排气系统：将车辆尾气排出暗室外部。

车辆行使控制装置：控制车辆的离合、制动、油门塌板等；实现车辆的起步、加速和制动等。

测试系统构架分析：

为了强调汽车的安全，在汽车EMC 测试中，其抗扰度测试(EMS)标准的设计和规范显得更为重要。ISO 11451 和ISO 11452 是针对汽车与车载电子进行的抗扰度性能的标准和规范。其中，辐射抗扰度和大电流注入为连续波抗扰度。辐射抗扰度以一米的测试距离向测试产品施加场强，根据不同的测试等级，其场强要求不同，频率从10kHz －18 GHz，而不同等级的场强意味着被测件在紧急情况下，在汽车安全方面所呈现的重要性。换句话说，越是对安全有直接和重大影响的被测件，场强的要求就越高，一般都从100V/m 或200V/m 开始。大电流注入法(BCI)，一般都做到400MHz, 注入电流为100mA－200mA，采用功率放大器放大的信号加到注入钳上，有分开环或闭环测试。根据测试要求，整车的辐射抗扰度测试要在暗室内进行，而部件的辐射抗扰度测试相对灵活，可以在暗室、带状线或者TEM小室内进行相关的测试。

辐射抗扰系统：

本系统包含两个基本部分；一个（10kHz-1GHz）低频测试系统和一个高频微波（1GHz-18GHz）测试子系统。该测试系统将由安装在控制电脑内部的EMC测试软件控制，并智能化控制完成整个测试过程。该软件由常宁自行研发，具有智能、快速、精密等特点，且完全按照中国客户需求所设计。完全符合国内客户测试要求。

该系统由“信号发生器，功放器，开关系统，功率表和场强测量探针”等国外知名品牌公司的设备所组成，而常宁也可按照客户指定设备厂商要求，完成系统整体交钥匙工程。

配备建议：微波测试子系统需要安置在离暗室最近的屏蔽室内，因为在高频的微波里，信号将会有很强的方向性和很大的损耗。因此保持电缆的长度越短，将越能节省能量的损耗。如果有必要，我们也可将该测试系统移至暗室内。而对于辐射抗扰测试的控制，我们不必要担心；信号开关将根据不同的测试连路，自动连接到恰当的功放器及测试天线。此部分测试也将通过我们的软件全自动完成。

CISPR 12 和CISPR 25 是针对汽车和车载电子的骚扰特性的测量规范。内容涵盖了辐射及传导测试以及各项测试的方法要求、测试布置、极限等。辐射测试主要是针对汽车及其车载设备，对于辐射测试，通过接收天线和测试接收机来进行测试。频率为150kHz －1GHz，并且这一测试频率的上限要进一步扩展，1GHz－18GHz频段的测量方法正在考虑中。传导测试则根据被测产品供电的电源线及其回线的长度的不同，做出不同的测试布置。

放射系统设置为一个CISPR16接收器，按照制定标准，接收器是由软件控制并允许和不同种类的天线测量。放射也可以在TEM小室，用于ISO11452。