unity未探索区域迷雾_Unity的探索性测试

unity未探索区域迷雾

Hello everybody, my name is Claus Petersen and I am a fairly recent addition to the Unity family. I am in charge of leading the Software Test Engineers in QA.

大家好，我叫克劳斯·彼得森，我是Unity家族的新成员。 我负责领导质量检查部门的软件测试工程师 。

Last week I finished reading the book ‘Exploratory Software Testing’ by James Whittaker. Not coincidentally at the same time we concluded the first round of exploratory testing (E.T.) sessions that I have been a part of here at Unity. I thought I would share my thoughts on the book as well as our current and future use of the E.T. *Spoiler Alert* … We have not seen the last of E.T. at Unity.

上周，我读完了詹姆斯·惠特克(James Whittaker)的《探索性软件测试》一书。 我们恰巧结束了我参加Unity的第一轮探索性测试(ET)会议，这并非偶然。 我想分享一下我对本书的想法，以及我们当前和将来使用ET * Spoiler Alert *的想法。。。

If you are interested in software testing and haven’t read the book, I encourage you to do so. It’s a relatively quick and easy read and even though the chapters vary greatly in usefulness, it’s never less than interesting.

如果您对软件测试感兴趣并且还没有读过这本书，那么我建议您这样做。 这是一个相对快速且容易阅读的内容，即使各章的实用性差异很大，也从来不会比它有趣。

The first two chapters – ‘The Magic of Software’ and ‘The Case for Manual Testing’ seem to be aimed at either novice testers getting into the craft or developers who believe that processes, engineering practices, defect prevention and automated testing (while all excellent) have or will make manual testing obsolete. James presents at least one damning evidence to the contrary – Windows Vista – and the fact that he worked at Microsoft during the development of Vista leads credence to his case.

前两章“软件的魔力”和“手动测试的案例”似乎是针对新手测试人员或相信流程，工程实践，缺陷预防和自动化测试的开发人员(尽管它们都很出色)。 )已经或将使手动测试过时。 詹姆斯提出了至少一个与此相反的令人震惊的证据-Windows Vista-并且他在Vista的开发过程中曾在Microsoft工作的事实使他对此案产生了信任。

The next four chapters are the core of the book. Chapters 3 and 4 are concerned with “testing in the small” and “testing in the large” respectively.

接下来的四章是本书的核心。 第三章和第四章分别涉及“小规模测试”和“大范围测试”。

The former – testing in the small – is about the actual nuts and bolts of testing. Hands on keyboard and eyes on screen. It does not contain actual test techniques as such. It is more about useful ways to think about software and testing. There are lots of good terms and concepts. A select few:

前者(即小规模测试)是关于测试的实际细节。 在键盘上的手和屏幕上的眼睛。 它不包含实际的测试技术。 它更多地是考虑软件和测试的有用方法。 有很多好的术语和概念。 几个选择：

• Significance of input order and input combinations

  输入顺序的意义   和输入组合

• A good definition of the concept of state (“A state of software is a coordinate in state space that contains exactly one value for every internal data structure”)

  很好地定义了状态(“软件的状态是状态空间中的一个坐标，其中每个内部数据结构仅包含一个值”)

None of this is revolutionary but useful for explaining the problems that James is trying to address in the book. However, as a source for concrete advice and test techniques, James’ own book ‘How to Break Software: A Practical Guide to Testing’, is much better.

这些都不是革命性的，但是对于解释詹姆斯试图在书中解决的问题很有用。 但是，作为具体建议和测试技术的来源，James自己的书《如何破解软件：实用的测试指南》要好得多。

Chapter 4 – ‘Exploratory Testing In the Large’ – is where the concept of exploratory testing “tours” is presented. James’ idea is to take different tourist metaphors and apply them to exploratory testing. For instance, the “guidebook tour” is about following the manual, a tour through the “historical district” examines legacy code and features and the “taxicab tour” explores all routes to a specific location or state. The concept of tours is the book’s main contribution to the world of software testing. The metaphor of software testing as exploration or travelling through terra incognita has often been used, not least in the “American” context-driven school of software testing. The tourist metaphor complements this view well. It is an easily grokkable way of framing and guiding the test activity.

第4章“大型探索性测试”是提出探索性测试“旅行”概念的地方。 詹姆斯的想法是采用不同的游客隐喻，并将其应用于探索性测试。 例如，“指南之旅”是关于遵循手册的，“历史区”之旅将检查遗留的代码和功能，而“出租车之旅”则探索到达特定位置或州的所有路线。 巡回概念是本书对软件测试领域的主要贡献。 经常使用软件测试的隐喻作为探索或穿越隐喻，尤其是在“美国”上下文驱动的软件测试学校中。 游客的隐喻很好地补充了这一观点。 这是一种易于理解的框架，可以指导测试活动。

Chapter 5 is an elaboration on some of the tours and chapter 6 presents some real-world examples of the tours in use. Both are required reading to understand the concept.

第5章详细介绍了一些旅行，第6章介绍了一些实际使用中的旅行示例。 两者都需要阅读以理解该概念。

Even though the actual tours are presented in the preceding three chapters, chapter 7 – ‘The Five Pain Points of Software Testing’ – is perhaps my favourite. It is one of the best summations of the fundamental challenges of software testing that I have seen:

尽管在前三章中介绍了实际的导览，但是第7章(“软件测试的五个痛点”)也许是我的最爱。 这是我所看到的软件测试的基本挑战的最好概括：

• Aimlessness: Testing without a goal. Testing for the sake of testing. In my experience this is the most widespread problem I have encountered in the field of software testing. Not properly defining what needs to be tested, when to test, as well as how to test. What are the questions that you seek to answer with your testing?

  无目的：没有目标的测试。 为了测试而进行测试。 以我的经验，这是我在软件测试领域遇到的最普遍的问题。 没有正确界定需要进行测试什么 ， 什么 时候测试，以及如何测试。 您想在测试中回答哪些问题？

• Repetitiveness: How do we make sure we inject enough variation into our testing so we don’t run into the pesticide paradox? How do we maintain our manual regression test suites.

  重复性：我们如何确保在测试中注入足够的变异性，以免出现农药悖论 ？ 我们如何维护手动回归测试套件。

• Transiency: How do we make sure that our testing is representative of real-world usage of the software?

  透明性：我们如何确保我们的测试能够代表软件的实际使用情况？

• Monotony: The fact that testing can be mind-numbingly, life-drainingly boring (he actually means “checking” – the difference between “testing” and “checking” is topic for another blog-post)

  单调：测试可能令人麻木，让生活变得无聊(事实上，他的意思是“检查” –“测试”和“检查”之间的区别是另一篇博客文章的主题)

• Memorylessness: For testing in the small, how can we persist and relate what actually happened during a test-session so that we can use that info at a later point? For testing in the large it has to do with the concept of coverage – how can we tell what we have tested and how do we get access to historical data about this so we can track trends over time?

  无记忆力：对于小型测试，我们如何才能坚持并关联测试会话期间实际发生的情况，以便我们以后可以使用该信息？ 对于大范围的测试，它与覆盖率的概念有关–我们如何知道我们所测试的内容以及如何获得有关此内容的历史数据，以便可以跟踪一段时间内的趋势？

The last three chapters can easily be skipped. Chapter 8 is musings about the future of software test, none of which seem particular insightful or relevant to me. He spends a lot of time talking about reusability of test-cases. The space and importance he allocates to this seems a little at odds with his points in the early chapters about the importance of manual testing with sentient testers. The last two chapters are collections of James’ blogposts. Good reads – James’ colourful style and affection for British pubs really come through here. But many of the points presented are covered elsewhere in the book.

可以轻松跳过最后三章。 第8章是关于软件测试的未来的沉思，没有哪一个看起来特别有见识或与我无关。 他花费大量时间谈论测试用例的可重用性。 他为此分配的空间和重要性似乎与他在早期章节中关于有感觉的测试人员进行手动测试的重要性的观点有些矛盾。 最后两章是James博客文章的集合。 朗读-詹姆斯对英国酒馆的多彩风格和喜爱确实体现在这里。 但是，本书中其他地方也提到了许多要点。

Exploratory testing tours are not a free lunch. I had actually encountered the concept of Whittaker’s tours before I started at Unity. First impression: “not impressed”. To me they seemed a little superficial and cute. We had tried running a couple of tours. Some of the obvious ones – supermodel, crime-spree, collectors etc. That was fine, but we didn’t find much that we wouldn’t have found using our normal methods. So we kind of moved on.

探索性测试之旅不是免费的午餐。 在加入Unity之前，我实际上曾遇到过Whittaker巡回演出的概念。 第一印象：“没有留下深刻印象”。 在我看来，它们似乎有些肤浅而可爱。 我们曾尝试进行几次旅行。 很好的一些例子-超级名模，犯罪狂欢，收藏家等。这很好，但是使用常规方法我们找不到的东西很多。 所以我们继续前进。

Because the concept of testing tours is so immediately graspable (which is good), it’s easy to fall into the trap of simply running the most basic and vanilla versions of the tours. But if your preparation consists of nothing but “inspect and interact with all UI-elements” (for the supermodel tour), then the results will reflect that. If the tours you pick exercise the same parts of the application that you would have tested anyway – well – your results will reflect that.

因为测试巡回赛的概念非常容易掌握(很好)，所以很容易陷入仅运行最基本和原始版本的巡回赛的陷阱。 但是，如果您的准备工作仅由“检查所有UI元素并与之交互”(用于超级模型之旅)组成，那么结果将反映出这一点。 如果您选择的巡演使用了您应该测试过的应用程序相同的部分，那么您的结果将反映出来。

The sad truth is that the more you prepare for a test session, tour or not, the more you will get out of it (to a point, of course). This also seemed to be one of the general takeaways from our internal evaluation of the E.T. sessions last week. To me, this is perhaps best illustrated by five minutes of James’ talk on testing tours (from 37 to 41 minutes in). It shows some of the work James’ team at Google did as preparation for test of the Chrome OS back in 2009. They didn’t just flip out the Landmark Tour and went to town. Instead they broke down the software into attributes, components and capabilities (ACC-breakdown). They filled out spreadsheets, talked to developers and hosted risk sessions. And THEN they decided on the tools they needed to test this – some of it automated testing, some of it carefully chosen E.T. tours.

可悲的事实是，您为考试准备的越多，是否进行巡回演出，您从中得到的好处就越多(当然，到了一定程度)。 这似乎也是我们上周对ET会议进行内部评估的主要收获之一。 对我来说，这可能是詹姆斯关于测试旅行的五分钟演讲 (从37分钟到41分钟)最好地说明了这一点。 它显示了Google的James团队在2009年为测试Chrome操作系统而做的一些工作。他们不仅跳出了Landmark Tour，还去了城镇。 相反，他们将软件分解为属性，组件和功能( ACC-breakdown )。 他们填写了电子表格，与开发人员进行了交谈并主持了风险会议。 然后，他们决定了测试所需的工具-其中一些是自动测试，一些是经过精心选择的ET之旅。

If, for whatever reason, you have no preparation, the tours in their basic form can be used to good effect. Certainly they are much better than complete ad-hoc testing. But they are not a silver bullet which was the impression I got from how they were initially presented to me.

如果出于某种原因您没有准备，可以使用基本形式的游览，以取得良好的效果。 当然，它们比完整的即席测试要好得多。 但是它们并不是灵丹妙药，这是最初给我的印象给我的印象。

The way I see it, exploratory testing tours are a great tool for overcoming the five pain points of testing outlined in James Whittaker’s book:

我认为，探索性测试之旅是克服詹姆斯·惠特克(James Whittaker)书中概述的五个测试痛点的好工具：

My goal is to integrate exploratory testing more with the way we work. Not big bang overnight but rather slowly and surely. For starters, I am sure we could benefit from having one or more tours as part of at least full test pass for each area. There is some work to do before this can happen. We need to do our homework and figure out our concepts for describing coverage. And then we need to just start doing it. Trying out different tours and see what gives results and what doesn’t. Maybe eventually even come up with some tours of our own.

我的目标是将探索性测试与我们的工作方式更多地集成在一起。 一夜之间不是大爆炸，而是缓慢而确定地。 对于初学者来说，我确信我们可以从至少每个区域的完整测试合格中受益于一次或多次巡回演出。 在此之前，需要做一些工作。 我们需要做功课并弄清楚描述覆盖率的概念。 然后我们需要开始做。 尝试不同的游览，看看能带来什么结果，什么没有。 也许最终甚至提出了一些我们自己的旅行。

I also see uses of exploratory testing that do not necessarily fit into the tours concept. This could be exploratory testing used as part of early feedback on new features pre-alpha. One thing is certain – we have not seen the last of exploratory testing at Unity.

我还发现探索性测试的使用不一定适合旅游概念。 这可能是探索性测试，是对Alpha前新功能的早期反馈的一部分。 可以肯定的是–我们还没有看到Unity上最后的探索性测试。

翻译自: https://blogs.unity3d.com/2013/02/28/10045/

unity未探索区域迷雾