昨天在搭建测试环境过程中安装完weblogic9.2后，发现启动服务报错后台错误提示：weblogic.management.ManagementException: [Management:141266]Parsing Failure in config.xml: javax.xml.namespace.QName; local class incompatible:
          stream classdesc serialVersionUID = 4418622981026545151, local class serialVersionUID = -9120448754896609940

折腾来快3小时最后终于搞定了，原因是：服务器上jdk的版本和某些类有冲突

解决办法：在startWeblogic.cmd(或startWeblogic.sh)文件中设置JAVA_OPTIONS的地方添加(注意是在一行的，中间用空格隔开)：
set JAVA_OPTIONS=%SAVE_JAVA_OPTIONS% -Dcom.sun.xml.namespace.QName.useCompatibleSerialVersionUID=1.0

备份:
第一种方法:   mysqldump

备份一个表 mysqldump  -h主机名  –u用户名 –p口令 数据库  表名 >文本文件
                恢复: mysql   -h  主机名 –u用户名 –p口令 数据库 <文本文件
备份一个数据库中的两个表或是多个表怎么办?
  Mysqldump –h 主机名 –u用户名 –p口令 数据库 表名1 表名2  >文本文件
 恢复的时候: mysql –h 主机名 –u用户名 –p 口令 数据库<文本文件

备份整个数据库:
格式: mysqldump –u用户名  -p密码 数据库名>文本文件名
如:C:\test>mysqldump -uroot -p111111 net14  >net14.txt

删除数据库net14:         drop database net14
进行恢复:
C:\test>mysql -u root  -p111111 net14<net14.txt
ERROR 1049 (42000): Unknown database 'net14'
报错.说找不到数据库net14;
必须先手工建立一个空的net14数据库,然后才能把数据导进来!
C:\test>mysql -u root  -p111111 net14<net14.txt

那还有一个问题,如果想同时备份两个以上的数据库怎么办?
格式: mysqldump –u用户名  -p密码  -B 数据库1   数据库2 >文本文件名
如:    C:\test>mysqldump -uroot -p111111 -B net14 net28  >net1428.txt
然后删除net14和net28再进行恢复
但是要注意:必须一个一个的恢复,不能同时恢复两个:
如: C:\test>mysql -uroot -p111111 -B net14   <net1428.txt
C:\test>mysql -uroot -p111111 -B net28   <net1428.txt

第二种方法:  select into 作备份:这相对于第一种方法就简单多了!
格式:  select 语句 into outfile “路径及文件名”;
如: mysql> select * from student into outfile 'c:\\abc1.txt';
Query OK, 13 rows affected (0.00 sec)
注意:
1.路径中的盘符后是两个\\,其中第一个代表转义作用,第二个才是代表根目录.有时写成一个\时不会报错,因此要注意检查备份的正确性;
2.不允许重写文本文件;
恢复方法:
那么怎么恢复呢::
用LOAD DATA来恢复:
格式: load data infile ‘路径及文件名’ into table 表名
如: load data infile 'c:\\student.txt' into table student;
注意:表必须存在.可用delete,清空其中的所有记录 或者用: truncate 表名,只删除记录,不删除结构!
如果恢复出错怎么办?
1. 权限问题.
2. 分界符不匹配!
3. 路径和文件名不对!
十一、数据的导入/导出：
如何与其他数据源之间进行数据的导入与导出!
例如:如何将  SQL server 的数据导到mysql中来
1. 先在MS SQL 2000的导入导出工具将数据导出成*.txt文件格式
注意打开backup.txt
观察其中的分隔字符 MS SQL 2000好像是用逗号分隔的
2. 在mysql中利用 load data infile 命令导入
mysql> load data infile 'c:\\sql.txt' into table abc fields terminated by ',';
Query OK, 5 rows affected (0.00 sec)
Records: 5  Deleted: 0  Skipped: 0  Warnings: 0
注意  目标表必须已经存在,并结构要与源表的结构相同!
ACCESS 导到 MYSQL：
1． 先建立一个access文件，保存成文本文件
2． 打开文本文件，再转换一下编码成ansi
3． 建立数据库，导入到mysql中！
mysql> load data infile 'c:\\abc1.txt' into table abc fields terminated by ',';
Query OK, 3 rows affected (0.00 sec)
EXCEL 导到mysql
 步骤同上。只是要注意的是：excel默认是以 TAB 分隔的所以应用以下的语句：
mysql> load data infile 'c:\\book1.txt' into table abc fields terminated by '\t';

1)     赋予一个人员相应的权限后，在界面上看此人员是否具有此权限，并以此人员身份登陆，验证权限设置是否正确（能否超出所给予的权限）；

2)     删除或修改已经登陆系统并正在进行操作的人员的权限，程序能否正确处理；

3)     重新注册系统变更登陆身份后再登录，看程序是否能正确执行，具有权限是否正确；

4)     在有工作组或角色管理的情况下，删除包含用户的工作组或角色，程序能否正确处理；

5)     不同权限用户登录同一个系统，权限范围是否正确；

6)     覆盖系统所有权限设定；

7)     能否添加信息为空的用户(其中包括空用户名及空口令、空用户名非空口令、非空用户名及空口令)；

8)     能否添加长用户名及长口令，如果允许，新用户能否正确登录；

9)     系统是否允许删除系统管理员这一特殊用户或修改系统管理员口令，删除或修改后系统的实际情况；

10)  登录用户能否修改自己的权限；

11)  添加用户（有标识或编号）:标识相同，用户名不同；标识相同，用户名相同；标识不同，用户名相同；标识不同，用户名不同；

12)  登录用户能否修改本人（或其他人）的信息，删除本人（或其他人）；

13)  修改用户的信息（包括权限，口令，基本信息等），对其他模块的影响；

14)  修改用户信息：修改后的用户信息和已经存在的用户信息相同；修改后的用户信息和已经存在的用户信息不同；

15)  不给用户授权，是否允许登录；

15)  改某些设置时，是否会影响具有上级权限及相同权限人员的设置；

16)  系统管理员修改了某些数据，以其他人员身份登录时数据是否改变；

17)  用户能否同时属于多个组，各个组的权限能否交叉；

1 、 熟悉需求背景及商业目标：

a)   了解清楚项目发起的原因，是为了解决用户的什么问题。

b)   当前的解决方案是不是最优的，为什么会这样做。

2 、业务模型法：

a)  考虑本项目与外部系统的交互，划分系统边界（除了本项目的需求中要求做的事情，其他的都可以是外部系统，本系统和外部系统之间的交互就是系统的边界），。可以参考系统分析说明书。

b)  确定测试范围和关注点。系统的边界是测试的重点，特别需要关注边界交互时的数据交互。

3 、业务场景法：

a) 考虑用例的调用者；考虑每一个用例提供的服务是供哪些外部用例或者系统调用，找出所有的调用者。调用的前提、约束都要考虑。每一个调用都可以考虑成一个大的业务流程。（一般和外部有交互的用例出错的概率比较大，需要重点关注。具体被哪些外部调用，每个产品线都需要自己整理添加。）

b) 考虑系统内部各个用例之间的交互（有可能 PD 划分用例的粒度不同，我们暂时考虑用户一次提交并且系统的状态及数据发生变化的功能是一个用例），形成内部业务流程图。需要分析每个用例之间的约束关系、执行条件，组织出各种业务流程图。

4 、功能分解法（对每一个 UC ）：

  1. 业务功能：与用户实际业务直接相关的功能 或细节。

  2. 辅助功能：辅助完成业务功能的一些功能或者是细节，比如，设置过滤条件。

  3. 数据约束：功能的细节，主要是用于控制在执行功能时，数据的显示范围、数据之间的关系等。

  4. 易用性需求：功能的细节，产品中必须提供了，便于功能操作使用的一些细节，比如快捷健就是典型的易用性需求。

  5. 编辑约束：功能的细节，在功能执行时，对输入数据项目的一些约束性条件，比如只能输入数字。

  6. 参数需求：功能的细节，在功能中，需要根据参数设置不同，进行不同处理的细节。

  7. 权限需求：功能的细节，这里的权限是指在功能的执行过程，根据根据不同的权限进行不同处理的，不包括直接限制某个功能的权限。

当一个测试人员证实了程序里充满bug的时候，他是一个好的还是一个糟糕的测试人员呢？在某些开发人员看来，这是一份糟糕的工作。看上去荒谬可笑，因为项目经理等人会因产品的延期交付而责备测试人员，而且开发人员会抱怨（通常是以玩笑的形式）：“测试人员对于程序过于较真。”因此很明显的，还有比计bug数更好的测试方法。这里是一些测试人员如何应对开发人员的小窍门。

当我作为一个测试人员开始我的工作时，我意识到在开发人员和测试人员之间存在一种持久的对抗关系，而且我毫不费力的相信了：这太常见了！我接受开发人员不欢迎的态度，因此我认为所有的测试人员在他们工作的不同时刻都会有相同的经历。从冷漠的不屑一顾到坦白的敌对相视（有时掩饰以同情的微笑），一个测试人员不得不忍受开发人员很多。这样很难保持测试人员积极的态度。但我们测试人员积极的态度取决于我们保持的优先权和保证项目质量的责任。我从Cem Kaner的《计算机软件测试》一书中摘得一句优美的话：“最好的测试人员不是发现了最多个bug或者使最多的开发人员感到不安的那个人，而是使开发人员fix最多bug的那个测试人员。”那么，我们从中能得到什么样的启发呢？

态度诚恳，有耐心。

作为一个测试人员，你也许发现说服一个开发人员修改你发现的缺陷比你发现缺陷本身更难。通常情况是，测试人员发现一个bug，开发人员会准备好十个理由来反驳。对于开发人员而言。有时很难接受自己的代码有缺陷这一事实——即便是另外一些人已经查明确实如此。开发人员需要测试团队的支持，他们能说服开发人员发现一个新的bug，对于尽可能使产品达到最好这一目的，是想望的、具有建设性的并且是非常重要的。采用一种人性化的方式，将更有利于测试人员了解开发人员。相信我，没有这样的一个人会和你坐在一起嘲笑他自己引出的bug。诚恳地态度常使开发人员说：“是吗？多亏你的bug报告，我得到一个非常重要的进步！”

要善用交际手段。

试着机智圆滑的展示你发现的bug并不带任何抱怨的解释它：“我肯定这是一个很小的bug，你会马上解决掉它。这是迄今为止非常完美的程序。”开发人员会非常欢迎解决它。

要善于采取心理战术，

时不时地赞美开发人员的工作。大多数开发人员不喜欢我们的bug报告的原因很简单：他们认为我们破坏了他们的辛勤劳动的成果。一些测试人员在只有发现问题的时候才与开发人员交流。对于开发人员而言，软件就像自己的孩子，而你测试人员只是一个外来的干预者。我告诉我的开发人员因为他们我才能留在公司，并且因为我，他们工作上的失误才能得以补救。这是在开发人员和测试人员之间的一种具有象征意义并且非常有益的关系。

不要使开发人员不安。

没有人喜欢别人指出自己的错误，这是人的本性。试着解释fix某个bug的具体办法，譬如需要一个大的图片，远比自顾自的提一大堆bug报告好的多。一大堆的缺陷报告不仅不能使开发人员着急，还会使你的辛苦工作在他们看来毫无用处。就像测试人员不能对程序测试完全一样，开发人员也不可能设计出没有错误的程序。他们比需要其他事情更强烈的需要测试人员的理解。我们期望出现错误，因为他们是整个过程的一部分。

有得必有失

我知道测试人员尽可能的将bug报告提的很严格。他们甚至不去听取开发人员关于这个bug不能fix或者是为了实现某个特性的解释。试着让自己放松下来，坐下来和开发人员一道分析这个bug的优先级和严重程度，如果这个开发人员对于不乐意修改这个bug有合理的和明智的解释的话，试着去理解他。只是要确保哪里是保证产品质量的底线。

警惕心理

外交手段和弹性应对并不能替换必需的警惕心理。开发人员经常找理由解释他们拒绝fix一个bug时，说因为他们没有意识到（或者你没有告诉他们）这个问题有多严重。设计你的bug报告和测试文档，使其能清楚地显示出问题的风险和严重程度。甚至更好的办法是召开一次会议，向开发人员解释这个bug。一个聪明的测试人员是一个在聆听与表达之间取得一个平衡的人。如果一个开发人员不能说服你不fix一个bug时，说服他fix这个bug就是你义不容辞的责任了。

一、JTEST

1、简介：

jtest是parasoft公司推出的一款针对java语言的自动化白盒测试工具,它通过自动实现java的单元测试和代码标准校验,来提高代码的可靠性。Jtest先分析每个java类，然后自动生成junit测试用例并执行用例，从而实现代码的最大覆盖，并将代码运行时未处理的异常暴露出来；另外，它还可以检查以DbC（Design by Contract）规范开发的代码的正确性。用户还可以通过扩展测试用例的自动生成器来添加更多的junit用例。Jtest还能按照现有的超过350个编码标准来检查并自动纠正大多数常见的编码规则上的偏差，用户可自定义这些标准，通过简单的几个点击，就能预防类似于未处理异常、函数错误、内存泄漏、性能问题、安全隐患这样的代码问题。

2、优势：

1）使预防代码错误成为可能，从而大大节约成本，提高软件质量和开发效率

2）使单元测试——包括白盒、黑盒以及回归测试成为可能

3）使代码规范检查和自动纠正成为可能

4）鼓励开发团队横向协作来预防代码错误

3、特征：

1）通过简单的点击，自动实现代码基本错误的预防，这包括单元测试和代码规范的检查

2）生成并执行junit单元测试用例，对代码进行即时检查

3）提供了进行黑盒测试、模型测试和系统测试的快速途径

4）确认并阻止代码中不可捕获的异常、函数错误、内存泄漏、性能问题、安全弱点的问题

5）监视测试的覆盖范围

6）自动执行回归测试

7）支持DbC编码规范

8）检验超过350个来自java专家的开发规范

9）自动纠正违反超过160个编码规范的错误

10）允许用户通过图形方式或自动创建方式来自定义编码规范

11）支持大型团队开发中测试设置和测试文件的共享

12）实现和IBM Websphere Studio /Eclipse IDE 的安全集成

4、价格：昂贵

二、JMETER

1、简介：

JMeter是Apache组织的开放源代码项目，它是功能和性能测试的工具，100%的用java实现。使用JMeter进行性能测试

2、特征：

JMeter可以用于测试静态或者动态资源的性能（文件、Servlets、Perl脚本、java对象、数据库和查询、ftp服务器或者其他的资源）。JMeter用于模拟在服务器、网络或者其他对象上附加高负载以测试他们提供服务的受压能力，或者分析他们提供的服务在不同负载条件下的总性能情况。你可以用JMeter提供的图形化界面分析性能指标或者在高负载情况下测试服务器/脚本/对象的行为。

3、价格：未知

三、JUNIT

1、简介：

JUnit是一个开源的java测试框架，它是Xuint测试体系架构的一种实现。在JUnit单元测试框架的设计时，设定了三个总体目标，第一个是简化测试的编写，这种简化包括测试框架的学习和实际测试单元的编写；第二个是使测试单元保持持久性；第三个则是可以利用既有的测试来编写相关的测试。

2、优势：

2.1)junit是完全Free的。

2.2)使用方便。在你提升程序代码的品质时JUnit测试仍允许你更快速的撰写程序 那听起来似乎不是很直觉，但那是事实。当你使用JUnit撰写测试，你将花更少的时间除虫，同时对你程序代码的改变更 俱有信心。这个信心让你更积极重整程序代码并增加新的功能。没有测试，对于重整及增加新功能你会变得没有信心；因为你不知道有甚么东西会破坏产出的结果。采用一个综合的测试系列，你可以在改变程序代码之后快速的执行多个测试并对于你的变动并未破坏任何东西感到有信心。在执行测试时如果发现臭虫，原始码仍然清楚的在你脑中，因此很容易找到臭虫。在JUnit中撰写的测试帮助你以一种极 大(extreme)的步伐撰写程序及快速的找出缺点。

2.3)JUnit非常简单撰写测试应该很简单--这是重点！如果撰写测试太复杂或太耗时间，便无法要求程序设计师撰写测试。使用JUnit你可以快速的撰写测试并检测你的程序代码并逐 步随着程序代码的成长增加测试。只要你写了一些测试，你想要快速并频繁的执行测试而不至于中断建立设计及开发程序。使用JUnit执行测试就像编译你的程序代码那么容易。事实上，你应该执行编译时也执行测试。编译是检测程序代码的语法而测试是检查程序代码的完整性(integrity)。

2.4)JUnit测试检验其结果并提供立即的回馈。 如果你是以人工比对测试的期望与实际结果那么测试是很不好玩的，而且让你的速度慢下来。JUnit测试可以自动执行并且检查他们自己的结果。当你执行测试，你获得简单且立即的回馈； 比如测试是通过或失败。而不再需要人工检查测试结果的报告。

2.5)JUnit测试可以合成一个测试系列的层级架构。 JUnit可以把测试组织成测试系列；这个测试系列可以包含其它的测试或测试系列。JUnit测试的合成行为允许你组合多个测试并自动的回归(regression)从头到尾测试整个测试系列。你也可以执行测试系列层级架构中任何一层的测试。

2.6)撰写JUnit测试所费不多。 使用Junit测试框架，你可以很便宜的撰写测试并享受由测试框架所提供的信心。撰写一个测试就像写一个方法一样简单；测试是检验要测试的程序代码并定义期望的结果。这个测试框架提供自动执行测试的背景；这个背景并成为其它测试集合的一部份。在测试少量的投资将持续让你从时间及品质中获得回收。

2.7)JUnit测试提升软件的稳定性。 你写的测试愈少；你的程序代码变的愈不稳定。测试使得软件稳定并逐步累积信心；因为任何变动不会造成涟漪效应而漫及整个软件。测试可以形成软件的完整结构的胶结。

2.8)JUnit测试是开发者测试。 JUnit测试是高度区域性(localized)测试；用以改善开发者的生产力及程序代码品质。不像功能测试(function test)视系统为一个黑箱以确认软件整体的工作性为主，单元测试是由内而外测试系统基础的建构区块。开发者撰写并拥有JUnit测试。每当一个开发反复(iteration)完成，这个测试便包裹成为交付软件的一部份提供一种沟通的方式，「这是我交付的软件并且是通过测试

2.9)JUnit测试是以Java写成的。 使用Java测试Java软件形成一个介于测试及程序代码间的无缝(seamless)边界。在测试的控制下测试变成整个软件的扩充同时程序代码可以被重整。Java编译器的单元测试静态语法检查可已帮助测试程序并且确认遵守软件接口的约定。

一段测试的程序代码无法单独的执行，它需要是执行环境的一部份。同时，它需要自动执行的单元测试--譬如在系统中周期性的执行所有的测试以证明没有任何东西被破坏。由于单元测试需要符合特定的准则：一个成功的测试不应该是人工检查的（那可要到天荒地老了啊），一个未通过测试的失败应可以产出文件以供诊断修改。而Junit可以提供给我们这些便利.。这样所有测试开发者所需撰写的只是测试码本身了。跟optimizeit、Jtest那些昂贵而又超级麻烦的tool比较起来，其利昭然可见！

导出表:
exp scott/tiger@mycon tables=(dept,emp) file=tab1.dmp
导出用户:
exp system/manager@mycon ōwner=scott file=usr1.dmp
导出数据库:
1.完全导出
exp system/manager@mycon full=y inctype=complete    file=full1.dmp
2.增量导出
exp system/manager@mycon full=y inctype=incremental file=inc1.dmp
3.累积导出
exp system/manager@mycon full=y inctype=cumulative file=cum1.dmp

imp example:
导入表:
imp system/manager@mycon file=c:\tab1.dmp tables=(dept,emp) touser=scott
导入用户:
imp system/manager@mycon file=usr1.dmp fromuser=scott touser=scott
导入数据库:
1.全库导入
imp system/manager@mycon file=full1.dmp full=y
2.增量导入
1)导入数据库最新信息
imp system/manager@mycon inctype=system full=y file=inc7.dmp
2)导入最近完全导出文件
imp system/manager@mycon inctype=restore full=y file=full1.dmp
3)导入所有累积导出文件
imp system/manager@mycon inctype=restore full=y file=cum1.dmp
4)导入最近一次增量导出的文件
imp system/manager@mycon inctype=restore full=y file=inc1.dmp

影响测试进度的原因有:

1、研发进度是否正常，是否正常按计划提交研发成果.

2、用户需求的频繁变更和变动影响范围，最根本原因是用户需求没有做好.

3、测试的资源缺乏，如：测试时间、测试环境、人力。

4、测试人员和开发人员的技术、沟通技能是否符合项目的要求

5、测试人员发现有效bug的情况

6、项目经理对整个项目的工作安排和计划是否合理，管理是否有效，是否人员流动频繁

7、项目的难度因素

8、用户的配合程度

我个人认为的解决方案如下,欢迎大家一起讨论啊:

第1种情况:按实际情况,合理调整开发进度和测试进度,这不是测试能把握住的,是需要由项目经理来把握.

第2种情况:需求没有做好,导致后期变更频繁,这需要加强需求调研人员的能力,同时做好需求变更的管理,怎么做好需求变更的管理?这个可以做为下一个题目来讨论

第3种情况:测试资源缺乏,时间不够,人力不够,那就只能加班,那就只能舍去不是特别重要的测试用例,确保优先级别高的功能或业务能够正常使用.测试环境没有,那就先在开发环境下跑并及时向领导汇报工作上碰到困难,汇报没有测试环境测试会出现的风险.

第4种情况:技术不行,就培训,没钱培训,就换适合的人来做.

第5种情况:测试发现的BUG不是有效BUG,就反省测试用例,测试负责人要加强所测试系统的业务理解,指导测试人员.测试人员要加强对BUG的理解,提高测试水平.

第6种情况:测试只能反馈情况,这个由项目经理来控制.

第7种情况:用最能干的人才来做,需要集体智慧和劳动才行.

第8种情况:这需要项目负责人和用户沟通,取得用户的信任和配合,这也不是测试能把握住的.

由上述可知:只有第3,4,5项原因是测试可控的,其它测试是不可控的;可想而知,要想把握好测试的进度是要看具体情况具体分析的了.....

若你想成为优秀的测试项目管理者，你就反思如下内容是否做到：
1) 在一个项目中多与开发和产品负责人讨论并了解变化，因为我们的规范永远不能保证测试的输入没有遗漏；
2) 在一个项目中多参与测试方案、测试用例、测试方法、测试工具、测试过程、测试结果的评审与讨论，弥补下属或者自己考虑不周全的问题；最好可以请开发负责人参加；
3) 在一个项目中多考虑测试效率和测试效果的问题，这样可以不断启用新的测试方法和测试流程来提高效率、保证测试效果；
4) 在一个项目中多多进行阶段小结，这样可以弥补一些测试不足的地方，并很好地规划下一个阶段的计划；测试计划不是一成不变的，必须定期调整；
5) 在一个项目中涉及到变更时，要再次评审测试方案、测试用例、测试方法、测试工具；若频繁变更，则更要把握好节奏；
6) 在一个项目中要非常重视组件/模块的接口测试、集成测试，不仅表现在方案、用例上，同时也表现在测试时间的安排和人的协调管理上；
7) 在一个项目中要非常重视下属直接参与技术讨论会议的重要性，既树立他与开发人员沟通的信心，又加深了下属对项目的了解情况，对未来的工作开展非常有利；
8) 在一个项目中对于还没有掌握沟通技巧或者对自己没有信心的下属，请带着他一起和开发或者产品进行沟通或者鼓励他去沟通，并了解他沟通的效果并指出下次沟通的注意事项；
9) 在一个项目中你要了解自己的知识面是否与该项目匹配，不匹配提前做好准备；
10) 在一个项目中你也要了解你的下属能力与该项目的要求是否匹配，若不匹配，要不换人，要不请开发来培训；
11) 在一个项目中你不要和下属争功，上级对你的考察永远是团队和项目，帮助下属成长和保证项目质量是你永远的责任；
12) 在一个项目中你的懒惰将会对下属和项目造成极坏的影响，因为你是核心。

若你还想往上发展，就不断地在项目中锻炼自己的同时，让自己多关注技术、管理和行业，缺哪个补哪个

对于一个测试用例好坏的评价，无外乎两个标准：是否可以发现尚未发现的软件缺陷？是否可以覆盖全部的测试需求？但是后来发现这两个标准对于一些问题是处理不了的。例如，对于一个质量非常好的软
件产品，存在的软件缺陷异乎寻常的少，测试用例设计人员准备了大量的测试用例，已经完
全覆盖了测试需求，但是只有很少一部分测试用例在执行时发现了缺陷，而其他用例都顺利
通过了。那么是否就可以认为顺利通过的那部分测试用例不好呢？
对于这个问题，我认为不管是测试用例是否可以发现尚未发现的缺陷，还是测试用例
对测试需求的覆盖度，都是用来评估测试用例设计人员工作能力标准，而对于如何评价测试
用例本身的优劣，应该还有其他标准。当然，在不同的团队中可能存在不同的标准，但下面
两条应该是适合于任何团队的。
1.易用性。对于一个即熟悉测试工作，又熟悉被测应用的测试人员，应当可以花费很少
的时间就可以理解测试用例中表达的测试思路，并可以很快的完成这个测试用例的执行；
2.易维护性。当开发过程中的某些因素影响了测试需求，测试用例的作者或其他测试用
例设计人员，应该可以花费很少的时间就完成定位和维护所有相关测试用例的工作。

第一部分 软件测试综述

软件测试-机械工业出版社 （美）Ron Patton著 周予滨 姚静等译
读书笔记与心得
      说真的，这本书真的很不错，里面的一些定义很权威的，而且话不罗嗦，
讲的都是重点，美中不足的在测试用例设计方法那块不完整。许多人在推荐
入门看什么书的时候都提到此书，为了方便新手学习（其实我也是新手哈哈），
我决定把我以前的读书笔记与一些心得敲出来贴在网上，写的不是太全，主要是我觉得不错的东西。在此感谢此书作者和翻译人员！

软件测试读书笔记之软件测试背景       
软件测试读书笔记之软件开发过程       
软件测试读书笔记之软件测试的实质       
软件测试读书笔记之检查产品说明书       
软件测试读书笔记之闭着眼睛测试软件       
软件测试读书笔记之检查代码       
软件测试读书笔记之带上X光眼镜检查软件       
软件测试读书笔记之配置测试       

读书笔记与心得之软件测试背景   
                         
一.软件缺陷的正式定义：
符合下边5个规则的才能叫做软件缺陷。
1.软件未达到产品说明书标明的功能。
2.软件出现了产品说明书指明不会出现的错误。
3.软件功能超出产品说明书指明范围。
4.软件未达到产品说明书虽未指出但应达到的目标。
5.软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。

二.软件缺陷的产生原因： 
导致软件缺陷最大的原因是产品说明书；第二大来源是设计方案；三是代码；
四是某些软件缺陷产生的条件被错误地认定。

三.软件缺陷的修复费用：
随时间增长，修复软件缺陷的费用是呈几何数级增长的，随时间推移，数十倍增长。

四.软件测试人员的目的：
软件测试远的目标就是发现软件缺陷，尽可能早一些，并确保其得以修复。

五.怎么成为优秀测试员：
1.探索精神
2.故障排除能手
3.不懈努力
4.创造性
5.追求完美
6.判断准确
7.老练稳重
8.说服力
9.除了这些素质，在软件编程方面受过的教育也是重要的。
10.软件的功能为了解决现实问题，因此，教学烹饪航空木工医疗等知识都
将对查找该领域软件的缺陷有莫大帮助

读书笔记与心得之软件开发过程

一.测试文挡包括：
1.测试计划
2.测试案例
3.软件缺陷报告
4.归纳，统计和总结。

二.软件产品由哪些部分组成（都是要测的哦，当然我国许多软件都无法
达到这么多部分~呵呵）
1. 最终产品（光盘/软盘/程序...）
2.帮助文件
3.用户手册
4.样本和示例
5.标签和帖子
6.产品支持信息
7.图标和标志
8.错误信息
9.广告和宣传材料
10.安装
11.说明文件
这些都是要测试的，书中尤其提到了不要忘了测试错误提示信息（错误提示信息
是软件产品最容易忽视的部分，通常是有程序员而不是训练有素的稿手来写的。这
些信息很少照顾到修复软件缺陷的需要，还常常造成麻烦。软件测试员
也难以找到并显示全部信息。在软件中不要加入吓人和不友好的错误提示信息。）

三.软件开发模式
1.大棒式：所有精力都在开发软件和编写代码上
2.边写边改式：没有时间做好，总有时间返工哈哈！这句话经典，测试者几乎每天都
拿到一个新版本，新版本出来的时候，旧版本还没测完！而新版本还包含新的或者经过修改的功能）
3.流水式：创意-分析-设计-开发-测试-最终产品，只许前进不能后退！
4.螺旋式：开始不必详细定义所有细节。从小开始，定义重要功能，努力实现，接受
客户反馈，然后进入下一阶段。（一个螺旋包括6个步骤：1.确定目标，可选方案和限
制条件；2.指出并解决风险；3.评估方案；4.本阶段开发和测试；5.计划下一阶段；
6.确定进入下一阶段的方法。 ）测试一直在进行，知道最后宣布成功！

读书笔记与心得之软件测试的实质

一.测试人员要知道的几个‘交通规则’和‘生活法则’~
1.完全测试是不可能的。A.输入量太大；B.输出结果太多；C.软件实现途径太多；
D.软件说明书没有客观标准。从不同角度看，软件缺陷标准不同。
2.软件测试是有风险行为。
3.测试无法显示潜伏的软件缺陷。
4.找到的软件缺陷越多，就说明软件缺陷越多。
5.老用一种药，害虫都有抵抗力，程序也如此，如在螺旋开发模式中，每一个轮回都
会对软件进行测试，几回合后，该发现的都发现了，找不到什么错误了。这要求我们必
须不断编写不同的新测试程序，对程序的不同部分进行测试，以找到更多的缺陷。
6.并非所有的软件缺陷都能修复：A.没有足够的时间；B.不算真正的缺陷；
C.修复风险太大；D.不值得修复
7.难以说清的软件缺陷
8.产品说明书不断变化：软件测试员必须想到产品说明书可能改变。
9.测试员做的工作不受欢迎，因为工作就是挑错！所以我们要懂得怎么和开发的相处：
A.早点找出缺陷；B.控制情绪；C.多交流，不要总是报告坏消息。
10.软件测试是一项讲究条理的技术专业。

二.软件测试的术语和定义
这里引用下网上的术语总结，对原作者表示歉意和谢意和敬意！（不知道是谁）
1.精确和准确：A.精确参照物是目标。与目标越接近，就越准确；B：准确参照物是
每次实施的结果。几次结果相互之间越接近，表示越精确。但与目标可能相去甚远.
2.验证和合法性检查：A.验证保证软件符合产品说明书的过程 B.合法性检查保证软
件满足用户要求的过程.
3.质量和可靠性：可靠性只是质量的一个方面。A.质量可能包含功能是否齐全，产
品能否在各种机器上运行，软件公司有没有技术支持，甚至包装盒的色彩，可靠性
或者软件产品是否经常毁坏数据可能也很重要，但不绝对。B.可靠性：你自己想吧，
我没找到定义哈哈~
4.测试和质量评判(QA)：A.软件测试员的目标是找出软件缺陷，尽可能造一些，
确保得以修复；B.软件质量评判人员的主要指责是创建和加强促进软件开发并防止
软件缺陷的标准和方法

第二部分 测试基础
读书笔记与心得之四检查产品说明书

一.开始测试
1.A：黑盒测试：软件测试员只需知道软件要做什么，无法看到如何运作。只进行输入操作来得到输入结果。
  B：白盒测试：软件测试员可以访问程序员的代码，并通过检查代码来协助测试。
2.A：静态测试：测试不运行的部分—只是检查和审阅。
  B：动态测试：指通常意义上的测试—运行和使用软件。
3.测试产品说明书属于静态黑盒测试。

二.对产品说明书进行高级审查
    测试产品说明书第一步不是去找软件缺陷，而是在一个高度上审视。审查产品说明书是为了找出根本性大问题，疏忽或遗漏之处。
1.占在客户角度思考:设身处地的为客户着想,测试的时候把自己当成客户。
2.研究现有的标准和规范:软件测试员的任务不是定义润件要符合何种标准和规范，而是观察，检验是否套用正确的标准，没有遗漏。
3.审查和测试同类软件:同类软件有助于制订测试条件和测试方法，还可能暴露没想到的潜在问题。

三.产品说明书的低级测试技术
1.优秀产品说明书应当具有的8个属性
A.完整。是否有遗漏和丢失？完全吗？单独使用是否包含全部内容？
B.准确。解决方案正确吗？目标明确吗？有没有错误？
C.精确、不含糊、清晰。描述是否一清二楚？还是自说自话？ 容易看懂和理解吗？
D.一致。产品功能描述是否自相矛盾？与其他功能有无冲突？
E.贴切。描述功能的陈述是否必要？有没有多余信息？功能是否原来的客户要求？
F.合理。在特定预算和进度下，以现有人力、物力和资源能否实现？
G.代码无关。是否坚持定义产品，而不是定义其所依赖的设计、架 构和代码？
H.可测试。特性能否测试？测试员建立验证操作的测试错误程序是否提供足够的信息？

2.产品说明书7个用语检查清单
A.总是、每一种、所有、没有、从不。
看到此类绝对或肯定的切实认定的叙述，可以着手设计针锋相对的案例。
B.当然、因此、明显、显然、必然。
这些话意图诱使接受假定情况。不要中了圈套。
C.某些、有时、常常、通常、经常、大多、几乎。
这些话太过模糊。“有时”发生作用的功能无法测试
D.等等、诸如此类、依此类推。
以这样的词结束的功能清单无法测试。功能清单要绝对或者解释明确。
E.良好、迅速、廉价、高效、稳定。
这些是不确定的说法，不可测试。如果在产品说明书出现，必须要求进一步指明含义。
F.已处理、已拒绝、已忽略、已消除。
这些说法可能会隐藏大量需要说明的功能。
G.如果...那么...（没有否则）。
缺少配套的否则，想一想，“如果”没有发生会怎样呢？

读书笔记与心得之闭着眼睛测试软件

一.动态黑盒测试
    1.不深入代码细节的软件测试方法称为动态黑盒子测试。它是动态的，因为程序正在运行；它是黑盒子，因为测试时不知道程序如何工作。测试工作就是进行输入，接受输出，检验结果。
    2.首先要弄清楚作为测试对象的软件要输入什么得到什么，或者操作结果。这就要求有文挡或产品说明书；接下来开始定义测试案例（就是我们常说的测试用例）
    3.选择测试案例是软件测试员最重要的任务。不正确的选择可能导致测试量过大或者过小，甚至测试目标不对。准确评估风险，把不可穷近的可能性减少到可以控制的范围是成功的诀窍。
    *4.没有产品说明书的情况下使用探索测试。（这个我觉得很重要，因为国内大部分软件都是这样的，因为国内大部分软件都是这样的，什么说明都没有,没有需求说明,没有产品说明书,没有设计书......呵呵,这就是有中国特色的软件测试吧~~，遇到这种情况不要烦躁，"把软件当成产品说明书来对待。分步骤地逐项探索软件特性。记录软件执行情况，详细描述功能。在这种情况下，无法像有产品说明书那样完整的测试软件--比如无法断定是否遗漏功能，但是可以进行系统测试。找到软件缺陷几乎是肯定的."  小雪经验总结:这种情况还要多和开发的沟通，在他们那了解软件更多的情况。他们自己写的,没有人比他们知道的多.这种测试会遇到很多你认为逻辑不合理的地方,因为没有需求说明,开发的完全照自己的意思来编写代码.有的是多人编写,每人负责一个模块,模块之间衔接和整个软件的业务逻辑多会有许多问题.

二.通过测试和失败测试

通过测试：确认软件至少能做什么，而不考验其能力。只运用最简单，最直观的测试案例。
失败测试：纯粹为了破坏软件而设计和执行的测试案例。
    设计和执行测试案例时，总是首先进行通过测试。在破坏性试验之前看看软件基本功能是否实现是很重要的，否则在正常使用软件时就会奇怪为什么有那么多的软件缺陷。常见的测试案例就是设法迫使软件出现错误提示信息。

三.等价分配
等价分配（等价类划分）：是指分步骤地把过多（无限）的测试案例减小到同样有效的小范围的过程。
    等价类别或者等价区间是指测试相同目标或者暴露相同软件缺陷的一组测试案例。在寻找等价区间时，想办法把软件的相似输入、输出、操作分成组。这些组就是等价区间。等价分配的目标是把可能的测试案例组合缩减到仍然足以测试软件的控制范围。因为选择了不完全测试，就要冒一定的风险。如果为了减少测试案例的数量过度进行等价分配，测试的风险就会增加。另外，等价区间的划分没有一定的标准，只要足以覆盖测试对象就行了。

（个人认为这里讲的不是很好，在笔记前我就说了，本书测试用例设计方法上做的不是很好，有关知识大家上网看吧，写的很详细，推荐一个风姿清扬整理的测试用例设计方法~。以后遇到相关测试用例设计的问题我都引用一些比较流行的通俗的知识或者直接省去了`。 我们设计用例数据的时候按照等价类划分方法：

等价类分为有效等价类和无效等价类，有效等价类就是由那些对程序的规格说明有意义的、合理的输入数据所构成的集合；无效等价类就是那些对程序的规格说明不合理的或无意义的输入数据所构成的集合。
划分等价类的方法：下面给出六条确定等价类的原则。
1、在输入条件规定了取值范围或值的个数的情况下，则可以确立一个有效等价类和两个无效等价类。
2、在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下，可确立一个有效等价类和一个无效等价类。
3、在输入条件是一个布尔量的情况下，可确定一个有效等价类。
4、在规定了输入数据的一组值（假定n个），并且程序要对每一个输入值分别处理的情况下，可确立n个有效等价类和一个无效等价类。
5、在规定了输入数据必须遵守的规则的情况下，可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）。
6、在确知已划分的等价类中各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步的划分为更小的等价类。）

四.数据测试

    软件由数据和程序组成。数据包括键盘输入、鼠标单击、磁盘文件、打印输出等等；程序指可执行的流程、转换、逻辑和运算。

    对数据进行软件测试，就是在检查用户输入的信息、返回结果以及中间计算结果是否正确。主要根据下列原则来进行等价分配，以合理减少测试案例：边界条件，次边界条件，空值和无效数据。

   （个人认为书里介绍边界值这块不是很好，新手还是看下面的吧，流行的比较经典的是边界值分析法：
上点，就是边界上的点，不管它是开区间还是闭区间，就是说，如果该点是封闭的，那上点就在域范围内，如果该点是开放的，那上点就在域范围外；
内点，就是在域范围内的任意一个点；
离点，就是离上点最近的一个点，如果边界是封闭的，那离点就是域范围外离上点最近的点，如果边界是开放的，那离点就是域范围内离上点最近的点。
边界值分析方法的原则：
1、如果输入（输出）条件规定了取值范围，则应该以该范围的边界值及边界附近的值作为测试数据；
2、如果输入（输出）条件规定了值的个数，则用最大个数，最小个数，比最小个数少一，比最大个数多一的数作为测试数据；
3、如果程序规格说明书中提到的输入或输出是一个有序的集合，应该注意选取有序集合的第一个和最后一个元素作为测试数据；
4、如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构的边界上的值作为测试数据。）

五.状态测试。

    软件状态是指软件当前所处的情况或者模式。软件通过代码进入某一个流程分支，触发一些数据位，设置某些变量，读取某些变量，而转入一个新的状态。软件测试员必须测试软件的状态及其转换。
1.测试软件的逻辑流程。状态测试运用等价分配技术选择状态和分支。因为选择不完全测试，所以要承担一定的风险，但是通过合理选择会减少危险。

2.建立状态转换图。包括的内容有：
A.软件可能进入的每一种独立状态；
B.如果不能断定是否为独立状态，就算它是，以后发现不是，随时把它T开；
C.从一种状态转入另一种状态所需的输入和条件。找出什么操作导致的变化；
D.进入或退出某种状态时的设置条件及输出结果。包括显示的菜单和按钮、设置的标志位、产生的打印输出、执行的运算等等。这些是状态转换时发生的部分或全部现象。

3.减少要测试的状态及转换的数量。
A.每种状态至少访问一次；
B.测试看起来最常见最普遍的状态转换；
C.测试状态之间最不常用的分支。
D.测试所有错误状态及其返回值;
E.测试随机状态转换。
4.具体测试的进行。确定要测试的状态及其转换之后,就可以定义测试案例了。测试状态及其转换包括检查所有的状态变量——与进入和退出状态相关的静态条件、信息、值、功能等等。状态变量也许不可见，但是很重要。

(建议看因果图法写测试用例呵呵)

六.失败状态测试

1.竞争条件和时序错乱:在真正的多任务环境中软件设计绝对不能想当然，必须处理随时被中断的情况，能够与其他任何软件在系统中同时运行，并且共享内存、磁盘、通信设备以及其他硬件资源。这一切的的结果就可能导致竞争条件问题.这些问题的几个事件恰好挤在一起,软件未预料到的操作过程被中断,时序就会发生错乱。竞争条件测试难以设计，最好是首先仔细查看状态转换图中的每一个状态，以找出哪些外部影响会中断该状态。考虑要使用数据如果没有准备好，或者在用到时发生了变化，状态会怎样。数条弧线或者直线同时相连的情形如何。
下是要面临竞争条件的典型情形：
A.两个不同的程序同时保存或打开同一个文档。
B.共享同一台打印机、通信端口或者其他外围设备。
C.当软件处于读取或者修改状态时按键或者单击鼠标。
D.同时关闭或者启动软件的多个实例。
E.同时使用不同的程序方位一个共同数据库。

2.重复、压迫和重负
测试的目标是处理那些连程序员都没有想到的恶劣条件下产生的问题的能力。
A.重复测试是不断执行同样的操作。最简单的是不停地启动和关闭程序，或者反复读写数据或者选择同一个操作。这种测试的主要目的是看内存是否不足。如果内存被分配进行某项操作，但操作完成时没有完全释放，就会产生一个常见的软件问题。
B.压迫测试是使软件在不够理想的条件下运行——内存小、磁盘空间少、CPU速度慢、调制解调器速率低等等。观察软件对外部资源的要求和依赖程度。压迫测试就是将支持降到最低限度，目的在于尽可能的限制软件的必要条件。
C.重负测试和压迫测试相反。压迫测试是尽量限制软件，而重负测试是尽量提供条件任其发挥。让软件处理尽可能大的数据文件。最大限度的发掘软件的能力，让它不堪重负。比如：软件对打印机或通信端口进行操作，就把能连的都连上；服务器可以处理几千个模拟连接，就按他说的做。
三者应联合使用，同时进行。
注意事项:      
A.项目管理员和小组程序员可能不完全接受软件测试员这样打破软件的做法。但是软件测试员的任务就是确保软件在这样恶劣的条件下正常工作，否则就报告软件缺陷。如何以最佳方式报告软件缺陷，使其得到严肃对待和修复，也是一门学问。
B.无数次重复和上千次的连接对于手工操作是不可能的。因而需要借助自动化测试工具来实现。

七.其他黑盒测试技术
1.像新用户那样做,随意操作.
2.在已经找到软件缺陷的地方再找找(80%的缺陷通常集中在20%的模块)
3.凭借经验、直觉和预感. (软件测试确实是越有经验越吃香啊!,像我们这样的只能好好学习,多多实践,多多积累,不断总结)

呼! 这章怎么这么长啊!排版很乱,有时间再整理吧,对不起大家的眼睛了,再看看这章名字,闭着眼睛..呵呵,看的眼睛痛了就闭眼睛想一会吧,

读书笔记与心得之检查代码

    软件测试不仅仅是检查产品说明书和闭着眼睛测试软件，还有对软

件设计和代码进行测试。因为在测试军队，金融，工业，医药类软件或

者在组织严格的开发模式下工作代码和产品检验是例行公事。

一.静态白盒子测试：检查设计和代码
     静态测试是指测试非运行部分——检查和审查。白盒测试是指访

问代码，能够查看和审查。静态白盒测试是在不执行的条件下有条理地

仔细审查软件设计、体系结构和代码，从而找出软件缺陷的过程。有时

也称为结构分析。
     进行静态白盒子测试的首要原因就是尽早发现软件缺陷，以找出

动态黑盒子测试难以揭示或遇到的软件缺陷；另一个好处是为接受该软

件测试的黑盒测试员的测试案例提供思路，他们不必了解代码细节，但

是根据审查备注，可以确定似乎有问题或者存在软件缺陷的特性范围。

二.正式审查
    正式审查就是进行静态白盒子测试的过程。正式审查含义广泛，从

程序员之间的交谈，到代码的严格检查均属于此过程。            

有4个基本要素：
1.确定问题。审查的目标是找出软件的问题，不仅是出错的项目，还包

括遗漏的项目。全部的批评应直指代码，而不是其创建者。合作者不应

该互相指责。个人情绪化感觉要保留。
2.遵守规则。 审查要遵守一套固定的规则，规则可能设定要审查的代

码量、花费多少时间、哪些内容要做备注等等。其重要性在于合作者了

解自己的作用和目标，这有助于使审查进展的更加顺利。
3. 准备。每个合作者需要了解自己的责任和义务，并积极参与审查。

在审查过程中找出问题大部分的缺陷是在准备期间发现的，而不是实际

审查期间。
4.编写报告。审查小组必须做出总结审查结果的书面报告，并使报告便

于开发小组使用。审查结果必须尽快告诉别人，比如发现多少问题，在

哪发现的。

正式审查有三种类型：
1.同事审查：召集小组成员进行初次正式审查是最简单的方法就是同时

审查。类似于“各抒己见”类型的讨论。常常仅在编写代码的程序员和

充当审查者的其他一两个程序员和测试员之间进行；
2.公开陈述：公开陈述是使同事审查正规化的下一步。编写代码的程序

员像5人小组或其它类似的程序员或测试员正式表述。审查人员应该在

审查之前接到软件拷贝，以便检查并编写备注和问题，在审查过程中提

问。
3.检验：检验是最正式的审查类型，具有高度组织化，要求每一个参与

者都接受训练。检验与同事审查不同之处在于，表述代码的人不是原来

的程序员。这就迫使他学习和了解要表述的材料，从而有可能在检验会

议上提出不同的看法和解释。另外的参与者称为检验员，职责是从不同

的角度（如用户、测试员或产品支持人员）的角度审查代码。检验会议

后，检验员可能再次碰头讨论他们发现的不足之处，并与会议主席共同

准备一份书面报告，明确解决问题所必须重做的工作。然后程序员进行

修改，由会议验证修改结果，可能要要进行重新检验，以便找到其余的

软件缺陷。

三.编码标准和规范

3个坚持标准和规范的重要原因：
1.可靠性。事实证明按照按规范编写的代码更可靠，软件缺陷将更少。
2.可读性/维护性。符合标准和规范的代码易于阅读，理解和维护。
3.移植性。如果代码符合设备标准，迁移到另一个平台就会容易，甚至

没有任何障碍。

标准由4个主要部分组成：
1.标题。描述标准包含的主题。
2.标准（或规范）。描述标准（或规范）内容，解释哪些允许，哪些不

允许。
3.解释说明。给出标准背后的原因，让人理解这为什么是好的编程习惯
4.示例。给出如何使用此种标准的简单程序示例，这不是必需的。
    但是，对软件进行正式审查时，测试和注解的对象仅限于错误和缺

漏，而不管是否坚持标准或者规范！

四.通用代码审查清单
1.数据引用错误
数据引用错误是指使用未经正确地初始化的变量、常量、数组、字符串或记录。
A. 是否引用了未初始化的变量？
B. 数组和字符串的下标是整数值吗？下标总是在数组和字符串大小范围之内吗？
C.在检索操作或者应用数组下标时是否包含"丢掉一个"这样的潜在错误？
D.是否在应该使用常量的地方使用了变量？
E.变量是否被赋予不同类型的值？
F.为引用的指针分配内存了吗？
G.一个数据结构是否在多个函数或者子程序中引用，在每一个引用中明确定义结构了吗？
2.数据声明错误
数据声明错误是指不正确地声明或使用变量和常量。
A.所有变量都赋予正确的长度、类型和存储类了吗？
B. 变量是否在声明的同时进行了初始化？是否正确初始化并与其类型一致？
C.变量有相似的名称吗？
D.存在声明过、但从未引用或者只引用过一次的变量吗？
E.在特定模块中所有变量都显式地声明了吗？
3.计算错误
计算错误是指基本的数学逻辑问题。
A.计算中是否使用了不同数据类型的变量，如整数与浮点数相加？
B.计算中是否使用了数据类型相同但字节长度不同的变量？
C.计算时是否了解和考虑到编译器对类型或长度不一致的变量的转换规则？
D.赋值的目的变量是否小于赋值表达式的值？
E.在数值计算过程中是否可能出现溢出？
F.除数或模是否可能为零？
G.对于整型算术运算或某些计算，特别是除法的代码处理是否会丢失精度？
H. 变量的值是否超过有意义的范围？
I. 对于包含多个操作的表达式，求值次序是否混乱，运算优先级对吗？需要加括号使其清晰吗？
4.比较错误
小于、大于、等于、不等于、真、假、比较和判断错误很可能是边界条件问题。
A.比较得正确吗？
B.存在分数或者浮点数之间的比较吗？如果有，精度问题会影响比较吗？1.00000001和1.00000002极其接近，它们相等吗？
C.每一个逻辑表达式都正确地表达了吗？逻辑计算如期进行了吗？求值次序有疑问吗？
D.逻辑表达式的操作数是逻辑值吗？
5.控制流程错误
控制流程错误是指编程语言中循环等控制结构未按预期方式工作，通常由计算或者比较错误直接或间接造成。
A.程序中的语句组是否对应？
B.程序、模块、子程序和循环能否终止？如果不能，可以接受吗？
C.可能存在永远不停的循环吗？
D.循环可能从不执行吗？如果是这样，可能接受吗？
E.对于多分支语句，索引变量能超出可能的分支数目吗？如果超出，该情况能正确处理吗？
F.是否存在"丢掉一个"错误，导致意外进入循环？
6.子程序参数错误
子程序参数错误的来源是软件子程序不正确地传递数据。
A.子程序接收的参数类型和大小与调用代码发送的匹配吗？次序正确吗？
B.如果子程序有多个入口点，引用的参数是否与当前入口点没有关系？
C.常量是否当作形参传递，意外在子程序中改动？
D. 子程序是更改了仅作为输入值的参数？
E.每一个参数的单位是否与相应的形参匹配？
F.如果存在全局变量，在所有引用子程序中是否有相似的定义和属性？
7.输入/输出错误
输入/输出错误包括文件读取、接受键盘或鼠标输入以及向输出设备写入错误等。
A.软件是否严格遵守外设读写数据的专用格式？
C. 软件是否处理外设未连接、不可用、或者读写过程中存储空间占满等情况？
D.软件以预期的方式处理预计的错误吗？
E.检查错误提示信息的准确性、正确性、语法和拼写了吗？
8.其他错误
A.软件是否使用其他外语？是否处理扩展ASCII字符？是否需用统一编码取代ASCII？
B. 软件是否需要移植到其他编译器？
C.是否考虑了兼容性，以使软件能够运行于不同数量的可用内存、不同的内部硬件、不同的外设等？
D.程序编译是否产生"警告"或者"提示"信息？这些信息通常指示语句有疑问。

读书笔记与心得之带上X光眼镜检查软件

一.动态白盒子测试

    用一句话来概括，动态白盒测试是指利用查看代码功能和实现方式得到的信息来确定哪些要测试，哪些不要测试，如何开展测试。动态白盒测试的另一个常用名称是结构化测试，因为软件测试员可以查看并使用代码的内部结构，从而设计和执行测试。
   动态白盒测试不仅仅是查看代码，还包括直接参数和控制软件。它包括四部分：
1.直接测试底层功能、过程、子程序和库。即应用程序接口（API）
2.以完整程序的方式从顶层测试软件，但是要根据对软件运行的了解调整测试案例。
3.从软件获得读取变量和状态信息的访问权，以便确定测试与预期结果是否相符，同时，强制软件以正常测试难以实现的方式运行。
4. 估算执行测试时“命中”的代码量和具体代码，然后调整测试，去掉多余的，补充遗漏的。

二、动态白盒子测试和调试

    测试和调试是不同的。白盒测试的目标是寻找软件缺陷，调试的目的是修复它们。然而它们在隔离软件缺陷的位置和原因上确实存在交叉现象。测试员应该把问题缩减为能够演示软件缺陷的最简化测试案例。在白盒测试中，甚至要包含那些值得怀疑的代码行信息。进行调试的程序员从这里继续，判断到底是什么导致的软件缺陷，并设法修复。
    一定要分清软件测试员和程序员的工作。程序员编写代码，测试员寻找软件缺陷，可能还要编写一些代码来驱动测试，然后程序员修复软件缺陷。要进行这样的底层测试，就要使用与程序员相同的工具。如果程序已经编译过，就要使用同样的编辑器，但是采用不同的设置，以加强错误检测功能。

    软件测试员可能会使用代码级的调试器来单步跟踪程序，观察变量，设置断点，等等。对于要求合法性检查的独立代码模块，还有编写测试程序进行测试。

三.分段测试

从测试的角度看，产生高额费用有两个原因：
A.难以甚至不可能找出导致问题的原因
B.某些软件缺陷掩盖了其他软件缺陷。

1.单元和集成测试
    独立代码段分别建立和测试，然后集成并重新测试。以最小模块为单位的测试叫单元测试或者模块测试。等到经过单元测试，底层的软件缺陷被找出并修复之后，就集成在一起，对模块组进行集成测试。这个不断增加的测试过程继续进行，加入的软件片段逐渐增多，直至整个产品-至少是产品的主要部分--在称为系统测试的过程中一起测试。
  
    采取这种测试策略很容易隔离软件缺陷。在单元级发现问题时，问题肯定就在那个单元中。如果多个单元集成发现软件缺陷，那么它一定与模块之间的交互有关。当然这个也有例外。

这种递增测试有两种方法：
A.自底向上：要编写测试驱动模块，测试驱动模块以将来真正模块同样的方式挂接，向处于测试的模块发送测试案例数据，接受返回结果，验证结果是否正确。采取这种方式，可以对整个软件进行测试，为它提供全部类型和数量的数据，甚至高层难以发送的数据。
B.自顶向下：有点像小规模的大棒测试，先测试高层的软件，然后测试它们下一层的。

注意：在进行白盒子测试之前，一定要根据说明书建立黑盒子测试案例。用这种方式可以看出真正测试模块的用意。如果先从模块的白盒子角度建立测试案例，检查代码，就会偏向模块工作方式建立测试案例。程序员或许错误地解释说明，于是测试案例会不对。虽然仔细测试了模块，但是可能不准确，因为没有测试预期的操作。

四.数据覆盖

    看了下笔记，发现很乱，取精华，去糟粕，为了不继续误‘倒’大家，我把网上流行的经典白盒测试用例设计方法COPY过来~

白盒测试的方法：总体上分为静态方法和动态方法两大类。

    静态分析是一种不通过执行程序而进行测试的技术。静态分析的关键功能是检查软件的表示和描述是否一致,没有冲突或者没有歧义。

　　动态分析的主要特点是当软件系统在模拟的或真实的环境中执行之前、之中和之后 , 对软件系统行为的分析。动态分析包含了程序在受控的环境下使用特定的期望结果进行正式的运行。它显示了一个系统在检查状态下是正确还是不正确。在动态分析技术中,最重要的技术是路径和分支测试。下面要介绍的六种覆盖测试方法属于动态分析方法。
1.语句覆盖：语句覆盖是最起码的结构覆盖要求，语句覆盖要求设计足够多的测试用例，使得程序中每条语句至少被执行一次。
2.判定覆盖：判定覆盖又称为分支覆盖，它要求设计足够多的测试用例，使得程序中每个判定至少有一次为真值，有一次为假值，即：程序中的每个分支至少执行一次。每个判断的取真、取假至少执行一次。
3.条件覆盖：条件覆盖要求设计足够多的测试用例，使得判定中的每个条件获得各种可能的结果，即每个条件至少有一次为真值，有一次为假值。
4.判定/条件覆盖：设计足够多的测试用例，使得判定中每个条件的所有可能结果至少出现一次，每个判定本身所有可能结果也至少出现一次。
5.条件组合覆盖：要求设计足够多的测试用例，使得每个判定中条件结果的所有可能组合至少出现一次。
6.路径覆盖：设计足够的测试用例，覆盖程序中所有可能的路径。
（具体例子请看我写的测试试卷一答案整理的大题和白盒子测试方法举例）
     总结：白盒测试是一种被广泛使用的逻辑测试方法，是由程序内部逻辑驱动的一种单元测试方法。只有对程序内部十分了解才能进行适度有效的白盒测试。但是贯穿在程序内部的逻辑存在着不确定性和无穷性，尤其对于大规模复杂软件。因此我们不能穷举所有的逻辑路径，即使穷举也未必会带来好运（穷举不能查出程序逻辑规则错误，不能查出数据相关错误，不能查出程序遗漏的路径）。
　　那么正确使用白盒测试，就要先从代码分析入手，根据不同的代码逻辑规则、语句执行情况，选用适合的覆盖方法。任何一个高效的测试用例，都是针对具体测试场景的。逻辑测试不是片面的测试正确的结果或是测试错误的结果，而是尽可能全面地覆盖每一个逻辑路径。

（原书是数据范围，代码范围，条件范围......看来作者真不是专业测试人员啊，书中有些术语翻译的不是很好，由于本人水平有限，没能都改正，建议英语好的人还是看英文版本的，不太好的用此笔记做辅助看，我相信效果会好一点。很抱歉，我还没看英文的呢，打算先把笔记写完再看英文的，先误‘倒’一下新手哈哈~ 在次希望大家指正错误，我会及时改的！谢谢~）

读书笔记与心得之配置测试

一.        配置综述

如果刚准备开始从事软件测试工作，首先的一个任务是配置测试。要保证测试的软件使用尽量多样化的硬件组合。配置测试是指使用各种硬件来测试软件操作的过程。
    我们常用有如下配置：个人计算机；部件；外设；接口；可选项和内存；设备驱动程序。
    如果准备开始进行软件的配置测试，就要考虑哪些配置与程序的关系最密切。这是必不可少的，因为并不是所有的生产硬件的商家都遵照一套标准来设计硬件。

1.分离配置缺陷
判断缺陷是配置问题还是普通缺陷的方法：在另一台配置完全不同的机器上执行相同
的操作。如果缺陷没产生，那就很可能是配置问题了，如果缺陷在多种配置中产生，应该是普通的缺陷（BUG）
判断缺陷是开发程序的问题还是硬件的问题，要找出问题所在：
（1）软件可能包含在多种配置中都会出现的缺陷。
（2）软件可能包含只在某一个特殊配置中出现的缺陷。
（3）硬件设备或者其设备驱动程序可能包含仅由软件揭示的缺陷。
（4）硬件设备或者其设备驱动程序可能包含一个借助许多其它软件才能看到的缺陷- 尽管它可能对测试的软件特别明显。  
前两种情况，由开发小组负责修复缺陷。后两种情况，责任不太清晰。但是即使是硬件的问题，都是开发小组的责任，因为客户不关缺陷是怎么产生的，他们只要求在自己的系统配置中能正常运行。

2. 计算工作量
    配置测试工作量可能非常大，我们不可能把会出现的配置都测试。减少麻烦的答案是等价类划分。需要找出一个方法把巨大的配置可能性减少的尽可能控制的范围。由于没有完全测试，因此存在一定的风险，但这正式软件测试的特点！

二.执行任务

确定测试哪些设备和如何测试的决定过程是相当直观的等价类划分工作。什么重要，怎样才会成功，是决定的内容。计划配置测试时采用的一般过程如下：
1.确定所需的硬件类型
2.确定哪些硬件，型号和驱动程序可用
3.确定可能的硬件特性，模式和选项
4.将确定后的硬件配置缩减为可控制的范围
5.明确使用硬件配置的软件唯一特性
6.设计在每一种配置中执行的测试用例
7.在每种配置中执行测试
8.反复测试直到小组对结果满意为止

三．获得硬件

即使把要配置的硬件可能性用等价类划分到最低限度，仍然需要N多硬件的，没那么多钱怎么办？
（1）只买可以或者将会经常使用的配置。
（2）与硬件生产商联系，看能否租借甚至白送
（3）问公司内部人有什么硬件，是否允许进行测试。为了完成配置测试，甚至要开车到乡下，但这仍然比买要便宜多了
1.明确硬件标准
大概意思就是了解硬件说明书的一些细节，有助于做出更多清晰的等价划分决定。
2.对其他硬件进行配置测试
根据从设备使用者，项目经理或者销售人员的输入建立硬件的等价区间，写测试用例，收集所选硬件，执行测试。

    总结：进行配置测试是软件测试新手经常被分配到的任务，因为它容易定义；是基本组织技巧和等价分配技术的敲门砖；是与其它项目小组成员合作的任务；是管理员快速验证结果的手段。

读书笔记与心得之兼容性测试

一.        容性测试综述
软件兼容性测试是指检查软件之间是否正确地进行交互和共享信息。
测试软件兼任性，要先对需求进行确定：
1.软件设计要求什么样的平台（系统，浏览器或操作环境等）与应用软件保持兼容？如果要测试的软件是一个平，那么设计要求什么应用程序在其上运行？
2.应该遵守何种定义软件之间交互的标准或者规范？
3.软件使用何种数据与其他平台和软件交互和共享信息？

二．平台和应用程序版本
   选择平台或者兼容的应用程序是程序管理或者市场定位的任务。软件设计用于某个操作系统，WEB,浏览器或者其他平台要由熟悉客户情况的人来决定，他们还要明确软件需要兼容的版本。

1.向前兼容和向后兼容：
向前兼容是指可以使用软件的以前版本。向后兼容是指可以使用软件的未来版本。
并非所有的如软件都要求向前或向后兼容。
。
2.测试多个版本的影响：
测试平台和软件应用程序多个版本相互之间是否正常工作可能是一个艰巨的任务！假设测试一个新的操作系统版本，旧版操作系统上可能有上百万的程序，新操作系统的目标是与它们100%兼容，这是一个很大的任务，我们很难一个个的去试！
只能运用以前学过的等价类分配法，划下等级类以减少工作。（在开始兼容性测试之前，要对所有的软件组合等价分配，使其成为验证软件之间正确交互的最小有效集合）
由于不可能在系统上测试成千上万的软件，所以要决定哪些是重要的，挑重要的来测试。决定的原则如下：
1.        流行程度。选择钱100或者前1000流行的软件
2.        年头。选择3年以内的程序和版本，不要把老古董拿出来哈。
3.        类型。这个其实算等价划分里的，把软件按用途分为画图，财务，数据库等等，每种类型选个代表。
4.        生产厂商。根据软件制作的公司来选。
这些没有标准答案的，看情况而定吧。

三．标准和规范
1.高级标准和规范
产品普遍遵守的规章，例如外观和支持性等等。
2.低级标准和规范
本质细节，例如文件格式或网络通信协议等等。

四.数据共享和兼容性
    
   在应用程序之间共享数据实际上是增强软件的功能。写得好的程序支持并遵守公开标准；允许用户与其他软件轻松传输数据，这样的程序是兼容性极好的产品。
   最为人熟知的数据传输方式—读写磁盘文件的例子：严格遵守磁盘和文件格式的低级标准是此类共享的前提。其他方式有时被想当然地接受，也要做兼容性测试。下面是些例子：
5.        文件保存和文件读取。把数据存入软盘（或其他介质）,然后放到不同系统的计算机上。文件的数据格式要符合标准，才能在两台计算机上都正常。
6.        文件导出和文件导入是许多程序与自身以前版本及其他程序保持兼容的方式。为了测试文件导入特性，需要以各种兼容文件格式创建多个文档—可能要利用源程序存为该格式。这些文档需要等价分配为可能的文件和格式，用于检查导入代码是否正确转换为新格式。
7.        剪切，复制和粘贴是程序间无需借助磁盘传输最常见的数据共享方式。在这种情况下，传输在内存中通过成为剪切板的即时程序实现。
8.        DDE和OLE是Windows中在两个程序之间传输数据的方式。DDE表示动态数据交换，OLE表示对象潜入链接。其他平台也支持此方法。

五．总结
   新手也可能接受到兼容性的测试任务，不要着急，按下面三步骤：
1.        对所有可能的兼容软件进行等价分类，使其成为可以控制的范围。当然，项目经理要认可测试清单，并接受由于未完全测试而引起的风险。
2.        研究适用于测试软件的高级/低级标准和规范。把他们当作产品说明书的补充内容。
3.        测试软件程序之间不同的数据流动方式。其中的数据交换就是程序之间保持兼容的因素。

读书笔记与心得之测试文档
    （这一章节内容与原书相比改动很大，加了许多我说的话）
文挡是软件产品中的非软件部分，在很多公司中这部分的测试经常被忽略。然而文挡测试也是测试人员职责所在，软件产品中的文挡对客户来说和软件的功能是一样重要的，他们可能经常查看和使用，如果文挡出现错误很可能会误导客户，比如安装说册错误，客户按其所示就无法正常安装，操作手册有错误就会让客户操作失败，不正确的错误提示可能把客户领进死胡同，所以说测试文挡是十分必要的。好文挡可以提高软件的易用性，可靠性，更能因为文挡中的引导和解释帮助用户克服操作困难，从而降低他们请求公司支持的几率，这样就节省了开发公司的支持费用。

　　在有中国特色的软件开发中，许多像操作手册，帮助文挡之类的文挡都是测试人员编写的，自己对自己写的东西有信心就不测试了是不负责任的做法，可是对自己写的东西测试又很容易被自己的思维所影响，所以最好不测试自己写的文挡，而是测试人员之间相互测试一下比较妥善。

       以前我只浅显的认为文挡只是帮助手册，安装指导，操作手册，可事实并不是我所想的那么简单， 什么是软件中的文挡部分呢？
　　  1.用户手册：这似乎是必须的了，即使有联机帮助也少不了一份用户的入门手册了。
　　  2.安装和设置指导。
　　  3.联机帮助。
        4.错误提示信息：恍然大悟啊，这也算文挡的部分。
        5.包装文字和图形。
        6.市场宣传材料，广告以及其它插页。
        7.授权/注册登记表。
        8.最终用户许可协议
        9.标签和封条
       10.向导，指南：相当于助手的动作，用户可以提出问题，然后软件一步步的指引完成任务。
       11.样例，示例和模版

     （其实做项目和做产品是有很多区别的，比如做项目做出来的软件就没有联机帮助，没有宣传材料，没有注册页，甚至可能没有包装盒等等，
这里把软件产品概念广义一下，即包括项目软件也包括产品软件，每一个软件不一定非要有上面的部分，但是可能会有：）
        如何进行文挡的测试呢？其实文挡的测试也分为动态的测试和静态的测试。
        静态的文挡测试主要是看：
        一看内容（自然包括图片了）是否完善齐全合理；
        二看语言是否表达正确准确以及明确；
        三看标记等是否正确，段落标点拼写和语法等等是否正确。
        四看文档的编写是否满足文档编写的目的。
       动态的文挡测试完全实际操作，跟随每个步骤，尝试每个示例，将执行结果与文挡描述做比较，索引的搜索结果是否正确，超级链接等跳转是否到正确页面。
       希望通过此文，让更多的人了解到文挡的测试重要性，然后在工作中认真的测试文挡。让我们共同努力，把在客户眼中和程序同等重要的文挡做的越来越好。

◆选择重复，消除重复和选择出序列

有例表：emp

emp_no name age   
  001 Tom 17   
  002 Sun 14   
  003 Tom   15   
  004 Tom 16

要求：

列出所有名字重复的人的记录

(1)最直观的思路：要知道所有名字有重复人资料，首先必须知道哪个名字重复了：

select   name   from   emp     
  group   by   name   
  having   count(*)   >1

所有名字重复人的记录是:

select   *   from   emp     
  where     
  name   in   (   
  select   name   from   emp     
  group   by   name   
  having   count(*)   >1   
      )

(2)稍微再聪明一点，就会想到，如果对每个名字都和原表进行比较，大于2个人名字与这条记录相同的就是合格的 ，就有

select   *   from   emp   
where   
(select   count(*)   from   emp   
e   where   e.name=emp.name)   
>1

--注意一下这个>1，想下如果是 =1，如果是 =2 如果是>2 如果 e 是另外一张表 而且是=0那结果 就更好玩了:)

这个过程是 在判断工号为001的 人 的时候先取得 001的 名字（emp.name） 然后和原表的名字进行比较 e.name

注意e是emp的一个别名。

再稍微想得多一点，就会想到，如果有另外一个名字相同的人工号不与她他相同那么这条记录符合要求：

select   *   from   emp   
  where   exists   
  (select   *   from   emp   e   where   
e.name=emp.name   and   e.emp_no<>emp.emp_no)

此思路的join写法：

select   emp.*     
  from   emp,emp   e   
  where     
  emp.name=e.name   and   emp.emp_no<>e.emp_no   
  /*   
  这个   语句较规范   的   join   写法是   
  select   emp.*     
  from   emp   inner   join     emp   e   
  on   
  emp.name=e.name   and   emp.emp_no<>e.emp_no   
  但个人比较倾向于前一种写法，关键是更清晰   
  */   
  b、有例表：emp   
  name age   
  Tom 16   
  Sun 14   
  Tom   16   
  Tom 16