刚刚入行的时候，我请教前辈，应该如何做
软件测试，她告诉我一句话：Think before you do。而后她告诉我，我应该制作一个测试覆盖的表格，详细的列出所有我需要做的测试，并且在随后的测试中不断的添加想到的方方面面，这样我就能不断的补充细节而永远不会失去对全局的把握。这后来就成为我做测试的一个基本
工作习惯。
写自动测试程序当然也不能摆脱这些基本的规律。因为无论是自动还是手动测试，都是一种手段而已，其目的是为了验证软件产品的质量。一味的将所有的测试
自动化其实是不合理的。
列出测试覆盖表格(
Testing Matrix)也很简单，不过是将工作细化而已.细化的原则是从简单到复杂，从部件到整体。
列表如下：
1. general user
* self service (modify user) (UF)
* search user (UF)
* search group (UF)
2. administrator
* User
o add user (UFL)
o search user (UF)
o modify user (UFL)
o active/in-active user (UF)
o delete user (UF)
* Group
o add group (UFL)
o search group (UF)
o modify group (UFL)
o active/in-active group (UF)
o delete group (UF)
* Policy
o Manage Policy (UF)
o manage search policy (UF)
o manage password policy (UF)
o manage user settings (UF)
* Self service (UF)
（凡例：U:UI测试， F:功能测试，L:逻辑流程测试）
功能测试的目的是为了保证网页能够将正确的信息传递给后台服务器，和将后台服务器的资料准确的显示在网页上，至于后台如何操作，则不是网页的功能测试的内容。我们需要独立的后台功能测试
UI测试的目的是为了保证网页的页面设计元素准确的显示在网页上
举例来说，对于同一个增加新用户的页面，UI测试是为了确认网页上会出现诸如“输入姓名”，“输入密码”等等的选项，至于用户在这些选项杀功能输入的数据是否被准确的输入了后台服务器，则是功能测试的内容。－－之所以将这两个看起来紧密结合的部分分开，是因为这样会让我们的每一步测试都从一个最小的单元开始，不至于有任何疏忽和遗漏。
逻辑流程测试也是必须的，比如说用户登录的页面在收到几次不匹配的用户名和密码之后，也许在逻辑流程上就可以转到另外一个提醒页面。
表格有了，我们还需要确认测试的程度。如下：
1. smog testing
2. acceptance tseting
3. regression testing
4. corner testing (enchanced testing for cortner cases), also called extrem condition testing
如果从测试数据的角度来分析，这些分类很容易理解。
somg testing：只提供符合要求的数据，确认功能在正确的数据情况下工作正常，这一级测试的目的是为了验证产品的最基本功能的完备
acceptance testing:根据设计的要求，提供正常范围内的合格和不合格的数据，目的是为了检测软件在正常情况下的正常使用
regression testing:在数据提供上和acceptance testing没有不同，但是涵盖更加广泛的产品功能，它由acceptance testing发展而来，仅仅是在功能上更加完备而已。
corner testing:提供比较极端情况下的数据，比如几百个字符长度的用户名和密码，目的是检验产品在极端情况下的对数据的处理能力－－这种处理能力不是为了验证产品的“稳定性”，而是为了验证产品对数据处理的“正确性”
