我这个人做完一件事情喜欢反思和总结，这个习惯一直保留着。在测试部做了两个月，虽然我对测试还是门外汉，只做了一些具体工作，但忍不住把自己的想法写了个系统文章，其实提意见我的看法是领导一般不反感，只要你的意见系统，有建设性，不针对个人攻击就好。
下面就是我当时写的对测试工作的反思，有些是参考了一些资料，结合自己总结写的。
对软件测试工作的反思
测试人员的配置：测试人员必须包括三类人，专业测试人员，熟练测试人员和对软件完全不熟悉的新人。专业测试人员主要负责测试规划和测试大纲，极限测试环境设计，熟练测试人员主要负责按规定完成大纲测试，属收敛性测试，新人主要负责易用性和界面合理性测试，属发散性测试，发现的各类问题由专业测试人员分析并给出解决对策。
测试文件的准备：提前准备好软件测试需要的图、工艺文件，OFFICES，TXT，其它CAD设计文件测试标准文件，而不是临时去找
测试软件的准备：应该提供不同的操作系统和数据库平台测试环境，必要的话提供多台测试机器，减少人工浪费在安装环境上的时间。
测试机器的准备：应给测试人员配置相对好的机器，以提高测试速度和效率，同时一定要配置相对差的机器，模拟在用户现场极端运行环境和速度。
业务测试的准备：（针对当时软件测试主要是功能测试的情况）应该设计大量的业务测试流程，流程可以从开发，市场，实施部门配合，给予解决。
测试阶段的划分：应该分开发测试（非常反感开发不懂操作，也不自行测试就提交测试人员验证的模式），功能测试，极限测试，BUG测试（主要是测试历史环境下有记录的BUG），现场测试（主要是易用性和测试业务流程）
对测试大纲的意见：
1、测试内容不全面，缺少测试文件样例，测试软件版本号
a）很多软件存在的功能测试大纲没有涉及，我自己把只要能够用的功能都测试了一遍，超出了规定测试大纲的内容，发现了很多新错误，当时公司测试水平也确实有限，所谓软件测试就是两个临时员工负责。
b）软件功能之间组合连续测试不完善，很多功能单独是好的，但如何把管理软件功能串合起来用的测试流程不清晰，需要测试人员自己发挥
2、极端环境测试得不够
对空数据，大数据，大量网络并发等环境下测试很不够，往往这个时候能测试出很多问题，例如软件运行效率
3、对误操作或非法操作给系统带来的影响测试大纲无体现
测试大纲都是要求你如何如何操作，应得到何种结果，但问题是用户不一定会这样操作，但我这里随意操作常常造成死机，这也是我对测试大纲很不满意的，软件应该做到即使是用户误操作系统有提示或者没反应，而不是死机，更不是要求实施人员去培训正确的操作。
4、测试动作量化不够
例如同一功能测试次数，测试频率，测试速度都应有规定，例如某一功能测试100次，可能才出现一次BUG，如果只测试10次可能就是OK的，或者连续使用10次就会出现BUG，但单独使用没问题，这些应该也体现的测试大纲，而不是让测试人员自己去测。
5、测试中对开发人员的开发功能逻辑了解不够，无法自觉测试潜在的功能缺失和冲突或干扰（后来我才晓得这叫白箱测试）
6、对软件的宜人性，友好性，WINDOWS下程序风格一致性，简洁性没有任何评估
7、没有以用户层面对设计的功能和动作进行挑剔。
8、缺乏软件测试质量保障体系（后来开目花了大力气建设了测试体系，通过CMM3级评估）
9、没有单位时间内任意测试过程中死机纪录，只测功能的实现性，没有系统稳定性指标，实时性，同步性等效率量化指标
10、没有参照软件的对比测试
11、没有前期积累的测试文献
12、测试工作不应该仅仅成为开发的完善工具，还要承担一部分探索开发方向的作用，甚至一定程度上和开发交融（这个观点我现在不支持，要求太高了，主要是当时我对自己测试太有信心了）
测试目的：
1）检查出软件中的功能设计不足或BUG以保证能满足用户正常使用
2）在说明书中明确一些常见错误操作以防止用户误操作或给出解决方法
3）对一些一时难以解决的难点，导致的问题给用户一个解释或变通的方法
根本目标：
保证开目软件的易学易用稳定的优势，以优质产品占领市场，赢得口碑。