系统测试方案指引Word文档格式.docx

1、2.8.22.8.32.8.42.8.52.8.62.8.7 易用性测试 . 9 功能测试. 10 文档测试. 10 安全性测试 .11 性能测试. 12 数据测试. 13 可扩展性测试. 14XXX项目测试方案 1 概述1.1 引言本文档包含针对XXX项目的全面的测试方案, 给出了对测试相关的文档指引，是完成XXX项目测试的指导性文件1.2 参考资料参考资料如下:1、软件评测师教程2、软件工程1.3 项目简介简单介绍项目2 系统测试2.1 概述2.1.1 范围本测试计划是针对XXX项目中规定内容的测试计划，包括： 相关文档的测试 系统的功能的测试 数据和存储处理 应用软件对操作人员身份和权限

2、验证 对非正常掉电、关机或其它软硬件故障具有一定的保护和恢复功能 启动任何一个有潜在风险的功能，对误操作造成不可恢复错误有一定的防范机制 权限管理体系 安全性测试2.1.2 限制条件本测试计划受限于产品开发人员提交测试的内容和时间的事实。根据开发人员提交模块的实际情况，本计划会做出相应修改。2.1.3 参考文档2.2 约定2.2.1 测试目标通过测试，达到以下目标： 测试已实现的产品是否达到设计的要求，包括：各个功能点是否以实现，业务流程是否正确。产品规定的操作和运行稳定。 Bug数和缺陷率控制在可接收的范围之内（少于5/1000非严重问题）。 目的是为判定该系统是否满足需求规格说明书中规定的

3、功能与性能指标提供客观的依据。2.2.2 测试环境2.2.2.1 硬件环境根据项目填写实际的硬件环境2.2.2.2 软件环境根据项目填写实际的软件环境2.2.2.3 测试工具根据项目填写实际的测试工具示例： TestDirector 8.0工具来辅助对测试活动的管理和缺陷管理。（填写实际中用到的工具） Winrunner 等自动化工具来辅助自动化测 试 LoadRunner 8.0 工具来辅助负载（压力）测试。2.2.3 送测要求（即提交测试的标准,根据项目的实际情况定,会在V3.0版本在更新）2.2.4 文档命名规范针对软件开发和测试相关内容和文档命名规范具体内容和模板参看：/测试/文档命名

4、规范目录下的相关文档2.3 组织机构2.3.1 角色与职责XXX项目测试过程参与者的角色,职责及其应具备的技能如下:2.3.2 培训2.3.2.1 系统业务知识培训 2.3.2.2 测试过程（流程）培训 2.3.2.3 工具培训 2.3.2.4 技术培训根据实际情况来定夺2.4 测试计划和进度根据开发计划制定详细的测试计划2.5 测试流程2.5.1 测试类型2.5.2 验收标准在此规定用于确定测试任务是否完成的验收标准。如一：功能完备,满足用户需求如二:测试用例执行率要达到100%，测试用例的通过率要达到80%。如三: 测试用例的覆盖率达到用户提出的主要功能点的百分率。如四：测试用例执行率要达

5、到100%，再提供一次回归测试。2.6 可交付成果规定本测试项目的可交付成果,如:测试方案、测试计划、测试用例、测试报告、缺陷报告、操作手册2.7 预测风险本次测试过程中，可能出现的风险如下： bug的修复情况 模块功能的实现情况 系统整体功能的实现情况 代码的编写质量 人员经验以及对软件的熟悉度 开发人员、测试人员关于项目约定的执行情况2.8 测试内容2.8.1 易用性测试易用性遵循三个基本原则:1、 易理解性2、 易学习性3、 易操作性具体的细节测试逐步补充完善易用性测试用例2.8.2 功能测试主要体现在一下五个方面:1、 适合性2、 准确性3、 互操作性4、 依从性5、 安全性软件所实现

6、的功能达到它的设计规范和满足用户需求的程序.2.8.3 文档测试用户文档包含了产品使用所需的信息，具有正确的信息，无歧异和错误的表达，便于用户要阅读使用。文档测试用例：2.8.4 安全性测试依据软件测试的标准，安全性测试应该包括以下几个方面：系统网络的安全性、用户认证的安全性和数据库安全性。2.8.4.1 用户认证安全性测试 对系统权限测试，系统不可出现权限混乱，不同级别的用户执行操作的界面不同。 系统不会出现同名用户冲突现象，在用户注册时，系统自动测试，对于同名的注册，系统拒绝注册。 用户登录密码是否可见，是否可以复制。 对通过绝对路径登陆系统，系统拒绝登录。 用户退出系统后，不可再通过后退

7、键再进入系统。2.8.4.2 数据库安全测试 数据是否机密 系统数据的完整性 系统数据的可管理性 系统数据的独立性 系统数据可备份和恢复能力2.8.5 性能测试2.8.5.1 测试内容 基本能力测试 模拟系统运行的业务压力和使用场景 系统的性能是否满足要求 测试参数响应时间（最小响应时间、平均响应时间、最大响应时间）是否符合需求 响应时间：用户所能感受到的响应时间，也是用户最重视的性能体验。确立响应时间的原则：2/5/10原则2：2秒钟用户会觉得是一个很好的体验。5：5秒钟用户可能会觉得差了一点，还行，比较好。 10：10秒钟是用户所能承受的最大极限。鉴于不同地区的网络环境，将用户所能承受的响

8、应时间极限定为1215秒。 负载测试 服务器端在高负载情况下的性能行为表现。负载可以是最大用户数，交易数，事务数等 系统的处理极限 容量测试 可处理同时在线的最大用户数 系统的最大吞吐量 最大并发数 压力测试 在一定的饱和状态下，系统是否会出现错误 查找系统的瓶颈 不能接受的性能点 疲劳强度测试 支持的最大并发用户数或者日常运行用户数 处理最大工作强度性能 大数据量测试 系统存储、传输、统计、查询等业务进行独立的大数据量测试 压力性能测试、负载性能测试、疲劳性能测试相结合进行综合数据量测试 并发性测试XXX项目测试方案 系统是否存在内存泄漏 是否存在线程锁 资源竞争性能测试的内容比较广泛,现在

9、主要只列举一些平常工作中比较多的监控指标: 最大并发用户数 业务操作响应时间 服务器资源监控指标 内存 处理器 磁盘I/O 数据库相应的指标等（性能测试是一个比较深的测试工作,需要更加深的研究和实践才能做的更好）2.8.6 数据测试2.8.6.1 大数据量测试2.8.6.2 SQL执行效率测试 宏观:大数量执行sql语句,查看执行时间日志,用profile工具计算平均值等 微观:跟踪oracle执行计划看sql经过哪些分区,哪些索引,多少次全表扫描等.2.8.7 可扩展性测试可扩展性测试是测试系统是否具有升级的空间，以及升级后对前版本的兼容情况。 可扩展性测试用例：2.8.8 可靠性测试可靠性

10、指在规定的时间和条件下,软件所能维持其性能水平的程度,主要体现3个方面:1、 成熟性2、 容错性3、 易恢复性软件可靠性测试，主要是在实验室内仿真环境下进行，可以根据需要和可能在用户现场进行 验证软件可靠性满足一定的要求：通过对软件可靠性测试中观测到的失效情况进行分析，可以验证软件可靠性的定量要求是否得到满足 估计、预计软件可靠性水平：通过对软件可靠性测试中观测到的失效数据进行分析，可以评估当前软件可靠性的水平，预测未来可能达到的水平。软件可靠性测试活动 测试数据：系统的输入值用其按时间的分布或按它们在可能输入范围内的出现概率的分布。 测试环境的准备：需要软件的可靠性仿真测试环境。 测试运行：

11、在真实的测试环境或可靠性仿真测试环境中，对软件进行测试。 可靠性数据收集：收集的数据包括软件的输入数据、输出结果，以便进行失效分析和进行回归测试；软件运行时间数据，可以是CPU执行时间、日历时间、时钟时间等；可靠性失效数据包括每次失效发生的时间或一段时间内发生的失效数，失效数据可以实时分析得到，也可以事后分析得到。 可靠性数据分析：失效分析根据运行结果判断软件时候失效，以及失效后果、原因等；可靠性分析根据失效数据，估计软件的可靠性水平，预计可能达到的水平。 失效纠正：如果软件的运行结果与需求不一致，通过失效分析，找到并纠正引起失效的程序中的缺陷，从而实现软件可靠性的增长。2.8.8.1 成熟性

12、测试用例主要体现在: 初期故障率 2.8.8.2 容错性测试用例2.8.8.3 易恢复性测试用例平均失效恢复时间 2.9 测试关键过程域在网上看到一些有用的资料整理如下（实际工作中也是根据这个来进行的）:完成XXX项目测试的关键过程域包括： 测试计划制订； 测试用例设计； 测试环境准备； 测试执行； 测试结果分析； 测试情况汇报。2.9.1 测试计划制订在此规定本项目的测试计划制订的步骤。示例: 根据项目名称的业务需求和技术需求，确定测试的具体内容； 对测试内容进行评审并制订测试需求；XXX项目测试方案 根据测试需求，识别不同的测试过程以及测试条件，针对每个测试过程规定测试数据的数量并对其特征

13、进行规定，即对测试用例进行描述； 识别项目活动，定义输出成果，估算每项活动所需的时间； 识别项目风险，并确定应对策略； 综合有关内容，确定阶段目标，并形成测试计划； 对测试计划进行评审、修改，直至测试计划获得批准； 将测试计划分发给有关人员。2.9.2 测试用例设计在此规定将如何进行测试用例开发。 根据测试计划中测试决策树的规定，按测试意图对每一个测试点分别设计在不同情况下的测试动作、输入和预期的反映； 形成测试用例列表； 对测试用例列表的覆盖度进行检查，完善后形成测试用例； 对于自动测试，还需根据手工测试用例修改成自动测试用例。2.9.3 测试环境准备在此规定为确保测试执行得以顺利进行所需的

14、任何有关测试环境方面的准备活动。 示例：准备硬件设备；安装软件；配置网络环境。2.9.4 测试执行在此规定测试执行活动。这些活动将使用根据测试计划制作的测试用例。 根据测试计划中有关测试环境的内容，检查测试环境（包括硬件及软件），确保测试环境符合要求； 对于测试用例的描述信息，按测试意图为每一个测试用例设计其操作流程中重要环节的动作、输入数据和预期的反映（注：此流程可不必详细到每一个具体的步骤，但应确保测试执行人员可以据此信息顺利执行，而不必询问测试用例的开发人员）； 执行测试活动，并记录所使用的机器及执行日期，对于每个测试用例还应记录关键操作步骤、输入数据以及任何与测试人员预期结果不符的系统

15、响应； 每个测试用例执行完毕后，视具体情况对系统进行备份或根据备份数据对系统进行恢复。2.9.5 测试结果分析在此对测试结果进行评估，并将这些结果与验收标准（在测试计划中事先设定）进行比较。 在本项目中，测试工作应遵循如下主要步骤： 对记录的测试结果数据进行分析； 对于存在问题的数据，分析判断产生问题的原因； 由于测试用例开发过程不合理产生的原因，提出测试用例开发过程修订建议，并记录相关数据； 由于测试执行方面的原因，提出测试用例开发过程修订建议，并记录相关数据； 由于被测软件的原因，将此情况记录在缺陷跟踪及管理系统中；（该过程域是对测试结果进行分析，软件有问题属于记录缺陷而不是分析缺陷） 根据测试结果数据计算各种度量值； 对各种度量值进行说明，给出明确的结果分析意见及有关建议。2.9.6 进行情况汇报在此规定测试组通过什么形式将测试情况汇报给管理层、应用开发组以及用户。在该报告中，测试组将给出测试结论及建议。 每周五给应用开发组反馈一周测试情况和缺陷报告，给管理者提交测试计划执行情况的报告。