1.软件项目的测试文档如何写

目前没有经典的定义。比较通常的说法是：指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。

不同类别的软件，测试用例是不同的。不同于诸如系统、工具、控制、游戏软件，管理软件的用户需求更加不统一，变化更大、更快。笔者主要从事企业管理软件的测试。因此我们的做法是把测试数据和测试脚本从测试用例中划分出来。测试用例更趋于是针对软件产品的功能、业务规则和业务处理所设计的测试方案。对软件的每个特定功能或运行操作路径的测试构成了一个个测试用例。

随着中国软件业的日益壮大和逐步走向成熟，软件测试也在不断发展。从最初的由软件编程人员兼职测试到软件公司组建独立专职测试部门。测试工作也从简单测试演变为包括：编制测试计划、编写测试用例、准备测试数据、编写测试脚本、实施测试、测试评估等多项内容的正规测试。测试方式则由单纯手工测试发展为手工、自动兼之，并有向第三方专业测试公司发展的趋势。

要使最终用户对软件感到满意，最有力的举措就是对最终用户的期望加以明确阐述，以便对这些期望进行核实并确认其有效性。测试用例反映了要核实的需求。然而，核实这些需求可能通过不同的方式并由不同的测试员来实施。例如，执行软件以便验证它的功能和性能，这项操作可能由某个测试员采用自动测试技术来实现；计算机系统的关机步骤可通过手工测试和观察来完成；不过，市场占有率和销售数据（以及产品需求），只能通过评测产品和竞争销售数据来完成。

既然可能无法（或不必负责）核实所有的需求，那么是否能为测试挑选最适合或最关键的需求则关系到项目的成败。选中要核实的需求将是对成本、风险和对该需求进行核实的必要性这三者权衡考虑的结果

2.软件测试报告怎么写

摘要 测试报告是把测试的过程和结果写成文档，并对发现的问题和缺陷进行分析，为纠正软件的存在的质量问题提供依据，同时为软件验收和交付打下基础。

本文提供测试报告模板以及如何编写的实例指南。 关键字 测试报告 缺陷 正文 测试报告是测试阶段最后的文档产出物，优秀的测试经理应该具备良好的文档编写能力，一份详细的测试报告包含足够的信息，包括产品质量和测试过程的评价，测试报告基于测试中的数据采集以及对最终的测试结果分析。

下面以通用的测试报告模板为例，详细展开对测试报告编写的具体描述。PARTⅠ 首页0.1页面内容： 密级 通常，测试报告供内部测试完毕后使用，因此密级为中，如果可供用户和更多的人阅读，密级为低，高密级的测试报告适合内部研发项目以及涉及保密行业和技术版权的项目。

XXXX项目/系统测试报告 报告编号 可供索引的内部编号或者用户要求分布提交时的序列号 部门经理 ______项目经理______ 开发经理______测试经理______ XXX公司 XXXX单位 （此处包含用户单位以及研发此系统的公司） XXXX年XX月XX日 0.2格式要求： 标题一般采用大体字（如一号），加粗，宋体，居中排列 副标题采用大体小一号字（如二号）加粗，宋体，居中排列 其他采用四号字，宋体，居中排列 0.3版本控制： 版本 作者 时间 变更摘要 新建/变更/审核 PARTⅡ 引言部分 1.1编写目的 本测试报告的具体编写目的，指出预期的读者范围。 实例：本测试报告为XXX项目的测试报告，目的在于总结测试阶段的测试以及分析测试结果，描述系统是否符合需求（或达到XXX功能目标）。

预期参考人员包括用户、测试人员、、开发人员、项目管理者、其他质量管理人员和需要阅读本报告的高层经理。 提示：通常，用户对测试结论部分感兴趣，开发人员希望从缺陷结果以及分析得到产品开发质量的信息，项目管理者对测试执行中成本、资源和时间予与重视，而高层经理希望能够阅读到简单的图表并且能够与其他项目进行同向比较。

此部分可以具体描述为什么类型的人可参考本报告XXX页XXX章节，你的报告读者越多，你的工作越容易被人重视，前提是必须让阅读者感到你的报告是有价值而且值得浪费一点时间去关注的。 1.2项目背景 对项目目标和目的进行简要说明。

必要时包括简史，这部分不需要脑力劳动，直接从需求或者招标文件中拷贝即可。 1.3系统简介 如果设计说明书有此部分，照抄。

注意必要的框架图和网络拓扑图能吸引眼球。 1.4术语和缩写词 列出设计本系统/项目的专用术语和缩写语约定。

对于技术相关的名词和与多义词一定要注明清楚，以便阅读时不会产生歧义。 1.5参考资料 1.需求、设计、测试用例、手册以及其他项目文档都是范围内可参考的东东。

2.测试使用的国家标准、行业指标、公司规范和质量手册等等 PARTⅢ 测试概要 测试的概要介绍，包括测试的一些声明、测试范围、测试目的等等，主要是测试情况简介。（其他测试经理和质量人员关注部分） 2.1测试用例设计 简要介绍测试用例的设计方法。

例如：等价类划分、边界值、因果图，以及用这类方法（3-4句）。 提示：如果能够具体对设计进行说明，在其他开发人员、测试经理阅读的时候就容易对你的用例设计有个整体的概念，顺便说一句，在这里写上一些非常规的设计方法也是有利的，至少在没有看到测试结论之前就可以了解到测试经理的设计技术，重点测试部分一定要保证有两种以上不同的用例设计方法。

2.2测试环境与配置 简要介绍测试环境及其配置。 提示：清单如下，如果系统/项目比较大，则用表格方式列出 数据库服务器配置 CPU： 内存： 硬盘：可用空间大小 操作系统： 应用软件： 机器网络名： 局域网地址： 应用服务器配置 ……. 客户端配置 ……. 对于网络设备和要求也可以使用相应的表格，对于三层架构的，可以根据网络拓扑图列出相关配置。

2.3测试方法（和工具） 简要介绍测试中采用的方法（和工具）。 提示：主要是黑盒测试，测试方法可以写上测试的重点和采用的测试模式，这样可以一目了然的知道是否遗漏了重要的测试点和关键块。

工具为可选项，当使用到测试工具和相关工具时，要说明。注意要注明是自产还是厂商，版本号多少，在测试报告发布后要避免大多工具的版权问题。

3.上周面试官问我：说说你对软件测试的理解

软件测试是使用人工或自动手动来运行或某个系统的过程，其目的在于检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别。也可以再说一下测试流程之类的基础知识。

另外测试文档也好多，如测试计划，测试方案，测试用例，测试报告等，可以找个模版看看，如测试计划包括目标、概述、组织形式、测试对象、需求跟踪、测试通过/失败的标准、测试挂起及恢复的标准、工作任务分配、应交付的测试工作产品、工作量估计、资源的分配，只要说一些核心的内容，再扩展说一下就可以啦！

4.软件测试 项目总结怎么写啊

能表达得有条理就可以了。

不必介意格式。总结无非就是总结经验，吸取教训咯，本人什么时候参加了什么项目的测试 这个项目是干什么的 我在项目组中做了什么 遇到了什么困难 如何解决的 通过这个项目我学习到了什么 我要感谢谁谁谁 我以后要在什么方面加强 此致 敬礼 附件一 X项目的测试工作到今天算是全部结束了，除了后期维护必要的一些回归测试和用户使用手册的撰写外，整个测试阶段告一段落。

从10月底进入项目，在测试经理的帮助下开始学着写项目测试文档，到根据文档的每日功能测试及回归测试，再到整个项目进行迭代后对测试文档的重新架构及整体回归测试，直至最后的统一交付测试，我个人提交总BUG数为244个。在这244个BUG的提交和回归过程中，在测试文档的写作及修订中，我对整个项目的逻辑及架构逐步清晰，对项目之间所需的复杂交互的认识也越发深入，对项目功能逻辑上的测试如何进行也更加明晰。

下面我简单谈谈对项目的认识、经验和教训，以及对未来改进的一些建议！一、对项目的认识 进入这个项目是在今年十月底，当时测试经理和C已经把Setting（当时是Admin）部分的测试结束了，所以我直接开始接着D的测试文档继续往下写（当时是从Revenue的Report部分开始，即现在的Report模块）。因为跳过了逻辑部分，所以对整个项目逻辑理解很不够，开始写的测试文档也非常浅显，就是描述了一下页面布局。

这里我的感觉是，测试人员进入项目初期，项目经理有必要指派专门人员与测试人员沟通，帮助其理清整个项目的顺序逻辑。当时C简单地跟我介绍了一下整个项目，我的感觉是沟通不够，对逻辑理解比较欠缺。

Report部分写完，就直接开始测试——用自己刚写完的文档进行测试，效果显然不够理想。因为测试人员刚进行该模块测试文档的编撰，再让他对该模块进行测试，这样做的一个后果就是，测试人员会先入为主地觉得自己不需要按部就班地照着文档进行测试（因为文档就是自己写的）。

还有一个很大的问题就是，倘若测试人员在文档撰写上存在严重漏洞的话，他在测试时仍然不可能发现自己的漏洞所在。所以我建议测试文档撰写人员与测试人员最好不要是同一个人，这样有助于发现测试文档构建的漏洞。

测试完Report后，紧接着开始进行Expense模块测试文档的撰写。这时我开始接触到一些逻辑，即Expense与Setting部分联系的逻辑。

这时遇到的问题最多最杂，随时随地都需要与C，甚至项目经理进行沟通。由于之前对主功能（Setting部分）的不熟悉，这种一边沟通一边撰写的测试文档可以说是漏洞百出。

由于项目时间也比较紧，我需要在一周内完成整个Expense模块的测试文档，所以最终完成的文档很不理想。这里我觉得还是之前沟通不到位的问题，应该有一个对整个项目非常熟悉的人来帮助测试人员理清整个项目逻辑再进行测试文档撰写，而不是一开始就撰写测试文档。

接着就是根据自己撰写的Expense文档对Expense模块进行测试，效果也不够理想。这里我还有一个建议就是，如果测试人员在初始进入项目时没有得到及时沟通，至少需要给他一周时间先对主功能（即Setting部分）进行完整测试，对照需求手册及主功能发现的BUG，对主功能进行深入理解。

Expense测试完成后，开始对整个项目进行回归测试。在这个过程中，我逐渐理清了整个项目的逻辑，也开始试图修改以前的文档。

但由于文档量太大，文档结构不够清晰，时间也比较紧，修改难于进行。大部分原因是我经验不足造成的，之前撰写测试文档时，思路过于混乱，想到哪里写到哪里，导致最后文档难于维护和修改。

回归测试结束后，整个系统逻辑已经比较清晰。这时项目进行新一轮的迭代，用户需求改了很多，其中包括增加、修改大量功能、名称，以及对整个系统结构进行重构。

这对测试文档而言改动点非常多（包括结构顺序改变、测试编号订正、功能模块名称修改等），而且需求文档并未因此变化，造成最后测试文档与需求文档的不匹配。这是一个协调的过程，系统迭代后，需求文档应及时随着系统进行修改。

迭代开发过程中，测试基本上是项目改到哪就测到哪，这里面最大的问题不是发现修改模块的BUG，而是发现修改该模块后牵涉到的其它模块出现的BUG。这种连带BUG的产生可以说是防不胜防，让测试人员苦恼不已。

到现在我也没想出解决办法，只能说对模块之间的联系及交互逻辑理解仍需加深。迭代开发后期，开始对整个系统从头回归一遍，这时候又发现了许多以前从未出现的BUG。

这个时期大家都很烦躁困惑，曾经运转良好的页面，突然出现存储问题；曾经更新正常的功能，突然无法更新；曾经显示正常的Excel，突然显示错误… …这些都让人苦恼，当然，这些应该都是正常现象。测试人员在测试后期尤其需要提高警惕，不能漏过任何一个功能点，更不能忽略任何一次貌似无用的查询、翻页、按键。

最后，是大家一起进行的交付测试，人员包括了所有的编程人员及测试人员。这期间，除了对基本功能的回归测试外，还包括了并发测试及性能测试（这主要是编程人员在做），除此之外，我将过去提交修正过的所有BUG重新验。