测试工作从时间上说，可以分为以下几个阶段：
开发者写程序时，要进行单元测试，比如某个函数中参数的变化是否正确，有没有那个参数不按照期望的方式去改变
>>
当一大块程序写好了，要进行代码覆盖率测试，尝试以各种不同的组合运行各段代码（单元测试已通过的），最好全部代码各种组合覆盖到90%
>>
然后要进行构建，开发者进行构建测试，即，把代码变成软件，然后测试各种基本功能，例如能否安装，能否运行，目标是得到一个“可测”的软件
>>
测试人员拿到可测的软件，进行验收测试，即尝试设计好的各种场景或称测试用例，测试结果是一个这样的表
|
场景ID |
场景名 |
测试结果 |
Bug ID |
|
001 |
登陆 |
成功 |
|
|
002 |
点击十大 |
失败 |
001 |
|
… |
… |
… |
… |
>>
以上bug找到并解决后，进行搜索式测试，有意无意搞一些奇怪的场景看有没有bug
>>
回归测试，最新的版本把bug都找到并解决后，测试新版本有没有旧版本中没有的bug，有了的话就叫做“退化”，这就是回归这两字的来由
>>
场景/集成/系统测试，把一个已经测号的模块放到整体环境中，看看在实际场景中整体上各个模块能否完成各自的工作
>>
如果程序变得很大，开发者把代码签入后再找代码代价很大，则可以开发者与测试者结对进行伙伴测试，测试者找到bug开发者fix后，才签入
>>
效能测试：不解释
压力测试：故意搞些软件受不了的极端场景，看软件会否崩溃，崩溃后会不会造成太大的影响
内测、公测：员工内部、社会上都用用软件看有没有问题
易用性测试：不解释
小强大扫荡：开发者、测试者一起找bug
--------------------------------------------------------------------------------------------------------
黄色是开发者该做的，蓝色是测试者该做的，没颜色的可能我们用不到。测试员不接触代码，只接触已通过构建测试的“可测”软件。
测试计划：
1.与team其他成员商量好每次发布测试任务时的规范，并对他们科普下下神马是测试
2.设计测试用例，测试已有的版本，目前软件功能依然很简单，所以还是很容易跟上进度滴
From： Gaoyao