执行力的境界(上)

很多人讲到执行力时,就会联想到“让你做一就做好一”,在看《我的成功可以复制》这本书以前,我持有同样的想法。但是在读过此书之后,我对它有了新的认识。

workplace

《我的成功可以复制》由唐骏编写,此前他曾陷入轰动一时的“学历门”事件,且不论其学历真假与否,他在这本书中的叙述让我坚定一点,至少他在书中所述经历是真实的。有些道理非得亲身实践方可感悟。

他在书中叙述了一个这样一个经历。他当时发现 Windows 在多语言开发模式上存在错误,同时还注意到,当时微软已有多人提出此问题,甚至有不少人已向经理提交书面解决方案,后来据他侧面了解,这些方案多达 80 多份。在进入微软之前,他曾是一家公司的老板,因此他知道,老板通常会将只会提建议的人视为“挑刺的人”,对既能提出问题又能提出解决方案的人产生好感,但最让其信任的则是,除了做到这两点,还能对方案可行性进行论证的员工。正是因为他意识到了这一点,因此在他发现此问题后,他利用晚上和周末的时间来对他的开发模式进行实验论证,得到了完全可行的结果。后来在他向上司提交的报告中,不仅提出问题和解决方案,还提交了他自己编写的程序。事后,他的方案的确被微软所采用。他的上司这样评价他:你不是第一个提出问题的人,亦不是第一个提出解决方案的人,但你是第一个对解决方案提出论证方法的人。

从这个故事中可以看出,执行力意味着“除了做到一,你还可以做到二,甚至做到三”,你可以深入一点,多站在对方的角度上思考问题,如果我是他,他会愿意得到怎样的结果。当你向上司提出自己的疑问时,他或她希望听到的是选择句,而非疑问句。他没有多余的时间帮你想解决办法,但是他可以依据自己的经验对你所提出的问题进行判断,帮助你决定哪种方式更可行。所以我们在自己这一环节要多思考,用最精炼的语句将自己想要表达的内容告诉上司,而不是出现一点点问题就找他或她。

在翻译这个行业中,虽然我们需要跟上司直接交流的机会并不多。但是,执行力仍然无疑是我们必须具备的一项职业素质。(未完待续)

黑盒测试及其分类介绍(二)

商务

 

上次跟大家分享了黑盒测试中功能测试的几个重要的测试种类, 这次继续和大家来分享黑盒测试中性能测试的内容。

现在很多企业在开发一个产品的时候,首先会定义产品的功能、功能约束限制、性能指标和其他相关的需求内容;那么当一个产品开始进入测试阶段时,肯定是先要保证其所有的功能都能正常时限,然后再保证产品的性能指标;

性能测试主要分为性能测试、负载测试、强度测试、容量测试、配置测试、失败测试等等

性能测试主要是评估被测对象的响应时间和吞吐量;

负载测试主要是指被测对象在系统资源不足的情况下,发现被测对象问题;

容量测试主要是被测对象在大数据量下,发现程序可能出现的问题;

强度测试主要是指使被测对象在高负载下,可能出现的问题;

配置测试是指在配置被测对象系统的数据库或者一些硬件软件配置时可能出现的问题;

以上就是在黑盒测试中性能测试的主要测试类型,一般在中小型企业中可能只会进行像性能测试、负载测试、强度测试、容量测试这几种主要的性能测试种类,在大型企业测试流程较完善测试时间较充足的情况下,会增加如配置测试、失败测试、可靠性测试等更多关于性能测试的工作;

性能测试较功能测试来说还不是特别普及,主要因为现在很多的产品软件都属快餐型产品,客户要求产品快速成型,功能基本完善,性能测试就没有考虑,这样的产品软件确实能够很快的站住市场,抓住用户,但我认为盲目地追求眼前的利益而忽略了产品的性能,会使用户在后期体验中产生众多的问题。

论熟练掌握工具的必要性

农业

在我们这类本地化翻译公司里面,各种各样翻译工具的使用是一大特色。这些工具不仅能加快我们承接并处理客户项目的速度,也让我们能及时提交客户稿件,最终取得客户信任、市场认可。由此可见,熟练掌握各类工具的重要性可见一斑。

很多人会说,其实各种工具大同小异,熟练掌握了一种,其他的也容易了解并使用,这话没错,知晓某个工具的存在、了解基本使用最后熟练掌握是一个循序渐进的过程,我希望大家不要只是停留在知晓或者了解皮毛的阶段,而应主动出击,熟练掌握与运用。

若客户需要我们使用某个新工具进行翻译处理时,而我们不会,那我们肯定会丢失各位销售人员辛辛苦苦争取来的项目,这无疑对公司还是对我们译员而言都是巨大的损失。即使我们承接了下来,但我们只是知晓该工具或了解皮毛,我们只能依据其他类似工具的使用经验来慢慢进行处理,可想而知,处理速度实在令人担忧。倘若处理过程中还出现一些难以解决的问题,我们要一边学习该工具一边进行该项目的处理,我们不能全身心进行TEP的各项工作,那么该项目的交付件品质可想而知。

我很羡慕那些熟练掌握各种工具的同事,每每看到他们能顺利地承接各种项目,并熟练地开始各种项目的处理,然后及时地提交各类交付件,我都眼红不已。而我自己也切身感受过工具不熟练的痛苦,明明只有几个字就可截稿了,可是突然跳出一个问题,之前的努力宣告白费,那个时候我就痛恨自己为什么以前没有熟练掌握该工具。所以我提倡公司内部多多进行各项工具的培训,让每位译员不要因为工具不熟练而出现各种各样的问题。

有人可能会觉得自己大声说自己工具不熟练很丢脸,我不这样觉得,我认为不懂装懂更可悲、可怜。不会就是不会,承认不会之后好好学习,熟练掌握,这样比藏着缩着永远不会的要好得多。

让我们都行动起来,主动学习、熟练掌握我们工作过程中需要用到的各类工具,然后凭借这些工具以及我们扎实的语言功底及时、高品质地完成各个项目和任务,从而成长为一名合格的翻译工作者。

黑盒测试及其分类介绍(一)

work

黑盒测试,又称为数据驱动测试,定义为把被测试对象看作是一个黑色的盒子,测试人员不关心软件内部逻辑是如何实现,只关心软件外部实现的功能是否与用户的需求规格说明一致;

又叫数据驱动测试,是因为黑盒测试主要关注用不同的输入,看程序的输出是否合理,是否达到软件的需求;

黑盒测试分为两大类,功能测试和性能测试,这篇先来简单介绍下功能测试:

功能测试顾名思义就是对被测对象的功能进行测试验证,验证软件实现的功能是否符合需求规格说明,功能测试又分为业务逻辑测试(也就是功能测试,主要测试方式)、UI测试(用户界面)、兼容性测试、安装测试、安全性测试、可用性测试

UI测试指的是对被测对象的用户界面进行测试验证,主要关注用户界面的风格是否符合用户需求、页面是否美观、排版是否合理等等;

兼容性测试指的是被测对象是否能兼容之前的老版本功能,还包括各种浏览器的兼容性验证、各种操作系统的兼容性验证、分辨率的兼容性验证等等

安装测试指的是安装被测对象是否正确,安装过程是否易懂明了,其实安装测试还包括卸载和升级,这部分以后有机会再和大家分享

安全性测试指的是验证被测对象是否能识别或者防止如黑客攻击,内部数据泄露等风险问题

可用性测试指的是验证被测对象是否能满足用户的一些可用性操作的需求,如易用,操作习惯、界面风格,提示信息,内容合理等等非常多的方面,可用性测试关注的方面主要针对客户,而且非常的多,本人目前也仍在学习中,有机会再和大家一起探讨研究

翻译尽责 编辑减负

u=728379666,3965029593&fm=23&gp=0

根据各位同事的反馈,公司内部有一种奇怪的现象,那就是愿意进行翻译的人数远远多于愿意从事编辑的人数,综合考虑各种实际情况后,特提出本次主题:加强翻译职责,让编辑减负。

 

翻译应履行以下职责:

 

1. 杜绝低级错误(漏译、数字错误、拼写错误、低级语法错误);

 

2. 对照source翻译,由于我们翻译过程中多采用工具,而工具又有一定的局限性,往往载入工具的内容与source相比有一定的差异,我们翻译阶段必须将这个问题解决;

 

3. Reference(包括客户网站、TM、术语表以及其他资料),我们在翻译过程中应尽量与客户提供的各种资料保持一致(除非内有明显错误,则应提Query),不得按照自己的理解随意翻译或将客户资料置之不理。

 

4. Query,译员在翻译过程中应将原文中错误、难以理解、不能把握的专业词汇等有疑问的地方填写至Query,然后交给PMPM应尽早与客户联系解决,然后将客户反馈告知该译员,让其通替通改,这个程序尽量不要留给编辑。

 

5. 译员在翻译过程中遇到的不确定处应突出显示(标红、黄色高亮、批注等各种方式),让编辑有重点地编辑,将重点放在语言上,从而提高交付件品质。

 

在各位翻译尽职尽责地完成翻译件后,各位编辑能在一定程度上减负。希望各位编辑不要畏惧挑战,卸下包袱,以一种认真负责的态度为交付件把好关,尽量提高交付件品质。

 

分享关于软件测试的种类和定义

67518
什么是软件?
软件就是计算机程序、数据和各种文档的集合;
什么是软件测试?
软件测试就是对计算程序、数据和文档验证并发现问题的过程;
软件测试的种类?
1. 按照阶段来分的话:可以分为单元测试、集成测试、系统(功能测试)、验收测试;这里为什么有系统(功能)测试呢?其实不同公司的测试流程不一样,而系统测试更高级于功能测试,后面会讲到
2. 按照是否查看代码来分:可以分为白盒测试、黑盒测试、灰盒测试;
3. 按照是否执行程序来分:静态测试、动态测试
4. 其他:冒烟测试、回归测试、随机测试
而在这之中,黑盒测试又分为功能测试盒性能测试;功能测试又分为业务逻辑测试(功能测试)、UI测试(界面测试)、易用性测试、安装测试、安全性测试;性能测试又分为性能测试、压力测试、负载测试、容量测试、可靠性测试、失败测试等
这些就基本是现有软件公司所可能要进行的测试种类,一般的小型公司经常会用到业务逻辑测试也就是功能测试,而很少会进行性能测试,因为对于测试团队和公司的成本及时间来说,首先要保证的肯定是软件的功能(用户提出的业务需求)是否实现,是否能正常运行,在这些都确定OK的情况下,才会考虑性能测试盒其他类型的测试;

问题所在

2013 DTP 发现小问题来总结一下。

20130813155755-1440574629

【摘要】

DTP (Desktop publishing),可理解为:“DTP 桌面排版服务”或是“桌面出版物排版”。它是本地化项目流程中的一个环节。具体来说,就是以英文文档为基础,根据本国家/地区文字方面的特殊规定或要求,排版文档。如:文字需要横排或是竖排,以从左到右的顺序或是从右到左的顺序;是否如同英文一样允许文字加粗,或是文字被斜体等等。

前不久在遇到一个这样问题,做 QuarkXPress 本地化版本的时候发现一个这样的问题。

客户提供:

QuarkXPress 9.0 版本以上英文工程文件

客户没有提供字体

客户提供图片

客户提供老版本 PDF(中日)以及更新译文 Excel (中日)译文

拿到所有文件检查文件和附件能否打开以及完整型。结果发现由于本机安装 QuarkXPress 版本太低无法打开。

任务:降低版本 索要字体(客户同意寻找类似的字体替换)

本地化过程中需要把 PDF和 Excel 译文顺利粘贴到 QuarkXPress 中。中文版本制作很顺利,必定中文是我们母语。但是在操作日文的过程中出现了一些问题,当时没有发现,客户反馈才发现日文中个别几个段落中是首字缺少。但是 Excel 译文粘贴中首字一切正常,事实告诉我在粘贴 PDF文字时候要高度重视。尽量不要把译文放到 pdf 中操作。

浅谈软件工程

67518

现代社会离不开软件。

国家基础设施和公共建设都是由基于计算机的系统控制,大多数的电子产品都有计算机和控制软件。工业制造和金融系统已经完全计算机化了。娱乐业,包括音乐产业、计算机产业、电影和电视产业,也都是软件密集型的产业。因此,软件工程对于一个国家和整个国际社会的运转都是必不可少的。

现在仍有很多有关软件项目出问题和“软件失败”的报道,除开软件测试遗漏的一些致命性或严重性或严重影响用户体验的问题外,软件工程因不能充分支持现代软件的开始而遭非议。然而,在我看来,这些所谓的软件失败主要源于以下两方面的原因:

  1. 不断增长的需求:由于新的软件工程技术可以帮助我们构建更大更复杂的系统,用户的需要因而在发生改变。系统必须更快速地构建并交付;需要更大更复杂的系统;系统必须具备在以前看来不可能实现的功能。现有的软件工程方法已经不能应对新形势,而新的软件工程技术还有待于进一步发展。
  2. 期望值太低:不采用软件工程的方法和技术区编写计算机程序相对来讲要容易一些。很多公司因为他们的产品和服务在逐步发展而在软件开发中随波逐流。他们通常不使用软件工程方法,结果导致他们的软件比预计的费用高且不可靠。

因此我们需要更好的软件工程教育和实践来解决此类问题。