软件测试的提升.doc

软件测试的提升
作者：哈哈猪
（本来是想写一些对测试人员提升的方法的，后来写着写着跑题了，大家见谅哈，嘿嘿）
前段时间遇到了一个问题，软件测试如何提升？后来我自己思索了一下，有一些不成熟的想法，在这里给大家分享一下。
总体而言，软件测试是一个比较新的职业，软件测试的发展、提升还没有比较成熟的理论。本篇文档也是个人的一些经验总结，希望可以对软件测试的同事有所帮助和启发。
我将软件测试的提升分为四个主要方向，分别是测试基本技能，自动化测试，测试工具，测试文档。
第一篇 测试基本技能
对一个软件测试工程师而言，测试计划，用例设计，测试执行，测试总结，测试评审这些是基本工作，也是最重要的技能。
1 测试计划
测试计划是对软件测试工程师比较重要的一个技能，主要是考察软件测试工程师的项目规划能力。只要注意到了以下几个方面，就可以做出一份比较成功的测试计划。（此项在公司现有的测试计划模板中有明确指出，这里不再赘述）
A 测试目的
B 测试范围
C 测试方法
D 测试资源（人力和仪器）
E 测试时间
F 测试风险
2 用例设计
测试用例的设计，是现在整个测试行业绞尽脑汁进行优化，规范化，效率化的地方。公司内部也引进推广过一些业界内部常用的工程方法：错误推测法，因果图法，功能图法，正交分析法，平时使用较多的可能是功能图法和正交分析法，一个比较关注独立功能的模块，一个适用于交互功能的模块。
现在，我们自己设计用例的瓶颈是在扩展思路这一块。我们现在的用例模式，一般都比较侧重于功能的单独实现，用例比较分散，功能实现比较独立。这样的用例，功能点都涉及到了，只针对功能点来说的话，我们的用例是全面的。
但是按照这样的用例进行一次全面测试，我们仍然能发现，从用例测试发现的bug，与用例数量的比例并不能令人满意。也就是说，我们的用例“全面性”只是体现在了表面上，一些复杂的，深入的用例还是没有包括进来，我觉得缺少的用例部分应该是如下这些方面：
第一，关于流程方面的用例没有包含全，有可能单独的功能都是OK的，但是如果两个功能有先后使用关系，就有可能出现问题，例如：压扩扰频两个功能单独使用都是好的，而先开启关闭压扩，再开启扰频，可能就会出现问题。
第二，包含多个测试点的，例如，将带亚音的信道和不带亚音的信道加在一个扫描列表中，有可能就不会再扫描亚音。
第三，功能嵌套类的，例如，在单独工作中启动VOX，是否正常。
第四，特殊使用场景的，例如，在使用中关机。
上述的这些问题，如果是针对修改的话其实也不是没有思路，按照现在已知的用例设计方法分别是：因果图法、功能图法、正交法、错误推测法（说是场景法也可以），就可以进行改进。
但是，个人认为，仅仅是掌握了一些用例设计方法，就想编写出一份高质量的用例，还是不够的。这个从我们现在的用例就可见一斑。我觉得，在现阶段，模板和流程对用例编写所起到的作用也许会更大。
首先，所谓的模板，就是用例的架构需要一个模板，这个模板可以这样分：基本功能，高级功能（本模块内部的交互和流程先后），交互（与其他模块的），场景法设计（使用场景模拟），问题收集（包括TD以前的问题，客户反馈的问题，公司内部反馈的问题）等五个部分。举个简单的例子：

基本功能
alert call
单独功能实现
select call
单独功能实现
高级功能
alert call
优先级（发解码的先后顺序）
select call
交互
扫描
扫描中发解码
场景使用
客户使用习惯，是否挨着身体发射
有的机器爱着人体发射，功率会降低一半
问题收集
扫描中解码成功率低
设置优先信道或者将预载波设置长一些可解决问题

如果用例的构架订好了模板，那么用例编写也就订好了模板。
其次，就是流程方面，需要增加两个评审点，第一个就是用例构架完成后，需要对构架进行评审，这时候的评审，需要多注意用例的全面性。第二次的评审，是用例完成后的检视评审，这个过程中需要对用例的可读性，可操作性，可验证性（预期结果写的清楚详尽）进行深入的讨论。
用例编写的过程中，评审是一个保证质量重要的关节点。在一定的时间范围内，用例投入的质量与时间是成正比的，用例编写的一些投入，是必需的。
所以，用例的编写，需要内在和外在两方面的努力，内在就是对功能的熟悉，对用例编写方法的掌握，外在的就是定制模板和流程设计。
3 测试执行
许多的软件测试工程师都有自己的测试技巧，但是不管怎么样，下面三点是必须掌握的。
第一，用例执行时的技巧，多个功能点一次测试完毕。因为我们的用例有许多是一类型的放在一起，这样，我们可以一次多看几条用例，而使用一个写频配置完成多个用例测试。
第二，异常情况敏感，任何一点的异常都有可能揪出一个大bug。
第三，测试灵感或者对场景测试的一些模拟。（没有用例的，一定要记得添加用例）
4 测试评审
测试评审对软件测试工程师的问题把握能力和沟通能力都有要求。
根据个人的经验来说，其实只要坚持原则就可以了，这个原则就是：功能上的和涉及客户的问题都必须修改，如果不能修改，则需要明确指出由开发来承担后续由这些问题所产生的影响。
第二篇 测试自动化
测试自动化是软件测试做深做高的一个重要方向，现在业界内普遍的认为软件测试自动化比软件测试更“技术”一些，相对的待遇也要好一些，如今的软件测试招聘基本上都会要求掌握一两个自动化工具，可见其重要性。
公司的自动化实现，在深圳业界内，算是比较靠前的，在这里，我只提出自动化提升需要注意的有两个方面：
第一，前期规划，保证产品设计可以较好的支持自动化，在产品设计之初，产品可支持自动化测试这一要求就必须作为重点事情进行规划（可以请测试部总体组做评估）。切记，自动化并不是引入几个自动化工具就可以做到的。
第二，做自动化的目的是什么？是为了提高效率！所以，自动化一定要实用！搞很深很高端科技的东西却实用性不大是劳民伤财，那个“风扇就可以吹走空纸箱”的笑话，我们不能搞到自己身上。
自动化跟软件测试一样，入门简单，精通却难，想成为合格的自动化工程师，需要付出很大的努力。当然，就目前公司的软件自动化测试而言，只要深入一些，制作一些脚本还是比较简单的，而且，这本身也是一个不错的学习机会。
希望大家在平时都能重视自动化的制作，并积极参与，这对于测试本身的升值，是一个非常好的途径。
第三篇 文档
软件测试工程师在文档这块普遍比较薄弱，其实测试文档是否专业也是测试工程师的重要评价指标之一。
首先，对项目而言，测试文档的完善，可以起到驱动的作用。比如，前期如果可以把测试标准方面和测试方法详以细的文档提交，那开发就会有意无意的针对这些进行研发，加快项目后期的进度。
其次，高质量的测试文档可以体现测试是否高质量完成的证明。软件测试工程师有这样的错误想法，包括以前的我在内，总是觉得测试的事情本来就多，有那么多的Bug在等着测试和处理，根本没有时间写文档。有了这样的想法，就开始忽略文档，觉得写测试文档太累，能用嘴说的就不用手写，能简单写的就绝不详细写。实际上，一个项目测试是否高质量完成，一般可以从两个方面进行评价:① 能否提供高质量的测试活动和结果。②能否提供有效的测试文档。第二点正是这个观点的证明。
接着，测试文档的重要性还表现在对于项目“传承”上，有了好的文档，那么当项目有新成员进入，测试文档就可以承担起指导新成员快速工作的作用，而不是单单询问原来的测试人员，节省了大家的时间。还有，当测试完成后，测试文档就将成为项目测试的文字载体，在后续人员培训方面提供详尽的素材。
最后，测试人员不应该只为写测试文档而写文档，良好的文档是思想交流、沟通的基础，也是整理和理清思路的基础。不懂得从经验中学习和成长，永远不会有质的提高。只有当每次完成一个测试任务，都有目的的总结，找到自己的不足，一个合格的测试人员才可能成长起来。
第四篇 测试工具
首先，这里讲的工具与自动化测试的工具是不一样的，这里讲的工具主要是平时测试时对问题的验证，和辅助测试的一些工具，比如说：综测仪，示波器，串口监视器等，与QTP等自动化工具是要区别开的。
测试行业，无论是硬件测试，还是软件测试，对测试工具的要求都比较严格。软件测试一般对各种编程语言，网络测试工具，数据库，自动化工具等都有明确的要求。
工具是为了提高效率而存在的，测试工具是为了辅助测试的，真正的实用主义测试者不会对测试工具特别看重，不会觉得一些工具不会使用就落后于整个时代，他们对待测试工具的态度是：按需索取、信手拈来。只有最合适的工具，没有最先进的工具。
另外，测试对工具的依赖一定程度上来源于对标准的渴求，根据大家都认定的标准（工具）确认的问题，更具有权威性，这也是平时我们手动测试发现问题，一般情况下会尽量寻找测试仪器进行验证的原因，也是测试人员一般比较谨慎的原因。
在整个测试过程中，测试工具起到一个非常重要的作用，有时候，能不能很好的使用测试工具，对测试的进展会起到很大的影响，希望测试工程师在闲暇之余，可以做一些对测试工具的基本研究，你会发现这其实是一个很有意思的过程，连带的，测试工作也就不会那么枯燥乏味了。
第五篇 总结
上述语言，均是一家之言，能够获得您认可的，可以随便取用；觉得有误的，也欢迎来找我理论，毕竟沟通是进步的很好的途径。