失败的测试极其补救(有没有人翻译啊)我翻译的一小段，后面我会继续哦

dtzfltest

我的英文实在太烂,我翻译出来的自己都不好意思看。希望大家多提意见,一起进步哈.

Software Testing is an integral part of the software development life cycle.  Inadequately tested applications result in loss of credibility with the customers - be it an existing customer or a new one. It is therefore very essential that effective testing be performed with an intention to eliminate the common problems that might cause havoc before releasing any software. This document briefs the common testing snags most of the testing projects face and a few tips to overcome them.
软件测试是软件开发生命周期中的一个完整的部分。没有充分测试过的软件往往会失去客户的信任，不论现有的客户还是潜在。因此在软件发布之前，有效的实施测试从而消除常见的会破坏系统运行的问题是非常重要的。这篇文档简单介绍了大多数项目都会碰到的问题极其克服这些问题的一些小技巧。
1. Poor Planning or Estimation
糟糕的计划与预算

Effective planning is one of the most critical and challenging steps in a test project. Test planning and estimating indicate the order and way in which the tasks are to be carried out and the resources required to execute the same. Proper planning is not possible without a sound and reliable estimate.
有效的计划是测试项目中众多非常严格与极具挑战性步骤中的一步。测试计划与预算指出了各个任务的执行次序和方法，并且说明执行它们所需的资源。没有范围与可靠性评估的计划是不可能的。
•Effort: Delays can result because of lack of resources to perform the activities in a certain time frame or in less efficient use of resources because too many resources are allocated
执行有时间限制活动时的资源短缺或者因大量分配而导致未被充分利用资源所以延期是必然的。

guirongb

俺来帮你翻译，只需要支付少量的劳务费就可以了，怎么样？神医？专业的服务哦。。。

saxifrage

本性能改！！

guirongb

哈，胡萝卜要哇？小兔儿，便宜哦

dtzfltest

同志们，对不起，里面的翻译有些我觉得不对。等完整翻完一大段我再重新发。谢谢

beiyue

翻译的不错

skinapi

(楼主先把原文用附件贴出来吧。^_^)删
原文以前有测友贴过了，没发现，真是不好意思。
欢迎楼主翻译并和大家分享。

[ Last edited by skinapi on 2005-4-21 at 22:28 ]

guadolf0708

我等你好消息，其实已经很不错了，只要认真，就ok,还有就是东侧是行业的术语。
祝你早日完工。

dtzfltest

附件里面包含原文及翻译。呵呵，谢谢大家捧场。:p

skinapi

感谢dtzfltest的翻译，希望能再接再厉翻译完。^_^

[ Last edited by skinapi on 2005-4-23 at 23:27 ]

dtzfltest

第二段来了。
2. Ambiguous Requirements
不明确的需求

Without adequate documentation, the testing effort usually takes longer and allows more errors to get through to the released version. Ambiguity in requirements makes the test design phase a tedious task. The cost of uncovering and correcting requirement deficiencies at this stage is significantly less than that incurred during the acceptance-testing phase. There may be numerous implied or underlying requirements, which may be overlooked by the testers on glancing the requirements.  It is therefore essential that the requirements be understood thoroughly at the initial phase of testing.  
如果没有足够的文档，测试方面的投入会非常多，而且在已发布的版本中也会出现更多的错误。需求的含糊不清使测试设计阶段的任务沉闷乏味。在测试设计阶段暴露和改正需求缺乏的成本远远低于接受测试阶段。在测试人员匆忙看需求的时候可能注意不到很多潜在的需求。因此在测试初始阶段能够充分理解需求是必不可少的而且非常重要的一步。
How to tackle?
如何去解决？

The testers can review the requirements and prepare a list of queries to be addressed on the requirements and get them clarified even before preparing the test cases to enable them deliver a quality product.  A report with the deficiencies in requirements may also be prepared.
测试人员应该评论需求，准备一个在需求方面的问题列表，在准备测试用例从而能使交付一个高品质产品成为可能之前验证他们。可能也要准备一份有关需求缺乏的报表。

西西

翻得不错，静候下文，希望在全翻译后整理一下！

zhangfh

不好意思，英语水平不高。下面这段译文是我借助词霸翻译的。希望英语水平高的同行给予指点。谢谢
失败的测试及其解决技巧
软件测试是软件开发生命周期中主要部分.不充分的测试结果会失去已有的客户或新客户的信任.在删除一些软件之前有目的地消除普通的问题可能会引起严重破坏,因此这是很基本的.这个文档简要阐述了大多数测试项目应该面对的问题和克服他们的一些办法.
l        1.不完整的计划和需求
有效的计划是测试一个项目中众多的评审和极具挑战性的步骤之一.测试计划和需求简要的说明了被执行和资源要求执行相同的顺序和方法.正确的计划不可能没有一个完整和可靠的需求.
²        结果方面：延迟可能在一定的时间阶段引起资源匮乏或者资源使用率方面不足的结果,因为太多的资源被分配.
²        进度方面：进度评估是在结果评估之后。开发人员低估了结果并且要求测试资源。结果是，在最后期限没有集成或是在交货日期只有部分经过测试的软件交付给最终用户。
²        费用方面：当没有正确的预算时，费用变得相当的昂贵。有时很可能导致测试活动被取消，结果是在项目的质量方面会引起更多的安全问题。
l        怎样去解决呢？
取一个总结果的百分率，基于以前类似的测试过程中使用标准的比率，考虑企业的一般费用，估算个人的工作时数和推断结果。不充分的测试会引起知识资源的浪费，例如使用知识匮乏或经验不足的测试员同样能造成质量测试方面的不足。不要忘记应包括
²        提高业务知识或技术方面的知识水平要求进行定期培训。
²        解决一些预见性的问题就要求有缓冲时间。
l        2。含糊的需求
如果没有足够的文档，在发布版本时，测试结果常常花费较长的时间且带来更多的错误。含糊的需求使得测试计划变成一项乏味的任务。准备不足的需求在这个阶段更多的花费就是未覆盖的和不正确的，在需求可接受阶段值得注意少于可招致（实在绕口不会翻译）。这可能有众多暗指的或潜在的需求，粗略的流程可能被测试员没注意到。因此在最初的测试阶段需求被彻底地理解。
²        如何解决？
测试员可以根据需求填写的姓名地址来浏览需求并且准备了一系列疑问，使得这些问题在提交产品质量之前阐述清楚。不充分的需求报告也可以准备了。
l        3。不充分的测试覆盖
        一个好的测试团队能达到大范围的覆盖。不完整的用例在这个项目中不能完成全部的功能测试。测试覆盖仅仅是一种质量测试的度量。如果高覆盖率的测试不能完成的，那么这个程序的功能必须加强是势在必行的。另一个额外的因素就是测试数据在可能存在的范围内不完全覆盖。
²        如何解决呢？
1。在一个EXCEL工作表中所有被写入的需求中确保违反需求的测试用例被标注，证明是关联的测试用例数量（比方说每一个用例将是唯一数字）。低覆盖率的测试说明了这个过程的一个问题，那就是可能需要这一批测试人员的技术提高，或者给测试人员进行培训。许多测试工具在测试覆盖率上被市场销售调查中证明是有效地。
2．在这个应用系统中不可能测试所有条件下的用例。有效的数据设计，无效的数据设计充分的可以准备正常程序操作的覆盖。边界值技术，等价类划分在整个测试数据中可以被应用。
l        4。未受控的测试环境
更多的测试环境类似于最终的产品环境。更多的可靠性被测试。测试环境的不足的结果就导致产品中不可预知的结果。
²        如何解决？
  1、测试将发生在一个受控的环境中。因此它将从开发或程序环境中分离出来。测试环境的所有权将被测试小组掌握并且没有他们的允许不能改变将要发生的环境。
  2、测试一直可以等到测试环境及时被搭建且确保环境也被管理时进行，等等。测试环境将充分地有代表性的执行这些测试，将会与产品环境相似的环境附近进行测试。为测试主管或开发小组提交管理的协调者负责的最适合的环境是必需的，授权等等。如果一个独立的测试小组被确定，它最完美的是也将拥有一个独立团队机构。
l        5。测试作为一种结果
低估了结果和资源必然导致了在开发周期的末尾从测试活动开始，使得测试人员未接地就关闭主要的错误变得困难，由于时间限制在测试文档中的导致细节折衷。
²        如何解决呢？
测试计划可以在需求一开始就被定义，程序测试在程序开发阶段就同时进行的方式被采用。
l        6.不合适的测试文档
不合适的/不正确的测试文档（测试计划，测试规范，缺陷报告等等）导致马上分析去测试/再测试涉及区域被测试，在提交时可能有影响或者产品质量。//翻译不了。
²        如何去解决呢？
1、        合适的结果也需要在文档上花费时间，因为测试文档在所有的测试阶段是一个很重要的任务。
2、        细心可以从所有被涉及测试的文档都被正确的准备从同步数据链路控制的开始而且不断的更新中得到。

zhangfh

抱歉，从word中粘贴过来的，“²”是项目符号，不影响阅读

dtzfltest

不过我不看，等我翻译完了再做个比较.忽忽

西西

我也翻翻一些，就算是班门弄斧吧！！因为是先看译文，所以翻得地方主要是对有异议地方翻译，其他的都是楼上原来翻的！！呵呵

拙劣的计划和估计
软件测试是软件开发生命周期中主要部分.不充分的测试结果会失去已有的客户或新客户的信任.（因此，在发布任何一种软件版本之间，执行有效的测试从而消除常见问题导致的严重错误是十分重要的。）.这个文档简要阐述了（大多数测试项目面临的常见测试障碍以及一些克服这些障碍的技巧）。

（在一个测试项目中，有效的计划是最重要和具有挑战意义的步骤之一。测试计划和评估指出了任务执行的次序和方法及其执行时所需的资源。一个正确的计划是不可能没有一个合理和可靠的估计的。）


（效果：在一个特定的时间段内缺乏足够的资源完成任务，或者过多的资源分配造成的效率低下都会造成时间延迟。）

（进度：进度估计是在效果估计之后，开发人员低估测试的效果和资源需求，这样的结果导致，最后期限未能交付软件或是软件仅经过部分测试后就提交给最终用户。）

（成本：当预算估计不准确时，费用变得相对昂高。这样可能导致一些测试工作被取消并进而影响项目的质量）

在工作中.....所以没有时间继续了，希望大家能继续讨论，把文章翻得更好

dtzfltest

第三段来了
3. Insufficient Test Coverage
不充分的测试覆盖率
A good test suite will achieve high coverage.  Inadequate number of cases cannot complete testing the functionality in its entirety.  Test coverage is only a measure of the quality of testing.  If high-test coverage is not achieved, it is imperative that the process needs to be strengthened. Another factor to be added is the inadequate test data that does not completely the possible ranges.
好的测试过程可以达到高的覆盖率。少量的用例不能完全测试全部的功能。测试覆盖率仅仅是衡量测试质量的一个方面。如果没有达到很高的测试覆盖率，那么加强测试过程是势在必行的。
How to tackle?
如何去解决？
1.         The associated test case identification number (say a unique number for every case) can be marked against the requirements in an excel sheet to ensure that test cases are written for all requirements. Low coverage indicates a process problem, which might require test generation technique to be improved, or training to be imparted to the tester. Many tools are available in the market to measure the test coverage.
1、可以将测试用例识别码（每个用例都有一个唯一的号码）与需求对应起来放在Excel工作表中，用来保证为所有的需求都写出了测试用例。低的覆盖率表明方法有问题，可能是测试生成技术需要改进，也可能需要给测试人员提供培训。市场上许多测试工具都可以度量测试覆盖率的。
2.        It is not possible to test all conditions in an application system.  Data design with valid, invalid data to cover normal processing operations adequately can be prepared. Techniques of boundary values, equivalence partitioning can be applied while preparing test data.
2、要测试到应用程序中的所有情形是不可能的。应该准备一些能充分覆盖正常业务的有效及无效的测试数据。在准备测试数据时会应用到临界值，等价类划分等技术。

fyxu333

下午看到另外一篇帖子，我就把文章翻译了，后来发现已经有这么些人翻译过了，不过我粗粗的看了一下，觉得大家还是有必要共享一下成果，好取长补短。
这是我的，请大家多提意见！

[ Last edited by fyxu333 on 2005-4-28 at 19:10 ]

skinapi

to zhangfh:
翻译出来的东东不用再从word里贴出来，直接附件word文档就可以了。^_^
to all:
尝试翻译的测友可以看看别人的翻译，对将来再阅读英文的资料有帮助，理解的能更准确一些。

maliry

`下次我也练练手！