软件产品检测报告1. 引言该报告主要介绍了对北京瑞易吉成数字科技有限公司实施的中国文史出版社“中央文化企业数字化转型升级”项目本次功能测试的测试过程和测试结果，通过对测试过程的检查和对测试结果的分析，达到对系统质量的认识和对整个系统的整体评估以及在以后的开发和测试工作中如何改进使软件更加符合用户的实际需求，更加易用等。

1.1.编写目的本文档作为该系统测试的测试标准，内容关系到本次系统测试可能涉及到的测试内容和测试技术解决方案。

1.2.系统概述该系统是数字出版的内容生产的管理系统。

各种内容资源通过导入工具、结构化地存储到内容资源库中，能够方便地实现内容重用和多媒体多渠道发布。

实现了出版流程再造，其中的协同编纂模块采用了灵活的工作流、严格的权限管理和明晰的版本管理，支持安全高效的内容生产。

采用了国际先进的技术标准，能够按照文件类型定制DTD模板以及拆分标准和规则，搭建了系统的内容资源库框架，支持XML内容和非XML内容的存储，实现了企业内容资产管理的目标。

2. 测试描述2.1.测试范围与内容对北京瑞易吉成数字科技有限公司实施的中国文史出版社“中央文化企业数字化转型升级”项目进行测试，保证使用方的功能正确，保证系统核心模块的稳定和安全，为项目的验收提供参考。

以此，本计划列出了在此次功能测试过程中所要进行的内容和实施的方案及测试资源的安排，作为测试活动的依据和参考。

本次测试的对象为北京瑞易吉成数字科技有限公司实施的中国文史出版社“中央文化企业数字化转型升级”项目，测试范围为：中央新闻出版总署招标文件的数字化加工、内容资源管理、编辑加工和产品发布四个包的功能清单。

本次测试的主要内容有功能测试（含容错测试）、性能测试、安全性测试、易用性测试等。

2.2.测试依据本次测试所依据的文档包含开发方提供的《需求规格说明书》、《操作手册》、《用户手册》，《维护手册》，《设计文档》等相关开发文档。

并依据IT行业项目的通用标准，包括功能测试标准、缺陷标准、易用性标准。

对于项目的易用性标准，原则上由测试方提出易用性问题修改的建议，由开发方对测试方提交的问题进行确认。

2.3.测试环境硬件平台软件平台客户端环境操作系统： Windows 7、Winddows 8浏览器：IE9、Firefox测试所用设备： HTC手机、iphone 4/5、PC3. 测试解决方案我方针对用户方提出的测试要求，根据以往项目的实际经验，撰写测试技术解决方案。

该解决方案包含了本次系统测试可能涉及到的测试类型，并分别介绍不同测试类型的内容和相关标准。

3.1.系统功能测试实施系统功能测试，完成对被测系统的功能确认。

采用黑盒测试方法，根据需求规格说明书和用户手册，将功能点转换为功能测试需求，根据测试需求编写测试用例，保证所有功能点必须被测试用例覆盖。

测试用例的编写采用基于场景的测试用例编写原则，便于以使用者的角度进行测试。

用例设计上兼顾正常业务逻辑和异常业务逻辑。

测试数据的选取可采用GUI测试，等价类划分、边界值分析、错误推测、比较测试等测试方法中的一种或者几种数据的组合，一般以等价类划分和边界值法为主。

3.1.1.系统功能项测试对《软件需求规格说明书》中的所有功能项进行测试；3.1.2.系统主要模块功能测试3.1.3.系统功能测试标准➢可测试的功能点100％作为测试需求（如未作为测试需求，必须在测试计划中标注原因并通知用户方负责人）；➢测试需求100％被测试用例覆盖；➢测试用例100％被实施（如未实施，在测试报告中标注未测试的原因并通知用户方负责人）；➢含有一类缺陷的系统不建议上线发布（缺陷严重等级见附录，需确认）；➢含有二类缺陷的系统不建议上线发布（缺陷严重等级见附录，需确认）；➢含有三类缺陷10个以上不建议上线发布（缺陷严重等级见附录，需确认）；➢权限矩阵测试覆盖率100％。

3.2.易用性测试本系统的易用性测试不是本次测试的重点。

我方的原则是在测试过程中如果发现有完全不符合IT行业习惯的操作、完成一次业务过多操作步骤和弹出窗口、界面颜色严重影响阅读、提示信息过于复杂或者简单、业务逻辑完全不符合思维逻辑的情况下，我方测试人员会提出易用性类型的缺陷，此类缺陷由用户方最终确认。

易用性测试的内容包括:软件的用户界面是否友好，是否出现中英文混杂的界面；软件中的提示信息是否清楚、易理解，是否存在原始的英文提示；软件中各个模块的界面风格是否一致；软件中的查询结果的输出方式是否比较直观、合理。

现有系统实现了如下易用性：软件的用户界面友好，未出现中英文混杂的界面；查询、添加、删除操行相关提示信息的一致性，可理解性；输入限制的正确性；输入限制提示信息的正确性、可理解性，一致性。

软件中各个模块的界面风格一致；3.3.容错测试本系统的容错测试不是本次测试的重点。

我方的原则是在测试的过程中检查对系统对非常规操作或业务流程的容错性处理，是否影响系统的正常运行，是否给与用户明确的提示信息等，此类缺陷由用户方最终确认。

容错测试的检查内容包括:软件对用户常见的误操作是否能进行提示；软件对用户的的操作错误和软件错误，是否有准确、清晰的提示；软件对重要数据的删除是否有警告和确认提示；软件是否能判断数据的有效性，屏蔽用户的错误输入，识别非法值，并有相应的错误提示。

现有系统实现了如下容错性：软件对用户常见的误操作能进行提示；软件对用户的的操作错误和软件错误，有准确、清晰的提示，为了防止误操作，有的按钮等在满足了前提条件的基础上，按钮才显示为可操作状态；软件对重要数据的删除有警告和确认提示；软件能判断数据的有效性，屏蔽用户的错误输入，识别非法值，并有相应的错误提示。

3.4.安全性测试在本次的安全性测试中，我方的原则是在测试的过程中检查对系统对非常规操作或业务流程的安全性处理，是否会造成用户内容资源的流失，进而造成经济损失等，是否存在安全漏洞，使系统容易受到外部攻击，威胁到系统的安全和正常使用等，此类缺陷由用户方最终确认。

安全性测试的检查内容包括:系统中的密钥是否以密文方式存储；系统是否有留痕功能, 即是否保存有用户的操作日志；系统中各种用户的权限分配是否合理；本系统通过用安全性检测工具Nikto进行漏洞扫描，发现了两个较低级别的信息类型的安全警示，在和北京瑞易吉成数字科技有限公司沟通和开发人员的再次鉴定之后，发现这两个并不存在安全漏洞，只是对数据类型进行例行校验，不会对系统造成威胁。

另外，现有系统在业务逻辑方面也采取了安全机制，具体内容如下：系统中的资料以加密方式存储和发布；系统是否有留痕功能, 保存有用户的操作日志；软件中各种用户的权限分配合理，自己只可见自己部门内部的资源，系统中的文档，一旦有人点击下载重要资源时，会触发审批工作流，审批通过的才能进行下载；3.5.性能测试本次性能测试通过和瑞易吉成公司和中国文史出版社沟通之后，选取了用户常用的和重要的业务环节作为测试场景，结合常用的测试策略，检测系统的性能是否满足用户需求。

我方的原则是在测试的过程中检查系统页面的响应时间、大数据的存取速率、查询检索速度等是否在用户可接受范围之内。

经测试发现以上提到的都在用户的可接受范围之内。

以下是本次性能测试相关的工具、测试策略、测试场景、各项指标等。

测试工具：LoadRunner9.0；测试策略：单场景、混合场景、快加压、慢加压；测试场景：登录、退出、拆分导入、查询检索、在线编辑、在线预览、保存版本、产品封装、在线购买、在线评论等；并发用户数：2秒内并发20、3秒内30、5秒内50；响应时间：在线编辑、在线保存、产品封装在50人并发时，响应时间大于2秒，其它的场景，单场景的平均事务响应时间均小于2秒；CPU：并发50时，user%+sys%<70%；内存：并发50时，free%>20%；IO: 并发50时，iowait%<20%；3.6.兼容性测试参照中国文史出版社的软、硬件使用环境和需求规格说明书中的规定，列出开发的软件需要满足的软、硬件环境（包括服务器环境、客户端环境）。

部署环境如下：操作系统： Windows 7、winddows 8浏览器：IE9、Firefox测试所用设备： HTC手机、iphone 4/5、PC现有系统前台支持windows 7或windows 8下的IE9、Firefox浏览器，移动终端支持HTC手机、iphone 4/5。

3.7.文档测试用户文档包括: 《需求说明书》、《系统使用手册》、《测试用例》、《测试报告》等。

对用户文档测试的内容包括:操作、维护文档是否齐全、是否包含产品使用所需的信息和所有的功能模块；用户文档描述的信息是否正确, 是否没有歧义和错误的表达；用户文档是否容易理解, 是否通过使用适当的术语、图形表示、详细的解释来表达；用户文档对主要功能和关键操作是否提供应用实例；用户文档是否有详细的目录表和索引表；文档描述与程序当前版本符合现有系统的用户文档包括:操作、维护文档齐全、包含产品使用所需的信息和所有的功能模块；用户文档描述的信息正确, 没有歧义和错误的表达；用户文档容易理解, 通过使用适当的术语、图形表示、详细的解释来表达；用户文档对主要功能和关键操作提供应用实例；用户文档有详细的目录表和索引表；文档描述符合程序当前版本；3.8.用户有特别要求的测试无4. 预期提交文档本次系统测试可能提交的文档包括《测试需求》、《测试计划》、《测试用例》、《测试报告》等。

其中测试计划、报告等根据测试回归次数而产生多份。

4.1.测试需求文档首先完成测试需求的整理，阅读项目功能性说明的相关文档，挑选出可以测试的功能点，完成测试需求的整理。

4.2.测试用例文档测试需求作为今后测试活动的指导和目标，且为测试工作量的估算提供可计算的依据。

我方制定测试需求后将测试需求提交相关人员进行审查。

通过之后，将根据测试需求完成功能性测试用例的编写。

4.3.测试日志文档测试用例设计完成之后，我方将测试用例提交给相关各方评审。

评审通过后测试人员按照测试用例实施测试。

测试人员在实施测试的时候，将每日填写测试日志。

4.4.测试报告完成一次完整的功能测试之后，我方已汇总缺陷，完成测试报告。

1. 缺陷描述：同一个稿件，下发给多个人的之后，可以创建多个选题；缺陷影响：不影响功能与流程，没做去重判断，可根据出版社需要进行定制。

2. 缺陷描述：产品封装时，未生成试读文件；缺陷影响：不影响功能与流程，产品上架时需要上传试读文件。

3. 缺陷描述：支付管理，目前只支持支付宝，不支持其他支付类型。

缺陷影响：不影响功能与流程，多个支付类型可方便用户进行多选择，一个支付方式满足支付功能，且支付宝是大众化的支付方式。

4. 缺陷描述：编辑器，上下翻看书籍时，编辑工具条悬浮在编辑器中；缺陷影响：不影响功能使用，后期进行优化。