|
进入现在所在的公司已经快一年了，期间参与了多个项目的测试工作，收获良多，感触颇多。一直想静下心来，好好总结一下个人所认识到的，现在所在部门可能存在的问题，并提出个人的观点。倒不是想改变什么，毕竟自身只是一个Tester，无力改变什么。只想在将来的某一天如果再遇到相同的问题，且自身有能力做点什么的时候，留下个参考而已。
一、 业务转型 在过去，部门所测试的是领域内专业化的产品，更多的面向专业级用户，且用户数量较小。客户和我们都有很良好的合作关系。产品中遇到的缺陷能很及时的得到客户的反馈，且修复成本较为低廉。但而今，在保持专业级别产品的同时，公司为了拓宽业务，保持业绩增长，增加了面向大众的内容提供服务，其对应产品所使用的客户群是未知的，且数量是巨大的，显然后者的测试风险更大，且一旦在用户中发现大的缺陷，修复成本非常高昂。
二、 测试用例 公司是一家美国公司的中国研发中心，成立时间也算不上非常长。早期专业级产品的测试用例都基本已经由美国研发中心设计好，我们只需要简单的执行而已。 而今，公司将开发和测试的重心移到了中国，美国对应的部门留下了只有一个开发和一个测试。随着新产品的研发和测试都由中国团队进行。所有的工作都需要我们从头开始进行，首当其冲的就是测试用例的设计。 一直以来，个人都认为测试用例是测试的万水之源。其主要包含三个方面，业务场景用例、功能点用例、测试数据（本处只关注功能测试）。测试用例的设计是一件极具技术含量的工作，个人认为其含金量甚至大于自动化测试。因为对于大部分企业，轻中量级的自动化测试足以满足需求，而自动化测试的基石就是设计好的测试用例。另一方面，对于业务场景的测试用例，因其涉及软件的核心功能，如果能设计出详细而有全面的数据流程图，其本质完成了一次软件开发的工作。因为在软件的系统设计阶段，这个步骤是肯定预先进行的。至于编码，只是实现数据流程图上的功能路径及攻克技术难点。 回首我们的测试过程，因为有非常详细的Spec，我们忽略了业务场景的用例设计，忽略了测试数据的设计，我们甚至都没有精心设计过我们的功能点测试用例，因为我们的Spec已经够详细了，测试工作的开展都基于Spec来进行。没有测试用例库、没有测试用例等级、没有精确的测试用时，有的只是一份Excel表格，其中列举了Spec中的各个细小章节点，算是一个个测试用例，初当项目leader的我在过去三周中经历的软件版本迁移中所进行的回归测试，用例的选择，用时的评估显得是那么的无力，因为没有数据可以参考。 当我们按照Spec完成一遍Sweeping测试后，剩余的就是Ad-hoc测试，人为能动性起了非常大的作用，当这个产品的多个版本我们已经测试了一年了，我们的测试兴趣和兴奋点还在哪里，我相信大部分人和我一样，都审丑疲劳了，当bug出现在我们面前时，我们还能敏感的捕捉到吗？ 幸运的是，我们的产品大部分时候有充裕的开发和测试时间，无穷尽的Ad-hoc测试下，估计80%常见的错误我们都能发现得到，如果某一天，没有充裕的时间测试，我们的产品质量从何保证？基于Ad-hoc？显然结果是否定的。 为了保证我们的产品质量，我们有必要向专业的测试流程靠拢了： n 发动团队的力量，精心设计业务场景用例、功能点测试用例、测试数据。 n 将测试用例纳入测试用例库集中管理，并设置优先级别和跟踪测试用时（在最初专业级产品的测试过程中采用的是DevTest测试用例系统，这两点都有做到，只是后来由于license费用的问题，公司转到了Jira系统中，但其不具备测试用例管理功能，至此我们失去了测试用例的管控）。 n 调动团队力量，相互审核其测试用例和测试数据的覆盖程度，尽可能做到高覆盖率。 n 让Ad-hoc做的更规范些吧，限制时间，限制功能区域。 n 让测试组成员拥有更多的责任感，建立区域责任制。有压力或许才有动力，这或许能稍微改善一些审丑疲劳所带来的副作用！
三、 自动化 说起自动化，不自然地想起了半年转正时和HR Director的谈话，了解到公司其实存在着一支专门的自动化队伍，帮助其它各部门响应自动化的各种需求。但是可悲的是，图有推广，没有响应。最终试用的部门在后续的使用中并没有给出积极且连续的反馈信息，有时就是一个无果而终的事情。想必还是因为习惯的问题！ 暂且不提自动化的技术细节能否实现，单纯从自动化的推广和使用方面来看，如果想让自动化能够最终成功，即收到自动化所提供的效益，个人认为在于两点： n 自动化的开发由熟悉软件业务功能的本部门测试人员进行 部门内部人员实施自动化，能有效且快速响应内部需求。如果跨部门，委托自动化开发部门来实现，那么势必存在自动化任务队列的优先级问题。自动化的需求有时就如同来自客户的需求一样，有一定的时间窗和deadline，一旦错过这个时间周期，自动化的开展意义会大打折扣；另外如果自动化的开展由部门内部人员来实行，其优点在于，部门内部人员熟悉软件业务功能，对于自动化的开发，编程实现上有明显的优势，且能有效控制自动化测试重点（软件功能重点，缺陷分布比较多的区域）。 n Control和push 自动化的实施，没有老板的强力支持是万万不行的，特别是当前公司中并没有自动化测试的习惯。当然这也和长期以来的产品其自身的特点是有关的。早期的产品并不适合开展自动化，因为其实现难度较大；另外一直以来产品的交付日期一直不是很紧张，我们有充足的时间来进行手工测试（我们的人手还是比较充足的）。时至今日，公司业务转向面向大众的应用软件开发，其软件的自身特点非常适合开展自动化。另外，产品的多平台的版本迭代，自动化测试的优点更是显示的淋漓尽致：有效且快速地保证软件的多版本回归中的质量！或许大家还不习惯自动化测试，或许大家习惯了手工点点点的测试模式，其本质还是在于我们还没有动力去做这件事情，我们也没切实体会到自动化到底能给我们带来什么！
四、 测试总结 首先想起了前段时间看到的一句话：“一个人的提升，70%来自于实践后的反思。”我并不清楚70%这个数据是否真的准确，但可以肯定的是总结总会使我们反思过去的经验和教训。经验值得推广，教训值得思考和探索规避方法。 对于测试项目而言，总结并不是最终阶段的任务，也不是项目leader一个人的任务。总结来自于每天测试完成后的汇总和思考，没有日常的积累，项目结束后的总结会显得不够全面！测试是参加软件测试的所有组员的共同的事情。项目leader不可能知晓全部的细节，全员参与，组织讨论会，分享每个测试组员的收获，集集体的智慧，以达到1+1>2的理想效果。 记得当年上高中的时候，数学不是很好，有一道几何题前后问了数学老师三遍，总是在每次听完老师讲解后很清楚的理解了解题步骤，可惜时间一长，仍然忘得一干二净。当时也知道有种东西叫错题集，只是每每写了几道题后，就没有写下去的毅力了。其实错题集也是种总结报告，不做总结，我们或许还会在同样的问题上感到迷惑，因为我们没有把本质搞清楚！总结也是一种方法论，掌握合适的方法总能让事情解决起来显得非常高效。
五、 培训 说起培训，一直是个纠结的事情，基本可以用positive和negative两个词来形容。公司有一套非常成熟的同事间的培训机制，基本一两周就会有一场培训讲座，个人也从其中学习和了解到了许多东西。 Positive，是因为当你不知道一样东西的时候，如果有人领你入门，指明方向，真的是一件非常惬意的事情。或许某项开发同事介绍的技术，你不会在测试中遇到，但是你至少知道了，哦，原来还有这种技术存在啊，对于自己眼界的开阔，真的是非常有好处。 Negative，或许还要说几个前提：当前自身的能力还有限，还不足以给整个公司的同仁介绍技术知识；我更倾向于和测试部门内部的同仁们交流测试心得；我更倾向于技术的深入，而非普及；我更倾向于主动式的学习，而非被动式的接受；我更倾向不采用PPT的形式，因为PPT能承载的内容实在太少，时间久了，大部分内容会被忘却；我更倾向于写出详细和深入的技术文档，以作部门内部传阅之用；我更倾向于采用讨论会，而非讲座的形式开展，因为讲座更多的是一种被动式接受方式，但讨论会则是一种集思广议的方式，而一个人的认知和能力是有限的，因而讨论会能产生更多知识碰撞的火花。另外讨论会的开展的前提要求对讨论的话题需做前期的准备工作，这涉及到主动式的学习方式。我尝试过几次将技术文档在部门内部传播过，可惜没有收到过反馈。没人说你的观点对，也没有人说你的观点不对。至于讨论会嘛，就更无从谈起了。 用一句自私而悖论的话，总结一下我对培训的感受：我喜欢被人培训，而不喜欢培训别人，但我喜欢和别人交流与探讨！
六、 学习 IT这个行当注定是个永远需要学习的行业，技术不断的推陈出新，其速度是令人惊诧的，如果长时间不关注业界的技术发展，或许就会成为一个火星来的人。让我们看看时下正兴的技术方向： n 云：2010年十大关键IT技术之首，热的有点烫手。第二届中国云计算大会正在北京召开。云似乎是一场革命，犹如当年的互联网革命一样。云的优越性我们或许已经切身体会到了，Google的Doc, 微软的Live Mesh，这些应用云让我们体会到了便捷的信息同步性。那么应用云的有效性测试，该如何开展呢？无穷尽的客户端下，测试策略该如何应对？ n 3D：一部Avatar将全民带入到了全新的视觉体验的世界。梦工厂已经宣布以后所有摄制的动画片都是3D的；三星已经率先发布了基于硬件芯片处理的实时2D转3D画质的LED电视。3D有别于2D，就目前都要借助眼镜来进行观看，且每个人对画质的感官和2D相比有非常大不同，有没有方法来量化这种感官，什么是PASS？什么是FAIL？ n Android：免费，任意定制，将Android推到了众手机平台的前沿，今天看到Google技术大会上发布的数据，Android在美国已经成为最受欢迎的智能手机操作系统，且已经超过iPhone。这或许又是一个淘金方向。都说嵌入式产品的自动化难搞，有没有独门秘籍可以研究？ 除了关注时兴的技术方向，关注一下别人的优秀测试方法，学学微软测试，看看测试大牛们在关注些什么，或许能给我们有效的引导，能让我们少走很多弯路。闭门造车，势必会成为井底之蛙，夜郎自大！ 为了避免我们被淘汰，且能保价升值，让我们永远保持学习吧！
以上种种，概括起来无非就是一个词：求变！对于一个软件公司，身处于一个科技日新月异的时代，用户的需求在变，开发的技术在变，我们的测试或许也该变变了！ |
|
|
