Verification: Confirmation by examination and through provision of objective evidence that specified requirements havebeen fulfilled. [ISO 9000]

验证：通过检查和提供客观证据来证实指定的需求是否已经满足。[ISO 9000]

Validation: Confirmation by examination and through provision of objective evidence that
the requirements for a specific intended use or application have been fulfilled. [ISO 9000]

确认：通过检查和提供客观证据来证实特定目的功能或应用已经实现。[ISO 9000]

辨析：验证(verification) 产品是否正确的按着设计文档实现功能。确认(validation) 产品是否正确的按着客户需求被实现功能。 也就是产品通过了验证测试但是不一定会通过确认测试。这也就是为什么要提早介入测试，让设计文档尽可能准确的符合需求文档的要求。需求和设计文档之间的Gap越小，两种测试就越可能得到相同的结果。

1. In prioritising what to test, the most important objective is to:

A. find as many faults as possible

B. test high risk areas 

C. obtain good test coverage 

D. test whatever is easiest to test

Answer: B

3. A failure is:

A. an incorrect step, process or data definition in a computer program 

B. found in the software; the result of an error 

C. departure from specified behavior 

D. a human action that produces an incorrect result

至郑文强老师的一封信：

郑文强老师，您好！

你好：

非常感谢你的来信，从心中可以看出你对ISTQB已经有相当的了解。ISTQB考证说明中FL的考题分布，确实是基于2007版本的。目前就一个内容有所更改，即一道K4的题目代替了原来K3的题目：白盒测试中的内容。因为CSTQB官方没有这个最新的更新，所以我也没有计划更新。从考试层面而言，白盒测试中的内容，你不用太关心，实际内容没有什么变化。

有任何ISTQB方面的疑问，欢迎来信，或者访问我的个人网站：http://www.skyqa.com。

祝好

郑文强

 

1. (K1)  下列关于错误、缺陷和失效的观点正确的是：
A)  人都会犯错误，因此在由人设计的程序也会引入缺陷；
B)  所有的缺陷都会产生失效；
C)  失效主要是由人的错误造成的，和环境条件没有关系；
D)  当存在缺陷的代码被执行时，才可能引发软件错误。

答案： 我选D， 但是答案是A

解析：粗心没好好看题，答案D应该是“引发软件失效”，用排除法得到答案A。

5. (K2)  下列关于不同的测试阶段的描述错误的是：
A)  维护测试通常是为了验证开发过程发现的缺陷是否被正确修复。
B)  组件测试的主要目标是尽可能的发现失效，从而识别和修正尽可能多的缺陷。
C)  验收测试的主要目标是确认系统是否按照预期工作，是建立满足了需求的信心。
D)  不同测试阶段，其测试目标是不同的。

答案： 我选B， 但是答案是A

解析：FL考纲2011版P14页：“维护测试通常是为了验证在开发过程中的软件变
更是否引入新的缺陷”。 而P30页：“当发现和修改了一个缺陷后，应进行再测试以确定已经成功的修改了原来的缺陷，这称之为确认。”，这样看来答案A的叙述是错误的。

7. (K2)  规划测试环境的搭建和确定测试需要的基础设施和工具属于下面的哪个活动？
(A)  计划和控制
(B)  分析和设计
(C)  实现和执行
(D)  评估出口准则和报告

答案： 我选A， 但是答案是B

解析：这个是被书“软件测试基础教程”的“2.2.1测试计划和控制”一节误导了，这节最后讲到了基础设施和测试工具需要开发的问题，就误认为A了。这部分内容在考纲P17页有很清楚的表述。

8. A test team consistently finds between 90% and 95% of the defects present in the system under test. While the test manager understands that this is a good defect-detection percentage for her test team and industry, senior management and executives remain disappointed in the test group, saying that the test team misses too many bugs. Given that the users are generally happy with the system and that the failures which have occurred have generally been low impact,which of the following testing principles is most likely to help the test manager explain to these managers and executives why some defects are likely to be missed?
a. Exhaustive testing is impossible
b. Defect clustering
c. Pesticide paradox
d. Absence-of-errors fallacy

答案： 我选B， 但是答案是A

解析：这个题很容易被90%~95%迷惑，粗心就选择B了，但是题目里表达了，发现了绝大部分Defect，并且剩余的问题对用户影响不大，因此给管理者的解释告诉他们避免全部的问题是不可能的，做到把影响大的问题最大程度发现是有可能的。

最近看到大家关于认证考试的一些看法的帖子，也有讨论考了证书能不能加工资的。 我打个比方，你想开车，必须考驾照，考了驾照，你就一定能多赚钱吗？ 换个说法一个人他想开车喜欢开车，但是他知道必须先考驾照才能学会开车，保证自己的驾驶技术可以得到最初的认可，也许他以后想去赛车。。。

想问认证的证书怎么样，要想问问自己怎么看待你正在从事的这份测试的职业。

我也在考认证的证书，之所以从事测试工作7，8年了才考这个证书，是因为自己发现自己对测试理论的认识不系统不严谨，需要一个系统性的梳理自己的测试理论知识的系统性的时候了。 比如，自己也设计测试用例，也管理测试计划，系统的看过教程才发现，自己以前早就知道的“软件质量特征”，其实是设计测试用例和考虑测试计划的出发点，软件需要达到的功能性，稳定性等的特征，决定了你测试用例设计和管理测试计划的的中心和重点。在这之前，自己还一直都迷失在套用测试计划设计模板里（不知道模板考虑的出发点和如何自己去设计一些新的内容）。

多考虑一些自己职业发展的问题，这对自己长远发展的大有裨益的，当然薪水的增加不仅和个人积累有关系，机遇也很重要。如果只一味考虑证书和薪水的关系，那从这个学习过程中个人能力的提升的程度也会大打折扣的。

The syllabus of ISTQB Foundation Level

2007(Blue) Vs. 2011(Black)

• K1: remember, recognize, recall;

• K1: remember

• K2: understand, explain, give reasons, compare, classify, categorize, give examples, summarize;

• K2: understand

• K3: apply, use.

• K3: apply

• K4: (No Exist)

• K4: analyze

1.  Fundamentals of Testing (K2)

1.1 Why is testing necessary? (K2)

LO-1.1.5 Recall the terms error, defect, fault, failure and corresponding terms mistake and bug. (K1)

LO-1.1.5 Explain and compare the terms error, defect, fault, failure, and the corresponding terms mistake and bug, using examples (K2)

1.2 What is testing? (K2)

LO-1.2.2 Describe the purpose of testing in software development, maintenance and operations as a means to find defects, provide confidence and information, and prevent defects. (K2)

LO-1.2.2 Provide examples for the objectives of testing in different phases of the software life cycle (K2)

LO-1.2.3 (No Exist)

LO-1.2.3 Differentiate testing from debugging (K2)

2. Testing Throughout the Software Life Cycle (K2)

2.1 Software development models (K2)

LO-2.1.1 Understand the relationship between development, test activities and work products in the development life cycle, and give examples based on project and product characteristics and context (K2).

LO-2.1.1 Explain the relationship between development, test activities and work products in the development life cycle, by giving examples using project and product type (K2).

3. Static techniques (K2)

3.1 Static techniques and the test process (K2)

LO-3.1.3 Explain the difference between static and dynamic techniques. (K2)

LO-3.1.4 Describe the objectives of static analysis and reviews and compare them to dynamic testing. (K2)

LO-3.1.3 Explain the difference between static and dynamic techniques, considering objectives, types of defects to bee identified, and the role of these techniques within the software life cycle (K2) 

3.3 Static analysis by tools (K2)

LO-3.3.2 List typical benefits of static analysis. (K1)

LO-3.3.2 Describe, using examples, the typical benefits of static analysis (K2)

4. Test design techniques (K4) * (K3 --> K4)

4.1 The test development process (K3) * (K2 --> K3)

LO-4.1.3 Evaluate the quality of test cases. Do they:

• show clear traceability to the requirements;

• contain an expected result. (K2)

LO-4.1.3 Evaluate the quality of test cases in terms of clear traceability to the requirements and expected results (K2)

4.3 Specification-based or black-box techniques (K3)

LO-4.3.1 Write test cases from given software models using the following test design techniques: (K3)

• Equivalence partitioning;

• Boundary value analysis;

• Decision table testing;

• State transition testing.

LO-4.3.1Write test cases from given software models using equivalence partitioning, boundary value analysis, decision tables and state transition diagrams/tables (K3)

LO-4.3.2 Understand the main purpose of each of the four techniques, what level and type of testing could use the technique, and how coverage may be measured. (K2)

LO-4.3.2 Explain the main purpose of each of the four testing techniques, what level and type of testing could use thee technique, and how coverage may be measured (K2)

LO-4.3.3 Understand the concept of use case testing and its benefits. (K2)

LO-4.3.3 Explain the concept of use case testing and its benefits (K2)

4.4 Structure-based or white-box techniques (K4) * (K3 --> K4)

LO-4.4.2 Explain the concepts of statement and decision coverage, and understand that these concepts can also be used at other test levels than component testing (e.g. on business procedures at system level). (K2)

O-4.4.2 Explain the concepts of statement and decision coverage, and give reasons why these concepts can also bee used at test levels other than component testing (e.g., on                business procedures at system level) (K2)

LO-4.4.3 Write test cases from given control flows using the following test design techniques:

• Statement testing;

• Decision testing. (K3)

LO-4.4.3 Write test cases from given control flows using statement and decision test design techniques (K3)

LO-4.4.4 Assess statement and decision coverage for completeness. (K3)

LO-4.4.4 Assess statement and decision coverage for completeness with respect to defined exit criteria. (K4)

4.6 Choosing test techniques (K2)

LO-4.6.1 List the factors that influence the selection of the appropriate test design technique for a particular kind of problem, such as the type of system, risk, customer requirements, models for use case modeling, requirements models or tester knowledge. (K2)

LO-4.6.1 Classify test design techniques according to their fitness to a given context, for thee test basis, respective models and software characteristics (K2)

5. Test management (K3)

5.1 Test organization (K2)

LO-5.1.2 List the benefits and drawbacks of independent testing within an organization. (K2)

LO-5.1.2 Explain the benefits and drawbacks of independent testing within an organization (K2)

5.2 Test planning and estimation (K3) * (K2 --> K3)

5.3 Test progress monitoring and control (K2)

LO-5.3.2 Understand and interpret test metrics for test reporting and test control (e.g. defects found and fixed, and tests passed and failed). (K2)

LO-5.3.2 Explain and compare test metrics for test reporting and test control (e.g., defects found and fixed, and tests passed and failed) related to purpose and use (K2)

6. Tool support for testing (K2)

6.1 Types of test tool (K2)

LO-6.1.1 Classify different types of test tools according to the test process activities. (K2)

LO-6.1.1 Classify different types of test tools according to their purpose and to the activities of the fundamental test process and the software life cycle (K2)

LO-6.1.2 Recognize tools that may help developers in their testing. (K1)

LO-6.1 .2 Intentionally skipped

LO-6.1.3 (No Exist)

LO-6.1.3 Explain the term test tool and the purpose of tool support for testing (K2)

6.2 Effective use of tools: potential benefits and risks (K2)

LO-6.2.2 Recognize that test execution tools can have different scripting techniques, including data driven and keyword driven. (K1)

LO-6.2.2 Remember special considerations for test execution tools, static analysis, and test management tools (K1)

LO-6.3.2 State the goals of a proof-of-concept/piloting phase for tool evaluation. (K1)

LO-6.3.2 State thee goals of a proof-of-concept for tool evaluation and a piloting phase for tool implementation (K1)

在我家领导的催促下，本人再次为ISTQB-FL考试做准备，不参加培训，使用自己手上的现有资料：

1. 以Foundations Of Software Testing ISTQB Certification(3rd)

为主要教材（OReilly上刚刚购入电子版花了好多米...）

2. 结合ISTQB的2011年的Syllabus和Glossary

3. 参考书是《Software_Testing_Foundations_Third_Edition》，主要是它是结合考纲的还有习题，但是买最新版本的是Amazon上太贵也不方便。

4. 可以再看看 EDS的ISTQB Testing Foundation 的Flash教程（内部资料哦）

5. 在教程看的差不多了要试试网上买来的题库，不知道好不好，总算是能做个练习。

6. 最后，花一大笔米去考试，如果不行的话那就杯具了，俺家领导可是给俺花了血本了。。。

Chapter 1  A Brief Tour

1. If we fi  nd that we really cannot make the minimal test strategy work on our project by using these patterns, we can fall back to the alternative patterns listed in the full descriptions of these patterns and in the other narratives.

翻译：如果我们确实遇到了使用这些模式但是不能使这些最小测试策略在我们的项目中起作用的情况，那么我们就需要返回到这些模式的完整描述和其他一些叙述的地方，那里列出了一些替换的模式。

2. I have laid out this simple strategy in five parts:
• Development Process: How the process we use to develop the code
affects our tests.

• Customer Tests: The fi  rst tests we should write as the ultimate defi  ni-
tion of “what done looks like.”

• Unit Tests: The tests that help our design emerge incrementally and
ensure that all our code is tested.

• Design for Testability: The patterns that make our design easier to test,
thereby reducing the cost of test automation.

• Test Organization: How we can organize our Test Methods (page 348)
and Testcase Classes (page 373).

我简单的罗列了在五个部分中的简单的测试策略：
1. 开发过程：我们使用开发代码的流程是如何影响我们的测试

2.客户测试：是我们应该写的作为“应该做出什么样子”的最终定义的第一个测试

3. 单元测试：是能够帮助增量式的形成设计并且确保所有的代码都是被测试过的测试

4. 可测性设计：使我们的设计更容易被测试从而降低了测试自动化的成本

5. 测试组织方法：我们应该如何组织测试方法和测试类

第一部分 基本知识

第3章 对象、类型和值

1. 初始化和赋值的区别：初始化需要检查变量的类型描述；赋值则需要将旧址销毁再将新值存入变量。

因此，将Destination Profile Configuration的GUI类分解为三个GUI子类:

由此就可以分别将GUI对象和对于的业务逻辑封装在不同的子类中，而公共的GUI对象， 比如 Turn Edit On对象就封装在Destination Profile Configuration窗口GUI类中，这样很好的提升了代码的复用性。

4.        简化测试执行流程

通过GUI对象的封装，对测试执行流程进行了有效的简化，并且对代码的可读性也有了显著的改善。下面是一个Add Destination Profile 测试的例子。

二.           检查点类

既然通过对GUI对象的封装可以简化了测试执行的流程，能不能将这种方法推广到测试检查流程呢？检查点的流程和测试执行流程既有关联由于区别，通常情况下需要重复部分测试流程，但是也有不同的附加流程，比如在Patient Input的检查流程需要对已经录入的Patient记录进行检索，然后再查看录入的内容，因此使用对GUI对象的封装方法，也对检查点对象使用的GUI对象和检查逻辑进行封装。下面是一个检查 Add Destination Profile的例子：

由此简化的测试执行流程和检查流程如下图所示：

三.           使用xUnit Pattern 重构测试代码

1.        断言（Assert）

断言是xUnit的最大特色之一，简化的调用方式使得嵌入在代码逻辑内的检查点既简洁又明确当前的检查类型和目标。封装一个Assert Class能够很好的简化测试流程，而且可以重构一些不明确的测试检查点。

Assert Class 提供一些检查方法，比如assertEquals（检查两个变量相等），assertTrue（检查变量是否为真）等。

虽然我们模仿了xUnit的断言，但是也不能一味的照搬，事实上与白盒测试不同的是基于GUI测试的检查点不仅仅需要检查结果，还需要通过检查控制测试流程是否进行下去，比如某个窗口不存在时就需要报错，然后中断测试流程执行下一个测试。xUnit的断言不是基于GUI的并不需要考虑这个问题。因此，必须对测试检查点进行分类实现。从检查以后产生的执行结果，我将检查点分为控制点（Control Point）和观察点（Observation Point）。观察点控制点只做值的检查，在检查成功或失败以后输出相应日志；控制点值的检查，在检查失败以后输出失败的日志，并且终止程序的执行。当然，这种划分不是绝对的，在有需要的情况下可以进一步扩展不同的检查点类型。

由此，assertEquals和assertTrue 分类为两组检查点方法：assertCPEquals，assertCPTrue和assertOPEquals ，assertOPTrue。

采用断言方法，测试的执行和检查可以进一步的被重构：

在使用VBScript实现断言过程中，由于VBScript并不提供支持try-catch的异常抛出和捕捉处理机制。但是通过VBScript提供的on error resume next 和on error goto 0机制来实现断言机制。实现的大致过程如下：

2.        SetUp 和TearDown

使用SetUp和TearDown方法可以将测试的前置条件（Prerequisite） 和 后置条件（Restoration）进行有效的封装，重构以后的测试代码显的更加有条理和边界分明。比如，使用指定的用户登录系统是一个常见的前置条件。

3.        TestSuite

对于一组测试用例采用TestSuite的方式进行组织。与TestCase的SetUp和TearDown方法类似，也可以采用同样的方法将更高层的公共前置条件和后置条件进行重构。下面是一个简单的例子：

四.           结束语

通过此次实践，我们找到了一种提高测试代码复用性的方法，虽然使用的效果还不是最为理想的，但是随着宿主语言对OO的支持的改进，这种思想和方面必将成为自动化测试发展的方向。