测试心得2017-3-20

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