5）测试的二八法则
偏向业务的软件产品中，真正核心的流程和场景只占20%，用户往往会把80%的精力放在我们的这20%部分中，对产品的认可度表决权也基于此，因此决定项目是否能顺利验收，产品是否能顺利发布等等，都很大程度取决于此。所以我们在资源不充分的背景下，只能抓大放小，把有限的精力高效利用，找准这20%的重点场景和业务，部署我们80%的测试资源，有侧重的去开展测试业务，作到有的放矢！
6）测试计划的重要性
往往很多项目一说时间紧，就把计划呀、评审呀这类环节省略了，其实要省时间，即是要敏捷，那么敏捷的朴素思想就是挤掉一切不是必须有的水分，使研发过程LIGHTLY。但是，如果一个环节的省略，会造成后续很大的潜在损失，那么就是必须的环节，因此适当的测试计划我认为恰恰是在短时间保证质量的有效途径，时间紧，则更要求计划作的细，作的好落实，分工给每个测试人员时，大家都很明确自己要作什么、作到什么程度、什么时间作完，同时各项分工整合在一起时还要作到对关键点的全面覆盖、要充分考虑到应变方案以应对可能出现的拖期等意外情况。再有就是在计划中把过程细分成一些关键的里程碑，比如什么时间点把详细需求固化、什么时间把测试方案确定、什么时间进行需求验证等一系列重要的时点，我们管理者在过程的监督和控制上只要抓好这些里程碑，就能比较好的驾驭这个项目，当然里程碑的颗粒度确定要根据项目的实际情况有所区别，量身定制最适合的。另外，计划是否起到良好作用的关键在于执行过程的管理，世间万物都是变化的、唯一不变的就是变化，所以计划中要体现优先级，在执行过程中及时调整，把握好哪些是不能变的，哪些是可以调整可以剪裁掉的，这是非常重要的。
7）风险前置
开发前期提前实现那些隐患比较大的功能部分，比如基础数据档案、非本部门或本项目组负责的接口方模块、复杂业务逻辑功能点、核心算法和单据、性能要求较高的操作等等，这些内容如在后期发现作的有问题，往往投鼠忌器，修改成本过大，所以这些环节尽量安排提前完成并提交需求、测试人员验证。
8）建立高效的工作流程和沟通机制
比如站立会议、燃烬图看板、成果演示等敏捷开发的工作方式可以适当尝试，一切以高效顺畅的沟通为底线，当然事情不是不需求讨论，但讨论一定要迅速落实，有了良好的工作流程作保障，会发现很多时间被挤了出来。
9）人的管理
21世纪什么最贵？人才！只有把人管好用好，事情才谈的上能否作好。首先提升人的能力，通过知识共享、传递、考核等手段，快速把测试人员的能力提升到胜任的水平；第二对人员进行合理的分工安排，关键位置关键人、分组分块、以老带新、男女搭配、交叉测试等各种方式；第三建立适当的授权，充分发挥团队核心人员的作用，一个人的关注度毕竟有限，集权式的管控模式在高效模式下很难运作的好，作为测试经理，如果手下有核心的主测或小组长，只要管好他们就成功大半了，同时有任命必有授权方可名正言顺，如果想基层的负责人顺利开展工作，适度的授权和放权是必须的；第四监督必不可少，没有监督，再多的任务布置都是形同虚设，负责人要在必要的环节、时点作关键的监督，比如抽验等方式对测试人员的工作状态和成果作具体的确认，对好的褒奖，对差的批评指正，累犯不改的害群之马尽早更替；最后还要提的一点是士气很重要，要努力营造一种积极团结，能抗压，爱攻坚的团队氛围，加班虽是捷径但实际上还是工作时间的延长并不是解决时间紧张的途径，而且同时可能会带来人员士气和健康方面的隐患。
10）适度的测试工具引入
工欲善其事必先利其器，适当引入测试工具代替人工无疑是件提升效率的好事，但一定注意投入产出的平衡，当时间不充分时尤其要考虑这一点，不要费了半天力气好容易把工具用上了，项目时间也所剩无几了，那样的话发挥不了太多作用。也不一定非要用很大而全的商业测试工具，有条件的可以自己开发一些小巧实用却能提升具体某个环节实际工作效率的工具，例如把一些公共可复用的测试用例整合起来作成一个共享的库，通过一些简便快捷的检索和订制就可以生成测试任务的小工具，诸如此类的思想，可以鼓励测试人员作一些创新和尝试，在实践中不断借助工具的力量提高效率。
以上种种，都是在我们实际工作中的一些体会，时间仓促，没有好好整理，很多没想到的地方也欢迎大家补充，希望对大家的测试工作开展有所帮助！
原帖地址：http://bbs.51testing.com/thread-483829-1-1.html
版权声明：本文由会员becky07 fatfish首发于51Testing软件测试论坛每周一问活动。
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。
