如何测试网页上的搜索功能

时间紧迫的情况下，如何做好测试工作？
软件产业迅猛发展，已经渗透到人类社会的各个层面，大到航天军工，小到商店收银，无不有软件的应用。

因此这个命题有点大，不同类型的软件，测试特性有所不同，很难以一盖全，这里我只是以一个从事ERP类软件测试的人员角度阐述一些观点和实践经验，希望对大家有些许帮助！
1）对时间、成本、质量要有清晰明确的认识。

有过项目经验的人肯定对时间、成本、质量这三轴围成的三角形不陌生，三者是相互作用相互制约的，作为项目管理者希望项目成功，自然要平衡这三要素的关系。

时间不充分的前提下，想作好测试工作，这个“好”字就得从项目整体的层面去认识，而不能单纯从质量一条线去衡量了！所以，测试人员有可能接受这样一个背景下的任务时，是不是应该和项目负责人提出一下：如果要力保时间，那么就要在成本上加大投入，另外在质量上必须接受一些瑕疵，我们是不是必须要这样作呢？明确一下我们本次任务的目标到底是什么？如果得到的答案是要抢时间，那么好，我们再去抱怨时间的紧迫就没有意义了，而是应该想一些切实有效的办法来解决这一问题！
2）加大成本。

上一条中我们看到了，如果时间要缩减，质量要求不变的情况下，项目成功度（三角形面积）须要通过加大投入成本来解决，很直接，就是人、财、物！但是那往往这是很理想的状态，绝大多数的情况则是随着时间的不充分，成本同样也不会有过多的追加，否则我们也不会把这个问题作为难点来讨论了。

那么我们就只能通过内部挖潜来尝试一下了。

3）需求要对产品有准确的定位和适当的剪裁。

作软件研发业务的最前端，产品定义、需求、设计对产品的成败至关重要，从实践中看，如果前端有一个小环节没有花时间考虑到位，那么后期的编程、测试的过程需要花数倍的时间来返工、弥补，甚至还要承担引发连锁反应的重大风险，因此在测试甚至编程开展之前，需求人员务必把份内工作作足，确保项目需求的准确性和稳定性。

同时如果在比较了时间等资源条件与要实现所有功能的工作量之后还是无法平衡，那么就必须作适当有效的剪裁来确保本次开发项目的可完成性。

4）开发人员实现的内容要及时充分印证和验证。

印证是指确保作出的东西是需求要的；验证是指确保作出的东西是可用的、好用的。

这方面可以通过各种手段，比如需求验证、单元自测、结对编程、同行评审、和需求测试人员加强沟通等等，原则只有两条：及时、充分。

5）测试的二八法则。

偏向业务的软件产品中，真正核心的流程和场景只占20%，用户往往会把80%的精力放在我们的这20%部分中，对产品的认可度表决权也基于此，因此决定项目是否能顺利验收，产品是否能顺利发布等等，都很大程度取决于此。

所以我们在资源不充分的背景下，只能抓大放小，把有限的精力高效利用，找准这20%的重点场景和业务，部署我们80%的测试资源，有侧重的去开展测试业务，作到有的放矢！
6）测试计划的重要性。

往往很多项目一说时间紧，就把计划呀、评审呀这类环节省略了，其实要省时间，即是要敏捷，那么敏捷的朴素思想就是挤掉一切不是必须有的水分，使研发过程LIGHTLY。

但是，如果一个环节的省略，会造成后续很大的潜在损失，那么就是必须的环节，因此适当的测试计划我认为恰恰是在短时间保证质量的有效途径，时间紧，则更要求计划作的细，作的好落实，分工给每个测试人员时，大家都很明确自己要作什么、作到什么程度、什么时间作完，同时各项分工整合在一起时还要作到对关键点的全面覆盖、要充分考虑到应变方案以应对可能出现的拖期等意外情况。

再有就是在计划中把过程细分成一些关键的里程碑，比如什么时间点把详细需求固化、什么时间把测试方案确定、什么时间进行需求验证等一系列重要的时点，我们管理者在过程的监督和控制上只要抓好这些里程碑，就能比较好的驾驭这个项目，当然里程碑的颗粒度确定要根据项目的实际情况有所区别，量身定制最适合的。

另外，计划是否起到良好作用的关键在于执行过程的管理，世间万物都是变化的、唯一不变的就是变化，所以计划中要体现优先级，在执行过程中及时调整，把握好哪些是不能变的，哪些是可以调整可以剪裁掉的，这是非常重要的。

7）风险前置。

开发前期提前实现那些隐患比较大的功能部分，比如基础数据档案、非本部门或本项目组负责的接口方模块、复杂业务逻辑功能点、核心算法和单据、性能要求较高的操作等等，这些内容如在后期发现作的有问题，往往投鼠忌器，修改成本过大，所以这些环节尽量安排提前完成并提交需求、测试人员验证。

8）建立高效的工作流程和沟通机制。

比如站立会议、燃烬图看板、成果演示等敏捷开发的工作方式可以适当尝试，一切以高效顺畅的沟通为底线，当然事情不是不需求讨论，但讨论一定要迅速落实，有了良好的工作流程作保障，会发现很多时间被挤了出来。

9）人的管理。

21世纪什么最贵？人才！只有把人管好用好，事情才谈的上能否作好。

首先提升人的能力，通过知识共享、传递、考核等手段，快速把测试人员的能力提升到胜任的水平；第二对人员进行合理的分工安排，关键位置关键人、分组分块、以老带新、男女搭配、交叉测试等各种方式；第三建立适当的授权，充分发挥团队核心人员的作用，一个人的关注度毕竟有限，集权式的管控模式在高效模式下很难运作的好，作为测试经理，如果手下有核心的主测或小组长，只要管好他们就成功大半了，同时有任命必有授权方可名正言顺，如果想基层的负责人顺利开展工作，适度的授权和放权是必须的；第四监督必不可少，没有监督，再多的任务布置都是形同虚设，负责人要在必要的环节、时点作关键的监督，比如抽验等方式对测试人员的工作状态和成果作具体的确认，对好的褒奖，对差的批评指正，累犯不改的害群之马尽早更替；最后还要提的一点是士气很重要，要努力营造一种积极团结，能抗压，爱攻坚的团队氛围，加班虽是捷径但实际上还是工作时间的延长并不是解决时间紧张的途径，而且同时可能会带来人员士气和健康方面的隐患。

10）适度的测试工具引入。

工欲善其事必先利其器，适当引入测试工具代替人工无疑是件提升效率的好事，但
一定注意投入产出的平衡，当时间不充分时尤其要考虑这一点，不要费了半天力气好容易把工具用上了，项目时间也所剩无几了，那样的话发挥不了太多作用。

也不一定非要用很大而全的商业测试工具，有条件的可以自己开发一些小巧实用却能提升具体某个环节实际工作效率的工具，例如把一些公共可复用的测试用例整合起来作成一个共享的库，通过一些简便快捷的检索和订制就可以生成测试任务的小工具，诸如此类的思想，可以鼓励测试人员作一些创新和尝试，在实践中不断借助工具的力量提高效率。

以上种种，都是在我们实际工作中的一些体会，时间仓促，没有好好整理，很多没想到的地方也欢迎大家补充，希望对大家的测试工作开展有所帮助！
陈玮
2011/8/30
粗略列一列，大致可以从以下几个层面考虑吧：
1．功能方面，是否能按指定条件查到正确、完整的结果，具体：
1.1录入条件为可查到结果的正常关键字、词、语句，检索到的内容、链接正确性；
1.2录入条件为不可查到结果的关键字、词、语句；
1.3录入条件为一些特殊的内容，如空、特殊符、标点符、极限值等，可引入等价类划
分的方法等；
2．性能方面，可利用测试工具或各种测试手段考虑功能在各方面的表现，具体：
2.1压力测试：在不同发用户数压力下的表现（评价指标如响应时间等）
2.2负载测试：看极限能承载多大的用户量同时正常使用
2.3稳定性测试：常规压力下能保持多久持续稳定运行
2.4内存测试：有无内存泄漏现象
3．易用性方面，交互界面的设计是否便于、易于使用，具体：
3.1依据不同的查询结果会有相关的人性化提示，查不到时告知？查到时统计条数并告知？有疑似输入条件错误时提示可能正确的输入项等等处理；
3.2查询出的结果罗列有序，如按点击率或其他排序规则，确保每次查询出的结果位置按规则列示方便定位，显示字体、字号、色彩便于识别等等；
3.3标题查询、全文检索、模糊查询、容错查询、多关键字组织查询（空格间格开）等实用的检索方式是否正常？
3.4有否快照等快捷查看方式等人性化设计？
4．兼容性方面，跨平台、多语言等多样性环境组合情况下测试使用的正常性，具体：
4.1WINDOWS/LINUX/UNIX等各类操作系统下及各版本条件下的应用
4.2IE/FIREFOX/GOOGLE/360/QQ等各类浏览器下及各版本条件下的应用
4.3SQL/ORACLE/DB2/MYSQL等各类数据库存储情况下的兼容性测试
4.4简体中文、繁体中文、英文等各类语种软件平台下的兼容性测试
4.5IPHONE/IPAD、安卓等各类移动应用平台下的兼容性测试
4.6与各相关的监控程序的兼容性测试，如杀毒、监控、防火墙等工具同时使用
5．安全性方面，往往容易被忽视的环节，具体：
5.1被删除、加密、授权的数据，不允许被查出来的，是否有安全控制设计；
5.2录入一些数据库查询的保留字符，如单引号、%等等，造成查询SQL拼接出的语句产生漏洞，如可以查出所有数据等等，这方面要有一些黑客攻击的思想并引入一些工具和技术，如爬网等。

5.3通过白盒测试技术，检查一下在程序设计上是否存在安全方面的隐患；
5.4对涉及国家安全、法律禁止的内容是否进行了相关的过滤和控制；
6．异常性测试，各种破坏性的操作的影响测试，具体：
6.1查询过程中断网、关机
6.2查询过程中强行中断关闭页面
6.3查询过程中强行杀死相关进程等。