51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 548|回复: 0
打印 上一主题 下一主题

[原创] 工作量评估的差异之实践之路(04)

[复制链接]
  • TA的每日心情
    无聊
    前天 09:05
  • 签到天数: 1050 天

    连续签到: 1 天

    [LV.10]测试总司令

    跳转到指定楼层
    1#
    发表于 2023-3-22 11:38:55 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
    1.4工作量评估的差异
      “凡事预则立,不预则废”。在项目立项前,对研发各专业方向工作量的评估便是“预”,工作量评估的准确性对“立”有重要影响。企业通过立项方式管理产品的研发过程是一种投资行为,研发人力成本(与工作量对应)通常是其中最大的一笔投入。如果对研发各专业方向评估的工作量太大,那么项目不一定立项成功;如果评估的工作量太小,那么产品可能不会按期交付,继而影响产品上市销售时间。可以看出,项目立项前的工作量评估是一项重要活动,我们需要综合多方面因素对工作量进行评估。
      Sherry所在企业研发的产品首次上市时必须提供中文和英语两种语言功能。在产品上市以后,根据市场需求,该企业还会陆续推出包含其他语言(如法语、德语等)功能的产品,以满足全球用户的需求。
      产品本地化是在现有产品的基础上实施的,属于工程改进性项目。以软件为例,一般情况下,软件在设计之初已考虑了国际化需求。对于具备多语言功能的软件产品,我们在测试时需要先进行沟通与模板制作工作,再设计测试方案和测试用例
      关于软件产品多语言功能的测试,Sherry讲的一个故事让作者印象深刻。某天,Sherry所在公司的软件总监J(下称总监J)找到她,并询问了多语言功能测试相关的问题。
      总监J:目前,你们测试一种产品的某一种语言功能需要多长时间?
      Sherry:以一个含4000条字符串的中等规模的产品为例,测试工作量多则5人天,少则3人天,平均为3~4人天。
      总监J在听取某个新部门的测试人员的汇报时,得到的答案是1人月。他觉得两个部门存在这么大的差异,有些不可思议,于是询问Sherry是如何开展相关工作的。
      Sherry:通过实践,我们已摸索出规范的流程和方法,同时开发出了相关工具,才确保实现了这个效率的提升。
      总监J:包括哪些流程、方法和工具呢?
      Sherry:流程与多语言项目的运营有关。就我们公司而言,多语言的翻译由专业翻译组或专业翻译公司完成。翻译的结果由软件读取并显示在界面上,翻译的结果和质量对软件测试的工作量有重要影响。例如,对于某个术语,其俄语字符比英语字符宽,翻译返回的俄语结果显示在界面上时,可能出现超长问题。这样,我们需要多次沟通和修改,才能让该术语对应的俄语字符满足软件界面的显示要求。那么,在第一次将中文字符串发给第三方翻译公司前,我们是否可估算出字符串在界面上能够完整显示的宽度呢?可以。于是,我们开发了一款小工具,该工具可以方便地获取软件的界面、对话框、提示框和按钮等控件资源显示的长度,并把此长度作为翻译结果的最大长度(maxlen)进行约束。关于外发翻译的对象、翻译的质量要求和相关费用等,我们与翻译组或翻译公司开会讨论。在了解了翻译组或翻译公司的工作流程后,我们共同设计了一个“字符串翻译承载模板”,见表1-4(最大长度要素便体现在其中)。在流程规范中,模板是一种常见的解决问题的标准化方法,是工程化的一种体现。按照流程规范做正确的事,可避免我们工作无序时的返工。在采用了此模板后,后续翻译返回的字符串超长的问题大幅减少。例如,原来3000个字符串中就存在300多个字符串在界面中显示超长的问题,比例大于10%,而现在我们可以控制在1%左右。这种接口流程、交付方法的变化大大提升了后面测试验证的效率。

    表1-4  字符串翻译承载模板

      总监J:这是一种比较好的从源头控制字符串超长的好方法。在面对翻译字符串超长的情况时,你们是否也需要调整软件的界面,使之适应不同语言的字符串,以达到完整显示的目的?
      Sherry:在面对这种情况时,我们遵守一个原则,即对于多语言的界面显示,尽量不调整界面。对软件的改动尽量小或不对软件进行改动,因为软件的设计是同一套代码,共享同一套界面布局,如果为了适应某种语言而调整界面的宽度,那么在显示其他语言时可能带来问题。
      总监J:明白了。在字符串翻译回来后,你们如何开展后续工作?
      Sherry:我们会按照规范的测试流程进行相关工作。在领取任务时,我们需要进行测试方案的设计,即启动多语言测试方案和测试用例的设计。我们的团队经历了多个产品的多语言测试工作,积累了不少经验,形成了可复用的平台性测试方案。同时,我们总结了不同语言的本地化习惯和基于我们的软件的设计特点而需要关注的特性,获得了一套稳定、可复用的测试用例。当开发的新产品需要增加多语言功能时,测试人员无须从头开始分析和设计多语言相关的测试用例,只需将从公共测试用例库中筛选出的测试用例放到新产品上执行即可。
      总监J:这套流程及方法很实用,能够提升整个团队的工作效率。你们可否将这些经验和做法分享给新部门的测试人员?他们那边有个刚上市的新产品,该产品亟需支持多语言,现在的主要瓶颈在测试方面。
      Sherry站在公司发展的角度,答应向新部门的同事提供帮助。
      点评
      从上述总监J与Sherry的对话中,读者得到了哪些启发?或许,Sherry所在团队的有些做法值得读者学习。多语言测试工作需要测试人员细心、耐心,又需要多种技巧、方法和工具,在工程实践中,还有很多值得我们挖掘的地方。
      多语言测试涉及软件的国际化设计、国际化测试,关于它们的详细讲解,读者可参考崔启亮和胡一鸣编写的《国际化软件测试》。

    分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
    收藏收藏
    回复

    使用道具 举报

    本版积分规则

    关闭

    站长推荐上一条 /1 下一条

    小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

    GMT+8, 2024-11-23 07:11 , Processed in 0.067118 second(s), 24 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

    快速回复 返回顶部 返回列表