简桀玄

众所周知，小企业肯定人数不会多，很多能精简则精简。甚至很多小企业都没有测试人员，当我们有幸加入到一个不是很大的企业的测试部门，如何能更好的进行测试呢？

现在敏捷开发被炒的很热，其实，我觉得现在还没有一个完全正确的工作流程能去阐述清楚敏捷开发，基本都是每家小企业拿着个文档不全的理去美化自己是敏捷开发，1000个企业就有1000个敏捷开发流程。敏捷开发里是弱化了文档的重要性，更着重讯息的及时沟通，需求变更也平常。所以，敏捷开发里的每一环的人员自身能力都要很靠谱。而对于测试人员的挑战与压力无非是巨大的。因为没有统一的文档，我们要时时刻刻关注所有聊天群组、站立会议、邮件等探讨出的新需求，漏掉哪一个，就彻底漏掉了，没有根源可寻。但是一出现问题，你没有测到，某某这时就会站出来说，我明明在之前说过，说没说过没人知道，因为你不是对着测试说的，我们已经尽力去搜寻散落的需求，但是这种遗漏还是会存在，发生这种情况总会比较尴尬。

  但是如何能避免呢？

你需要一个记事本，新版本的所有需求，反正你知道的，无论何种途径，立马同步更新到你的记事本里，开发过程中的新增需求、修改的需求，删减的需求，都及时同步，这样就会最大化保证需求的同步，好记性不如烂笔头，这样在最后验收的时候才能确保万无一失。记事本可以考虑印象笔记、onenote，都还不错。

需求已经尽量得到了同步，接下来如何去进行高质量、高效的测试呢？

从高效的角度来说，敏捷开发完全可以摒弃测试用例。那种详细的、繁杂的描述也是就是耗费时间，没等你写完，就已经到了开测的时间。这时候的测试用例基本成了鸡肋，用也用不上。而且慢慢看测试用例的时间已经够我测完一个需求点了。但是我们又不能什么都不写，那我们和那些不懂测试，拿到手就开始随便点点点的人又有何不同？不写测试用例是节约了时间，但是如何保证质量呢？其实我们可以根据现有的需求列出checklist，这样即节约了时间成本，又给我们真正测试时提供了测试思维的提醒，不至于漏测一些常规路径，从而可以保证质量。

也许其他人会有更好的想法，我目前是这样安排的：

解释：

1、需求编号：有些录入到禅道或者excel中的需求是有编号的，为了方便我们查看，可以写出编号；有些是临时加的，我们可以直接写出需求点；另外如果有删减的，可以直接添加删除线。

2、checklist：即是需要测试的检查点，对应的A、B、C其实是测试人员。checklist由C写出后，给与A一些参考，A可继续完善补充checklist再给B参考，B测试过程中也可继续完善和补充checklist，这样最终返回到C手中的checklist已经丰富了好多。

3、系统测试：系统测试其实是很重要的一个缓解，需要测试好几轮，确保bug收敛到最低，然后交给B去交叉。

4、交叉测试：交给B交叉是为了发散出更多的路径，毕竟每个人看东西的角度都是不一样的，这样能更大限度的去保证质量。

5、验收测试：从写checklist到现在，C其实一直没有参与到测试，而这时，bug基本已经没有，C根据补充完善后的checklist进行最后的验收。

6、常规测试：这是我自己分化的功能模块，每个测试人员都有自己负责的模块功能。这样没有新增需求的模块、线上的应用、反馈的问题，都能对应到具体模块负责人，比如首页就是A一直负责的，所以最终新增需求都测试结束后，首页整个模块都需要A最后再去验收。

7、α测试：除去参与此需求从产生到结束的人员，找一些公司其他人员，充当用户，给与15分钟的快速体验，测试只需在一旁记录下体验期间提的所有建议就可以。这些建议也许不是bug，仅仅是操作上的不爽，这些也应该记录，之后汇总、讨论，哪些是必要解决，哪些是可以延期处理的，哪些是可以忽略的。

8、β测试：不一定每次的版本都需要执行，可以在重大需求，或者发布有风险的前提下实行。增加一些灰度测试，取一些真实用户去体验，及时收集用户的反馈，并可根据第三方查看日志，是否有崩溃等问题出现。

表格解释完了之后，明眼人都能看出，这样一层层测试下来，质量绝对是有保障的，而且能利用的资源基本都被高效利用了，已经实现了利益的最大化。针对于小型企业、测试部门人数不足的情况，我目前只能想到这样去安排工作，如果我之后发现有更好的工作方式，会及时更新的。

希望对你有作用。

测试移动端与测试web或者其他还是有些许差异的，为了方便大家能够快速的掌握测试移动端app的要点，下面根据自己的切身经验进行了一些总结。希望能够对大家有所帮助。

测试前的思考

我们这个产品主要是做什么的？市场上有那些同类型的产品？我们的产品所具有的优势？

测试前的准备

1、使用同类型的产品，在接触到自己产品之前，就已经对大致的主体功能有测试方向。

2、熟悉我们产品的需求设计文档，模糊的地方积极和pm交流。

3、写测试用例，资源不够的话可以不写，但是需要有checklist。

功能测试注意点

1、基本功能，主要指app是否完成了设计的所有功能。

分清模块，写一份checklist，避免漏测。

详细包括：

1）安装/卸载时，系统正常安装/卸载成功（注意覆盖安装）；

2）安装成功后，系统图标显示正确；

3）根据checklist进行需求点的覆盖测试；

4）对于中途中的一些返回或退出，应有相应的提示信息；

5）显示的数据与接口返回的数据一致（抓包查看，如fiddler、charles）

6）信息上传到数据库，上传的数据保持正确

2、系统交互：系统正在使用一些功能时，外界给与的干扰是否会影响当前功能。

1）电话短信干扰；

2）低电量提醒；

3）push提醒；

4）usb数据线插拔提醒；

5）充电提醒；

6）音乐播放器干扰等。

3、兼容性：android碎片化是个难题，bug也多，ios相对bug少。

需要针对不同系统及不同机型进行覆盖测试。Android可以选取一些代表性的机型。

性能测试注意点

1、稳定性：利用monkey在下班后进行一些伪随机用户事件的执行，会发现一些ANR及CRASH的问题。

2、app运行的内存消耗和cpu消耗。

3、app后台长时间运行的耗流量，耗电量。

2、3点等可以用Emmagee或GT进行Android端的测试，iOS端可以直接利用xcode自带的插件进行分析

4、不同网络下的响应速度测试（可以利用charles工具实现）。

5、服务端的压力测试（可以使用jmeter），高用户的并发都要要考虑的问题。

易用性测试注意点

1、路径短，用户操作简单

2、界面是否吸引人、容易理解。

3、界面整洁、简单，色调统一。

4、无错别字，字体格式统一。

5、点击范围确定，利于用户操作等。

这部分测试很多，可以参照易用性-界面测试规范，如果认为有不合理的地方通常会提交需求bug-设计问题。

自动化测试注意点

如果不是敏捷开发，可以执行自动化测试（robotium，monkeyrunner，androidjunit），这样在回归的时候会节约很多资源。但是面对经常变更UI的敏捷开发，自动化测试的维护成本就较高，这时候并不合适加入自动化测试。但可以加入monkey自动化随机测试，还可以对接口进行自动化测试。

另外，敏捷开发中，一定要有持续集成的环境，这样可以节省很多时间。

其他测试注意点

1、网络切换下的app运行情况及功能正常（wifi/4G/3G/2G）。

2、网络信号强、弱甚至无网络情况下的app运行情况。

暂时就总结这么多了，以我目前的眼界也只能囊括这么多，如果以后发现了更多的注意点，会逐步更新的。

之所以写这篇文章，主要是大部分测试还是处于弱势地位，线上一旦出问题，大部分人想到的是：你这个没测？基于这点，这篇文章也许可以给你一个明确的答案，这到底是谁的责任。

一、先解决问题

线上爆发重大bug，这时候不是追究责任的时候，而是动员所有可调用的资源，尽快解决这一问题，将损失降到最低。而一般公司在这之前就应该制定好出现重大问题的补救流程和方案以及对应的人员分配。

二、定义bug的性质

解决问题后，定义线上发生的问题的性质，是第三方引起的，不可抗拒的问题，还是自身疏忽导致的错误？且爆发的问题的严重程度，关于bug严重程度的区分，可以参看我的另一篇文章。（传送门：http://blog.jianjiexuan.com/testdocument/42.html）

三、分析产生bug的根源

1、需求未涉及，或需求当初定义的不够详细造成。

 这个一般由需求、设计、测试都承担责任，需求的责任最重。之所以说设计和测试也有连带责任，是因为需求评审的时候也参与进去了，而需求都是通过大家一致确认可行通过才执行的。当然，有些公司对于需求评审也不是很重视，也没有专门写需求文档的人，甚至一些小公司直接都是口头表达，这样的需求连记录都没有，实在没办法追责。不过，一般这样的公司也不会追责，如果追责的话，建议设计（产品）、测试一句：你可以刷新简历了。

2、设计过程、开发过程未实现造成。

 这种问题是需求检查到了有未完成的需求，但是设计和开发并没有进行弥补。则为设计与开发的责任，而设计的责任最大。

3、测试过程中的疏漏造成。

 测试过程中的疏漏有2种情况，一种是测试用例没有覆盖，一种是测试用例覆盖了没有执行。第一种参与过测试用例评审的都有责任，但是设计测试用例的人承担最大责任。第二种则完全是测试责任。当然，很多公司根本就不具备评审测试用例或者有专门写测试用例的人，本来管理流程就乱，一人做多种职位的事情，这时候如果硬要追责，建议测试一句：你可以刷新简历了。

4、交付部署中出现问题造成。

 比如版本错误、发布错误、部署错误，一般在设计（产品）、配置、测试经理共同承担责任。

5、私自改动代码造成。

 只能开发哥哥完全承担了。

四、分析总结

 对于这次的事件进行分析与总结，确定是谁的问题后，应该吸取教训，并给出措施，给下次的版本一个参考。

其实这套方案肯定是基于自身的流程和管理都非常明确的公司执行。并不适合小团队去执行，小团队建议还是大家一起承担，否则，只会让员工提前离开。如果你不是领导者，愿你不需要看到这篇文章。