软件测试[意义与方法][中英对照翻译]

软件测试
1.Objective目的
The objective of this document is to describe software testing for use with any software development project. The purpose is to provide a baseline for software testing activities. A standardized testing process is required because it improves the effectiveness and efficiency of testing for the project. It does so in several ways.
本文档的目的是描述任何软件开发项目中的软件测试活动，目的是提供一个标准的测试活动基准。

标准化的测试流程是被需要的,因为它可以提高项目测试的效率和有效性。

∙Defines the testing process
∙Makes the testing process repeatable
∙Ensures high-risk components of the system are tested
∙Lessens the effects of individual differences (tester background and skill set) on testing
∙Adds “intelligence” to testing
∙Provides metrics for managing and controlling testing
∙Provides metrics for assessing and improving testing
∙Provides a basis for test automation
∙Produces specific testing deliverable
∙定义测试过程
∙确保测试过程可重复
∙确保系统中高风险的组件得到测试
∙缩小测试中由于测试人员的背景和技能的不同产生的影响
∙增加“intelligence”去测试
∙为管理和控制测试提供度量
∙为评估和改进测试提供度量
∙提供自动化测试的基础
∙产出具体的测试交付物
2.What is Software Testing?什么是软件测试？The goal of the testing activity is to find as many errors as possible before the user of the software finds them. We can use testing to determine whether a program component meets its requirements.
测试活动的目标是在软件的真正用户使用前尽可能的发现更多的错误，我们使用测试去确定一个程序组件是否满足它的需求。

To accomplish its primary goal (finding errors) or any of its secondary purposes (meeting requirements), software testing must be applied in a systematic fashion.
为了实现它的主要目标（发现错误）或者第二目标（满足需求），软件测试必须应用在一个系统方式中。

Testing involves operation of a system or application under controlled conditions and evaluating the results.
测试包括了一个系统的操作或者受控条件下的应用和结果评价。

Verification and Validation验证和确认
Verification and Validation (V&V) is a Software Testing activity to enhance quality of the software being built. It is planned and conducted systematically through out the software lifecycle.
验证和确认（V &V）是一种软件测试活动去增强被构建的软件质量，V&V被计划并系统化的执行于整个软件生命周期。

∙Verification is the checking or testing of items, including software, for conformance and
consistency with an associated specification. Software testing is just one kind of verification,
which also uses techniques such as reviews, analysis, inspections and walkthroughs.
∙验证(Verification)是对一些内容的检查和测试，它包括对于软件规格符合性和一致性的检查，软件测试仅仅是验证的一种，还用到了一些其他的技术比如评审，分析，检查，走查（reviews,
analysis, inspections and walkthroughs）。

∙Validation is the process of checking that what has been specified is what the user actually
wanted. Validation activity may begin when most or all software functions as per customer
expectations.
∙确认（Validation）是针对那些被用户指定的，满足他们实际期望的需求的检查过程。

确认活
动可以开始于多数或者所有软件功能按照客户期望完成时。

∙Validation testing provides final accurance that the software meets all functional, behavioral
and performance requirements. Usually Black-box testing is used for this activity.
∙确认测试提供最终的保证，确保软件满足所有功能，运行情况和性能需求。

通常黑盒测试被
用于该活动。

Verification: Are we building the project right? 我们正确的构建了这个项目吗？
Validation: Are we building the right product? 我们构建了正确的产品吗？
Debugging Vs Testing 调试 Vs 测试
The term bug is often used to refer to a problem or fault in a computer. There are software bugs and hardware bugs.
“Bug”这个术语通常用于计算机的一个问题或者错误，包括软件和硬件的Bug。

Software testing should not be confused with debugging. Debugging is the process of analyzing and locating bugs when software does not behave as expected. Although the identification of some bugs will
be obvious from playing with the software, a methodical approach to software testing is a much more thorough means of identifying bugs. Debugging is therefore an activity, which supports testing, but cannot replace testing. However, no amount of testing can be guaranteed to discover all bugs.
软件测试不应该与调试混淆。

调试是指当软件没有像预期的运行时，进行分析并且找出Bug的过程。

虽然
运行软件可以很明显的确认一些Bug，但是有系统地进行软件测试是一种更彻底地来发现 Bug的方法。

因
此调试是一种支持测试的活动，但是不能替代测试。

同时，不能保证有多少的测试可以发现所有Bug。

Common Problems 常见问题
∙Poor requirements – if requirements are unclear, incomplete, too general, or not testable,
there will be problems
∙需求不足-如果需求是不明确的、不完整的、太概括、或者不可测，那就会有问题
∙Unrealistic schedule – if too much work is crammed in too little time, problems are inevitable
∙不切实际的进度安排-如果有限时间里有太多工作，不可避免地就会有问题
∙Inadequate testing – no one will know whether or not the program is any good until the
customer complains or systems crash
∙测试不足-在用户抱怨或者系统崩溃之前，没有人知道程序好不好。

∙Requirements change – requests to pile on new features after development is underway are
common
∙需求变更-开发后还有新功能需求提出，这也很普遍
∙Miscommunication –if developers don‟t know what is needed or customers have erroneous
expectations, problems are guaranteed
∙沟通错误-如果开发人员不知道需要什么，或者用户有不正确的期望，肯定会有问题
∙Poorly documented code – sufficient comments not built into the source code, requirement
changes not updated in the impacted documents
∙代码文档化不够-源代码中没有足够的注释，没有在文档中体现需求的变更
Solutions解决方案
∙Solid requirements – clear, complete, detailed, cohesive, attainable, testable requirements
that are agreed to by all players use prototypes to help nail down requirements.
∙可靠的需求-清晰、完整、详细、连贯的、可达到的、可测试的需求，并且取得所有相关人员
的同意，可以使用原型的方法来明确需求。

∙Realistic schedules – allow adequate time for planning, design, testing, bug fixing, re-
testing, changes, and documentation; personnel should be able to complete the project without
burning out.
∙合理的进度安排-为计划、设计、测试、缺陷修复、重测试、变更和文档编写预留足够的时间。

∙Adequate testing - start testing early on, re-test after fixes or changes, plan for adequate
time for testing and bug-fixing.
∙充分测试-尽早开始测试，在缺陷修复或变更后重新测试，为测试和缺陷修复计划充分的时间。

∙Stick to initial requirements as much as possible – be prepared to defend against excessive changes and additions once development has begun, and be prepared to explain consequences.
If changes are necessary, they should be adequately reflected in related schedule changes. If
possible, use rapid prototype during the design phase so that customer can see what to expect.
This will provide them a higher comfort level with their requirements decisions and minimize
changes later on.
∙初始需求-做好在开发开始后大量变更和增加的准备，并且解释相应的结果。

如果变更是必需
的，应该在反映在相应的进度变更中。

如果可能，在设计阶段采用快速原型，从而客户可以看到
期望的结果。

这可以帮助客户决定需求并且减少之后的变更。

∙Communication – require walkthroughs and inspections when appropriate; make extensive
use of group communication tools - e-mail, groupware, networked bug-tracking tools and change
management tools, intranet capabilities, etc.; ensure that information/documentation is available
and up-to-date - preferably electronic, not paper; promote teamwork and cooperation; use
prototypes early on so that customers' expectations are clarified.
∙沟通-在合适的时候要求走查和审查；使用团队沟通工具-电子邮件，缺陷跟踪工具和变更管
理工具，intranet等；保证信息/文档的可用并且是最新的；促进团队工作和合作；尽早使用原型，
以了解客户的期望。

3.Who should perform software testing?谁需要
执行软件测试？
Person having the following skills is most ideal for performing software testing:
∙…Test to Break‟ attitude
∙Ability to understand customers point of view
∙Strong desire for quality
∙Attention to detail
执行软件测试人员最希望有以下技能
发现问题的态度
了解客户的观点
关注细节
Further, the following added skills assist in better and effective software testing:
以下的技能可以帮助更好并且更有效的进行软件测试：
∙Familiarity with the software development process
∙Promote a positive atmosphere within the team, despite the …negative‟ process (Example:
Looking for problems in the system)
∙Diplomatic skills to promote improvements in QA processes.
∙Ability to withstand pressures and say …No‟ to manages when quality is insufficient or QA
processes are not being adhered to.
∙Good communication and interactive skills to communicate with technical, non-technical
people, engineers, managers, and customers.
∙Good documentation and reporting skills to record the defects.
∙熟悉软件开发过程
∙在团队中提倡积极的氛围，尽管需要在系统中寻找“消极”的问题
∙有技巧的倡导质量保证过程
∙能够承担压力，在质量不能得到保证或者没有遵循流程的时候说“不”
∙能与技术、非技术人员、经理和客户等进行良好的沟通和交互
∙能够有效的记录并汇报缺陷
4.Types of Tests测试类型
Listed are some the customary tests conducted before delivery:
1. Unit test
2. Integration test
3. Regression test
4. System test
5. Acceptance test
6. Installation test
以下列出一些交付前的常见的测试：
单元测试
集成测试
回归测试
系统测试
验收测试
安装测试
4.1.Unit Testing单元测试
A unit can be defined as the smallest testable element of a software design.
单元可以定义为软件设计的最小可测元素。

Unit testing is a white box testing technique. They are essential path tests. The idea is to focus on a relatively small segment of code and aim to exercise a high percentage of the internal path.
单元测试是白盒测试技术。

是基本路径测试。

主要关注于一小部分代码，目标是执行大部分的内部路径。

A path is an instruction sequence that threads through the program from entry to final exit. The simplest approach is to ensure that every statement is exercised at least once. A more stringent criterion is to require coverage of every path within a program.
路径是程序从入口到退出的指令顺序。

最简单的方法是保证每个语句至少执行一次。

更严格的准则是要求覆盖程序中的每一条路径。

A more practical criterion is to exercise each condition for each decision statement at least once and ensure that all variables and parameters are exercised at and below minimums, at and above maximums, and at intermediate values.
比较实际的准则是至少执行一次每个决定的条件，并且保证所有的变量和参数通过最小值以下、最高值以上和中间值的测试。

White box testing generally has the highest error yield of all testing techniques. In fact, a retrospective study states that comprehensive path and parameter testing could potentially have caught 72.9 percent of the problems encountered by the users of one large program.
白盒测试是所有测试技术中能发现最多错误的。

事实上，有研究发现在大型的程序中，全面的路径和参数测试可以发现用户会遇到问题的72.9%。

4.2.Integration Testing集成测试
A Module is a collection of source files that form a coherent bundle. A module could consist of related functions/units.
一个模块是一个有关联关系的源文件集。

一个模块可以由相关的功能/单元组成。

Integration Testing is a systematic technique to uncover errors associated with interfacing (build the program structure as per the design) modules / units. The modules are integrated in parts, where errors are easier to isolate and correct. It examines the interactions between various software components.
集成测试是发现有接口关联的模块/单元相关的问题。

模块按部件集成，这样可以比较容易地隔离并纠正错误。

Integration testing combines both white box and black box testing. Integration testing can be done in the following ways. Namely, top-down and bottom-up methods. The advantages and disadvantages of this testing are also discussed.
集成测试包括白盒测试和黑盒测试。

测试可以采用以下两种方法，自上而下和自下往上，同时也描述了测试的优点和缺点。

Test Drivers and Stubs (IT)测试Driver和Stub(IT)
The concepts of test drivers and stubs are used throughout this integration testing. A test driver is a software, which executes software in order to test it, providing a framework for setting input parameters, executing the unit, and reading the output parameters. A stub is an imitation of a unit, used in place of the real unit to facilitate testing.
在集成测试中会用到测试driver和stub的概念。

测试driver是一个软件，提供了一个可以设置输入参数、执行单元并且读取输出参数的框架，可以通过执行软件来进行测试。

Stub是一个模拟单元，取代真实的单元来推动测试。

4.2.1.Top-Down Testing自上而下测试
In top-down testing, individual units are tested by using them from the units, which call them, but in isolation from the units called. The unit at the top of a hierarchy is tested first, with all called units replaced by stubs. Testing continues by replacing the stubs with the actual called units, with lower level units being stubbed. This process is repeated until the lowest level units have been tested. Top down testing requires test stubs, but not test drivers.
在自上而下测试中，每一个单元通过从其他单元调用来测试，调用的单元与被调用的单元是隔离的。

在结构顶端的单元先测试，所有其他被调用的单元由stub代替。

继续用实际的被调用单元取代stub，同时下一层单元采用stub。

重复这个过程直到最下面一层单元被测试。

自上而下测试要求测试stub,而不是测试driver。

Figure 1 illustrates the test stubs and tested units needed to test unit D, assuming that units A, B, and C have already been tested in a top-down approach
图1举例说明要测试单元D需要的测试stub和被测单元，假设在自上而下的方法中，单元A,B和C已经
被测试了。

A test plan for the program shown in figure 1, using a strategy based on the top-down organizational approach, could read as follows:
图1中说明了一个程序的测试计划，使用了自上而下的策略：
Step 1 步骤1
Test unit A, using stubs for units B, C, and D
测试单元A，单元B、C和D使用stub。

Step 2步骤2
Test unit B, by calling it from tested unit A, using stubs for units C and D.
测试单元B, 从已测的单元A中调用，单元C和D使用stub。

Step 3步骤3
Test unit C, by calling it from tested unit A, using tested units B and a stub for unit D
测试单元C, 从已测的单元A中调用，单元B已测，单元D使用stub。

Step 4步骤4
Test unit D, by calling it from tested unit A, using tested unit B and C, and stubs for units E, F and G. (Shown in figure 2.1)
测试单元D，从已测的单元A中调用，单元B和C已测，单元E、F、G使用stub。

（如图2.1）
Step 5步骤5
Test unit E, by calling it from tested unit D, which is called from tested unit A, using tested units B and C, and stubs for units F, G, H, I and J.
测试单元E, 从已测试过的单元D中调用，同时从单元A中调用单元D，此时B和C已测试，单元F、G、H、I、J使用stub.
Step 6步骤6
Test unit F, by calling it from tested unit D, which is called from tested unit A, using tested units B, C and E, and stubs for units G, H, I and J.
测试单元F，从已测试过的单元D中调用，同时从单元A中调用单元D，此时B,C,E已测试，单元G,H, I
和J使用stub.
Step 7步骤7
Test unit G, by calling it from tested unit D, which is called from tested unit A, using tested units B, C, E and F, and stubs for units H, I and J.
测试单元G，从已测试过的单元D中调用，同时从单元A中调用单元D，此时B,C,E,F已测试，单元H, I
和J使用stub.
Step 8步骤8
Test unit H, by calling it from tested unit E, which is called from tested unit D, which is called from tested unit A, using tested units B, C, E, F and G, and stubs for units I and J.
测试单元H，从已测试过的单元E中调用，此时单元A调用单元D，单元D调用单元E, 其中B,C,E,F,G
已测试，单元I和J使用stub.
Step 9步骤9
Test unit I, by calling it from tested unit E, which is called from tested unit D, which is called from tested unit A, using tested units B, C, E, F, G and H, and a stub for units J.
测试单元I，从已测试过的单元E中调用，此时单元A调用单元D，单元D调用单元E，其中B,C,E,F,G,H 已测试，单元J使用stub.
Step 10步骤10
Test unit J, by calling it from tested unit E, which is called from tested unit D, which is called from tested unit A, using tested units B, C, E, F, G, H and I.
测试单元J，从已测试过的单元E中调用，此时单元A调用单元D，单元D调用单元E，其中
B,C,E,F,G,H,I均已测试。

Figure 1: Top-down Testing自上而下测试
Major Features: The controlled program is tested first
Modules are integrated one at a time
Major emphasis is one interface testing
主要特点：先测试受控程序；模块逐步集成；强调接口测试。

Advantages: No test drivers are needed
The controlled program plus a few modules form the basic early prototype
Interface errors are discovered early
Modular features aid debugging
优点：不需要测试driver；受控程序和一小部分模块形成基本的早期原型；可以尽早发现接口的错误；模块化的特性帮助调试。

Disadvantages: Test stubs are needed
The extended early phases dictate a slow manpower buildup
Errors is critical modules at low levels are found late
缺点：需要测试stub;早期阶段较长，从而人员组建也会比较慢；关键但是低层的模块中包含的错误会很晚发现。

Comments: An early working program raises morale and helps convince management progress is being made It is hard to maintain a pure top-down strategy in practice
注释：尽早开始工作可以提升士气，同时帮助将进展情况呈现给管理层；但是实际中很难做到纯粹的自上而下。

4.2.2.Bottom-up Testing自下而上测试
Units are tested in isolation from the units, which call them, but using the actual units called as part of the test. The lowest level units are tested first, and then used to facilitate the testing of higher level units. Other units are then tested using previously tested called units. The process is repeated until the unit at the top of the hierarchy has been tested. Bottom up testing requires test drivers, but does not require test stubs. Figure 2 illustrates the test driver and tested units needed to test unit D, assuming that units E, F, G, H, I and J have already been tested in a bottom up approach.
将单元与调用他们的单元隔离，但是使用被调用的单元进行测试。

首先测试最底层的单元，然后推动上层单元的测试。

其他单元使用被调用并已测试的单元进行测试。

重复过程，直到最顶层的单元被测试。

自下往上测试要求测试driver，但不需要测试stub。

图2说明了测试单元D需要的测试driver和已测单元，假设单元E, F, G, H, I 和 J已经使用自下而上的策略进行了测试。

A test plan for the program shown in Figure 2 using a strategy based on the bottom-up organization approach could read as follows:
图2采用了自下而上的测试策略：
Step 1步骤1
(Note that the sequence of tests within this step is unimportant, all tests within step 1 could be executed in parallel.)
（注意本步骤内的测试顺序不重要，步骤1中的所有测试可以被并行执行。

）
Test unit H, using a driver to call it in place of unit E
Test unit I, using a driver to call it in place of unit E
Test unit J, using a driver to call it in place of unit E
Test unit F, using a driver to call it in place of unit D
Test unit G, using a driver to call it in place of unit D
Test unit B, using a driver to call it in place of unit A
Test unit C, using a driver to call it in place of unit A
测试单元H，使用driver从单元E调用；
测试单元I，使用driver从单元E调用；
测试单元J，使用driver从单元E调用；
测试单元F，使用driver从单元D调用；
测试单元G，使用driver从单元D调用；
测试单元B，使用driver从单元A调用；
测试单元C，使用driver从单元A调用；
Step (2)步骤2
Test unit E, using a driver to call it in place of unit D and tested units H, I and J.
测试单元E，使用driver从单元D调用，H、I、J已测。

Step (3)步骤3
Test unit D, using a driver to call it in place of unit A and tested units E, F, G, H, I and J. (Shown in figure 2).
测试单元D,使用driver从单元A调用，E、F、G、H、I、J已测。

Step (4)步骤4
Test unit A, using tested units B, C, D, E, F, G, H, I and J.
测试单元A，使用已测的B、C、D、E、F、G、H、I和J。

Figure 2: Bottom-up Testing自下而上测试
Major Features: Allows early testing aimed at proving feasibility and practical of particular modules Modules can be integrated in various clusters as desired
Major emphasis is on module functionality and performance
主要特点：允许尽早对特定模块的可行性和实用性进行测试；模块可以根据需要进行集成；主要关注模块的功能和性能。

Advantages: No test stubs are needed.
It is easier to adjust to manpower needs
Error in critical modules are found early
优点：不需要测试stub;可以方便调配人力资源；关键模块的错误可以尽早发现。

Disadvantages: Test drivers are needed
Many modules must be integrated before a working program is available
Interface errors are discovered late
缺点：需要测试driver；在一个可工作的程序出现之前，需要集成很多模块；较晚发现接口错误。

Comments: At any given point, more code has been written and tested than with top-down testing Some people feel that bottom-up is a more intuitive philosophy
注释：在任何时候，与自上而下测试相比，有更多的代码被编写并测试。

很多人认为自下而上是一种更为自发的哲学。

4.3.Regression Testing回归测试
Whenever there is a change to the existing software or when new modules/units are added, there could be new data flow paths, new I/O, new control logics. These changes may impact the existing functions that were previously working flawlessly. Regression testing is the process of running all existing test cases and verifying that the changes have not propagated any side effects.
当对软件做变更或者增加新的模块/单元时，可能会有新的数据流、I/O、控制逻辑。

变更可能会影响已有的正常运行的功能。

回归测试是运行所有已有的测试用例并且验证变更没有带来副作用的过程。

Regression testing is the only reliable way to ensure that modifications did not introduce new errors into code or to check whether modifications successfully eliminated existing errors. Every time code is modified or used in a new environment, regression testing should be used to check the code's integrity. Ideally, you perform regression testing nightly (during automated nightly builds) to ensure that errors are detected and fixed as soon as possible
要保证修改没有带来新的错误，或者检查修改是否成功排除已有的错误，回归测试是最可靠的方法。

每一
次代码被修改或者在新的环境中使用，都应该进行回归测试来检查代码的完整性。

理想状态下，每天晚上
进行回归测试（自动的夜间build）来保证及时发现并修复错误。

Regression testing is most often used in testing maintenance to existing programs. It is also used when new modules are added to a system under development, which has already undergone integration testing. 回归测试最常用在已有测试的测试维护。

在开发时，当往已经进行集成测试的系统中添加新的模块，也可
使用回归测试。

4.4.System Testing系统测试
System testing verifies that all elements (modules/units) mesh properly and that overall system
function/performance is achieved.
系统测试验证所有元素（模块/单元）配置正常，并且整个系统功能/性能达到要求。

In system testing the focus is on the whole application and its environment. It is intended to test the system as a whole rather than individual system component. Inevitably, System Testing reveals errors which were undiscovered during Integration testing.
在系统测试中，关注整体应用和环境。

将系统作为整体而不是各个组件来测试。

系统测试会发现集成测试
中未发现的错误。

System testing involves Interface Testing and Stress Testing.
系统测试包括接口测试和压力测试。

4.5.Acceptance Testing (Alpha and Beta Testing)接受测试（Alpha和
Beta测试）
Acceptance Testing is a process of demonstrating to the customer that the system is acceptable. When customer software is built, series of acceptance tests are conducted to enable the customer to validate all requirements. Acceptance testing is usually performed by the end-users. They will work with the system
to determine if it satisfies their criteria.
接受测试是向客户显示系统是可接受的过程。

当客户软件建立后，客户可以做一系列的接受测试来验证需求。

接受测试通常由最终用户执行。

他们来决定系统是否满足准则。

Most software developers use a process called Alpha and Beta testing to uncover errors that only the
end-users seem s able to find. The Alpha test is conducted at the developers‟ site by the customer with
the developer monitoring the recording of errors and other usage problems.
大多数开发人员使用Alpha和Beta测试来发现只有最终用户才能发现的错误。

Alpha测试由用户在开发现
场进行，开发人员监控并记录错误和其他使用问题。

The Beta test is conducted at one or more customer site by the end-user of the software. Unlike Alpha testing, the developer usually is not present. Therefore, Beta test is a …live‟ application in an environment that cannot be controlled by the developer.
Beta测试在客户现场由最终用户执行。

与Alpha测试不同，通常开发人员不参与。

因为Beta是开发人员
不能控制的环境中的“实际”应用。

4.6.Installation Testing安装测试
Installation testing is the final test before handing a system over to the users. It consists of moving all system components to the production environment and ensuring that the users will have a workable system. The product, from a functional standpoint is now ready to be used.
安装测试是将系统交付给用户之前的最终测试。

它包含将所有系统组建移交到生产环境，并保证用户有一
个可用的系统。

产品，从功能角度来看已经可用。

5.White Box Testing白盒测试
White box testing is a test case design method that uses a controlled structure of the procedural design to derive test cases. This method can derive cases that:
白盒测试是使用结构化设计步骤设计测试用例的方法，方法可以产生用例：
1. Guarantee that all independent paths within a module have been exercised at least once.
2. Exercise all logical decision on their true and false sides.
3. Execute all loops at their boundaries and within their operational bounds.
4. Exercise internal data structures to ensure their validity.
1. 保证模块中所有的独立路径都至少执行一次。

2. 执行所有逻辑决定的true和false。

3. 执行所有循环的边界和操作边界内部。

4. 执行内部数据结构来保证正确性。

6.Black Box Testing黑盒测试
All white box tests have the disadvantage that the program's source code is needed to run the tests. Functional or black box testing, however, aims to test a given program's behavior against its specification without making any reference to the internal structures of the program or the algorithms used. Therefore the source code is not needed, and so even purchased modules can be tested. The programs just get a certain input, and its functionality is examined by observing the output.
所有白盒测试的缺点是运行测试时需要程序的源码。

功能或者黑盒测试的目标是按照程序说明来测试，而
不关注程序内部的结构或者算法。

因此不需要源码，所以购买的模块也可以被测试。

程序得到一定的输入，通过观察输出来检查它的功能。

The tested program gets a certain input or the input is observed. Then the product does its job and generates a certain output, which is collected by a second interface. This result is then compared to the expected output, which has been determined before the test.
被测试的程序得到一定的输入或者输入被观察。

然后运行产品产生一定的输出，通过接口进行输出的收集。

将输出与测试前确定的期望的输出进行对比。

Black box testing attempts to find errors in the following categories:
1. Incorrect or missing functions
2. Interface errors
3. Errors in data structure or external database access
4. Performance errors
5. Initialization and termination errors
黑盒测试发现一下几类错误：
1.不正确或者确实的功能
2.接口错误
3.数据结构或者外部数据库访问的错误
4.性能错误
5.启动和结束错误
There are a lot of different ways to do black box testing. The important 5 types are namely, Function, System, Performance, Stress, and User testing.
有很多不同的方法来做黑盒测试。

重要的5种包括：功能、系统、性能、压力和用户测试。

Advantages of Black Box Testing:
∙Black box tests are reproducible
∙Environment the program is running is also tested
∙The invested effort can be used multiple times
黑盒测试的有点是：
∙黑盒测试是可重复的
∙同时也测试了程序运行的环境
∙投入的工作量可以被多次使用
Disadvantages of Black Box Testing
∙Results are often overestimated
∙Not all properties of a software product can be tested
∙The reason for a failure is not found
黑盒测试的缺点：
∙通常会高估结果
∙不能测试软件的所有特性
∙不能找到造成失败的原因
7.Automated Test Approach自动测试
∙For small projects the time needed to learn and implement testing tools may not be worth it.
For larger projects or for ongoing long-term projects, they can be valuable.
∙由于需要时间来学习和实施测试工作，对于小项目可能不使用。

对于大型或者持续的长期项
目，比较有价值。

∙ A common type of automated tool is the 'record/ playback' type. For example, a tester could
click through all combinations of menu choices, dialog box choices, buttons, etc. in an
application GUI and have them 'recorded' with the results logged by a tool.
∙常见的自动工作是“录制/重放”的类型。

例如：对于一个GUI的应用，测试人员可以点击菜单、对话选择、按钮等的任意组合，并且和结果一起录制在工具中。

∙The 'recording' is typically in the form of text based on a scripting language that is
interpretable by the testing tool. If new buttons are added, or some underlying code in the
application is changed, etc. the application can then be retested by just 'playing back' the
'recorded' actions, and comparing the logging results to check effects of the changes.
∙“录制”通常是测试工具可以识别的脚本。

如果添加新的按钮，或者应用系统中的代码变更等，可以通过“重放”已“录制”的内容来对应用系统进行重新测试，比较结果来检查变更的效果。

Disadvantages:缺点：
∙The problem with such tools is that if there are continual changes to the system being
tested, the 'recordings' may have to be changed so much that it becomes very time-consuming
to continuously update the scripts. Additionally, interpretation of results (screens, data, logs, etc.)
can be a difficult task. Note that there are record/playback tools for text-based interfaces also,
and for all types of platforms.
∙工具的问题是如果被测试的系统有持续的变更，需要频繁变更“录制”更新脚本，从而要花费
大量的时间。

另外，结果（屏幕、数据、日志等）的理解也会很困难。

需要注意的是录制/重放工
具同样也适用于文字界面，和所有的平台。