敏捷开发模式下的测试思考

BECK27 2015-11-05 09:06:37

一，拿到BI，首先做四件事情
1.这个BI产出的业务背景是什么？
2.这个BI要帮助什么业务场景实现哪些功能？或者要帮助对应相关的业务处理什么事情？
3.这个BI关联到其他哪些模块？这些功能模块如何被设计实现？数据流动是怎样的？
4.要准备哪些测试数据去覆盖业务场景？

例如：有个BI卡片写着：“PJK0130-定损平台：导入功能优化：导入失败规则”
如果是我去测这个BI，那么就要去了解：
首先了解定损平台的业务背景，通过问SA，问业务同事，我们知道，原来定损平台是处理车险客户案件的车辆定损，配件定损，修理厂等等的相关业务；
其次，导入功能在做定损业务时，具体实现一个怎样的功能作用？通俗的说就是：导入在这儿干嘛用的？
导入功能优化：导入失败规则，和其他哪些模块有关联影响呢？这里我们应该会想到也许会跟规则有关联，那么导入的这些数据从何而来，到哪而去？
了解完以上三点之后，我们就开始构想该怎么去测了，这时问题又来了，我该造什么样的数据，在导入的场景中去测呢？
二，关于测试的思路
1. 切记不要偏离业务实际情况，而一头钻进需求文档中，为测系统而测系统。这一点在做性能测试时也尤为重要！在一切事情没有明确之前，测试要敢于
质疑需求，BI有时未必是合理的，设计也未必是合理的，要联系实际业务场景去测试系统功能的实现，联系系统上下构造去理解功能模块的设计。
谨记：做出来的系统，主要是为业务的一切场景而服务的。
测试的宗旨就是：保证系统（产品）质量，让一个拥有高质量高效能的系统去更好的为业务提供服务；

2. 使用系统时，站在用户的角度思考：用户群体是哪些人？ta们最关心的是什么？
分析系统时，站在开发的角度思考：某个功能的实现，如何去设计代码？各个功能模块采用什么机制关联起来？数据库表设计是否严谨？...
测试系统时，站在业务的角度思考：我执行这个案例的目的是什么？我操作的业务场景，业务流程正确吗？我准备的测试数据覆盖到业务场景了吗？
这些数据的实际输入与预期输出符合业务需求吗？发现的问题跟踪到底了吗？这个BUG产生的原因是什么？最终
是如何被解决的？上线前的回归测试覆盖度如何？...
3.养成画流程图的习惯：业务流程，前后台交互流程，数据流向图等，画完这些流程图，要了解流程的每一个节点的作用是什么？很多BUG往往就是出现在
某一个节点上，因为某个节点运作失败，或者节点作用失效而造成的。知道这些，有助于测试更好的设计测试案例，甚至提前通过
后台测试（接口测试，单元测试等）尽早的发现问题；
例如：车险理赔系统的任务平台，操作一个查勘任务时，按业务要求完成查勘数据的输入后，点击“发送”，系统正常情况下是返回发送成功的提示。
那么问题来了，我在查勘任务页面输入的数据发送到哪里去了？如果系统设置的自动提调规则在查勘这一环节被触发，后台是通过什么机制触发的？
触发之后生成的提调任务，是由哪个后台模块处理的？...这一系列的疑问，通过画“业务流程，前后台交互流程，数据流向图” 可以很清晰的理解
并在测试时，造准确的数据，设计有效的业务场景；

4.针对每个需求覆盖的功能点，关联模块，工作流程，有针对性的设计测试案例，评估案例粒度。比如页面元素验证（输入框，字段展示等），功能实现逻辑，
工作流程控制及影响点，异常操作（系统容错性）的相应机制；

5.学会跳出开发的角度评审开发设计文档，以及学会利用后台运行日志定位系统问题；
三，关于团队沟通
1.一个BI，一定要是测试，开发，BA/SA三方理解达成一致的前提下，才启动开发-测试-验收工作。从而避免后期修正的时间成本；
2.测试与开发的沟通，主要以暴露问题为主，问题越确切，越有助于开发有效并快速定位问题并解决。暴露的问题不一定都是BUG，
也可以是代码逻辑上的疑问。不要抛出类似“某某模块出现BUG了，你看看是什么回事？”，“这里为什么报错了？”，“你的BI
大概什么时候可以showcase？”等等类似增加沟通时间成本的问题，我们发现BUG了，第一时间记录下来，重现场景给开发。我们
想知道开发什么时候可以showcase，可以直接问他：“这个BI6月10号可以showcase吗？”
3.测试有必要第一时间知道系统的任何变动，无论是需求上，设计上的，环境部署的等等变动，测试必须第一时间收到通知。
4.对于自己负责的需求一定要多问为什么，背景，目标，设计，实现等，合理设计功能测试案例
5.了解需求对生产业务的影响度，性能，效率
6.版本发布计划评审以及各需求的首移时间确定：版本计划和版本各BI的首移时间，测试人员是可以提要求的，如果评估移交时间有风险可以提出异议
7.版本测试案例设计和评审：及时完成需求和开发设计的理解，并完成测试案例，此环节一定要主动思考，与开发积极互动，不能只做开发的测试执行

...全文