篇章分析的理论和应用
一、篇章分析的理论


衔接性分析



衔接性：篇章范围内词汇之间的关联。 一个成分的含义依赖于另一成分的解释


连贯性：句子层⾯面的意义关联


篇章的衔接性可以分成两类，前者是借助一系列的语法手段，⽽而后者是词汇手段：



语用学

主要研究人们如何运用语言：

-如何使用语言达成某种目的？——言外行为

-会话含义如何根据话语推导？—合作原则

言外行为理论



合作原则



对话分析

对话分析vs语用学

对话分析关注对话过程中的⼀一连串话语之间的关系



二、篇章分析在中文信息处理中


有歧义的句子如何理解？“能穿多少，穿多少？”

1）在自然语言处理理中，篇章分析被认为是有衔接性和连贯性两个方面，前者目前研究主要集中在词汇链和指代消解；后者的研究主要关注意图

2）目前主要还是通过标注语料库来进行行机器学习训练机器

3）语用学和对话分析不是研究的主要兴趣


中文的处理难点

1）汉语本身的难题：

a. 篇章的基本单位是什么？零句？小句？标点句？

b. 汉语中零形指代使用普遍

2）目前没有⼀一个完善的汉语篇章模型


三、读后感
Li Mian：

机器在进行语篇分析时，要想正确理解语篇含义，需要先识别语篇中起衔接作用的词汇性成分。语篇中起衔接作用的常常为连词、副词、代词、名词等。代词、名词一般表示的是指称义，要进行同指或指代的消解。而连词和副词在上下文中表示的是词义，需要先消除歧义，并进行词义的相似性计算。如何让机器正确理解零形指代和复杂的虚词语义，是汉语语篇分析中的两个难点。在连贯性分析上存在如何界定基本单元的难题。目前，有两种主流的界定方式：一是以小句为基本单元；二是以标点句为基本单元。然而，让机器正确识别小句并不容易。理论上讲，句子和句群关系应该避免再对句子内部的句法结构进行分析，否则就会陷入循环论证的怪圈。

汉语自身还具有诸多特点，如常常省略主要句法成分，常常带有言外之意，常常频繁跳转话题等等，这使汉语语篇分析难上加难，还有待汉语言学家展开更深入的研究。
英俊：NLP实现上下文理解并非无法可循

我们在平常聊天的过程中，如有第三者在中途加入聊天，我们常常需要跟这个新加入的人复述或者补充聊天话题的某些信息，才能让他理解整个聊天的语境。

例如：“他拿了他不该拿的东西”，这句话中的“他”到底是指谁？“他不该拿东西”又是什么东西？这个东西为什么又是“他不该拿”的？

如若没有上下文辅助提供的信息，旁人就无法理解这句话真正的含义。

受现有技术和实际应用场景等各种因素所限，我们公司的NLP现在主要处理的基本对象是语句。但实际上语言不是简单的语句集合，语句之上还有篇章结构，还有跨句回指。研究篇章语言学，有助于深度解析语言，提高机器理解语义的能力。

我认为做篇章理解也可以尝试这样的解法：

逐层处理；

引用李维的话：鉴于自然语言的结构复杂性，语句的深度解析和理解很难在单层的系统一蹴而就，自浅而深的多层管式系统于是成为一个很有吸引力的策略。多层了以后，很多不可解的问题，变得可解了。多层的必要性为的是要有足够的厚度及其动态的中间表达，去容纳从词法分析、实体识别、（嵌套）短语分析、单句分析、复句分析乃至跨句分析（篇章分析）以及从形式分析、语义分析到语用分析的全谱。
找出内部变化的特征。

语篇分析是指超越单个句子范围的各种可能分析，包括句子（语段）之间的关系以及关系类型的划分，段落之间的关系的判断，跨越单个句子的词与词之间的关系分析，话题的继承与变迁等。这些关系可以通过某些显性的特征分析出来：

特征：

	重复出现或相关词出现都是词汇的衔接性表现。通过相同词和相关词的多次出现，将语篇所强调的概念或话题呈现出来。

	语篇中第一次指示实体的名词或名词短语称为先行语（antecedent）。先行语通常会先于代词出现，此时的指代关系也称为回指（anaphora）；在有些情况下，也可能先出现代词，后出现先行语，此时的指代关系则称为预指（cataphoric reference）。

	词汇衔接又表现为词汇重复、同义或近义、反义、上下位义、整体与部分以及搭配六种。具有衔接关系的词可以通过一个链表示，称为词汇链。

Najie：篇章分析可以和工作结合的点

FAQ似乎是以单句较多，和篇章分析能结合的地方不太多。我想到的篇章分析其实不是运用在多轮和上下文中，而是能不能结合机器阅读的技术，实现我们从大量文字材料中提取出关键词（例如实体、属性）甚至是StdQ。

文档当中提到关于实现cohesion的方式：

Devices used to create grammatical cohesion include:

· Conjunction (using ‘connecting words’)

· Reference (using a pronoun to refer to another word)

· Substitution (substituting one word or phrase for another word or phrase)

· Ellipses (leaving something out)

个人感觉conjunction部分，中文可借鉴的不多。中文的连词经常省略，句子和句子之间结构较为松散，可能属于“隐式关系”（P23，中文）。但后面三个部分还是可以借鉴的。

例如中文代词，如果可以实现指代消解，有利于我们统计高频词，可以更好地帮助我们实现篇章理解。

在FAQ中，常出现的pronoun有“你们”（通常指代我们的甲方客户），“我”等，可以做一个关于人称代词的指代频率统计。

关于语用学的方面，定义如下：

Pragmatics is the study of how people use words to accomplish actions in their conversations: actions like requesting, threatening and apologizing.

想到的两方面应用有：

结合intent

可以从语用角度分析我们目前的intent，并在此基础上设计一些批量训练intent的方式。
结合聚类，例如把requesting的归集到一起，提高聚类准确性

需要做到这两方面应用的话，可能需要总结一些语用的规则，尤其是在我们已落地的产品中。如果没有思路的话，可以先大概搭一个框架，然后分析一些用户问来得出初步结论。（可以作为新的实验方向）
Shuyan：如何通过语篇分析来确定意图是NLP的一个难点

不同于那些拥有明确分词、性数格的语言，汉语的语篇分析的难点在于汉语是一种高语境的语言，一句话有很多种表达方式，一句话也可以表达很多隐含的意义，因此对汉语的词句划分和标签化的时候存在着边界难以厘清和单一维度无法覆盖可能出现的语言情况等等现状。

阅读材料里提出了两种确定句子意图的方向，一是按照词的衔接和句的连贯性来理解，二是直接通过对语篇的全文分析来明确其含义。但不管采用哪一种方式，其实都是在模仿人类理解语言文字的过程，或者说试图把人类理解文字的过程用语言，甚至公式描述出来：人在阅读的时候有从后往前理解的，也有从前往后寻找信息的。做NLP的时候就是参考了这样的思考模式，让机器从不同的维度对文字语言进行学习，然后按照统计概率的方式，使程序“学会”了分辨某一类句子所代表的含义。

我们现在能做的，除了要理解nlp大概的工作原理，还可以从两个方面发散思维：一是怎么能在语言学的角度更好地帮助机器学习（具体来说就是各种扩写方法论、算法迭代等等），二是怎么样能结合需求实现工具的进化，从而减轻我们的工作量（比如语料库实体自动替换）。
Fiona：篇章的连贯性/衔接性理论和语用学的结合

将篇章的连贯性/衔接性理论和语用学放到一起来读，最大的感受是，我发现两者的理论是可以结合到一起进行应用的。以前一直觉得篇章语言学和语用学是两个方面的语言学理论，不过其实两者都可以看作是语篇分析，一个是从其语法和语义角度分析上下文的连贯，一个是从意图角度分析话语是什么行为（speech act）。

但是在分析言语行为或意图的时候，我发现无论是目前的理论或者应用，都还比较局限在单个句子上面，整个语篇的上下文连贯的意图和言语行为的分析还比较匮乏。那么是否可以结合语言学篇章连贯的知识，将意图识别和言外行为分析的功能扩大呢？也就是说上下文的连贯不仅是语言层面的连贯，还包括意图的连贯。因为人类的很多对话，其意图和行为也往往是连贯的。举例：

A：你有笔吗？——言外行为：借笔

B：没有，要我帮你跟我旁边的人借一只吗？

A：这太麻烦了。——言外行为：不想麻烦B，但是也可能是比较委婉的试探

如果不结合上下文，单看“这太麻烦了”这句话是不能分析出它的含义和意图的。

我们在测试闲聊机器人的时候，经常会发现，单纯说一句话还好，连着几句围绕一件事情跟它聊，它就聊不动了，这一方面是机器在上下文连贯方面的技术还不足，训练不够，一方面就是没有把用户的意图以连贯的方式去解读，导致机器人的回答只是针对上一句，而不是结合语篇（整个对话）的回答。所以上下文连贯和言外行为分析/意图可以进行结合，尤其可以运用在我们的闲聊的场景中。
Xingxing：

本次读书笔记令我思考很多，回忆起了当初读书时候的许多美好时光。真是一件令人开心的事情。

I	语篇分析

关于语用主义（pragmatics）和会话分析的区别

前者指的是人们的言语行为来完成一定的动作目的，比如请求，威胁或者是道歉。有一定的功能性。而后者着重从社交学的角度，关注社会成员之间人和人之间的互动手段（methods）。

2.Cohesion(衔接)和Coherence（连贯）

这1对也是很有趣的概念区分。Cohesion强调的语言形式上的特征，表现为语法特征和或者语义层面的特征，Coherence应该是更加抽象的一组期望值框架的存在，要求整个段落需要保证的内在意义的一致性。比如说到“穿”，应该出来的是“吃/用/住”这样的动词，或者是“穿”的宾语，如“衣服/鞋子”之类的，而不会出现“宇宙灭亡”之类跟主题毫无相关的内容。

-两者的表现手段的差异

应该说，cohesion的特征会更容易让我们识别和掌握。

Cohesion的常见手段

语法手段：

-连接词（词性上可能是连词，比如，and/but也可能是副词，比如however/furthermore）

-指称语（reference），比如代词，代词在句子中经常先/后出现，来作回指或预指。

-替换（substitution）  似乎用别的实词来替代已经出现得词语

-省略（Ellipses）建立在双方已知的层面上，省略某些语法成分，比如主语/谓语/句子，比如“I think so”,so就指代了前面的一句话。

语义手段：表述有限，基本上可以理解为，基于更广泛的语义范畴的相关性，作者称之为“语义链-lexical chain”,通俗来说，就是基于某一个特定的，达成一致的语境说话，不要“风马牛不相及”。

Coherence

连贯性，基于一个共识的诠释性框架（interpretive framework）来做的。

2.交际手段

熟悉的Grace,再次回顾下他的会话原则：数量原则，质量原则，方式原则和关联性原则。实际的交际中，有时候会为了某一原则，违反别的原则。

II	意图

意图和topic不一样，前者的范畴是句法范畴，要有动词，但是topic的范畴是词语范畴，可以看成讲述某类问题。而这个类，应该是是对句子主语或者是宾语的聚类。
发现意图的部分，有一个疑问点，既然意图不区分句式是疑问句还是陈述句，为什么同样的动作和宾语，匹配到了不一样的意图呢？（当时培训好像讲了，不记得了）

猜想的原因：可能是5000元做了识别；

也有可能在“查”这个意图里，区别了陈述句和疑问句。

III 人工智能中汉语语篇分析的难点

1.单位切分，小句还是标点符号断句的大句。

2. 衔接手段出现很频繁，尤其是指代和省略，给机器学习带来了很大的困难。

3.目前，感觉从词语层面-topic/或者是语法层面的-Intent入手，应该更快一些。

4. 也许训练出属于汉语的语篇分析模型，通过标注的积累，让机器半监督学习。
四、与当前工作结合点


用户log的分析

对于宝贵的用户log,可以聪语言学的角度入手，分析它的语用特征，比如言内行为/言外行为，更好地为扩写提供方向。


复句中的语义研究

对于“如果….那么……”这样的复句，语义的指向往往在某一个分句上，比如前句或者后句，，如果确定了语义指向，直接通过识别连词，就可以直接读取语义所在的分句了。目前我们可以针对转折/并列/因果等复句，探究句子的语义核心小句是在前句还是在后句。


为语料库做支撑

以上2点，可以为语料库的情景库做素材补充，丰富语料扩写。

参考文章：

https://blog.csdn.net/qq_16605855/article/details/75973026
1.口诀

多对多，三张表，关联表两外键

一对多，两张表，多的表加外键

一对一，主键共享，外键唯一

原则尽量避免数据冗余

2.理论

理论上要满足第三范式，但是在实际的开发过程中，有的时候会退到第二范式。

1.第一范式：满足每条巨鹿是唯一的，要有主键，每个列是原子的，不可在分的（相对的）

2.第二范式：在第一范式的基础上，消除对逐渐的部分依赖

3.第三范式：第二范式的基础上，消除传递依赖
示例一 第一范式
如图所示的表，是否满足第一范式，是否有数据冗余，如何修改表，使其规范化



不符合第一范式

（1）表中主键不唯一，修改王五学生编号为1003



（2）表中联系方式还可以再分为邮箱和电话两列，如下图：


示例二 多对多
如图所示，分析该表并作出修改，避免其数据的冗余

如图所示，

分析老师和学生是多对多的关系，故拆分成三张表（学生表、教师表、学生教师关系表），如图所示



使用power designer可以自动生成物理数据模型，帮助建表，图为一句上图的ER图自动生成的数据库表单


示例三 一对多
如图所示，如何优化表格避免其冗余




由于学生和课程表为多对一的关系，所以生成两张表，学生表加外键，如图；


示例四 一对一
以登录系统为例，登陆时，需要账户表（用户名，密码，状态），用户表（用户真实姓名，电话…）很显然，一个用户对应一个账户，即一对一关系；他们可以合并成为一个表，但是为了方便管理（考虑查询速度，以及关系型数据库的特性。）另外为了对业务进行事务隔离操作，将其内容分为两个表表示。

（1）共享主键

见名思意，就是两张表共用主键，主键是一样的，相当于拆分了的一张表，各自保留ID作为主键



（2）外键依赖

在用户表中加入账户表中的ID作为外键，将两张表联系起来


示例五 空间换时间
假设某一购物网站，有商品明细表（id,name,type，typename,price）



商品种类表(id,typename)



那么每次查询，需要对两个表做冗余查询，，为了省事，用一张表来表示，这样空间上冗余了，但是查询时间上变快了

说起数据质量，其实是一个很宽泛的问题，类似于写数据建模一样，是一个抽象概念为主的事情，对于程序员群体来说，总是难以解答和回答的。这里针对数据质量等类似的、在数据仓库平台中必须提及的概念，提供一种解答的思路，就是架构推导理论。

先说一下基本的架构推导理论：架构 = 组件模块+关联关系+约束&指导原则。我们用一张图来解释架构在系统中的作用：



 

从上图可以看出，架构是介于产品和业务之间的桥梁，从任意维度出发，通过架构，能够推导出另一维度的相关信息。因而，架构的推导也有两种思路：自顶向下和自底向上。



 



 

通过这两种方式，我们可以先采用自底向上的方式，来分拆产品描述的细节，总结出初步的观点，再按照程序员的思路进行自顶向下的拆分，最后再进行一轮自底向上的总结，基本上就可以确定一套系统应该有的架构和细节。

说了这么多，其实核心思想很简单，针对任何一类问题，都有两种思考它的方法：自顶向下和自底向上。在此基础上，可以多次组合这两种方法，来得到一个问题完整的多方面回答。

|0x01 从程序员视角看数据质量

那么数据质量应该怎么思考，首先从程序员的角度出发，进行自底向上总结。

第一步，从程序员的日常工作出发。数据仓库工作中，开发占了绝大部分的比重，因此代码规范肯定是非常有必要的，其次应该是具体技术的应用细节，例如注意数据倾斜等问题，再次要对业务的概念非常熟悉，避免与产品思路上的差异，最后就是要熟练应用各种开发工具。把这些事情的各种细节做总结，升华一下概念，就是开发质量。

第二步，从配合人员的工作出发。如果团队稍微大一些的话，肯定有相应的测试或者运维人员，对于我们开发的代码和运行进行配合。例如业务逻辑的二次check、数据的运行结果之间一致性是否有保障，同时如果已开发的过程存在了问题，如何回溯历史数据、优化老代码也属于这个范畴。总结一下，就是需要测试的配合。

第三步，从流程角度出发避免人为失误。基本上正规一些的公司都会强调上线规范，做好数据校验、回滚方案、上下游监控等工作。

第四步，从维护角度出发及时发现问题。数据仓库其实最主要的一个问题，就是针对每一个问题，都要有相应的开发人员来检查问题，因此要有详细的值周规约，能够在第一时间出问题时有人介入。此外还需要配合各种完善的报警与监控平台，针对数据仓库日常的整体状况进行一个全面的监控。

总结这四个细节问题的汇总，可以得到四个角度的回答：易读易扩展易维护；上线无失误；报警及时处理；业务逻辑清晰。这四条其实就可以看作是数据质量的一个大的概念，用一张图来总结更为清晰一些：



 

|0x02 从理论层面看数据质量

虽然说从程序员的角度出发，数据质量的问题描述的已经比较清晰了，但是对于非数据开发的程序员，以及产品和运营人员来说，这些还是有些难以读懂。因此很多时候要求我们用更抽象的角度出发，来进行问题的拆解。

这里常见的描述问题方式，参照CAP与BASE原则，我们可以仿照别人的概念，来组织和细化一个属于我们自己的概念，这里也算是自顶向下思路的一种实现。

从笔者自身的角度出发，我总结了大概八条原则，详情如下：

数据的完整性：数据的完整性比较易于理解，主要作用在数据仓库架构中的数据采集环节中，对应到数据分层理论是DWD层，例如要剔除掉数据的缺失信息，注意采集过程中的数据偏移现象并纠正，等等；
	
数据的准确性：数据的准确性不太常见，但比较关键，例如记录消费金额的信息不能为负值，要加入校验逻辑以防止业务部门的数据修正操作，对应到数据分层理论是DWD层，另外需要引入反作弊系统的支持，过滤掉那些无效的作弊数据，防止统计结果出现偏差，对应到数据分层理论是ODS层，；
	
数据的一致性：数据的一致性主要作用在离线开发环节中，对应的数据分层理论是DWS层，针对同一主题下的数据统计，确保统计的数据源是一致的
	
数据的及时性：比较完整一些的数据平台都包括了实时数据统计、小时级数据统计及天级数据统计，其实数据准时产出也算是数据质量原则的一部分，应该每天早上8点统计好前一天的数据，如果你延迟到了10点，肯定会有很多客户投诉你，尽管数据是准确的，但这种引起客户投诉的情况，也需要归到数据质量原则中来；
	
数据的安全性：假设团队规模较大，涉及了多个业务线的数据，那么权限与安全问题也需要值得注意，因为消费金额这一类的数据，在任何一家公司都属于敏感信息，在对外暴露时需要做脱敏的处理，提供点击展现等信息也应该有权限申请的步骤，这个环节既可以作用在数据分层理论的ADS层，也可以作用在DWS层；
	
数据的自查性：数据仓库并不是说我开发好了，就放在那里不管了，也不能说我需要指定一个人，天天去盯着有没有问题，数据仓库的架构中应该有对自身运行情况自动检查的特性，作用在数据分层理论的ADS层，例如在重点步骤之后添加校验环节，统计同比/环比信息，波动过大时主动报警等；
	
数据的周期性：数据质量不仅与开发过程密切相关，也与存储数据的硬件息息相关，在很多场景下，由于服务器资源的有限增长与数据资产的无限增加，必然到了一定的时间就会产生成本压力，因此定期删除无用数据，针对一些冷门数据做极限压缩，都是有效保障数据长期稳定运行的基石；
	
数据的可追踪性：数据的可追踪性，与元数据平台的搭建息息相关，可以说因为有了元数据平台，能够看到每一个过程的上下游血缘信息，因此在排查问题时，能够快速及时定位出问题的步骤，这非常关键。
|0x03 从架构的环节看数据质量

但其实总结出理论还是很抽象，一些Boss或者Leader会要求你结合具体的场景来解释这些概念，这个时候从一次普通的业务开发出发，完整的阐述从数据采集、同步、开发，到最后的数据展现，我们都做了哪些事情，就十分有必要了，这也是从架构角度看数据质量如何保障的具体实现。

首当其冲的是业务信息的变更，例如增加某种统计字段，或者是重新改变某种指标的计算方式。业务信息的变化不仅是需要开发人员的主动介入，也需要平台工具的相关支持。例如Mysql数据库表发生信息变更时，通过Canal等组件可以感知数据表的DDL变化情况，离线根据DDL信息变更对应Hive表的信息。

其次是代码提交的校验环节，因为数据质量是一个很冰冷的词汇，代码出了问题就是质量不好，因此如何最大程度上避免人为错误，就成了数据质量保障的重要工作。

还是两个方面的思路，一个是交叉检验，既然一个人容易出问题，那么两人及以上来校验，出错的概率就会大幅降低，因此需要搭建一个可行的测试环境，如果没有，可以在线上平台搭建一个相同的测试表，导入少量的数据，这时安排测试人员介入逻辑的检查，并且做相应的回归测试。

另一个是进行静态的SQL代码检查，针对大表扫描、空值校验等检查，提示开发人员对应的错误风险。在数据采集环节，还可以加入一些与具体业务紧密相连的监控规则，例如订单拍下时间不大于当天时间，等等。

再次是搭建一些机制完善的辅助平台，例如可以调整任务优先级的调度平台，例如可以准时发现问题并提醒的报警平台，例如可以检测任务依赖死锁的开发平台，等等，针对数据的延迟监控、作业调度的合理性等情况做辅助的技术保障。

最后是要有完善的开发组织工作，针对每一次出现的数据故障，都得安排对应的事件回顾，每周安排例行会议进行典型开发代码的Code Review，有详细的数据问题应对手册以供新入职的开发人员熟悉，等等。

|0x04 数据资产评估

既然提到了数据质量，那么质量便有好坏的区分，像数据平台百万级的数据表，总有高质量与低质量的区分，这时候需要进行相应的数据资产评估，高质量的表需要更高的优先级来进行处理。

|0xFF 如何评估数据质量

这里提供一些常见场景：

通过数据资产评估体系，制定高、中、低三种数据标准，以季度为周期，统计三种标准问题次数；
	
规定详细的数据产出时间，假设数据产出延时，计算延迟时间及问题，并进行记录；
	
通过产品、客户、数据使用人员及配合部门反馈意见，发现数据不一致等问题，及时反馈，确认后计入问题清单；
	
通过监控及报警平台，统计每日异常信息，分类产出报告；
	
针对每位开发人员，测试人员检查发现问题后，如果确认问题存在，计入开发问题，最后汇总常见问题场景；
	
定期扫描开发代码，发现问题及时发出报警。

软件测试理论知识总结

.梳理知识点

1、白盒测试的四个原则
    保证一个模块中所有的路径至少被测试一次
	所有逻辑值都要测试真和假两种情况
	检查程序内部数据结构是否有效
	在上下边界及可操作范围内运行所有的循环

2、黑盒测试的优点
            从产品功能角度测试可以最大程度满足用户的需求
			相同的动作可以重复执行，最枯燥的部分可以由机器完成
			依据测试用例针对性的找寻问题，定位更为准确，容易生成测试数据，
			将测试直接和程序系统要完成的操作相关联

3、黑盒测试缺点
			代码得不到测试
			规格说明书设计有误，很难发现
			测试不能充分进行
			结果却决于测试用例设计

4、黑盒测试方法
等价类划分法
			边界值
			因果图
			判定表
			场景法
			功能图
			错误推测法
			正交表设计法

5、测试用例的内容
测试用例的编号
		测试日期
		测试用例设计人员和测试人员
		测试用例的优先级
		测试标题
		测试环境
		输入数据/动作
		测试操作的步骤
		测试的预期结果

6、测试用例的文档资料
软件需求说明书
	软件设计说明书
	软件测试需求说明书
	成熟的测试用例

7、黑盒测试设计用例主要目的是什么？
检查功能是否实现或者遗漏
	检查人机交互界面是否出错
	数据库读取，更新操作出错
	性能特性是否满足

8、单元测试主要测试8点

程序语法检查、程序逻辑检查、模块接口测试、局部数据结构测试、路径测试、边界条件测试、错误处理测试、代码书写规范检查

9、功能测试

一般可归为界面、数据、操作、逻辑、接口等几个方面

10、功能测试的重点

整体性和重点性

重点性
			确认每个功能是否都能正常使用，每项功能符合实际要求
			是否实现产品规格说明书的要求
			是否适当接受输入数据而产生正确的输出结果
			用户界面测试、是否有相应的提示框、适当的错误提示
			系统界面是否清晰、美观
			菜单、按钮操作正常、灵活、能处理一些异常的操作
			是否能接受不同的数据输入
			数据输出结果准确，格式清晰，可以保存和读取
			功能逻辑清晰、符合使用者的习惯
			系统对各种状态按照业务逻辑而变化，报纸稳定
			支持各种应用环境，能配合多种硬件周边的设备，与外界的应用系统接口有效
			软件升级后，能继续支持旧版本的数据

11、 请详细说明 Web 翻页功能测试的方法主要包括的内容。

A．首页、上一页、下一页、尾页。
		★ 有无数据时控件的显示情况； 
	    ★ 在首页时，首页和上一页是否能点击； 
	    ★ 在尾页时，下一页和尾页是否能点击； 
	    ★ 在非首页和非尾页时，四个按钮功能是否正确； 
	    ★ 翻页后，列表中的记录是否仍按照指定的排序列进行了排序。 
B．总页数，当前页数 
				★ 总页数是否等于总的记录数/指定每页条数； 
 			★ 当前页数是否正确。 
C．指定跳转页 


		★ 是否能正常跳转到指定的页数； 
	    ★ 输入的跳转页数非法时的处理。 
    D．指定每页显示条数 

				★ 是否有默认的指定每页显示条数； 
			    ★ 指定每页的条数后，列表显示的记录数，页数是否正确； 
			    ★ 输入的每页条数非法时的处理。

12、请详细说明搜索功能测试的方法主要包括的内容。对于搜索功能，主要通过以下八点测试：
		1． 页面检查； 
	    2． 默认条件搜索； 
	    3． 修改可选条件搜索； 
	    4． 修改输入条件搜索； 
	    5． 修改区间条件搜索； 
	    6． 组合可选、输入条件搜索； 
	    7． 操作后检查搜索条件及查询结果； 
	    8． 错误、空记录搜索。

13、系统测试实用技术

系统测试类型
				功能测试
				性能测试
				负载测试
				容量测试
				安全测试
				用户界面测试
				配置测试
				安装测试
				回归测试等

14、	测试策略应包括如下内容：
		★ 要进行的测试类型和测试目标； 
	    ★ 进行测试时要采用的技术； 
	    ★ 对测试的结果制定标准； 
	    ★ 对测试过程中所出现问题存在的影响的特殊事项； 
	    ★ 进行系统测试的对是应是完整的、集成的计算机系统； 
	    ★ 按照设计说明书的规定，逐项测试系统的功能．性能等特性。

15、系统测试方法比较多的，常用的方法是？

多任务测试

临界测试

中断测试 —人为中断、硬件中断、程序执行中断、意外中断

16、验收测试的目的主要是：

★ 新建系统产品是否是按照用户需求开发的，体验该产品是否能够满足用   户使用要求、

有没有达到原设计水平、完成的功能怎样；

★ 对照合同的需求进行验收测试，是否符合双方达成的共识；

★ 新建系统产品的可靠性和可维护性好不好？

★ 新建系统产品通过运行的结果表明，对业务处理的能力；

★ 新建系统产品对用户操作的容错能力；

★ 新建系统产品新系统对系统运行时发生故障的恢复能力；

★ 承建单位向业主单位提交的有关技术资料是否俱全。
17、请列举验收测试过程中所涉及到的相关文档。

测试过程中涉及到的文档有：
				 1. 测试任务说明书； 
			    2. 测试计划说明书； 
			    3. 测试用例说明书； 
			    4. 测试报告说明书； 
			    5. 测试总结说明书； 
			    6. 测试验收说明书； 
			    7. 缺陷跟踪报告说明书。

18、1. 配置测试的目标都有哪些？

★ 验证应用程序（即，确定它是否满足了它的配置要求）。

★ 确定配置问题的软件出错。

★ 帮助识别那些不能有效地在单元和集成测试发现的一些缺陷。

★ 决定增加或修改，如硬件资源的影响：内存、磁盘和磁带资源、处理器、负载均衡。

★ 确定最佳的系统配置。
19、进行配置测试需要以下几个前提条件：

★ 进行配置测试的需求分析已经完成。

★ 已完成应用程序的多个版本。

★ 相关的软件组件已通过单元测试。

★ 软件集成测试已经进行，但在配置测试开始之前软件组件必须已经安装在被测硬件

设备上。

★ 相关系统组件已通过系统集成测试。

★ 在独立的测试小组配备足够的人员进行配置测试和训练。

★ 配置测试环境准备完成。
20、配置测试的目标是为了使软件在尽可能多的硬件平台上运作，那么进行配置测试一般需

要测试它的硬件环境和软件环境。

1．硬件环境

硬件环境主要包括：

★ 不同的主机；

★ 不同的组件；

★ 不同的外设；

★ 不同的接口以及可选项的测试。

2．软件环境

软件环境包括：

★ 对操作系统平台的兼容测试；

★ 对同一操作系统平台不同版本的测试；

★ 软件自身向前向后更新操作时的测试；

★ 同其他软件产品兼容性测试以及数据兼容性（主要是数据共享）的测试。

21、请说明接口测试的目的。

接口测试（Interface-Testing）的目的是：

 测试系统相关联的外部接口；

 测试的重点是要检查数据的交换；

 传递和控制管理过程；

 提高测试质量；

 提高测试覆盖；

 更好地重现软件缺陷；

 更好定位错误。
22、接口测试的测试项目主要包括以下几点：

1．数据类型问题
			 	 ★ 变量的数据类型是否错误 ； 
	        	★ 是否存在不同数据类型的赋值； 
	      	 	 ★ 是否存在不同数据类型的比较。 
2．变量值问题 
	  		 ★ 变量的初始化或缺省值是否有错误； 
	        ★ 变量是否发生上溢或下溢； 
    		★ 变量的精度是否足够。 
3．逻辑判断问题 
            ★ 是否由于精度原因导致比较无效； 
            ★ 表达式中的优先级是否有误 ； 
            ★ 逻辑判断结果是否颠倒。 
4．文件 I/O 问题 
            ★ 对不存在的或者错误的文件是否进行操作； 
            ★ 文件是否以不正确的方式打开； 
            ★ 文件结束判断是否正确； 
            ★ 是否正确地关闭了文件。