13.4 从微软裁员首裁软件测试工程师谈起
微软宣布裁员18000人
腾讯科技[微博]瑞雪2014年07月17日20:23
腾讯科技讯7月17日，微软周四宣布，该公司计划在今年裁减最多1.8万名员工，这将创下微软公司历史上最大的裁员规模，原因是其正在消化收购诺基亚手机业务的交易，并调整自身定位以适应未来发展。
……
纳德拉在上周拒绝透露公司是否会进行裁员，仅表示在7月22日发布第四财季财报时，他将会透露更多的信息。不过消息人士透露，微软此次还将会在软件测试员当中进行裁员。
……
2014年夏天爆出一条新闻，微软公司新CEO上任后开始第二次大规模的裁员，这次裁员对象首先是并购过来的诺基亚员工，然后是软件测试工程师。这条新闻在微信群里得到一位微软员工的证实，然后引发了一场争论。
一部分朋友认为需求变化快，用户众多，社会压力要求版本发布快。这样，如果采用正规专业的软件测试，只会延长产品开发周期，不利于企业成长。软件测试应该由自动化测试和用户测试来代替，或者企业软件测试采用外包形式。甚至有人认为，只会点点鼠标的软件测试工程师早就应该被社会淘汰了。
另一部分朋友认为，让用户进行软件测试简直就是对质量不负责任的表现，用户使用Bug很多的软件只会加速企业的灭亡。特别是关系到生命安全的软件，如航空、航天、医疗设备、车辆安全控制等软件，甚至无法保证人的生命安全。
到底孰对孰错呢？其实都对，也都不对。为什么这样说，因为大家只考虑了问题的表面，而没有考虑企业产品及使用产品的客户类型。
对于互联网行业来说，用户众多，需求不明确，许多产品只有快速推到市场上，让用户尽早使用产品，提出建议，这些建议才是真正的用户需求，从而避免开发出不是用户需要的软件产品。对于这些产品，在产品首推市场前可以弱化软件测试，但是对于易用性，或者说用户体验性测试还是要重视的，否则用户用了一次就不用了。如果这种企业采用传统的方法，企业会失去更多用户，从而造成企业的破产（据说微软要走互联网行业模式）。
而对于传统软件行业，尤其是航空、航天、通信、医疗等关系到人身安全的，关系到国家基础设施的软件企业，这些软件产品中的核心组件必须由专业的软件测试工程师独立完成，而且必须由专门的质量部门把控。如果这种企业采用互联网企业方式，甚至让用户进行软件测试，肯定会造成致命性的毁灭。
现在业界大谈敏捷，甚至某些公司滥用敏捷，认为敏捷就是快速。快速开发法、火车模型、测试用例无用论等观点也越来越兴起，不少企业不管这种方法是不是适合自己，一窝蜂地上敏捷，一窝蜂地采用快速法，认为上了敏捷就可以提高自己的生产力，提升质量。其实，瀑布模型、迭代模型、RUP、敏捷方法等本身都是好东西，但要看适不适合贵公司以及使用贵公司产品的客户类型，甚至可以跟随自身产品对模型本身进行裁剪。比如，航空航天软件的开发生命周期都很长，一年甚至很多年才可发布一个版本。对于，这类产品需求也很明确，客户也很单一，所以无需进行不断的迭代。他们有自己独立的软件测试团队，甚至经过自己软件测试团队进行测试完毕后，还要通过有资质的第三方软件测试公司（如中国航天科技集团公司软件评测中心）进行再测试。可想而知，如果的软件产品采用敏捷，或者采用快速开发法是绝对不可行的。
所以，采用何种软件工程、软件测试方法，这是根据自身软件产品及客户群来决定的，千万不可随波逐流，否则只会自取灭亡。
在这里再强调5点。
（1）自动化测试永远不可能代替手工测试。不管对于互联网企业，还是传统企业，对于某些产品，自动化测试重要且不可少，而对于另一些产品，需求总在变化，或者全是各个不同企业定制的，没有通用功能的，是否采用自动化测试要做好经济成本预算。而对于自动化测试程度比较高的产品，完成后也要进行一段时间的手工软件测试，如探索式软件测试，经过这些测试会发现一些意想不到的Bug，包括微软在内也应该保留一些探索式软件测试工程师。并且，对于基本上确定需求的功能，出厂前可以使用自动化测试工具进行比较严格的、全面的回归测试，任何一个人都不会愿意使用经常出错或者Bug满天飞的产品的。
（2）基本需求比较确定的功能可由自动化测试工具来实现，其他的还是需要一定的基于经验的软件测试方法来解决。比如，探索式软件测试、缺陷攻击法。这些对软件测试工程师的水平要求也高了，即使是点点鼠标的操作，也应该学会如何去点、点何处、按照何种步骤去点。所以，丰富的软件测试经验、对业务的了解、熟悉产品如何实现、系统运行环境如何、数据库知识和操作系统知识等都是软件测试工程师应该需要具备的。
（3）不管形式如何变，互联网企业与传统软件企业必将共同存在。专业独立的软件测试工程师不会消失，特别是在传统软件企业，年轻的朋友，如果喜欢软件测试，欢迎加入。据权威机构研究，专业的软件测试职位不会消失，而且缺口还很大，不要畏惧，不要犹豫，软件测试工程师是社会所需要的人才。
（4）基于风险的软件测试分析方法在这种情况下非常有效。不管在互联网企业，还是传统软件企业，对测试用例做好基于风险的优先级分析，优先测试风险级别高的测试用例。对Bug修改也做好基于风险的优先级分析，优先解决优先级高的那些Bug，对于优先级低的Bug，可以在出厂后解决或者不解决，从而避免过度软件测试或过少软件测试。
（5）企业在实施过程中要不断对过程进行调整，但千万不可照搬某一方法。戴明博士提到的PDCA就是个很好的方法。
13.5 软件测试的本质
13.5.1 纯软件测试方法介绍
武术的本质是"攻"与"防"，那么软件测试的本质是什么？笔者认为也是两个字"测"和"试"。所谓"测"，就是针对软件文档，对软件产品进行检测，找出其缺陷，也就是通常所说的Bug，供开发工程师修改的一系列工作；所谓"试"，就是在用户使用的软件环境（包括操作系统、数据库系统及应用软件系统等）、硬件网络环境（包括CPU、内存、硬盘空间、网卡和网络带宽等）和其他特殊情况（包括高并发、高容量）的环境下，尝试软件是否可以正常运行的工作。
为了解决让软件研发人员头疼的软件危机问题，出现了各种软件工程模型：比如本书中"软件工程模型"所提及的瀑布模型、迭代模型等，根据这些软件工程模型又建立了各种软件测试模型（本书中"软件测试模型"所提及的V模型、X模型、H模型），以至于现在很流行的敏捷开发与测试模型。但是这些模型的建立，并没有从本质上解决软件危机的现象。据2014年统计，美国仅有5%的软件项目是按照计划发布的。因此，业界流行一种说法："一个软件产品能否交付，主要看软件支持工程师能否说服用户接受带有缺陷的产品，这就是所谓的灰色发布"，显然，这是很不严谨的。
众所周知，软件测试是保证软件产品质量的一个重要环节。因此，要把软件测试做好，就应该抓住软件测试的本质"测"和"试"。抛弃各种模型中的"套路"，不要把过多的时间花在书写软件测试文档和软件测试代码上，而是要集中精力，多把时间花在"测"和"试"上。整个"测"和"试"的过程要贯穿软件生命周期的各个阶段，这个过程从软件需求阶段就开始，一直贯穿概要设计、详细设计和代码，直到最后软件形成后再一版接一版地测试。
这里，笔者不是反对书写软件测试文档和软件测试代码。而是强调不要过度地书写软件测试文档和软件测试代码，必要的软件测试文档和软件测试代码也是必须的。比如，没有软件测试计划，那整个软件测试管理就要失控；比如不书写软件测试代码，那么许多软件测试，特别是回归测试和性能测试就不能有效地进行。但是用在文档和代码上的时间过多，就得不偿失了。在这里举个例子：一个人设计书写一个功能测试用例起码需要花费20分钟的时间，那么书写1000个功能测试用例就要花费20000分钟（约334小时），把这1000个功能测试用例的四分之一转化成功能测试代码就要花费约334/4×2.5=208小时（按照书写一个功能测试代码需要2.5倍的功能测试用例的时间计算），加上书写功能测试用例花费的334个小时，总共需要花费542小时。按照每人每天工作8小时计算，也就是需要67个工作日。事实上，一个项目中一个软件测试设计工程师需要书写的测试用例一般都有上千甚至上万个，这样估算下来，如果把时间都花在书写功能测试用例和书写功能测试脚本的时间上，读者可以算一下这样下来大概需要花费几个月甚至几年的时间了，这个项目也就过了交工期限了，也就没有时间搞软件测试了。
抓住软件测试的实质"测"和"试"，把主要时间和精力花在"测"和"试"二字上，软件产品的质量才能得到保证。我把这种软件测试方法叫作"纯软件测试方法"，这也正是软件测试的本质。
13.5.2 纯软件测试方法在Sprint中的运用
下面来讨论在一个Sprint中如何运用软件测试的本质"测"与"试"来进行测试工作。假设一个Sprint为1个月，即22个工作日，把这22个工作日分成前、中、后3部分。前（第1个工作日到第7个工作日），中（第7个工作日到第14个工作日），后（第15个工作日到第22个工作日）。
在Sprint前期测试人员的主要工作为书写这个Sprint 新功能的测试用例，这些测试用例可以是自动化，也可以是手工的，并且在这些测试用例中，以证"真"的"测"的方法为主，证"伪"的"试"的方法为辅。在这里测试用例没有具体的格式，目的只要可以给相应的开发人员看懂就行，关键需要关注的是对新特性的覆盖度。从第二个工作日开始，在每日站会后，测试人员把他们前一天写的测试用例交给相应的开发人员，与他们进行一对一的评审，由于测试用例是每日提交的，所以评审的时间不会很长。一旦通过评审后，这个测试用例就交给开发人员了。开发人员在开发期间需要100%达到这些测试用例所希望的结果，并且根据开发人员的自身需求，在适当的时候执行测试用例。
在Sprint中期，测试人员主要工作专向基于经验的探索式测试和非功能性测试，在这个阶段，主要运用证"伪"的试的方法。而开发人员的主要责任在重新运行一遍交给自己的测试用例，以及对缺陷的修改。
在Sprint后期，开发人员协助测试人员一起完成回归测试，开发人员按照以前的测试用例执行测试，测试人员仍旧以探索式方式来测试，以保证整个Sprint结束是一个高质量可交付的产品。一旦发现缺陷，开发人员优先回去修改缺陷。
13.5.3 纯软件测试方法与软件质量的关系
谈起软件质量，肯定就会想到ISO 225000标准（参见第一篇第1.1.9节），软件质量可以分为功能性、可靠性、易用性、效率、信息安全、相容性、维护性与可移植性8个方面。
功能测试是指测试软件所具有的功能，软件的功能一般都会通过《需求规格说明书》或《用户故事》来说明，所以功能测试主要是验证软件是否满足用户提及的功能需求，属于验证，证"真"，所以功能测试为"测"的范畴。
可靠性测试主要试验软件在错误情况下的应变能力，比如断网，断电后的恢复能力，对非法输入的处理能力等。所以可靠性测试属于证"伪"，所以为"试"的范畴。
易用性测试主要检查软件是否好用，易用，易用性一般没有真正的需求，而且某些易用性与人的性格有关。但易用性测试主要检查软件是否存在大多数用户不容易使用的部分，比如重要功能需要点击3次鼠标才可以方现。所以易用性测试为"试"的范畴。
效率即为性能，在有些需求中有相应的性能需求，比如在大多数并发条件下，首页必须在二秒内显示完毕，二、三级页面在5秒内显示完毕，叶子页面在7秒内显示完毕，这种性能测试为"测"的范畴。而大部分测试需要找到最大负载点，最大数据饱合量，最大吞吐量，对于这样的性能测试则为"试"的范畴。
信息安全测试可以属于"测"的范畴，也可以属于"试"的范畴。对于安全测试，需要检验系统是否安全或者系统是否存在安全漏洞。前者属于"测"，后者属于"试"。
是否具有相容性，比如Web程序对浏览器的兼容性测试，需要去尝试才能得到答案，所以相容性测试为"试"的范畴。
软件是否具有可维护性测试，也需要去尝试，比如需要把原来系统上增加新的功能，就要去尝试是否可以升级？同样可测试性也需要通过尝试的行动来确定是否具备。所以可维护性测试也为"试"的范畴。
同样，可移植性测试与可维护性测试相同，比如需要把原来系统数据库平台从MySQL移植到Oracle，仍旧需要去尝试。所以可移植性测试还是"试"的范畴。
综上所述，功能性测试，部分性能测试与部分安全性测试属于"测"的范畴。稳定性测试、部分性能测试、部分安全性测试、易用性测试、相容性测试、可移植性测试与可维护性测试属于"试"的范畴。但是某些时候"测"与"试"也不是完全绝对的，上面介绍的只是在一般情况下。比如系统必须支持火狐浏览器下运行，可说："我们验证一下系统是否可否支持火狐浏览器。"而在大多数情况下是不可确定的，所以只能说："我们尝试一下系统可否可以支持火狐浏览器。"
版权声明：51Testing软件测试网获人民邮电出版社和作者授权连载本书部分章节。任何个人或单位未获得明确的书面许可，不得对本文内容复制、转载或进行镜像，否则将追究法律责任。
相关推荐：
