首先应当把“尽早和不断地测试”作为开发规范的座右铭。
首先程序员应该避免检查自己的程序，测试工作应该由独立的专业的软件测试机构来完成。设计测试用例时，应该考虑到合法的输入和不合法的输入，以及各种边界条件，特殊情况下要制造极端状态和意外状态，比如网络异常中断、电源断电等情况，一定要注意测试中的错误集中发生现象，这和程序员的编程水平和习惯有很大的关系。对测试错误结果一定要有一个确认的过程。一般有A测试出来的错误，一定要有一个B来确认，严重的错误可以召开评审会进行讨论和分析。制定严格的测试计划，并把测试时间安排得尽量宽松，不要希望在极短的时间内完成一个高水平的测试。 回归测试的关联性一定要引起充分的注意，修改一个错误而引起更多错误出现的现象并不少见。 妥善保存一切测试过程文档，意义是不言而喻的，测试的重现性往往要靠测试文档。对于测试中常见问题分析及对策，我们一般把发现的错误bug(我们也称为缺陷defect)按严重性分为4类：死机(系统崩溃或挂起)、致命(使系统不稳定、或破坏数据、或产生错误结果，而且是常规操作中经常发生或非常规操作中不可避免的)、严重(系统性能或响应时间变慢、产生错误的中间结果但不影响最终结果，如：显示不正确但输出正确)、一般(界面拼写错误或用户使用不方便)。
一、形象类问题：---不专业、用户不信任 1、不符合用户操作习惯。如，快捷键定义不科学、不实用(键位分布不合理、按键太多，甚至没有快捷键)。 2、界面中英文混杂，经常弹出莫名其妙的信息，而且还拼错单词 3、SETUP界面：CopyRight 1994-1996；缺省认为用户使用某种分辨率； 4、说明书或帮助的排版格式不专业：中英文搭配不对、标点符号全角半角部分、没有排版禁则 5、程序名/路径名是程序员的名字、或没有安装程序、或安装程序不完善(丢掉一些必要的模块或文件) 6、界面元素参差不齐，文字不能完全显示，TAB时鼠标乱走。 7、程序界面不统一。
二、可用性问题：---用户无法使用或不方便使用 “用户比开发或测试人员在接触界面上要花费更多时间。表面上不重要的方面的影响会变得越来越大，最终甚至会掩盖了产品得有用得方面。”
下面是一些用户界面错误的例子： 1、输入无合法性检查和值域检查，允许用户输入错误的数据类型，并导致不可逆料的后果 2、界面中的信息不能及时更新，不能正确反映数据状态，甚至对用户产生错误的误导。如： 数据库中剩余记录个数；参数设置对话框中的预设值 。
下面是一些低效的用户界面的例子： 1、表达不清或过于模糊的信息提示 2、要求用户输入多余的、本来系统可以自己得到的数据。如：服务是否启动，安装后用户要手动修改某些配置文件。 3、为了达到某个设置或对话框，用户必须做许多冗余操作。如，对话框嵌套层次太多。 4、不能记忆用户的设置或操作习惯，用户每次进入都需要重新操作一次初始环境。 5、使用不完善的功能且不给用户以恰当的提示，如：对于TIF图片的不完全支持；Undo功能的局限性。 6、不经用户确认就对系统或数据进行重大修改
三、稳定性问题：---影响用户正常工作 1、不可重现的死机，或不断申请但不完全释放资源，系统性能越来越低 2、主系统和子系统使用同样的临界资源而互相不知道。如：使用同样的类名或临时文件名、使用同样的数据库字段名或登录帐号。 3、不能重现的错误，许多与代码中的未初始化变量(在Debug时一般是缺省初始化的)有关； 有些与系统不检查异常情况(如内存申请不成功、网络突然中断或长时间没有响应)有关。
四、其他问题 1、文档匮乏：无标准；无新功能使用方法；无版本改动说明。我们不仅要认为没有说明文档的产品不是是一个完整的产品； 也要认为没有说明或没有正确说明的功能是一个没有完全实现的功能，因为用户无法用得起来。 2、运行时不检查内存、数据库或硬盘空间等 3、无根据地假设用户环境：硬件/网络环境；有些动态库；安装程序换台机器不正确；假设网络随时都是连通的 4、提供的版本带病毒，或根本无法安装，或没有加密 5、提供Debug版本给测试组或测试用户，或项目组与测试组使用不同版本 6、用户现场开发和修改，又没有记录和保留 7、错误反复出现，改动得不彻底、或版本管理出现混乱 8、错误越改越多，改动得不彻底、或改动得不小心 9、版本中部分内容和接口倒退 10、有些选项永远是灰的；有些选项、菜单项在该灰时还不灰，并且还能状态显示 11、资源没有和代码分离，不同语言版本间不能平滑转换
五、期望关注的一些问题 1、修改Bug的人考虑得不够周全，也可能是没有能力考虑周全---不懂全部程序 2、问题留给测试组去发现的心态----不仔细测试、不小心修改、甚至不全面改(不彻底) 3、自己不会用，不了解产品的用法。 4、更多地从用户使用的角度考虑设计、编码与测试
