普通用户和测试人员在测试的时候，区别：
普通用户在进行应用测试的时候有以下几个特点：
1、专注于某个功能点或某条业务逻辑的测试，测试的覆盖度不足
2、当遇到问题就认为是bug，不考虑测试环境，测试条件，预期结果，比如当没有网络或是网络很差的情况，应用常常会出现异常，功能常常失效，这时候用户不是先排除环境问题，而直接认为是应用本身的问题。这种情况还有很多，比如手机内存不足死机、切换应用后功能失效等等，当然站在体验测试的角度，这确实是问题，但是程序的稳定性、性能、安全都不是某个版本一次性解决的问题，而是要不断的持续集成。
3、要让用户做专业的测试，按照测试步骤来，用户先要熟悉需求，分析需求，考虑输入条件，考虑操作步骤，设想预期结果等等，用户要按照步骤测试多久呢？这样的效率可想而知
4、普通用户不懂业务流程，他们去执行测试用例，可能看都看不懂。不懂业务的测试人员，有执行测试用例的价值吗？测试用例应当是有思考活动存在的。
固定测试用例（比如用excel、禅道、testlink等）所带来的问题：
1、修改维护工作量大
2、用例未经过评审
3、用例编写人和执行用例人不一致，思想不统一
4、测试重点、优先级、标准、规范不明确
比如测试用例里面写死了数据、业务步骤 不同测试人员都按照同一步骤来测试，就好比输入比10小的数，改为输入9，则可能只测试到一个临界点，还有（隐藏点0、非正数呢？），如果需要测试其他客户、其他业务呢？有些测试人员就再复制一个用例出来，造成用例泛滥，且测试点不全。这就跟用例未评审、测试标准、测试规范有关了。
有时候公司需求会进行变更，去掉老模块、优化老模块，增加新模块，一旦模块变化，对应模块所涉及的用例可能全部都会修改，一个模块所涉及的测试用例可能就会有上百条
测试用例依然没有思考的过程 负责第一次编写的测试人员有思考，但负责执行的测试人员，没有再继续跟开发交互测试过程，没有更深入的思考，而是仅仅按照用例执行，那这种效果等于走过场。
3、遇到十几个、甚至几十个步骤的功能，用例编写耗时 例如：打开浏览器，输入账号密码登录，这些其实也是不必要展示的步骤，做测试就要熟悉业务，测试人员应当更加关注的是开发是否做了正确的功能，功能是否做了正确的事情，在一个测试、开发比例1:4（有些是1:10）的团队里面，测试人员的时间是有限的，不要陷入过分的步骤细节里面去深究，要把重点思路放在运用哪些测试方法、如何组合更加有效覆盖测试故事点。
例如简洁的测试故事点：作为主帐户，输入正确的用户名和密码登录系统，以便能够查看当日的带宽数据。
测试人员的技能提升困难
我认为大多数测试人员要花更多的时间去了解产品需求、产品业务逻辑，要是长期只为1个产品测试，测试会产生盲点，会因为重复性太强而产生惰性，从而无法创新测试点。一旦遇到这种情况如果团队不是学习型，很难产生技术突破，而测试可能到最后没事可做，因为产品生存周期越长越稳定，能发现的bug越少，当然这是没有新需求的情况下。
测试计划
组织形式：人员
测试对象：移动APP或是后台管理系统
需求跟踪：测试覆盖程度
通过与执行标准：什么程度的缺陷达到多少不通过，模块缺陷的频率
测试执行挂起标准和恢复必要条件：无法成功登录，导致登录后的功能都无法进行测试，此时必须将测试任务挂起直到修改完成
测试工作任务分配：组长应该管理、统计、策划和解决问题，而不是执行
测试交付及收集反馈：对通过的产品和其它部门进行交接沟通，需要进行评审，交付确认，反馈确认，以及持续跟踪