测试工作经验总结3：简短的总结？

1、由于开发人员技术水平的不同（编码技术和编码规范），会导致代码的优劣程度不同，应用不同模块由不同人员开发导致缺陷出现率也不同。开发人员的水平也决定了软件程序的质量，和二次开发维护的难易程度。

2、当流程出现问题时，测试发现bug越多，开发修改后出现更多bug，如何才能趋于稳定？

3、项目是要质量还是市场，如何把握产品的定位？在二次开发立项时，应该考虑功能模块和数据的问题，是否可以沿用，老版本部分功能模块与新版本的耦合性是否很大，如果很大则开发时间应比实际开发时间预算多1.5到3倍，视项目规模而定。代码整合，开发计划是否在开发时计划后期迭代过程中应把老代码（乱、差）进行替换优化。

4、任务分配：

    项目经理给所有人不均分配任务，每个人的能力不同，完成任务的效率和质量不同。如果A完成了，就让未完成任务的B给A分配任务。B的任务未完成就是B的责任，不能找A的原因。B分配任务的原则要根据任务多少、任务难易程度；不能把90%的任务都分给A了，自己却做很少，然后任务未完成就推给A责任；或是把难的任务都给A，自己做简单的；任务的分配要与A进行沟通，如果遇到两个人都完成困难，不能在规定时间内按时完成的应该及时上报。

5、表单重复提交：比如提现、支付，客户端会发送多次信息给服务器，服务器就响应多次，造成多次支付或提现的现象。支付宝和微信都出现过但钱未丢失，易造成用户误解，弱网环境造成伤害较大。

6、客户端页面刷新或跳转不成功，导致上个操作已经实现，但是无法进入到下一个操作页面或步骤，导致的问题。比如提交付款操作后，页面没有跳转而是继续停留在当前页面，导致用户误认为没有操作成功，重复进行操作。这种问题后台需要对同一编号订单的状态进行判断，使其付款后不能二次付款操作或其他操作等。弱网环境造成的伤害，会让用户造成误解。

7、总结手机测试可以用到的方法，工具，流程，分解部分业务流程形成总结。报告+文档+配置文档。（这个是啥？）

8、新老版本更新，如果业务流程也有改动，应该分析老版本业务流程对新版本的影响，比如老版本业务没有钱包余额功能，不支持记账，而新版本的可以则多了这个功能后，用户在老版本执行订单过程中切换到新版本使用后会带来什么影响：1、新版本多了余额，用户先在老版本进行服务操作，最后在新版本进行结算操作，那么结算后是按照老版本的流程走还是新版本的流程走？（在新版本上线后，对老版本进行发布任务、确认完成任务的屏蔽），2、新版本多了记账功能，那么老版本的数据，是否要显示到新版本的记账当中，还是说记账只记录新版生成的订单记录。（关于更新是个有针对性的问题，就像登录一样，看似简单，一旦想成规模考虑的就多了，比如各种第三方登录、各个平台登录、各个角色登录、账号的一致性、安全性等等，更新要考虑兼容性、安全性、稳定性、各个平台等等）。市场人员只要发现一个问题，就好像这个产品快要死掉了一样。。。。。。

9、涉及金钱交易：

    1、对账：出账入账的闭环、当入账出现问题时，出账需要封死（出账可能有多种情况：提现、支付、积分兑换等不然无法追溯金额流水）

    2、查账：简易对账、详细对账

    3、策略的经常变换会导致对账不准确或复杂话，如费率的改变需要提前做好准备（建立尝试建立时间尺度，会提前进行版本更新）

    4、在查账过程中，进行成功支付，查账结束后判断金额丢失，再次支付时进行查账，就会查出坏账。查账前后应做限制，避免查账过程中出现数据变动，导致查账失败

（这里是乱写的）

10、如何明确测试计划，计划中应该体现不同版本的测试重点。实际情况是每个版本的项目时间，没有正确计算测试时间，对测试过程中的单元、集成、冒泡、系统、验收测试进行精确定位。测试可能不是一次性完成的工作，也不是每次都对全部模块都进行测试。应该划分模块，将模块的测试结果做封闭，代码做封闭，和开发进行沟通降低模块代码之间的耦合度。而不是在原来代码基础的情况下进行修改，造成项目的冗余度，从代码的架构清晰度来根除缺陷的产生。还应该寻求其他方法来辅助缺陷的产生。（事实证明很难做到）

11、用例编写技巧：

先分类编写有效用例，满足需求基本功能和流程的用例

再根据基本用例延生编写异常用例：如延迟、输入长度限制、输入类型限制、UI效果限制

再根据上面的用例编写场景用例：弱网环境、服务器部署、断电环境、通话环境，环境的用例不用每条用例都重复，可以根据实际情况进行用例细分，比如弱网环境的退出功能就不用测试，但是支付功能或网页交互功能等就需要测试

在写用例时，需要根据划分重复测试点、交互测试点、优先测试点、重要测试点等，

12、测试工作的意义：协助提高软件质量、找bug、分析测试结果、总结项目经验，为下个项目做经验累积、分析测试需求，提高项目需求