1.测试前准备阶段
主要是相关业务的学习。业务知识是测试的根本依据，只有业务过关了，以后才能有效的进行测试工作。
了解业务步骤：
a、了解业务名词；
b、对现有系统的学习：功能点、业务场景等；
c、分析现有系统数据库，了解数据的走向。
2.需求分析阶段
需求是项目开发的基础，也是测试的依据。所以需求分析一定要做。但是很多公司是没有详细的需求文档的，那如何进行需求分析呢？
此时分析数据库就是一个非常好的方法：
a、每张表的索引和约束条件；
b、数据的来源、走向；
c、数据的存储、变化；
d、数据间的关联；
e、表与表间的关系；
这些分析都可以为了解业务场景和之后的测试用例设计打好基础。
3.测试计划阶段
我们总是觉得被测试进度紧逼、计划失控、测试不完全等等状态，其实解决这些情况的最好方法就是：制定测试目标。
在计划初期先明确测试目标，制定不同层次目标的执行标准，指导后期设计不同级别的测试用例，跟踪不同级别的缺陷修改。在测试时间较紧情况下，至少可以先把保证所有功能正常操作的最低目标版本先提交给客户，不会再有手忙脚乱，心里没底的状况。
测试目标分为：
最低目标
基本目标
较高目标
最高目标 等级别
可以使用表格形式来规范目标准侧，例如：
测试目标准则表
|
目标 |
测试范围 |
需求覆盖率 |
|
最低目标：
正常的输入+正常的处理过程，有一个正确的输出
|
（明确的功能点全部列出来） |
1. 功能：
正常功能
异常功能
单功能
业务场景
非功能：16种测试类型
2. 输入覆盖率：
有效无效
处理过程：基本流
备选流
状态变化：正常、异常
输出 |
|
SRS00001 |
|
SRS00002 |
|
SRS00003 |
|
基本目标：
对异常的输入有错误的捕获，并进行相应提示或屏蔽
|
|
|
|
较高目标：
对隐式需求进行测试
|
|
|
根据公司规模不同，确定测试目标级别也可不同。一般小公司有最低标、基本目标即可，大公司可以提高目标标准，直接从基本目标开始，直至最高目标。
4.具体的ST用例的编写以及执行
测试用例设计的粒度一直是个讨论对象，很多时候总会强调时间很紧啊，如果时间再多点，我的用例肯定会设计的再细一些！！
是不是设计的越细就一定越好呢，不一定，测试是无穷尽的，使用穷举方法来进行测试是不科学的。
因为制定了测试目标，那么就应该根据测试目标，在设计测试用例时也要制定设计用例目标。
比如：按照最低目标选择测试用例
输入—>有效
处理—>有效
输出—>有效
按照最低目标的宗旨，只要是设计出来的测试用例足以覆盖和验证系统基本功能可以正常使用，那么这些测试用例的粒度就足够细了！从而提高了设计用例效率，同时也提高了测试效率。
5.测试之后的评估
实现一级测试目标之后都要进行评审工作，根据评审结果进行系统版本发布。例如：
1.保证所有需求都有测试用例
2.保证所有功能的正常操作和正常操作有对应的测试用例 V1.0版本
3.保证所有功能的异常校验有对应的测试用例 V2.0版本
4.各功能组合形成的业务流有对应的测试用例 V3.0版本
5.各功能或整体软件所需满足的非功能性需求有对应的测试用例 V4.0版本
这样做既可以对代码版本进行控制，也可以应对需求变更的问题。
也许“确定测试目标”还不能彻底解决复杂测试工作中出现的问题，但是我觉得这最起码可以让你的测试工作变得有条理；跟领导汇报工作的时候业绩和工作效率有凭可据；面对需求变更的时候有理可依！
