公司测试工作效率低下、问题之多，测试妹子不合理的方法，项目难交付啊....哎，还是自己简单总结下吧，希望有用。
一测试工作的意义
我们知道，一个完整的开发流程。包括了：确定需求、产品研发、实施交付三个步骤，与岗位对应起来，是产品、技术、测试，产品负责规划、技术负责开发、测试人员负责验收。
一流的战略+三流的执行 和 三流的战略+一流的执行，怎么选？马云选择后者。一个产品体验的好快，不是由一个人决定的，需要团队中每个角色对自己负责那道流程把控好。
再好的战略如果无法执行，那也是一文不值。测试人员需要验收实际执行成果。所以，测试工作必须到位。
二什么是互联网产品测试
产品测试包括非功能性测试和功能性测试。
非功能性测试指的是环境测试，如网络环境：3G\4G\Wifi。手机环境：系统ios\android、系统版本、型号等;
功能性测试指的是功能逻辑测试，开发的功能是否按要求运作。我们主要关心这块，通过编写测试用例文档理清逻辑的同时方便测试工作的进行。
三写测试文档的好处
能确保测试人员了解需求，产品功能，而不是在测试过程中每去询问他人，影响效率；
不会疏漏测试点，忘记分支流程或边缘功能点；
不用每次在测试的过程去想逻辑（这很累），而且容易遗漏。
四测试用例编写说明
1.编写前提
明确知道需求和与之对应的产品功能，根据产品人员提供原型（需求文档）、产品和开发确定的功能逻辑编写。
2.什么是用例？
可以理解成用户使用产品完成某一目的的分解任务。如：登录账号、支付订单等。
任务会因为测试人员的分解的粒度不一样，产生变化。举个比较大的栗子：
使用京东app购物。用户主要需要这么几个任务：
1、打开app
2、登录
3、选择商品
4、下单
5、付钱。
但是如果把任务分的更细的话，会更多的任务：
1、打开app
2、使用微信登录\手机号登录
3、使用搜索直接筛选商品/使用分类功能筛选商品
4、加入购物车，选择付款商品
5、填写收货地址、提交订单
6、使用微信支付、京东支付、让好友代付。
上述过程当然还能更细。
用例粒度大小需要编写人员把控、平衡，分的过细会显得文档冗长，分的太大又会影响测试描述。这里建议把按照不同模块的复杂程度来分。如：
登录注册模块和订单管理模块。登录注册较为简单，那可以把功能点拆的较细。可将登录账号功能点分用例成：输入账号、输入密码、点击登录按钮。而订单管理模块比较复杂，可以拆分功能为：管理待支付订单、管理待收货订单、管理退款订单等。然后再在管理待支付订单这个功能点里详细描述用例即可：删除待支付订单、支付订单。
这么做的目的是保证涵盖所有的功能点同时帮助自己或别人相对轻松阅读文档。
3.文档结构：
1、模块：该功能点具体属于哪个模块的，填写这个主要是方便查找，如：账户系统模块。
2、功能点：指模块下具体的某个功能。如：登录、注册。
3、编号：每个用例的编号，方便快速定位。可通过设定规则来方便使用：如：A0001。其中A表示注册/登录模块。00表示账号登录，01 表示账号密码登录下的第一个测试用例。
4、用例名称：具体测试用例的名称。一般采用N+V结构（动名词）。如：输入账号、输入密码、密码不合规等等。
5、前置条件：指要开始测试操作前，需要满足哪些条件。如：提交订单前，需要先登录账号。删除订单前，需要有订单能删除。
6、操作步骤：指要达到预期测试结果，需要按哪些步骤来。最好说明在什么页面，点击或操作什么内容，输入什么内容。
7、预期结果：说明按照前面操作步骤写的应该呈现出怎样的结果。根据产品设定的交互填写。
8、测试结果：若符合预期，则可不填写。如不符合，需要说明哪里不正常。
9、测试时间：方便查询，管理测试进度。
10、bug负责人：具体落实到谁身上去解决，能有头有尾。
