第一问： 测试团队的工作也依赖于业务和开发，如何有效提高与业务团队和开发团队的合作默契？

答1：测试团队与开发团队和业务团队的沟通，都是难点，这个难点，一方面是沟通机制的问题。但是更为重要的是各自的知识积累，比如测试人员的业务知识积累，以及对软件系统的全面了解。

因此，对于复杂的产品，比如业务性很强的软件，比如复杂通讯系统，复杂的金融系统，测试工程师的测试效果，可能三分靠测试技术，气七分要考对测试金融、通讯具体业务的了解和掌握程度。测试人员的职业寿命比较长，与这一点也是密切相关。对于复杂的业务来说，培养一个测试专家不难，难事培养一个对业务全面了解的业务专家是很难的。这也是测试工程师职业竞争力的一个积累点所在。

除此之外，测试工程师最好能够学一点心理学的知识，测试工程师和码农还不完全一样，如果学习一点心理学的知识，对工作更有帮助。目前，有关心理学的课程，知识都很多。最简单的，买一本戴尔卡耐基的《人性的弱点》反复看一看，会对工作有帮助的。还有几本书，也可以作为参考比如《狂热分子》，《乌合之众》，对人的心理和人性理解的深入一些，工作开展更为容易一些。

答2：测试团队和开发团队的关系时上下游关系，测试的进程依赖于开发的进度，测试的结果需要开发承认。需要注意的是双方的关系要融洽。开发和测试容易形成敌对关系，这需要开发和测试的主管要具备协调对立关系的能力和缓解对立情绪办法。

第二问：团队如何考虑平衡质量和速度的测试策略？

答1：测试本身就是在成本和质量之间找的平衡点，如果投入的财力和工作量是有限的。那么必须对被测试对象的功能点划分优先级，优先级高的优先测试。

另外，一个要考虑产品遗留bug会产生后果的严重程度。如果是公司内部IT系统，功能对业务影响不大，又着急上线，那么跑完正常功能和正常流程，以及少量异常流程，基本就可以上西线了。如果，是银行、电信这类系统，没有办法避免投入。目前，中国的银行在IT方面的投入，可能是世界之最，超级就，超级的投入，产生超级的应用和质量。大家可以对比国外的金融IT，基本上都不是中国的对手。如果是产品，或者系统不断迭代升级的软件系统，那么就需要考虑自动化了。一般来说，同一产品，五轮以上的手工测试，就可以考虑自动化了。这是提升效率的好办法。

不同的项目，对软件的质量要求是不一样的，公司的领导层必须对产品质量的要求要有理性客观的定位，否则，会出现测试资源投入不足，造成既要马儿跑，又不让马儿吃草的局面。所以说，测试工作的定调，首先是研发的老大要做好的。如果一旦做不好，可能工作开展就比较麻烦。我对这个问题，就阐述到此。

答2：移动app举例解答下这个问题，app要求全质量（功能、性能、易用性、安全和兼容性，一样不少），考虑到发布要求尽量做到分层测试，第一种分层考虑是先考虑接口功能、UI功能和性能测试，再考虑兼容性和安全测试。第二种分层考虑研发阶段、系统测试阶段和上线回归三个阶段任务分层，研发相当于功能集成测试，尽量做到接口功能自动化测试，用例和自动化保持在基本覆盖用例集，内部测试团队独立承担；在系统测试和上线验收阶段，可考虑众测、灰度发布用户中组织并承担测试。

对代码质量检查和持续集成活动是自动化测试活动、接口测试是自动化测试活动、UI界面功能也是自动化活动，迭代最多还是版本持续集成这个环节。

系统测试和验收测试阶段，倘若用例质量高，建立众测能力也是不错的选择发，用例覆盖有保障，执行层面参与的人多了，手工比自动化测试效率更高。

第三问：敏捷模式下，如何平衡快速发布和客户对质量的期望？

答：敏捷指的是内部迭代的敏捷，不是鲁莽的把一个没经过充分测试的产品直接推给客户。客户对质量的期望需要在销售阶段就做好引导，测试人员在后期面对客户去平衡客户的期望就太晚了。

第四问： 团队的人测不出问题 ，上线后问题又很多，主管只能抽测一些重点的 ，这种情况怎么解决？

答1：团队的人员测试不出来问题，这是很严重的。那么，首先要找到原因所在。既然主管，做了一些重新测试，如果主管发现了问题，针对这些问题，要与测试工程师一起分析为什么测试工程师没有发现问题。也就是做缺陷分析，缺陷分析是提升测试人员测试效果很好的手段。

答2：如果系统的使用环境很复杂的话，这种情况就不是自己能避免的了。我最近遇到一个客户，他们内部测试团队能力已经比较强了，但是系统部署到客户那里依然会出现各种问题，归根到底是因为客户是多样的，而自己的测试环境变化是有限的。 解决方案只能是自家的测试队伍努力提高测试用例的完备性，利用其它力量在不同的环境下做充分验证。

答3：我觉得测试测不出问题，工作量评估、工作环境评估不准也是原因。

应需充分调研客户的具体需求，实际运作环境，然后做测试工作量的准确评估，提出合理的人力、测试时长诉求。如果人力、时间给足了，Case也覆盖到了，还有遗漏，就是严重的工作态度问题，属于测试遗漏。我们的做法是所有跟用例无关的缺陷，后续都必须维护回测试用例里，不求用例百分百覆盖，但应尽可能趋近于百分百。

第五问：如何提高测试团队学习业务知识的速度？

答1：如果业务知识是行业知识，最好通过一些资格认证，比如做证券软件，测试工程师可以去通过考证券从业资格考试，提升自己对证券行业的理解，其他行业也是一样道理。

答2：根据我的经验，提高学习业务知识的速度最有效的就是让新手回归缺陷。缺陷里有完整的执行步骤，有利于快速的掌握如何操作系统，并且预期结果和实际结果的对比，非常有利于新人梳理业务流中的测试项和观察点。

答3：找一些行业顾问集中培训几天，并且可以长期集中答疑。

第六问： 如何快速打造组建一个测试团队？

答：说到底，还是与预算有关系。预算允许，招聘有经验的关键人员，搭班子初期，要有好人。

在面试的时候，可以做一些逻辑测试和职业性格测试。尤其职业性格测试对后续组建团队很有帮助。博为峰开发了一套职业性格测试系统，有些人就是不适合做技术工作，或者不是做与人协调的技术工作，这种人，在搭班子初期不适合进来。比如，我们曾经招聘过乐群性是0分的人，后来通过评测才发现他的问题如此严重，这类人很难把工作做好。还有独立性，稳定性，这都是可以通过测试发现问题的。市面上比较多的是，mtbi测试。大家可以找来看看，尤其测试经理。建议测试经理和人事针对这个问题做些讨论。

第七问： 关于面向业务的测试，自动化测试该如何实施？

答：自动化方面的问题，我觉得先要确定是否有必要做，再考虑怎么做。大部分公司的自动化测试实践是无效的。 先从成本角度和技术能力两个方面考虑是否要做。

如果上述两个问题经过认真评估，还是决定做自动化，可以按照三个步骤来实施：1.选择使用哪种自动化测试解决方案。2.梳理需要自动化测试用例。3.随着版本的变更，维护自动化测试代码。

追问（如何让领导觉得测试团队有成长。通常测试团队的能力提升是很难通过图标或数字表现出来的）

答：测试团队能力的成长，可以在产品质量上得到体现，经过你们测试的产品质量逐步提升了，这就是团队能力提升的一个有力的表现。 另外，测试团队要逐步建立自己的质量保证体系，在规范、标准方面逐步积累，让领导通过过程输出文档看到你们在提升。

第八问：1）公司产品为智能硬件（可定义为新型制造业），测试团队负责范围除了软件测试，还包含传统的硬件测试；想听下贵司专家对此类企业，测试经理/总监和品质经理/总监的关联及区别；要看硬件的规模，一般这类产品分为软件测试团队、纯硬件测试团队，系统集成测试团队这三类。如果智能硬件的规模比较小，可能只有纯硬件测试团队和软硬件系统集成测试的团队即可。

2）测试人员主动学习能力和积极性普遍弱于开发人员，会存在被开发同化现象（比如BUG的解读被开发牵着走）；如果快速有效提升测试人员对产品理解及专业技能？

答1：我觉得认为测试比开发弱的观念首先是不对的，这种观念如果存在，很难有自己独立的思想，很难来保证质量。我招聘人员的时候会考量，一个测试人员如果连挑战开发的勇气都没有的测试，我们是不需要的。为什么弱，弱在那里，是业务弱，还是技术弱？每一样事情做到极致了，就没有弱的说法。

答2：测试人员在具体编程方面可能不如开发，但是这只是个熟能生巧的工作。在业务整体性的理解方面，测试一定会强于单个的开发人员。

答3：这个问题我觉得是团队定位除了问题，测试把自己定位成开发的助手了。这需要测试团队的老大从思想上给手下人明确自己的的职责，并且要提高业务水平。说白了就是对自己不自信，被人一怼就怂了。

3）性格外向型测试人员，跨部门沟通效果好，但有些容易浮于表面；内向型的测试更容易发现潜藏较深BUG（微软曾做过此类研究）；测试团队搭建，性别、性格、开发/测试比例等是否存在“黄金比例”？

这可能是个伪命题。内向外向只是分析问题的一个维度，这可能不是决定性的。决定性的原因是测试人员是否有独立工作的能力，有些人外向，是因为没有独立工作能力，凡事都需要协作。以及测试人员的逻辑分析能力，专研精神。

这个看情况的，不能一棍子打死一定是那种性格好，内向型中有内敛性的，也有小白兔性的，有外弱内强性的。面试的时候时间不够，如果不擅于沟通，不擅长沟通，肯定是要吃亏的。

4）有低成本且简单好用的相关管理工具推荐吗？

个人摸索了多款项目管理工具没找到太好解决方案，目前采用免费版JIRA+禅道（对使用还是偏繁琐）旧版JIRA BUG管理很不错，但无法追溯管理测试版本；禅道可以管理项目版本（包括附件），但BUG管理没JIRA直观；腾讯免费开放的TAPD版本迭代不具备附件功能（略遗憾）

答1：jira所在的公司是澳大利亚的一家软件公司，规模很大，全套的敏捷开发工具都涵盖了。在他的工具链中，应该有相关的支撑。atlassian的产品功能强大，就是重了。但是扩展性很好。

答2：我们一直用禅道，感觉开源，轻量，禅道可以:产品--项目--用例--缺陷，还有丰富的报告图表。

5）APP自动化测试，尝试过python+appium的方式；UI自动化实际产生的价值效果并不理想；希望能了解更实用的自动化测试技术（比如接口、性能等）

答1：关于APP自动化测试，个人看法是，如果是兼容性测试，借助自动化UI测试效率最高。其他的功能自动化要看情况了。如果是做系统级接口测试，app的UI所对应的API都要有封装，这个需要开发团队配合。这样，做完接口测试，还是要跑一边UI测试的。否则，无法保证UI的正确性。至于用python调用接口，这个技术就太简单了。python与其他语言的粘合性比较好，都有相关的办法。这类资料很多。

答2：UI和接口哪个稳定就做哪个自动化，都不稳定就放弃自动化。自动化大部分时间都是不成功的，不要强求。

答3：如果UI变化不是很频繁，可以考虑。往往和自动化效率有点冲突。自动化希望快速迭代回归，快速迭代，UI可能变化频繁。如果资源不是很多，或者先做重要流程的APP自动化。接口的话，由于现在团队代码能力弱，所以采用Jmeter来做，还顺便做接口压测，jmeter搭积木试的，加业务断言，测试可以把更多精力放在业务上。功能的同事也可以很快学起来，用起来，他们也比较喜欢学。

第九问：如何识别有效的加班和无效的加班？

答：有效加班与无效加班，其实还是得看主管个人观察与评估。  可以从工作量及工作效率等相关因素上考虑。及测试结果上做评判。

第十问 制定上线的产品发布的质量标准需要考虑哪些维度？  怎么统计线上遗漏率？

答：发布标准，很重要的一个是表是缺陷的收敛情况。如果不收敛，发布风险太大。当然，是不同维度的bug的收敛程度，不能只看一个维度，包括功能和性能。一般上线之后遗留bug不是由研发部门来处理了，而是运维或者售后部门来收集和记录，并反馈到研发。这类bug要特别标识，便于集中分析。很多公司，记录运维阶段的bug是有专门的系统的。有别于我们研发阶段的bug系统。

版权声明：本文出自51Testing原创，51Testing软件测试网及相关内容提供者拥有内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。