如何控制开发交付版本的质量想法一

上一篇 / 下一篇  2012-06-04 20:23:00

查看( 1444 ) / 评论( 2 ) / 评分( 0 / 0 )
最近几天，都在想如何控制开发人员交付给我们测试人员的版本质量。这个我觉得不是很简单。
从软件工程上来说，开发人员在提交测试部门版本时应该附带单元测试报告、集成测试报告。这是之前开发人员很少做的。但我在想，如果让他们做了，只能表面上做，版本的质量应该不会得到很好的提高。那我是不是限制版本的打回次数，或者加入一道流程，就是demo版本的冒烟测试。冒烟测试通过了再进行系统测试。二次冒烟测试，如果主要功能点ok就进入系统测试。
其实不管冒烟测试、还是集成测试报告，这些都是逼开发人员自己去测试自己所编写的程序，我为何叫程序测试，我觉得开发人员没有写文档，就还只是提交给我程序，没有提交给我版本。

写到这我就在标题中加了三个字“想法一”，我觉得以上只是我今天的点滴想法，再想时再补充成想法二比较连贯。

收藏 举报

TAG:

QBOSS的个人空间 引用 删除 qjf   /   2012-07-04 22:08:52
对的，有个接收版本的过程，但这个标准现在我可能定的要求严格了，集成测试要消灭A、B级BUG，系统测试的时间和质量才可控，目前在实施中。
原帖由菜鸟@大虾于2012-06-07 15:00:03发表
个人觉得：控制开发提交的给测试人员的版本质量，在测试人员接收测试之前，可以控制下冒烟测试通过的标准.
菜鸟@大虾的个人空间 引用 删除 菜鸟@大虾   /   2012-06-07 15:00:03
个人觉得：控制开发提交的给测试人员的版本质量，在测试人员接收测试之前，可以控制下冒烟测试通过的标准，记得原来在阿里巴巴的时候，搞了一个试点：冒烟测试case通过率要高于90%，并且，冒烟点测试用的case是测试人员随即选取的，事前并不告诉开发人员，这样以来，在软件通过冒烟测试 测试人员正式接手测试的时候  版本的质量 一定是非常不错的。。大家一起讨论下哈  

当然。。每个团队都有自己的风格  适合自己的才是最好的
 

评分：0

我来说两句

qjf

qjf

差不多，这个词语很多时候想用，但是却差很多。人生就是在差不多和差得多之间轮回。

日历

« 2024-05-02  
日 一 二 三 四 五 六
   1234
567891011
12131415161718
19202122232425
262728293031 

数据统计

  • 访问量: 11941
  • 日志数: 23
  • 建立时间: 2008-08-16
  • 更新时间: 2016-08-31

RSS订阅

Open Toolbar