第三方软件测试报告（暂定）
1. 引言
1.1. 编写目的
本文档作为该系统测试的测试标准，内容关系到本次系统测试可能涉及到的测试内容和测试技术解决方案。
1.2. 系统概述
略
2. 测试描述
2.1. 测试范围与内容
我方（北京圆规创新公司）对XX公司“XX”项目进行测试，保证使用方的功能正确，保证系统核心模块的稳定和安全，为项目的验收提供参考。以此，本计划列出了在此次功能测试过程中所要进行的内容和实施的方案及测试资源的安排，作为测试活动的依据和参考。
本次测试的对象为XX公司“XX”项目，测试范围为：略。
本次测试的主要内容有功能测试（含容错测试）、易用性测试。
2.2. 测试依据
本次测试所依据的文档包含开发方提供的《需求规格说明书》、《操作手册》、《用户手册》，《维护手册》，《设计文档》等相关开发文档。
并依据IT行业项目的通用标准，包括功能测试标准、缺陷标准、易用性标准。 对于项目的易用性标准，原则上由测试方提出易用性问题修改的建议，由开发方对测试方提交的问题进行确认。
3. 测试解决方案
我公司针对用户方提出的测试要求，根据以往项目的实际经验，撰写测试技术解决方案。该解决方案包含了本次系统测试可能涉及到的测试类型，并分别介绍不同测试类型的内容和相关标准。
3.1. 系统功能测试
实施系统功能测试，完成对被测系统的功能确认。
采用黑盒测试方法，根据需求规格说明书和用户手册，将功能点转换为功能测试需求，根据测试需求编写测试用例，保证所有功能点必须被测试用例覆盖。
测试用例的编写采用基于场景的测试用例编写原则，便于以使用者的角度进行测试。用例设计上兼顾正常业务逻辑和异常业务逻辑。测试数据的选取可采用GUI测试，等价类划分、边界值分析、错误推测、比较测试等测试方法中的一种或者几种数据的组合，一般以等价类划分和边界值法为主。
3.1.1.
系统功能项测试 对《软件需求规格说明书》中的所有功能项进行测试（列表）；
3.1.2.
系统业务流程测试
对《软件需求规格说明书》中的典型业务流程进行测试（列表）；
3.1.3. 系统功能测试标准
可测试的功能点100％作为测试需求（如未作为测试需求，必须在测试计划
中标注原因并通知用户方负责人）；
测试需求100％被测试用例覆盖；
测试用例100％被实施（如未实施，在测试报告中标注未测试的原因并通知
用户方负责人）；
含有一类缺陷的系统不建议上线发布（缺陷严重等级见附录，需确认）； 含有二类缺陷的系统不建议上线发布（缺陷严重等级见附录，需确认）； 含有三类缺陷10个以上不建议上线发布（缺陷严重等级见附录，需确认）； 权限矩阵测试覆盖率100％。
3.2. 易用性测试
本系统的易用性测试不是本次测试的重点。我方的原则是在测试过程中如果发现有完全不符合IT行业习惯的操作、完成一次业务过多操作步骤和弹出窗口、界面颜色严重影响阅读、提示信息过于复杂或者简单、业务逻辑完全不符合思维逻辑的情况下，我方测试人员会提出易用性类型的缺陷，此类缺陷由用户方最终确认。
易用性测试的内容包括
:
软件的用户界面是否友好，是否出现中英文混杂的界面；
软件中的提示信息是否清楚、易理解，是否存在原始的英文提示；
软件中各个模块的界面风格是否一致；
软件中的查询结果的输出方式是否比较直观、合理。
3.3. 容错测试
本系统的容错测试不是本次测试的重点。我方的原则是在测试的过程中检查对系统对非常规操作或业务流程的容错性处理，是否影响系统的正常运行，是否给与用户明确的提示信息等，此类缺陷由用户方最终确认。
容错测试的检查内容包括:
软件对用户常见的误操作是否能进行提示；
软件对用户的的操作错误和软件错误，是否有准确、清晰的提示；
软件对重要数据的删除是否有警告和确认提示；
软件是否能判断数据的有效性，屏蔽用户的错误输入，识别非法值，并有相应的错误提示。
3.4. 安全性测试
如用户方有明确的安全测试需求，可根据用户实际情况，进行安全性测试。 安全性测试的检查内容包括
:
软件中的密钥是否以密文方式存储；
软件是否有留痕功能, 即是否保存有用户的操作日志；
软件中各种用户的权限分配是否合理；
3.5. 性能测试
对软件需求规格说明书中明确的软件性能进行测试。测试的准则是要满足规格说明书中的各项性能指标（需明确说明）。
3.6. 适应性测试
参照用户的软、硬件使用环境和需求规格说明书中的规定，列出开发的软件需要满足的软、硬件环境（包括服务器环境、客户端环境）。对部署环境进行测试（需明确说明）。
3.7. 文档测试
用户文档包括: 安装手册、操作手册和维护手册（需明确说明）。对用户文
档测试的内容包括
:
操作、维护文档是否齐全、是否包含产品使用所需的信息和所有的功能模块；
用户文档描述的信息是否正确, 是否没有歧义和错误的表达；
用户文档是否容易理解, 是否通过使用适当的术语、图形表示、详细的解释来表达；
用户文档对主要功能和关键操作是否提供应用实例；
用户文档是否有详细的目录表和索引表；
文档描述与程序当前版本符合
3.8. 用户有特别要求的测试
用户对于系统是否有特别的要求（需明确说明）
4. 预期提交文档
本次系统测试可能提交的文档包括《测试需求》、《测试计划》、《测试用例》、《测试报告》等。其中测试计划、报告等根据测试回归次数而产生多份。
4.1. 测试需求文档
首先完成测试需求的整理，阅读项目功能性说明的相关文档，挑选出可以测试的功能点，完成测试需求的整理。
4.2. 测试用例文档
测试需求作为今后测试活动的指导和目标，且为测试工作量的估算提供可计算的依据。我方制定测试需求后将测试需求提交相关人员进行审查。通过之后，
将根据测试需求完成功能性测试用例的编写。
4.3. 测试日志文档
测试用例设计完成之后，我方将测试用例提交给相关各方评审。评审通过后测试人员按照测试用例实施测试。测试人员在实施测试的时候，将每日填写测试日志。
4.4. 测试报告
完成一次完整的功能测试之后，我方将汇总缺陷，完成测试报告。
5. 测试工作流程
5.1. 测试启动
开发方提供项目相关文档，包括《需求规格说明书》、《设计文档》、《用户手册》等相关文档；
开发方搭建测试环境，提供必要的软、硬件；
开发方进行系统讲解，完成对测试方的培训；
测试方阅读相关文档并学习使用被测系统；
测试方对依据的文档中的不足提出意见，由开发方补充完善文档。
5.2. 测试准备
测试方制定必要的标准，提交开发方和用户方审阅；
测试方整理测试需求，提交开发方和用户方审阅；
测试方书写测试计划，提交开发方和用户方审阅；
测试方编写测试用例，开发测试脚本，可提交开发方和用户方审阅；
5.3. 测试实施
测试方按照测试计划，按照设计的测试用例实施测试，记录测试过程中的问题。测试方每日完成测试日志，并将测试日志提交开发方和用户方。
5.4. 测试总结
测试方对每次回归测试提交缺陷列表，编写测试报告。
6. 三方职责分工
测试过程中需要开发方精悍有素的人员的大力支持与配合，并且为测试方提供现场技术支持。开发方有义务配合测试方完成本次的系统测试，并提供必要的支持工作。
由于测试阶段的根本目标是尽可能多发现并排除软件中潜藏的错误，最终把一个高质量的软件系统交给用户使用，因此用户方在测试阶段的直接参与、指正和确认起着十分重要的作用。开发方需要有专人负责本次系统测试工作，组织测试现场和相关硬件设备，沟通和协调各方关系。
测试方严格按照软件工程理论进行测试，提供专业测试人员和必要的测试工具，并以用户方的根本利益为工作原则指导。
7. 附录
7.1. 软件错误的严重性等级
7.1.1. Critical：1级错误
这一级别的错误一般包括以下内容:
✓ 没有实现或错误地实现重要的功能；
✓ 业务流程存在重大隐患；
✓ 软件在操作过程中由于软件自身的原因自动退出系统或出现死机的情况；
✓ 软件在操作过程中由于软件自身的原因对系统或数据造成破坏； ✓ 在现有的软、硬建设环境下不能实现应有的功能；
✓ 特殊软件在操作过程中可能危及系统和人身安全等。
7.1.2. Major：2级错误
这一级别的错误一般包括以下内容:
✓ 没有实现基本功能，并且不存在替代办法；
✓ 没有实现重要功能中的部分功能，并且不存在替代办法；
✓ 业务流程衔接错误；
✓ 用户的权限分配不合理；
✓ 不可继续使用的异常错误；
✓ 系统不明原因资源占用增大,导致性能不断下降；
✓ 界面与需求不符；
7.1.3. Averagte：3级错误
这一级别的错误一般包括以下内容:
✓ 没有实现基本功能，但存在替代办法；
✓ 没有实现重要功能中的部分功能，但存在替代办法；
✓ 可继续使用的异常错误；
✓ 提示信息存在错误
7.1.4. Minor：4级错误
这一级别的错误通常为易用性方面的错误：
✓ 界面不友好、前后风格不一；
✓ 中英文混杂；
✓ 查询结果输出不直观；
✓ 错别字，提示信息轻微错误；
✓ 界面控件缺陷；
✓ 快捷键错误；
7.1.5. Enhancement：5级错误
通常为不影响正常使用下的用户方提出的改进性建议，或者文档方面的错误。
✓ 界面调整
✓ 功能改进调整建议
✓ 颜色,字体,图像等不合适
✓ 基本操作过于复杂
✓ 使用手册与功能不符（功能使用正常）
第三方软件测试报告（暂定）
1. 引言
1.1. 编写目的
本文档作为该系统测试的测试标准，内容关系到本次系统测试可能涉及到的测试内容和测试技术解决方案。
1.2. 系统概述
略
2. 测试描述
2.1. 测试范围与内容
我方（北京圆规创新公司）对XX公司“XX”项目进行测试，保证使用方的功能正确，保证系统核心模块的稳定和安全，为项目的验收提供参考。以此，本计划列出了在此次功能测试过程中所要进行的内容和实施的方案及测试资源的安排，作为测试活动的依据和参考。
本次测试的对象为XX公司“XX”项目，测试范围为：略。
本次测试的主要内容有功能测试（含容错测试）、易用性测试。
2.2. 测试依据
本次测试所依据的文档包含开发方提供的《需求规格说明书》、《操作手册》、《用户手册》，《维护手册》，《设计文档》等相关开发文档。
并依据IT行业项目的通用标准，包括功能测试标准、缺陷标准、易用性标准。 对于项目的易用性标准，原则上由测试方提出易用性问题修改的建议，由开发方对测试方提交的问题进行确认。
3. 测试解决方案
我公司针对用户方提出的测试要求，根据以往项目的实际经验，撰写测试技术解决方案。该解决方案包含了本次系统测试可能涉及到的测试类型，并分别介绍不同测试类型的内容和相关标准。
3.1. 系统功能测试
实施系统功能测试，完成对被测系统的功能确认。
采用黑盒测试方法，根据需求规格说明书和用户手册，将功能点转换为功能测试需求，根据测试需求编写测试用例，保证所有功能点必须被测试用例覆盖。
测试用例的编写采用基于场景的测试用例编写原则，便于以使用者的角度进行测试。用例设计上兼顾正常业务逻辑和异常业务逻辑。测试数据的选取可采用GUI测试，等价类划分、边界值分析、错误推测、比较测试等测试方法中的一种或者几种数据的组合，一般以等价类划分和边界值法为主。
3.1.1.
系统功能项测试 对《软件需求规格说明书》中的所有功能项进行测试（列表）；
3.1.2.
系统业务流程测试
对《软件需求规格说明书》中的典型业务流程进行测试（列表）；
3.1.3. 系统功能测试标准
可测试的功能点100％作为测试需求（如未作为测试需求，必须在测试计划
中标注原因并通知用户方负责人）；
测试需求100％被测试用例覆盖；
测试用例100％被实施（如未实施，在测试报告中标注未测试的原因并通知
用户方负责人）；
含有一类缺陷的系统不建议上线发布（缺陷严重等级见附录，需确认）； 含有二类缺陷的系统不建议上线发布（缺陷严重等级见附录，需确认）； 含有三类缺陷10个以上不建议上线发布（缺陷严重等级见附录，需确认）； 权限矩阵测试覆盖率100％。
3.2. 易用性测试
本系统的易用性测试不是本次测试的重点。我方的原则是在测试过程中如果发现有完全不符合IT行业习惯的操作、完成一次业务过多操作步骤和弹出窗口、界面颜色严重影响阅读、提示信息过于复杂或者简单、业务逻辑完全不符合思维逻辑的情况下，我方测试人员会提出易用性类型的缺陷，此类缺陷由用户方最终确认。
易用性测试的内容包括
:
软件的用户界面是否友好，是否出现中英文混杂的界面；
软件中的提示信息是否清楚、易理解，是否存在原始的英文提示；
软件中各个模块的界面风格是否一致；
软件中的查询结果的输出方式是否比较直观、合理。
3.3. 容错测试
本系统的容错测试不是本次测试的重点。我方的原则是在测试的过程中检查对系统对非常规操作或业务流程的容错性处理，是否影响系统的正常运行，是否给与用户明确的提示信息等，此类缺陷由用户方最终确认。
容错测试的检查内容包括:
软件对用户常见的误操作是否能进行提示；
软件对用户的的操作错误和软件错误，是否有准确、清晰的提示；
软件对重要数据的删除是否有警告和确认提示；
软件是否能判断数据的有效性，屏蔽用户的错误输入，识别非法值，并有相应的错误提示。
3.4. 安全性测试
如用户方有明确的安全测试需求，可根据用户实际情况，进行安全性测试。 安全性测试的检查内容包括
:
软件中的密钥是否以密文方式存储；
软件是否有留痕功能, 即是否保存有用户的操作日志；
软件中各种用户的权限分配是否合理；
3.5. 性能测试
对软件需求规格说明书中明确的软件性能进行测试。测试的准则是要满足规格说明书中的各项性能指标（需明确说明）。
3.6. 适应性测试
参照用户的软、硬件使用环境和需求规格说明书中的规定，列出开发的软件需要满足的软、硬件环境（包括服务器环境、客户端环境）。对部署环境进行测试（需明确说明）。
3.7. 文档测试
用户文档包括: 安装手册、操作手册和维护手册（需明确说明）。对用户文
档测试的内容包括
:
操作、维护文档是否齐全、是否包含产品使用所需的信息和所有的功能模块；
用户文档描述的信息是否正确, 是否没有歧义和错误的表达；
用户文档是否容易理解, 是否通过使用适当的术语、图形表示、详细的解释来表达；
用户文档对主要功能和关键操作是否提供应用实例；
用户文档是否有详细的目录表和索引表；
文档描述与程序当前版本符合
3.8. 用户有特别要求的测试
用户对于系统是否有特别的要求（需明确说明）
4. 预期提交文档
本次系统测试可能提交的文档包括《测试需求》、《测试计划》、《测试用例》、《测试报告》等。其中测试计划、报告等根据测试回归次数而产生多份。
4.1. 测试需求文档
首先完成测试需求的整理，阅读项目功能性说明的相关文档，挑选出可以测试的功能点，完成测试需求的整理。
4.2. 测试用例文档
测试需求作为今后测试活动的指导和目标，且为测试工作量的估算提供可计算的依据。我方制定测试需求后将测试需求提交相关人员进行审查。通过之后，
将根据测试需求完成功能性测试用例的编写。
4.3. 测试日志文档
测试用例设计完成之后，我方将测试用例提交给相关各方评审。评审通过后测试人员按照测试用例实施测试。测试人员在实施测试的时候，将每日填写测试日志。
4.4. 测试报告
完成一次完整的功能测试之后，我方将汇总缺陷，完成测试报告。
5. 测试工作流程
5.1. 测试启动
开发方提供项目相关文档，包括《需求规格说明书》、《设计文档》、《用户手册》等相关文档；
开发方搭建测试环境，提供必要的软、硬件；
开发方进行系统讲解，完成对测试方的培训；
测试方阅读相关文档并学习使用被测系统；
测试方对依据的文档中的不足提出意见，由开发方补充完善文档。
5.2. 测试准备
测试方制定必要的标准，提交开发方和用户方审阅；
测试方整理测试需求，提交开发方和用户方审阅；
测试方书写测试计划，提交开发方和用户方审阅；
测试方编写测试用例，开发测试脚本，可提交开发方和用户方审阅；
5.3. 测试实施
测试方按照测试计划，按照设计的测试用例实施测试，记录测试过程中的问题。测试方每日完成测试日志，并将测试日志提交开发方和用户方。
5.4. 测试总结
测试方对每次回归测试提交缺陷列表，编写测试报告。
6. 三方职责分工
测试过程中需要开发方精悍有素的人员的大力支持与配合，并且为测试方提供现场技术支持。开发方有义务配合测试方完成本次的系统测试，并提供必要的支持工作。
由于测试阶段的根本目标是尽可能多发现并排除软件中潜藏的错误，最终把一个高质量的软件系统交给用户使用，因此用户方在测试阶段的直接参与、指正和确认起着十分重要的作用。开发方需要有专人负责本次系统测试工作，组织测试现场和相关硬件设备，沟通和协调各方关系。
测试方严格按照软件工程理论进行测试，提供专业测试人员和必要的测试工具，并以用户方的根本利益为工作原则指导。
7. 附录
7.1. 软件错误的严重性等级
7.1.1. Critical：1级错误
这一级别的错误一般包括以下内容:
✓ 没有实现或错误地实现重要的功能；
✓ 业务流程存在重大隐患；
✓ 软件在操作过程中由于软件自身的原因自动退出系统或出现死机的情况；
✓ 软件在操作过程中由于软件自身的原因对系统或数据造成破坏； ✓ 在现有的软、硬建设环境下不能实现应有的功能；
✓ 特殊软件在操作过程中可能危及系统和人身安全等。
7.1.2. Major：2级错误
这一级别的错误一般包括以下内容:
✓ 没有实现基本功能，并且不存在替代办法；
✓ 没有实现重要功能中的部分功能，并且不存在替代办法；
✓ 业务流程衔接错误；
✓ 用户的权限分配不合理；
✓ 不可继续使用的异常错误；
✓ 系统不明原因资源占用增大,导致性能不断下降；
✓ 界面与需求不符；
7.1.3. Averagte：3级错误
这一级别的错误一般包括以下内容:
✓ 没有实现基本功能，但存在替代办法；
✓ 没有实现重要功能中的部分功能，但存在替代办法；
✓ 可继续使用的异常错误；
✓ 提示信息存在错误
7.1.4. Minor：4级错误
这一级别的错误通常为易用性方面的错误：
✓ 界面不友好、前后风格不一；
✓ 中英文混杂；
✓ 查询结果输出不直观；
✓ 错别字，提示信息轻微错误；
✓ 界面控件缺陷；
✓ 快捷键错误；
7.1.5. Enhancement：5级错误
通常为不影响正常使用下的用户方提出的改进性建议，或者文档方面的错误。
✓ 界面调整
✓ 功能改进调整建议
✓ 颜色,字体,图像等不合适
✓ 基本操作过于复杂
✓ 使用手册与功能不符（功能使用正常）