测试是一个严肃规范的事情，跟大家分享一下测试的完整工作流程，在以后工作中也能做到知道每一个环境都是干嘛的，应该怎么做。
1 需求分析：参加需求分析会，俗称：“对需求”，需求是开发和测试的导向，需求不可以错
2测试计划：根据任务量拟定计划
3测试用例：根据计划书中的任务分配，进行测试用例的编写（采用各种测试方法）
4执行用例：记录执行结果，提交BUG，并跟踪BUG状态
5缺陷报告：总结哪些模块产生了哪些缺陷
6测试报告：总结本轮测试活动，评估软件整体质量
需要注意的是，以上流程，需求需要评审，计划需要评审，用例也需要评审，但不同公司，流程不同，评审方式也不同。常见的评审就是所有相关人员（产品，开发，测试）一起参加。

测试用例详细介绍测
试用例是执行测试的依据，把测试系统的操作步骤用文档的形式描述出来，简单来说，就是对于一个功能点你打算怎么测，把“你是如何测试的”记录成文档 。
测试用例是功能测试最重要的内容了。它主要就是解决的问题就是测什么、怎么测，是测试工作进行的依据
测试用例一般都是用excel表格去写的。

为什么要写测试用例
1）避免盲目测试，突出测试重点，提高测试效率（有时候测着测着就不知道某些点刚才测没测）
2）软件更新时，只需改动少部分用例，便可以开展工作，能够缩短测试周期（现成的）
3）测试相似软件功能时，用例基本可以通用和复用（做少量修改就可以直接拿来用）
4）方便监督测试过程（领导要知道你一天都干啥了）
5）记录测试过程，防止漏测（把控测试覆盖率）

测试用例的注意事项1）用例编写前，要明确用例具体的格式要求，比如编号的规则，提交的方式
2）用例要不断更新维护，每次写用例都是升级完善的过程（杀虫剂悖论）
3）用例需要正式评审，注意，评审之前自己一定要熟悉，否则开会可能会非常尴尬，别人可能会对你不合理的地方，或者有疑问的地方提出问题，你需要很快的解答
4）对需求点理解的越全面，用例的覆盖率就越高，也越能体现测试人员的技能水平

测试用例的编写原则
1）准确：符合测试需求，且测试方式方法正确
2）简洁：不要加入多余的或可有可无的步骤（不是写作文），不要写你做了什么，而是写应该做什么
3）纯净：不会因为执行完该用例，而去影响其他用例的执行，且不会产生“脏数据”
4）可执行：可被他人理解，可被他人执行，也就是其他人照着用例可以很顺畅地执行下来
5）可复现：要保证在任何时间测试，测试结果都保持不变
6）可跟踪：一个需求对应多条用例，每条用例都可跟踪到需求
注意：一般情况下，正常流程是一条用例（正例），异常流程是多条用例（反例）
注意：每条用例只包含一个测试点，不能将多个测试点放入一条用例中
7）可覆盖：尽可能地覆盖全系统，用例执行完，遗留的缺陷最少，这是评定的标准