软件质量控制实践 - Microsoft 篇（2）

   <p> <a href="http://www.open-open.com/news/view/1bd2315">软件质量控制实践――Microsoft 篇 (1)</a></p>    <p> <strong>4. Drive quality upstream</strong></p>    <p> 我们都知道 bug 越是滞后发现，修复的成本越高。据微软统计，如果产品发布以后需要发布一个热修复，它的直接成本是 150 万美元（间接成本在 200 万美元），而在发布之前的一个月发现的话，修复成本是 5 万，设计阶段修复成本是 1 千，需求阶段修复成本是 1 百。在需求分析阶段，测试人员主要职责就是验证需求分析的可行性和可靠性。PM 和 DEV 的共性是易于乐观，倾向于把实际情况简单化，所以会作出很多假设。比如用户肯定不会这么使用，用户肯定知道如何用，所有用户的环境肯定都有该配置。但是实际情况下总会有用户不知道如何用，总会有用户会不按“预先设计”的方式使用，总会有用户环境没有该项配置。所以测试人员的主要职责就是找出这些假设并提出疑问并加以验证。</p>    <p> 在 dev 设计阶段，测试人员需要验证设计，同样找出 dev 的假设然后疑问这些假设是否合理，看看该设计是否处理很多没有预料的但是有可能会发生的情况，比如用户输入特殊字符，非常规操作，非常规流程，机器重启，死机，数据库连接中断，网络中断，内存耗尽等等。除了验证设计是否处理非正常情况外，测试人员的另外一个更为重要的职责是验证设计的可测试性。可测试性是指测试软件容易的程度。软件的可测性对于提高软件的质量至关重要。道理很简单，如果你的软件很难测试，无从下手，测试一个用例需要几个小时甚至几天的话，你的软件质量也就无从保证。提高软件可测试性通常的做法是把软件模块化，松耦合，模块内部运行状态可见，模块内部运行分支可控制。在评审一个设计时通常问的问题是该如何测试该模块，是否容易测试它，能不能单独测试它。如果不可以的话，需要重新考虑设计。因为一个设计的很容易测试的模块和产品可以使得后期的测试代价大大降低。微软大部分复杂系统都会有一个“one-box”版本，该版本是个假的模拟系统但是拥有真正系统的几乎所有功能，它可以运行在任何机器上。系统的绝大部分功能都可以在该模拟系统上快速方便验证。我在培训的时候很多学生问：他们在后期测试的时候遇到许多无法测试或者很难测试的困境，问我该如何解决。在具体了解困难和困境之后，我发现他们的测试策略非常单调，只能把产品部署到有限的测试环境下从用户界面上做端到端的测试。如果想测试某个特定模块或功能需要好几个其它模块配合起来才可以。我就坦率的说如果你的软件是这么架构设计的话而且已经到了这一步，世界上没有人可以解决你现在面临的困难。因为看起来好像你是卡在现在这一步了，但实际上根本问题是在前期，在需求或设计。就像解决河流的水质污染问题，你在下游无论多大的代价也只能稍微改善，解决问题的根本方法是在解决上游的污染源。或者像隔靴挠痒，隔着厚厚的靴子无法挠到关键地方，必须能够把靴子脱掉直接挠。</p>    <p> <strong>5. Getting better every day</strong></p>    <p> 软件测试的目的一个是找出 bug,另外一个是衡量软件的质量。通过测试来了解产品哪些地方薄弱，哪些地方不稳定. 通过监控测试的结果，包括功能测试，性能压力测试，安全测试，本地化测试，容错测试等等来反映当前软件的质量。这也是持续集成的一个重要原因，它一方面短期迭代，另一方面可以在最短的时间内知道软件的质量，同时跟踪软件质量重开始到发布，软件质量的变化曲线。衡量软件质量的通常指标有：测试用例通过率/趋势，bug 数量，种类/趋势，代码覆盖率等等。另外测试在开发周期中通常做的其它工作还有：bug root cause analysis, Bug analysis, Test case failure analysis, test gap analysis, Bug talk, bug share, CCS data analysis 等等。这一方面促使产品质量逐渐变好，而且是看得见的好。另外也促使自己放下繁忙的工作静心思考一下，如何更有效率更进一步提高质量。</p>    <p> <strong>6. Engineering agility</strong></p>    <p> 随着软件即服务和云计算的兴起，它们给开发管理，质量管理，运营管理等提出了很多新的挑战。以前那种保密开发测试2－3年再突然发布的策略无法适应互联网应用服务的要求，而是逐渐演变成快速开发出产品基本原型，然后就发布，根据用户反馈不断加以改进的方式。质量管理方面，基于服务的产品除了关注功能性能，还有其它特别重要的方面，比如 scalability， high availability， fault tolerance, disaster recovery， etc.. 这些都是桌面型产品所没有的或不重视的。微软从 2010 年开始在很多组开始实践如何提高服务型产品的质量，比如 Azure, Bing, etc…。其中最为根本的一点就是提高整个团队的敏捷度，团队能够跟的上快速迭代交付的节奏。这需要从产品设计上到测试自动化，工具，基础设施上得以保障。另外一个非常重要的实践就是 TiP (test in production) 或 crowd-sourced testing. 我们在前面谈到“drive quality upstream”，也即是提前测试。test in production 正好相反是“drive quality downstream”，也即是在产品环境中测试。传统的桌面产品发布之后就不再测试了。服务型产品，产品发布后继续测试。它的基本出发点是：无论投资多少建立测试环境用以模拟产品运行环境，测试环境和真正产品环境总会有不同。无论花费多大的代价做前期测试，都不可能找出所有的 bug。所以无论在发布之前花费多大的代价做测试，在产品上线后总会发现新的 bug。现在既然发布产品更新非常快和容易，为什么不干脆在真正产品环境中来测试，或者利用真正的用户使用真正的产品来测试（当然用户意识不到）。一旦发现 bug,马上修复，马上更新。这不仅减轻了前期测试的投入，而且提高的测试效率。看看我们在测试环境中发现的 bug 有多少没有被认为是“真正”的 bug 就明白了。当然要做到 test in production, 需要很多具体的流程、技术，工具作为保障。不能影响用户的关键业务，不能让用户发现过于简单的 bug。 除了基本的测试自动化基础设施和测试用例外，常用的一些 TiP 技术有：A/B testing, expose control/slicing model, on/off features, chaos-monkey， measuring/monitoring.</p>    <p> <strong>7. invest on test engineer’s career</strong></p>    <p> 无论产品使用何种方式保障质量，人总是最核心最关键的因素。提高软件质量有无数种方式和无数个因素，如果非要说一个最最重要的方式，那就是激发测试工程师的工作热情。You can only achieve average by working hard, but passion is the one driving to excellence. 为了最大化激发测试工程师的潜能，微软为测试工程师设计一整套完善的职业发展计划。测试工程师主要有两个职业发展路线。一个是 Individual Contributor (IC): 不管人，管技术。另外一个是 Manager: 偏重于管人和项目。这两个路线没有好坏之分，因人而异。两个路线都是以技术能力为核心，也是加薪升职的最主要考虑因素。经理未必比个人挣钱更多，“Become a manager is not a promotion”。You are paid for what you cover。”what you cover”就像长方形的面积，面积大小有长和宽同时决定。VP 管的很多（长），但是深度有限（宽）。而技术大牛管的很少（长），但是很深（宽），所以两个长方形的面积大小差不多。这也就是为什么有些技术大牛一个人不管但是挣钱和 VP 一样多。下面是几个测试工程师常见的职位：</p>    <p> SDET － 初级测试工程师 ，要求是：executor，如果有个问题需要解决，而且告诉你如何解决，你能够很好地把问题解决了。</p>    <p> SDET 2 － 中级测试工程师 ，要求是：designer，如果有个问题需要解决，你自己找出办法去解决。</p>    <p> Senior SDET － 资深测试工程师，要求是：planner，你自己去发现问题，然后找出解决办法。</p>    <p> Principal SDET － 首席测试工程师， 要求是：thinker，能发现问题并且发现问题的共性，不仅解决问题而且避免问题出现。</p>    <p> 对经理的要求也大致如此，除了技术上也要过硬外，还要求经理为手下的人尽可能创造机会以帮助他们成功。</p>    <p> 另外微软鼓励测试工程师创造性思维，鼓励员工创建好的测试工具用来提高测试效率，好的想法也可以可以申请测试专利或发表论文，并且被邀请到国际性测试会议上做演讲。微软内部有一个测试工具库，有将近 1 万个测试工具。本人就有一个测试，具在微软内部 50 多个产品组广泛使用，我也多次做演讲，现在正 open source。</p>    <p> 最后，我总结的测试工程师必须具备的硬技术能力：</p>    <p> 1、至少一门编程语言，比如 C++/C#/Java，最好也了解<a title="设计模式" href="http://www.amazon.cn/gp/product/B001130JN8/ref=as_li_qf_sp_asin_il_tl?ie=UTF8&tag=vastwork-23&linkCode=as2&camp=536&creative=3200&creativeASIN=B001130JN8" rel="nofollow" target="_blank">设计模式</a>的基本概念，比如：open-close principle, design to interfaces, favor aggregation over inheritance, encapsulate</p>    <p> by policy and reveal by need, etc…</p>    <p> 2、至少一个脚本语言， 比如 DOS batch, powershell, perl</p>    <p> 3、熟悉测试基础，比如功能测试，性能压力测试，安全测试，本地化测试。</p>    <p> 4、基本测试技能，比如等价类划分，边界值分析，黑白盒测试，组合测试，基于模型测试，探索性测试等</p>    <p> 5、Xml</p>    <p> 6、P/invoke</p>    <p> 7、Reflection</p>    <p> 8、Threading</p>    <p> 9、Code coverage analysis</p>    <p> 10、Network knowledge, such as TCP/IP, HTTP, HTTPS,WCF</p>    <p> 11、Fault injection/dependency injection and mocking</p>    <p> 还有微软鼓励测试工程师 take responsibility， make a difference。鼓励员工在做好本职工作同时在某一项技术领域专的更深。比如前面提到的一些测试基础 (test fundamentals) 包含功能测试，性能压力测试，安全性测试，本地化测试，容错测试， TiP 等等。可以鼓励测试团队的每一个人选一个领域去专研，把他培养成不仅是产品组里的 go-to person, 而且成为公司内乃至更大范围的领域专家。这不仅对产品的质量有帮助，更是对员工本身职业发展的极大激励。工程师是一群特殊的人类，如果一直重复做一件事（比如本职工作），很容易厌倦失去兴趣；相反越是有难度，有挑战，有<a title="影响力" href="http://www.amazon.cn/gp/product/B0044KME2E/ref=as_li_qf_sp_asin_il_tl?ie=UTF8&tag=vastwork-23&linkCode=as2&camp=536&creative=3200&creativeASIN=B0044KME2E" rel="nofollow" target="_blank">影响力</a>的工作，越是激发工程师一定要搞定，做好的斗志和恒心，哪怕是没有任何报酬，不为别人，为的是自我价值的实现。英语里有句话：it’s not what you have to do make you success, it’s what else you do . that will make a difference. 所以不仅仅把本职工作做好（这是最低要求了），更进一步将会使你脱颖而出。“更进一步”不是指你的本职工作，也不是让你加班加点，而是指那些自己喜欢的可以实现自我价值，同时对产品质量有深刻影响的东西。没有人逼你做这些东西，你完全可以选择按部就班或平平庸庸。最后引用功夫熊猫里的一句话立志：It’s not about where you came from or what you were, it’s about what you choose to be。所以，what you choose to be?</p>    <p> 好了，关于微软的话题就此打住。感觉好像在写长篇小说，没完没了，越聊话题越多。:)</p>    <p> 小结，英语里面有句话“little steps lead to big change”。我觉得这句话用来描述微软走过的测试路最恰当不过了。微软有几百个产品组，发布过几千个产品。很难有一个或几个因素决定产品的质量。但是上面几个是我个人认为是诸多因素中的几个至关重要的。微软是世界上最伟大的软件公司…..（没有之一）。尤其是在测试方面，微软的投资比其它任何公司都多，在软件测试理论和实践上绝对是首屈一指的领先者。微软就像一个健壮的中年人，而 google 像一个 20 岁的青年，非死book 可能只是 teenager。 但是 google,非死book 这些公司起源于互联网应用服务，在互联网应用服务质量管理方面的确有很多出色的实践。所以下一次和大家探讨：提高软件质量实践――Google 篇。</p>    <div id="come_from">    来自:     <a id="link_source2" href="/misc/goto?guid=4958340536840225186" target="_blank">blogs.msdn.com</a>    </div>