10条软件测试过程中常遭遇的问题及解决思路，值得收藏！
第⼀问：测试团队的⼯作也依赖于业务和开发，如何有效提⾼与业务团队和开发团队的合作默契？
答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版本迭代不具备附件功能（略遗憾）
放的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搭积⽊试的，加业务断⾔，测试可以把更多精⼒放在业务上。功能的同事也可以很快学起来，⽤起来，他们也⽐较喜欢学。
第九问：如何识别有效的加班和⽆效的加班？软件测试app
有效加班与⽆效加班，其实还是得看主管个⼈观察与评估。可以从⼯作量及⼯作效率等相关因素上考虑。及测试结果上做评判。
第⼗问制定上线的产品发布的质量标准需要考虑哪些维度？怎么统计线上遗漏率？
发布标准，很重要的⼀个是表是缺陷的收敛情况。如果不收敛，发布风险太⼤。当然，是不同维度的bug的收敛程度，不能只看⼀个维度，包括功能和性能。⼀般上线之后遗留bug不是由研发部门来处理了，⽽是运维或者售后部门来收集和记录，并反馈到研发。这类bug要特别标识，便于集中分析。很多公司，记录运维阶段的bug是有专门的系统的。有别于我们研发阶段的bug系统。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。