每周总结下自己刚步入这个行业的心得。
希望厚积薄发。
1.意识到测试工作对于App形象的重要性
为什么总会有线上bug没有被发现修正？
一方面，用户的使用场景下，App哪怕卡死，自然也就是强制关闭再打开的方法来解决。有极少数客户，会选择问题反馈（严重影响使用的情况），花时间来上报问题的细节。那么为了维持App的高质量和服务可靠的形象，测试人员要承担这部分不积极用户遇到的问题。但是测试人员很难完全模拟用户所有的使用场景（就像产品经理完全理解客户也是有一定难度的）。这次测试出来的消息推送弹窗功能场景就不容易想到：需要安装App，没有打开通知，两次App打开时间戳相隔一天以上才能复现的App黑屏卡死问题。我也是大量的UI自动化中遇到的这个问题，然后阅读代码去了解这个弹窗出现的逻辑。前提是最近对于Xcode工具又熟悉了一些，对于代码定位总结出了经验（可见周期性的总结学到的知识对于之后的工作大有裨益）。
★善用工具
Xcode-可以检测代码失误，比如循环引用、内存泄漏。好处是门槛低：只要会用这个工具，不用懂得太多原理，就可以帮开发者发现代码问题。即便是某些难以自动化的测试流程，有条件的情况下完全可以连接Xcode等调试工具进行必要检查测试。安卓同理。接下来花时间学习下安卓系统的常用调试、测试工具，尝试更专业的眼光发现问题，也帮开发者减轻负担，更好地沟通。
★不能对不熟悉的需求附加自己的理解
要默认不是bug的心态去和开发沟通。通过产品文档和产品沟通来确认结果。即便是看上去不太合理的情况、两个系统客户端实现不一致的情况，也可能有历史原因。
★安卓版本技术更新测试的心得
bugA显示页面1不应该返回交易页面，bugB显示页面2不应该返回交易页面。
那么bug数量增加的时候就应该思考，为什么返回的都是交易页面，这可能是个通病，于是尝试复现，找出来操作路径S使得大部分二级页面返回都去到交易页面的bug。或者说这些bug可能都是一个技术问题导致的（最后开发的备注也验证了我这个猜想是正确的）。控制bug数量，提出更贴近开发视角的bug，会使得团队协作过程效率提升。所以需要关注下同期需求别人提出的bug，然后善于思考、总结、bug归类。接下来熟悉安卓客户端的代码会很有帮助。
2.在测试过程中发现有一些耗时的复制粘贴工作（比如对token进行AES加密之后再用于postman发送请求），尝试重现产品中的AES加密方案，没有成功，有时间继续尝试。在使用App的过程中，充分思考自己的经验来发掘问题，找到了几个问题，比如消息弹窗遮挡问题，和开发沟通后进行了修复并验证问题的解决。还有一些不确认是否属于bug的问题，在和同事探讨的过程中也增强了对产品的认识。
3.学到的完成某一部分工作的方法，不能完全的照搬和循环，要多加思考，看看是否能够改进过程和工具来提高效率，从而获得业务和技能的双丰收。遇到问题，在自行探索的过程之后，才应该有虚心请教的主动性。不能依赖别人，也不能过于被动而影响进度。
4App看似上层结构简介明了，其实内部逻辑纷繁复杂，作为刚接触业务不久的我应该仔细研究各种买卖公式和逻辑，了解App模块间的跳转关系和调用逻辑。不然看客户端代码都步履维艰。印证了上周例会学到的那句“业务是技术的有力支撑”。
踏下心来，一个个业务模块总会弄懂，技术也不能落下，优化时间分配，让两者辅助发展。
5.关注作为测试人员的基础、核心能力，规划成长体系。
不可以贪求学的知识过多、过快、过杂。
目前的规划是把熟悉业务作为首要条件，在工作中尽可能多的熟知任务的细节，然后扎实地开始学习用例的设计方法。
学一点理论就要尝试把它实践一下，结合工作内容进行导向学习。
6.在实施项目的过程中，如果觉得中间容易遇到一些问题，这些问题应该被记录和总结出来，不管对于自己的积累还是团队知识的共享，都是很有意义的。
7.基本结论是稳定性和速度上，UITest是优于Appium的。那么支持文档少的原因，一个是iOS开发者并没有太多精力来用于测试开发，而测试开发人员又不一定能够很好的运用Objective-C和Swift语言（总结为门槛稍高，但是Swift很容易看懂，UITest用到的知识也不算太深）。Appium社区多，发展快，是它的兼容性好，多平台多语言。但是正是这个庞大和臃肿的兼容平台带来了环境部署难，运行速度慢，容易崩溃等弊端。借着和iOS开发团队的沟通支持，和自己已有的对移动端UI编程的了解，希望能把这个心的测试工具引入到生产过程中去。
UI测试的过程中有一些问题是需要解决的，目前遇到的一个情况就是有些元素需要通过一个标志符来获取焦点，但是并没有配置Accessbility属性和标志符，换句话说需要我在源代码中加上几个赋值语句来完成用例编写。这会与业务产生耦合，但是对功能没影响。目前的方案有两种：
学习Hook技术，交换函数指针来在壳工程中进行设置Accessbility属性（待探究，且稳定性未知。可能需要ios开发来支持）。
在对每个版本建立UI自动化工程的过程中，手动的去相应位置、相应元素添加两行赋值语句。这个手动插入代码的工作量需要再尝试写一些用例才能确定，目测不会太多。（目前优先考虑该方案）
8.多个任务确实容易出错，电脑都会卡慢。但是两个任务还是比较高效的，因为有的任务存在等待过程，比如编译，比如等待发布，等待开发修复操作的间隙。交替执行使得时间利用率更高的同时，也能使得大脑在不同任务间减少单调疲惫感，有利于联想和创新。
XCUITest in iOS UI自动化
能够查看完整测试报告，失败用例会有截图。
由于支持文档不是很多，通过苹果的开发者大会视频，认识了FirstMatch函数，网上很少提及，因为是Xcode9新增功能。也就是几个月前发布。合理地正确地使用这个函数能够提高将近一倍的UI元素查找性能，对整个UI自动化有着重要意义！于是下周会抽出时间把近三年的开发者大会的UITest官方发布内容都过一遍。
解决urs登录的自动化测试问题时，输入完整的账户名称，还是会弹出下拉列表提示一些备选的登录名。这个列表遮挡了密码输入框。在没有找到操作这个列表的方法情况下，换了思路，先填写密码，再填写登录名称。感觉有些弯道暂时绕过技术问题，先追求投入产出比再改进技术才是适合任务的思路。同样的，测试需要了解技术原理（或者说数据流的变化），编辑测试开发代码的时候也是找到了共鸣。URS登录页面的两种登录方式通过按钮切换，实际上不是我理解的切换了一个视图（从手机号登录--到邮箱登录），而是公用一个视图，宽度是屏幕两倍，隐藏了拖动条。所以我操作的登录按钮总是找不到。
关于各角色的思路：
开发者：修复bug，验证没问题即可。
测试：哪里都不能有问题，A页面调用的C功能，和B页面调用的C功能是不是同一段代码？
在素材自动化配置的过程中，测试出不能编辑配置的bug，修复完成后，详情页面可以编辑了，列表页面还是不能编辑。最终证明这是同一个函数调用，出现在相似的两个地方，只改了一处。这也给测试提供了一个思路，有时间就去读一下代码，就算没时间也要推断同样业务的多个入口是否也可能存在同样问题。
9.测试工作要往前赶（保持认真的前提下），留有一点空间给意外和新需求，因为新需求测试可能会比想象的复杂些（耗时间久）。
从中学到两点：
一个是代码修改需要重新评估回归测试范围，了解bug的群集性。
一个是经典核心功能不能认为测试得多就稳定，要当做全新App去认真回归
10.随着对UI自动化操作的熟悉，能够发现不同现象（iOS 9系统下密码输入框找不到，“智投独家”按钮找不到）在技术原理上的共同点，可能是都使用了自定义的UI组件，而不是常规原生组件。所以没有很好地支持Accessbility辅助功能定位，需要走进源码探究。在iOS开发的帮助下，学到了快速定位UI控件在代码中的位置的方法。每个操作能提升下效率，那么整个工程就能得到推进。（共鸣：工欲善其事必先利其器）
在视频悬浮窗的关闭按钮上，iOS 9系统能找到关闭按钮，但是tap（）点击操作无效（点击操作无效问题在iOS 9的别处UI也很常见）。最终的解决方案是找到的按钮的位置信息，计算出一个坐标在它内部，利用坐标的tap来完成button的tap（）。问题是暂时解决了，但是最好搞清楚无效的原因，因为绕过的小问题太多终会导致出现棘手的、无从下手的大问题。暂时能用为主，初期需要效率。
11.最近了解了下做好测试工作的技能树。结合谈下自己的感悟：
我抽空大概阅读了主站的接口测试工程代码，case逻辑是很相似，参考编写应该不会太难。但是让我写可能会漏掉业务重点，总之需要结合手工测试来确认接口在整个工程中的地位，才容易写出覆盖更全面的用例。包括在组里的有道云协作分享的知识中，也看到说：通过阅读后台源码、了解业务，才能发现没有覆盖到却有必要验证的函数部分。
测试掌握多种语言、了解并尝试拓宽广度到性能、电量、稳定性等专项测试，是有必要的。当然是把技术应用到业务中产生效益才有意义。自己会初步探究使用稳定性测试工具、性能测试工具来帮助提高和保证App产品质量的方法。不断积累知识，在各个方面，希望产生量变和融会贯通的效果。
通过不断地总结业务性强的需求，增进对业务的了解。
12.在测试过程中如果发现重复或者过于复杂的操作，要时刻尝试去缩短操作流程，提高效率。前提是保证本次测试任务按时完成（第一原则）。
另外就是要多熟悉已有的测试平台、工具和项目，思考它们之间的关系，才能改进工作流程而从中受益。
13.★提高效率的途径中，我思考过“工具”和“方法”：
上周的ipa文件安装属于“工具”，那这次复现在线bug路径就属于“方法”了。
①这次复现一个【编辑交易品】闪退的线上bug，感受就是首先相信bug的产生大多不是代码偶然，代码是静态的，接口也相对稳定的情况下：就是探寻一个必现路径的过程。开始只是知道“操作复杂”导致闪退
-->交易Tab下的操作
-->和开发探讨编辑交易品的情景，结合bugly的堆栈信息推测数组是否越界、删除点击操作和长按移动操作是否冲突等等原因
-->尝试减少商品数量验证越界（采用手机屏幕录制来统计规律：比如商品个数变化，种类的排列规律、是否移动了首末元素等）
-->最后得到较小的复现路径范围：只需要来回交换商品顺序，不需要增删就能发生闪退。
开发最终定位的原因：动画未完成的时候点击了“完成”按钮，说明之前总结商品排列规律的思路是走偏了，所以提供了新的bug定位经验-快速操作。
以后还可以通过快速操作来检查代码的问题，这部分UI自动化的操作速度会明显优于人工。
②还有一个返回箭头部分页面显示不完整的问题，开发备注的原因是“部分页面使用了自定义的返回实现”。这就印证了我写UI自动化代码的时候为什么统一实现的返回函数在一些地方不起作用。随着对产品、代码的深入理解，对编写自动化项目和发现更多使用问题起到促进作用，相辅相成。
必现&偶现
理论上所有偶现的crash，找到出现条件都能必现。但是没找到就不是必现的。
★测试的一部分工作需要开发视角
测试微信助手的过程中，学习到了看开发者日志的方式，有助于增进定位问题的能力，更方便地和开发沟通。
尽管不看源码，也要理清楚代码操作数据的逻辑，就像开发者在设计新增需求锁改动和增加的数据。
业务的改动有很多是基于某块功能的完善，所以随着接触不同功能模块，测试越来越得心应手，效率提升，对内容的掌握也增进。尤其是微信助手这样的App，体量不算大，是个训练测试思想、技巧的好项目。
14.探究iOS的Monkey测试工具，阅读源码
对之前的Appium的测试环境原理加深了理解，在一个领域之内的各个项目之间研究和应用会明显感觉到有些触类旁通。学习不能操之过急，有目的性和耐性才能逐个攻破。
旧的技术UIAutomation被逐步取代，新的XCTest也被开发者们开始利用，基于XCTest的C/S模式测试也兴起，FastMonkey基于此进行改进。
感觉有时候并不知道解决问题的本质，但是找了一些帖子照做就绕过去了，希望随着Xcode使用越来越多能够渐渐明白。
15.★Xcode Instruments心得
工具使用方便，功能全面。在接下来对App质量掌控上能够给与很大的帮助。之前对于UITest过程中上一步还能找到按钮，点了一下其它按钮就找不到原来的这个按钮的情况一致觉得莫名（甚至想归结为UITest的技术不成熟）。最终发现是CPU占用超标，导致的随机性失败。CPU超标的原因可能有很多种。
★不积累疑问，尽量研究透彻
对于代码质量的提升是没有上限的，包括可读性、稳定性、可扩展性和实现原理的方方面面。UITest这一轮CPU指标纠错，让我认识到Xcode10必须清理并重新编译才能实现代码效果的bug对开发团队影响之大。也发现自己实现用例过程中基于单一机型实现的能用即可的代码对稳定性带来的不利影响。不断地去定位代码和增加Accessbility属性的过程，已经带着我越来越清晰地认识了各个模块的实现方式，对于之后bug的定位理解都会有帮助。
★要找准解决问题的方向
有问题是需要一些经验来推测的，但是如果推测方向失误，那么可能会走很多弯路。比如tab找不到去推测多window导致的，其实是CPU超负荷之后客户端无法承担UITest的查询。最终锁定CPU超负荷是快讯页面引起的。首次启动App的广告页测试失败可能也与此有关，因为此时App已经开始在渲染planA的快讯页面了。实践出真知，把快讯页面临时替换成空白页面，来观察CPU的表现，从而得出进一步的定论。
16.★意识到测试工作对于App形象的重要性
为什么总会有线上bug没有被发现修正？
一方面，用户的使用场景下，App哪怕卡死，自然也就是强制关闭再打开的方法来解决。有极少数客户，会选择问题反馈（严重影响使用的情况），花时间来上报问题的细节。那么为了维持App的高质量和服务可靠的形象，测试人员要承担这部分不积极用户遇到的问题。但是测试人员很难完全模拟用户所有的使用场景（就像产品经理完全理解客户也是有一定难度的）。这次测试出来的消息推送弹窗功能场景就不容易想到：需要安装App，没有打开通知，两次App打开时间戳相隔一天以上才能复现的App黑屏卡死问题。我也是大量的UI自动化中遇到的这个问题，然后阅读代码去了解这个弹窗出现的逻辑。前提是最近对于Xcode工具又熟悉了一些，对于代码定位总结出了经验（可见周期性的总结学到的知识对于之后的工作大有裨益）。
★善用工具
Xcode-可以检测代码失误，比如循环引用、内存泄漏。好处是门槛低：只要会用这个工具，不用懂得太多原理，就可以帮开发者发现代码问题。即便是某些难以自动化的测试流程，有条件的情况下完全可以连接Xcode等调试工具进行必要检查测试。安卓同理。接下来花时间学习下安卓系统的常用调试、测试工具，尝试更专业的眼光发现问题，也帮开发者减轻负担，更好地沟通。
★不能对不熟悉的需求附加自己的理解
要默认不是bug的心态去和开发沟通。通过产品文档和产品沟通来确认结果。即便是看上去不太合理的情况、两个系统客户端实现不一致的情况，也可能有历史原因。
★安卓版本技术更新测试的心得
bugA显示页面1不应该返回交易页面，bugB显示页面2不应该返回交易页面。
那么bug数量增加的时候就应该思考，为什么返回的都是交易页面，这可能是个通病，于是尝试复现，找出来操作路径S使得大部分二级页面返回都去到交易页面的bug。或者说这些bug可能都是一个技术问题导致的（最后开发的备注也验证了我这个猜想是正确的）。控制bug数量，提出更贴近开发视角的bug，会使得团队协作过程效率提升。所以需要关注下同期需求别人提出的bug，然后善于思考、总结、bug归类。接下来熟悉安卓客户端的代码会很有帮助。
