Certainly unit testing, whether test-first or not, should be your first line of defense, ensuring that each piece of your application works the way you think it should. However, the type of testing you're talking about, where it can be helpful to get another pair of eyes, is more in the area of acceptance tests -- does the application as a whole work the way it should; does it work for various weird scenarios or behaviors, etc.
One helpful approach is to imagine personas: first test the application as yourself, but then test it again imagining that you are 85 years old, can't see terribly well, and don't use a mouse that well. You may tend to click on the brightest or largest thing, assuming it's what you're supposed to do, which it may not be. Now imagine you're 12 and in a tearing hurry. No way are you going to read instructions. Does it still work?
For any given field, what are the edge cases of what a person might type in? What happens if you type only spaces? Only numbers into a textual field? What happens if you type HTML? Javascript? Something in a non-western alphabet? What if you type something really really long?
The key is not just to test the "happy path", where the user goes through the application the way you had in mind. Go through the application in ways no one ever should. Because... they will.
The other important piece is never to ignore anything. It's easy to have a weird screen come up and say to yourself "Oh, that's just a fluke." You have to make yourself notice and track down everything that isn't just as it should be.
There are always constraints on how much testing you can do. Within the constraints, you obviously need to construct tests. Clearly you want to construct tests for the most critical areas first (security, possibility of damage, loss of data, functionality).
Other than the functional specification, you're not likely to get a lot of manual help deciding what to test. But you can get automated help in the form of test coverage tools. These tools tell you what code you have tested, and therefore what code you have NOT tested. By inspecting the untested code, you can determine if it is more or less critical, and therefore more or less deserving of having tests coded for it before release. Test coverage tools also tell you the ratio of tested code versus total code, and its an industry best practice to ensure that this ratio is 70% or above. You can use this data to negotiate more time with your boss by a simple artifice: "We only have 15% test coverage... dare we release it?"
I think TDD is exactly what you're looking for. First write tests, then write the code that passes the tests. You don't need anyone else apart from you (some help with the tests would be recommended, though) and you'll have a clearer idea of what the tool should do, even before start coding on it.
I hate to say it, but I think in your case Alex Tingle's right. It's an impossible situation.
JacobM and Santi are correct in mentioning unit testing, acceptance testing, and test-driven development. I'd add code coverage and static analysis tools to that list.
But while TDD or basic unit testing will generally pay off in decreased testing time, lowered defect rates, and ease of maintenance, they won't help you deliver on time in a deathmarch. This is especially true if you aren't experienced at writing automated tests.
Politely phrased, your boss is asking you to incur technical debt. Correctly phrased, he's asking you to disregard professional ethics.
Smile, say "yes sir," do the best you can in the time allotted, and update your resume.
One thing to bear in mind is that there's a natural tendency for a developer to test the "best path" for their code. In other words, you wrote it, so you know that you're supposed to click on certain spots, type in certain things, and so you test for that. This is, of course, important.
There are some good suggestions here, but the one that seems to be missed by most (but not all) is negative testing. Basically, you need to test the boundaries and you need to test the malicious. As noted, put script code in fields such as:
<script>alert('abc')</script>
It becomes pretty obvious that you failed to encode properly if you get an alert! Another thing to do is:
abc' or 'a' = 'a'
That will potentially show SQL injection problems in things like authentication. You can also test SQL injection with things like:
abc'; drop table users; select * from dual where 'a' = '
If your table just went away, you have an issue! There are a huge number of examples, but at the very least you need to spend some time testing the OWASP top 10.
Other places where you want to test is things like very large numbers, especially when expecting integer input on a 32 bit platform, negative values, no values, etc. Basically, test that the desired flows work and then do everything you can to break it.
I agree with the previous answer posted on the value and effectiveness of Test Driven Development and Unit Testing. If done correctly, a TDD process in which you write your unit tests before you write the production/deliverable code will help maintain your focus and help validate your design and interfaces. Additionally, other developers will be able to have a clear and consistent way to work from on how to use and consume your code in a very straight forward manner. Just keep in mind that Unit Testing is not the same and is not a substitute for full integration testing. In this approach, you may still need to write a full integration test plan.
I work primarliy in .NET, and have had nothing but good results in working with NUnit.
I haven't worked in PHP before, but from what I've seen, you may want to consider SimpleTest or PHPUnit.
Given your boss's requirements, which you have to respect while you work for him and up until you can change his mind, you have given the correct answer in the question.
发布评论
评论（8）
当然，单元测试，无论是否测试优先，都应该是您的第一道防线，确保应用程序的每个部分都按照您认为应该的方式工作。然而，您所谈论的测试类型（获得另一双眼睛可能会有所帮助）更多的是在验收测试领域 - 应用程序作为一个整体是否按其应有的方式工作？它是否适用于各种奇怪的场景或行为等。
一种有用的方法是想象人物角色：首先以您自己的身份测试应用程序，然后再次测试它，想象您已经 85 岁了，视力不太好，而且不看重应用程序。鼠标用得不好。您可能倾向于点击最亮或最大的东西，假设这是您应该做的事情，但事实可能并非如此。现在想象一下，你 12 岁，心急如焚。您绝对不会阅读说明。还有效吗？
对于任何给定字段，人们可能输入的内容的边缘情况是什么？如果只输入空格会怎样？文本字段中只能输入数字吗？如果您输入 HTML 会发生什么？ JavaScript？非西方字母表中的东西？如果您输入的内容非常长怎么办？
关键不仅仅是测试“快乐路径”，即用户按照您想要的方式浏览应用程序。以任何人不应该的方式完成申请。因为……他们会的。
另一个重要的部分是永远不要忽视任何事情。很容易出现一个奇怪的屏幕并对自己说“哦，这只是侥幸”。你必须让自己注意到并追踪一切不正常的事情。
Certainly unit testing, whether test-first or not, should be your first line of defense, ensuring that each piece of your application works the way you think it should. However, the type of testing you're talking about, where it can be helpful to get another pair of eyes, is more in the area of acceptance tests -- does the application as a whole work the way it should; does it work for various weird scenarios or behaviors, etc.
One helpful approach is to imagine personas: first test the application as yourself, but then test it again imagining that you are 85 years old, can't see terribly well, and don't use a mouse that well. You may tend to click on the brightest or largest thing, assuming it's what you're supposed to do, which it may not be. Now imagine you're 12 and in a tearing hurry. No way are you going to read instructions. Does it still work?
For any given field, what are the edge cases of what a person might type in? What happens if you type only spaces? Only numbers into a textual field? What happens if you type HTML? Javascript? Something in a non-western alphabet? What if you type something really really long?
The key is not just to test the "happy path", where the user goes through the application the way you had in mind. Go through the application in ways no one ever should. Because... they will.
The other important piece is never to ignore anything. It's easy to have a weird screen come up and say to yourself "Oh, that's just a fluke." You have to make yourself notice and track down everything that isn't just as it should be.
您可以进行的测试数量始终受到限制。在限制范围内，您显然需要构建测试。显然，您希望首先为最关键的领域构建测试（安全性、损坏的可能性、数据丢失、功能）。
除了功能规范之外，您不太可能获得大量手动帮助来决定测试什么。但您可以通过测试覆盖率工具的形式获得自动化帮助。这些工具会告诉您已经测试了哪些代码，以及尚未测试哪些代码。通过检查未经测试的代码，您可以确定它是否或多或少重要，因此或多或少值得在发布之前对其进行测试。测试覆盖率工具还会告诉您已测试代码与总代码的比率，并且确保该比率为 70% 或以上是行业最佳实践。您可以使用这些数据通过一个简单的技巧与您的老板协商更多时间：“我们只有 15% 的测试覆盖率......我们敢发布它吗？”
可以在此处找到适用于 PHP 的测试覆盖率工具：
语义设计 PHP 测试覆盖率工具
There are always constraints on how much testing you can do. Within the constraints, you obviously need to construct tests. Clearly you want to construct tests for the most critical areas first (security, possibility of damage, loss of data, functionality).
Other than the functional specification, you're not likely to get a lot of manual help deciding what to test. But you can get automated help in the form of test coverage tools. These tools tell you what code you have tested, and therefore what code you have NOT tested. By inspecting the untested code, you can determine if it is more or less critical, and therefore more or less deserving of having tests coded for it before release. Test coverage tools also tell you the ratio of tested code versus total code, and its an industry best practice to ensure that this ratio is 70% or above. You can use this data to negotiate more time with your boss by a simple artifice: "We only have 15% test coverage... dare we release it?"
A test coverage tool that works with PHP can be found here:
Semantic Designs PHP Test Coverage Tool
我认为 TDD 正是您正在寻找的。
首先编写测试，然后编写通过测试的代码。除了您之外，您不需要任何其他人（不过，建议在测试方面提供一些帮助），并且即使在开始对其进行编码之前，您也会更清楚地了解该工具应该做什么。
http://en.wikipedia.org/wiki/Test-driven_development
I think TDD is exactly what you're looking for.
First write tests, then write the code that passes the tests. You don't need anyone else apart from you (some help with the tests would be recommended, though) and you'll have a clearer idea of what the tool should do, even before start coding on it.
http://en.wikipedia.org/wiki/Test-driven_development
您的雇主显然不认为测试很重要。你应该辞职并找到一份合适的工作。
Your employer clearly doesn't think that testing is important. You should quit and find a proper job.
我不想这么说，但我认为就你的情况而言，亚历克斯·廷格尔是对的。这是不可能的情况。
JacobM 和 Santi 在提到单元测试、验收测试和测试驱动开发方面是正确的。我会将代码覆盖率和静态分析工具添加到该列表中。
但是，虽然 TDD 或基本单元测试通常会在减少测试时间、降低缺陷率和易于维护方面带来回报，但它们无法帮助您在死亡行军中按时交付。如果您没有编写自动化测试的经验，则尤其如此。
委婉地说，你的老板要求你承担技术债务。用正确的措辞来说，他是在要求你无视职业道德。
微笑，说“是的，先生”，在规定的时间内尽力而为，并更新你的简历。
I hate to say it, but I think in your case Alex Tingle's right. It's an impossible situation.
JacobM and Santi are correct in mentioning unit testing, acceptance testing, and test-driven development. I'd add code coverage and static analysis tools to that list.
But while TDD or basic unit testing will generally pay off in decreased testing time, lowered defect rates, and ease of maintenance, they won't help you deliver on time in a deathmarch. This is especially true if you aren't experienced at writing automated tests.
Politely phrased, your boss is asking you to incur technical debt. Correctly phrased, he's asking you to disregard professional ethics.
Smile, say "yes sir," do the best you can in the time allotted, and update your resume.
需要记住的一件事是，开发人员自然倾向于测试其代码的“最佳路径”。换句话说，你写了它，所以你知道你应该点击某些位置，输入某些内容，然后你进行测试。这当然很重要。
这里有一些很好的建议，但大多数（但不是全部）似乎错过了负面测试。基本上，您需要测试边界，并且需要测试恶意行为。如前所述，将脚本代码放入以下字段中：
如果收到警报，很明显您未能正确编码！另一件要做的事情是：
这可能会在身份验证等方面显示 SQL 注入问题。您还可以使用以下内容来测试 SQL 注入：
如果您的表刚刚消失，那么您就有问题了！有大量的示例，但至少您需要花一些时间测试 OWASP 前 10 名。您
想要测试的其他地方是非常大的数字，尤其是在 32 位平台上期望整数输入时，负值、无值等。基本上，测试所需的流程是否有效，然后尽一切努力打破它。
One thing to bear in mind is that there's a natural tendency for a developer to test the "best path" for their code. In other words, you wrote it, so you know that you're supposed to click on certain spots, type in certain things, and so you test for that. This is, of course, important.
There are some good suggestions here, but the one that seems to be missed by most (but not all) is negative testing. Basically, you need to test the boundaries and you need to test the malicious. As noted, put script code in fields such as:
It becomes pretty obvious that you failed to encode properly if you get an alert! Another thing to do is:
That will potentially show SQL injection problems in things like authentication. You can also test SQL injection with things like:
If your table just went away, you have an issue! There are a huge number of examples, but at the very least you need to spend some time testing the OWASP top 10.
Other places where you want to test is things like very large numbers, especially when expecting integer input on a 32 bit platform, negative values, no values, etc. Basically, test that the desired flows work and then do everything you can to break it.
我同意之前发布的关于测试驱动开发和单元测试的价值和有效性的答案。如果做得正确，在编写生产/可交付代码之前编写单元测试的 TDD 流程将有助于保持您的注意力并帮助验证您的设计和界面。此外，其他开发人员将能够以清晰一致的方式工作，以非常直接的方式使用和使用您的代码。请记住，单元测试不同，并且不能替代完整的集成测试。在这种方法中，您可能仍然需要编写完整的集成测试计划。
我主要在 .NET 中工作，并且在使用 NUnit 时只取得了良好的结果。
我以前没有使用过 PHP，但从我所见，您可能需要考虑 SimpleTest或 PHPUnit。
I agree with the previous answer posted on the value and effectiveness of Test Driven Development and Unit Testing. If done correctly, a TDD process in which you write your unit tests before you write the production/deliverable code will help maintain your focus and help validate your design and interfaces. Additionally, other developers will be able to have a clear and consistent way to work from on how to use and consume your code in a very straight forward manner. Just keep in mind that Unit Testing is not the same and is not a substitute for full integration testing. In this approach, you may still need to write a full integration test plan.
I work primarliy in .NET, and have had nothing but good results in working with NUnit.
I haven't worked in PHP before, but from what I've seen, you may want to consider SimpleTest or PHPUnit.
鉴于你老板的要求，在你为他工作期间你必须尊重这些要求，直到你改变他的想法为止，你已经在问题中给出了正确的答案。
Given your boss's requirements, which you have to respect while you work for him and up until you can change his mind, you have given the correct answer in the question.