京东购买链接：https://item.jd.com/10205955087769.html
6.6 项目推测
上一节提供了两个推测的示例：随时间变革的缺陷数目和随时间变革的测试用例通过数目。我们对这两个指标并不特殊热衷。在敏捷开发配景下，目的是快速办理值得修复的 bug，bug 的唯一纪录大概只是版本控制体系中的一个变更。
“推测（Projections）”一词源自“project”，在此并不严酷限定其意义。在处理处罚软件质量时，我们大概渴望做出几种推测，这些推测大概包罗以下几个方面：
● 受影响人数：这个变更或缺陷将影响多少用户或客户？
● 逐日经济丧失：标题一连存在的每一天，造成的收入丧失是多少？这被称为“延期本钱”（cost of delay）。
● 间接本钱：除了用户无法利勤劳能的直接本钱外，我们在用户采取、客户流失、贩卖和品牌荣誉方面是否有间接本钱？
● 修复工作量评估：查找标题、修复及重新测试所需的工作量预计是多少？
● 投资回报率比力：相比于其他潜伏的工作，该需求或变更的投资回报率是多少？
Amazon曾声称，网页加载时间延长1秒会导致每年丧失16亿美元的贩卖额，这一说法已经有 10 多年的汗青了。时至本日，这类标题导致的丧失大概会变得更大。有人曾经做过如许的分析。
如今确实有一些工具可以用来分析日志以获取这些信息。对于 Web API 而言，这些工具能分析出相应时间的均匀值（均值）、中位数（中值）和最常见的相应时间（众数）。同时，检察处理处罚哀求的最慢时间也很有资助，好比最慢的25% 哀求的统计指标（比方均匀值、中位数和众数）。别的，我们也可以直接导出整个数据集来直接检察原始数据。
在传统项目中，你大概会发现一些方法来权衡已完成的工作量，以及错误出现的频率，从而推测完成整个项目须要多少个周期以及每个周期应该有多长。随着每个周期推进，待测试的内容量大概会徐徐淘汰。在末了一次运行中，假如回归测试频仍失败，而且我们无法一次只发布一部分内容，那么我们倾向于回到早期的完备用户路程中，重新实行这些测试。关键在于利用 bug 陈诉、度量指标和分析本领来平衡各方面因素，并推测效果。
起首，我们要弄清楚当前的状态；接着，确定须要做出哪些改变，辨认哪些方面须要改进或调解；之后，思索怎样有效地转达这些信息，确保团队成员或优点相干者可以或许明白并采取发起。在第 8 章和第 9 章中，我们将详细探究怎样详细实行这一系列步调。
6.7 推动厘革
我们可以以为，测试“仅仅”是一种技能性观察，旨在展现与质量相干的信息。就这肯界说而言，没有什么标题，由于其涵盖的范围并不大。假如测试工作发现了标题，而且这些标题被详细纪录下来，但却从未有人阅读……那么实际上不会有任何改变，测试工作的贸易代价也就便是零。大概公司很荣幸，没有出现“致命性 bug”，用户也不在意。在这种情况下，理智的管理层大概会淘汰测试预算，大概公司也大概会因此而倒闭。
我们大多数人大概并没有遇到那种完全忽视测试发现的标题的情况，但我们大概面临另一种窘境：测试确实发现了 bug，但只有一部分得到了修复，且不敷彻底。更糟糕的是，开发职员没有从错误中汲取教导，反复犯同样的错误，不绝产生相似的 bug，这种情况会拖累整个团队的服从。有些测试职员以为如许很好，由于有工作可做，就不会赋闲。曾经有一位测试职员对我们说，每次发布都会包罗大量用户界面的 bug 或更改，利用录制回放主动化脚本时，这些变更都会导致脚本失效。通过手工重新创建脚本（实质上是手工测试），他可以发现这些bug，然后等候修复，并再次验证修复情况。整个“主动化”过程实际上与人工测试是重复的，并没有增长额外代价。但只要他乐意，他就能保住工作。
对于拒绝厘革的测试职员，最好的效果大概就是得到一份恒久但使人变得头脑惰化、只是呆板实行脚本的工作，我们以为这并不是一件功德。从第 12 章开始，我们将动手讨论实践战略，但在此之前，先来讨论一个与测试真正相干的精良技能—总结信息的本领。
6.8 总结信息
测试职员身处信息洪流之中，我们须要从中罗致关键信息。由于高层向导者很少偶然间和精神去深入相识这些细节，即便他们偶然间，也无法得到他们所需的高条理信息来做决议。这些决议包罗：
● 软件本日能否上线？
● 我们何时能启动广告宣传运动？
● 为了让软件“充足好”，如今须要修复哪些内容？
● 新功能是否充足好，可以在 ×× 集会上举行演示吗？
● 我们能发布（新功能）了吗？
已往常用的模式是给团队施加压力，促使团队宣称产物已经准备好发布。而当产物并未到达发布标定时，就会去品评那些蒙受了巨大压力的团队成员。对此，我们想寻求一种更好的方式办理这种标题。
语境驱动测试（一种测试头脑的表现，通常是指测试职员起首检察特定迭代的细节，如产物特性、业务需求、相干职员等，来选择他们的测试目的，即夸大人的作用，探求优点相干方关注的 bug）将测试职员定位为观察员和信息通报者，而非决议者。这意味着测试职员不会说“测试已完成”，而是会说“我针对这六个风险举行了测试，发现了这些标题，并以为继续测试没有更多代价”。如许的对话可以在需求开发 / 测试层面、回归测试层面（比方 API、某个 sprint 冲刺），乃至季度全量测试或项目测试层面举行。当我们看到某些“大规模”方法中的额外负担（如 Large-Scale Scrum 在实行过程中确实大概存在一些额外的负担，这些负担重要源于跨团队和谐、产物积蓄工作的管理、脚色和职责的扩展、工具和技能的顺应性以及构造厘革的寻衅）时，我们试图通过“架构师”或“发布列车工程师”等脚色来实现这一目的。接下来，让我们通过一个简单的文本示例来看看如作甚一个假造产物“POWERTRAIN”制作如许的总结。
在对 POWERTRAIN 举行了 4 小时的测试后，我们面临着三种选择：在当天办理以下标题后发布、直接以当前状态发布，或是来日诰日继续测试。我们倾向先办理标题再摆设。以下是我们发现的四个最严峻的标题，预期假如发现更多错误，它们的严峻性也不会超出以下情况：
● 在旧版本的 iPad 和 Safari 欣赏器（特殊是运行 2019 年从前利用体系版本的型号）上举行回归测试时，发现了一系列标题。这些版本虽得到支持并可以利用，但存在一些用户体验标题（缺陷 #2220），只管有直观的暂时办理方案，但用户体验仍旧不佳。Safari/iPad 用户占总体用户的 0.25%，占贩卖额的 0.05%。我们同时也测试了其他欣赏器。
● 奇怪蔬菜图标表现为“破坏图标”（缺陷 #2120）。
● 同时应用五个或以上属性过滤，再加上高级搜索条件（包罗多个 AND或 OR）时，无法返回任何效果（缺陷 #2229）。
● 批评字段限定在 2048 个字符（缺陷 #225），而需求是不限定字符数。值得注意的是，数据库中 95% 的批评长度都小于这个限定，而且错误提示信息清楚明确。
我们预计开发职员能在本日下战书办理上述标题，并于来日诰日上午 9 点摆设产物。我们的测试工作重要会合在搜索功能、产物展示及购物车部分，由于这些是变更最大的模块。我们还快速查抄了陈诉和控制面板功能，并创建了自界说目次功能。如今，我们面临三个选项：继续在这几个关键范畴举行 4 小时的深度测试，对变革最大的地区举行更深入的测试，或是根据当前情况规划产物发布。
上述示例提供了一个文本总结，大概显得有些“繁琐”。在后续章节中，我们将探究怎样利用仪表板、头脑导图、热力图和其他可视化工具，直观展示已测试内容与未测试内容的对比情况。
上面的总结信息中含有一些隐含的信息点，本节我们就来讨论它们。
起首，它向管理层提供了多项选择：“我们可以如许做，也可以那样做，大概采取第三种方案。”当只有一个选择时，人们会感到没有自由。当有两种选择时，他们大概会陷入两难田地。而给出三个或更多的选择后，人们开始感觉到自己把握了控制权，可以或许根据情况做出更得当的决定。
其次，总结中表明，这些只是我们如今发现的 bug。假如有更多时间，我们很大概会发现更渺小的 bug。
末了，它表明确哪些内容没有被测试。这为决议者提供了基于质量因素做出判定所需的信息，同时也提供了一种战略上的机动性。也就是说，假如列出的bug 看起来并不严峻，那么纵然不修复也可以相对安心地上线。毕竟，进一步的测试大概会发现更多此类 bug。
而假如存在更多 bug，但它们存在于我们选择不测试（或仅大抵测试）的地区中，那么我们就不谋面临“为什么没发现这三个标题？”之类的质疑。相反，我们让管理层加入到了决议过程中来，他们乃至不会提出这个标题，由于品评这个决定就是在品评他们自己。
向人们提供信息，让他们加入到决议过程中，如许他们之后就不会对你所做的决议举行品评。
偶然间，构造大概不会服从理智的声音。他们会忽略你的告诫，纵然产物状态一团糟，纵然是字斟句酌的警示可也能会被视而不见，你发现自己无力改变终极的效果。
即便在如许的窘境中，你仍旧可以找到积极的意义。当下次雷怜悯况发生时，构作育有了学习和改进的机会。当他们说“这个项目感觉很像之前的POWERTRAIN 项目”时，你可以回应道：“另有谁履历过 POWERTRAIN 项目？我们还想重蹈覆辙吗？”
假如你渴望从事涉及测试的职业，并盼望在这个范畴有所作为，那么作育可以或许影响厘革的本领是至关告急的。此中一部分涉及战略和政治手腕—你须要意识到大多数决议实际上在集会之前就已经开端形成，假如在集会中试图改变决议方向，大概会偶然中让其他人显得不敷称职或决议不妥。
简便有力的总结是一个好的出发点。无论是口头表达还是书面笔墨，都须要练习这项技能。相识你的听众须要的信息量，学会根据他们的继续本领调解信息的多寡。起首报告现状，接着给出缘故原由，与受众熟悉的案例类比，末了提供多种可选的办理方案。
通常情况下，从事测试工作的职员通常没有决议权，却在蒙受压力，乃至常因团队中有人做出了匆匆发布产物的不良决议而受到品评。我们大概无法完全克制这种情况的发生，但可以通过一些方式资助向导者认同决议过程，偶然乃至是促进整个构造从中学习和发展。
6.9 本章回首
本章讨论了举行高效测试所需的测试相干技能，包罗辨承认能困扰用户的标题、正确陈诉标题、运用数据报告一个有说服力的故事，以及做出推测。然而，“厘革”这一测试环节常常被忽视。假如没有这一环节，测试就仅仅是“我们为了将软件投入生产情况而必须做的官样文章”。另一个常被忽视的测试元素则是测试数据。在下一章中，我们将叙述为何测试数据云云告急，并为读者提供一些战略来网络和管理测试数据。以顺应变革，消除错误警报并紧缩调试时间。
免责声明：如果侵犯了您的权益，请联系站长及时删除侵权内容，谢谢合作！qidao123.com:ToB企服之家，中国第一个企服评测及软件市场,开放入驻,技术点评得现金. |
发表于 