丿CraZy小叶
软件测试报告（范文）
展开全部 测试数据测试项总数 0 PASS 0 PASS率 #DIV/0! FAIL 0 FAIL率 #DIV/0！ 严重度——高 0 其中：高-- #DIV/0！ 严重度——中 0 中-- #DIV/0！ 严重度——低 0 低-- #DIV/0！ 测试项编号 测试项 通过与否 问题描述 问题严重度注： 问题严重度的界定：高——导致系统死机或后续部分测试项功能不能实现；中——影响该部分的测试功能的完整性且急需解决；低——仅属于系统中的小bug，或根据测试过程发现的需要调整的部分，但并非急需解决。
软件测试需要哪些文档？
1、测试方案（主要设计怎么测试什么内容和采用什么样的方法，经过分析，在这里可以得到相应的测试用列表）2、测试执行策略（可以主要包括哪些可以先测试，哪些可以放在一起测试之类的），3、测试用例（主要根据测试用例列表，写出每一个用例的操作步骤和紧急程度，和预置结果），4、BUG描述报告（主要可以包括，测试环境的介绍，预置条件，测试人员，问题重现的操作步骤和当时测试的现场信息），5、整个项目的测试报告（从设计和执行的角度上来对此项目测试情况的介绍，从分析中总结此次设计和执行做的好的地方和需要努力的地方和对此项目的一个质量评价）。
软件测试方法的文档测试
文档测试的英文是documentation testing，测试关注于文档的正确性。
文档测试有三大类分别是开发文件、用户文件、管理文件。
1. 开发文件：可行性研究报告、软件需求说明书、数据要求说明书、概要设计说明书、详细设计说明书、数据库设计说明书、模块开发卷宗。
2.用户文件：用户手册、操作手册。
3.管理文件：项目开发计划、测试计划、测试分析报告、开发进度月报、项目开发总结报告。
软件测试中的文档测试主要是对相关的设计报告和用户使用说明进行测试，对于设计报告主要是测试程序与设计报告中的设计思想是否一致；对于用户使用说明进行测试时，主要是测试用户使用说明书中对程序操作方法的描述是否正确，重点是用户使用说明中提到的操作例子要进行测试，保证采用的例子能够在程序中正确完成操作。
一般来说，文档是软件的重要组成部分，因此文档测试也是软件测试的主要内容。
在软件的整个生命周期中会出现很多文档，通常可以把文档粗略地分为三类：开发文档，管理文档和用户文档。
由于文档与代码不同，不能直接运行，对于文档的测试通常只能以文档审查的方式进行。
对于管理文档和审查通常归属于管理范畴，而不是软件测试范畴，因为对于管理文档审查的目的不是为了发现和消除用户所看到的软件中的缺陷，而是为了更好地管理软件开发的过程。
对于开发文档，由于这些文档本身体现了所在开发阶段的软件实际形态，对于这些文档的测试实际上是早期软件测试的主要活动。
用户文档是那些随程序一起交付给用户的文档，它们实际上是交付给用户的软件的重要组成部分。
对于这些文档的测试是对最终软件产品测试的一部分。
软件测试流程,在给我一个测试项目的例子
展开全部 一般的软件测试流程是这样：1.拿到需求说明书，开始对需求进行测试，找出需求中的问题或者说不可测的地方2.需求测试通过后，根据需求说明书制定测试计划，包括测试策略、测试方法、测试周期等3.然后根据软件功能说明书编写测试用例，一般的公司都是根据需求说明书进行编写4.搭建测试环境，包括软件环境和硬件环境5.根据测试用例进行测试，提交缺陷6.回归测试7.测试完成后，进行测试总结，编写测试报告至于测试文档，我这倒是有cmmi标准的一些文档，如果你想要的话，可以留下邮箱，我发过去。
好了，都发过去了。
...
软件测试文档包含什么？
不知道你的文档具体是什么，但是用户文档测试的主要内容如下：1. 读者群：文档面向的读者要明确，对于初级用户、中级用户、高级用户应该有不同的定位；2. 术语：文档中的术语要适用于定位的读者群，用法一致，标准规范与业界相吻合；3. 正确性：测试中需检查所有信息是否真实正确，查找由于过期产品说明书和销售人员夸大事实而导致的错误。
检查所有的目录、索引和章节引用是否已更新，尝试链接是否准确，产品支持电话、地址和邮政编码是否正确。
4. 完整性：对照软件界面检查是否有重要的分支没有描述到，甚至是否有整个大模块没有描述到。
5. 一致性：按照文档描述的操作执行后，检查软件返回的结果是否与文档描述相同。
6. 易用性：对关键步骤以粗体或背景色给用户以提示，合理的页面布局、适量的图表都可以给用户更高的易用性。
需要注意的是文档要有助于用户排除错误，不但描述正确操作，也要描述错误处理办法。
文档对于用户看到的错误信息应当有更详细的文档解释。
7. 图表与界面截图：检查所有图表与界面截图是否与发行版本相同。
8. 样例与示例：像用户一样载入和使用样例。
如果是一段程序，就输入数据并执行它。
以每一个模版制作文件，确认它们的正确性。
9. 语言：不出现错别字，不要出现有二义性的说法。
特别要注意的是屏幕截图或绘制图形中的文字。
10.印刷与包装：检查印刷质量；手册厚度与开本是否合适；包装盒的大小是否合适；有没有零碎易丢失的小部件等。
软件测试过程中主要测试文档有哪些
软件测试的流程，以及各阶段的相关文档无论是采用瀑布式还是其他的产品生命周期模型，软件测试分为如下几个阶段：1、测试需求分析阶段。
测试需求分析阶段主要工作是获得测试项目的测试需求（测试规格）。
输出产物：《可测试性需求说明书》和《测试规格》2、测试计划阶段。
以测试需求为基础，分析产品的总体测试策略。
输出产物：《产品总体测试策略》3、测试方案设计阶段。
本阶段主要是以测试规格为基础获得特性测试方案，对于有自动化测试的项目，进行自动化测试的分析，获得测试策略。
输出产物：《产品或者版本总体测试方案》4、测试用例实现阶段。
本阶段主要是完成各个特性的测试用例的编写和自动化脚本的编写。
输出产物：《产品自动化测试用例》和《手工执行测试用例》5、测试执行阶段。
本阶段是根据测试策略开展测试执行和回归测试。
输出产品：《产品或版本测试报告》和《缺陷分析报告》6、评估与关闭阶段。
只对前面的各个阶段的执行情况，完成对测试项目的关闭，同时提供完整的度量数据和项目总结报告。
输出产物：《遗留问题风险分析报告》、《度量分析报告》和《测试关闭报告》
软件开发或测试中所说的读文件写文件是什么意思,可以用个例子说明...
这里的读文件或者写文件，一般情况是指将一些设定的，可更改的配置写入到配置文件中。
这种配置文件一般是ini或xml格式的，你可以使用记事本打开并查看。
比如常用软件360，在他的软件目录下，有一个updatecfg.ini的配置文件。
你打开后可以看见很多的标注性的东西。
比如版本号ver，地址path等。
当软件启动并联网时，软件会自动将本地的版本号与360服务器上的进行比对，假如不一致，则提示你升级。
从软件测试开始到测试结束,规范的说一般要生成哪些文档。
一般会包括 测试计划 - 测试用例 - 缺陷报告 - 测试报告 当然如果去细分的话，可能还会有其他的一些文档需要产生。
你们公司以前没做过软件测试，所以也没必要在去分的那么详细了。
一般公司在测试中所产生的文档也就上面所说的那几个了。
这些文档都是分别写在不同的文档中的。
当然，有的公司测试人员还可能会去编写用户手册。
简述软件系统中用户文档的测试要点？
展开全部 参考答案：(1)读者群。
文档面向的读者定位要明确。
对于初级用户、中级用户以及高级用户应该有不同的定位(2)术语。
文档中用到的术语要适用与定位的读者群，用法一致，标准定义与业界规范相吻合。
(3)正确性。
测试中需检查所有信息是否真实正确，查找由于过期产品说明书和销售人员夸大事实而导致的错误。
检查所有的目录、索引和章节引用是否已更新，尝试链接是否准确，产品支持电话、地址和邮政编码是否正确。
(4)完整性。
对照软件界面检查是否有重要的分支没有描述到，甚至是否有整个大模块没有描述到。
(5)一致性。
按照文档描述的操作执行后，检查软件返回的结果是否与文档描述的相同。
(6)易用性。
对关键步骤以粗体或背景色给用户以提示，合理的页面布局、适量的图表都可以给用户更高的易用性。
需要注意的是文档要有助于用户排除错误。
不但描述正确操作，也要描述错误处理办法。
文档对于用户看到的错误信息应当有更详细的文档解释。
(7)图表与界面截图。
检查所有图表与界面截图是否与发行版本相同。
(8)样例与示例。
像用户一样载入和使用样例。
如果是一段程序，就输入数据并执行它。
以每一个模块制作文件，确认它们的正确性。
(9)语言。
不出现错别字，不要出现有二义性的说法。
特别要注意的是屏幕截图或绘制图形中的文字。
(10)印刷与包装。
检查印刷质量；手册厚度与开本是否合适；包装盒的大小是否合适；有没有零碎易丢失的小部件等等。
