大型测试团队应使用哪套准则来减少创建的屏幕截图之间的差异。开发人员和项目经理可能会以不同的方式疯狂,由五个测试人员创建并突出显示屏幕截图。如我所见,为所有测试人员提供简短的指南将是一件很棒的事情,到目前为止,其中有3个:


图像中的颜色用法
用于创建屏幕截图的工具
图像命名

图像中的颜色使用情况

橙色,用于突出显示错误(个人不喜欢红色,因为我想与开发者保持良好关系。另请参见老师应该停止使用红色的笔来标记作业),绿色以突出显示正确的行为并简短地注释该错误的实际操作。

用于创建屏幕截图的工具

为了减少样式上的差异并避免使用不方便的旧工具(例如Paint)。并使用专门为此目的创建的工具(例如TechSmith的Jing或SnagIt)

图像的命名

时间戳记,然后清楚地描述出了什么问题。就像在TechSmith工具中一样:

2015-10-14_1531_[description of the image clear to human being]

该图像应在错误描述或错误报告的注释中以名称提及(否则,为什么我们需要该图像,为什么我应该还是开发人员,请在错误报告中未提及PM检查附件?)

还有其他建议吗?我的想法有什么问题吗?

编辑:


添加了@Dhiman建议的几种截屏和图像编辑工具

> EDIT(2015/11/11):

到目前为止,我们不在图像名称中使用时间戳(在图像文件属性中创建时间就足够了),但是我们添加了发行号和服务器的名字。例如:

58.1.3_[Test_server_name]_[Image_name_clear_to_human].png

对于发现问题的配置,这对于回归测试非常有用。

评论

对于您的工具,我想补充一点,您应该选择TechSmith的“ SnagIt”工具来捕获屏幕快照。我和我的团队也使用此工具来捕获错误和用户文档的屏幕快照,我喜欢这个工具及其非常简单,功能丰富的工具。我不想将其发布为答案,因为它可能会引发讨论。

“开发人员和PM可能会以不同的方式发疯,五个测试人员创建并突出显示屏幕截图。”我想我从未见过这成为一个真正的问题。只要可以轻松地查看和理解图​​像,我就会避免不必要的“标准”。您确实有一个真正的错误跟踪系统,对吗?您不仅仅依赖图片吗?

@JoeStrazzere,我们使用HP ALM 12.20。并且系统中大约有3500多个错误,当一个错误的历史悠久并且在不同时间制作了3个以上的附件时,就会出现问题,这些附件的名称为“ bug308”,“ pic001”等,并且描述中没有诸如“ see附件bug308”,可能只是“检查附件”,但是是哪一个?

#1 楼

我认为您的建议非常好,有明确的指导原则总是好的。尽管不应将它们固定在石头上,而应作为指导而不是作为常规。

全屏显示

为了重现此问题,我要尽可能尽可能的信息。屏幕截图可以说出一千个单词。有些人只截屏他们认为重要的部分,但我一直想要完整的桌面截屏。

全屏图像包括时间,URL和/或用户可能选择的其他屏幕和选择有。此信息通常是快速再现问题的关键。这将在重新制作或重新测试时为开发人员和测试人员提供帮助。

评论


当测试团队中有很多新手时,这一点尤为重要:他们可能不知道屏幕上实际重要的是什么

–伊凡·格拉西缅科(Ivan Gerasimenko)
2015年10月15日在9:39

+1获取完整的桌面屏幕截图。我曾经在许多应用程序上工作过,在这些应用程序中,小部件或UI块可能会显示在几个不同的页面上,或者用户可能遵循不同的路径来访问它。完整的屏幕截图包括面包屑和其他重要数据,以帮助在正确的位置重现问题。

–约翰·奥格斯比
2015年10月15日14:43

#2 楼

错误报告的图像应:


包含所需的所有信息。因此,对于浏览器屏幕截图,请使用整个浏览器窗口,以便人们可以看到浏览器,浏览器版本以及反映已安装工具的所有工具栏,以及显示信息的所有页脚工具栏。
不包含无关信息。我不喜欢整个桌面屏幕截图,因为它包含了太多无关的,分散注意力的信息,甚至可能包含个人信息。同样,这通常意味着您必须放大才能看到实际的窗口并发出通知。
采用的格式可以将图像显示为嵌入到您的票务跟踪系统中(如果您正在使用的话)。
显示导致错误的流程。在这种情况下,我将扩展“屏幕截图”以包括使用电影,然后使用QuickTime(OSX)进行屏幕录制。当难以发现和重现错误时,这将非常有用。对于电影,您可能希望将自己限制在窗口的一部分,以节省空间并减小文件大小。请记住,一部9英寸x9英寸的电影比3英寸x3英寸(9 * 9 = 81和3 * 3 = 9)大9倍。通常用红色圈出项目或写评论。如果使用免费或低成本工具(例如http://www.quickpicturetools.com/en/add_text/)的图像,则可以在顶部完成此操作,例如:




默认情况下应以文件名格式包含日期。许多屏幕保护程序在文件名中使用数据和时间。使它成为必需的过程。这解决了完整屏幕快照的主要有用功能之一。
http://www.allthingsquality.com/2010/04/picture-is-not-worth-thousand-words.html还强调了以下内容:
图片不能解释我们如何到达那里
图片本身不能解释什么是对的,什么是错误的图片在搜索时无济于事

因此,请确保您在这种情况下补充图片。

我个人不注意日期戳和屏幕快照文件名的描述。我将所有元数据都放入了包含屏幕截图的错误跟踪系统中,例如Trello,Jira,Pivotal Tracker等。

评论


当然,我不是在谈论“仅一张照片”错误报告)感谢您对全屏显示的意见。不同意电影“显示导致错误的流程”的原因,这应该在错误报告的“复制步骤”部分中进行描述,从我的观点来看,描述中的图片就足够了99.9%

–伊凡·格拉西缅科(Ivan Gerasimenko)
2015年10月15日14:07



对于电影-我会尝试的。它改变了我执行错误报告的方式,并极大地减少了“我不了解它/无法复制它”的信息。开发人员的想法可能会有所不同。描述有时并没有减少,或者可能会很长,在这种情况下,如果您想借口一句盗用的话,一部电影就值一千张屏幕截图和说明,我不是每次都做,但是当它与工作流程以及如何到达那里有关时,它们会对我们有所帮助。

–迈克尔·杜兰特(Michael Durrant)
2015年10月15日14:12



是的,复制步骤很重要。我之所以没有这样做,是因为一旦添加,我可能还会添加更多内容,并且我想继续关注话题,只讨论图像。好吧,好吧,电影也;)还有很多其他关于好的错误报告的问题。大多数操作系统屏幕截图的默认值是文件名中包含日期时间,因此我允许其为“原样”。这也符合精益平均敏捷哲学,在这种哲学中,除非明确了它们的附加值,否则我不会死记硬背地创建此类工件。

–迈克尔·杜兰特(Michael Durrant)
2015年10月15日14:27



言归正传:在显示动画问题时,电影而不是图片至关重要!当然,可能会有更多的例子。

–伊凡·格拉西缅科(Ivan Gerasimenko)
2015年10月21日在7:25

#3 楼

我将一一回答/仔细说明您的观点,并尝试在您的有用且精确的描述之外添加一些有价值的信息。

图像中的颜色使用:在创建与以下内容相关的错误时,突出显示至关重要GUI。关于颜色,过去几年,我们一直使用红色(R = 255,G = B = 0)和蓝色(R = G = 0,B = 255)来突出显示颜色(通过SnagIt)。没有遇到任何开发人员的问题。我已经看完了发布的文章,会说,如果用红色突出显示错误会导致团队问题,那么创建错误会更令人讨厌。

因此,您可以毫无问题地使用红色,因为这是团队应该理解的工作的一部分(我也不介意您的橙色想法),但是红色更引人注目。我们定义了两种颜色,因为有时您要突出显示的区域已经具有相同的背景或边框,这使得突出显示不可用。因此,请定义两种颜色以突出显示。

用于创建屏幕截图的工具:我已经提到SnagIt应用最广泛,并且功能丰富的工具可以捕获和编辑图像以创建错误,用户指南,发行说明等。 。它还提供了“自动滚动”选项,当您需要拍摄整个页面的屏幕快照时,该选项非常有用且节省时间,否则最终会拍摄多张并将其添加到一张中。不能说出Jing,因为我还没使用过它。

请注意此处列表中的前两个(Snipping Tool和FastStone Capture)仅适用于Windows。
没有OSX或Linux版本。



图像的命名:我们使用的这方面与您定义的准则非常相似,即DateTimestamp_PageName_SectionName(if multiple sections/tabs are there on page)_DefectedFunctionality/Feature

除此之外,我完全同意“ Niels van Reijmersdal”关于完全桌面捕获的想法,并且只是添加了它。我已经看到全屏捕获还有助于确定包含错误的特定页面的路径,例如如果您的应用程序维护/显示导航路径(Breadcrumbs),则该路径对于开发人员(尤其是大型应用程序中的新开发人员)而言非常重要,因为它很容易将其引导至该页面,而无需任何其他团队成员的帮助。

然后,您需要定义



文本框(它们的边框,填充颜色,易于读取的字体和字体大小)的用法
箭头,指针,线条(颜色和宽度)
SnagIt印章(对于定义图像中的步骤非常有用)

我要说的是保持准则和所有这些设置简单,灵活且轻巧。在我的上一个项目中,我们已经为这些准则创建了一个客户端共享文档(不是专门用于错误报告,而是主要用于用户文档),并将其作为新QA归纳过程的一部分。

评论


+1使其成为归纳文档的一部分。大多数组织/团队不遵循这些程序。

–demouser123
2015年10月15日15:33

#4 楼

在我们公司,我们非常罕见地将屏幕截图用于错误报告,主要是为了显示视觉错误,因为屏幕可以显示1000多个单词。为了突出显示,我们通常使用绿色来表示正确的行为,而使用蓝色(或torsquise)来突出显示不正确的行为-这有两点:


与GUI更好的对比
避免出现红色/绿色盲目问题

但是当然必须对每个屏幕截图都必须有详尽的问题描述。屏幕快照只是错误报告措辞的补充。

在超过95%的测试/错误报告中,我们使用视频工具HP Screen Recorder(无论如何与HP ALM一起使用),以及这些视频可以逐帧访问,因此您可以看到每个步骤,例如构建GUI时。

甚至有点题外话:我们的视频快照指南也包括


全屏显示(查看其他打开的程序,URLS等。)
显示带有视频的版本号的“信息”屏幕
显示一些基本数据(如果与错误相关,也许是计算结果)
显示直到错误发生
在视频中添加文本框/错误/突出显示框以向观众提供信息,例如“我现在按F12”

,这可以帮助开发人员在很大程度上找出导致错误的原因错误不是由发生的时间点直接导致的,而是由于“正在发生的故障”或由于不良的基本信息而导致测试人员不知道的-因此可能不在错误报告中。通常是这样,因为我们的某些错误报告的质量来自最终使用该软件并且没有接受过如何编写好的错误报告的培训的人员。