专业测试团队会消亡还是新生
文/朱少民敏捷软件开发致使很多人质疑专业测试团队存在的价值,本文对此进行了深度的剖析,并结合技术发展现状给出了软件测试的未来方向。敏捷软件开发带来的困惑敏捷软件开发强调“拥抱变化”, 认为不能将需求定义一次做到位,也没必要一次做到位,需要不断挖掘,才能逐渐获得真实的需求。这就给测试带来极大的挑战,因为测试需要把验证的标准作为参 照系,否则如果需求不清楚,就很难确定测试中发现的问题是不...
·
文/朱少民 敏捷软件开发致使很多人质疑专业测试团队存在的价值,本文对此进行了深度的剖析,并结合技术发展现状给出了软件测试的未来方向。
敏捷软件开发带来的困惑 敏捷软件开发强调“拥抱变化”, 认为不能将需求定义一次做到位,也没必要一次做到位,需要不断挖掘,才能逐渐获得真实的需求。这就给测试带来极大的挑战,因为测试需要把验证的标准作为参 照系,否则如果需求不清楚,就很难确定测试中发现的问题是不是真正的缺陷,导致测试的设计与执行困难重重。在这种情况下,我们是否只能依赖探索式测试呢?
敏捷软件开发强调持续构建、持续测试。在构建中不仅可以完成单元测试,还可以完成集成测试。因为每天都构建软件包,一旦单元之间(接口)存在问题,就很容易 暴露出来。每日构建和集成可被看作持续测试的一种体现。在这种情况下,是否就无需单独的集成测试阶段?测试的投入是否就可以减少呢? 敏捷软件开发强调与用户的沟通和协作,用户起初并不清楚自己的需求,通过软件产品的使用,才逐步明白自己想要什么。如果用户真能参与开发过程,即用户每天都能及 时使用正在开发的软件,那么还需要测试人员吗?如果将持续集成和用户及时反馈结合起来,专业测试人员的测试投入是不是就可以大大降低? 敏捷软件开发强调持续交付,即及时发布有价值功能给客户,并尽快地满足客户的需求。之所以能做到持续交付,是因为软件已从产品销售模式转为服务模式—软件即服 务(Software as a Service,SaaS),不存在以前产品模式的销售渠道,软件版本的更新只要在自己数据中心的服务器上打个patch就可以了。这种SaaS模式使得 持续交付成为可能,软件能够快速上线、用户也能及时获得更新的服务,因此缺陷能被快速修复,缺陷修复的成本极大降低,大大提高了人们对缺陷的容忍度,降低 了对质量的要求。但这可以大大降低测试的投入吗? 特别是像Facebook这样耀眼的公司,其实践似乎在支持“无需建立独立的测试团队”, 让开发人员来承担越来越多的测试工作,甚至承担全部测试工作。还有人提议将测试团队的一半成员拿出来做开发,这样可以解决以前单元测试不足的问题。而测试 团队的另一半被抽调到客户服务(Customer Care)团队中,负责需求前期调查和后期技术支持,在需求上加大投入,帮助建立软件产品的客户验收标准,让开发人员基于验收标准完成软件系统的设计和编 程,从源头上提高质量,而且后期技术支持也得到了加强。
专业测试团队要不要? 一系列新的实践似乎在加剧质疑“专业测试团队的存在意义”。但在传统软件测试理念中,则强调测试的独立性和专业性,专业性越强,越需要全职人员。这些实践在 传统产业的质管理实践中已得到充分的验证。传统产业的质检部门是独立的,质检人员也是全职的。如果不管三七二十一,将测试团队拆分掉,会不会带来新的问题?比如:
- 究竟要不要专业的测试团队?
- 软件测试由谁来做更有效?
- 专业的测试团队未来的路会是怎样?
[/caption] 基本上,大家已达成共识:单元测试、集成测试一般由开发人员做效率更高些,而系统测试和验收测试由测试人员做比较好。为什么会有这样的共识呢? 如果开发人员先实现再测试,其测试的思路一定会受到实现的影响,不能达到良好的测试效果。如果先设计测试再实现产品,即采用TDD开发软件,让测试在先而不 受实现的影响,效果会不错。但问题是有多少开发团队能够真正做到TDD?而且TDD对需求有更高的要求,软件产品质量的验收标准事先需要被明确定义,然后 才能做到先开发测试脚本,后开发产品代码。而现实的需求又很难做到这点。 软件质量就是客户满意度。从这个角度看,测试工作更重要的任务是要 在系统层面验证是否能够全面满足业务需求、是否真正满足不同用户的实际需求。而这样的测试必须要等到系统建立起来之后才能进行,如果这时让开发人员来做测 试,必然会受到之前实现思维惯性的影响,效果明显降低。其次,每个开发人员通常只完成系统的很小一部分,对整体业务无法有效地把握,而且业务场景太多、繁 杂,这时很考察测试人员的专业能力。只有站得高、看得远,完成业务端到端的测试,覆盖各种业务场景,才能确保系统能够正确、有效地实现整个业务流程。 如果开发人员知道某些地方很有可能存在缺陷,那么就会设法避免这些缺陷的产生。但往往开发人员并不知道自己会犯哪些错误。而如果让专业的测试人员从不同的角度、不同的思路来测试软件,测试的效果会有效得多。 更何况测试本身具有很强的专业性,包括测试建模技术、测试方法及其工具的应用,只有专业的测试人员才能很好掌握。 举一个例子,仅仅是黑盒测试方法中一项具体的测试技术—因果分析法(cause-effect analysis),美国测试专家Richard Bender差不多用其一生的时间来研究它,才将这项技术做到极致。除系统的功能测试外,做好系统的性能测试、安全性测试等就更不容易,而且随着软件技术 和应用的不断发展会不断引发新的测试问题。因此,可以说这种专业的实践和积累将是一项长期的任务。 互联网的多数应用(如新浪微博、 Facebook、Google搜索)属于文化娱乐服务,受缺陷的影响非常有限。例如,新浪微博的Beta版能在线运行长达三年,但银行业务系统Beta 版在线运行一天都不可能。在金融、国防、航天、通信、交通控制乃至庞大的制造业生产控制等领域,无不要求零缺陷的软件产品,其独立的专业测试更是不可缺 少。最近几年,各大银行不仅建立了独立的测试团队,而且测试团队还保持30%以上的发展速度。如果考虑云计算、物联网等新技术的应用,软件系统的复杂性会 非线性增长,软件缺陷造成的负面影响也不能同日而语,那么在这些领域加强测试也是必然的,对专业的测试团队的需求不但不降低,反而会增强。
软件测试的未来 近几年,敏捷测试、探索式测试、精益测试、基于模型的测试等越来越受到大家的关注。《软件测试:经验与教训》一书的作者Bret Pettichord在2003年将软件测试归为四大学派(School),四年后(2007年)又增加了一个敏捷测试学派,将软件测试分为五个学派,如 图2所示。 [caption id="" align="aligncenter" width="377" caption="图2 软件测试五大流派示意图"]
[/caption]
- 分析学派(Analytic School):认为软件是逻辑性的,将测试看作计算机科学和数学的一部分,结构化测试、代码覆盖率就是其中一些典型的例子。他们认为测试工作是技术性很强的工作,侧重使用类似UML工具进行分析和建模。
- 标准学派(Standard School):从分析学派分支出来并得到IEEE的支持,把测试看作侧重劣质成本控制并具有可重复标准的、旨在衡量项目进度的一项工作,测试是对产品需求的确认,每个需求都需要得到验证。
- 质量学派(Quality School):软件质量需要规范,测试就是过程的质量控制、揭示项目质量风险的活动,确定开发人员是否遵守规范,测试人员扮演产品质量的守门员角色。
- 上下文驱动学派(Context-Driven School):认为软件是人创造的,测试所发现的每一个缺陷都和相关利益者(stakeholder)密切相关;认为测试是一种有技巧的心理活动;强调人的能动性和启发式测试思维。探索性测试就是其典型代表。
- 敏捷学派(Agile School):认为软件就是持续不断的对话,而测试就是验证开发工作是否完成,强调自动化测试。TDD是其典型代表。
更多推荐
已为社区贡献1642条内容
所有评论(0)