csdn博客：http://blog.csdn.net/qwentest
一个关于争议问题的绝妙言论(一)
上一篇 / 下一篇 2011-08-17 16:58:10 / 个人分类：Bug那些事儿
开发A added a comment - 28/七月/11 01:59 下午 - edited
进入"审核－xx"表页面，可以看到查询范围勾选的是：临时库
数据也是从临时库查询出来的，在此页面，删除临时库数据，Of course是直接删除。
拥有审核权限的用户，审核时，可以审核通过、不通过，可以查看、修改数据，当删除时，新增记录删除是删除新增数据，历史变更发起项的删除是删除这个发起项，相当于发起用户自己在审核流程中列表里删除这个发起项，拥有审核权限的用户有这个权利删除这个发起项，这个操作也可称为撤销历史变更的发起。
[ 链接地址 | 编辑 | 删除 | ? 隐藏 ]
测试B added a comment - 28/七月/11 04:08 下午 - edited
个人认为，审核不通过功能已经包括了"撤销历史变更的发起"，在这先说明下我对审核不通过功能的理解，可以体现在两种情况：
1.录入人员对历史数据的修改，审核人认为修改后的数据不符合要求，这时，审核人将该种情况置为"审核不通过"
2.录入人员对历史数据的修改，审核人认为不需要修改该数据，之时，审核人想要对该数据进行"撤销历史变更的发起"，审核人填写相应的"审核意见"，将该种情况置为"审核不通过"。这时，录入人员可以在"未审核通过列表"中对该数据进行删除，已完成"撤销历史变更的发起"整个流程。也就相当于你说的"通过删除按钮来撤销历史变更的发起"这个功能。
最后，个人仍坚持最初的【解决提议】
[ 链接地址 | 编辑 | 删除 | ? 隐藏 ]
开发A added a comment - 28/七月/11 04:56 下午
首先，要明确一点，审核人进行审核时，首选操作是审核通过或不通过，特殊情况需要对数据进行修改，那么会将数据修改后审核通过让数据进入历史库。
于是，当审核人经判断当前提交的历史变更记录是不需要变更的，首选操作是审核这条记录为审核不通过，填写审核意见后将这条记录退回给发起人。
删除按钮的作用是当记录不是历史变更项，而是新增的数据，审核人认为不是有效数据需要删除，系统提供这个功能，至于使用删除按钮删除历史变更发起项，按记录实际存储的位置(临时表)、当前操作模式(查询范围：临时)和业务逻辑(临时库数据删除为真删除)，该记录将直接删除，相当于删除历史变更的发起项。
另外，根据Bug单所描述的
【期待结果】
step 1： 该记录在"待审核列表"中，"提交类型"为"删除"
What is 这个期待结果的理由和逻辑？审核人对发起项进行删除操作，如果系统不删除这条数据，而是把修改类型改为"删除"，继续由审核人自己再审核，删除了发起项又给自己再审核？
[ 链接地址 | 编辑 | 删除 | ? 隐藏 ]
测试B added a comment - 28/七月/11 05:44 下午 - edited
审核人对发起项进行删除操作，把修改类型改为"删除"。----这种情况是用户目前所需要的，至少录入部门经理需要。
至于使用删除按钮的删除功能，可以细化为两个功能：
1.对临时库新增记录的真删除
2.对历史变更发起项的"提交类型"的更改，即将原先的"提交类型"改为"删除"
至于如何去区分是"临时库新增记录"还是"历史变更发起项"，可以给临时数据与历史数据增加一个标识符来区分。
至于"删除了发起项又给自己再审核"，其实，与目前的功能"修改了发起项再提交给自己审核"，这两者没有什么不同。
[ 链接地址 | 编辑 | 删除 | ? 隐藏 ]
开发A added a comment - 29/七月/11 10:39 上午
在审核时，面对的历史数据不是历史数据本身，而是历史数据的副本、审核项、发起项，删除按钮就是删除审核项，按钮文本不带"..."，指示不会弹出删除对话框，也不会有删除原因。
既然进入了审核模块，就是对数据进行审核操作，而要对历史数据进行删除，必须到"通用录入"模块里勾选查询范围为历史库再进行需要的操作。在那里提供了必需的权限验证和必需的对话框。
审核模块只做审核相关的事情，只包含审核相关的功能，不提供对历史数据的删除。
在审核模块中想对历史数据删除，就好比去到足球场而想要可以打蓝球的场地。
[ 链接地址 | 编辑 | 删除 | ? 隐藏 ]
测试B added a comment - 09/八月/11 12:14 下午 - edited
就目前已有的功能：在"审核-xx表"对提交上来的历史数据进行修改。这算不算在篮球场上，却想着踢足球？貌似现在也的确有很多足球爱好者在篮球场上踢足球。
坚持该批注的说法：测试B added a comment - 28/七月/11 05:44 下午
[ 链接地址 | 编辑 | 删除 | ? 隐藏 ]
开发A added a comment - 10/八月/11 10:53 上午 - edited
修改的不是历史数据，同样是发起项。需求调研中客户明确表明在审核时需要可以修改数据，所以录入系统在审核之前先跳转到查看数据窗体提供审核项的查看和修改功能。
蓝球场上当然可以踢足球，足球场上同样也可以打蓝球，只是草地上球弹不起来也没有蓝球板，只在于你愿不愿意而已。
既然你想要在足球场上打蓝球，建议你周末带个蓝球去梅林中学的足球场，然后发现在草地上球弹不起来，于是你跑到校长办公室，
"足球场咋打不了蓝球"
校长："足球场只提供踢足球的环境，蓝球场就在足球场旁边30米处，你可以到那里打"
"足球场应该要同时提供打蓝球的环境啊，我坚持应该要提供!"
...
Well,你将用实践来证明足球场应该提供打蓝球的功能，这是很令人激动的，我们会在Jira上等待你的好消息。
客户没有需求在审核时同时可以删除历史数据。不要把主观的意愿加入中心库系统。业务不了解建议多看需求文档，开发不会再次解释足球场为什么不提供打蓝球的功能，也不会解释软件模块功能职责的单一性，软件工程设计思想不熟悉建议多了解这方面的知识。
[ 链接地址 | 编辑 | 删除 | ? 隐藏 ]
测试B added a comment - 10/八月/11 11:06 上午 - edited
说到需求，该批注已明确说明这是一个用户需求：测试B added a comment - 28/七月/11 05:44 下午
用户对这个的需求的说明图，前几天也发到你RTX上了，如果你没注意到RTX信息，或者根本看不见，接收不到信息，哦，接收不到，或许是在传输过程中丢包了，也没关系，怪马化腾的失误。
用户要求在足球场上建个篮球架，对足球场的草地改进成可弹起篮球，这也的确为难你了。我只是个传达人，调解员，也可以说是监工，不是监xx工，是监施工，至于结果要不要改进足球场呢，这个需求与技术难题还是有待你们足球场建设施工队与用户直接沟通。
还有，照你上面的第一句话得意思：可以在"审核-xx表"通过修改发起项来达到对历史数据的修改。那么同样也可以在"审核-xx表"通过删除发起项来达到对历史数据的删除（至于怎么删除，且看该批注的建议：测试B added a comment - 28/七月/11 05:44 下午），毫无疑问这两者都是在足球场上打篮球，此篮球非彼篮球？我只知道世界上只有一种篮球，至于此篮球是否非彼篮球？对于这一点，对于你的施工技能，我是不会吝啬我的赞美之词的。
[ 链接地址 | 编辑 | 删除 | ? 隐藏 ]
开发A added a comment - 16/八月/11 11:53 上午
对于指定不是缺陷的内容，并且带有回复批注时，不需要重新开启Bug单。
如果开发回复不能理解，与你的小组讨论沟通寻找帮助；
如果对业务理解不全面，多看需求文档和加强理解能力；
如果仍认为问题是个缺陷，把此类问题最终汇总为文档，找时间和最终用户，分析师，开发等一同讨论，而不是又重新开启Bug单。
Jira的使用不熟悉去看Jira帮助，开发表示不愿意再次看到类似下面的问题，因为已经很多次的出现，严重影响了开发的时间：
1.Bug单提交问题描述随意，问题描述与实际偏差太大，操作步骤不能重现问题，应该附加截图和附件的没有附加
2.Bug单类型应该为建议的提交为缺陷
3.测试方法不专业使得多次提交不是缺陷的Bug单，简单问题仍需要开发指示测试方法
4.对需求了解不够，导致不能测试到系统重要分支和提交与需求不一致的Bug单
[ 链接地址 | 编辑 | 删除 | ? 隐藏 ]
测试B added a comment - 16/八月/11 04:33 下午 - edited
之所以需要测试，是因为开发无可避免地有缺陷，因此，请勿以开发的思维来评判测试的思维。
1.对于重现步骤中需要注意的细节的问题，测试会不惜笔墨详细描述，这是为了让开发能一次性最大概率地重现问题，最终目的是为了节约开发时间。至于bug详细描述的【问题提议】这部分内容，是测试对当前bug的一个分析，同样一个目的也是为了帮助开发更好地更快去分析bug引发的渊源，去更准确地定位bug的根源。若开发不需要测试分析，也可以避开不看该部分内容，完全不影响开发去理解去分析bug，请明晰。对于需要截图的bug，测试从未吝啬ctrl+shift+x
2.对于是缺陷，或是建议，缺陷有分功能缺陷与业务逻辑缺陷，并非非功能缺陷就不是缺陷，请明晰。对于某些问题是缺陷还是建议，没有一个明确的界定，更加开发与测试的思考问题的方式不同，理解也不同，因此同样，勿以开发的思维来强加于测试的思维。
3.提交不是缺陷的bug单，是曾经发生过，有些的确是测试对于一些细节不够严谨，有些属于其他系统数据变更或者重现概率较低的问题，没有开发说的那么严重。
4.请列明没有测试到的系统重要分支的问题，之所以提交与需求不一致的bug单，是因为测试在测试过程中发现用户在提出需求时可能没有考虑到的一些细节问题，这些都属于测试过程中不可避免的，也是测试的一个不可或缺的部分，发现该类问题并提出来，是测试的职责。
欲想深入理解测试，不妨勇敢迈进测试这个行业，衷心建议：勿以足球的眼光来审视篮球。对于该问题，测试不想再无谓地浪费时间。
进入"审核－xx"表页面，可以看到查询范围勾选的是：临时库
数据也是从临时库查询出来的，在此页面，删除临时库数据，Of course是直接删除。
拥有审核权限的用户，审核时，可以审核通过、不通过，可以查看、修改数据，当删除时，新增记录删除是删除新增数据，历史变更发起项的删除是删除这个发起项，相当于发起用户自己在审核流程中列表里删除这个发起项，拥有审核权限的用户有这个权利删除这个发起项，这个操作也可称为撤销历史变更的发起。
[ 链接地址 | 编辑 | 删除 | ? 隐藏 ]
测试B added a comment - 28/七月/11 04:08 下午 - edited
个人认为，审核不通过功能已经包括了"撤销历史变更的发起"，在这先说明下我对审核不通过功能的理解，可以体现在两种情况：
1.录入人员对历史数据的修改，审核人认为修改后的数据不符合要求，这时，审核人将该种情况置为"审核不通过"
2.录入人员对历史数据的修改，审核人认为不需要修改该数据，之时，审核人想要对该数据进行"撤销历史变更的发起"，审核人填写相应的"审核意见"，将该种情况置为"审核不通过"。这时，录入人员可以在"未审核通过列表"中对该数据进行删除，已完成"撤销历史变更的发起"整个流程。也就相当于你说的"通过删除按钮来撤销历史变更的发起"这个功能。
最后，个人仍坚持最初的【解决提议】
[ 链接地址 | 编辑 | 删除 | ? 隐藏 ]
开发A added a comment - 28/七月/11 04:56 下午
首先，要明确一点，审核人进行审核时，首选操作是审核通过或不通过，特殊情况需要对数据进行修改，那么会将数据修改后审核通过让数据进入历史库。
于是，当审核人经判断当前提交的历史变更记录是不需要变更的，首选操作是审核这条记录为审核不通过，填写审核意见后将这条记录退回给发起人。
删除按钮的作用是当记录不是历史变更项，而是新增的数据，审核人认为不是有效数据需要删除，系统提供这个功能，至于使用删除按钮删除历史变更发起项，按记录实际存储的位置(临时表)、当前操作模式(查询范围：临时)和业务逻辑(临时库数据删除为真删除)，该记录将直接删除，相当于删除历史变更的发起项。
另外，根据Bug单所描述的
【期待结果】
step 1： 该记录在"待审核列表"中，"提交类型"为"删除"
What is 这个期待结果的理由和逻辑？审核人对发起项进行删除操作，如果系统不删除这条数据，而是把修改类型改为"删除"，继续由审核人自己再审核，删除了发起项又给自己再审核？
[ 链接地址 | 编辑 | 删除 | ? 隐藏 ]
测试B added a comment - 28/七月/11 05:44 下午 - edited
审核人对发起项进行删除操作，把修改类型改为"删除"。----这种情况是用户目前所需要的，至少录入部门经理需要。
至于使用删除按钮的删除功能，可以细化为两个功能：
1.对临时库新增记录的真删除
2.对历史变更发起项的"提交类型"的更改，即将原先的"提交类型"改为"删除"
至于如何去区分是"临时库新增记录"还是"历史变更发起项"，可以给临时数据与历史数据增加一个标识符来区分。
至于"删除了发起项又给自己再审核"，其实，与目前的功能"修改了发起项再提交给自己审核"，这两者没有什么不同。
[ 链接地址 | 编辑 | 删除 | ? 隐藏 ]
开发A added a comment - 29/七月/11 10:39 上午
在审核时，面对的历史数据不是历史数据本身，而是历史数据的副本、审核项、发起项，删除按钮就是删除审核项，按钮文本不带"..."，指示不会弹出删除对话框，也不会有删除原因。
既然进入了审核模块，就是对数据进行审核操作，而要对历史数据进行删除，必须到"通用录入"模块里勾选查询范围为历史库再进行需要的操作。在那里提供了必需的权限验证和必需的对话框。
审核模块只做审核相关的事情，只包含审核相关的功能，不提供对历史数据的删除。
在审核模块中想对历史数据删除，就好比去到足球场而想要可以打蓝球的场地。
[ 链接地址 | 编辑 | 删除 | ? 隐藏 ]
测试B added a comment - 09/八月/11 12:14 下午 - edited
就目前已有的功能：在"审核-xx表"对提交上来的历史数据进行修改。这算不算在篮球场上，却想着踢足球？貌似现在也的确有很多足球爱好者在篮球场上踢足球。
坚持该批注的说法：测试B added a comment - 28/七月/11 05:44 下午
[ 链接地址 | 编辑 | 删除 | ? 隐藏 ]
开发A added a comment - 10/八月/11 10:53 上午 - edited
修改的不是历史数据，同样是发起项。需求调研中客户明确表明在审核时需要可以修改数据，所以录入系统在审核之前先跳转到查看数据窗体提供审核项的查看和修改功能。
蓝球场上当然可以踢足球，足球场上同样也可以打蓝球，只是草地上球弹不起来也没有蓝球板，只在于你愿不愿意而已。
既然你想要在足球场上打蓝球，建议你周末带个蓝球去梅林中学的足球场，然后发现在草地上球弹不起来，于是你跑到校长办公室，
"足球场咋打不了蓝球"
校长："足球场只提供踢足球的环境，蓝球场就在足球场旁边30米处，你可以到那里打"
"足球场应该要同时提供打蓝球的环境啊，我坚持应该要提供!"
...
Well,你将用实践来证明足球场应该提供打蓝球的功能，这是很令人激动的，我们会在Jira上等待你的好消息。
客户没有需求在审核时同时可以删除历史数据。不要把主观的意愿加入中心库系统。业务不了解建议多看需求文档，开发不会再次解释足球场为什么不提供打蓝球的功能，也不会解释软件模块功能职责的单一性，软件工程设计思想不熟悉建议多了解这方面的知识。
[ 链接地址 | 编辑 | 删除 | ? 隐藏 ]
测试B added a comment - 10/八月/11 11:06 上午 - edited
说到需求，该批注已明确说明这是一个用户需求：测试B added a comment - 28/七月/11 05:44 下午
用户对这个的需求的说明图，前几天也发到你RTX上了，如果你没注意到RTX信息，或者根本看不见，接收不到信息，哦，接收不到，或许是在传输过程中丢包了，也没关系，怪马化腾的失误。
用户要求在足球场上建个篮球架，对足球场的草地改进成可弹起篮球，这也的确为难你了。我只是个传达人，调解员，也可以说是监工，不是监xx工，是监施工，至于结果要不要改进足球场呢，这个需求与技术难题还是有待你们足球场建设施工队与用户直接沟通。
还有，照你上面的第一句话得意思：可以在"审核-xx表"通过修改发起项来达到对历史数据的修改。那么同样也可以在"审核-xx表"通过删除发起项来达到对历史数据的删除（至于怎么删除，且看该批注的建议：测试B added a comment - 28/七月/11 05:44 下午），毫无疑问这两者都是在足球场上打篮球，此篮球非彼篮球？我只知道世界上只有一种篮球，至于此篮球是否非彼篮球？对于这一点，对于你的施工技能，我是不会吝啬我的赞美之词的。
[ 链接地址 | 编辑 | 删除 | ? 隐藏 ]
开发A added a comment - 16/八月/11 11:53 上午
对于指定不是缺陷的内容，并且带有回复批注时，不需要重新开启Bug单。
如果开发回复不能理解，与你的小组讨论沟通寻找帮助；
如果对业务理解不全面，多看需求文档和加强理解能力；
如果仍认为问题是个缺陷，把此类问题最终汇总为文档，找时间和最终用户，分析师，开发等一同讨论，而不是又重新开启Bug单。
Jira的使用不熟悉去看Jira帮助，开发表示不愿意再次看到类似下面的问题，因为已经很多次的出现，严重影响了开发的时间：
1.Bug单提交问题描述随意，问题描述与实际偏差太大，操作步骤不能重现问题，应该附加截图和附件的没有附加
2.Bug单类型应该为建议的提交为缺陷
3.测试方法不专业使得多次提交不是缺陷的Bug单，简单问题仍需要开发指示测试方法
4.对需求了解不够，导致不能测试到系统重要分支和提交与需求不一致的Bug单
[ 链接地址 | 编辑 | 删除 | ? 隐藏 ]
测试B added a comment - 16/八月/11 04:33 下午 - edited
之所以需要测试，是因为开发无可避免地有缺陷，因此，请勿以开发的思维来评判测试的思维。
1.对于重现步骤中需要注意的细节的问题，测试会不惜笔墨详细描述，这是为了让开发能一次性最大概率地重现问题，最终目的是为了节约开发时间。至于bug详细描述的【问题提议】这部分内容，是测试对当前bug的一个分析，同样一个目的也是为了帮助开发更好地更快去分析bug引发的渊源，去更准确地定位bug的根源。若开发不需要测试分析，也可以避开不看该部分内容，完全不影响开发去理解去分析bug，请明晰。对于需要截图的bug，测试从未吝啬ctrl+shift+x
2.对于是缺陷，或是建议，缺陷有分功能缺陷与业务逻辑缺陷，并非非功能缺陷就不是缺陷，请明晰。对于某些问题是缺陷还是建议，没有一个明确的界定，更加开发与测试的思考问题的方式不同，理解也不同，因此同样，勿以开发的思维来强加于测试的思维。
3.提交不是缺陷的bug单，是曾经发生过，有些的确是测试对于一些细节不够严谨，有些属于其他系统数据变更或者重现概率较低的问题，没有开发说的那么严重。
4.请列明没有测试到的系统重要分支的问题，之所以提交与需求不一致的bug单，是因为测试在测试过程中发现用户在提出需求时可能没有考虑到的一些细节问题，这些都属于测试过程中不可避免的，也是测试的一个不可或缺的部分，发现该类问题并提出来，是测试的职责。
欲想深入理解测试，不妨勇敢迈进测试这个行业，衷心建议：勿以足球的眼光来审视篮球。对于该问题，测试不想再无谓地浪费时间。
TAG:
标题搜索
日历
|
|||||||||
| 日 | 一 | 二 | 三 | 四 | 五 | 六 | |||
| 1 | 2 | 3 | 4 | ||||||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 | |||
| 12 | 13 | 14 | 15 | 16 | 17 | 18 | |||
| 19 | 20 | 21 | 22 | 23 | 24 | 25 | |||
| 26 | 27 | 28 | 29 | 30 | 31 | ||||
我的存档
数据统计
- 访问量: 55411
- 日志数: 104
- 建立时间: 2009-09-10
- 更新时间: 2017-04-30
