常用翻译软件测试
翻译技术工具考核试卷
五、主观题（本题共4小题，每题5分，共20分）
1.请描述翻译记忆库在翻译过程中的作用，并说明它是如何提高翻译效率的。（）
2.结合实际案例，阐述后编辑在机器翻译应用中的重要性。（）
3.请比较桌面翻译工具和在线翻译协作平台的优缺点，并说明在不同的翻译项目中如何选择合适的工具。（）
14.以下哪些因素可能会影响后编辑过程？（）
A.机器翻译的质量
B.翻译记忆的准确性
C.翻译人员的专业知识
D.时间压力
15.以下哪些是翻译技术工具中自动术语提取的优点？（）
A.提高工作效率
B.保持术语一致性
C.降低人为错误
D.自动识别新术语
16.以下哪些情况可能需要使用桌面翻译工具？（）
A.需要离线工作
A. SDL Trados Studio
B. MemoQ
C. Wordfast
D. MateCat
14.在使用翻译技术工具进行项目时，以下哪个步骤是必要的？（）
A.预处理文件
B.添加术语库
C.导入翻译记忆
D.所有以上选项
15.以下哪种情况不适合使用众包翻译？（）
A.需要大量翻译资源
B.翻译质量要求较高
3. ABC
4. ABC
5. ABCD
6. ABC
7. ABCD
8. ABC
9. ABCD
10. ABCD
11. ABC
12. ABC
13. ABCD
14. ABC
15. ABCD
16. ABD
17. ABC
18. ABCD
19. BC
20. ABCD
三、填空题
深度解析最火在线翻译软件Deep L
DeepL是一款得到了很多用户好评的在线翻译工具。
相比较市场上其它的同类型的翻译软件， DeepL被认为是目前最好用的在线翻译软件，因为它提供的结果比谷歌翻译更加的准确。
但是DeepL的最终翻译结果还是直译，在没有任何编辑的情况下无法完全还原源语言内容。
对于DeepL是否能真正取代人工翻译，答案是否定。
一些企业会试图使用DeepL进行一些翻译，结果并不是总能让人满意。
对于人工智能在翻译工具上的使用，大家讨论的除了翻译结果的差异性，还会产生道义上的一些争议。
以DeepL为例，我们来深度探讨一下人工智能翻译为什么不能完全的取代人工翻译。
更先进的AI技术应用，成功的尝试DeepL算法利用人工智能来模拟人类在翻译文档时的一些技巧。
根据各种测试，DeepL 翻译提供了比谷歌翻译更自然的结果，因为采取了更高级的驱动技术从而捕捉到传统机器翻译忽视的不同语言之间的细微差别，但是这种模拟人类的思考方式具有一定的局限性，更新速度赶不上人类语言习惯的变化。
无门槛免费基础版本和谷歌翻译一样，DeepL提供免费版本，任何人都可以使用基础的功能。
对于企业用户而言，想要获得更加全面的功能，可以付费订阅更多的选项。
现在市面上的翻译软件大多数都会提供免费版或者限时使用期限，让用户体验随之订阅收费版本。
不断进化的词库除了使用AI技术模拟人类学习，DeepL会利用用户反馈和评分来帮助提高翻译质量。
换言之，所有的DeepL用户在使用软件的过程中都给该公司提供了扩大词库的帮助。
AI机器翻译软件的局限虽然DeepL的付费版本保证不会存储您的任何文本，但是敏感的公司数据还是会通过他们的服务器进行处理，甚至公司内部机密的行业文件都会在其服务器留下痕迹。
如果你使用的是DeepL的免费版本，他们会将您的文本存储一段时间，供其改进和更新算法。
因此，隐私信息安全将会是需要值得深思得问题。
大多数得机器翻译软件都无法做到涵盖多个语言，DeepL的一个限制因素是可选择的翻译语言种类不多。
几种常用在线翻译工具的对比研究
几种常用在线翻译工具的对比研究摘要随着翻译工作的需求量越来越大，借助翻译软件进行辅助翻译受到了翻g人员的青睐。
本文主要讨论几种常用的在线翻译工具，包括谷歌在线翻译、有道词典及有道在线翻译、金山词霸、爱词霸及百度在线翻译、必应词典及必应在线翻译、CNKI翻译助手、灵格斯词霸及在线翻译。
首先简要介绍了每种翻译工具的发展历程和特色，然后以核科技翻译为例，从专业术语、长难句及篇章的翻译处理来对比每种翻译工具的优劣，根据用户需求推荐了不同翻译工具：词汇翻译推荐使用有道词典，长难句翻译推荐使用金山或百度，篇章翻译推荐使用百度或谷歌。
关键词翻译软件在线翻译工具核科技翻译软件是帮助用户将一种语言翻译为另一种语言的工具，它从出现到大量普及，给翻译人员甚至普通用户带来了极大的方便，虽然机器始终不能代替人脑，不可能完全独立地译出一篇完美的文章，但是它的出现和不断发展，为翻译人员节约了大量时间，提高了效率，是当今高速发展的经济社会里一项不可缺少的语言工具。
翻译软件分为本地和在线两种类型，最初是依赖本地数据库进行词汇和语句查找，后来随着互联网的普及，经历了几十年的调整和完善，出现了能借助因特网搜罗海量词汇和例句的在线翻译软件，受到了翻译人员和语言学习者的青睐。
本文试以核科技翻译为例，对比研究目前使用率最高的几款在线翻译工具。
1 常用在线翻译工具简介1.1 谷歌翻译谷歌翻译是目前全世界最受欢迎的一款在线翻译工具，谷歌翻译支持90种语言，每天为超过两亿用户提供免费翻译服务。
谷歌翻译的工作本质是基于多种语言的平行语料库，结合统计和数学方法，构建大数据分析模型，挖掘各种语言间的内在规律。
1.2 有道词典及有道在线翻译有道词典及有道在线翻译是国内近年兴起的一款颇受年轻人青睐的翻译软件，目前用户已经超过3.8亿。
有道词典的最大特色是网络释义功能，给中高级翻译和语言学习者足够准确的材料去辨识词汇的正确用法。
另一特色是融入了内容丰富的百科全书，在查找单词的同时，可浏览丰富的百科知识。
外文翻译---软件测试策略
附录英文文献SOFTW ARE TESTING STEATEGIESA strategy for software testing integrates software test case design methods into a well-planned series of steps that result in the successful construction of software .As important ,a software testing strategy provides a rode map for the software developer, the quality assurance organization ,and the customer—a rode map that describes the steps to be conducted as part of testing, when these steps are planned and then undertaken, and how much effort, time, and resources will be required. Therefore , any testing strategy must incorporate test planning, test case design, test execution, and resultant data collection .一INTEGRATION TESTINGA neophyte in the software world might ask a seemingly legitimate question once all modules have been unit tested:“IF they all work individually, why do you doubt that they’ll work when we put them together?”The problem, of course, is“putting them together”—interfacing . Data can be lost across an interface; one module can have an inadvertent, adverse affect on another; subfunctions, when combiner, may not produce the desired major function; individually acceptable imprecision may be magnified to unacceptable levels; global data structures can present problems—sadly, the list goes on and on .Integration testing is a systematic technique for constructing the program structure while conducting tests to uncover errors associated with interfacing. The objective is to take unit tested modules and build a program structure that has been dictated by design.There is often a tendency to attempt non-incremental integration; that is, to construct the program using a :“big bang”approach. All modules are combined in advance .the entire program in tested as a whole. And chaos usually results! A set of errors are encountered. Correction is difficult because isolation of causes is complicated by the vast expanse of the entire program. Once these errors are corrected, new ones appear and the process continues in a seemingly endless, loop.Incremental integration is the antithesis of the big bang approach. The program is constructed and tested in small segments, where errors are easier to isolate and correct; interfaces are more likely to be tested completely; and a systematic test approach may be applied. In the sections that follow, a number of different incremental integration strategies are discussed.1.1 Top-Down IntegrationTop-Down Integration is an incremental approach to construction of program structure. Modules are integrated by moving downward through the control hierarchy, beginning with the main control module (main program). Modules subordinate (and ultimately subordinate) to the main control module are incorporated into the structure in either a depth-first or breadth-first manner.Depth-first integration would integrate all modules on a major control path of the structure. Selection of a major path is somewhat arbitrary and depends on application-specific characteristics. For example, selecting the left hand path, modules M1,M2, and M5 would be integrated first. Next, M8 or (if necessary for proper functioning of M2) M6 would be integrated. Then, the central and right hand control paths are built. Breadth-first integration incorporates all modules directly subordinate at each level, moving across the structure horizontally. From the figure, modules M2, M3, and M4 would be integrated first. The next control level, M5, M6, and so on, follows.The integration process is performed in a series of steps:（1）The main control module is used as a test driver, and stubs are substituted for all modules directly subordinate to the main control module.（2）Depending on the integration approach selected (i.e., depth- or breadth-first), subordinate stubs are replaced one at a time with actual modules.（3）Tests are conducted as each module is integrated.（4）On completion of each set of tests, another stub is replaced with the real module.（5）Regression testing may be conducted to ensure that new errors have not been introduced.The process continues from step 2 until the program structure is built.The top-down integration strategy verifies major control or decision points early in the test process. In a well-factored program structure, decision making occurs at upper levels in the hierarchy and is therefore encountered first. If major controlprogram do exist, early recognition is essential. If depth-first integration is selected, a complete function of the software may be implemented and demonstrated. For example, consider a classic transaction structure in which a complex series of interactive inputs path are requested, acquired, and validated via an incoming path. The incoming path may be integrated in a top-down manner. All input processing (for subsequent transaction dispatching) maybe demonstrated before other elements of the structure have been integrated. Early demonstration of functional capability is a confidence builder for both the developer and the customer.Top-down strategy sounds relatively uncomplicated, but in practice, logistical problems can arise. The most common of these problems occurs when processing at low levels in the hierarchy is required to adequately test upper levels, Stubs replace low-level modules at the beginning of top-down testing; therefore no significant data can flow upward in the program structure. The tester is left with three choices: 1 delay many tests until stubs are replaced with actual modules, 2 develop stubs that perform limited functions that simulate the actual module, or 3 integrate the software from the bottom of the hierarchy upward.The first approach (delay tests until stubs are replaced by actual modules) causes us to lose some control over correspondence between specific tests and incorporation of specific modules. This can lead to difficulty in determining the cause of errors and tends to violate the highly constrained nature of top-down approach. The second approach is workable, but can lead to significant overhead, as stubs become more and more complex. The third approach is called bottom-up testing.1.2 Bottom-Up IntegrationBottom-up integration testing, as its name implies, begins construction and testing with atomic modules (i.e., modules at the lowest level in the program structure). Because modules are integrated from the bottom up, processing required for modules subordinate to a given level is always available and the need for stubs is eliminated.A bottom-up integration strategy may be implemented with the following steps:1 Low-level modules are combined into clusters (sometimes called builds) that perform a specific software subfunction.1. A driver (a control program for testing) is written to coordinate test case input and output.2 .The cluster is tested.3.Drivers are removed and clusters are combined moving upward in the program structure.Modules are combined to form clusters 1,2, and 3. Each of the clusters is tested using a driver (shown as a dashed block) Modules in clusters 1 and 2 are subordinate to M1. Drivers D1 and D2 are removed, and the clusters are interfaced directly to M1. Similarly, driver D3 for cluster 3 is removed prior to integration with module M2. Both M1 and M2 will ultimately be integrated with M3, and so forth.As integration moves upward, the need for separate test drivers lessens, In fact, if the top tow levels of program structure are integrated top-down, the number of drivers can be reduced substantially and integration of clusters is greatly simplified.1.3 Regression TestingEach time a new module is added as part of integration testing, the software changes. New data flow paths are established, new I/O may occur, and new control logic is invoked. These changes may cause problems functions that regression testing is the re-execution of some subset of tests that have already been conducted to ensure that changes have not propagated unintended side effects.In a broader context, successful tests (of any kind) result in the discovery of errors, and errors must be corrected. Whenever software is corrected, some aspect of the software configuration (the program, its documentation, or the data that support it) is changes. Regression testing is the activity that helps to ensure that changes (due to testing or for other reasons) do not introduce unintended behavior or additional errors.Regression testing maybe conducted manually, be re-executing a subset of all test cases or using automated capture playback tools. Capture-playback tools enable the software engineer to capture test cases and results for subsequent playback and comparison. The regression test suite (the subset of tests to be executed) contains three different classes of test cases:1.A representative sample of tests that will exercise all software functions.2.Additional tests that focus on software functions that are likely to be affected by the change.3.Tests that focus on the software components that have been changed.As integration testing proceeds, the number of regression tests can grow quite large. Therefore, the regression test suite should be designed to include only those tests that address one or more classes of errors in each of the major program functions. It is impractical and inefficient to re-execute every test for every program functiononce a change has occurred.1.4 Comments on Integration TestingThere has been much discussion of the relative advantages and disadvantages of top-down versus bottom-up integration testing. In general, the advantages of one strategy tend to result in disadvantages for the other strategy. The major disadvantage of the top-down approach is the need for stubs and the attendant testing difficulties that can be associated with them. Problems associated with stubs maybe offset by the advantage of testing major control functions early. The major disadvantage of bottom up integration is that “the program as an entity does not exist until the last module is added”. This drawback is tempered by easier test case design and a lack of stubs.Selection of an integration strategy depends upon software characteristics and sometimes, project schedule. In general, a combined approach (sometimes called sandwich testing) that uses a top-down strategy for upper levels of the program structure, coupled with a bottom-up strategy for subordinate levels maybe the best compromise.As integration testing is conducted, the tester should identify critical modules. A critical module has one or more of following characteristics: 1 addresses several software requirements;2 has a high level of control (resides relatively high in the program structure); 3 is complex or error-prone(cyclomatic complexity maybe used as an indicator ); or 4 has definite performance requirements. Critical modules should be tested as early as is possible. In addition, regression tests should focus on critical module function.二SYSTEM TESTING2.1 Recovery TestingMany computer-based systems must recover from faults and resume processing within a prespecified time. In some cases, a system must be fault tolerant; that is, processing fault must not cause overall system function to cease. In other cases, a system failure must be corrected whining a specified period of time or severe economic damage will occur.Recovery testing is a system test that forces the software to fail in variety of ways and recovery is properly performed. If recovery is automatic (performed by the system itself), re-initialization, checkpointing mechrequires human intervention, the mean time to repair is evaluated to determine whether it is within acceptable limits.2.2 Security TestingAny computer-based system that manages sensitive information or cause actions that can improperly harm (or benefit) individuals is a target for improper or illegal penetration.Penetration spans a broad range of activities: hackers who attempt to penetrate systems for sport; disgruntled employees who attempt to penetrate for revenge; and dishonest individuals who attempt to penetrate for illicit personal gain.Security testing attempts to verify that protection mechanisms built into a system will in fact protect it from improper penetration. To quote Beizer:“The system’s security must, of course, be tested for invulnerability from frontal attack—but must also be tested for invulnerability from flank or rear attack.”During security testing, the tester plays the role of the individual who desires to penetrate the system. Anything goes! The tester may attempt to acquires passwords through external clerical means, may attack the system with custom software designed to break down any defenses that have been constructed; may overwhelm the errors, hoping to penetrate during recovery; may browse through insecure data, hoping to find the key to system entry; and so on.Given enough time and resources, good security testing will ultimately penetrate a system. The role of the system designer is to make penetration cost greater than the value of the information that will be obtained.2.3 Stress TestingDuring earlier software testing steps, while-box techniques resulted in through evaluation of normal program functions and performance. Stress tests are designed to confront programs with abnormal situations. In essence, the tester who performs stress testing asks:“How high can we crank this up before it fail?”Stress testing executes a system in a manner that demands resources in abnormal quantity, frequency, or volume. For example, 1 special tests maybe designed that generate 10 interrupts per second, when one or two is the average rate; 2 input data rates maybe increased by an order of magnitude to determine how input functions will respond; 3 test cases that require maximum memory or other resources maybe executed;4 test cases that may cause thrashing in a virtual operating system maybe designed; or 5 test cases that may cause excessive hunting for disk resident datamaybe created. Essentially, the tester attempts to break the problem.A variation of stress testing is a technique called sensitivity testing. In some situations (the most common occur in mathematical algorithms) a very small rang of data contained within the bounds of valid data for a program may cause extreme and even erroneous processing or profound performance degradation. This situation is analogous to a singularity in a mathematical function. Sensitivity testing attempts to uncover data combinations within valid input classes that may cause instability or improper processing.2.4 Performance TestingFor real-time and embedded systems, software that provides required function but does not conform to performance requirements is unacceptable. Performance testing is designed to test run-time performance of software within the context of an integrated system. Performance testing occurs throughout all steps in the testing process. Even at the unit level, the performance of an individual module maybe assessed as while-box test are conducted. H0owever, it is not until all system elements are fully integrated that the true performance of a system can be ascertained.软件测试策略软件测试策略把软件测试案例的设计方法集成到一系列已经周密计划的步骤中去，从而使软件的开发得以成功地完成。
写论文,翻译软件帮你忙,几款翻译软件介绍
写论文，翻译软件帮你忙，几款翻译软件介绍说到网友们常用的翻译工具，不外乎是国内的金山词霸，有道词典，国外的灵格斯词霸，微软必应词典等等，最近这几款翻译市场上的巨擘都有一定的升级更新，但性能具体如何，值得一论！第一回合属性比较小编这里用的都是PC版本，兼容性属灵格斯和必应两款最好，都能兼容Win8 ，但国内的两款翻译工具不支持。
有道所占内存最小，必应体积有15.8M，是四款软件中最大的。
第二回合安装过程比较四款软件中只有有道词典捆绑现象严重，虽然小编都一一勾去了，但是安装完成后居然还有！金山词霸1.价格：免费2.版本：4.03.类别：国产软件/外语工具4.大小：7361KB5.开发商：金山6.人气：63977.语言：简体中文8.发布日期：2013-3-22简介：金山词霸是由金山公司推出的一款词典类软件。
第三回合主界面设计比较金山主界面有道主界面灵格斯主界面必应主界面【小结】：虽说面子工程很重要，但这四款词典走的都是简约风，没有花哨的皮肤设置，更没有广告，恩，这才是软件该有的态度！相比而言，小编喜欢必应词典的主界面设计，界面配色鲜亮，没有多余按钮设计，大气，简单；不太中意灵格斯的主界面，无论是颜色还是版面设计上都显得较为单薄。
至于有道和金山只能说中规中矩吧。
有道词典1.价格：免费2.版本：5.4.40.9488 正式版3.类别：国产软件/转换翻译4.大小：5445KB5.开发商：网易6.人气：63977.语言：简体中文8.发布日期：2012-12-15简介：有道词典是网易有道出品的一款很小很强大的翻译软件。
第四回合词典资源比较1.金山词霸金山词霸为用户提供16本通用词典，默认全部开启，支持下载离线词典。
2.有道词典有道词典支持两种自定义词典，一种是有道词典增强版，该版本完整收录《21世纪大英汉词典》及《新英汉大辞典》，离线时也可查看释义；另一种是兼容StarDict格式的词典。
如果您需要添加此格式的词典，只需在搜索引擎中用“stardict”或“星际译王”等关键字进行查询，就可以找到StarDict格式的词典下。
【计算机专业文献翻译】软件测试
附录2 英文文献及其翻译原文：Software testingThe chapter is about establishment of the system defects objectives according to test programs. You will understand the followings: testing techniques that are geared to discover program faults, guidelines for interface testing, specific approaches to object-oriented testing, and the principles of CASE tool support for testing. Topics covered include Defect testing, Integration testing, Object-oriented testing and Testing workbenches.The goal of defect testing is to discover defects in programs. A successful defect test is a test which causes a program to behave in an anomalous way. Tests show the presence not the absence of defects. Only exhaustive testing can show a program is free from defects. However, exhaustive testing is impossible.Tests should exercise a system's capabilities rather than its components. Testing old capabilities is more important than testing new capabilities. Testing typical situations is more important than boundary value cases.An approach to te sting where the program is considered as a ‘black-box’. The program test cases are based on the system specification. Test planning can begin early in the software process. Inputs causing anomalous behaviour. Outputs which reveal the presence of defects.Equivalence partitioning. Input data and output results often fall into different classes where all members of a class are related. Each of these classes is an equivalence partition where the program behaves in an equivalent way for each class member. Test cases should be chosen from each partition.Structural testing. Sometime it is called white-box testing. Derivation of test cases according to program structure. Knowledge of the program is used to identify additional test cases. Objective is to exercise all program statements, not all path combinations.Path testing. The objective of path testing is to ensure that the set of test cases is such that each path through the program is executed at least once. The starting point for path testing is a program flow graph that shows nodes representing program decisions and arcs representing the flow of control.Statements with conditions are therefore nodes in the flow graph. Describes the program control flow. Each branch is shown as a separate path and loops are shown by arrows looping back to the loop condition node. Used as a basis for computing the cyclomatic complexity.Cyclomatic complexity = Number of edges -Number of nodes +2The number of tests to test all control statements equals the cyclomatic complexity.Cyclomatic complexity equals number ofconditions in a program. Useful if used with care. Does not imply adequacy of testing. Although all paths are executed, all combinations of paths are not executed.Cyclomatic complexity: Test cases should be derived so that all of these paths are executed.A dynamic program analyser may be used to check that paths have been executed.Integration testing.Tests complete systems or subsystems composed of integrated components. Integration testing should be black-box testing with tests derived from the specification.Main difficulty is localising errors. Incremental integration testing reduces this problem. Tetsing approaches. Architectural validation. Top-down integration testing is better at discovering errors in the system architecture.System demonstration.Top-down integration testing allows a limited demonstration at an early stage in the development. Test observation: Problems with both approaches. Extra code may be required to observe tests. Takes place when modules or sub-systems are integrated to create larger systems. Objectives are to detect faults due to interface errors or invalid assumptions about interfaces. Particularly important for object-oriented development as objects are defined by their interfaces.A calling component calls another component and makes an error in its use of its interface e.g. parameters in the wrong order.Interface misunderstanding. A calling component embeds assumptions about the behaviour of the called component which are incorrectTiming errors: The called and the calling component operate at different speeds and out-of-date information is accessed.Interface testing guidelines: Design tests so that parameters to a called procedure are at the extreme ends of their ranges. Always test pointer parameters with null pointers. Design tests which cause the component to fail. Use stress testing in message passing systems. In shared memory systems, vary the order in which components are activated.Stress testingExercises the system beyond its maximum design load. Stressing the system often causes defects to come to light. Stressing the system test failure behaviour. Systems should not fail catastrophically. Stress testing checks for unacceptable loss of service or data. Particularly relevant to distributed systems which can exhibit severe degradation as a network becomes overloaded.The components to be tested are object classes that are instantiated as objects. Larger grain than individual functions so approaches to white-box testing have to be extended. No obvious ‘top’ to the system for top-down integration and testing. Object-oriented testing. Testing levels.Testing operations associated with objects.Testing object classes. Testing clusters of cooperating objects. Testing the complete OO systemObject class testing. Complete test coverage of a class involves. Testing all operations associated with an object. Setting and interrogating all object attributes. Exercising the object in all possible states.Inheritance makes it more difficult to design object class tests as the information to be tested is not localized. Weather station object interface. Test cases are needed for all e a state model toidentify state transiti.ons for testing.Object integration. Levels of integration are less distinct in objectoriented systems. Cluster testing is concerned with integrating and testing clusters of cooperating objects. Identify clusters using knowledge of the operation of objects and the system features that are implemented by these clusters. Testing is based on a user interactions with the system. Has the advantage that it tests system features as experienced byusers.Thread testing.Tests the systems response to events as processing threads through the system. Object interaction testing. Tests sequences of object interactions that stop when an object operation does not call on services from another objectScenario-based testing. Identify scenarios from use-cases and supplement these with interaction diagrams that show the objects involved in the scenario. Consider the scenario in the weather station system where a report is generated.Input of report request with associated acknowledge and a final output of a report. Can be tested by creating raw data and ensuring that it is summarised properly. Use the same raw data to test the WeatherData object.Testing workbenches.Testing is an expensive process phase. Testing workbenches provide a range of tools to reduce the time required and total testing costs. Most testing workbenches are open systems because testing needs are organisation-specific. Difficult to integrate with closed design and analysis workbenchesTetsing workbench adaptation. Scripts may be developed for user interface simulators and patterns for test data generators. Test outputs may have to be prepared manually for comparison. Special-purpose file comparators may be developed.Key points:Test parts of a system which are commonly used rather than those which are rarely executed. Equivalence partitions are sets of test cases where the program should behave in an equivalent way. Black-box testing is based on the system specification. Structural testing identifies test cases which cause all paths through the program to be executed.Test coverage measures ensure that all statements have been executed at least once. Interface defects arise because of specification misreading, misunderstanding, errors or invalid timing assumptions. To test object classes, test all operations, attributes and states.Integrate object-oriented systems around clusters of objects.译文：软件测试本章的目标是介绍通过测试程序发现程序中的缺陷的相关技术。
在线翻译软件对比
百度、谷歌、有道在线翻译对比
网易旗下有道搜索今日推出在线翻译服务测试版，据悉是自主技术开发的机器翻译。
百度于7月初推出的翻译功能，这样在国内市场上就有三家提供在翻译服务的搜索引擎网络公司了：谷歌、百度和网易。
具体的翻译功能哪家比较好了。
笔者试图从最常用的单词翻译、段落翻译和网页翻译几个功能比较了一下。
因为工作中经常用到翻译，所以这个比较也是代表了个人的喜好。
从单个单词的翻译效果来讲，看不出大的差别来，逐词翻译三家采用的技术和翻译的词汇条数都很详细。
就段落翻译而言，三家就比较出差别来了。
笔者认为谷歌和有道的翻译内容能看懂，有分段，翻译的效果这两家差不太多。
从这点上来看，网易有道的自主研发技术看来还是有其一定能力。
而百度的翻译效果则很差了，翻译的内容前言不搭后语，两段以上的翻译结果会无分段地粘在一起，翻译的结果很糟糕，看都不想看。
对同样一段英文，下图为谷歌的翻译结果：
下面这个图是有道的翻译结果，看起来界面和谷歌很像啊：
再来看看百度的，堆在一起了：
而网页功能谷歌是当之无愧的老大，不仅仅是因为其他两家都没有此项功能，最主要的是它的网页翻译效果很不错，速度也很快，很方便我的工作。
综上所述，笔者认为谷歌的翻译最后，有道的段落翻译可以补充，而百度的则就不敢恭维了，我想这也是百度没有把翻译功能放到首页的原因吧。
其他两家都放到首页了。
不过，既然做的不够好，我想百度还不如不用这么着急推出来。
google、有道翻译优缺点
谷歌有道爱词霸谁是翻译多面手 2011.6.1 14:41 比特网 ( 0条评论 )如今这年头，谁没有过上国外网站查资料、看两三篇英文文献熬毕设、上网泡MM的时候拽两句英文唬唬人的经历?现在就连上围脖都得对外语略知一二，不然连苍老师的更新都看不明白。
可毕竟大部分人都不是外语专业的高材生，这时候在线翻译就成了上网的必备武器。
小编的英语水平一般，但由于兴趣爱好广泛，常常会接触一些国外的信息，所以对现有的几种在线翻译工具也比较熟悉，算是小有心得。
在此，小编根据使用在线翻译的几个常见的场景，对现在主流的几个在线翻译做一个简单的点评。
这次点评的对象包括：谷歌翻译/有道在线翻译/金山爱词霸翻译/场景一：网页翻译在外文网站看新闻、购物或者查找相关的外文资料时，小编就曾经面对着整屏幕的外文单词，完全无从下手，不知从何点起。
后来出现了网页翻译这样贴心的功能，因为看不懂页面而无奈点叉关闭的窘境就很少在小编身上发生了。
依小编看来，衡量网页翻译的好坏，可以按照使用的人性化、准确度两个要素来综合考量。
由于小编几乎每天都要上美国在线()看新闻，这里就以它作为翻译的测试对象。
1、谷歌翻译：经小编测试可以通过两种方法使用谷歌翻译。
一是进入谷歌翻译页面，将需要翻译的网页地址输入翻译框，点击翻译后就会在当前窗口显示翻译后的页面。
另一种方法是直接在谷歌浏览器中输入地址，浏览器会自动提醒你是不是要翻译成中文。
两种方式都非常方便，翻译速度也非常之快。
准确度上表现也相当不错(图一)。
目前，谷歌翻译支持多达57 种语言，其采用了源自全球范围内样本的“统计机器翻译”技术，谷歌的整体机器翻译水平无疑处于全球领先。
图一：谷歌浏览器对AOL的翻译效果，上面的提示框可以自动弹出不过，在使用谷歌网页翻译功能时，只能进行全文翻译。
当我们需要进一步细究某句话含义时，只能将鼠标移至翻译结果上方查看原文，再结合重点词语的意思去理解，相当不方便。
并且由于众所周知的原因，谷歌在评测过程中多次出现无法打开的情况。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
外文文献原文
It was not until the industrial revolution that methods for automatically steering ships were first contemplated, although the first ship autopilots did not come into use until the first part of the 20th century. Nevertheless, before the development of autopilots could progress it was necessary to devise a powered rudder or steering engine. The motivation for a steering engine came primarily from the naval requirement for warships to undertake high-speed manoeuvres. Bennett (1979) reports that in the late 1860s the British Admiralty equipped several of their sailing ships with various types of steering engines, many of which were based on a steam-hydraulic system.
1、海词词典译文
直到工业革命的方法自动操舵船第一次考虑,尽管第一艘蒙才开始被使用20世纪的第一部分。
然而,在蒙特里的发展进步有必要设计一种驱动舵或舵机。
舵机的动机主要来自海军军舰进行高速演习要求。
班尼特(1979)报告说,在1860年代末英国海军装备他们的几艘帆船和各种类型的转向引擎,其中很多都是基于一个蒸汽-液压系统。
2.有道译文
直到工业革命的方法自动操舵船第一次考虑,尽管第一艘蒙才开始被使用20世纪的第一部分。
然而,在蒙特里的发展进步有必要设计一种驱动舵或舵机。
舵机的动机主要来自海军军舰进行高速演习要求。
班尼特(1979)报告说,在1860年代末英国海军装备他们的几艘帆船和各种类型的转向引擎,其中很多都是基于一个蒸汽-液压系统。
3.金山翻译
直到工业革命的方法自动转向船第一次设想，虽然第一个船舶自动舵没有投入使用，直到第二十世纪的第一部分。
然而，在自动驾驶仪的发展进步有必要设计一个动力舵舵机。
一个舵机动力主要来自海军军舰进行高速机动的要求。
班尼特（1979）报道，在1860年代后期英国海军装备的几种不同类型的转向引擎航行的船只，其中许多是基于蒸汽液压系统。
4、百度翻译
直到工业革命的方法自动转向船第一次设想，虽然第一个船舶自动舵没有投入使用，直到第二十世纪的第一部分。
然而，在自动驾驶仪的发展进步有必要设计一个动力舵舵机。
一个舵机动力主要来自海军军舰进行高速机动的要求。
班尼特（1979）报道，在1860年代后期英国海军装备的几种不同类型的转向引擎航行的船只，其中许多是基于蒸汽液压系统。
5、谷歌翻译
它不是直到自动转向船舶的方法首先考虑的工业革命，虽然第一艘自动驾驶仪没有投入使用，直到20世纪的第一部分。
尽管如此，自动驾驶仪可能进步发展之前，有必要制定一个电动舵或转向引擎。
对舵机的动机来自海军的要求来主要用
于军舰进行高速机动。
贝内特（1979）报告说，在19世纪60年代末，英国海军装备他们几个帆船与各类型的转向发动机，其中许多是基于蒸汽液压系统。
我的翻译：尽管第一台船舶自动操舵仪直到20世纪初才出现，人们在工业革命时期就提出了船舶自动操纵方法的设想。
然而，在自动操舵仪的发展取得进步之前，必须配备动力舵或者舵机。
战舰高速机动的航行要求大大推动了舵机的发展。
Bennett（1979）曾报道在19世纪六十年代末英国政府为他们的帆船配备了不同种类的舵机，其中很多舵机都是蒸汽液压系统。
由上可以看出
1、海词词典和有道词典的译文是相同的，金山词霸和百度翻译的译文是相同的，
加上谷歌翻译总共有三种版本的译文。
其中金山词霸的译文实际上本身就是依靠百度翻译得来的。
2、就这一段翻译而言，由这三种译文中对比可以看出：
2.1专业词汇翻译的准确性
high-speed manoeuvres.“高速机动”，其中百度谷歌均翻译正确，有道译成了“高速演习”
the first ship autopilots “第一架船舶自动操舵仪”其中百度谷歌均翻译正确，有道译成了“第一艘蒙”
结论：百度翻译 = 谷歌翻译> 有道翻译
2.2 语句的通顺和语法正确
It was not until the industrial revolution that methods for
automatically steering ships were first contemplated, although the first ship autopilots did not come into use until the first part of the 20th century.
就这一句的翻译而言，个人感觉语法和语义通顺方面
结论：百度翻译>谷歌翻译>有道翻译。
3、其他方面如用户使用体验，系统的稳定性占不做对比。