软件质量控制实践――Microsoft 篇 (2)
- 4. Drive quality upstream
我们都知道bug越是滞后发现，修复的成本越高。据微软统计，如果产品发布以后需要发布一个热修复，它的直接成本是150万美元（间接成本在200万美元），而在发布之前的一个月发现的话，修复成本是5万，设计阶段修复成本是1千，需求阶段修复成本是1百。在需求分析阶段，测试人员主要职责就是验证需求分析的可行性和可靠性。PM和DEV的共性是易于乐观，倾向于把实际情况简单化，所以会作出很多假设。比如用户肯定不会这么使用，用户肯定知道如何用，所有用户的环境肯定都有该配置。但是实际情况下总会有用户不知道如何用，总会有用户会不按“预先设计”的方式使用，总会有用户环境没有该项配置。所以测试人员的主要职责就是找出这些假设并提出疑问并加以验证。
在dev设计阶段，测试人员需要验证设计，同样找出dev的假设然后疑问这些假设是否合理，看看该设计是否处理很多没有预料的但是有可能会发生的情况，比如用户输入特殊字符，非常规操作，非常规流程，机器重启，死机，数据库连接中断，网络中断，内存耗尽等等。除了验证设计是否处理非正常情况外，测试人员的另外一个更为重要的职责是验证设计的可测试性。可测试性是指测试软件容易的程度。软件的可测性对于提高软件的质量至关重要。道理很简单，如果你的软件很难测试，无从下手，测试一个用例需要几个小时甚至几天的话，你的软件质量也就无从保证。提高软件可测试性通常的做法是把软件模块化，松耦合，模块内部运行状态可见，模块内部运行分支可控制。在评审一个设计时通常问的问题是该如何测试该模块，是否容易测试它，能不能单独测试它。如果不可以的话，需要重新考虑设计。因为一个设计的很容易测试的模块和产品可以使得后期的测试代价大大降低。微软大部分复杂系统都会有一个“one-box”版本，该版本是个假的模拟系统但是拥有真正系统的几乎所有功能，它可以运行在任何机器上。系统的绝大部分功能都可以在该模拟系统上快速方便验证。我在培训的时候很多学生问，他们在后期测试的时候遇到许多无法测试或者很难测试的困境，问我该如何解决。在具体了解困难和困境之后，我发现他们的测试策略非常单调，只能把产品部署到有限的测试环境下从用户界面上做端到端的测试。如果想测试某个特定模块或功能需要好几个其它模块配合起来才可以。我就坦率的说如果你的软件是这么架构设计的话而且已经到了这一步，世界上没有人可以解决你现在面临的困难。因为看起来好像你是卡在现在这一步了，但实际上根本问题是在前期，在需求或设计。就像解决河流的水质污染问题，你在下游无论多大的代价也只能稍微改善，解决问题的根本方法是在解决上游的污染源。或者像隔靴挠痒，隔着厚厚的靴子无法挠到关键地方，必须能够把靴子脱掉直接挠。
5. Getting better every day
软件测试的目的一个是找出bug,另外一个是衡量软件的质量。通过测试来了解产品哪些地方薄弱，哪些地方不稳定. 通过监控测试的结果，包括功能测试，性能压力测试，安全测试，本地化测试，容错测试等等来反映当前软件的质量。这也是持续集成的一个重要原因，它一方面短期迭代，另一方面可以在最短的时间内知道软件的质量，同时跟踪软件质量重开始到发布，软件质量的变化曲线。衡量软件质量的通常指标有：测试用例通过率/趋势，bug数量，种类/趋势，代码覆盖率等等。另外测试在开发周期中通常做的其它工作还有：bug root cause analysis, Bug analysis, Test case failure analysis, test gap analysis, Bug talk, bug share, CCS data analysis等等。这一方面促使产品质量逐渐变好，而且是看得见的好。另外也促使自己放下繁忙的工作静心思考一下，如何更有效率更进一步提高质量。
6. Engineering agility
随着软件即服务和云计算的兴起，它们给开发管理，质量管理，运营管理等提出了很多新的挑战。以前那种保密开发测试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.
最后一篇将和大家讨论一下测试工程师的技能提高和职业发展， to be continued .....
----------------------------------------
关注我：新浪微博：@billliu_seattle https://www.weibo.com/windowsazure 或twitter: @billliu_seattle
Comments
- Anonymous
May 07, 2012
The comment has been removed - Anonymous
May 07, 2012
由于微软产品的特殊性，微软是否几乎不存在有第三方需求驱动的测试和开发？