首席鉴黄大师
二、软件测试报告的正文的格式
1 范围
1.1 标识
列出本文档的：
a． 已批准的标识号；
b． 标题；
c． 缩略语；
d． 本文档适用的系统计算机软件配置项（CSCI）。此外，还应包括在本报告中记录的每个正式合格性测试的名称和编号。
1.2 系统概述
概述本报告所适用的系统和CSCI 的用途。
1.3 文档概述
概述本报告的用途和内容。
2 引用文档
按文档号和标题列出本文档引用的所有文档。
3 测试概述
分节描述本报告所覆盖的每项正式合格性测试的结果。
3.1 （正式合格性测试名称及项目的唯一标识号）
按名称和编号来说明正式合格性测试，并分小节概述测试结果。
3.1.1 （正式合格性测试名称）小结
总结正式合格性测试的结果。若失败，则要说明产生错误结果的测试步骤和问题报告。这些内容可参考表1 的测试结果一览表进行概括。
3.1.2 （正式合格性测试名称）测试记录
按时间顺序记录所有测试前、进行测试、分析、说明以及正式合格性测试结果等有关事件。同时，还庆提供测试日志，按时间顺序记录正式合格性测试中的工作，包括：
a．测试时间、地点、软硬件的配置。需要时，测试配置项的描述还要记录软件版本号、研制单位、升级号、批准日期及所有硬件型号和软件部件使用的名
称；
b．每一个测试相关活动的日期和时间、测试操作人员和参加人员；
c．测试过程中对所出现和产生的问题所采取的测试步骤，包括对问题的改
进的次数和每一次结果；
d．恢复重新测试的备份点或测试步骤。
4 测试结果
分节详述每个正式合格性测试的细节。
4.X （正式合格性测试的名称和项目的唯一标识号）测试结果
从4.1 节开始编号。按名称和项目唯一标识号标识正式合格性测试，并分小节详细描述每一正式合格性测试用例的结果。
表1 测试结果一览表示例
（缺）
1） 如果测试过程出现一个故障或错误，则记录发生故障或错误的各个步骤。
2） PR=问题报告。
4.X.Y （测试用例名称和项目的唯一标识号）
从4.1.1 节开始编号，按名称和项目的唯一标识号标识每一测试用例，并分小节详细说明测试用例的结果。
4.X.Y.1 （测试用例名称）测试结果
说明测试用例的测试结果。对测试过程的每一步都要记录测试结果和在测试
过程中出现的各种异常和矛盾情况。记录或引用有助于杜绝和纠正矛盾情况的信息（如存储器转储、寄存器记录、显示流程图），并分析导致矛盾的原因和改进的方法。
4.X.Y.2 （测试用例名称）测试过程中的差异情况
详细说明相应的软件测试说明中描述的测试过程中的差异情况（例如，所需设备的替换，支持软件的改变，测试计划的偏差）。对每一种差异情况，必须说明导致差异的原因和它对测试有效性的影响。
5 CSCI 评估和建议
5.1 CSCI 评估
全面分析测试结果，对CSCI 的能力作出评估。通过分析标出存在的缺陷、局限性和CSCI 的约束等，并写入软件问题/更改报告。对每一种偏差，局限性和约束应包括：
a． 说明它对于CSCI 及系统运行的影响；
b． 说明它对于CSCI 及为纠正偏差的系统设计的影响；
c． 提供改必的方法和建议。
5.2 改进建议
对系统设计、操作和CSCI 测试提出改进建议，并分析每一建议对CSCI 的影响。若无建议，则写“无”。
软件测试 项目总结怎么写啊？高手指教下
能表达得有条理就可以了。不必介意格式。总结无非就是总结经验，吸取教训咯,本人什么时候参加了什么项目的测试
这个项目是干什么的
我在项目组中做了什么
遇到了什么困难 如何解决的
通过这个项目我学习到了什么
我要感谢谁谁谁
我以后要在什么方面加强
此致
敬礼
附件一
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重新验证了一遍。在并发测试中，我们发现了很多之前单人测试难以发现的并发问题（包括多人一起提交，一起选择，一起修改等等），并发问题可以说层出不穷，甚至包括了同一台电脑打开两个页面分别进行修改的问题（由于我从一开始就是打开两个页面来测，一个为用户本人，一个为该用户代理人delegator，所以有些问题在早期已经暴露），这是测试中的一个重点，也是比较严重的漏洞，需要在以后多加留意。
在验证过去修正过的BUG时，仍然发现不少问题，有些是BUG本身的问题，有些是BUG附带问题，还有很多验证时联想到的问题。这一验证过程效果非常明显，所以我建议在项目末期有必要将过去修正的BUG重新认真验证一遍，可以在短时间内收到奇效。
至此，整个项目的测试算是告一段落。用户过来测试后提出一些BUG，经过分析，绝大部分属于用户的一些想法，与测试漏洞无关，整个测试算是圆满结束。
二、经验和教训
这个项目是我接手的第一个项目，也是一个理论联系实际的过程，回想起来，收获颇丰。
经验主要如下：
1、 学会如何将书中的理论与实践相结合；
2、 学会如何根据项目Demo及需求文档撰写测试文档；
3、 学会如何根据项目变更修改测试文档；
4、 学会如何用英文撰写文档，提交，验证问题；
5、 学会如何理清项目逻辑，如何更深入地撰写文档并进行测试；
6、 学会如何与编程人员沟通交流，获得解答，以便正确提交BUG；
教训如下：
1、 撰写测试文档前没有理清业务逻辑，导致前期测试深度不够；
2、 撰写测试文档时结构不清晰，导致后期难以维护和修改；
3、 测试过程中心态有些浮躁，有些急于求成；
4、 还没有形成测试思维，测试过程思维显得有些混乱；
5、 对BUG轻重缓急界定不够，导致有时测试难以继续进行（对一些影响进度的低级别BUG优先级定得太低）；
三、对未来改进的一些建议
经过这次完整的项目测试，学到了很多，也发现了很多问题。对于未来项目的测试，我如下几个不太成熟的建议：
1、 在测试之前项目经理有必要对测试人员进行项目培训，让测试人员对整个项目心中有数，在撰写测试文档时有的放矢；
2、 在测试文档撰写之前需要定义一个撰写规范和标准，大家按照同一个标准撰写，有利于日后文档的维护；
3、 同一个项目功能测试至少应有两人，可以交叉编写模块测试文档，交叉检查文档，交叉进行回归测试，交叉验证BUG，这样有利于避免单人测试考虑不足的漏洞，也能产生更多新的想法，还能相互督促完善文档，提高测试进度；
4、 从一开始就高度重视并发问题，并发问题暴露得越早越易于修改；
5、 项目后期除了不留死角、轮番地扫遍每一个角落（多人协作）外，还需要将过去所有解决的BUG全部验证一遍，会发现不少难以预见的BUG；
6、 对于本项目，目前还有32个延迟（Pending）的BUG，里面大部分为性能和并发问题，还有一些光标、排序及空数据遗留问题，这些看似无关紧要或暂时难以解决的问题都是未来亟需解决的关键所在；
如何写软件测试人员的周报
一般部门内部都有自己的周报模板
内容写一下项目schedule、本周bug数量（连续几个星期的曲线图）、bug状态、也可以列一下top issue、执行的case数、本周工作日志、下周工作计划等
软件测试如何进行日志记录
这个问题你去领测国际官网看看，也许上面会有很多软件测试的相关资源。也有一套视频很不错，是讲解软件测试的教学视频，可以免费下载学习，你会学到很多东西的。你的问题也会得到解决的
Android软件测试的日志文件（Log文件）之多少
log文件分为实时打印的，还有状态信息的两种
实时打印的主要有：logcat main，logcat radio，logcat events，tcpdump，还有高通平台的还会有QXDM日志
状态信息的有：adb shell dmesg，adb shell dumpstate，adb shell dumpsys，adb bugreport
讲解一下各自作用：
通过DDMS抓的其实跟用dos批处理抓的一样都是logcat的日志文件，ddms抓的通常是main缓存中的，就是应用程序打印的日志文件。不过ddms好处在于能够实时看到带有颜色的，如果是用dos批处理只能重定向到文件，到抓完之后才能够看到，不是实时的。
adb logcat -b main -v timeapp.log
打印应用程序的log
adb logcat -b radio -v time radio.log
打印射频相关的log，SIM STK也会在里面，modem相关的ATcommand等，当然跟QXDM差的很远了。
adb logcat -b events -v time
打印系统事件的日志，比如触屏事件。。。
tcpdump 是很有用的，对于TCP/IP协议相关的都可以使用这个来抓，adb shell tcpdump -s 10000 -w /sdcard/capture.pcap，比如抓mms下载的时候的UA profile，browser上网的时候，使用proxy的APN下载，streaming的相关内容包括UA profile等。
最后是高通平台的QXDM，不管是不是Android，只要使用高通芯片，都会对它很熟悉，当然了，不是高通的芯片就不用提它了。这个不多讲，内容丰富，射频，电话，上网，...凡是高通提供的解决方案，这个都可以抓。
状态信息：其实一个就够了，那就是bugreport（命令adb bugreportbugreport.log)。里面包含有dmesg，dumpstate和dumpsys。dmesg（命令adb shell dmesg ldmesg_kernel.log）是kernel的log，凡是跟kernel相关的，比如driver出了问题（相机，蓝牙，usb，启动，等等吧）。 dumpstate是系统状态信息，里面比较全，包括手机当前的内存信息、cpu信息、logcat缓存，kernel缓存等等。adb shell dumpsys这个是关于系统service的内容都在这个里面，这个命令还有更详尽的用法，比如
db shell dumpsys meminfo system是查看system这个process的内存信息。还有其他的比如PV的log，一般都是开发人员自己写的，可能让你放到sd卡里面，其他的不足或需要补充的期望您的指导
标准的软件测试日志是什么样的
没有什么标准的，记录一些事情就可以了
给个 大致框架
项目ID
版本
测试阶段
工作量（人时）
概述
计划执行用例数
实际执行用例数
本日发现缺陷数
致命缺陷数
一般缺陷数
提示缺陷数
困难
建议
标题
执行者
日期
总用例数
累计已执行用例数
累计发现缺陷数
缺陷ID
缺陷ID
缺陷ID
工作日志怎么写？
工作日志包括了发生的日期、时间、主要内容记录，还包括了一些增值信息，您可以通过记录“日程安排”的方式来完成您的工作日志，这些工作日志还可以是循环不断发生的，您还可以设置是否需要提醒，记录和某个事情相关的费用等等。
拓展资料：
关于工作日志
工作日志是指针对自己的工作，每天记录工作的内容、所花费的时间以及在工作过程中遇到的问题，解决问题的思路和方法。最好可以详细客观的记录下你所面对的选择、观点、观察、方法、结果和决定，这样每天日事日清，经过长期的积累，才能达到通过工作日志提高自己的工作技能。按分类可分为：班主任工作日志、学生工作日志、销售工作日志、采购工作日志、行政工作日志、客户服务工作日志、研发工作日志、管理工作日志等等。
随着移动互联网时代的到来，QQ、微博、微信等新应用层出不穷，人们对于时间资源的需求也越来越大，而另一方面，时间的碎片化往往让很多工作者结束一天工作的时候，却想不起来今天到底做了哪些工作。工作日志在帮助人们抵抗时间碎片化方面能够起到一定的作用。
转载请注明出处51数据库 » 软件测试日志怎么写 软件系统测试报告怎么写
