23、刚刚接触测试，还在培训中，想向前辈们讨点迷津，怎样学好软件测试？现在感觉很糊涂。

　　专家分析：首先了解什么是软件测试？

　　软件测试就是利用测试工具按照测试方案和流程对产品进行功能和性能测试，甚至根据需要编写不同的测试工具，设计和维护测试系统，对测试方案可能出现的问题进行分析和评估。执行测试用例后，需要跟踪故障，以确保开发的产品适合需求。是帮助识别开发完成（中间或最终的版本）的计算机软件（整体或部分）的正确度（correctness） 、完全度（completeness）和质量（quality）的软件过程；是SQA（software quality assurance）的重要子域。软件测试的发展，是伴随着软件开发技术的进步，以及软件质量管理观念的形成。软件测试是从软件质量保证过渡而来，软件测试的职位从传统的白盒测试逐渐演变到黑盒测试，从单一的测试岗位发展到众多的测试岗位，如：WEB测试、数据库测试、安全测试、手机测试。

　　学好软件测试

　　首先，是重点概念，现在有很多同学说概念或理论自己看书就能解决，主要是没有实际工作经验，其实老师在讲解概念或理论的同时，也在不断灌输软件测试的实质，没有理论上的掌握，你就无法理解一个软件产品怎么测试，为什么这么测试，怎么去考虑测试的方法或策略，软件测试术语是怎么引申来的，其实都在启发你的逻辑思维能力；也在不断的讲授和上机练习中体验软件测试的流程，软件测试的过程，由无形到有形，从无序的知识点到有序的系统的知识体系。

　　其次，要有统筹兼顾，全盘考虑的思想，做测试工作不是一个孤立、片面的工作，很多同学都曾说过以前的学哥学姐都传授过经验，测试就那么回事，等到了工作单位，每天就那点活，老是机械式的重复，这些都是我们没有看到或没有意识到的，目前的软件开发与软件测试已不再是小作坊式的规模了，它需要大量的人力来协同工作，每个人的工作都是必不可少的一部分，所以需要在全局上把握，从宏观上考虑，这就是软件测试策略的由来，但是具体测试工作还是微观上的，还需要掌握软件测试的各种方法，另外还要站在项目管理的层面上，从时间上、成本上、效率上、人员分工上、测试团队的能力上、风险上等诸多方面来统筹考虑，要做到从事软件测试工作要从宏观到微观、从全面到局部去认识，不能再盲人摸象或者摸石头过河，要从认识论升华到方法论上；

　　最后，要多上机实践，这个是非常关键的一点，多思考，会思考，找出疑难与不解，要从软件测试实践中总结出测试理论，再用测试理论去指导实践，这是个循环往复的过程，只有当你的认识达到一定的高度，你就深刻理解了什么是软件测试，你才会发现原来软件测试是那么的有意思、那么有动力、那么具有挑战性，以后还有很多未知的迷团需要你去拨开，还有更多的知识需要你去掌握。软件测试技术到目前为止，还是一门新兴学科，还没有形成固定的理论体系，还需要很多人的努力，最终将这门艺术变成一种科学。

　　24、一份需求文档，里边有很多功能点，就会有更多测试点。那么一般用用例设计方法来设计某一模块，具体操作起来是怎样的流程？那些用例设计方法的对象是功能点还是测试点？

　　专家分析：用例的根本目的是给测试人员使用，故在设计用例时，若脱离用例本身的使用环境而空空其谈，也就违背了用例设计的根基，直接导致被设计出的仅仅是无效用例而已。

　　所以，经常被谈到用例粒度、覆盖率等，虽然提及的次数多，但一直没有明确的标准规范。其很大程度就是因为用例本身的使用环境差异较大，若不进行实际情况分析，就无法得到恰当粒度的用例。

　　比如，针对某一模块，如手机电话本进行用例设计，大致流程如下：

　　（1）根据电话本需求文档列举所有的功能点。若不能很好掌握功能点划分的粒度，可考虑使用UI结构图代替

　　（2）分类各个功能点，主要依据为在实际测试中，各个功能点是否可能被其他用例补充。如，后台运行的功能点需单独分割作为被中断用例的前置环境；被动消息功能点则会被作为中断用例的操作步骤；与其他模块存在接口的功能点则会作为其他模块的补充用例….等等

　　（3）根据单个功能点的复杂程度，考虑是否存在需要提取公共用例。如将各个功能点的编辑框提取出来设计单独的编辑框用例。

　　（4）使用常规的用例设计方法，通常为等价和边界设计基础用例。若功能点过于复杂，可考虑继续继续分割功能点或使用高级用例设计方法。

　　（5）完成以上4步后，使用容错和场景法对设计用例的覆盖率进行验证。

　　（6）最后，根据此功能模块在系统流程图中的位置，设计该模块被其他模块调用的补充用例。（若每个模块都能保证完成以上5个步骤，第6步其实可以省略）

　　（7）根据设计要求，考虑NFT用例的分布，通常会根据每个功能点单独提取，也可以通过用例优先级控制。（NFT用例分布策略通常取决于公司测试策略，主要适用即可，不需要太纠结于形式）