软件质量控制实践 - Microsoft 篇 (1)

     <p> 因为工作在微软的缘故，无论我在给国内企业做软件测试内训的时候，还是在质量技术大会上做演讲的时候，问的最多的一个问题就是：微软如何做测试的？前几天看见有人在新浪微博上讨论是否需要专职 QA，再有我刚刚决定带领两个 google 在西雅图的测试工程师一起翻译 google 的新书《how google tests software》。微软以前也有一本书《how we test software at microsoft》。所以几件事情碰到一起，有感而发，决定写一个“xx 公司如何测试的”系列文章。目的不是为了回答以上问题，旨在通过分析对比如 Microsoft,Google, Amazon, 非死book 等在保证产品质量的诸多具体实践， 和大家分享一下我个人认为这些公司在保证软件质量中的最为关键的几个实践和经验。希望大家有所收获和思考。我们今天先谈谈微软在提高软件质量上有哪些值得学习和借鉴的经验：</p>    <p> <strong> 1. Evolving test role</strong></p>    <p> 微软的正式测试工程师可以追溯到 1990 年左右，以后以每年大概 500 人递增。现在大概有 1 万左右的测试工程师。回顾走过的 20 多年，其中最为明显的特征就是微软对软件测试和质量控制的认识不是一成不变的，而是随着经验的积累，产品的演变不断演变，同时测试工程师的职责也不断在演变。最开始叫 software test engineer (STE)，主要职责是设计测试用例，手工黑盒测试。2000年左右演变成 Software Design Engineer in Test (SDET)，主要职责是设计测试用例，开发测试自动化代码，测试基础设施和测试工具。同时把繁琐的简单的手工测试外包给印度和中国的外包公司。2005 年以前公司的测试文化基本上是：产品质量是测试人员的责任，测试人员保证产品质量，测试人员很多时候像给开发打下手为开发服务。2005年后随着敏捷和软件及服务的出现，测试的角色逐渐从依赖测试来提高产品质量转变成用测试来建立保证产品质量的具体要素。测试不再像给开发打下手，而是转变成一个独立的岗位为产品质量服务。2010后，随着软件即服务和云计算的日趋成熟，微软很多产品组转向开发服务型的产品，同时测试人员的角色为了适应新的挑战而继续演变，比如现在很多组开发也做测试，测试也做开发，两者间的界限越来越模糊。正是测试的这种灵活性和对不同时期不同产品的适应性使得每个发布产品的质量得以有效保证。</p>    <p> <strong>2. Set full-time test role</strong></p>    <p> 微软的产品一直以桌面产品为主，比如 Windows, Office, SQL server, etc…。这些类型的产品的共同特点就是对发布版本的质量要求非常非常高，它要求产品在发布之前必须修复几乎所有的 bug，至少不可以有关键性 bug。因为万一漏掉一个关键性的 bug，召回产品或发布热修复的代价太大。所以每个产品组在产品开发过程中投入大量的测试人员来全方位，反反复复测试， 包括功能测试，性能压力测试，本地化国际化测试，安全性测试，使用性和兼容性测试，等等。这些大量繁重的工作不可能都有 dev 来做。有了专职的测试人员不仅大大减轻了开发人员的工作量，而且通过测试人员特有的、经过专门训练的技能可以在产品发布之前找出更多、更为关键的 bug。所以在这种情况下，专职测试人员不仅是有用的而且是必须的，他们对提高软件质量起到至关重要的作用。在像 windows 和 office 这两个最大的产品组，专职测试人员的数量和开发一样多，再加上大量外包公司的测试人员，可以说测试人员的数量实际上是开发的将近两倍。但是，如前所述，随着从桌面产品逐渐转向服务型的产品（软件即服务），专职测试人员的作用在逐渐下降。主要原因是：首先产品质量不再是光光通过“测试”来提高了；其次对发布版本质量要求有所降低，因为服务型产品不是安装在用户机器上而是部署在微软自己的数据中心里，如果有 bug，开发人员可以很快修复然后及时更新产品（而不是像桌面产品需要召回），所以热修复的成本大大降低了；还有就是利用用户来做测试（我们在下面会具体再谈）。所以在服务型产品中，专职测试人员的作用不再像以前那样显得至关重要。微软现在许多组在削减测试，或者转成 dev，即使保留测试的头衔，做的工作也不是严格意义上的测试了。另外一点值得说明的是，虽然专职测试人员数量有所减少，但是并不意味着测试的覆盖率就一定减少了。很多时候实际上是测试的覆盖率更多了，这主要是因为开发做越来越多的测试，同时测试的效率提高。</p>    <p> <strong>3. Heavily invest in test automation</strong></p>    <p> 测试自动化不是万能的，但是没有测试自动化是万万不能的。测试自动化可以把测试人员从枯燥重复的手工测试中解脱出来做更多更有有技术含量的工作。当然测试自动化需要前期投入，而且不稳定的测试自动化还会把测试人员拽到疲于维护的泥潭中。但是这不是否定测试自动化的理由。没有用好测试自动化并不代表它没有用。而且，敏捷测试，持续集成，快速交付，等等都是以测试自动化为基础的。公司可以根据具体情况采用逐步提高的策略，比如先自动化每日构建，再自动化部署，然后自动化最关键的测试用例，次关键的测试用例，等等。微软测试工程师有超过 80％的时间是在写测试代码。它们包括测试自动化代码，开发基础设施代码以及开发测试工具。默认情况下自动化所有测试用例，除非你有合理的理由不自动化。我个人的准则是：如果手工重复运行一个过程超过 3 次，就是时候自动化了。通常在一个发布周期的计划阶段，PM,dev，test,根据本次发布的时间长短和内容各自做计划，然后汇总讨论，制定一个最终的符合各个角色的发布计划。Pm 和 dev 决定本次发布中的产品新功能，测试决定本次发布中的测试有关的工作量，比如为新功能而添加的测试自动化，为修改现有功能而修改测试，需要开发或改进的测试工具或基础设施。经过讨论后大家一致同意最终计划。计划好后，大家就根据各自的计划并行工作，当然中间大家及时沟通进度，如果需要，调整计划。这个过程的好处是把与测试自动相关的所有工作都放到开始项目计划中来，包括新功能测试自动化，现有代码的维护，工具的创建和改进等等，这不仅逐步提高测试自动化覆盖率，而且使得基础设施和测试工具逐渐成熟和完善。成熟和完善的设施和工具同时极大提供了开发效率和速度，比如大部分产品组都有 daily execution 和 checkin quality gate：</p>    <p> × Daily execution: 每天晚上，自动生成每日构建，自动部署到测试环境，自动运行测试用例。对于失败的测试用例，系统自动报 bug,并且对测试日志和产品日志进行自动分析，把相关信息放到 bug 中。最后自动发送测试结果到整个组。第二天早上到办公室，每个人都会看到已经运行完的测试报告。这使得测试可以有更多的时间自动化更多的用例，更多的时间分析测试缺口或做探索性测试。</p>    <p> × Checkin quality gate: 开发在提交代码之前通过运行一个简单命令可以把相关测试自动运行一遍。这使得开发从一开始就提交高质量的代码。</p>    <p> 即使在做手工或探索性测试，测试工程师也尽可能使用测试工具来自动化其中步骤，从而使得测试人员完全专注于应该专注的地方，比如思考探索尝试，而不是在别的地方浪费时间，比如准备测试数据，搭建测试环境，分析日志，报 bug 等等。 打个简单的比喻，比如你要从北京到上海开会，手工测试就好像你骑自行车过去，你的目的是开会但是你结果把大量时间浪费在路上了。测试自动化就好像你乘飞机过去。还有看起来来好像飞机票很贵，成本比骑自行车要大，但实际上最后骑自行车的成本要高的很多。只不过很多成本你当时看不到罢了。</p>    <p> 所以很多我给做培训的公司的经理抱怨说我们也想做单元测试，做测试自动化，但是就是成本负担不起。我就说你只看到“做”的成本，因为它很直接；而看不到“不做”的成本，因为你不能马上看到。业界无数公司，项目已经证明在单元测试和测试自动化在提高软件质量方面“不做”的成本要比“做”的成本大的多得多。</p>    <div id="come_from">     来自:     <a id="link_source2" href="/misc/goto?guid=4958338572377054655" target="_blank">blogs.msdn.com</a>    </div>