软件测试实战：微软技术专家经验总结(2)

　　测试报告：测试人员是项目的“车前灯”，他需要提供高质量的缺陷报告和测试报告，以帮助项目团队掌握项目情况并形成决策。

　　测试建模：人们处理复杂问题的常用策略是“分而治之”。在测试领域，测试人员可以建立产品的模型来帮助测试。在建模过程中，他用当前测试目标为指导，省略无关的产品细节，突出重要的产品元素。针对简化后的产品模型，可以更有效地实施测试设计。

　　测试设计与执行：测试人员需要积累多种测试技术，将它们综合运用于当前项目，并在测试执行的迭代过程中，通过持续地评估和反思来逐步增强测试方案。

　　测试开发：测试人员可以使用或开发恰当的测试工具，以提高测试效率。

　　可见，测试人员需要多种能力才能胜任测试工作。其能力集合与开发人员有重叠，但不尽相同。不能单纯用“编程能力”的强弱来评价测试人员的水平。

　　其实，无论主管是否要求，测试人员都可以主动学习编程技术，并应用于实际工作。在测试中，许多活动提供了自动化的机会，例如产品部署、环境配置、机械性的测试执行、信息收集、报表生成等。合理地运用开发技术，构建合适的工具，能够明显提高测试效率。

　　平心而论，项目主管更看重编程工作有现实因素。软件项目的目标是交付能够赢得竞争的软件，而编程是产生软件的最直接的活动，开发人员的水平对软件质量有最直接的影响。测试人员的工作虽然重要，但不能直接产生代码，所以容易被低估。测试人员应该正视这种情况，但不必怀忧丧志。作为一个专业人员(professional)，他应该通过每天的努力来推动职业发展。

　　图灵访谈：您与淘宝测试工程师高翔合著了《探索式测试实践之路》一书的过程中有没有发现一些测试理念的分歧，这样的分歧来源自哪里?最后你们是如何解决的?

　　史亮：我和高翔通过彼此的博客发现双方都对探索式测试有浓厚的兴趣，于是经常交换意见和分享经验，自然成为好友。后来，我们一起合作撰写了《探索式测试实践之路》 一书，以分享所学所知。因为我们都高度认同语境驱动测试和探索式测试的思想，所以并没有根本性的分歧。我们的主要差别在于如何论述探索式测试的实践。

　　下图是测试专家James Bach提出的概念模型，以展示不同测试方法的风格，其中最左侧是严格脚本化的测试，最右侧是高度机动的自由式探索。高翔在论述探索式测试时，更着力于自由式探索并提出了一批他总结出的测试模型，我则没有特别喜好的方法，较宽泛地介绍了一些技术和工具。从某个角度，我们的论述内容构成了深度与广度的互补。

　　图灵访谈：有人说Microsoft算是在软件测试方向上偏传统的，您认同吗?您能向我们介绍一下其他互联网公司如Facebook、Google以及Amazon的测试风格吗?

　　史亮：我并没有在其他互联网公司工作过，虽然阅读过一些报道，但是不能提供更多的信息。因此，难以置喙。我阅读过原版的《Google软件测试之道》(中文版由人民邮电出版社引进)。该书较生动地介绍了一些谷歌的测试实践，部分内容很有启发性，值得一读。

　　正如我之前提到的，测试实践主要取决于产品、项目和团队。在很长的一段时间内，微软最知名的产品都是发布周期为2~3年的套装软件，如 Windows和Office。这些产品的测试实践很成熟，成为微软测试的代表。《微软的软件测试之道》(Alan Page, Ken Johnston, Bj Rollson著)较好地总结了相关方法和经验。

　　随着互联网成为新的计算平台，商业社会的运作已经深度依赖于互联网服务，因此互联网服务的开发和测试成为新的热点。而且，智能手机和平板电脑主导了移动计算的发展，基于App Store发布的移动应用成为用户的新宠。相比之下，套装软件显得不那么“时髦”。因此，微软的测试给人以“传统”的印象。

　　但是，如果仔细观察，不难发现微软的产品已经发生了深刻的变化，且还在持续演变中。伴随而来的是软件开发和测试方式的转变。以下是一些例子。

　　必应的一些在线服务已经做到每日部署(daily deployment)，即代码签入之后，如果成功通过编译和自动化测试，可以在24小时内部署到产品环境，整个流程(代码编译、自动测试、服务部署、在线监控)不需要人工操作。其自动化水平与其他互联网领军企业相当。

原文转自：http://www.cnblogs.com/liangshi/p/3794306.html