如果竞标成功，项目就开始要启动了。

      华为方会提供一份CRS(客户需求)和SOW（工作任务书），华为方派人过来进行需求培训，这时该项目的测试组长也要参与到项目需求的培训和评审，也就是测试工作应该从需求开始介入。

      项目经理编写《项目计划》，开发人员产出《SRS》，这时测试组长就要根据SOW开始编写《测试计划》，其中包括人员，软件硬件资源，测试点，集成顺序，进度安排和风险识别等内容。

     《测试计划》编写完成后需要进行评审，参与人员有项目经理，测试经理和华为方人员，测试组长需要根据评审意见修改《测试计划》，并上传到VSS上，由配置管理员管理。

      待开发人员把《SRS》归纳好并打了基线，测试组长开始组织测试成员编写《测试方案》，测试方案要求根据《SRS》上的每个需求点设计出包括需求点简介，测试思路和详细测试方法三部分的方案。《测试方案》编写完成后也需要进行评审，评审人员包括项目经理，开发人员，测试经理，测试组长，测试成员和华为方；如果华为方不在公司，就需要测试组长把《测试方案》发送给华为进行评审，并返回评审结果。测试组长组织测试成员修改测试方案，直到华为方评审通过后才进入下个阶段――编写测试用例。

      测试用例是根据《测试方案》来编写的，通过《测试方案》阶段，测试人员对整个系统需求有了详细的理解。这时开始编写用例才能保证用例的可执行和对需求的覆盖。测试用例需要包括测试项，用例级别，预置条件，操作步骤和预期结果。其中操作步骤和预期结果需要编写详细和明确。测试用例应该覆盖测试方案，而测试方案又覆盖了测试需求点，这样才能保证客户需求不遗漏。同样，测试用例也需要通过开发人员，测试人员和华为方的评审，测试组长也需要组织测试人员对测试用例进行修改，直到华为方评审通过。

　　在我们编写测试用例的阶段，开发人员基本完成代码的编写，同时完成单元测试。华为的外包项目一般是一次性集成，所以软件转测试部后直接进行系统测试。测试部对刚转过来的测试版本进行预测试，如果软件未实现CheckList清单上的10％，测试部会把该版本打回。否则，软件转测试部进行系统测试。根据《测试计划》进度安排，测试组长进行多轮次的测试，每轮测试完成后测试组长需要编写测试报告，其中包括用例执行通过情况，缺陷分布情况，缺陷产生原因，测试中的风险等等，这时测试人员就修改增加测试用例。待到开发修改完bug并转来新的测试版本，测试部开始进行第二轮的系统测试，首先回归完问题单，再继续进行测试，编写第二轮的测试报告，如此循环下去，直到系统测试结束。在系统测试期间，测试人员还需要编写验收手册，验收用例和资料测试用例等。

　　完成系统测试后，软件就开始转到华为进行验收测试，其中大概测试半个月，一般会要求测试部派人到华为方进行协助测试，并发回问题单给公司开发人员修改。

　　如果验收发现的缺陷率在SOW规定的范围内，那么验收成功，华为方付钱给公司，项目结束。如果超过规定的缺陷率，那么公司可能要罚钱了，整个项目组的成员（包括开发和测试）都可能要罚了。这种情况也会有，如果按照流程做事，概率不会很大。

　　测试流程的规范是很重要的，但是如果要成为优秀的测试人员只知道流程还是不够的，需要学习的东西还很多，包括熟悉相关测试业务，计算机专业知识（linux，oracle，tcp/ip等），开发的架构和语言，性能测试和系统瓶颈分析、调优等。还有性格（细心，耐心）和人际沟通能力也是很重要的决定条件。任重而道远，我刚起步，希望大家一起在测试的路上互励互勉。

　　2. 相关性检查：删除/增加一项会不会对其他项产生影响，如果产生影响，这些影响是否都正确。

　　3. 检查按钮的功能是否正确：如update, cancel, delete, save等功能是否正确。

　　4. 字符串长度检查: 输入超出需求所说明的字符串长度的内容, 看系统是否检查字符串长度,会不会出错.

　　5. 字符类型检查: 在应该输入指定类型的内容的地方输入其他类型的内容(如在应该输入整型的地方输入其他字符类型),看系统是否检查字符类型,会否报错.

　　6. 标点符号检查: 输入内容包括各种标点符号,特别是空格,各种引号,回车键.看系统处理是否正确.

　　7. 中文字符处理: 在可以输入中文的系统输入中文,看会否出现乱码或出错.

　　8. 检查带出信息的完整性: 在查看信息和update信息时,查看所填写的信息是不是全部带出.,带出信息和添加的是否一致

　　9. 信息重复: 在一些需要命名,且名字应该唯一的信息输入重复的名字或ID,看系统有没有处理,会否报错,重名包括是否区分大小写,以及在输入内容的前后输入空格,系统是否作出正确处理.

　　10. 检查删除功能:在一些可以一次删除多个信息的地方,不选择任何信息,按”delete”,看系统如何处理,会否出错;然后选择一个和多个信息,进行删除,看是否正确处理.

　　11. 检查添加和修改是否一致: 检查添加和修改信息的要求是否一致,例如添加要求必填的项,修改也应该必填;添加规定为整型的项,修改也必须为整型.

　　12. 检查修改重名:修改时把不能重名的项改为已存在的内容,看会否处理,报错.同时,也要注意,会不会报和自己重名的错.

　　13. 重复提交表单：一条已经成功提交的纪录，back后再提交，看看系统是否做了处理。

　　14. 检查多次使用back键的情况: 在有back的地方,back,回到原来页面,再back,重复多次,看会否出错.

　　15. search检查: 在有search功能的地方输入系统存在和不存在的内容,看search结果是否正确.如果可以输入多个search条件,可以同时添加合理和不合理的条件,看系统处理是否正确.

　　16. 输入信息位置: 注意在光标停留的地方输入信息时,光标和所输入的信息会否跳到别的地方.

　　17. 上传下载文件检查：上传下载文件的功能是否实现，上传文件是否能打开。对上传文件的格式有何规定，系统是否有解释信息，并检查系统是否能够做到。

　　18. 必填项检查：应该填写的项没有填写时系统是否都做了处理，对必填项是否有提示信息，如在必填项前加*

　　19. 快捷键检查：是否支持常用快捷键，如Ctrl+C Ctrl+V Backspace等，对一些不允许输入信息的字段，如选人，选日期对快捷方式是否也做了限制。

　　20. 回车键检查: 在输入结束后直接按回车键,看系统处理如何,会否报错.

				
						读完TDD（测试驱动开发），发现其中主要就是在反复说了这么两件事情（也就是两个简单的规则）：一、在写任何代码之前，写一个会失败的自动测试程序，即单元测试；二、消除重复设计，优化设计结构，即重构。整本书都围绕着这两个规则来进行说明，告诉读者到底要如何这样做？又如何分阶段应用这些规则？这两条简单的规则可以运用多深？
				
		

				
						第一部分通过一个简单的实例来告诉读者如何使用TDD，如何反复通过“不可运行/可运行/重构/不可运行/可运行/重构”来进行开发；第二部分告诉读者如何使用单元测试，怎样组织单元测试；第三部分则是将TDD分解成较小的步骤来进行详细说明，根据我对本书的理解，我认为需要完全将TDD运用到日常的开发行为中，则要按照以下非常细小的步骤进行：
				
		

1.       获得任务。即项目经理安排的任务。任务往往不止一项。将它们写入周工作计划表或者月工作计划表。

2.       选择任务。每天开始工作之前，将今天将要解决的问题写入工作计划列表。并选择自己最有把握完成的任务作为当前任务。

3.       分析并分解任务。将当前任务分解成一个个相对简单的问题，分解的问题最好是能在十多分钟之内能完成，并将它们写入工作列表。如：若要实现多币种相加，则可以分解为：实现相同币种之间的相加，不同币种之间的互换，最后才能实现不同币种之间的相加。

4.       写测试列表。将分解后的问题所对应的测试写入测试列表。

5.       选择测试。从测试列表中选择自己认为最有把握实现的一项。如：“同币种相加”对我来说是最有把握实现的一项，因此我最先来实现它，即先从它的测试程序开始编写。

6.       编写测试数据。写一个容易让人理解的必须实现的测试数据列表，尽量使用显然数据。如：用 String 表示 IP 地址 "255.255.255.255" 转换为 int ，在我们写测试数据时应这样写： (255 << 24) + (255 << 16) + (255 << 8) + 255 ，而不是写“ -1 ”。

7.       编写测试。选择一项最容易让测试通过的测试数据加入测试方法。断言优先，然后加入为了让断言通过编译的一切准备条件。

8.       运行测试，不可运行状态。

9.       编写方法注释，把所有想到的该方法要实现的功能写上。

10.   编写功能代码，使之达到可运行状态。

11.   重构，消除重复设计。

12.   往测试方法中增加一个新的小测试。

13.   运行测试，不可运行状态。

14.   修改功能代码，使之达到可运行状态。

15.   重构。消除重复设计。

16.   重复 12-15 。

17.   当无论如何也不能让该测试通过的时候，认真想一想是不是哪里出大问题了，如果实在想不出来的话，就将现有代码扔掉，重新开始。

18.   所有测试都运行通过之后，仔细检查所有代码，看是否还有值得重构的地方，并重构。

19.   提交 (check in) 。

20.   再选择测试列表中的下一个测试。重复以上步骤。

21.   当一天的工作结束时，若有某个任务未完成，则留下一个不完整测试，以便于次日能迅速回忆起当时写该代码时的想法，并接着写下去。

一般的数据类都应该有自己的数据合法性检查，如一个Person类，它的年龄属性是int型的，但是如果给它赋值10000则为不合法，一个人不可能活那么长时间。因此需要在创建该类的对象时必需对其进行合法性检查，若构造方法传入的是非法数据，则不让其创建该对象，并抛出异常。也许大多数人认为只需要对构造方法传入的参数进行合法性检查即可。如下所示：
class ValidClass
{
        int  dataValid1;
        String dataValid2;

         public ValidClass(int i, String str)
         {
               check(int i, String str);
               dataValid1 = i;
               dataValid2 = str;
         }

         void check(int i, String str)
         {
            if(i >100 && i <= 0) throws new RuntimeException("message");
            if(str == "str") throws new RuntimeException("message");
         }

         void setDataValid1(int dataValid1)
         {
               this.dataValid1 = dataValid1;
         }
}
实际上这种合法性并不可靠，这样只是保证了在构造方法中传入的数据是合法的，但是不能保证程序员在使用该对象时能传入合法的数据。如下程序代码：
ValidClass validClass = new ValidClass(2, "123");
validClass.set(200);
这样使用的话，程序运行并不会报错，但是实际上我们已经传入了非法数据到该对象中去了，因此为了避免出现程序员在使用的时候也犯这种错误，对数据的合法性检查的正确方式应如下所示：
class ValidClass

       {

              int  dataValid;

              protected checkDataValid()

              {

                     check if dataValid valid

                     if (fail)

                     {     throws new RZXDataException(this, “.needValidate=”

+needValidate); }

              }

public ValidClass(int in)

              {    

setDataValid(in);    

}

              public setDataValid(int in)

              {                     
                     checkNeedValidate();

                     dataValid = in;

              }

       }

在set方法中进行合法性检查，然后在构造方法中也调用set方法设置字段值，而不直接使用类中的字段。这样做的好处很明显：不仅保证了构造方法中传入的数据必须合法，而且可以保证程序在使用的过程中不能使用非法数据，如果程序员使用了非法数据，程序运行必然出错，并且能够很快的找到错误的根源所在。

         另外，有些程序员认为，有些数据类的对象全部来自于另一个数据对象，也就是说该类的构造方法中的参数即另一个数据类对象，因此在该类中所有与被传入对象类中有相同的合法性检查的数据字段不需要再进行合法性检查了。其实这种想法是错误的，问题与上面所说的一样，你能保证传入的数据是合法的，但不能保证使用者在调用你的set方法时能100%传入合法数据。因此，程序员是不应该偷这个懒的。也许有人会说，他们的合法性检查完全一样，如果在该类中再写的话就会出现大量的重复代码了。能想到这里是对的，但是如果你有一定的经验，你就知道去建立一个专门保存合法性检查方法的类，这样你就可以在需要进行合法性检查的时候就使用该类里面的方法，如果该类中没有你所需要的方法，你就可以在里面加入你所需要的合法性检查方法，再去使用它。这样做会使得代码非常的清晰。

         我认为，应该在自己类中的所有使用“this.value = data;”字样的代码都应该使用setValue()，因为也许这个字段现在不需要进行合法性检查，但是不能保证将来也没有合法性要求。而一旦以后需要对该字段进行合法检查的时候，就需要在set方法中增加合法性检查代码，而且需要将该类中所有对该字段的赋值语句均改用set方法。一旦有某处漏掉，则很可能带来致命的错误。也许在某个运算中带来了非法数据，但是你却怎么也不会往这方面去想，因为你一直以为自己全部都作了合法性检查的。

package com.liyingcheng.netTest;

import com.liyingcheng.net.Sort;

import junit.framework.Test;
import junit.framework.TestCase;
import junit.framework.TestSuite;
import junit.xiaoxuhui.Sum;

public class SortTest extends TestCase
{
 // Sort popObj = new Sort();

 public SortTest(String name)
 {
  super(name);
 }

 protected void setUp() throws Exception
 {
  super.setUp();
 }

 protected void tearDown() throws Exception
 {
  super.tearDown();
 }

 static public void assertEquals(int[] expected, int[] actual)
 {
  for(int i = 0; i < expected.length; i++)
  {
   assertEquals(null, expected[i], actual[i]);
  }
 }

 public void testPopSort()
 {
  int[] expected = new int[] {1, 2, 3, 4};
  assertEquals(expected, Sort.popSort(new int[] {1, 2, 4, 3}));
  assertEquals(expected, Sort.popSort(new int[] {1, 2, 3, 4}));
  assertEquals(expected, Sort.popSort(new int[] {1, 3, 4, 2}));
  assertEquals(expected, Sort.popSort(new int[] {1, 3, 2, 4}));
  assertEquals(expected, Sort.popSort(new int[] {2, 1, 4, 3}));
  assertEquals(expected, Sort.popSort(new int[] {2, 4, 1, 3}));
  assertEquals(expected, Sort.popSort(new int[] {3, 2, 4, 1}));
  assertEquals(new int[] {1, 2}, Sort.popSort(new int[] {2, 1}));
  // assertEquals(new int[]{1,3,2,4},popObj.popSort(new int[]{1,2,4,3}));
  // assertEquals(new int[]{1,2,3,4},popObj.popSort(new int[]{1,2,4,3}));
 }

 public void testCreateArray()
 {
  assertEquals(4, Sort.createArray(4).length);
 }

 public void testGetSum()
 {
  assertEquals(5050, Sum.getSum(1, 100));
 }

 public void testFalse()
 {
  assertFalse(false);
  assertTrue(true);
 }

 public void testIsNull()
 {
  String str1 = "";
  int[] arr1 = {};
  String str2 = null;
  int[] arr2 = null;
  assertNotNull(str1);
  assertNotNull(arr1);
  assertNull(str2);
  assertNull(arr2);
  // assertNull(str);
 }

 public void testNull()
 {
 }

 public void testNotSame()
 {
  String str1 = "123";
  String str2 = "123";
  String str3 = new String(str1);
  String str4 = new String("123");
  int one = 1;
  int first = 1;
  assertSame(one, first);
  assertSame(str1, str2);
  assertNotSame(str3, str4);
  //fail("hahahahahahahah");
  /*
   * assertNotSame(one,first); assertNotSame(str1,str2);
   */
 }

 public static Test suite()
 {
  TestSuite suite = new TestSuite("Test sort!");
  suite.addTestSuite(SortTest.class);
  return suite;
 }

}

• MathToolTest.java

package onlyfun.caterpillar.test;

import onlyfun.caterpillar.MathTool;
import junit.framework.TestCase;

public class MathToolTest extends TestCase {
    public MathToolTest(String testMethod) {
        super(testMethod);
    }

    public void testGcd() {
        assertEquals(5, MathTool.gcd(10, 5));
    }

    public static void main(String[] args) {
        junit.textui.TestRunner.run(MathToolTest.class);
    }
}