对任何系统来说，虽然我们能够进行各种类型的测试，但是，如果要测试所有可能的错误，是一个相当大的工作量，也是不可能的，因此，必须把注意力集中到能够确定的至关重要的测试条件上，而不是确定为相对不太重要的大量条件上。重点测试那些顾客和用户密切关注的系统行为，因为这些行为有可能在发行之后给用户造成不便。所以，我们需要分析系统的质量风险，根据风险来确定对系统软件我们应该测试什么。而不应该根据我们能够测试什么去测试系统软件。

         质量风险分析，我觉得可以通过以下几个过程来实现。

 A．    确定质量风险分类

 软件测试中，有一些通用的质量风险分类，总结如下，

 根据这些通用分类，结合之前的项目经验，对将要测试的系统质量风险进行分类。在需求评审完毕后，组织项目相关人员参与系统质量风险分类制定，以保证尽可能准确。

 B．    确定质量风险优先级

 系统质量风险优先级可以根据三种因素，严重性，优先级，发生的可能性

 严重性：该种类型的质量风险错误产生的后果的严重程度，按照下面的标准从1（破坏性最大）到5（破坏性最小）范围的数值评分。

 ü         1数据丢失――引起用户或系统数据的丢失

 ü         2功能丢失——系统主要功能丢失，或者主要不能使用

 ü         3能够克服的功能丢失――用户可以通过复杂或者变通的方式实现主要功能的使用。

 ü         4功能的部分丢失――主要功能模块的部分不重要功能丢失或无法使用

 ü         5表面错误――允许用户使用正常的功能，但是有明显的缺点，比如易用性

 优先级：该种类型的质量风险错误产生后，修复错误的紧迫性。取值范围从1（最需要修正）到5（最不需要修正）变化

 ü         1紧急的——必须立即解决

 ü         2重要的——必须在发行之前解决

 ü         3有价值的——错误会严重降低系统对于一个或多个用户的价值，应该尽量解决

 ü         4有需要的——如果条件允许，在本次版本中解决，否则，在下个版本中解决

 ü         5可忽略的——如果有需要，在以后发行的升级版本中解决

 发生的可能性：该种类型的质量风险错误产生的可能性。其值在1（最可能发生）到5（最不可能发生）之间。评定发生的可能性应该考虑这集中因素。

 Ø         该种质量风险类型包含的错误在系统中存在的可能性有多大

 Ø         该种质量风险类型包含的错误被开发人员遗漏的可能性有多大

Ø         该种质量风险类型包含的错误在系统的日常运行中，出现的可能性有多大

 ü         1很可能发生

 ü         2可能发生

 ü         3有可能发生

 ü         4可能性不大

 ü         5可能性很小

            将严重性，优先级，发生的可能性的数字相乘，则得到质量风险优先级数值，其取值范围在1（非常严重的）到125（微不足道的）。

         根据质量风险优先级数值，我们可以确定测试用例优先级数值，具体如下

 ü         1高——质量风险优先级在1－9。标记为高的测试用例，测试人员在执行这些测试用例的时候，如果执行用例失败，测试人员应该花费相当多的时间来重现和分离问题，并和开发人员沟通解决该问题。迭代开发周期中，在每次发布新测试版本，测试人员都要执行标记为高的测试用例。

 ü         2中——质量风险优先级在9－24。标记为中的测试用例，测试人员在执行这些测试用例的时候，如果执行用例失败，测试人员应该先根据bug的严重性和优先级评估，决定是否花费相当多的时间来重现和分离问题，是否和开发人员沟通解决该问题。迭代开发周期中，发布新版本后，如果时间允许，则执行这些用例的回归测试，如果时间不允许，则不执行。

 ü         3低——质量风险优先级在24－48。标记为中的测试用例，测试人员应该在执行这些测试用例的时候，如果执行用例失败，测试人员应该先根据bug的严重性和优先级评估是否需要重现和分离问题。迭代开发周期中，发布新版本后，不执行该种类的测试用例。开发周期完成后，执行回归测试时，执行该种类测试用例。

 ü         4微小——质量风险优先级在49以上。标记为微小的测试用例，测试人员应该在执行测试时，如果时间紧张，可以不执行该种类的测试用例，但是，如果在执行其他种类的测试过程中，发现该种类的缺陷，应该提交缺陷报告。该种类的测试用例在回归测试时不执行。

C．    完善质量风险分析

     完成质量风险分类表格后，质量风险分析基本已经结束，但是，在这个过程中，肯定存在一些归类错误或者风险优先级设置错误的地方，需要测试人员在设计测试用例或者在执行测试过程中进行完善，每次质量风险表格修改后，都需要同志项目组相关人员进行确认。

   探索性测试并不是一个最近才被提出来的测试技术，也不是一种很深奥的技术——事实上，许多测试工程师在自觉或不自觉地使用这种技术。那么，究竟什么是探索性测试呢？

   对探索性测试的理解本身会存在一些争议，因此，很难给出探索性测试的准确定义，不过，一般来说，探索性测试具有这样的一些特点：
   1、探索性测试强调测试设计和测试执行的“同时”性——这个“同时”是相对于传统软件测试过程中严格的“先设计，后执行”来说的；
   2、测试工程师通过测试来不断学习被测系统；
   3、探索性测试的重点是创造；

   探索性测试的出发点是“测试者如果没有真正使用过系统，就不可能真正理解和掌握系统，也就不可能真正有效地测试该系统”，相信所有有过测试实践的测试工程师都会承认这一点，确实，在我们没有接触到一个真正的系统之前，很难完全认识到这个系统，虽然可以在测试计划阶段按照需求或是设计的要求写出测试方案和用例，但总觉得这些用例不可能具有太强的可操作性。

   事实上，探索性测试给出的另一个测试的思路：“如果我们可以在对系统的测试中逐渐深入地学习系统，测试是否会更加有效率？”在我看来，这个问题的答案是显然的，如果测试工程师能够在测试中对系统越来越深入地了解，那么，利用这些逐渐增加的了解，自然可以让测试变得更加有效率。

   探索性测试只是一种方法和思路，并不是一个确定的过程。因此，在使用探索性测试时，无法回避的是When的问题，也就是说，在什么时候进行探索性测试更加有效呢？我的答案是“在你认为合适的时候”：）因为，探索性测试可以针对不同的测试层面，例如，针对业务场景的探索性测试、针对功能点的探索性测试，甚至是头脑风暴式的探索性测试，都能够在测试中发挥积极主动的作用。

    引言：自己开始了测试工作，总想把自己测试工作的点滴记录下来，可是，自己也是刚刚开始的测试，没有太多的经验，每次想写，缺又不知道写些什么。后来觉得，如果把自己做测试的过程记录下来，也是一种总结，或许能够给想做测试的人一些帮助，起个名字就是《追寻测试》.

真正做好软件测试是需要学习一定知识的，并不是说有了软件工程的基础，并不是说学习了C， C++， JAVA等开发语言，并不是说有计算机基础知识就可以做测试的，测试需要有测试的一整套知识体系，虽然软件工程会包含测试的一些内容，但是，那个仅仅就是罗列了测试的一些内容而已，比如简单介绍一些测试的阶段，测试的方法等，至少我学习过的软件工程课程里面关于软件测试仅仅就只有这些内容。

    但是，并不是说你在开始软件测试的时候，就一定需要做好软件测试工作的那么些知识。不是的，没有人天生就会做任何的事情，无论是多么牛的人，他也是从零开始学习，他也是进入了他所从事的行业多年才变的很牛的，那么如果我们喜欢做软件测试，我们当然也可以做到很牛的，只有我们努力。

要努力，首先就要进入到软件测试这个行业中。

如果你没有测试的基础知识，而你学习过软件工程的课程，学习过编程语言，你就有机会进入软件测试这个行业，如果你没有任何的计算机基础，但是，你对计算机感兴趣，你知道软件测试是做什么的，你也可以进入软件测试。进入软件测试并不难，难的是，你是不是对软件测试这个工作有兴趣，难的是，你愿不愿意做软件测试这个工作。

如果你对软件测试很感兴趣，你希望进入到软件测试这个当前最热的行业中来，我希望我所有的博文能够给你一些帮助，因为我也是从从对软件测试一无所知开始我的测试工作的。就让我们一起，一起来追寻测试。

JAVA的环境变量如何设置？

如果是Win2000或者XP，使用鼠标右击“我的电脑”->属性->高级->环境变量
系统变量->新建->变量名：JAVA_HOME 变量值：c:\j2sdk1.4.2
系统变量->编辑->变量名：Path 在变量值的最前面加上：%JAVA_HOME%\bin;
系统变量->新建->变量名：CLASSPATH 变量值：.;
CLASSPATH前面的那个"."和上面的意义是一样的。

Q:javac 不是有效的内部命令
A:有两个原因：1 没有安装jdk，安装了jre，这时候是可以运行java命令，但是javac不能运行。2 安装了jdk但路径设置不对，也就是path这个环境变量设置不对，请参考如上设置方法，一定要在path的最前边加上jdk的bin目录的路径。例如，如果设置了JAVA_HOME，那么在path前加【%JAVA_HOME%/bin;】

Q: JDK怎么使用？
A: 按照提示把JDK安装成功，设置好环境变量，打开记事本，输入：

1
2
3
4
5

 public class HelloWorld {
        public static void main(String[] args) {
            System.out.println("Hello ,world!");
        }
    }//注意大小写 ！！！

1
2

File[] fileSet=new File[3];//只是初始化了fileSet数组,并没有初始化各个元素,各个元素现在仍为null.
fileSet[0].exists();//该操作就会造成NullPointerException异常.

1
2
3
4
5
6
7
8
9

public class check extends Applet implements ItemListener{
      public void init(){ 
      .......
      } 
      
      public void itemStateChange(ItemEvent e){
      ......
      }
}

日志说明：

     今天开始了EDS系统的测试，这个项目的黑盒测试都都是由自己负责进行的，而且测试主管正在尝试建立完善的测试流程，因为这个是自己第一次独立进行的测试任务，一定要努力的去做好他，每天都写总结，为自己积累测试经验。

开始我的测试项目

     今天的测试，总天来说是比较凌乱的，测试程序是开发人员匆忙中完成的，版本的质量不高，出现了很多本不应该出现的问题，而且，对于需求说明中的一些功能，无论是编写人员还是开发人员，还是我自己都没有详细的去考虑，导致今天在测试的时候发现的问题需要修改需求说明。自己在前段时间所做的需求评审，其实并没有关注具体的细节问题，只是大致的把每个功能模块需要进行测试的内容进行了考虑，其实把时间都用在了测试用例的设计上面去了，而在今天的测试，发现测试用例并没有起到什么作用，测试的时候还是依照需求说明和自己的经验进行的，一个方面是自己设计的测试用例确实存在问题，另一个方面是，根据需求说明，其实在测试的时候就可以设计测试用例，不用参考已经设计好的测试用例了。

     公司的项目都是一个人负责一个项目，其实没有必要把测试用来设计的十分详细和正规，在测试用例中体现出测试项和测试思想就可以了，重点是测试思想的体现，其实测试用例就是你测试思想的体现，只不过详细的测试用例把你测试思想细化了，从输入数据方面进行了细化，因为公司的项目基本上一致的，测试数据的细化并没有太多的复杂性，在以后的测试用例设计中，应该重点体现自己的测试思想，而不是为了完成测试用例那个文档而去做一些本来没有必要却花费时间的事情。

      由于开始的时候没有考虑到会被要求今天就开始在linux下进行测试，自己给自己的测试时间是今天完成windows下的测试，没有想到，测试主管会要求自己在linux下也要进行测试，于是，整个测试都比较马虎，这是不应该出现的，不能为了时间而忽视质量，何况测试主管要求的，不一定非要去完成，就算是完不成，也没有什么关系，但是，如果自己测试的东西在以后正式交付以后出现了问题，那就不是测试主管的问题，而是自己的问题，测试主管不会去管你十分做完了他交代的任务，而是管你做的工作质量如何。

      晚上的时候，也总结了一些今天测试中的问题和想法，顺便写在这里，作为记录。

      1. 测试界面友好性问题如果在编码之前就能够确定，那么就不会出现今天提示信息不一致的bug了，因为没有统一的格式，每个开发人员在自己负责开发的模块用自己熟悉的提示信息，这样导致了整个程序的提示信息格式不一致和凌乱，虽然这个问题没有什么大的影响，但是，至少体现了一个开发团队的成熟度。

      2. 自己执行测试用例，所以测试用例可以不用详细，但是在测试中需要和其他人员进行交流，需要其他人员的支持，所以测试计划一定要详细，对需要其他人员支持的部分一定要详细描述，同时，在完成测试计划以后，应该把测试计划提交给相关的每个人，如果可能，应该组织评审，由自己说明测试自己对这个项目的测试思想，测试策略，需要哪些资源支持，提早让相关的人员知晓。

      3. 需求文档中没有规定的或者开发人员没有实现的程序和需求文档中规定的内容不一致，但是，事实上开发人员是对的，而需求文档是错误的，那么在这种情况下需求肯定要变更，而测试用例和测试都要相应的进行变更，此时就需要变更控制了，还有极端的情况是，需求说明书中的错误比较多，会导致测试错误，此情况应该如何处理呢？

在51testing上注册已经有好几天了，可是总是没有能够写下些什么，一个原因是自己前端时间一直都在同学宿舍里面住宿，每次回去都很晚了，而白天的时候有没有时间去写，还有一个原因就是一直没有下定决心去写些什么，就这样，直到今天，才决定要写些什么了，因为今天是7.1日，是一个月的新的开始，而起自己也有了属于自己的房子，虽然是租的，但是，至少可以做些自己喜欢做的事情了。

    进入测试并不是偶然的，但也不是必然的，如果不是麦结倒闭了，我不可能进入测试，如果不是因为等待了很久没有麦结的消息，我也不可能进入测试，如果不是听说陈启隆在测试，我也没有想去做测试，但是，就是因为这些偶然的因素，使我考虑进入测试这个行业。如果不是因为自己在上学的时候就关注测试，我不可能做测试，如果不是自己看了软件测试相关的一本书，我也不可能做测试，如果不是以前工作虽然是技术支持，但是做的工作却是软件测试的工作，我更不可能做测试，这些都是我进入测试这个行业的必然因素。

    无论进入测试这个行业的过程是怎么样的，现在我既然已经进入了，那么就要做好测试这个工作，不单单是测试现在很火，也不单单是测试入门比较简单，如果是开始进入测试有那么一些这两个方面的因素，那么现在我已经做了一个半月了，我已经喜欢上做测试这个工作了，虽然困扰我的一个问题是，我不喜欢编程序，但是，自动化测试的时候，需要编写测试脚本的，但是我想，既然我进入这个行业了，我也喜欢做这个行业，那么总会找到一个解决的方法的。其实，有些事情，你考虑的时候很困难的，但是如果你真正做的时候，并不是你考虑的那么困难的，就象现在我马上要做的自动化测试。

     已经开始了测试生活，已经开始了测试生活的记录，那么，我就要坚持去做，并且做的更好，如果有一天，我所写的这些内容，能够为别人所用，为别人所参考，为别人所赞誉，那么我将是欣慰的。

      欢迎所有喜欢测试的同志们，祝福所有做测试的同志们！