京东购买链接：https://item.jd.com/10205955087769.html
6.3 编写 bug 陈诉
我们相助的一些团队已经制止编写 bug 陈诉，也不再追踪 bug。取而代之的是，开辟职员和测试职员在协同工作时发现并办理标题。在某些情况下，团队成员大概会在某个框架中创建一个失败的主动化查抄，此时，修复的目标是让查抄通过，同时不引起其他任何部门失败。偶尔，开辟职员也会自测，发现标题后直接“修复并继续进步”。别的一些情况下，团队成员位于同一空间中，发现标题标人可以直接走到责任人（结对编程、三人一组或群体编程）面前，表明标题，然后立刻办理。许多人以为这是当代软件开辟的方式—即将测试融入开辟过程中。这种做法非常棒，我们也很支持。
但我们仍然以为你应该学习怎样编写一份有效的 bug 陈诉。
从根本上讲，bug 陈诉是一种不理想的沟通方式。它指出的标题会给干系人士带来困扰，这种沟通既可以是口头告知他人标题地点，也可以通过书面情势进练习怎样有效地誊写 bug 陈诉、学习怎样具体形貌 bug，并养成截屏和录屏的风俗—在 bug 通报过程中，这些技能都非常有代价。口头交换的风险会根据对话的笼统程度而略有差别，但提供了更好的即时反馈机会。相比之下，bug 陈诉则为修改代码提供了更便利的机会。假如公司有跟踪纪录 bug 陈诉，不妨利用午休时间回首已往一百份左右的陈诉，看看哪些得到了修复。在多数情况下，陈诉的誊写方式就能预示着 bug 的将来走向。那些表述暗昧且将缘故因由排查推给修复者的陈诉，很大概会被以“无法复现”“符合预期”为由关闭，或是导致开辟团队与陈诉人之间无休止地来回沟通。
再次夸大，我们将 bug 界说为“令紧张人物感到烦恼或困扰的事物”。低级测试职员经常会发现一些困扰本身的标题，但他们并不是决定标题是否必要修复的人。正如我们的同事弗里·纳德曼正确地指出的那样，这大概会让人感到沮丧。我们渴望通过这项工作资助你理办理策者关心什么，并以一种对他们故意义的方式表达。更高级别的员工大概会“站在决议者角度思考”，在某种程度上成为一个小型的产物负责人。
对于举行用户验收测试（User Acceptance Testing,UAT）的公司来说，bug 陈诉尤为紧张。UAT 是指软件为特定范例的客户（用户）定制，且公司在测试过程中会约请代表这些用户脚色的职员参加。然而，假如现场没有人帮忙这些用户有效地编写 bug 陈诉，终极网络到的信息通常会很暗昧，无法提供实质性的资助。我们以为 bug 陈诉是提拔软件质量的一种机制，若缺乏有效的陈诉机制，整个测试过程将徒劳无功。这也是许多人对 UAT 持生存态度的缘故因由—由于他们的 bug 陈诉质量非常糟糕。
在某些情况下，缺陷会逃逸到生产情况。纵然团队在标题进入生产情况之前能发现全部标题，新的欣赏器版本或利用体系也大概导致新的 bug。在这种情况下，假如收到的 bug 陈诉不敷以阐明标题，那么 bug 大概要被反复陈诉多次后才会得到修复。
可见，我们有须要写好 bug 陈诉。
6.3.1 有效的 bug 陈诉
下面是一个 bug 陈诉模板：
● 前置条件：包罗情况变量、数据库中的内容以及任何须要的设置。假如是特定欣赏器或情况下发现的标题，也应该在此阐明。
● 利用步调：复现 bug 的具体利用步调，最好是以编号列表的情势出现。
● 预期效果：软件预期产生的举动或输出效果。
● 实际效果：软件实际的效果或体现。
● 更多信息：假如实际效果并不清楚明确，可以思量添加附件，比方屏幕截图、录制视频。本书保举利用 Windows 自带的截图工具或 Techsmith 的Snagit。另一种选择是利用手机直接拍摄标题界面并附加到陈诉中。假如复现bug 存在困难，但你能使其在 70% 或更多的情况下出现，那么可以在此列出复现标题标提示和本领。弗里 · 纳德曼发起每次测试控制在 30 分钟左右，并录制整个过程。如许做会从一开始就确保标题标可复现性。
● 择要 / 标题：对标题举行一行简单的概括阐明。
在实践中，人们经常会跳过陈诉中的具体内容。因此，我们必要积极将择要写得充足完备，以使读者纵然跳过主体内容也能相识标题概况。为了到达这个目标，我们将择要放在末了并发起末了誊写。
为了阐明这点，我们提供了一张某网站的真实（稍作暗昧处置惩罚）截图（图 6-3）。你会给这个 bug 起什么标题呢？
图 6-3 一个移动应用中的文本处置惩罚错误
下面，我们来看一些大概的标题，以及测试职员怎样对待它们：
● 集会会议网站中“关于我们”页面在移动版本上数字紊乱。查抄职员大概会在平板电脑上复现这个标题，但没有发现标题，然后将其标志为无法重现。
● 在特定型号的 iPhone 上利用 Safari 欣赏器访问“关于我们”页面时出现数字重叠 / 庞杂。这大概引发关于 iPhone 用户数目、支持哪些 iPhone 版本以及公司是否支持 Safari 欣赏器的争论。实际上，公司通常会为装备设定一个最低支持版本（通常支持已往两到三个版本的装备），以及支持的欣赏器范例。在举行测试时，我们一样寻常至少会在两种差别的欣赏器上举行，而且只管选择与开辟职员所用差别的欣赏器。然而，随着欣赏器市场的不停成熟，我们发现所谓的“欣赏器兼容性标题”正渐渐淘汰。因此，择要大概如许会更好些：
● 移动装备上“关于我们”页面出现数字重叠 / 紊乱（以 iPhone 16 Pro 为例的屏幕截图）。如许的择要既告知读者他们可以在一个特定装备上复现该标题，同时也表明标题并不范围于这一特定装备。
当我们将此截图发布在 X（原 Twitter）上并征求一个好的择要时，有人复兴说“列标题相互重叠”，我们可以将其完满为“移动装备：‘关于我们’页面的列标题 / 数据重叠（来自 iPhone 16 Pro 的截图）”。
想象一下阅读 bug 陈诉的人很懒，他们不想按照步调去重现标题，他们渴望全部信息都能从标题中直接获取，而且是立刻就要得到。
以是为什么不直接提供给他们呢？
6.3.2 有效的复现步调
假设你正在测试一个在线账单应用步调。点击服务日期（service date）后检察“月份”的弹出窗口，如图 6-4 所示，此中日期以数字体现，而 23 号却错误地体现为 2.3。
下面提供两种方式来形貌这个标题。
方式一：
● 择要：在服务日期（新建账单）日历中，部门数字以笔墨情势体现。
● 复现步调：利用 Chrome 欣赏器最新版本，创建一个新的账单，点击服务日期旁的日期选择器图标，睁开的日历中会看到某些数字以笔墨情势出现。
方式二：
● 择要：新建账单标题：条记本电脑上，服务日期的日历下拉菜单中月份的某些数字以笔墨情势体现。
图 6-4 日历功能中的文本转换错误
● 复现步调：
Ⅰ. 以测试用户身份登录，即利用 testuser@testaccount.com 邮箱举行登录。
Ⅱ. 期待页面加载完成。
Ⅲ . 点击“Sales”（贩卖）。
Ⅳ . 点击“Invoice”（发票）。
Ⅴ . 点击“New”（新建）。
Ⅵ . 期待页面加载完成。
Ⅶ . 找到第一张发票第一行中的“service date”字段。
Ⅷ . 点击“service date”。
Ⅸ . 进入“月份”下拉菜单。
Ⅹ . 选择月份“August”。
● 预期效果：日期选择器中的月份弹出窗口，全部日期均以数字情势显现。
● 实际效果：日历中的 1 号、2 号、11 号、15 号、20 号和 21 号等日期以英文单词情势体现（如“one”“two”等），而 23 号却非常体现为 2.3（此处错误地在数字 2 和 3 之间参加了小数点）。
第二个表达方式固然具体且正确，但确实显得较为冗长和乏味。因此在编写bug 陈诉时，必要找到一个平衡点，既要提供充足的信息以正确地辨认和修复标题，也要制止过多的细节导致信息紊乱。
在“正确性”与“易读性”之间的最佳平衡点，会因团队需求的差别及 bug的具体情况有所变革。根据我们的履历，对于那些显着错误的标题，通常只需一个简单的阐明共同截图就充足了。为了提拔团队在这方面的意识和本领，我们发起开展一项练习：选取一个真实的 bug，让每个团队成员独立编写 bug 陈诉。随后打印这些陈诉，带上暗号笔，让团队成员选出他们以为最优质的 bug 陈诉。然后，对你们以为优质的 bug 陈诉的构成要素举行分类和讨论。这项练习的理念在罗伯特 · M · 波西格（Robert Maynard Persig）的著作《禅与摩托车维修艺术》中有较为具体的形貌，该书副标题是“对代价的探究”。
现在，我们发起将 bug 陈诉视为一种目标导向的辩说。无论 bug 陈诉以何种情势出现，阅读陈诉的人都大概有一个潜伏目标—那就是忽视这份陈诉。他们面临着停止日期的压力和其他诸多紧张事件，而修复 bug 只会拖慢他们的进度。鉴于此，他们会探求各种来由不可止理这些标题。这些来由大概包罗以下几点：
● bug 陈诉太暗昧，我无法明白或复现。
● bug 陈诉太具体，冗长且乏味，以是不紧张。
● 这个 bug 仅在特定情况下出现，因此没那么紧张。
● 没有提到情况，我在 ×× 情况测试了，无法复现。
● 这份 bug 陈诉错别字太多，我无法认真对待。
● 这份 bug 陈诉太长了，更像是抱怨而非陈诉。
这使得陈诉 bug 的过程雷同于奥德修斯（Odysseus）驾驶他的船在双怪之间飞行的情形—一边是栖息于悬崖岩石上的怪物斯库拉（Scylla），另一边则是制造漩涡的卡律布迪斯（Charybdis）。完善的 bug 陈诉应当如飞行于这两者之间那般精准而不外于枯燥，既要防止被误解，又要得当地表达标题标范围和紧张性。
假如你地点的情况经常出现仅在某个平台上出现的 bug，那么花上约莫 10 分钟时间去查抄该 bug 是否也存在于其他装备、外形规格、利用体系和欣赏器。假如确实存在，你仍然应该列出最初发现该bug的情况，同时注明该bug似乎广泛存在。
测试陈诉过程的压力
在本节将竣事之际，我们想跳出当前的视角，审阅一下那些效果不佳的 bug陈诉。从第 12 章开始的“职场实践”部门，将包罗一些测试工作效果不佳且未能产生有效改变的故事。在大多数情况下，bug 陈诉的标题未能充实证明该标题必须得到办理，即陈诉 bug 的人未能让管理层意识到这些标题标紧张性。然后，一周、一个月，以致一年之后，当出现严峻的标题时，管理层又会将责任归咎于那些本应该关注产物风险的人—特别是与产风致量干系的风险。
编写不佳的 bug 陈诉还具偶尔间衰减效应。在陈诉刚被创建时，由于团队正满身心地投入到工作中，陈诉中所指的标题大概还算明确。但到了下一个冲刺阶段，大概必要泯灭一些功夫才华明白编写不佳的陈诉。而到了来岁，随着团队成员的变更，由于缺乏共同的工作履历和上下文明白，原先的陈诉对新团队成员而言大概就变得毫偶然义。新团队大概看不到旧陈诉的代价，由于这些陈诉对他们来说没有直接的资助，不具有实际效用。
全部这些因素加在一起，大概会边沿化以致消除测试工作的作用。这种因素并不希奇，也不是独一无二的，而且不会消散。我们渴望，纵然测试脚色的关注度大概会低落，软件开辟流程中的每个人都应意识到，随着测试职员的淘汰或测试脚色的消散，团队中的每个人都必要更加深入地学习测试。那些接纳灵敏方法和高信托度、选择“发现标题就立刻修复”而不纪录 bug 的团队，将陷入无法明白测试过程中发生的情况、没有数据来验证假设、做出调解或举行实验的风险中。缺乏这些数据，测试的其他要素，如度量、推测和规划，就变得更加紧张，接下来我们将转向这些方面。
免责声明：如果侵犯了您的权益，请联系站长及时删除侵权内容，谢谢合作！qidao123.com:ToB企服之家，中国第一个企服评测及软件市场,开放入驻,技术点评得现金. |
发表于 
