新手的答案：为什么想做测试，测试是做什么的，你要做哪种测试，那你怎么看待测试呢？

前段时间接了一个客户报上来的bug, 因为涉及到与操作系统相关的安装问题，修复该bug可能要涉及到架构的一些变化，所有产品的安装component都会受到牵连，所以最终选择了在read me文档中添加说明项来解决用户使用过程中遇到的不便。

文档测试，说起来很简单，就是因为其简单的表象，很容易使测试人员心里麻痹而忽视一些细节。从直觉判断，我觉得这个看似简单的问题也不能简单的对待，于是查阅了一些书籍，对文档测试进行了一些深入的理解。

作为一个软件测试人员，一定要具备宏观的质量意识，不仅仅是专注于业务和技术。随着软件产品的日趋复杂化，文档已经成为软件产品的重要组成部分之一，其中包括：

1.Package text and graphics.
2.Marketing material, ads, and other insert.
3.Warranty/registration.
4.EULA- end user license Agreement.
5.Labels and stickers.
6.Installation and setup instructions.
7.User's manual.
8.Online help.
9.tutorials, wizard, and CBT(computer base training).
10.Samples, examples, and templates.
11.Error messages.
所有的这些item都是大部分专业客户在使用过程中密切关注的，如果任何一项出现错误或者低可用性，都会严重影响客户的使用感，从而对我们的产品质量产生不好的感觉。因此，文档测试必须和代码测试，功能测试等一样同等重视。

那么，一个好的文档测试可以给软件产品带来什么好处呢？ 首先，提高了软件的可用性；其次，提高了软件稳定性；最后，降低了技术支持的成本。
为什么这么说呢？如果客户在文档中找不到软件使用的说明，那么势必会对使用产生一些疑惑，或者因为错误使用而导致不可预知的结果。最终客户将会致电客服技术支持来寻求解决。如果在一开始文档就有比较完善的测试，就不会导致上面一系列的结果。

就像software testing里面所说：A very effective approach to testing it is to treat it just like a user would. Read it carefully, follow every step, examine every step, examine every figure, and try every example. If there is sample code, type it in and make sure it works as described. With this simple real-world approach, you'll find bugs both in the software and the documentation.

基于这些理解，最终我是怎么来测试这个read me文档的呢？

1.可用性测试：我首先重现了这个客户报上来的bug，并且理解了问题的原因，然后仔细阅读了read me文档里面添加的内容，按照里面所描述的逻辑进行操作，看问题是否被修复了。
2.进行了拼写检查，和描述清晰度检查，考虑是否有第二种理解，或者歧义，然后根据第二种或者第三种理解进行操作，看是否会出现不可预知的错误；
3.检查文档是否安全，是否带有威胁性的病毒或者不安全因素；
4.检查所有的问题都被描述到，并且在制定的build里面已经包含了该文档；

最后我发现这个添加的描述存在理解歧义，客户容易产生疑惑，并且不能很快的解决问题。我试图和文档开发人员进行了沟通，最终他认可了我的建议，将这段文字进行了修改。

似乎整个过程表面上看起来略显繁琐，有点吹毛求疵的嫌疑。但是我觉得作为一个软件测试人员，就是需要将质量意识贯穿到每一个日常工作中，才能够提高客户满意度，建立真正的“customer driven”意识。

从年前开始做一个产品新build的regression 测试，因为是第一次接触产品，之前没有时间去了解功能，着实花了很多时间，连续加班半个月，还是有点累人的。在这里总结一下这大半个月的工作，从中学到知识得到成长。

结合实践，我希望对regression有更加透彻的理解，以帮助日后的工作：

查了一些资料，先从原理来理解。

Regress 的英语定义是：  return  to  a  worse  or  lessdeveloped state

而Regression test 的意义在于：在新版本上运行所有已通过测试的case，从而验证新版本的稳定性。

在软件项目中，如果一个模块或功能以前是正常工作的，但是在一个新的构建中出了问题，那这个模块就出现了一个“退步”（Regression），从正常工作的稳定状态退化到不正常工作的不稳定状态。

在一个模块的功能逐步完成的同时，与此功能有关的测试用例也同样在完善中。一旦有关的测试用例通过，我们就得到了此模块的功能基准（Baseline）。

如果这样的“倒退”是由于模块的功能发生了正常变化（由于设计变更的原因）引起的，那么测试用例的基准就要修改，以便和新的功能保持一致。

针对一个Bug Fix，我们也要作Regression Test。

（1）验证新的代码的确把缺陷改正了。

（2）同时要验证新的代码没有把模块的现有功能破坏，没有Regression。

回归测试最好要自动化，因为这样就可以对于每一个构建快速运行所有回归测试，以保证尽早发现问题。

结合上面的原理，我总结有以下几点：

1.       Regression测试主要目的是验证模块和功能是否出现倒退，以前修过的bug是否重新复发；

2.       Regression测试除了围绕上面两个工作展开，还需要进行测试用例baseline的维护工作：

a)         模块功能的正常变化所引起的不符合，需要及时更正case；

b)         把上一个版本所出现并且修复的缺陷及时的引入到case库里面；

c)         把功能的变更和名称的改动及时地反映到case里面；

3.       Regression测试中也会遇到以前版本里面本来就存在但没有被发现的缺陷，但这些缺陷不应该作为重点验证的部分，因为regression测试的主要目的是发现因为修改而出现的倒退现象；

4.       为了节省时间和精力，节约成本，regression测试应该重点侧重于分析因为上一版本所改动部分可能引起的问题并重点验证，而不要过多的集中于一些边缘测试和性能测试等；

    测试用例（Test Case）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。对软件的每个特定功能或运行操作路径的测试构成了一个个测试用例。
    目前的功能测试用例都需要首先进行需求理解，再进行用例设计，这些过程都是基于人工实现的。尤其是测试用例的测试输入部分需要人来理解需求并组合测试步骤，测试用例的预期结果业需要人工来提取。人工撰写功能测试用例，不仅耗费大量时间在需求理解阶段，而且也需要花费大量人力和时间撰写。尽管这样，撰写出来的测试用例仍然存在覆盖度不均衡，依赖用例撰写者的经验和能力，以及不能够完全的的复现需求的问题。

一、需求文档分析
通过分析需求文档的章节排版和内容格式，将需求分解成一个个Feature、Sub Feature、case的描述。
比如例1：
***********************************************
1 Place a call .................................Feature1
1.1 Dialling........................................Sub Feature1
Phone number: “0~9”
Case 1
Tap the keyboard then input the correct phone number or select the phone number from contacts or select it from the call history, then tap the “Dial” button, can make a call. The dialing main interface is as below:
*Interface image*
Case 2
Tap the “End call” button……
1.2 Incoming Call...................................Sub Feature2
1.3 XX..........................................Sub Feature3
2 Calendar reminder.....................Feature2
3 XX.............................................Feature3
***********************************************

产生出以下的编号和子功能 case描述：
Data format：Phone number[0~9]
F1_SF1_C1 ：
Tap the keyboard then input the correct phone number or select the phone number from contacts or select it from the call history, then tap the “Dial” button, can make a call. The dialing main interface is as below:
*Interface image*
F1_SF1_C2 ：
Tap the “End call” button……
F1_SF2........：

二、测试需求分析

测试需求分析就是将前面提取出来的case描述逻辑词汇识别出来，画出逻辑关系图，再使用决策表或者因果图的用例设计方法，一个功能点尽可能全面的覆盖尽可能多的测试用例：

举例如下：（个人观点，仅供参考，讲得不对也请指出来）
1、 将子功能Case描述中的逻辑关键字提取出来，如：或\或者（or）、和（and）、与（and）、并且（and）、然后（and）、否（not）、不（not）、非（not）、反之（not）、当（if）、如果（if）等，建立起步骤间的逻辑关系。
2、 将子功能Case描述中的句法和语义进行分析，将条件、动作和结果分别识别出来。
比如，F1_SF1_C1就可以被分解成：
<Tap> the keyboard (then) <input> the correct phone number (or) <select> the phone number from contacts (or) <select> it from the call history, (then) <tap> the “Dial” button, [can] make a call.
根据例1，可以画出测试步骤逻辑关系。
  因为例一较简单，所涉及的逻辑层次只有两层，对于有三层以上的情况，将会有更加复杂的逻辑关系图。

用例设计
根据

    测试第一步应是文档先行,而不是拿到软件就开始盲目测试!   

    软件测试的原则之一就是“尽早的进入到软件开发周期中进行测试”。在产品需求设计阶段，测试人员就应该开始介入，一方面是为了参与产品需求设计的验证和确认，从而在软件开发初始阶段降低软件缺陷的发生；另一方面是尽早的理解产品需求，为测试计划的定制和测试用例的设计做准备。

    因此，需求确认阶段的测试用例很大程度上来自于对于产品需求设计文档的理解和解析。但是，由于软件开发面向需求的特性，使实现过程中软件需求不断升级、细化、变更和增加，其所伴随的测试例等也必须随之升级以适应，导致测试任务难度加大，风险升级。

    把握好测试用例的上游产品——需求说明书的质量，就能够尽早的发现问题；通过对需求规格说明书特性的分析，以及测试用例与需求说明书之间关系的分析，就能够很好的建立起测试用例与需求之间的关系，增加测试覆盖率，提高需求文档的编写质量。

需求规格说明书的特点如下：

1.    不含糊的／无歧异性：

   最终产品的每一个特性只用某一术语描述，使用正规化的需求说明语言。

2.    可追踪性

   每一个需求的来源是清楚的

   具有「向后的追踪能力」：每一个需求皆明确的参照到他先前文件的来源

   具有「向前追踪能力」：每一个在SRS中的需求皆具有独一的命名或参照号码。

3.    可验证性

4.    完整性

   对于所有有效或无效的输入值皆必须明确说明软件的响应

   所有在SRS中的图片、表格与图例皆必须具有完整的标示与参照，并且必须定义所有的名词与衡量单位

5.    一致性

   各个需求的描述不矛盾。即所谓的内部一致性

   一个SRS 是具有内部一致性的，则表示没有个别需求描述的子集合是互相冲突的

   SRS 中可能发生的冲突：真实世界的对象的具体特性可能发生冲突；在二个被叙述的行动之间可能有逻辑上的或时间上的冲突；二个或较多的需求可能描述相同的真实世界对象，但却使用不同的术语

6.    可修正性

   SRS的结构和风格是可以修正的

   任何需求的变化皆可以容易地、完全地、和一致地进行，并且保持原有的结构风格具有一个一致、易使用且包含目次 , 索引, 和明确的前后参照的组织不是多余的分开地表达每个需求，而不是与其它的需求相混合。

需求说明书的低级测试技术

完整。是否有遗漏和丢失？完全吗？单独使用是否包含全部内容？

准确。解决方案正确吗？目标明确吗？有没有错误？

精确、不含糊、清晰。描述是否一清二楚？还是自说自话？容易看懂和理解吗？

一致。产品功能描述是否自相矛盾？与其它功能有无冲突？

贴切。描述功能的陈述是否必要？有没有多余信息？功能是否原来的客户要求？

合理。在特定预算和进度下，以现有人力、物力和资源能否实现？

代码无关。是否坚持定义产品，而不是定义其所依赖的设计、架构和代码？

可测试。特性能否测试？测试员建立验证操作的测试错误程序是否提供足够的信息？

需求说明书7个用语检查清单

1.总是、每一种、所有、没有、从不。

看到此类绝对或肯定的切实认定的叙述，可以着手设计针锋相对的案例。

2.当然、因此、明显、显然、必然。

这些话意图诱使接受假定情况。不要中了圈套。

3.某些、有时、常常、通常、经常、大多、几乎。

这些话太过模糊。“有时”发生作用的功能无法测试

4.等等、诸如此类、依此类推。

以这样的词结束的功能清单无法测试。功能清单要绝对或者解释明确。

5.良好、迅速、廉价、高效、稳定。

这些是不确定的说法，不可测试。如果在产品说明书出现，必须要求进一步指明含义。

6.已处理、已拒绝、已忽略、已消除。

这些说法可能会隐藏大量需要说明的功能。

7.如果...那么...（没有否则）。

缺少配套的否则，想一想，“如果”没有发生会怎样呢？

     从上面我们可以看出，需求说明书的这些特定用语都带有逻辑和程度的语义，测试工程师可以通过分析这些语义逻辑关系，再结合因果图和决策表的用例设计方法设计出测试用例来。

     更加深入探究的话，如果一份严格按照一定的规则编写的需求说明书，就能够通过计算机对自然语言的逻辑分析，再结合因果图和决策表的用例设计方法，自动产生出测试用例来。