(04)微信端公众号+web端后台测试的几点经验
2018-04-02 本文已影响304人
哇哈哈E
前段时间,老板拿了微信号+Web端的项目来测,要求敏捷开发(🙂️后来发现他们要求的敏捷原来是一直72变)。
自己之前主要是偏向功能更多,这次要顺带提到了点接口(还好自己空余的时候有学点,正好趁这次可以实践操作一下,不过老板还真是心大,为了对得起他的信任,加油测吧)
在测试前,需要考虑到以下几点:
- 微信公众号前端测试会涉及到什么?
- Web后端测试会涉及到什么?
- 微信端测试是否会因为腾讯爸爸的改动而有所影响?
- 整个流程是否安全?
- 微信+web的模式?(我们的公众号是商城模式,所以难免涉及到一整个订单的流程,以及其他的一些交互性的东西。所以在这方面的背景也要自己去弄清楚,前端和后台的链条性自己也要非常清楚。)
在测试中,一般功能方面我是这样测的:
- 冒烟测试:关于微信公众号端,对每个页面进行任意点击。能够顺利点击进入才可进行下一步的测试,否则,因为公司开发的水平问题,很多模块不能够进行测试,反而浪费时间;关于Web后台端,同样对每个页面进行任意点击,若能顺利点击通过,再关心界面UI和流程的问题。
个人觉得应该:功能—>流程—>界面UI的先后顺序来进行测试,但是大多数时候,我们会更偏向于关注第一眼所看到的东西,即界面UI这种低级Bug
- 系统测试:这里我们是分模块来进行测试的。其实之前有写测试用例,但实际在这个测试过程中,并没有很好地把测试用例用起来(但我这用例还是没有白写,1⃣可以给自己心理有个谱,要测哪些方面哪些点,之后回顾的时候会发现漏测,记得千万别漏测啊;2⃣可以交给用户看,我们测过了哪些;3⃣由于“敏捷”所以需求实在变得有点快,边写测试用例边进行测试,宝宝确实有点办不到),所以整个测试中主要是通过原型图和需求列表在发散&Free测试。一个一个模块进行仔细地测试,然后是模块间的互动测试,最后再进行一个整体流程的测试。随时将发现的问题在禅道中提交相应的Bug&截图.
- 场景测试:在这个环节,会把自己想象成各种挑剔客户,会对微信公众号前端的整体做一些挑剔,甚至有些吹毛求疵,力求把公众号能够让用户用起来觉得还行;web后端主要面向的是内部使用人员,但也要力求更好。
在测试中,一般接口方面我是这样测的:
-
需要开发将所有需要测试的接口定义下来。
- 每个接口的url是什么?
- 接受什么样的参数?
- 每种参数的类型是什么?
- 哪些参数是可选的,哪些是必选的?
- 输入参数正确/参数异常,接口的返回是什么?接口行为是什么?
-
有了详细和明确的接口定义后,就可以用各种方法来设计测试用例了。
- 弱覆盖:至少应该覆盖所有的输出可能;
- 中等覆盖:对于同一种输出,测到所有有效等价的输入情况;
- 强覆盖:如果在此基础上,对后端的数据内容和服务状态也进行了验证。
- 如果再能考虑更多的异常场景,那么基本上这个接口就测得比较有信心了。
-
统计下所有的接口中,哪些测得强,哪些测得弱,这样就大致对接口的测试覆盖心中有数了。
-
使用的工具Postman
推荐一个网址上面有Postman的教学视频https://ke.qq.com/course/246722
tips:
冒烟测试(Smoke Testing):直接翻译是用抽烟的功夫就能完成的测试,但实际上是在软件代码正式编译并交付测试之前,先尽量消除其“表面的”错误,减少后期测试的负担。因此可以说,Smoke Testing 是预测试,虽然初级直观,但是必不可少。
Alpha(α测试)是由一个用户在开发环境下进行的测试,也可以是公司内部的用户在模拟实际操作环境下进行的测试。
Beta(β测试)是由软件的多个用户在实际使用环境下进行的测试。这些用户返回有关错误信息给开发者。
群集现象:测试后程序中残存的错误数目与该程序中已发现的错误数目成正比 。