XXX系统测试策略与计划

1.1编写目的

  XXXXXXXXXXXXXXXXXXXXXXXX

本文档的读者范围包括：XXX系统项目内的部门领导、项目经理,测试工程师、软件工程师等。

1.2项目概况

XXX系统是一个XXXXXXXXXXXX。

1.3参考资料

2.1硬件资源

3.1 整体策略

本项目采用瀑布开发模式，第一个转测试版本包括了所有需求和要实现的功能，后续版本仅进行回归测试，不做新功能测试。

第一个版本为XXX，实现需求规格上面的功能包括：XXXXXXXXXXXXXXX。第一版发布时进行全面测试，测试重点关注功能是否满足需求规格上的要求。全面测试的内容包括功能测试、性能测试、压力测试、兼容性测试。所有测试内容按照已经编写的全面测试用例执行，阻塞的用例需备注说明阻塞原因。

第二个版本为XXX，本次为回归测试，测试重点为回归第一版软件中发现BUG，另外还要挑选基本业务流程中的高优先级用例进行测试。

第三个版本为XXX，本次为回归测试，测试重点为回归第二版软件中发现BUG，另外还要挑选基本业务流程中的高优先级用例进行测试。

所以本项目的测试策略为1轮全面+2轮回归，测完后需根据软件实际质量表现确定是否继续进行后续的其他测试。

3.2测试类型

3.2.1功能测试

3.3.1编写规范

1、一个测试用例只测试一个点，避免一个用例中测试内容过多。

2、测试用例标题要能简明概要的说明用例的测试要点，有利于读者对用例的理解。标题不能用重复。如果测试的内容相似，标题无法区分，则可以在标题后面加数字进行区分。

3、测试用例的数据要明确。对于测试中的输入项，要有明确的输入内容来做测试，提高可操作性。不能只用文字描述，导致测试内容模糊不清。

4、测试用例需要保障唯一性，即功能用例之间不存在重叠，流程用例不存在包含关系。没有重复、冗余的测试用例，满足相应的行业标准。

5、描述要清晰明确，简明扼要，没有含糊的概念和易产生歧义的文字。应尽量避免不确定的用词，如：如果、若、否则、大概、可能等。

6、测试用例中需要有充分的异常测试数据，考虑大数据量测试时的数据准备。例如对于数据量的边界值，需要使用工具产生边界数据量来验证。

7、正常的输入测试和异常的输入测试需分开进行

8、测试用例必须包含所有的功能需求点，对于功能模块之间有耦合的，对其他模块的影响也要体现在预期结果中

3.3.2用例设计方法

常用的用例设计方法包括等价类、边界值、流程分析法、因果图、错误猜测法等。

等价类：等价类是指某个输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的错误都是等效的，并合理地假定：测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果。

边界值：边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。

错误猜测法：基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法。列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例。

流程分析法：基于某一功能点的所有可能的流程进行分析，并对每一个分支流程都设计测试用例。

应果图法：因果图法是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况。等价类划分法和边界值分析方法都是着重考虑输入条件，但没有考虑输入条件的各种组合、输入条件之间的相互制约关系。这样虽然各种输入条件可能出错的情况已经测试到了，但多个输入条件组合起来可能出错的情况却被忽视了。

3.3.3用例命名规范

以实际测试功能模块和测试内容要点进行命名

3.3.4用例编号规范

用例编号格式为：项目名_测试类型_功能模块_编号

测试类型分为：功能测试(F)、性能测试(P)、安全性测试(S)、压力测试(O)、兼容性测试(C)

编号从001开始

功能模块取被测功能模块的英文标识，例如User(用户管理)、Device(设备管理)、Portal（PORTAL管理）、Statistics（数据分析）、System(系统维护)等。

用例编号实例一：XXX_F_User_001

用例编号实例二：XXX_C_Browser_001

3.3.5测试用例模板

3.4.1 BUG提交

项目测试中发现的BUG需与相应的开发进行沟通，确认之后立即提交到BUG系统上。如果对BUG有争议，则提交评审后进行裁决。

3.4.2 BUG提交规范

1、标题需能概括本BUG的大意

2、BUG描述力求清晰准确，解释到位。必须完整描述BUG的复现步骤，如果有前提条件，需明确说明。需写明预期结果和实际结果，能够让其他测试人员和开发人员理解这个BUG是什么意思

3、尽量能附带日志或BUG截图

4、相同的BUG不能重复提交

5、再微小的BUG也要提交，提交BUG宜早不宜晚，不要等到后面的版本再提交。

3.4.3 BUG严重级别划分

参考公司文档《XXX公司BUG严重级别划分及项目通过标准》

3.5风险分析

风险发生可能性说明：高：>60%，中：30%—60%，低：<30%。

1、检查软件转测试交付件，必须包括releasenote，自测试报告。releasenote中需明确当前版本开发情况，遗留问题和测试建议。自测试报告中测试用例通过率需达到100%。以上条件任一不满足，做版本退回处理。

2、正常构建版本测试过程中发现bug的严重影响后续测试，或者发现的致命性bug，版本退回。输出测试报告。

3.7任务分配

4.1里程碑

1、回归测试中，研发需附带自测试报告，自测试用例需通过率达到100%，才能转测试。

2、研发需要将上一轮提交的BUG尽量解决掉才转测试，转测试时需要对遗留BUG进行统计，并计算分值，如果遗留BUG累积分值达到54分，则不接收转测试。BUG的分值计算标准如下：

6.1挂起条件

当测试发生4.2中“版本退回”的条件时，应挂起测试，等待条件满足时再重新开始测试；

当由于硬件故障导致测试中断时，需等硬件方面维修调试完毕后再恢复测试；

除此之外，其它由于开发方面、市场方面、或管理决策等导致的项目暂停、停止等，应适时地挂起测试活动，只有决策项目继续开展时，才再次启动测试活动。

6.2恢复条件

参考6.1中恢复测试说明