1. 软件测试过程：
对软件需求评估，全方位掌握第一手软件资料；
制定测试计划------------根据测试类型，制定时间计划；这个过程很重要，里面涉及软件出现bug后的严重等级程度考虑，软件测试文档的涉及，时间的安排，最好和各个负责人一起讨论，并明确整个软件开发过程中出现问题的解决，如具体人，电话以及及时的沟通，好处很多，这样出现过不去的情况会多一种选择。噢，还有测试需要的资源，如人力，设施及相应其它人员的支持，如硬件人员，配置人员；
设计测试案例------------根据需求设计测试案例；设计测试案例是对测试人员的另一重要考验，第一考验就是你对所测试工作的框架理解，在测试计划中体现。测试案例最需要注意的问题就是分步写，罗罗嗦嗦一大堆，其价值会随着时间的流逝而毫无价值，有时可能出现这种情况，写完的测试案例就那样安静的长眠于电脑中或者是书柜中，它有个英文名叫shelfware；避免这种状况的方法就是抽象测试案例，把主要执行的步骤名字说出来，举例子如：登入界面测试，
甲：输入登入名/输入密码/登入
乙：输入正确登入名，错误密码，单击确定；
输入错误登入名，正确密码，单击确定；
这里毫无疑问我们应该选择甲的做法，就是我说的抽象测试案例；
对于测试案例的另一点就是测试案例的编写有个不成文的规范，对于测试需求中的每一条都要至少准备两个测试案例，一个正确执行的，一个为错误的，最重要的是测试错误时的情况；
设置测试环境------------软件的安装，配置测试环境；
测试资源-----软件测试人员、硬件电脑、网络等等，这里最要关注的就是麻烦的系统环境，如Windows XP、98、2000系列，每个操作的方方面面都不同，而且对于一个不熟悉系统配置的测试人员更麻烦，所以现在的测试很少测试程序在不同系统下的兼容性；
开始测试------------------按照测试案例执行测试，并增补测试案例；
测试的第一步，分清测试内容的前后、主次关系，说白了就是谁更重要，谁最先测试，这些时常要依据程序员的开发进度决定，对于应用不同环境下的程序，测试时所要求的重点也不一样，如有的稳定性要求的更多些（金融），有的稳定性要求的更多些（大众软件），有的精确度要求的更多些（太空）；
测试第二步，抓住测试的基本功能，如提款机最基本的功能就是取款，测试时对取款一定重视，如ATM要去银联测试，对报文、通信就要重视，这些是最基本的；
测试的第三步，在完成基本功能测试后要注意界面测试、外语测试、性能测试；
***********测试有个定律，经常出现bug的地方也是bug最多的地方***************
提交测试报告------------记录测试结果，并反馈--------反馈很重要，比如测试某项工作，
共有7个测试案例，其中甲乙丙3个案例没有通过，如何没有通过；
每天的测试工作完成后并不意味着测试就结束了，相反真正的测试才刚开始，我们要把每天的测试bug
总结，并通过一定手段传到需要负责程序开发的人员手里，同时写测试bug也是非常重要的，而且是
相当要求规范的，其最基本的几点如下：
1、 bug发现的时间，发现的模块，发现人，即when\where\who；
2、 bug的严重程度，出现的几率，可否重现，重现的步骤，如果不能重现，是否有当时的日志；
3、 bug的存放地点，方便以后查询的唯一标识号，负责此bug的人，以及出现bug的版本号；
重复测试-------------------验证出错的地方是否得到改正，没有出错的地方是否出错；
很麻烦、很枯燥的一步，测试人往往很厌烦，觉得测试过的内容只轻轻带过就好了，但是要注意了，这样会丢掉不少bug，试着采用另外一种思路来重新考虑测试；
*************测试理论理有个著名理论叫杀虫剂悖论（pesticide paradox），简单理解就如同给果树喷农药，为了杀灭害虫只打一种杀虫药，虫子就会有抗体而变的适应
