测试总结
测试总结项目第一阶段的测试总算结束了，不过很庆幸没有发现很多的BUG，其中发现的BUG相对于项目的功能方面也没有太大的影响；BUG发现的少，不能说明测试做的不到位，只能证明我们项目开发的很成功，这样我们项目潜在的BUG就会相对来说降多很低，为我们的产品质量奠定一个良好的基础。下面就第一阶段的测试总结如下：
1.WEB页面
WEB页面是客户对产品的第一印象，如果WEB页面出现的问题太多势必将会对产品的形象有严重的影响；WEB页面一定要人性化，直观，易懂，符合一般人的操作习惯，色彩方面除了符合产品特色以外，还要给客户“亲和”的感觉或者一种“高贵”的感觉，好功能配好界面，希望在以后的WEB界面起码能给我们自己满意的直观印象。关于WEB页面的一些建议如下：
部分页面布局不合理，总感觉页面不是很饱满
弹出的页面不能移动，这个问题希望以后能解决
表格说明和表头之间希望能有一个更好的方式显示
页面的提示信息希望能准确，明确
弹出的提示框的有的比例不合适
每个htm页面中的title应该表明页面的功能
2.需求说明书
需求说明书可以检验软件的完成性，是软件测试的标准，只有需求说明书详细的说明每个输入与动作，这样测试才可以有标准可衡量，这次的需求说明书的每个操作动作基本详细明了，唯一不足的就是每个输入动作的要求，比如能明确Target名称，CHAP用户名称输入位数的要求，这样测试就更加有依据！具体建议如下：
详细叙述每一个输入的要求，比如位数和字符要求
系统界面弹出提示的格式在需求中要明确
需求中要明确比较生疏或者特殊的使用方法，包括软件的限制,比如255.255.255.255的使用，还有一些危险性的操作等等
需求明确后，做一个项目的原型，这样可以进一步确认需求，这样可以为项目的后续阶段节约大量的时间和人力
3.测试用例
在这个测试阶段完成后，体会最大的是测试用例在测试阶段的过程中的使用率，就我自己来说，基本上没有按照测试用例依次执行，只是在考虑到测试的全面性是才会参考的测试用例；这次的测试用例还有一部分无效，比如一些页面的显示问题，完全可以没有；测试用例写的不好，还有一方面就是写的简单，仅仅测试了一些基本的功能，测试用例之间的相互性不是很强，也就是测试用例的综合性不强，这样就漏掉了系统中可能存在的BUG；当初写测试用例的初衷是每个用例要细化的每个动作，尽量去覆盖程序的每个动作，但是这样却忽略了测试的目的，测试的目的是为了找到程序的中的BUG,而不是跑程序的每个动作或者流程，至于以后怎么写还得需要大家的能给出一个良好的意见，以便于进一步完善测试用例。具体的建议如下：
测试用例的格式的改善，增强测试时的执行效率
加强测试用例的综合性
坚决去掉无效的测试用例
测试用例语言要通俗易懂
总之，在项目的测试阶段，已经很尽力，很用心；就我个人感觉而言，仍然不能定位系统潜在的BUG到底还有多少，会不会影响到产品的质量，依然还是个未知数，不过我想jingli会有一个很好的把握！预祝项目成功结束！
以上纯出个人的小小建议，如果不对之处，请大家给予指教，本人一定虚心向咱们的每个开发人员认真学习！
感谢大家在工作中一直的支持！◎
[ 本帖最后由 ◎了了 于 2007-10-30 16:33 编辑 ] 测试过后，没有发现多少bug并不是件值得庆幸的事情，很有可能是测试工程师水平有限，而发现不了很有价值或者隐藏着的bug 能够最终满足客户的需求就可以了额,发现bug的数量多少并没多大的关系哦 是不是应该说，软件在经过测试后发现的bug越少越好，不过前提是软件要能令用户用舒心，满意。客户是上帝吗！o(∩_∩)o... 没办法有时候还是要以BUG得多少来判断这个软件的质量！ BUG的数量是不能充分说明问题的，
还是要看发现的BUG的严重等级的吧 对
看发现的BUG的严重等级
页:
[1]
