做完OA项目后，公司接了个会议系统新项目，我主要负责测试。
无纸化会议系统是通过无线网络，借助平板电脑实现局域网内开会的一套系统。当年不像现在互联网这么发达，市面上比较常见的是纯软件的会议系统如webbex，还有硬件的会议系统（就是有自动升降台的那种会议系统），前者缺点是受网络影响，体验不佳，后者是价钱太高，而且对小企业来讲不现实。
我们先来看传统会议的特点:
在特定的会议场所，与会人员面对面的交流，讨论业务并进行决策；通过电脑、投影仪、幕布等为会议提供显示工具。
缺点是会议通知，会议文件准备，现场记录人员，会后纪要整理等繁杂的工作需要大量时间；缺乏互动参与，对于决策性会议缺乏便捷高效的解决方法（如投票表决）。
智能会议的特点：
会议管理清晰，节省纸张等资源，丰富的会议方式。
产品功能：
1、会议资料管理
主持人可以在后台上传好资料，根据资料权限，与会人可以直接在平板上查看或标注资料重点；会议时通过主持人共享给与会人员查看，避免机密核心资料外泄。
2、白板讨论分享
主持人可以在白板上写字绘图共享给参会人。
3、投票表决
与会人现场参与投票，现场实时匿名反馈投票结果，公平公正，提高投票效率。
以上是简单介绍，下面讲下我主要负责的测试工作，测试不是盲目随意的测试，需要有测试目的，测试方法，测试结论，最终评估项目的可操作性，为产品下一步的发布做准备。
测试目的
通过功能性测试，验证会议系统的性能及在公司部署的可行性、可操作性，为系统的实施奠定一个良好的基础。
测试环境
在公司局域网内搭建测试环境：
后台平台： windows2003
中间层： IIS 7.0
数据库： SQL 2005
设备： TP-LINK路由1台、思科无线AP1台，PAD 24台（8寸、9.7寸）
测试方法
一般来讲，软件公司都有专门的测试人员来测试，实施人员主要是配合做软件的功能性测试（黑盒测试）通过测试来检查软件的每个功能是否正常使用，不考虑程序内部等情况，只检查功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接受输入数据而产生正确的输入信息。
当时老大只给了excel模版，然后讲了1个小时，我就开始测试了。参考模版里面很简约的写了测试的重点，远没有软件测试书籍里面讲的那么多内容。
测试数据准备
主要有用户数据、权限数据、其它输入数据等。通过这些数据，我们建立好基础测试环境，准备后面的常规测试。
1）外观、命名的检查（一致性测试）
这里主要遵循一致性原则，就是软件各个界面、按钮等元素的统一。比如软件界面风格，按钮的摆放位置等，都需要一致。
2）默认值测试
所有的下拉列表、查询框、日期时间等都需要有默认值
3）常规测试
根据我们之前准备的测试数据，完成的操作软件，主要涉及的就是 增、删、改、查等操作，根据测试过程，看是否能达到预期的结果。
4）边界、非法值测试
我们输入的内容主要有数字、字母、符号、文字等信息，判断是否允许输入以及是否有异常的提示。
5）逻辑测试
比较简单的方法就是，按照用户的操作相关完整的体验下软件的操作流程，想象自己是小白用户，这样容易发现软件业务逻辑中容易出现的问题。
测试完毕后记录收集软件的缺陷或需求，反馈给项目经理（产品经理），然后他们会讨论决定排期并分配人员解决。当然，我们再描述Bug（缺陷）的时候应当力求准确性，尽量的可以量化，最好是能够重现这个问题，利于解决。例如
- 投票，新建投票，点击保存后，经常出现意外停止。
- 主持人发起投票，参会人平板有时能弹出投票框，有时没有弹出。
- 查看投票，查看饼状图的界面应该有“返回”按钮
这时第一次测试后反馈的测试结果的前3条，老大看到就开始发飙：什么叫经常和有时？这个可以重现吗？可以用数字衡量吗？为什么你觉得饼状图界面应该有“返回”按钮？
以上是反面的例子，要是现在我再来回答，肯定就会明确的告诉频率，比如：我这边重复操作了10，出现意外停止的评论是3次等等。针对为什么你觉得饼状图界面应该有“返回”按钮？可以这样说明：查看完饼状图界面，用户需要返回，有2种方式去实现：一个是增加“返回”按钮，另一个是做成再次点击饼状图返回的交互效果……
重复的测试工作比较考验人，必须要非常有耐心，才能测出软件的Bug，此外还要多问自己几个为什么，为什么要这么设计，可以不可以……这样在测试的过程中可以给产品带来更多新的东西。