主要结论
　　1.测试自动化是一种妥善记录并具备清晰定义的方法，借此可以反复运行同一套测试脚本。然而与此同时，这种测试自动化脚本还可进一步实现其他更有创意的应用。
　　2.虽然自动化的分析思维很难实现，但我们的脚本中无疑可以具备一定的随机性。
　　3.测试中“随机性”的具体程度各异：从随机输入和参数，再到全面的随机测试用例，情况不一而足。
　　4.很难将随机步骤与相应的验证措施匹配起来，但我们可以使用不同的验证策略确保应用程序能够按照预期工作。
　　5.随机测试无法取代主观或传统测试技术，但可在回归测试过程中让我们对应用程序质量更为自信。
　　正如Cem Kaner在他的一片教程中所说，探索式测试是一种强调个人自由度和个体测试人员责任的软件测试方式，可通过将与测试有关的学习、测试设计、测试执行，以及测试结果的理解视作一系列彼此提携，在项目完整过程中并行执行的活动，借此对测试工作的成果进行持续不断的优化。
　　简而言之，按照他的定义，众所周知的“软件质量和消费者（Software Quality and Consumer）”主张为测试人员提供了在项目中按照自己认为合适的方式进行测试的自由和责任。循序渐进地记录所有规范，这种做法已经不再是必须，原因也很简单，创意过程基本式无法记录的，对吧！在他在TestBash 3大会上有关测试中决策工作的演讲中，Mark Tomlinson对系统的主观理解这一想法表示支持。如果将其作为探索式的，基于风险和基于会话的测试技术（可将其称之为主观技术）的核心，测试者将能主观地确定应用程序中可能导致失败的重要环节。
　　可以参看这张旋转舞者的动力学错觉示意图：不同时刻内，我们的大脑或判断舞者以一个特定的顺序旋转：向左或向右。测试工作也会面临类似情况：我们可能考虑使用不同流程实现相同结果，或相同流程导致虽不同但符合预期的结果，或者，嗯……任何其他结果。
　　整个测试执行过程所用的主观技术可以通过各种成熟的分析思维和“随机性”的优势加以引导。其中后者是一个更重要的要素，本文，将揭露自动化测试中“随机化”的神秘面纱。
　　明确起见，测试自动化并不是一种创作活动，而是一种妥善记录且清晰定义的方法，借此可以让同一套测试脚本反复运行使用。问题在于，我们该如何使用这些测试自动化脚本，同时更更具创意？
　　产品质量随时间而变
　　产品质量模型和所记录的测试场景可通过特定的状态机以及外部特性加以概括。这一点正是测试自动化所热爱的。测试自动化所关注的正是根据一些非常具体的测试需求集编写测试脚本。
　　这种做法很适合功能性回归测试：清理、打磨、全新发布，随后由开发大师创建。姑且将其称之为Shiny吧。

　　但经过一段冗长、精疲力竭的开发时间线后（伴随着多次发布，长达数年的支持，数百个Bug的修复和功能请求等），系统会变成什么样？

　　确实，从用户接口的角度来看，可能非常类似于那种虽然老旧但依然工作良好的系统，但表面之下，这种情况通常被称之为“大泥球”。
　　对于这样的系统，算使用自动化脚本，具体功能的哪些部分依然能获得和初生产发布时同等程度的测试？也许只有30%-80%的部分可以吧。那么其他功能呢？不知道。
　　当然，此时简单的办法可能是审查所有现有的质量文档，改良原有的场景，（即时）引入新的场景等。但考虑到业内的经验，随着遗留系统的规则测试文档逐渐过时，虽然更新工作依然重要，但这种做法并非总是可行。
　　为测试自动化解决方案打造妥善定义的架构
　　下图是一个精简的测试自动化解决方案的范例图，其中包含三层（类似于基于UI、业务逻辑和数据库实现业务应用程序的方法）：UI/API映射、业务裸机，以及测试脚本。

　　1.UI/API映射代表该解决方案的技术端：UI自动化工具程度与自动化系统的UI高度绑定，这一层所用的方法可能类似于focus()、type_text()、click_button()。
　　2.业务逻辑是一种由来自业务操作的关键字组成的库。业务操作是指可以在应用程序中执行的某个步骤（如login()、create_user()、validate_user_created()）。
　　3.测试脚本负责执行一系列链再一起的业务步骤。
　　深入了解独立测试（Separate Test）
　　考虑这样一种简单的记录测试用例：执行这个 – 验证这个，执行那个 – 验证那个，执行某某 – 验证某某。合格的自动化开发者会创建一系列类似下面这样的方法：
　　do_that()， verify_that()， do_this()， verify_this()， do_bla().
　　测试脚本会按照某种特定的顺序调用这样的方法：
　　mySpecifiedCase_1(){
　　do_that();
　　verify_that();
　　do_this();
　　verify_this();
　　do_bla();
　　verify_that();
　　verify_this();
　　}