第三方软件测试报告[模板]

萌到你眼炸
958次浏览
2021年02月13日 08:09
最佳经验
本文由作者推荐

-

2021年2月13日发(作者:矫情镇物)






















WORD


格式


.


可 编辑

































第三方软件测试报告(暂定)




1.



引言



1.1.



编写目的



本文档作为该系统测试的测 试标准,


内容关系到本次系统测试可能涉及到的


测试内容和测试 技术解决方案。



1.2.



系统概述







2.



测试描述



2.1.



测试范围与内容



我方(北京圆规创新 公司)对


XX


公司“


XX


”项目


进行测试,保证使用方的功


能正确,保证系统 核心模块的稳定和安全,为项目的验收提供参考。以此,本计


划列出了在此次功能测试过 程中所要进行的内容和实施的方案及测试资源的安


排,作为测试活动的依据和参考。



本次测试的对象为


XX

< br>公司“


XX


”项目


,测试范围为 :





本次 测试的主要内容有功能测试(含容错测试)、易用性测试




2.2.



测试依据



本次测试所依据的文档包含 开发方提供的


《需求规格说明书》



《 操作手册》



《用户手册》,《维护手册》,《设计文档》等相 关开发文档。

































技术资料分享
























































WORD


格式


.


可 编辑

































并依据


IT


行业项目的通用标准,


包括功能测 试标准、


缺陷标准、


易用性标准。


< /p>


对于项目的易用性标准,


原则上由测试方提出易用性问题修改的建 议,


由开


发方对测试方提交的问题进行确认。

< br>



3.



测试解决方案



我公司针对用户方提出 的测试要求,


根据以往项目的实际经验,


撰写测试技

< p>
术解决方案。


该解决方案包含了本次系统测试可能涉及到的测试类型,


并分别介


绍不同测试类型的内容和相关标准。



3.1.



系统功能测试



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


< p>
采用黑盒测试方法,


根据需求规格说明书和用户手册,

将功能点转换为功能


测试需求,根据测试需求编写测试用例,保证所有功能点必须被 测试用例覆盖。



测试用例的编写采用基于场景的测试用例编写 原则,


便于以使用者的角度进


行测试。


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


测试数据的选取可采用

< br>GUI


测试,等价类划分、边界值分析、错误推测、比较测试等测试方法中的一种


或者几种数据的组合,一般以等价类划分和边界值法为主。




3.1.1.




系统功能项测试


< br>对


《软件需求规格说明书》


中的所有功能项进行测试


(列表)




3.1.2.




系统业务流程测试




《软件需求规格说明书》


中的典型业务流程进行测试


( 列表)






3.1.3.



系统功能测试标准





可测试的功能点

< br>100


%作为测试需求(如未作为测试需求,必须在测试计划

中标注原因并通知用户方负责人);

































技术资料分享
























































WORD


格式


.


可编辑



































测试需 求


100


%被测试用例覆盖;





测试用例


100


%被实施(如未实施,在测试报告中标注未测试的原因并通知

用户方负责人);





含有一类缺陷的系统不建议上线发布


(缺陷严重等级见附录,需确认)< /p>






含有二类缺陷的系统不建议上线发布


(缺陷严重等级见附录,需确认)






含有三类缺陷


10


个以上不建议上线发布< /p>


(缺陷严重等级见附录,需确认)






权限矩阵测试覆盖率


100


%。




3.2.



易用性测试



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


我方的原则是在测试过程中如果


发现有完全不 符合


IT


行业习惯的操作、完成一次业务过多操作步骤和弹出窗 口、


界面颜色严重影响阅读、


提示信息过于复杂或者简单、


业务逻辑完全不符合思维


逻辑的情况下,


我 方测试人员会提出易用性类型的缺陷,


此类缺陷由用户方最终


确 认。



易用性测试的内容包括


:



软件的用户界面是否友好,是否出现中英文混杂的界面;




软件中的提示信息是否清楚、易理解,是否存在原始的英文提 示;




软件中各个模块的界面风格是否一致;




软件中的查询结果的输出方式是否比较直观、合理。




3.3.



容错测试



本系统的容错测试不是本次 测试的重点。


我方的原则是在测试的过程中检查


对系统对非常规 操作或业务流程的容错性处理,


是否影响系统的正常运行,


是否


给与用户明确的提示信息等,此类缺陷由用户方最终确认。



容错测试的检查内容包括


:
































技术资料分享
























































WORD


格式


.


可编辑


































软件对用户常见的误操作是否能进行提示;




软件对用户的的操作错误和软件错误,是否有准确、清晰的提 示;




软件对重要数据的删除是否有警告和确认提示;




软件是否能判断数据的有效性,屏蔽用户的错误输入,识别非 法值,并


有相应的错误提示。




3.4.



安全性测试



如用户方有明确的安全测 试需求,可根据用户实际情况,进行安全性测试。



安全性测试的检查内容包括


:



软件中的密钥是否以密文方式存储;




软件是否有留痕功能


,


即是否保存有用户的操作日志;




软件中各种用户的权限分配是否合理;




3.5.



性能测试



对软件需求规格说明书中明 确的软件性能进行测试。


测试的准则是要满足规


格说明书中的各 项性能指标


(需明确说明)





3.6.



适应性测试



参照用户的软、


硬件使用环境和需求规格说明书中的规定,


列出开发的软件


需要满足的软、硬件环境(包括服务器环境、客户端环境)。对部署环境进行测



(需明确说明)





3.7.



文档测试



用户文档包括


:


安装手册、操作手册 和维护手册(需明确说明)


。对用户文
































技术资料分享



































-


-


-


-


-


-


-


-