测试人员设计测试用例时应当遵循以下原则：在人员变化和新项目中能够重用；能够分类； 测试的内容不重复；保存在测试用例的数据库中；在项目进行过程中可不断增强。
设计测试用例时的一些通常考虑“点”是：根据产品规格测试基本功能；设计普通用户的使用方案；设计稀有或特殊的使用方案；与系统其他组成部分的配合（如FAX和上网可能都要用到调制解调器，测试中要考虑对设备的共享）；考虑特殊情况（比如内存和硬件的冲突等）；设计极端情况（比如内存泄漏、破坏性测试等）。
BUG的发现和管理
微软把软件中常见的BUG分为以下几种类型：功能错误；用户界面错误；边界值相关错误；初始化错误；计算错误；内存相关错误；硬件相关错误和文档错误。
测试工程师发现BUG之后，首先应验证是不是自己的偶然失误造成BUG出现，如不是则立即建立每一个新的BUG记录；尽可能地分析产生BUG的原因；设计合适的优先级和严重级别。测试人员的目标不是找出更多的BUG，而是改进产品的质量；依据BUG的优先级和严重级别分派给某一个相应的人；BUG记录要清楚、明白。
一般来说，BUG在数据库中有三种状态：活跃（Active）、被解（Resolved）、关闭（Closed）。活跃状态指的是测试人员新建一个BUG时的状态，必须分派给相应的设计人员、开发人员或者是用户教育人员，表明BUG的状态是等待纠正的。被解状态指的是设计人员、开发人员或者用户教育人员修正BUG后的状态，必须重新分派给报告BUG的测试人员，表明BUG已经得到修正，但等待较验。关闭状态指的是测试人员较验完成并关掉之后的状态，表明BUG已经得到修正，并完成了较验，如果再次出现同样的问题，还可以重新激活成活跃状态，此时又开始了另一轮的状态循环。活跃BUG数量的趋势，一般在代码完成前很少，代码完成后增长很快，接近Beta测试时会下降，接近RC时奔向零。因此由此亦可判断产品质量和里程碑的信号——每天新建的BUG数量与修正的BUG数量相比较；活跃状态的BUG数量。
永远有缺憾是所有智力活动的特征。软件一定有数不清的缺点，问题不在在于判断这个产品好与不好，而是决定修改哪一部分使产品比较能被用户接受或喜爱。微软有“BUG法庭”，审查每一个BUG，选择和修改产品中最重要的错误，决定相应解决方案，尽量使大部分的用户在大部分的时间内都能够使用愉快。
微软研发的交响乐章
软件研发需要先进的技术和科学的管理。纵观微软对软件开发周期过程的管理，其精髓的做法一是是将大项目划分成若干个子项目的里程碑式的开发模式；其次，通过对产品组各人员角色对职责的承诺来控制产品的开发过程，保证产品的进度和质量。经过多年的积累，团队合作一直是微软软件开发的基础。
在微软，既鼓励创造性，又最大限度地实现科学管理；同时，每个员工都能互相分享自己的经验和教训，彼此合作。 而这，正是微软的文化（最大的成功）。
文章来源于领测软件测试网 https://www.ltesting.net/
