日前，由CSDN旗下高级技术管理者大本营CTO俱乐部举办的“如何管理你的软件测试工作”线下主题活动在SOHO西区某咖啡厅举行。本次活动邀请到了CTO俱乐部软件测评技术专委会会长、资深软件测试专家贺炘。贺炘以软件测试为切入点，分享如何在不同规模，不同诉求的企业情景下，最大限度的利用现有资源，通过测试维护软件质量。
据悉，这是CTO俱乐部软件测评技术专业委员会成立以来的第二场线下活动，来自于拉手网首席科学家、中移动通信研究院、卓望集团、世纪佳缘、央视国际网络等公司技术负责人现场参加了本次活动。
活动现场
软件测评技术专委会会长贺炘
测试没有银弹
在贺炘看来，在测试行业，并没有放之四海皆准的灵丹妙药，不可能有一种方法能够解决所有的测试问题，当然也不会有哪个测试师一上来就能解决所有的问题。随后贺炘引用孙子兵法战法：道、天、地、将、法，这些兵法同样适用于管理软件测试团队，他强调“道”是指要将企业愿景目标须明确，是一切的前提！而具体到“法”的话，则是解决如何做测试的方法、按什么顺序做的问题，剩余的就是管理的问题。但是对于不同的团队，由于侧重点和资源都不一样，所以不可能通过一种通用方法解决测试问题。
不同类型的团队适用于不同的测试管理方法
- 小型团队
小型团队通常面对的最大的问题是如何存活下来。总之就是要有特色，也就是“人无我有，人有我精，人精我贱”（这里贱是指便宜）。以此为前提，才能决定测试怎么做。小型团队最讲究少花钱多办事，这绝对是不“二”的选择！以此为前提，那么最适合小团队的就是互测了。三五个人的小团队通过互测、自测来保证质量，更多的时间应该放在业务功能上，把卖点做足。
- 中型团队
中型团队已经可以有自己的专职测试人员了。那么第一问题就在于明确KPI，清楚什么才代表真正做好了。在搭配独立的测试工程师的时候，最好按照角色进行划分：比如：软件测试搭建、自动测试组、手工测试组、性能测试组和安全评估等。
中型团队虽然可以通过自动测试来提高效率，但是自动测试有时候会出现一些简单错误，所以不要去期望有一个万能的自动测试框架来解决所有的问题。自动化测试只是用来提高机械测试的效率的。
对于中型团队，敏捷也是一个不错的解决方案。但是在实行敏捷之前需要确定项目的容错率和可靠的人，最合适敏捷的一般是30岁以上能对项目负责、重视荣誉感的人，这才能保证项目的质量和进度。
- 大型团队
大型团队很需要重视企业文化，贺炘举例，微软坚信人才最有价值，Google信奉互联网也有民主。但不同的公司的核心企业文化通常差异很大，因为他们的业务并不一样。侧重软件的微软会比互联网公司Google更重视产品质量，因为Google的产品更新简单，但微软的维护、升级成本却很高。做测试也同样需要明确这个理念，软件公司需要质量能有有力保证，互联网公司则更需要敏捷做推动力。
贺炘建议，在做大型软件项目时开始推进持续集成，至少每天集成一次，Build时就相当一次安全检查，完成之后再进行一系列单元测试在集成到整个系统，再对整个系统进行编译，再部署，最后自动化回归。总之，每天都在做测试、做集成。
贺炘提醒与会者，大型团队的质量也是有成本的，最好做个实用主义者，谋定而后动，目标决定过程，而过程决定质量。
现场观众提问
随后现场进入最精彩的互动环节，不少与会者都是带着问题过来的，第一个人问了三个问题：开源对测试的影响，如何看待测试的开放性？千万级高并发环境下如何做测试模式的设计？云计算的测试和评估工具对比？贺炘都一一进行了解答。
其他与会到的问题(部分)：
提问：敏捷测试对个人素质要求比较高，但团队通常是年轻人居多，经验普遍不足，就这个方面您能否给出一些建议？
贺炘：敏捷要求具备很强烈的学习欲望，愿意对自己负责，而不是现在会什么，团队的持续学习的能力才叫素质。所以团队做不了敏捷是因为没有学习的氛围或者是团队人员本身就不适合这样的学习氛围。
提问：对于小型公司，在团队里测试人员更适合做哪些除测试之外的服务和帮助？
贺炘：研发人员通常会把自己不愿意做的事情扔给测试人员，比如说明书、用户培训、安装和售后支持、服务等。这在小公司没有什么问题，但绝对不适合大公司。但更应该让专业的人干专业的事。比如产品说明书，我曾经就找来一个专科文科学生代替测试人员，但结果更好、更专业。
提问：测试人员做得好了常跳到产品部门，公司留不住人怎么办？
贺炘：这是好事。公司里最重要的是好的产品，所以理解产品的那个人是对公司最重要的人是对公司最重要的人。如果测试部门能培养这样的人那无疑对公司是一件好事。这个问题可以试着通过轮岗来解决。
CTO俱乐部为贺炘颁发荣誉证书并合影留念
