[转] 软件测试(一)

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<SPAN style="FONT-FAMILY: 宋体; mso-fareast-language: ZH-CN; mso-ascii-f