前段时间，老板拿了微信号+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(β测试)是由软件的多个用户在实际使用环境下进行的测试。这些用户返回有关错误信息给开发者。
群集现象：测试后程序中残存的错误数目与该程序中已发现的错误数目成正比 。
