51Testing软件测试论坛

标题: 软件为产品（区别于项目）的话该如何测试？希望高手来讨论！ [打印本页]

作者: 译风 时间: 2008-2-18 21:31
标题: 软件为产品（区别于项目）的话该如何测试？希望高手来讨论！
公司是做产品化的项目的，而我进公司的时候，这个产品已经有8年的历史了，之前是从来没有测试人员的。
每天个性化修改的问题一大堆，6，7个开发人员每天就是在进行个性化的修改。软件升级也是每天频繁的升级更新。
所以做为测试部门来说，测试的效果根本就看不出来，一方面，产品本身问题一大堆，另一方面，每天都在进行软件功能的
新增，却测试的不及时全面（人手不够，测试不规范，业务不熟悉）。
针对这样一个永无止境的个性化修改，系统太复杂，根本不等我们测试出一个稳定版本，就有很多新的功能增加
我们的测试人员该如何测试？
目前的设想是，出一个相对稳定的版本，然后开发人员在他们另一个版本上继续进行个性化修改，而测试人员测试的
是相对稳定的版本，软件的每天更新变为半个月更新一次（这样的时间对于测试来说根本也是不可能在半个月内测试出
一个稳定版本的）。这样的做法，最终有一天也会因为来不及而作罢的。
希望高手们能给点建议。。。。

作者: Nio 时间: 2008-2-19 12:41
给点建议：
1、版本控制首先要做起来，不能说BUILD就BUILD。
2、进行个性化的修改可以，得问是由谁要求与首肯的，有人批准的就好办，修改完了，得拿来测试，没有测试过的（包括没来得及测的），偶们就不会承担一丁点的责任。列个清单出来，那些是经过测试的，那些是没有经过测试的。没人批准RD就改，你不必测试了，把情况记录下来往上报好了，不关测试人员的事。
3、人手不够，得有依据，写个工作量评估报告什么的，往上报好了。
4、测试不规范，有意见提出来，如果自个是老大，想办法规范起来。
5、业务不熟悉，呵呵测试人员自身问题，尽快进行相关培训吧。
6、产品问题一堆，不能这么笼统的说，列个清单报告啥的吧，这样测试人员也尽到了责任。
7、RD出新的版本，一定要问清楚做了什么样的变更，测不测是一回事，了不了解是一回事。得记录在案。
8、测试的进度不能跟上开发的进度要尽可能早的向上报，要列出客观原因，有条件的给个解决方法等。

一句话，问题多是多，还得一个一个的来解决，不要急。呵呵。

作者: archonwang 时间: 2008-2-21 01:12
实际上很难想象一个产品历经8年，仍然还有如此众多的问题，可以预见的是产品在研发过程中，其版本管理和配置管理的能力一定很弱。建议找人控制这一块。频繁更新不利于产品质量稳定。反而会有损质量——尽管会修复一些bug，但可能会带来更多bug。

作者: muler 时间: 2008-2-22 17:19
1，测试不及时不全面就是测试人员的事：一方面是人手不够；一方面是测试人员的水平不够。
2，测试效果不明显：是测试人员没有发现很容易出现的Bug，还是发现了而是开发人员没有来的及修该版本有更新了，第一种原因就是我们本身的事，针对第二种情况个人认为可以采取：对一些常用的功能或者一些已经固定不变的功能进行详细的测试（应该这部分已经bug不多了）对于经常更新或者添加的功能简单的进行测试（半个月更新一次，也更新的台快了），最重要的是在发现bug的时候及时地与开发人员沟通，确保能得到及时的修改，保证回归测试。
3，对测试时间的控制：更新速度太快，这样就导致测试的覆盖面减小，保证测试用例的质量，制定详细的时间表，提高测试的效率。

最后就是，其实有稳定的测试用例半个月的时间是完全可以进行一轮完整的测试。

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)