一般来说，不要陷入认为这只是 IT 人员的问题的常见陷阱。显然，您不希望代码中出现错误，并且有许多工具/流程可以帮助解决这一问题 - QA 实际上是一个更大范围的流程。正如 DBA_Alex 上面提到的，您需要知道您正在使用您的软件为企业解决什么问题，并且最终需要企业机构参与来回答该问题。确保您的最终解决方案包括来自 IT 和业务的人员...
In general, dont fall into the common trap of thinking this is an IT-staff only problem. Clearly you dont want bugs in your code, and there are any number of tools/processes that help with that - QA is really a larger scope process. As mentioned above by DBA_Alex, you need to know what problem you are solving for the business with your software, and at the end of the day, business bodies need to be involved to answer that question. Make sure your end solution includes people from both IT and business...
为了可重复性和便于管理，由 Hudson 或 Cruise Control 等构建服务器自动运行从源代码控制系统提取的代码的单元测试是一个好主意。它还将为“权力”提供一些指标，以便您可以展示代码的构建、测试等方式。
最终，这取决于关心自己正在做的事情的好人。
You could try reading blogs of "the great and the good", people like Martin Fowler on hi 'Bliki' and Robert Martin on Uncle Bob's Blatherings ... and Joel Spolsky's now defunct Joel On Software. All good for opinions on what quality is about.
Currently using java and tools such as Macker and Findbugs to check for code correctness and adherence to guidelines.
For repeatability and to please management, unit tests run automatically by a build server such as Hudson or Cruise Control on code extracted from a source control system is a good idea. It will also give the 'powers that be' some metrics so you can show how your code building, testing, etc.
Ultimately though it just comes down to good people who care about what they're doing.
It's all about testing, testing, testing. There are many tools that can help you achieve this, such as unit testing frameworks, code analyzers, memory profilers, etc. The tools you would use depend on the programming language and development platform your company uses for its software.
As the others have said, testing is an essential part of software QA. But I'm surprised that no one has yet mentioned code reviews. Take a look how you can integrate peer code reviews into your development process; it's a great way to improve code quality and share knowledge throughout the team. The earlier you detect a problem, the easier and cheaper it is to fix it, so consider a code review for every source code change.
If you want an excellent and thorough introduction to QA, read Parts II and V of Code Complete by Steve McConnell. In fact, read all of it - it provides practical examples of how to improve code quality, and metrics (which you can show to management) that explain the benefits of different QA techniques.
The chapters that I mention include topics such as:
Design concepts and practices to improve quality
High-quality routines
Defensive programming
Pseudocode programming
Techniques for improving Software Quality (including an assessment of relative effectiveness)
When to do Quality Assurance
Collaborative construction (including pair programming, code inspections)
It's also about the validation process that is used. You can test your software all day long but if you don't know what it's intended to do and what the expected result is you could be testing for the wrong thing altogether. There's a real good book that lays out a solid framework to start with (that'll also cover any ISO requirements if your company is ISO certified): http://www.amazon.com/Computer-System-Management-Validation-Cycle/dp/1932828095
As Bernard says above, you need to do testing. If you are developing in Java, you can use JUnit (NUnit works similarly in .Net). Unit testing is just the beginning though, you might look at code coverage tools to give you an indication of how complete your unit testing is (open source tools EMMA and Cobertura provide this for Java). You might also use hudson to automatically execute these tests whenever a change is checked into your source tree (hudson will give you an indication of how stable your developments are, lots of fluctuations in test case pass rates indicate that you're making lots of breaking changes for example).
After that, you could look at something like Findbugs for Java to spot dodgy practices. If you are using Eclipse for Java development you can get the metrics plugin to perform various other pieces of analysis on your code but you need to know what these metrics actually indicate.
Ultimately, the quality of your product will be defined by whether you can reliably introduce changes that achieve their aim without causing regressions. The tools above are just the beginning, it takes a long time to become good at testing (I'm not there myself) but if you introduce the tools and practices to your organisation you can work on it from there.
发布评论
评论（6）
一般来说，不要陷入认为这只是 IT 人员的问题的常见陷阱。显然，您不希望代码中出现错误，并且有许多工具/流程可以帮助解决这一问题 - QA 实际上是一个更大范围的流程。正如 DBA_Alex 上面提到的，您需要知道您正在使用您的软件为企业解决什么问题，并且最终需要企业机构参与来回答该问题。确保您的最终解决方案包括来自 IT 和业务的人员...
In general, dont fall into the common trap of thinking this is an IT-staff only problem. Clearly you dont want bugs in your code, and there are any number of tools/processes that help with that - QA is really a larger scope process. As mentioned above by DBA_Alex, you need to know what problem you are solving for the business with your software, and at the end of the day, business bodies need to be involved to answer that question. Make sure your end solution includes people from both IT and business...
你可以尝试阅读“伟大而善良”的博客，比如 Martin Fowler 的 hi 'Bliki' 和 Robert Martin 的 Uncle Bob's Blatherings ……以及 Joel Spolsky 现已不复存在的 Joel On Software。对于质量的看法，一切都很好。
目前使用 java 和 Macker 和 Findbugs 等工具来检查代码的正确性和对准则的遵守情况。
为了可重复性和便于管理，由 Hudson 或 Cruise Control 等构建服务器自动运行从源代码控制系统提取的代码的单元测试是一个好主意。它还将为“权力”提供一些指标，以便您可以展示代码的构建、测试等方式。
最终，这取决于关心自己正在做的事情的好人。
You could try reading blogs of "the great and the good", people like Martin Fowler on hi 'Bliki' and Robert Martin on Uncle Bob's Blatherings ... and Joel Spolsky's now defunct Joel On Software. All good for opinions on what quality is about.
Currently using java and tools such as Macker and Findbugs to check for code correctness and adherence to guidelines.
For repeatability and to please management, unit tests run automatically by a build server such as Hudson or Cruise Control on code extracted from a source control system is a good idea. It will also give the 'powers that be' some metrics so you can show how your code building, testing, etc.
Ultimately though it just comes down to good people who care about what they're doing.
这都是关于测试、测试、测试。有许多工具可以帮助您实现这一目标，例如单元测试框架、代码分析器、内存分析器等。您将使用的工具取决于您公司用于其软件的编程语言和开发平台。
It's all about testing, testing, testing. There are many tools that can help you achieve this, such as unit testing frameworks, code analyzers, memory profilers, etc. The tools you would use depend on the programming language and development platform your company uses for its software.
正如其他人所说，测试是软件质量保证的重要组成部分。但令我惊讶的是，还没有人提到代码审查。了解如何将同行代码审查集成到您的开发过程中；这是提高代码质量和在整个团队中共享知识的好方法。越早发现问题，修复它就越容易、成本也就越低，因此请考虑对每个源代码更改进行代码审查。
如果您想要对 QA 进行精彩而全面的介绍，请阅读 Steve McConnell 撰写的 Code Complete 的第二部分和第五部分。事实上，请阅读所有内容 - 它提供了如何提高代码质量的实际示例，以及解释不同 QA 技术优势的指标（您可以向管理层展示）。
我提到的章节包括以下主题：
引用麦康奈尔的软件质量一般原则：
As the others have said, testing is an essential part of software QA. But I'm surprised that no one has yet mentioned code reviews. Take a look how you can integrate peer code reviews into your development process; it's a great way to improve code quality and share knowledge throughout the team. The earlier you detect a problem, the easier and cheaper it is to fix it, so consider a code review for every source code change.
If you want an excellent and thorough introduction to QA, read Parts II and V of Code Complete by Steve McConnell. In fact, read all of it - it provides practical examples of how to improve code quality, and metrics (which you can show to management) that explain the benefits of different QA techniques.
The chapters that I mention include topics such as:
To quote McConnell's General Principle of Software Quality:
它还与所使用的验证过程有关。您可以整天测试您的软件，但如果您不知道它的用途和预期结果是什么，您可能会完全测试错误的东西。有一本真正的好书，它列出了一个坚实的框架（如果您的公司通过了 ISO 认证，它还将涵盖任何 ISO 要求）：http://www.amazon.com/Computer-System-Management-Validation-Cycle/dp/1932828095
It's also about the validation process that is used. You can test your software all day long but if you don't know what it's intended to do and what the expected result is you could be testing for the wrong thing altogether. There's a real good book that lays out a solid framework to start with (that'll also cover any ISO requirements if your company is ISO certified): http://www.amazon.com/Computer-System-Management-Validation-Cycle/dp/1932828095
正如伯纳德上面所说，你需要进行测试。如果您使用 Java 进行开发，则可以使用 JUnit（NUnit 在 .Net 中的工作方式类似）。不过，单元测试只是开始，您可以查看代码覆盖率工具，以了解单元测试的完整性（开源工具 EMMA 和 Cobertura 为 Java 提供了此工具）。每当将更改签入源树时，您也可以使用 hudson 自动执行这些测试（hudson 会告诉您您的开发有多稳定，测试用例通过率的大量波动表明您正在进行大量破坏例如更改）。
之后，您可以查看 Findbugs for Java 之类的工具来发现狡猾的做法。如果您使用 Eclipse 进行 Java 开发，您可以获取指标插件来对代码执行各种其他分析，但您需要知道这些指标实际表明什么。
最终，产品的质量将取决于您是否能够可靠地引入实现其目标而不导致回归的更改。上面的工具只是一个开始，需要很长时间才能擅长测试（我自己并不在那里），但是如果您向您的组织引入这些工具和实践，您就可以从那里开始工作。
As Bernard says above, you need to do testing. If you are developing in Java, you can use JUnit (NUnit works similarly in .Net). Unit testing is just the beginning though, you might look at code coverage tools to give you an indication of how complete your unit testing is (open source tools EMMA and Cobertura provide this for Java). You might also use hudson to automatically execute these tests whenever a change is checked into your source tree (hudson will give you an indication of how stable your developments are, lots of fluctuations in test case pass rates indicate that you're making lots of breaking changes for example).
After that, you could look at something like Findbugs for Java to spot dodgy practices. If you are using Eclipse for Java development you can get the metrics plugin to perform various other pieces of analysis on your code but you need to know what these metrics actually indicate.
Ultimately, the quality of your product will be defined by whether you can reliably introduce changes that achieve their aim without causing regressions. The tools above are just the beginning, it takes a long time to become good at testing (I'm not there myself) but if you introduce the tools and practices to your organisation you can work on it from there.