测试技术方案模板Word文档下载推荐.docx

1、设计针对XX市XX中心业务系统的系统测试功能测试方案。通过上述方案用以验证：产品功能是否满足需求规定并能够正常运行功能测试；用户界面是否与需求保持一致，保证用户界面的友好性、易操作性用户界面测试；产品性能是否满足需求规定并能够正常运行性能测试；1.4目标读者及阅读建议目标读者阅读建议工程经理及评审人员全文档仔细阅读测试负责人及测试工程师开发工程师仔细阅读“章节2-“章节4，其他局部了解性阅读1.5参考文档文档参考内容作者或来源使用备注GBT-8567-2006计算机软件文档编制标准：软件测试方案（STP）文档格式确定文档格式及涉及内容需求规格说明书工程组确定测试需求及策略大/中日程方案测试方案

2、确定测试方案及人员安排2 软件测试环境2.1测试环境硬件用途客户端硬件配置信息数量软件分类软件名称版本操作系统浏览器数据库客户端效劳器操作系统 WEB中间件数据库2.2参与组织参与方人员提供资源参与工作参与阶段参与时间2.3人员角色下表列出了在工程内部测试工作过程中的人员配备：角色职责工程经理提供技术指导并获取适当资源负责整个工程中的协调工作测试负责人编写测试方案、方案工程测试的日常管理工作监控测试工作，躲避风险编写系统测试报告等测试工程师编制和维护测试用例执行测试并记录结果缺陷跟踪对程序缺陷进行修改程序新版本发布必要时参加进行功能测试2.4测试工具工具类型工具名称用例管理工具缺陷管理工具工程

3、管理3 方案3.1总体方案该系统测试的策略有功能测试、用户界面测试和性能测试，功能测试要覆盖系统中的每个功能。在功能测试时既要输入正确的数据，测试功能是否满足，也要对每个功能中的每个数据输入域成心输入错误的数据，测试系统的健壮性。用户界面测试核实各个窗口风格包括颜色、字体、提示信息、图标、Title等都与需求保持一致，或符合可接受标准，保证用户界面的友好性、易操作性，而且符合用户操作习惯。性能测试往往针对软件的一局部功能，进行专项测试。执行完一组工作后，及时检查是否已到达预定目标，是否已执行完该过程所有的步骤等，如实际情况与方案出入较大，应及时调整方案。考虑到各种因素和条件的限制，采用黑盒测试

4、方案，即根据软件所需要的输入数据的格式以及应该完成的功能，设计一些合法的测试用例和不合法的测试用例，特别是根据边界条件设计一些边界测试用例，以检查系统是否能正确地完成预期功能，得到希望的输出；或者是对不合法的输入和操作能够正确地识别和防御。3.1.1测试级执行的测试级别为系统级。3.1.2测试准备测试方案编写完成并邮件告知工程组成员；测试组根据需求规格说明书完成测试内容确认和重点交易列表，需工程经理或开发人员确认；工程经理安排相关人员完成内部测试环境的配置；测试开始前将与开发人员配合将“测试相关信息.xls文档整理完成，包括测试环境配置、Bugfree用户信息，柜员信息等；3.1.3测试类别3

5、.1.3.1功能测试功能测试侧重于可以被直接追踪利用例或业务功能和业务规那么的所有测试需求。这些测试的目标在于核实能否正确的接受、处理和检索数据以及业务规那么是否正确实施。这种类型的测试基于黑盒方法，即通过图形用户界面GUI与应用程序交互并分析输出结果来验证应用程序及其内部进程。以以下出测试方法概要：测试范围：验证数据精确度、数据类型、业务功能等相关方面的正确性测试目标：核实所有功能均已正常实现，且与需求一致。方法：利用有效的和无效的数据来执行各个用例或功能，以核实以下内容：在使用有效的数据时得到预期结果；在使用无效的数据时显示相应的错误信息或警告；各业务规那么都得到了正确的应用；依据：测试用

6、例完成标准：所方案的测试已全部执行所发现的缺陷已全部解决无1,2级遗留缺陷需考虑的特殊事项3.1.3.2用户界面UI测试用户界面UI测试用于核实用户与软件之间的交互。UI测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。另外，UI测试还可确保UI中的对象按照预期的方式运行，并符合公司或行业的标准。1、导航、链接、Cookie、页面结构包括菜单、背景、颜色、字体、按钮名称、Title、提示信息的一致性等2、友好性、可操作性、易用性核实各个窗口风格包括颜色、字体、提示信息、图标、Title等都与需求保持一致，或符合可接受标准，能够保证用户界面的友好性、易操作性，而且符合

7、用户操作习惯。WEB非功能性通用测试方法，手工测试UI符合可接受标准，能够保证用户界面的友好性、易操作性，而且符合用户操作习惯重点测试网上业务平台、政务网站等对外门户的用户界面。3.1.3.3性能测试性能测试对响应时间、事务处理速率和其他与时间相关的需求进行评测和评估。性能测试的目标是核实性能需求是否都已满足。实施和执行性能测试的目的是将测试对象的性能行为当作条件例如工作量或硬件配置的一种函数来进行测试和微调。多用户长时间在线操作时性能方面的测试核实系统在大流量的数据与多用户操作时软件性能的稳定性， 不造成系统崩溃或相关的异常现象。使用loadrunner工具进行测试系统满足用户需求中所要求的

8、性能要求3.2方案执行的测试3.2.1测试范围序号分类核心用例来源用例编写人员测试策略功能测试、用户界面测试、性能测试234567891011121314151617181920212223242526272829303132注：具体各核心内容下的交易见“交易测试情况一览表，此处不逐一列出。3.2.2测试重点测试重点主要从以下几个方面考虑，针对测试重点，在用例的编写与评审、人员安排、测试轮次、Bug解决要求等方面都应高于其他局部。需求中，优先级高的重点功能或用户的常用功能；开发过程中，重点关注的模块、功能及特性此项通过交易的代码修改量等内容确定，由工程经理提供；相关领导的关注点和意见；开发人员

9、的能力和水平差异；以往版本或其他工程中的常见问题；此项内容由工程经理配合进行确认，具体交易列表及重点测试交易，见“交易测试情况一览表，此处不逐一列出。3.2.3测试入口准那么在提交测试组进行系统测试前，开发工程师需要经过自测试以及开发组组内互测；测试组接收测试，且通过冒烟测试后，方可进行系统测试。3.2.4测试通过标准系统无业务逻辑错误和二级缺陷，经确定的所有缺陷都已得到商定的解决结果；设计的测试用例全部执行完成，由于其他因素导致未能执行的用例有相应记录；2.1节中规定的所有功能点，测试覆盖率=100%，有效Bug的关闭率=90%；满足联合测试和第三方测评要求。3.3测试用例1测试用例分类测试

10、用例与测试类型对应：功能测试用例、用户界面测试用例及性能测试用例重点用例通过用例中的用例级别进行标记：A-关键业务正常流测试B-功能点详细测试C-交互测试：主要测试界面、易用性等内容D-异常测试2测试用例评审组内评审：测试组内部采用交叉评审方式，对已做成测试用例进行评审；组外评审：开发组的相关人员由工程经理或部门经理指定，对测试一览表中重点交易的用例进行评审；4 测试实施4.1轮次执行轮次内容第一轮1、第二轮第三轮1.其他考前须知：1测试工程师根据测试用例进行测试，并将测试中发现的Bug，记录到Bugfree中；2开发工程师对Bug进行修改，并说明Bug产生的原因及产生阶段；3如果对需要修改的

11、Bug意见不统一，那么由工程经理确认修改意见；4第二轮系统测试开始，测试工程师首先对第一轮测试中遗留的问题进行回归验证，即验证上一轮发现的Bug是否已经全部得到解决。回归测试完成后，测试工程师再根据测试用例，开展新的系统测试工作；5第三轮系测试，结合核心系统进行测试，同时加强对业务系统中重点交易的测试。4.2测试方案工程里程碑任务开始时间结束时间输出物执行人员制定测试方案编写测试方案设计测试测试用例编写测试用例评审测试用例评审记录表执行测试内部测试第一轮缺陷记录、轮次测试报告内部测试第二轮内部测试第三轮评估测试测试总结内部测试报告轮次测试的具体内容会根据各子系统开发进度做适当调整。4.3缺陷管

12、理参见【03 Bugfree填写标准V1.0.4.doc】。5测试评价系统测试完毕，提供以下度量指标结果用以评估工程质量并输出测试报告：度量指标名称定义/计算公式指标目的数据主要来源测试功能点总数个测试功能点总数各级测试功能点数之和；统计测试规模“附件1：交易测试情况一览表.xls功能点测试生产率个/人月功能点测试生产率 = 测试功能点总数 /测试组实际总工作量；衡量测试组的生产率系统功能测试轮次轮指测试组实际进行的系统功能测试轮数；预估类似工程的平均测试轮数Bugfree测试覆盖率100%功能点测试覆盖率 =测试功能点总数 / 功能点总数；衡量测试的覆盖程度功能点测试通过率100%完全通过功

13、能点数/测试功能点总数由此指标，可衡量代码开发的质量。Bug关闭率100%Bug总关闭率 = 已关闭Bug总数 / 有效Bug总数 * 100%1、衡量开发人员对Bug的解决程度；2、判断产品交付时的遗留Bug数BugFree测试密度个/功能测试密度=实际测试用例数/功能点总数衡量测试用例颗粒度是否适当Bug密度1个/功能Bug密度1=实际Bug数/功能点总数衡量bug产出是否在合理范围内Bug密度2个/功能Bug密度2=实际Bug数/代码变动数衡量代码变动产生的bug数是合理6风险预估和应对下表列出了在工程测试工作中存在的各种风险的假定，需要考虑工程测试过程中可能发生的具体事务，分别分析并加

14、以应对，然后表到达测试方案中。风险类型风险责任方风险内容处理优先级应对措施时间方案人员风险资源协调插入事务任务超预期各个风险类型解释如下：时间方案：关键MileStone无法匹配的延期风险；人员风险：测试人员和需配合方的人员的变动导致的工作任务无法按方案完成或者完成质量无法保证的风险，包括新人风险、人员变化、投入缺乏、投入质量不高等；资源协调：包括所需资源不能如期到位，或者资源质量低于预期等风险。比方测试工具开发的风险、各个阶段交付物的质量风险等；插入事务：包括临时插入高优先级的事务，打乱原有方案等风险；任务超预期：实际执行时的工作复杂程度、结果的质量同预期不符所带来的风险。属于不可预期的风险，只能待出现时及时合理地调整。 风险分为可预期的和不可预期的，对于可预期的风险，可以要求资源，制定提前的应对措施。但是对于不可预期的风险，只能待出现时，充分考虑各方因素，及时调整。所以，对于可预期的风险，需要的能力是充分预估，对于不可预期的风险，需要的是及时发觉并调整应对。7 测试输出物1内部测试方案2测试用例3测试报告轮次测试报告内部测试报告测试总结邮件发送附件1：交易测试情况一览表附件2：交易品质分析数据4缺陷列表